From jason-openssh at shalott.net  Sat Dec  1 00:31:28 2001
From: jason-openssh at shalott.net (Jason Stone)
Date: Fri, 30 Nov 2001 05:31:28 -0800 (PST)
Subject: openssh 2.9p2 release 8.7 security alert!!!
In-Reply-To: <002c01c178a4$7f6241c0$6501a8c0@pureview.com>
Message-ID: <20011130052952.T27799-100000@walter>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> My system was compromised a few days ago.
> The cracker attacked the system through openssh 2.9p2 release 8.7.
> I attached part of the log file.

Has this been verified yet by anyone else?  Has there been an announcement
from the openssh core team?


 -Jason

 -----------------------------------------------------------------------
 I worry about my child and the Internet all the time, even though she's
 too young to have logged on yet.  Here's what I worry about.  I worry
 that 10 or 15 years from now, she will come to me and say "Daddy, where
 were you when they took freedom of the press away from the Internet?"
	-- Mike Godwin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE8B4o0swXMWWtptckRAs1rAKDtV1LUzf2HLM25Zr/cpBW0S15cHwCfXN74
wRqD7vcGsWreX6vHZu6GqAU=
=BlkM
-----END PGP SIGNATURE-----



From ed at UDel.Edu  Sat Dec  1 00:48:48 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 30 Nov 2001 08:48:48 -0500 (EST)
Subject: [PATCH] tcp-wrappers support extended to x11 forwards 
In-Reply-To: <200111300716.fAU7GDP31905@rotta.tmt.tele.fi>
Message-ID: <Pine.SOL.4.30.0111300822300.21584-100000@mahler.udel.edu>

On Fri, 30 Nov 2001, Osmo Paananen wrote:

> Date: Fri, 30 Nov 2001 09:16:13 +0200
> From: Osmo Paananen <odie at rotta.media.sonera.net>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Kevin Steves <stevesk at pobox.com>, openssh-unix-dev at mindrot.org
> Subject: Re: [PATCH] tcp-wrappers support extended to x11 forwards
>
> > I you login to SystemB with X forwarding enabled to SystemA, then an
> > attacker gets your fake cookie on SystemB, how do you propose to prevent
> > him from running X programs and displaying on SystemA - even with the
> > proposed X wrapper support?  It doesn't seem stoppable, since you've
> > enable forwarding for SystemB-to-SystemA, the attacker is logged into
> > SystemB, and has your fake cookie...
>
> ACL won't protect me in that case.
>
> But without ACL the attack can come from host C which is not related to
> A or B.  The attacker doesn't have the fake cookie, but he may guess it
> (by trying several times).  I don't know how possible values there are for
> the fake cookie. My guess is that there is a lot of them. That is why
> this is not a big security hole.

Okay... I see now.  It's a little scary that even with a valid "fake"
cookie that has somehow been stolen and put on SystemC, that a hacker on
SystemC could display X progrms on SystemA.  I would have guessed that
unless you configured ssh/sshd to explicitly allow this kind of X
forwarding, it wouldn't work - but I just tried it and it works fine.  I
guess this is why there has been talk lately about the "fake" X server
port being bound to localhost explicity or not (at least I think that's
what they were talking about)...

> Sure, the attack will be noisy and time consuming.
>
> But still the hole is there. And there is no reason for it to be there.

I agree.  There are already enough "gotchas" with supporting X
forwarding, without having to create more with the "fake" X server socket
itself.  It'd be nice if there were a way to "wrapper" the "fake" X server
socket to not allow this... which I think is exactly your suggestion - now
that I understand a little more. ;-)

On a side note, I recently reported a bug (and received no response)
that is relevent to the above.  If a hacker were actually trying to use
random cookies from SystemC to diplay on SystemA through SystemB... there
is a bug in ssh/sshd were they hang around instead of exiting when you log
out - and in this scenario, the bug allows the hacker to keep trying
cookies forever or until you explicitly kill ssh/sshd.  The bug itself
seems to cause ssh/sshd to hang instead of exiting.  I also submitted the
exact details on how to reproduce the bug.  That was weeks ago...

Regards,

	Ed

Ed Phillips <ed at udel.edu> 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 matthew at debian.org  Sat Dec  1 02:05:21 2001
From: matthew at debian.org (Matthew Vernon)
Date: 30 Nov 2001 15:05:21 +0000
Subject: Authentication response too long with protocol 2 and ssh 3.0.1p1
In-Reply-To: Matthew Vernon's message of Fri, 30 Nov 2001 11:15:35 GMT
References: <15367.25933.558190.959265@rapun.sel.cam.ac.uk>
Message-ID: <5bk7w8fgem.fsf@chiark.greenend.org.uk>

Matthew Vernon <matthew at sel.cam.ac.uk> writes:

[snip lots of garbage]

Erm. sorry about that. More embarrasingly still, I can't now replicate
the problem I was having earlier...

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


From Tariq.Lahyani at aa.com  Sat Dec  1 03:26:26 2001
From: Tariq.Lahyani at aa.com (Tariq Lahyani)
Date: Fri, 30 Nov 2001 10:26:26 -0600
Subject: scp
Message-ID: <sc075ef9.064@aahdq01-ms28.aa.com>

Hello again -

Has anybody tried scp or sftp successfully with openssh_3. I haven't been able to so far.  Here is what happens when I run the command:

home>scp -v myuser at machine4:/tmp/myfile ./file_new
Executing: program /opt/openssh2/bin/ssh host machine4, user myuser, command scp -v -f /tmp/myfile
OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
...
...
debug1: ssh-userauth2 successful: method publickey
debug1: fd 8 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: Sending command: scp -v -f /tmp/myfile
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug1: channel 0: read<=0 rfd 8 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
...
...

Is it normal that the command it sends is diff. than the original one? I mean, it adds -f and suppresses the destination file.  The same scenario happens with sftp. Please let me know if you have an idea what might be going wrong here. Thanks.

Tariq



>>> Damien Miller <djm at mindrot.org> 11/28/01 05:41PM >>>
On Wed, 28 Nov 2001, Tariq Lahyani wrote:

> Hello -
>
> I am trying to use scp (openssh_3.0), but every time I run it, I get
> the following error:
>
> stty: Not a typewriter

Do you have .bashrc or similar scripts that are being run when non-login
sessions are started? If so, fix them.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org 
| But in reality there are atoms and space - Democritus (c. 400 BCE)




From pekkas at netcore.fi  Sat Dec  1 03:37:30 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 30 Nov 2001 18:37:30 +0200 (EET)
Subject: Support for PKCS cryptocards..
In-Reply-To: <20011124125320.E22093@folly>
Message-ID: <Pine.LNX.4.33.0111301834470.18141-100000@netcore.fi>

On Sat, 24 Nov 2001, Markus Friedl wrote:
> On Sat, Nov 24, 2001 at 10:12:18AM +0200, Pekka Savola wrote:
> > Hello all,
> > 
> > You may find this interesting:
> > 
> > http://jemmari.tky.hut.fi/sc/
> > 
> > Here in Finland, we have cryptocards which have a PKCS#15 interface. They
> > already have RSA keys stored in them, and can be used in various
> > applications. I'm sure they're getting more common elsewhere too.
> 
> but you don't wan't to reuse keys?

Sorry for the delay, I forgot to answer this message.

The card has a static keypair that cannot be removed; the private key 
cannot be read.  In that context, if you want to replace the keys, or 
substitute the key with your current one, it's impossible.

However, most cards have free memory for storing additional keys,
certificates etc., so if you're so inclined, you might be able to use
those more flexibly.  Nothing prevents from reading the private key
though.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From scott.burch at camberwind.com  Sat Dec  1 06:34:33 2001
From: scott.burch at camberwind.com (Scott Burch)
Date: Fri, 30 Nov 2001 13:34:33 -0600
Subject: Authentication response too long with protocol 2 and ssh 3.0.1p1
References: <15367.25933.558190.959265@rapun.sel.cam.ac.uk> <5bk7w8fgem.fsf@chiark.greenend.org.uk>
Message-ID: <012e01c179d6$09d6f850$f24318ac@ent.core.medtronic.com>

Matt,

What version of OpenSSH is the server running you are connecting to? I can
reproduce this problem by trying to sftp (with the version in OpenSSH
3.0.1p1) to a machine running OpenSSH 2.9p2. The message too long message
only occurs with sftp, not a straight ssh connection in this case. Since you
aren't having the problem now, you may have already updated the server.

-Scott

----- Original Message -----
From: "Matthew Vernon" <matthew at debian.org>
To: <openssh-unix-dev at mindrot.org>
Sent: Friday, November 30, 2001 9:05 AM
Subject: Re: Authentication response too long with protocol 2 and ssh
3.0.1p1


> Matthew Vernon <matthew at sel.cam.ac.uk> writes:
>
> [snip lots of garbage]
>
> Erm. sorry about that. More embarrasingly still, I can't now replicate
> the problem I was having earlier...
>
> Matthew
>
> --
> "At least you know where you are with Microsoft."
> "True. I just wish I'd brought a paddle."
> http://www.debian.org
>
>



From stevesk at pobox.com  Sat Dec  1 07:09:41 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 30 Nov 2001 12:09:41 -0800 (PST)
Subject: [PATCH] tcp-wrappers support extended to x11 forwards 
In-Reply-To: <200111300716.fAU7GDP31905@rotta.tmt.tele.fi>
Message-ID: <Pine.HPX.4.42.0111301202550.1540-100000@jenny>

On Fri, 30 Nov 2001, Osmo Paananen wrote:
:But without ACL the attack can come from host C which is not related to
:A or B.  The attacker doesn't have the fake cookie, but he may guess it
:(by trying several times).  I don't know how possible values there are for
:the fake cookie. My guess is that there is a lot of them. That is why
:this is not a big security hole.

if it's MIT-MAGIC-COOKIE-1, it's 128 bits.



From stevesk at pobox.com  Sat Dec  1 07:15:57 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 30 Nov 2001 12:15:57 -0800 (PST)
Subject: [PATCH] tcp-wrappers support extended to x11 forwards 
In-Reply-To: <Pine.SOL.4.30.0111300822300.21584-100000@mahler.udel.edu>
Message-ID: <Pine.HPX.4.42.0111301210320.1540-100000@jenny>

On Fri, 30 Nov 2001, Ed Phillips wrote:
:Okay... I see now.  It's a little scary that even with a valid "fake"
:cookie that has somehow been stolen and put on SystemC, that a hacker on
:SystemC could display X progrms on SystemA.  I would have guessed that
:unless you configured ssh/sshd to explicitly allow this kind of X
:forwarding, it wouldn't work - but I just tried it and it works fine.  I
:guess this is why there has been talk lately about the "fake" X server
:port being bound to localhost explicity or not (at least I think that's
:what they were talking about)...

yes, that's what we are talking about.

:On a side note, I recently reported a bug (and received no response)
:that is relevent to the above.  If a hacker were actually trying to use
:random cookies from SystemC to diplay on SystemA through SystemB... there
:is a bug in ssh/sshd were they hang around instead of exiting when you log
:out - and in this scenario, the bug allows the hacker to keep trying
:cookies forever or until you explicitly kill ssh/sshd.  The bug itself
:seems to cause ssh/sshd to hang instead of exiting.  I also submitted the
:exact details on how to reproduce the bug.  That was weeks ago...

i don't see that.  what is the bug number?



From matthew at sel.cam.ac.uk  Sat Dec  1 12:57:43 2001
From: matthew at sel.cam.ac.uk (Matthew Vernon)
Date: Sat, 1 Dec 2001 01:57:43 +0000
Subject: Authentication response too long with protocol 2 and ssh 3.0.1p1
In-Reply-To: <012e01c179d6$09d6f850$f24318ac@ent.core.medtronic.com>
References: <15367.25933.558190.959265@rapun.sel.cam.ac.uk>
	<5bk7w8fgem.fsf@chiark.greenend.org.uk>
	<012e01c179d6$09d6f850$f24318ac@ent.core.medtronic.com>
Message-ID: <15368.14615.580966.897369@rapun.sel.cam.ac.uk>

Scott Burch writes:
 > Matt,
 > 
 > What version of OpenSSH is the server running you are connecting to? I can
 > reproduce this problem by trying to sftp (with the version in OpenSSH
 > 3.0.1p1) to a machine running OpenSSH 2.9p2. The message too long message
 > only occurs with sftp, not a straight ssh connection in this case. Since you
 > aren't having the problem now, you may have already updated the server.
 
No, I was using ssh/scp. In one case it was a 2.3.0 server; I can't
now reproduce this, though.

Matthew

-- 
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org


From matthew at sel.cam.ac.uk  Sat Dec  1 13:08:46 2001
From: matthew at sel.cam.ac.uk (Matthew Vernon)
Date: Sat, 1 Dec 2001 02:08:46 +0000
Subject: ssh-add default
Message-ID: <15368.15278.509019.706984@rapun.sel.cam.ac.uk>

Hi,

Since we're doing protocol v2 by default, shouldn't ssh-add default to
one of the v2 keys, rather than ~/.ssh/identity ?

Matthew

-- 
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org


From matthew at debian.org  Sat Dec  1 13:12:32 2001
From: matthew at debian.org (Matthew Vernon)
Date: 01 Dec 2001 02:12:32 +0000
Subject: mips/mipsel problem
Message-ID: <5bn113n0xb.fsf@chiark.greenend.org.uk>

Hi,

There seems to be a problem with the arc4random code on mips/mipsel,
producing the following error message:

Couldn't obtain random bytes (error 604389476)

To quote the bug submitter:
"On mips and mipsel, the above error message is frequently seen when
calling
ssh with a command, usually several times in rapid succession,
although that
is not always the case.  The error appears to come from the OpenBSD
compat code
for arc4random, even if arc4 is not the cipher in use!

What the error number means I am not sure of, as it comes from inside
SSL, and I can't tell what it means from a quick glance at the code. 
A call to one of the more descriptive error calls at this point may be
a good idea.

So I can see two possible things to help the problem:
1. report a more verbose error message so that one might understand
why it
   is failing so it might be fixed.
2. don't initialize the arc4 random routines if arc4 is not used."

I don't have a mips/mipsel box to hand, so I can't comment
myself. Full details are at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=115767&repeatmerged=yes

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


From ssklar at stanford.edu  Sat Dec  1 14:33:35 2001
From: ssklar at stanford.edu (Sandor W. Sklar)
Date: Fri, 30 Nov 2001 19:33:35 -0800
Subject: ssh/sshd_config option confusion ...
Message-ID: <p0510101cb82dfd7762f2@[171.64.18.74]>

Hello,

The item that causes me the most difficulty in deploying OpenSSH (and 
the commercial ssh, as well) is confusion over the large number of 
options for the configuration file; while the man page gives an 
explanation of each one, they are listed alphabetically there, with 
no "logical" grouping.

For my own use, I've created a heavily annotated sample sshd_config 
file, grouping all of the various directives in a way that seemed to 
make the most sense.  This file is available at:

  <http://whippet.stanford.edu/~ssklar/misc/openssh/sshd_config.txt>

... if anyone is interested; I'd appreciate being mailed if someone 
notices an error or omission (I based it on the 3.0.1p1 man pages).

If there is any interest in replacing the current sample conf files 
that are bundled with the distribution with this one (and the one 
I'll be doing for ssh_config), I'd be happy to keep up the 
maintenance on it for future changes to the software.  I'm not a 
programmer, so I can't contribute code, but I really appreciate the 
work of everyone who does, and perhaps this is some small way I can 
contribute.

Thanks, --Sandy
-- 
   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Sandor W. Sklar  -  Unix Systems Administrator  -  Stanford University ITSS
   Non impediti ratione cogitationis.   <http://whippet.stanford.edu/~ssklar/>
   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


From djm at mindrot.org  Sat Dec  1 17:51:21 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 1 Dec 2001 17:51:21 +1100 (EST)
Subject: mips/mipsel problem
In-Reply-To: <5bn113n0xb.fsf@chiark.greenend.org.uk>
Message-ID: <Pine.LNX.4.33.0112011750130.14356-100000@mothra.mindrot.org>

On 1 Dec 2001, Matthew Vernon wrote:

> Hi,
> 
> There seems to be a problem with the arc4random code on mips/mipsel,
> producing the following error message:
> 
> Couldn't obtain random bytes (error 604389476)

That error is caused because an OpenSSL RAND_bytes() call is failing. 
You need to investiagte why that is happening. Does the MIPS have 
/dev/urandom?

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From markus at openbsd.org  Sun Dec  2 09:11:28 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 1 Dec 2001 23:11:28 +0100
Subject: ssh-add default
In-Reply-To: <15368.15278.509019.706984@rapun.sel.cam.ac.uk>; from matthew@sel.cam.ac.uk on Sat, Dec 01, 2001 at 02:08:46AM +0000
References: <15368.15278.509019.706984@rapun.sel.cam.ac.uk>
Message-ID: <20011201231128.A20639@folly>

On Sat, Dec 01, 2001 at 02:08:46AM +0000, Matthew Vernon wrote:
> Since we're doing protocol v2 by default, shouldn't ssh-add default to
> one of the v2 keys, rather than ~/.ssh/identity ?

i'd prefer ssh-add and ssh-keygen to have no defaults.


From gert at greenie.muc.de  Sat Dec  1 23:34:59 2001
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 1 Dec 2001 13:34:59 +0100
Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability
In-Reply-To: <200111282306.fASN6owa005550@rollcage.bl.echidna.id.au>; from carl@bl.echidna.id.au on Thu, Nov 29, 2001 at 10:06:50AM +1100
References: <200111282306.fASN6owa005550@rollcage.bl.echidna.id.au>
Message-ID: <20011201133459.A4412@greenie.muc.de>

Hi,

On Thu, Nov 29, 2001 at 10:06:50AM +1100, carl at bl.echidna.id.au wrote:
[..]
> fame.  Where would we be if Eric Allman didn't make sendmail 
> interact better with M$'s broken SMTP AUTH?  If Apache
> insisted on only supporting "proper" HTTP?  If Mozilla only parsed 
> 100% legal HTML (if anyone can define that anyway?). If
> your resolver library rejected A records with _'s in them? 

All of these are good examples NOT to include more broken code into
additional packages.

Make decent standards, and then make programs adhere to it.

If vendors then show up not coding according to standards, their
software will not work and their users will complain until the vendor
eventually fixes the problem (which may be different for Microsoft, 
but ssh.com is not MS, and for their users, there are enough interesting
alternatives if they refuse to fix ssh.com).

gert
-- 
Gert Doering
Mobile communications ... right now writing from *train near Osnabrueck*
... mobile phone: +49 177 2160221 ... or mail me:  gert at greenie.muc.de


From carson at taltos.org  Mon Dec  3 05:30:14 2001
From: carson at taltos.org (Carson Gaspar)
Date: Sun, 02 Dec 2001 13:30:14 -0500
Subject: [PATCH] tcp-wrappers support extended to x11 forwards 
In-Reply-To: <Pine.HPX.4.42.0111301202550.1540-100000@jenny>
References: <Pine.HPX.4.42.0111301202550.1540-100000@jenny>
Message-ID: <153717421.1007299814@[192.168.0.1]>



--On Friday, November 30, 2001 12:09 PM -0800 Kevin Steves 
<stevesk at pobox.com> wrote:

> if it's MIT-MAGIC-COOKIE-1, it's 128 bits.

Generated from what entropy source? I've never seen X require /dev/random 
et. al., so I seriously doubt the quality of their PRNG.

-- 
Carson Gaspar - carson at taltos.org
Queen Trapped in a Butch Body



From markus at openbsd.org  Mon Dec  3 09:10:36 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 2 Dec 2001 23:10:36 +0100
Subject: [PATCH] tcp-wrappers support extended to x11 forwards
In-Reply-To: <153717421.1007299814@[192.168.0.1]>; from carson@taltos.org on Sun, Dec 02, 2001 at 01:30:14PM -0500
References: <Pine.HPX.4.42.0111301202550.1540-100000@jenny> <153717421.1007299814@[192.168.0.1]>
Message-ID: <20011202231036.A28280@folly>

On Sun, Dec 02, 2001 at 01:30:14PM -0500, Carson Gaspar wrote:
> 
> 
> --On Friday, November 30, 2001 12:09 PM -0800 Kevin Steves 
> <stevesk at pobox.com> wrote:
> 
> > if it's MIT-MAGIC-COOKIE-1, it's 128 bits.
> 
> Generated from what entropy source? I've never seen X require /dev/random 
> et. al., so I seriously doubt the quality of their PRNG.

this is not about X, this is about the fake cookie.


From stevesk at pobox.com  Mon Dec  3 09:59:37 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Sun, 2 Dec 2001 14:59:37 -0800 (PST)
Subject: [PATCH] tcp-wrappers support extended to x11 forwards 
In-Reply-To: <153717421.1007299814@[192.168.0.1]>
Message-ID: <Pine.HPX.4.42.0112021453360.2596-100000@jenny>

On Sun, 2 Dec 2001, Carson Gaspar wrote:
:--On Friday, November 30, 2001 12:09 PM -0800 Kevin Steves
:> if it's MIT-MAGIC-COOKIE-1, it's 128 bits.
:
:Generated from what entropy source? I've never seen X require /dev/random
:et. al., so I seriously doubt the quality of their PRNG.

in this case, we are talking about the proxy secret/cookie, which is
generated by ssh, so for openssh it depends on how good the client
platform's arc4random() is.



From djm at mindrot.org  Tue Dec  4 12:33:17 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 4 Dec 2001 12:33:17 +1100 (EST)
Subject: gnome-ssh-askpass and kinput2
Message-ID: <Pine.LNX.4.33.0112041231530.8740-100000@mothra.mindrot.org>

Has anyone had problems using gnome-ssh-askpass with kinput2 running?
If I click in the text entry box, gnome-ssh-askpass hangs - which is
bad because it has grabbed the Xserver at that point.

-d



From bulch at ftc.ru  Tue Dec  4 23:46:10 2001
From: bulch at ftc.ru (Oleg Bulavsky)
Date: Tue, 04 Dec 2001 18:46:10 +0600
Subject: OpenSSH 3.x on SCO OpenServer 5.x
Message-ID: <3C0CC592.6050707@ftc.ru>

This patch allow to use NGROUPS value compiled into kernel (up to 256) instead 
of statical NGROUPS_MAX (8)

-- 
Windows 95: Multicrashing, OS/2: Multitasking, Win NT: MultiSleeping

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: defines.h.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011204/c7ad4a85/attachment.ksh 

From Markus_Friedl at genua.de  Tue Dec  4 23:48:19 2001
From: Markus_Friedl at genua.de (Markus Friedl)
Date: Tue, 4 Dec 2001 13:48:19 +0100
Subject: OpenSSH 3.0.2 fixes UseLogin vulnerability
Message-ID: <20011204134819.A26751@skaidan>

OpenSSH 3.0.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.

Important Changes:
==================

        This release fixes a vulnerability in the UseLogin option
        of OpenSSH.  This option is not enabled in the default
        installation of OpenSSH.

        However, if UseLogin is enabled by the administrator, all
        versions of OpenSSH prior to 3.0.2 may be vulnerable to
        local attacks.

        The vulnerability allows local users to pass environment
        variables (e.g. LD_PRELOAD) to the login process.  The login
        process is run with the same privilege as sshd (usually
        with root privilege).

        Do not enable UseLogin on your machines or disable UseLogin
        again in /etc/sshd_config:
		UseLogin no

We also have received many reports about attacks against the crc32
bug.  This bug has been fixed about 12 months ago in OpenSSH 2.3.0.
However, these attacks cause non-vulnerable daemons to chew a lot
of cpu since the crc32 attack sends a tremendously large amount of
data which must be processed.

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller and Ben Lindstrom.



The following patch fixes the UseLogin vulnerability in OpenSSH 3.0.1 and
earlier releases.

--- session.c	11 Oct 2001 13:45:21 -0000	1.108
+++ session.c	1 Dec 2001 22:14:39 -0000
@@ -875,6 +875,7 @@
 		child_set_env(&env, &envsize, "TZ", getenv("TZ"));
 
 	/* Set custom environment options from RSA authentication. */
+	if (!options.use_login)
 	while (custom_environment) {
 		struct envstring *ce = custom_environment;
 		char *s = ce->s;



From djast at cs.toronto.edu  Wed Dec  5 08:18:33 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 4 Dec 2001 16:18:33 -0500
Subject: [PATCH] tcp-wrappers support extended to x11 forwards 
In-Reply-To: Your message of "Fri, 30 Nov 2001 08:48:48 EST."
             <Pine.SOL.4.30.0111300822300.21584-100000@mahler.udel.edu> 
Message-ID: <01Dec4.161839edt.453149-29217@jane.cs.toronto.edu>

On Fri, 30 Nov 2001 08:48:48 EST, Ed Phillips writes:
> 
> On a side note, I recently reported a bug (and received no response)
> that is relevent to the above.  If a hacker were actually trying to use
> random cookies from SystemC to diplay on SystemA through SystemB... there
> is a bug in ssh/sshd were they hang around instead of exiting when you log
> out - and in this scenario, the bug allows the hacker to keep trying
> cookies forever or until you explicitly kill ssh/sshd.  The bug itself
> seems to cause ssh/sshd to hang instead of exiting.  I also submitted the
> exact details on how to reproduce the bug.  That was weeks ago...

I haven't seen any further mention of that bug here either.  The bug is
still present (as of 3.0.2p1).

The bug occurs anytime an X connection is rejected (e.g., "X11
connection uses different authentication protocol" or "X11 auth data
does not match fake data").

When this occurs, the TCP connection to the X client is never closed,
and the session is never cleaned up.

I believe that in channels.c, the code in the "else if (ret == -1)" case
in channel_pre_x11_open(), which calls chan_read_failed(c) and
chan_write_failed(c), is insufficient; this puts the input into the
"drain" state, but never actually permits it to close.

The patch below seems to correct the problem.  Note the difference for
protocol version 1 vs. v2.  Someone more familiar with the code than
myself should verify that the patch makes sense, and that there's not a
more elegant fix.

========================================================================
--- channels.c.orig Thu Oct 11 21:35:05 2001
+++ channels.c  Tue Dec  4 16:12:01 2001
@@ -872,7 +872,9 @@
        } else if (ret == -1) {
                debug("X11 rejected %d i%d/o%d", c->self, c->istate, c->ostate);
                chan_read_failed(c);    /** force close? */
-               chan_write_failed(c);
+               chan_ibuf_empty(c);
+               if (compat20)
+                       chan_write_failed(c);
                debug("X11 closed %d i%d/o%d", c->self, c->istate, c->ostate);
        }
 }
========================================================================

Cheers,

-- 
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 josb at cncdsl.com  Wed Dec  5 09:29:51 2001
From: josb at cncdsl.com (Jos Backus)
Date: Tue, 4 Dec 2001 14:28:51 -0801
Subject: PATCH: log key fingerprint upon successful login
Message-ID: <20011204222913.GA1896@lizzy.bugworks.com>

This patch is against 3.0.2p1. It produces output like the first line in the
example below for both v1 and v2 logins. Logging is turned on by sticking
``LogFingerprint yes'' in sshd_conf. It would be nice if something like this
would make it into OpenSSH.

Dec  4 14:21:09 lizzy.bugworks.com sshd[7774]: [ID 800047 auth.info] Found
matching RSA1 key: dd:5f:1b:ed:2f:cd:a5:05:f6:d1:39:6b:d2:66:dc:2e
Dec  4 14:21:09 lizzy.bugworks.com sshd[7774]: [ID 800047 auth.info] Accepted
rsa for josb from 1.2.3.4 port 1889

--- openssh-3.0.2p1.dist/auth-rsa.c	Mon Aug  6 14:01:49 2001
+++ openssh-3.0.2p1/auth-rsa.c	Tue Dec  4 14:14:06 2001
@@ -181,7 +181,7 @@
 	 */
 	while (fgets(line, sizeof(line), f)) {
 		char *cp;
-		char *options;
+		char *optionsp;
 
 		linenum++;
 
@@ -199,7 +199,7 @@
 		 */
 		if (*cp < '0' || *cp > '9') {
 			int quoted = 0;
-			options = cp;
+			optionsp = cp;
 			for (; *cp && (quoted || (*cp != ' ' && *cp != '\t')); cp++) {
 				if (*cp == '\\' && cp[1] == '"')
 					cp++;	/* Skip both */
@@ -207,7 +207,7 @@
 					quoted = !quoted;
 			}
 		} else
-			options = NULL;
+			optionsp = NULL;
 
 		/* Parse the key from the line. */
 		if (!auth_rsa_read_key(&cp, &bits, pk->e, pk->n)) {
@@ -232,7 +232,7 @@
 		 * If our options do not allow this key to be used,
 		 * do not send challenge.
 		 */
-		if (!auth_parse_options(pw, options, file, linenum))
+		if (!auth_parse_options(pw, optionsp, file, linenum))
 			continue;
 
 		/* Perform the challenge-response dialog for this key. */
@@ -251,6 +251,15 @@
 		 * otherwise continue searching.
 		 */
 		authenticated = 1;
+		if (options.log_fingerprint) {
+			Key *auth_key = key_new(KEY_RSA1);
+			auth_key->rsa->n = pk->n;
+			auth_key->rsa->e = pk->e;
+			log("Found matching %s key: %s",
+				key_type(auth_key),
+				key_fingerprint(auth_key, SSH_FP_MD5, SSH_FP_HEX));
+			key_free(auth_key);
+		}
 		break;
 	}
 
diff -ruN openssh-3.0.2p1.dist/auth2.c openssh-3.0.2p1/auth2.c
--- openssh-3.0.2p1.dist/auth2.c	Tue Nov 13 04:46:19 2001
+++ openssh-3.0.2p1/auth2.c	Tue Dec  4 14:12:37 2001
@@ -690,8 +690,13 @@
 	found_key = 0;
 	found = key_new(key->type);
 
+	if (options.log_fingerprint)
+		log("Find matching %s key: %s",
+			key_type(key),
+			key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX));
+
 	while (fgets(line, sizeof(line), f)) {
-		char *cp, *options = NULL;
+		char *cp, *optionsp = NULL;
 		linenum++;
 		/* Skip leading whitespace, empty and comment lines. */
 		for (cp = line; *cp == ' ' || *cp == '\t'; cp++)
@@ -703,7 +708,7 @@
 			/* no key?  check if there are options for this key */
 			int quoted = 0;
 			debug2("user_key_allowed: check options: '%s'", cp);
-			options = cp;
+			optionsp = cp;
 			for (; *cp && (quoted || (*cp != ' ' && *cp != '\t')); cp++) {
 				if (*cp == '\\' && cp[1] == '"')
 					cp++;	/* Skip both */
@@ -720,10 +725,14 @@
 			}
 		}
 		if (key_equal(found, key) &&
-		    auth_parse_options(pw, options, file, linenum) == 1) {
+		    auth_parse_options(pw, optionsp, file, linenum) == 1) {
 			found_key = 1;
 			debug("matching key found: file %s, line %lu",
 			    file, linenum);
+			if (options.log_fingerprint)
+				log("Found matching %s key: %s",
+					key_type(key),
+					key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX));
 			break;
 		}
 	}
--- openssh-3.0.2p1.dist/servconf.c	Tue Nov 13 05:03:15 2001
+++ openssh-3.0.2p1/servconf.c	Tue Dec  4 12:37:39 2001
@@ -109,6 +109,7 @@
 	options->client_alive_count_max = -1;
 	options->authorized_keys_file = NULL;
 	options->authorized_keys_file2 = NULL;
+	options->log_fingerprint = -1;
 }
 
 void
@@ -229,6 +230,8 @@
 	}
 	if (options->authorized_keys_file == NULL)
 		options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS;
+	if (options->log_fingerprint == -1)
+		options->log_fingerprint = 0;
 }
 
 /* Keyword tokens. */
@@ -261,6 +264,7 @@
 	sBanner, sReverseMappingCheck, sHostbasedAuthentication,
 	sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, 
 	sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2,
+	sLogFingerprint,
 	sDeprecated 
 } ServerOpCodes;
 
@@ -334,6 +338,7 @@
 	{ "clientalivecountmax", sClientAliveCountMax },
 	{ "authorizedkeysfile", sAuthorizedKeysFile },
 	{ "authorizedkeysfile2", sAuthorizedKeysFile2 },
+	{ "logfingerprint", sLogFingerprint },
 	{ NULL, 0 }
 };
 
@@ -858,6 +863,10 @@
 		case sClientAliveCountMax:
 			intptr = &options->client_alive_count_max;
 			goto parse_int;
+
+		case sLogFingerprint:
+			intptr = &options->log_fingerprint;
+			goto parse_flag;
 
 		case sDeprecated:
 			log("%s line %d: Deprecated option %s",
diff -ruN openssh-3.0.2p1.dist/servconf.h openssh-3.0.2p1/servconf.h
--- openssh-3.0.2p1.dist/servconf.h	Wed Sep 12 09:40:06 2001
+++ openssh-3.0.2p1/servconf.h	Tue Dec  4 12:37:39 2001
@@ -129,6 +129,7 @@
 	char   *authorized_keys_file;	/* File containing public keys */
 	char   *authorized_keys_file2;
 	int	pam_authentication_via_kbd_int;
+	int	log_fingerprint;
 
 }       ServerOptions;
 

Thanks,
-- 
Jos Backus                 _/  _/_/_/        Santa Clara, CA
                          _/  _/   _/
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb at cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;


From sluggo at unknown.nu  Thu Dec  6 05:54:21 2001
From: sluggo at unknown.nu (Kim Scarborough)
Date: Wed, 5 Dec 2001 12:54:21 -0600 (CST)
Subject: OpenSSH compile problem on Solaris 8 & 9
Message-ID: <Pine.BSF.4.42.0112051248410.39800-100000@jinx.unknown.nu>

Sorry if this is the wrong place to post this... the OpenSSH Mailing Lists
page is a little ambiguous.

I've tried to compile OpenSSH 3.0.1p1 & 3.0.2p1 on two different Solaris
platforms, one running Solaris 8 and the other Solaris 9 beta. It
configures fine, but the make dies:

gcc -I/opt/include -Wall -Wpointer-arith -Wno-uninitialized -I. -I.
-I/opt/include -I/opt/include -I/usr/local/include
-DETCDIR=\"/opt/pkgs/openssh-3.0.1p1/etc\"
-D_PATH_SSH_PROGRAM=\"/opt/pkgs/openssh-3.0.1p1/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/pkgs/openssh-3.0.1p1/libexec/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/opt/pkgs/openssh-3.0.1p1/libexec/sftp-server\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c cipher.c
cipher.c: In function `des_ssh1_setkey':
cipher.c:71: incompatible type for argument 2 of `des_set_key'
cipher.c: In function `des_ssh1_encrypt':
cipher.c:82: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c: In function `des_ssh1_decrypt':
cipher.c:88: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c: In function `des3_setkey':
cipher.c:95: incompatible type for argument 2 of `des_set_key'
cipher.c:96: incompatible type for argument 2 of `des_set_key'
cipher.c:97: incompatible type for argument 2 of `des_set_key'
cipher.c: In function `des3_cbc_encrypt':
cipher.c:114: incompatible type for argument 4 of `des_ede3_cbc_encrypt'
cipher.c:114: incompatible type for argument 5 of `des_ede3_cbc_encrypt'
cipher.c:114: incompatible type for argument 6 of `des_ede3_cbc_encrypt'
cipher.c: In function `des3_cbc_decrypt':
cipher.c:121: incompatible type for argument 4 of `des_ede3_cbc_encrypt'
cipher.c:121: incompatible type for argument 5 of `des_ede3_cbc_encrypt'
cipher.c:121: incompatible type for argument 6 of `des_ede3_cbc_encrypt'
cipher.c: In function `des3_ssh1_setkey':
cipher.c:141: incompatible type for argument 2 of `des_set_key'
cipher.c:142: incompatible type for argument 2 of `des_set_key'
cipher.c:144: incompatible type for argument 2 of `des_set_key'
cipher.c:146: incompatible type for argument 2 of `des_set_key'
cipher.c: In function `des3_ssh1_encrypt':
cipher.c:153: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c:155: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c:157: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c: In function `des3_ssh1_decrypt':
cipher.c:164: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c:166: incompatible type for argument 4 of `des_ncbc_encrypt'
cipher.c:168: incompatible type for argument 4 of `des_ncbc_encrypt'
make: *** [cipher.o] Error 1

(This is from the 3.0.1p1, but the same thing happens on the latest
version.)

Anything I'm missing? I'm running 64-bit gcc 3.0.1. OpenSSH 2.9 and below
compile fine. Let me know if there's more information I should include, or
if there's a more appropriate mailing list.

-------------------------------------------------------------------------------
Kim Scarborough                                      http://www.unknown.nu/kim/
-------------------------------------------------------------------------------
"Football combines the two worst features of American life: violence and
committee meetings."
                                                                   -George Will
-------------------------------------------------------------------------------



From stevesk at pobox.com  Thu Dec  6 08:16:25 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Wed, 5 Dec 2001 13:16:25 -0800 (PST)
Subject: DISPLAY=localhost
Message-ID: <Pine.HPX.4.42.0112051302190.1534-100000@jenny>

hi,

this can be applied to the latest portable CVS.  by default bind sshd fake
display to localhost.

[stevesk at jenny stevesk]$ uname -sr
HP-UX B.11.11
[stevesk at jenny stevesk]$ echo $DISPLAY
localhost:14.0
[stevesk at jenny stevesk]$ netstat -an|grep 6014
tcp        0      0  127.0.0.1.6014         *.*                     LISTEN

this is currently controlled with sshd_config gatewayports;
gatewayports=yes will revert to old behavior (hostname or IP address
depending on platform).  on hp-ux 11.11 this works with X11 clients using
the R6 libs.  i'd be interested in hearing about results of trying this.
much of it is already commited to the openbsd CVS tree.

Index: includes.h
===================================================================
RCS file: /var/cvs/openssh/includes.h,v
retrieving revision 1.51
diff -u -r1.51 includes.h
--- includes.h	2001/09/20 02:07:51	1.51
+++ includes.h	2001/12/05 20:52:02
@@ -28,6 +28,7 @@
 #include <sys/ioctl.h>
 #include <sys/wait.h>
 #include <sys/resource.h>
+#include <sys/utsname.h>

 #include <netinet/tcp.h>
 #include <arpa/inet.h>
Index: channels.h
===================================================================
RCS file: /var/cvs/openssh/channels.h,v
retrieving revision 1.43
diff -u -r1.43 channels.h
--- channels.h	2001/11/12 00:04:55	1.43
+++ channels.h	2001/12/05 20:52:05
@@ -197,8 +197,7 @@
 /* x11 forwarding */

 int	 x11_connect_display(void);
-char	*x11_create_display(int);
-char	*x11_create_display_inet(int, int);
+int	 x11_create_display_inet(int, int);
 void     x11_input_open(int, int, void *);
 void     x11_request_forwarding(void);
 void	 x11_request_forwarding_with_spoofing(int, const char *, const char *);
Index: channels.c
===================================================================
RCS file: /var/cvs/openssh/channels.c,v
retrieving revision 1.111
diff -u -r1.111 channels.c
--- channels.c	2001/10/12 01:35:05	1.111
+++ channels.c	2001/12/05 20:52:24
@@ -2396,19 +2396,17 @@

 /*
  * Creates an internet domain socket for listening for X11 connections.
- * Returns a suitable value for the DISPLAY variable, or NULL if an error
- * occurs.
+ * Returns a suitable display number for the DISPLAY variable, or -1 if
+ * an error occurs.
  */
-char *
-x11_create_display_inet(int screen_number, int x11_display_offset)
+int
+x11_create_display_inet(int x11_display_offset, int gateway_ports)
 {
 	int display_number, sock;
 	u_short port;
 	struct addrinfo hints, *ai, *aitop;
 	char strport[NI_MAXSERV];
 	int gaierr, n, num_socks = 0, socks[NUM_SOCKS];
-	char display[512];
-	char hostname[MAXHOSTNAMELEN];

 	for (display_number = x11_display_offset;
 	     display_number < MAX_DISPLAYS;
@@ -2416,12 +2414,12 @@
 		port = 6000 + display_number;
 		memset(&hints, 0, sizeof(hints));
 		hints.ai_family = IPv4or6;
-		hints.ai_flags = AI_PASSIVE;		/* XXX loopback only ? */
+		hints.ai_flags = gateway_ports ? AI_PASSIVE : 0;
 		hints.ai_socktype = SOCK_STREAM;
 		snprintf(strport, sizeof strport, "%d", port);
 		if ((gaierr = getaddrinfo(NULL, strport, &hints, &aitop)) != 0) {
 			error("getaddrinfo: %.100s", gai_strerror(gaierr));
-			return NULL;
+			return -1;
 		}
 		for (ai = aitop; ai; ai = ai->ai_next) {
 			if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6)
@@ -2430,7 +2428,7 @@
 			if (sock < 0) {
 				if ((errno != EINVAL) && (errno != EAFNOSUPPORT)) {
 					error("socket: %.100s", strerror(errno));
-					return NULL;
+					return -1;
 				} else {
 					debug("x11_create_display_inet: Socket family %d not supported",
 						 ai->ai_family);
@@ -2466,7 +2464,7 @@
 	}
 	if (display_number >= MAX_DISPLAYS) {
 		error("Failed to allocate internet-domain X11 display socket.");
-		return NULL;
+		return -1;
 	}
 	/* Start listening for connections on the socket. */
 	for (n = 0; n < num_socks; n++) {
@@ -2475,53 +2473,10 @@
 			error("listen: %.100s", strerror(errno));
 			shutdown(sock, SHUT_RDWR);
 			close(sock);
-			return NULL;
+			return -1;
 		}
 	}

-	/* Set up a suitable value for the DISPLAY variable. */
-	if (gethostname(hostname, sizeof(hostname)) < 0)
-		fatal("gethostname: %.100s", strerror(errno));
-
-#ifdef IPADDR_IN_DISPLAY
-	/*
-	 * HPUX detects the local hostname in the DISPLAY variable and tries
-	 * to set up a shared memory connection to the server, which it
-	 * incorrectly supposes to be local.
-	 *
-	 * The workaround - as used in later $$H and other programs - is
-	 * is to set display to the host's IP address.
-	 */
-	{
-		struct hostent *he;
-		struct in_addr my_addr;
-
-		he = gethostbyname(hostname);
-		if (he == NULL) {
-			error("[X11-broken-fwd-hostname-workaround] Could not get "
-				"IP address for hostname %s.", hostname);
-
-			packet_send_debug("[X11-broken-fwd-hostname-workaround]"
-				"Could not get IP address for hostname %s.", hostname);
-
-			shutdown(sock, SHUT_RDWR);
-			close(sock);
-
-			return NULL;
-		}
-
-		memcpy(&my_addr, he->h_addr_list[0], sizeof(struct in_addr));
-
-		/* Set DISPLAY to <ip address>:screen.display */
-		snprintf(display, sizeof(display), "%.50s:%d.%d", inet_ntoa(my_addr),
-			 display_number, screen_number);
-	}
-#else /* IPADDR_IN_DISPLAY */
-	/* Just set DISPLAY to hostname:screen.display */
-	snprintf(display, sizeof display, "%.400s:%d.%d", hostname,
-		 display_number, screen_number);
-#endif /* IPADDR_IN_DISPLAY */
-
 	/* Allocate a channel for each socket. */
 	for (n = 0; n < num_socks; n++) {
 		sock = socks[n];
@@ -2531,8 +2486,8 @@
 		    0, xstrdup("X11 inet listener"), 1);
 	}

-	/* Return a suitable value for the DISPLAY environment variable. */
-	return xstrdup(display);
+	/* Return the display number for the DISPLAY environment variable. */
+	return display_number;
 }

 #ifndef X_UNIX_PATH
Index: session.c
===================================================================
RCS file: /var/cvs/openssh/session.c,v
retrieving revision 1.156
diff -u -r1.156 session.c
--- session.c	2001/11/13 12:46:19	1.156
+++ session.c	2001/12/05 20:52:38
@@ -108,8 +108,10 @@
 	int	row, col, xpixel, ypixel;
 	char	tty[TTYSZ];
 	/* X11 */
+	int	display_number;
 	char	*display;
 	int	screen;
+	char	*auth_display[2];
 	char	*auth_proto;
 	char	*auth_data;
 	int	single_connection;
@@ -1415,32 +1417,28 @@
 				    _PATH_SSH_SYSTEM_RC);
 		} else if (do_xauth && options.xauth_location != NULL) {
 			/* Add authority data to .Xauthority if appropriate. */
-			char *screen = strchr(s->display, ':');
-
 			if (debug_flag) {
 				fprintf(stderr,
 				    "Running %.100s add "
 				    "%.100s %.100s %.100s\n",
-				    options.xauth_location, s->display,
+				    options.xauth_location, s->auth_display[0],
 				    s->auth_proto, s->auth_data);
-				if (screen != NULL)
+				if (s->auth_display[1])
 					fprintf(stderr,
-					    "Adding %.*s/unix%s %s %s\n",
-					    (int)(screen - s->display),
-					    s->display, screen,
+					    "add %.100s %.100s %.100s\n",
+					    s->auth_display[1],
 					    s->auth_proto, s->auth_data);
 			}
 			snprintf(cmd, sizeof cmd, "%s -q -",
 			    options.xauth_location);
 			f = popen(cmd, "w");
 			if (f) {
-				fprintf(f, "add %s %s %s\n", s->display,
-				    s->auth_proto, s->auth_data);
-				if (screen != NULL)
-					fprintf(f, "add %.*s/unix%s %s %s\n",
-					    (int)(screen - s->display),
-					    s->display, screen,
-					    s->auth_proto,
+				fprintf(f, "add %s %s %s\n",
+				    s->auth_display[0], s->auth_proto,
+				    s->auth_data);
+				if (s->auth_display[1])
+					fprintf(f, "add %s %s %s\n",
+					    s->auth_display[1], s->auth_proto,
 					    s->auth_data);
 				pclose(f);
 			} else {
@@ -1941,6 +1939,10 @@
 		xfree(s->term);
 	if (s->display)
 		xfree(s->display);
+	if (s->auth_display[0])
+		xfree(s->auth_display[0]);
+	if (s->auth_display[1])
+		xfree(s->auth_display[1]);
 	if (s->auth_data)
 		xfree(s->auth_data);
 	if (s->auth_proto)
@@ -2036,6 +2038,8 @@
 session_setup_x11fwd(Session *s)
 {
 	struct stat st;
+	char display[512], auth_display[512];
+	char hostname[MAXHOSTNAMELEN];

 	if (no_x11_forwarding_flag) {
 		packet_send_debug("X11 forwarding disabled in user configuration file.");
@@ -2059,11 +2063,68 @@
 		debug("X11 display already set.");
 		return 0;
 	}
-	s->display = x11_create_display_inet(s->screen, options.x11_display_offset);
-	if (s->display == NULL) {
+	s->display_number = x11_create_display_inet(options.x11_display_offset,
+	    options.gateway_ports);
+	if (s->display_number == -1) {
 		debug("x11_create_display_inet failed.");
 		return 0;
 	}
+
+	/* Set up a suitable value for the DISPLAY variable. */
+	if (gethostname(hostname, sizeof(hostname)) < 0)
+		fatal("gethostname: %.100s", strerror(errno));
+	/*
+	 * auth_display must be used as the displayname when the
+	 * authorization entry is added with xauth(1).  This will be
+	 * different than the DISPLAY string for localhost displays.
+	 */
+	s->auth_display[1] = NULL;
+	if (!options.gateway_ports) {
+		struct utsname uts;
+
+		snprintf(display, sizeof display, "localhost:%d.%d",
+		    s->display_number, s->screen);
+		snprintf(auth_display, sizeof auth_display, "%.400s/unix:%d.%d",
+		    hostname, s->display_number, s->screen);
+		s->display = xstrdup(display);
+		s->auth_display[0] = xstrdup(auth_display);
+		/*
+		 * Xlib may use gethostbyname() or uname() hostname to
+		 * look up authorization data for FamilyLocal; see:
+		 * xc/lib/xtrans/Xtrans.c:TRANS(GetHostname)
+		 * We just add authorization entries with both
+		 * hostname and nodename if they are different.
+		 */
+		if (uname(&uts) == -1)
+			fatal("uname: %.100s", strerror(errno));
+		if (strcmp(hostname, uts.nodename) != 0) {
+			snprintf(auth_display, sizeof auth_display,
+			    "%.400s/unix:%d.%d", uts.nodename,
+			    s->display_number, s->screen);
+			s->auth_display[1] = xstrdup(auth_display);
+		}
+	} else {
+#ifdef IPADDR_IN_DISPLAY
+		struct hostent *he;
+		struct in_addr my_addr;
+
+		he = gethostbyname(hostname);
+		if (he == NULL) {
+			error("Can't get IP address for X11 DISPLAY.");
+			packet_send_debug("Can't get IP address for X11 DISPLAY.");
+			return 0;
+		}
+		memcpy(&my_addr, he->h_addr_list[0], sizeof(struct in_addr));
+		snprintf(display, sizeof display, "%.50s:%d.%d", inet_ntoa(my_addr),
+		    s->display_number, s->screen);
+#else
+		snprintf(display, sizeof display, "%.400s:%d.%d", hostname,
+		    s->display_number, s->screen);
+#endif
+		s->display = xstrdup(display);
+		s->auth_display[0] = xstrdup(display);
+	}
+
 	return 1;
 }




From rouilj at cs.umb.edu  Thu Dec  6 08:37:02 2001
From: rouilj at cs.umb.edu (John P. Rouillard)
Date: Wed, 05 Dec 2001 16:37:02 -0500
Subject: permitopen for -R connections?
Message-ID: <200112052137.QAA20103@cs.umb.edu>


It looks like there is good support for limiting connections on the
server side when the client uses the -L flag. What about support for
server side connections (listens) when the client uses the -R flag?

I am looking for an equivalent to permitopen that says what ports are
valid for the remote host when using the -R flag. As it sits now, an
unscrupulous ssh user can bind to any port above 1024 (on a unix box)
or bind to any port on a windows box.

Does anybody have any ideas? I am working from the 3.0.2p1 release of
the code. It seems like channels.c is the proper place to put this
code if I can develop it. Is there any roadmap to how the code in
connect.c is used or is this a case of UTSL? I just took a cursory
glance through the code and I fail to see any functions in channels.c
that are intended for setting up the reverse forwarded connections.

I assume I will have to add a new check function in:

 serverloop.c:server_input_global_request

at:

 /* check permissions */
                if (!options.allow_tcp_forwarding ||
                    no_port_forwarding_flag ||
                    (listen_port < IPPORT_RESERVED && pw->pw_uid != 0)) {
                        success = 0;
                        packet_send_debug("Server has disabled port forwarding."

I assumed I could implement a parallel mechanism to the -L port
checking, but I am having trouble figuring out how restriction of the
-L ports is implemented.

Any assistance welcome.

				-- rouilj
John Rouillard
===============================================================================
My employers don't acknowledge my existence much less my opinions.


From shade at chemlab.org  Thu Dec  6 08:44:06 2001
From: shade at chemlab.org (steve j. kondik)
Date: 05 Dec 2001 16:44:06 -0500
Subject: gssapi + seam on solaris
Message-ID: <1007588651.436.4.camel@tesseract>

i've compiled openssh with the gssapi patches on a solaris 8 system
using sun's SEAM.  gssapi isn't initializing properly it seems.

debug2: input_userauth_request: try method gssapi
debug1: Mechanism negotiation is not supported
Failed gssapi for xxxx from xxxx port 33555 ssh2

sun's kerberized tools are working fine.

any help would be appreciated.

-- 
http://chemlab.org  -  email shade-pgpkey at chemlab.org for pgp public key
  chemlab radio!    -  drop out @ http://mp3.chemlab.org:8000   24-7-365

"i could build anything if i could just find my tools.."	



From markus at openbsd.org  Thu Dec  6 09:03:17 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 5 Dec 2001 23:03:17 +0100
Subject: permitopen for -R connections?
In-Reply-To: <200112052137.QAA20103@cs.umb.edu>
References: <200112052137.QAA20103@cs.umb.edu>
Message-ID: <20011205230316.A8427@faui02>

> I assume I will have to add a new check function in:
> 
>  serverloop.c:server_input_global_request

yes, for ssh2.

for ssh v1 it's SSH_CMSG_PORT_FORWARD_REQUEST
for ssh v2 SSH2_MSG_GLOBAL_REQUEST with "tcpip-forward"

-m


From dbutts at maddog.storability.com  Thu Dec  6 09:04:09 2001
From: dbutts at maddog.storability.com (David Butts)
Date: Wed, 5 Dec 2001 17:04:09 -0500
Subject: OpenSSH compile problem on Solaris 8 & 9
In-Reply-To: <Pine.BSF.4.42.0112051248410.39800-100000@jinx.unknown.nu>
References: <Pine.BSF.4.42.0112051248410.39800-100000@jinx.unknown.nu>
Message-ID: <20011205170409.A6043@storability.com>

Hello-

On Wed, Dec 05, 2001 at 12:54:21PM -0600, Kim Scarborough wrote:
> Sorry if this is the wrong place to post this... the OpenSSH Mailing Lists
> page is a little ambiguous.
> 
> I've tried to compile OpenSSH 3.0.1p1 & 3.0.2p1 on two different Solaris
> platforms, one running Solaris 8 and the other Solaris 9 beta. It
> configures fine, but the make dies:

> Anything I'm missing? I'm running 64-bit gcc 3.0.1. OpenSSH 2.9 and below
> compile fine. Let me know if there's more information I should include, or
> if there's a more appropriate mailing list.

I would try it with a different compiler.  The GCC folks have explicitly
revoked 64-bit ultrasparc support in 3.0.x

http://gcc.gnu.org/gcc-3.0/buildstat.html

Also, FWIW, last time I checked, the bignum routines in openssl (which
are written in assembly) only use sparcv8+, since a fair number of 64
bit registers are available even if the kernel only guarantees 32 bits.
Which is all a long-winded way of saying that a 32-bit version of gcc
creating sparcv8plus binaries should give you all the 64-bit goodness
that sparcv9 would in the crypto functions.

The comments in crypto/bn/asm/sparcv8plus.S in the openssl distribution
give more details about it.

David



From dnewman at maraudingpirates.org  Thu Dec  6 13:07:51 2001
From: dnewman at maraudingpirates.org (David F. Newman)
Date: Wed, 5 Dec 2001 21:07:51 -0500 (EST)
Subject: OpenSSH compile problem on Solaris 8 & 9
In-Reply-To: <Pine.BSF.4.42.0112051248410.39800-100000@jinx.unknown.nu>
Message-ID: <Pine.GSO.4.33.0112052104580.1516-100000@cortez.maraudingpirates.org>

On Wed, 5 Dec 2001, Kim Scarborough wrote:

> I've tried to compile OpenSSH 3.0.1p1 & 3.0.2p1 on two different Solaris
> platforms, one running Solaris 8 and the other Solaris 9 beta. It
> configures fine, but the make dies:

[snip]

> Anything I'm missing? I'm running 64-bit gcc 3.0.1. OpenSSH 2.9 and below
> compile fine. Let me know if there's more information I should include, or
> if there's a more appropriate mailing list.
>

Works fine with 2.95.2 on Solaris 8.  Besides, isn't 64-bit gcc still
experimental on solaris?

-Dave




From kent at unit.liu.se  Fri Dec  7 22:22:31 2001
From: kent at unit.liu.se (Kent =?iso-8859-1?q?Engstr=F6m?=)
Date: 07 Dec 2001 12:22:31 +0100
Subject: CVS server not responding
In-Reply-To: kent@unit.liu.se's message of "30 Nov 2001 12:56:29 +0100"
Message-ID: <m33d2nb7go.fsf_-_@ceres.unit.liu.se>

Hi,

the anonymous CVS server for portable OpenSSH does not want to talk to
me:

> % cvs upd -Pd
> cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused

Looking at http://www.openssh.com/portable.html, 
":pserver:cvs at bass.directhit.com:/cvs" is still the recommended
repository.

Is this a known problem?

-- 
Kent Engstr?m,		Link?ping University Incident Response Team
kent at unit.liu.se  	abuse at liu.se
+46 13 28 1744

UNIT, Link?ping University; SE-581 83  LINK?PING; SWEDEN


From mbabcock at fibrespeed.net  Sat Dec  8 02:08:34 2001
From: mbabcock at fibrespeed.net (Michael T. Babcock)
Date: Fri, 7 Dec 2001 10:08:34 -0500
Subject: Authentication 'failure' success
Message-ID: <20011207100834.Y14152@godzilla.fibrespeed.net>

We are using OpenSSH (portable) version 3.0.1p1 on Linux 2.2.14-10 with 
RedHat's distribution of PAM 0.72-20.6.x for rsync'ing RRDTool data 
between two machines (among other things).  When running 'rsync -essh 
-avz', everything works fine but the system log on the sshd side shows:

PAM_pwdb[8021]: authentication failure; (uid=0) -> rrd for sshd service 
sshd[8021]: Accepted publickey for rrd from 216.168.105.35 port 3908 ssh2 
PAM_pwdb[8021]: (sshd) session opened for user rrd by (uid=0) 
PAM_pwdb[8021]: (sshd) session closed for user rrd 

Lines 2, 3 and 4 seem fine, but what's with the first line claiming 
there was an authentication failure?  Any other information necessary 
can be easily providedm, but I'm not subscribed to this list so CC: me
on replies.
-- 
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/


From dan at doxpara.com  Sat Dec  8 02:37:55 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 7 Dec 2001 07:37:55 -0800
Subject: Authentication 'failure' success
References: <20011207100834.Y14152@godzilla.fibrespeed.net>
Message-ID: <007501c17f35$24217050$1701000a@effugas>

Mike--

Looking on the other side, we see:

debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/Dan/.ssh/identity
debug1: try privkey: /home/Dan/.ssh/id_rsa
debug1: try privkey: /home/Dan/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password

So perhaps its failing with the first key, and succeeding with the next one.

Speaking of rsync, check out unison.  It appears to be a userspace
bidirectional rsync, done quite elegantly.  Supports ssh as a transport.

http://www.cis.upenn.edu/~bcpierce/unison/

--Dan
www.doxpara.com




From michael at bizsystems.com  Sat Dec  8 09:18:10 2001
From: michael at bizsystems.com (Michael)
Date: Fri, 7 Dec 2001 14:18:10 -0800
Subject: hang on exit bug under Linux 
In-Reply-To: <20011114003143.19330.qmail@wizard.math.ualberta.ca>
Message-ID: <200112072218.OAA15873@ns2.bizsystems.net>

> The hang-on-exit bug still hasn't been fixed in OpenSSH-3.0p1... :-(
> 

Has this issue been resolved in 3.02 ??

Michael
Michael at bizsystems.com


From meyman at txc.com  Sat Dec  8 09:35:11 2001
From: meyman at txc.com (Mark Eyman)
Date: Fri, 07 Dec 2001 17:35:11 -0500
Subject: -c none option
Message-ID: <3C11441F.545BF47A@txc.com>

We are using openssh with backup software to transport data back and
force between clients and backup server. Common sense and some testing
suggest that the data transfer rate is significantly slower when the ssh
native encryption is used. For the backup applications it's probably OK
to use ssh without encryption. Unfortunately, it looks like the recent
versions including 3.0.2p1 do not support the "-c none" option. Is there
a patch or at least plans to fix this?

Also, assuming -c none works, how the password authentication suppose to
be implemented? Encrypted or unencrypted?

Thanks
Mark





From dan at doxpara.com  Sat Dec  8 10:05:21 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 7 Dec 2001 15:05:21 -0800
Subject: -c none option
References: <3C11441F.545BF47A@txc.com>
Message-ID: <00a301c17f73$a5c014c0$1701000a@effugas>

Mark--

    The SSH2 protocol separated authentication and message integrity from
encryption.  As such,  OpenSSH *should* be supporting None as an encryption
type while enforcing authenticated packets w/ hmac-md5 or something similar.
It isn't.

    Null Encryption mode was likely ruled out from the days of SSH1, where
going without encryption meant the authentication verified at the beginning
of a session did not necessarily carry over to future packets.  Essentially,
an attacker could just sit around waiting for an authentication to occur,
and then hijack the connection.  Without encryption in place, there'd be
nothing to stop it.

    That's changed now, of course, but the block on null crypto stands.
That might change, but in the meantime I suggest using "-c arcfour" for
maximum performance.  RC4 is a ludicrously simple and fasst algorithm to
compute against, so hopefully you'll start approaching the speeds you're
used to.

    I've actually been getting steadily more concerned with SSH's
performance.  FTP runs at about 3MB/s, standard SCP at 1MB/s, and SFTP at
100KB/s(!!!).  Now, I emphasize that this is just in my personal
environment, but still, something ain't right.

    What backup software are you using, if I may ask?

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com




From dan at doxpara.com  Sat Dec  8 10:19:02 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 7 Dec 2001 15:19:02 -0800
Subject: hang on exit bug under Linux 
References: <200112072218.OAA15873@ns2.bizsystems.net>
Message-ID: <00b601c17f75$8f1936a0$1701000a@effugas>


> > The hang-on-exit bug still hasn't been fixed in OpenSSH-3.0p1... :-(
> >
>
> Has this issue been resolved in 3.02 ??

Hit enter, tilde, and period.

~.

It's an escape sequence for force killing an SSH client.  There are more;
use ~? instead.

--Dan





From nalin at redhat.com  Sat Dec  8 10:21:22 2001
From: nalin at redhat.com (Nalin Dahyabhai)
Date: Fri, 7 Dec 2001 18:21:22 -0500
Subject: Authentication 'failure' success
In-Reply-To: <20011207100834.Y14152@godzilla.fibrespeed.net>; from mbabcock@fibrespeed.net on Fri, Dec 07, 2001 at 10:08:34AM -0500
References: <20011207100834.Y14152@godzilla.fibrespeed.net>
Message-ID: <20011207182122.A20517@redhat.com>

On Fri, Dec 07, 2001 at 10:08:34AM -0500, Michael T. Babcock wrote:
> We are using OpenSSH (portable) version 3.0.1p1 on Linux 2.2.14-10 with 
> RedHat's distribution of PAM 0.72-20.6.x for rsync'ing RRDTool data 
> between two machines (among other things).  When running 'rsync -essh 
> -avz', everything works fine but the system log on the sshd side shows:
> 
> PAM_pwdb[8021]: authentication failure; (uid=0) -> rrd for sshd service 
> sshd[8021]: Accepted publickey for rrd from 216.168.105.35 port 3908 ssh2 
> PAM_pwdb[8021]: (sshd) session opened for user rrd by (uid=0) 
> PAM_pwdb[8021]: (sshd) session closed for user rrd 
> 
> Lines 2, 3 and 4 seem fine, but what's with the first line claiming 
> there was an authentication failure?  Any other information necessary 
> can be easily providedm, but I'm not subscribed to this list so CC: me
> on replies.

This looks like the usual "no password" authentication test.  If it is,
then it's perfectly normal.

Cheers,

Nalin


From jason at shalott.net  Sat Dec  8 10:40:27 2001
From: jason at shalott.net (Jason Stone)
Date: Fri, 7 Dec 2001 15:40:27 -0800 (PST)
Subject: -c none option
In-Reply-To: <00a301c17f73$a5c014c0$1701000a@effugas>
Message-ID: <20011207152927.K47337-100000@walter>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>     The SSH2 protocol separated authentication and message integrity
> from encryption.  As such, OpenSSH *should* be supporting None as an
> encryption type while enforcing authenticated packets w/ hmac-md5 or
> something similar. It isn't.

Also, many governments regulate the use of "cryptographic" algorithms, but
not "authentication" algorithms.  In particular, for many years you could
not export 56-bit DES implementations from the US, but you could export
any MD5 or SHA1 implementation.

Supporting cipher=none with MAC'd packets might make it legal to use ssh
in some countries where it couldn't otherwise be used, and while it would
not prevent sniffing attacks, it _would_ prevent session hijacking, which
is better than nothing.


 -Jason

 -----------------------------------------------------------------------
 I worry about my child and the Internet all the time, even though she's
 too young to have logged on yet.  Here's what I worry about.  I worry
 that 10 or 15 years from now, she will come to me and say "Daddy, where
 were you when they took freedom of the press away from the Internet?"
	-- Mike Godwin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE8EVNuswXMWWtptckRAtsEAKDg7TeB/T3LsIIuS2i0CVA25707CwCdH/fb
CzQBAdZ83XqOTEkDKrqv9HU=
=Qexd
-----END PGP SIGNATURE-----




From michael at bizsystems.com  Sat Dec  8 15:20:55 2001
From: michael at bizsystems.com (Michael)
Date: Fri, 7 Dec 2001 20:20:55 -0800
Subject: hang on exit bug under Linux 
In-Reply-To: <00b601c17f75$8f1936a0$1701000a@effugas>
Message-ID: <200112080420.UAA17468@ns2.bizsystems.net>

> 
> > > The hang-on-exit bug still hasn't been fixed in OpenSSH-3.0p1... :-(
> > >
> >
> > Has this issue been resolved in 3.02 ??
> 
> Hit enter, tilde, and period.
> 
> ~.
> 
> It's an escape sequence for force killing an SSH client.  There are
> more; use ~? instead.
> 

so what about connections that are made from a script??

Michael
Michael at bizsystems.com


From lstein at cshl.org  Sat Dec  8 16:03:45 2001
From: lstein at cshl.org (Lincoln Stein)
Date: Sat, 8 Dec 2001 00:03:45 -0500
Subject: Patch to allow gatewaying of remote forwarded ports
In-Reply-To: <20011208045536.D6C572DF3C@shitei.mindrot.org>
References: <20011208045536.D6C572DF3C@shitei.mindrot.org>
Message-ID: <01120800034501.08991@fontina>

Hi,

Enclosed is a patch against the "portable" OpenSSH version 3.02p1.  It 
enables the -g switch when applied to -R (remote) forwardings.  This allows 
remote hosts to connect to forwarded ports on the sshd host.

To be consistent with the behavior of the SSH1 clients and servers, the 
GatewayPorts option will activate both remote and local port gatewaying when 
set to "yes".

Best regards,

Lincoln

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY

NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. 
PLEASE WRITE FOR DETAILS.
========================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remote_forward_patch
Type: text/x-c
Size: 4209 bytes
Desc: lets the -g flag work on -R forwardings
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011208/76f99dde/attachment.bin 

From Jewnix at technohac.com  Sat Dec  8 23:08:00 2001
From: Jewnix at technohac.com (Gil Disatnik)
Date: Sat, 08 Dec 2001 14:08:00 +0200
Subject: Name Resolving bug in Open SSH 3.0.2
Message-ID: <5.1.0.14.2.20011208140020.00aa2540@pop3.norton.antivirus>

Hello there,
In OpenSSH 3.0.2p1 there is a strange name resolving bug:

/etc/nsswitch.conf shows:

hosts:          files dns

When I am trying to connect to a host that is in /etc/hosts using the 
hostname, ssh tries to first resolve this name using the dns, regardless to 
the resolve order in /etc/nsswitch.conf, if the dns is timeout or the 
machine is not connected to the Internet at this time - this causes a delay 
of 10 seconds before connecting to a neighbor machine... that's bad.
REMOVING dns from /etc/nsswitch.conf solves this problem, however... 
/etc/nsswitch is there to tell which mechanism to go to first...

What do you say?


Regards

Gil Disatnik
UNIX system/security administrator at netish inc.
www.netish.com

GibsonLP at EFnet
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
"Windows NT has detected mouse movement, you MUST restart
your computer before the new settings will take effect, [ OK ]"
--------------------------------------------------------------------
Windows is a 32 bit patch to a 16 bit GUI based on a 8 bit operating
system, written for a 4 bit processor by a 2 bit company which can
not stand 1 bit of competition.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-



From vinschen at redhat.com  Sat Dec  8 23:23:06 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sat, 8 Dec 2001 13:23:06 +0100
Subject: -c none option
In-Reply-To: <20011207152927.K47337-100000@walter>; from jason@shalott.net on Fri, Dec 07, 2001 at 03:40:27PM -0800
References: <00a301c17f73$a5c014c0$1701000a@effugas> <20011207152927.K47337-100000@walter>
Message-ID: <20011208132306.Z740@cygbert.vinschen.de>

On Fri, Dec 07, 2001 at 03:40:27PM -0800, Jason Stone wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >     The SSH2 protocol separated authentication and message integrity
> > from encryption.  As such, OpenSSH *should* be supporting None as an
> > encryption type while enforcing authenticated packets w/ hmac-md5 or
> > something similar. It isn't.
> 
> Also, many governments regulate the use of "cryptographic" algorithms, but
> not "authentication" algorithms.  In particular, for many years you could
> not export 56-bit DES implementations from the US, but you could export
> any MD5 or SHA1 implementation.
> 
> Supporting cipher=none with MAC'd packets might make it legal to use ssh
> in some countries where it couldn't otherwise be used, and while it would

Just because an encryption implementation couldn't be exported from
the US, it doesn't mean they weren't available.  That would mean
that there were no developers outside of the US ;-)

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From Jewnix at technohac.com  Sat Dec  8 23:15:46 2001
From: Jewnix at technohac.com (Gil Disatnik)
Date: Sat, 08 Dec 2001 14:15:46 +0200
Subject: Name Resolving bug in Open SSH 3.0.2 (Addendum)
Message-ID: <5.1.0.14.2.20011208141115.00aace70@pop3.norton.antivirus>

Almost forgot...
I already reported this but a few months ago when I was using openSSH 2.9x, 
it's the same bug.

And no - it's not the server end that is stalling me on a revese lookup:
1. I was doing ssh localhost, localhost resolves perfectly, the same for 
127.0.0.1 (reverse)
2. ssh -v shows me:

debug1: Reading configuration data /usr/local/etc/ssh_config
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

And here it is getting stalled, there is no actual connection yet, hence it 
could not be the end server that stalls me.


Regards

Gil Disatnik
UNIX system/security administrator at netish inc.
www.netish.com

GibsonLP at EFnet
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
"Windows NT has detected mouse movement, you MUST restart
your computer before the new settings will take effect, [ OK ]"
--------------------------------------------------------------------
Windows is a 32 bit patch to a 16 bit GUI based on a 8 bit operating
system, written for a 4 bit processor by a 2 bit company which can
not stand 1 bit of competition.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011208/3b88ca3d/attachment.html 

From pekkas at netcore.fi  Sat Dec  8 23:27:22 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Sat, 8 Dec 2001 14:27:22 +0200 (EET)
Subject: Name Resolving bug in Open SSH 3.0.2
In-Reply-To: <5.1.0.14.2.20011208140020.00aa2540@pop3.norton.antivirus>
Message-ID: <Pine.LNX.4.33.0112081424020.3942-100000@netcore.fi>

On Sat, 8 Dec 2001, Gil Disatnik wrote:
> Hello there,
> In OpenSSH 3.0.2p1 there is a strange name resolving bug:
> 
> /etc/nsswitch.conf shows:
> 
> hosts:          files dns
> 
> When I am trying to connect to a host that is in /etc/hosts using the 
> hostname, ssh tries to first resolve this name using the dns, regardless to 
> the resolve order in /etc/nsswitch.conf, if the dns is timeout or the 
> machine is not connected to the Internet at this time - this causes a delay 
> of 10 seconds before connecting to a neighbor machine... that's bad.
> REMOVING dns from /etc/nsswitch.conf solves this problem, however... 
> /etc/nsswitch is there to tell which mechanism to go to first...

I believe you're using Linux.

If so, this is an issue in glibc:

http://sources.redhat.com/ml/libc-alpha/2001-11/msg00125.html

(this was brought up a year ago too).

The problem is that getaddrinfo tries to look up AAAA record for the entry 
in /etc/hosts via DNS first unless there is an IPv6 address for the name 
in /etc/hosts too.

You can work around this in OpenSSH by compiling --with-ipv4-default.

-- 
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 gem at rellim.com  Sun Dec  9 12:15:26 2001
From: gem at rellim.com (Gary E. Miller)
Date: Sat, 8 Dec 2001 17:15:26 -0800 (PST)
Subject: -c none option
In-Reply-To: <20011208132306.Z740@cygbert.vinschen.de>
Message-ID: <Pine.LNX.4.41.0112081712590.16550-100000@catbert.rellim.com>

Yo Corinna!

Having something available is not good enough.  Crypto use in many
countries could mean jail.  I know people that have been outside the
US using crypto and told by the local government to cease and desist
or be arrested.

Until we have steganography as an option for SSH there will be a need
for authentication only.

On Sat, 8 Dec 2001, Corinna Vinschen wrote:

> > Supporting cipher=none with MAC'd packets might make it legal to use ssh
> > in some countries where it couldn't otherwise be used, and while it would
>
> Just because an encryption implementation couldn't be exported from
> the US, it doesn't mean they weren't available.  That would mean
> that there were no developers outside of the US ;-)



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




From ccwf at bacchus.com  Sun Dec  9 12:33:29 2001
From: ccwf at bacchus.com (Charles C. Fu)
Date: 08 Dec 2001 17:33:29 -0800
Subject: Bug#66740: ssh-askpass-gnome: The first password is always bad (was: OpenSSH 3.0)
In-Reply-To: <20011107.124748.92055508.gotoh@taiyo.co.jp>
References: <20011106224841.A20613@folly>
	<20011107.124748.92055508.gotoh@taiyo.co.jp>
Message-ID: <87pu5pch3q.fsf_-_@thanatar.east.bacchus.com>

   Background: Many Debian users have reported a problem to Debian
   with ssh-askpass-gnome always rejecting the first passphrase.
   <URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=66740&repeatmerged=yes>
   shows the thread for one of these reports.

OK, I have traced through the logic and believe I have identified the
causes of this bug.

1. ssh-askpass-gnome uses puts() to print the passphrase.  The puts()
   call writes the passphrase and a line terminator to stdout.
   However, multiple write() calls may be invoked by puts() to write
   the passphrase and terminator.

2. In ssh-add, readpass.c(ssh_askpass) uses a single read() call to
   read the passphrase from the SSH_ASKPASS program.  If the
   SSH_ASKPASS program used multiple calls to write(), depending upon
   timing, read() may not return the characters written by write()
   calls after the first.  With Debian/Linux, the result is that only
   the passphrase is read and not the LF.

3. In ssh-add, readpass.c(ssh_askpass) did not correctly check if the
   characters read ended with a line terminator.  If they did not,
   the function would not null-terminate the string correctly, and
   ssh-add could report a bad passphrase (depending upon what the
   contents of buf happened to be before the read()).  As reported on
   the openssh-unix-dev mailing list (see, for example, the message
   <20011107.124748.92055508.gotoh at taiyo.co.jp> on 06 Nov 2001), this
   problem could also result in worse problems.

   The second time the passphrase is requested, the buffer into
   which the passphrase is read is pre-zeroed with memset, thereby
   null-terminating the string (normally) and avoiding the bug.

Fixing any of these three issues should eliminate this problem.  The
third issue was already fixed in the CVS repository on Nov 8, 2001.  I
think the second issue should be addressed as well.

1. As Mattia Monga suggested, replacing puts() in ssh-askpass-gnome
   with a function that does a single call to write() works around the
   bug.  Of course, it does not fix the underlying problems in
   readpass.c, so other SSH_ASKPASS programs could continue to exhibit
   this bug.

2. In readpass.c(ssh_askpass), replacing the single read() call with a
   loop to be sure all characters are read (up to the size permitted
   by the buf buffer) would be a good fix to the problem.

   Moving the waitpid() call up before the read() call (so that the
   passphrase is not read from the pipe until the SSH_ASKPASS program
   has exited) also works for ordinary cases.  However, deadlock could
   then result if the SSH_ASKPASS program tries to write a passphrase
   exceeding the OS buffer for pipes.

3. Revision 1.23 of readpass.c, as a pleasant side effect, by ensuring
   that the characters read are always null terminated, works around
   the ssh-askpass-gnome problem in addition to fixing the buffer
   overflow problem for which it was originally submitted.  Simply
   picking up this recent revision in Debian (it was incorporated into
   OpenSSH 3.0.1) should have fixed the apparent ssh-askpass-gnome
   bug, so it and all the duplicate reports of this problem can now be
   closed in the Debian bug tracking system.  I can confirm that one
   of my Debian boxes exhibited this bug in versions up to and
   including 2.9p2-6 and that it has now finally gone away with the
   installation of 3.0.1p1-1.2.

   Again, theoretical problems with other SSH_ASKPASS programs which
   use multiple write() calls to write the passphrase will remain
   until issue 2 above is resolved.

Finally, since readpass.c(ssh_askpass) does not use the stdio library
to read the passphrase, it might be a good idea to recommend
SSH_ASKPASS programs not use stdio routines to write the passphrase.
This would avoid line terminator mismatches.  However, with the
changes in readpass.c revision 1.23, the line terminator has become
optional, and I think it would be an even better idea to phase out
writing it in SSH_ASKPASS programs.

-ccwf
-- 
                 ,--         Charles C. Fu          ccwf at bacchus.com
___  __ __. . ,-/--         Vice President            310-455-2396
    (_,(_,|/|/ /             Bacchus, Inc.    http://www.bacchus.com/~ccwf/
            --'


From mouring at etoh.eviladmin.org  Sun Dec  9 16:36:52 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sat, 8 Dec 2001 23:36:52 -0600 (CST)
Subject: -c none option
In-Reply-To: <20011208132306.Z740@cygbert.vinschen.de>
Message-ID: <Pine.BSO.4.33.0112082333330.28085-100000@etoh.eviladmin.org>


Besides OpenSSH is a canada product.  All us USites that do work on it
don't touch the encryption aspects.  And Canada does not have all those
stupid laws yet..  I'm waiting to see what Canada does on the WIPO sstuff.

- Ben

On Sat, 8 Dec 2001, Corinna Vinschen wrote:

> On Fri, Dec 07, 2001 at 03:40:27PM -0800, Jason Stone wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > >     The SSH2 protocol separated authentication and message integrity
> > > from encryption.  As such, OpenSSH *should* be supporting None as an
> > > encryption type while enforcing authenticated packets w/ hmac-md5 or
> > > something similar. It isn't.
> >
> > Also, many governments regulate the use of "cryptographic" algorithms, but
> > not "authentication" algorithms.  In particular, for many years you could
> > not export 56-bit DES implementations from the US, but you could export
> > any MD5 or SHA1 implementation.
> >
> > Supporting cipher=none with MAC'd packets might make it legal to use ssh
> > in some countries where it couldn't otherwise be used, and while it would
>
> Just because an encryption implementation couldn't be exported from
> the US, it doesn't mean they weren't available.  That would mean
> that there were no developers outside of the US ;-)
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Developer
> Red Hat, Inc.
> mailto:vinschen at redhat.com
>



From mouring at etoh.eviladmin.org  Sun Dec  9 16:50:41 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sat, 8 Dec 2001 23:50:41 -0600 (CST)
Subject: -c none option
In-Reply-To: <Pine.LNX.4.41.0112081712590.16550-100000@catbert.rellim.com>
Message-ID: <Pine.BSO.4.33.0112082343470.28085-100000@etoh.eviladmin.org>


This sems like a bullshit reason to add -c none. In those countries the
POSESSION  of ssh even if you don't use the higher encryptions is illegal.

- Ben

On Sat, 8 Dec 2001, Gary E. Miller wrote:

> Yo Corinna!
>
> Having something available is not good enough.  Crypto use in many
> countries could mean jail.  I know people that have been outside the
> US using crypto and told by the local government to cease and desist
> or be arrested.
>
> Until we have steganography as an option for SSH there will be a need
> for authentication only.
>
> On Sat, 8 Dec 2001, Corinna Vinschen wrote:
>
> > > Supporting cipher=none with MAC'd packets might make it legal to use ssh
> > > in some countries where it couldn't otherwise be used, and while it would
> >
> > Just because an encryption implementation couldn't be exported from
> > the US, it doesn't mean they weren't available.  That would mean
> > that there were no developers outside of the US ;-)
>
>
>
> 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
>
>
>



From markus at openbsd.org  Mon Dec 10 00:34:06 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:34:06 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112072218.OAA15873@ns2.bizsystems.net>; from michael@bizsystems.com on Fri, Dec 07, 2001 at 02:18:10PM -0800
References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <200112072218.OAA15873@ns2.bizsystems.net>
Message-ID: <20011209143406.A8904@folly>

On Fri, Dec 07, 2001 at 02:18:10PM -0800, Michael wrote:
> Has this issue been resolved in 3.02 ??

no bugreport, no fix.  no bug, no fix.


From markus at openbsd.org  Mon Dec 10 00:35:04 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:35:04 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112080420.UAA17468@ns2.bizsystems.net>; from michael@bizsystems.com on Fri, Dec 07, 2001 at 08:20:55PM -0800
References: <00b601c17f75$8f1936a0$1701000a@effugas> <200112080420.UAA17468@ns2.bizsystems.net>
Message-ID: <20011209143504.B8904@folly>

On Fri, Dec 07, 2001 at 08:20:55PM -0800, Michael wrote:
> so what about connections that are made from a script??

the so-called bug is only related to sessions with ptys.

you don't use ptys with scripts, so there is no problems
for scripts.


From markus at openbsd.org  Mon Dec 10 00:42:29 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:42:29 +0100
Subject: Patch to allow gatewaying of remote forwarded ports
In-Reply-To: <01120800034501.08991@fontina>; from lstein@cshl.org on Sat, Dec 08, 2001 at 12:03:45AM -0500
References: <20011208045536.D6C572DF3C@shitei.mindrot.org> <01120800034501.08991@fontina>
Message-ID: <20011209144229.A18440@folly>

On Sat, Dec 08, 2001 at 12:03:45AM -0500, Lincoln Stein wrote:
> Enclosed is a patch against the "portable" OpenSSH version 3.02p1.  It 
> enables the -g switch when applied to -R (remote) forwardings.  This allows 
> remote hosts to connect to forwarded ports on the sshd host.

+ gateway_ports = (strncmp(listen_address,"0.0.0.0",7) == 0) || options.gateway_ports;                                                    

this would violate the policy of the server.

if the sshd_config says: gatewayports==no, then the
socket should be bound to 127.0.0.1 only, regardless
of what the client wants.

	gateway_ports = options.gateway_ports &&
	    (strncmp(listen_address,"0.0.0.0",7) == 0);

would be correct.


From markus at openbsd.org  Mon Dec 10 00:43:32 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:43:32 +0100
Subject: Name Resolving bug in Open SSH 3.0.2
In-Reply-To: <5.1.0.14.2.20011208140020.00aa2540@pop3.norton.antivirus>; from Jewnix@technohac.com on Sat, Dec 08, 2001 at 02:08:00PM +0200
References: <5.1.0.14.2.20011208140020.00aa2540@pop3.norton.antivirus>
Message-ID: <20011209144332.B18440@folly>

On Sat, Dec 08, 2001 at 02:08:00PM +0200, Gil Disatnik wrote:
> In OpenSSH 3.0.2p1 there is a strange name resolving bug:

openssh is not involved.  it's the resolver libraries job and/or bug.


From markus at openbsd.org  Mon Dec 10 00:46:02 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:46:02 +0100
Subject: -c none option
In-Reply-To: <3C11441F.545BF47A@txc.com>; from meyman@txc.com on Fri, Dec 07, 2001 at 05:35:11PM -0500
References: <3C11441F.545BF47A@txc.com>
Message-ID: <20011209144602.C18440@folly>

On Fri, Dec 07, 2001 at 05:35:11PM -0500, Mark Eyman wrote:
> Also, assuming -c none works, how the password authentication suppose to
> be implemented? Encrypted or unencrypted?

unencrypted, since encryption is a different layer.


From markus at openbsd.org  Mon Dec 10 00:48:03 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:48:03 +0100
Subject: -c none option
In-Reply-To: <00a301c17f73$a5c014c0$1701000a@effugas>; from dan@doxpara.com on Fri, Dec 07, 2001 at 03:05:21PM -0800
References: <3C11441F.545BF47A@txc.com> <00a301c17f73$a5c014c0$1701000a@effugas>
Message-ID: <20011209144803.D18440@folly>

On Fri, Dec 07, 2001 at 03:05:21PM -0800, Dan Kaminsky wrote:
> Mark--
> 
>     The SSH2 protocol separated authentication and message integrity from
> encryption.  As such,  OpenSSH *should* be supporting None as an encryption

There is no SHOULD in draft-ietf-secsh-transport-11.txt

     none             OPTIONAL          no encryption; NOT RECOMMENDED

-m


From markus at openbsd.org  Mon Dec 10 00:50:46 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 14:50:46 +0100
Subject: -c none option
In-Reply-To: <00a301c17f73$a5c014c0$1701000a@effugas>; from dan@doxpara.com on Fri, Dec 07, 2001 at 03:05:21PM -0800
References: <3C11441F.545BF47A@txc.com> <00a301c17f73$a5c014c0$1701000a@effugas>
Message-ID: <20011209145046.E18440@folly>

On Fri, Dec 07, 2001 at 03:05:21PM -0800, Dan Kaminsky wrote:
>     I've actually been getting steadily more concerned with SSH's
> performance.  FTP runs at about 3MB/s, standard SCP at 1MB/s, and SFTP at
> 100KB/s(!!!).

this can be improved by fixing the sftp client. just go for it.


From mdb at juniper.net  Mon Dec 10 03:25:04 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Sun, 09 Dec 2001 08:25:04 -0800
Subject: CVS server not responding 
In-Reply-To: Mail from kent@unit.liu.se (Kent =?iso-8859-1?q?Engstr=F6m?=) 
             dated 07 Dec 2001 12:22:31 +0100
             <m33d2nb7go.fsf_-_@ceres.unit.liu.se> 
Message-ID: <200112091625.fB9GP4674286@merlot.juniper.net>

For what it is worth, I have had the same problem for the last few days.

So, I have been forced to fetch the daily snapshot rather than doing
an update of my local cvs checked-out tree.

http://bass.directhit.com/openssh_snap/openssh-SNAP-`date +%Y%m%d`.tar.gz

I hope that whatever the problem is on the bass.directhit.com AnonCVS
server gets fixed son.

	Thanks,
	-- Mark

> From: kent at unit.liu.se (Kent =?iso-8859-1?q?Engstr=F6m?=)
> Date: 07 Dec 2001 12:22:31 +0100
> 
> Hi,
> 
> the anonymous CVS server for portable OpenSSH does not want to talk to
> me:
> 
> > % cvs upd -Pd
> > cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused
> 
> Looking at http://www.openssh.com/portable.html, 
> ":pserver:cvs at bass.directhit.com:/cvs" is still the recommended
> repository.
> 
> Is this a known problem?
> 
> -- 
> Kent Engstr?m,		Link?ping University Incident Response Team
> kent at unit.liu.se  	abuse at liu.se
> +46 13 28 1744
> 
> UNIT, Link?ping University; SE-581 83  LINK?PING; SWEDEN
> 



From lstein at cshl.org  Mon Dec 10 03:35:37 2001
From: lstein at cshl.org (Lincoln Stein)
Date: Sun, 9 Dec 2001 11:35:37 -0500
Subject: Patch to allow gatewaying of remote forwarded ports
In-Reply-To: <20011209144229.A18440@folly>
References: <20011208045536.D6C572DF3C@shitei.mindrot.org> <01120800034501.08991@fontina> <20011209144229.A18440@folly>
Message-ID: <01120911353700.16161@fontina>

I was worried about that too, but the current behavior is if the server says 
gatewayports "yes", then all ports are remotely accessible regardless of what 
the client wants.

Lincoln

On Sunday 09 December 2001 08:42, Markus Friedl wrote:
> On Sat, Dec 08, 2001 at 12:03:45AM -0500, Lincoln Stein wrote:
> > Enclosed is a patch against the "portable" OpenSSH version 3.02p1.  It
> > enables the -g switch when applied to -R (remote) forwardings.  This
> > allows remote hosts to connect to forwarded ports on the sshd host.
>
> + gateway_ports = (strncmp(listen_address,"0.0.0.0",7) == 0) ||
> options.gateway_ports;
>
> this would violate the policy of the server.
>
> if the sshd_config says: gatewayports==no, then the
> socket should be bound to 127.0.0.1 only, regardless
> of what the client wants.
>
> 	gateway_ports = options.gateway_ports &&
> 	    (strncmp(listen_address,"0.0.0.0",7) == 0);
>
> would be correct.

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY

NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. 
PLEASE WRITE FOR DETAILS.
========================================================================


From lstein at cshl.org  Mon Dec 10 03:51:21 2001
From: lstein at cshl.org (Lincoln Stein)
Date: Sun, 9 Dec 2001 11:51:21 -0500
Subject: Patch to allow gatewaying of remote forwarded ports
In-Reply-To: <20011209144229.A18440@folly>
References: <20011208045536.D6C572DF3C@shitei.mindrot.org> <01120800034501.08991@fontina> <20011209144229.A18440@folly>
Message-ID: <01120911512102.16161@fontina>

Enclosed is a revised patch which respects the server policy with respect to 
GatewayPorts.

Lincoln

On Sunday 09 December 2001 08:42, Markus Friedl wrote:
> On Sat, Dec 08, 2001 at 12:03:45AM -0500, Lincoln Stein wrote:
> > Enclosed is a patch against the "portable" OpenSSH version 3.02p1.  It
> > enables the -g switch when applied to -R (remote) forwardings.  This
> > allows remote hosts to connect to forwarded ports on the sshd host.
>
> + gateway_ports = (strncmp(listen_address,"0.0.0.0",7) == 0) ||
> options.gateway_ports;
>
> this would violate the policy of the server.
>
> if the sshd_config says: gatewayports==no, then the
> socket should be bound to 127.0.0.1 only, regardless
> of what the client wants.
>
> 	gateway_ports = options.gateway_ports &&
> 	    (strncmp(listen_address,"0.0.0.0",7) == 0);
>
> would be correct.

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY

NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. 
PLEASE WRITE FOR DETAILS.
========================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-3.0.2p1-gateway.patch
Type: text/x-c
Size: 2920 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011209/bc997da5/attachment.bin 

From markus at openbsd.org  Mon Dec 10 04:55:23 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 9 Dec 2001 18:55:23 +0100
Subject: Patch to allow gatewaying of remote forwarded ports
In-Reply-To: <01120911353700.16161@fontina>; from lstein@cshl.org on Sun, Dec 09, 2001 at 11:35:37AM -0500
References: <20011208045536.D6C572DF3C@shitei.mindrot.org> <01120800034501.08991@fontina> <20011209144229.A18440@folly> <01120911353700.16161@fontina>
Message-ID: <20011209185523.A13089@folly>

On Sun, Dec 09, 2001 at 11:35:37AM -0500, Lincoln Stein wrote:
> I was worried about that too, but the current behavior is if the server says 
> gatewayports "yes", then all ports are remotely accessible regardless of what 
> the client wants.

yes, but that's not the default.

however, having ssh force the sshd to listen to localhost is ok.

-m


From simon at sxw.org.uk  Mon Dec 10 10:41:53 2001
From: simon at sxw.org.uk (Simon Wilkinson)
Date: Sun, 9 Dec 2001 23:41:53 +0000
Subject: gssapi + seam on solaris
In-Reply-To: <200112091230.MAA25609@canna.dcs.ed.ac.uk>
References: <200112091230.MAA25609@canna.dcs.ed.ac.uk>
Message-ID: <01120923415301.05445@loki.dcs.ed.ac.uk>

> i've compiled openssh with the gssapi patches on a solaris 8 system
> using sun's SEAM.  gssapi isn't initializing properly it seems.

As far as I'm aware, no-one has yet tested these patches with SEAM. I'd be 
_very_ interested in getting this working.

> > debug2: input_userauth_request: try method gssapi
> > debug1: Mechanism negotiation is not supported

This indicates that the client is trying to establish a gssapi connection 
when it has no supported GSSAPI mechanisms. This is rather wierd, and can 
only result from a compile time configuration problem. It looks like GSSAPI 
is being enabled, but no mechanisms (either KRB5 or GSI) are being added.
Looking at my additions to configure, I'm not sure how this can happen! 

>From what I've heard of SEAM (I've yet to play with it), I suspect that 
things won't work "out of the box", but if you've got time to investigate 
that would be greatly appreciated!

Could you send me a copy of the output from running configure? Also, if you 
could let me see the section of config.h that lists the GSSAPI related 
defines, that would be good.

-- 
Simon Wilkinson            <simon at sxw.org.uk>          http://www.sxw.org.uk
"Richard had noticed that events were cowards: they didn't occur singly, but
instead they would run in packs and leap out at him all at once." 
- Neil Gaiman 



From stevesk at pobox.com  Mon Dec 10 14:23:35 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Sun, 9 Dec 2001 19:23:35 -0800 (PST)
Subject: largefile problems; bug 20
Message-ID: <Pine.HPX.4.42.0112091921050.1311-100000@jenny>

can anyone duplicate sftp/scp related largefile problems described in the
following?  thanks.

http://bugzilla.mindrot.org/show_bug.cgi?id=20



From bugzilla-daemon at mindrot.org  Tue Dec 11 03:56:50 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 03:56:50 +1100 (EST)
Subject: [Bug 27] per display information on HP-UX 11.00
Message-ID: <20011210165650.3921F2DF5E@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=27

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com
             Status|ASSIGNED                    |NEW



------- Additional Comments From stevesk at pobox.com  2001-12-11 03:56 -------
assign to 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 Dec 11 03:59:11 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 03:59:11 +1100 (EST)
Subject: [Bug 20] sftp appears to have a file size limit as well
Message-ID: <20011210165911.AD7B52DF55@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=20

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com
             Status|ASSIGNED                    |NEW



------- Additional Comments From stevesk at pobox.com  2001-12-11 03:59 -------
assign to stevesk



------- 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 Dec 11 04:00:09 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 04:00:09 +1100 (EST)
Subject: [Bug 14] Can't change expired /etc/shadow password without PAM
Message-ID: <20011210170009.294F72DF61@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=14

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com
             Status|ASSIGNED                    |NEW



------- Additional Comments From stevesk at pobox.com  2001-12-11 04:00 -------
assign to stevesk



------- 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 Dec 11 04:05:42 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 04:05:42 +1100 (EST)
Subject: [Bug 2] sshd should have BSM auditing on Solaris
Message-ID: <20011210170542.52F9D2DF10@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=2

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |REMIND



------- Additional Comments From stevesk at pobox.com  2001-12-11 04:05 -------
waiting for code or code samples.



------- 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 Dec 11 04:07:52 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 04:07:52 +1100 (EST)
Subject: [Bug 8] 20011024 compile failure on SGI
Message-ID: <20011210170752.446E32DF5F@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=8

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com



------- Additional Comments From stevesk at pobox.com  2001-12-11 04:07 -------
waiting for submitter to retest



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From michael at bizsystems.com  Tue Dec 11 04:10:08 2001
From: michael at bizsystems.com (Michael)
Date: Mon, 10 Dec 2001 09:10:08 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011209143406.A8904@folly>
References: <200112072218.OAA15873@ns2.bizsystems.net>; from michael@bizsystems.com on Fri, Dec 07, 2001 at 02:18:10PM -0800
Message-ID: <200112101710.JAA31549@ns2.bizsystems.net>

> On Fri, Dec 07, 2001 at 02:18:10PM -0800, Michael wrote:
> > Has this issue been resolved in 3.02 ??
> 
> no bugreport, no fix.  no bug, no fix.
> 

so try this, guaranteed to hang the exit of the session for 
openssh, but ssh-1.2.27 likes it fine.

file tst.pl
#!/usr/bin/perl

while (1) {
  sleep 1;
}

# end

at the keyboard, just type

> perl tst.pl &
> exit


Like I said, ssh-1.2.27 works fine
OpenSSH_2.9.9p2 is guaranteed to hang

This means that a daemon can never be stopped and restarted from the 
keyboard without a hang or screwing around with special exit 
procedures. Looks, sounds, smells like a bug to me.

Michael
Michael at Insulin-Pumpers.org


From mouring at etoh.eviladmin.org  Tue Dec 11 04:19:46 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 11:19:46 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <200112101710.JAA31549@ns2.bizsystems.net>
Message-ID: <Pine.BSO.4.33.0112101117040.26173-100000@etoh.eviladmin.org>


[..]
> Like I said, ssh-1.2.27 works fine
> OpenSSH_2.9.9p2 is guaranteed to hang
>
ssh 1.2.27 could/would lose data on scp because is favored quiting before
the buffers were flushed.

> This means that a daemon can never be stopped and restarted from the
> keyboard without a hang or screwing around with special exit
> procedures. Looks, sounds, smells like a bug to me.
>

This pretty much is very unhelpful.  If you read the whole history on this
mailinglist a more USEFUL insight would be why it occurs on some UNIXes
and not others.  And what the correct solution is.

Something no one has been able to do, and I'm at a loss without approving
a hack that may bite us in the ass later on.

- Ben



From johnh at aproposretail.com  Tue Dec 11 04:23:28 2001
From: johnh at aproposretail.com (John Hardin)
Date: 10 Dec 2001 09:23:28 -0800
Subject: -c none option
In-Reply-To: <Pine.LNX.4.41.0112081712590.16550-100000@catbert.rellim.com>
References: <Pine.LNX.4.41.0112081712590.16550-100000@catbert.rellim.com>
Message-ID: <1008005008.6589.16.camel@johnh.apropos.com>

On Sat, 2001-12-08 at 17:15, Gary E. Miller wrote:

> Until we have steganography as an option for SSH

Streaming steganographic video hiding a telnet session? How hideously
baroque...

-- 
John Hardin                                   <johnh at aproposretail.com>
Internal Systems Administrator                    voice: (425) 672-1304
Apropos Retail Management Systems, Inc.             fax: (425) 672-0192
-----------------------------------------------------------------------
 "...in retrospect, we probably should have turned it on by default."
     - Craig Mundie, Microsoft CTO, on shipping Windows XP with the
       much-hyped "Internet Connection Firewall" turned off by default
-----------------------------------------------------------------------



From michael at bizsystems.com  Tue Dec 11 04:40:22 2001
From: michael at bizsystems.com (Michael)
Date: Mon, 10 Dec 2001 09:40:22 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.BSO.4.33.0112101117040.26173-100000@etoh.eviladmin.org>
References: <200112101710.JAA31549@ns2.bizsystems.net>
Message-ID: <200112101740.JAA31827@ns2.bizsystems.net>

> 
> [..]
> > Like I said, ssh-1.2.27 works fine
> > OpenSSH_2.9.9p2 is guaranteed to hang
> >
> ssh 1.2.27 could/would lose data on scp because is favored quiting
> before the buffers were flushed.
> 
> > This means that a daemon can never be stopped and restarted from the
> > keyboard without a hang or screwing around with special exit
> > procedures. Looks, sounds, smells like a bug to me.
> >
> 
> This pretty much is very unhelpful.  If you read the whole history
> on this mailinglist a more USEFUL insight would be why it occurs on
> some UNIXes and not others.  And what the correct solution is.
> 
> Something no one has been able to do, and I'm at a loss without
> approving a hack that may bite us in the ass later on.
> 

I have been following this thread for some time. John Bowman 
submitted a patch for 3.01 on Nov 14 that purportedly fixes the 
problem. I don't know what this does on various OS's and am certainly 
not the one to say it is "the" permanent fix, but there was no 
further comment after that. I'd like to see a fix as the present 
situation certainly is not acceptable in the long run. If John's fix 
works for Linux and does so without data loss, then perhaps it should 
be included and compiled in by configuration option for those OS's 
where it is known to solve the problem.

Michael
Michael at Insulin-Pumpers.org


From mouring at etoh.eviladmin.org  Tue Dec 11 04:49:06 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 11:49:06 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <200112101740.JAA31827@ns2.bizsystems.net>
Message-ID: <Pine.BSO.4.33.0112101143360.26173-100000@etoh.eviladmin.org>



On Mon, 10 Dec 2001, Michael wrote:

> >
> > [..]
> > > Like I said, ssh-1.2.27 works fine
> > > OpenSSH_2.9.9p2 is guaranteed to hang
> > >
> > ssh 1.2.27 could/would lose data on scp because is favored quiting
> > before the buffers were flushed.
> >
> > > This means that a daemon can never be stopped and restarted from the
> > > keyboard without a hang or screwing around with special exit
> > > procedures. Looks, sounds, smells like a bug to me.
> > >
> >
> > This pretty much is very unhelpful.  If you read the whole history
> > on this mailinglist a more USEFUL insight would be why it occurs on
> > some UNIXes and not others.  And what the correct solution is.
> >
> > Something no one has been able to do, and I'm at a loss without
> > approving a hack that may bite us in the ass later on.
> >
>
> I have been following this thread for some time. John Bowman
> submitted a patch for 3.01 on Nov 14 that purportedly fixes the
> problem. I don't know what this does on various OS's and am certainly
> not the one to say it is "the" permanent fix, but there was no
> further comment after that. I'd like to see a fix as the present
> situation certainly is not acceptable in the long run. If John's fix
> works for Linux and does so without data loss, then perhaps it should
> be included and compiled in by configuration option for those OS's
> where it is known to solve the problem.
>
As stated John's fix did it at the cost of the protocol and also was
not very portable.  It may have solved it for Linux, but it broken OpenBSD
which worked fine without it.  And did not solve the problem for other
platforms such as NeXT, HP/UX, etc.  So it was considered unacceptable.

I believe this has been stated at least 3 times so far in the last year.

The issue resolves around how each platform handles open File descriptors
on TTYs.  Thus the reason why if you redirect all file descriptors to
/dev/null when launching services it does not hang.

- Ben



From bob at proulx.com  Tue Dec 11 04:57:33 2001
From: bob at proulx.com (Bob Proulx)
Date: Mon, 10 Dec 2001 10:57:33 -0700
Subject: hang on exit bug under Linux
In-Reply-To: <200112101710.JAA31549@ns2.bizsystems.net>
References: <200112072218.OAA15873@ns2.bizsystems.net>
	<20011209143406.A8904@folly>
	<200112101710.JAA31549@ns2.bizsystems.net>
Message-ID: <200112101757.fBAHvX919960@torment.proulx.com>

> so try this, guaranteed to hang the exit of the session for 
> openssh, but ssh-1.2.27 likes it fine.
> file tst.pl
> #!/usr/bin/perl
> while (1) {
>   sleep 1;
> }
> # end
> at the keyboard, just type
> > perl tst.pl &
> > exit
> This means that a daemon can never be stopped and restarted from the 
> keyboard without a hang or screwing around with special exit 
> procedures. Looks, sounds, smells like a bug to me.

That is not a proper daemon program and therefore not a good example
of a problem.  Proper daemons should always close any tty file
descriptor, detach from any controlling terminals, call setsid() to
form a new process group, etc.  This is more representative of a
program that could loose data.

Perhaps one of the reasons this issue has been hard to get agreement
on is that everyone is testing with different daemons and some of
those are ill behaved?

Bob


From Nicolas.Williams at ubsw.com  Tue Dec 11 04:57:45 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 12:57:45 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <200112101740.JAA31827@ns2.bizsystems.net>; from michael@bizsystems.com on Mon, Dec 10, 2001 at 09:40:22AM -0800
References: <200112101710.JAA31549@ns2.bizsystems.net> <Pine.BSO.4.33.0112101117040.26173-100000@etoh.eviladmin.org> <200112101740.JAA31827@ns2.bizsystems.net>
Message-ID: <20011210125744.A1177@sm2p1386swk.wdr.com>

 - with no ptys, you want to make sure that your remote command closes
   all its stdio and you get no hang (there was a hang bug wrt
   agent/x11/port forwarding).

 - with pty you may want sshd to do killpg() on the pty/tty process
   groups when the client closes the session.

 - with and without ptys it would be nice to have a client-side option
   to have the client close the main session as soon as possible (launch
   and forget).

Closing a session is a client-side decision (unless the server is
halting/rebooting, say :)

I've made the mistake of thinking otherwise.

Cheers,

Nico


On Mon, Dec 10, 2001 at 09:40:22AM -0800, Michael wrote:
> > 
> > [..]
> > > Like I said, ssh-1.2.27 works fine
> > > OpenSSH_2.9.9p2 is guaranteed to hang
> > >
> > ssh 1.2.27 could/would lose data on scp because is favored quiting
> > before the buffers were flushed.
> > 
> > > This means that a daemon can never be stopped and restarted from the
> > > keyboard without a hang or screwing around with special exit
> > > procedures. Looks, sounds, smells like a bug to me.
> > >
> > 
> > This pretty much is very unhelpful.  If you read the whole history
> > on this mailinglist a more USEFUL insight would be why it occurs on
> > some UNIXes and not others.  And what the correct solution is.
> > 
> > Something no one has been able to do, and I'm at a loss without
> > approving a hack that may bite us in the ass later on.
> > 
> 
> I have been following this thread for some time. John Bowman 
> submitted a patch for 3.01 on Nov 14 that purportedly fixes the 
> problem. I don't know what this does on various OS's and am certainly 
> not the one to say it is "the" permanent fix, but there was no 
> further comment after that. I'd like to see a fix as the present 
> situation certainly is not acceptable in the long run. If John's fix 
> works for Linux and does so without data loss, then perhaps it should 
> be included and compiled in by configuration option for those OS's 
> where it is known to solve the problem.
> 
> Michael
> Michael at Insulin-Pumpers.org
--
-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 michael at bizsystems.com  Tue Dec 11 05:00:44 2001
From: michael at bizsystems.com (Michael)
Date: Mon, 10 Dec 2001 10:00:44 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011209143504.B8904@folly>
References: <200112080420.UAA17468@ns2.bizsystems.net>; from michael@bizsystems.com on Fri, Dec 07, 2001 at 08:20:55PM -0800
Message-ID: <200112101800.KAA32031@ns2.bizsystems.net>

> On Fri, Dec 07, 2001 at 08:20:55PM -0800, Michael wrote:
> > so what about connections that are made from a script??
> 
> the so-called bug is only related to sessions with ptys.
> 
> you don't use ptys with scripts, so there is no problems
> for scripts.
> 

That's not true. Example:

on the target host running openssh sshd daemon

#!/usr/bin/perl
while(1) {
  sleep 1;
}
# end

on the client, with no password required

#!/bin/sh
/usr/localbin/ssh targethost "/usr/bin/perl tstprog.pl &"
# end

the script hangs and never returns because sshd will not close its 
connection to the client. Seems whenever STDOUT or STDERR may return 
info, sshd will not detach as other programs such as telnet, rsh, 
ssh-1.2x, etc.. are happy to do.

Stick this in your crontab if you want to really screw up your 
machine.

Michael
Michael at Insulin-Pumpers.org


From bugzilla-daemon at mindrot.org  Tue Dec 11 05:09:20 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 05:09:20 +1100 (EST)
Subject: [Bug 31] ssh-keygen not able to save key files
Message-ID: <20011210180920.7A7842DF79@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=31

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com



------- Additional Comments From stevesk at pobox.com  2001-12-11 05:09 -------
i can't explain this; i can dup with:

$ ssh-keygen -t rsa -f '' -N ""
Generating public/private rsa key pair.
open  failed: No such file or directory.
Saving the key failed: .

need more info.  can other macosx users dup?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From internet at psimation.com  Tue Dec 11 05:06:25 2001
From: internet at psimation.com (P.Agenbag)
Date: Mon, 10 Dec 2001 20:06:25 +0200
Subject: Time delay security function
Message-ID: <3C14F9A1.9020706@psimation.com>

Hi all developers.

I cannot consider myself to be a software developer ( only have a fair 
exposure to some C++, but mostly Perl nad alot of PHP), so forgive my 
ignorance.

I recently had an idea about improving security of a system to make it 
impossible for another party to hack a system via a login procedure.

Now I'm not sure how current authentication systems work, but I think 
that if one could implement the following into a login procedure, it 
should be virtually impossible to crack a password:

The idea is as follow.
When one enters the system root password for the first time, what if one 
could capture the time between keystrokes as well, and store the time 
between strokes on the host system only. This way, even if someone tries 
to run combinations against a password, it would be impossible for the 
cracker to "simulate" the time between two specific characters of the 
password as the time between two strokes is not sent with the password 
string but measured by the host machine as it receives each character. 
So, this is also the first "glitch" in the idea... One would either have 
to make the login process a "streaming" process, ie. reading keystrokes 
as they happen and not waiting for a return, or the passwords needs to 
be read one character at a time with a return after each.

My vision with a system like this would further be to refine a system 
like this to build a profile of an individual via the tempo of their 
typing, much like fingerprints, I'm convinced that every person has his 
own unique typing "print" which a system should be able to "learn" over 
time and would also maybe be able to grow with the person as their 
typing improves.
If this could be made possible, EVERYTHING a person does on his/her 
system would be under scrutiny of constant checking, and not just the 
login procedure, theoretically making the system much safer even if 
someone gained access to the system.

Now, in theory this sounds all possible to me, but I'm not very clued up 
on coding and I'm not even sure if someone else has already tried 
something like this. So, I wouldn't know if this is at all feasible, 
hence my post here. I'd really appreciate your input. And if a 
substantial amount of developers on this forum feels like it could be 
possible to develop a system like this, I would be very interested to be 
part of the development in some way. I would eventually like to become a 
crack coder, but knows when to take a step back and let the experts take 
over.

Please let me know what you think and if you guys think it's a lame idea 
or if this is not the place to post wacky ideas, please tell me too, but 
at least point me towards a list were i can maybe get some help or 
advise or anything for that matter.
I ran this idea past the people at ssh.com about a year ago, but never 
got any response from them, so maybe they think it sucks.

Anyway, thanks for your time and input.

Petre Agenbag
Linux fan
South Africa
 



From mouring at etoh.eviladmin.org  Tue Dec 11 05:14:14 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 12:14:14 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <20011210125744.A1177@sm2p1386swk.wdr.com>
Message-ID: <Pine.BSO.4.33.0112101212020.26173-100000@etoh.eviladmin.org>



On Mon, 10 Dec 2001, Nicolas Williams wrote:

>  - with no ptys, you want to make sure that your remote command closes
>    all its stdio and you get no hang (there was a hang bug wrt
>    agent/x11/port forwarding).
>
>  - with pty you may want sshd to do killpg() on the pty/tty process
>    groups when the client closes the session.
>
Markus suggsted this and threw together a small patch, but I've
been able to test it since my test servers are still scattered all
over Minnesota and I'm only slowly now reclaiming them and putting them
into my house.

- Ben



From michael at bizsystems.com  Tue Dec 11 05:20:46 2001
From: michael at bizsystems.com (Michael)
Date: Mon, 10 Dec 2001 10:20:46 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <200112101757.fBAHvX919960@torment.proulx.com>
References: <200112101710.JAA31549@ns2.bizsystems.net>
Message-ID: <200112101820.KAA32192@ns2.bizsystems.net>

> > so try this, guaranteed to hang the exit of the session for 
> > openssh, but ssh-1.2.27 likes it fine.
> > file tst.pl
> > #!/usr/bin/perl
> > while (1) {
> >   sleep 1;
> > }
> > # end
> > at the keyboard, just type
> > > perl tst.pl &
> > > exit
> > This means that a daemon can never be stopped and restarted from the 
> > keyboard without a hang or screwing around with special exit 
> > procedures. Looks, sounds, smells like a bug to me.
> 
> That is not a proper daemon program and therefore not a good example
> of a problem.  Proper daemons should always close any tty file
> descriptor, detach from any controlling terminals, call setsid() to
> form a new process group, etc.  This is more representative of a
> program that could loose data.
> 
> Perhaps one of the reasons this issue has been hard to get agreement
> on is that everyone is testing with different daemons and some of
> those are ill behaved?
> 

Sure, I know it's not a proper daemon. The point is, it is 
representative of what people do everyday when writing 
script programs. Other clients that attach to unix boxes manage 
somehow to get around this and do so, in my opinion, because the 
developers realize that the the people that use these tools are not 
"perfect programers" that always do every thing exactly the right 
way. It is not unreasonable to assume that some people that write 
script code are all senior developers. It's also not unreasonable to 
expect or require that when a client is told to disconnect that the 
server end honor the request and clean up any mess that might remain. 
It's really not any different than the loss of the connection due to 
a network outage. I haven't checked, but I assume (excuse me) that 
sshd is capable of cleaning up after a network loss and not polluting 
the system with unused daemons that will never close.

If openssh is to remain a useful and viable tool for secure 
communication between hosts, it must operate in a manner where even 
the idiots can use it. When you sit at the keyboard and type 
>exit
one assumes that what's on the other end will go away. RTFM'ing to 
find ~. or ~? is not the solution. Likewise, ps-ax'ing the remote 
host to find out how many sshd's remain because of broken client 
connections is not realistic either. In many cases, the client 
operator or script does not even know what version of sshd is on the 
other end and will have no idea that there is a problem. The sysop of 
the target system is also in the dark since he has no idea what his 
users are doing at any given moment. Certainly the victim sysop does 
not want useless copies of sshd lying around in the job table simply 
because it is incapable of complying with a disconnect 
request from its client. Basically, the request for disconnect is 
analogus to a kill -15 followed by a kill -9 if there is not an 
immediate response. The daemon can not in the presence of a 
disconnect request or loss of connection to the client, fail to clean 
up what ever remains of its process and die unconditionally.

And, ..... yes I have followed and read the entire thread about this. 
What I fail to understand is why all the dithering. Data might be 
lost, but the client has said "GO AWAY" and obviously does not want 
any more data.

Michael
Michael at Insulin-Pumpers.org


From dan at doxpara.com  Tue Dec 11 05:50:06 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 10 Dec 2001 10:50:06 -0800
Subject: hang on exit bug under Linux
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com>
Message-ID: <003a01c181ab$7c0779e0$1701000a@effugas>

> That is not a proper daemon program and therefore not a good example
> of a problem.  Proper daemons should always close any tty file
> descriptor, detach from any controlling terminals, call setsid() to
> form a new process group, etc.  This is more representative of a
> program that could loose data.

So I've got all these Windows 9x machines that won't shut down.  Have to
power cycle them every time, or leave them on 24/7.  Rather wasteful of
power, and you risk your file system every time you decide to go through
with it.  It's one of the worst parts of 9x.

Look: ssh user at host "command" needs to never, ever hang.  It needs to not
leave processes running, it needs to not break scripts, it needs to simply
be "this command, as if it was run locally, only it's really somewhere else.
And if I'd be staring at a prompt somewhere else, damnit, I need to be
staring at a prompt here."

I've gotten critical pages at three in the morning from irate sysadmins half
the world over wondering why I'm taking up most of the load on their machine
as a side effect of this class of bugs.  Lemme tell you, stuff like that
puts a damper on my ability to evangelize SSH :-)

> Perhaps one of the reasons this issue has been hard to get agreement
> on is that everyone is testing with different daemons and some of
> those are ill behaved?

I think it's mostly a cross platform issue.  Ugliness always hides at the
fringes, and the exact set of behavior that signifies "this app is closed"
has the exact feel of a fringe.

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com




From Nicolas.Williams at ubsw.com  Tue Dec 11 06:02:12 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 14:02:12 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <003a01c181ab$7c0779e0$1701000a@effugas>; from dan@doxpara.com on Mon, Dec 10, 2001 at 10:50:06AM -0800
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <003a01c181ab$7c0779e0$1701000a@effugas>
Message-ID: <20011210140210.B1177@sm2p1386swk.wdr.com>

On Mon, Dec 10, 2001 at 10:50:06AM -0800, Dan Kaminsky wrote:
> > That is not a proper daemon program and therefore not a good example
> > of a problem.  Proper daemons should always close any tty file
> > descriptor, detach from any controlling terminals, call setsid() to
> > form a new process group, etc.  This is more representative of a
> > program that could loose data.
> 
> So I've got all these Windows 9x machines that won't shut down.  Have to
> power cycle them every time, or leave them on 24/7.  Rather wasteful of
> power, and you risk your file system every time you decide to go through
> with it.  It's one of the worst parts of 9x.
> 
> Look: ssh user at host "command" needs to never, ever hang.  It needs to not
> leave processes running, it needs to not break scripts, it needs to simply
> be "this command, as if it was run locally, only it's really somewhere else.
> And if I'd be staring at a prompt somewhere else, damnit, I need to be
> staring at a prompt here."
> 
> I've gotten critical pages at three in the morning from irate sysadmins half
> the world over wondering why I'm taking up most of the load on their machine
> as a side effect of this class of bugs.  Lemme tell you, stuff like that
> puts a damper on my ability to evangelize SSH :-)

This could (should?) be handled with an option to the client to close
the session as soon as possible, perhaps with a timer. Don't use a pty
so your remote command won't get SIGHUP though!

Hey, I have the same problem to deal with. I deal with it. I always put
in explicit stdio redirections to/from /dev/null. What's wrong with that?

> > Perhaps one of the reasons this issue has been hard to get agreement
> > on is that everyone is testing with different daemons and some of
> > those are ill behaved?
> 
> I think it's mostly a cross platform issue.  Ugliness always hides at the
> fringes, and the exact set of behavior that signifies "this app is closed"
> has the exact feel of a fringe.
> 
> Yours Truly,
> 
>     Dan Kaminsky
>     DoxPara Research
>     http://www.doxpara.com
> 


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 dan at doxpara.com  Tue Dec 11 06:08:13 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 10 Dec 2001 11:08:13 -0800
Subject: hang on exit bug under Linux
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <003a01c181ab$7c0779e0$1701000a@effugas> <20011210140210.B1177@sm2p1386swk.wdr.com>
Message-ID: <005901c181ae$0410b160$1701000a@effugas>

> Hey, I have the same problem to deal with. I deal with it. I always put
> in explicit stdio redirections to/from /dev/null. What's wrong with that?

ssh is a general purpose method of running remote commands as if they were
locally.  Not "specially written remote commands", not "custom apps".  Just
remote commands.

That's what it inherited from rsh, and though I perhaps use this
functionality a bit more...strenuously...then others, I think I have a
reasonable expectation for dozens of processes to not accumulate.

I shouldn't have to rewrite applications, or even have to investigate how
they function in order to run them.  For the most part, ssh is excellent
about this.  Every once in a while though...and of course, that's the
problem.  Nothing worse than intermittent failures.

--Dan




From Nicolas.Williams at ubsw.com  Tue Dec 11 06:17:14 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 14:17:14 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <005901c181ae$0410b160$1701000a@effugas>; from dan@doxpara.com on Mon, Dec 10, 2001 at 11:08:13AM -0800
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <003a01c181ab$7c0779e0$1701000a@effugas> <20011210140210.B1177@sm2p1386swk.wdr.com> <005901c181ae$0410b160$1701000a@effugas>
Message-ID: <20011210141713.L973@sm2p1386swk.wdr.com>

Sorry, Unix systems just work this way you know? RSH hangs the same
way if the remote command keeps stdio open. I learned to use rsh with
stdio redirection to /dev/null long before SSH became the norm.

So what's the problem then?

This topic and these arguments seem to be re-tread, over and over.

I'd like to see a client-side option to have the client end the primary
session as soon as the remote command is launched, with an optional
timer. But in the meantime, I know how to redirect stdio. And the
agent/x11/port forwarding hang bug supposedly is fixed (I can't test it
yet), so I'm pretty happy(*).

(*) I'd like a patch that applies cleanly to 2.9p2 for the
agent/x11/port forwarding hang bug. The one I found on the list does
not, in fact, apply.

Cheers,

Nico


On Mon, Dec 10, 2001 at 11:08:13AM -0800, Dan Kaminsky wrote:
> > Hey, I have the same problem to deal with. I deal with it. I always put
> > in explicit stdio redirections to/from /dev/null. What's wrong with that?
> 
> ssh is a general purpose method of running remote commands as if they were
> locally.  Not "specially written remote commands", not "custom apps".  Just
> remote commands.
> 
> That's what it inherited from rsh, and though I perhaps use this
> functionality a bit more...strenuously...then others, I think I have a
> reasonable expectation for dozens of processes to not accumulate.
> 
> I shouldn't have to rewrite applications, or even have to investigate how
> they function in order to run them.  For the most part, ssh is excellent
> about this.  Every once in a while though...and of course, that's the
> problem.  Nothing worse than intermittent failures.
> 
> --Dan
> 
--
-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  Tue Dec 11 06:32:07 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 11 Dec 2001 06:32:07 +1100 (EST)
Subject: [Bug 23] The Protocol configuration option in sshd_config fails to work properly.
Message-ID: <20011210193207.8A2E92DF7F@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=23

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com



------- Additional Comments From stevesk at pobox.com  2001-12-11 06:32 -------
reproduce the problem with that client and provide sshd -d -d -d output.



------- 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 Dec 11 06:31:47 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 13:31:47 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <200112101820.KAA32192@ns2.bizsystems.net>
Message-ID: <Pine.BSO.4.33.0112101329240.26173-100000@etoh.eviladmin.org>

[..]
> And, ..... yes I have followed and read the entire thread about this.
> What I fail to understand is why all the dithering. Data might be
> lost, but the client has said "GO AWAY" and obviously does not want
> any more data.
>
> Michael
> Michael at Insulin-Pumpers.org
>

Mike,

Let me borrow a line from Theo...

		"Show me code"

To which I'll add..

		"That is acceptable Markus, Damien, and myself that
works on EVERY platform, does not break/bend SSH protocol, works for v1
and v2 protocols, and is not a utter fucking hack."


Until such time.. this is just a waste of everyone's time.  Whining (no
matter how much it makes you feel better) does not improve code.

- Ben



From vsync at quadium.net  Tue Dec 11 06:36:43 2001
From: vsync at quadium.net (vsync)
Date: 10 Dec 2001 12:36:43 -0700
Subject: Time delay security function
In-Reply-To: <3C14F9A1.9020706@psimation.com>
References: <3C14F9A1.9020706@psimation.com>
Message-ID: <87ofl6uat0.fsf@feynman.hurstdog.org>

"P.Agenbag" <internet at psimation.com> writes:

> When one enters the system root password for the first time, what if
> one could capture the time between keystrokes as well, and store the
> time between strokes on the host system only. This way, even if
> someone tries to run combinations against a password, it would be
> impossible for the cracker to "simulate" the time between two specific
> characters of the password as the time between two strokes is not sent
> with the password string but measured by the host machine as it
> receives each character. So, this is also the first "glitch" in the

1 word: lag.

-- 
vsync
http://quadium.net/
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
      (cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))


From markus at openbsd.org  Tue Dec 11 07:05:22 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:05:22 +0100
Subject: pubkey auth with NFS home on AIX
Message-ID: <20011210210522.A13748@folly>

can someone confirm this:

http://bugzilla.mindrot.org/show_bug.cgi?id=29

Authentication refused: realpath /home/user/.ssh/authorized_keys failed: The file access permissions do not allow the specified action.


From markus at openbsd.org  Tue Dec 11 07:11:13 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:11:13 +0100
Subject: X11 on Mac OS X: ssh forwarding (fwd)
Message-ID: <20011210211113.A16548@faui02>

has this been fixed?
-------------- next part --------------
An embedded message was scrubbed...
From: Markus Friedl <msfriedl>
Subject: X11 on Mac OS X: ssh forwarding
Date: Mon, 10 Dec 2001 21:10:45 +0100 (MET)
Size: 3058
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011210/c1a3b835/attachment.mht 

From markus at openbsd.org  Tue Dec 11 07:15:13 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:15:13 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112101800.KAA32031@ns2.bizsystems.net>; from michael@bizsystems.com on Mon, Dec 10, 2001 at 10:00:44AM -0800
References: <200112080420.UAA17468@ns2.bizsystems.net>; <20011209143504.B8904@folly> <200112101800.KAA32031@ns2.bizsystems.net>
Message-ID: <20011210211513.B22844@folly>

On Mon, Dec 10, 2001 at 10:00:44AM -0800, Michael wrote:
> > On Fri, Dec 07, 2001 at 08:20:55PM -0800, Michael wrote:
> > > so what about connections that are made from a script??
> > 
> > the so-called bug is only related to sessions with ptys.
> > 
> > you don't use ptys with scripts, so there is no problems
> > for scripts.
> > 
> 
> That's not true. Example:
> 
> on the target host running openssh sshd daemon
> 
> #!/usr/bin/perl
> while(1) {
>   sleep 1;
> }
> # end
> 
> on the client, with no password required
> 
> #!/bin/sh
> /usr/localbin/ssh targethost "/usr/bin/perl tstprog.pl &"
> # end
> 
> the script hangs and never returns because sshd will not close its 
> connection to the client. Seems whenever STDOUT or STDERR may return 
> info, sshd will not detach as other programs such as telnet, rsh, 
> ssh-1.2x, etc.. are happy to do.

rsh does not always, it might do on some systems, but that is IMHO
incorrect behaviour.

use
	$ rsh targethost -n "/usr/bin/perl tstprog.pl >/dev/null 2>&1 &"
or
	$ ssh targethost -n "/usr/bin/perl tstprog.pl >/dev/null 2>&1 &"

-m


From markus at openbsd.org  Tue Dec 11 07:16:20 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:16:20 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112101710.JAA31549@ns2.bizsystems.net>; from michael@bizsystems.com on Mon, Dec 10, 2001 at 09:10:08AM -0800
References: <200112072218.OAA15873@ns2.bizsystems.net>; <20011209143406.A8904@folly> <200112101710.JAA31549@ns2.bizsystems.net>
Message-ID: <20011210211620.C22844@folly>

On Mon, Dec 10, 2001 at 09:10:08AM -0800, Michael wrote:
> > On Fri, Dec 07, 2001 at 02:18:10PM -0800, Michael wrote:
> > > Has this issue been resolved in 3.02 ??
> > 
> > no bugreport, no fix.  no bug, no fix.
> > 
> 
> so try this, guaranteed to hang the exit of the session for 
> openssh, but ssh-1.2.27 likes it fine.
> 
> file tst.pl
> #!/usr/bin/perl
> 
> while (1) {
>   sleep 1;
> }
> 
> # end
> 
> at the keyboard, just type
> 
> > perl tst.pl &
> > exit
> 
> 
> Like I said, ssh-1.2.27 works fine

ssh-1.2.27 loses data. this has been changed in later
versions, e.g ssh-1.2.32.

> OpenSSH_2.9.9p2 is guaranteed to hang
> 
> This means that a daemon can never be stopped and restarted from the 
> keyboard without a hang or screwing around with special exit 
> procedures. Looks, sounds, smells like a bug to me.

it works unless the daemon is broken.

-m


From markus at openbsd.org  Tue Dec 11 07:17:45 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:17:45 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112101740.JAA31827@ns2.bizsystems.net>; from michael@bizsystems.com on Mon, Dec 10, 2001 at 09:40:22AM -0800
References: <200112101710.JAA31549@ns2.bizsystems.net> <Pine.BSO.4.33.0112101117040.26173-100000@etoh.eviladmin.org> <200112101740.JAA31827@ns2.bizsystems.net>
Message-ID: <20011210211745.D22844@folly>

On Mon, Dec 10, 2001 at 09:40:22AM -0800, Michael wrote:
> If John's fix 
> works for Linux and does so without data loss, then perhaps it should 
> be included and compiled in by configuration option for those OS's 
> where it is known to solve the problem.

it cannot be included because it introduces bugs.

-m


From markus at openbsd.org  Tue Dec 11 07:19:13 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:19:13 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <20011210125744.A1177@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Mon, Dec 10, 2001 at 12:57:45PM -0500
References: <200112101710.JAA31549@ns2.bizsystems.net> <Pine.BSO.4.33.0112101117040.26173-100000@etoh.eviladmin.org> <200112101740.JAA31827@ns2.bizsystems.net> <20011210125744.A1177@sm2p1386swk.wdr.com>
Message-ID: <20011210211913.E22844@folly>

On Mon, Dec 10, 2001 at 12:57:45PM -0500, Nicolas Williams wrote:
>  - with and without ptys it would be nice to have a client-side option
>    to have the client close the main session as soon as possible (launch
>    and forget).

use < > 2&>1 and devnull for this.


From roth+openssh at feep.net  Tue Dec 11 07:19:31 2001
From: roth+openssh at feep.net (Mark D. Roth)
Date: Mon, 10 Dec 2001 14:19:31 -0600
Subject: pubkey auth with NFS home on AIX
In-Reply-To: <20011210210522.A13748@folly>; from markus@openbsd.org on Mon, Dec 10, 2001 at 09:05:22PM +0100
References: <20011210210522.A13748@folly>
Message-ID: <20011210141931.A21959@yorktown.isdn.uiuc.edu>

On Mon Dec 10 21:05 2001 +0100, Markus Friedl wrote:
> can someone confirm this:
> 
> http://bugzilla.mindrot.org/show_bug.cgi?id=29
> 
> Authentication refused: realpath /home/user/.ssh/authorized_keys failed: The file access permissions do not allow the specified action.

I haven't had time to look into this, but I started seeing it when I
upgraded from 2.9p2 to 2.9.9p2.  I haven't had time to check 3.x yet,
so I don't know if it's still broken...

-- 
Mark D. Roth <roth at feep.net>
http://www.feep.net/~roth/


From markus at openbsd.org  Tue Dec 11 07:20:33 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:20:33 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112101820.KAA32192@ns2.bizsystems.net>; from michael@bizsystems.com on Mon, Dec 10, 2001 at 10:20:46AM -0800
References: <200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <200112101820.KAA32192@ns2.bizsystems.net>
Message-ID: <20011210212033.F22844@folly>

On Mon, Dec 10, 2001 at 10:20:46AM -0800, Michael wrote:
> Sure, I know it's not a proper daemon. The point is, it is 
> representative of what people do everyday when writing 
> script programs.

buggy scripts do not mean we should add yet more bugs to sshd.


From markus at openbsd.org  Tue Dec 11 07:28:03 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:28:03 +0100
Subject: pubkey auth with NFS home on AIX
In-Reply-To: <20011210141931.A21959@yorktown.isdn.uiuc.edu>
References: <20011210210522.A13748@folly> <20011210141931.A21959@yorktown.isdn.uiuc.edu>
Message-ID: <20011210212803.B16548@faui02>

On Mon, Dec 10, 2001 at 02:19:31PM -0600, Mark D. Roth wrote:
> On Mon Dec 10 21:05 2001 +0100, Markus Friedl wrote:
> > can someone confirm this:
> > 
> > http://bugzilla.mindrot.org/show_bug.cgi?id=29
> > 
> > Authentication refused: realpath /home/user/.ssh/authorized_keys failed: The file access permissions do not allow the specified action.
> 
> I haven't had time to look into this, but I started seeing it when I
> upgraded from 2.9p2 to 2.9.9p2.  I haven't had time to check 3.x yet,
> so I don't know if it's still broken...

well sshd switches uid/groups to the user before calling realpath(). 

-m


From markus at openbsd.org  Tue Dec 11 07:28:35 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 10 Dec 2001 21:28:35 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <003a01c181ab$7c0779e0$1701000a@effugas>; from dan@doxpara.com on Mon, Dec 10, 2001 at 10:50:06AM -0800
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <003a01c181ab$7c0779e0$1701000a@effugas>
Message-ID: <20011210212835.G22844@folly>

On Mon, Dec 10, 2001 at 10:50:06AM -0800, Dan Kaminsky wrote:
> Look: ssh user at host "command" needs to never, ever hang.

wrong.

it needs to hang.

it needs to hang until it can be sure that 'command' does not need
any input.

it needs to hang until it can be sure that 'command' does not produce
any output.

it needs to hang until 'command' exits because sshd needs to tell
the exit status from 'command' to ssh.

	$ ssh -n host 'exec > /dev/null 2>&1; sleep 3; exit 5' 
	$ echo $?

and so on.


From mouring at etoh.eviladmin.org  Tue Dec 11 07:30:07 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 14:30:07 -0600 (CST)
Subject: X11 on Mac OS X: ssh forwarding (fwd)
In-Reply-To: <20011210211113.A16548@faui02>
Message-ID: <Pine.BSO.4.33.0112101427560.17618-100000@etoh.eviladmin.org>


Doubt it.  This looks like the same issue one has when NeXTStep
attempts to do X11 stuff.

And I did not get to fixing it before I was forced out my my appartment.

But I think if Steve continues down his X11 update path it may be a moot
point.

- Ben

On Mon, 10 Dec 2001, Markus Friedl wrote:

> has this been fixed?
>



From Nicolas.Williams at ubsw.com  Tue Dec 11 07:37:14 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 15:37:14 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011210211913.E22844@folly>; from markus@openbsd.org on Mon, Dec 10, 2001 at 09:19:13PM +0100
References: <200112101710.JAA31549@ns2.bizsystems.net> <Pine.BSO.4.33.0112101117040.26173-100000@etoh.eviladmin.org> <200112101740.JAA31827@ns2.bizsystems.net> <20011210125744.A1177@sm2p1386swk.wdr.com> <20011210211913.E22844@folly>
Message-ID: <20011210153712.C1177@sm2p1386swk.wdr.com>

On Mon, Dec 10, 2001 at 09:19:13PM +0100, Markus Friedl wrote:
> On Mon, Dec 10, 2001 at 12:57:45PM -0500, Nicolas Williams wrote:
> >  - with and without ptys it would be nice to have a client-side option
> >    to have the client close the main session as soon as possible (launch
> >    and forget).
> 
> use < > 2&>1 and devnull for this.

I do. I'm not complaining. Don't get me wrong. :)

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 Nicolas.Williams at ubsw.com  Tue Dec 11 07:57:23 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 15:57:23 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011210212835.G22844@folly>; from markus@openbsd.org on Mon, Dec 10, 2001 at 09:28:35PM +0100
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <003a01c181ab$7c0779e0$1701000a@effugas> <20011210212835.G22844@folly>
Message-ID: <20011210155722.D1177@sm2p1386swk.wdr.com>

Markus,

This should be an FAQ on the OpenSSH site... :)

It keeps being brought up.

Nico


On Mon, Dec 10, 2001 at 09:28:35PM +0100, Markus Friedl wrote:
> On Mon, Dec 10, 2001 at 10:50:06AM -0800, Dan Kaminsky wrote:
> > Look: ssh user at host "command" needs to never, ever hang.
> 
> wrong.
> 
> it needs to hang.
> 
> it needs to hang until it can be sure that 'command' does not need
> any input.
> 
> it needs to hang until it can be sure that 'command' does not produce
> any output.
> 
> it needs to hang until 'command' exits because sshd needs to tell
> the exit status from 'command' to ssh.
> 
> 	$ ssh -n host 'exec > /dev/null 2>&1; sleep 3; exit 5' 
> 	$ echo $?
> 
> and so on.
--
-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 michael at bizsystems.com  Tue Dec 11 08:22:43 2001
From: michael at bizsystems.com (Michael)
Date: Mon, 10 Dec 2001 13:22:43 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011210212835.G22844@folly>
References: <003a01c181ab$7c0779e0$1701000a@effugas>; from dan@doxpara.com on Mon, Dec 10, 2001 at 10:50:06AM -0800
Message-ID: <200112102122.NAA00783@ns2.bizsystems.net>

> On Mon, Dec 10, 2001 at 10:50:06AM -0800, Dan Kaminsky wrote:
> > Look: ssh user at host "command" needs to never, ever hang.
> 
> wrong.
> 
> it needs to hang.
> 
> it needs to hang until it can be sure that 'command' does not need
> any input.
> 
> it needs to hang until it can be sure that 'command' does not
> produce any output.
> 
> it needs to hang until 'command' exits because sshd needs to tell
> the exit status from 'command' to ssh.
> 

So from a sysadmin's view point, some fool writes a piece of buggy 
software which hundreds of shell users decide to use and they then 
proceed to connect to the host via ssh and leave hundreds of "hung" 
sshd's in the process table, or even just one user with a cron job 
doing a repeated action. That sounds just great. Why on earth should 
anyone use openssh if they can expect it to mess up the operation of 
an entire system because it is BROKEN. This is a problem that will 
not go away. You can assert that script writers should do a better 
job, but they won't and that is why they write scripts.

Your response requesting me to write the code is something I can't 
do. I only have access to Linux boxes and have no clue (and would not 
presume to know) what the implications are for sun, aix, hp, 
bsd, etc... Closing off discussion on the issue won't fix it either. 
I don't mean to be a pest, but I consider openssh to be an excellent 
tool that does a lot to promote security in general and security at 
our site in particular. I'd like to see it work well. It seems to 
have one glaring flaw this one glaring flaw that needs to be fixed to 
make it generally acceptable as a replacement for virtually all other 
remote shell access programs. Saying that rsh is broken also simply 
doesnt' justify why a program under active development by a very 
bright group of people has to be broken also.

Michael
Michael at Insulin-Pumpers.org


From mouring at etoh.eviladmin.org  Tue Dec 11 09:02:52 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 16:02:52 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <200112102122.NAA00783@ns2.bizsystems.net>
Message-ID: <Pine.BSO.4.33.0112101537250.17618-100000@etoh.eviladmin.org>



On Mon, 10 Dec 2001, Michael wrote:
[..]
> Your response requesting me to write the code is something I can't
> do. I only have access to Linux boxes and have no clue (and would not
> presume to know) what the implications are for sun, aix, hp,
> bsd, etc... Closing off discussion on the issue won't fix it either.
> I don't mean to be a pest, but I consider openssh to be an excellent
> tool that does a lot to promote security in general and security at
> our site in particular. I'd like to see it work well. It seems to
> have one glaring flaw this one glaring flaw that needs to be fixed to
> make it generally acceptable as a replacement for virtually all other
> remote shell access programs. Saying that rsh is broken also simply
> doesnt' justify why a program under active development by a very
> bright group of people has to be broken also.
>

First off, it was my response.  Not Markus'.

Second off, this is part of the problem.  We have *SOO* many (excuse my
language) fucking people whining about a bug in the portable release, but
no one willing to lend us a hand on solving the bug instead of covering
it up.

I am a very mellow person, but this is just starting to bug the living
shit out of me.  If for no other reason than I can't see a clear path to
fix this bug.

Which I guess is true for most of the portable team.  We have problems
that we can solve now.  And so I'm sure most of us have left this problem
on a backburner because we don't know the correct bug fix.  What we don't
want is another 'scp' gotcha 8 months later which requires us to dig far
enough back to figure out what patch may have triggered it.

So, no we are not leaving this because "We want to piss the crap out of
people."  Or ignoring that real issues exist.  We have pratical advice
to help work around, but we DO NOT WANT another bandaid that fixes the
symptoms leaving the bug to fester and pop up in another way (gawd, that
is what I'd expect to see Linus say, not me  <sigh>).

And like most I'm tired of arguing anything that is not a potental
solution.  Which is why this current thread is worthless as it provides no
TECHNICAL information that is USEFUL to any of us developers.

So don't take this wrong, but having the same topic came up every 2 months
with no addition new information information is as worthless as crying
wolves in a pack of wild dogs when no one has a shotgun.  =) We already
know they exists.

- Ben



From rachit at ensim.com  Tue Dec 11 09:09:20 2001
From: rachit at ensim.com (Rachit Siamwalla)
Date: Mon, 10 Dec 2001 14:09:20 -0800
Subject: hang on exit bug under Linux
Message-ID: <9AC41B8C4781464695BB013F106FCA3102900DD0@nasdaq.ms.ensim.com>

>From what I understand, the problem is due to people's disagreement about what the "correct" behavior should be. I'm pretty sure that the following is the correct behavior from running rsh and ssh often (both fsecure and openssh).

Lets say you have a stupid script that does

while 1
do
   sleep 1
done

Called foreverSleep on your remote host:

rsh remotehost "foreverSleep &"

Should and does hang (on Linux and Solaris at least).

HOWEVER,

rsh remotehost
# foreverSleep &
# exit

does NOT hang.

---

If you run openssh, like the following:

ssh remotehost "foreverSleep &"

Should and does hang (fsecure hangs as well).

HOWEVER,

ssh remotehost
# foreverSleep &
# exit

DOES hang. (fsecure does not hang) This is where the bug is. If you run ssh with a tty and in interactive mode, if the client decides to disconnect, it disconnects cleanly (I'm not sure about what happens to the remaining processes, you will have to look at rsh code for that -- it may be SIGHUP or something, i dunno -- other posts may be clearer on this).

I hope I'm not just stating the obvious, and hope this clears things up. If I'm wrong about the behaviours, let me know. I really think we should figure out what the correct behaviour should be before trying to come up with a fix.

-rchit

-----Original Message-----
From: Michael [mailto:michael at bizsystems.com]
Sent: Monday, December 10, 2001 1:23 PM
To: openssh-unix-dev at mindrot.org
Subject: Re: hang on exit bug under Linux


> On Mon, Dec 10, 2001 at 10:50:06AM -0800, Dan Kaminsky wrote:
> > Look: ssh user at host "command" needs to never, ever hang.
> 
> wrong.
> 
> it needs to hang.
> 
> it needs to hang until it can be sure that 'command' does not need
> any input.
> 
> it needs to hang until it can be sure that 'command' does not
> produce any output.
> 
> it needs to hang until 'command' exits because sshd needs to tell
> the exit status from 'command' to ssh.
> 

So from a sysadmin's view point, some fool writes a piece of buggy 
software which hundreds of shell users decide to use and they then 
proceed to connect to the host via ssh and leave hundreds of "hung" 
sshd's in the process table, or even just one user with a cron job 
doing a repeated action. That sounds just great. Why on earth should 
anyone use openssh if they can expect it to mess up the operation of 
an entire system because it is BROKEN. This is a problem that will 
not go away. You can assert that script writers should do a better 
job, but they won't and that is why they write scripts.

Your response requesting me to write the code is something I can't 
do. I only have access to Linux boxes and have no clue (and would not 
presume to know) what the implications are for sun, aix, hp, 
bsd, etc... Closing off discussion on the issue won't fix it either. 
I don't mean to be a pest, but I consider openssh to be an excellent 
tool that does a lot to promote security in general and security at 
our site in particular. I'd like to see it work well. It seems to 
have one glaring flaw this one glaring flaw that needs to be fixed to 
make it generally acceptable as a replacement for virtually all other 
remote shell access programs. Saying that rsh is broken also simply 
doesnt' justify why a program under active development by a very 
bright group of people has to be broken also.

Michael
Michael at Insulin-Pumpers.org


From gert at greenie.muc.de  Tue Dec 11 09:18:53 2001
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 10 Dec 2001 23:18:53 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <9AC41B8C4781464695BB013F106FCA3102900DD0@nasdaq.ms.ensim.com>; from Rachit Siamwalla on Mon, Dec 10, 2001 at 02:09:20PM -0800
References: <9AC41B8C4781464695BB013F106FCA3102900DD0@nasdaq.ms.ensim.com>
Message-ID: <20011210231853.E12395@greenie.muc.de>

Hi,

On Mon, Dec 10, 2001 at 02:09:20PM -0800, Rachit Siamwalla wrote:
> Called foreverSleep on your remote host:
> 
> rsh remotehost "foreverSleep &"
> 
> Should and does hang (on Linux and Solaris at least).
> 
> HOWEVER,
> 
> rsh remotehost
> # foreverSleep &
> # exit
> 
> does NOT hang.

This is what I have already suggested:

 - if we have a pty, and the direct child goes away "just close the
   session", and accept data loss.   Data loss can only come from
   background processes, who are *background* processes and shouldn't 
   send stuff anyway - if they do, they deserve a SIGPIPE or worse.

 - if we have no pty, do what we do now, and block if needed.

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 ed at UDel.Edu  Tue Dec 11 09:19:09 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 10 Dec 2001 17:19:09 -0500 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.BSO.4.33.0112101329240.26173-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0112101712450.2560-100000@mahler.udel.edu>

On Mon, 10 Dec 2001 mouring at etoh.eviladmin.org wrote:

> Date: Mon, 10 Dec 2001 13:31:47 -0600 (CST)
> From: mouring at etoh.eviladmin.org
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: hang on exit bug under Linux
>
> [..]
> > And, ..... yes I have followed and read the entire thread about this.
> > What I fail to understand is why all the dithering. Data might be
> > lost, but the client has said "GO AWAY" and obviously does not want
> > any more data.
> >
> > Michael
> > Michael at Insulin-Pumpers.org
> >
>
> Mike,
>
> Let me borrow a line from Theo...
>
> 		"Show me code"
>
> To which I'll add..
>
> 		"That is acceptable Markus, Damien, and myself that
> works on EVERY platform, does not break/bend SSH protocol, works for v1
> and v2 protocols, and is not a utter fucking hack."
>

Is this mailing list for code submissions only?  I got the impression when
I joined this list that here is where problems should be reported - and
that here is really the "only" place to report.  So, is it useless for
anyone to make suggestions about something that needs fixing without
submitting code?  Is there another list where people can submit problem
report so that other (well-versed in the OpenSSH code) people will make
fixes?

	Ed

Ed Phillips <ed at udel.edu> 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  Tue Dec 11 09:19:19 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 16:19:19 -0600 (CST)
Subject: -c none option
In-Reply-To: <Pine.LNX.4.41.0112101334500.10314-100000@catbert.rellim.com>
Message-ID: <Pine.BSO.4.33.0112101612520.17618-100000@etoh.eviladmin.org>



On Mon, 10 Dec 2001, Gary E. Miller wrote:

> Yo Ben!
>
> M$ distributes a special version of their Remote Desktop Cient (RDP,
> formerly TSC) without encryption just for the French market.  Some
> French oriented distributor could do the same for OpenSSH.
>
Not to be cold heart, but my reply:

	"Great, that French company can add in -c none to all their
versions, and strip out all encryption.  It's BSD licensed so they can do
what they will with it."

Besides, last I checked OpenSSH was not money driven.  I doubt
Theo is making a few million a month off of OpenSSH.  If he is I
think he needs to cut the rest of the crew in for a few bread crums
(unless working for him is our payment <grin>).

> If I was managing any equipment in France I would think auth only
> SSH was a big step up from telnet.
>
> What France had done with their crypto regs is wrong, but they will
> not change just because of us, so we must adapt as best we can.
>

The point being that by just having -c none does not make 'ssh' magicly
legal in france.

That is kinda like telling a cop in the US.. "I just bought the bong for
decoration!  Honest!  I don't even smoke that stuff!" =)  It would go over
like a lead brick.

- Ben



From ed at UDel.Edu  Tue Dec 11 09:28:16 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 10 Dec 2001 17:28:16 -0500 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <20011210212835.G22844@folly>
Message-ID: <Pine.SOL.4.30.0112101726340.2560-100000@mahler.udel.edu>

On Mon, 10 Dec 2001, Markus Friedl wrote:

> Date: Mon, 10 Dec 2001 21:28:35 +0100
> From: Markus Friedl <markus at openbsd.org>
> To: Dan Kaminsky <dan at doxpara.com>
> Cc: Bob Proulx <bob at proulx.com>, michael at bizsystems.com,
>      openssh-unix-dev at mindrot.org
> Subject: Re: hang on exit bug under Linux
>
> On Mon, Dec 10, 2001 at 10:50:06AM -0800, Dan Kaminsky wrote:
> > Look: ssh user at host "command" needs to never, ever hang.
>
> wrong.
>
> it needs to hang.
>
> it needs to hang until it can be sure that 'command' does not need
> any input.
>
> it needs to hang until it can be sure that 'command' does not produce
> any output.
>
> it needs to hang until 'command' exits because sshd needs to tell
> the exit status from 'command' to ssh.
>
> 	$ ssh -n host 'exec > /dev/null 2>&1; sleep 3; exit 5'
> 	$ echo $?
>
> and so on.

I think he means that "ssh ..." should never hang after the command on the
server side has exited.  Certainly, I think we all expect the behaviour
you describe above.

	Ed

Ed Phillips <ed at udel.edu> 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 ed at UDel.Edu  Tue Dec 11 09:41:11 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 10 Dec 2001 17:41:11 -0500 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.BSO.4.33.0112101537250.17618-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0112101735370.2560-100000@mahler.udel.edu>

On Mon, 10 Dec 2001 mouring at etoh.eviladmin.org wrote:

> Second off, this is part of the problem.  We have *SOO* many (excuse my
> language) fucking people whining about a bug in the portable release, but
> no one willing to lend us a hand on solving the bug instead of covering
> it up.

It might be a lot better for everyone if we just try to say "Hey, we
know... we could use some help solving this confirmed problem.", instead
of all the screaming... ;-)  The average user that submits a problem to
this list has no idea of the number of actual real "coders" that can
actually devote serious time to improving and fixing bugs in OpenSSH, so
they probably don't know what to expect in terms of "support" - so they
guess too high.

	Ed

Ed Phillips <ed at udel.edu> 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 yamaneko at centurytel.net  Tue Dec 11 10:23:23 2001
From: yamaneko at centurytel.net (Sam Vaughan)
Date: Mon, 10 Dec 2001 15:23:23 -0800 (PST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.SOL.4.30.0112101735370.2560-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0112101516450.10366-100000@localhost.localdomain>


Is there a list, or a way to get a list, of current known bugs or 
TODO's? Maybe also if someone is actively working on them?  
 
  





From mouring at etoh.eviladmin.org  Tue Dec 11 10:24:43 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 10 Dec 2001 17:24:43 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.LNX.4.33.0112101516450.10366-100000@localhost.localdomain>
Message-ID: <Pine.BSO.4.33.0112101724081.17618-100000@etoh.eviladmin.org>


There is the 'TODO' file in the distro which has long standing
issues that are being looked at.  Or there is the new
bugzilla.mindrot.org web bug tracking.

- Ben

On Mon, 10 Dec 2001, Sam Vaughan wrote:

>
> Is there a list, or a way to get a list, of current known bugs or
> TODO's? Maybe also if someone is actively working on them?
>
>
>
>
>
>



From yamaneko at centurytel.net  Tue Dec 11 10:41:54 2001
From: yamaneko at centurytel.net (Sam Vaughan)
Date: Mon, 10 Dec 2001 15:41:54 -0800 (PST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.BSO.4.33.0112101724081.17618-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.33.0112101538470.10439-100000@localhost.localdomain>



Thanks! 

On Mon, 10 Dec 2001 mouring at etoh.eviladmin.org wrote:

> 
> There is the 'TODO' file in the distro which has long standing
> issues that are being looked at.  Or there is the new
> bugzilla.mindrot.org web bug tracking.
> 
> - Ben
> 
> On Mon, 10 Dec 2001, Sam Vaughan wrote:
> 
> >
> > Is there a list, or a way to get a list, of current known bugs or
> > TODO's? Maybe also if someone is actively working on them?
> >
> >
> >
> >
> >
> >
> 
> 

-- 
Sam Vaughan
Systems Engineer / Programmer
svaughan at asterion.com
Home-Office 360.297.8913
Cell 360.471.3052



From gem at rellim.com  Tue Dec 11 08:57:54 2001
From: gem at rellim.com (Gary E. Miller)
Date: Mon, 10 Dec 2001 13:57:54 -0800 (PST)
Subject: -c none option
In-Reply-To: <Pine.BSO.4.33.0112082343470.28085-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.41.0112101334500.10314-100000@catbert.rellim.com>

Yo Ben!

M$ distributes a special version of their Remote Desktop Cient (RDP,
formerly TSC) without encryption just for the French market.  Some
French oriented distributor could do the same for OpenSSH.

If I was managing any equipment in France I would think auth only
SSH was a big step up from telnet.

What France had done with their crypto regs is wrong, but they will
not change just because of us, so we must adapt as best we can.

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, 8 Dec 2001 mouring at etoh.eviladmin.org wrote:

> This sems like a bullshit reason to add -c none. In those countries the
> POSESSION  of ssh even if you don't use the higher encryptions is illegal.



From stevesk at pobox.com  Tue Dec 11 12:24:44 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Mon, 10 Dec 2001 17:24:44 -0800 (PST)
Subject: -c none option
In-Reply-To: <Pine.LNX.4.41.0112101334500.10314-100000@catbert.rellim.com>
Message-ID: <Pine.HPX.4.42.0112101706060.7655-100000@jenny>

On Mon, 10 Dec 2001, Gary E. Miller wrote:
:M$ distributes a special version of their Remote Desktop Cient (RDP,
:formerly TSC) without encryption just for the French market.  Some
:French oriented distributor could do the same for OpenSSH.

microsoft has different goals than we do, as well as different finances,
etc.

http://www.openbsd.org/goals.html

:If I was managing any equipment in France I would think auth only
:SSH was a big step up from telnet.

see goals.html:

     "We want to make available source
     code that anyone can use for ANY PURPOSE, with no restrictions. We
     strive to make our software robust and secure, and encourage companies to
     use whichever pieces they want to."

:What France had done with their crypto regs is wrong, but they will
:not change just because of us, so we must adapt as best we can.

no, see goals.html:

     "Be as politics-free as possible; solutions should be decided on the basis
     of technical merit."



From djm at mindrot.org  Tue Dec 11 12:37:43 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 12:37:43 +1100 (EST)
Subject: -c none option
In-Reply-To: <20011209145046.E18440@folly>
Message-ID: <Pine.LNX.4.33.0112111236340.18366-100000@mothra.mindrot.org>

On Sun, 9 Dec 2001, Markus Friedl wrote:

> On Fri, Dec 07, 2001 at 03:05:21PM -0800, Dan Kaminsky wrote:
> >     I've actually been getting steadily more concerned with SSH's
> > performance.  FTP runs at about 3MB/s, standard SCP at 1MB/s, and SFTP at
> > 100KB/s(!!!).
> 
> this can be improved by fixing the sftp client. just go for it.

To be more specific, the sftp client does a round-trip for each block 
of data from the server. It should be fixed to:

1. Read the largest possible blocks at a time
2. Do some readahead, i.e keep at least one request pending at all times

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From djm at mindrot.org  Tue Dec 11 12:40:21 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 12:40:21 +1100 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <003a01c181ab$7c0779e0$1701000a@effugas>
Message-ID: <Pine.LNX.4.33.0112111239410.18366-100000@mothra.mindrot.org>

On Mon, 10 Dec 2001, Dan Kaminsky wrote:

> Look: ssh user at host "command" needs to never, ever hang.  It needs to not
> leave processes running, it needs to not break scripts, it needs to simply
> be "this command, as if it was run locally, only it's really somewhere else.
> And if I'd be staring at a prompt somewhere else, damnit, I need to be
> staring at a prompt here."

ssh user at host command must never, ever loose data.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From dan at doxpara.com  Tue Dec 11 12:44:19 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 10 Dec 2001 17:44:19 -0800
Subject: -c none option
References: <Pine.BSO.4.33.0112101612520.17618-100000@etoh.eviladmin.org>
Message-ID: <014601c181e5$59dca1d0$1701000a@effugas>

> That is kinda like telling a cop in the US.. "I just bought the bong for
> decoration!  Honest!  I don't even smoke that stuff!" =)  It would go over
> like a lead brick.

Actually, ssh is in my mind the single best method for remote invocation of
commands, as well as TCP tunneling, encryption or not.  It is cross
platform, stable as hell, and well-authenticated.  It is probably the single
cleanest method of getting a remote shell with all terminal weirdness
handled.  Even if I had an ipsec-authenticated link to a remote site, I'd
*still* use SSH for alot of my work.

That being said ... debugging isn't a compelling enough reason for -c none
to exist by default, and except for gigabit links -c arcfour is going to be
fast enough.  Whatever performance problems SSH is having, I doubt it's
because of the crypto.  So I'm pretty much convinced there shouldn't be a -c
none option by default, and I wasn't before.

But what about as a compile-time option, i.e. ./configure --with-null-crypto
?  It's the worst tendancy of Microsoft to make an absolute policy statement
for the "benefit" of the user, despite substantial minority interest in the
contrary.  If the code for this were to drop on your doorstep, what then?

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com




From djm at mindrot.org  Tue Dec 11 12:47:38 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 12:47:38 +1100 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.SOL.4.30.0112101712450.2560-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0112111244000.18366-100000@mothra.mindrot.org>

On Mon, 10 Dec 2001, Ed Phillips wrote:

> Is this mailing list for code submissions only?  I got the impression when
> I joined this list that here is where problems should be reported - and
> that here is really the "only" place to report.  So, is it useless for
> anyone to make suggestions about something that needs fixing without
> submitting code?

openssh-unix-dev sure *isn't* a place to go over the same damn 
(hang on exit, -c none) ground over and over.

The time for complaining about the "hang on exit" passed six months
ago - everyone knows about it and has stated their positions. We know
how to recreate it at whim and we have tried just about all non-horrid
ways of fixing it.

As we have said (over and over), if people really want to fix the problem
they would be well advised to determine why it only appears on some OSs.
e.g. OpenBSD doesn't have the problem. What aspect of kernel fd semantics
allows OpenBSD to avoid the problem?

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From djm at mindrot.org  Tue Dec 11 12:49:04 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 12:49:04 +1100 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.LNX.4.33.0112101516450.10366-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.33.0112111248310.18366-100000@mothra.mindrot.org>

On Mon, 10 Dec 2001, Sam Vaughan wrote:

> 
> Is there a list, or a way to get a list, of current known bugs or 
> TODO's? Maybe also if someone is actively working on them?  

bugzilla.mindrot.org should be the place, would be the place if more
people use it.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From djm at mindrot.org  Tue Dec 11 12:50:59 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 12:50:59 +1100 (EST)
Subject: -c none option
In-Reply-To: <Pine.LNX.4.41.0112101334500.10314-100000@catbert.rellim.com>
Message-ID: <Pine.LNX.4.33.0112111249140.18366-100000@mothra.mindrot.org>

On Mon, 10 Dec 2001, Gary E. Miller wrote:

> Yo Ben!
> 
> M$ distributes a special version of their Remote Desktop Cient (RDP,
> formerly TSC) without encryption just for the French market.  Some
> French oriented distributor could do the same for OpenSSH.
> 
> If I was managing any equipment in France I would think auth only
> SSH was a big step up from telnet.

I thought France repealed the no-crypto law? The CLS[1] says this has been
the case since 1999.

-d

[1] http://cwis.kub.nl/~frw/people/koops/cls2.htm#fr

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From djm at mindrot.org  Tue Dec 11 12:52:51 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 12:52:51 +1100 (EST)
Subject: -c none option
In-Reply-To: <014601c181e5$59dca1d0$1701000a@effugas>
Message-ID: <Pine.LNX.4.33.0112111251430.18366-100000@mothra.mindrot.org>

On Mon, 10 Dec 2001, Dan Kaminsky wrote:

> But what about as a compile-time option, i.e. ./configure --with-null-crypto
> ?  It's the worst tendancy of Microsoft to make an absolute policy statement
> for the "benefit" of the user, despite substantial minority interest in the
> contrary.  If the code for this were to drop on your doorstep, what then?

Options are bad, except for compile time options which are worse.

I don't want -c none in portable, and I don't think Markus wants it in 
OpenBSD (though he can speak for himself).

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From gem at rellim.com  Tue Dec 11 14:09:09 2001
From: gem at rellim.com (Gary E. Miller)
Date: Mon, 10 Dec 2001 19:09:09 -0800 (PST)
Subject: -c none option
In-Reply-To: <Pine.LNX.4.33.0112111249140.18366-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.41.0112101825580.10314-100000@catbert.rellim.com>

Yo Damien!

Yes, France did significantly loosen their crypto law.  There is
still a lot of older software still in France that does not
support string crypto.  This issue comes up weekly in the
rdesktop mailing list...

If you look further in the URL you gave, you will notice several
countries that still ban encryption under certain circumstances.

Austria:
The Betriebsfunkverordnung forbids encryption in internal company and
organisation radio transmissions.

Belarus:
Cryptography use by business people is restricted.


Burma (Myanmar)
Cryptography is said to be restricted through a licensing regime.

People's Republic of China
By State Council Order No. 273, "Commercial Use Password Management
Regulations", published on 15 October 1999 and in effect since 7 October
1999, domestic crypto manufacture and use is severely restricted.

Russia
On 3 April 1995, president Yeltsin issued a decree prohibiting
unauthorized encryption.


Personnally, I would never use a "-c none" option.  I'm just pointing
out that there exist a class of people for which that is their only
option.

It is up to you to decide whether to reach out to this group or not.

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 Tue, 11 Dec 2001, Damien Miller wrote:

> On Mon, 10 Dec 2001, Gary E. Miller wrote:
>
> > M$ distributes a special version of their Remote Desktop Cient (RDP,
> > formerly TSC) without encryption just for the French market.  Some
> > French oriented distributor could do the same for OpenSSH.
> >
> > If I was managing any equipment in France I would think auth only
> > SSH was a big step up from telnet.
>
> I thought France repealed the no-crypto law? The CLS[1] says this has been
> the case since 1999.
>
> -d
>
> [1] http://cwis.kub.nl/~frw/people/koops/cls2.htm#fr



From vinschen at redhat.com  Tue Dec 11 10:45:13 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 11 Dec 2001 00:45:13 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.SOL.4.30.0112101735370.2560-100000@mahler.udel.edu>; from ed@UDel.Edu on Mon, Dec 10, 2001 at 05:41:11PM -0500
References: <Pine.BSO.4.33.0112101537250.17618-100000@etoh.eviladmin.org> <Pine.SOL.4.30.0112101735370.2560-100000@mahler.udel.edu>
Message-ID: <20011211004513.O740@cygbert.vinschen.de>

On Mon, Dec 10, 2001 at 05:41:11PM -0500, Ed Phillips wrote:
> On Mon, 10 Dec 2001 mouring at etoh.eviladmin.org wrote:
> 
> > Second off, this is part of the problem.  We have *SOO* many (excuse my
> > language) fucking people whining about a bug in the portable release, but
> > no one willing to lend us a hand on solving the bug instead of covering
> > it up.
> 
> It might be a lot better for everyone if we just try to say "Hey, we
> know... we could use some help solving this confirmed problem.", instead
> of all the screaming... ;-)  The average user that submits a problem to
> this list has no idea of the number of actual real "coders" that can
> actually devote serious time to improving and fixing bugs in OpenSSH, so

Hmmm, maybe I got that wrong but the name of this list is

	openssh-unix-dev
	             ===

so _I_ was under the impression that this is not a user forum
but a developers forum.  Personally I would expect that people
bugged by a problem and subscribed to this list would actually
try to solve the problem by putting their own hands on it.

As I said, I might be wrong, but that's what I'd expect from
a developer list.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From roth+openssh at feep.net  Tue Dec 11 15:15:19 2001
From: roth+openssh at feep.net (Mark D. Roth)
Date: Mon, 10 Dec 2001 22:15:19 -0600
Subject: pubkey auth with NFS home on AIX
In-Reply-To: <20011210212803.B16548@faui02>; from markus@openbsd.org on Mon, Dec 10, 2001 at 09:28:03PM +0100
References: <20011210210522.A13748@folly> <20011210141931.A21959@yorktown.isdn.uiuc.edu> <20011210212803.B16548@faui02>
Message-ID: <20011210221519.A22621@yorktown.isdn.uiuc.edu>

On Mon Dec 10 21:28 2001 +0100, Markus Friedl wrote:
> On Mon, Dec 10, 2001 at 02:19:31PM -0600, Mark D. Roth wrote:
> > On Mon Dec 10 21:05 2001 +0100, Markus Friedl wrote:
> > > can someone confirm this:
> > > 
> > > http://bugzilla.mindrot.org/show_bug.cgi?id=29
> > > 
> > > Authentication refused: realpath /home/user/.ssh/authorized_keys failed: The file access permissions do not allow the specified action.
> > 
> > I haven't had time to look into this, but I started seeing it when I
> > upgraded from 2.9p2 to 2.9.9p2.  I haven't had time to check 3.x yet,
> > so I don't know if it's still broken...
> 
> well sshd switches uid/groups to the user before calling realpath(). 

Nevertheless, it is still happening.  I just verified it with 3.0.1p1.

-- 
Mark D. Roth <roth at feep.net>
http://www.feep.net/~roth/


From lstein at cshl.org  Tue Dec 11 15:13:04 2001
From: lstein at cshl.org (Lincoln Stein)
Date: Mon, 10 Dec 2001 23:13:04 -0500
Subject: Patch to allow gatewaying of remote forwarded ports
In-Reply-To: <01120911512102.16161@fontina>
References: <20011208045536.D6C572DF3C@shitei.mindrot.org> <20011209144229.A18440@folly> <01120911512102.16161@fontina>
Message-ID: <01121023130400.18821@fontina>

Enclosed is a re-revised patch that includes documentation changes!  Please 
ignore the two previous patches.  I hope this is it.

Lincoln

On Sunday 09 December 2001 11:51, Lincoln Stein wrote:
> Enclosed is a revised patch which respects the server policy with respect
> to GatewayPorts.
>
> Lincoln
>
> On Sunday 09 December 2001 08:42, Markus Friedl wrote:
> > On Sat, Dec 08, 2001 at 12:03:45AM -0500, Lincoln Stein wrote:
> > > Enclosed is a patch against the "portable" OpenSSH version 3.02p1.  It
> > > enables the -g switch when applied to -R (remote) forwardings.  This
> > > allows remote hosts to connect to forwarded ports on the sshd host.
> >
> > + gateway_ports = (strncmp(listen_address,"0.0.0.0",7) == 0) ||
> > options.gateway_ports;
> >
> > this would violate the policy of the server.
> >
> > if the sshd_config says: gatewayports==no, then the
> > socket should be bound to 127.0.0.1 only, regardless
> > of what the client wants.
> >
> > 	gateway_ports = options.gateway_ports &&
> > 	    (strncmp(listen_address,"0.0.0.0",7) == 0);
> >
> > would be correct.

----------------------------------------
Content-Type: text/x-c; charset="iso-8859-1"; 
name="openssh-3.0.2p1-gateway.patch"
Content-Transfer-Encoding: base64
Content-Description: 
----------------------------------------

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY

NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. 
PLEASE WRITE FOR DETAILS.
========================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-3.0.2p1-gateway.patch
Type: text/x-c
Size: 4766 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011210/f840ce0a/attachment.bin 

From Nicolas.Williams at ubsw.com  Tue Dec 11 15:15:56 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 23:15:56 -0500
Subject: -c none option
In-Reply-To: <Pine.BSO.4.33.0112101612520.17618-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Mon, Dec 10, 2001 at 04:19:19PM -0600
References: <Pine.LNX.4.41.0112101334500.10314-100000@catbert.rellim.com> <Pine.BSO.4.33.0112101612520.17618-100000@etoh.eviladmin.org>
Message-ID: <20011210231556.A3807@wdr.com>

On Mon, Dec 10, 2001 at 04:19:19PM -0600, mouring at etoh.eviladmin.org wrote:

[...]

> The point being that by just having -c none does not make 'ssh' magicly
> legal in france.

You'd be surprised how foolish politicians can be. They want to have
secure networks, secure e-commerce, but no encryption. Ok, so the same
algorythms and code are needed for both, but if you don't give the
option to encrypt, just to have cryptographically-strong authentication,
hey, all must be ok, right? Wrong. But that is how some folk think and
that's all there's to it.

> That is kinda like telling a cop in the US.. "I just bought the bong for
> decoration!  Honest!  I don't even smoke that stuff!" =)  It would go over
> like a lead brick.

Well, drug paraphernalia is often legal in many States for the simple
reason that it much of it cna be used with legal products like tobacco.

> - Ben


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 Nicolas.Williams at ubsw.com  Tue Dec 11 15:20:14 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 10 Dec 2001 23:20:14 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <9AC41B8C4781464695BB013F106FCA3102900DD0@nasdaq.ms.ensim.com>; from Rachit Siamwalla on Mon, Dec 10, 2001 at 02:09:20PM -0800
References: <9AC41B8C4781464695BB013F106FCA3102900DD0@nasdaq.ms.ensim.com>
Message-ID: <20011210232014.B3807@wdr.com>

On Mon, Dec 10, 2001 at 02:09:20PM -0800, Rachit Siamwalla wrote:
> >From what I understand, the problem is due to people's disagreement about what the "correct" behavior should be. I'm pretty sure that the following is the correct behavior from running rsh and ssh often (both fsecure and openssh).

Some people don't get stdio. Hey.

> Called foreverSleep on your remote host:
> 
> rsh remotehost "foreverSleep &"
> 
> Should and does hang (on Linux and Solaris at least).
> 
> HOWEVER,
> 
> rsh remotehost
> # foreverSleep &
> # exit
> 
> does NOT hang.

It should do a killpg() to send SIGHUP to the relevant processes. What
if they don't want to die? Huh?

> ---
> 
> If you run openssh, like the following:
> 
> ssh remotehost "foreverSleep &"
> 
> Should and does hang (fsecure hangs as well).
> 
> HOWEVER,
> 
> ssh remotehost
> # foreverSleep &
> # exit
> 
> DOES hang. (fsecure does not hang) This is where the bug is. If you run ssh with a tty and in interactive mode, if the client decides to disconnect, it disconnects cleanly (I'm not sure about what happens to the remaining processes, you will have to look at rsh code for that -- it may be SIGHUP or something, i dunno -- other posts may be clearer on this).

What if "foreverSleep" needs a forwarded agent/port/x11? Huh? What if it
doesn't exit if sshd sends it SIGHUP when you exit?

I say: with ptys, send SIGHUP when the main process exits and/or when
the client closes the session.

Perhaps there should be an option like -n for the client but which
applies to stdout and stderr for the faint of heart who refuse to
understand '>' and '2>' and '2>&1' and so on.

> I hope I'm not just stating the obvious, and hope this clears things up. If I'm wrong about the behaviours, let me know. I really think we should figure out what the correct behaviour should be before trying to come up with a fix.
> 
> -rchit


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 djm at mindrot.org  Tue Dec 11 16:53:14 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Dec 2001 16:53:14 +1100 (EST)
Subject: Bug#66740: ssh-askpass-gnome: The first password is always bad
 (was: OpenSSH 3.0)
In-Reply-To: <87pu5pch3q.fsf_-_@thanatar.east.bacchus.com>
Message-ID: <Pine.LNX.4.33.0112111649370.20647-100000@mothra.mindrot.org>

On 8 Dec 2001, Charles C. Fu wrote:

>    Background: Many Debian users have reported a problem to Debian
>    with ssh-askpass-gnome always rejecting the first passphrase.
>    <URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=66740&repeatmerged=yes>
>    shows the thread for one of these reports.

Please report future portable OpenSSH bugs at http://bugzilla.mindrot.org/ - 
it makes them easier to track.

Could you try this patch?

Index: readpass.c
===================================================================
RCS file: /var/cvs/openssh/readpass.c,v
retrieving revision 1.21
diff -u -r1.21 readpass.c
--- readpass.c	2001/11/12 00:05:21	1.21
+++ readpass.c	2001/12/11 05:47:26
@@ -46,7 +46,7 @@
 	pid_t pid;
 	size_t len;
 	char *pass;
-	int p[2], status;
+	int p[2], status, ret;
 	char buf[1024];
 
 	if (fflush(stdout) != 0)
@@ -71,14 +71,23 @@
 		fatal("ssh_askpass: exec(%s): %s", askpass, strerror(errno));
 	}
 	close(p[1]);
-	len = read(p[0], buf, sizeof buf -1);
+
+	len = ret = 0;
+	do {
+		ret = read(p[0], buf + len, sizeof(buf) - 1 - len);
+		if (ret == -1 && errno == EINTR)
+			continue;
+		if (ret <= 0)
+			break;
+		len += ret;
+	} while (sizeof(buf) - 1 - len > 0);
+	buf[len] = '\0';
+
 	close(p[0]);
 	while (waitpid(pid, &status, 0) < 0)
 		if (errno != EINTR)
 			break;
-	if (len <= 1)
-		return xstrdup("");
-	buf[len] = '\0';
+
 	buf[strcspn(buf, "\r\n")] = '\0';
 	pass = xstrdup(buf);
 	memset(buf, 0, sizeof(buf));

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From markus at openbsd.org  Tue Dec 11 19:35:22 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 11 Dec 2001 09:35:22 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.SOL.4.30.0112101726340.2560-100000@mahler.udel.edu>
References: <20011210212835.G22844@folly> <Pine.SOL.4.30.0112101726340.2560-100000@mahler.udel.edu>
Message-ID: <20011211093522.A21093@faui02>

On Mon, Dec 10, 2001 at 05:28:16PM -0500, Ed Phillips wrote:
> I think he means that "ssh ..." should never hang after the command on the
> server side has exited.  Certainly, I think we all expect the behaviour
> you describe above.

sigh, we had this before.

you cannot close the channel after the command exits, you have
to wait till all data from the dead process has been processed.

i won't comment on these issue, unless someone provides non-broken patches.


From gert at greenie.muc.de  Tue Dec 11 21:53:42 2001
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 11 Dec 2001 11:53:42 +0100
Subject: -c none option
In-Reply-To: <Pine.LNX.4.33.0112111249140.18366-100000@mothra.mindrot.org>; from Damien Miller on Tue, Dec 11, 2001 at 12:50:59PM +1100
References: <Pine.LNX.4.41.0112101334500.10314-100000@catbert.rellim.com> <Pine.LNX.4.33.0112111249140.18366-100000@mothra.mindrot.org>
Message-ID: <20011211115342.G12395@greenie.muc.de>

hi,

On Tue, Dec 11, 2001 at 12:50:59PM +1100, Damien Miller wrote:
> > If I was managing any equipment in France I would think auth only
> > SSH was a big step up from telnet.
> 
> I thought France repealed the no-crypto law? The CLS[1] says this has been
> the case since 1999.

That's what I remember as well.  A 180 degree turn from "crypto is evil
and has to be licensed!" to "hey, everybody use crypto, otherwise those
outlanders will spy on us!".

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert.doering at physik.tu-muenchen.de


From markus at openbsd.org  Wed Dec 12 00:06:09 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 11 Dec 2001 14:06:09 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.SOL.4.30.0112101712450.2560-100000@mahler.udel.edu>; from ed@UDel.Edu on Mon, Dec 10, 2001 at 05:19:09PM -0500
References: <Pine.BSO.4.33.0112101329240.26173-100000@etoh.eviladmin.org> <Pine.SOL.4.30.0112101712450.2560-100000@mahler.udel.edu>
Message-ID: <20011211140609.B5866@folly>

On Mon, Dec 10, 2001 at 05:19:09PM -0500, Ed Phillips wrote:
> Is this mailing list for code submissions only?  I got the impression when
> I joined this list that here is where problems should be reported - and
> that here is really the "only" place to report.

bugzilla should be used for bugreports. otherwise reports will be
lost in the noise. the mailing list should be used for signals,
usenet could be used for noise instead.


From markus at openbsd.org  Wed Dec 12 00:08:16 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 11 Dec 2001 14:08:16 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <20011210141713.L973@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Mon, Dec 10, 2001 at 02:17:14PM -0500
References: <200112072218.OAA15873@ns2.bizsystems.net><20011209143406.A8904@folly><200112101710.JAA31549@ns2.bizsystems.net> <200112101757.fBAHvX919960@torment.proulx.com> <003a01c181ab$7c0779e0$1701000a@effugas> <20011210140210.B1177@sm2p1386swk.wdr.com> <005901c181ae$0410b160$1701000a@effugas> <20011210141713.L973@sm2p1386swk.wdr.com>
Message-ID: <20011211140816.C5866@folly>

On Mon, Dec 10, 2001 at 02:17:14PM -0500, Nicolas Williams wrote:
> (*) I'd like a patch that applies cleanly to 2.9p2 for the
> agent/x11/port forwarding hang bug. The one I found on the list does
> not, in fact, apply.

it's a very simple patch. just port all the uses
	c->force_drain;
back to 2.9p2.


From markus at openbsd.org  Wed Dec 12 00:12:07 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 11 Dec 2001 14:12:07 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112102122.NAA00783@ns2.bizsystems.net>; from michael@bizsystems.com on Mon, Dec 10, 2001 at 01:22:43PM -0800
References: <003a01c181ab$7c0779e0$1701000a@effugas>; <20011210212835.G22844@folly> <200112102122.NAA00783@ns2.bizsystems.net>
Message-ID: <20011211141207.D5866@folly>

On Mon, Dec 10, 2001 at 01:22:43PM -0800, Michael wrote:
> So from a sysadmin's view point, some fool writes a piece of buggy 

from a developers point of view you cannot everybody happy.


From Nicolas.Williams at ubsw.com  Wed Dec 12 00:12:32 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 11 Dec 2001 08:12:32 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011211093522.A21093@faui02>; from Markus Friedl on Tue, Dec 11, 2001 at 09:35:22AM +0100
References: <20011210212835.G22844@folly> <Pine.SOL.4.30.0112101726340.2560-100000@mahler.udel.edu> <20011211093522.A21093@faui02>
Message-ID: <20011211081232.C3807@wdr.com>

On Tue, Dec 11, 2001 at 09:35:22AM +0100, Markus Friedl wrote:
> sigh, we had this before.
> 
> you cannot close the channel after the command exits, you have
> to wait till all data from the dead process has been processed.
> 
> i won't comment on these issue, unless someone provides non-broken patches.

There's nothing really to fix, so why wait for patches?

Actually, now I'm convinced that even having the sshd send SIGHUP to the
process group when the session leader exits might not be correct.

Is it possible to have the client, upon reception of the session exit
message, choose to send SIGHUP to the session (meaning the process
group) and/or force the channels closed? Is this at all possible in the
SSHv2 protocol?

If so then that could be a client side option. That would shut up most
folk.

But definitely you guys need an FAQ...

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 markus at openbsd.org  Wed Dec 12 00:16:56 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 11 Dec 2001 14:16:56 +0100
Subject: -c none option
In-Reply-To: <014601c181e5$59dca1d0$1701000a@effugas>; from dan@doxpara.com on Mon, Dec 10, 2001 at 05:44:19PM -0800
References: <Pine.BSO.4.33.0112101612520.17618-100000@etoh.eviladmin.org> <014601c181e5$59dca1d0$1701000a@effugas>
Message-ID: <20011211141656.E5866@folly>

On Mon, Dec 10, 2001 at 05:44:19PM -0800, Dan Kaminsky wrote:
> Whatever performance problems SSH is having, I doubt it's
> because of the crypto.

did you try build openssh with profiling enabled?


From markus at openbsd.org  Wed Dec 12 00:19:22 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 11 Dec 2001 14:19:22 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <20011211081232.C3807@wdr.com>
References: <20011210212835.G22844@folly> <Pine.SOL.4.30.0112101726340.2560-100000@mahler.udel.edu> <20011211093522.A21093@faui02> <20011211081232.C3807@wdr.com>
Message-ID: <20011211141921.A16973@faui02>

On Tue, Dec 11, 2001 at 08:12:32AM -0500, Nicolas Williams wrote:
> Actually, now I'm convinced that even having the sshd send SIGHUP to the
> process group when the session leader exits might not be correct.
> 
> Is it possible to have the client, upon reception of the session exit
> message, choose to send SIGHUP to the session (meaning the process
> group) and/or force the channels closed? Is this at all possible in the
> SSHv2 protocol?

i sent a patch for signal passing. nobody did comment.

i sent a patch for SIGHUP, and got one single comment.

so i guess, nobody cares.

-m


From djast at cs.toronto.edu  Wed Dec 12 02:20:09 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 11 Dec 2001 10:20:09 -0500
Subject: hang on exit bug under Linux 
In-Reply-To: Your message of "Mon, 10 Dec 2001 23:20:14 EST."
             <20011210232014.B3807@wdr.com> 
Message-ID: <01Dec11.102017edt.453139-10740@jane.cs.toronto.edu>

On Mon, 10 Dec 2001 23:20:14 EST, Nicolas Williams writes:
> 
> I say: with ptys, send SIGHUP when the main process exits and/or when
> the client closes the session.

Would setting the HUPCL termios cflag for the pty a) work, b) be
portable, and c) be more appropriate than killpg()?

-- 
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 mouring at etoh.eviladmin.org  Wed Dec 12 02:23:49 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 11 Dec 2001 09:23:49 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <20011211141921.A16973@faui02>
Message-ID: <Pine.BSO.4.33.0112110921490.5670-100000@etoh.eviladmin.org>



On Tue, 11 Dec 2001, Markus Friedl wrote:

> On Tue, Dec 11, 2001 at 08:12:32AM -0500, Nicolas Williams wrote:
> > Actually, now I'm convinced that even having the sshd send SIGHUP to the
> > process group when the session leader exits might not be correct.
> >
> > Is it possible to have the client, upon reception of the session exit
> > message, choose to send SIGHUP to the session (meaning the process
> > group) and/or force the channels closed? Is this at all possible in the
> > SSHv2 protocol?
>
> i sent a patch for signal passing. nobody did comment.
>
I would like to see that patch go in, but without actually running it
and testing it.  I really did not want to comment on it.  Same is true
about SIGHUP.

However, there are more people than me on this list that are in far better
positions for testing (for at least the next month or two).  So it is very
sad that no one had bothered to comment on it.

 - Ben



From Nicolas.Williams at ubsw.com  Wed Dec 12 02:49:36 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 11 Dec 2001 10:49:36 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011211141921.A16973@faui02>; from Markus Friedl on Tue, Dec 11, 2001 at 02:19:22PM +0100
References: <20011210212835.G22844@folly> <Pine.SOL.4.30.0112101726340.2560-100000@mahler.udel.edu> <20011211093522.A21093@faui02> <20011211081232.C3807@wdr.com> <20011211141921.A16973@faui02>
Message-ID: <20011211104936.E3807@wdr.com>

On Tue, Dec 11, 2001 at 02:19:22PM +0100, Markus Friedl wrote:
> On Tue, Dec 11, 2001 at 08:12:32AM -0500, Nicolas Williams wrote:
> > Actually, now I'm convinced that even having the sshd send SIGHUP to the
> > process group when the session leader exits might not be correct.
> > 
> > Is it possible to have the client, upon reception of the session exit
> > message, choose to send SIGHUP to the session (meaning the process
> > group) and/or force the channels closed? Is this at all possible in the
> > SSHv2 protocol?
> 
> i sent a patch for signal passing. nobody did comment.
> 
> i sent a patch for SIGHUP, and got one single comment.
> 
> so i guess, nobody cares.

I'm commenting now.

The signal passing patch seems to be for passing signals received by
the ssh client. But I'm talking about the ssh client passing a SIGHUP
upon getting a session exit message from sshd. Is it possible to pass a
signal to that session that just exited at that point? The semantics
would be to killpg() the process group of the session in question - but
the session has exited, ergo there's a chicken-and-the-egg problem and
I'm not familiar enough with the protocol to know if it's even doable.

The killpg() patch, on second thought, is probably not good, on the
grounds that it should be the client that decides such things. You have
succeeded in convincing me of this :) which is why I'm suggesting that
the client have an option for passing SIGHUP to sessions as they exit
and/or close their channels as the sessions exit. E.g.,

hostA% ssh -o nohang hostB
hostB% sleep 150 &
hostB% exit
<ssh passes SIGHUP, closes channels for session, unused forwarded
 agent/x11, sshd exits>
hostA% 

Without -o nohang the behaviour would be as now.

> -m


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 udo.schweigert at siemens.com  Wed Dec 12 04:22:21 2001
From: udo.schweigert at siemens.com (Udo Schweigert)
Date: Tue, 11 Dec 2001 18:22:21 +0100
Subject: Patch for ReliantUnix
Message-ID: <20011211172221.GA41065@alaska.cert.siemens.de>

Hi all,

attached you find a patch for OpenSSH 3.0.2p1 configure which enables OpenSSH
to again compile under ReliantUnix (due to utimes it is again needed to
include /usr/ucblib/libucb.a)

Sorry for not testing it before the release ;-(

Best regards

--
Udo Schweigert, Siemens AG   | Voice      : +49 89 636 42170
CT IC 3, Siemens CERT        | Fax        : +49 89 636 41166
D-81730 Muenchen / Germany   | email      : udo.schweigert at siemens.com
-------------- next part --------------
--- configure.ac.orig	Sat Nov  3 20:09:33 2001
+++ configure.ac	Tue Dec 11 17:38:26 2001
@@ -187,13 +187,12 @@
 	;;
 *-sni-sysv*)
 	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	# /usr/ucblib MUST NOT be searched on ReliantUNIX
 	LDFLAGS="$LDFLAGS -L/usr/local/lib"
+	LIBS="$LIBS /usr/ucblib/libucb.a"
 	IPADDR_IN_DISPLAY=yes
 	AC_DEFINE(USE_PIPES)
 	AC_DEFINE(IP_TOS_IS_BROKEN)
 	AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H)
-	# /usr/ucblib/libucb.a no longer needed on ReliantUNIX
 	# Attention: always take care to bind libsocket and libnsl before libc,
 	# otherwise you will find lots of "SIOCGPGRP errno 22" on syslog
 	;;
--- configure.orig	Sun Dec  2 00:38:55 2001
+++ configure	Tue Dec 11 08:29:06 2001
@@ -3732,8 +3732,8 @@
 	;;
 *-sni-sysv*)
 	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	# /usr/ucblib MUST NOT be searched on ReliantUNIX
 	LDFLAGS="$LDFLAGS -L/usr/local/lib"
+	LIBS="$LIBS /usr/ucblib/libucb.a"
 	IPADDR_IN_DISPLAY=yes
 	cat >>confdefs.h <<\_ACEOF
 #define USE_PIPES 1
@@ -3747,7 +3747,6 @@
 #define HAVE_BOGUS_SYS_QUEUE_H 1
 _ACEOF
 
-	# /usr/ucblib/libucb.a no longer needed on ReliantUNIX
 	# Attention: always take care to bind libsocket and libnsl before libc,
 	# otherwise you will find lots of "SIOCGPGRP errno 22" on syslog
 	;;

From mouring at etoh.eviladmin.org  Wed Dec 12 04:34:37 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 11 Dec 2001 11:34:37 -0600 (CST)
Subject: Patch for ReliantUnix
In-Reply-To: <20011211172221.GA41065@alaska.cert.siemens.de>
Message-ID: <Pine.BSO.4.33.0112111133030.5670-100000@etoh.eviladmin.org>


I don't see why we need to include libucb.a  utimes() is defined in
openbsd-compat/misc.c  unless for some odd reason the ./configure script
is misdetecting it.  In which case it should be corrected and
not adding ucb library back into the mix.

- Ben

On Tue, 11 Dec 2001, Udo Schweigert wrote:

> Hi all,
>
> attached you find a patch for OpenSSH 3.0.2p1 configure which enables OpenSSH
> to again compile under ReliantUnix (due to utimes it is again needed to
> include /usr/ucblib/libucb.a)
>
> Sorry for not testing it before the release ;-(
>
> Best regards
>
> --
> Udo Schweigert, Siemens AG   | Voice      : +49 89 636 42170
> CT IC 3, Siemens CERT        | Fax        : +49 89 636 41166
> D-81730 Muenchen / Germany   | email      : udo.schweigert at siemens.com
>



From bugzilla-daemon at mindrot.org  Wed Dec 12 06:06:32 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 12 Dec 2001 06:06:32 +1100 (EST)
Subject: [Bug 17] Build fails on Solaris 2.5.1 - vsnprintf does not exist
Message-ID: <20011211190632.C2D632DF0E@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=17

Darren.Moffat at Sun.COM changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From Darren.Moffat at Sun.COM  2001-12-12 06:06 -------
The vsnprintf is a red herring, note that the error message comes from
ld.so.1 when loading the acomp program.  What this is saying is that
acomp actually calls vsnprintf but ld.so.1 couldn't resolve that symbol.

Since the Forte Developer 6 update 1 acomp was compiled and linked on
Solaris 2.6, it won't run on Solaris 2.5.1.

Forte Developer 6 (WS6) dropped Solaris 2.5.1 support; so did
Forte Developer 6 update 1 (WS6U1) and Forte Developer 6 update 2 (WS6U2).

So if you want to compile on Solaris 2.5.1 you need to use an older
compiler.

So this isn't a bug in OpenSSH.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From jesus at omniti.com  Wed Dec 12 06:46:19 2001
From: jesus at omniti.com (Theo Schlossnagle)
Date: Tue, 11 Dec 2001 14:46:19 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <005901c181ae$0410b160$1701000a@effugas>
Message-ID: <BF391256-EE6F-11D5-AEE6-00039358205C@omniti.com>

On Monday, December 10, 2001, at 02:08  PM, Dan Kaminsky wrote:
>> Hey, I have the same problem to deal with. I deal with it. I always put
>> in explicit stdio redirections to/from /dev/null. What's wrong with 
>> that?
>
> ssh is a general purpose method of running remote commands as if they 
> were
> locally.  Not "specially written remote commands", not "custom apps".  
> Just
> remote commands.

This is the point everyone is making.  If run a poorly written daemon 
"locally", it can spit error messages at me twenty minutes later.  It 
didn't close its file descriptors.  Now, consider computers for what 
they are... trusting.  It wasn't poorly written, it was _intentionally_ 
written that way because I _want_ to see those error messages (say I am 
not smart enough to close file descriptors and use syslog) -- this is 
what the OS assumes.

You want them to run just as if they were run locally.  Find. ssh 
_should_ linger (it doesn't _hang_) and wait for the program to spit 
anything out if it will.  There is no excuse for not working around the 
problem.  Simply write a daemonizing wrapper program that fork()s and 
setsid() before it runs your command and be sure to direct you file 
descriptors somewhere other than std*.

> I shouldn't have to rewrite applications, or even have to investigate 
> how
> they function in order to run them.  For the most part, ssh is excellent
> about this.  Every once in a while though...and of course, that's the
> problem.  Nothing worse than intermittent failures.

I have application I wrote that forks and expects to write to stdout, 
ssh _better_ "hang"!  That is its job.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7



From jesus at omniti.com  Wed Dec 12 06:51:14 2001
From: jesus at omniti.com (Theo Schlossnagle)
Date: Tue, 11 Dec 2001 14:51:14 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.LNX.4.33.0112111239410.18366-100000@mothra.mindrot.org>
Message-ID: <6ED73BD8-EE70-11D5-AEE6-00039358205C@omniti.com>

On Monday, December 10, 2001, at 08:40  PM, Damien Miller wrote:
> On Mon, 10 Dec 2001, Dan Kaminsky wrote:
>> Look: ssh user at host "command" needs to never, ever hang.  It needs to 
>> not
>> leave processes running, it needs to not break scripts, it needs to 
>> simply
>> be "this command, as if it was run locally, only it's really somewhere 
>> else.
>> And if I'd be staring at a prompt somewhere else, damnit, I need to be
>> staring at a prompt here."
>
> ssh user at host command must never, ever loose data.

I agree 100%.  Thank you for putting it so concisely.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7



From roth+openssh at feep.net  Wed Dec 12 07:01:33 2001
From: roth+openssh at feep.net (Mark D. Roth)
Date: Tue, 11 Dec 2001 14:01:33 -0600
Subject: pubkey auth with NFS home on AIX
In-Reply-To: <20011210212803.B16548@faui02>; from markus@openbsd.org on Mon, Dec 10, 2001 at 09:28:03PM +0100
References: <20011210210522.A13748@folly> <20011210141931.A21959@yorktown.isdn.uiuc.edu> <20011210212803.B16548@faui02>
Message-ID: <20011211140133.A23719@yorktown.isdn.uiuc.edu>

On Mon Dec 10 21:28 2001 +0100, Markus Friedl wrote:
> On Mon, Dec 10, 2001 at 02:19:31PM -0600, Mark D. Roth wrote:
> > On Mon Dec 10 21:05 2001 +0100, Markus Friedl wrote:
> > > can someone confirm this:
> > > 
> > > http://bugzilla.mindrot.org/show_bug.cgi?id=29
> > > 
> > > Authentication refused: realpath /home/user/.ssh/authorized_keys failed: The file access permissions do not allow the specified action.
> > 
> > I haven't had time to look into this, but I started seeing it when I
> > upgraded from 2.9p2 to 2.9.9p2.  I haven't had time to check 3.x yet,
> > so I don't know if it's still broken...
> 
> well sshd switches uid/groups to the user before calling realpath(). 

I just dug a little deeper, and it looks like AIX is using the real
uid instead of the effective uid to determine NFS access.  sshd is
only changing the effective uid, presumably since it needs to reclaim
root privileges, but that's enough to cause the NFS problem.

Unfortunately, the only way I can think of to address this problem is
to fork a child process which can change its real uid to do the
realpath() check and report its findings back to the parent.  This is
a particularly inelegant (and inefficient) solution, so I'm hoping
someone else can think of something better...

-- 
Mark D. Roth <roth at feep.net>
http://www.feep.net/~roth/


From roth+openssh at feep.net  Wed Dec 12 08:29:13 2001
From: roth+openssh at feep.net (Mark D. Roth)
Date: Tue, 11 Dec 2001 15:29:13 -0600
Subject: pubkey auth with NFS home on AIX
In-Reply-To: <01Dec11.151444edt.453139-10740@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Dec 11, 2001 at 03:14:40PM -0500
References: <20011211140133.A23719@yorktown.isdn.uiuc.edu> <01Dec11.151444edt.453139-10740@jane.cs.toronto.edu>
Message-ID: <20011211152913.A23806@yorktown.isdn.uiuc.edu>

On Tue Dec 11 15:14 2001 -0500, Dan Astoorian wrote:
> You say the problem was introduced between 2.9 and 2.9.9: the realpath()
> behaviour in auth.c is relatively new.  Do you know whether AIX provides
> a realpath() function, or whether OpenSSH is using
> openbsd-compat/realpath.c?

AIX does indeed have realpath(), and the configure script is detecting
it normally.


> If AIX's realpath() is being used, can you try compiling with the
> openbsd-compat/ version and see if it makes a difference?  If so, this
> may be a workaround; otherwise, perhaps you can at least find out
> exactly what operation is causing the failure.

Good idea.  I tried this, and it works fine!  The problem must be
being caused by something in the AIX version.

Now the question is what to do about it.  It's hard to test for this
problem, since not every machine has an NFS-mounted filesystem, and
the configure script will probably not be run as root anyway.  I
really hate that ``case "$host" in'' block in configure.ac, but I
don't see any alternative...  Anyone see something I'm missing?

-- 
Mark D. Roth <roth at feep.net>
http://www.feep.net/~roth/


From djm at mindrot.org  Wed Dec 12 09:18:05 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 12 Dec 2001 09:18:05 +1100 (EST)
Subject: hang on exit bug under Linux 
In-Reply-To: <01Dec11.102017edt.453139-10740@jane.cs.toronto.edu>
Message-ID: <Pine.LNX.4.33.0112120917490.3348-100000@mothra.mindrot.org>

On Tue, 11 Dec 2001, Dan Astoorian wrote:

> On Mon, 10 Dec 2001 23:20:14 EST, Nicolas Williams writes:
> > 
> > I say: with ptys, send SIGHUP when the main process exits and/or when
> > the client closes the session.
> 
> Would setting the HUPCL termios cflag for the pty a) work, b) be
> portable, and c) be more appropriate than killpg()?

What about sessions without a pty?

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From Nicolas.Williams at ubsw.com  Wed Dec 12 09:28:20 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 11 Dec 2001 17:28:20 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.LNX.4.33.0112120917490.3348-100000@mothra.mindrot.org>; from Damien Miller on Wed, Dec 12, 2001 at 09:18:05AM +1100
References: <01Dec11.102017edt.453139-10740@jane.cs.toronto.edu> <Pine.LNX.4.33.0112120917490.3348-100000@mothra.mindrot.org>
Message-ID: <20011211172820.A15087@wdr.com>

On Wed, Dec 12, 2001 at 09:18:05AM +1100, Damien Miller wrote:
> On Tue, 11 Dec 2001, Dan Astoorian wrote:
> 
> > On Mon, 10 Dec 2001 23:20:14 EST, Nicolas Williams writes:
> > > 
> > > I say: with ptys, send SIGHUP when the main process exits and/or when
> > > the client closes the session.
> > 
> > Would setting the HUPCL termios cflag for the pty a) work, b) be
> > portable, and c) be more appropriate than killpg()?
> 
> What about sessions without a pty?

They should always "hang", or, rather, "hang around."

In any case, I no longer think that sshd should do killpg(HUP) when the
session leader exits, nor, for that matter, should it set the HUPCL
termios cflag for the pty.

Instead I think the client should have an option to, when the sshd
tells it the session exited, close the related channels and/or pass a
SIGHUP to the session which the sshd would then send to the process
group of the session leader.

> -d
> 


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 michael at bizsystems.com  Wed Dec 12 10:13:01 2001
From: michael at bizsystems.com (Michael)
Date: Tue, 11 Dec 2001 15:13:01 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011210232014.B3807@wdr.com>
References: <9AC41B8C4781464695BB013F106FCA3102900DD0@nasdaq.ms.ensim.com>; from Rachit Siamwalla on Mon, Dec 10, 2001 at 02:09:20PM -0800
Message-ID: <200112112313.PAA09496@ns2.bizsystems.net>

> > If you run openssh, like the following:
> > 
> > ssh remotehost "foreverSleep &"
> > 
> > Should and does hang (fsecure hangs as well).
> > 
> > HOWEVER,
> > 
> > ssh remotehost
> > # foreverSleep &
> > # exit
> > 
> > DOES hang. (fsecure does not hang) This is where the bug is. If you run ssh with a tty and in interactive mode, if the client decides to disconnect, it disconnects cleanly (I'm not sure about what happens to the remaining processes, you will have to 
look at rsh code for that -- it may be SIGHUP or something, i dunno -- other posts may be clearer on this).
> 

A real example would be a perl program that runs as a daemon
#!/usr/bin/perl
unless ($pid = fork) {
   unless (fork) {
       open(SDOUT,'>/dev/null');
       open(STDERR,'>/dev/null');
       open (X, 'some_process 2>&1 |'); # that generates stdio to X 
       while (X) {   # real program uses select
             do something
       }
     # dies
       exit 0;
   }
   waitpid($pid,0);
   exit 0;
}


This process will hang ssh, it should not. ....or please tell me why 
it should.

Michael
Michael at Insulin-Pumpers.org


From djm at mindrot.org  Wed Dec 12 10:42:18 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 12 Dec 2001 10:42:18 +1100 (EST)
Subject: hang on exit bug under Linux
In-Reply-To: <200112112313.PAA09496@ns2.bizsystems.net>
Message-ID: <Pine.LNX.4.33.0112121039140.3348-100000@mothra.mindrot.org>

On Tue, 11 Dec 2001, Michael wrote:

> unless ($pid = fork) {
>    unless (fork) {
>        open(SDOUT,'>/dev/null');
>        open(STDERR,'>/dev/null');
>        open (X, 'some_process 2>&1 |'); # that generates stdio to X 
>        while (X) {   # real program uses select
>              do something
>        }
>      # dies
>        exit 0;
>    }
>    waitpid($pid,0);
>    exit 0;
> }
> 
> 
> This process will hang ssh, it should not. ....or please tell me why 
> it should.

It doesn't close or redirect stdin. Here is a better one, which doesn't
cause ssh to linger:

------------ daemon.pl

#!/usr/bin/perl -wT

use strict;
use POSIX 'setsid';

my $prog = shift @ARGV;

defined($prog)			or die "Usage: daemon.pl program [args]\n";
(-x $prog)			or die "Can't execute $prog";

chdir '/'			or die "Can't chdir to /: $!";
open STDIN, '/dev/null'		or die "Can't read /dev/null: $!";
open STDOUT, '>/dev/null'	or die "Can't write to /dev/null: $!";
defined(my $pid = fork)		or die "Can't fork: $!";
exit if $pid;
setsid				or die "Can't start a new session: $!";
open STDERR, '>&STDOUT'		or die "Can't dup stdout: $!";

exec $prog, @ARGV		or die "Can't execute: $!";

------------

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From bugzilla-daemon at mindrot.org  Wed Dec 12 11:46:43 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 12 Dec 2001 11:46:43 +1100 (EST)
Subject: [Bug 13] Need faster ssh startup when no /dev/random or prngd available
Message-ID: <20011212004643.6A8A42DF5D@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=13

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement



------- Additional Comments From djm at mindrot.org  2001-12-12 11:46 -------
I don't like this - you could easily end up in a situation where you end up
using  essentially the same seed over and over again.



------- 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 Dec 12 11:53:57 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 12 Dec 2001 11:53:57 +1100 (EST)
Subject: [Bug 16] MD5 passwords not detected on Linux
Message-ID: <20011212005357.0F2A02DF5D@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=16

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From djm at mindrot.org  2001-12-12 11:53 -------
You can't go reading /etc/shadow to determine what format your passwords are in
- it is quite possible (preferred even) that you build as a non-root user. 

The system's crypt() function is the place to implement MD5 password hashing.
Unfortunately this is often overriden by libcrypto's DES-only function of the
same name. I hear that future OpenSSL releases will remove this. IIRC Redhat
patches OpenSSL to remove the function.

BTW on Mandrake you should be using PAM anyway :)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From mouring at etoh.eviladmin.org  Wed Dec 12 12:42:30 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 11 Dec 2001 19:42:30 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <200112112313.PAA09496@ns2.bizsystems.net>
Message-ID: <Pine.BSO.4.33.0112111941490.13601-100000@etoh.eviladmin.org>



On Tue, 11 Dec 2001, Michael wrote:

> > > If you run openssh, like the following:
> > >
> > > ssh remotehost "foreverSleep &"
> > >
> > > Should and does hang (fsecure hangs as well).
> > >
> > > HOWEVER,
> > >
> > > ssh remotehost
> > > # foreverSleep &
> > > # exit
> > >
> > > DOES hang. (fsecure does not hang) This is where the bug is. If you run ssh with a tty and in interactive mode, if the client decides to disconnect, it disconnects cleanly (I'm not sure about what happens to the remaining processes, you will have to
> look at rsh code for that -- it may be SIGHUP or something, i dunno -- other posts may be clearer on this).
> >
>
> A real example would be a perl program that runs as a daemon
> #!/usr/bin/perl
> unless ($pid = fork) {
>    unless (fork) {
>        open(SDOUT,'>/dev/null');
>        open(STDERR,'>/dev/null');
Perl opens STDIN also.  So it should hang very nicely.

- Ben



From michael at bizsystems.com  Wed Dec 12 13:31:17 2001
From: michael at bizsystems.com (Michael)
Date: Tue, 11 Dec 2001 18:31:17 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.BSO.4.33.0112111941490.13601-100000@etoh.eviladmin.org>
References: <200112112313.PAA09496@ns2.bizsystems.net>
Message-ID: <200112120231.SAA10986@ns2.bizsystems.net>

> 
> 
> On Tue, 11 Dec 2001, Michael wrote:
> 
> > > > If you run openssh, like the following:
> > > >
> > > > ssh remotehost "foreverSleep &"
> > > >
> > > > Should and does hang (fsecure hangs as well).
> > > >
> > > > HOWEVER,
> > > >
> > > > ssh remotehost
> > > > # foreverSleep &
> > > > # exit
> > > >
> > > > DOES hang. (fsecure does not hang) This is where the bug is. If you run ssh with a tty and in interactive mode, if the client decides to disconnect, it disconnects cleanly (I'm not sure about what happens to the remaining processes, you will have
 to
> > look at rsh code for that -- it may be SIGHUP or something, i dunno -- other posts may be clearer on this).
> > >
> >
> > A real example would be a perl program that runs as a daemon
> > #!/usr/bin/perl
> > unless ($pid = fork) {
> >    unless (fork) {
> >        open(SDOUT,'>/dev/null');
> >        open(STDERR,'>/dev/null');
> Perl opens STDIN also.  So it should hang very nicely.
> 
> - Ben
> 
Oops ! {blush} ....ur right

I'd really like to be able to have and sshd daemon that would boot 
the client off the machine and exit when it receives a close after 
starting a faulty daemon. I'm not keen about having many waiting 
sshd's in the process table because users don't clean up after 
themselves. This really is the issue, not what is truly right or 
wrong. I really don't think everyone will every agree. I'd be most 
happy even with an option with which I could configure MY sshd's to 
dump the user unconditionally if it receives a request to disconnect 
and the process is backgrounded. Giving the sysop the option to set 
things up that way would go a long way toward solving the problem 
until the "world" comes to an agreement on the true solution.

Michael
Michael at Insulin-Pumpers.org


From csc_seminar at cscorp.com.ua  Wed Dec 12 15:38:58 2001
From: csc_seminar at cscorp.com.ua (csc_seminar)
Date: Wed, 12 Dec 2001 06:38:58 +0200 (EET)
Subject: Invitation for seminar. Ïðèãëàøåíèå íà ñåìèíàð
Message-ID: <200112120438.fBC4Xd14032279@gw0.visti.net>



    ????????????????? ???????? Capital Standard Corporation ?????????? ??? ??????? ??????? ? ??????????? ???????????????? ?????????-??????????? ??? ???????????? ? ???????? ????????? ???????????? ??????????? ????? ????????

 
    ??????????? ???????????????? ???????-????????? ????????? ???????? ?? ????????????? ?????????? ??????. ???????????? ????????
    ???? ??????????: 19 ??????? 2001 ????
    ????? ?????????? ????????: 9.30-17.30
    ????? ??????????: ???????? ????????????? ?????????
    ? ????????? ????????:
    1. ?????????? - ??? ?????? ???????????? ????????:
        - ??????? ?????????
        - ????????????? ? ?????? ????????? ?????
        - ?????, ??????????? ??? ??????
    2. ??????????? ??????? ???????? ? ?????????? ??????:
        - FOREX - ????????????? ????? ?????? ?????
        - ?????????? ? ????????? ????????? 
    3. ?????????? ? ???????? ???????? ? ??????????? ????????: 
        - ??????????????? ????, ??????? ? ???????? ???????????? ?????? ????????
        - ???????? ????? ?spot?
        - ???????? ???????? ???????
        - ???????????? ???????? ???????
        - ?????????????? ??????? ? ???????????? ?????????? ?? ??????????? ?????????? ???????? 
    4. ??? ???????????? ?? ?????:
        - ?????????? ????????
        - ????????? (??????-??????)
        - ???????? ????
        - ?????
        - ????????? ?????
        - ?????????? ??????
        - ????? ? ?????? "????????-????????"
        - ???????????? ????????                         
    5. ??????????????? ???????? ?????????:
        - ??????????? ??????
        - ??????????????? ??????
        - ???????????????? ???????????? ??????? ? ??????????? ???????????, ???????????? ? ?????? ???????

    ????????? ??????? ? ????????: 440 ??????
    ??? ??????? ? ???????? ????????? ?? ????? ???????? ?????? ? 10%.
    ? ????????? ????????: ???????? ? ???????????? ?? ????????, ????, ????-??????. ???????????? ?????? ?????????? ????????? ???????? ?? ????????????? ?????????? ??????. ???????????? ????????, ??????????????? ?????????? ?????????? ??? ?????????? ? ?????? ???? ????????? ????????? ? ??????????.


    ??????????? ???????????????? ???????-?????????:
    ??????????? ????????????? ??????????????????? ?????????????
    ???? ??????????: 21 ??????? 2001 ????
    ????? ?????????? ????????: 9.30-17.30
    ????? ??????????: ?????????-??? ????????? ??????-??????????
    ? ????????? ????????:
    ??????????? ??????????? ???????????????? ? ????? ??????????????????? ????????????.
    ????? ??????? ?? ?????????? ?????? ???????? ?? 5.04.2001 ? 2371-???. ????????? ? ?????????? ? ????? ??????? ?? ????????? ?? 1.12.01. ?????????? ???????? ???????????? ??????????????????? ????????????. 
    ??????????? ??????????? ?????????? ? ?????? ?????????? ? ????????? ????????. ??????????? ???????? ???? ????????? ????????.
    ????? ??????? ?????? ????????????? ???????. ??????? ?????????? ????????????  CT-1, EUR 1,2.
    ??????? ????????????? ???????. ????? ??????????? ?????????? ???? ?? ???????? ????????? ????????????? ?? ????????? ?? 1.12.01.
    ??????????? ?????????? ??? ??? ????????? ?????????? ???????. ?????????? ?????????, ????????? ???? ??????.
    ?????????? ??? ?? ??????????????????? ????????? ? ???????? ????? ???? ??????.
    ???????? ??????????? ??????????? ???????? ??????? ?????? ?????? (??????????????????? ????????, ??????? ??????? ????????? ???????? ?? ?????????? ??????). ???????????? ?????? ?????????? ??????????????, ????????????? ? ?????????????? ?????????? ?????? ??????????????, ???????, ??????????????? ?????????????????, ??????????? ????????? ??? ????????? ???.
    ???????? ?????? ??? ????????????? ????????????? ???????????????? ?????? ? ?????????? ????? (??????? ??????? ? ????????????? ?????????? ?? ?????????? ????????, ????- ? ?????????????? ?????????????????? ????????).
    ??????? ?????????? ?????????, ??????????, ? ???????? ???????????????? ?????? ? ?????????? ????????.

    ????????? ??????? ? ???????? 570 ??????
    ??? ??????? ? ???????? ????????? ?? ????? ????? ?????? ? 10%.
    ? ????????? ????????: ???????? ? ???????????? ?? ????????, ????, ????-??????. ???????????? ?????? ?????????? ??????????? ????????????? ??????????????????? ?????????????, ??????????????? ?????????? ?????????? ??? ?????????? ? ?????? ???? ????????? ????????? ? ??????????
 
    ???? ???????? ?????????? ????? ?????? ??? ?????????? ?????????????? ???????????????? ????????? ?? ????????? ???? ???????? ? ??? ? ?????.
    ??? ??????? ? ???????? ?????????? ?????????????????? ?? ????? ????????? ? ??????????? ???? ??????? ??????? 
(044) 494 46 58,  E-mail: csc_seminar at cscorp.com.ua


    ?? ???????? ???? ?????????, ???? ???????? ???????? ??? ?? ?????????. ??????? ???? ????? ?? ?????? ??????????? ?? ??????, ??????? ?????? ?? ?????? unsubscribe_sem at cscorp.com.ua



From nakaji at tutrp.tut.ac.jp  Wed Dec 12 18:35:37 2001
From: nakaji at tutrp.tut.ac.jp (NAKAJI Hiroyuki)
Date: 12 Dec 2001 16:35:37 +0900
Subject: connect to bass.directhit.com(65.214.36.12):2401 failed: Connection refused
Message-ID: <87n10o3n7a.fsf@boggy.acest.tutrp.tut.ac.jp>

Hi,

According to http://www.openssh.com/portable.html, I tried to update my
openssh_cvs tree by CVS. And got an error.

$ cvs update -dP
cvs [update aborted]: connect to bass.directhit.com(65.214.36.12):2401 failed: Connection refused

Why? And from which cvs pserver can I get the latest openssh-portable?

Thanks.
-- 
NAKAJI Hiroyuki


From wilfrid.billot at imag.fr  Wed Dec 12 20:20:20 2001
From: wilfrid.billot at imag.fr (Wilfrid Billot)
Date: Wed, 12 Dec 2001 10:20:20 +0100
Subject: ssh api
Message-ID: <3C172154.82170827@imag.fr>

I'm currently upgrading a tool which is a parallelized rsh for a cluster
and want to include ssh connection in it. But the ssh code is huge and,
as I don't want to loose too much time reading ssh code, I'd like to
know if there is in ssh a C-function like rcmd, that opens a ssh
connection and give in return a socket descriptor.

Thanks

-- 
Wilfrid Billot

Laboratoire ID				Tel.: 04 76 61 20 35
ZIRST - 51, avenue Jean Kuntzmann	e-mail : wilfrid.billot at imag.fr
38330 Montbonnot Saint Martin

Clustering, installation/setup : http://ka-tools.sourceforge.net


From emsi at ipartners.pl  Wed Dec 12 20:38:25 2001
From: emsi at ipartners.pl (Mariusz Woloszyn)
Date: Wed, 12 Dec 2001 10:38:25 +0100 (EET)
Subject: configuration bug
Message-ID: <Pine.LNX.4.43.0112121034200.22484-100000@dzyngiel.ipartners.pl>


Tested in 2.9.9p2.

I did (right after unpacking):
./configure --prefix=/usr/ --sysconfdir=/etc/

then invoking sshd reports:
Could not load host key: /usr/local/ertc/ssh_host_key

make install installed it properly in /etc, but binary refers to
/usr/local.




--
Mariusz Wo?oszyn
Internet Security Specialist, Internet Partners



From markus at openbsd.org  Wed Dec 12 20:40:17 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 12 Dec 2001 10:40:17 +0100
Subject: ssh api
In-Reply-To: <3C172154.82170827@imag.fr>
References: <3C172154.82170827@imag.fr>
Message-ID: <20011212104017.A2365@faui02>

On Wed, Dec 12, 2001 at 10:20:20AM +0100, Wilfrid Billot wrote:
> I'm currently upgrading a tool which is a parallelized rsh for a cluster
> and want to include ssh connection in it. But the ssh code is huge and,
> as I don't want to loose too much time reading ssh code, I'd like to
> know if there is in ssh a C-function like rcmd, that opens a ssh
> connection and give in return a socket descriptor.

try to check what sftp does. or scp. they just run the ssh binary
to create a secure connection.

other than that, there is no rcmd-like API.

-m


From gert at greenie.muc.de  Wed Dec 12 21:16:51 2001
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 12 Dec 2001 11:16:51 +0100
Subject: configuration bug
In-Reply-To: <Pine.LNX.4.43.0112121034200.22484-100000@dzyngiel.ipartners.pl>; from Mariusz Woloszyn on Wed, Dec 12, 2001 at 10:38:25AM +0100
References: <Pine.LNX.4.43.0112121034200.22484-100000@dzyngiel.ipartners.pl>
Message-ID: <20011212111651.E8002@greenie.muc.de>

hi,

On Wed, Dec 12, 2001 at 10:38:25AM +0100, Mariusz Woloszyn wrote:
> Tested in 2.9.9p2.
> 
> I did (right after unpacking):
> ./configure --prefix=/usr/ --sysconfdir=/etc/
> 
> then invoking sshd reports:
> Could not load host key: /usr/local/ertc/ssh_host_key
> 
> make install installed it properly in /etc, but binary refers to
> /usr/local.

Sounds more like "config file refers to /usr/local".

If there is a sshd_config already in place, "make install" won't overwrite
it (which is a *good* thing), so you won't get the new path.

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 emsi at ipartners.pl  Wed Dec 12 21:21:20 2001
From: emsi at ipartners.pl (Mariusz Woloszyn)
Date: Wed, 12 Dec 2001 11:21:20 +0100 (EET)
Subject: configuration bug
In-Reply-To: <20011212111651.E8002@greenie.muc.de>
Message-ID: <Pine.LNX.4.43.0112121119120.22484-100000@dzyngiel.ipartners.pl>

On Wed, 12 Dec 2001, Gert Doering wrote:

> > make install installed it properly in /etc, but binary refers to
> > /usr/local.
>
> Sounds more like "config file refers to /usr/local".
>
> If there is a sshd_config already in place, "make install" won't overwrite
> it (which is a *good* thing), so you won't get the new path.
>
Yes. You're right.
Thank you for your help, and sorry for bothering.

--
Mariusz Wo?oszyn
Internet Security Specialist, Internet Partners



From dwd at bell-labs.com  Thu Dec 13 01:53:09 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Wed, 12 Dec 2001 08:53:09 -0600
Subject: [Bug 13] Need faster ssh startup when no /dev/random or prngd available
In-Reply-To: <20011212004643.6A8A42DF5D@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Wed, Dec 12, 2001 at 11:46:43AM +1100
References: <20011212004643.6A8A42DF5D@shitei.mindrot.org>
Message-ID: <20011212085309.A13059@lucent.com>

On Wed, Dec 12, 2001 at 11:46:43AM +1100, bugzilla-daemon at mindrot.org wrote:
> http://bugzilla.mindrot.org/show_bug.cgi?id=13
> 
> djm at mindrot.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Severity|normal                      |enhancement
> 
> 
> 
> ------- Additional Comments From djm at mindrot.org  2001-12-12 11:46 -------
> I don't like this - you could easily end up in a situation where you end up
> using  essentially the same seed over and over again.


I put the following response into bugzilla, but for some reason it
didn't send email to anybody:




------- Additional Comments From Dave Dykstra 2001-12-13 01:31 -------

No, that's not true, because every startup still adds small amounts of easily
gathered entropy.  You could argue that that means people could guess all the
possibilities and try them all, but they can't because they do not know the
contents of the seed file which was originally generated from a large amount
of entropy.  The only added risk is that somebody may get hold of the seed
file, but if the ~/.ssh directory is not secured someone could easily break
in anyway so I maintain that it doesn't add any more overall risk.  There is
no way for someone to guess the contents of the seed file by examining network
traffic because the psuedo-random number generation process is not reversible.
As an added protection, the seed file is re-written with additional entropy
mixed in each time ssh is run.

You don't have to rely on just my arguments, either: the SSH 1.2.* series did
this and there was never any CERT advisories nor complaints from crypto experts
about it, and pointing out SSH weaknesses have brought fame to many of them
so I'm sure that if there was a weakness here you would have heard about it.
Also, GnuPG does essentially the same thing on systems that don't have
/dev/random.


From j.petersen at msh.de  Thu Dec 13 02:15:30 2001
From: j.petersen at msh.de (=?ISO-8859-1?Q?=22Petersen=2C_J=F6rg=22?=)
Date: Wed, 12 Dec 2001 16:15:30 +0100
Subject: hang on exit bug under Linux
Message-ID: <B56A3A4C735ED2118F25000083687FBB019D6E91@MSHNTS04>

If you like a C-Version; you might be inspired by my "daemon.c":
I use it to run Shell-Scripts as "clean" daemons:


/* daemon.c
 * $Id: daemon.c,v 1.4 2001/10/10 07:14:59 jp Exp $
 * $Source: /home/u/jp/RCS/daemon.c,v $
 *
 * 1.1   19.09.2001 jp- RCS-Checkin der ersten Version
 * 1.2   19.09.2001 jp- Einbau Option -l logfile, -c, -q
 * 1.3   19.09.2001 jp- ID als extern-String
 * 1.4   10.10.2001 jp- Usage auch auf stderr
 */

/*
   cc daemon.c -o daemon; strip daemon
 */
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <time.h>
#include <sys/syslog.h>
#include <sys/types.h>

extern char version[]="$Id: daemon.c,v 1.4 2001/10/10 07:14:59 jp Exp $";
char * progname;
int chdirRoot=0;
int quiet=0;

void usage(char * txt) {
        fprintf (stderr,"%s\n",txt);
        fprintf (stderr,"Usage: %s [-c] [-l /log/file] /path/to/exe arg1
arg2\n",
                        progname);
        fprintf (stderr,"   -l /log/file  does '>/log/file 2>&1'\n");
        fprintf (stderr,"   -c            does cd / (use whenever
possible!)\n");
        syslog (LOG_INFO | LOG_DAEMON,"%s\n",txt);
        syslog (LOG_INFO | LOG_DAEMON,"Usage: %s [-c] [-l /log/file]
/path/to/exe arg1 arg2\n",
                        progname);
        syslog (LOG_INFO | LOG_DAEMON,"   -l /log/file  does '>/log/file
2>&1'\n");
        syslog (LOG_INFO | LOG_DAEMON,"   -c            does cd / (use
whenever possible!)\n");
        exit(-1);
}

char * timetext(void) {
    time_t current;
    struct tm * local;
    static char str[22];
    time(&current); /* momentane Zeit */
    local = localtime(&current);
    sprintf(str,"%02i.%02i.%04i,%02i:%02i:%02i",
                local->tm_mday,
                local->tm_mon+1,
                local->tm_year+1900,
                local->tm_hour,
                local->tm_min,
                local->tm_sec);
    return str;
}

void MSHdaemon(char * logfile, char * infotxt) {
        int rc;

          rc=fork();
          if (-1==rc) {
            syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to fork()\n");
            exit(-1);
          }
          if (rc>0) exit(0); /* parent should exit and return control,
                 it's OK. */
          rc=setsid();
          if (-1==rc) {
            syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to setsid()\n");
            exit(-1);
          }
          rc=fork();
          if (-1==rc) {
            syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to fork()\n");
            exit(-1);
          }
          if (rc>0) exit(0); /* parent should exit and return control,
                                         it's OK. */

        if (chdirRoot == 1) {
          rc=chdir("/");
          if (-1==rc) {
            syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to chdir()\n");
            exit(-1);
          }
          /* umask(0); */
        }

        if (!freopen("/dev/null", "r", stdin)) {
 syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to freopen(%s,...,%s):
%s\n",
                "/dev/null","stdin",strerror (errno));
            fflush(stderr);
            exit(-1);
        }
        if (!freopen(logfile, "a", stdout)) {
 syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to freopen(%s,...,%s):
%s\n",
                logfile,"stdout",strerror (errno));
            fflush(stderr);
            exit(-1);
        }
        if (! quiet)
            fprintf(stdout,"Test stdout\n");
        fflush(stdout);
        if (!freopen(logfile, "a", stderr)) {
 syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to freopen(%s,...,%s):
%s\n",
                logfile,"stderr",strerror (errno));
            fflush(stderr);
            exit(-1);
        }
        if (! quiet)
            fprintf(stderr,"Test stderr\n");
        if (! quiet)
            fprintf(stderr,"%s\n",infotxt);
        fprintf(stderr,"%s\n__O_u_t_p_u_t_:____\n",timetext());
        fflush(stderr);
        if (! quiet)
            syslog (LOG_INFO | LOG_DAEMON, infotxt);
        return; /* a grandchild returns... free as a bird..  */
}


int main (int argc, char * const * argv) {
    char prog[1024];
    char infotxt[1024];
    char errmsg[1024];
    FILE * ftest;

    extern char *optarg;
    extern int optind;
    int fd;
    int ch;                     /* global int chdirRoot: cd / ? */
    char logfile[256] = "/dev/null";    /* logfile:
                                       where stdout&stderr are sent to */
    progname = argv[0];
    while ((ch = getopt(argc, argv, "qcl:")) != -1)
        switch (ch) {
            case 'q':
                quiet = 1;
                break;
            case 'c':
                chdirRoot = 1;
                break;
            case 'l':
                if (argc < 2) {
 syslog (LOG_INFO | LOG_DAEMON,"Logfilename too long! (max 255 char.!)\n");
                    exit(-1);
                }
                strcpy(logfile,optarg);
                break;
             case '?':
             default:
                     usage("Unbekanntes Argument");
     }
     argc -= optind;
     argv += optind;



    if (strlen(progname)+strlen(argv[1]) > 750) {
            syslog (LOG_INFO | LOG_DAEMON,"ArgV too long.... Tschuess\n");
        exit(-1);
    }
    if (argc < 1) {
        usage("Zu wenig Argumente!");
    }
    /* Testen ob Logfile geschrieben werden kann */
        ftest=fopen(logfile, "w");
        if (!ftest) {
   syslog (LOG_INFO | LOG_DAEMON,"daemon - Unable to fopen(%s): %s\n",
                logfile,strerror (errno));
            fflush(stderr);
            exit(-1);
        }
        fclose(ftest);
    sprintf(prog,"uid=%i prog='%s'",(int)geteuid(),argv[0]);
    sprintf(infotxt,"run as daemon: %s log='%s'",prog,logfile);
    if (! quiet)
        fprintf(stdout,"%s\n",infotxt);
    MSHdaemon(logfile,infotxt);
    execvp(argv[0],argv);
    /* Wenn wir hier ankommen, hat exec nicht funktioniert... */
    sprintf(errmsg,"%s ERROR: %s",prog,strerror (errno));
    syslog (LOG_ERR | LOG_DAEMON, errmsg);

    /* Write to log too ... */
    syslog (LOG_INFO | LOG_DAEMON,"\nERROR\n%s\n",errmsg);
    fflush(stderr);
    fclose(stderr);
    exit(0);
    return 0;
}



From epa98 at doc.ic.ac.uk  Thu Dec 13 04:07:30 2001
From: epa98 at doc.ic.ac.uk (Edward Avis)
Date: Wed, 12 Dec 2001 17:07:30 +0000 (GMT)
Subject: RFE: ssh-askpass program configurable
Message-ID: <Pine.LNX.4.42.0112121659490.32365-100000@sync25.doc.ic.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I note that ssh-askpass-gnome was moved into the contrib/ directory of
portable OpenSSH and the configure option for it
(--with-gnome-askpass) was removed.

I can understand not wanting a configure option for one particular
askpass program, but it would be useful to have a general replacement,
as in

% ./configure --with-askpass-program=ssh-askpass-gnome

- -- 
Ed Avis <epa98 at doc.ic.ac.uk>
Finger for PGP key

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8F47WIMp73jhGogoRAkm/AJ9pSkbb0Gj1t0j99SHyGOOXTSgshACfZ6o0
OXvElZRnzyljYWTBWesudOE=
=2tIJ
-----END PGP SIGNATURE-----



From bugzilla-daemon at mindrot.org  Thu Dec 13 07:21:19 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 13 Dec 2001 07:21:19 +1100 (EST)
Subject: [Bug 34] Incorrect claim about Commercial SSH's key length
Message-ID: <20011212202119.DE4FB2DF12@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=34

provos at citi.umich.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From provos at citi.umich.edu  2001-12-13 07:21 -------
I do not see anything wrong there.  A 1023-bit RSA key is a 1023-bit key, and
 not a 1024-bit key.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From djm at mindrot.org  Thu Dec 13 08:21:53 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 13 Dec 2001 08:21:53 +1100 (EST)
Subject: ssh api
In-Reply-To: <3C172154.82170827@imag.fr>
Message-ID: <Pine.LNX.4.33.0112130821230.2505-100000@mothra.mindrot.org>

On Wed, 12 Dec 2001, Wilfrid Billot wrote:

> I'm currently upgrading a tool which is a parallelized rsh for a cluster
> and want to include ssh connection in it. But the ssh code is huge and,
> as I don't want to loose too much time reading ssh code, I'd like to
> know if there is in ssh a C-function like rcmd, that opens a ssh
> connection and give in return a socket descriptor.

pipe()
fork()
dup2()
execl()

See sftp.c for an example.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From yamaneko at centurytel.net  Thu Dec 13 08:30:24 2001
From: yamaneko at centurytel.net (Sam Vaughan)
Date: Wed, 12 Dec 2001 13:30:24 -0800 (PST)
Subject: BUG #18 
Message-ID: <Pine.LNX.4.33.0112121321540.3450-100000@localhost.localdomain>


I submitted some comments for BUG #18, but forgot to cc this list.

Let me know if I shouldn't cc the list.


Bugzilla Bug 18  
Using ssh -f -L bombs on SCO Openserver 5.0.5  

------- Additional Comments From Sam Vaughan 2001-12-13 08:17 -------

This seems to be fixed in Openserver 5.0.6. The above command runs as
expected. So something has changed between 5.0.5 and 5.0.6 in the way
select has been implemented in SCO.

The only thing I found, so far, is in patch 5.0.6a for 5.0.6 systems.

"As of Release Supplement 506A for OpenServer Release 5.0.6, a subset of
APIs that use the kernel clock have been modified to utilize the
high-precision clock.  These are:

    select(S) has microsecond precision, adjusted for kernel entry and
exit times, time-sharing delays, and so forth."

Could this be the change? 

I traced the error on 5.0.5 to the select statement in the function
client_wait_until_can_do_something in file clientloop.c 

When I get more time, I will look into this further. 




From jmknoble at pobox.com  Thu Dec 13 09:54:50 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 12 Dec 2001 17:54:50 -0500
Subject: RFE: ssh-askpass program configurable
In-Reply-To: <Pine.LNX.4.42.0112121659490.32365-100000@sync25.doc.ic.ac.uk>; from epa98@doc.ic.ac.uk on Wed, Dec 12, 2001 at 05:07:30PM +0000
References: <Pine.LNX.4.42.0112121659490.32365-100000@sync25.doc.ic.ac.uk>
Message-ID: <20011212175450.C7599@zax.half.pint-stowp.cx>

Circa 2001-Dec-12 17:07:30 +0000 dixit Edward Avis:

: I note that ssh-askpass-gnome was moved into the contrib/ directory of
: portable OpenSSH and the configure option for it
: (--with-gnome-askpass) was removed.
: 
: I can understand not wanting a configure option for one particular
: askpass program, but it would be useful to have a general replacement,
: as in
: 
: % ./configure --with-askpass-program=ssh-askpass-gnome

Not sure what RFE means in the subject.

You can specify the default askpass program ssh tries to use at compile
time:

  make ASKPASS_PROGRAM=/path/to/your/askpass/program

You can also specify the askpass program at runtime via the environment
variable SSH_ASKPASS.

contrib/gnome-ssh-askpass.c contains compilation instructions in a
comment near the top of the file if you'd like to build it.

If you'd rather build and install a different askpass program, there's
a pointer to x11-ssh-askpass in the INSTALL file.

I don't understand the problem....

-- 
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/20011212/71b71e6b/attachment.bin 

From mouring at etoh.eviladmin.org  Thu Dec 13 12:05:43 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 12 Dec 2001 19:05:43 -0600 (CST)
Subject: RFE: ssh-askpass program configurable
In-Reply-To: <20011212175450.C7599@zax.half.pint-stowp.cx>
Message-ID: <Pine.BSO.4.33.0112121905160.13997-100000@etoh.eviladmin.org>


RFE - Request For Enhancement

- Ben

On Wed, 12 Dec 2001, Jim Knoble wrote:

> Circa 2001-Dec-12 17:07:30 +0000 dixit Edward Avis:
>
> : I note that ssh-askpass-gnome was moved into the contrib/ directory of
> : portable OpenSSH and the configure option for it
> : (--with-gnome-askpass) was removed.
> :
> : I can understand not wanting a configure option for one particular
> : askpass program, but it would be useful to have a general replacement,
> : as in
> :
> : % ./configure --with-askpass-program=ssh-askpass-gnome
>
> Not sure what RFE means in the subject.
>
> You can specify the default askpass program ssh tries to use at compile
> time:
>
>   make ASKPASS_PROGRAM=/path/to/your/askpass/program
>
> You can also specify the askpass program at runtime via the environment
> variable SSH_ASKPASS.
>
> contrib/gnome-ssh-askpass.c contains compilation instructions in a
> comment near the top of the file if you'd like to build it.
>
> If you'd rather build and install a different askpass program, there's
> a pointer to x11-ssh-askpass in the INSTALL file.
>
> I don't understand the problem....
>
> --
> jim knoble | jmknoble at pobox.com   | http://www.pobox.com/~jmknoble/
> (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
>



From carl at bl.echidna.id.au  Thu Dec 13 12:19:16 2001
From: carl at bl.echidna.id.au (carl at bl.echidna.id.au)
Date: Thu, 13 Dec 2001 12:19:16 +1100 (EST)
Subject: behaviour of ssh/scp over flakey links - timeout/retry?
Message-ID: <200112130119.fBD1JGBT017211@rollcage.bl.echidna.id.au>

I'm using OpenSSH's ssh and scp to back up some remote
machines, roughly as follows :

ssh remote-host "tar up a few dirs"
scp remote-host:tarfile local-repository

On the whole, as I'd expect, this works just fine.
But .. sometimes the link is a bit dodgey (for lack of
a more explicit term, this being a polite list :) )

Can anyone tell me how ssh and scp timeout and retry, or if they
do, during a session (I know about timeout and retry during
establishment, it's documented in the man page).  The job's
scripted, and I need to be able to make my script deal with a loss,
by as a minimum, alerting me that it's happened.  At the moment,
it seems to just hang when its lost the link.  I could use 
expect I guess, and catch timeouts that way, but I'd prefer if
ssh said "timeout on session, giving up" or something.

FWIW, we're using OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
on RedHat 7.1 and 6.2.

I'll be updating to 3.0 "soon", once I've had a chance to test it in
our environment.

Thanks :)

Carl



From dan at doxpara.com  Thu Dec 13 13:10:58 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 12 Dec 2001 18:10:58 -0800
Subject: behaviour of ssh/scp over flakey links - timeout/retry?
References: <200112130119.fBD1JGBT017211@rollcage.bl.echidna.id.au>
Message-ID: <00da01c1837b$676edf60$1701000a@effugas>

Carl:

    I've honestly never had the best of luck with scp.  In my experience,
command forwarding the tar command is the fastest, most cross-platform(even
on Windows, using the Cygwin OpenSSH daemon) method of moving files.

    Try this:

    # For unpacked files on the backup host
    alicehost$  ssh alice at bobhost "tar -cf - /path" | tar -xf -
    # To get the tarball itself
    alicehost$  ssh alice at bobhost "tar -cf - /path" > /path/bobhost.tar
    # Slight variant -- send a tarball somewhere else
    bobhost$  tar -cf - /path | ssh bob at alicehost "cat > /path/bobhost.tar"

    Now, that being said, it sounds like the real problem is that the TCP
session dies on occasion.  There are a couple solutions to this, some of
which I'm still working on:

    1) Use a transfer system that can handle incremental(and thus resumable)
updates.  Rsync comes to mind.  Make sure Keepalives are enabled("ssh -o
KeepAlive Yes", or modify your /etc/ssh.conf) so timeouts will happen
quicker, then have your script go back and rsync again if rsync returns an
error code.  (It won't upon a successful syncing.)  Do something like:

    alicehost$  rsync -e "ssh -o KeepAlive yes" alice at bobhost:/path
/path/bobhost/
    or
    bobhost$  rysnc -e "ssh -o KeepAlive yes" /path
bob at alicehost:/path/bobhost

    2) Add a TCP Reliability Layer.  ROCKS, available at
http://www.cs.wisc.edu/~zandy/rocks/ ,handles links that are...ah..."less
than stable".  Quoting the description:  "Rock-enabled programs continue to
run after any of these events; their broken connections recover
automatically, without loss of in-flight data, when connectivity returns.
Rocks work transparently with most applications, including SSH clients,
X-windows applications, and network service daemons."  You'll almost
certainly need to disable SSH keepalives for this to work, but the
reliability layer will almost certainly handle even extended network
outages.

    I haven't tested ROCKS at *all*, but I'll be doing so shortly.

    You might find yourself missing, well, the status updates that you get
with scp.  cpipe, available at http://wsd.iitb.fhg.de/~kir/cpipehome/ , is a
nice general purpose tool for monitoring the speed of a pipe.

    Lemme know if any of this helps; I'm working on stuff related to this
right now.

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com



From stuge at cdy.org  Thu Dec 13 13:18:27 2001
From: stuge at cdy.org (Peter Stuge)
Date: Thu, 13 Dec 2001 03:18:27 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112120231.SAA10986@ns2.bizsystems.net>; from michael@bizsystems.com on Tue, Dec 11, 2001 at 06:31:17PM -0800
References: <200112112313.PAA09496@ns2.bizsystems.net> <Pine.BSO.4.33.0112111941490.13601-100000@etoh.eviladmin.org> <200112120231.SAA10986@ns2.bizsystems.net>
Message-ID: <20011213031826.A16141@foo.birdnet.se>

On Tue, Dec 11, 2001 at 06:31:17PM -0800, Michael wrote:
>>>>> If you run openssh, like the following:
>>>>> 
>>>>> ssh remotehost "foreverSleep &"
>>>>> 
>>>>> Should and does hang (fsecure hangs as well).

If you do not want this to "hang", use

ssh remotehost foreverSleep &

instead.  Obvious solution maybe, but it's what this is all about.


>>>>> HOWEVER,
>>>>>
>>>>> ssh remotehost
>>>>> # foreverSleep &
>>>>> # exit
>>>>>
>>>>> DOES hang. (fsecure does not hang) This is where the bug is. If
>>>>> you run ssh with a tty and in interactive mode, if the client
>>>>> decides to disconnect, it disconnects cleanly (I'm not sure about
>>>>> what happens to the remaining processes, you will have to
>>>>> look at rsh code for that -- it may be SIGHUP or something, i
>>>>> dunno -- other posts may be clearer on this).

SSH Inc's sshd and rshd both behave this way, yes, and both can hence cause
data loss.  The same goes for xterm.  And my Linux console.  And the OpenBSD
console.  And this is the problem.  We're used to all these programs causing
possible data loss, but we don't quite see it this way.

At least I didn't, until now.

I was just discussing this with a nice guy in #openbsd on DALnet, and
neither of us could come up with one single program that would linger in the
above case..

<JohnA> but i can't think of any process that behaves that way these days,
        you'd just end up with piles of lingering processes on some machines


> I'd really like to be able to have and sshd daemon that would boot 
> the client off the machine and exit when it receives a close after 
> starting a faulty daemon. I'm not keen about having many waiting 
> sshd's in the process table because users don't clean up after 
> themselves. This really is the issue, not what is truly right or 
> wrong. I really don't think everyone will every agree. I'd be most 
> happy even with an option with which I could configure MY sshd's to 
> dump the user unconditionally if it receives a request to disconnect 
> and the process is backgrounded. Giving the sysop the option to set 
> things up that way would go a long way toward solving the problem 
> until the "world" comes to an agreement on the true solution.

The true solution is considered to be one of two things:

1. All daemons shall behave.  (ie. close std*)
2. The user knows what he/she wants.  (ie. to exit, loosing data)

I actually want both.  I want to be able to tell sloppy daemon programmers
that they should clean up their code.  But I also want my users to not have
to deal with sloppy daemon programmers, unless they choose to do so.
This is tough.

A thought that occured in my mind tonight while thinking about this is that
the ssh client could background itself and tell the user about it, instead
of closing down and causing possible data loss.  And it needs to leave std*
open, ie. not daemonize, but background.  This would propagate over multiple
connections all the way back to my actual terminal.  And if I choose to
close my terminal (xterm, console, whatever) the process that I started at
remotehost will be sent SIGHUP.  In the perl case it would kill it, a C
program that catches the signal doesn't care and keeps running.  Data will
be lost but that is out of SSH scope.

Comments on this, anyone?


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From carl at bl.echidna.id.au  Thu Dec 13 13:20:49 2001
From: carl at bl.echidna.id.au (carl at bl.echidna.id.au)
Date: Thu, 13 Dec 2001 13:20:49 +1100 (EST)
Subject: behaviour of ssh/scp over flakey links - timeout/retry?
Message-ID: <200112130220.fBD2Knd0017526@rollcage.bl.echidna.id.au>

> From: "Dan Kaminsky" <dan at doxpara.com>
> 
> Carl:
> 
>     I've honestly never had the best of luck with scp.  In my experience,
> command forwarding the tar command is the fastest, most cross-platform(even
> on Windows, using the Cygwin OpenSSH daemon) method of moving files.
> 
>     Try this:
> 
>     # For unpacked files on the backup host
>     alicehost$  ssh alice at bobhost "tar -cf - /path" | tar -xf -
>     # To get the tarball itself
>     alicehost$  ssh alice at bobhost "tar -cf - /path" > /path/bobhost.tar
>     # Slight variant -- send a tarball somewhere else
>     bobhost$  tar -cf - /path | ssh bob at alicehost "cat > /path/bobhost.tar"
> 
>     Now, that being said, it sounds like the real problem is that the TCP
> session dies on occasion.

Yep, the connection is to a few IDS probes that are behind flakey 
switches and overloaded LANs.  We get a lot of dropped sessions.

>  There are a couple solutions to this, some of
> which I'm still working on:
> 
>     1) Use a transfer system that can handle incremental(and thus resumable)
> updates.  Rsync comes to mind.  Make sure Keepalives are enabled("ssh -o
> KeepAlive Yes", or modify your /etc/ssh.conf) so timeouts will happen
> quicker, then have your script go back and rsync again if rsync returns an
> error code.  (It won't upon a successful syncing.)  Do something like:
> 
>     alicehost$  rsync -e "ssh -o KeepAlive yes" alice at bobhost:/path
> /path/bobhost/
>     or
>     bobhost$  rysnc -e "ssh -o KeepAlive yes" /path
> bob at alicehost:/path/bobhost

Ok, I like that option.

>     2) Add a TCP Reliability Layer.  ROCKS, available at
> http://www.cs.wisc.edu/~zandy/rocks/ ,handles links that are...ah..."less
> than stable".  Quoting the description:  "Rock-enabled programs continue to
> run after any of these events; their broken connections recover
> automatically, without loss of in-flight data, when connectivity returns.
> Rocks work transparently with most applications, including SSH clients,
> X-windows applications, and network service daemons."  You'll almost
> certainly need to disable SSH keepalives for this to work, but the
> reliability layer will almost certainly handle even extended network
> outages.
> 
>     I haven't tested ROCKS at *all*, but I'll be doing so shortly.

Interesting.

>     You might find yourself missing, well, the status updates that you get
> with scp.  cpipe, available at http://wsd.iitb.fhg.de/~kir/cpipehome/ , is a
> nice general purpose tool for monitoring the speed of a pipe.

No, don't care.  Just want the copy to complete, or tell me it didn't.

>     Lemme know if any of this helps; I'm working on stuff related to this
> right now.

It sure does, thankyou.

Carl



From weitz at neo.tamu.edu  Thu Dec 13 13:34:22 2001
From: weitz at neo.tamu.edu (Weitz Richard A)
Date: Thu, 13 Dec 2001 02:34:22 -0000
Subject: openssh-3.0.2p1
Message-ID: <200112130234.fBD2YMu62845@smtp-relay-1.tamu.edu>


mips sgi irix6.2

..    
gcc -mabi=64 -mips4 -mmips-as -O0 -Wall -Wpointer-arith -Wno-uninitialized
-I. -I. -I/usr/local/ssl/include  -I/usr/local/include 
-DETCDIR=\"/usr/local/openssh/etc\" 
-D_PATH_SSH_PROGRAM=\"/usr/local/openssh/bin/ssh\" 
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/openssh/libexec/ssh-askpass\"    
-D_PATH_SFTP_SERVER=\"/usr/local/openssh/libexec/sftp-server\" 
-D_PATH_SSH_PIDDIR=\"/usr/local/openssh/etc\" 
-DHAVE_CONFIG_H -c clientloop.c
gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o
readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib 
-L/usr/local/lib/libz64 -lssh -lopenbsd-compat -lz  -lgen -lcrypto
ld32: FATAL 12: Expecting n32 objects: ssh.o is 64-bit.
collect2: ld returned 4 exit status
gmake: *** [ssh] Error 1


Any suggestions ?
And, where is -lgen from and located ?
       
       Thanks,
       Richard



From dan at doxpara.com  Thu Dec 13 13:34:25 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 12 Dec 2001 18:34:25 -0800
Subject: behaviour of ssh/scp over flakey links - timeout/retry?
References: <200112130220.fBD2Knd0017526@rollcage.bl.echidna.id.au>
Message-ID: <00f501c1837e$ae52bb60$1701000a@effugas>

> Yep, the connection is to a few IDS probes that are behind flakey
> switches and overloaded LANs.  We get a lot of dropped sessions.

Hmmm.  There's an interesting third option that attempts to stream all files
directly to a backend aggregator, using the file system only as a cache in
case connectivity is lost, if at all.

What's the datarate of each of your probes, worstcase?

--Dan




From carl at bl.echidna.id.au  Thu Dec 13 13:34:32 2001
From: carl at bl.echidna.id.au (carl at bl.echidna.id.au)
Date: Thu, 13 Dec 2001 13:34:32 +1100 (EST)
Subject: hang on exit bug under Linux
Message-ID: <200112130234.fBD2YWcU017575@rollcage.bl.echidna.id.au>


> From: Peter Stuge <stuge at cdy.org>
> 
> The true solution is considered to be one of two things:
> 
> 1. All daemons shall behave.  (ie. close std*)

Ideally, but not likely :(

> 2. The user knows what he/she wants.  (ie. to exit, loosing data)
> 
> I actually want both.  I want to be able to tell sloppy daemon programmers
> that they should clean up their code.  But I also want my users to not have
> to deal with sloppy daemon programmers, unless they choose to do so.
> This is tough.

Could it be done at the command line?  ssh -bad-daemon foohost ?

We have to restart Firewall-1 and IDS probes with closed source
all the time using ssh.  Having the ability to do so without
totally hosing things is a big plus.  It's not something I can
script around either.

> A thought that occured in my mind tonight while thinking about this is that
> the ssh client could background itself and tell the user about it, instead
> of closing down and causing possible data loss.  And it needs to leave std*
> open, ie. not daemonize, but background.  This would propagate over multiple
> connections all the way back to my actual terminal.  And if I choose to
> close my terminal (xterm, console, whatever) the process that I started at
> remotehost will be sent SIGHUP.  In the perl case it would kill it, a C
> program that catches the signal doesn't care and keeps running.  Data will
> be lost but that is out of SSH scope.
> 
> Comments on this, anyone?

Is it too hard to have a command line switch (or config option) to say
"lossy/not lossy" ?  It's because of this problem that I'm still stuck
with a lot of firewalls still running ssh v1 :(

Carl



From stuge at cdy.org  Thu Dec 13 13:44:25 2001
From: stuge at cdy.org (Peter Stuge)
Date: Thu, 13 Dec 2001 03:44:25 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112130234.fBD2YWcU017575@rollcage.bl.echidna.id.au>; from carl@bl.echidna.id.au on Thu, Dec 13, 2001 at 01:34:32PM +1100
References: <200112130234.fBD2YWcU017575@rollcage.bl.echidna.id.au>
Message-ID: <20011213034424.B16141@foo.birdnet.se>

On Thu, Dec 13, 2001 at 01:34:32PM +1100, carl at bl.echidna.id.au wrote:
> 
> Is it too hard to have a command line switch (or config option) to say
> "lossy/not lossy" ?  It's because of this problem that I'm still stuck
> with a lot of firewalls still running ssh v1 :(

You wouldn't need the option if the ssh client put itself in the background.


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From carl at bl.echidna.id.au  Thu Dec 13 13:49:48 2001
From: carl at bl.echidna.id.au (carl at bl.echidna.id.au)
Date: Thu, 13 Dec 2001 13:49:48 +1100 (EST)
Subject: behaviour of ssh/scp over flakey links - timeout/retry?
Message-ID: <200112130249.fBD2nmOb017652@rollcage.bl.echidna.id.au>


> From: "Dan Kaminsky" <dan at doxpara.com>
> 
> > Yep, the connection is to a few IDS probes that are behind flakey
> > switches and overloaded LANs.  We get a lot of dropped sessions.
> 
> Hmmm.  There's an interesting third option that attempts to stream all files
> directly to a backend aggregator, using the file system only as a cache in
> case connectivity is lost, if at all.
> 
> What's the datarate of each of your probes, worstcase?

I'm not sure, I'm not involved in that part of the system
much.  



From carl at bl.echidna.id.au  Thu Dec 13 13:52:09 2001
From: carl at bl.echidna.id.au (carl at bl.echidna.id.au)
Date: Thu, 13 Dec 2001 13:52:09 +1100 (EST)
Subject: hang on exit bug under Linux
Message-ID: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au>


> From: Peter Stuge <stuge at cdy.org>
> 
> On Thu, Dec 13, 2001 at 01:34:32PM +1100, carl at bl.echidna.id.au wrote:
> > 
> > Is it too hard to have a command line switch (or config option) to say
> > "lossy/not lossy" ?  It's because of this problem that I'm still stuck
> > with a lot of firewalls still running ssh v1 :(
> 
> You wouldn't need the option if the ssh client put itself in the background.

so if I did 

ssh firewall
firewall$ fwstop; fwstart
exit

It wouldn't hang in that instance?



From stuge at cdy.org  Thu Dec 13 13:59:24 2001
From: stuge at cdy.org (Peter Stuge)
Date: Thu, 13 Dec 2001 03:59:24 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au>; from carl@bl.echidna.id.au on Thu, Dec 13, 2001 at 01:52:09PM +1100
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au>
Message-ID: <20011213035924.C16141@foo.birdnet.se>

On Thu, Dec 13, 2001 at 01:52:09PM +1100, carl at bl.echidna.id.au wrote:
> 
> > You wouldn't need the option if the ssh client put itself in the background.
> 
> so if I did 
> 
> ssh firewall
> firewall$ fwstop; fwstart
> exit
> 
> It wouldn't hang in that instance?

The ssh client process would linger, but in the background.  It would be the
equivalent of doing ^Z and then typing bg with the current OpenSSH version.

You would be back at the prompt where you typed "ssh firewall"..


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From carl at bl.echidna.id.au  Thu Dec 13 14:04:27 2001
From: carl at bl.echidna.id.au (carl at bl.echidna.id.au)
Date: Thu, 13 Dec 2001 14:04:27 +1100 (EST)
Subject: hang on exit bug under Linux
Message-ID: <200112130304.fBD34RlE017733@rollcage.bl.echidna.id.au>

> From: Peter Stuge <stuge at cdy.org>
> 
> On Thu, Dec 13, 2001 at 01:52:09PM +1100, carl at bl.echidna.id.au wrote:
> > 
> > > You wouldn't need the option if the ssh client put itself in the background.
> > 
> > so if I did 
> > 
> > ssh firewall
> > firewall$ fwstop; fwstart
> > exit
> > 
> > It wouldn't hang in that instance?
> 
> The ssh client process would linger, but in the background.  It would be the
> equivalent of doing ^Z and then typing bg with the current OpenSSH version.
> 
> You would be back at the prompt where you typed "ssh firewall"..

Does that solve the problem?  Wouldn't I then end up with, over
time, a stack of these ssh client sessions?

I guess I could kill -KILL them? :)

Carl



From mouring at etoh.eviladmin.org  Thu Dec 13 14:06:46 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 12 Dec 2001 21:06:46 -0600 (CST)
Subject: hang on exit bug under Linux
In-Reply-To: <20011213035924.C16141@foo.birdnet.se>
Message-ID: <Pine.BSO.4.33.0112122105440.5548-100000@etoh.eviladmin.org>


On Thu, 13 Dec 2001, Peter Stuge wrote:

> On Thu, Dec 13, 2001 at 01:52:09PM +1100, carl at bl.echidna.id.au wrote:
> >
> > > You wouldn't need the option if the ssh client put itself in the background.
> >
> > so if I did
> >
> > ssh firewall
> > firewall$ fwstop; fwstart
> > exit
> >
> > It wouldn't hang in that instance?
>
> The ssh client process would linger, but in the background.  It would be the
> equivalent of doing ^Z and then typing bg with the current OpenSSH version.
>
> You would be back at the prompt where you typed "ssh firewall"..
>
>
UGH No.

It would be bad enough the server side sshd hangs and wastes resources.
It would be even worse if both did.

- Ben



From stuge at cdy.org  Thu Dec 13 14:16:12 2001
From: stuge at cdy.org (Peter Stuge)
Date: Thu, 13 Dec 2001 04:16:12 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <200112130304.fBD34RlE017733@rollcage.bl.echidna.id.au>; from carl@bl.echidna.id.au on Thu, Dec 13, 2001 at 02:04:27PM +1100
References: <200112130304.fBD34RlE017733@rollcage.bl.echidna.id.au>
Message-ID: <20011213041611.D16141@foo.birdnet.se>

On Thu, Dec 13, 2001 at 02:04:27PM +1100, carl at bl.echidna.id.au wrote:
> > > 
> > > ssh firewall
> > > firewall$ fwstop; fwstart
> > > exit
> > > 
> > > It wouldn't hang in that instance?
> > 
> > The ssh client process would linger, but in the background.  It would be the
> > equivalent of doing ^Z and then typing bg with the current OpenSSH version.
> > 
> > You would be back at the prompt where you typed "ssh firewall"..
> 
> Does that solve the problem?  Wouldn't I then end up with, over
> time, a stack of these ssh client sessions?

No.  Try it.  When you (eventually) close the (say, xterm) session the ssh
client will be killed.  And the sshd on the other side will too.  Or at
least that's what happens here with my 2.9.9p2.  Left is my perl script. 
And data is lost.  But it's not at the fault of OpenSSH, but of me.


> I guess I could kill -KILL them? :)

You could do that too.  Or just SIGTERM, that works too.


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From stuge at cdy.org  Thu Dec 13 14:28:31 2001
From: stuge at cdy.org (Peter Stuge)
Date: Thu, 13 Dec 2001 04:28:31 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <Pine.BSO.4.33.0112122105440.5548-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Wed, Dec 12, 2001 at 09:06:46PM -0600
References: <20011213035924.C16141@foo.birdnet.se> <Pine.BSO.4.33.0112122105440.5548-100000@etoh.eviladmin.org>
Message-ID: <20011213042831.E16141@foo.birdnet.se>

On Wed, Dec 12, 2001 at 09:06:46PM -0600, mouring at etoh.eviladmin.org wrote:
> 
> > The ssh client process would linger, but in the background.  It would be the
> > equivalent of doing ^Z and then typing bg with the current OpenSSH version.
> >
> > You would be back at the prompt where you typed "ssh firewall"..
> >
> >
> UGH No.
> 
> It would be bad enough the server side sshd hangs and wastes resources.
> It would be even worse if both did.

If data loss isn't going to be the price to pay for bad code, something else
has to be.  Besides, the client (and server) will only linger until the
parent xterm exits..

A strong point is that this shoves the problem off to someone else, leaving
all of us to do something else.  We shouldn't really be dealing with it in
the first place.  It's a broken world and we can't easily fix anything on
the other side of our doorstep..


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From rob at hagopian.net  Thu Dec 13 15:10:47 2001
From: rob at hagopian.net (Rob Hagopian)
Date: Wed, 12 Dec 2001 23:10:47 -0500 (EST)
Subject: connect to bass.directhit.com(65.214.36.12):2401 failed: Connection
 refused
In-Reply-To: <87n10o3n7a.fsf@boggy.acest.tutrp.tut.ac.jp>
Message-ID: <Pine.LNX.4.33.0112122310280.8027-100000@karma.hagopian.net>

I'll look into this in the morning...
								-Rob

On 12 Dec 2001, NAKAJI Hiroyuki wrote:

> Hi,
>
> According to http://www.openssh.com/portable.html, I tried to update my
> openssh_cvs tree by CVS. And got an error.
>
> $ cvs update -dP
> cvs [update aborted]: connect to bass.directhit.com(65.214.36.12):2401 failed: Connection refused
>
> Why? And from which cvs pserver can I get the latest openssh-portable?
>
> Thanks.
>



From nakaji at tutrp.tut.ac.jp  Thu Dec 13 17:31:36 2001
From: nakaji at tutrp.tut.ac.jp (NAKAJI Hiroyuki)
Date: 13 Dec 2001 15:31:36 +0900
Subject: 3.0.2p1 on mips-sony-bsd
Message-ID: <87n10n3a2f.fsf@boggy.acest.tutrp.tut.ac.jp>

Hi,

A little change of openbsd-compat/readpassphrase.c is needed for the
target mips-sony-bsd, which has VSTATUS defined in termios.h but not have
_POSIX_VDISABLE nor VDISABLE in termios.h.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-3.0.2p1.diff
Type: application/octet-stream
Size: 597 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011213/77af7139/attachment.obj 
-------------- next part --------------
-- 
NAKAJI Hiroyuki

From Nicolas.Williams at ubsw.com  Thu Dec 13 18:13:56 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 13 Dec 2001 02:13:56 -0500
Subject: Solution? (was Re: hang on exit bug under Linux)
In-Reply-To: <200112130234.fBD2YWcU017575@rollcage.bl.echidna.id.au>; from carl@bl.echidna.id.au on Thu, Dec 13, 2001 at 01:34:32PM +1100
References: <200112130234.fBD2YWcU017575@rollcage.bl.echidna.id.au>
Message-ID: <20011213021356.F3807@wdr.com>

On Thu, Dec 13, 2001 at 01:34:32PM +1100, carl at bl.echidna.id.au wrote:
> 
> > From: Peter Stuge <stuge at cdy.org>
> > 
> > The true solution is considered to be one of two things:
> > 
> > 1. All daemons shall behave.  (ie. close std*)
> 
> Ideally, but not likely :(
> 
> > 2. The user knows what he/she wants.  (ie. to exit, loosing data)
> > 
> > I actually want both.  I want to be able to tell sloppy daemon programmers
> > that they should clean up their code.  But I also want my users to not have
> > to deal with sloppy daemon programmers, unless they choose to do so.
> > This is tough.
> 
> Could it be done at the command line?  ssh -bad-daemon foohost ?

I think the solution is to have a client-side option to specify the
behaviour of the client when the number of live sessions goes down to 0.
The behaviour could be any of:

 - wait for channels to close ("hang")
 - background the client
 - pass SIGHUP to the session(s) that still have open channels (sshd
   should do a killpg() in response)
 - force the closure of remaining channels and exit, possibly doing this
   after the expiration of a timer

The key thing to understand here is that SSHv2 is *very* different from
SSHv1.

SSHv2 allows the use of multiple sessions in one SSH connection. And
even when there are no live sessions the client could still initiate new
ones. Thus, to fully suport the protocol, the server must not
unilaterally drop SSHv2 connections.

So what is needed to satisfy the howlers is to provide an option as
described above.

DISCLAIMER: I'm not an expert on SSHv2, nor am I involved in the
OpenSSH effort other than as a user and occasional contributor on this
list -- so I may be wrong. Ben? Markus?

> Is it too hard to have a command line switch (or config option) to say
> "lossy/not lossy" ?  It's because of this problem that I'm still stuck
> with a lot of firewalls still running ssh v1 :(

No, I don't think it is too much. The key though, is to undersand that
this is an issue of the client's behaviour. An option to say "hey, I'd
do an ~. when the session leader exits, so just do it and save me the
bother".

> Carl


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 johnh at aproposretail.com  Fri Dec 14 03:30:57 2001
From: johnh at aproposretail.com (John Hardin)
Date: 13 Dec 2001 08:30:57 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011213035924.C16141@foo.birdnet.se>
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> 
	<20011213035924.C16141@foo.birdnet.se>
Message-ID: <1008261058.2212.4.camel@johnh.apropos.com>

On Wed, 2001-12-12 at 18:59, Peter Stuge wrote:
> The ssh client process would linger, but in the background.  It would be the
> equivalent of doing ^Z and then typing bg with the current OpenSSH version.
> 
> You would be back at the prompt where you typed "ssh firewall"..

...so you're saying having a "hung" ssh session is okay if it's
backgrounded?

-- 
John Hardin                                   <johnh at aproposretail.com>
Internal Systems Administrator                    voice: (425) 672-1304
Apropos Retail Management Systems, Inc.             fax: (425) 672-0192
-----------------------------------------------------------------------
 "...in retrospect, we probably should have turned it on by default."
     - Craig Mundie, Microsoft CTO, on shipping Windows XP with the
       much-hyped "Internet Connection Firewall" turned off by default
-----------------------------------------------------------------------
 Today: Geminid meteor shower



From wichert at wiggy.net  Fri Dec 14 03:35:49 2001
From: wichert at wiggy.net (Wichert Akkerman)
Date: Thu, 13 Dec 2001 17:35:49 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <1008261058.2212.4.camel@johnh.apropos.com>
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com>
Message-ID: <20011213163549.GA8500@wiggy.net>

Previously John Hardin wrote:
> ...so you're saying having a "hung" ssh session is okay if it's
> backgrounded?

It is if the backgrounded program has not disconnected itself from
the pty.

Wichert.

-- 
  _________________________________________________________________
 /wichert at wiggy.net         This space intentionally left occupied \
| wichert at deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


From stuge at cdy.org  Fri Dec 14 11:58:42 2001
From: stuge at cdy.org (Peter Stuge)
Date: Fri, 14 Dec 2001 01:58:42 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <20011213163549.GA8500@wiggy.net>; from wichert@wiggy.net on Thu, Dec 13, 2001 at 05:35:49PM +0100
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net>
Message-ID: <20011214015841.H16141@foo.birdnet.se>

On Thu, Dec 13, 2001 at 05:35:49PM +0100, Wichert Akkerman wrote:
> Previously John Hardin wrote:
> > ...so you're saying having a "hung" ssh session is okay if it's
> > backgrounded?
> 
> It is if the backgrounded program has not disconnected itself from
> the pty.

My point exactly.  And nothing has hung.  The client is lingering, waiting
for all remote tasks to complete.  This is the same behaviour you get if you
set SO_LINGER on a socket.  Check out socket(7)..  If/when the program in
the background (on remotehost) exits, the ssh client and the sshd on the
server will also exit.  And if the xterm (or virtual console) gets closed,
the ssh client will be killed off, as the sshd on remotehost.  If the
backgrounded program on remotehost catches HUP it will stay alive, but any
data output from it will be lost.  That's however hard to change from within
ssh.

Now off to code up this patch.  Or at least I'll try, had a look at some of
the code yesterday too but didn't get anywhere..


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From Nicolas.Williams at ubsw.com  Fri Dec 14 12:19:15 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 13 Dec 2001 20:19:15 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011214015841.H16141@foo.birdnet.se>; from Peter Stuge on Fri, Dec 14, 2001 at 01:58:42AM +0100
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net> <20011214015841.H16141@foo.birdnet.se>
Message-ID: <20011213201915.G3807@wdr.com>

On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> On Thu, Dec 13, 2001 at 05:35:49PM +0100, Wichert Akkerman wrote:
> > Previously John Hardin wrote:
> > > ...so you're saying having a "hung" ssh session is okay if it's
> > > backgrounded?
> > 
> > It is if the backgrounded program has not disconnected itself from
> > the pty.
> 
> My point exactly.  And nothing has hung.  The client is lingering, waiting
> for all remote tasks to complete.  This is the same behaviour you get if you
> set SO_LINGER on a socket.  Check out socket(7)..  If/when the program in
> the background (on remotehost) exits, the ssh client and the sshd on the
> server will also exit.  And if the xterm (or virtual console) gets closed,
> the ssh client will be killed off, as the sshd on remotehost.  If the
> backgrounded program on remotehost catches HUP it will stay alive, but any
> data output from it will be lost.  That's however hard to change from within
> ssh.
> 
> Now off to code up this patch.  Or at least I'll try, had a look at some of
> the code yesterday too but didn't get anywhere..

Cool.

You need options processing code (readconf.c) and session-exit
processing code. When the client gets a session-exit message, and that
was the last session still "alive", then do as the user wanted. The
things to do could be many, as I've suggested before and as I'll repeat:

 - do nothing ("hang" until the session's channels are closed)
 - background the client (what you suggest)
 - force the channels closed and exit (what many users want)
 - pass a SIGHUP to the session in question (reading the drafts this can
   be done because the session exit message is really associated with the
   session's channel, therefore, though the session has exited it
   continues to exist until the channels are closed. The server should
   kill the process group of the session leader whose exiting elicited
   the session-exit message).

You needn't implement all of those options. The first two will do for
you, apparently, so implement that. The others can be added later.


> //Peter
> 

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 michael at bizsystems.com  Fri Dec 14 13:56:49 2001
From: michael at bizsystems.com (Michael)
Date: Thu, 13 Dec 2001 18:56:49 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011213201915.G3807@wdr.com>
References: <20011214015841.H16141@foo.birdnet.se>; from Peter Stuge on Fri, Dec 14, 2001 at 01:58:42AM +0100
Message-ID: <200112140256.SAA29301@ns2.bizsystems.net>

> On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> > On Thu, Dec 13, 2001 at 05:35:49PM +0100, Wichert Akkerman wrote:
> > > Previously John Hardin wrote:
> > > > ...so you're saying having a "hung" ssh session is okay if it's
> > > > backgrounded?
> > > 
> > > It is if the backgrounded program has not disconnected itself from
> > > the pty.
> > 
> > My point exactly.  And nothing has hung.  The client is lingering, waiting
> > for all remote tasks to complete.  This is the same behaviour you get if you
> > set SO_LINGER on a socket.  Check out socket(7)..  If/when the program in
> > the background (on remotehost) exits, the ssh client and the sshd on the
> > server will also exit.  And if the xterm (or virtual console) gets closed,
> > the ssh client will be killed off, as the sshd on remotehost.  If the
> > backgrounded program on remotehost catches HUP it will stay alive, but any
> > data output from it will be lost.  That's however hard to change from within
> > ssh.
> > 
> > Now off to code up this patch.  Or at least I'll try, had a look at some of
> > the code yesterday too but didn't get anywhere..
> 
> Cool.
> 
> You need options processing code (readconf.c) and session-exit
> processing code. When the client gets a session-exit message, and
> that was the last session still "alive", then do as the user wanted.
> The things to do could be many, as I've suggested before and as I'll
> repeat:
> 
>  - do nothing ("hang" until the session's channels are closed)
>  - background the client (what you suggest)
>  - force the channels closed and exit (what many users want)
>  - pass a SIGHUP to the session in question (reading the drafts this
>  can
>    be done because the session exit message is really associated
>    with the session's channel, therefore, though the session has
>    exited it continues to exist until the channels are closed. The
>    server should kill the process group of the session leader whose
>    exiting elicited the session-exit message).
> 
> You needn't implement all of those options. The first two will do
> for you, apparently, so implement that. The others can be added
> later.
> 

The behavior may be different for V1 vs V2

The old V1 behavior simply exits unconditionally -- whereas V2 waits 
and presumably would be altered by the proposed modification
or....
are V1 and V2 to operate in the same manner???

Michael at bizsystems.com


From Nicolas.Williams at ubsw.com  Fri Dec 14 16:51:21 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 14 Dec 2001 00:51:21 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <200112140256.SAA29301@ns2.bizsystems.net>; from Michael on Thu, Dec 13, 2001 at 06:56:49PM -0800
References: <20011214015841.H16141@foo.birdnet.se>; <20011213201915.G3807@wdr.com> <200112140256.SAA29301@ns2.bizsystems.net>
Message-ID: <20011214005121.H3807@wdr.com>

On Thu, Dec 13, 2001 at 06:56:49PM -0800, Michael wrote:
> > On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> > > Now off to code up this patch.  Or at least I'll try, had a look at some of
> > > the code yesterday too but didn't get anywhere..
> > 
> > Cool.
> > 
> > You need options processing code (readconf.c) and session-exit
> > processing code. When the client gets a session-exit message, and
> > that was the last session still "alive", then do as the user wanted.
> > The things to do could be many, as I've suggested before and as I'll
> > repeat:

[...]

> The behavior may be different for V1 vs V2
> 
> The old V1 behavior simply exits unconditionally -- whereas V2 waits 
> and presumably would be altered by the proposed modification
> or....
> are V1 and V2 to operate in the same manner???

SSHv1 and SSHv2 are radically different in this area. The v1 behaviour
cannot be modified. But with v2, the client makes the decision of when
to quit, either by letting the user make the decision (~.) or by knowing
ahead of time what the user would have the client do (hang, background,
~., SIGHUP).

So this would clearly be a SSHv2-only option.


> Michael at bizsystems.com


Correct me if I'm wrong.

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 stuge at cdy.org  Sat Dec 15 04:10:59 2001
From: stuge at cdy.org (Peter Stuge)
Date: Fri, 14 Dec 2001 18:10:59 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <20011214015841.H16141@foo.birdnet.se>; from stuge@cdy.org on Fri, Dec 14, 2001 at 01:58:42AM +0100
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net> <20011214015841.H16141@foo.birdnet.se>
Message-ID: <20011214181059.A12650@foo.birdnet.se>

On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> 
> Now off to code up this patch.  Or at least I'll try, had a look at some of
> the code yesterday too but didn't get anywhere..

Ok.  Here we go.  It's not very complicated but it took me some time to get
familiar with all the code, which is very easy to read, kudos to all!
And after finishing it, I fell alseep.  Ohwell.

For this to work as desired the sshd must send the SSH_MSG_CHANNEL_CLOSE
message fast enough for the client to buffer it together with the
CHANNEL_REQ "exit-status", so that CHAN_CLOSE_RCVD is set in the channel
flags when client_process_buffered_input_packets() returns.  If this isn't
acceptable/practical the only alternative I can see is to set a time limit.

The case I'm trying to handle here is "exit-status received for this
channel, but no SSH_MSG_CHANNEL_CLOSE" - when is that a fact?  Sure, if some
other packet than _CHANNEL_EOF or _CHANNEL_CLOSE is received, I'll know.
And I implemented that first, using a dispatch_preprocess function that
would be run before the message handler. But that doesn't cut it when there
simply aren't any packets arriving..

On top of this, much to my disappointment, a backgrounded ssh didn't get
killed when I closed my xterm.  But if it lingers it gets killed.  This is
because bash sends SIGHUP to all jobs when it is exiting.  But since the ssh
fork()s, it's no longer considered to be a job.  Hmm.  I tried putting a
call to setpgrp() and then setsid() in the fork()ed off child, but that
didn't make any difference, obviously I guess.  Is what I want even
possible?

Tell me if I've done something wrong in the patch.  It makes ssh in any case
tell the user about what is happening and why, wheter it lingers, goes to
background or terminates.


//Peter

-- 
irc: CareBear\
irl: Peter Stuge
-------------- next part --------------
diff -r -U 3 openssh-3.0.2p1/clientloop.c openssh-3.0.2p1-linger/clientloop.c
--- openssh-3.0.2p1/clientloop.c	Mon Nov 12 01:06:33 2001
+++ openssh-3.0.2p1-linger/clientloop.c	Fri Dec 14 18:07:20 2001
@@ -779,6 +779,9 @@
 	double start_time, total_time;
 	int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0;
 	char buf[100];
+	Channel *c;
+	int check_linger = 1;
+	pid_t pid;
 
 	debug("Entering interactive session.");
 
@@ -847,6 +850,36 @@
 
 		/* Process buffered packets sent by the server. */
 		client_process_buffered_input_packets();
+
+		if (exit_status != -1 && check_linger) {
+			check_linger = 0;
+			c = channel_lookup(ssh2_chan_id);
+			if (c && !(c->flags & CHAN_CLOSE_RCVD))
+				switch (options.on_linger) {
+				case 0:
+					error("[lingering due to open channel]");
+					break;
+				case 1:
+					error("[backgrounding client with open channels]");
+					leave_raw_mode();
+					channel_stop_listening();
+					pid = fork();
+					if (pid < 0) {
+						error("fork: %.100s", strerror(errno));
+						break;
+					}
+					if (pid != 0)
+						exit(0);
+					buffer_append(&stdin_buffer , "\004", 1);
+					break;
+				case 2:
+					error("[terminating client with open channels - data will be lost]");
+					quit_pending = 1;
+					break;
+				default:
+					fatal("unknown action OnLinger=%d",options.on_linger);
+				}
+		}
 
 		if (compat20 && session_closed && !channel_still_open())
 			break;
diff -r -U 3 openssh-3.0.2p1/readconf.c openssh-3.0.2p1-linger/readconf.c
--- openssh-3.0.2p1/readconf.c	Wed Oct  3 19:39:39 2001
+++ openssh-3.0.2p1-linger/readconf.c	Fri Dec 14 08:58:04 2001
@@ -115,7 +115,8 @@
 	oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias,
 	oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication,
 	oHostKeyAlgorithms, oBindAddress, oSmartcardDevice,
-	oClearAllForwardings, oNoHostAuthenticationForLocalhost 
+	oClearAllForwardings, oNoHostAuthenticationForLocalhost,
+	oOnLinger
 } OpCodes;
 
 /* Textual representations of the tokens. */
@@ -187,6 +188,7 @@
 	{ "smartcarddevice", oSmartcardDevice },
 	{ "clearallforwardings", oClearAllForwardings }, 
 	{ "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, 
+	{ "onlinger", oOnLinger },
 	{ NULL, 0 }
 };
 
@@ -678,6 +680,25 @@
 			*intptr = value;
 		break;
 
+	case oOnLinger:
+		intptr = &options->on_linger;
+		arg = strdelim(&s);
+		if (!arg || *arg == '\0')
+			fatal("%.200s line %d: Missing linger/background/dataloss argument.",
+			      filename, linenum);
+		value = 0;	/* To avoid compiler warning... */
+		if (strcmp(arg, "linger") == 0)
+			value = 0;
+		else if (strcmp(arg, "background") == 0)
+			value = 1;
+		else if (strcmp(arg, "dataloss") == 0)
+			value = 2;
+		else
+			fatal("%.200s line %d: Bad linger/background/dataloss argument.", filename, linenum);
+		if (*activep && *intptr == -1)
+			*intptr = value;
+		break;
+
 	default:
 		fatal("process_config_line: Unimplemented opcode %d", opcode);
 	}
@@ -799,6 +820,7 @@
 	options->bind_address = NULL;
 	options->smartcard_device = NULL;
 	options->no_host_authentication_for_localhost = - 1;
+	options->on_linger = -1;
 }
 
 /*
@@ -919,6 +941,8 @@
 		clear_forwardings(options);
 	if (options->no_host_authentication_for_localhost == - 1)
 		options->no_host_authentication_for_localhost = 0;
+	if (options->on_linger == -1)
+		options->on_linger = 0;
 	/* options->proxy_command should not be set by default */
 	/* options->user will be set in the main program if appropriate */
 	/* options->hostname will be set in the main program if appropriate */
diff -r -U 3 openssh-3.0.2p1/readconf.h openssh-3.0.2p1-linger/readconf.h
--- openssh-3.0.2p1/readconf.h	Wed Oct  3 19:39:39 2001
+++ openssh-3.0.2p1-linger/readconf.h	Fri Dec 14 08:57:24 2001
@@ -102,6 +102,8 @@
 	Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION];
 	int	clear_forwardings;
 	int	no_host_authentication_for_localhost;
+
+	int	on_linger;
 }       Options;
 
 
diff -r -U 3 openssh-3.0.2p1/ssh.0 openssh-3.0.2p1-linger/ssh.0
--- openssh-3.0.2p1/ssh.0	Sun Dec  2 00:38:46 2001
+++ openssh-3.0.2p1-linger/ssh.0	Fri Dec 14 09:57:09 2001
@@ -619,6 +619,18 @@
              Specifies the number of password prompts before giving up.  The
              argument to this keyword must be an integer.  Default is 3.
 
+     OnLinger
+             Specifies what action to take when a user tries to log out and
+             there are background processes on the remote host whose stdin,
+             stdout or stderr are open and unredirected.  If this flag is set
+             to `linger'', ssh will wait until the remote file descripts are
+             closed.  If this flag is set to `background'', ssh will put it-
+             self in the background and no data will be lost.  If this flag is
+             set to `dataloss'', ssh will terminate and any data from the re-
+             mote background process will be lost.  The argument must be
+             `linger'', `background'' or `dataloss''. The default is
+             `linger''.
+
      PasswordAuthentication
              Specifies whether to use password authentication.  The argument
              to this keyword must be ``yes'' or ``no''.  The default is
diff -r -U 3 openssh-3.0.2p1/ssh.1 openssh-3.0.2p1-linger/ssh.1
--- openssh-3.0.2p1/ssh.1	Mon Nov 12 01:05:49 2001
+++ openssh-3.0.2p1-linger/ssh.1	Fri Dec 14 09:24:41 2001
@@ -995,6 +995,28 @@
 Specifies the number of password prompts before giving up.
 The argument to this keyword must be an integer.
 Default is 3.
+.It Cm OnLinger
+Specifies what action to take when a user tries to log out and there are
+background processes on the remote host whose stdin, stdout or stderr are
+open and unredirected.  If this flag is set to
+.Dq linger ,
+.Nm
+will wait until the remote file descripts are closed.  If this flag is set
+to
+.Dq background , 
+.Nm
+will put itself in the background and no data will be lost.  If this flag
+is set to
+.Dq dataloss , 
+.Nm
+will terminate and any data from the remote background process will be lost.
+The argument must be
+.Dq linger ,
+.Dq background
+or
+.Dq dataloss .
+The default is
+.Dq linger .
 .It Cm PasswordAuthentication
 Specifies whether to use password authentication.
 The argument to this keyword must be

From toddr at rpi.edu  Sat Dec 15 06:38:10 2001
From: toddr at rpi.edu (R. Lindsay Todd)
Date: Fri, 14 Dec 2001 14:38:10 -0500
Subject: PATCH: OpenSSH 3.0.2p1 on Solaris + Kerberos + AFS
Message-ID: <3C1A5522.3000404@rpi.edu>

Compiling OpenSSH 3.0.2p1 on Solaris 2.8, enabling both Kerberos 4 and
AFS, leads to some compilation difficulties.  Some structures in
sys/ioctl.h are used for AFS, but are defined in sys/ioccom.h, which has
not been included.  The attached patch causes configure to search for
this file and include it if found.  The resulting patched code still
compiles under Linux, AIX, and Irix, as well as builds on Solaris.

NB.  I do not have the exact same version of autoconf that was used to
build the OpenSSH distribution, so I have hand-patched changes to configure.

-- 
R. Lindsay Todd                          email: toddr at rpi.edu
Senior Systems Programmer                phone: 518-276-2605
Rensselaer Polytechnic Institute         fax:   518-276-2809
Troy, NY 12180-3590                      WWW:   http://www.rpi.edu/~toddr


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-solaris.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011214/4cfbb4df/attachment.ksh 

From toddr at rpi.edu  Sat Dec 15 06:39:12 2001
From: toddr at rpi.edu (R. Lindsay Todd)
Date: Fri, 14 Dec 2001 14:39:12 -0500
Subject: PATCH: OpenSSH 3.0.2p1 + Kerberos 4 on Irix 6.5
Message-ID: <3C1A5560.5060906@rpi.edu>

There are conflicts between the krb.h and crypt.h on Irix 6.5 in
auth-passwd.c.  Since auth-passwd does not need krb.h, we can avoid
these conflicts.  The attached patch provides a little preprocessor
magic to fix this.  The resulting code still compiles on Solaris 2.8,
AIX 4.3.3, and RedHat Linux 7.2.

-- 
R. Lindsay Todd                          email: toddr at rpi.edu
Senior Systems Programmer                phone: 518-276-2605
Rensselaer Polytechnic Institute         fax:   518-276-2809
Troy, NY 12180-3590                      WWW:   http://www.rpi.edu/~toddr


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-irix.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011214/03b54566/attachment.ksh 

From toddr at rpi.edu  Sat Dec 15 07:27:31 2001
From: toddr at rpi.edu (R. Lindsay Todd)
Date: Fri, 14 Dec 2001 15:27:31 -0500
Subject: PATCH: Kerberos password authentication w/o KDC verification
Message-ID: <3C1A60B3.300@rpi.edu>

Folks: We use an old AFS cell with Kerberos 4.  Our use of Kerberos 4 is 
fairly limited; we have never needed to  implement rcmd host principals 
for most of our systems.  Indeed, given that Kerberos 4 strips off the 
domain name portion of a hostname when determining the rcmd instance, we 
would not be able to do this, since we do have duplicate hostnames in 
multiple subdomains.

For AFS password authentication, OpenSSH first does Kerberos password 
authentication.  It then attempts to get a ticket for the server's rcmd 
service, in order to verify that the KDC is not being spoofed.  Of 
course, this fails if you do not have an rcmd service key.

For most of RPI's systems, those running Linux, Solaris, or AIX, this is 
not a problem.  OpenSSH uses PAM on Linux and Solaris, and AIX 
"authenticate" on AIX.  These external systems do not verify the KDC; if 
you submit a correct Kerberos/AFS password, it will grant you tickets. 
 You do not need an rcmd key.  However, our SGI Irix systems actually 
use the built-in auth-kerb4 authentication.  Since we do not have rcmd 
keys, password authentication fails.

I am sure that verifying the KDC is a good thing to do... But in our 
case, it causes difficulties.  Verifying the KDC is not consistently 
enforced, anyway.  So the attached patch provides a way to turn it off. 
 I have implemented a server configuration option, KerberosVerifyServer, 
that defaults to "yes".  If it is true, then the KDC is verified, as 
currently happens.  If it set to "no", then the behaviour I need, of not 
verifying the KDC, is provided.

 From our point of view, it would be a nice thing if this became a 
standard feature of OpenSSH.

-- 
R. Lindsay Todd                          email: toddr at rpi.edu
Senior Systems Programmer                phone: 518-276-2605
Rensselaer Polytechnic Institute         fax:   518-276-2809
Troy, NY 12180-3590                      WWW:   http://www.rpi.edu/~toddr

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-kerberos-verify-server.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011214/6403445d/attachment.ksh 

From jan.iven at cern.ch  Sat Dec 15 08:47:57 2001
From: jan.iven at cern.ch (Jan IVEN)
Date: 14 Dec 2001 22:47:57 +0100
Subject: problem with AFS token forwarding
In-Reply-To: <3BFA06DF.9A4AD658@psi.ch>
References: <Pine.LNX.4.33.0111200620210.4649-100000@bergson.bibliothek.tu-chemnitz.de>
	<3BFA06DF.9A4AD658@psi.ch>
Message-ID: <unm1yhxpj76.fsf@asis-w2.cern.ch>

Serge,

I have taken your "early AFS token forwarding" patch and extended it
to cover KRB4 TGTs as well. It also prevents the "failed login" count
from being increased. Maybe you are interested...

A second patch fixes a SEGV during KRB4-based login (double free() on
the client name in case .klogin fails, one in auth-krb4.c, the other
in do_authloop() in auth1.c...)

Best regards
Jan

diff -uw openssh-3.0.1p1/auth1.c openssh-3.0.1p1.bricol/auth1.c
--- openssh-3.0.1p1/auth1.c	Tue Nov 13 13:46:19 2001
+++ openssh-3.0.1p1.bricol/auth1.c	Fri Dec 14 17:33:12 2001
@@ -114,6 +114,31 @@
 		/* Process the packet. */
 		switch (type) {
 
+#ifdef AFS
+		case SSH_CMSG_HAVE_AFS_TOKEN:
+		        if ( options.afs_pass_token_before_auth ) {
+			   if (!options.afs_token_passing || !k_hasafs()) {
+				   verbose("AFS token passing disabled.");
+				   break;
+			   } else {
+				   /* Accept AFS token. */
+				   char *token_string = packet_get_string(&dlen);
+				   packet_integrity_check(plen, 4 + dlen, type);
+				   if (!auth_afs_token(authctxt, token_string))
+					   verbose("AFS token REFUSED for %.100s", authctxt->user);
+				   else {
+				     /* token ok, continue with real authentication */
+				     packet_start(SSH_SMSG_SUCCESS);
+				     packet_send();
+				     packet_write_wait();
+				     continue;
+				   }
+				   xfree(token_string);
+			   }
+		        } else  packet_send_debug("AFS token passing disabled before authentication.");
+			break;
+#endif /* AFS */
+
 #if defined(KRB4) || defined(KRB5)
 		case SSH_CMSG_AUTH_KERBEROS:
 			if (!options.kerberos_authentication) {
@@ -160,13 +185,49 @@
 #if defined(AFS) || defined(KRB5)
 			/* XXX - punt on backward compatibility here. */
 		case SSH_CMSG_HAVE_KERBEROS_TGT:
-			packet_send_debug("Kerberos TGT passing disabled before authentication.");
-			break;
+		    if ( options.afs_pass_token_before_auth ) {
+			if (!options.kerberos_tgt_passing) {
+				verbose("Kerberos TGT passing disabled.");
+			} else {
+				char *kdata = packet_get_string(&dlen);
+				packet_integrity_check(plen, 4 + dlen, type);
+				
+				/* XXX - 0x41, see creds_to_radix version */
+				if (kdata[0] != 0x41) {
+#ifdef KRB5
+					krb5_data tgt;
+					tgt.data = kdata;
+					tgt.length = dlen;
+					
+					if (!auth_krb5_tgt(authctxt, &tgt))
+						verbose("Kerberos v5 TGT refused for %.100s", authctxt->user);
+					else {
+					  /* tgt ok, continue with real authentica\tion */
+					  packet_start(SSH_SMSG_SUCCESS);
+					  packet_send();
+					  packet_write_wait();
+					  continue;
+					}
+#endif /* KRB5 */
+				} else {
 #ifdef AFS
-		case SSH_CMSG_HAVE_AFS_TOKEN:
-			packet_send_debug("AFS token passing disabled before authentication.");
-			break;
+					if (!auth_krb4_tgt(authctxt, kdata))
+						verbose("Kerberos v4 TGT refused for %.100s", authctxt->user);
+					else {
+					  /* token ok, continue with real authentica\tion */
+					  packet_start(SSH_SMSG_SUCCESS);
+					  packet_send();
+					  packet_write_wait();
+					  continue;
+					}
 #endif /* AFS */
+				}
+				xfree(kdata);
+			}
+		    } else packet_send_debug("Kerberos TGT passing disabled before authentication.");
+
+		    break;
+
 #endif /* AFS || KRB5 */
 			
 		case SSH_CMSG_AUTH_RHOSTS:
diff -uw openssh-3.0.1p1/readconf.c openssh-3.0.1p1.bricol/readconf.c
--- openssh-3.0.1p1/readconf.c	Wed Oct  3 19:39:39 2001
+++ openssh-3.0.1p1.bricol/readconf.c	Fri Dec 14 08:46:34 2001
@@ -103,7 +103,7 @@
 	oKerberosTgtPassing,
 #endif
 #ifdef AFS
-	oAFSTokenPassing,
+	oAFSTokenPassing,oAFSPassTokenBeforeAuth,
 #endif
 	oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward,
 	oUser, oHost, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand,
@@ -149,6 +149,7 @@
 #endif
 #ifdef AFS
 	{ "afstokenpassing", oAFSTokenPassing },
+	{ "afspasstokenbeforeauth", oAFSPassTokenBeforeAuth},
 #endif
 	{ "fallbacktorsh", oFallBackToRsh },
 	{ "usersh", oUseRsh },
@@ -372,6 +373,9 @@
 	case oAFSTokenPassing:
 		intptr = &options->afs_token_passing;
 		goto parse_flag;
+	case oAFSPassTokenBeforeAuth:
+		intptr = &options->afs_pass_token_before_auth;
+		goto parse_flag;
 #endif
 	case oFallBackToRsh:
 		intptr = &options->fallback_to_rsh;
@@ -759,6 +763,7 @@
 #endif
 #ifdef AFS
 	options->afs_token_passing = -1;
+	options->afs_pass_token_before_auth = -1;
 #endif
 	options->password_authentication = -1;
 	options->kbd_interactive_authentication = -1;
@@ -842,6 +847,8 @@
 #ifdef AFS
 	if (options->afs_token_passing == -1)
 		options->afs_token_passing = 1;
+	if (options->afs_pass_token_before_auth == -1)
+		options->afs_pass_token_before_auth = 0;
 #endif
 	if (options->password_authentication == -1)
 		options->password_authentication = 1;
diff -uw openssh-3.0.1p1/readconf.h openssh-3.0.1p1.bricol/readconf.h
--- openssh-3.0.1p1/readconf.h	Wed Oct  3 19:39:39 2001
+++ openssh-3.0.1p1.bricol/readconf.h	Fri Dec 14 08:46:34 2001
@@ -49,6 +49,7 @@
 #endif
 #ifdef AFS
 	int     afs_token_passing;	/* Try AFS token passing. */
+	int     afs_pass_token_before_auth;	/* Pass Token before Auth. */
 #endif
 	int     password_authentication;	/* Try password
 						 * authentication. */
diff -uw openssh-3.0.1p1/servconf.c openssh-3.0.1p1.bricol/servconf.c
--- openssh-3.0.1p1/servconf.c	Tue Nov 13 14:03:15 2001
+++ openssh-3.0.1p1.bricol/servconf.c	Fri Dec 14 08:46:34 2001
@@ -84,6 +84,7 @@
 #endif
 #ifdef AFS
 	options->afs_token_passing = -1;
+	options->afs_pass_token_before_auth = -1;
 #endif
 	options->password_authentication = -1;
 	options->kbd_interactive_authentication = -1;
@@ -193,6 +194,8 @@
 #ifdef AFS	
 	if (options->afs_token_passing == -1)
 		options->afs_token_passing = k_hasafs();
+	if (options->afs_pass_token_before_auth == -1)
+		options->afs_pass_token_before_auth = 0;  
 #endif
 	if (options->password_authentication == -1)
 		options->password_authentication = 1;
@@ -248,6 +251,7 @@
 #endif
 #ifdef AFS
 	sAFSTokenPassing,
+	sAFSPassTokenBeforeAuth,
 #endif
 	sChallengeResponseAuthentication,
 	sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress,
@@ -299,6 +303,7 @@
 #endif
 #ifdef AFS
 	{ "afstokenpassing", sAFSTokenPassing },
+	{ "afspasstokenbeforeauth", sAFSPassTokenBeforeAuth },
 #endif
 	{ "passwordauthentication", sPasswordAuthentication },
 	{ "kbdinteractiveauthentication", sKbdInteractiveAuthentication },
@@ -636,6 +641,9 @@
 		case sAFSTokenPassing:
 			intptr = &options->afs_token_passing;
 			goto parse_flag;
+		case sAFSPassTokenBeforeAuth:
+			intptr = &options->afs_pass_token_before_auth;
+			goto parse_flag;
 #endif
 
 		case sPasswordAuthentication:
diff -uw openssh-3.0.1p1/servconf.h openssh-3.0.1p1.bricol/servconf.h
--- openssh-3.0.1p1/servconf.h	Wed Sep 12 18:40:06 2001
+++ openssh-3.0.1p1.bricol/servconf.h	Fri Dec 14 08:46:34 2001
@@ -89,6 +89,7 @@
 #endif
 #ifdef AFS
 	int     afs_token_passing;	/* If true, permit AFS token passing. */
+	int     afs_pass_token_before_auth;	/* If true, pass AFS token before user authenticication. */
 #endif
 	int     password_authentication;	/* If true, permit password
 						 * authentication. */
diff -uw openssh-3.0.1p1/ssh.1 openssh-3.0.1p1.bricol/ssh.1
--- openssh-3.0.1p1/ssh.1	Mon Nov 12 01:05:49 2001
+++ openssh-3.0.1p1.bricol/ssh.1	Fri Dec 14 18:06:10 2001
@@ -707,6 +707,13 @@
 or
 .Dq no .
 This option applies to protocol version 1 only.
+.It Cm AFSPassTokenBeforeAuth
+Specifies whether to pass AFS tokens or KRB4 TGTs before users are authenticicated.
+The argument to this keyword must be
+.Dq yes
+or
+.Dq no .
+This option applies to protocol version 1 only.
 .It Cm BatchMode
 If set to
 .Dq yes ,
diff -uw openssh-3.0.1p1/sshconnect1.c openssh-3.0.1p1.bricol/sshconnect1.c
--- openssh-3.0.1p1/sshconnect1.c	Wed Oct 10 07:03:12 2001
+++ openssh-3.0.1p1.bricol/sshconnect1.c	Fri Dec 14 08:46:34 2001
@@ -1140,6 +1140,26 @@
 	if (type != SSH_SMSG_FAILURE)
 		packet_disconnect("Protocol error: got %d in response to SSH_CMSG_USER", type);
 	
+
+#ifdef AFS
+    if (   options.afs_pass_token_before_auth ) {
+	   /* Try Kerberos v4 TGT passing if the server supports it. */
+	   if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) &&
+		   options.kerberos_tgt_passing) {
+		   if (options.cipher == SSH_CIPHER_NONE)
+			   log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!");
+		   send_krb4_tgt();
+	   }
+	   /* Try AFS token passing if the server supports it. */
+	   if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) &&
+		   options.afs_token_passing  && k_hasafs()) {
+		   if (options.cipher == SSH_CIPHER_NONE)
+			   log("WARNING: Encryption is disabled! Token will be transmitted in the clear!");
+		   send_afs_tokens();
+	   }
+	}
+#endif /* AFS */
+	
 #ifdef KRB5
 	if ((supported_authentications & (1 << SSH_AUTH_KERBEROS)) &&
             options.kerberos_authentication) {
@@ -1256,6 +1276,7 @@
 #endif
 	
 #ifdef AFS
+    if ( !  options.afs_pass_token_before_auth ) {
 	/* Try Kerberos v4 TGT passing if the server supports it. */
 	if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) &&
 	    options.kerberos_tgt_passing) {
@@ -1270,6 +1291,7 @@
 			log("WARNING: Encryption is disabled! Token will be transmitted in the clear!");
 		send_afs_tokens();
 	}
+	}
 #endif /* AFS */
 
 	return;	/* need statement after label */
diff -uw openssh-3.0.1p1/sshd.8 openssh-3.0.1p1.bricol/sshd.8
--- openssh-3.0.1p1/sshd.8	Mon Nov 12 01:04:06 2001
+++ openssh-3.0.1p1.bricol/sshd.8	Fri Dec 14 18:05:39 2001
@@ -314,6 +314,11 @@
 Specifies whether an AFS token may be forwarded to the server.
 Default is
 .Dq yes .
+.It Cm AFSPassTokenBeforeAuth
+Specifies whether AFS tokens or KRB4 TGTs are accepted before the user
+is authenticated.
+Default is
+.Dq yes .
 .It Cm AllowGroups
 This keyword can be followed by a list of group names, separated
 by spaces.

########## auth-krb4.c double xfree() patch ###################################
--- openssh-3.0.2p1/auth-krb4.c~	Wed Jul  4 06:21:15 2001
+++ openssh-3.0.2p1/auth-krb4.c	Fri Dec 14 22:15:47 2001
@@ -253,6 +253,7 @@
 		log("Kerberos v4 .klogin authorization failed for %s to "
 		    "account %s", *client, authctxt->user);
 		xfree(*client);
+		*client = NULL;
 		return (0);
 	}
 	/* Increment the checksum, and return it encrypted with the



 


From jhawk at MIT.EDU  Sat Dec 15 09:55:04 2001
From: jhawk at MIT.EDU (John Hawkinson)
Date: Fri, 14 Dec 2001 17:55:04 -0500
Subject: PATCH: Kerberos password authentication w/o KDC verification
In-Reply-To: <3C1A60B3.300@rpi.edu>
References: <3C1A60B3.300@rpi.edu>
Message-ID: <20011214175504.G25713@multics.mit.edu>

R. Lindsay Todd <toddr at rpi.edu> wrote on Fri, 14 Dec 2001
at 15:27:31 -0500 in <3C1A60B3.300 at rpi.edu>:

> Folks: We use an old AFS cell with Kerberos 4.  Our use of Kerberos 4 is 

> I have implemented a server configuration option, KerberosVerifyServer, 
> that defaults to "yes".  If it is true, then the KDC is verified, as 
> currently happens.  If it set to "no", then the behaviour I need, of not 
> verifying the KDC, is provided.

As a Kerberos4-specific option, this should have a Kerberos4-specifc name.
I would suggets "Kerberos4VerifyServer".

Please note that this is occasionally an issue for Kerberos 5, but there
is a krb5.conf variable (verify_ap_req_nofail) to control this.

--jhawk


From michael at bizsystems.com  Sat Dec 15 10:49:05 2001
From: michael at bizsystems.com (Michael)
Date: Fri, 14 Dec 2001 15:49:05 -0800
Subject: hang on exit bug under Linux
In-Reply-To: <20011214005121.H3807@wdr.com>
References: <200112140256.SAA29301@ns2.bizsystems.net>; from Michael on Thu, Dec 13, 2001 at 06:56:49PM -0800
Message-ID: <200112142348.PAA02368@ns2.bizsystems.net>

> On Thu, Dec 13, 2001 at 06:56:49PM -0800, Michael wrote:
> > > On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> > > > Now off to code up this patch.  Or at least I'll try, had a look at some of
> > > > the code yesterday too but didn't get anywhere..
> > > 
> > > Cool.
> > > 
> > > You need options processing code (readconf.c) and session-exit
> > > processing code. When the client gets a session-exit message, and
> > > that was the last session still "alive", then do as the user wanted.
> > > The things to do could be many, as I've suggested before and as I'll
> > > repeat:
> 
> [...]
> 
> > The behavior may be different for V1 vs V2
> > 
> > The old V1 behavior simply exits unconditionally -- whereas V2 waits 
> > and presumably would be altered by the proposed modification
> > or....
> > are V1 and V2 to operate in the same manner???
> 
> SSHv1 and SSHv2 are radically different in this area. The v1
> behaviour cannot be modified. But with v2, the client makes the
> decision of when to quit, either by letting the user make the
> decision (~.) or by knowing ahead of time what the user would have
> the client do (hang, background, ~., SIGHUP).
> 
> So this would clearly be a SSHv2-only option.
> 
> Correct me if I'm wrong.
> 
> Cheers,

I happen to agree, but when an old v1 client connects to openssh, the 
"new behavior" prevails. That's one thing that would have to be 
fixed.
Michael at Insulin-Pumpers.org


From vinschen at redhat.com  Sat Dec 15 23:36:18 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sat, 15 Dec 2001 13:36:18 +0100
Subject: connect to bass.directhit.com(65.214.36.12):2401 failed: Connection refused
In-Reply-To: <Pine.LNX.4.33.0112122310280.8027-100000@karma.hagopian.net>; from rob@hagopian.net on Wed, Dec 12, 2001 at 11:10:47PM -0500
References: <87n10o3n7a.fsf@boggy.acest.tutrp.tut.ac.jp> <Pine.LNX.4.33.0112122310280.8027-100000@karma.hagopian.net>
Message-ID: <20011215133618.Z740@cygbert.vinschen.de>

On Wed, Dec 12, 2001 at 11:10:47PM -0500, Rob Hagopian wrote:
> I'll look into this in the morning...
> 								-Rob

That problem is still not solved, unfortunately.  

Corinna

> 
> On 12 Dec 2001, NAKAJI Hiroyuki wrote:
> 
> > Hi,
> >
> > According to http://www.openssh.com/portable.html, I tried to update my
> > openssh_cvs tree by CVS. And got an error.
> >
> > $ cvs update -dP
> > cvs [update aborted]: connect to bass.directhit.com(65.214.36.12):2401 failed: Connection refused
> >
> > Why? And from which cvs pserver can I get the latest openssh-portable?
> >
> > Thanks.
> >

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From tgl at sss.pgh.pa.us  Mon Dec 17 04:17:32 2001
From: tgl at sss.pgh.pa.us (Tom Lane)
Date: Sun, 16 Dec 2001 12:17:32 -0500
Subject: Timing glitch during startup of forwarded connection?
Message-ID: <25333.1008523052@sss.pgh.pa.us>

I have been chasing a reliability problem that seems to boil down to
this: sshd needs a certain amount of time delay between opening a
forwarded connection and receiving the first data packet for the
connection.  Otherwise it never forwards the data.  Anyone heard of
such a thing, or have an idea where to look for the problem?

I see a possibly-related bug report in the archives:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100147052203072&w=2
but little followup.

Details: I'm using openssh-2.9.9p2 here ("here" being an HPUX 10.20 box)
to tunnel to a machine inside my company's firewall (that machine is
running openssh_2.9p2 on RHLinux 7.0).  The tunnel connection carries
several forwarded ports, including one that forwards POP connections
to my company's mail server, elsewhere inside the firewall.  What I was
seeing was that fetchmail runs would sometimes work and sometimes hang
up at the start of the connection.  I first assumed it was fetchmail's
problem and set to work debugging fetchmail, but could find no problem;
what's more, inserting any breakpoint between opening the connection and
sending the first POP command caused the problem to vanish.  I then
tried debugging ssh instead, with the same results: AFAICT, ssh is
sending the first data packet on, but nothing comes back, if there is
too little delay before the packet is sent.  Building with PACKET_DEBUG
enabled suppresses the problem, evidently because executing buffer_dump
a couple of times provides the necessary delay.  (Commenting out the
calls to buffer_dump in packet.c allows the problem to come back, even
with -v -v -v.  The debug trace shows no indication of trouble.)

The sshd connection itself is not frozen, as data will transfer just
fine over other new or existing tunneled connections.  Also, if I give
up and kill fetchmail, the stuck tunneled connection is closed down
properly.

I don't have the privileges to try to debug sshd at my company's server,
so I'm kinda stuck at this point.

According to reports in my company's intranet, other people have seen
similar problems with fetchmail hanging for quite some time, but
apparently no one has tried hard to chase it down.  I take this to mean
that the problem is not specific to my platform or the particular
openssh versions in use.

Any suggestions would be much appreciated.

			regards, tom lane


From dparks at davidparks.org  Mon Dec 17 11:51:18 2001
From: dparks at davidparks.org (David Parks)
Date: 16 Dec 2001 19:51:18 -0500
Subject: sftp ls problem upgrading from 2.9.9p2 to 3.0.2p1 on Linux
Message-ID: <1008550284.3842.3.camel@sulako.davidparks.cxm>

	I am running two Red Hat 6.2 servers with the 2.2.16 kernel.  I am
running OpenSSH_2.9.9p2 (SSH proto 2) and OpenSSL 0.9.5a 1 on both with
no problems.  I am having problems upgrading to OpenSSH 3.0.2p1 on both
systems. After doing a gnu make installation, ssh works fine, but sftp
displays fourteen digit numbers instead of file names when you do an ls
listing of directory contents.  File transfers work properly in sftp. 
lls correctly displays local content.  This problem affects all 3.x
portable versions of OpenSSH, on my systems.  At one point, I was also
having problems with scp never terminating properly, but that problem
seems to have disappeared with this attempt/version.  

Compare the before:

sftp> ls
drwx------    3 account    account        4096 Dec 16 15:59 .
drwxr-xr-x    8 root     root             4096 Oct 23 01:05 ..
-rw-r--r--    1 account    account          24 Dec  3  2000 .bash_logout
-rw-r--r--    1 account    account         230 Dec  3  2000
.bash_profile
-rw-r--r--    1 account    account         124 Dec  3  2000 .bashrc
-rw-------    1 account    account         445 Dec 13 07:33
.bash_history
drwxrwxr-x    2 account    account        4096 Mar  8  2001 Mail
-rw-r--r--    1 account    account       28332 Dec  1 16:27
linux-2.2.20-ow1.tar.gz
-rw-r--r--    1 account    account    19605381 Dec  1 16:30
linux-2.2.20.tar.gz
-rw-r--r--    1 account    account      781092 Dec 16 15:59
openssh-3.0.2p1.tar.gz
sftp>

to the after:

sftp> ls
drwx------    3 account    account    17592186044416 Dec 16 17:01
drwx------    3 account    account    17592186044416 Dec 16 17:01
drwx------    3 account    account    17592186044416 Dec 16 17:01
sftp>


I use the following options when compiling.

#  CC="egcs" \
> CFLAGS="-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentium
-march=pentium -fomit-frame-pointer -fno-exceptions" \
> ./configure \
> --prefix=/usr \
> --sysconfdir=/etc/ssh \
> --with-pam \
> --with-tcp-wrappers \
> --with-ipv4-default \
> --with-ssl-dir=/usr/include/openssl
...

OpenSSH has been configured with the following options:
                 User binaries: /usr/bin
               System binaries: /usr/sbin
           Configuration files: /etc/ssh
               Askpass program: /usr/libexec/ssh-askpass
                  Manual pages: /usr/man/manX
                      PID file: /var/run
        sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin
      Random number collection: Device (/dev/urandom)
                Manpage format: doc
                   PAM support: yes
            KerberosIV support: no
             Smartcard support: no
                   AFS support: no
                 S/KEY support: no
          TCP Wrappers support: yes
          MD5 password support: no
   IP address in $DISPLAY hack: no
      Use IPv4 by default hack: yes
       Translate v4 in v6 hack: yes

              Host: i586-pc-linux-gnu
          Compiler: egcs
    Compiler flags: -O9 -funroll-loops -ffast-math -malign-double
-mcpu=pentium -march=pentium -fomit-frame-pointer -fno-exceptions -Wall
-Wpointer-arith -Wno-uninitialized
Preprocessor flags: -I/usr/include/openssl
      Linker flags: -L/usr/include/openssl
         Libraries: -lpam -ldl -lwrap -lutil -lz -lnsl  -lcrypto

PAM is enabled. You may need to install a PAM control file for sshd,
otherwise password authentication may fail. Example PAM control files
can be found in the contrib/ subdirectory

# make
# make install
# install -m644 contrib/redhat/sshd.pam /etc/pam.d/sshd

	Any suggestions?
Thanks...



From Nicolas.Williams at ubsw.com  Tue Dec 18 02:04:46 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 17 Dec 2001 10:04:46 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011214181059.A12650@foo.birdnet.se>; from Peter Stuge on Fri, Dec 14, 2001 at 06:10:59PM +0100
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net> <20011214015841.H16141@foo.birdnet.se> <20011214181059.A12650@foo.birdnet.se>
Message-ID: <20011217100446.A12209@wdr.com>

On Fri, Dec 14, 2001 at 06:10:59PM +0100, Peter Stuge wrote:
> On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> > 
> > Now off to code up this patch.  Or at least I'll try, had a look at some of
> > the code yesterday too but didn't get anywhere..
> 
> Ok.  Here we go.  It's not very complicated but it took me some time to get
> familiar with all the code, which is very easy to read, kudos to all!
> And after finishing it, I fell alseep.  Ohwell.
> 
> For this to work as desired the sshd must send the SSH_MSG_CHANNEL_CLOSE
> message fast enough for the client to buffer it together with the
> CHANNEL_REQ "exit-status", so that CHAN_CLOSE_RCVD is set in the channel
> flags when client_process_buffered_input_packets() returns.  If this isn't
> acceptable/practical the only alternative I can see is to set a time limit.
> 
> The case I'm trying to handle here is "exit-status received for this
> channel, but no SSH_MSG_CHANNEL_CLOSE" - when is that a fact?  Sure, if some
> other packet than _CHANNEL_EOF or _CHANNEL_CLOSE is received, I'll know.
> And I implemented that first, using a dispatch_preprocess function that
> would be run before the message handler. But that doesn't cut it when there
> simply aren't any packets arriving..

Hmmm, I would say, if you're backgrounding, you don't care, because if
the _CHANNEL_CLOSE is going to arrive you'll exit then anyways...

If you're going to exit and risk losing data, then you also don't care
when, if ever, the _CHANNEL_CLOSE is to arrive. I would agree that a
one-second timer would be nice, but, hey, folk are asking for the right
to risk losing data - let them have it.

> On top of this, much to my disappointment, a backgrounded ssh didn't get
> killed when I closed my xterm.  But if it lingers it gets killed.  This is
> because bash sends SIGHUP to all jobs when it is exiting.  But since the ssh
> fork()s, it's no longer considered to be a job.  Hmm.  I tried putting a
> call to setpgrp() and then setsid() in the fork()ed off child, but that
> didn't make any difference, obviously I guess.  Is what I want even
> possible?

This is because each "job" gets its own process group and the tty send
SIGHUP only to the lead job.

> Tell me if I've done something wrong in the patch.  It makes ssh in any case
> tell the user about what is happening and why, wheter it lingers, goes to
> background or terminates.

I don't see a check for whether there are other live sessions. That should
be needed because SSHv2 supports multiple sessions per-connection. I
think there was a patch floating around to implement a ~ escape for
starting new sessions... For now this is no big deal, but it should be
easy to add a session_still_live() function to check.

> 
> //Peter
> 
> -- 
> irc: CareBear\
> irl: Peter Stuge


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 csoler at euskalnet.net  Tue Dec 18 02:43:26 2001
From: csoler at euskalnet.net (=?ISO-8859-1?B?Q+lzYXIgU29sZXI=?=)
Date: Mon, 17 Dec 2001 16:43:26 +0100
Subject: sftp-server questions
Message-ID: <18678026416.20011217164326@euskalnet.net>

Hello,

Is there any way to specify which pubkey has rights to use the
sftp-server subsytem when this has been set up in the sshd server?
I don't know if I could control which users are authorized to use the
sftp-server, could I?
Is there any official patch that allows sftp-sessions 'chroot'ed?

Thanks in advance.

-- 
Best regards,
 quart                          mailto:quart at wanadoo.es




From markus at openbsd.org  Tue Dec 18 02:40:48 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 17 Dec 2001 16:40:48 +0100
Subject: Timing glitch during startup of forwarded connection?
In-Reply-To: <25333.1008523052@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Sun, Dec 16, 2001 at 12:17:32PM -0500
References: <25333.1008523052@sss.pgh.pa.us>
Message-ID: <20011217164048.A321@folly>

On Sun, Dec 16, 2001 at 12:17:32PM -0500, Tom Lane wrote:
> I have been chasing a reliability problem that seems to boil down to
> this: sshd needs a certain amount of time delay between opening a
> forwarded connection and receiving the first data packet for the
> connection.  Otherwise it never forwards the data.  Anyone heard of
> such a thing, or have an idea where to look for the problem?

there was a bug around 2.9 related to async connects + forwarding.

however, it should be fixed in 2.9.9 and later.

w/o debugging output we cannot help.

-m


From markus at openbsd.org  Tue Dec 18 02:45:23 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 17 Dec 2001 16:45:23 +0100
Subject: sftp-server questions
In-Reply-To: <18678026416.20011217164326@euskalnet.net>
References: <18678026416.20011217164326@euskalnet.net>
Message-ID: <20011217164523.A13953@faui02>

On Mon, Dec 17, 2001 at 04:43:26PM +0100, Csar Soler wrote:
> Is there any official patch that allows sftp-sessions 'chroot'ed?

sorry, no.

there are no 'official' patches.

-m


From markus at openbsd.org  Tue Dec 18 02:50:31 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 17 Dec 2001 16:50:31 +0100
Subject: ssh host echo bla | echo bla
Message-ID: <20011217165031.A14156@faui02>

what should ssh do for:
	$ ssh host echo bla | echo bla
	$ ssh -1 host echo bla | echo bla
	$ ssh -2 host echo bla | echo bla

-m


From mouring at etoh.eviladmin.org  Tue Dec 18 02:56:49 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 17 Dec 2001 09:56:49 -0600 (CST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011217165031.A14156@faui02>
Message-ID: <Pine.BSO.4.33.0112170953460.6712-100000@etoh.eviladmin.org>


[mouring at newton ~]$echo blah | echo blah
blah

I would expect no less from OpenSSH myself.  2.9.9 (which was the machine
I had right handly) hangs indefinately after printing 'blah'.

- Ben

On Mon, 17 Dec 2001, Markus Friedl wrote:

> what should ssh do for:
> 	$ ssh host echo bla | echo bla
> 	$ ssh -1 host echo bla | echo bla
> 	$ ssh -2 host echo bla | echo bla
>
> -m
>



From vinschen at redhat.com  Tue Dec 18 03:00:27 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 17 Dec 2001 17:00:27 +0100
Subject: What's the problem with the CVS repository?
Message-ID: <20011217170027.F21898@cygbert.vinschen.de>

Hi,

at least for three days now I can't update my sources from CVS.
When connecting to the CVS server I'm getting a

cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused

message.  I'd like to make a `cvs diff' since I have an important
patch related to a SEGV in the Cygwin sshd.

What's the problem with bass.directhit.com?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From mouring at etoh.eviladmin.org  Tue Dec 18 02:59:19 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 17 Dec 2001 09:59:19 -0600 (CST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <Pine.BSO.4.33.0112170953460.6712-100000@etoh.eviladmin.org>
Message-ID: <Pine.BSO.4.33.0112170958590.29215-100000@etoh.eviladmin.org>



FYI.. That is under Solaris it does that..  OpenBSD returns.

Interesting

- Ben

On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:

>
> [mouring at newton ~]$echo blah | echo blah
> blah
>
> I would expect no less from OpenSSH myself.  2.9.9 (which was the machine
> I had right handly) hangs indefinately after printing 'blah'.
>
> - Ben
>
> On Mon, 17 Dec 2001, Markus Friedl wrote:
>
> > what should ssh do for:
> > 	$ ssh host echo bla | echo bla
> > 	$ ssh -1 host echo bla | echo bla
> > 	$ ssh -2 host echo bla | echo bla
> >
> > -m
> >
>
>



From mouring at etoh.eviladmin.org  Tue Dec 18 03:19:14 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 17 Dec 2001 10:19:14 -0600 (CST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <Pine.BSO.4.33.0112170958590.29215-100000@etoh.eviladmin.org>
Message-ID: <Pine.BSO.4.33.0112171018400.29215-100000@etoh.eviladmin.org>


Ermm.. disregard that.. I was doing the ssh teat against a test server box
that had some oddish patches which causes ill-behavior.

- Ben

On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:

>
>
> FYI.. That is under Solaris it does that..  OpenBSD returns.
>
> Interesting
>
> - Ben
>
> On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:
>
> >
> > [mouring at newton ~]$echo blah | echo blah
> > blah
> >
> > I would expect no less from OpenSSH myself.  2.9.9 (which was the machine
> > I had right handly) hangs indefinately after printing 'blah'.
> >
> > - Ben
> >
> > On Mon, 17 Dec 2001, Markus Friedl wrote:
> >
> > > what should ssh do for:
> > > 	$ ssh host echo bla | echo bla
> > > 	$ ssh -1 host echo bla | echo bla
> > > 	$ ssh -2 host echo bla | echo bla
> > >
> > > -m
> > >
> >
> >
>
>



From ed at UDel.Edu  Tue Dec 18 03:57:06 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 17 Dec 2001 11:57:06 -0500 (EST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <Pine.BSO.4.33.0112170958590.29215-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0112171152320.14740-100000@mahler.udel.edu>

When I run this on Sol8 with 2.9.9p2 it doesn't even connect to the remote
host...

polycut:~> ssh ldap1 echo bla | echo bla
bla
polycut:~> polycut:~>

If I type "jobs" afterwards...

polycut:~> ssh ldap1 echo bla | echo bla
bla
polycut:~> polycut:~> jobs
[1]    Hangup                        ssh ldap1 echo bla |
polycut:~>

That doesn't seem like a desirable result... :-(

	Ed

On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:

> Date: Mon, 17 Dec 2001 09:59:19 -0600 (CST)
> From: mouring at etoh.eviladmin.org
> To: openssh-unix-dev at mindrot.org
> Subject: Re: ssh host echo bla | echo bla
>
>
>
> FYI.. That is under Solaris it does that..  OpenBSD returns.
>
> Interesting
>
> - Ben
>
> On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:
>
> >
> > [mouring at newton ~]$echo blah | echo blah
> > blah
> >
> > I would expect no less from OpenSSH myself.  2.9.9 (which was the machine
> > I had right handly) hangs indefinately after printing 'blah'.
> >
> > - Ben
> >
> > On Mon, 17 Dec 2001, Markus Friedl wrote:
> >
> > > what should ssh do for:
> > > 	$ ssh host echo bla | echo bla
> > > 	$ ssh -1 host echo bla | echo bla
> > > 	$ ssh -2 host echo bla | echo bla
> > >
> > > -m
> > >
> >
> >
>

Ed Phillips <ed at udel.edu> 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  Tue Dec 18 03:59:59 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 17 Dec 2001 10:59:59 -0600 (CST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <Pine.SOL.4.30.0112171152320.14740-100000@mahler.udel.edu>
Message-ID: <Pine.BSO.4.33.0112171056290.17877-100000@etoh.eviladmin.org>


Oh a clean (much better this time. =)  install on Solaris it does:

$ ssh localhost echo bla | echo bla
bla
lindstro at localhost's password:
Connection to localhost closed by remote host.

And no jobs are left over.. Which in a lot of respect what I would
expect.

connect to the server, echo 'bla' from the server pass it out stdout.  Hit
the sent '| echo bla'  which is local (because you are not quoting).  It
is lost because the second program disgards all stdin and writes it's
own output.

Not dead sure why Markus was asking what the right behavior should be
since the above is the right behavior (even if I had broken test ssh
servers around the first time. =).

Not sure why yours is background anything.  I can verify this on Linux,
OpenBSD, and Solaris as behavior this way.

- Ben

On Mon, 17 Dec 2001, Ed Phillips wrote:

> When I run this on Sol8 with 2.9.9p2 it doesn't even connect to the remote
> host...
>
> polycut:~> ssh ldap1 echo bla | echo bla
> bla
> polycut:~> polycut:~>
>
> If I type "jobs" afterwards...
>
> polycut:~> ssh ldap1 echo bla | echo bla
> bla
> polycut:~> polycut:~> jobs
> [1]    Hangup                        ssh ldap1 echo bla |
> polycut:~>
>
> That doesn't seem like a desirable result... :-(
>
> 	Ed
>
> On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:
>
> > Date: Mon, 17 Dec 2001 09:59:19 -0600 (CST)
> > From: mouring at etoh.eviladmin.org
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: ssh host echo bla | echo bla
> >
> >
> >
> > FYI.. That is under Solaris it does that..  OpenBSD returns.
> >
> > Interesting
> >
> > - Ben
> >
> > On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:
> >
> > >
> > > [mouring at newton ~]$echo blah | echo blah
> > > blah
> > >
> > > I would expect no less from OpenSSH myself.  2.9.9 (which was the machine
> > > I had right handly) hangs indefinately after printing 'blah'.
> > >
> > > - Ben
> > >
> > > On Mon, 17 Dec 2001, Markus Friedl wrote:
> > >
> > > > what should ssh do for:
> > > > 	$ ssh host echo bla | echo bla
> > > > 	$ ssh -1 host echo bla | echo bla
> > > > 	$ ssh -2 host echo bla | echo bla
> > > >
> > > > -m
> > > >
> > >
> > >
> >
>
> Ed Phillips <ed at udel.edu> 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 ed at UDel.Edu  Tue Dec 18 04:55:20 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 17 Dec 2001 12:55:20 -0500 (EST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <Pine.BSO.4.33.0112171056290.17877-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0112171249060.14740-100000@mahler.udel.edu>

It's even worse with csh (my first test was tcsh):

polycut:~> csh -f
polycut.nss.udel.edu% ssh ldap1 echo bla | echo bla
bla
polycut.nss.udel.edu% Reset tty pgrp from 13749 to 13747
<..hang..>

If I hit CTRL-C and type "jobs" I get:

^C
polycut.nss.udel.edu% jobs
[1]    Hangup               ssh ldap1 echo bla |
polycut.nss.udel.edu%

The following works fine...

polycut:~> ssh ldap1 ps -eaf | egrep slapd
...

The other thing is that /bin/rsh behaves the same way as ssh does in my
first test:

polycut:~> rsh mahler echo bla | echo bla
bla
polycut:~> polycut:~>

No actual connection to the remote system is made.  Very weird.

	Ed

On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:

> Date: Mon, 17 Dec 2001 10:59:59 -0600 (CST)
> From: mouring at etoh.eviladmin.org
> To: Ed Phillips <ed at UDel.Edu>
> Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>
> Subject: Re: ssh host echo bla | echo bla
>
>
> Oh a clean (much better this time. =)  install on Solaris it does:
>
> $ ssh localhost echo bla | echo bla
> bla
> lindstro at localhost's password:
> Connection to localhost closed by remote host.
>
> And no jobs are left over.. Which in a lot of respect what I would
> expect.
>
> connect to the server, echo 'bla' from the server pass it out stdout.  Hit
> the sent '| echo bla'  which is local (because you are not quoting).  It
> is lost because the second program disgards all stdin and writes it's
> own output.
>
> Not dead sure why Markus was asking what the right behavior should be
> since the above is the right behavior (even if I had broken test ssh
> servers around the first time. =).
>
> Not sure why yours is background anything.  I can verify this on Linux,
> OpenBSD, and Solaris as behavior this way.
>
> - Ben
>
> On Mon, 17 Dec 2001, Ed Phillips wrote:
>
> > When I run this on Sol8 with 2.9.9p2 it doesn't even connect to the remote
> > host...
> >
> > polycut:~> ssh ldap1 echo bla | echo bla
> > bla
> > polycut:~> polycut:~>
> >
> > If I type "jobs" afterwards...
> >
> > polycut:~> ssh ldap1 echo bla | echo bla
> > bla
> > polycut:~> polycut:~> jobs
> > [1]    Hangup                        ssh ldap1 echo bla |
> > polycut:~>
> >
> > That doesn't seem like a desirable result... :-(
> >
> > 	Ed
> >
> > On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:
> >
> > > Date: Mon, 17 Dec 2001 09:59:19 -0600 (CST)
> > > From: mouring at etoh.eviladmin.org
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: Re: ssh host echo bla | echo bla
> > >
> > >
> > >
> > > FYI.. That is under Solaris it does that..  OpenBSD returns.
> > >
> > > Interesting
> > >
> > > - Ben
> > >
> > > On Mon, 17 Dec 2001 mouring at etoh.eviladmin.org wrote:
> > >
> > > >
> > > > [mouring at newton ~]$echo blah | echo blah
> > > > blah
> > > >
> > > > I would expect no less from OpenSSH myself.  2.9.9 (which was the machine
> > > > I had right handly) hangs indefinately after printing 'blah'.
> > > >
> > > > - Ben
> > > >
> > > > On Mon, 17 Dec 2001, Markus Friedl wrote:
> > > >
> > > > > what should ssh do for:
> > > > > 	$ ssh host echo bla | echo bla
> > > > > 	$ ssh -1 host echo bla | echo bla
> > > > > 	$ ssh -2 host echo bla | echo bla
> > > > >
> > > > > -m
> > > > >
> > > >
> > > >
> > >
> >
> > Ed Phillips <ed at udel.edu> 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
> >
> >
>

Ed Phillips <ed at udel.edu> 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 djast at cs.toronto.edu  Tue Dec 18 05:06:16 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Mon, 17 Dec 2001 13:06:16 -0500
Subject: ssh host echo bla | echo bla 
In-Reply-To: Your message of "Mon, 17 Dec 2001 12:55:20 EST."
             <Pine.SOL.4.30.0112171249060.14740-100000@mahler.udel.edu> 
Message-ID: <01Dec17.130620edt.453149-3305@jane.cs.toronto.edu>

On Mon, 17 Dec 2001 12:55:20 EST, Ed Phillips writes:
> It's even worse with csh (my first test was tcsh):
> 
> polycut:~> csh -f
> polycut.nss.udel.edu% ssh ldap1 echo bla | echo bla
> bla
> polycut.nss.udel.edu% Reset tty pgrp from 13749 to 13747
> <..hang..>

This is a known bogosity with csh builtins (see Tom Christiansen's
classic article "Csh Programming Considered Harmful" for specifics).
Don't pipe stuff to builtins... or, if you do, don't expect consistent
behaviour.

You may wish to try piping to "/bin/echo" rather than "echo".  Or even
to "/bin/true", if you're just looking for a command which ignores
stdin--I haven't figured out exactly what it is you're trying to test.

-- 
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 ed at UDel.Edu  Tue Dec 18 05:34:50 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 17 Dec 2001 13:34:50 -0500 (EST)
Subject: ssh host echo bla | echo bla 
In-Reply-To: <01Dec17.130620edt.453149-3305@jane.cs.toronto.edu>
Message-ID: <Pine.SOL.4.30.0112171330140.14740-100000@mahler.udel.edu>

On Mon, 17 Dec 2001, Dan Astoorian wrote:

> Date: Mon, 17 Dec 2001 13:06:16 -0500
> From: Dan Astoorian <djast at cs.toronto.edu>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: mouring at etoh.eviladmin.org,
>      OpenSSH Development <openssh-unix-dev at mindrot.org>
> Subject: Re: ssh host echo bla | echo bla
>
> On Mon, 17 Dec 2001 12:55:20 EST, Ed Phillips writes:
> > It's even worse with csh (my first test was tcsh):
> >
> > polycut:~> csh -f
> > polycut.nss.udel.edu% ssh ldap1 echo bla | echo bla
> > bla
> > polycut.nss.udel.edu% Reset tty pgrp from 13749 to 13747
> > <..hang..>
>
> This is a known bogosity with csh builtins (see Tom Christiansen's
> classic article "Csh Programming Considered Harmful" for specifics).
> Don't pipe stuff to builtins... or, if you do, don't expect consistent
> behaviour.

Duh... I didn't even think that "echo" might be a built-in... it works
as expected like this:

polycut:~> ssh ldap1 echo bla | /bin/echo bla
bla
polycut:~>

> You may wish to try piping to "/bin/echo" rather than "echo".  Or even
> to "/bin/true", if you're just looking for a command which ignores
> stdin--I haven't figured out exactly what it is you're trying to test.

I'm not what Markus is trying to test either... I was just trying to
submit results from my systems to be helpful.

Thanks,

	Ed

Ed Phillips <ed at udel.edu> 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 markus at openbsd.org  Tue Dec 18 05:50:25 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 17 Dec 2001 19:50:25 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011217165031.A14156@faui02>
References: <20011217165031.A14156@faui02>
Message-ID: <20011217195025.A1404@faui02>

On Mon, Dec 17, 2001 at 04:50:31PM +0100, Markus Friedl wrote:
> what should ssh do for:
> 	$ ssh host echo bla | echo bla
> 	$ ssh -1 host echo bla | echo bla
> 	$ ssh -2 host echo bla | echo bla
> 

cf

	% ssh -1 host /bin/echo | true


From mjt at tls.msk.ru  Tue Dec 18 05:58:37 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Mon, 17 Dec 2001 21:58:37 +0300
Subject: ssh host echo bla | echo bla
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02>
Message-ID: <3C1E405D.2EDC9E38@tls.msk.ru>

Markus Friedl wrote:
> 
> On Mon, Dec 17, 2001 at 04:50:31PM +0100, Markus Friedl wrote:
> > what should ssh do for:
> >       $ ssh host echo bla | echo bla
> >       $ ssh -1 host echo bla | echo bla
> >       $ ssh -2 host echo bla | echo bla
> >
> 
> cf
> 
>         % ssh -1 host /bin/echo | true

Hey, `true' is a builtin in most shells too! ;)

 $ ssh -1 localhost /bin/echo | /bin/echo dummy
 dummy
 Write failed flushing stdout buffer.
 write stdout: Broken pipe
 $ _

 $ ssh -2 localhost /bin/echo | /bin/echo dummy
 dummy
 $ _

Note: in the last case, there is NO attempt to connect to remote
host.  First one seems to be correct to me (and only this -- all
previous examples shows ill behaviour).

Aha -- I see now why this strange question... ;)

BTW, here, on linux with bash-2.05.1, both builtins and external
commands works the same way.

Regards,
  Michael.


From markus at openbsd.org  Tue Dec 18 05:59:40 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 17 Dec 2001 19:59:40 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011217195025.A1404@faui02>
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02>
Message-ID: <20011217195940.A7401@faui02>

ok, consider this:

	$ ssh -1 localhost od /bsd | true 
	$ ssh -2 localhost od /bsd | true 

i think this is a 'bug'

-m


From markus at openbsd.org  Tue Dec 18 06:02:24 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 17 Dec 2001 20:02:24 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1E405D.2EDC9E38@tls.msk.ru>
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <3C1E405D.2EDC9E38@tls.msk.ru>
Message-ID: <20011217200224.A8111@faui02>

On Mon, Dec 17, 2001 at 09:58:37PM +0300, Michael Tokarev wrote:
> >         % ssh -1 host /bin/echo | true
> 
> Hey, `true' is a builtin in most shells too! ;)

hey, echo and true are not in my shell. but this is not about shells :)


From mouring at etoh.eviladmin.org  Tue Dec 18 06:11:17 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 17 Dec 2001 13:11:17 -0600 (CST)
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011217195940.A7401@faui02>
Message-ID: <Pine.BSO.4.33.0112171309030.7443-100000@etoh.eviladmin.org>


Hmm.. Did something change from 2.9.9 to 3.0.x? (NeXTStep has my only 3.0
version and that is turned off at the moment).  Because I don't get
any errors under ksh and bash.  (Solaris/Linux)  And it connects out via
SSH first then it quietly drops as true is ran locally.

On 2.9.x machines (some productive some test) I can't produce the error
you see.


- Ben


On Mon, 17 Dec 2001, Markus Friedl wrote:

> ok, consider this:
>
> 	$ ssh -1 localhost od /bsd | true
> 	$ ssh -2 localhost od /bsd | true
>
> i think this is a 'bug'
>
> -m
>



From mjt at tls.msk.ru  Tue Dec 18 06:13:41 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Mon, 17 Dec 2001 22:13:41 +0300
Subject: ssh host echo bla | echo bla
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02>
Message-ID: <3C1E43E5.33E2E9B@tls.msk.ru>

Markus Friedl wrote:
> 
> ok, consider this:
> 
>         $ ssh -1 localhost od /bsd | true
>         $ ssh -2 localhost od /bsd | true
> 
> i think this is a 'bug'

Definitely.  And this explains some strange issues we has had
when switched from v1 to v2 protocol (well, there was a bug in
our script, but v1 shows it while v2 silently "ignores" it).
I found this bug in our script a few seconds earlier after
changing all `ssh' to `ssh -1' -- now ssh shows that I was
mistaken...

Regards,
 Michael.


From Nicolas.Williams at ubsw.com  Tue Dec 18 06:47:30 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 17 Dec 2001 14:47:30 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011217195940.A7401@faui02>; from Markus Friedl on Mon, Dec 17, 2001 at 07:59:40PM +0100
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02>
Message-ID: <20011217144730.B12209@wdr.com>

On Mon, Dec 17, 2001 at 07:59:40PM +0100, Markus Friedl wrote:
> ok, consider this:
> 
> 	$ ssh -1 localhost od /bsd | true 
> 	$ ssh -2 localhost od /bsd | true 
> 
> i think this is a 'bug'

 - with -1, if stdout is a dead pipe, then ssh trie to open /dev/tty?
 - with -2, if stdout is a dead pipe, then ssh exits?

Why should one behaviour be correct and the other not?

I mean, if you've got a broken pipe, print a message to stderr about it,
and if that's broken too, oh well. Either way exit.

So I would say that the -1 behaviour is forgiving, but the -2 behaviour
is correct.

> -m


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 Nicolas.Williams at ubsw.com  Tue Dec 18 06:48:48 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 17 Dec 2001 14:48:48 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1E43E5.33E2E9B@tls.msk.ru>; from Michael Tokarev on Mon, Dec 17, 2001 at 10:13:41PM +0300
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <3C1E43E5.33E2E9B@tls.msk.ru>
Message-ID: <20011217144848.C12209@wdr.com>

On Mon, Dec 17, 2001 at 10:13:41PM +0300, Michael Tokarev wrote:
> Markus Friedl wrote:
> > 
> > ok, consider this:
> > 
> >         $ ssh -1 localhost od /bsd | true
> >         $ ssh -2 localhost od /bsd | true
> > 
> > i think this is a 'bug'
> 
> Definitely.  And this explains some strange issues we has had
> when switched from v1 to v2 protocol (well, there was a bug in
> our script, but v1 shows it while v2 silently "ignores" it).

Right, it's a bug in your script. I think that the OpenSSH -2 behaviour
is correct and not a bug.

Or are you and Markus saying that the -1 behaviour is a bug? :)

> I found this bug in our script a few seconds earlier after
> changing all `ssh' to `ssh -1' -- now ssh shows that I was
> mistaken...
> 
> Regards,
>  Michael.


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 bbense at networking.stanford.edu  Tue Dec 18 06:56:34 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Mon, 17 Dec 2001 11:56:34 -0800 (PST)
Subject: PATCH: Kerberos password authentication w/o KDC verification
In-Reply-To: <3C1A60B3.300@rpi.edu>
Message-ID: <Pine.GSO.4.43.0112171124450.14629-100000@shred.stanford.edu>

On Fri, 14 Dec 2001, R. Lindsay Todd wrote:

> Folks: We use an old AFS cell with Kerberos 4.  Our use of Kerberos 4 is
> fairly limited; we have never needed to  implement rcmd host principals
> for most of our systems.  Indeed, given that Kerberos 4 strips off the
> domain name portion of a hostname when determining the rcmd instance, we
> would not be able to do this, since we do have duplicate hostnames in
> multiple subdomains.
>
> For AFS password authentication, OpenSSH first does Kerberos password
> authentication.  It then attempts to get a ticket for the server's rcmd
> service, in order to verify that the KDC is not being spoofed.  Of
> course, this fails if you do not have an rcmd service key.
>
> For most of RPI's systems, those running Linux, Solaris, or AIX, this is
> not a problem.  OpenSSH uses PAM on Linux and Solaris, and AIX
> "authenticate" on AIX.  These external systems do not verify the KDC; if
> you submit a correct Kerberos/AFS password, it will grant you tickets.
>  You do not need an rcmd key.  However, our SGI Irix systems actually
> use the built-in auth-kerb4 authentication.  Since we do not have rcmd
> keys, password authentication fails.
>

- I think you are confusing two things here. There's getting
a "convience" ticket and using kerberos to prove who you are.
If you don't verify the ticket using the rcmd principal and
you haven't verified the username/password via other means,
you are pretty much wide open to attack by anybody that
can inject packets into your network. Since k4 uses UDP
the attack is trivial. Any PAM module that doesn't do this
is horribly broken.

- However, if you've already verified your username/password
via the local password entry and are just getting a convience
ticket for accessing things like afs, it's a different story.


> I am sure that verifying the KDC is a good thing to do...

- It's not just a good thing to do, it's the fundamental
basis of the protocol. If you don't do it, there isn't
much difference between what you're doing and the old
rlogin /hosts.equiv file.

> But in our
> case, it causes difficulties.  Verifying the KDC is not consistently
> enforced, anyway.

- Any code that uses the tgt to grant authority, but does not verify
it by getting a service ticket and verifying the service ticket is
BROKEN. It's just the same as putting a buffer overrun or a tmp file
race condition in the code. If it's not consistently enforced, then
it should be.

> So the attached patch provides a way to turn it off.
>  I have implemented a server configuration option, KerberosVerifyServer,
> that defaults to "yes".  If it is true, then the KDC is verified, as
> currently happens.  If it set to "no", then the behaviour I need, of not
> verifying the KDC, is provided.
>
>  From our point of view, it would be a nice thing if this became a
> standard feature of OpenSSH.
>

- I think making this patch a "standard" feature is dubious at
best. It totally circumvents the security of the kerberos protocol.
It would be one thing if the user had already autheticated via
a local password entry, but as I understand the code there is
no guarantee that this has occurred.

- If you do include it, I suggest that you word the feature much
more perjoratively, something like.

Kerberos4UnsafeAuthentication

- You need to make it very clear that you are opening your box
wide open for the sake of convience. There was a security advisory
posted last year about exactly why this is a bad idea. I can't
seem to find the reference at the moment.

- Booker C. Bense






From dugsong at monkey.org  Tue Dec 18 07:24:29 2001
From: dugsong at monkey.org (Dug Song)
Date: Mon, 17 Dec 2001 15:24:29 -0500
Subject: PATCH: Kerberos password authentication w/o KDC verification
In-Reply-To: <Pine.GSO.4.43.0112171124450.14629-100000@shred.stanford.edu>; from bbense@networking.stanford.edu on Mon, Dec 17, 2001 at 11:56:34AM -0800
References: <3C1A60B3.300@rpi.edu> <Pine.GSO.4.43.0112171124450.14629-100000@shred.stanford.edu>
Message-ID: <20011217152429.C20698@naughty.monkey.org>

On Mon, Dec 17, 2001 at 11:56:34AM -0800, Booker C. Bense wrote:

> - You need to make it very clear that you are opening your box
> wide open for the sake of convience. There was a security advisory
> posted last year about exactly why this is a bad idea. I can't
> seem to find the reference at the moment.

http://www.monkey.org/~dugsong/kdcspoof.tar.gz

-d.

---
http://www.monkey.org/~dugsong/


From kirk.ranjitsingh at us.sema.com  Tue Dec 18 07:32:49 2001
From: kirk.ranjitsingh at us.sema.com (Ranjitsingh, Kirk)
Date: Mon, 17 Dec 2001 15:32:49 -0500
Subject: disabling sftp authentication using openssh 2.9.9p2...
Message-ID: <338D10123297D5119EFB00508B8BFDDFC2BA3C@svratl03.us.lhsgroup.com>

I'm trying to use sftp from a 2.9.9p2 client, connecting to a F-Secure 2.4.0
server, but consistently get the following.

debug1: authentications that can continue: hostbased,publickey,password
debug1: next auth method to try is publickey
debug1: try privkey: /path/acct/.ssh/id_rsa
debug1: try pubkey: /path/acct/.ssh/id_dsa
debug1: authentications that can continue: hostbased,publickey,password
debug1: next auth method to try is password
acct at remotehostsftp's password:

Entering the password allow access.  But I'm trying to authenticate with
having to enter a password.

The remote host has a copy of the public key from
/path/acct/.ssh/identity.pub file
Client host /path/acct/.ssh/id_dsa exists and ssh-agent is running.

I assume the id_dsa file isn't needed for publickey authentication, but why
is it asking for the pubkey: /path/acct/.ssh/id_dsa.
What am I missing?

Help...


From tgl at sss.pgh.pa.us  Tue Dec 18 08:56:24 2001
From: tgl at sss.pgh.pa.us (Tom Lane)
Date: Mon, 17 Dec 2001 16:56:24 -0500
Subject: Timing glitch during startup of forwarded connection? 
In-Reply-To: <20011217164048.A321@folly> 
References: <25333.1008523052@sss.pgh.pa.us> <20011217164048.A321@folly>
Message-ID: <7501.1008626184@sss.pgh.pa.us>

Markus Friedl <markus at openbsd.org> writes:
> On Sun, Dec 16, 2001 at 12:17:32PM -0500, Tom Lane wrote:
>> I have been chasing a reliability problem that seems to boil down to
>> this: sshd needs a certain amount of time delay between opening a
>> forwarded connection and receiving the first data packet for the
>> connection.  Otherwise it never forwards the data.  Anyone heard of
>> such a thing, or have an idea where to look for the problem?

> there was a bug around 2.9 related to async connects + forwarding.
> however, it should be fixed in 2.9.9 and later.

Thanks for the tip.  Quick testing indicates that indeed the problem
is gone after upgrading the gateway machine's sshd to 3.0.2.

			regards, tom lane


From stuge at cdy.org  Tue Dec 18 10:21:43 2001
From: stuge at cdy.org (Peter Stuge)
Date: Tue, 18 Dec 2001 00:21:43 +0100
Subject: hang on exit bug under Linux
In-Reply-To: <20011217100446.A12209@wdr.com>; from Nicolas.Williams@ubsw.com on Mon, Dec 17, 2001 at 10:04:46AM -0500
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net> <20011214015841.H16141@foo.birdnet.se> <20011214181059.A12650@foo.birdnet.se> <20011217100446.A12209@wdr.com>
Message-ID: <20011218002143.A26769@foo.birdnet.se>

On Mon, Dec 17, 2001 at 10:04:46AM -0500, Nicolas Williams wrote:
> > 
> > The case I'm trying to handle here is "exit-status received for this
> > channel, but no SSH_MSG_CHANNEL_CLOSE" - when is that a fact?  Sure, if
> > some other packet than _CHANNEL_EOF or _CHANNEL_CLOSE is received, I'll
> > know.  And I implemented that first, using a dispatch_preprocess
> > function that would be run before the message handler. But that doesn't
> > cut it when there simply aren't any packets arriving..
> 
> Hmmm, I would say, if you're backgrounding, you don't care, because if
> the _CHANNEL_CLOSE is going to arrive you'll exit then anyways...
> If you're going to exit and risk losing data, then you also don't care
> when, if ever, the _CHANNEL_CLOSE is to arrive. I would agree that a
> one-second timer would be nice, but, hey, folk are asking for the right
> to risk losing data - let them have it.

If the calls to error() are kept in, it would mean that the message always
got printed whenever the exit-status request was recevied and also cause the
_CHANNEL_CLOSE and any other packets sent by the server to never get
handled..  I wanted to accurately determine the state when exit-message was
received but not _CHANNEL_CLOSE..  And depending on different server
implementations, I guess, my assumptions will work..


> > On top of this, much to my disappointment, a backgrounded ssh didn't get
> > killed when I closed my xterm.  But if it lingers it gets killed.  This
> > is because bash sends SIGHUP to all jobs when it is exiting.  But since
> > the ssh fork()s, it's no longer considered to be a job.  Hmm.  I tried
> > putting a call to setpgrp() and then setsid() in the fork()ed off child,
> > but that didn't make any difference, obviously I guess.  Is what I want
> > even possible?
> 
> This is because each "job" gets its own process group and the tty send
> SIGHUP only to the lead job.

The lead job is bash.  And bash forwards the HUP to all it's "jobs"..  But
since the ssh process that is a child of bash has exited (leaving a new
process that it fork()ed off) bash never sends the backgrounded ssh process
a HUP, since it's not a child of bash.  So my question is sort of bash
related, but I was hoping it was generic to all shells or maybe even
processes.  I guess I could try to find an answer somewhere in POSIX?


> > Tell me if I've done something wrong in the patch.  It makes ssh in any
> > case tell the user about what is happening and why, wheter it lingers,
> > goes to background or terminates.
> 
> I don't see a check for whether there are other live sessions. That should
> be needed because SSHv2 supports multiple sessions per-connection. I
> think there was a patch floating around to implement a ~ escape for
> starting new sessions... For now this is no big deal, but it should be
> easy to add a session_still_live() function to check.

Yeah, I realized this when I read up on the protocol.  But since it wasn't
currently used anywhere in OpenSSH I figured I didn't have to care about it. 
And because of that I didn't see any obivous way to handle it..

What sort of channel did this patch let you create in the new session?  I
can see before me a patch turning OpenSSH into a secure "screen"-program,
which would be sort of cool, but a bit out of scope, none the less..  :)

Thanks for the input!


//Peter

-- 
irc: CareBear\
irl: Peter Stuge


From nahid.taheri at wamu.net  Tue Dec 18 10:38:22 2001
From: nahid.taheri at wamu.net (Nahid Taheri)
Date: Mon, 17 Dec 2001 15:38:22 -0800
Subject: SSH hanging
Message-ID: <3C1E81EE.835B3EA5@wamu.net>

Hi,

We installed OBSD's ssh package on production and find our batch jobs
are hanging on the "ssh"
command.  The details are included below, for both normal and "hanging"
executions.  Please let
me know if this is a new or existing bug or if you require further info
to debug this.  The command
was executed with the highest debug level (-v -v -v for level 3).  This
script
serves a critical business function and this bug affects our database
recoverability.

Thanks,

Nahid Taheri
Lead Enterprise DBA
Washington Mutual
(949) 833 6644

Details follows:
-----------------------------------
Normal execution:
debug2: callback start
debug1: client_init id 0 arg 0
debug1: Sending command: df -k /u03/oraarch_remote/crmsbprd
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
debug1: channel 0: read<=0 rfd 5 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: rcvd close
debug2: channel 0: no data after CLOSE
debug2: channel 0: no data after CLOSE
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following connections are
open:
  #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)
debug2: !channel_still_open.
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

---------------------------------
Prior to haning situation: (normal execution):
debug2: callback start
debug1: client_init id 0 arg 0
debug1: Sending command: df -k /u03/oraarch_remote/crmsbprd
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
debug1: channel 0: read<=0 rfd 5 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: rcvd close
debug2: channel 0: no data after CLOSE
debug2: channel 0: no data after CLOSE
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following connections are
open:
  #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)
debug2: !channel_still_open.
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1

-------------------------------------------------------------------
Hanging Execution:
debug2: callback start^M
debug1: client_init id 0 arg 0^M
debug1: Sending command: df -k /u03/oraarch_remote/crmsbprd^M
debug2: callback done^M
debug1: channel 0: open confirm rwindow 0 rmax 16384^M
debug2: channel 0: rcvd adjust 32768^M
debug1: channel 0: read<=0 rfd 5 len 0^M
debug1: channel 0: read failed^M
debug1: channel 0: input open -> drain^M
debug1: channel 0: close_read^M
debug1: channel 0: input: no drain shortcut^M
debug1: channel 0: ibuf empty^M
debug1: channel 0: input drain -> closed^M
debug1: channel 0: send eof^M
debug1: channel 0: rcvd eof^M
debug1: channel 0: output open -> drain^M
debug1: channel 0: obuf empty^M
debug1: channel 0: output drain -> closed^M
debug1: channel 0: close_write^M
debug1: channel 0: send close^M
debug2: channel 0: no data after CLOSE^M
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0^M
debug1: channel 0: rcvd close^M
debug2: channel 0: no data after CLOSE^M
debug1: channel 0: is dead^M
debug1: channel_free: channel 0: status: The following connections are
open:^M
  #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)^M
^M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nahid.taheri.vcf
Type: text/x-vcard
Size: 158 bytes
Desc: Card for Nahid Taheri
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011217/c660c95d/attachment.vcf 

From mjt at tls.msk.ru  Tue Dec 18 10:37:53 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Tue, 18 Dec 2001 02:37:53 +0300
Subject: ssh host echo bla | echo bla
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <20011217144730.B12209@wdr.com>
Message-ID: <3C1E81D1.60678387@tls.msk.ru>

Nicolas Williams wrote:
[]
>  - with -1, if stdout is a dead pipe, then ssh trie to open /dev/tty?
>  - with -2, if stdout is a dead pipe, then ssh exits?
> 
> Why should one behaviour be correct and the other not?
> 
> I mean, if you've got a broken pipe, print a message to stderr about it,
> and if that's broken too, oh well. Either way exit.
> 
> So I would say that the -1 behaviour is forgiving, but the -2 behaviour
> is correct.

Them aren't consistent at the end.  And -2 doesn't print the error
message (and not tries to logon to remote host).  Can't say about
logging in to remote, but the error message should be printed in
both cases (stderr isn't closed, it's ssh's stdout that's closed).
And both should exit with non-zero return code (imho):

 $ (ssh -1 localhost echo mmm; echo $? >&2) | true
 mjt at localhost's password: 
 Write failed flushing stdout buffer.
 write stdout: Broken pipe
 255
 $ (ssh localhost echo mmm; echo $? >&2) | true
 mjt at localhost's password: 
 0
 $ _

The 255 and 0 are the return codes.  Note that in this case, connection
attempt WAS made by both ssh's (note the passwd prompt).  (openssh-2.2.9p2).

Regards,
 Michael.


From markus at openbsd.org  Tue Dec 18 19:46:39 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 09:46:39 +0100
Subject: disabling sftp authentication using openssh 2.9.9p2...
In-Reply-To: <338D10123297D5119EFB00508B8BFDDFC2BA3C@svratl03.us.lhsgroup.com>
References: <338D10123297D5119EFB00508B8BFDDFC2BA3C@svratl03.us.lhsgroup.com>
Message-ID: <20011218094639.A19119@faui02>

On Mon, Dec 17, 2001 at 03:32:49PM -0500, Ranjitsingh, Kirk wrote:
> I'm trying to use sftp from a 2.9.9p2 client, connecting to a F-Secure 2.4.0
> server, but consistently get the following.

i don't think there is a "F-Secure 2.4.0".

> debug1: authentications that can continue: hostbased,publickey,password
> debug1: next auth method to try is publickey
> debug1: try privkey: /path/acct/.ssh/id_rsa
> debug1: try pubkey: /path/acct/.ssh/id_dsa
> debug1: authentications that can continue: hostbased,publickey,password
> debug1: next auth method to try is password
> acct at remotehostsftp's password:
> 
> Entering the password allow access.  But I'm trying to authenticate with
> having to enter a password.
> 
> The remote host has a copy of the public key from
> /path/acct/.ssh/identity.pub file
> Client host /path/acct/.ssh/id_dsa exists and ssh-agent is running.

if you want to use ssh v2 with id_dsa, you need to copy the matching
public key file to the server. consult your server documentation.

probably you have to use ssh-keygen(1) to convert from openssh
to ssh.com format.
	$ ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh2/dsakey.pub
	$ echo Key dsakey.pub > ~/.ssh2/authorization

-m


From markus at openbsd.org  Tue Dec 18 19:53:21 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 09:53:21 +0100
Subject: cross-compilation failure
In-Reply-To: <D9223EB959A5D511A98F00508B68C20C1F9653@ORSMSX108>
References: <D9223EB959A5D511A98F00508B68C20C1F9653@ORSMSX108>
Message-ID: <20011218095321.C20018@faui02>

On Mon, Dec 17, 2001 at 05:00:30PM -0800, Carlson, Kristen wrote:
> I notice that it is on your TODO list to fix the configure script so that we
> can use it to cross-compile properly with.  Any estimates on when that will
> be done?

sorry, no. but you can send patches to
	openssh-unix-dev at mindrot.org


From guido.paliot at to.com  Tue Dec 18 20:30:22 2001
From: guido.paliot at to.com (Guido Paliot)
Date: Tue, 18 Dec 2001 10:30:22 +0100 (CET)
Subject: openssh, pam and cryptocard's cryptoadmin / easyradius
Message-ID: <Pine.LNX.4.33.0112181020430.11574-100000@elwood.think>

Hi,

this is merely FYI, but i would appreciate if someone had any comments 
or further information on the topic.

We were using the following setup :
cryptocard easyradius with RB-1 hardware tokens (hex or decimal display, 
synchronous (quicklog) mode)
f-secure ssh with pam radius authentication

This worked fine until we updated to openssh 2.9p2. Then all 
authentications where the response included alpha characters did not work 
anymore. That means that users whose tokens were set to hexadecimal 
display could not auhenticate, except when their hex response conatined 
numbers _only_.

We reprogrammed all tokens to decimal display and contacted cryptocard. 
You find their response forwarded.

Regards,

Guido Paliot

-- 
----------------------------------------------------------------------
Guido Paliot                                       guido.paliot at to.com
Thinking Objects                              phone: +49.711.88770.400
Lilienthalstra?e 2                              fax: +49.711.88770.449
70825 Stuttgart-Korntal, Germany
----------------------------------------------------------------------

---------- Forwarded message ----------
Date: Tue, 11 Dec 2001 11:33:38 -0500
From: Felix Franceschina <Felix at cryptocard.com>
To: Guido Paliot <guido.paliot at to.com>
Subject: OpenSSH and PAM

Guido,

    Upgrading to the latest version of CRYPTOAdmin 5.16 will not help.  Here is what happens.

If the sshd pam configuration file is setup like this:
auth    sufficient    /lib/security/pam_radius_auth.so

- A normal numeric respsonse will go through.
- If an alpha numeric response is entered into the response prompt it will take it but then display a challenge and ask for the same response again.
Once the response is entered again you will be connected.

    This is not a function of the CRYPTOAdmin server or the PAM module (the same thing happens with the freeradius.org PAM RADIUS module).  The SSH server doesn't understand the alphanumeric response.  Given the complexity of SSH Clients (Windows and Linux) I suggest changing all your tokens over to numeric if you wish to use SSH.  The other daemons (login, ftp, ppp) do not have this problem. 


Felix Franceschina
Unix Technical Support
CRYPTOCard Corp.
1.800.307.7042
1.613.599.2441
felix at cryptocard.com



---------------------------------------------------------------------
To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com
For additional commands, e-mail: secureshell-help at securityfocus.com



From bugzilla-daemon at mindrot.org  Tue Dec 18 23:02:24 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 18 Dec 2001 23:02:24 +1100 (EST)
Subject: [Bug 42] sh: scp: not found
Message-ID: <20011218120224.19FAB2DF0F@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=42

hampus.lind at rps.police.se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From hampus.lind at rps.police.se  2001-12-18 23:02 -------
I installed a new hp-ux depot witch i found at: 
http://hpux.connect.org.uk/hppd/hpux/Networking/Admin/openssh-3.0.2p1/



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From entwicklung at heubach-edv.de  Tue Dec 18 23:27:28 2001
From: entwicklung at heubach-edv.de (MH - Entwicklung)
Date: Tue, 18 Dec 2001 13:27:28 +0100
Subject: chroot howto for sftp-server
Message-ID: <004901c187bf$ce7c7210$1500c80a@heubachedv.de>

Using OpenSSH SFTP with chroot
==============================

Several people have been asking now for some kind of documentation on how to 
use the chroot-patch for the sftp-server. So here it comes. I hope nobody minds 
that i post this in the developer list.

The patch has been provided to the list some time ago. I'm sorry not giving 
credit to the author, but I really don't know who posted it in the first 
place. Anyway many thanks to all people developing OpenSSH. You are doing a 
great job!

A little note on myself: I'm not very used to programming anymore. I coded a 
lot in the end of the 80s on a Motorola 68000 running on a good old ATARI ST. 
But that's long ago. So better don't ask me about in depth details. Im just 
starting to get back to programming.

The machine on which I made the tests with SFTP CHROOT is running SuSE LINUX 
7.2 with a 2.4.10 kernel. But the following step by step guide should apply to 
all LINUX variants.

Thanks to Ben and Paulius for the feedback.


--------------


Applying the patch doesn't need much programming skills. But you should be 
used to compiling and reading a little bit of C.


1 Obtaining the sources:
========================
Get yourself a copy of the sources of OpenSSH. You can find links for 
downloading them on www.openssh.org.

The patch can be found at the end of this document.


2 Applying the patch:
=====================
Apply the patch to sftp-server.c, compile and install it. 

The patch does the following:
1. It checks if the HOME directory of the user ends with a "/./"
2. If it finds a "/./" it makes a chroot into this HOME directory. If there is 
no "/./" chroot won't be done. This allows you to set up a chroot jail only 
for certain users. The rest of your users has normal access.

(if chroot into the homedir should be done for every user, you can simply  
comment out the portion of the patch which checks for the "/./".)

SSHD calls sftp-server in the context of the authenticated user. So you have 
to make sure sftp-server is SUID and owned by root:

 chown root .../sftp-server
 chmod u+s  .../sftp-server (or chmod 4755)


3 Setting up a user for chroot:
===============================
In /etc/passwd add a "/./" to the users homedir.

e.g. (from passwd):
test:x:502:100::/home/test/./:/chroot/test/sftp-server
                ^^^^^^^^^^^^^

Now you can start sshd and try sftp:
 sftp test at localhost
 test at localhost's password: xxxxxxxx
 pwd
 Remote working directory: /
 exit

Before exiting the sftp session you should check that the sftp-server has 
dropped root priviledges. If not, something went wrong when applying the 
patch.

 ps ef|grep sftp-server

=================
!!! Attention !!!
=================
So far sftp-server is doing chroot correctly. But your users can still access 
your host by ssh and scp. In order to prevent this simply give them sftp-
server as a loginshell. Whenever they try ssh or scp they will fail. You can 
also write a dummy shell. But you have to provide a login shell in any case 
otherwise sshd will not invoke sftp-server for your users. /bin/false as a 
login shell will not work.


4 Security concerns:
====================
In order to prevent your sftp user from playing around with the .ssh directory
you should chown root:root and then chmod 766 the .ssh directory. You can also
chmod it to 000 but this forbids using keys for authentication. If you don't 
trust these users you should only give read access to the .ssh and any file in
it. Keep all files owned by root!

In my environment I also have the homedirs owned by root and I gave only read
access to the users. There are several subdirs in the homedirs which are
writeable for the users.

I'm not sure if it's possible to do something nasty if you give sftp-server as
a login shell. So maybe it's better to use a dummy shell.

5 The Patch:
============
(diff against 3.0.1)

--- sftp-server.c Tue Jul 31 14:42:50 2001
+++ sftp-server.c~ Fri Nov 23 10:56:48 2001
@@ -33,6 +33,8 @@
 #include "sftp.h"
 #include "sftp-common.h"
 
+#define CHROOT
+
 /* helper */
 #define get_int64()   buffer_get_int64(&iqueue);
 #define get_int()   buffer_get_int(&iqueue);
@@ -1008,6 +1010,36 @@
  }
 }
 
+#ifdef CHROOT
+void
+chroot_init(void)
+{
+ char *user_dir, *new_root;
+
+ user_dir = getenv("HOME");
+
+ if (!user_dir)
+  fatal("HOME isn't in environment");
+
+ new_root = user_dir + 1;
+
+ while ((new_root = strchr(new_root, '.')) != NULL) {
+  new_root--;
+  if (strncmp(new_root, "/./", 3) == 0) {
+   *new_root = '\0';
+   new_root += 2;
+
+   if (chroot(user_dir) != 0)
+    fatal("Couldn't chroot to user directory %s: %s",user_dir, strerror(errno));
+
+   setenv("HOME", new_root, 1);
+   break;
+  }
+  new_root += 2;
+ }
+}
+#endif /* CHROOT */
+
 int
 main(int ac, char **av)
 {
@@ -1022,6 +1054,13 @@
 #ifdef DEBUG_SFTP_SERVER
  log_init("sftp-server", SYSLOG_LEVEL_DEBUG1, SYSLOG_FACILITY_AUTH, 0);
 #endif
+
+#ifdef CHROOT
+ chroot_init();
+#endif /* CHROOT */
+
+ if (setuid(getuid()) != 0)
+  fatal("Couldn't drop privileges: %s", strerror(errno));
 
  in = dup(STDIN_FILENO);
  out = dup(STDOUT_FILENO);


--

manfred heubach edv und neue medien
Hindenburgstr. 47
D-73728 Esslingen

Tel. +49 711 9315824
Fax  +49 711 9315825
www.heubach-edv.de


Informationstechnologie und Telekommunikation f?r Unternehmen

-------------- next part --------------
Using OpenSSH SFTP with chroot
==============================

Several people have been asking now for some kind of documentation on how to 
use the chroot-patch for the sftp-server. So here it comes ...

The patch has been provided to the list some time ago. I?m sorry not giving 
credit to the author, but I really don?t know who posted it in the first 
place. Anyway many thanks to all people developing OpenSSH. You are doing a 
great job!

A little note on myself: I'm not very used to programming anymore. I coded a 
lot in the end of the 80s on a Motorola 68000 running on a good old ATARI ST. 
But that's long ago. So better don't ask me about in depth details. Im just 
starting to get back to programming.

The machine on which I made the tests with SFTP CHROOT is running SuSE LINUX 
7.2 with a 2.4.10 kernel. But the following step by step guide should apply to 
all LINUX variants.

Thanks to Ben and Paulius for the feedback.


--------------


Applying the patch doesn't need much programming skills. But you should be 
used to compiling and reading a little bit of C.


1 Obtaining the sources:
========================
Get yourself a copy of the sources of OpenSSH. You can find links for 
downloading them on www.openssh.org.

The patch can be found at the end of this document.


2 Applying the patch:
=====================
Apply the patch to sftp-server.c, compile and install it. 

The patch does the following:
1. It checks if the HOME directory of the user ends with a "/./"
2. If it finds a "/./" it makes a chroot into this HOME directory. If there is 
no "/./" chroot won't be done. This allows you to set up a chroot jail only 
for certain users. The rest of your users has normal access.

(if chroot into the homedir should be done for every user, you can simply  
comment out the portion of the patch which checks for the "/./".)

SSHD calls sftp-server in the context of the authenticated user. So you have 
to make sure sftp-server is SUID and owned by root:

	chown root .../sftp-server
	chmod u+s  .../sftp-server (or chmod 4755)


3 Setting up a user for chroot:
===============================
In /etc/passwd add a "/./" to the users homedir.

e.g. (from passwd):
test:x:502:100::/home/test/./:/chroot/test/sftp-server
                ^^^^^^^^^^^^^

Now you can start sshd and try sftp:
	sftp test at localhost
	test at localhost?s password: xxxxxxxx
	pwd
	Remote working directory: /
	exit

Before exiting the sftp session you should check that the sftp-server has 
dropped root priviledges. If not, something went wrong when applying the 
patch.

	ps ef|grep sftp-server

=================
!!! Attention !!!
=================
So far sftp-server is doing chroot correctly. But your users can still access 
your host by ssh and scp. In order to prevent this simply give them sftp-
server as a loginshell. Whenever they try ssh or scp they will fail. You can 
also write a dummy shell. But you have to provide a login shell in any case 
otherwise sshd will not invoke sftp-server for your users. /bin/false as a 
login shell will not work.


4 Security concerns:
====================
In order to prevent your sftp user from playing around with the .ssh directory
you should chown root:root and then chmod 766 the .ssh directory. You can also
chmod it to 000 but this forbids using keys for authentication. If you don?t 
trust these users you should only give read access to the .ssh and any file in
it. Keep all files owned by root!

In my environment I also have the homedirs owned by root and I gave only read
access to the users. There are several subdirs in the homedirs which are
writeable for the users.

I?m not sure if it?s possible to do something nasty if you give sftp-server as
a login shell. So maybe it?s better to use a dummy shell.

5 The Patch:
============
(diff against 3.0.1)

--- sftp-server.c	Tue Jul 31 14:42:50 2001
+++ sftp-server.c~	Fri Nov 23 10:56:48 2001
@@ -33,6 +33,8 @@
 #include "sftp.h"
 #include "sftp-common.h"
 
+#define CHROOT
+
 /* helper */
 #define get_int64()			buffer_get_int64(&iqueue);
 #define get_int()			buffer_get_int(&iqueue);
@@ -1008,6 +1010,36 @@
 	}
 }
 
+#ifdef CHROOT
+void
+chroot_init(void)
+{
+	char *user_dir, *new_root;
+
+	user_dir = getenv("HOME");
+
+	if (!user_dir)
+		fatal("HOME isn't in environment");
+
+	new_root = user_dir + 1;
+
+	while ((new_root = strchr(new_root, '.')) != NULL) {
+		new_root--;
+		if (strncmp(new_root, "/./", 3) == 0) {
+			*new_root = '\0';
+			new_root += 2;
+
+			if (chroot(user_dir) != 0)
+				fatal("Couldn't chroot to user directory %s: %s",user_dir, strerror(errno));
+
+			setenv("HOME", new_root, 1);
+			break;
+		}
+		new_root += 2;
+	}
+}
+#endif /* CHROOT */
+
 int
 main(int ac, char **av)
 {
@@ -1022,6 +1054,13 @@
 #ifdef DEBUG_SFTP_SERVER
 	log_init("sftp-server", SYSLOG_LEVEL_DEBUG1, SYSLOG_FACILITY_AUTH, 0);
 #endif
+
+#ifdef CHROOT
+	chroot_init();
+#endif /* CHROOT */
+
+	if (setuid(getuid()) != 0)
+		fatal("Couldn't drop privileges: %s", strerror(errno));
 
 	in = dup(STDIN_FILENO);
 	out = dup(STDOUT_FILENO);


From markus at openbsd.org  Wed Dec 19 00:28:52 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 14:28:52 +0100
Subject: chroot howto for sftp-server
In-Reply-To: <004901c187bf$ce7c7210$1500c80a@heubachedv.de>
References: <004901c187bf$ce7c7210$1500c80a@heubachedv.de>
Message-ID: <20011218142852.D28262@faui02>

On Tue, Dec 18, 2001 at 01:27:28PM +0100, MH - Entwicklung wrote:
> 1. It checks if the HOME directory of the user ends with a "/./"

why does sftp-server use $HOME? should it be setuid root and
trust $HOME?


From Nicolas.Williams at ubsw.com  Wed Dec 19 02:31:22 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 10:31:22 -0500
Subject: hang on exit bug under Linux
In-Reply-To: <20011218002143.A26769@foo.birdnet.se>; from Peter Stuge on Tue, Dec 18, 2001 at 12:21:43AM +0100
References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net> <20011214015841.H16141@foo.birdnet.se> <20011214181059.A12650@foo.birdnet.se> <20011217100446.A12209@wdr.com> <20011218002143.A26769@foo.birdnet.se>
Message-ID: <20011218103122.D12209@wdr.com>

On Tue, Dec 18, 2001 at 12:21:43AM +0100, Peter Stuge wrote:
> On Mon, Dec 17, 2001 at 10:04:46AM -0500, Nicolas Williams wrote:
> > > 
> > > The case I'm trying to handle here is "exit-status received for this
> > > channel, but no SSH_MSG_CHANNEL_CLOSE" - when is that a fact?  Sure, if
> > > some other packet than _CHANNEL_EOF or _CHANNEL_CLOSE is received, I'll
> > > know.  And I implemented that first, using a dispatch_preprocess
> > > function that would be run before the message handler. But that doesn't
> > > cut it when there simply aren't any packets arriving..
> > 
> > Hmmm, I would say, if you're backgrounding, you don't care, because if
> > the _CHANNEL_CLOSE is going to arrive you'll exit then anyways...
> > If you're going to exit and risk losing data, then you also don't care
> > when, if ever, the _CHANNEL_CLOSE is to arrive. I would agree that a
> > one-second timer would be nice, but, hey, folk are asking for the right
> > to risk losing data - let them have it.
> 
> If the calls to error() are kept in, it would mean that the message always
> got printed whenever the exit-status request was recevied and also cause the
> _CHANNEL_CLOSE and any other packets sent by the server to never get
> handled..  I wanted to accurately determine the state when exit-message was
> received but not _CHANNEL_CLOSE..  And depending on different server
> implementations, I guess, my assumptions will work..

I still don't understand why you'd care.

Once you've decided that you're going to exit when you get the
session-exit, why wait [more than a short, short period of time]? And
why worry about not handling an SSH_MSG_CHANNEL_CLOSE that might never
come? I mean, if you're exiting because you don't know when the close
message will come, then yeah, you're not going to handle it. That's the
point.

And if you've decided to wait, whether in the foreground or in the
background, then you're waiting anyways and will exit when you get the
channel close message.

I have to look at the patch again to see what these calls to error()
are. But, in any case, ssh should only exit when there's no channels and
sessions still open/alive or when the user forces the client to exit or
when the user has asked that the client exit when the sessions all exit
or when there's an error. Right?

> > > On top of this, much to my disappointment, a backgrounded ssh didn't get
> > > killed when I closed my xterm.  But if it lingers it gets killed.  This
> > > is because bash sends SIGHUP to all jobs when it is exiting.  But since
> > > the ssh fork()s, it's no longer considered to be a job.  Hmm.  I tried
> > > putting a call to setpgrp() and then setsid() in the fork()ed off child,
> > > but that didn't make any difference, obviously I guess.  Is what I want
> > > even possible?
> > 
> > This is because each "job" gets its own process group and the tty send
> > SIGHUP only to the lead job.
> 
> The lead job is bash.  And bash forwards the HUP to all it's "jobs"..  But
> since the ssh process that is a child of bash has exited (leaving a new
> process that it fork()ed off) bash never sends the backgrounded ssh process
> a HUP, since it's not a child of bash.  So my question is sort of bash
> related, but I was hoping it was generic to all shells or maybe even
> processes.  I guess I could try to find an answer somewhere in POSIX?

Right. Hmmm, time to crack open the Stevens books...

> > I don't see a check for whether there are other live sessions. That should
> > be needed because SSHv2 supports multiple sessions per-connection. I
> > think there was a patch floating around to implement a ~ escape for
> > starting new sessions... For now this is no big deal, but it should be
> > easy to add a session_still_live() function to check.
> 
> Yeah, I realized this when I read up on the protocol.  But since it wasn't
> currently used anywhere in OpenSSH I figured I didn't have to care about it. 
> And because of that I didn't see any obivous way to handle it..

Handle that now and this patch will never get in the way of another...  :)

> What sort of channel did this patch let you create in the new session?  I

I think it was for starting a new session after the current one exited.
Or I could be smoking something...

> can see before me a patch turning OpenSSH into a secure "screen"-program,
> which would be sort of cool, but a bit out of scope, none the less..  :)

It would be cool. I imagine turning ssh into a session agent and agent
client, with a master session agent control Unix socket, and a Unix
socket for each session.

But that's for some other time.

> Thanks for the input!

NP.

> 
> //Peter
> 
> -- 
> irc: CareBear\
> irl: Peter Stuge


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 Nicolas.Williams at ubsw.com  Wed Dec 19 02:33:37 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 10:33:37 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1E81D1.60678387@tls.msk.ru>; from Michael Tokarev on Tue, Dec 18, 2001 at 02:37:53AM +0300
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <20011217144730.B12209@wdr.com> <3C1E81D1.60678387@tls.msk.ru>
Message-ID: <20011218103337.E12209@wdr.com>

On Tue, Dec 18, 2001 at 02:37:53AM +0300, Michael Tokarev wrote:
> Nicolas Williams wrote:
> []
> >  - with -1, if stdout is a dead pipe, then ssh trie to open /dev/tty?
> >  - with -2, if stdout is a dead pipe, then ssh exits?
> > 
> > Why should one behaviour be correct and the other not?
> > 
> > I mean, if you've got a broken pipe, print a message to stderr about it,
> > and if that's broken too, oh well. Either way exit.
> > 
> > So I would say that the -1 behaviour is forgiving, but the -2 behaviour
> > is correct.
> 
> Them aren't consistent at the end.  And -2 doesn't print the error
> message (and not tries to logon to remote host).  Can't say about
> logging in to remote, but the error message should be printed in
> both cases (stderr isn't closed, it's ssh's stdout that's closed).
> And both should exit with non-zero return code (imho):

Yes, the -2 should print an error; but what if stderr is also a broken
pipe? (Think "ssh -2 host /bin/echo foo 2>&1 | /bint/true").

And you're right about the exit status.

> Regards,
>  Michael.


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 markus at openbsd.org  Wed Dec 19 03:12:02 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 17:12:02 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1E43E5.33E2E9B@tls.msk.ru>
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <3C1E43E5.33E2E9B@tls.msk.ru>
Message-ID: <20011218171202.A20071@faui02>

On Mon, Dec 17, 2001 at 10:13:41PM +0300, Michael Tokarev wrote:
> Markus Friedl wrote:
> > 
> > ok, consider this:
> > 
> >         $ ssh -1 localhost od /bsd | true
> >         $ ssh -2 localhost od /bsd | true
> > 
> > i think this is a 'bug'
> 
> Definitely. 

especially since
	$ ssh -2 host od /bsd | true
will take some time, but data is not sent to
the client.


From Nicolas.Williams at ubsw.com  Wed Dec 19 03:28:47 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 11:28:47 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218171202.A20071@faui02>; from Markus Friedl on Tue, Dec 18, 2001 at 05:12:02PM +0100
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <3C1E43E5.33E2E9B@tls.msk.ru> <20011218171202.A20071@faui02>
Message-ID: <20011218112847.F12209@wdr.com>

On Tue, Dec 18, 2001 at 05:12:02PM +0100, Markus Friedl wrote:
> On Mon, Dec 17, 2001 at 10:13:41PM +0300, Michael Tokarev wrote:
> > Markus Friedl wrote:
> > > 
> > > ok, consider this:
> > > 
> > >         $ ssh -1 localhost od /bsd | true
> > >         $ ssh -2 localhost od /bsd | true
> > > 
> > > i think this is a 'bug'
> > 
> > Definitely. 
> 
> especially since
> 	$ ssh -2 host od /bsd | true
> will take some time, but data is not sent to
> the client.

So what's the fix? Check to make sure that stdout/stderr are not broken
pipes before starting the connection? And what if the pipe breaks after
the connection is started?

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 markus at openbsd.org  Wed Dec 19 03:37:33 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 17:37:33 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218112847.F12209@wdr.com>
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <3C1E43E5.33E2E9B@tls.msk.ru> <20011218171202.A20071@faui02> <20011218112847.F12209@wdr.com>
Message-ID: <20011218173733.A21185@faui02>

On Tue, Dec 18, 2001 at 11:28:47AM -0500, Nicolas Williams wrote:
> On Tue, Dec 18, 2001 at 05:12:02PM +0100, Markus Friedl wrote:
> > On Mon, Dec 17, 2001 at 10:13:41PM +0300, Michael Tokarev wrote:
> > > Markus Friedl wrote:
> > > > 
> > > > ok, consider this:
> > > > 
> > > >         $ ssh -1 localhost od /bsd | true
> > > >         $ ssh -2 localhost od /bsd | true
> > > > 
> > > > i think this is a 'bug'
> > > 
> > > Definitely. 
> > 
> > especially since
> > 	$ ssh -2 host od /bsd | true
> > will take some time, but data is not sent to
> > the client.
> 
> So what's the fix?

this is why i mail to the list. this list is for people who
send patches :)

even
	$ ssh -n -2 host od /bsd | true
waits very long.


From djast at cs.toronto.edu  Wed Dec 19 03:48:38 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 18 Dec 2001 11:48:38 -0500
Subject: chroot howto for sftp-server 
In-Reply-To: Your message of "Tue, 18 Dec 2001 08:28:52 EST."
             <20011218142852.D28262@faui02> 
Message-ID: <01Dec18.114849edt.453149-3305@jane.cs.toronto.edu>

On Tue, 18 Dec 2001 08:28:52 EST, Markus Friedl writes:
> On Tue, Dec 18, 2001 at 01:27:28PM +0100, MH - Entwicklung wrote:
> > 1. It checks if the HOME directory of the user ends with a "/./"
> 
> why does sftp-server use $HOME? should it be setuid root and
> trust $HOME?

In case Markus's subtlety is lost on some readers: privileged programs
need to be much more careful than this with chroot().  Even though
sftp-server itself gives up its privileges after the chroot(), an
attacker could create hard links to other privileged programs, which
expect to be able to trust absolute paths, and use sftp-server to run
them in unexpected contexts.

This is the reason the chroot() command is, by design, restricted to the
superuser.

Furthermore, it appears that this patch, as written, would allow a user
to gain information about directories he or she should not have
permission to access: for example, if /home/user1 is mode 0700, <user2>
can use this program to try to chroot() to /home/user1/privatedir/.  At
a minimum the attacker may determine whether or not this directory
exists based on whether the chroot() succeeds.

Even if the patch didn't trust $HOME, it doesn't do any sanity checking
on the directory it's chroot()'ing to; a more conservative patch would
verify that the target directory and its contents have nominally
acceptable ownership and permissions, e.g., that the new /, /etc, /dev,
/usr and so on are system-owned and not writable by anyone else.

The patch also fails to chdir() to the new root after the chroot(),
which is among the least of its worries given the problems listed above.

Finally: the manipulation of the environment in chroot_init() does not
look portable or safe: retrieving the value of a variable with getenv(),
modifying it, then setting the same environment variable with a
substring of the original value may be asking a bit much of the setenv()
implementation.

Yecch.

-- 
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 Nicolas.Williams at ubsw.com  Wed Dec 19 03:49:09 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 11:49:09 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218173733.A21185@faui02>; from Markus Friedl on Tue, Dec 18, 2001 at 05:37:33PM +0100
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <3C1E43E5.33E2E9B@tls.msk.ru> <20011218171202.A20071@faui02> <20011218112847.F12209@wdr.com> <20011218173733.A21185@faui02>
Message-ID: <20011218114909.G12209@wdr.com>

On Tue, Dec 18, 2001 at 05:37:33PM +0100, Markus Friedl wrote:
> On Tue, Dec 18, 2001 at 11:28:47AM -0500, Nicolas Williams wrote:
> > So what's the fix?
> 
> this is why i mail to the list. this list is for people who
> send patches :)
> 
> even
> 	$ ssh -n -2 host od /bsd | true
> waits very long.

I don't know if there is a fix. You never know when stdout or stderr
might become broken pipes. You just don't know because the only way to
find out is to poll them or write to them. But if you poll them you lose
because the poll will almost always return right away (they'll almost
always be writable or have an error). And you can't be writing to them
when you have nothing to write.

So the question is what should ssh do *when* ssh discovers that stdout
or stderr are broken pipes.


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 markus at openbsd.org  Wed Dec 19 05:20:02 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 19:20:02 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218114909.G12209@wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Dec 18, 2001 at 11:49:09AM -0500
References: <20011217165031.A14156@faui02> <20011217195025.A1404@faui02> <20011217195940.A7401@faui02> <3C1E43E5.33E2E9B@tls.msk.ru> <20011218171202.A20071@faui02> <20011218112847.F12209@wdr.com> <20011218173733.A21185@faui02> <20011218114909.G12209@wdr.com>
Message-ID: <20011218192002.A27301@folly>

On Tue, Dec 18, 2001 at 11:49:09AM -0500, Nicolas Williams wrote:
> On Tue, Dec 18, 2001 at 05:37:33PM +0100, Markus Friedl wrote:
> > On Tue, Dec 18, 2001 at 11:28:47AM -0500, Nicolas Williams wrote:
> > > So what's the fix?
> > 
> > this is why i mail to the list. this list is for people who
> > send patches :)
> > 
> > even
> > 	$ ssh -n -2 host od /bsd | true
> > waits very long.
> 
> I don't know if there is a fix. You never know when stdout or stderr
> might become broken pipes. You just don't know because the only way to
> find out is to poll them or write to them.

ssh does, just check ssh -vvv.

in the
	$ ssh -n -2 host od /bsd | true
case it seems that client and server deadlock.


From carson at taltos.org  Wed Dec 19 05:53:13 2001
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 18 Dec 2001 13:53:13 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218173733.A21185@faui02>
References: <20011218173733.A21185@faui02>
Message-ID: <667476421.1008683593@[192.168.0.1]>

Under Solaris 8 OpenSSH 2.5.2p3 (I know, I'll upgrade RSN, but that means 
porting my patches forward...), I get:

$ ssh -1 localhost od /bsd | true
carson at localhost's password:
od: cannot open /bsd: No such file or directory

$ ssh -2 localhost od /bsd | true
carson at localhost's password:
od: cannot open /bsd: No such file or directory

It _seems_ like people are saying that since stdout has been closed, ssh 
shouldn't bother connecting. As my above example shows, stderr _is_ still 
connected, and can still receive useful data. Please be _very_ careful 
before you mess with this.

-- 
Carson Gaspar - carson at taltos.org
Queen Trapped in a Butch Body



From vinschen at redhat.com  Wed Dec 19 06:20:09 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 18 Dec 2001 20:20:09 +0100
Subject: [PATCH]: Fix potential security hole in Cygwin version
Message-ID: <20011218202009.G21898@cygbert.vinschen.de>

Hi,

the following patch fixes a potential security hole in the Cygwin
version of sshd.

If you're logging in to a Cygwin sshd with version 2 protocol using an
arbitrary user name which is not in /etc/passwd, the forked sshd which
is handling this connection crashes with a segmentation violation.  The
client side encounters an immediate disconnect ("Connection reset by   
peer").  This could be used by a malicious remote client to enumerate
the user names on the Cygwin server machine.

The cause is that the Cygwin specific function check_nt_auth() is called
in auth1.c and auth2.c with implicitly dereferencing the pointer to struct
passwd to get the pw_uid member as parameter.  This struct passwd pointer
can be NULL if the user isn't found in /etc/passwd.  Other similar funcs
as auth_pam_password() are called getting the structy passwd pointer
itself as parameter, testing it for NULL inside of the function.

Changing the check_nt_auth() to behave that way and changing auth1.c and
auth2.c accordingly solves that problem.

Patch follows.

Thanks,
Corinna

Index: auth1.c
===================================================================
RCS file: /cvs/openssh_cvs/auth1.c,v
retrieving revision 1.46
diff -u -p -r1.46 auth1.c
--- auth1.c	6 Dec 2001 17:55:26 -0000	1.46
+++ auth1.c	18 Dec 2001 19:07:12 -0000
@@ -313,9 +313,9 @@ do_authloop(Authctxt *authctxt)
 
 #ifdef HAVE_CYGWIN
 		if (authenticated &&
-		    !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD,pw->pw_uid)) {
+		    !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD, pw)) {
 			packet_disconnect("Authentication rejected for uid %d.",
-			(int)pw->pw_uid);
+			pw ? (int)pw->pw_uid : -1);
 			authenticated = 0;
 		}
 #else
Index: auth2.c
===================================================================
RCS file: /cvs/openssh_cvs/auth2.c,v
retrieving revision 1.78
diff -u -p -r1.78 auth2.c
--- auth2.c	6 Dec 2001 17:55:26 -0000	1.78
+++ auth2.c	18 Dec 2001 19:07:13 -0000
@@ -341,7 +341,7 @@ userauth_none(Authctxt *authctxt)
 		return(0);
 
 #ifdef HAVE_CYGWIN
-	if (check_nt_auth(1, authctxt->pw->pw_uid) == 0)
+	if (check_nt_auth(1, authctxt->pw) == 0)
 		return(0);
 #endif
 #ifdef USE_PAM
@@ -367,7 +367,7 @@ userauth_passwd(Authctxt *authctxt)
 	packet_done();
 	if (authctxt->valid &&
 #ifdef HAVE_CYGWIN
-		check_nt_auth(1, authctxt->pw->pw_uid) &&
+	    check_nt_auth(1, authctxt->pw) &&
 #endif
 #ifdef USE_PAM
 	    auth_pam_password(authctxt->pw, password) == 1)
@@ -404,7 +404,7 @@ userauth_kbdint(Authctxt *authctxt)
 	xfree(devs);
 	xfree(lang);
 #ifdef HAVE_CYGWIN
-	if (check_nt_auth(0, authctxt->pw->pw_uid) == 0)
+	if (check_nt_auth(0, authctxt->pw) == 0)
 		return(0);
 #endif
 	return authenticated;
@@ -510,7 +510,7 @@ userauth_pubkey(Authctxt *authctxt)
 	xfree(pkalg);
 	xfree(pkblob);
 #ifdef HAVE_CYGWIN
-	if (check_nt_auth(0, authctxt->pw->pw_uid) == 0)
+	if (check_nt_auth(0, authctxt->pw) == 0)
 		return(0);
 #endif
 	return authenticated;
Index: openbsd-compat/bsd-cygwin_util.c
===================================================================
RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v
retrieving revision 1.6
diff -u -p -r1.6 bsd-cygwin_util.c
--- openbsd-compat/bsd-cygwin_util.c	27 Nov 2001 01:19:44 -0000	1.6
+++ openbsd-compat/bsd-cygwin_util.c	18 Dec 2001 19:07:14 -0000
@@ -58,7 +58,7 @@ int binary_pipe(int fd[2])
 	return ret;
 }
 
-int check_nt_auth(int pwd_authenticated, uid_t uid)
+int check_nt_auth(int pwd_authenticated, struct passwd *pw)
 {
 	/*
 	* The only authentication which is able to change the user
@@ -73,6 +73,8 @@ int check_nt_auth(int pwd_authenticated,
 	*/
 	static int has_create_token = -1;
 
+	if (pw == NULL)
+		return 0;
 	if (is_winnt) {
 		if (has_create_token < 0) {
 			struct utsname uts;
@@ -90,7 +92,7 @@ int check_nt_auth(int pwd_authenticated,
 			}
 		}
 		if (has_create_token < 1 &&
-		    !pwd_authenticated && geteuid() != uid)
+		    !pwd_authenticated && geteuid() != pw->pw_uid)
 			return 0;
 	}
 	return 1;
Index: openbsd-compat/bsd-cygwin_util.h
===================================================================
RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v
retrieving revision 1.5
diff -u -p -r1.5 bsd-cygwin_util.h
--- openbsd-compat/bsd-cygwin_util.h	27 Nov 2001 01:19:44 -0000	1.5
+++ openbsd-compat/bsd-cygwin_util.h	18 Dec 2001 19:07:14 -0000
@@ -24,7 +24,7 @@
 
 int binary_open(const char *filename, int flags, ...);
 int binary_pipe(int fd[2]);
-int check_nt_auth(int pwd_authenticated, uid_t uid);
+int check_nt_auth(int pwd_authenticated, struct passwd *pw);
 int check_ntsec(const char *filename);
 void register_9x_service(void);
 
-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From vinschen at redhat.com  Wed Dec 19 06:25:26 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 18 Dec 2001 20:25:26 +0100
Subject: [PATCH]: Fix environment variable size restriction in Cygwin version
Message-ID: <20011218202526.H21898@cygbert.vinschen.de>

Hi,

the following patch changes the Cygwin specific function copy_environment()
to not restricting the strlen of a single environment variable to 512 byte.

The PAM specific function do_pam_environment() (also in session.c) has
the same problem but I don't know if that's important for PAM since
only PAM specific environment variables are copied in that function.

The below patch fixes that problem only for Cygwin for now.

Thanks,
Corinna

Index: session.c
===================================================================
RCS file: /cvs/openssh_cvs/session.c,v
retrieving revision 1.158
diff -u -p -r1.158 session.c
--- session.c	7 Dec 2001 17:26:49 -0000	1.158
+++ session.c	18 Dec 2001 19:07:14 -0000
@@ -918,25 +918,29 @@ void do_pam_environment(char ***env, u_i
 #ifdef HAVE_CYGWIN
 void copy_environment(char ***env, u_int *envsize)
 {
-	char *equals, var_name[512], var_val[512];
+	char *var_name = NULL, *var_val;
+	size_t size = 0, i_size;
 	int i;
 
 	for(i = 0; environ[i] != NULL; i++) {
-		if ((equals = strstr(environ[i], "=")) == NULL)
+		if ((i_size = strlen(environ[i]) + 1) < 3)
 			continue;
 
-		if (strlen(environ[i]) < (sizeof(var_name) - 1)) {
-			memset(var_name, '\0', sizeof(var_name));
-			memset(var_val, '\0', sizeof(var_val));
-
-			strncpy(var_name, environ[i], equals - environ[i]);
-			strcpy(var_val, equals + 1);
+		if (i_size > size) {
+			var_name = xrealloc(var_name, i_size);
+		    	size = i_size;
+		}
+		strcpy(var_name, environ[i]);
+		if ((var_val = strchr(var_name, '=')) != NULL) {
+			*var_val++ = '\0';
 
 			debug3("Copy environment: %s=%s", var_name, var_val);
 
 			child_set_env(env, envsize, var_name, var_val);
 		}
 	}
+	if (var_name)
+		xfree(var_name);
 }
 #endif
 

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From vinschen at redhat.com  Wed Dec 19 06:29:26 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 18 Dec 2001 20:29:26 +0100
Subject: [PATCH]: Fix typo in contrib/cygwin/README
Message-ID: <20011218202926.I21898@cygbert.vinschen.de>

Hi,

the following patch fixes just a typo in the Cygwin's README file.

Thanks,
Corinna

Index: contrib/cygwin/README
===================================================================
RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v
retrieving revision 1.7
diff -u -p -r1.7 README
--- contrib/cygwin/README	27 Nov 2001 01:19:44 -0000	1.7
+++ contrib/cygwin/README	18 Dec 2001 19:07:14 -0000
@@ -83,12 +83,12 @@ If you start sshd as deamon via cygrunsr
 If starting via inetd, copy sshd to eg. /usr/sbin/in.sshd and add the
 following line to your inetd.conf file:
 
-sshd stream tcp nowait root /usr/sbin/in.sshd sshd -i
+ssh stream tcp nowait root /usr/sbin/in.sshd sshd -i
 
 Moreover you'll have to add the following line to your
 ${SYSTEMROOT}/system32/drivers/etc/services file:
 
-   sshd         22/tcp          #SSH daemon
+   ssh         22/tcp          #SSH daemon
 
 ===========================================================================
 The following restrictions only apply to Cygwin versions up to 1.3.1

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From stevesk at pobox.com  Wed Dec 19 07:29:54 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Tue, 18 Dec 2001 12:29:54 -0800 (PST)
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011217170027.F21898@cygbert.vinschen.de>
Message-ID: <Pine.HPX.4.43.0112181229030.1584-100000@jenny>

On Mon, 17 Dec 2001, Corinna Vinschen wrote:
:at least for three days now I can't update my sources from CVS.
:When connecting to the CVS server I'm getting a
:
:cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused
:
:message.  I'd like to make a `cvs diff' since I have an important
:patch related to a SEGV in the Cygwin sshd.
:
:What's the problem with bass.directhit.com?

well, Rob Hagopian <rob at hagopian.net> said he would look into it.  i don't
think anyone else can do much.



From mjt at tls.msk.ru  Wed Dec 19 08:16:55 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Wed, 19 Dec 2001 00:16:55 +0300
Subject: ssh host echo bla | echo bla
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]>
Message-ID: <3C1FB247.D82D8025@tls.msk.ru>

Carson Gaspar wrote:
[]
> It _seems_ like people are saying that since stdout has been closed, ssh
> shouldn't bother connecting. As my above example shows, stderr _is_ still
> connected, and can still receive useful data. Please be _very_ careful
> before you mess with this.

Ops -- this is another point of view and a direction.  For me, that was
obvious that ssh should NOT depend on it's environment (i.e. are filedescr.
opened or not), but it should ALWAYS do what it was asked for, and print
any error message as appropriate.  I.e. for me, the -2 behaviour was
incorrect, not -1 one.

Well, what to do if we can't write error message is totally different
story (well, ignoring errors while printing error messages seems to be
a good way).  But ssh should do what it has been asked to, or attempt to
do that -- it should NEVER try to "optimize" it's work by e.g. eliminating
connection attempt if e.g. stdout is closed.  That to say -- I think that
ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
(i.e. do what it was asked for and print any error message), but NOT the
reverse.

Regards,
 Michael.


From markus at openbsd.org  Wed Dec 19 08:20:43 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 22:20:43 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <667476421.1008683593@[192.168.0.1]>
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]>
Message-ID: <20011218222043.B4252@faui02>

On Tue, Dec 18, 2001 at 01:53:13PM -0500, Carson Gaspar wrote:
> Under Solaris 8 OpenSSH 2.5.2p3 (I know, I'll upgrade RSN, but that means 
> porting my patches forward...), I get:
> 
> $ ssh -1 localhost od /bsd | true
> carson at localhost's password:
> od: cannot open /bsd: No such file or directory
> 
> $ ssh -2 localhost od /bsd | true
> carson at localhost's password:
> od: cannot open /bsd: No such file or directory

you don't get the deadlock in this case. you need to od an existing
file.

-m


From Nicolas.Williams at ubsw.com  Wed Dec 19 08:37:07 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 16:37:07 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1FB247.D82D8025@tls.msk.ru>; from Michael Tokarev on Wed, Dec 19, 2001 at 12:16:55AM +0300
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru>
Message-ID: <20011218163707.H12209@wdr.com>

On Wed, Dec 19, 2001 at 12:16:55AM +0300, Michael Tokarev wrote:
> Carson Gaspar wrote:
> []
> > It _seems_ like people are saying that since stdout has been closed, ssh
> > shouldn't bother connecting. As my above example shows, stderr _is_ still
> > connected, and can still receive useful data. Please be _very_ careful
> > before you mess with this.
> 
> Ops -- this is another point of view and a direction.  For me, that was
> obvious that ssh should NOT depend on it's environment (i.e. are filedescr.
> opened or not), but it should ALWAYS do what it was asked for, and print
> any error message as appropriate.  I.e. for me, the -2 behaviour was
> incorrect, not -1 one.
> 
> Well, what to do if we can't write error message is totally different
> story (well, ignoring errors while printing error messages seems to be
> a good way).  But ssh should do what it has been asked to, or attempt to
> do that -- it should NEVER try to "optimize" it's work by e.g. eliminating
> connection attempt if e.g. stdout is closed.  That to say -- I think that
> ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> (i.e. do what it was asked for and print any error message), but NOT the
> reverse.

Why not? I think exiting when stdout or stderr are broken is fine, as
long as it's documented. :)

Deadlocking is not.

> Regards,
>  Michael.


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 mjt at tls.msk.ru  Wed Dec 19 08:51:55 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Wed, 19 Dec 2001 00:51:55 +0300
Subject: ssh host echo bla | echo bla
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru> <20011218163707.H12209@wdr.com>
Message-ID: <3C1FBA7B.4ED709C0@tls.msk.ru>

Nicolas Williams wrote:
> 
[]
> > connection attempt if e.g. stdout is closed.  That to say -- I think that
> > ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> > (i.e. do what it was asked for and print any error message), but NOT the
> > reverse.
> 
> Why not? I think exiting when stdout or stderr are broken is fine, as
> long as it's documented. :)

Because it is (sometimes) legal action to do -- to run ssh w/o stdout, that
is.  If ssh is transparent (i.e. it runs commands on the remote just like
if them are running on a local box), then let it be transparent.  If it is
ok to say "echo foo | echo bar" on a local box (while stupid), it should be
the same with ssh (and with the error messages and exit codes).  Remote
command may not produce anyhing -- and not having a valid stdout isn't a
reason to skip running it at all.

BTW, on linux even,

  cat /dev/zero | true

will NOT produce any error message, but

 (cat /dev/zero; echo $?) | true

also NOT prints anything -- subshell in () was killed by SIGPIPE
(if memory serves me correctly, the same will print something
sensitive/useful on solaris).  But if the same will be called from
a e.g. perl program with proper redirections, perl will be able to
detect that first process killed (by SIGPIPE) and not exited normally.

> Deadlocking is not.

Yes, obviously.

Regards,
 Michael.


From markus at openbsd.org  Wed Dec 19 09:11:56 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 18 Dec 2001 23:11:56 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1FB247.D82D8025@tls.msk.ru>
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru>
Message-ID: <20011218231156.C4252@faui02>

On Wed, Dec 19, 2001 at 12:16:55AM +0300, Michael Tokarev wrote:
> But ssh should do what it has been asked to, or attempt to
> do that --

sure.

> it should NEVER try to "optimize" it's work by e.g. eliminating
> connection attempt if e.g. stdout is closed.

yes, this was never considered. ssh will always connect
since it will not try to write to stdout before authentication
succeeds.

> That to say -- I think that
> ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> (i.e. do what it was asked for and print any error message), but NOT the
> reverse.

yes, where's a patch :) ?


From Nicolas.Williams at ubsw.com  Wed Dec 19 09:35:45 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 17:35:45 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <3C1FBA7B.4ED709C0@tls.msk.ru>; from Michael Tokarev on Wed, Dec 19, 2001 at 12:51:55AM +0300
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru> <20011218163707.H12209@wdr.com> <3C1FBA7B.4ED709C0@tls.msk.ru>
Message-ID: <20011218173545.I12209@wdr.com>

On Wed, Dec 19, 2001 at 12:51:55AM +0300, Michael Tokarev wrote:
> Nicolas Williams wrote:
> > 
> []
> > > connection attempt if e.g. stdout is closed.  That to say -- I think that
> > > ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> > > (i.e. do what it was asked for and print any error message), but NOT the
> > > reverse.
> > 
> > Why not? I think exiting when stdout or stderr are broken is fine, as
> > long as it's documented. :)
> 
> Because it is (sometimes) legal action to do -- to run ssh w/o stdout, that
> is.  If ssh is transparent (i.e. it runs commands on the remote just like

If I want to run ssh without stdout I redirect its stdout to /dev/null,
NOT to a broken pipe. I don't think it's useful to use a broken pipe on
purpose as the stdout of anything. If ssh can't output because stdout is
broken then, IMHO, it should try to log an error message to stderr and/or
syslog and then exit.

> if them are running on a local box), then let it be transparent.  If it is
> ok to say "echo foo | echo bar" on a local box (while stupid), it should be
> the same with ssh (and with the error messages and exit codes).  Remote
> command may not produce anyhing -- and not having a valid stdout isn't a
> reason to skip running it at all.

/bin/od /kernel/genunix | /bin/true

exits right away on Solaris (sooner than "/bin/od /kernel/genunix|wc").

/bin/od /dev/zero | /bin/true

hangs on Solaris - /bin/od sits there reading and reading - never
writing.

ssh -v -v -v -2 somehost /bin/od /kernel/genunix | /bin/true

hangs on Solaris and here's the key bit of the stderr output:

...
debug1: Sending command: /bin/od /kernel/genunix
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
debug1: channel 0: write failed
debug1: channel 0: output open -> closed
debug1: channel 0: close_write
<hang>

I think that ssh should have: a) printed an error message to stderr (and
syslog, if that failed) when "debug1: channel 0: write failed" and b)
exited.

With "ssh -v -v -v -2 somehost /bin/od /dev/zero | /bin/true" the hang
occurs because ssh never has a reason to print to stdout BECAUSE /bin/od
/dev/zero DOESN'T PRINT ANYTHING, so ssh never finds out that stdout is
broken, and then there's nothing special for it to do.

SIGPIPE and EPIPE are produced synchronously - i.e., when ssh writes to
stdout - so if ssh doesn't write to stdout it can't know that stdout is
broken.

> BTW, on linux even,
> 
>   cat /dev/zero | true
> 
> will NOT produce any error message, but

See above. /bin/od apparently wants to summarize all the nulls in the
input, so /dev/zero is a bad candidate for this test.

>  (cat /dev/zero; echo $?) | true

(/bin/od /kernel/genunix; print -u2 $?)|/bin/true
141

on Solaris.

(/bin/od /dev/zero; print -u2 $?)|/bin/true      

hangs, on Solaris. Again, /bin/od and /dev/zero - bad test case.

> also NOT prints anything -- subshell in () was killed by SIGPIPE
> (if memory serves me correctly, the same will print something
> sensitive/useful on solaris).  But if the same will be called from
> a e.g. perl program with proper redirections, perl will be able to
> detect that first process killed (by SIGPIPE) and not exited normally.

Default action for SIGPIPE is ignore, I think.

> > Deadlocking is not.
> 
> Yes, obviously.

Right. See above. OpenSSH notices the broken stdout and does nothing and
that's the reason for the hang and the problem altogether.

> Regards,
>  Michael.


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 arnim at med-dev.co.nz  Wed Dec 19 09:44:47 2001
From: arnim at med-dev.co.nz (Arnim Littek)
Date: Wed, 19 Dec 2001 11:44:47 +1300 (NZDT)
Subject: ssh: limits on authorized_keys2 (fwd)
Message-ID: <Pine.LNX.4.21.0112191129310.18196-101000@chameleon.logical.co.nz>

Damien wrote:
> Could you redo your traces with "-v -v -v" set? Best send the report to
> openssh-unix-dev at mindrot.org so it isn't just myself looking at it.

Attached are a number of log files from a problem I'm seeing with
DSA/authorized_keys2 when operating ssh strictly with Protocol
2.  Damien has not been able to reproduce it with his RSA setup.

When my server has more than X entries in authorized_keys2, the ssh
connection is rejected, whereas when that pubkey is in the first X,
the connection works fine.  All that I am doing in between is
shuffling the order of the pubkeys.  On one machine, X=2, on the
machine I did this logging on, X=3.

There's a nice, clear error message in the server's auth.log:

Dec 19 11:10:26 cabrio sshd[23206]: fatal: buffer_get: trying to get
more bytes 128 than in buffer 91

which has to be a useful clue.  Files in the attached tarball:

auth.log-cabrio  - server /var/log/auth.log
log_auth2cabrio.1stposn - failed ssh login, logged via: 
           ssh -v -v -v -4 cabrio 2> log_auth2cabrio.1stposn  
log_auth2cabrio.4thposn - successful ssh login, same command line,
           except for logfilename and ordering of pubkeys in
             cabrio:/home/arnim/.ssh/authorized_keys2
ssh_config-fox - client /etc/ssh/ssh_config
sshd_config-cabrio - server /etc/ssh/sshd_config

Note that this example is done between a RedHat client and a Debian
server, but I have seen the same fault with an OBSD 3.0 server and
other clients.

I hope this is sufficient to motivate someone to have a poke at the
buffer_get code...  Any other information on the circumstance is
available upon request.

Arnim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auth2log.tar.gz
Type: application/x-gzip
Size: 3724 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011219/5f763c99/attachment.bin 

From Nicolas.Williams at ubsw.com  Wed Dec 19 09:56:31 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 18 Dec 2001 17:56:31 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218231156.C4252@faui02>; from Markus Friedl on Tue, Dec 18, 2001 at 11:11:56PM +0100
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru> <20011218231156.C4252@faui02>
Message-ID: <20011218175631.J12209@wdr.com>

On Tue, Dec 18, 2001 at 11:11:56PM +0100, Markus Friedl wrote:
> On Wed, Dec 19, 2001 at 12:16:55AM +0300, Michael Tokarev wrote:
> > But ssh should do what it has been asked to, or attempt to
> > do that --
> 
> sure.
> 
> > it should NEVER try to "optimize" it's work by e.g. eliminating
> > connection attempt if e.g. stdout is closed.
> 
> yes, this was never considered. ssh will always connect
> since it will not try to write to stdout before authentication
> succeeds.

Right. See my other post from the last few minutes. Ssh does find that
stdout is broken when there's output from the remote command and then
simply closes stdout.

> > That to say -- I think that
> > ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> > (i.e. do what it was asked for and print any error message), but NOT the
> > reverse.
> 
> yes, where's a patch :) ?

The patch should be to nchan.c:chan_write_failed2() - it should check
whether the fildes being closed is stdout (or stderr), and if so, print
an error / log an error and then call fatal().

Simple enough, yes? Correct? I think so.

Caveat emptor: ssh will not find out about stdout/stderr being broken
pipes until it has reason to write to stdout/stderr.

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 qralston+ml.openssh-unix-dev at andrew.cmu.edu  Wed Dec 19 10:29:46 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Tue, 18 Dec 2001 18:29:46 -0500 (EST)
Subject: openssh and defensive programming (or lack thereof)
In-Reply-To: <20011114144549.A20807@folly>
Message-ID: <Pine.LNX.4.33.0112181824040.17967-100000@pcmy.sei.cmu.edu>

Before I start, a disclaimer: I've spent (literally) a few weeks
pondering this issue and how to best raise it (where I define "best"
as meaning "most likely to lead to a productive dialog" instead of
"most likely to fill the openssh-unix-dev mailing list with random
flamage").  Despite that, some of what I say will no doubt be
abrasive, or perhaps even offensive.  That's not my intent.  My intent
is to help make openssh a better, more secure software product.

On Wed, 14 Nov 2001, Markus Friedl wrote:

>> ------- Additional Comments From ralston at pobox.com  2001-11-13
>> 15:59 ------- The question is irrelevant; regardless of how one
>> chooses to answer it, the answer does not make sshd's behavior (of
>> not making sure all inherited descriptors are closed) any less
>> broken.
> 
> no, i don't understand. if the program calling sshd breaks because
> sshd does not close fd 142 on startup, then the program is broken.
> it must close its filedescriptors.

Ok, fine.  Let's declare that a startup procedure/program that leaves
descriptors other than [0,1,2] open when it invokes sshd is broken.

But sshd is still broken, regardless of whether the startup
procedure/program is broken.  That is the point I am trying to get
across.

> [daemons] need to make sure to close fd 0-2.  closing 1024 file
> descriptors on startup does not fix bugs, it only fixes symptoms and
> hides the actual bugs.

But this is one of the main ideas of defensive programming: trying to
anticipate what bugs might be in your program (or others' programs),
and coding in such a way that if bugs *are* discovered, their damage
is minimized.

And I'm talking about *bugs in sshd* here.  Any security conscious
program, when starting, should clear file descriptors that it doesn't
need.  There have been several programs, including sendmail, that
could be exploited by opening all but a couple of file descriptors,
and then starting the program and having it die due to an unexpected
shortage of file descriptors.  In some cases, it was possible to turn
this into a root level exploit.

When I originally filed a bug report on this, you closed it with
NOTABUG.  Before you did so, did you conduct an audit of the entire
OpenSSH source tree, and verify that it was impossible for the attack
described above to cause sshd to malfunction, and/or allow privilege
escalation?  Did you?  If you didn't (as I highly suspect), then why
not?

I attended the LISA 2001 conference at the beginning of this month,
and I had lunch with two of the OpenBSD people who were there.
Unfortunately, I don't now remember their names, but they both said
that you were a really great guy, and that you cared a lot about
OpenSSH.  ("OpenSSH is Markus' baby", as one of them put it.)

If this is true, then I challenge you to do the right: FIX THE DAMN
BUG IN SSHD, and just as important, FIX YOUR ATTITUDE.  I can and will
patch the former for you (as I already did, and already offered to
redo), but I can't correct your (apparent) religious opposition to
defensive programming, which will ultimately cause you to create new
bugs in OpenSSH faster than they can be fixed.

(I'll have the reworked patch in a few days, BTW.)

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From deraadt at cvs.openbsd.org  Wed Dec 19 10:36:44 2001
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 18 Dec 2001 16:36:44 -0700
Subject: openssh and defensive programming (or lack thereof) 
In-Reply-To: Your message of "Tue, 18 Dec 2001 18:29:46 EST."
             <Pine.LNX.4.33.0112181824040.17967-100000@pcmy.sei.cmu.edu> 
Message-ID: <200112182336.fBINai3I004909@cvs.openbsd.org>

I agree with Markus that closing all file descriptors in all daemons is
retarded.

It is not defensive.  It is a waste of time.

That said, the file descriptor handling code, especially the fd_set
padding, was written to be very careful.

Please submit real bug reports, not "defensive programming"
discussions.


From deraadt at cvs.openbsd.org  Wed Dec 19 10:41:17 2001
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 18 Dec 2001 16:41:17 -0700
Subject: openssh and defensive programming (or lack thereof) 
In-Reply-To: Your message of "Tue, 18 Dec 2001 16:36:44 MST."
             <200112182336.fBINai3I004909@cvs.openbsd.org> 
Message-ID: <200112182341.fBINfH3I030071@cvs.openbsd.org>

Let me be even more clear.

You are basically suggesting that we add "close all file descriptor"
loops to every daemon in our source tree.

For some reason, even when we firmly believe in not using such
"defensive programming" techniques, we have been doing better than the
entire industry.  Perhaps because we don't rely on such code-clogging
techniques, but read and re-read the source code.


From ccwf at bacchus.com  Wed Dec 19 11:45:54 2001
From: ccwf at bacchus.com (Charles C. Fu)
Date: 18 Dec 2001 16:45:54 -0800
Subject: Bug#66740: ssh-askpass-gnome: The first password is always bad (was: OpenSSH 3.0)
In-Reply-To: <Pine.LNX.4.33.0112111649370.20647-100000@mothra.mindrot.org>
References: <Pine.LNX.4.33.0112111649370.20647-100000@mothra.mindrot.org>
Message-ID: <874rmokpfh.fsf@thanatar.east.bacchus.com>

In <Pine.LNX.4.33.0112111649370.20647-100000 at mothra.mindrot.org>
   on 10 Dec 2001, djm at mindrot.org <djm at mindrot.org> wrote:
> Please report future portable OpenSSH bugs at
> http://bugzilla.mindrot.org/ - it makes them easier to track.

Sorry, is the URL above in the documentation?  I didn't see it and so
didn't know about it.

> Could you try this patch?

Patch appears to work fine, enabling a two write passphrase to be
read.  I tested with SSH_ASKPASS set to the following simple script

  #!/bin/sh -
  echo -n '<passphrase>'
  sleep 6
  echo

and verified using gdb that the new logic now reads all the characters
written.  I have not regression tested to be sure the new code still
handles the passphrase >= sizeof buf case (readpass v1.23), but the
code looks visually OK to me.

As a side note, I don't think the memset at the end is necessary,
although we were fortunate before that it happened to let ssh-add
function properly the second time the passphrase was read (because the
memset had zeroed that area of the stack and nothing else overwrote it
between the calls to ssh_askpass).

-ccwf


From mouring at etoh.eviladmin.org  Wed Dec 19 15:43:09 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 18 Dec 2001 22:43:09 -0600 (CST)
Subject: openssh and defensive programming (or lack thereof)
In-Reply-To: <Pine.LNX.4.33.0112181824040.17967-100000@pcmy.sei.cmu.edu>
Message-ID: <Pine.BSO.4.33.0112182200090.10214-100000@etoh.eviladmin.org>



On Tue, 18 Dec 2001, James Ralston wrote:

> Before I start, a disclaimer: I've spent (literally) a few weeks
> pondering this issue and how to best raise it (where I define "best"
> as meaning "most likely to lead to a productive dialog" instead of
> "most likely to fill the openssh-unix-dev mailing list with random
> flamage").  Despite that, some of what I say will no doubt be
> abrasive, or perhaps even offensive.  That's not my intent.  My intent
> is to help make openssh a better, more secure software product.
>
> On Wed, 14 Nov 2001, Markus Friedl wrote:
>
> >> ------- Additional Comments From ralston at pobox.com  2001-11-13
> >> 15:59 ------- The question is irrelevant; regardless of how one
> >> chooses to answer it, the answer does not make sshd's behavior (of
> >> not making sure all inherited descriptors are closed) any less
> >> broken.
> >
> > no, i don't understand. if the program calling sshd breaks because
> > sshd does not close fd 142 on startup, then the program is broken.
> > it must close its filedescriptors.
>
> Ok, fine.  Let's declare that a startup procedure/program that leaves
> descriptors other than [0,1,2] open when it invokes sshd is broken.
>

First off let me ensure something is crystal clear..

1) If Markus applied every patch for  every broken OS to the OpenBSD code
it would be impossible to audit and we return back to the dark aged of SSH
1.2.x days where hacks were applied to hack until the code was soo bad
that no one  understood why it worked or did not work. (Which is why the
original hack to v1 was applied.  No one took the @#$%^&* time to
understand nor care!) [There is a reason we have 'portable' releases.]

2) This is an issue with how each OS handles tty and file descriptors.  In
which (I will freely admit) is not something I fully can grasp on a
programming level, but still does not invalid what has been pointed out by
Markus and others as what the core issue is.

3) I'm all for Defensive programming when it is correct, but applying a
bandaid to an application and proclaiming 'This is defensive programming'
is pure and utter horse crap.  And to steal a line from Princess Bride,
"Anyone telling you differently is selling something."

No one (including myself) has ever gotten to the HEART of the issue (Even
if Markus has brough it up over and over).  It keeps being outskirted by
everyone who has been bitching about it.  *WHY* is this occuring on some
platforms?  *WHAT* are we *NOT* doing *CORRECTLY* to have it work on some
systems, and fail on others?

No one has yet come up with answers to such questions. I repeat.. *NO
ONE*..Of course people have suggested bandaids or what they would 'like'
OpenSSH to do, but that does not solve the bug.  IT just covers it up.

Why can I take MySQL right from the raw .tar.gz file steal the startup
script from Redhat and not have a problem restarting it on my Sparc SS20
running OpenBSD?  Yet compiling the *SAME* code on Redhat/Mandrake/etc
using the *SAME* start up script it hangs.  Are we vhang() in the worng
place?  are we not following SysV rules for group processes..  SOMEONE
GIVE ME NON-BULLSHIT reason and not 'Because telnet does not do it'..
Which is not a valid reason.

Are you starting to see the point?  If not I suggest you re-read this
email and dig through some of Linus' rants about solving the bug and not
covering them up.  He make a lot of very good points.

- Ben
Disclaimer: I am not a foaming at the mouth Linus, Linux, nor OpenBSD
fan.  Hell.. I rip on every OS I use and develop on equally.  Don't
believe me drop by #unixhelp on efnet and ask around.  You'll find it is
not limited to OS rants either (try perl, php, C, stupid users, people who
don't 'RTFM', or don't care to do their research, etc).



From djm at mindrot.org  Wed Dec 19 16:41:45 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 19 Dec 2001 16:41:45 +1100 (EST)
Subject: openssh and defensive programming (or lack thereof)
In-Reply-To: <Pine.LNX.4.33.0112181824040.17967-100000@pcmy.sei.cmu.edu>
Message-ID: <Pine.LNX.4.33.0112191623270.8117-100000@mothra.mindrot.org>

On Tue, 18 Dec 2001, James Ralston wrote:

> If this is true, then I challenge you to do the right: FIX THE DAMN
> BUG IN SSHD, and just as important, FIX YOUR ATTITUDE.  I can and will
> patch the former for you (as I already did, and already offered to
> redo), but I can't correct your (apparent) religious opposition to
> defensive programming, which will ultimately cause you to create new
> bugs in OpenSSH faster than they can be fixed.

You are telling the OpenBSD developers how to write secure code. Surely
you appreciate the irony here. OpenBSD's track record is worth megabytes
of polemic about development methodology.

Of the (minor) security problems that OpenSSH has had in the past three
years, how many do you think would have been avoided through this doctrine
of "defensive programming"?

sshd is a system service. If your broken system is passing stray fds to
sshd upon (re)start, you need to fix your system - it is that simple.
Why uglify every daemon on your system when you can fix the problem where
it lies? Think about what would happen if this was carried to its logical
conclusion...

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From djm at mindrot.org  Wed Dec 19 16:44:33 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 19 Dec 2001 16:44:33 +1100 (EST)
Subject: What's the problem with the CVS repository?
In-Reply-To: <Pine.HPX.4.43.0112181229030.1584-100000@jenny>
Message-ID: <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org>

On Tue, 18 Dec 2001, Kevin Steves wrote:

> On Mon, 17 Dec 2001, Corinna Vinschen wrote:
> :at least for three days now I can't update my sources from CVS.
> :When connecting to the CVS server I'm getting a
> :
> :cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused
> :
> :message.  I'd like to make a `cvs diff' since I have an important
> :patch related to a SEGV in the Cygwin sshd.
> :
> :What's the problem with bass.directhit.com?
> 
> well, Rob Hagopian <rob at hagopian.net> said he would look into it.  i don't
> think anyone else can do much.

There is a new anoncvs server which has just become active. Details 
are at http://www.openssh.com/portable.html

I should also mention that snapshots are now also available directly from 
the OpenBSD mirrors.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From deraadt at cvs.openbsd.org  Wed Dec 19 16:49:09 2001
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 18 Dec 2001 22:49:09 -0700
Subject: openssh and defensive programming (or lack thereof) 
In-Reply-To: Your message of "Wed, 19 Dec 2001 16:41:45 +1100."
             <Pine.LNX.4.33.0112191623270.8117-100000@mothra.mindrot.org> 
Message-ID: <200112190549.fBJ5n93I004586@cvs.openbsd.org>

> sshd is a system service. If your broken system is passing stray fds to
> sshd upon (re)start, you need to fix your system - it is that simple.
> Why uglify every daemon on your system when you can fix the problem where
> it lies? Think about what would happen if this was carried to its logical
> conclusion...

Actually, we have done such cleanup.

Without following those incorrect defensive methods.

You may notice that sshd, like the rest of openbsd, does dynamic
fd_set manipulation....


From entwicklung at heubach-edv.de  Wed Dec 19 18:32:25 2001
From: entwicklung at heubach-edv.de (MH - Entwicklung)
Date: Wed, 19 Dec 2001 08:32:25 +0100
Subject: chroot howto for sftp-server 
References: <01Dec18.114849edt.453149-3305@jane.cs.toronto.edu>
Message-ID: <001f01c1885f$4e3b3be0$1500c80a@heubachedv.de>

Dear Dan,

of course this chroot patch is very quick and dirty and doesn't make any further checks. On the other hand - if I give the users which will get the chrooted sftp-server no shell login they shouldn't be able to play around with $HOME. I think $HOME can be trusted in this special case:

$HOME ist set to the home path given in passwd with every new shell a user opens. After connecting to ssh $HOME ist set from passwd. As I give no real shell but only sftp-server as the login shell no manipulation of $HOME should be possible.

I can see a problem for "trusted" users who login via ssh then manipulate their $HOME and then invoke the chrooted sftp-server. They will be able to access directories they shouldn't have access to. And if file permissions under this directories are set in a lax way this really means that users can access files they shouldn't see at all.

The only way to prevent this is to give no shell login to anybody. Another idea is to use a special "chroot control file" - but that means some more coding :-)

As I already mentioned I don't know if there are any possibilities using sftp-server itself for doing "nasty" things.

If I'm completely wrong with trusting $HOME please let me know.


Regards
Manfred Heubach

----- Original Message ----- 
From: "Dan Astoorian" <djast at cs.toronto.edu>
To: "MH - Entwicklung" <entwicklung at heubach-edv.de>; <openssh-unix-dev at mindrot.org>
Sent: Tuesday, December 18, 2001 5:48 PM
Subject: Re: chroot howto for sftp-server 


> On Tue, 18 Dec 2001 08:28:52 EST, Markus Friedl writes:
> > On Tue, Dec 18, 2001 at 01:27:28PM +0100, MH - Entwicklung wrote:
> > > 1. It checks if the HOME directory of the user ends with a "/./"
> > 
> > why does sftp-server use $HOME? should it be setuid root and
> > trust $HOME?
> 
> In case Markus's subtlety is lost on some readers: privileged programs
> need to be much more careful than this with chroot().  Even though
> sftp-server itself gives up its privileges after the chroot(), an
> attacker could create hard links to other privileged programs, which
> expect to be able to trust absolute paths, and use sftp-server to run
> them in unexpected contexts.
> 
> This is the reason the chroot() command is, by design, restricted to the
> superuser.
> 
> Furthermore, it appears that this patch, as written, would allow a user
> to gain information about directories he or she should not have
> permission to access: for example, if /home/user1 is mode 0700, <user2>
> can use this program to try to chroot() to /home/user1/privatedir/.  At
> a minimum the attacker may determine whether or not this directory
> exists based on whether the chroot() succeeds.
> 
> Even if the patch didn't trust $HOME, it doesn't do any sanity checking
> on the directory it's chroot()'ing to; a more conservative patch would
> verify that the target directory and its contents have nominally
> acceptable ownership and permissions, e.g., that the new /, /etc, /dev,
> /usr and so on are system-owned and not writable by anyone else.
> 
> The patch also fails to chdir() to the new root after the chroot(),
> which is among the least of its worries given the problems listed above.
> 
> Finally: the manipulation of the environment in chroot_init() does not
> look portable or safe: retrieving the value of a variable with getenv(),
> modifying it, then setting the same environment variable with a
> substring of the original value may be asking a bit much of the setenv()
> implementation.
> 
> Yecch.
> 
> -- 
> 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 shorty at getuid.de  Wed Dec 19 23:42:26 2001
From: shorty at getuid.de (Christian Kurz)
Date: Wed, 19 Dec 2001 13:42:26 +0100
Subject: What's the problem with the CVS repository?
In-Reply-To: <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org>
References: <Pine.HPX.4.43.0112181229030.1584-100000@jenny> <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org>
Message-ID: <20011219124226.GC731@salem.getuid.de>

On 19/12/01, Damien Miller wrote:
> On Tue, 18 Dec 2001, Kevin Steves wrote:

> > On Mon, 17 Dec 2001, Corinna Vinschen wrote:
> > :at least for three days now I can't update my sources from CVS.
> > :When connecting to the CVS server I'm getting a
> > :
> > :cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused
> > :
> > :message.  I'd like to make a `cvs diff' since I have an important
> > :patch related to a SEGV in the Cygwin sshd.
> > :
> > :What's the problem with bass.directhit.com?

> > well, Rob Hagopian <rob at hagopian.net> said he would look into it.  i don't
> > think anyone else can do much.

> There is a new anoncvs server which has just become active. Details 
> are at http://www.openssh.com/portable.html

Hm, according to the website description it now uses SSH? Doesn't this
have the implication that only people who's ssh key is included in the
authorized_keys file are able to do a checkout? If not, how is it then
supposed to work? And why was it changed from pserver to ssh now? 

Christian
-- 
If you live long enough, you'll see that every victory turns into a defeat.
                -- Simone de Beauvoir


From markus at openbsd.org  Thu Dec 20 00:46:36 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 19 Dec 2001 14:46:36 +0100
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011219124226.GC731@salem.getuid.de>
References: <Pine.HPX.4.43.0112181229030.1584-100000@jenny> <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org> <20011219124226.GC731@salem.getuid.de>
Message-ID: <20011219144636.F16664@faui02>

On Wed, Dec 19, 2001 at 01:42:26PM +0100, Christian Kurz wrote:
> On 19/12/01, Damien Miller wrote:
> > On Tue, 18 Dec 2001, Kevin Steves wrote:
> 
> > > On Mon, 17 Dec 2001, Corinna Vinschen wrote:
> > > :at least for three days now I can't update my sources from CVS.
> > > :When connecting to the CVS server I'm getting a
> > > :
> > > :cvs [update aborted]: connect to bass.directhit.com:2401 failed: Connection refused
> > > :
> > > :message.  I'd like to make a `cvs diff' since I have an important
> > > :patch related to a SEGV in the Cygwin sshd.
> > > :
> > > :What's the problem with bass.directhit.com?
> 
> > > well, Rob Hagopian <rob at hagopian.net> said he would look into it.  i don't
> > > think anyone else can do much.
> 
> > There is a new anoncvs server which has just become active. Details 
> > are at http://www.openssh.com/portable.html
> 
> Hm, according to the website description it now uses SSH? Doesn't this
> have the implication that only people who's ssh key is included in the
> authorized_keys file are able to do a checkout?

no.

> If not, how is it then
> supposed to work?

no password.

> And why was it changed from pserver to ssh now? 

different provider, different service. what's wrong with ssh?


From shorty at getuid.de  Thu Dec 20 01:29:08 2001
From: shorty at getuid.de (Christian Kurz)
Date: Wed, 19 Dec 2001 15:29:08 +0100
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011219144636.F16664@faui02>; from markus@openbsd.org on Wed, Dec 19, 2001 at 02:46:36PM +0100
References: <Pine.HPX.4.43.0112181229030.1584-100000@jenny> <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org> <20011219124226.GC731@salem.getuid.de> <20011219144636.F16664@faui02>
Message-ID: <20011219152908.B31074@bofh.de>

On 01-12-19 Markus Friedl wrote:
> On Wed, Dec 19, 2001 at 01:42:26PM +0100, Christian Kurz wrote:
[...]
> > And why was it changed from pserver to ssh now? 

> different provider, different service. what's wrong with ssh?

Hm, I just wonder why the cvs is hanging for me. I have the variable
echo $CVS_RSH correctly set and with an other project, that's working
fine. But when I try to run

|cvs -z3 -dopenssh at anoncvs.be.openbsd.org:/cvs get openssh

it hangs. And will using strace, I saw that it hangs here:

|connect(4, {sin_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("157.193.69.9")}}, 16

I then verified via mtr that I can reach that host (9 hops) and that no
packet loss is occuring. So could anyone please tell me, what the
problem is?

Christian
-- 
Always do right.  This will gratify some people and astonish the rest.
                -- Mark Twain


From wichert at wiggy.net  Thu Dec 20 02:35:45 2001
From: wichert at wiggy.net (Wichert Akkerman)
Date: Wed, 19 Dec 2001 16:35:45 +0100
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011219152908.B31074@bofh.de>
References: <Pine.HPX.4.43.0112181229030.1584-100000@jenny> <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org> <20011219124226.GC731@salem.getuid.de> <20011219144636.F16664@faui02> <20011219152908.B31074@bofh.de>
Message-ID: <20011219153545.GB26099@wiggy.net>

Previously Christian Kurz wrote:
> I then verified via mtr that I can reach that host (9 hops) and that no
> packet loss is occuring. So could anyone please tell me, what the
> problem is?

ECN?

Wichert.

-- 
  _________________________________________________________________
 /wichert at wiggy.net         This space intentionally left occupied \
| wichert at deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


From djast at cs.toronto.edu  Thu Dec 20 02:46:30 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Wed, 19 Dec 2001 10:46:30 -0500
Subject: chroot howto for sftp-server 
In-Reply-To: Your message of "Wed, 19 Dec 2001 02:32:25 EST."
             <001f01c1885f$4e3b3be0$1500c80a@heubachedv.de> 
Message-ID: <01Dec19.104638edt.453146-7551@jane.cs.toronto.edu>

On Wed, 19 Dec 2001 02:32:25 EST, "MH - Entwicklung" writes:
> 
> I can see a problem for "trusted" users who login via ssh then 
> manipulate their $HOME and then invoke the chrooted sftp-server. They 
> will be able to access directories they shouldn't have access to. And if 
> file permissions under this directories are set in a lax way this really 
> means that users can access files they shouldn't see at all.

The problem is greater than this: it's an avenue of attack for these
users to *crack root*.  Applying your patch and making sftp-server
setuid-root makes the system less secure, not more; and forgive my
bluntness, but providing instructions that advise people to apply a
half-assed patch with no mention of the potential holes it opens up is
just plain irresponsible.

> The only way to prevent this is to give no shell login to anybody. 

No, a better way to prevent the trusted-$HOME problem is to use the
/etc/passwd entry (i.e., getpwnam(getlogin()) or getpwuid(getuid()))
instead of an environment variable which the user can manipulate.

Ideally there should still be additional sanity checks on the target
directory, but at least this puts the responsibility for ensuring that
the target is secure into the hands of the system administrator.

On that topic, your instructions advise controlling the permissions and
ownership of the ~/.ssh directory, but doesn't talk about setting up and
controlling the chroot() target or the user's home directory itself at
all.

Also, I think there's already been consensus here that it would be wiser
to chroot() to a subdirectory of the user's home directory, rather than
the home directory itself, in order to avoid an entire class of attacks
(such as manipulating ~/.ssh, uploading dot files which may be used to
cause other programs to run commands, e.g., ~/.bashrc, ~/.forward,
etc.).

> If I'm completely wrong with trusting $HOME please let me know.

You're completely wrong with trusting $HOME.  :-)

-- 
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 markus at openbsd.org  Thu Dec 20 03:26:39 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 19 Dec 2001 17:26:39 +0100
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011218175631.J12209@wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Dec 18, 2001 at 05:56:31PM -0500
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru> <20011218231156.C4252@faui02> <20011218175631.J12209@wdr.com>
Message-ID: <20011219172639.B3149@folly>

On Tue, Dec 18, 2001 at 05:56:31PM -0500, Nicolas Williams wrote:
> On Tue, Dec 18, 2001 at 11:11:56PM +0100, Markus Friedl wrote:
> > On Wed, Dec 19, 2001 at 12:16:55AM +0300, Michael Tokarev wrote:
> > > But ssh should do what it has been asked to, or attempt to
> > > do that --
> > 
> > sure.
> > 
> > > it should NEVER try to "optimize" it's work by e.g. eliminating
> > > connection attempt if e.g. stdout is closed.
> > 
> > yes, this was never considered. ssh will always connect
> > since it will not try to write to stdout before authentication
> > succeeds.
> 
> Right. See my other post from the last few minutes. Ssh does find that
> stdout is broken when there's output from the remote command and then
> simply closes stdout.
> 
> > > That to say -- I think that
> > > ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> > > (i.e. do what it was asked for and print any error message), but NOT the
> > > reverse.
> > 
> > yes, where's a patch :) ?
> 
> The patch should be to nchan.c:chan_write_failed2() - it should check
> whether the fildes being closed is stdout (or stderr), and if so, print
> an error / log an error and then call fatal().
> 
> Simple enough, yes? Correct? I think so.

i think the ssh client should close the 'channel' when both the local
read and write FDs are closed.

-m


From Gunnar.Bluth at drkw.com  Thu Dec 20 03:46:26 2001
From: Gunnar.Bluth at drkw.com (Gunnar.Bluth at drkw.com)
Date: Wed, 19 Dec 2001 17:46:26 +0100
Subject: Problems with aged passwords (Red Hat 7.x, OpenSSH 2.9.x-3.0.2p1)
Message-ID: <200112191649.QAA18462@frank.dresdnerkb.com>

We're experiencing weird problems here:

The Solaris guys have user-packages, so we had to do this too for the Linux 
boxes (7.0, 7.1).
Since some of the accounts get "easy" passwords set at install time, they are 
expired at once:
/usr/bin/chage -m 7 -M 84 -W 14 <user>

Now, at login, the user is prompted:

You are required to change your password immediately (root enforced)
Warning: Your password has expired, please change it now
Changing password for <user>
(current) UNIX password:xxxxxxxx
New UNIX password:xxxxxxx          (and yes, it definitly is a good one ;-) )
BAD PASSWORD: is too simple
New UNIX password:
and so on...

2.9.9p2 even showed what was typed in plain text, 3.x.x doesn't (at least...).
/var/log/messages just says:

[...] sshd(pam_unix)[20078]: expired password for user f998628 (root enforced)

but no clues why pam_cracklib fails (or whatever happens..).

This does nor appear on the machines (yet) using 2.5.2p2.

We need the enhanced SSH2-handling, thus we really hope anybody has a 
solution to this...

Thx in advance,

Nick



----------------------------------------------------------------------
If you have received this e-mail in error or wish to read our e-mail 
disclaimer statement and monitoring policy, please refer to 
http://www.drkw.com/disc/email/ or contact the sender.
----------------------------------------------------------------------


From tschroed at media.mit.edu  Thu Dec 20 03:51:44 2001
From: tschroed at media.mit.edu (Trevor Schroeder)
Date: Wed, 19 Dec 2001 11:51:44 -0500
Subject: Patch for DU SIA auth
Message-ID: <20011219115140.M1147@diesel.media.mit.edu>

Hello.  The following is a patch against OpenSSH 3.0.2p1 to fix OpenSSH's
handling of Tru64 SIA authentication.  The main changes are to make the
SIAENTITY a global variable (so that it remains persistent across function
calls), initialization only happens once, the session is only released
once.  This makes SIA modules that require authentication in order to
perform certain actions during the session launch call work properly.

For example, we have a Kerberos 5 / AFS SIA module here that requires that
the user authenticate durring sia_ses_authent and then uses the information
stored in the SIAENTITY during ses_launch to fetch krb tickets and afs
tokens.

diff -c openssh-3.0.2p1/auth-sia.c openssh-3.0.2p1-tschroed/auth-sia.c
*** openssh-3.0.2p1/auth-sia.c	Mon Apr 16 04:37:05 2001
--- openssh-3.0.2p1-tschroed/auth-sia.c	Thu Dec  6 13:02:26 2001
***************
*** 21,32 ****
  extern char **saved_argv;
  
  extern int errno;
  
  int
  auth_sia_password(char *user, char *pass)
  {
  	int ret;
- 	SIAENTITY *ent = NULL;
  	const char *host;
  
  	host = get_canonical_hostname(options.reverse_mapping_check);
--- 21,32 ----
  extern char **saved_argv;
  
  extern int errno;
+ SIAENTITY *__sia_ent = NULL;
  
  int
  auth_sia_password(char *user, char *pass)
  {
  	int ret;
  	const char *host;
  
  	host = get_canonical_hostname(options.reverse_mapping_check);
***************
*** 34,51 ****
  	if (!user || !pass)
  		return(0);
  
! 	if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, NULL, 0,
  	    NULL) != SIASUCCESS)
  		return(0);
  
! 	if ((ret = sia_ses_authent(NULL, pass, ent)) != SIASUCCESS) {
  		error("couldn't authenticate %s from %s", user, host);
  		if (ret & SIASTOP)
! 			sia_ses_release(&ent);
  		return(0);
  	}
  
- 	sia_ses_release(&ent);
  
  	return(1);
  }
--- 34,50 ----
  	if (!user || !pass)
  		return(0);
  
! 	if (sia_ses_init(&__sia_ent, saved_argc, saved_argv, host, user, NULL, 0,
  	    NULL) != SIASUCCESS)
  		return(0);
  
! 	if ((ret = sia_ses_authent(NULL, pass, __sia_ent)) != SIASUCCESS) {
  		error("couldn't authenticate %s from %s", user, host);
  		if (ret & SIASTOP)
! 			sia_ses_release(&__sia_ent);
  		return(0);
  	}
  
  
  	return(1);
  }
***************
*** 55,84 ****
  {
  	int ret;
  	struct passwd *pw;
! 	SIAENTITY *ent = NULL;
  	const char *host;
  
  	host = get_canonical_hostname (options.reverse_mapping_check);
  
- 	if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0,
- 	    NULL) != SIASUCCESS) {
- 		error("sia_ses_init failed");
- 		exit(1);
- 	}
- 
  	if ((pw = getpwnam(user)) == NULL) {
! 		sia_ses_release(&ent);
  		error("getpwnam(%s) failed: %s", user, strerror(errno));
  		exit(1);
  	}
! 	if (sia_make_entity_pwd(pw, ent) != SIASUCCESS) {
! 		sia_ses_release(&ent);
  		error("sia_make_entity_pwd failed");
  		exit(1);
  	}
  
! 	ent->authtype = SIA_A_NONE;
! 	if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) {
  		error("couldn't establish session for %s from %s", user,
  		    host);
  		exit(1);
--- 54,77 ----
  {
  	int ret;
  	struct passwd *pw;
! 	/* SIAENTITY *__sia_ent = NULL; */
  	const char *host;
  
  	host = get_canonical_hostname (options.reverse_mapping_check);
  
  	if ((pw = getpwnam(user)) == NULL) {
! 		sia_ses_release(&__sia_ent);
  		error("getpwnam(%s) failed: %s", user, strerror(errno));
  		exit(1);
  	}
! 	if (sia_make_entity_pwd(pw, __sia_ent) != SIASUCCESS) {
! 		sia_ses_release(&__sia_ent);
  		error("sia_make_entity_pwd failed");
  		exit(1);
  	}
  
! 	__sia_ent->authtype = SIA_A_NONE;
! 	if (sia_ses_estab(sia_collect_trm, __sia_ent) != SIASUCCESS) {
  		error("couldn't establish session for %s from %s", user,
  		    host);
  		exit(1);
***************
*** 85,106 ****
  	}
  
  	if (setpriority(PRIO_PROCESS, 0, 0) == -1) {
! 		sia_ses_release(&ent);
  		error("setpriority failed: %s", strerror (errno));
  		exit(1);
  	}
  
! 	if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) {
  		error("couldn't launch session for %s from %s", user, host);
  		exit(1);
  	}
  	
! 	sia_ses_release(&ent);
  
  	if (setreuid(geteuid(), geteuid()) < 0) {
  		error("setreuid failed: %s", strerror (errno));
  		exit(1);
  	}
  }
  
  #endif /* HAVE_OSF_SIA */
--- 78,100 ----
  	}
  
  	if (setpriority(PRIO_PROCESS, 0, 0) == -1) {
! 		sia_ses_release(&__sia_ent);
  		error("setpriority failed: %s", strerror (errno));
  		exit(1);
  	}
  
! 	if (sia_ses_launch(sia_collect_trm, __sia_ent) != SIASUCCESS) {
  		error("couldn't launch session for %s from %s", user, host);
  		exit(1);
  	}
  	
! 	sia_ses_release(&__sia_ent);
  
  	if (setreuid(geteuid(), geteuid()) < 0) {
  		error("setreuid failed: %s", strerror (errno));
  		exit(1);
  	}
+ 	sia_ses_release(&__sia_ent);
  }
  
  #endif /* HAVE_OSF_SIA */


From heubach at heubach-edv.de  Thu Dec 20 03:53:44 2001
From: heubach at heubach-edv.de (Manfred Heubach)
Date: Wed, 19 Dec 2001 17:53:44 +0100
Subject: chroot howto for sftp-server 
References: <01Dec19.104638edt.453146-7551@jane.cs.toronto.edu>
Message-ID: <00a501c188ad$b8543290$1500c80a@heubachedv.de>

Dear Dan,

of course you're right. I should have mentioned that this patch may open security holes and that everybody has to decide on his own wether to use this patch or not. Sorry for that!

But back to a possible solution:
1. If I change the patch to access the information from passwd this solves the $HOME issue.

2. Then we could change the directory for chroot to something like /home/username/chroot instead of the home directory itself. This would prevent the users from accessing the home directory and .ssh at all.

(My instructions suggested to chown .ssh to root:root and chmod it and all files in it to 755 (I looked into my howto right now and this is really bad because there I told to chmod 766 - which is complete bullshit). If .ssh is owned by root and 755 then users can read files from .ssh but not change them or upload files to .ssh. Furthermore I mentioned that I have the homedirs themselves owned by root and only readable for the users. This - of course - should have been recommended.)

3. Sanity checks on the chroot target are beyond my scope. As I already told I'm not very up to date with programming.


Regards
Manfred


----- Original Message ----- 
From: "Dan Astoorian" <djast at cs.toronto.edu>
To: "MH - Entwicklung" <entwicklung at heubach-edv.de>
Cc: <openssh-unix-dev at mindrot.org>
Sent: Wednesday, December 19, 2001 4:46 PM
Subject: Re: chroot howto for sftp-server 


> On Wed, 19 Dec 2001 02:32:25 EST, "MH - Entwicklung" writes:
> > 
> > I can see a problem for "trusted" users who login via ssh then 
> > manipulate their $HOME and then invoke the chrooted sftp-server. They 
> > will be able to access directories they shouldn't have access to. And if 
> > file permissions under this directories are set in a lax way this really 
> > means that users can access files they shouldn't see at all.
> 
> The problem is greater than this: it's an avenue of attack for these
> users to *crack root*.  Applying your patch and making sftp-server
> setuid-root makes the system less secure, not more; and forgive my
> bluntness, but providing instructions that advise people to apply a
> half-assed patch with no mention of the potential holes it opens up is
> just plain irresponsible.
> 
> > The only way to prevent this is to give no shell login to anybody. 
> 
> No, a better way to prevent the trusted-$HOME problem is to use the
> /etc/passwd entry (i.e., getpwnam(getlogin()) or getpwuid(getuid()))
> instead of an environment variable which the user can manipulate.
> 
> Ideally there should still be additional sanity checks on the target
> directory, but at least this puts the responsibility for ensuring that
> the target is secure into the hands of the system administrator.
> 
> On that topic, your instructions advise controlling the permissions and
> ownership of the ~/.ssh directory, but doesn't talk about setting up and
> controlling the chroot() target or the user's home directory itself at
> all.
> 
> Also, I think there's already been consensus here that it would be wiser
> to chroot() to a subdirectory of the user's home directory, rather than
> the home directory itself, in order to avoid an entire class of attacks
> (such as manipulating ~/.ssh, uploading dot files which may be used to
> cause other programs to run commands, e.g., ~/.bashrc, ~/.forward,
> etc.).
> 
> > If I'm completely wrong with trusting $HOME please let me know.
> 
> You're completely wrong with trusting $HOME.  :-)
> 
> -- 
> 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 nalin at redhat.com  Thu Dec 20 04:01:24 2001
From: nalin at redhat.com (Nalin Dahyabhai)
Date: Wed, 19 Dec 2001 12:01:24 -0500
Subject: Problems with aged passwords (Red Hat 7.x, OpenSSH 2.9.x-3.0.2p1)
In-Reply-To: <200112191649.QAA18462@frank.dresdnerkb.com>; from Gunnar.Bluth@drkw.com on Wed, Dec 19, 2001 at 05:46:26PM +0100
References: <200112191649.QAA18462@frank.dresdnerkb.com>
Message-ID: <20011219120124.C6634@redhat.com>

On Wed, Dec 19, 2001 at 05:46:26PM +0100, Gunnar.Bluth at drkw.com wrote:
> We're experiencing weird problems here:
> 
> The Solaris guys have user-packages, so we had to do this too for the Linux 
> boxes (7.0, 7.1).
> Since some of the accounts get "easy" passwords set at install time, they are 
> expired at once:
> /usr/bin/chage -m 7 -M 84 -W 14 <user>
> 
> Now, at login, the user is prompted:
> 
> You are required to change your password immediately (root enforced)
> Warning: Your password has expired, please change it now
> Changing password for <user>
> (current) UNIX password:xxxxxxxx
> New UNIX password:xxxxxxx          (and yes, it definitly is a good one ;-) )
> BAD PASSWORD: is too simple
> New UNIX password:
> and so on...

This is a pam_cracklib bug.  Because 7.0 and 7.1 sound like version
numbers of RHL, I'll point you at the update for RHL 7.1 at
http://www.redhat.com/support/errata/RHBA-2001-149.html.  The updates
for 7.1 should work without difficulties on 7.0.

Cheers,

Nalin


From bugzilla-daemon at mindrot.org  Thu Dec 20 04:15:42 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 20 Dec 2001 04:15:42 +1100 (EST)
Subject: [Bug 55] [PATCH] Kerberos v5 support in portable
Message-ID: <20011219171542.22B922DF43@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=55





------- Additional Comments From simon at sxw.org.uk  2001-12-20 04:15 -------
Created an attachment (id=6)
Patch to provide MIT Kerberos 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  Thu Dec 20 04:25:10 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 20 Dec 2001 04:25:10 +1100 (EST)
Subject: [Bug 49] Banner /etc/issue.net is not displayed
Message-ID: <20011219172510.2E02D2DF3A@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=49

markus at openbsd.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME



------- Additional Comments From markus at openbsd.org  2001-12-20 04:25 -------
The banner is displayed for protocol v2 and for clients
that support this feature.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From Gunnar.Bluth at drkw.com  Thu Dec 20 04:30:55 2001
From: Gunnar.Bluth at drkw.com (Bluth, Gunnar)
Date: Wed, 19 Dec 2001 18:30:55 +0100
Subject: Problems with aged passwords (Red Hat 7.x, OpenSSH 2.9.x-3.0.
	2p1)
Message-ID: <F14059C75C32934AA7F5B3831BAC095124EE5A@ibfftce502.is.de.dresdnerkb.com>

Ooops, I missed that one, sorry.
I'll see if it helps.

Thx.

Nick

	Nick (Gunnar) Bluth
	Linux Systems Administrator
	Dresdner Kleinwort Wasserstein 
	Dresdner Bank AG 
	Global Business Services     <mailto: gunnar.bluth at DrKW.com> 
	IT Operational Integrity     Voice:  +49 69 263 57913  (97000 -
57913) 
	J?rgen-Ponto-Platz 1         Fax:    +49 69 263 16994  (97000 -
16994) 
	D-60301 Frankfurt am Main    Mobile: +49 172 8853339	 

	Linux Admin Team:     <mailto: DrKWlinux at DrKW.com> 
	Linux Support Team:  <mailto:DrKWfftlinuxsupport at DrKW.com> 




> -----Original Message-----
> From:	Nalin Dahyabhai [SMTP:nalin at redhat.com]
> Sent:	19 December 2001 18:01
> To:	Gunnar.Bluth at drkw.com
> Cc:	openssh-unix-dev at mindrot.org
> Subject:	Re: Problems with aged passwords (Red Hat 7.x, OpenSSH
> 2.9.x-3.0.2p1)
> 
> On Wed, Dec 19, 2001 at 05:46:26PM +0100, Gunnar.Bluth at drkw.com wrote:
> > We're experiencing weird problems here:
> > 
> > The Solaris guys have user-packages, so we had to do this too for the
> Linux 
> > boxes (7.0, 7.1).
> > Since some of the accounts get "easy" passwords set at install time,
> they are 
> > expired at once:
> > /usr/bin/chage -m 7 -M 84 -W 14 <user>
> > 
> > Now, at login, the user is prompted:
> > 
> > You are required to change your password immediately (root enforced)
> > Warning: Your password has expired, please change it now
> > Changing password for <user>
> > (current) UNIX password:xxxxxxxx
> > New UNIX password:xxxxxxx          (and yes, it definitly is a good one
> ;-) )
> > BAD PASSWORD: is too simple
> > New UNIX password:
> > and so on...
> 
> This is a pam_cracklib bug.  Because 7.0 and 7.1 sound like version
> numbers of RHL, I'll point you at the update for RHL 7.1 at
> http://www.redhat.com/support/errata/RHBA-2001-149.html.  The updates
> for 7.1 should work without difficulties on 7.0.
> 
> Cheers,
> 
> Nalin


If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.


From bugzilla-daemon at mindrot.org  Thu Dec 20 05:40:57 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 20 Dec 2001 05:40:57 +1100 (EST)
Subject: [Bug 54] ssh does not respect /etc/host.conf
Message-ID: <20011219184057.4FA1D2DF08@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=54

sfllaw at engmail.uwaterloo.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From sfllaw at engmail.uwaterloo.ca  2001-12-20 05:40 -------
Further investigation reveals that this is not an SSH bug.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From Nicolas.Williams at ubsw.com  Thu Dec 20 05:51:34 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 19 Dec 2001 13:51:34 -0500
Subject: ssh host echo bla | echo bla
In-Reply-To: <20011219172639.B3149@folly>; from Markus Friedl on Wed, Dec 19, 2001 at 05:26:39PM +0100
References: <20011218173733.A21185@faui02> <667476421.1008683593@[192.168.0.1]> <3C1FB247.D82D8025@tls.msk.ru> <20011218231156.C4252@faui02> <20011218175631.J12209@wdr.com> <20011219172639.B3149@folly>
Message-ID: <20011219135134.K12209@wdr.com>

On Wed, Dec 19, 2001 at 05:26:39PM +0100, Markus Friedl wrote:
> On Tue, Dec 18, 2001 at 05:56:31PM -0500, Nicolas Williams wrote:
> > The patch should be to nchan.c:chan_write_failed2() - it should check
> > whether the fildes being closed is stdout (or stderr), and if so, print
> > an error / log an error and then call fatal().
> > 
> > Simple enough, yes? Correct? I think so.
> 
> i think the ssh client should close the 'channel' when both the local
> read and write FDs are closed.

I'm not sure I understand. You're saying that SSH should close the [ssh]
channel (ok, yes) but only if stdin *and* stdout are broken/closed? I
would change that "and" to "or" and add stderr. And after closing the
ssh channel the client would exit, yes? Assuming no in-use port/agent/X
forwardings.


> -m


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 greg at nest.cx  Thu Dec 20 06:56:58 2001
From: greg at nest.cx (Gregory Steuck)
Date: Wed, 19 Dec 2001 11:56:58 -0800
Subject: public key authentication failure
Message-ID: <20011219115658.A13411@dirty.nest.cx>

Hello,

I am attempting to make public key authentication to work between
OpenSSH 3.0.2 client on OpenBSD and SSH-1.99-OpenSSH_2.9 FreeBSD
localisations 20011202. From reading sshd -ddd and ssh -v I can't
figure out what goes wrong. Could somebody interpret the attached
typescripts for me, please?

Here's the relevant part from the server log and I don't understand it:

debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1005/1005 (e=0)
debug1: restore_uid
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Failed publickey for incomingmail from cl.ie.nt.ip port 29365 ssh2

Another thing that puzzles me is why does it start asking for s/key
authentication? I don't even have opie setup on the server side.  I am
pretty sure it has something to do with FreeBSD "localisations".

Thanks
Greg
-------------- next part --------------
Script started on Wed Dec 19 11:36:56 2001
$ sudo -u art ~art/sendartmail
Password:
OpenSSH_3.0.2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 1002 geteuid 1002 anon 1
debug1: Connecting to server.example.com [se.rv.er.ip] port 2222.
debug1: temporarily_use_uid: 1002/999 (e=1002)
debug1: restore_uid
debug1: temporarily_use_uid: 1002/999 (e=1002)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/art/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9 FreeBSD localisations 20011202
debug1: match: OpenSSH_2.9 FreeBSD localisations 20011202 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2
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: 127/256
debug1: bits set: 521/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server.example.org' is known and matches the RSA host key.
debug1: Found key in /home/art/.ssh/known_hosts:3
debug1: bits set: 538/1024
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try pubkey: /home/art/.ssh/id_rsa
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is keyboard-interactive
otp-md5 391 bu2613 ext
S/Key Password: 
debug1: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64)
Connection closed by se.rv.er.ip
debug1: Calling cleanup 0x1b7e0(0x0)
$ 
Script done on Wed Dec 19 11:38:08 2001
-------------- next part --------------
Script started on Wed Dec 19 11:40:22 2001
[greg at bum tmp]$ sudo /usr/sbin/sshd -ddd -p 2222
debug1: sshd version OpenSSH_2.9 FreeBSD localisations 20011202
debug1: private host key: #0 type 0 RSA1
debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #2 type 1 RSA
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from client.example.com port 29365
Connection from cl.ie.nt.ip port 29365
debug1: Client protocol version 2.0; client software version OpenSSH_3.0.2
debug1: match: OpenSSH_3.0.2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.9 FreeBSD localisations 20011202
debug1: Rhosts Authentication disabled, originating port not trusted.
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: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se
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: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se
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
debug2: kex_parse_kexinit: none
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 aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
WARNING: /etc/ssh/primes does not exist, using old prime
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 128/256
debug1: bits set: 538/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 521/1024
debug2: ssh_rsa_sign: done
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug3: Trying to reverse map address cl.ie.nt.ip.
debug1: userauth-request for user incomingmail service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for incomingmail
debug1: Starting up PAM with username "incomingmail"
debug2: input_userauth_request: try method none
Failed none for incomingmail from cl.ie.nt.ip port 29365 ssh2
debug1: userauth-request for user incomingmail service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1005/1005 (e=0)
debug1: restore_uid
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Failed publickey for incomingmail from cl.ie.nt.ip port 29365 ssh2
debug1: userauth-request for user incomingmail service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive language  devs 
Postponed keyboard-interactive for incomingmail from cl.ie.nt.ip port 29365 ssh2
^C
Script done on Wed Dec 19 11:41:35 2001

From bugzilla-daemon at mindrot.org  Thu Dec 20 08:02:01 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 20 Dec 2001 08:02:01 +1100 (EST)
Subject: [Bug 37] Another SGI warning
Message-ID: <20011219210201.D65F42DF4B@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=37

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com



------- Additional Comments From stevesk at pobox.com  2001-12-20 08:01 -------
i'm not sure we want to try to silence every warning for valid C.
in the other cases it made sense, i don't really know about this
one.  but we could add 2 _UNKNOWN enums to silence this.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From jmknoble at pobox.com  Thu Dec 20 11:05:46 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 19 Dec 2001 19:05:46 -0500
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011219152908.B31074@bofh.de>; from shorty@getuid.de on Wed, Dec 19, 2001 at 03:29:08PM +0100
References: <Pine.HPX.4.43.0112181229030.1584-100000@jenny> <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org> <20011219124226.GC731@salem.getuid.de> <20011219144636.F16664@faui02> <20011219152908.B31074@bofh.de>
Message-ID: <20011219190546.K3026@zax.half.pint-stowp.cx>

Circa 2001-Dec-19 15:29:08 +0100 dixit Christian Kurz:

: Hm, I just wonder why the cvs is hanging for me. I have the variable
: echo $CVS_RSH correctly set and with an other project, that's working
: fine. But when I try to run
: 
: |cvs -z3 -dopenssh at anoncvs.be.openbsd.org:/cvs get openssh

Don't you mean:

   cvs -z3 -d:ext:openssh at anoncvs.be.openbsd.org:/cvs get openssh
             ^^^^^

?

-- 
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/20011219/7d98e193/attachment.bin 

From Albert-Lunde at northwestern.edu  Thu Dec 20 11:55:00 2001
From: Albert-Lunde at northwestern.edu (Albert Lunde)
Date: Wed, 19 Dec 2001 18:55:00 -0600
Subject: warnings building openssh-3.0.2p1 on HP-UX 10.20
Message-ID: <p05100306b846e17be1c5@[129.105.188.80]>

I'm getting a number of compiler warnings about type mismatches, 
building openssh-3.0.2p1 on HP-UX 10.20 with the HP ANSI C compiler.

The resulting code seems to work, but spot-checking suggested that 
some of the warnings are the result of mixing int and u_int types, 
which might introduce subtle bugs.

I figured it might be worth reporting, since I'm in the minority of 
people not using a gcc-derived compiler, and thus may see different 
errors.  I'm quoting a small section here, I'd be glad to send more 
details to anyone wanting to look into this further.

(This is HP-UX 10.20 with quite a few patches, but not absolutely the 
latest of everything.)

I'm not subscribed to this list, so CC me on replies.

This is the options I used to run configure:

- - cut here - -
#!/usr/bin/csh -vx
rm -f config.cache
setenv CC "cc"
setenv CFLAGS "-Ae +O2 -I/usr/local/include  -I/nuinfo/local/openssl/include"
setenv LFLAGS "-L/usr/local/lib -L/opt/local/openssl"
nohup sh ./configure  --prefix=/nuinfo/local/openssh \
        --sysconfdir=/etc/openssh \
        --with-ssl-dir=/nuinfo/local/openssl/lib        \
        --with-prngd-socket=/var/run/egd-pool   \
        --without-lastlog       \
        --with-cflags="-Ae -I/usr/local/include -I/nuinfo/local/openssl/include"
\
        --with-lflags="-L/usr/local/lib -L/nuinfo/local/openssl" \
        --with-tcp-wrappers \
        --with-ipv4-default \
        --with-default-path="/usr/bin:/usr/contrib/bin/opt/local/bin:"  \
   >& my.configure.out.$$ &

#
echo my.configure.out.$$
#
ps -f
#

- - cut here - -
A sample of errors:

(I think, based on a prior version, the first warning about "stat" can be fixed by commenting out "struct stat;" in openbsd-compat/glob.h I'm more worried by the other errors.)

- - cut here - -
        cc -Ae +O2 -I/usr/local/include  -I/nuinfo/local/openssl/include -Ae -Ae
 -I/usr/local/include -I/nuinfo/local/openssl/include -I. -I. -I/nuinfo/local/op
enssl/lib  -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -DETCDIR=\"
/etc/openssh\"  -D_PATH_SSH_PROGRAM=\"/nuinfo/local/openssh/bin/ssh\"  -D_PATH_S
SH_ASKPASS_DEFAULT=\"/nuinfo/local/openssh/libexec/ssh-askpass\"  -D_PATH_SFTP_S
ERVER=\"/nuinfo/local/openssh/libexec/sftp-server\"  -D_PATH_SSH_PIDDIR=\"/var/r
un\" -DHAVE_CONFIG_H -c packet.c
cc: "openbsd-compat/glob.h", line 48: warning 617: Redeclaration of tag "stat" i
gnored.
cc: "packet.c", line 316: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 316: warning 563: Argument #2 is not the correct type.
cc: "packet.c", line 416: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 416: warning 563: Argument #2 is not the correct type.
cc: "packet.c", line 416: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 416: warning 563: Argument #3 is not the correct type.
cc: "packet.c", line 578: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 578: warning 563: Argument #2 is not the correct type.
cc: "packet.c", line 578: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 578: warning 563: Argument #3 is not the correct type.
cc: "packet.c", line 732: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 732: warning 563: Argument #1 is not the correct type.
cc: "packet.c", line 738: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 738: warning 563: Argument #2 is not the correct type.
cc: "packet.c", line 738: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 738: warning 563: Argument #3 is not the correct type.
cc: "packet.c", line 807: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 807: warning 563: Argument #2 is not the correct type.
cc: "packet.c", line 807: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 807: warning 563: Argument #3 is not the correct type.
cc: "packet.c", line 836: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 836: warning 563: Argument #2 is not the correct type.
cc: "packet.c", line 836: warning 604: Pointers are not assignment-compatible.
cc: "packet.c", line 836: warning 563: Argument #3 is not the correct type.
- - cut here - -
-- 
    Albert Lunde         Albert-Lunde at northwestern.edu (new address)
                         Albert-Lunde at nwu.edu (old address)


From djm at mindrot.org  Thu Dec 20 15:28:06 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 20 Dec 2001 15:28:06 +1100 (EST)
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011219190546.K3026@zax.half.pint-stowp.cx>
Message-ID: <Pine.LNX.4.33.0112201527330.4103-100000@mothra.mindrot.org>

On Wed, 19 Dec 2001, Jim Knoble wrote:

> Circa 2001-Dec-19 15:29:08 +0100 dixit Christian Kurz:
> 
> : Hm, I just wonder why the cvs is hanging for me. I have the variable
> : echo $CVS_RSH correctly set and with an other project, that's working
> : fine. But when I try to run
> : 
> : |cvs -z3 -dopenssh at anoncvs.be.openbsd.org:/cvs get openssh
> 
> Don't you mean:
> 
>    cvs -z3 -d:ext:openssh at anoncvs.be.openbsd.org:/cvs get openssh
>              ^^^^^

Seems to work either way for me...

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From Dominique.Frise at ci.unil.ch  Thu Dec 20 21:24:13 2001
From: Dominique.Frise at ci.unil.ch (Dominique Frise)
Date: Thu, 20 Dec 2001 11:24:13 +0100
Subject: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
Message-ID: <3C21BC4D.CDA68808@ci.unil.ch>

Hi,

Trying to install the Solaris package I made after configure/compilation
under Solaris 8.

My configure settings
---------------------
OpenSSH has been configured with the following options:
                 User binaries: /usr/local/bin
               System binaries: /usr/local/sbin
           Configuration files: /usr/local/etc
               Askpass program: /usr/local/libexec/ssh-askpass
                  Manual pages: /usr/local/man/manX
                      PID file: /var/run
        sshd default user PATH:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
      Random number collection: Builtin (timeout 200)
                Manpage format: man
                   PAM support: yes
            KerberosIV support: no
             Smartcard support: no
                   AFS support: no
                 S/KEY support: no
          TCP Wrappers support: yes
          MD5 password support: no
   IP address in $DISPLAY hack: no
      Use IPv4 by default hack: no
       Translate v4 in v6 hack: no

              Host: sparc-sun-solaris2.8
          Compiler: cc
    Compiler flags: -g
Preprocessor flags: -I/usr/local/ssl/include  -I/usr/local/include
-DPAM_TTY_KLUDGE
      Linker flags: -R/usr/local/ssl/lib -L/usr/local/ssl/lib 
-L/usr/local/lib -R/usr/local/lib
         Libraries: -lpam -ldl -lwrap -lz -lsocket -lnsl  -lcrypto 

PAM is enabled. You may need to install a PAM control file for sshd,
otherwise password authentication may fail. Example PAM control files
can be found in the contrib/ subdirectory

WARNING: you are using the builtin random number collection service.
Please read WARNING.RNG and request that your OS vendor includes
/dev/random in future versions of their OS.
Here below the log of my Solaris package installation:


Log of the package installation
-------------------------------
# pkgadd -d OpenSSH-sparc-3.0.2p1.pkg

The following packages are available:
  1  OpenSSH     OpenSSH Portable for Solaris
                 (sparc) 3.0.2p1

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:  

Processing package instance <OpenSSH> from
</local/soft/pub/openssh-3.0.2p1/contrib/solaris/OpenSSH-sparc-3.0.2p1.pkg>

OpenSSH Portable for Solaris
(sparc) 3.0.2p1
OpenSSH Portable Team - http://www.openssh.com/portable.html
## Processing package information.
## Processing system information.
   13 package pathnames are already properly installed.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.

The following files are already installed on the system and are being
used by another package:
* /usr/local

* - conflict with a file which does not belong to any package.

Do you want to install these conflicting files [y,n,?,q] y
## Checking for setuid/setgid programs.

The following files are being installed with setuid and/or setgid
permissions:
  /usr/local/bin/ssh <setuid root>

Do you want to install these as setuid/setgid files [y,n,?,q] y

Installing OpenSSH Portable for Solaris as <OpenSSH>

## Installing part 1 of 1.
/etc/init.d/opensshd
/etc/rc0.d/K30opensshd <symbolic link>
/etc/rc1.d/K30opensshd <symbolic link>
/etc/rc2.d/S98opensshd <symbolic link>
/etc/rcS.d/K30opensshd <symbolic link>
/usr/local/bin/scp
/usr/local/bin/sftp
/usr/local/bin/slogin <symbolic link>
/usr/local/bin/ssh
/usr/local/bin/ssh-add
/usr/local/bin/ssh-agent
/usr/local/bin/ssh-keygen
/usr/local/bin/ssh-keyscan
/usr/local/etc/moduli
/usr/local/etc/ssh_config
/usr/local/etc/ssh_prng_cmds
/usr/local/etc/sshd_config
/usr/local/libexec/sftp-server
/usr/local/man/man1/scp.1
/usr/local/man/man1/sftp.1
/usr/local/man/man1/slogin.1 <symbolic link>
/usr/local/man/man1/ssh-add.1
/usr/local/man/man1/ssh-agent.1
/usr/local/man/man1/ssh-keygen.1
/usr/local/man/man1/ssh-keyscan.1
/usr/local/man/man1/ssh.1
/usr/local/man/man8/sftp-server.8
/usr/local/man/man8/sshd.8
/usr/local/sbin/sshd
/usr/local/share/Ssh.bin
[ verifying class <none> ]

Installation of <OpenSSH> was successful.

Now the problem I got
---------------------
Before pkg install. /usr/local was a soft link to /local (ln -s /local
/usr/local).
After installation the link is gone and a new /usr/local directory is
created containing only openssh stuff :-(

  
Thanks for help,

Dominique
____________________UNIL - University of Lausanne____________________ 
Dominique Frise                    E-mail: Dominique.Frise at ci.unil.ch
UNIL, Centre Informatique          Phone:            +41 21 692 22 21 
Rte de Chavannes 33                Fax:              +41 21 692 22 05
CH-1007 Lausanne, Switzerland      URL:         http://www.unil.ch/ci


From shorty at getuid.de  Thu Dec 20 20:30:30 2001
From: shorty at getuid.de (Christian Kurz)
Date: Thu, 20 Dec 2001 10:30:30 +0100
Subject: What's the problem with the CVS repository?
In-Reply-To: <20011219153545.GB26099@wiggy.net>
References: <Pine.HPX.4.43.0112181229030.1584-100000@jenny> <Pine.LNX.4.33.0112191641570.8117-100000@mothra.mindrot.org> <20011219124226.GC731@salem.getuid.de> <20011219144636.F16664@faui02> <20011219152908.B31074@bofh.de> <20011219153545.GB26099@wiggy.net>
Message-ID: <20011220093030.GA9411@salem.getuid.de>

On 19/12/01, Wichert Akkerman wrote:
> Previously Christian Kurz wrote:
> > I then verified via mtr that I can reach that host (9 hops) and that no
> > packet loss is occuring. So could anyone please tell me, what the
> > problem is?

> ECN?

Yes, that seems to be the problem. Thanks for the hint, now I just need
to write a small script to disable ecn before trying to update my local
copy of openssh cvs. Thanks.

Christian
-- 
If you live long enough, you'll see that every victory turns into a defeat.
                -- Simone de Beauvoir


From Nicolas.Williams at ubsw.com  Fri Dec 21 03:54:04 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 20 Dec 2001 11:54:04 -0500
Subject: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
In-Reply-To: <3C21BC4D.CDA68808@ci.unil.ch>; from Dominique Frise on Thu, Dec 20, 2001 at 11:24:13AM +0100
References: <3C21BC4D.CDA68808@ci.unil.ch>
Message-ID: <20011220115404.L12209@wdr.com>

On Thu, Dec 20, 2001 at 11:24:13AM +0100, Dominique Frise wrote:
> Hi,
> 
> Trying to install the Solaris package I made after configure/compilation
> under Solaris 8.

[...]

> Log of the package installation
> -------------------------------
> # pkgadd -d OpenSSH-sparc-3.0.2p1.pkg
> 
> The following packages are available:
>   1  OpenSSH     OpenSSH Portable for Solaris
>                  (sparc) 3.0.2p1
> 
> Select package(s) you wish to process (or 'all' to process
> all packages). (default: all) [?,??,q]:  
> 
> Processing package instance <OpenSSH> from
> </local/soft/pub/openssh-3.0.2p1/contrib/solaris/OpenSSH-sparc-3.0.2p1.pkg>

[...]

> The following files are already installed on the system and are being
> used by another package:
> * /usr/local
> 
> * - conflict with a file which does not belong to any package.
> 
> Do you want to install these conflicting files [y,n,?,q] y

Here's the problem. Whether a package should include an entry for
BASEDIR, I'm not sure(*), but certainly you didn't have to install
"conflicting" files, particularly when the only conflict was
/usr/local/ and it already existed.

[...]

> Installation of <OpenSSH> was successful.
> 
> Now the problem I got
> ---------------------
> Before pkg install. /usr/local was a soft link to /local (ln -s /local
> /usr/local).
> After installation the link is gone and a new /usr/local directory is
> created containing only openssh stuff :-(

See above.

> Thanks for help,
> 
> Dominique
> ____________________UNIL - University of Lausanne____________________ 
> Dominique Frise                    E-mail: Dominique.Frise at ci.unil.ch
> UNIL, Centre Informatique          Phone:            +41 21 692 22 21 
> Rte de Chavannes 33                Fax:              +41 21 692 22 05
> CH-1007 Lausanne, Switzerland      URL:         http://www.unil.ch/ci


(*) Actually, packages should not include pkgmap entries for BASEDIR and
other relocatable directories - those should either be created by the
preinstall script if they did not exist or should be in pkgmap but
conditional on particular classes enabled by a checkinstall script.

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 GILBERT.R.LOOMIS at saic.com  Fri Dec 21 04:05:44 2001
From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip)
Date: Thu, 20 Dec 2001 12:05:44 -0500
Subject: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
Message-ID: <3C1E3607B37295439F7C409EFBA08E680E283A@COL-581-EXS01>

Since I neglected to CC the list, here's what I
sent to Dominique--

-----Original Message-----
From: Loomis, Rip 
Sent: Thursday, 20 December, 2001 10:09
To: 'Dominique Frise'
Subject: RE: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file


Dominique--
Unfortunately, this is one of those:
  "Hey Doc, it hurts when I do this..."
  "Well, don't do that anymore..."
situations.

You have a non-standard installation method.  The Solaris
pkgadd doesn't do a perfect job of handling such things,
and the only way that the OpenSSH package could handle all
such possible cases would be to have an ugly preinstall
script that checked for things.  Ben's new-and-improved
packaging routines are cleaner than my old-and-ugly
ones in the older OpenSSH portable versions, and work
better for most cases--and I don't think it's likely that
scripts to work around situations like this will be added.

The correct answer, for future reference, is to answer
"No" to the question about installing "conflicting files".
pkgadd will then ask you if you want to continue--say
yes, and the package should install properly.  If it
*doesn't* at that point, then let the list know.

Hope this helps--

--
Rip Loomis
Senior Systems Security Engineer
SAIC Center for Information Security Technology 

> -----Original Message-----
> From: Dominique Frise [mailto:Dominique.Frise at ci.unil.ch]
> Sent: Thursday, 20 December, 2001 05:24
[[SNIP]]
> The following files are already installed on the system and are being
> used by another package:
> * /usr/local
> 
> * - conflict with a file which does not belong to any package.
> 
> Do you want to install these conflicting files [y,n,?,q] y
[[SNIP]]
> Now the problem I got
> ---------------------
> Before pkg install. /usr/local was a soft link to /local (ln -s /local
> /usr/local).
> After installation the link is gone and a new /usr/local directory is
> created containing only openssh stuff :-(
[[SNIP]] 


From mouring at etoh.eviladmin.org  Fri Dec 21 04:20:25 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 20 Dec 2001 11:20:25 -0600 (CST)
Subject: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E283A@COL-581-EXS01>
Message-ID: <Pine.BSO.4.33.0112201115130.32182-100000@etoh.eviladmin.org>


> From: Loomis, Rip
[..]
> You have a non-standard installation method.  The Solaris
> pkgadd doesn't do a perfect job of handling such things,
> and the only way that the OpenSSH package could handle all
> such possible cases would be to have an ugly preinstall
> script that checked for things.  Ben's new-and-improved
> packaging routines are cleaner than my old-and-ugly
> ones in the older OpenSSH portable versions, and work
> better for most cases--and I don't think it's likely that
> scripts to work around situations like this will be added.
>

I'm not against such scripts in a preinstall.  We need to include
a preinstall sooner or later to handle things a bit cleaner.  I'd
like to see a fully relocable binary with the fact Solaris 9 now
supports /dev/random.  Just neither of these things are high on
my priority, nor on my "Ugh I can't stand this any more.." list.

Which is the main reason why I wrote my version.  I could not
stand being forced to maintain the script and ensure it worked for
/usr/local and /opt (since I use the latter).

PLEASE, any Solaris experts.  Feel free to submit updates to the solaris
package script.  I'll only bitch and yell if you attempt to destory the
fake root feature of it (which is the main reason for me doing it, since
no one was updating it =).

- Ben



From tim at mcgarry.ch  Fri Dec 21 05:19:20 2001
From: tim at mcgarry.ch (Tim McGarry)
Date: Thu, 20 Dec 2001 19:19:20 +0100
Subject: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
References: <3C21BC4D.CDA68808@ci.unil.ch> <20011220115404.L12209@wdr.com>
Message-ID: <003101c18982$dabc1e80$c902a8c0@cablecom.ch>

These types of errors can usually be fixed by replacing the fields in the
package map that set the owner group permissions to be
? ? ?, that way the Solaris packaging system sees no conflict.


Tim
----- Original Message -----
From: "Nicolas Williams" <Nicolas.Williams at ubsw.com>
To: "Dominique Frise" <Dominique.Frise at ci.unil.ch>;
<openssh-unix-dev at mindrot.org>
Sent: Thursday, December 20, 2001 5:54 PM
Subject: Re: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file


> On Thu, Dec 20, 2001 at 11:24:13AM +0100, Dominique Frise wrote:
> > Hi,
> >
> > Trying to install the Solaris package I made after configure/compilation
> > under Solaris 8.
>
> [...]
>
> > Log of the package installation
> > -------------------------------
> > # pkgadd -d OpenSSH-sparc-3.0.2p1.pkg
> >
> > The following packages are available:
> >   1  OpenSSH     OpenSSH Portable for Solaris
> >                  (sparc) 3.0.2p1
> >
> > Select package(s) you wish to process (or 'all' to process
> > all packages). (default: all) [?,??,q]:
> >
> > Processing package instance <OpenSSH> from
> >
</local/soft/pub/openssh-3.0.2p1/contrib/solaris/OpenSSH-sparc-3.0.2p1.pkg>
>
> [...]
>
> > The following files are already installed on the system and are being
> > used by another package:
> > * /usr/local
> >
> > * - conflict with a file which does not belong to any package.
> >
> > Do you want to install these conflicting files [y,n,?,q] y
>
> Here's the problem. Whether a package should include an entry for
> BASEDIR, I'm not sure(*), but certainly you didn't have to install
> "conflicting" files, particularly when the only conflict was
> /usr/local/ and it already existed.
>
> [...]
>
> > Installation of <OpenSSH> was successful.
> >
> > Now the problem I got
> > ---------------------
> > Before pkg install. /usr/local was a soft link to /local (ln -s /local
> > /usr/local).
> > After installation the link is gone and a new /usr/local directory is
> > created containing only openssh stuff :-(
>
> See above.
>
> > Thanks for help,
> >
> > Dominique
> > ____________________UNIL - University of Lausanne____________________
> > Dominique Frise                    E-mail: Dominique.Frise at ci.unil.ch
> > UNIL, Centre Informatique          Phone:            +41 21 692 22 21
> > Rte de Chavannes 33                Fax:              +41 21 692 22 05
> > CH-1007 Lausanne, Switzerland      URL:         http://www.unil.ch/ci
>
>
> (*) Actually, packages should not include pkgmap entries for BASEDIR and
> other relocatable directories - those should either be created by the
> preinstall script if they did not exist or should be in pkgmap but
> conditional on particular classes enabled by a checkinstall script.
>
> 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 djm at mindrot.org  Fri Dec 21 12:10:18 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 21 Dec 2001 12:10:18 +1100 (EST)
Subject: Killing the builtin entropy code
Message-ID: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>

Over the holidays, I intend to finally rid portable OpenSSH of the
builtin entropy collection code. Here's what I intend to do:

When init_rng is called, we'll check OpenSSL's RAND_status(). If this
indicates that their PRNG is already seeded, we'll do nothing. This
effectively detects platforms which have /dev/urandom (or similar)
configured into OpenSSL.

If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess
"ssh-rand-helper" which will return 64 bytes of randomness to stdout.
This will be used to seed OpenSSL's PRNG. 512 bits should be enough
for anyone :)

ssh-rand-helper may be a program which fetches randomness from PRNGd,
it could be a Yarrow implementation or it could be an adaptation of the
current entropy code to run in a one-shot mode. I'll certainly implement 
a PRNGd ssh-rand-helper, if time permits I'll do one of the others.

This takes all the responsability out of OpenSSH for collecting random
numbers and allows sites to implement whatever fallbacks they require
using wrappers around ssh-rand-helper (which could be shell scripts).

Comments?

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From mouring at etoh.eviladmin.org  Fri Dec 21 13:31:34 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 20 Dec 2001 20:31:34 -0600 (CST)
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>
Message-ID: <Pine.BSO.4.33.0112202018460.28618-100000@etoh.eviladmin.org>


Just so long as we can pull together decent documentation for
all the options they have after the code removal.  I know I'll
be looking at doing PRNGd/OpenSSL mix soon then on my aging Solaris and
NeXT boxes.

BTW Damien, I assume this is your Christmas present to yourself.  So
enjoy.  I won't stir. =)

- Ben

On Fri, 21 Dec 2001, Damien Miller wrote:

> Over the holidays, I intend to finally rid portable OpenSSH of the
> builtin entropy collection code. Here's what I intend to do:
>
> When init_rng is called, we'll check OpenSSL's RAND_status(). If this
> indicates that their PRNG is already seeded, we'll do nothing. This
> effectively detects platforms which have /dev/urandom (or similar)
> configured into OpenSSL.
>
> If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess
> "ssh-rand-helper" which will return 64 bytes of randomness to stdout.
> This will be used to seed OpenSSL's PRNG. 512 bits should be enough
> for anyone :)
>
> ssh-rand-helper may be a program which fetches randomness from PRNGd,
> it could be a Yarrow implementation or it could be an adaptation of the
> current entropy code to run in a one-shot mode. I'll certainly implement
> a PRNGd ssh-rand-helper, if time permits I'll do one of the others.
>
> This takes all the responsability out of OpenSSH for collecting random
> numbers and allows sites to implement whatever fallbacks they require
> using wrappers around ssh-rand-helper (which could be shell scripts).
>
> Comments?
>
> -d
>
> --
> | By convention there is color,       \\ Damien Miller <djm at mindrot.org>
> | By convention sweetness, By convention bitterness, \\ www.mindrot.org
> | But in reality there are atoms and space - Democritus (c. 400 BCE)
>
>



From jmknoble at pobox.com  Fri Dec 21 15:01:15 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 20 Dec 2001 23:01:15 -0500
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Dec 21, 2001 at 12:10:18PM +1100
References: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>
Message-ID: <20011220230115.P3026@zax.half.pint-stowp.cx>

Circa 2001-Dec-21 12:10:18 +1100 dixit Damien Miller:

: Over the holidays, I intend to finally rid portable OpenSSH of the
: builtin entropy collection code. Here's what I intend to do:

  [...]

: If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess
: "ssh-rand-helper" which will return 64 bytes of randomness to stdout.
: This will be used to seed OpenSSL's PRNG. 512 bits should be enough
: for anyone :)

Obviously, we'd only suid(user) for sshd, not for e.g. ssh, ssh-agent,
or ssh-keygen.

: ssh-rand-helper may be a program which fetches randomness from PRNGd,
: it could be a Yarrow implementation or it could be an adaptation of the
: current entropy code to run in a one-shot mode. I'll certainly implement 
: a PRNGd ssh-rand-helper, if time permits I'll do one of the others.
: 
: This takes all the responsability out of OpenSSH for collecting random
: numbers and allows sites to implement whatever fallbacks they require
: using wrappers around ssh-rand-helper (which could be shell scripts).
: 
: Comments?

I wonder if we might not want to go so far as to specify an interface
for this sort of thing (sort of like djb's checkpassword interface
<http://cr.yp.to/checkpwd.html>).  For example:

  ssh-rand-helper prints 64 octets of crytpo-quality randomness to
  stdout, closes stdout, and exits 0.  If ssh-rand-helper could not
  obtain 64 octets of entropy, it closes stdout and exits 1.

Then we could ask e.g. Yarrow to ship an ssh-rand-helper program that
fits the interface, and it would no longer be our responsibility to
maintain the helper for Yarrow.  Sort of like we do with (ahem)
ssh-askpass....

-- 
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/20011220/f40c9b6e/attachment.bin 

From mouring at etoh.eviladmin.org  Fri Dec 21 15:06:43 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 20 Dec 2001 22:06:43 -0600 (CST)
Subject: Killing the builtin entropy code
In-Reply-To: <20011220230115.P3026@zax.half.pint-stowp.cx>
Message-ID: <Pine.BSO.4.33.0112202205210.5371-100000@etoh.eviladmin.org>



On Thu, 20 Dec 2001, Jim Knoble wrote:

> Circa 2001-Dec-21 12:10:18 +1100 dixit Damien Miller:
[..]
>   [...]
>
> : If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess
> : "ssh-rand-helper" which will return 64 bytes of randomness to stdout.
> : This will be used to seed OpenSSL's PRNG. 512 bits should be enough
> : for anyone :)
>
> Obviously, we'd only suid(user) for sshd, not for e.g. ssh, ssh-agent,
> or ssh-keygen.
>

Do we?  ssh can be setuid.  And IIRC the current place we seed the random
number still has root privs.  So ssh and sshd could need to drop
prives accordingly.

- Ben



From josb at cncdsl.com  Fri Dec 21 15:43:08 2001
From: josb at cncdsl.com (Jos Backus)
Date: Thu, 20 Dec 2001 20:43:08 -0800
Subject: Killing the builtin entropy code
In-Reply-To: <20011220230115.P3026@zax.half.pint-stowp.cx>
References: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org> <20011220230115.P3026@zax.half.pint-stowp.cx>
Message-ID: <20011221044330.GA447@lizzy.bugworks.com>

On Thu, Dec 20, 2001 at 11:01:15PM -0500, Jim Knoble wrote:
> Circa 2001-Dec-21 12:10:18 +1100 dixit Damien Miller:
> 
> : Over the holidays, I intend to finally rid portable OpenSSH of the
> : builtin entropy collection code. Here's what I intend to do:

> I wonder if we might not want to go so far as to specify an interface
> for this sort of thing (sort of like djb's checkpassword interface
> <http://cr.yp.to/checkpwd.html>).  For example:

Both of these are excellent ideas imo.

-- 
Jos Backus                 _/  _/_/_/        Santa Clara, CA
                          _/  _/   _/
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb at cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;


From jmknoble at pobox.com  Fri Dec 21 17:33:02 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Fri, 21 Dec 2001 01:33:02 -0500
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.BSO.4.33.0112202205210.5371-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Thu, Dec 20, 2001 at 10:06:43PM -0600
References: <20011220230115.P3026@zax.half.pint-stowp.cx> <Pine.BSO.4.33.0112202205210.5371-100000@etoh.eviladmin.org>
Message-ID: <20011221013301.Q3026@zax.half.pint-stowp.cx>

Circa 2001-Dec-20 22:06:43 -0600 dixit mouring at etoh.eviladmin.org:

: On Thu, 20 Dec 2001, Jim Knoble wrote:
: > Obviously, we'd only suid(user) for sshd, not for e.g. ssh, ssh-agent,
: > or ssh-keygen.
: 
: Do we?  ssh can be setuid.  And IIRC the current place we seed the random
: number still has root privs.  So ssh and sshd could need to drop
: prives accordingly.

Gack.  Of course, you're right (i've never had a use for Rhost-anything
authentication, so i haven't installed ssh setuid-root in several years).

In reflecting on that, i suppose 'setuid(getuid());' won't hurt
anything even if ssh isn't setuid-root.  In which case i suppose it
can't really hurt to do it everywhere....

*Slinks back under rock*

-- 
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/20011221/d5c76e3e/attachment.bin 

From Alexander.Dost at drkw.com  Fri Dec 21 19:38:06 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Fri, 21 Dec 2001 09:38:06 +0100
Subject: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
Message-ID: <F14059C75C32934AA7F5B3831BAC09511CFA7C@ibfftce502.is.de.dresdnerkb.com>

That won't really help you. The second field in the pkgmap file points to
the type of the file to install. If it tells pkgadd that /usr/local is a
directory it will install a directory and kill your link. You would have to
change it to a symbolic link if this should work. There is no way to tell
pkgadd not to overwrite a link with a directory... The best way (as someone
stated before) is not to install conflicting files and continue without
creating /usr/local anyway.

Alex

> -----Original Message-----
> From:	Tim McGarry [SMTP:tim at mcgarry.ch]
> Sent:	Thursday, December 20, 2001 19:19
> To:	Nicolas Williams; Dominique Frise; openssh-unix-dev at mindrot.org
> Subject:	Re: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
> 
> These types of errors can usually be fixed by replacing the fields in the
> package map that set the owner group permissions to be
> ? ? ?, that way the Solaris packaging system sees no conflict.
> 
> 
> Tim
> ----- Original Message -----
> From: "Nicolas Williams" <Nicolas.Williams at ubsw.com>
> To: "Dominique Frise" <Dominique.Frise at ci.unil.ch>;
> <openssh-unix-dev at mindrot.org>
> Sent: Thursday, December 20, 2001 5:54 PM
> Subject: Re: OpenSSH-sparc-3.0.2p1.pkg: /usr/local conflicting file
> 
> 
> > On Thu, Dec 20, 2001 at 11:24:13AM +0100, Dominique Frise wrote:
> > > Hi,
> > >
> > > Trying to install the Solaris package I made after
> configure/compilation
> > > under Solaris 8.
> >
> > [...]
> >
> > > Log of the package installation
> > > -------------------------------
> > > # pkgadd -d OpenSSH-sparc-3.0.2p1.pkg
> > >
> > > The following packages are available:
> > >   1  OpenSSH     OpenSSH Portable for Solaris
> > >                  (sparc) 3.0.2p1
> > >
> > > Select package(s) you wish to process (or 'all' to process
> > > all packages). (default: all) [?,??,q]:
> > >
> > > Processing package instance <OpenSSH> from
> > >
> </local/soft/pub/openssh-3.0.2p1/contrib/solaris/OpenSSH-sparc-3.0.2p1.pkg
> >
> >
> > [...]
> >
> > > The following files are already installed on the system and are being
> > > used by another package:
> > > * /usr/local
> > >
> > > * - conflict with a file which does not belong to any package.
> > >
> > > Do you want to install these conflicting files [y,n,?,q] y
> >
> > Here's the problem. Whether a package should include an entry for
> > BASEDIR, I'm not sure(*), but certainly you didn't have to install
> > "conflicting" files, particularly when the only conflict was
> > /usr/local/ and it already existed.
> >
> > [...]
> >
> > > Installation of <OpenSSH> was successful.
> > >
> > > Now the problem I got
> > > ---------------------
> > > Before pkg install. /usr/local was a soft link to /local (ln -s /local
> > > /usr/local).
> > > After installation the link is gone and a new /usr/local directory is
> > > created containing only openssh stuff :-(
> >
> > See above.
> >
> > > Thanks for help,
> > >
> > > Dominique
> > > ____________________UNIL - University of Lausanne____________________
> > > Dominique Frise                    E-mail: Dominique.Frise at ci.unil.ch
> > > UNIL, Centre Informatique          Phone:            +41 21 692 22 21
> > > Rte de Chavannes 33                Fax:              +41 21 692 22 05
> > > CH-1007 Lausanne, Switzerland      URL:         http://www.unil.ch/ci
> >
> >
> > (*) Actually, packages should not include pkgmap entries for BASEDIR and
> > other relocatable directories - those should either be created by the
> > preinstall script if they did not exist or should be in pkgmap but
> > conditional on particular classes enabled by a checkinstall script.
> >
> > 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 dan at doxpara.com  Fri Dec 21 21:53:40 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 21 Dec 2001 02:53:40 -0800
Subject: Killing the builtin entropy code
References: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>
Message-ID: <02b701c18a0d$c07ab640$1701000a@effugas>

Damien--

    The end question is, "Will ssh continue to work with no external
dependencies or not?"

    If an upgrade comes out that suddenly breaks OpenSSH on all sorts of
platforms, well, people won't upgrade.  Hell, they're lazy enough to still
use some ancient kernel devoid of kernelspace entropy generation; I think
they can scrounge together the laziness to never, ever upgrade their build
of OpenSSH again :-)

    I very much do like the idea of being able to plug in external entropy
generators.  I think this is critical and important and many different kinds
of good.  However, it's pretty critical that, failing the existence of one
of these external generator applications, ssh be able to take care of
itself -- possibly through a default last-ditch entropy source of "ssh -o
OutputEntropy yes".

    We've had security issues before, and we may very well again.  If we
make it difficult to upgrade a build of OpenSSH, knowing that will prevent
the software from being upgraded in the field, we're dooming a portion of
our audience to insecurity.

    I have trouble accepting that.

--Dan




From djm at mindrot.org  Fri Dec 21 22:14:57 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 21 Dec 2001 22:14:57 +1100 (EST)
Subject: Killing the builtin entropy code
In-Reply-To: <02b701c18a0d$c07ab640$1701000a@effugas>
Message-ID: <Pine.LNX.4.33.0112212212530.16802-100000@mothra.mindrot.org>

On Fri, 21 Dec 2001, Dan Kaminsky wrote:

> Damien--
> 
>     The end question is, "Will ssh continue to work with no external
> dependencies or not?"

That depends on two things:

1. Whether I write or adapt a ssh-rand-helper which pulls entropy
directly from the system (like we do now).

or failing that:

2. Whether someone else does.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From austin at coremetrics.com  Sat Dec 22 04:20:06 2001
From: austin at coremetrics.com (Austin Gonyou)
Date: 21 Dec 2001 11:20:06 -0600
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>
References: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>
Message-ID: <1008955206.17239.13.camel@UberGeek>

I like the idea of doing this, and also doing something like mod_ssl for
apache does? 

There is a subsection in httpd.conf that says what to use for entropy,
and there can be many different types specified. Perhaps the final
output could be a more configureable openssh with virtual hosts and the
whole bit? This would allow different types of ciphers, and such to be
used, but on a per virt host basis? 

Is that something that could be potentially bad? Just curious. 

On Thu, 2001-12-20 at 19:10, Damien Miller wrote:
> Over the holidays, I intend to finally rid portable OpenSSH of the
> builtin entropy collection code. Here's what I intend to do:
> 
> When init_rng is called, we'll check OpenSSL's RAND_status(). If this
> indicates that their PRNG is already seeded, we'll do nothing. This
> effectively detects platforms which have /dev/urandom (or similar)
> configured into OpenSSL.
> 
> If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess
> "ssh-rand-helper" which will return 64 bytes of randomness to stdout.
> This will be used to seed OpenSSL's PRNG. 512 bits should be enough
> for anyone :)
> 
> ssh-rand-helper may be a program which fetches randomness from PRNGd,
> it could be a Yarrow implementation or it could be an adaptation of the
> current entropy code to run in a one-shot mode. I'll certainly implement
> 
> a PRNGd ssh-rand-helper, if time permits I'll do one of the others.
> 
> This takes all the responsability out of OpenSSH for collecting random
> numbers and allows sites to implement whatever fallbacks they require
> using wrappers around ssh-rand-helper (which could be shell scripts).
> 
> Comments?
> 
> -d
> 
> -- 
> | By convention there is color,       \\ Damien Miller <djm at mindrot.org>
> | By convention sweetness, By convention bitterness, \\ www.mindrot.org
> | But in reality there are atoms and space - Democritus (c. 400 BCE)
-- 
Austin Gonyou
Systems Architect, CCNA 
Coremetrics, Inc.
Phone: 512-698-7250
email: austin at coremetrics.com
 
"Have regard for your name, since it will remain for you longer than a
great store of gold."
Ecclesiastes, Aprocrypha
-------------- 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/20011221/5e1df4c3/attachment.bin 

From mouring at etoh.eviladmin.org  Sat Dec 22 04:48:47 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 21 Dec 2001 11:48:47 -0600 (CST)
Subject: Killing the builtin entropy code
In-Reply-To: <1008955206.17239.13.camel@UberGeek>
Message-ID: <Pine.BSO.4.33.0112211148060.12394-100000@etoh.eviladmin.org>


Umm... Unless you are doing Vhost by IP.. OpenSSH has no clue if
you selected mysite.whatever.com vs yoursite.whatever.com if they
have the same IP.  Therefor it is silly to add such features.

- Ben

On 21 Dec 2001, Austin Gonyou wrote:

> I like the idea of doing this, and also doing something like mod_ssl for
> apache does?
>
> There is a subsection in httpd.conf that says what to use for entropy,
> and there can be many different types specified. Perhaps the final
> output could be a more configureable openssh with virtual hosts and the
> whole bit? This would allow different types of ciphers, and such to be
> used, but on a per virt host basis?
>
> Is that something that could be potentially bad? Just curious.
>
> On Thu, 2001-12-20 at 19:10, Damien Miller wrote:
> > Over the holidays, I intend to finally rid portable OpenSSH of the
> > builtin entropy collection code. Here's what I intend to do:
> >
> > When init_rng is called, we'll check OpenSSL's RAND_status(). If this
> > indicates that their PRNG is already seeded, we'll do nothing. This
> > effectively detects platforms which have /dev/urandom (or similar)
> > configured into OpenSSL.
> >
> > If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess
> > "ssh-rand-helper" which will return 64 bytes of randomness to stdout.
> > This will be used to seed OpenSSL's PRNG. 512 bits should be enough
> > for anyone :)
> >
> > ssh-rand-helper may be a program which fetches randomness from PRNGd,
> > it could be a Yarrow implementation or it could be an adaptation of the
> > current entropy code to run in a one-shot mode. I'll certainly implement
> >
> > a PRNGd ssh-rand-helper, if time permits I'll do one of the others.
> >
> > This takes all the responsability out of OpenSSH for collecting random
> > numbers and allows sites to implement whatever fallbacks they require
> > using wrappers around ssh-rand-helper (which could be shell scripts).
> >
> > Comments?
> >
> > -d
> >
> > --
> > | By convention there is color,       \\ Damien Miller <djm at mindrot.org>
> > | By convention sweetness, By convention bitterness, \\ www.mindrot.org
> > | But in reality there are atoms and space - Democritus (c. 400 BCE)
> --
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-698-7250
> email: austin at coremetrics.com
>
> "Have regard for your name, since it will remain for you longer than a
> great store of gold."
> Ecclesiastes, Aprocrypha
>



From jason at shalott.net  Sat Dec 22 05:39:20 2001
From: jason at shalott.net (Jason Stone)
Date: Fri, 21 Dec 2001 10:39:20 -0800 (PST)
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.BSO.4.33.0112211148060.12394-100000@etoh.eviladmin.org>
Message-ID: <20011221103544.A86806-100000@walter>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Umm... Unless you are doing Vhost by IP.. OpenSSH has no clue if you
> selected mysite.whatever.com vs yoursite.whatever.com if they have the
> same IP.  Therefor it is silly to add such features.

You can certainly do it by IP, but I agree that there's absolutely no need
for this in OpenSSH.  If you really need to use different options for
different ip's, just run multiple copies of the daemon and pass them
different config files on the command line....


 -Jason

 -----------------------------------------------------------------------
 I worry about my child and the Internet all the time, even though she's
 too young to have logged on yet.  Here's what I worry about.  I worry
 that 10 or 15 years from now, she will come to me and say "Daddy, where
 were you when they took freedom of the press away from the Internet?"
	-- Mike Godwin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE8I4HeswXMWWtptckRAmHAAKCC+ImOLnW6JA/qFaWSF0w6+UcGmgCePqag
5bzgbTrzt464UHgupg6cpTc=
=03uZ
-----END PGP SIGNATURE-----



From download at ahpcc.unm.edu  Sat Dec 22 07:26:52 2001
From: download at ahpcc.unm.edu (download (Jim Prewett))
Date: Fri, 21 Dec 2001 13:26:52 -0700 (MST)
Subject: help -- generating a patch
Message-ID: <Pine.LNX.4.21.0112211321290.21943-100000@trucha02.ahpcc.unm.edu>

All, 

I'm attempting to generate a patch for 3.0.2p1.  This patch will modify
the configure script (and another file); I would like to do it via the
configure.ac file.

However, when I run 'autoconf ./configure.ac > ./configure.new', I get an
unuseable ./configure.new script; both with and without my patch
applied (including from a freshly unpacked tarball).  Here is the error:

[dl at spacebrain openssh-3.0.2p1]$ ./configure.new 
loading cache ./config.cache
./configure.new: line 606: syntax error near unexpected token
`AC_CONFIG_SRCDIR(ssh.c)'
./configure.new: line 606: `AC_CONFIG_SRCDIR(ssh.c)'

Now, I'm guessing that I screwed something up (i'm not terribly familular
with autoconf and friends).  Any help you could give me would be
appriciated....

Also, while I'm at it, is the proper way to submit a patch to OpenSSH to
create a 'diff -u' of the two trees?

Thanks,
--dl

--------------------------------------------------------------------------------
                    That machine has got to be destroyed!
--------------------------------------------------------------------------------



From mouring at etoh.eviladmin.org  Sat Dec 22 07:55:27 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 21 Dec 2001 14:55:27 -0600 (CST)
Subject: help -- generating a patch
In-Reply-To: <Pine.LNX.4.21.0112211321290.21943-100000@trucha02.ahpcc.unm.edu>
Message-ID: <Pine.BSO.4.33.0112211455110.12394-100000@etoh.eviladmin.org>


Make sure you have 2.5x or above autoconf package.

- Ben

On Fri, 21 Dec 2001, download (Jim Prewett) wrote:

> All,
>
> I'm attempting to generate a patch for 3.0.2p1.  This patch will modify
> the configure script (and another file); I would like to do it via the
> configure.ac file.
>
> However, when I run 'autoconf ./configure.ac > ./configure.new', I get an
> unuseable ./configure.new script; both with and without my patch
> applied (including from a freshly unpacked tarball).  Here is the error:
>
> [dl at spacebrain openssh-3.0.2p1]$ ./configure.new
> loading cache ./config.cache
> ./configure.new: line 606: syntax error near unexpected token
> `AC_CONFIG_SRCDIR(ssh.c)'
> ./configure.new: line 606: `AC_CONFIG_SRCDIR(ssh.c)'
>
> Now, I'm guessing that I screwed something up (i'm not terribly familular
> with autoconf and friends).  Any help you could give me would be
> appriciated....
>
> Also, while I'm at it, is the proper way to submit a patch to OpenSSH to
> create a 'diff -u' of the two trees?
>
> Thanks,
> --dl
>
> --------------------------------------------------------------------------------
>                     That machine has got to be destroyed!
> --------------------------------------------------------------------------------
>
>



From djm at mindrot.org  Sat Dec 22 10:00:54 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 22 Dec 2001 10:00:54 +1100 (EST)
Subject: help -- generating a patch
In-Reply-To: <Pine.LNX.4.21.0112211321290.21943-100000@trucha02.ahpcc.unm.edu>
Message-ID: <Pine.LNX.4.33.0112220959410.2176-100000@mothra.mindrot.org>

On Fri, 21 Dec 2001, download (Jim Prewett) wrote:

> All, 
> 
> I'm attempting to generate a patch for 3.0.2p1.  This patch will modify
> the configure script (and another file); I would like to do it via the
> configure.ac file.
> 
> However, when I run 'autoconf ./configure.ac > ./configure.new', I get an
> unuseable ./configure.new script; both with and without my patch
> applied (including from a freshly unpacked tarball).  Here is the error:

I recreate configure by running "autoheader ; autoconf" in the source directory (with no additional arguments).

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From info at ninosdepapel.org  Sat Dec 22 14:02:19 2001
From: info at ninosdepapel.org (Niños de Papel)
Date: Fri, 21 Dec 2001 22:02:19 -0500
Subject: Feliz Navidad y Próspero 2002
Message-ID: <200112212211437.SM01538@sonic>

***** This is an HTML Message ! *****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011221/77fcd8f9/attachment.html 

From seberino at spawar.navy.mil  Sun Dec 23 17:23:35 2001
From: seberino at spawar.navy.mil (Chris Seberino)
Date: Sat, 22 Dec 2001 22:23:35 -0800
Subject: ssh
Message-ID: <20011222222335.A12258@spawar.navy.mil>

Hello! I would really appreciate any hints
to a little puzzle that has been gnawing at me
about remote sessions with ssh... 
(and likely all connectivity programs...)

Because network connections can only talk in
ASCII, there is no way to tell the difference
between TAB and "Ctrl-i" (i.e. pressing Ctrl and i keys
together).  BOTH are transmitted as same ASCII
code.  Likewise, Ctrl-m and RETURN key both
are transmitted as the same ASCII character
by ssh and every other network connection 
probably.

Is there ANY way to tweak ssh program or something
else so that something DIFFERENT is sent
to distinguish between Ctrl-i and TAB and 
to distinguish between Ctrl-m and RETURN?????

It would REALLY make my day.

Sincerely,

Chris

-- 
=======================================================
| Dr. Christian Seberino  || (619) 553-7940  (office) |
| SPAWARSYSCEN 2363       || (619) 553-2836  (fax)    |
| 53560 HULL ST           ||                          |
| SAN DIEGO CA 92152-5001 || seberino at spawar.navy.mil |
=======================================================


From dan at doxpara.com  Sun Dec 23 18:43:02 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Sat, 22 Dec 2001 23:43:02 -0800
Subject: ssh
References: <20011222222335.A12258@spawar.navy.mil>
Message-ID: <036a01c18b85$73aa33d0$1701000a@effugas>

Chris--

    
----- Original Message ----- 
From: "Chris Seberino" <seberino at spawar.navy.mil>
To: <openssh-unix-dev at mindrot.org>
Sent: Saturday, December 22, 2001 10:23 PM
Subject: ssh


> Hello! I would really appreciate any hints
> to a little puzzle that has been gnawing at me
> about remote sessions with ssh... 
> (and likely all connectivity programs...)
> 
> Because network connections can only talk in
> ASCII, there is no way to tell the difference
> between TAB and "Ctrl-i" (i.e. pressing Ctrl and i keys
> together).  BOTH are transmitted as same ASCII
> code.  Likewise, Ctrl-m and RETURN key both
> are transmitted as the same ASCII character
> by ssh and every other network connection 
> probably.
> 
> Is there ANY way to tweak ssh program or something
> else so that something DIFFERENT is sent
> to distinguish between Ctrl-i and TAB and 
> to distinguish between Ctrl-m and RETURN?????
> 
> It would REALLY make my day.
> 
> Sincerely,
> 
> Chris
> 
> -- 
> =======================================================
> | Dr. Christian Seberino  || (619) 553-7940  (office) |
> | SPAWARSYSCEN 2363       || (619) 553-2836  (fax)    |
> | 53560 HULL ST           ||                          |
> | SAN DIEGO CA 92152-5001 || seberino at spawar.navy.mil |
> =======================================================
> 



From dan at doxpara.com  Sun Dec 23 18:49:04 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Sat, 22 Dec 2001 23:49:04 -0800
Subject: ssh
References: <20011222222335.A12258@spawar.navy.mil>
Message-ID: <036e01c18b86$4b45f900$1701000a@effugas>

Chris:

    Funny you mention this; I was looking into the possibilities of more
detailed keyboard input some time ago.  What can I say; I *really* want to
play with the Half-Keyboard Patch(
http://www.ugcs.caltech.edu/~john/computer/hk/) without having to sit at
console.

    At some level, it's absolutely possible for at least PC hardware to
detect keypresses independent of their ASCII codes -- think of all the PC
games that use this capability to know that up, Z, and X are all pressed at
once.  What I don't know is whether or not there's a TTY mode that handles
this.

    What's your use for this, out of curiosity?

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com

P.S. Yes, that blank email was sent because of me experimenting with control
combinations.  Oops.



From djm at mindrot.org  Mon Dec 24 01:42:04 2001
From: djm at mindrot.org (Damien Miller)
Date: Mon, 24 Dec 2001 01:42:04 +1100 (EST)
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.LNX.4.33.0112211158580.10272-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.33.0112240125040.1235-100000@mothra.mindrot.org>

On Fri, 21 Dec 2001, Damien Miller wrote:

> Over the holidays, I intend to finally rid portable OpenSSH of the
> builtin entropy collection code. Here's what I intend to do:

Have done :)

I have just committed a patch which splits out the entropy gathering
into a seperate process "ssh-rand-helper". As a result, there are
nearly 1k fewer lines of hairy code in ssh and sshd :)

There is an example ssh-rand-helper which, suspiciously enough, looks
exactly like the old in-process entropy gatherer. At the moment it is
not very pretty (though no worse than the old code), but it is time to
stop for this evening.

Hopefully someone else will step up to the plate and write or port
a proper Yarrow PRNG.

ssh-rand-helper is invoked by a hardcoded path (in libexecdir) and
must produce a fixed (48 byte) quantity of entropy to stdout on
execution. This is subject to change.

It would be greatly appreciated if people cast a critical eye over the
new entropy.c to make sure I haven't missed anything.

The new code should "just work" after a "make install", so please try it
out (after reading it thoroughly!)

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From eperez at it.uc3m.es  Mon Dec 24 02:04:40 2001
From: eperez at it.uc3m.es (eperez at it.uc3m.es)
Date: Sun, 23 Dec 2001 15:04:40 +0000
Subject: ssh port forwarding blocks in connect()
Message-ID: <20011223150440@localhost.localdomain>

Hello,
I've seen that ssh port forwarding blocks in connect()
Is this correct ?

ssh shouldn't block for a single event anywere

This is the problem:
I type:
ssh -L localport0:crahsedserver.com:remoteport0 -L localport1:workingserver:remoteport1 me at myserver.com

If I connect to localhost:localport0 and then to localhost:localport1
the second connection blocks until the first one finish with timeout

I'm using: OpenSSH_3.0.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
from Debian/3.0

Did you know the problem ?
Is anyone working on this ?
Am I wrong ?

I wish you a Merry Christmas,

                Eduardo


From bugzilla-daemon at mindrot.org  Mon Dec 24 02:35:44 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon, 24 Dec 2001 02:35:44 +1100 (EST)
Subject: [Bug 59] The contrib/chroot.diff patch is out of date and broken
Message-ID: <20011223153544.ABB2C2DF12@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=59





------- Additional Comments From raoul at cag.lcs.mit.edu  2001-12-24 02:35 -------
Created an attachment (id=7)
chroot patch for openssh-3.0.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  Mon Dec 24 13:41:20 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon, 24 Dec 2001 13:41:20 +1100 (EST)
Subject: [Bug 59] The contrib/chroot.diff patch is out of date and broken
Message-ID: <20011224024120.CCF642DF10@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=59

mouring at eviladmin.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From mouring at eviladmin.org  2001-12-24 13:41 -------
As soon as I get get my Linux box to talk to the CVS server again I plan on 
removing this patch from the main OpenSSH portable tree.  It will have to be 
maintained outside of the project.  Anyone who wishes to do so please send me 
your email address and where it will be hosted.  

- Ben



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From markus at openbsd.org  Mon Dec 24 22:24:26 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 24 Dec 2001 12:24:26 +0100
Subject: ssh port forwarding blocks in connect()
In-Reply-To: <20011223150440@localhost.localdomain>; from eperez@it.uc3m.es on Sun, Dec 23, 2001 at 03:04:40PM +0000
References: <20011223150440@localhost.localdomain>
Message-ID: <20011224122426.A9033@folly>

On Sun, Dec 23, 2001 at 03:04:40PM +0000, eperez at it.uc3m.es wrote:
> Hello,
> I've seen that ssh port forwarding blocks in connect()
> Is this correct ?

no. it does not block in connect() just when
using DNS (unless you use a very old version
of openssh). if you use -L the blocking
occurs in the sshd, so make sure you use a recent
openssh sshd.

-m


From tjw at tjw.org  Tue Dec 25 05:02:32 2001
From: tjw at tjw.org (Tony J. White)
Date: Mon, 24 Dec 2001 12:02:32 -0600 (CST)
Subject: static compilation
Message-ID: <Pine.LNX.4.33.0112241149530.31062-100000@gw.linespeed.net>


I had the same problem compiling openssh-3.0.2p1 statically on Slackware 8.0.
The problem is caused by the redefinition of opterr, optind, and optopt in
openbsd-compat/getopt.c (previously defined in libc).

Here's how I was able to get it to build statically:

1. ./configure

2. edit openbsd-compat/getopt.c
45 //int   opterr = 1,            /* if error message should be printed */
46 //      optind = 1,             /* index into parent argv vector */
47 //      optopt,                 /* character checked for validity */
48 int     optreset;               /* reset getopt */

3. edit openbsd-compat/Makefile
Added '-I/usr/include' to the CFLAGS variable.

4. edit Makefile
Added '-static' to the CC and LD variables

5. make

-Tony


>I'm currently running linux mandrake 8.0 and a redhat 7.1. I tried to
>compiled openssh 3.0 static without any succes, an error seems to appear in
>ssh.c, optreset declaration. Openssh 2.9 compiled statically without any
>problems: LDFLAGS=-static, CFLAGS=-static worked fine. Currently im no more
>able to compile it statically, the main error seems due to openbsd-compat..
>Of course if I dont use "-static" the compilation is okay.
>Does anyone have any ideas on how to compile cleanly OpenSSH, statically?





From rgooch at ras.ucalgary.ca  Tue Dec 25 10:43:16 2001
From: rgooch at ras.ucalgary.ca (Richard Gooch)
Date: Mon, 24 Dec 2001 16:43:16 -0700
Subject: OpenSSH-3.0.2p1 and Linux libc5
Message-ID: <200112242343.fBONhGN05505@vindaloo.ras.ucalgary.ca>

  Hi, all. I'm trying to compile OpenSSH-3.0.2p1 on a Linux libc5
system, and it fails when compiling packet.c with the following:

gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.  -DETCDIR=\"/etc/ssh\" -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=\"/var/run\" -DHAVE_CONFIG_H -c packet.c
packet.c: In function `packet_set_interactive':
packet.c:1211: `TCP_NODELAY' undeclared (first use in this function)
packet.c:1211: (Each undeclared identifier is reported only once
packet.c:1211: for each function it appears in.)

The naive solution of adding:
#include <linux/tcp.h>
doesn't work:
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.  -DETCDIR=\"/etc/ssh\" -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=\"/var/run\" -DHAVE_CONFIG_H -c packet.c
In file included from packet.c:62:
/usr/include/linux/tcp.h:23: redefinition of `struct tcphdr'

so I fell back to adding the following:
#define TCP_NODELAY 1

Brute force, but it works.

				Regards,

					Richard....
Permanent: rgooch at atnf.csiro.au
Current:   rgooch at ras.ucalgary.ca


From djm at mindrot.org  Wed Dec 26 00:22:46 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 26 Dec 2001 00:22:46 +1100 (EST)
Subject: OpenSSH-3.0.2p1 and Linux libc5
In-Reply-To: <200112242343.fBONhGN05505@vindaloo.ras.ucalgary.ca>
Message-ID: <Pine.LNX.4.33.0112260020340.1285-100000@mothra.mindrot.org>

On Mon, 24 Dec 2001, Richard Gooch wrote:

>   Hi, all. I'm trying to compile OpenSSH-3.0.2p1 on a Linux libc5
> system, and it fails when compiling packet.c with the following:

[snip - compilation failing on missing TCP_NODELAY]

> The naive solution of adding:
> #include <linux/tcp.h>
> doesn't work:

[snip - compliation failing on redef of struct tcphdr]

> so I fell back to adding the following:
> #define TCP_NODELAY 1
> 
> Brute force, but it works.

I can't think of any clean way we can get autoconf to work around this 
header breakage, but at least your message is in the archives (for those 
who bother to search them :)

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From mandar at webchat.chatsystems.com  Wed Dec 26 11:34:36 2001
From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com)
Date: Tue, 25 Dec 2001 18:34:36 -0600 (CST)
Subject: auth*.c
Message-ID: <Pine.LNX.4.33.0112251800260.15616-100000@webchat.chatsystems.com>

Folks,

During testing, we found a couple of issues with openssh3.0.2p1:

1. In userauth_finish() in auth2.c (as well as in do_authloop in auth1.c),
the foll. check:

  if (authctxt->failures++ > AUTH_FAIL_MAX)

is never satisfied and thus packet_disconnect() never gets called. I
suspect the code just drops out of the dispatch_run function list instead.
This should be an == instead of >. While looking at the debug output
when deliberately entering wrong passwords, I noticed one try for none,
three for password, and then three for keyboard-interactive, at which point
authctxt->failures is 6, and then the loop completes.

2. I'd like to move loginfailed() within the #ifdef WITH_AIXAUTHENTICATE
of auth1.c and auth2.c to auth_log() instead, and call it on every
password method failure, as well as an overall authctxt->failures ==
AUTH_FAIL_MAX check for the other methods. This should clean up the code a
bit, and should fix the issue of the unsuccessful login counter not being
incremented on each unsucessful try.


Please let me know if I should go ahead and submit cdiffs for auth.c,
auth1.c and auth2.c through bugzilla, or if these problems are already
known/assigned/resolved, or if I've missed something..thanks.

- Mandar




From dan at doxpara.com  Wed Dec 26 12:58:44 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 25 Dec 2001 17:58:44 -0800
Subject: OpenSSH-3.0.2p1 and Linux libc5
References: <Pine.LNX.4.33.0112260020340.1285-100000@mothra.mindrot.org>
Message-ID: <002101c18db2$22446f90$9601000a@effugas>

> > so I fell back to adding the following:
> > #define TCP_NODELAY 1
> >
> > Brute force, but it works.
>
> I can't think of any clean way we can get autoconf to work around this
> header breakage, but at least your message is in the archives (for those
> who bother to search them :)

What, we can't do something like:

#ifndef TCP_NODELAY
#define TCP_NODELAY 1
#endif

I mean, we support some damn obscure platforms, I think we should be able to
do libc5 :-)

--Dan




From djm at mindrot.org  Wed Dec 26 14:40:42 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 26 Dec 2001 14:40:42 +1100 (EST)
Subject: OpenSSH-3.0.2p1 and Linux libc5
In-Reply-To: <002101c18db2$22446f90$9601000a@effugas>
Message-ID: <Pine.LNX.4.33.0112261439510.1235-100000@mothra.mindrot.org>

On Tue, 25 Dec 2001, Dan Kaminsky wrote:

> What, we can't do something like:
> 
> #ifndef TCP_NODELAY
> #define TCP_NODELAY 1
> #endif

It's a rather big assumption that TCP_NODELAY is going to be 1 on every
platform that doesn't have it in its headers.

-d




From dan at doxpara.com  Wed Dec 26 15:23:45 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 25 Dec 2001 20:23:45 -0800
Subject: OpenSSH-3.0.2p1 and Linux libc5
References: <Pine.LNX.4.33.0112261439510.1235-100000@mothra.mindrot.org>
Message-ID: <004101c18dc5$1c00e920$9601000a@effugas>

> > #ifndef TCP_NODELAY
> > #define TCP_NODELAY 1
> > #endif
>
> It's a rather big assumption that TCP_NODELAY is going to be 1 on every
> platform that doesn't have it in its headers.

Fair enough.  The alternative is to surround lines 1211-1213 in packet.c
(the only place in the codebase where TCP_NODELAY is actually used) w/ a
simple #ifdef TCP_NODELAY.  Somehow, I suspect though that libc5 builds of
the Linux kernel still respect 1 as the value for TCP_NODELAY.  Regardless,
our top priority is to make sure the app compiles and works -- and I've been
more concerned than most about SSH's performance.

If it won't compile, it performs pretty terribly :-)

--Dan




From djm at mindrot.org  Wed Dec 26 16:28:06 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 26 Dec 2001 16:28:06 +1100 (EST)
Subject: OpenSSH-3.0.2p1 and Linux libc5
In-Reply-To: <004101c18dc5$1c00e920$9601000a@effugas>
Message-ID: <Pine.LNX.4.33.0112261627270.1235-100000@mothra.mindrot.org>

On Tue, 25 Dec 2001, Dan Kaminsky wrote:

> > > #ifndef TCP_NODELAY
> > > #define TCP_NODELAY 1
> > > #endif
> >
> > It's a rather big assumption that TCP_NODELAY is going to be 1 on every
> > platform that doesn't have it in its headers.
> 
> Fair enough.  The alternative is to surround lines 1211-1213 in packet.c
> (the only place in the codebase where TCP_NODELAY is actually used) w/ a
> simple #ifdef TCP_NODELAY. 

You don't want to do that on an interactive connection.

-d



From rgooch at ras.ucalgary.ca  Wed Dec 26 16:30:24 2001
From: rgooch at ras.ucalgary.ca (Richard Gooch)
Date: Tue, 25 Dec 2001 22:30:24 -0700
Subject: OpenSSH-3.0.2p1 and Linux libc5
In-Reply-To: <Pine.LNX.4.33.0112261627270.1235-100000@mothra.mindrot.org>
References: <004101c18dc5$1c00e920$9601000a@effugas>
	<Pine.LNX.4.33.0112261627270.1235-100000@mothra.mindrot.org>
Message-ID: <200112260530.fBQ5UOQ16696@vindaloo.ras.ucalgary.ca>

Damien Miller writes:
> On Tue, 25 Dec 2001, Dan Kaminsky wrote:
> 
> > > > #ifndef TCP_NODELAY
> > > > #define TCP_NODELAY 1
> > > > #endif
> > >
> > > It's a rather big assumption that TCP_NODELAY is going to be 1 on every
> > > platform that doesn't have it in its headers.
> > 
> > Fair enough.  The alternative is to surround lines 1211-1213 in packet.c
> > (the only place in the codebase where TCP_NODELAY is actually used) w/ a
> > simple #ifdef TCP_NODELAY. 
> 
> You don't want to do that on an interactive connection.

How about:
#if !defined(TCP_NODELAY) && defined(__linux__)
#  define TCP_NODELAY 1
#endif

That will work on all Linux systems, and doesn't have the problem of
using a possibly bogus value on other platforms which don't define it.

				Regards,

					Richard....
Permanent: rgooch at atnf.csiro.au
Current:   rgooch at ras.ucalgary.ca


From jmknoble at pobox.com  Thu Dec 27 10:43:10 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 26 Dec 2001 18:43:10 -0500
Subject: OpenSSH-3.0.2p1 and Linux libc5
In-Reply-To: <200112242343.fBONhGN05505@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Mon, Dec 24, 2001 at 04:43:16PM -0700
References: <200112242343.fBONhGN05505@vindaloo.ras.ucalgary.ca>
Message-ID: <20011226184309.A5039@zax.half.pint-stowp.cx>

Circa 2001-Dec-24 16:43:16 -0700 dixit Richard Gooch:

:   Hi, all. I'm trying to compile OpenSSH-3.0.2p1 on a Linux libc5
: system, and it fails when compiling packet.c with the following:
: 
: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.  -DETCDIR=\"/etc/ssh\" -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=\"/var/run\" -DHAVE_CONFIG_H -c packet.c
: packet.c: In function `packet_set_interactive':
: packet.c:1211: `TCP_NODELAY' undeclared (first use in this function)
: packet.c:1211: (Each undeclared identifier is reported only once
: packet.c:1211: for each function it appears in.)

That's odd.  I don't get any such error when compiling on Red Hat Linux
4.2 (libc-5.3.12-18.4, kernel-2.0.35).  Richard, what are the details
of the platform you're compiling on?

-- 
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/20011226/8e57678f/attachment.bin 

From kevin at kevindegraaf.net  Thu Dec 27 14:07:47 2001
From: kevin at kevindegraaf.net (Kevin DeGraaf)
Date: Wed, 26 Dec 2001 22:07:47 -0500 (EST)
Subject: Resolving error
Message-ID: <Pine.LNX.4.33.0112262121060.2211-100000@uranus.kevindegraaf.net>

OpenSSH gurus:

Apologies if this has been covered already (or is a genuine FAQ).  I've
searched both Google and MARC extensively on this issue, and have come up
empty.

I use OpenSSH 3.0.2p1 (openssl-0.9.6c) on a group of Linux (Slackware 8.0,
kernel 2.4.13, glibc 2.2.3) machines that have this in /etc/hosts:

10.1.1.2  s1  s1.[domain].com
...
10.1.1.6  s5  s5.[domain].com

This is in /etc/host.conf:
  order hosts, bind

This is in /etc/nsswitch.conf:
  hosts:    files dns

This is in /etc/resolv.conf:
  domain [domain].com
  nameserver 127.0.0.1

If I ssh from one of these servers to another using IP addresses, the
connection takes place in milliseconds (they are 1 GHz, 1 GB RAM machines
with 100-base-TX switched Ethernet).  However, trying to ssh using a
hostname (e.g. "s1" or "s1.[domain].com") results in a five-second delay
before successful authentication takes place.

Running strace on the ssh command indicates that:

1. /etc/nsswitch.conf is read.
2. /etc/passwd, group, and services are read.
3. /etc/resolv.conf is read.
4. /etc/host.conf is read.
5. /etc/hosts is read.
6. Multiple DNS queries are made to my nameserver (127.0.0.1).
7. /etc/resolv.conf is read again.
8. ssh finally has the correct IP address and begins a key-auth
dialogue that works without error.

Every UNIX networking program I know of (e.g. telnet, ftp, ping) obeys
either host.conf or nsswitch.conf, which in my case both clearly state
that /etc/hosts should be consulted before a DNS lookup is performed.
But OpenSSH seems to ignore the host data it reads in step 5, consulting
my DNS servers instead.

(This is a problem because my local resolver, DJB's dnscache, follows the
delegation for s[1-5].[domain].com all the way to the authoritative
nameservers, which are s5 and s1; all the servers are NAT'ed behind a PIX,
rendering them inaccessable to each other via their external addresses.)

This delay is annoying, and wouldn't happen if OpenSSH read /etc/hosts and
used that data, as it should.

--
Kevin DeGraaf



From pekkas at netcore.fi  Thu Dec 27 17:56:52 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 27 Dec 2001 08:56:52 +0200 (EET)
Subject: Resolving error
In-Reply-To: <Pine.LNX.4.33.0112262121060.2211-100000@uranus.kevindegraaf.net>
Message-ID: <Pine.LNX.4.33.0112270852590.19575-100000@netcore.fi>

On Wed, 26 Dec 2001, Kevin DeGraaf wrote:
> This delay is annoying, and wouldn't happen if OpenSSH read /etc/hosts and
> used that data, as it should.

Try compiling with --with-ipv4-default.

This might be the same issue as:

Date: Sat, 8 Dec 2001 14:27:22 +0200 (EET)
From: Pekka Savola <pekkas at netcore.fi>
To: Gil Disatnik <Jewnix at technohac.com>
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Name Resolving bug in Open SSH 3.0.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






From markus at openbsd.org  Thu Dec 27 23:01:30 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 27 Dec 2001 13:01:30 +0100
Subject: auth*.c
In-Reply-To: <Pine.LNX.4.33.0112251800260.15616-100000@webchat.chatsystems.com>; from mandar@webchat.chatsystems.com on Tue, Dec 25, 2001 at 06:34:36PM -0600
References: <Pine.LNX.4.33.0112251800260.15616-100000@webchat.chatsystems.com>
Message-ID: <20011227130130.C25982@folly>

On Tue, Dec 25, 2001 at 06:34:36PM -0600, mandar at webchat.chatsystems.com wrote:
> Folks,
> 
> During testing, we found a couple of issues with openssh3.0.2p1:
> 
> 1. In userauth_finish() in auth2.c (as well as in do_authloop in auth1.c),
> the foll. check:
> 
>   if (authctxt->failures++ > AUTH_FAIL_MAX)
> 
> is never satisfied and thus packet_disconnect() never gets called. I
> suspect the code just drops out of the dispatch_run function list instead.
> This should be an == instead of >. While looking at the debug output
> when deliberately entering wrong passwords, I noticed one try for none,
> three for password, and then three for keyboard-interactive, at which point
> authctxt->failures is 6, and then the loop completes.

sorry, i don't understand.


From dalco_lehmann at hotmail.com  Fri Dec 28 01:02:13 2001
From: dalco_lehmann at hotmail.com (Jonas Lehmann)
Date: Thu, 27 Dec 2001 15:02:13 +0100
Subject: sftp-server and chroot
Message-ID: <F132U64z1TXcfTqeB7P00011453@hotmail.com>

Hi,

It's a shame that the sshd/sftp-server programs do not support chroot and 
sftp-only users.  As far as I can tell, there's a patch availble that 
modifies OpenSSH to chroot() based on a specific entry in /etc/passwd.

Since, I personally, do not enjoy applying unofficial patches to released 
programs, I was looking for an alternative but found none.

I've written a small sample program 'sftpsh' which acts as a shell 
replacement for sftp-only users.   The 'sftpsh' is assigned to users in 
/etc/passwd and is used instead of fully functional shells such as 
/bin/bash.

'sftpsh' is primitive and only performs two tasks.  First it changes the 
root directory to the user's home directory (chroot($HOME)) and then it 
exec's the 'sftp-server'.   Since chroot() can only be invoked successfully 
as root, 'sftpsh' unfortunately has to run as root.  The first thing 
'sftpsh' does is chroot() followed by resetting the uid/gid.

The source for 'sftpsh' is available from 
http://www.jonaslehmann.info/linux/sftpsh.c .

If there's a more official way to accomplish this without patching or 
additional programs, I'd appreciate pointers.

Regards,
-Jonas


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From kevin at kevindegraaf.net  Fri Dec 28 01:47:36 2001
From: kevin at kevindegraaf.net (Kevin DeGraaf)
Date: Thu, 27 Dec 2001 09:47:36 -0500 (EST)
Subject: Resolving error
In-Reply-To: <Pine.LNX.4.33.0112270852590.19575-100000@netcore.fi>
Message-ID: <Pine.LNX.4.33.0112270947150.3014-100000@uranus.kevindegraaf.net>

> Try compiling with --with-ipv4-default.

Problem solved.  Thank you.

--
Kevin DeGraaf



From djast at cs.toronto.edu  Fri Dec 28 02:18:19 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Thu, 27 Dec 2001 10:18:19 -0500
Subject: sftp-server and chroot 
In-Reply-To: Message from "Jonas Lehmann" <dalco_lehmann@hotmail.com> 
   of "Thu, 27 Dec 2001 09:02:13 EST." <F132U64z1TXcfTqeB7P00011453@hotmail.com> 
Message-ID: <01Dec27.101824edt.453142-24906@jane.cs.toronto.edu>

On Thu, 27 Dec 2001 09:02:13 EST, "Jonas Lehmann" writes:
> 
> 'sftpsh' is primitive and only performs two tasks.  First it changes the 
> root directory to the user's home directory (chroot($HOME)) and then it 
> exec's the 'sftp-server'.   Since chroot() can only be invoked successfully 
> as root, 'sftpsh' unfortunately has to run as root.  The first thing 
> 'sftpsh' does is chroot() followed by resetting the uid/gid.

This program, like the sftp-server.c patch recently posted to this list,
is potentially a huge security hole, and IMHO should not be used in its
present form.

There's a *reason* you have to be root in order to use the chroot()
system call.

This program lets any user on the system chroot() to an arbitrary
directory under the user's control by setting the HOME environment
variable.  This can quickly lead to a root compromise, e.g., by creating
hard links to privileged programs which expect to be run under the real
filesystem root (or at least a secure one).

Also:
- the program doesn't check whether the chdir() after the chroot is
  successful;
- the code which attempts to reset the uid/gids has a number of
  problems, which I won't go into here.

-- 
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 dalco_lehmann at hotmail.com  Fri Dec 28 05:24:09 2001
From: dalco_lehmann at hotmail.com (Jonas Lehmann)
Date: Thu, 27 Dec 2001 19:24:09 +0100
Subject: sftp-server and chroot
Message-ID: <F15skB47qXLFfJNwPmx000118bb@hotmail.com>

Thanks Dan.   I agree with you.  I wouldn't use either yet, either.

I did look at attempting to fix some of the obvious shortcomings you easily 
and quickly detected.

The chroot($HOME) problem I had underestimated.  I knew that a user with 
shell access could set his $HOME and then run /bin/sftpsh.  I tried that and 
it certainly worked.  But, I falsely assumed that by exec'ing the 
sftp-server the security risk to the system would be minimal.  But, I'm most 
likely just naive.

I added a success check to chdir() to make sure that worked.

I'm interested in (maybe not appropriate for newsgroup) why the setreuid() 
and success checking is not sufficient after chroot().

To remove the risk of $HOME exploits, I changed the sample program to use 
getpwent() instead of getenv("HOME").  I'm sure this is not great either.  I 
know that a user's home directory may not be secure in itself but I 
conceptually like the simplicity of working with home directories.


Appreciate your feedback,
-Jonas



>From: Dan Astoorian <djast at cs.toronto.edu>
>To: "Jonas Lehmann" <dalco_lehmann at hotmail.com>
>CC: openssh-unix-dev at mindrot.org
>Subject: Re: sftp-server and chroot
>Date: Thu, 27 Dec 2001 10:18:19 -0500

>This program lets any user on the system chroot() to an arbitrary
>directory under the user's control by setting the HOME environment
>variable.

>Also:
>- the program doesn't check whether the chdir() after the chroot is
>   successful;
>- the code which attempts to reset the uid/gids has a number of
>   problems, which I won't go into here.


>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




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



From vinschen at redhat.com  Fri Dec 28 20:17:32 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 28 Dec 2001 10:17:32 +0100
Subject: [PATCH]: Fix potential security hole in Cygwin version
In-Reply-To: <20011218202009.G21898@cygbert.vinschen.de>
References: <20011218202009.G21898@cygbert.vinschen.de>
Message-ID: <20011228101732.A14970@cygbert.vinschen.de>

Hi,

could anybody please look into these Cygwin specific changes and either
apply them or tell me why they shouldn't get applied?

This patch

"[PATCH] Fix potential security hole in Cygwin version"

and the following two patches

"[PATCH]: Fix environment variable size restriction in Cygwin version"
"[PATCH]: Fix typo in contrib/cygwin/README"

are already part of OpenSSH-3.0.2p1-3 in the Cygwin net distribution but
they all belong into the main sources.

Thanks,
Corinna

On Tue, Dec 18, 2001 at 08:20:09PM +0100, Corinna Vinschen wrote:
> Hi,
> 
> the following patch fixes a potential security hole in the Cygwin
> version of sshd.
> 
> If you're logging in to a Cygwin sshd with version 2 protocol using an
> arbitrary user name which is not in /etc/passwd, the forked sshd which
> is handling this connection crashes with a segmentation violation.  The
> client side encounters an immediate disconnect ("Connection reset by   
> peer").  This could be used by a malicious remote client to enumerate
> the user names on the Cygwin server machine.
> 
> The cause is that the Cygwin specific function check_nt_auth() is called
> in auth1.c and auth2.c with implicitly dereferencing the pointer to struct
> passwd to get the pw_uid member as parameter.  This struct passwd pointer
> can be NULL if the user isn't found in /etc/passwd.  Other similar funcs
> as auth_pam_password() are called getting the structy passwd pointer
> itself as parameter, testing it for NULL inside of the function.
> 
> Changing the check_nt_auth() to behave that way and changing auth1.c and
> auth2.c accordingly solves that problem.
> 
> Patch follows.
> 
> Thanks,
> Corinna
> 
> Index: auth1.c
> ===================================================================
> RCS file: /cvs/openssh_cvs/auth1.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 auth1.c
> --- auth1.c	6 Dec 2001 17:55:26 -0000	1.46
> +++ auth1.c	18 Dec 2001 19:07:12 -0000
> @@ -313,9 +313,9 @@ do_authloop(Authctxt *authctxt)
>  
>  #ifdef HAVE_CYGWIN
>  		if (authenticated &&
> -		    !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD,pw->pw_uid)) {
> +		    !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD, pw)) {
>  			packet_disconnect("Authentication rejected for uid %d.",
> -			(int)pw->pw_uid);
> +			pw ? (int)pw->pw_uid : -1);
>  			authenticated = 0;
>  		}
>  #else
> Index: auth2.c
> ===================================================================
> RCS file: /cvs/openssh_cvs/auth2.c,v
> retrieving revision 1.78
> diff -u -p -r1.78 auth2.c
> --- auth2.c	6 Dec 2001 17:55:26 -0000	1.78
> +++ auth2.c	18 Dec 2001 19:07:13 -0000
> @@ -341,7 +341,7 @@ userauth_none(Authctxt *authctxt)
>  		return(0);
>  
>  #ifdef HAVE_CYGWIN
> -	if (check_nt_auth(1, authctxt->pw->pw_uid) == 0)
> +	if (check_nt_auth(1, authctxt->pw) == 0)
>  		return(0);
>  #endif
>  #ifdef USE_PAM
> @@ -367,7 +367,7 @@ userauth_passwd(Authctxt *authctxt)
>  	packet_done();
>  	if (authctxt->valid &&
>  #ifdef HAVE_CYGWIN
> -		check_nt_auth(1, authctxt->pw->pw_uid) &&
> +	    check_nt_auth(1, authctxt->pw) &&
>  #endif
>  #ifdef USE_PAM
>  	    auth_pam_password(authctxt->pw, password) == 1)
> @@ -404,7 +404,7 @@ userauth_kbdint(Authctxt *authctxt)
>  	xfree(devs);
>  	xfree(lang);
>  #ifdef HAVE_CYGWIN
> -	if (check_nt_auth(0, authctxt->pw->pw_uid) == 0)
> +	if (check_nt_auth(0, authctxt->pw) == 0)
>  		return(0);
>  #endif
>  	return authenticated;
> @@ -510,7 +510,7 @@ userauth_pubkey(Authctxt *authctxt)
>  	xfree(pkalg);
>  	xfree(pkblob);
>  #ifdef HAVE_CYGWIN
> -	if (check_nt_auth(0, authctxt->pw->pw_uid) == 0)
> +	if (check_nt_auth(0, authctxt->pw) == 0)
>  		return(0);
>  #endif
>  	return authenticated;
> Index: openbsd-compat/bsd-cygwin_util.c
> ===================================================================
> RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 bsd-cygwin_util.c
> --- openbsd-compat/bsd-cygwin_util.c	27 Nov 2001 01:19:44 -0000	1.6
> +++ openbsd-compat/bsd-cygwin_util.c	18 Dec 2001 19:07:14 -0000
> @@ -58,7 +58,7 @@ int binary_pipe(int fd[2])
>  	return ret;
>  }
>  
> -int check_nt_auth(int pwd_authenticated, uid_t uid)
> +int check_nt_auth(int pwd_authenticated, struct passwd *pw)
>  {
>  	/*
>  	* The only authentication which is able to change the user
> @@ -73,6 +73,8 @@ int check_nt_auth(int pwd_authenticated,
>  	*/
>  	static int has_create_token = -1;
>  
> +	if (pw == NULL)
> +		return 0;
>  	if (is_winnt) {
>  		if (has_create_token < 0) {
>  			struct utsname uts;
> @@ -90,7 +92,7 @@ int check_nt_auth(int pwd_authenticated,
>  			}
>  		}
>  		if (has_create_token < 1 &&
> -		    !pwd_authenticated && geteuid() != uid)
> +		    !pwd_authenticated && geteuid() != pw->pw_uid)
>  			return 0;
>  	}
>  	return 1;
> Index: openbsd-compat/bsd-cygwin_util.h
> ===================================================================
> RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 bsd-cygwin_util.h
> --- openbsd-compat/bsd-cygwin_util.h	27 Nov 2001 01:19:44 -0000	1.5
> +++ openbsd-compat/bsd-cygwin_util.h	18 Dec 2001 19:07:14 -0000
> @@ -24,7 +24,7 @@
>  
>  int binary_open(const char *filename, int flags, ...);
>  int binary_pipe(int fd[2]);
> -int check_nt_auth(int pwd_authenticated, uid_t uid);
> +int check_nt_auth(int pwd_authenticated, struct passwd *pw);
>  int check_ntsec(const char *filename);
>  void register_9x_service(void);
>  
> -- 
> Corinna Vinschen
> Cygwin Developer
> Red Hat, Inc.
> mailto:vinschen at redhat.com

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From andreas at conectiva.com.br  Fri Dec 28 23:33:57 2001
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Fri, 28 Dec 2001 10:33:57 -0200
Subject: Openssh portable and specific version of openssl
Message-ID: <20011228103357.F1154@conectiva.com.br>

Hello!
Why is it that openssh portable requires always the specific
version of openssl it was compiled with, even when there are
no ABI changes in the library? Just a precaution?



From markus at openbsd.org  Sat Dec 29 00:09:20 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 28 Dec 2001 14:09:20 +0100
Subject: Openssh portable and specific version of openssl
In-Reply-To: <20011228103357.F1154@conectiva.com.br>
References: <20011228103357.F1154@conectiva.com.br>
Message-ID: <20011228140920.B15750@faui02>

On Fri, Dec 28, 2001 at 10:33:57AM -0200, Andreas Hasenack wrote:
> Hello!
> Why is it that openssh portable requires always the specific
> version of openssl it was compiled with, even when there are
> no ABI changes in the library? Just a precaution?
> 

AFAIK openssl is not always binary compatible.

-m


From djm at mindrot.org  Sat Dec 29 00:13:56 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 29 Dec 2001 00:13:56 +1100 (EST)
Subject: [PATCH]: Fix potential security hole in Cygwin version
In-Reply-To: <20011228101732.A14970@cygbert.vinschen.de>
Message-ID: <Pine.LNX.4.33.0112290011280.1232-100000@mothra.mindrot.org>

On Fri, 28 Dec 2001, Corinna Vinschen wrote:

> Hi,
> 
> could anybody please look into these Cygwin specific changes and either
> apply them or tell me why they shouldn't get applied?

It could be that some of us are enjoying the holiday break.

Please post future patches to http://bugzilla.mindrot.org They are less
likely to get passed over that way.

-d



From djm at mindrot.org  Sat Dec 29 00:15:33 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 29 Dec 2001 00:15:33 +1100 (EST)
Subject: Openssh portable and specific version of openssl
In-Reply-To: <20011228103357.F1154@conectiva.com.br>
Message-ID: <Pine.LNX.4.33.0112290013580.1232-100000@mothra.mindrot.org>

On Fri, 28 Dec 2001, Andreas Hasenack wrote:

> Hello!
> Why is it that openssh portable requires always the specific
> version of openssl it was compiled with, even when there are
> no ABI changes in the library? Just a precaution?

OpenSSL have a nasty habit of breaking binary compatability between
releases of their library. The check has been loosened in CVS portable
OpenSSH to allow upgrading OpenSSL releases which only change the
patchlevel.

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)



From bugzilla-daemon at mindrot.org  Sat Dec 29 00:35:26 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 29 Dec 2001 00:35:26 +1100 (EST)
Subject: [Bug 36] Channels for rejected X sessions hang
Message-ID: <20011228133526.53A672DF5A@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=36

markus at openbsd.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|openssh-unix-dev at mindrot.org|markus at openbsd.org



------- Additional Comments From markus at openbsd.org  2001-12-29 00:35 -------
i'll look into this



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From dan at doxpara.com  Sat Dec 29 00:36:29 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 28 Dec 2001 05:36:29 -0800
Subject: [PATCH]: Fix potential security hole in Cygwin version
References: <Pine.LNX.4.33.0112290011280.1232-100000@mothra.mindrot.org>
Message-ID: <03fc01c18fa4$a8206b70$9601000a@effugas>

> It could be that some of us are enjoying the holiday break.

To put it a *wee* bit nicer, Happy Holidays everyone :-D

--Dan




From andreas at conectiva.com.br  Sat Dec 29 00:37:35 2001
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Fri, 28 Dec 2001 11:37:35 -0200
Subject: Openssh portable and specific version of openssl
In-Reply-To: <Pine.LNX.4.33.0112290013580.1232-100000@mothra.mindrot.org>
References: <20011228103357.F1154@conectiva.com.br> <Pine.LNX.4.33.0112290013580.1232-100000@mothra.mindrot.org>
Message-ID: <20011228113735.A1187@conectiva.com.br>

Em Sat, Dec 29, 2001 at 12:15:33AM +1100, Damien Miller escreveu:
> > no ABI changes in the library? Just a precaution?
> 
> OpenSSL have a nasty habit of breaking binary compatability between
> releases of their library. The check has been loosened in CVS portable

Yeah, I thought so. They break compatibility with minor releases sometimes.
Thanks for the reply.



From bugzilla-daemon at mindrot.org  Sat Dec 29 00:37:54 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 29 Dec 2001 00:37:54 +1100 (EST)
Subject: [Bug 56] SSH2_MSG_UNIMPLEMENTED is implemented wrong
Message-ID: <20011228133754.E58D72DF61@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=56

markus at openbsd.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From markus at openbsd.org  2001-12-29 00:37 -------
fixed in -current



------- 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 Dec 29 00:57:27 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 29 Dec 2001 00:57:27 +1100 (EST)
Subject: [Bug 13] Need faster ssh startup when no /dev/random or prngd available
Message-ID: <20011228135727.D1AEC2DF0E@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=13

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From djm at mindrot.org  2001-12-29 00:57 -------
This is redundant now. You can implement whatever local policy you like using
shell script wrappers around the new ssh-rand-helper in -current CVS



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From david-bronder at uiowa.edu  Sat Dec 29 04:26:23 2001
From: david-bronder at uiowa.edu (David Bronder)
Date: Fri, 28 Dec 2001 11:26:23 -0600 (CST)
Subject: [openssh-unix-dev] auth*.c
In-Reply-To: <Pine.LNX.4.33.0112251800260.15616-100000@webchat.chatsystems.com> from "mandar@webchat.chatsystems.com" at Dec 25, 2001 06:34:36 PM
Message-ID: <200112281726.fBSHQNU15968@fire.its.uiowa.edu>

I've been working on some patches to address these same issues
with OpenSSH and AIX.  In the process, though, I've uncovered
some further complications.

The current incarnation of my patch does the following things:

  * Moves the AIX loginfailed() call into the auth_log() call as
    in your point (2) below.  This effectively addresses your point
    (1) as well; your fix for that point doesn't cover it since the
    client decides how many or few authentication attempts to make
    (the client may try fewer methods or fewer retries).

  * Moves the AIX loginsuccess() call down in session.c to after the
    record_login() call, which made more sense to me.

I haven't submitted the patch yet because of new problems that it
uncovered.  The problems have to do with how /etc/nologin is handled
under AIX in particular, and "invalid" users in general.  If these
problems can be resolved (or maybe even if they can't), I'll post
the patch after I've finished testing.

The first problem is that the AIX loginrestrictions() call returns
failure if /etc/nologin exists and the user is not root.  So in
OpenSSH, a non-root user will be marked as invalid, and will never
reach the normal nologin handling.  There is no way to tell from
loginrestrictions() what condition(s) caused the failure.  So the
connection attempt will fail but the client will get no indication
of why.

The other problem is that OpenSSH allows an invalid user to continue
retrying authentication, even though all the authentication methods
immediately fail when authctxt->valid is false or authctxt->pw is
NULL.  In the case of AIX and /etc/nologin, the user inflates the
unsuccessful login counter, but gets no feedback as to what's going
on.

My question to the developers is this:  Should login attempts by an
invalid user behave this way?  Or should the invalid user check be
made after a successful authentication instead of before, and then
cause the disconnect?  The latter seems more correct to me.

Also, I'll take any advice offered on how to handle the /etc/nologin
feedback issue under AIX...

=Dave

mandar at webchat.chatsystems.com wrote:
> 
> During testing, we found a couple of issues with openssh3.0.2p1:
> 
> 1. In userauth_finish() in auth2.c (as well as in do_authloop in auth1.c),
> the foll. check:
> 
>   if (authctxt->failures++ > AUTH_FAIL_MAX)
> 
> is never satisfied and thus packet_disconnect() never gets called. I
> suspect the code just drops out of the dispatch_run function list instead.
> This should be an == instead of >. While looking at the debug output
> when deliberately entering wrong passwords, I noticed one try for none,
> three for password, and then three for keyboard-interactive, at which point
> authctxt->failures is 6, and then the loop completes.
> 
> 2. I'd like to move loginfailed() within the #ifdef WITH_AIXAUTHENTICATE
> of auth1.c and auth2.c to auth_log() instead, and call it on every
> password method failure, as well as an overall authctxt->failures ==
> AUTH_FAIL_MAX check for the other methods. This should clean up the code a
> bit, and should fix the issue of the unsuccessful login counter not being
> incremented on each unsucessful try.


-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu


From florin at sgi.com  Sat Dec 29 06:14:35 2001
From: florin at sgi.com (Florin Andrei)
Date: 28 Dec 2001 11:14:35 -0800
Subject: openssh reveals existing accounts?
Message-ID: <1009566875.8821.5.camel@stantz.corp.sgi.com>

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57859

There's a method to see if an account exists or not: if it does exist,
and the password fails, there's a small delay before getting the prompt
again. But if it doesn't, the password prompt returns immediately.
Looks like a bug... :o)

-- 
Florin Andrei

Linux Is Not "gnU linuX"


---------------------------------------------------------------------
To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com
For additional commands, e-mail: secureshell-help at securityfocus.com



From markus at openbsd.org  Sat Dec 29 06:40:25 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 28 Dec 2001 20:40:25 +0100
Subject: openssh reveals existing accounts?
In-Reply-To: <1009567736.7993.10.camel@stantz.corp.sgi.com>
References: <1009566875.8821.5.camel@stantz.corp.sgi.com> <20011228201857.A5932@faui02> <1009567736.7993.10.camel@stantz.corp.sgi.com>
Message-ID: <20011228204025.B5932@faui02>

On Fri, Dec 28, 2001 at 11:28:56AM -0800, Florin Andrei wrote:
> On Fri, 2001-12-28 at 11:18, Markus Friedl wrote:
> > On Fri, Dec 28, 2001 at 11:14:35AM -0800, Florin Andrei wrote:
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57859
> > > 
> > > There's a method to see if an account exists or not: if it does exist,
> > > and the password fails, there's a small delay before getting the prompt
> > > again. But if it doesn't, the password prompt returns immediately.
> > 
> > i doubt this.
> 
> I would certainly believe you, but i prefer to believe my own eyes. :-)
> See the link in my message for details.

you report is lacking details.

this all depends on the speed of crypt() on the target system.

also,
	When you login by ssh to a host and the password fails, there's
	a small delay before getting the password prompt again, which
	prevents bruteforce attacks.
is wrong, this has nothing to do with bruteforce prevention.

-m


From djm at mindrot.org  Sat Dec 29 14:00:03 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 29 Dec 2001 14:00:03 +1100 (EST)
Subject: [PATCH]: Fix environment variable size restriction in Cygwin
 version
In-Reply-To: <20011218202526.H21898@cygbert.vinschen.de>
Message-ID: <Pine.LNX.4.33.0112291359240.1232-100000@mothra.mindrot.org>

On Tue, 18 Dec 2001, Corinna Vinschen wrote:

> Hi,
> 
> the following patch changes the Cygwin specific function
> tcopy_environment() o not restricting the strlen of a single
> tenvironment variable to 512 byte.

This patch is simpler. Comments?

Index: session.c
===================================================================
RCS file: /var/cvs/openssh/session.c,v
retrieving revision 1.162
diff -u -r1.162 session.c
--- session.c	2001/12/21 03:58:36	1.162
+++ session.c	2001/12/29 02:59:16
@@ -885,62 +885,28 @@
 	fclose(f);
 }
 
-#ifdef USE_PAM
-/*
- * Sets any environment variables which have been specified by PAM
- */
-void do_pam_environment(char ***env, u_int *envsize)
+void copy_environment(char **source, char ***env, u_int *envsize)
 {
-	char *equals, var_name[512], var_val[512];
-	char **pam_env;
+	char *var_name, *var_val;
 	int i;
 
-	if ((pam_env = fetch_pam_environment()) == NULL)
+	if (source == NULL)
 		return;
 
-	for(i = 0; pam_env[i] != NULL; i++) {
-		if ((equals = strstr(pam_env[i], "=")) == NULL)
+	for(i = 0; source[i] != NULL; i++) {
+		var_name = xstrdup(source[i]);
+		if ((var_val = strstr(var_name, "=")) == NULL) {
+			xfree(var_name);
 			continue;
-
-		if (strlen(pam_env[i]) < (sizeof(var_name) - 1)) {
-			memset(var_name, '\0', sizeof(var_name));
-			memset(var_val, '\0', sizeof(var_val));
-
-			strncpy(var_name, pam_env[i], equals - pam_env[i]);
-			strcpy(var_val, equals + 1);
-
-			debug3("PAM environment: %s=%s", var_name, var_val);
-
-			child_set_env(env, envsize, var_name, var_val);
 		}
-	}
-}
-#endif /* USE_PAM */
-
-#ifdef HAVE_CYGWIN
-void copy_environment(char ***env, u_int *envsize)
-{
-	char *equals, var_name[512], var_val[512];
-	int i;
-
-	for(i = 0; environ[i] != NULL; i++) {
-		if ((equals = strstr(environ[i], "=")) == NULL)
-			continue;
+		*var_val++ = '\0';
 
-		if (strlen(environ[i]) < (sizeof(var_name) - 1)) {
-			memset(var_name, '\0', sizeof(var_name));
-			memset(var_val, '\0', sizeof(var_val));
-
-			strncpy(var_name, environ[i], equals - environ[i]);
-			strcpy(var_val, equals + 1);
-
-			debug3("Copy environment: %s=%s", var_name, var_val);
-
-			child_set_env(env, envsize, var_name, var_val);
-		}
+		debug3("Copy environment: %s=%s", var_name, var_val);
+		child_set_env(env, envsize, var_name, var_val);
+		
+		xfree(var_name);
 	}
 }
-#endif
 
 #if defined(HAVE_GETUSERATTR)
 /*
@@ -1215,7 +1181,7 @@
 	 * The Windows environment contains some setting which are
 	 * important for a running system. They must not be dropped.
 	 */
-	copy_environment(&env, &envsize);
+	copy_environment(environ, &env, &envsize);
 #endif
 
 	if (!options.use_login) {
@@ -1299,7 +1265,7 @@
 #endif
 #ifdef USE_PAM
 	/* Pull in any environment variables that may have been set by PAM. */
-	do_pam_environment(&env, &envsize);
+	copy_environment(fetch_pam_environment(), &env, &envsize);
 #endif /* USE_PAM */
 
 	if (auth_get_socket_name() != NULL)



From djm at mindrot.org  Sat Dec 29 14:08:40 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 29 Dec 2001 14:08:40 +1100 (EST)
Subject: [PATCH]: Fix potential security hole in Cygwin version
In-Reply-To: <20011218202009.G21898@cygbert.vinschen.de>
Message-ID: <Pine.LNX.4.33.0112291408330.1232-100000@mothra.mindrot.org>

On Tue, 18 Dec 2001, Corinna Vinschen wrote:

> Hi,
> 
> the following patch fixes a potential security hole in the Cygwin
> version of sshd.

Applied.

-d



From djm at mindrot.org  Sat Dec 29 14:10:17 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 29 Dec 2001 14:10:17 +1100 (EST)
Subject: [PATCH]: Fix typo in contrib/cygwin/README
In-Reply-To: <20011218202926.I21898@cygbert.vinschen.de>
Message-ID: <Pine.LNX.4.33.0112291410110.1232-100000@mothra.mindrot.org>

On Tue, 18 Dec 2001, Corinna Vinschen wrote:

> Hi,
> 
> the following patch fixes just a typo in the Cygwin's README file.

Applied



From bugzilla-daemon at mindrot.org  Sat Dec 29 19:26:49 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 29 Dec 2001 19:26:49 +1100 (EST)
Subject: [Bug 58] Cannot find a type to use in place of socklen_t
Message-ID: <20011229082649.0D5D82DF0F@shitei.mindrot.org>

http://bugzilla.mindrot.org/show_bug.cgi?id=58

bugzilla at candlefire.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME



------- Additional Comments From bugzilla at candlefire.org  2001-12-29 19:26 -------
This is probaly not a bug.  I resolved my issues by simply correcting 
the /usr/include/asm path by creating a symlink to /usr/include/asm-sparc.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From markus at openbsd.org  Sat Dec 29 21:00:02 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 29 Dec 2001 11:00:02 +0100
Subject: [openssh-unix-dev] auth*.c
In-Reply-To: <200112281726.fBSHQNU15968@fire.its.uiowa.edu>; from david-bronder@uiowa.edu on Fri, Dec 28, 2001 at 11:26:23AM -0600
References: <Pine.LNX.4.33.0112251800260.15616-100000@webchat.chatsystems.com> <200112281726.fBSHQNU15968@fire.its.uiowa.edu>
Message-ID: <20011229110002.C19143@folly>

On Fri, Dec 28, 2001 at 11:26:23AM -0600, David Bronder wrote:
> My question to the developers is this:  Should login attempts by an
> invalid user behave this way?  Or should the invalid user check be
> made after a successful authentication instead of before, and then
> cause the disconnect?  The latter seems more correct to me.

how can a non existing user authenticate successful?


From vinschen at redhat.com  Sat Dec 29 21:12:40 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sat, 29 Dec 2001 11:12:40 +0100
Subject: [PATCH]: Fix environment variable size restriction in Cygwin version
In-Reply-To: <Pine.LNX.4.33.0112291359240.1232-100000@mothra.mindrot.org>
References: <20011218202526.H21898@cygbert.vinschen.de> <Pine.LNX.4.33.0112291359240.1232-100000@mothra.mindrot.org>
Message-ID: <20011229111240.A22640@cygbert.vinschen.de>

On Sat, Dec 29, 2001 at 02:00:03PM +1100, Damien Miller wrote:
> On Tue, 18 Dec 2001, Corinna Vinschen wrote:
> 
> > Hi,
> > 
> > the following patch changes the Cygwin specific function
> > tcopy_environment() o not restricting the strlen of a single
> > tenvironment variable to 512 byte.
> 
> This patch is simpler. Comments?

It's ok with me, especially that you're using the same function
for both, PAM and Cygwin.  The difference is just that I'm trying
to avoid many single xmalloc/xfree pairs since that will probably
clutter up the memory in conjunction with the call to child_set_env()

    for all env_vars:
	xstrcpy
	    xmalloc
	xfree

which is the reason I used xrealloc.  But that's probably just a
theoretical difference so I don't care.

Thanks,
Corinna

> Index: session.c
> ===================================================================
> RCS file: /var/cvs/openssh/session.c,v
> retrieving revision 1.162
> diff -u -r1.162 session.c
> --- session.c	2001/12/21 03:58:36	1.162
> +++ session.c	2001/12/29 02:59:16
> @@ -885,62 +885,28 @@
>  	fclose(f);
>  }
>  
> -#ifdef USE_PAM
> -/*
> - * Sets any environment variables which have been specified by PAM
> - */
> -void do_pam_environment(char ***env, u_int *envsize)
> +void copy_environment(char **source, char ***env, u_int *envsize)
>  {
> -	char *equals, var_name[512], var_val[512];
> -	char **pam_env;
> +	char *var_name, *var_val;
>  	int i;
>  
> -	if ((pam_env = fetch_pam_environment()) == NULL)
> +	if (source == NULL)
>  		return;
>  
> -	for(i = 0; pam_env[i] != NULL; i++) {
> -		if ((equals = strstr(pam_env[i], "=")) == NULL)
> +	for(i = 0; source[i] != NULL; i++) {
> +		var_name = xstrdup(source[i]);
> +		if ((var_val = strstr(var_name, "=")) == NULL) {
> +			xfree(var_name);
>  			continue;
> -
> -		if (strlen(pam_env[i]) < (sizeof(var_name) - 1)) {
> -			memset(var_name, '\0', sizeof(var_name));
> -			memset(var_val, '\0', sizeof(var_val));
> -
> -			strncpy(var_name, pam_env[i], equals - pam_env[i]);
> -			strcpy(var_val, equals + 1);
> -
> -			debug3("PAM environment: %s=%s", var_name, var_val);
> -
> -			child_set_env(env, envsize, var_name, var_val);
>  		}
> -	}
> -}
> -#endif /* USE_PAM */
> -
> -#ifdef HAVE_CYGWIN
> -void copy_environment(char ***env, u_int *envsize)
> -{
> -	char *equals, var_name[512], var_val[512];
> -	int i;
> -
> -	for(i = 0; environ[i] != NULL; i++) {
> -		if ((equals = strstr(environ[i], "=")) == NULL)
> -			continue;
> +		*var_val++ = '\0';
>  
> -		if (strlen(environ[i]) < (sizeof(var_name) - 1)) {
> -			memset(var_name, '\0', sizeof(var_name));
> -			memset(var_val, '\0', sizeof(var_val));
> -
> -			strncpy(var_name, environ[i], equals - environ[i]);
> -			strcpy(var_val, equals + 1);
> -
> -			debug3("Copy environment: %s=%s", var_name, var_val);
> -
> -			child_set_env(env, envsize, var_name, var_val);
> -		}
> +		debug3("Copy environment: %s=%s", var_name, var_val);
> +		child_set_env(env, envsize, var_name, var_val);
> +		
> +		xfree(var_name);
>  	}
>  }
> -#endif
>  
>  #if defined(HAVE_GETUSERATTR)
>  /*
> @@ -1215,7 +1181,7 @@
>  	 * The Windows environment contains some setting which are
>  	 * important for a running system. They must not be dropped.
>  	 */
> -	copy_environment(&env, &envsize);
> +	copy_environment(environ, &env, &envsize);
>  #endif
>  
>  	if (!options.use_login) {
> @@ -1299,7 +1265,7 @@
>  #endif
>  #ifdef USE_PAM
>  	/* Pull in any environment variables that may have been set by PAM. */
> -	do_pam_environment(&env, &envsize);
> +	copy_environment(fetch_pam_environment(), &env, &envsize);
>  #endif /* USE_PAM */
>  
>  	if (auth_get_socket_name() != NULL)

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com


From cce at clarkevans.com  Sun Dec 30 05:33:56 2001
From: cce at clarkevans.com (Clark C . Evans)
Date: Sat, 29 Dec 2001 13:33:56 -0500
Subject: reversing the roles of ssh and sshd
Message-ID: <20011229133356.A30874@doublegemini.com>

I have a box behind a firewall that I'd like to administer.  The
firewall allows outgoing connections, but blocks all incoming
connection requests.  Thus, behind the firewall I can ssh out
to my server, but I can't do the reverse.   I found Sebastian
Krahmer's OpenSSH Reverse [1] which looks very promising, but
it is a few revisions behind.   I was wondering if anyone has
considered integrating this with the OpenSSH code base.  It
seems like such a useful feature... 

Best,

Clark

[1] http://www.securiteam.com/tools/6I00N0K03K.html
    http://teso.scene.at/releases/openssh.reverse.tgz
    Patched OpenSSH (cl+sv) for tunneling firewalls
    (client connects to server)
 


From dan at doxpara.com  Sun Dec 30 05:31:08 2001
From: dan at doxpara.com (Dan Kaminsky)
Date: Sat, 29 Dec 2001 10:31:08 -0800
Subject: reversing the roles of ssh and sshd
References: <20011229133356.A30874@doublegemini.com>
Message-ID: <000701c19096$fbf0c900$1701000a@effugas>

Clark--

    It's much better to use remote port forwards for a job like this.
Essentially, you have the ssh client on your firewalled machine remote port
forward that machine's ssh server.  So, for example:

    firewalled$ ssh -R2022:127.0.0.1:22 dummyuser at adminsite
    adminsite$ ssh -o "HostKeyAlias firewalled" user at 127.0.0.1 -p 2022

    Of course, there's the question of how to trigger the firewalled host's
SSHing into your admin box.  Email, crontabs, on-site triggering(i.e. you
call someone and say "please go to this webpage if you want me to fix your
machine), or just leaving the link up at all times are viable options.

--Dan


----- Original Message -----
From: "Clark C . Evans" <cce at clarkevans.com>
To: <openssh-unix-dev at mindrot.org>
Cc: <krahmer at cs.uni-potsdam.de>
Sent: Saturday, December 29, 2001 10:33 AM
Subject: reversing the roles of ssh and sshd


> I have a box behind a firewall that I'd like to administer.  The
> firewall allows outgoing connections, but blocks all incoming
> connection requests.  Thus, behind the firewall I can ssh out
> to my server, but I can't do the reverse.   I found Sebastian
> Krahmer's OpenSSH Reverse [1] which looks very promising, but
> it is a few revisions behind.   I was wondering if anyone has
> considered integrating this with the OpenSSH code base.  It
> seems like such a useful feature...
>
> Best,
>
> Clark
>
> [1] http://www.securiteam.com/tools/6I00N0K03K.html
>     http://teso.scene.at/releases/openssh.reverse.tgz
>     Patched OpenSSH (cl+sv) for tunneling firewalls
>     (client connects to server)
>
>



From david-bronder at uiowa.edu  Sun Dec 30 09:31:40 2001
From: david-bronder at uiowa.edu (David Bronder)
Date: Sat, 29 Dec 2001 16:31:40 -0600 (CST)
Subject: [openssh-unix-dev] auth*.c
In-Reply-To: <20011229110002.C19143@folly> from "Markus Friedl" at Dec 29, 2001 11:00:02 AM
Message-ID: <200112292231.fBTMVed40580@fire.its.uiowa.edu>

Markus Friedl wrote:
> 
> On Fri, Dec 28, 2001 at 11:26:23AM -0600, David Bronder wrote:
> > My question to the developers is this:  Should login attempts by an
> > invalid user behave this way?  Or should the invalid user check be
> > made after a successful authentication instead of before, and then
> > cause the disconnect?  The latter seems more correct to me.
> 
> how can a non existing user authenticate successful?
> 

True.  I should have been more explicit.  You're overloading the
authctxt->valid flag to mean either the user doesn't exist or the
user does exist but isn't allowed to log in for policy reasons.

The problem is calling allowed_user(), which only occurs if the
getpwname() call was successful (i.e. the user exists).  If a user
isn't allowed to log in (as determined by allowed_user() before
any authentication method is tried), then you know in advance that
you're going to deny the session regardless of the result of any
auth methods you try.

For the case of a non-existant user, you want to hide the fact
that the user doesn't exist from the client.

For the case of a disallowed (but existing) user, you want to let
the user know they're disallowed (or so I would expect).  But you
don't want to do that until after they've authenticated, or you'll
be giving away info to username-guessers.

So I'm thinking either keep authctxt->valid overloaded, but don't
check it until after a successful authentication, if one happens
(a grossly oversimplified statement, but concept first and code
later); or split the allowed_user() call out and move it until
after successful authentication.

(This still doesn't directly help the AIX nologin issue, but one
thing at a time...)

=Dave

-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu


From news at egyptcat.com  Sun Dec 30 08:35:14 2001
From: news at egyptcat.com (EgyptCat)
Date: Sun, 30 Dec 2001 00:35:14 +0300
Subject: CIRAMICA  PRIMA
Message-ID: <00c201c190b2$26fedd60$2d724fc2@hisham>

   

      CIRAMICA PRIMA
     ???????? ??? ??????? 
     ???????? ????? 
     

     ???????? ??????? ??????????? ????????

      ???????: 49 ? ????? ???? ??? ??????

      Tel: +(202) 3043952 - 3464306

      Mob: (+202) 010 1377575

      Mob: (+202) 010 1377576

      E-mail: pprima at hotmail.com
     
     

     Distributors List
     
     



      L 203



      L 218
     


     Arch 


     

e-mailed by www.egyptcat.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011230/e171d061/attachment.html 

From djm at mindrot.org  Sun Dec 30 17:30:40 2001
From: djm at mindrot.org (Damien Miller)
Date: Sun, 30 Dec 2001 17:30:40 +1100 (EST)
Subject: New mailing list server
Message-ID: <Pine.LNX.4.33.0112301727540.1232-100000@mothra.mindrot.org>

The openssh-unix-dev at mindrot.org mailing list has just been migrated
for majordomo to mailman. You will be able to edit your subscription
information through the webpage at:

http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

To actually make changes, you will need a password. You can request
the one that has been automatically assigned to you from the page 
above.

Please report any problems to me.

-d



From djm at mindrot.org  Sun Dec 30 17:37:28 2001
From: djm at mindrot.org (Damien Miller)
Date: Sun, 30 Dec 2001 17:37:28 +1100 (EST)
Subject: test, please ignore
In-Reply-To: <Pine.LNX.4.33.0112301727540.1232-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.33.0112301736290.1232-100000@mothra.mindrot.org>

On Sun, 30 Dec 2001, Damien Miller wrote:

> The openssh-unix-dev at mindrot.org mailing list has just been migrated
> for majordomo to mailman.

That wasn't quite right.

-d



From djm at mindrot.org  Sun Dec 30 17:40:52 2001
From: djm at mindrot.org (Damien Miller)
Date: Sun, 30 Dec 2001 17:40:52 +1100 (EST)
Subject: test, please ignore
In-Reply-To: <Pine.LNX.4.33.0112301736290.1232-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.33.0112301740260.1232-100000@mothra.mindrot.org>

On Sun, 30 Dec 2001, Damien Miller wrote:

> That wasn't quite right.

Neither was that.

-d



From djm at mindrot.org  Sun Dec 30 18:09:47 2001
From: djm at mindrot.org (Damien Miller)
Date: Sun, 30 Dec 2001 18:09:47 +1100 (EST)
Subject: New mailing list manager
In-Reply-To: <Pine.LNX.4.33.0112301727540.1232-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.33.0112301732200.1232-100000@mothra.mindrot.org>

The openssh-unix-dev at mindrot.org mailing list has just been migrated
from Majordomo to Mailman[1]. Posting to the mailing list should be
unaffected.

If you wish to unsubscribe or alter the parameters of your
subscription, you may now do so at the list's webpage:

http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

To make changes you will require a password. Since majordomo didn't
keep passwords for subscribed users, your passwords have been randomly
generated and may be obtained using the above form.

If you are using procmail (or similar) to filter postings from the
list, you can match on the following header.

X-BeenThere: openssh-unix-dev at mindrot.org

Please report any problems with the mailing list to me.

-d

[1] http://www.list.org/



From djm at xenon.mel.ibs.com.au  Sun Dec 30 19:02:29 2001
From: djm at xenon.mel.ibs.com.au (Damien Miller)
Date: Sun, 30 Dec 2001 19:02:29 +1100
Subject: Testing
Message-ID: <200112300802.fBU82Th30507@xenon.mel.ibs.com.au>

test, please ignore


From markus at openbsd.org  Sun Dec 30 21:56:03 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 30 Dec 2001 11:56:03 +0100
Subject: reversing the roles of ssh and sshd
In-Reply-To: <20011229133356.A30874@doublegemini.com>; from cce@clarkevans.com on Sat, Dec 29, 2001 at 01:33:56PM -0500
References: <20011229133356.A30874@doublegemini.com>
Message-ID: <20011230115603.B3461@folly>

On Sat, Dec 29, 2001 at 01:33:56PM -0500, Clark C . Evans wrote:
> I have a box behind a firewall that I'd like to administer.  The
> firewall allows outgoing connections, but blocks all incoming
> connection requests.  Thus, behind the firewall I can ssh out
> to my server, but I can't do the reverse.   I found Sebastian
> Krahmer's OpenSSH Reverse [1] which looks very promising, but
> it is a few revisions behind.   I was wondering if anyone has
> considered integrating this with the OpenSSH code base.  It
> seems like such a useful feature... 

i think you could use this instead:

http://teso.scene.at/releases/reverb-0.1.0.tar.gz


From bbense at networking.stanford.edu  Mon Dec 31 12:01:38 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Sun, 30 Dec 2001 17:01:38 -0800 (PST)
Subject: Killing the builtin entropy code
In-Reply-To: <Pine.LNX.4.33.0112240125040.1235-100000@mothra.mindrot.org>
Message-ID: <Pine.GSO.4.43.0112301644080.8310-100000@shred.stanford.edu>

On Mon, 24 Dec 2001, Damien Miller wrote:

> On Fri, 21 Dec 2001, Damien Miller wrote:
>
> > Over the holidays, I intend to finally rid portable OpenSSH of the
> > builtin entropy collection code. Here's what I intend to do:
>
> Have done :)
>
> I have just committed a patch which splits out the entropy gathering
> into a seperate process "ssh-rand-helper". As a result, there are
> nearly 1k fewer lines of hairy code in ssh and sshd :)
>
> There is an example ssh-rand-helper which, suspiciously enough, looks
> exactly like the old in-process entropy gatherer. At the moment it is
> not very pretty (though no worse than the old code), but it is time to
> stop for this evening.
>
> Hopefully someone else will step up to the plate and write or port
> a proper Yarrow PRNG.
>

- I have made a start using the Yarrow library provided at

http://opensource.zeroknowledge.com/yarrow/

This was the only unix Yarrow implementation I could find,
it seems pretty "beta" at best. It still has the problem
of figuring out good entrophy estimators. Once the code
compiles I'll hand it out, but I'm not sure it will actually
be any improvement.

- Booker C. Bense