From eggert at twinsun.com  Mon Oct  1 00:59:14 2001
From: eggert at twinsun.com (Paul Eggert)
Date: Sun, 30 Sep 2001 07:59:14 -0700 (PDT)
Subject: openssh-2.9.9p2 assumes pid_t, uid_t, etc. are not 'long'
In-Reply-To: <Pine.LNX.4.21.0109291252120.12012-100000@life.blorf.net>
	(wayned@users.sourceforge.net)
References: <Pine.LNX.4.21.0109291252120.12012-100000@life.blorf.net>
Message-ID: <200109301459.f8UExEt27040@sic.twinsun.com>

> Date: Sat, 29 Sep 2001 13:06:35 -0700 (PDT)
> From: Wayne Davison <wayned at users.sourceforge.net>
> 
> I submitted a patch for this back on April 4th and it has yet to be
> applied.  At the time I heard an objection that these types are
> required to be "int" by POSIX, but from everything I can see, that is
> not the case.

You are correct.  The current version of POSIX merely requires that
they are no wider than "long".

And the next version of POSIX will even allow them to be wider than
"long": they can be as wide as "intmax_t", which (in theory, anyway)
can be even wider than "long long".  I can cite chapter and verse
from the latest draft, if you like.

I don't think OpenSSH needs to worry about them being wider than
"long", though.  The only system types that I have found wider than
"long" in practice are the file-size-related types (notably off_t).
And I realize that it's a pain to print integers wider than "long" in
code that is portable to older hosts.


From lhecking at nmrc.ie  Mon Oct  1 08:54:57 2001
From: lhecking at nmrc.ie (Lars Hecking)
Date: Sun, 30 Sep 2001 23:54:57 +0100
Subject: scp 2.9.9p2 doesn't work
In-Reply-To: <3BB618C7.6060601@cheers.bungi.com>
References: <20010929163907.A11804@nmrc.ie> <3BB618C7.6060601@cheers.bungi.com>
Message-ID: <20010930235457.A13714@nmrc.ie>

Greg writes:
> On 09/29/01 08:39 AM, Lars Hecking wrote:
> 
> > I just upgraded openssh on my Solaris 8 boxes from 2.9p2 to 2.9.9p2,
> > and scp has stopped working. Remote logins with ssh do work, though.
> > Both client and server run 2.9.9p2.
> 
> 
> See the "2.9.9p2 bug in PAM support" thread started on 9/28.  Configure 
> without PAM or try the one line change suggested by Brent Nelson.

 Thanks, Greg, I'll check it out tomorrow.

 On a related note, how does one configure ssh support in Solaris' pam?



From jesus at omniti.com  Mon Oct  1 13:23:43 2001
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sun, 30 Sep 2001 23:23:43 -0400
Subject: SecurID support in 2.9.9
In-Reply-To: <CBF8277AF9311944B369F11236F3FAA16C52AA@S102.rhcci.com>
Message-ID: <B7702BE6-B61B-11D5-B98A-0003930FCDF8@omniti.com>

On Thursday, September 27, 2001, at 04:44  PM, Dmitri Smirnov wrote:
> is anybody know what is happened with RSA SecurID support in 2.9.9? It 
> was a
> part of 2.9 (auth-securid.c) but not in 2.9.9 anymore.

There was a SecurID.diff in some older openssh releases.  It is not 
supported by the openssh team.  It was in contrib.  I am the 
maintainer.  I have been unable to keep up with the openssh 
development -- that is great in my opinion, it means forward progress!  
I can only assume that this is why the SecurID.diff has been removed 
from contrib -- I have no objections there.

Perhaps a SecurID.README could be added stating that the patches are not 
part of the main distribution and are supported maintained elsewhere and 
give the below URL.  That might be helpful to people -- then they can 
complain to me about outdated version.  I am usually pretty responsive.

The SecurID support patches are made available (as they have been) on my 
projects page:

http://www.omniti.com/~jesus/projects/

The patch against the latest release may follow a few days after its 
release.

2.9.9p2 patch is there now :-)  Enjoy.

--
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 Jewnix at technohac.com  Mon Oct  1 05:29:18 2001
From: Jewnix at technohac.com (Gil Disatnik)
Date: Sun, 30 Sep 2001 21:29:18 +0200
Subject: Logging out OpenSSH while there is a running job on the
  background
Message-ID: <5.1.0.14.2.20010930212416.02478370@pop3.norton.antivirus>

Hello there.
Sorry for bothering you regarding this, but I am really looking for a 
solution to this problem, maybe you saw it in the SSH mailing list... but 
just in case...
I remember you tried helping me once... If you could at least tell me who 
should ask regarding this issue, that would be quite a nice start...

The problem:
I have noticed that when I am forking something to the background and 
trying to logout - nothing happens, when I run SSH with some verbosity, the 
last debug information is:
client_input_channel_req: channel 0 rtype exit-status reply 0

What can I do about it?
Thanks.

P.S - I've encountered the problem on the following platforms (All running 
2.9p1):
AIX 4.1.5
AIX 4.3.3
AIX 5L
Solaris 2.5.1
Solaris 8
Linux (Various kernels (2.2.17-2.2.19, 2.4.0-2.4.10))

I have also seen it on version 2.9.9p2 running on linux


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/20010930/d84ff2f1/attachment.html 

From Nicolas.Williams at ubsw.com  Mon Oct  1 23:44:14 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 1 Oct 2001 09:44:14 -0400
Subject: 2.9.9p2 bug in PAM support
In-Reply-To: <3BB50E7C.2B75643A@bartlett.house>; from abartlet@pcug.org.au on Sat, Sep 29, 2001 at 09:57:48AM +1000
References: <Pine.LNX.4.33.0109281538180.19444-100000@bani.phys.ufl.edu> <3BB50E7C.2B75643A@bartlett.house>
Message-ID: <20011001094412.G5739@sm2p1386swk.wdr.com>

Perhaps OpenSSH should use a different PAM_SERVICE name for non-tty
sessions so its PAM stack could be configured differently than for tty
sessions.

This may not be possible, if OpenSSH's sshd doesn't know what kind of
session to run when it calls pam_start(). Is this so?

Alternatively, using 'ssh' as the PAM_TTY might do, but then, should
pam_close_session() be called right away after pam_open_session()?

Nico


On Sat, Sep 29, 2001 at 09:57:48AM +1000, Andrew Bartlett wrote:
> There are a number of bugs in some PAM modules (pam_time.so notably)
> where they really object when you don't give them a TTY.  This define
> just makes OpenSSH give 'ssh' as the tty.
> 
> (The OpenSSH team are really in a bind here, as they have one group of
> people - like me - who want those session modules used, and another
> group for whome it locks them out.  As you noted the previous version
> changed in your favor, but it was changed back on complaints from other
> users and a 'discussion' on BugTraq).
> 
> Hope this helps, 
> 
> Andrew Bartlett
> 
> -- 
--
-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 abartlet at pcug.org.au  Tue Oct  2 00:04:42 2001
From: abartlet at pcug.org.au (Andrew Bartlett)
Date: Tue, 02 Oct 2001 00:04:42 +1000
Subject: 2.9.9p2 bug in PAM support
References: <Pine.LNX.4.33.0109281538180.19444-100000@bani.phys.ufl.edu> <3BB50E7C.2B75643A@bartlett.house> <20011001094412.G5739@sm2p1386swk.wdr.com>
Message-ID: <3BB877FA.FC387E14@bartlett.house>

Nicolas Williams wrote:
> 
> Perhaps OpenSSH should use a different PAM_SERVICE name for non-tty
> sessions so its PAM stack could be configured differently than for tty
> sessions.
> 
> This may not be possible, if OpenSSH's sshd doesn't know what kind of
> session to run when it calls pam_start(). Is this so?

Indeed, this is unknown that the time pam_start() is called.
 
> Alternatively, using 'ssh' as the PAM_TTY might do, but then, should
> pam_close_session() be called right away after pam_open_session()?

Why?

> Nico
> 
> On Sat, Sep 29, 2001 at 09:57:48AM +1000, Andrew Bartlett wrote:
> > There are a number of bugs in some PAM modules (pam_time.so notably)
> > where they really object when you don't give them a TTY.  This define
> > just makes OpenSSH give 'ssh' as the tty.
> >
> > (The OpenSSH team are really in a bind here, as they have one group of
> > people - like me - who want those session modules used, and another
> > group for whome it locks them out.  As you noted the previous version
> > changed in your favor, but it was changed back on complaints from other
> > users and a 'discussion' on BugTraq).
> >
> > Hope this helps,
> >
> > Andrew Bartlett
> >
> > --
> --
> -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.

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Samba Team member, Build Farm maintainer        abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net


From Nicolas.Williams at ubsw.com  Tue Oct  2 00:23:11 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 1 Oct 2001 10:23:11 -0400
Subject: 2.9.9p2 bug in PAM support
In-Reply-To: <3BB877FA.FC387E14@bartlett.house>; from Andrew Bartlett on Tue, Oct 02, 2001 at 12:04:42AM +1000
References: <Pine.LNX.4.33.0109281538180.19444-100000@bani.phys.ufl.edu> <3BB50E7C.2B75643A@bartlett.house> <20011001094412.G5739@sm2p1386swk.wdr.com> <3BB877FA.FC387E14@bartlett.house>
Message-ID: <20011001102311.I26615@wdr.com>

On Tue, Oct 02, 2001 at 12:04:42AM +1000, Andrew Bartlett wrote:
> Nicolas Williams wrote:
> > 
> > Perhaps OpenSSH should use a different PAM_SERVICE name for non-tty
> > sessions so its PAM stack could be configured differently than for tty
> > sessions.
> > 
> > This may not be possible, if OpenSSH's sshd doesn't know what kind of
> > session to run when it calls pam_start(). Is this so?
> 
> Indeed, this is unknown that the time pam_start() is called.

That's too bad.

> > Alternatively, using 'ssh' as the PAM_TTY might do, but then, should
> > pam_close_session() be called right away after pam_open_session()?
> 
> Why?

I'm thinking of things like UTMP, where ttys are expected to be accessed
in exclusive manner. Perhaps some PAM modules expect the same.

Alternatively, cons up a fake TTY name, like ssh-<session id>...

> -- 
> Andrew Bartlett                                 abartlet at pcug.org.au
> Samba Team member, Build Farm maintainer        abartlet at samba.org
> Student Network Administrator, Hawker College   abartlet at hawkerc.net
> http://samba.org     http://build.samba.org     http://hawkerc.net


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 roth at feep.net  Tue Oct  2 00:45:58 2001
From: roth at feep.net (Mark D. Roth)
Date: Mon, 1 Oct 2001 09:45:58 -0500
Subject: 2.9.9p2 bug in PAM support
In-Reply-To: <3BB50E7C.2B75643A@bartlett.house>; from abartlet@pcug.org.au on Sat, Sep 29, 2001 at 09:57:48AM +1000
References: <Pine.LNX.4.33.0109281538180.19444-100000@bani.phys.ufl.edu> <3BB50E7C.2B75643A@bartlett.house>
Message-ID: <20011001094558.A25016@yorktown.isdn.uiuc.edu>

On Sat Sep 29 09:57 2001 +1000, Andrew Bartlett wrote:
> Brent A Nelson wrote:
> > With OpenSSH 2.9.9p2 as the server, I'm not able to do scp or "ssh
> > machinename command"  in general to any of my Suns!
> > 
> > I tracked this down a bit; the problem occurs only when PAM support is
> > enabled.  However, if I remove line 430 of session.c,
> > "do_pam_session(s->pw->pw_name, NULL);" inside of do_exec_no_pty, the
> > problem goes away.
> > 
> > It looks like the following entry in the Changelog may be responsible:
> > 
> >         20010627
> >          - (djm) Reintroduce pam_session call for non-pty sessions.
> > 
> > Let me know if you need any additional info to track this down.
> 
> What happens if you define PAM_TTY_KLUDGE and recompile?

FWIW, this does fix the problem.  Sounds to me like this should be
enabled by default on all PAM systems.

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


From strube at physik3.gwdg.de  Tue Oct  2 01:08:53 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Mon, 1 Oct 2001 17:08:53 +0200 (MET DST)
Subject: openssh-2.9p2, short hostnames
Message-ID: <200110011508.RAA20527@marc.physik3.gwdg.de>

> For systems where the local hostname is obtained as a short name without
> domain, there should be a ssh_config option "DefaultDomain" as in ssh-3.x
> from ssh.com.
Below there is a patch which implements this. But it does not abort (as
ssh-3.x does) if the host name is not FQDN, since within the local net
there is no need for this. By making the config entry conditional for names
with dots, a short "chost" name can be used within the local net and the
FQDN otherwise:
Host *.*
   DefaultDomain my.local.net
Host *
#  no DefaultDomain

> For the server, there might be a corresponding option in order to strip
> the domain name from the remote client name (if it matches the server's
> DefaultDomain) for use in auth_rhost2, since netgroups usually contain
> short names in this case.
If the resolvedname in auth2.c is short, this is not necessary if either a
short chost is used by the client (with the trailing dot stripped in auth2.c,
see thread "openssh-2.9.p2, auth2.c") or if HostbasedUsesNameFromPacketOnly
is *not* used in the server.

Patch (the line numbers are for 2.9.9p2):
*** readconf.c.ORI	Thu Sep 20 02:57:56 2001
--- readconf.c	Mon Oct  1 15:17:47 2001
***************
*** 116,121 ****
--- 116,122 ----
  	oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication,
  	oHostKeyAlgorithms, oBindAddress, oSmartcardDevice,
  	oClearAllForwardings
+ 	,oDefaultDomain
  } OpCodes;
  
  /* Textual representations of the tokens. */
***************
*** 186,191 ****
--- 187,193 ----
  	{ "bindaddress", oBindAddress },
  	{ "smartcarddevice", oSmartcardDevice },
  	{ "clearallforwardings", oClearAllForwardings }, 
+ 	{ "defaultdomain", oDefaultDomain }, 
  	{ NULL, 0 }
  };
  
***************
*** 488,493 ****
--- 490,499 ----
  		charptr = &options->smartcard_device;
  		goto parse_string;
  
+ 	case oDefaultDomain:
+ 		charptr = &options->default_domain;
+ 		goto parse_string;
+ 
  	case oProxyCommand:
  		charptr = &options->proxy_command;
  		string = xstrdup("");
***************
*** 793,798 ****
--- 799,805 ----
  	options->preferred_authentications = NULL;
  	options->bind_address = NULL;
  	options->smartcard_device = NULL;
+ 	options->default_domain = NULL;
  }
  
  /*
*** readconf.h.ORI	Thu Sep 20 02:57:56 2001
--- readconf.h	Mon Oct  1 15:18:28 2001
***************
*** 101,106 ****
--- 101,107 ----
  	int     num_remote_forwards;
  	Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION];
  	int	clear_forwardings;
+ 	char	*default_domain;
  }       Options;
  
  
*** sshconnect2.c.ORI	Wed Sep 12 20:29:01 2001
--- sshconnect2.c	Mon Oct  1 15:37:02 2001
***************
*** 842,850 ****
--- 842,859 ----
  		return 0;
  	}
  	len = strlen(p) + 2;
+ 	i = 0;
+ 	if (!strchr(p, '.') && options.default_domain) {
+ 		i = 1;
+ 		len += strlen(options.default_domain) + 1;
+ 	}
  	chost = xmalloc(len);
  	strlcpy(chost, p, len);
  	strlcat(chost, ".", len);
+ 	if(i > 0) {
+ 		strlcat(chost, options.default_domain, len);
+ 		strlcat(chost, ".", len);
+ 	}
  	debug2("userauth_hostbased: chost %s", chost);
  	/* check for a useful key */
  	for (i = 0; i < authctxt->nkeys; i++) {


From markus at openbsd.org  Tue Oct  2 01:26:58 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 1 Oct 2001 17:26:58 +0200
Subject: SecurID.diff file missing in new openssh version
In-Reply-To: <"041713BB8880601F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Quick/g=Edward/i=T/"@MHS>; from Edward.T.Quick@BritishAirways.com on Mon, Oct 01, 2001 at 03:13:10PM +0000
References: <"041713BB8880601F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Quick/g=Edward/i=T/"@MHS>
Message-ID: <20011001172658.A22788@faui02.informatik.uni-erlangen.de>

currently we don't support secure id.


On Mon, Oct 01, 2001 at 03:13:10PM +0000, Quick, Edward T wrote:
> Hi,
> 
> I'm not sure if this is just the ftp site I downloaded from or not, but the SecurID.diff file (that goes under the contrib directory) on the new openssh2.9.9p2 distribution seems to be missing.
> 
> Regards,
> 
> Edward.


From mouring at etoh.eviladmin.org  Tue Oct  2 03:18:02 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 1 Oct 2001 12:18:02 -0500 (CDT)
Subject: SecurID.diff file missing in new openssh version
In-Reply-To: <20011001172658.A22788@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.BSO.4.33.0110011217390.4116-100000@etoh.eviladmin.org>


http://www.omniti.com/~jesus/SecurID/

Is the location for all secure patches.  Please refer there for all
inquires.

- Ben

On Mon, 1 Oct 2001, Markus Friedl wrote:

> currently we don't support secure id.
>
>
> On Mon, Oct 01, 2001 at 03:13:10PM +0000, Quick, Edward T wrote:
> > Hi,
> >
> > I'm not sure if this is just the ftp site I downloaded from or not, but the SecurID.diff file (that goes under the contrib directory) on the new openssh2.9.9p2 distribution seems to be missing.
> >
> > Regards,
> >
> > Edward.
>



From tim at multitalents.net  Tue Oct  2 06:41:42 2001
From: tim at multitalents.net (Tim Rice)
Date: Mon, 1 Oct 2001 13:41:42 -0700 (PDT)
Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX
In-Reply-To: <200109281746.f8SHkGm04399@shade.twinsun.com>
Message-ID: <Pine.UW2.4.40.0110011241020.10640-100000@uw711.int.multitalents.net>

On Fri, 28 Sep 2001, Paul Eggert wrote:

> > From: Gert Doering <gert at greenie.muc.de>
> > Date: Fri, 28 Sep 2001 11:41:40 +0200
> >
> > > my theory is that you'll get an error message instead.
> > So it is.
>
> In that case, here is an (untested) patch to a recent Autoconf
> snapshot that should fix the problem.

I couldn't find where to get snapshots so I tried applying it to
autoconf-2.52. makeinfo chokes on the doc/autoconf.texi portion.
I couldn't find a status.m4 anywhere but after poking around
I found the section in acgeneral.m4 that I could manually apply the
patch too.

"make check" on SCO Open Server 3 still fails bigtime.
But using the patched version of 2.52 on my UnixWare machine produces
an openssh configure script that DOES work on SCO Open Server 3.


>
> 2001-09-28  Paul Eggert  <eggert at twinsun.com>
>
[patch snipped]
>
-----------------------------------------
--- acgeneral.m4.old	Wed Jul  4 08:05:43 2001
+++ acgeneral.m4	Fri Sep 28 12:54:03 2001
@@ -4145,7 +4145,7 @@
 s,[\\$`],\\&,g
 t clear
 : clear
-s,^[ 	]*#[ 	]*define[ 	][ 	]*\(\([^ 	(][^ 	(]*\)([^)]*)\)[ 	]*\(.*\)$,${ac_dA}\2${ac_dB}\1${ac_dC}\3${ac_dD},gp
+s,^[ 	]*#[ 	]*define[ 	][ 	]*\([^ 	(][^ 	(]*\)\(([^)]*)\)[ 	]*\(.*\)$,${ac_dA}\1${ac_dB}\1\2${ac_dC}\3${ac_dD},gp
 t end
 s,^[ 	]*#[ 	]*define[ 	][ 	]*\([^ 	][^ 	]*\)[ 	]*\(.*\)$,${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD},gp
 : end]
-----------------------------------------

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From pekkas at netcore.fi  Tue Oct  2 15:35:02 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 2 Oct 2001 08:35:02 +0300 (EEST)
Subject: openssh-2.9p2, short hostnames
In-Reply-To: <200110011508.RAA20527@marc.physik3.gwdg.de>
Message-ID: <Pine.LNX.4.33.0110020833560.8225-100000@netcore.fi>

On Mon, 1 Oct 2001, Hans Werner Strube wrote:
> > For systems where the local hostname is obtained as a short name without
> > domain, there should be a ssh_config option "DefaultDomain" as in ssh-3.x
> > from ssh.com.
> Below there is a patch which implements this. But it does not abort (as
> ssh-3.x does) if the host name is not FQDN, since within the local net
> there is no need for this. By making the config entry conditional for names
> with dots, a short "chost" name can be used within the local net and the
> FQDN otherwise:
> Host *.*
>    DefaultDomain my.local.net
> Host *
> #  no DefaultDomain

I don't think it is a good idea to hack _ssh_ to support this.  Why don't
you use FQDN's as hostnames like most of the other people?

-- 
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 strube at physik3.gwdg.de  Tue Oct  2 17:32:18 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Tue, 2 Oct 2001 09:32:18 +0200 (MET DST)
Subject: openssh-2.9p2, short hostnames
Message-ID: <200110020732.JAA21024@marc.physik3.gwdg.de>

>
> > > For systems where the local hostname is obtained as a short name without
> > > domain, there should be a ssh_config option "DefaultDomain" as in ssh-3.x
> > > from ssh.com.
> > Below there is a patch which implements this. But it does not abort (as
> > ssh-3.x does) if the host name is not FQDN, since within the local net
> > there is no need for this. By making the config entry conditional for names
> > with dots, a short "chost" name can be used within the local net and the
> > FQDN otherwise:
> > Host *.*
> >    DefaultDomain my.local.net
> > Host *
> > #  no DefaultDomain
> 
> I don't think it is a good idea to hack _ssh_ to support this.  Why don't
> you use FQDN's as hostnames like most of the other people?

For instance, because FQDNs blow up the netgroup entries. Then large
netgroups would be difficult to treat with NIS, since the NIS ndbm records
are limited to 1024 bytes. This is a historical burden of Solaris. Also it
is usually much more convenient to work with short names *within* a local
network. (Well, I know, in principle you are right, and some PD programs
have difficulties constructing the FQDN then ...)



From phdm at macqel.be  Tue Oct  2 19:55:36 2001
From: phdm at macqel.be (Philippe De Muyter)
Date: Tue, 2 Oct 2001 11:55:36 +0200 (CEST)
Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX
In-Reply-To: <200109281746.f8SHkGm04399@shade.twinsun.com> from Paul Eggert at
 "Sep 28, 2001 10:46:16 am"
Message-ID: <200110020955.f929tbO09694@mail.macqel.be>

> 2001-09-28  Paul Eggert  <eggert at twinsun.com>
> 
> 	* doc/autoconf.texi (Limitations of Usual Tools):
> 	Document that some older sed implementations can't handle
> 	nested parenthesization.
> 
> 	* lib/autoconf/status.m4 (AC_OUTPUT_MAKE_DEFS):
> 	Don't use nested parenthesization.  This patch was originally
> 	suggested to bug-autoconf by Philippe De Muyter on 2000-05-28,
> 	but somehow it didn't get incorporated then.

Glad to see it didn't get lost.  "Mieux vaut tard que jamais" (French for :
rather late than never.) :)

Philippe

Philippe De Muyter  phdm at macqel.be  Tel +32 27029044
Macq Electronique SA  rue de l'Aeronef 2  B-1140 Bruxelles  Fax +32 27029077


From serge.droz at psi.ch  Tue Oct  2 20:47:45 2001
From: serge.droz at psi.ch (Serge Droz)
Date: Tue, 02 Oct 2001 12:47:45 +0200
Subject: AFS and tokenforwarding
Message-ID: <3BB99B51.6A0E8EB9@psi.ch>

For some reasons the afs tokenforwarding stuff has changed
siginificantly from v 2.9p2 to 2.9.9p2. 
This makes it impossible to use public key authenticication in a
standart AFS environment. 
I don't know the reasons for these changes. 

In any case attached is a patch which restores the old behaviour.

Regards
Serge


-- 
Serge Droz
Paul Scherrer Institut                mailto:serge.droz at psi.ch
CH-5232 Villigen PSI                   Phone: ++41 56 310 3637
                                         Fax: ++41 56 310 3649
-------------- next part --------------
--- openssh-2.9.9p2.orig/sshconnect1.c	Sat Jul 14 04:17:00 2001
+++ openssh-2.9.9p2/sshconnect1.c	Thu Sep 27 09:58:37 2001
@@ -1111,13 +1111,14 @@
 ssh_userauth1(const char *local_user, const char *server_user, char *host,
     Key **keys, int nkeys)
 {
+	
 #ifdef KRB5
 	krb5_context context = NULL;
 	krb5_auth_context auth_context = NULL;
 #endif
 	int i, type;
 	int payload_len;
-	
+
 	if (supported_authentications == 0)
 		fatal("ssh_userauth1: server supports no auth methods");
 
@@ -1139,6 +1140,23 @@
 		goto success;
 	if (type != SSH_SMSG_FAILURE)
 		packet_disconnect("Protocol error: got %d in response to SSH_CMSG_USER", type);
+#ifdef AFS
+	/* 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)) &&
@@ -1202,6 +1220,7 @@
 				goto success;
 		}
 	}
+
 	/* Try RSA authentication if the server supports it. */
 	if ((supported_authentications & (1 << SSH_AUTH_RSA)) &&
 	    options.rsa_authentication) {
@@ -1226,6 +1245,7 @@
 		if (try_challenge_response_authentication())
 			goto success;
 	}
+
 	/* Try password authentication if the server supports it. */
 	if ((supported_authentications & (1 << SSH_AUTH_PASSWORD)) &&
 	    options.password_authentication && !options.batch_mode) {
@@ -1255,22 +1275,6 @@
 		krb5_free_context(context);
 #endif
 	
-#ifdef AFS
-	/* 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 */
 
 	return;	/* need statement after label */
 }
--- openssh-2.9.9p2.orig/auth1.c	Wed Jul  4 06:21:16 2001
+++ openssh-2.9.9p2/auth1.c	Fri Sep 28 08:53:35 2001
@@ -118,6 +118,22 @@
 		/* Process the packet. */
 		switch (type) {
 
+#ifdef AFS
+		case SSH_CMSG_HAVE_AFS_TOKEN:
+			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);
+				xfree(token_string);
+			}
+			//continue;
+#endif /* AFS */
+
 #if defined(KRB4) || defined(KRB5)
 		case SSH_CMSG_AUTH_KERBEROS:
 			if (!options.kerberos_authentication) {
@@ -169,9 +185,9 @@
 			packet_send_debug("Kerberos TGT passing disabled before authentication.");
 			break;
 #ifdef AFS
-		case SSH_CMSG_HAVE_AFS_TOKEN:
-			packet_send_debug("AFS token passing disabled before authentication.");
-			break;
+//		case SSH_CMSG_HAVE_AFS_TOKEN:
+//			packet_send_debug("AFS token passing disabled before authentication.");
+//			break;
 #endif /* AFS */
 #endif /* AFS || KRB5 */
 			
@@ -440,4 +456,5 @@
 
 	/* Perform session preparation. */
 	do_authenticated(authctxt);
+	
 }

From kr at roqe.org  Tue Oct  2 21:28:16 2001
From: kr at roqe.org (Konrad Rieck)
Date: Tue, 2 Oct 2001 13:28:16 +0200
Subject: Probably broken getaddrinfo() on Solaris x86. 
Message-ID: <20011002132816.A21725@roqe.org>


Hi,

I discovered a strange problem with the latest version (2.9.9p2) and previous
versions of OpenSSH when using portforwarding und Solaris 8 x86. 

It seems like the getaddrinfo() function on Solaris 8 x86 is somehow broken,
instead of binding a port to 127.0.0.1, OpenSSH tried to bind it to
1.0.0.127 (1.0.0.127 was the ai->ai_addr returned by getaddrinfo() in
channel.c). 

I could not reproduce this on Solaris 8 Sparc and I assume that Sun
developers mixed endianess on the x86 platform. 

I could fix the problem by marking the getaddrinfo() function as broken 
on Solaris 8 x86 (#define BROKEN_GETADDRINFO 1).

Maybe someone of you could recheck this problem and try to find a better
fix for it. 

Regards,
Konrad

-- 
Konrad Rieck <kr at roqe.org>                    
Roqefellaz - http://www.roqe.org, Public Key http://www.roqe.org/keys/kr.pub
--           Fingerprint: 5803 E58E D1BF 9A29 AFCA  51B3 A725 EA18 ABA7 A6A3


From openssh-unix-dev at thewrittenword.com  Wed Oct  3 01:35:52 2001
From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com)
Date: Tue, 2 Oct 2001 10:35:52 -0500
Subject: Probably broken getaddrinfo() on Solaris x86.
In-Reply-To: <20011002132816.A21725@roqe.org>; from kr@roqe.org on Tue, Oct 02, 2001 at 01:28:16PM +0200
References: <20011002132816.A21725@roqe.org>
Message-ID: <20011002103552.A81925@oolong.il.thewrittenword.com>

On Tue, Oct 02, 2001 at 01:28:16PM +0200, Konrad Rieck wrote:
> I discovered a strange problem with the latest version (2.9.9p2) and previous
> versions of OpenSSH when using portforwarding und Solaris 8 x86. 
> 
> It seems like the getaddrinfo() function on Solaris 8 x86 is somehow broken,
> instead of binding a port to 127.0.0.1, OpenSSH tried to bind it to
> 1.0.0.127 (1.0.0.127 was the ai->ai_addr returned by getaddrinfo() in
> channel.c). 
> 
> I could not reproduce this on Solaris 8 Sparc and I assume that Sun
> developers mixed endianess on the x86 platform. 
> 
> I could fix the problem by marking the getaddrinfo() function as broken 
> on Solaris 8 x86 (#define BROKEN_GETADDRINFO 1).
> 
> Maybe someone of you could recheck this problem and try to find a better
> fix for it. 

I just checked sunsolve.sun.com and I think patch id 111328-01 fixes
this problem. I don't have a Sol 8/Intel machine to test.

-- 
albert chin (china at thewrittenword.com)


From openssh-unix-dev at thewrittenword.com  Wed Oct  3 01:37:47 2001
From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com)
Date: Tue, 2 Oct 2001 10:37:47 -0500
Subject: openssh-2.9p2, short hostnames
In-Reply-To: <200110020732.JAA21024@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Tue, Oct 02, 2001 at 09:32:18AM +0200
References: <200110020732.JAA21024@marc.physik3.gwdg.de>
Message-ID: <20011002103747.B81925@oolong.il.thewrittenword.com>

On Tue, Oct 02, 2001 at 09:32:18AM +0200, Hans Werner Strube wrote:
> >
> > > > For systems where the local hostname is obtained as a short name without
> > > > domain, there should be a ssh_config option "DefaultDomain" as in ssh-3.x
> > > > from ssh.com.
> > > Below there is a patch which implements this. But it does not abort (as
> > > ssh-3.x does) if the host name is not FQDN, since within the local net
> > > there is no need for this. By making the config entry conditional for names
> > > with dots, a short "chost" name can be used within the local net and the
> > > FQDN otherwise:
> > > Host *.*
> > >    DefaultDomain my.local.net
> > > Host *
> > > #  no DefaultDomain
> > 
> > I don't think it is a good idea to hack _ssh_ to support this.  Why don't
> > you use FQDN's as hostnames like most of the other people?
> 
> For instance, because FQDNs blow up the netgroup entries. Then large
> netgroups would be difficult to treat with NIS, since the NIS ndbm records
> are limited to 1024 bytes. This is a historical burden of Solaris. Also it
> is usually much more convenient to work with short names *within* a local
> network. (Well, I know, in principle you are right, and some PD programs
> have difficulties constructing the FQDN then ...)

While the length of a key's value is 1024 bytes, you can break the
value so it references other *keys* and therefore work around this
limitation. If you generate the NDBM maps directly from text files
though, your kinda screwed unless you somehow automate this process.

-- 
albert chin (china at thewrittenword.com)


From Nicolas.Williams at ubsw.com  Wed Oct  3 02:07:02 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 2 Oct 2001 12:07:02 -0400
Subject: openssh-2.9p2, short hostnames
In-Reply-To: <20011002103747.B81925@oolong.il.thewrittenword.com>; from openssh-unix-dev@thewrittenword.com on Tue, Oct 02, 2001 at 10:37:47AM -0500
References: <200110020732.JAA21024@marc.physik3.gwdg.de> <20011002103747.B81925@oolong.il.thewrittenword.com>
Message-ID: <20011002120701.H5739@sm2p1386swk.wdr.com>

On Tue, Oct 02, 2001 at 10:37:47AM -0500, openssh-unix-dev at thewrittenword.com wrote:
> On Tue, Oct 02, 2001 at 09:32:18AM +0200, Hans Werner Strube wrote:
> > >
> > > > > For systems where the local hostname is obtained as a short name without
> > > > > domain, there should be a ssh_config option "DefaultDomain" as in ssh-3.x
> > > > > from ssh.com.
> > > > Below there is a patch which implements this. But it does not abort (as
> > > > ssh-3.x does) if the host name is not FQDN, since within the local net
> > > > there is no need for this. By making the config entry conditional for names
> > > > with dots, a short "chost" name can be used within the local net and the
> > > > FQDN otherwise:
> > > > Host *.*
> > > >    DefaultDomain my.local.net
> > > > Host *
> > > > #  no DefaultDomain
> > > 
> > > I don't think it is a good idea to hack _ssh_ to support this.  Why don't
> > > you use FQDN's as hostnames like most of the other people?
> > 
> > For instance, because FQDNs blow up the netgroup entries. Then large
> > netgroups would be difficult to treat with NIS, since the NIS ndbm records
> > are limited to 1024 bytes. This is a historical burden of Solaris. Also it
> > is usually much more convenient to work with short names *within* a local
> > network. (Well, I know, in principle you are right, and some PD programs
> > have difficulties constructing the FQDN then ...)
> 
> While the length of a key's value is 1024 bytes, you can break the
> value so it references other *keys* and therefore work around this
> limitation. If you generate the NDBM maps directly from text files
> though, your kinda screwed unless you somehow automate this process.

The reverse maps are the ones used by innetgr() on Solaris. The reverse
maps' keys are named after users and hosts, and the values are
comma-separated lists of netgroups the users/hosts belong to.

There's no way to break those up.

> -- 
> albert chin (china at thewrittenword.com)


Nico
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



From strube at physik3.gwdg.de  Wed Oct  3 02:16:07 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Tue, 2 Oct 2001 18:16:07 +0200 (MET DST)
Subject: openssh-2.9p2, short hostnames
Message-ID: <200110021616.SAA22786@marc.physik3.gwdg.de>

> > While the length of a key's value is 1024 bytes, you can break the
> > value so it references other *keys* and therefore work around this
> > limitation. If you generate the NDBM maps directly from text files
> > though, your kinda screwed unless you somehow automate this process.

I have already applied this technique before (even for too many short
host names) but would like to avoid it if possible.

> The reverse maps are the ones used by innetgr() on Solaris. The reverse
> maps' keys are named after users and hosts, and the values are
> comma-separated lists of netgroups the users/hosts belong to.
> 
> There's no way to break those up.

But there is no need to break those up, since those records are quite short.


From Nicolas.Williams at ubsw.com  Wed Oct  3 02:20:24 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 2 Oct 2001 12:20:24 -0400
Subject: openssh-2.9p2, short hostnames
In-Reply-To: <200110021616.SAA22786@marc.physik3.gwdg.de>; from Hans Werner Strube on Tue, Oct 02, 2001 at 06:16:07PM +0200
References: <200110021616.SAA22786@marc.physik3.gwdg.de>
Message-ID: <20011002122024.T26615@wdr.com>

On Tue, Oct 02, 2001 at 06:16:07PM +0200, Hans Werner Strube wrote:
> > > While the length of a key's value is 1024 bytes, you can break the
> > > value so it references other *keys* and therefore work around this
> > > limitation. If you generate the NDBM maps directly from text files
> > > though, your kinda screwed unless you somehow automate this process.
> 
> I have already applied this technique before (even for too many short
> host names) but would like to avoid it if possible.

Automate this. It's not hard. Remember, split the netgroups into a
shallow tree of netgroups, not a deep list. Some broken innetgr()
implementations do a depth-first traversal with a depth-limit as an
anti-looping heuristic.

> > The reverse maps are the ones used by innetgr() on Solaris. The reverse
> > maps' keys are named after users and hosts, and the values are
> > comma-separated lists of netgroups the users/hosts belong to.
> > 
> > There's no way to break those up.
> 
> But there is no need to break those up, since those records are quite short.

The hostname being long does not much affect the reverse map entries.
That is true.

But I have certainly seen very, very long reverse map entries.

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 kr at roqe.org  Wed Oct  3 02:52:27 2001
From: kr at roqe.org (Konrad Rieck)
Date: Tue, 2 Oct 2001 18:52:27 +0200
Subject: Probably broken getaddrinfo() on Solaris x86.
In-Reply-To: <20011002103552.A81925@oolong.il.thewrittenword.com>; from openssh-unix-dev@thewrittenword.com on Tue, Oct 02, 2001 at 10:35:52AM -0500
References: <20011002132816.A21725@roqe.org> <20011002103552.A81925@oolong.il.thewrittenword.com>
Message-ID: <20011002185227.A940@roqe.org>

On Tue, Oct 02, 2001 at 10:35:52AM -0500, openssh-unix-dev at thewrittenword.com wrote:
> 
> I just checked sunsolve.sun.com and I think patch id 111328-01 fixes
> this problem. I don't have a Sol 8/Intel machine to test.

Thanks, 
I missed this patch. 

Konrad

-- 
Konrad Rieck <kr at roqe.org>                    
Roqefellaz - http://www.roqe.org, Public Key http://www.roqe.org/keys/kr.pub
--           Fingerprint: 5803 E58E D1BF 9A29 AFCA  51B3 A725 EA18 ABA7 A6A3


From alexm+openssh at ac.upc.es  Wed Oct  3 06:01:07 2001
From: alexm+openssh at ac.upc.es (Alex Muntada)
Date: Tue, 2 Oct 2001 22:01:07 +0200
Subject: New feature: remote entropy gatherer port
Message-ID: <20011002220107.N256@ac.upc.es>

	[NOTE: I'm new to this list and this is my first
	approach to OpenSSH code.]

I've enhanced "--with-prngd-port=PORT" flag to accept an
optional hostname as in "myhost:myport", e.g.:

  % ./configure --with-prngd-port=example.com:12345

Although I'm certain that this may cause big trouble if remote
gatherer isn't online (ssh will refuse to open any connection)
I think it's an interesting enhancement, specially if you have an
specialized random gatherer in your local environment.

Imagine a server running egd or prngd feeding from the usual PRNG
shell commands. Then, add to that server some random traffic from
your local network or from other random gatherers like random.org
(e.g. http://random.org/cgi-bin/randbyte?nbytes=128&format=f ),
etc. Thus, all random requesters (OpenSSH, OpenSSL, GnuPG, etc.)
could use the same gatherer and requesters won't need to run all
those PRNG shell commands all the time (I've noticed 10 sec.
delays in some hosts that lack a random device).

I've attached the diff to openssh-2.9.9p2 (the last release I've
seen) and I'm planning to add some sshd_config options to select
PRNGD hostname and port but, first, I'd like to know what you
think about this.

Thanks.

--
Alex Muntada <alexm at ac.upc.es>
http://people.ac.upc.es/alexm/
-------------- next part --------------
*** acconfig.h.orig	Thu Sep 20 21:43:41 2001
--- acconfig.h	Tue Oct  2 20:25:35 2001
***************
*** 95,100 ****
--- 95,103 ----
  /* Location of PRNGD/EGD random number socket */
  #undef PRNGD_SOCKET
  
+ /* Port number of PRNGD/EGD random number host */
+ #undef PRNGD_HOST
+ 
  /* Port number of PRNGD/EGD random number socket */
  #undef PRNGD_PORT
  
*** configure.in.orig	Wed Sep 26 00:39:38 2001
--- configure.in	Tue Oct  2 20:34:09 2001
***************
*** 1494,1505 ****
  	]
  )
  
! # Check for PRNGD/EGD pool file
  AC_ARG_WITH(prngd-port,
! 	[  --with-prngd-port=PORT  read entropy from PRNGD/EGD localhost:PORT],
  	[
  		if test ! -z "$withval" -a "x$withval" != "xno" ; then
! 			PRNGD_PORT="$withval"
  			AC_DEFINE_UNQUOTED(PRNGD_PORT, $PRNGD_PORT)
  		fi
  	]
--- 1494,1510 ----
  	]
  )
  
! # Check for PRNGD/EGD pool port (with remote host support)
  AC_ARG_WITH(prngd-port,
! 	[  --with-prngd-port=[HOST:]PORT  read entropy from PRNGD/EGD HOST:PORT (default=localhost:PORT)],
  	[
  		if test ! -z "$withval" -a "x$withval" != "xno" ; then
! 			if test ! -z "$withval" -a "x$withval" != "xno" ; then
! 				PRNGD_HOST=`echo $withval | sed "s~:.*$~~"`
! 				AC_DEFINE_UNQUOTED(PRNGD_HOST, "$PRNGD_HOST")
! 			fi
! 
! 			PRNGD_PORT=`echo $withval | sed "s~^.*:~~"`
  			AC_DEFINE_UNQUOTED(PRNGD_PORT, $PRNGD_PORT)
  		fi
  	]
*** entropy.c.orig	Mon Aug  6 08:51:49 2001
--- entropy.c	Tue Oct  2 20:39:25 2001
***************
*** 90,95 ****
--- 90,98 ----
  	int fd;
  	char msg[2];
  #ifdef PRNGD_PORT
+ #ifdef PRNGD_HOST
+ 	struct hostent *he;
+ #endif
  	struct sockaddr_in addr;
  #else
  	struct sockaddr_un addr;
***************
*** 101,107 ****
--- 104,120 ----
  
  #ifdef PRNGD_PORT
  	addr.sin_family = AF_INET;
+ #ifdef PRNGD_HOST
+ 	he = gethostbyname(PRNGD_HOST);
+ 	if (he == NULL) {
+ 	        error("Could not get IP address for hostname %s.", PRNGD_HOST);
+ 		goto done;
+ 	}
+ 
+ 	memcpy(&addr.sin_addr.s_addr, he->h_addr_list[0], sizeof(struct in_addr));
+ #else /* use localhost IP address */
  	addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
+ #endif
  	addr.sin_port = htons(PRNGD_PORT);
  	addr_len = sizeof(struct sockaddr_in);
  #else /* use IP socket PRNGD_SOCKET instead */
***************
*** 137,144 ****
--- 150,162 ----
  
  	if (connect(fd, (struct sockaddr*)&addr, addr_len) == -1) {
  #ifdef PRNGD_PORT
+ #ifdef PRNGD_HOST
+ 		error("Couldn't connect to PRNGD host %s port %d: %s",
+ 			PRNGD_HOST, PRNGD_PORT, strerror(errno));
+ #else
  		error("Couldn't connect to PRNGD port %d: %s",
  		    PRNGD_PORT, strerror(errno));
+ #endif
  #else
  		error("Couldn't connect to PRNGD socket \"%s\": %s",
  		    addr.sun_path, strerror(errno));

From mouring at etoh.eviladmin.org  Wed Oct  3 06:14:40 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 2 Oct 2001 15:14:40 -0500 (CDT)
Subject: New feature: remote entropy gatherer port
In-Reply-To: <20011002220107.N256@ac.upc.es>
Message-ID: <Pine.BSO.4.33.0110021506500.26854-100000@etoh.eviladmin.org>


This has been talked about before (actually joked about because PRNGd
supports this idea with maybe a tweak or two), but the main question is
the security of the matter.  How easily would it be to insert a
predicatable set of information into this 'unencryption' data streem in
order to weaken the encryption.  Or just as bad someone hijacking the IP
of the box and feeding predictable data out to all clients.

What if your 'entropy host' is down (crashed machine, DoSed, etc).. Do you
really wish to trust entropy collection off your machine?  I'd rather see
OSes implement the right kernel level tools instead of giving them an
excuse to say it is not required.

I'd rather not see anything like this go into the portable tree.  It will
end up being yet another option for uninformed people to use and screw up.
And thus blame on us for their lack of understanding (much like KeepAlive
and friends <sigh>).

On Tue, 2 Oct 2001, Alex Muntada wrote:

> 	[NOTE: I'm new to this list and this is my first
> 	approach to OpenSSH code.]
>
> I've enhanced "--with-prngd-port=PORT" flag to accept an
> optional hostname as in "myhost:myport", e.g.:
>
>   % ./configure --with-prngd-port=example.com:12345
>
> Although I'm certain that this may cause big trouble if remote
> gatherer isn't online (ssh will refuse to open any connection)
> I think it's an interesting enhancement, specially if you have an
> specialized random gatherer in your local environment.
>
> Imagine a server running egd or prngd feeding from the usual PRNG
> shell commands. Then, add to that server some random traffic from
> your local network or from other random gatherers like random.org
> (e.g. http://random.org/cgi-bin/randbyte?nbytes=128&format=f ),
> etc. Thus, all random requesters (OpenSSH, OpenSSL, GnuPG, etc.)
> could use the same gatherer and requesters won't need to run all
> those PRNG shell commands all the time (I've noticed 10 sec.
> delays in some hosts that lack a random device).
>
> I've attached the diff to openssh-2.9.9p2 (the last release I've
> seen) and I'm planning to add some sshd_config options to select
> PRNGD hostname and port but, first, I'd like to know what you
> think about this.
>
> Thanks.
>
> --
> Alex Muntada <alexm at ac.upc.es>
> http://people.ac.upc.es/alexm/
>



From dwd at bell-labs.com  Wed Oct  3 06:29:20 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 2 Oct 2001 15:29:20 -0500
Subject: OpenSSH (portable) and entropy gathering
In-Reply-To: <01Sep28.101355edt.453144-11860@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Fri, Sep 28, 2001 at 10:13:50AM -0400
References: <Pine.LNX.4.33.0109281039530.3675-100000@mothra.mindrot.org> <01Sep28.101355edt.453144-11860@jane.cs.toronto.edu>
Message-ID: <20011002152920.A24424@lucent.com>

On Fri, Sep 28, 2001 at 10:13:50AM -0400, Dan Astoorian wrote:
> On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes:
> > On Thu, 27 Sep 2001, Dan Astoorian wrote:
> > 
> > > 
> > > It would (IMHO) be useful if there were a way to optionally configure
> > > that code to fall back to the internal entropy gathering routines in the
> > > event that EGD was not available; as it is, the routines simply fail if
> > > EGD is unavailable at the time the ssh daemon or client is invoked.
> > > 
> > > Is this a feature the OpenSSH Portability Team would consider
> > > worthwhile?
> > 
> > Probably not - in fact we want to deprecate the built in entropy 
> > collection in favor of the use of a daemon or subprocess.
> 
> I can understand that desire, and I don't mean to be argumentative, but
> I'm looking at it from the standpoint of a sysadmin.  Right now, my
> systems use the internal entropy gathering.  I _want_ to move to PRNGD.
> However, I don't want my systems to stop working entirely if PRNGD isn't
> running or if its socket gets clobbered.  For instance, I need the
> ability to run ssh *clients* from the console in single-user mode,
> before PRNGD has started up.
> 
> By not having an option to fall back, it's making it more difficult to
> justify the case for installing PRNGD, because functionality takes
> precedence over efficiency.
> 
> I don't see a downside to having a configure-time option (off by
> default) like "--with-entropy-fallback" to use the built-in code if (and
> only if) the daemon were unreachable, unless the OpenSSH Portability
> Team considers it better to fail completely than to use the deprecated
> code.
> 
> Am I missing something?
> 
> I'd be willing to code the change.


I submitted a patch to allow all sources of entropy to be selected at 
runtime.  Thread begins at
    http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99193668118573&w=2

It works by allowing you to specify multiple sources of entropy at
configure time, and choosing between them all at runtime.

I haven't updated it to 2.9.9p2 yet, I'll post it again when I do.
The last response from Ben was that it probably wouldn't get in until
after 3.0.

- Dave Dykstra


From djm at mindrot.org  Wed Oct  3 09:03:13 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 3 Oct 2001 09:03:13 +1000 (EST)
Subject: New feature: remote entropy gatherer port
In-Reply-To: <20011002220107.N256@ac.upc.es>
Message-ID: <Pine.LNX.4.33.0110030859370.4143-100000@mothra.mindrot.org>

On Tue, 2 Oct 2001, Alex Muntada wrote:

> 	[NOTE: I'm new to this list and this is my first
> 	approach to OpenSSH code.]
> 
> I've enhanced "--with-prngd-port=PORT" flag to accept an
> optional hostname as in "myhost:myport", e.g.:
> 
>   % ./configure --with-prngd-port=example.com:12345

You didn't enhance, you broke. This will allow a local eavesdropper to
sniff the entropy on as it crosses your network.

If an attacker can sniif the entropy, they can predict session keys,
new host or user keys that are generated and can even determine
existing DSA keys. This makes the use of SSH worse than useless.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer




From root at bigredrockeater.com  Wed Oct  3 15:18:34 2001
From: root at bigredrockeater.com (Charlie Root)
Date: Wed, 3 Oct 2001 01:18:34 -0400
Subject: segmentation violation using openssh-2.9.9p2 on linux 2.2.19
Message-ID: <20011003011834.A2582@bigredrockeater.com>


I received a segmentation violation whilst using openssh-2.2.9p2 today:

	Kernel 2.2.19-6.2.7 (Redhat 6.2)
	Gcc version egcs-2.91.66
	glibc-2.1.3-22
	Hardware is 333MHz K6-3Dnow with 64MB RAM if that matters

Here is what happened along with a stack dump...


# ssh -L 80:someplace.net:80 -l charlie someplace.net
Password:
(works for a while, then seems to freeze)
^C
Segmentation violation (core dumped)
# cd /usr/local/src/openssh-2.9.9p2
# gdb /usr/local/bin/ssh ~root/core
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `ssh -L 80:someplace.net:80 -l charlie someplace.net'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /usr/lib/libcrypto.so.0...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /lib/libnss_nisplus.so.2...done.
Reading symbols from /lib/libnss_nis.so.2...done.
Reading symbols from /lib/libnss_dns.so.2...done.
Reading symbols from /lib/libresolv.so.2...done.
#0  0x4019d109 in chunk_free (ar_ptr=0x40231d40, p=0x808cf38) at malloc.c:3111
3111	malloc.c: No such file or directory.
(gdb) backtrace
#0  0x4019d109 in chunk_free (ar_ptr=0x40231d40, p=0x808cf38) at malloc.c:3111
#1  0x4019cf9a in __libc_free (mem=0x808cf40) at malloc.c:3023
#2  0x8067452 in error ()
#3  0x80534ab in EVP_get_digestbyname ()
#4  0x804d230 in EVP_get_digestbyname ()
#5  0x804c797 in EVP_get_digestbyname ()
#6  0x4015b9cb in __libc_start_main (
    main=0x804b9e4 <EVP_get_digestbyname+1116>, argc=6, argv=0xbffffb54, 
    init=0x804a898 <_init>, fini=0x80691dc <_fini>, 
    rtld_fini=0x4000aea0 <_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
(gdb) quit
#



From jinmei at isl.rdc.toshiba.co.jp  Wed Oct  3 15:38:00 2001
From: jinmei at isl.rdc.toshiba.co.jp (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=)
Date: Wed, 03 Oct 2001 14:38:00 +0900
Subject: a trouble about filename authentication in 2.9.9p2
Message-ID: <y7vn1395lmv.wl@condor.jinmei.org>

Hello,

After upgrading OpenSSH to 2.9.9p2, I've found some troubles on public
key authentication with an sshd working at Solaris 2.5.1 machine.

The server failed to validate the user's path in
auth.c:secure_filename().  There were actually two reasons for the
trouble:

1. the "realpath" of pw->pw_dir (that realpath() would return) was
   different from pw->pw_dir itself.  Thus, comparing the directory
   name to each directory in the for loop of the function never
   succeeded.
2. Our Solaris box had its own dirname(), which returned an empty
   string for the root directory.  So the stat() call in the for loop
   failed for the root directory.

I've attached a patch to fix the problem 1 to this message.  For the
problem 2, we're using a quick patch to check the empty string in
secure_filename(), but I'm not sure if this is the correct fix.  We
might rather use the shared dirname() in openbsd-compat/dirname.c.  So
I've not included the quick hack for now.

I'd apologize in advance if this is a well-known issue and/or has
already been fixed.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp

p.s. I don't subscribe to the list, so if anyone of you need further
information or questions on this issue, please include me in the
response explicitly.  Thanks.

*** auth.c.orig	Wed Oct  3 14:15:47 2001
--- auth.c	Wed Oct  3 14:14:43 2001
***************
*** 363,369 ****
      char *err, size_t errlen)
  {
  	uid_t uid = pw->pw_uid;
! 	char buf[MAXPATHLEN];
  	char *cp;
  	struct stat st;
  
--- 363,369 ----
      char *err, size_t errlen)
  {
  	uid_t uid = pw->pw_uid;
! 	char buf[MAXPATHLEN], pwbuf[MAXPATHLEN];
  	char *cp;
  	struct stat st;
  
***************
*** 372,377 ****
--- 372,382 ----
  		    strerror(errno));
  		return -1;
  	}
+ 	if (realpath(pw->pw_dir, pwbuf) == NULL) {
+ 		snprintf(err, errlen, "realpath %s failed: %s", pw->pw_dir,
+ 		    strerror(errno));
+ 		return -1;
+ 	}
  
  	/* check the open file to avoid races */
  	if (fstat(fileno(f), &st) < 0 ||
***************
*** 400,406 ****
  		}
  
  		/* If are passed the homedir then we can stop */
! 		if (strcmp(pw->pw_dir, buf) == 0) {
  			debug3("secure_filename: terminating check at '%s'",
  			    buf);
  			break;
--- 405,411 ----
  		}
  
  		/* If are passed the homedir then we can stop */
! 		if (strcmp(pwbuf, buf) == 0) {
  			debug3("secure_filename: terminating check at '%s'",
  			    buf);
  			break;



From Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct  3 18:18:52 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Wed, 3 Oct 2001 10:18:52 +0200
Subject: New feature: remote entropy gatherer port
In-Reply-To: <Pine.BSO.4.33.0110021506500.26854-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Tue, Oct 02, 2001 at 03:14:40PM -0500
References: <20011002220107.N256@ac.upc.es> <Pine.BSO.4.33.0110021506500.26854-100000@etoh.eviladmin.org>
Message-ID: <20011003101852.A26378@serv01.aet.tu-cottbus.de>

On Tue, Oct 02, 2001 at 03:14:40PM -0500, mouring at etoh.eviladmin.org wrote:
> This has been talked about before (actually joked about because PRNGd
> supports this idea with maybe a tweak or two), but the main question is
> the security of the matter.  How easily would it be to insert a
> predicatable set of information into this 'unencryption' data streem in
> order to weaken the encryption.  Or just as bad someone hijacking the IP
> of the box and feeding predictable data out to all clients.
> 
> What if your 'entropy host' is down (crashed machine, DoSed, etc).. Do you
> really wish to trust entropy collection off your machine?  I'd rather see
> OSes implement the right kernel level tools instead of giving them an
> excuse to say it is not required.
> 
> I'd rather not see anything like this go into the portable tree.  It will
> end up being yet another option for uninformed people to use and screw up.
> And thus blame on us for their lack of understanding (much like KeepAlive
> and friends <sigh>).

Please let me express my full support for your statement. In your discussion
you left out the typical sniffer problem: if somebody sniffs the entropy
downloaded from the entropy server, it is not worth anything anymore.
(Of course you could download the entropy over an encrypted channel, but
then you won't need the entropy anymore :-)

PRNGd does not support remote ports and it will never do, for the reasons
just stated. TCP port support was only added to help people without
UNIX sockets anyway.

Best regards,
	Lutz
(If you want to support a locally running PRNGd (or EGD) from a remote
source, you my easily add some network command to the list of gatherers
or use the "upload entropy" function to feed it into the pool. The security
point of view has just been discussed.)
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From runemo at stavanger.geco-prakla.slb.com  Mon Oct  1 22:30:51 2001
From: runemo at stavanger.geco-prakla.slb.com (Rune Mossige)
Date: Mon, 1 Oct 2001 14:30:51 +0200
Subject: Couldn't obtain random bytes
Message-ID: <20011001143051.P7353@GSTE44.stavanger.Geco-Prakla.slb.com>

I am trying to generate a ssh_known_hosts2 file, 2.9.9p2,
using:
ssh-keyscan -f list_of_hosts -t rsa > ssh_known_hosts.rsa
and
ssh-keyscan -f list_of_hosts -t dsa > ssh_known_hosts.dsa

but both commands fail almost immidiately with:
Couldn't obtain random bytes (error 604389476)

What could that mean?

Servers that I am aware of that I query is:
OpenSSH_2.5.1p2
OpenSSH_2.5.2p2
OpenSSH_2.9p2
OpenSSH_2.9.9p2

Adding a -v to ssh-keyscan does not give much more info:
sh-keyscan -v -f list_of_hosts -t rsa
debug1: match: OpenSSH_2.9.9p2 pat ^OpenSSH
# xxxxxx.yyyy SSH-1.99-OpenSSH_2.9.9p2
Enabling compatibility mode for protocol 2.0
Couldn't obtain random bytes (error 604389476)
debug1: Calling cleanup 0x21bf8(0x0)
debug1: Calling cleanup 0x1c3cc(0x0)


-- 
-------------------------------------------------------------------
           (-: Hiroshima 45, Chernobyl 86, Windows 95 :-)
Our ultimate goal is to make overloaded systems appear to be idle.
High performance, High reliability, Low cost -------- Pick any two.
-------------------------------------------------------------------
Rune  Mossige,  Systems  Support  Engineer,  WesternGeco, Stavanger
Tel: (+47)51946869                             Mobile:(+47)90871024

---------------------------------------------------------------------
To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com
For additional commands, e-mail: secureshell-help at securityfocus.com



From djm at mindrot.org  Thu Oct  4 00:04:01 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Oct 2001 00:04:01 +1000 (EST)
Subject: segmentation violation using openssh-2.9.9p2 on linux 2.2.19
In-Reply-To: <20011003011834.A2582@bigredrockeater.com>
Message-ID: <Pine.LNX.4.33.0110040003280.1209-100000@mothra.mindrot.org>

On Wed, 3 Oct 2001, Charlie Root wrote:

> 
> I received a segmentation violation whilst using openssh-2.2.9p2 today:
> 
> 	Kernel 2.2.19-6.2.7 (Redhat 6.2)
> 	Gcc version egcs-2.91.66
> 	glibc-2.1.3-22
> 	Hardware is 333MHz K6-3Dnow with 64MB RAM if that matters
> 
> Here is what happened along with a stack dump...

The stack trace looks a little weird - did you compile with debugging
symbols?

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From alexm+openssh at ac.upc.es  Thu Oct  4 00:07:00 2001
From: alexm+openssh at ac.upc.es (Alex Muntada)
Date: Wed, 3 Oct 2001 16:07:00 +0200
Subject: New feature: remote entropy gatherer port
In-Reply-To: <20011003101852.A26378@serv01.aet.tu-cottbus.de> <Pine.LNX.4.33.0110030859370.4143-100000@mothra.mindrot.org> <Pine.BSO.4.33.0110021506500.26854-100000@etoh.eviladmin.org>
References: <20011002220107.N256@ac.upc.es> <Pine.BSO.4.33.0110021506500.26854-100000@etoh.eviladmin.org> <20011003101852.A26378@serv01.aet.tu-cottbus.de> <20011002220107.N256@ac.upc.es> <Pine.LNX.4.33.0110030859370.4143-100000@mothra.mindrot.org> <20011002220107.N256@ac.upc.es> <Pine.BSO.4.33.0110021506500.26854-100000@etoh.eviladmin.org>
Message-ID: <20011003160700.D2892@ac.upc.es>

The purpose of my patch was to avoid installing prngd/egd
locally in every host from our environment (we run many
different OSes lacking a random device). Since the main servers
are protected through our firewall, having an internal entropy
host didn't seem so bad (crashes and DoSes, aside).

I agree that the best solution is that the OS itself provides
such a random device and having a local PRNG daemon can help when
random device is weak or missing. The entropy host approach is
dangerous by means of security, even if running from a local
firewalled network.

Thanks for your feedback.

--
Alex Muntada <alexm at ac.upc.es>
http://people.ac.upc.es/alexm/


From bbense at networking.stanford.edu  Thu Oct  4 01:42:37 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Wed, 3 Oct 2001 08:42:37 -0700 (PDT)
Subject: Minor bug in ssh_connect1.c when AFS is defined.
Message-ID: <Pine.GSO.4.33.0110030834540.27532-100000@shred.stanford.edu>


- I'm not really sure if this is a bug in openssh or in
Kth's krb4-1.1. Anyway, if you define --with-afs=/usr/athena[1]
and --with-kerberos4=/usr/athena on
Solaris 2.7, you need to apply this minor patch to get
the client to build.

- You could argue that kafs.h should include these sys
files since it uses macros inside them.

- Booker C. Bense

[1]- Where kth installs by default.


diff -u -r1.1.1.1 sshconnect1.c
--- sshconnect1.c       2001/10/01 18:18:47     1.1.1.1
+++ sshconnect1.c       2001/10/02 22:53:09
@@ -25,6 +25,8 @@
 #include <krb5.h>
 #endif
 #ifdef AFS
+#include <sys/ioccom.h>
+#include <sys/ioctl.h>
 #include <kafs.h>
 #include "radix.h"
 #endif




From mouring at etoh.eviladmin.org  Thu Oct  4 03:59:28 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 12:59:28 -0500 (CDT)
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <5b66a49x5x.fsf@chiark.greenend.org.uk>
Message-ID: <Pine.BSO.4.33.0110031258500.27777-100000@etoh.eviladmin.org>


Technically should it not be 'chmod 600'  just to ensure we have
all permissions right.

- Ben

On 27 Sep 2001, Matthew Vernon wrote:

> Hi,
>
> quick patch to ssh-copy-id to make it set the file modes more
> correctly.
>
> Thanks,
>
> Matthew
> --- contrib/ssh-copy-id.orig    Thu Sep 27 21:47:44 2001
> +++ contrib/ssh-copy-id Thu Sep 27 21:47:52 2001
> @@ -33,7 +33,7 @@
>    exit 1
>  fi
>
> -{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >>
> .ssh/authori
> zed_keys ; chmod g-w . .ssh .ssh/authorized_keys"
> +{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >>
> .ssh/authori
> zed_keys ; chmod go-w . .ssh .ssh/authorized_keys"
>
>  cat <<EOF
>  Now try logging into the machine, with "ssh '$1'", and check in:
>
> --
> "At least you know where you are with Microsoft."
> "True. I just wish I'd brought a paddle."
> http://www.debian.org
>



From mouring at etoh.eviladmin.org  Thu Oct  4 04:11:04 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:11:04 -0500 (CDT)
Subject: AFS and tokenforwarding
In-Reply-To: <3BB99B51.6A0E8EB9@psi.ch>
Message-ID: <Pine.BSO.4.33.0110031308100.27777-100000@etoh.eviladmin.org>


This code changed when Assar Westerlund and Bjorn Bronvall added Kerb5
code to SSH1.

I would have to defer the changes to them as to why this happened, and
if there is some agreement as to the correct fix for both Krb4 and krb5 to
live together nicely with AFS.

- Ben

On Tue, 2 Oct 2001, Serge Droz wrote:

> For some reasons the afs tokenforwarding stuff has changed
> siginificantly from v 2.9p2 to 2.9.9p2.
> This makes it impossible to use public key authenticication in a
> standart AFS environment.
> I don't know the reasons for these changes.
>
> In any case attached is a patch which restores the old behaviour.
>
> Regards
> Serge
>
>
> --
> Serge Droz
> Paul Scherrer Institut                mailto:serge.droz at psi.ch
> CH-5232 Villigen PSI                   Phone: ++41 56 310 3637
>                                          Fax: ++41 56 310 3649



From matthew at sel.cam.ac.uk  Thu Oct  4 04:10:48 2001
From: matthew at sel.cam.ac.uk (Matthew Vernon)
Date: Wed, 3 Oct 2001 19:10:48 +0100 (BST)
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <Pine.BSO.4.33.0110031258500.27777-100000@etoh.eviladmin.org>
References: <5b66a49x5x.fsf@chiark.greenend.org.uk>
	<Pine.BSO.4.33.0110031258500.27777-100000@etoh.eviladmin.org>
Message-ID: <15291.21672.946344.259586@rapun.sel.cam.ac.uk>

mouring at etoh.eviladmin.org writes:
 > 
 > Technically should it not be 'chmod 600'  just to ensure we have
 > all permissions right.
 
OK. This version does that. 

Matthew

--- contrib/ssh-copy-id.orig	Thu Sep 27 21:47:44 2001
+++ contrib/ssh-copy-id	Thu Sep 27 21:47:52 2001
@@ -33,7 +33,7 @@
   exit 1
 fi
 
-{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys ; chmod g-w . .ssh .ssh/authorized_keys"
+{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys ; chmod 600 . .ssh .ssh/authorized_keys"
 
 cat <<EOF
 Now try logging into the machine, with "ssh '$1'", and check in:
 

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


From mouring at etoh.eviladmin.org  Thu Oct  4 04:19:46 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:19:46 -0500 (CDT)
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <15291.21672.946344.259586@rapun.sel.cam.ac.uk>
Message-ID: <Pine.BSO.4.33.0110031316411.27777-100000@etoh.eviladmin.org>


You know.. thinking about this.. I really hate the idea of
any script mucking around with my ~/  permissions.  That is seriously
asking for trouble.

chmod 700 .ssh; chmod 600 .ssh/authorized_keys

makes more sense.  Changing ~/ permissions is a local policy issue, and I
know I get peaved when something changes my policy without asking.

- Ben

On Wed, 3 Oct 2001, Matthew Vernon wrote:

> mouring at etoh.eviladmin.org writes:
>  >
>  > Technically should it not be 'chmod 600'  just to ensure we have
>  > all permissions right.
>
> OK. This version does that.
>
> Matthew
>
> --- contrib/ssh-copy-id.orig	Thu Sep 27 21:47:44 2001
> +++ contrib/ssh-copy-id	Thu Sep 27 21:47:52 2001
> @@ -33,7 +33,7 @@
>    exit 1
>  fi
>
> -{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys ; chmod g-w . .ssh .ssh/authorized_keys"
> +{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys ; chmod 600 . .ssh .ssh/authorized_keys"
>
>  cat <<EOF
>  Now try logging into the machine, with "ssh '$1'", and check in:
>
>
> --
> Rapun.sel - outermost outpost of the Pick Empire
> http://www.pick.ucam.org
>



From mouring at etoh.eviladmin.org  Thu Oct  4 04:28:27 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:28:27 -0500 (CDT)
Subject: SIGCHLD race condition? 
In-Reply-To: <E15mIWA-0000Tn-00@pmenage-dt.ensim.com>
Message-ID: <Pine.BSO.4.33.0110031328030.27777-100000@etoh.eviladmin.org>


By the pipe solution I assume you mean #define USE_PIPE 1 .. We already
support Pipes for platforms that need them.

- Ben

On Wed, 26 Sep 2001, Paul Menage wrote:

> >
> >
> >On Wed, 26 Sep 2001, Paul Menage wrote:
> >
> >> - Switch to using queued signals for network readiness events, then use
> >> sigtimedwait() or similar instead of select(). I imagine that this would
> >> be a fairly major overhaul of the networking code.
> >>
> >
> >And how does one emulate sigtimedwait() for those older platforms that
> >lack it?  I don't remember seeing it listed in the NeXTStep manpages.
>
> So scrap that idea then - it's more of a change than I'd think people
> would want anyway.
>
> How about the pipe solution? That should be relatively portable.
>
> Paul
>
>



From peterw at usa.net  Thu Oct  4 04:28:19 2001
From: peterw at usa.net (Peter W)
Date: Wed, 3 Oct 2001 14:28:19 -0400
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <Pine.BSO.4.33.0110031316411.27777-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Wed, Oct 03, 2001 at 01:19:46PM -0500
References: <15291.21672.946344.259586@rapun.sel.cam.ac.uk> <Pine.BSO.4.33.0110031316411.27777-100000@etoh.eviladmin.org>
Message-ID: <20011003142819.D2550@usa.net>

On Wed, Oct 03, 2001 at 01:19:46PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> You know.. thinking about this.. I really hate the idea of
> any script mucking around with my ~/  permissions.  That is seriously
> asking for trouble.

Agreed.

> chmod 700 .ssh; chmod 600 .ssh/authorized_keys
> 
> makes more sense.  Changing ~/ permissions is a local policy issue, and I
> know I get peaved when something changes my policy without asking.

What about simply setting the umask to 077 before doing anything? If the
user has existing files/dirs, they won't be changed, but any new stuff would
be safely created.

-Peter


From mouring at etoh.eviladmin.org  Thu Oct  4 04:35:42 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:35:42 -0500 (CDT)
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <20011003142819.D2550@usa.net>
Message-ID: <Pine.BSO.4.33.0110031334160.27777-100000@etoh.eviladmin.org>



On Wed, 3 Oct 2001, Peter W wrote:

> > chmod 700 .ssh; chmod 600 .ssh/authorized_keys
> >
> > makes more sense.  Changing ~/ permissions is a local policy issue, and I
> > know I get peaved when something changes my policy without asking.
>
> What about simply setting the umask to 077 before doing anything? If the
> user has existing files/dirs, they won't be changed, but any new stuff would
> be safely created.
>

Best idea I've seen so far.

If no one scream...this is what the new line will look like:

{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat
>> .ssh/authorized_keys"

- Ben



From bg at sics.se  Thu Oct  4 04:34:26 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 03 Oct 2001 20:34:26 +0200
Subject: AFS and tokenforwarding
In-Reply-To: mouring@etoh.eviladmin.org's message of "Wed, 3 Oct 2001 13:11:04 -0500 (CDT)"
References: <Pine.BSO.4.33.0110031308100.27777-100000@etoh.eviladmin.org>
Message-ID: <wuhetgr2rx.fsf@bg.sics.se>


I'm not sure I received the relevant emails pertaining to this
discussion. Are you talking about the problems with including the
required files under SunOS 5.7? Probably this is about some different
issue?

Cheers,
Bj?rn

>>>>> "mouring" == mouring  <mouring at etoh.eviladmin.org> writes:

mouring> This code changed when Assar Westerlund and Bjorn Bronvall
mouring> added Kerb5 code to SSH1.

mouring> I would have to defer the changes to them as to why this
mouring> happened, and if there is some agreement as to the correct
mouring> fix for both Krb4 and krb5 to live together nicely with AFS.

mouring> - Ben

mouring> On Tue, 2 Oct 2001, Serge Droz wrote:

>> For some reasons the afs tokenforwarding stuff has changed
>> siginificantly from v 2.9p2 to 2.9.9p2.  This makes it impossible
>> to use public key authenticication in a standart AFS environment.
>> I don't know the reasons for these changes.
>> 
>> In any case attached is a patch which restores the old behaviour.
>> 
>> Regards Serge
>> 
>> 
>> -- Serge Droz Paul Scherrer Institut mailto:serge.droz at psi.ch
>> CH-5232 Villigen PSI Phone: ++41 56 310 3637 Fax: ++41 56 310 3649



-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From Nicolas.Williams at ubsw.com  Thu Oct  4 04:35:08 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 3 Oct 2001 14:35:08 -0400
Subject: SIGCHLD race condition?
In-Reply-To: <Pine.BSO.4.33.0110031328030.27777-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Wed, Oct 03, 2001 at 01:28:27PM -0500
References: <E15mIWA-0000Tn-00@pmenage-dt.ensim.com> <Pine.BSO.4.33.0110031328030.27777-100000@etoh.eviladmin.org>
Message-ID: <20011003143507.I5739@sm2p1386swk.wdr.com>

No, Paul meant to open a pipe when there are no child fildes left to
select for and all you have to do is wait for client input or the child
to die -- since select() can't do the waiting, the next best thing is
for the SIGCHLD handler to write into this pipe whose read end you can
select() for.

It's a neat trick. SIGCHLD arrives and the handler reaps the child and
writes a byte to this place holder pipe, then, when the select() loop is
entered you come out because there's that byte in the pipe, you check
the child terminated variable and you exit. No more race condition.

Nico


On Wed, Oct 03, 2001 at 01:28:27PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> By the pipe solution I assume you mean #define USE_PIPE 1 .. We already
> support Pipes for platforms that need them.
> 
> - Ben
> 
> On Wed, 26 Sep 2001, Paul Menage wrote:
> 
> > >
> > >
> > >On Wed, 26 Sep 2001, Paul Menage wrote:
> > >
> > >> - Switch to using queued signals for network readiness events, then use
> > >> sigtimedwait() or similar instead of select(). I imagine that this would
> > >> be a fairly major overhaul of the networking code.
> > >>
> > >
> > >And how does one emulate sigtimedwait() for those older platforms that
> > >lack it?  I don't remember seeing it listed in the NeXTStep manpages.
> >
> > So scrap that idea then - it's more of a change than I'd think people
> > would want anyway.
> >
> > How about the pipe solution? That should be relatively portable.
> >
> > Paul
> >
> >
--

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 mouring at etoh.eviladmin.org  Thu Oct  4 04:40:32 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:40:32 -0500 (CDT)
Subject: AFS and tokenforwarding
In-Reply-To: <wuhetgr2rx.fsf@bg.sics.se>
Message-ID: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org>



On 3 Oct 2001, Bjoern Groenvall wrote:

>
> I'm not sure I received the relevant emails pertaining to this
> discussion. Are you talking about the problems with including the
> required files under SunOS 5.7? Probably this is about some different
> issue?
>
> Cheers,
> Bj?rn
>

Sorry about that.. Here is the attachment.. My mail program decided to eat
it for lunch.  <sigh>  Glad it was well feed.

I know nothing about this.  Just trying to assure a correct solution is
proposed.

- Ben

--- openssh-2.9.9p2.orig/sshconnect1.c	Sat Jul 14 04:17:00 2001
+++ openssh-2.9.9p2/sshconnect1.c	Thu Sep 27 09:58:37 2001
@@ -1111,13 +1111,14 @@
 ssh_userauth1(const char *local_user, const char *server_user, char *host,
     Key **keys, int nkeys)
 {
+
 #ifdef KRB5
 	krb5_context context = NULL;
 	krb5_auth_context auth_context = NULL;
 #endif
 	int i, type;
 	int payload_len;
-
+
 	if (supported_authentications == 0)
 		fatal("ssh_userauth1: server supports no auth methods");

@@ -1139,6 +1140,23 @@
 		goto success;
 	if (type != SSH_SMSG_FAILURE)
 		packet_disconnect("Protocol error: got %d in response to SSH_CMSG_USER", type);
+#ifdef AFS
+	/* 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)) &&
@@ -1202,6 +1220,7 @@
 				goto success;
 		}
 	}
+
 	/* Try RSA authentication if the server supports it. */
 	if ((supported_authentications & (1 << SSH_AUTH_RSA)) &&
 	    options.rsa_authentication) {
@@ -1226,6 +1245,7 @@
 		if (try_challenge_response_authentication())
 			goto success;
 	}
+
 	/* Try password authentication if the server supports it. */
 	if ((supported_authentications & (1 << SSH_AUTH_PASSWORD)) &&
 	    options.password_authentication && !options.batch_mode) {
@@ -1255,22 +1275,6 @@
 		krb5_free_context(context);
 #endif

-#ifdef AFS
-	/* 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 */

 	return;	/* need statement after label */
 }



From mouring at etoh.eviladmin.org  Thu Oct  4 04:47:59 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:47:59 -0500 (CDT)
Subject: SIGCHLD race condition?
In-Reply-To: <20011003143507.I5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.BSO.4.33.0110031342400.27777-100000@etoh.eviladmin.org>


On Wed, 3 Oct 2001, Nicolas Williams wrote:

> No, Paul meant to open a pipe when there are no child fildes left to
> select for and all you have to do is wait for client input or the child
> to die -- since select() can't do the waiting, the next best thing is
> for the SIGCHLD handler to write into this pipe whose read end you can
> select() for.
>
> It's a neat trick. SIGCHLD arrives and the handler reaps the child and
> writes a byte to this place holder pipe, then, when the select() loop is
> entered you come out because there's that byte in the pipe, you check
> the child terminated variable and you exit. No more race condition.
>

Neat trick, but I've seen scp terminate with a SIGCHLD before the pipe was
empty.

I guess I'd have to see the code since I get a feeling we could lose data
on non-interactive session with this trick.  I'd rather track down what C
code is holding the offending file descriptor past's the due date and
rework the code.  I'm not too much a fan of repeating the last 'scp
missing data' thread.

But I'd be damned if I can find it.  <frown>

- Ben



From CLAD at chevron.com  Thu Oct  4 04:50:29 2001
From: CLAD at chevron.com (Ladner, Eric (CLAD))
Date: Wed, 3 Oct 2001 11:50:29 -0700
Subject: [PATCH] ssh-copy-id should do chmod go-w
Message-ID: <8F88657F29DFD11189ED0008C728C6B0078AA720@chevron.com>

Doesn't the authorized_keys have to be world readable?

Just checking..

Eric

-----Original Message-----
From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
Sent: Wednesday, October 03, 2001 1:36 PM
Cc: openssh-unix-dev at mindrot.org
Subject: Re: [PATCH] ssh-copy-id should do chmod go-w




On Wed, 3 Oct 2001, Peter W wrote:

> > chmod 700 .ssh; chmod 600 .ssh/authorized_keys
> >
> > makes more sense.  Changing ~/ permissions is a local policy issue, and
I
> > know I get peaved when something changes my policy without asking.
>
> What about simply setting the umask to 077 before doing anything? If the
> user has existing files/dirs, they won't be changed, but any new stuff
would
> be safely created.
>

Best idea I've seen so far.

If no one scream...this is what the new line will look like:

{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat
>> .ssh/authorized_keys"

- Ben




From Nicolas.Williams at ubsw.com  Thu Oct  4 04:53:15 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 3 Oct 2001 14:53:15 -0400
Subject: SIGCHLD race condition?
In-Reply-To: <Pine.BSO.4.33.0110031342400.27777-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Wed, Oct 03, 2001 at 01:47:59PM -0500
References: <20011003143507.I5739@sm2p1386swk.wdr.com> <Pine.BSO.4.33.0110031342400.27777-100000@etoh.eviladmin.org>
Message-ID: <20011003145315.M26615@wdr.com>

On Wed, Oct 03, 2001 at 01:47:59PM -0500, mouring at etoh.eviladmin.org wrote:
> On Wed, 3 Oct 2001, Nicolas Williams wrote:
> > It's a neat trick. SIGCHLD arrives and the handler reaps the child and
> > writes a byte to this place holder pipe, then, when the select() loop is
> > entered you come out because there's that byte in the pipe, you check
> > the child terminated variable and you exit. No more race condition.
> >
> 
> Neat trick, but I've seen scp terminate with a SIGCHLD before the pipe was
> empty.

There's no such pipe in the code now. It'd be merely a place holder to
tie the SIGCHLD/wait() event to select().

SSHD would still only exit IFF (child is dead && child fildes are dead).

The pipe trick is merely a race avoidance technique.

> I guess I'd have to see the code since I get a feeling we could lose data
> on non-interactive session with this trick.  I'd rather track down what C
> code is holding the offending file descriptor past's the due date and
> rework the code.  I'm not too much a fan of repeating the last 'scp
> missing data' thread.

Wrong thread, methinks. This is the sigchld-arrived-before-entering-
select()-but-after-checking-child_terminated-and-client-has-nothing-
to-send-and-the-child's-fildes-are-closed-therefore-sshd-ends-up-
waiting-forever-in-select()-for-the-client-to-send-something thread.

> But I'd be damned if I can find it.  <frown>
> 
> - 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 mouring at etoh.eviladmin.org  Thu Oct  4 04:58:27 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 13:58:27 -0500 (CDT)
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <8F88657F29DFD11189ED0008C728C6B0078AA720@chevron.com>
Message-ID: <Pine.BSO.4.33.0110031357150.28109-100000@etoh.eviladmin.org>



$ ls -l .ssh/authorized_keys2
-rw-------  1 mouring  users  237 Sep  4 17:43 .ssh/authorized_keys2

It does? =) Could have fooled my UNIX boxes.  <smile>

- Ben

On Wed, 3 Oct 2001, Ladner, Eric (CLAD) wrote:

> Doesn't the authorized_keys have to be world readable?
>
> Just checking..
>
> Eric
>
> -----Original Message-----
> From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
> Sent: Wednesday, October 03, 2001 1:36 PM
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: [PATCH] ssh-copy-id should do chmod go-w
>
>
>
>
> On Wed, 3 Oct 2001, Peter W wrote:
>
> > > chmod 700 .ssh; chmod 600 .ssh/authorized_keys
> > >
> > > makes more sense.  Changing ~/ permissions is a local policy issue, and
> I
> > > know I get peaved when something changes my policy without asking.
> >
> > What about simply setting the umask to 077 before doing anything? If the
> > user has existing files/dirs, they won't be changed, but any new stuff
> would
> > be safely created.
> >
>
> Best idea I've seen so far.
>
> If no one scream...this is what the new line will look like:
>
> { eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat
> >> .ssh/authorized_keys"
>
> - Ben
>
>
>



From mouring at etoh.eviladmin.org  Thu Oct  4 05:01:31 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 14:01:31 -0500 (CDT)
Subject: SIGCHLD race condition?
In-Reply-To: <20011003145315.M26615@wdr.com>
Message-ID: <Pine.BSO.4.33.0110031359140.28109-100000@etoh.eviladmin.org>



On Wed, 3 Oct 2001, Nicolas Williams wrote:

> On Wed, Oct 03, 2001 at 01:47:59PM -0500, mouring at etoh.eviladmin.org wrote:
> > On Wed, 3 Oct 2001, Nicolas Williams wrote:
> > > It's a neat trick. SIGCHLD arrives and the handler reaps the child and
> > > writes a byte to this place holder pipe, then, when the select() loop is
> > > entered you come out because there's that byte in the pipe, you check
> > > the child terminated variable and you exit. No more race condition.
> > >
> >
> > Neat trick, but I've seen scp terminate with a SIGCHLD before the pipe was
> > empty.
>
> There's no such pipe in the code now. It'd be merely a place holder to
> tie the SIGCHLD/wait() event to select().
>
> SSHD would still only exit IFF (child is dead && child fildes are dead).
>
> The pipe trick is merely a race avoidance technique.
>
> > I guess I'd have to see the code since I get a feeling we could lose data
> > on non-interactive session with this trick.  I'd rather track down what C
> > code is holding the offending file descriptor past's the due date and
> > rework the code.  I'm not too much a fan of repeating the last 'scp
> > missing data' thread.
>
> Wrong thread, methinks. This is the sigchld-arrived-before-entering-
> select()-but-after-checking-child_terminated-and-client-has-nothing-
> to-send-and-the-child's-fildes-are-closed-therefore-sshd-ends-up-
> waiting-forever-in-select()-for-the-client-to-send-something thread.
>

It is related..  The other thread is
sigchld-arrived-before-select-not-all-file-descriptors-are-closed-select-
hangs-until-either-a-bit-of-data-appears (IE sleep 30&exit)
or-hangs-forever (IE vi file, ctrl-Z, ctrl-d).

It is the same bug in reality.

- Ben



From Nicolas.Williams at ubsw.com  Thu Oct  4 05:05:56 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 3 Oct 2001 15:05:56 -0400
Subject: SIGCHLD race condition?
In-Reply-To: <Pine.BSO.4.33.0110031359140.28109-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Wed, Oct 03, 2001 at 02:01:31PM -0500
References: <20011003145315.M26615@wdr.com> <Pine.BSO.4.33.0110031359140.28109-100000@etoh.eviladmin.org>
Message-ID: <20011003150556.N26615@wdr.com>

On Wed, Oct 03, 2001 at 02:01:31PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> 
> On Wed, 3 Oct 2001, Nicolas Williams wrote:
> 
> > On Wed, Oct 03, 2001 at 01:47:59PM -0500, mouring at etoh.eviladmin.org wrote:
> > > On Wed, 3 Oct 2001, Nicolas Williams wrote:
> > SSHD would still only exit IFF (child is dead && child fildes are dead).
> >
> > The pipe trick is merely a race avoidance technique.

[...]

> > Wrong thread, methinks. This is the sigchld-arrived-before-entering-
> > select()-but-after-checking-child_terminated-and-client-has-nothing-
> > to-send-and-the-child's-fildes-are-closed-therefore-sshd-ends-up-
> > waiting-forever-in-select()-for-the-client-to-send-something thread.
> >
> 
> It is related..  The other thread is
> sigchld-arrived-before-select-not-all-file-descriptors-are-closed-select-
> hangs-until-either-a-bit-of-data-appears (IE sleep 30&exit)
> or-hangs-forever (IE vi file, ctrl-Z, ctrl-d).
> 
> It is the same bug in reality.

Yes. But then, when should SSHD exit? Is the above condition correct?
I.e., (child is dead && child fildes are dead)?

Ultimately, the guy who suggested the pipe technique want to know which
solution you're open to so he knows which to code.

So the question is: would the pipe trick satisfy you OpenSSH gods
[provided it works as advertised, of course], or is it still too
earthly? :)

> - 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 CLAD at chevron.com  Thu Oct  4 05:08:19 2001
From: CLAD at chevron.com (Ladner, Eric (CLAD))
Date: Wed, 3 Oct 2001 12:08:19 -0700
Subject: [PATCH] ssh-copy-id should do chmod go-w
Message-ID: <8F88657F29DFD11189ED0008C728C6B0078AA724@chevron.com>


Ah.. maybe I'm not as paranoid as I should be.

Thanks for the info.

Eric

-----Original Message-----
From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
Sent: Wednesday, October 03, 2001 1:58 PM
To: openssh-unix-dev at mindrot.org
Subject: RE: [PATCH] ssh-copy-id should do chmod go-w




$ ls -l .ssh/authorized_keys2
-rw-------  1 mouring  users  237 Sep  4 17:43 .ssh/authorized_keys2

It does? =) Could have fooled my UNIX boxes.  <smile>

- Ben

On Wed, 3 Oct 2001, Ladner, Eric (CLAD) wrote:

> Doesn't the authorized_keys have to be world readable?
>
> Just checking..
>
> Eric
>
> -----Original Message-----
> From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
> Sent: Wednesday, October 03, 2001 1:36 PM
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: [PATCH] ssh-copy-id should do chmod go-w
>
>
>
>
> On Wed, 3 Oct 2001, Peter W wrote:
>
> > > chmod 700 .ssh; chmod 600 .ssh/authorized_keys
> > >
> > > makes more sense.  Changing ~/ permissions is a local policy issue,
and
> I
> > > know I get peaved when something changes my policy without asking.
> >
> > What about simply setting the umask to 077 before doing anything? If the
> > user has existing files/dirs, they won't be changed, but any new stuff
> would
> > be safely created.
> >
>
> Best idea I've seen so far.
>
> If no one scream...this is what the new line will look like:
>
> { eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat
> >> .ssh/authorized_keys"
>
> - Ben
>
>
>




From Nicolas.Williams at ubsw.com  Thu Oct  4 05:16:00 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 3 Oct 2001 15:16:00 -0400
Subject: [PATCH] ssh-copy-id should do chmod go-w
In-Reply-To: <8F88657F29DFD11189ED0008C728C6B0078AA724@chevron.com>; from CLAD@chevron.com on Wed, Oct 03, 2001 at 12:08:19PM -0700
References: <8F88657F29DFD11189ED0008C728C6B0078AA724@chevron.com>
Message-ID: <20011003151559.J5739@sm2p1386swk.wdr.com>

If your home directory is accessed via NFS, then yes, your .sshd has to
be 711 at least and your authorized_keys* files must be 644.

Doubly so if you're using secure NFS.

Unless your home directory is exported such that root on the NFS clients
has root privs on the server. And this caveat doesn't count if you're
using secure NFS.

Nico


On Wed, Oct 03, 2001 at 12:08:19PM -0700, Ladner, Eric (CLAD) wrote:
> 
> Ah.. maybe I'm not as paranoid as I should be.
> 
> Thanks for the info.
> 
> Eric
> 
> -----Original Message-----
> From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
> Sent: Wednesday, October 03, 2001 1:58 PM
> To: openssh-unix-dev at mindrot.org
> Subject: RE: [PATCH] ssh-copy-id should do chmod go-w
> 
> 
> 
> 
> $ ls -l .ssh/authorized_keys2
> -rw-------  1 mouring  users  237 Sep  4 17:43 .ssh/authorized_keys2
> 
> It does? =) Could have fooled my UNIX boxes.  <smile>
> 
> - Ben
> 
> On Wed, 3 Oct 2001, Ladner, Eric (CLAD) wrote:
> 
> > Doesn't the authorized_keys have to be world readable?
> >
> > Just checking..
> >
> > Eric
> >
> > -----Original Message-----
> > From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
> > Sent: Wednesday, October 03, 2001 1:36 PM
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: Re: [PATCH] ssh-copy-id should do chmod go-w
> >
> >
> >
> >
> > On Wed, 3 Oct 2001, Peter W wrote:
> >
> > > > chmod 700 .ssh; chmod 600 .ssh/authorized_keys
> > > >
> > > > makes more sense.  Changing ~/ permissions is a local policy issue,
> and
> > I
> > > > know I get peaved when something changes my policy without asking.
> > >
> > > What about simply setting the umask to 077 before doing anything? If the
> > > user has existing files/dirs, they won't be changed, but any new stuff
> > would
> > > be safely created.
> > >
> >
> > Best idea I've seen so far.
> >
> > If no one scream...this is what the new line will look like:
> >
> > { eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat
> > >> .ssh/authorized_keys"
> >
> > - Ben
> >
> >
> >
> 
--

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 dschiebe at cisco.com  Thu Oct  4 05:18:50 2001
From: dschiebe at cisco.com (Schieber, Dustin)
Date: Wed, 3 Oct 2001 15:18:50 -0400 
Subject: hang on exit - bug or no bug?
Message-ID: <FC1C45AE08EFD211B9C600A0C96B86DA03921E4C@rtp-xch1.cisco.com>

The hang on exit has become quite an issue in my organization(Sun and HP
hosts).  I see this note in the changelog which indicates that there
will not be a fix for this problem:

20001129
 - (djm) Back out all the serverloop.c hacks. sshd will now hang again
   if there are background children with open fds.

Also, I am aware of the workaround as noted in the FAQ.  However this
workaround is not ideal for sysadmins that regularly background jobs
from the cmd-line.  It's impractical to ask them to redirect stdin,
stdout, and stderr every time.  In addition, we have many jobs failing
because various stop/start scripts leave open fds.  Identifying and
modifying all such scripts is possible but not something I want to
undertake.   

Question:  This was not an issue for us with ssh 1.2.x.  Why is it an
issue with Openssh?   Will this ever be classified as a bug?

thx,
-das



From bg at sics.se  Thu Oct  4 05:26:55 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 03 Oct 2001 21:26:55 +0200
Subject: AFS and tokenforwarding
In-Reply-To: mouring@etoh.eviladmin.org's message of "Wed, 3 Oct 2001 13:40:32 -0500 (CDT)"
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org>
Message-ID: <wuelokr0cg.fsf@bg.sics.se>

>>>>> "mouring" == mouring  <mouring at etoh.eviladmin.org> writes:

mouring> On 3 Oct 2001, Bjoern Groenvall wrote:

>>  I'm not sure I received the relevant emails pertaining to this
>> discussion. Are you talking about the problems with including the
>> required files under SunOS 5.7? Probably this is about some
>> different issue?
>> 
>> Cheers, Bj?rn
>> 

I still feel I'm out of sync in this discussion so perhaps somebody
can correct me. Meanwhile I have to make some guesses!

I assume that the problem is that public key authentication does not
work in 

RCSID("$OpenBSD: sshconnect1.c,v 1.31.2.1 2001/09/27 19:03:55 jason Exp $");

if the keys are stored in an read protected AFS directory.

To make it possible for sshd to read those read protected files in
~/.ssh it is necessary to first forward a valid AFS token. That can be
achieved by moving the code:

        /* 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();

so that it happens before any files are accessed in the users home
directory.

I guess that is what Serges patch was designed to do.

>From a more general perspective one may reason that both AFS tokens
and krb{4,5} tickets should be forwarded early to allow for access to
files in remote home directories. I.e change the code to first forward
AFS tokens, then krb4 tickets, and then krb5 tickets. If tickets are
forwarded early, one must also be careful to handle ownership
correctly. This should not be a problem with tokens since they are
referenced via a PAG.

Objections anybody?

/Bj?rn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From pmenage at ensim.com  Thu Oct  4 05:37:41 2001
From: pmenage at ensim.com (Paul Menage)
Date: Wed, 03 Oct 2001 12:37:41 -0700
Subject: SIGCHLD race condition? 
In-Reply-To: Your message of "Wed, 03 Oct 2001 15:05:56 EDT."
             <20011003150556.N26615@wdr.com> 
Message-ID: <E15orpt-0005Yu-00@pmenage-dt.ensim.com>

>Yes. But then, when should SSHD exit? Is the above condition correct?
>I.e., (child is dead && child fildes are dead)?
>
>Ultimately, the guy who suggested the pipe technique want to know which
>solution you're open to so he knows which to code.
>

Actually, we just went with putting a 10 second maximum timeout on the
select(). I did briefly start putting together the pipe solution, as
follows:

- add a new channel type, SSH_CHANNEL_WAKEUP

- add a pre-handler that adds the pipe rfd to the readfd set

- add a post-handler that drains the pipe (and ignores the data)

But it wasn't clear to me where the best place to initialise the pipe
channel was, and I've been too busy to delve deeper into the SSH code.

Paul





From dugsong at monkey.org  Thu Oct  4 05:39:06 2001
From: dugsong at monkey.org (Dug Song)
Date: Wed, 3 Oct 2001 15:39:06 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <Pine.BSO.4.33.0110031308100.27777-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Wed, Oct 03, 2001 at 01:11:04PM -0500
References: <3BB99B51.6A0E8EB9@psi.ch> <Pine.BSO.4.33.0110031308100.27777-100000@etoh.eviladmin.org>
Message-ID: <20011003153906.L3563@naughty.monkey.org>

On Wed, Oct 03, 2001 at 01:11:04PM -0500, mouring at etoh.eviladmin.org wrote:

> This code changed when Assar Westerlund and Bjorn Bronvall added Kerb5
> code to SSH1.

i ported their krb5 code to OpenSSH, from FreeBSD.

> I would have to defer the changes to them as to why this happened, and
> if there is some agreement as to the correct fix for both Krb4 and krb5 to
> live together nicely with AFS.

booker's patch looks fine, although i don't have a way to test it
right now. niels, can you try it?

-d.

---
http://www.monkey.org/~dugsong/


From djm at mindrot.org  Thu Oct  4 10:25:16 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Oct 2001 10:25:16 +1000 (EST)
Subject: 2.9.9p2 bug in PAM support
In-Reply-To: <3BB5220E.3080301@cheers.bungi.com>
Message-ID: <Pine.LNX.4.33.0110041024330.4445-100000@mothra.mindrot.org>

On Fri, 28 Sep 2001, Greg wrote:

> FYI.  If pam_unix is used then at least one of PAM_TTY or PAM_RHOST must 
>    be set before calling pam_open_session or it's considered a 
> PAM_SESSION_ERR.

We set PAM_RHOST unconditionally, but it is not enough. Some stupid PAM
module use stdio when they aren't passed a PAM_TTY.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Thu Oct  4 10:32:21 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Oct 2001 10:32:21 +1000 (EST)
Subject: hang on exit - bug or no bug?
In-Reply-To: <FC1C45AE08EFD211B9C600A0C96B86DA03921E4C@rtp-xch1.cisco.com>
Message-ID: <Pine.LNX.4.33.0110041028140.4445-100000@mothra.mindrot.org>

On Wed, 3 Oct 2001, Schieber, Dustin wrote:

> Question:  This was not an issue for us with ssh 1.2.x.  Why is it an
> issue with Openssh?   Will this ever be classified as a bug?

I haven't been able to find a sane way of avoiding the hang on exit 
on Linux or Solaris. OpenBSD doesn't seem to have the problem - there 
seem to be some differing fd semantics as work. Anyone who want to try
to fix the problem would be well advised to investigate these differing
semantics.

By 'sane', I mean a solution that won't lose data even under pathological
conditions. An avoidable hang on exit is an annoyance, data loss is 
unforgivable.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Thu Oct  4 11:31:18 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Oct 2001 11:31:18 +1000 (EST)
Subject: OpenSSH (portable) and entropy gathering 
In-Reply-To: <01Sep28.101355edt.453144-11860@jane.cs.toronto.edu>
Message-ID: <Pine.LNX.4.33.0109291044040.1359-100000@mothra.mindrot.org>

On Fri, 28 Sep 2001, Dan Astoorian wrote:

> On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes:
> > On Thu, 27 Sep 2001, Dan Astoorian wrote:
> > > Is this a feature the OpenSSH Portability Team would consider
> > > worthwhile?
> > 
> > Probably not - in fact we want to deprecate the built in entropy 
> > collection in favor of the use of a daemon or subprocess.
> 
> I can understand that desire, and I don't mean to be argumentative, but
> I'm looking at it from the standpoint of a sysadmin.  Right now, my
> systems use the internal entropy gathering.  I _want_ to move to PRNGD.
> However, I don't want my systems to stop working entirely if PRNGD isn't
> running or if its socket gets clobbered.  For instance, I need the
> ability to run ssh *clients* from the console in single-user mode,
> before PRNGD has started up.

In these cases the built-in prng is just about useless as most of its
sources of entropy assume an active system.

I would like to replace the built in prng with a choice of /dev/random
(or equiv), EGD/PRNGd and a new option to execute a subprocess which 
dumps entropy to stdout. 

-d


-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer




From dmahurin at berkeley.innomedia.com  Thu Oct  4 12:36:40 2001
From: dmahurin at berkeley.innomedia.com (Don Mahurin)
Date: Wed, 03 Oct 2001 19:36:40 -0700
Subject: patch - forceshell
Message-ID: <3BBBCB38.C19BD161@berkeley.innomedia.com>

Attached is a simple patch which allows an auth param 'shell=' like
'command='
When specified, sshd will use this shell instead of the one in
/etc/passwd or the default shell.

This patch allows you can have some chrooted shell (actually any shell)
associated with a specific key.
You could do this with command=, but then the command given to ssh will
be ignored, and scp will not work.

changing the shell in /etc/passwd only works if you want that shell for
every key.

I suppose if there was a root= auth parameter which caused a chroot,
this could perform a similar task. Has someone already written that
code?

Attached also is a simple chrooted shell perl script.

-Don Mahurin



-------------- next part --------------
diff -ur openssh-2.9p2/auth-options.c openssh-2.9p2_forceshell/auth-options.c
--- openssh-2.9p2/auth-options.c	Sun Mar 18 16:13:47 2001
+++ openssh-2.9p2_forceshell/auth-options.c	Wed Oct  3 09:57:24 2001
@@ -29,6 +29,8 @@
 
 /* "command=" option. */
 char *forced_command = NULL;
+/* "shell=" option. */
+char *forced_shell = NULL;
 
 /* "environment=" options. */
 struct envstring *custom_environment = NULL;
@@ -98,6 +100,35 @@
 			packet_send_debug("Pty allocation disabled.");
 			no_pty_flag = 1;
 			opts += strlen(cp);
+			goto next_option;
+		}
+		cp = "shell=\"";
+		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
+			opts += strlen(cp);
+			forced_shell = xmalloc(strlen(opts) + 1);
+			i = 0;
+			while (*opts) {
+				if (*opts == '"')
+					break;
+				if (*opts == '\\' && opts[1] == '"') {
+					opts += 2;
+					forced_shell[i++] = '"';
+					continue;
+				}
+				forced_shell[i++] = *opts++;
+			}
+			if (!*opts) {
+				debug("%.100s, line %lu: missing end quote",
+				    file, linenum);
+				packet_send_debug("%.100s, line %lu: missing end quote",
+				    file, linenum);
+				xfree(forced_shell);
+				forced_shell = NULL;
+				goto bad_option;
+			}
+			forced_shell[i] = 0;
+			packet_send_debug("Forced shell: %.900s", forced_shell);
+			opts++;
 			goto next_option;
 		}
 		cp = "command=\"";
diff -ur openssh-2.9p2/auth-options.h openssh-2.9p2_forceshell/auth-options.h
--- openssh-2.9p2/auth-options.h	Sun Jan 21 21:34:40 2001
+++ openssh-2.9p2_forceshell/auth-options.h	Wed Oct  3 09:57:33 2001
@@ -28,6 +28,7 @@
 extern int no_x11_forwarding_flag;
 extern int no_pty_flag;
 extern char *forced_command;
+extern char *forced_shell;
 extern struct envstring *custom_environment;
 
 /*
diff -ur openssh-2.9p2/session.c openssh-2.9p2_forceshell/session.c
--- openssh-2.9p2/session.c	Sat Jun 16 20:40:51 2001
+++ openssh-2.9p2_forceshell/session.c	Wed Oct  3 09:58:44 2001
@@ -1195,7 +1195,12 @@
 	 * Get the shell from the password data.  An empty shell field is
 	 * legal, and means /bin/sh.
 	 */
+	if(forced_shell != NULL) {
+		shell = forced_shell;
+	}
+	else {
 	shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell;
+	}
 #ifdef HAVE_LOGIN_CAP
 	shell = login_getcapstr(lc, "shell", (char *)shell, (char *)shell);
 #endif
-------------- next part --------------
#!/usr/bin/perl
# Changes root to APPROOT as current user and runs given command or bash
# -Don Mahurin

my(@command) = @ARGV;
if(@command)
{ 
  if ($command[0] =~ m:^-:) { unshift(@command,"bash") } # assume shell args
  @command = untaint(@command);
}
else
{ 
   @command = ( "bash" );
}

exit(1) unless(open(FILE, "/etc/rbusd/APPROOT"));
my($rdir) = <FILE>;
chomp($rdir);
close(FILE);
if($rdir =~ m:^(/mnt.*)$:) { $rdir = $1 } else { die "bad dir: $rdir"; }

chdir($rdir) || die "can't chdir: $dir";
chroot($rdir) || die "can't chroot: $dir";
$> = $<;
$ENV{PATH}="/bin:/usr/bin";
exec(@command);

sub untaint
{
   my @out;
   for (@_) { if ( /^(^.*)$/) { push(@out, $1) } }
   return @out;
}


From djm at mindrot.org  Thu Oct  4 12:49:33 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Oct 2001 12:49:33 +1000 (EST)
Subject: patch - forceshell
In-Reply-To: <3BBBCB38.C19BD161@berkeley.innomedia.com>
Message-ID: <Pine.LNX.4.33.0110041248440.4445-100000@mothra.mindrot.org>

On Wed, 3 Oct 2001, Don Mahurin wrote:

> Attached is a simple patch which allows an auth param 'shell=' like
> 'command='
> When specified, sshd will use this shell instead of the one in
> /etc/passwd or the default shell.
> 
> This patch allows you can have some chrooted shell (actually any shell)
> associated with a specific key.
> You could do this with command=, but then the command given to ssh will
> be ignored, and scp will not work.

You can get around this by using the $SSH_ORIGINAL_COMMAND env var. 

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From bbense at networking.stanford.edu  Thu Oct  4 12:58:14 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Wed, 3 Oct 2001 19:58:14 -0700 (PDT)
Subject: AFS and tokenforwarding
In-Reply-To: <20011003153906.L3563@naughty.monkey.org>
Message-ID: <Pine.GSO.4.33.0110031954490.1940-100000@shred.stanford.edu>

On Wed, 3 Oct 2001, Dug Song wrote:

> On Wed, Oct 03, 2001 at 01:11:04PM -0500, mouring at etoh.eviladmin.org wrote:
>
> > This code changed when Assar Westerlund and Bjorn Bronvall added Kerb5
> > code to SSH1.
>
> i ported their krb5 code to OpenSSH, from FreeBSD.
>
> > I would have to defer the changes to them as to why this happened, and
> > if there is some agreement as to the correct fix for both Krb4 and krb5 to
> > live together nicely with AFS.
>
> booker's patch looks fine, although i don't have a way to test it
> right now. niels, can you try it?
>

- I think there are two problems being conflated into one. My patch
is just to get the AFS code to compile when using Kth-1.1. It doesn't
fix the problem of the token not being available when you need to
access the filesystem. I think that was the point of the other
patch posted.

- I'll test that one and report back. The lack of AFS access was
the next thing on my list of things to get working.

- Booker C. Bense



From bowman at math.ualberta.ca  Thu Oct  4 13:23:05 2001
From: bowman at math.ualberta.ca (John Bowman)
Date: 4 Oct 2001 03:23:05 -0000
Subject: hang on exit - bug or no bug?
Message-ID: <20011004032305.7490.qmail@wizard.math.ualberta.ca>

> I haven't been able to find a sane way of avoiding the hang on exit 
> on Linux or Solaris. OpenBSD doesn't seem to have the problem - there 

On Linux, a patch to fix this openssh bug, without data loss, has been
available for some time now:

http://www.math.ualberta.ca/imaging/snfs/ 

-- John Bowman
University of Alberta

-- 


From mouring at etoh.eviladmin.org  Thu Oct  4 13:57:33 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 3 Oct 2001 22:57:33 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004032305.7490.qmail@wizard.math.ualberta.ca>
Message-ID: <Pine.BSO.4.33.0110032256430.9153-100000@etoh.eviladmin.org>



On 4 Oct 2001, John Bowman wrote:

> > I haven't been able to find a sane way of avoiding the hang on exit
> > on Linux or Solaris. OpenBSD doesn't seem to have the problem - there
>
> On Linux, a patch to fix this openssh bug, without data loss, has been
> available for some time now:
>
> http://www.math.ualberta.ca/imaging/snfs/
>

Again we went over this.. It causes data lost on other systems.  We are
not Linux centric.  If we ever became that I would leave.

- Ben



From serge.droz at psi.ch  Thu Oct  4 16:44:20 2001
From: serge.droz at psi.ch (Serge Droz)
Date: Thu, 04 Oct 2001 08:44:20 +0200
Subject: AFS and tokenforwarding
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se>
Message-ID: <3BBC0544.5E5BD29C@psi.ch>

Ok, here the rational for my patch. I haven't looked at the krb5 stuff
and hope I didn't break anything there.

As you say, public key authentication doesn't work in the 2.9.9p2
release.
This is becasue the AFS token get's passed too late, and sshd can't read 
the .ssh/* files on the remote system.

All I did (more or less) was to move the respective calls back to where
they where
in the pre 2.9.9p2 releases. 

I'm not sure why you think the tokens get passed unencrypted:

>ssh -v yyyy.psi.ch
OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
bla bla ....
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'llc1' is known and matches the RSA1 host key.
debug1: Found key in /afs/psi.ch/user/d/droz/.ssh/known_hosts:16
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Remote: AFS token accepted (afs at psi.ch, AFS ID 3789 at psi.ch)
debug1: Trying RSA authentication via agent with 'droz at xxxx.psi.ch'
debug1: Received RSA challenge from server.
debug1: Sending response to RSA challenge.
debug1: Remote: RSA authentication accepted.
debug1: RSA authentication accepted by server.
bla bla
Last login: Fri Sep 28 12:02:49 2001 from xxxx.psi.ch
>

Serge
> 
> I still feel I'm out of sync in this discussion so perhaps somebody
> can correct me. Meanwhile I have to make some guesses!
> 
> I assume that the problem is that public key authentication does not
> work in
> 
> RCSID("$OpenBSD: sshconnect1.c,v 1.31.2.1 2001/09/27 19:03:55 jason Exp $");
> 
> if the keys are stored in an read protected AFS directory.
> 
> To make it possible for sshd to read those read protected files in
> ~/.ssh it is necessary to first forward a valid AFS token. That can be
> achieved by moving the code:
> 
>         /* 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();
> 
> so that it happens before any files are accessed in the users home
> directory.
> 
> I guess that is what Serges patch was designed to do.
> 
> From a more general perspective one may reason that both AFS tokens
> and krb{4,5} tickets should be forwarded early to allow for access to
> files in remote home directories. I.e change the code to first forward
> AFS tokens, then krb4 tickets, and then krb5 tickets. If tickets are
> forwarded early, one must also be careful to handle ownership
> correctly. This should not be a problem with tokens since they are
> referenced via a PAG.
> 
> Objections anybody?
> 
> /Bjorn
> 
> --
>   _     _                                               ,_______________.
> Bjorn Gronvall (Bjorn Gronvall)                        /_______________/|
> Swedish Institute of Computer Science                  |               ||
> PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
> Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
> Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------'

-- 
Serge Droz
Paul Scherrer Institut                mailto:serge.droz at psi.ch
CH-5232 Villigen PSI                   Phone: ++41 56 310 3637
                                         Fax: ++41 56 310 3649


From bg at sics.se  Thu Oct  4 18:34:58 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 04 Oct 2001 10:34:58 +0200
Subject: AFS and tokenforwarding
In-Reply-To: Serge Droz's message of "Thu, 04 Oct 2001 08:44:20 +0200"
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch>
Message-ID: <wubsjnrefh.fsf@bg.sics.se>

>>>>> "Serge" == Serge Droz <serge.droz at psi.ch> writes:

Serge> All I did (more or less) was to move the respective calls back
Serge> to where they where in the pre 2.9.9p2 releases.

Sounds just fine.

Serge> I'm not sure why you think the tokens get passed unencrypted:

Don't think I ever said that. However, as I said in my letter one must
be a bit careful with ownership management of the forwarded
tickets. That should be simple to verify though.

Cheers,
Bj?rn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From dugsong at monkey.org  Thu Oct  4 18:41:54 2001
From: dugsong at monkey.org (Dug Song)
Date: Thu, 4 Oct 2001 04:41:54 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <Pine.GSO.4.33.0110031954490.1940-100000@shred.stanford.edu>; from bbense@networking.stanford.edu on Wed, Oct 03, 2001 at 07:58:14PM -0700
References: <20011003153906.L3563@naughty.monkey.org> <Pine.GSO.4.33.0110031954490.1940-100000@shred.stanford.edu>
Message-ID: <20011004044154.U3563@naughty.monkey.org>

On Wed, Oct 03, 2001 at 07:58:14PM -0700, Booker C. Bense wrote:

> - I think there are two problems being conflated into one. My patch
> is just to get the AFS code to compile when using Kth-1.1. It doesn't
> fix the problem of the token not being available when you need to
> access the filesystem. I think that was the point of the other
> patch posted.

sorry - i was indeed thinking of the other patch.

i remember now - the issue was, we didn't want to send Kerberos TGTs
or AFS tokens until authentication succeeded. i talked this over with
Markus at the time.

i know that this prevents things like RSA authentication when the user
needs AFS tokens to access their home directory, but i've always
regretted that this went into the original SSH-AFS patches (there was
some long debate about this on the mailing list, and i conceded to
popular opinion).

-d.

---
http://www.monkey.org/~dugsong/


From markus at openbsd.org  Thu Oct  4 18:46:51 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 4 Oct 2001 10:46:51 +0200
Subject: AFS and tokenforwarding
In-Reply-To: <wubsjnrefh.fsf@bg.sics.se>; from bg@sics.se on Thu, Oct 04, 2001 at 10:34:58AM +0200
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se>
Message-ID: <20011004104651.A15907@faui02.informatik.uni-erlangen.de>

On Thu, Oct 04, 2001 at 10:34:58AM +0200, Bjoern Groenvall wrote:
> Don't think I ever said that. However, as I said in my letter one must
> be a bit careful with ownership management of the forwarded
> tickets. That should be simple to verify though.

currently, i agree with Dug Song that the token should not be accpeted
by the server before client and server have authenticated each other.

this is why token handling was moved from auth1.c to session.c
when Dug imported Kerb5 to OpenSSH.

-m


From strube at physik3.gwdg.de  Thu Oct  4 21:14:26 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Thu, 4 Oct 2001 13:14:26 +0200 (MET DST)
Subject: PAM on Solaris
Message-ID: <200110041114.NAA24246@marc.physik3.gwdg.de>

When openssh-2.9.9p2 is configured with PAM on Solaris 7 (using the
system's default /etc/pam.conf) the passwd authentication works:
 debug1: PAM Password authentication accepted for user "strube"
 ...
 debug1: PAM setting tty to "/dev/pts/1"
 debug1: PAM establishing creds
but on logout a message is seen:
 debug1: Cannot delete credentials[7]: Permission denied

Why does this occur? Does it have adverse effects (e.g., credentials
accumulating, memory leak etc.)? How can it be avoided?


From phil-openssh-unix-dev at ipal.net  Thu Oct  4 21:20:39 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Thu, 4 Oct 2001 06:20:39 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110032256430.9153-100000@etoh.eviladmin.org> from "mouring@etoh.eviladmin.org" at Oct 03, 2001 10:57:33 PM
Message-ID: <20011004112039.2C66F234@vega.ipal.net>

mouring at etoh.eviladmin.org wrote:

> On 4 Oct 2001, John Bowman wrote:
> 
> > > I haven't been able to find a sane way of avoiding the hang on exit
> > > on Linux or Solaris. OpenBSD doesn't seem to have the problem - there
> >
> > On Linux, a patch to fix this openssh bug, without data loss, has been
> > available for some time now:
> >
> > http://www.math.ualberta.ca/imaging/snfs/
> >
> 
> Again we went over this.. It causes data lost on other systems.  We are
> not Linux centric.  If we ever became that I would leave.

If the patch can be done in such a way that it won't compile in
for systems where it won't work, e.g. conditional only to Linux,
then would that be acceptable to roll it in to the p versions?

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From serge.droz at psi.ch  Thu Oct  4 22:31:29 2001
From: serge.droz at psi.ch (Serge Droz)
Date: Thu, 04 Oct 2001 14:31:29 +0200
Subject: AFS and tokenforwarding
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de>
Message-ID: <3BBC56A1.59975DD1@psi.ch>

Markus Friedl wrote:
> 
> On Thu, Oct 04, 2001 at 10:34:58AM +0200, Bjoern Groenvall wrote:
> > Don't think I ever said that. However, as I said in my letter one must
> > be a bit careful with ownership management of the forwarded
> > tickets. That should be simple to verify though.
> 
> currently, i agree with Dug Song that the token should not be accpeted
> by the server before client and server have authenticated each other.
> 
> this is why token handling was moved from auth1.c to session.c
> when Dug imported Kerb5 to OpenSSH.
> 
> -m

This seems to be a matter of philosophy here. 
For us it's important that people can use PKA in an AFS environment. 
Why was this decission taken?
1) Maybe I missunderstand something here. What's the problem if a token
get's 
forwarded before the user is authenticicated? At the time the tokens
gets passed the data stream is encrypted. So there is no danger of
leaking a token. And if a user can create fake tokens and manipiulate
the public keys on the rompte system he's probably god or somthing, i.e.
you have a much bigger problem anyway.

2) This changes an established bahvior which will confuse users.

So what will happen here? Could this maybe become an option in the
sshd_config?
As I mentiond, we need this feature here, and I'd hate to have to have
my own ssh version.

Serge


-- 
Serge Droz
Paul Scherrer Institut                mailto:serge.droz at psi.ch
CH-5232 Villigen PSI                   Phone: ++41 56 310 3637


From Nicolas.Williams at ubsw.com  Thu Oct  4 23:22:23 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 09:22:23 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <3BBC56A1.59975DD1@psi.ch>; from serge.droz@psi.ch on Thu, Oct 04, 2001 at 02:31:29PM +0200
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch>
Message-ID: <20011004092222.K5739@sm2p1386swk.wdr.com>

On Thu, Oct 04, 2001 at 02:31:29PM +0200, Serge Droz wrote:
> Markus Friedl wrote:

[...]

> > currently, i agree with Dug Song that the token should not be accpeted
> > by the server before client and server have authenticated each other.

[...]

> > -m
> 
> This seems to be a matter of philosophy here. 
> For us it's important that people can use PKA in an AFS environment. 
> Why was this decission taken?
> 1) Maybe I missunderstand something here. What's the problem if a token
> get's 
> forwarded before the user is authenticicated? At the time the tokens
> gets passed the data stream is encrypted. So there is no danger of
> leaking a token. And if a user can create fake tokens and manipiulate
> the public keys on the rompte system he's probably god or somthing, i.e.
> you have a much bigger problem anyway.

If the token is forwarded before authentication then you don't know if
the server is really who you think it is, so you might be forwarding
your token to an impostor. Ooops.

> 2) This changes an established bahvior which will confuse users.
> 
> So what will happen here? Could this maybe become an option in the
> sshd_config?
> As I mentiond, we need this feature here, and I'd hate to have to have
> my own ssh version.

Perhaps there should be an option to specify a location for users' .ssh
dirs. Kinda like sendmail has an option to specify where .forward files
live, and for much the same reasons.

> Serge
> 
> 
> -- 
> Serge Droz
> Paul Scherrer Institut                mailto:serge.droz at psi.ch
> CH-5232 Villigen PSI                   Phone: ++41 56 310 3637


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  Thu Oct  4 23:31:44 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Oct 2001 23:31:44 +1000 (EST)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004112039.2C66F234@vega.ipal.net>
Message-ID: <Pine.LNX.4.33.0110042331360.1206-100000@mothra.mindrot.org>

On Thu, 4 Oct 2001, Phil Howard wrote:

> If the patch can be done in such a way that it won't compile in
> for systems where it won't work, e.g. conditional only to Linux,
> then would that be acceptable to roll it in to the p versions?

no

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From Nicolas.Williams at ubsw.com  Thu Oct  4 23:24:04 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 09:24:04 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004112039.2C66F234@vega.ipal.net>; from phil-openssh-unix-dev@ipal.net on Thu, Oct 04, 2001 at 06:20:39AM -0500
References: <Pine.BSO.4.33.0110032256430.9153-100000@etoh.eviladmin.org> <20011004112039.2C66F234@vega.ipal.net>
Message-ID: <20011004092403.L5739@sm2p1386swk.wdr.com>

This patch seems to do the same sort of thing being discussed in the
SIGCHLD race thread: add a timeout to the select(). If this is done only
when there's no child fildes left open, and only to break the SIGCHLD
race deadlock, then it can't lead to data loss (unless you're doing
something else wrong).

Nico


On Thu, Oct 04, 2001 at 06:20:39AM -0500, Phil Howard wrote:
> mouring at etoh.eviladmin.org wrote:
> 
> > On 4 Oct 2001, John Bowman wrote:
> > 
> > > > I haven't been able to find a sane way of avoiding the hang on exit
> > > > on Linux or Solaris. OpenBSD doesn't seem to have the problem - there
> > >
> > > On Linux, a patch to fix this openssh bug, without data loss, has been
> > > available for some time now:
> > >
> > > http://www.math.ualberta.ca/imaging/snfs/
> > >
> > 
> > Again we went over this.. It causes data lost on other systems.  We are
> > not Linux centric.  If we ever became that I would leave.
> 
> If the patch can be done in such a way that it won't compile in
> for systems where it won't work, e.g. conditional only to Linux,
> then would that be acceptable to roll it in to the p versions?
> 
> -- 
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
> | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.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 phil-openssh-unix-dev at ipal.net  Fri Oct  5 00:01:32 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Thu, 4 Oct 2001 09:01:32 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.LNX.4.33.0110042331360.1206-100000@mothra.mindrot.org> from "Damien Miller" at Oct 04, 2001 11:31:44 PM
Message-ID: <20011004140132.98739234@vega.ipal.net>

Damien Miller wrote:

> On Thu, 4 Oct 2001, Phil Howard wrote:
> 
> > If the patch can be done in such a way that it won't compile in
> > for systems where it won't work, e.g. conditional only to Linux,
> > then would that be acceptable to roll it in to the p versions?
> 
> no

So is this because the patch itself is undesired (flawed, incomplete,
not the right solution, or not a problem to be solved), or is it
because OS-specific conditional compilation is undesired?

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From mouring at etoh.eviladmin.org  Fri Oct  5 00:10:31 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 4 Oct 2001 09:10:31 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004140132.98739234@vega.ipal.net>
Message-ID: <Pine.BSO.4.33.0110040909340.9480-100000@etoh.eviladmin.org>



On Thu, 4 Oct 2001, Phil Howard wrote:

> Damien Miller wrote:
>
> > On Thu, 4 Oct 2001, Phil Howard wrote:
> >
> > > If the patch can be done in such a way that it won't compile in
> > > for systems where it won't work, e.g. conditional only to Linux,
> > > then would that be acceptable to roll it in to the p versions?
> >
> > no
>
> So is this because the patch itself is undesired (flawed, incomplete,
> not the right solution, or not a problem to be solved), or is it
> because OS-specific conditional compilation is undesired?
>

The patch itself is flawed and the flaws were already discussed on the
list.

- Ben



From phil-openssh-unix-dev at ipal.net  Fri Oct  5 00:12:02 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Thu, 4 Oct 2001 09:12:02 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004092403.L5739@sm2p1386swk.wdr.com> from "Nicolas Williams" at Oct 04, 2001 09:24:04 AM
Message-ID: <20011004141202.1764F234@vega.ipal.net>

Nicolas Williams wrote:

> This patch seems to do the same sort of thing being discussed in the
> SIGCHLD race thread: add a timeout to the select(). If this is done only
> when there's no child fildes left open, and only to break the SIGCHLD
> race deadlock, then it can't lead to data loss (unless you're doing
> something else wrong).

Actually, I would like to see a way to solve the situation where there
are hung processes.  In an interactive session I can do ^\. and get out
OK.  In a "batch" session this normally should not be a problem, but I
have seen it occur.  Now I do not want to trade it off to get the data
loss problem as that is worse.  If both cannot be fixed at the same time,
then hang is preferrable to data loss.  But I do think it should be
possible to get around the problem without data loss (aside from the
ambiguity of dealing with background processes, which for batch scripts
can be done the "right way" anyway).

I'm following this thread not because I have an urgent problem with
this (I don't) but rather to just get an understanding on the group
think and philosophy on how things like this are dealt with.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From markus at openbsd.org  Fri Oct  5 00:27:02 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 4 Oct 2001 16:27:02 +0200
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004140132.98739234@vega.ipal.net>; from phil-openssh-unix-dev@ipal.net on Thu, Oct 04, 2001 at 09:01:32AM -0500
References: <Pine.LNX.4.33.0110042331360.1206-100000@mothra.mindrot.org> <20011004140132.98739234@vega.ipal.net>
Message-ID: <20011004162701.C2314@faui02.informatik.uni-erlangen.de>

On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> So is this because the patch itself is undesired (flawed, incomplete,
> not the right solution, or not a problem to be solved), or is it
> because OS-specific conditional compilation is undesired?

it's because calling shutdown() before reading all remainig data from
the pipe is wrong.

it will cause data loss like the older so called bug fixes did.

we will include bug fixes, but only if they don't break ssh.


From Nicolas.Williams at ubsw.com  Fri Oct  5 00:37:07 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 10:37:07 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004162701.C2314@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Thu, Oct 04, 2001 at 04:27:02PM +0200
References: <Pine.LNX.4.33.0110042331360.1206-100000@mothra.mindrot.org> <20011004140132.98739234@vega.ipal.net> <20011004162701.C2314@faui02.informatik.uni-erlangen.de>
Message-ID: <20011004103706.M5739@sm2p1386swk.wdr.com>

I think the requestor here wants this behaviour and wants it to be
optional. This seems acceptable to me (not an OpenSSH maintainer), but:

I also think it's silly -- if you know you'll have children on the
server side hanging on to the fildes and you don't want them to, then
re-work what you're doing on the server side so that this hack is not
necessary.

Nico


On Thu, Oct 04, 2001 at 04:27:02PM +0200, Markus Friedl wrote:
> On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> > So is this because the patch itself is undesired (flawed, incomplete,
> > not the right solution, or not a problem to be solved), or is it
> > because OS-specific conditional compilation is undesired?
> 
> it's because calling shutdown() before reading all remainig data from
> the pipe is wrong.
> 
> it will cause data loss like the older so called bug fixes did.
> 
> we will include bug fixes, but only if they don't break ssh.
--

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 stephen.cooke at telewest.co.uk  Fri Oct  5 00:42:34 2001
From: stephen.cooke at telewest.co.uk (Stephen Cooke (KN))
Date: Thu, 4 Oct 2001 15:42:34 +0100
Subject: openssh 2.5.2 and above seem to have a feature I dont like.
Message-ID: <D376D4D39642D411B8D20008C7E61B7A02535F7C@KN-NW-XCHG-1>

When I issue commmands via 

ssh myuser at myhost
Once I am logged in, I issue a command like the one bolew

nohup commmand & 

and then logoff my session hangs until I issue a ~. 
this then returns me to the calling host.  

Any ideas what is causing this,  I am currently running openssh 2.9.9p2 on
AIX this still seems to have the problem.
regards
steve

------------------------------------------------------------------------------
Live Life in Broadband
www.telewest.co.uk


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material.
Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer.


==============================================================================



From dmahurin at berkeley.innomedia.com  Fri Oct  5 01:19:46 2001
From: dmahurin at berkeley.innomedia.com (Don Mahurin)
Date: Thu, 04 Oct 2001 08:19:46 -0700
Subject: patch - forceshell
References: <Pine.LNX.4.33.0110041248440.4445-100000@mothra.mindrot.org>
Message-ID: <3BBC7E11.50380983@berkeley.innomedia.com>

Damien Miller wrote:

> On Wed, 3 Oct 2001, Don Mahurin wrote:
>
> > Attached is a simple patch which allows an auth param 'shell=' like
> > 'command='
> > When specified, sshd will use this shell instead of the one in
> > /etc/passwd or the default shell.
> >
> > This patch allows you can have some chrooted shell (actually any shell)
> > associated with a specific key.
> > You could do this with command=, but then the command given to ssh will
> > be ignored, and scp will not work.
>
> You can get around this by using the $SSH_ORIGINAL_COMMAND env var.

This env var is really no help.

You could do:
   echo '$SSH_ORIGINAL_COMMAND' | ssh Host echo hi world
But why not just do:
   echo 'hi world' | ssh Host
And using scp, will require some wrapper script, or other magic.

I don't want any magic.  With a shell= auth param, the client side users need
to know nothing, and
can use unmodified ssh clients.

-don




From dschiebe at cisco.com  Fri Oct  5 02:11:18 2001
From: dschiebe at cisco.com (Schieber, Dustin)
Date: Thu, 4 Oct 2001 12:11:18 -0400 
Subject: hang on exit - bug or no bug?
Message-ID: <FC1C45AE08EFD211B9C600A0C96B86DA03921E55@rtp-xch1.cisco.com>

Yes, I think it would be nice to have this as an option. I'm not that
concerned about the inconvenience of a hang in an interactive session.
I've very concerned about batch jobs that hang.

I agree with you that it's best to just resolve the problem with the
open fds on the server side.  But again, this is a less than ideal
solution from a sysadmin's perspective.  Several of the issues I've
heard of involve scripts included with the OS. For example, I've
verified the hang occurs when simply restarting syslog or the snmp
agents on a Sun box.  (/etc/init.d/syslog stop|start)
(/etc/rc3.d/S76snmpdx stop|start).  Of course I can modify these scripts
to utilize the workaround. But it would be nice to have another
option...

I've also seen this problem with various 3rd party software packages.
Apparently this is a widespread problem with the open fds.  

Thanks! 
-das





> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> Sent: Thursday, October 04, 2001 10:37 AM
> To: Markus Friedl
> Cc: Phil Howard; openssh-unix-dev at mindrot.org
> Subject: Re: hang on exit - bug or no bug?
> 
> 
> I think the requestor here wants this behaviour and wants it to be
> optional. This seems acceptable to me (not an OpenSSH 
> maintainer), but:
> 
> I also think it's silly -- if you know you'll have children on the
> server side hanging on to the fildes and you don't want them to, then
> re-work what you're doing on the server side so that this hack is not
> necessary.
> 
> Nico
> 
> 
> On Thu, Oct 04, 2001 at 04:27:02PM +0200, Markus Friedl wrote:
> > On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> > > So is this because the patch itself is undesired (flawed, 
> incomplete,
> > > not the right solution, or not a problem to be solved), or is it
> > > because OS-specific conditional compilation is undesired?
> > 
> > it's because calling shutdown() before reading all remainig 
> data from
> > the pipe is wrong.
> > 
> > it will cause data loss like the older so called bug fixes did.
> > 
> > we will include bug fixes, but only if they don't break ssh.
> --
> 
> 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 pekkas at netcore.fi  Fri Oct  5 02:18:17 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 4 Oct 2001 19:18:17 +0300 (EEST)
Subject: hang on exit - bug or no bug?
In-Reply-To: <FC1C45AE08EFD211B9C600A0C96B86DA03921E55@rtp-xch1.cisco.com>
Message-ID: <Pine.LNX.4.33.0110041916520.28740-100000@netcore.fi>

On Thu, 4 Oct 2001, Schieber, Dustin wrote:
> I've also seen this problem with various 3rd party software packages.
> Apparently this is a widespread problem with the open fds.

It's probably a bug in the software -- e.g. fds not being closed when
forking.  This can have grave security considerations also.

-- 
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 Nicolas.Williams at ubsw.com  Fri Oct  5 02:21:27 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 12:21:27 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <FC1C45AE08EFD211B9C600A0C96B86DA03921E55@rtp-xch1.cisco.com>; from Schieber, Dustin on Thu, Oct 04, 2001 at 12:11:18PM -0400
References: <FC1C45AE08EFD211B9C600A0C96B86DA03921E55@rtp-xch1.cisco.com>
Message-ID: <20011004122127.A26615@wdr.com>

No, don't modify your OS' startup scripts, just run them differently.

Look, the fds are left open, so you potentially lose data, but you don't
care, right? So why not run those scripts like so:

ssh -n root at somehost /etc/init.d/syslog stop
ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1

?

You have this issue with RSH too you know. I long ago learned to deal
with this by manually redirecting stdio to /dev/null. And yes, sometimes
you care about some bit of command's output, because you may want to see
error msgs from /etc/init.d/syslog, say. There's a few solutions:

 - write a separate script for checking that the batch job is doing ok
 - use intr (yes, Solaris doesn't have one -- write one yourself) on the
   client side to set a timeout after which to kill ssh
 - write an intr-like command for the remote side that closes the fds
   after a timeout and which might be used like so:

   ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
 - fix the scripts


Nico


On Thu, Oct 04, 2001 at 12:11:18PM -0400, Schieber, Dustin wrote:
> Yes, I think it would be nice to have this as an option. I'm not that
> concerned about the inconvenience of a hang in an interactive session.
> I've very concerned about batch jobs that hang.
> 
> I agree with you that it's best to just resolve the problem with the
> open fds on the server side.  But again, this is a less than ideal
> solution from a sysadmin's perspective.  Several of the issues I've
> heard of involve scripts included with the OS. For example, I've
> verified the hang occurs when simply restarting syslog or the snmp
> agents on a Sun box.  (/etc/init.d/syslog stop|start)
> (/etc/rc3.d/S76snmpdx stop|start).  Of course I can modify these scripts
> to utilize the workaround. But it would be nice to have another
> option...
> 
> I've also seen this problem with various 3rd party software packages.
> Apparently this is a widespread problem with the open fds.  
> 
> Thanks! 
> -das
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> > Sent: Thursday, October 04, 2001 10:37 AM
> > To: Markus Friedl
> > Cc: Phil Howard; openssh-unix-dev at mindrot.org
> > Subject: Re: hang on exit - bug or no bug?
> > 
> > 
> > I think the requestor here wants this behaviour and wants it to be
> > optional. This seems acceptable to me (not an OpenSSH 
> > maintainer), but:
> > 
> > I also think it's silly -- if you know you'll have children on the
> > server side hanging on to the fildes and you don't want them to, then
> > re-work what you're doing on the server side so that this hack is not
> > necessary.
> > 
> > Nico
> > 
> > 
> > On Thu, Oct 04, 2001 at 04:27:02PM +0200, Markus Friedl wrote:
> > > On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> > > > So is this because the patch itself is undesired (flawed, 
> > incomplete,
> > > > not the right solution, or not a problem to be solved), or is it
> > > > because OS-specific conditional compilation is undesired?
> > > 
> > > it's because calling shutdown() before reading all remainig 
> > data from
> > > the pipe is wrong.
> > > 
> > > it will cause data loss like the older so called bug fixes did.
> > > 
> > > we will include bug fixes, but only if they don't break ssh.
> > --
> > 
> > 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.
> > 
--
-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  Fri Oct  5 02:26:05 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 12:26:05 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.LNX.4.33.0110041916520.28740-100000@netcore.fi>; from pekkas@netcore.fi on Thu, Oct 04, 2001 at 07:18:17PM +0300
References: <FC1C45AE08EFD211B9C600A0C96B86DA03921E55@rtp-xch1.cisco.com> <Pine.LNX.4.33.0110041916520.28740-100000@netcore.fi>
Message-ID: <20011004122604.N5739@sm2p1386swk.wdr.com>

On Thu, Oct 04, 2001 at 07:18:17PM +0300, Pekka Savola wrote:
> On Thu, 4 Oct 2001, Schieber, Dustin wrote:
> > I've also seen this problem with various 3rd party software packages.
> > Apparently this is a widespread problem with the open fds.
> 
> It's probably a bug in the software -- e.g. fds not being closed when
> forking.  This can have grave security considerations also.

Right. All the more reason to manually redirect stdio to /dev/null folks.

> -- 
> 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
--

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 pekkas at netcore.fi  Fri Oct  5 02:30:06 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 4 Oct 2001 19:30:06 +0300 (EEST)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004122127.A26615@wdr.com>
Message-ID: <Pine.LNX.4.33.0110041928050.28740-100000@netcore.fi>

On Thu, 4 Oct 2001, Nicolas Williams wrote:

> No, don't modify your OS' startup scripts, just run them differently.
>
> Look, the fds are left open, so you potentially lose data, but you don't
> care, right? So why not run those scripts like so:
>
> ssh -n root at somehost /etc/init.d/syslog stop
> ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1

IMO, if 'ssh root at somehost /etc/init.d/syslog restart' hangs, it's
probably syslogd at fault there, not the scripts.

-- 
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 mjr at knoware.com  Fri Oct  5 02:54:04 2001
From: mjr at knoware.com (Michael J. Ryan)
Date: Thu, 4 Oct 2001 12:54:04 -0400
Subject: FTP Port Forwarding & SSH2_MSG_CHANNEL_DATA question
Message-ID: <NBBBIJIPGPDGCLNPMFJNCENGELAA.mjr@knoware.com>

Hi,
 I'm currently working on an FTP utility which contains
SSH2/Port Forwarding functionality. I'm having a problem with
receiving large amounts of data. When I open my forwarding
channel, I give it a Window Size, say about 10K. When I try
to download a file through the forwarded FTP channel, the 
SSH2 server (VShell in this case) is only sending over 10K.

Apparently the server will only send over the amount that will
fit within your Window Session Size. My question is...how do
I get around this? Do I need to send a Window Adjust message 
over to the server to reset the size, or should I set Xon/Xoff?

I've checked through the man's but was unable to find any 
concrete answer.

I'm using OpenSSH v2.2...

Thanks in advance!

Michael Ryan


From dschiebe at cisco.com  Fri Oct  5 03:18:33 2001
From: dschiebe at cisco.com (Schieber, Dustin)
Date: Thu, 4 Oct 2001 13:18:33 -0400 
Subject: hang on exit - bug or no bug?
Message-ID: <FC1C45AE08EFD211B9C600A0C96B86DA03921E57@rtp-xch1.cisco.com>

I definately don't have the same problem with rsh, and never had it with
ssh 1.2.31.  It was only after upgrading to Openssh that we experienced
this problem. I can't dispute what has been said about the the code in
1.2.31.  I can only state what my experience has been... we did not have
this hanging problem with 1.2.31. 

Your suggested workarounds have been discussed and in some cases already
implemented on our hosts.   But the perception in my organization has
been that Openssh is "broken" because this was not a problem before. The
FAQ provides very little documentation on this problem, it's unclear if
it's considered a bug or not.  

This thread has been very helpful in understanding the issue, thanks for
all the information.  And thanks to all of the developers who have
worked on this software.  It is working well for us and we are generally
very happy with it. 
thx,
-das




> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> Sent: Thursday, October 04, 2001 12:21 PM
> To: Schieber, Dustin; Markus Friedl
> Cc: Phil Howard; openssh-unix-dev at mindrot.org
> Subject: Re: hang on exit - bug or no bug?
> 
> 
> No, don't modify your OS' startup scripts, just run them differently.
> 
> Look, the fds are left open, so you potentially lose data, 
> but you don't
> care, right? So why not run those scripts like so:
> 
> ssh -n root at somehost /etc/init.d/syslog stop
> ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1
> 
> ?
> 
> You have this issue with RSH too you know. I long ago learned to deal
> with this by manually redirecting stdio to /dev/null. And 
> yes, sometimes
> you care about some bit of command's output, because you may 
> want to see
> error msgs from /etc/init.d/syslog, say. There's a few solutions:
> 
>  - write a separate script for checking that the batch job is doing ok
>  - use intr (yes, Solaris doesn't have one -- write one 
> yourself) on the
>    client side to set a timeout after which to kill ssh
>  - write an intr-like command for the remote side that closes the fds
>    after a timeout and which might be used like so:
> 
>    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
>  - fix the scripts
> 
> 
> Nico
> 
> 
> On Thu, Oct 04, 2001 at 12:11:18PM -0400, Schieber, Dustin wrote:
> > Yes, I think it would be nice to have this as an option. 
> I'm not that
> > concerned about the inconvenience of a hang in an 
> interactive session.
> > I've very concerned about batch jobs that hang.
> > 
> > I agree with you that it's best to just resolve the problem with the
> > open fds on the server side.  But again, this is a less than ideal
> > solution from a sysadmin's perspective.  Several of the issues I've
> > heard of involve scripts included with the OS. For example, I've
> > verified the hang occurs when simply restarting syslog or the snmp
> > agents on a Sun box.  (/etc/init.d/syslog stop|start)
> > (/etc/rc3.d/S76snmpdx stop|start).  Of course I can modify 
> these scripts
> > to utilize the workaround. But it would be nice to have another
> > option...
> > 
> > I've also seen this problem with various 3rd party software 
> packages.
> > Apparently this is a widespread problem with the open fds.  
> > 
> > Thanks! 
> > -das
> > 
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> > > Sent: Thursday, October 04, 2001 10:37 AM
> > > To: Markus Friedl
> > > Cc: Phil Howard; openssh-unix-dev at mindrot.org
> > > Subject: Re: hang on exit - bug or no bug?
> > > 
> > > 
> > > I think the requestor here wants this behaviour and wants it to be
> > > optional. This seems acceptable to me (not an OpenSSH 
> > > maintainer), but:
> > > 
> > > I also think it's silly -- if you know you'll have children on the
> > > server side hanging on to the fildes and you don't want 
> them to, then
> > > re-work what you're doing on the server side so that this 
> hack is not
> > > necessary.
> > > 
> > > Nico
> > > 
> > > 
> > > On Thu, Oct 04, 2001 at 04:27:02PM +0200, Markus Friedl wrote:
> > > > On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> > > > > So is this because the patch itself is undesired (flawed, 
> > > incomplete,
> > > > > not the right solution, or not a problem to be 
> solved), or is it
> > > > > because OS-specific conditional compilation is undesired?
> > > > 
> > > > it's because calling shutdown() before reading all remainig 
> > > data from
> > > > the pipe is wrong.
> > > > 
> > > > it will cause data loss like the older so called bug fixes did.
> > > > 
> > > > we will include bug fixes, but only if they don't break ssh.
> > > --
> > > 
> > > 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.
> > > 
> --
> -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 sxw at dcs.ed.ac.uk  Fri Oct  5 03:58:24 2001
From: sxw at dcs.ed.ac.uk (Simon Wilkinson)
Date: Thu, 4 Oct 2001 18:58:24 +0100 (BST)
Subject: AFS and tokenforwarding
In-Reply-To: Nicolas Williams's message of Thu, 4 Oct 2001 09:22:23 -0400
Message-ID: <200110041758.SAA07313@canna.dcs.ed.ac.uk>

> If the token is forwarded before authentication then you don't know if
> the server is really who you think it is, so you might be forwarding
> your token to an impostor. Ooops.

But, assuming this is a Kerberos token you are discussing, is the
token not protected by being encrypted with the session key, which in
turn is encrypted with the server's host key?

So, an imposter could get something to brute force, but they could get
that via a passive attack anyway.

I would agree however, that forwarding a TGT _before_ the users credentials
have been accepted seems theoretically wrong, however practically safe it
may be.

Cheers,

Simon.


From Nicolas.Williams at ubsw.com  Fri Oct  5 04:09:35 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 14:09:35 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <200110041758.SAA07313@canna.dcs.ed.ac.uk>; from Simon Wilkinson on Thu, Oct 04, 2001 at 06:58:24PM +0100
References: <200110041758.SAA07313@canna.dcs.ed.ac.uk>
Message-ID: <20011004140935.F26615@wdr.com>

On Thu, Oct 04, 2001 at 06:58:24PM +0100, Simon Wilkinson wrote:
> > If the token is forwarded before authentication then you don't know if
> > the server is really who you think it is, so you might be forwarding
> > your token to an impostor. Ooops.
> 
> But, assuming this is a Kerberos token you are discussing, is the
> token not protected by being encrypted with the session key, which in
> turn is encrypted with the server's host key?

Yes, but if the token is not going to be useful until after [Kerberos]
authentication then why bother sending it early?

> So, an imposter could get something to brute force, but they could get
> that via a passive attack anyway.
> 
> I would agree however, that forwarding a TGT _before_ the users credentials
> have been accepted seems theoretically wrong, however practically safe it
> may be.
> 
> Cheers,
> 
> Simon.


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 bg at sics.se  Fri Oct  5 05:15:23 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 04 Oct 2001 21:15:23 +0200
Subject: AFS and tokenforwarding
In-Reply-To: Nicolas Williams's message of "Thu, 4 Oct 2001 09:22:23 -0400"
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com>
Message-ID: <wuzo77p67o.fsf@bg.sics.se>

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at ubsw.com> writes:

Nicolas> If the token is forwarded before authentication then you
Nicolas> don't know if the server is really who you think it is, so
Nicolas> you might be forwarding your token to an impostor. Ooops.

I don't think any of the ssh (at least v1) authentication mechanisms
really authenticate the server. A masquerading server can always
forward the authentication information to the real server and use that
response as a legitimate reply. Thus you may still be passing
credentials down to an impostor. Either way you do it, you can always
be fooled. A similar problem exists with the common "pass passwords in
the clear" methods used by ssh. Hopefully this is fixed in v2 but I
never really bothered to check.

/Bj?rn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From bg at sics.se  Fri Oct  5 05:23:53 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 04 Oct 2001 21:23:53 +0200
Subject: AFS and tokenforwarding
In-Reply-To: Simon Wilkinson's message of "Thu, 4 Oct 2001 18:58:24 +0100 (BST)"
References: <200110041758.SAA07313@canna.dcs.ed.ac.uk>
Message-ID: <wuwv2bp5ti.fsf@bg.sics.se>

>>>>> "Simon" == Simon Wilkinson <sxw at dcs.ed.ac.uk> writes:

>> If the token is forwarded before authentication then you don't know
>> if the server is really who you think it is, so you might be
>> forwarding your token to an impostor. Ooops.

Simon> But, assuming this is a Kerberos token you are discussing, is
Simon> the token not protected by being encrypted with the session
Simon> key, which in turn is encrypted with the server's host key?

The token is passed in a "usable form", i.e both ticket and the
corresponding session key is passed.

Simon> So, an imposter could get something to brute force, but they
Simon> could get that via a passive attack anyway.

No brute force is required.

Simon> I would agree however, that forwarding a TGT _before_ the users
Simon> credentials have been accepted seems theoretically wrong,
Simon> however practically safe it may be.

The user should not forward a TGT before the server has been
authenticated. With ssh v1 this is however not possible, regardless if
this is done before or after user authentication the server is still
not properly authenticated.

Cheers,
Bj?rn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From Nicolas.Williams at ubsw.com  Fri Oct  5 05:23:59 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 15:23:59 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <wuzo77p67o.fsf@bg.sics.se>; from Bjoern Groenvall on Thu, Oct 04, 2001 at 09:15:23PM +0200
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com> <wuzo77p67o.fsf@bg.sics.se>
Message-ID: <20011004152359.G26615@wdr.com>

I was thinking that AFS token passing would be mixed with Kerberos
network authentication. If it's Kerberos V then I'd expect mutual auth
to be used.

Then again, I've ever used SSHv1 with Kerberos -- only SSHv2 with
GSS/Kerberos (thanks to Simon Wilkinson's patches) and SSH w/ GSS *does*
require mutual authentication.

So how will you make AFS token passing in SSHv2?

I think you'll need to store .ssh dirs not in home directories, but
somewhere that allows world readability. With Secure NFS this problem
goes away since any client with root/fqdn at REALM principals gets read
access as "nobody" so that, if ~/.ssh and ~/.ssh/authorized_keys* are
world-readable, then sshd can read them before installing the user's
creds (alternatively, it can install them early, then remove them if
authorization fails).

Nico


On Thu, Oct 04, 2001 at 09:15:23PM +0200, Bjoern Groenvall wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at ubsw.com> writes:
> 
> Nicolas> If the token is forwarded before authentication then you
> Nicolas> don't know if the server is really who you think it is, so
> Nicolas> you might be forwarding your token to an impostor. Ooops.
> 
> I don't think any of the ssh (at least v1) authentication mechanisms
> really authenticate the server. A masquerading server can always
> forward the authentication information to the real server and use that
> response as a legitimate reply. Thus you may still be passing
> credentials down to an impostor. Either way you do it, you can always
> be fooled. A similar problem exists with the common "pass passwords in
> the clear" methods used by ssh. Hopefully this is fixed in v2 but I
> never really bothered to check.
> 
> /Bj?rn
> 
> -- 
>   _     _                                               ,_______________.  
> Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
> Swedish Institute of Computer Science                  |               ||
> PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
> Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
> Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 
--
-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 dugsong at monkey.org  Fri Oct  5 05:34:34 2001
From: dugsong at monkey.org (Dug Song)
Date: Thu, 4 Oct 2001 15:34:34 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <wuwv2bp5ti.fsf@bg.sics.se>; from bg@sics.se on Thu, Oct 04, 2001 at 09:23:53PM +0200
References: <200110041758.SAA07313@canna.dcs.ed.ac.uk> <wuwv2bp5ti.fsf@bg.sics.se>
Message-ID: <20011004153434.C9634@naughty.monkey.org>

On Thu, Oct 04, 2001 at 09:23:53PM +0200, Bjoern Groenvall wrote:

> The token is passed in a "usable form", i.e both ticket and the
> corresponding session key is passed.

yep, this is why people liked it, so they could use RSA auth with AFS
home directories. but i never liked this. i suppose we could make this
configurable, but this is somewhat scary...

> The user should not forward a TGT before the server has been
> authenticated. With ssh v1 this is however not possible, regardless if
> this is done before or after user authentication the server is still
> not properly authenticated.

? 

SSH-1 krb4 support requires the server to return the incremented
challenge successfully encrypted with the session key.

-d.

---
http://www.monkey.org/~dugsong/


From bg at sics.se  Fri Oct  5 05:43:29 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 04 Oct 2001 21:43:29 +0200
Subject: AFS and tokenforwarding
In-Reply-To: Nicolas Williams's message of "Thu, 4 Oct 2001 15:23:59 -0400"
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com> <wuzo77p67o.fsf@bg.sics.se> <20011004152359.G26615@wdr.com>
Message-ID: <wuu1xfp4wu.fsf@bg.sics.se>

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at ubsw.com> writes:

Nicolas> I was thinking that AFS token passing would be mixed with
Nicolas> Kerberos network authentication. If it's Kerberos V then I'd
Nicolas> expect mutual auth to be used.

Yes, kerberos mutual authentication is used, however it is used the
wrong way. A masquerading server can use the real server as an
oracle. Thus mutual authentication is used, but it does not really
provide any mutual authentication.

Nicolas> Then again, I've ever used SSHv1 with Kerberos -- only SSHv2
Nicolas> with GSS/Kerberos (thanks to Simon Wilkinson's patches) and
Nicolas> SSH w/ GSS *does* require mutual authentication.

Hopefully this is done right in v2, I don't enough about v2 though.

Nicolas> So how will you make AFS token passing in SSHv2?

I don't really now enough about the details of v2 authentication and
session key generation. In theory, it should be possible to pass the
token (encrypted) along with the authentication information in such a
format so that only a legitimate server can unpack the token. If this
matches the v2 model, I simply don't know.

Cheers,
Bj?rn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From bg at sics.se  Fri Oct  5 05:49:42 2001
From: bg at sics.se (Bjoern Groenvall)
Date: 04 Oct 2001 21:49:42 +0200
Subject: AFS and tokenforwarding
In-Reply-To: Dug Song's message of "Thu, 4 Oct 2001 15:34:34 -0400"
References: <200110041758.SAA07313@canna.dcs.ed.ac.uk> <wuwv2bp5ti.fsf@bg.sics.se> <20011004153434.C9634@naughty.monkey.org>
Message-ID: <wupu83p4mh.fsf@bg.sics.se>

>>>>> "Dug" == Dug Song <dugsong at monkey.org> writes:

>> The user should not forward a TGT before the server has been
>> authenticated. With ssh v1 this is however not possible, regardless
>> if this is done before or after user authentication the server is
>> still not properly authenticated.

Dug> ?

Dug> SSH-1 krb4 support requires the server to return the incremented
Dug> challenge successfully encrypted with the session key.

You can use the real server to increment the challenge for you. The
kerberos session key is only used for this. The kerberos session key
should really really be used to change the ssh session key so that the
tunnel between client and masquerading server breaks.

Cheers,
Bj?rn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Bj?rn Gr?nvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 


From Nicolas.Williams at ubsw.com  Fri Oct  5 05:53:49 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 15:53:49 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <wuu1xfp4wu.fsf@bg.sics.se>; from Bjoern Groenvall on Thu, Oct 04, 2001 at 09:43:29PM +0200
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com> <wuzo77p67o.fsf@bg.sics.se> <20011004152359.G26615@wdr.com> <wuu1xfp4wu.fsf@bg.sics.se>
Message-ID: <20011004155349.H26615@wdr.com>

On Thu, Oct 04, 2001 at 09:43:29PM +0200, Bjoern Groenvall wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at ubsw.com> writes:
> 
> Nicolas> I was thinking that AFS token passing would be mixed with
> Nicolas> Kerberos network authentication. If it's Kerberos V then I'd
> Nicolas> expect mutual auth to be used.
> 
> Yes, kerberos mutual authentication is used, however it is used the
> wrong way. A masquerading server can use the real server as an
> oracle. Thus mutual authentication is used, but it does not really
> provide any mutual authentication.

??? How? In Kerberos V I don't see how.

> Nicolas> Then again, I've ever used SSHv1 with Kerberos -- only SSHv2
> Nicolas> with GSS/Kerberos (thanks to Simon Wilkinson's patches) and
> Nicolas> SSH w/ GSS *does* require mutual authentication.
> 
> Hopefully this is done right in v2, I don't enough about v2 though.
> 
> Nicolas> So how will you make AFS token passing in SSHv2?
> 
> I don't really now enough about the details of v2 authentication and
> session key generation. In theory, it should be possible to pass the
> token (encrypted) along with the authentication information in such a
> format so that only a legitimate server can unpack the token. If this
> matches the v2 model, I simply don't know.

There's two competing SSH/GSS proposals. The better one (IMHO) is
implemented by patches posted here (*). GSS-API is used, which means,
for Kerberos, that the AP_REQ and KRB_CREDS are sent together on the
first token, but the KRB_CREDS are sent doubly encrypted in the
authenticator checksum field (a gross network optimization hack --
sigh). The patches I'm referring to require mutual authentication.
Session key generation can be done in either of two ways: GSS-protected
Diffie-Hellman exchange (which eschews the SSH host keys) or SSHv2 host
key based session key generation and SSH-protected GSS exchange.

(*) http://www.sxw.org.uk/computing/patches/

> Cheers,
> Bj?rn
> 

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 dugsong at monkey.org  Fri Oct  5 06:55:43 2001
From: dugsong at monkey.org (Dug Song)
Date: Thu, 4 Oct 2001 16:55:43 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <20011004152359.G26615@wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Oct 04, 2001 at 03:23:59PM -0400
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com> <wuzo77p67o.fsf@bg.sics.se> <20011004152359.G26615@wdr.com>
Message-ID: <20011004165543.D9634@naughty.monkey.org>

On Thu, Oct 04, 2001 at 03:23:59PM -0400, Nicolas Williams wrote:

> Then again, I've ever used SSHv1 with Kerberos -- only SSHv2 with
> GSS/Kerberos (thanks to Simon Wilkinson's patches) and SSH w/ GSS *does*
> require mutual authentication.
> 
> So how will you make AFS token passing in SSHv2?

maybe GSS? i don't know which protocol namespace we can shoehorn this in...

> I think you'll need to store .ssh dirs not in home directories, but
> somewhere that allows world readability.

you can fudge this in AFS with symlinks to publicly-readable
(system:anyuser rl) directories.

-d.

---
http://www.monkey.org/~dugsong/


From dugsong at monkey.org  Fri Oct  5 07:00:44 2001
From: dugsong at monkey.org (Dug Song)
Date: Thu, 4 Oct 2001 17:00:44 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <wupu83p4mh.fsf@bg.sics.se>; from bg@sics.se on Thu, Oct 04, 2001 at 09:49:42PM +0200
References: <200110041758.SAA07313@canna.dcs.ed.ac.uk> <wuwv2bp5ti.fsf@bg.sics.se> <20011004153434.C9634@naughty.monkey.org> <wupu83p4mh.fsf@bg.sics.se>
Message-ID: <20011004170044.E9634@naughty.monkey.org>

On Thu, Oct 04, 2001 at 09:49:42PM +0200, Bjoern Groenvall wrote:

> You can use the real server to increment the challenge for you. The
> kerberos session key is only used for this. The kerberos session key
> should really really be used to change the ssh session key so that the
> tunnel between client and masquerading server breaks.

yes, there's been argument over this before as well, and whether to
just GSSify all of SSH anyhow, since there's so much overlap. :-/

hrr, an easy interim solution would be to encrypt the SSH session key
(or an HMAC of the challenge with the key) with the Kerberos session
key however nasty this is...

-d.

---
http://www.monkey.org/~dugsong/


From serge.droz at psi.ch  Fri Oct  5 06:59:38 2001
From: serge.droz at psi.ch (Serge Droz)
Date: Thu, 04 Oct 2001 22:59:38 +0200
Subject: AFS and tokenforwarding
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com>
Message-ID: <3BBCCDBA.53CEDAA4@psi.ch>

> 
> If the token is forwarded before authentication then you don't know if
> the server is really who you think it is, so you might be forwarding
> your token to an impostor. Ooops.
> 
Now what do you mean by that?
The server is authenticated (vi the server key) before the token is
passed.
You can't do any better (at least in ssh1). 
If I can fake that, then I can always authenticate a user by his
password
(Just accept anything). 
And now I just accept the token. 
What is teh point of tokenpassing under AFS? If I have to use my afs
password, I'll get a tokem anyway, so I won't need to pass one. 
So what is it I don't see?
> > 2) This changes an established bahvior which will confuse users.
> >
> > So what will happen here? Could this maybe become an option in the
> > sshd_config?
> > As I mentiond, we need this feature here, and I'd hate to have to have
> > my own ssh version.
> 
> Perhaps there should be an option to specify a location for users' .ssh
> dirs. Kinda like sendmail has an option to specify where .forward files
> live, and for much the same reasons.
> 
You can set the acl's under afs to world readable, so sshd can read the
authorized hosts file. This is not really recomended practice though. 
The point is, that under afs not even root can read your files (in fact
root is treated just like any other user). 


Serge


-- 
Serge Droz
Paul Scherrer Institut                mailto:serge.droz at psi.ch
CH-5232 Villigen PSI                   Phone: ++41 56 310 3637


From Nicolas.Williams at ubsw.com  Fri Oct  5 07:04:03 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 4 Oct 2001 17:04:03 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <20011004170044.E9634@naughty.monkey.org>; from Dug Song on Thu, Oct 04, 2001 at 05:00:44PM -0400
References: <200110041758.SAA07313@canna.dcs.ed.ac.uk> <wuwv2bp5ti.fsf@bg.sics.se> <20011004153434.C9634@naughty.monkey.org> <wupu83p4mh.fsf@bg.sics.se> <20011004170044.E9634@naughty.monkey.org>
Message-ID: <20011004170403.I26615@wdr.com>

On Thu, Oct 04, 2001 at 05:00:44PM -0400, Dug Song wrote:
> On Thu, Oct 04, 2001 at 09:49:42PM +0200, Bjoern Groenvall wrote:
> 
> > You can use the real server to increment the challenge for you. The
> > kerberos session key is only used for this. The kerberos session key
> > should really really be used to change the ssh session key so that the
> > tunnel between client and masquerading server breaks.
> 
> yes, there's been argument over this before as well, and whether to
> just GSSify all of SSH anyhow, since there's so much overlap. :-/
> 
> hrr, an easy interim solution would be to encrypt the SSH session key
> (or an HMAC of the challenge with the key) with the Kerberos session
> key however nasty this is...
> 
> -d.
> 
> ---
> http://www.monkey.org/~dugsong/

One of the two competing GSS-in-SSH proposals as an option to do just
this as a GSS-protected Diffie-Hellman key exchange.

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 dugsong at monkey.org  Fri Oct  5 07:12:52 2001
From: dugsong at monkey.org (Dug Song)
Date: Thu, 4 Oct 2001 17:12:52 -0400
Subject: AFS and tokenforwarding
In-Reply-To: <3BBCCDBA.53CEDAA4@psi.ch>; from serge.droz@psi.ch on Thu, Oct 04, 2001 at 10:59:38PM +0200
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com> <3BBCCDBA.53CEDAA4@psi.ch>
Message-ID: <20011004171252.F9634@naughty.monkey.org>

On Thu, Oct 04, 2001 at 10:59:38PM +0200, Serge Droz wrote:

> Now what do you mean by that?  The server is authenticated (vi the
> server key) before the token is passed.  You can't do any better (at
> least in ssh1).

that's kind of the point. it isn't real authentication, it's user
acceptance of server credentials which may actually be from a
man-in-the-middle.

> What is teh point of tokenpassing under AFS? If I have to use my afs
> password, I'll get a tokem anyway, so I won't need to pass one.

you may have tokens for multiple cells you wish to pass transparently.

-d.

---
http://www.monkey.org/~dugsong/


From markus at openbsd.org  Fri Oct  5 07:28:15 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 4 Oct 2001 23:28:15 +0200
Subject: AFS and tokenforwarding
In-Reply-To: <wuzo77p67o.fsf@bg.sics.se>; from bg@sics.se on Thu, Oct 04, 2001 at 09:15:23PM +0200
References: <Pine.BSO.4.33.0110031338240.27777-100000@etoh.eviladmin.org> <wuelokr0cg.fsf@bg.sics.se> <3BBC0544.5E5BD29C@psi.ch> <wubsjnrefh.fsf@bg.sics.se> <20011004104651.A15907@faui02.informatik.uni-erlangen.de> <3BBC56A1.59975DD1@psi.ch> <20011004092222.K5739@sm2p1386swk.wdr.com> <wuzo77p67o.fsf@bg.sics.se>
Message-ID: <20011004232815.B13911@folly>

On Thu, Oct 04, 2001 at 09:15:23PM +0200, Bjoern Groenvall wrote:
> Nicolas> If the token is forwarded before authentication then you
> Nicolas> don't know if the server is really who you think it is, so
> Nicolas> you might be forwarding your token to an impostor. Ooops.
> 
> I don't think any of the ssh (at least v1) authentication mechanisms
> really authenticate the server.

this depends on how the host key is authenticated. server
authentication is as strong as the host key authentication.

> A masquerading server can always
> forward the authentication information to the real server and use that
> response as a legitimate reply. Thus you may still be passing
> credentials down to an impostor. Either way you do it, you can always
> be fooled. A similar problem exists with the common "pass passwords in
> the clear" methods used by ssh. Hopefully this is fixed in v2 but I
> never really bothered to check.

same thing can happen in ssh v2 unless you use pubkey authentication.
successful pubkey authentication is only possible if there is no MITM.


From markus at openbsd.org  Fri Oct  5 07:33:51 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 4 Oct 2001 23:33:51 +0200
Subject: FTP Port Forwarding & SSH2_MSG_CHANNEL_DATA question
In-Reply-To: <NBBBIJIPGPDGCLNPMFJNCENGELAA.mjr@knoware.com>; from mjr@knoware.com on Thu, Oct 04, 2001 at 12:54:04PM -0400
References: <NBBBIJIPGPDGCLNPMFJNCENGELAA.mjr@knoware.com>
Message-ID: <20011004233351.C13911@folly>

On Thu, Oct 04, 2001 at 12:54:04PM -0400, Michael J. Ryan wrote:
> Apparently the server will only send over the amount that will
> fit within your Window Session Size. My question is...how do
> I get around this? Do I need to send a Window Adjust message 
> over to the server to reset the size, or should I set Xon/Xoff?

no need or xon/xoff, check the openssh source
and the ietf drafts.


From jakob at crt.se  Fri Oct  5 07:54:52 2001
From: jakob at crt.se (Jakob Schlyter)
Date: Thu, 4 Oct 2001 23:54:52 +0200 (MEST)
Subject: AFS and tokenforwarding
In-Reply-To: <20011004092222.K5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.BSO.4.40.0110042352530.4257-100000@fonbella.crt.se>

[recipients trimmed]

On Thu, 4 Oct 2001, Nicolas Williams wrote:

> Perhaps there should be an option to specify a location for users' .ssh
> dirs. Kinda like sendmail has an option to specify where .forward files
> live, and for much the same reasons.

the AuthorizedKeysFile server option can be used for this.

	jakob



From tim at multitalents.net  Fri Oct  5 08:36:13 2001
From: tim at multitalents.net (Tim Rice)
Date: Thu, 4 Oct 2001 15:36:13 -0700 (PDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004122127.A26615@wdr.com>
Message-ID: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>

On Thu, 4 Oct 2001, Nicolas Williams wrote:

> No, don't modify your OS' startup scripts, just run them differently.
>
> Look, the fds are left open, so you potentially lose data, but you don't
> care, right? So why not run those scripts like so:
>
> ssh -n root at somehost /etc/init.d/syslog stop
> ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1
>
> ?
>
> You have this issue with RSH too you know. I long ago learned to deal
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What's bothering so many people, is there are a number of platforms
where ssh hangs but rsh does not.
(Anyone have source to Solaris, UnixWare, SCO, ......) ;-)

> with this by manually redirecting stdio to /dev/null. And yes, sometimes
> you care about some bit of command's output, because you may want to see
> error msgs from /etc/init.d/syslog, say. There's a few solutions:
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From mouring at etoh.eviladmin.org  Fri Oct  5 09:04:39 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 4 Oct 2001 18:04:39 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>
Message-ID: <Pine.BSO.4.33.0110041802390.24291-100000@etoh.eviladmin.org>



On Thu, 4 Oct 2001, Tim Rice wrote:

> On Thu, 4 Oct 2001, Nicolas Williams wrote:
>
> > No, don't modify your OS' startup scripts, just run them differently.
> >
> > Look, the fds are left open, so you potentially lose data, but you don't
> > care, right? So why not run those scripts like so:
> >
> > ssh -n root at somehost /etc/init.d/syslog stop
> > ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1
> >
> > ?
> >
> > You have this issue with RSH too you know. I long ago learned to deal
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> What's bothering so many people, is there are a number of platforms
> where ssh hangs but rsh does not.
> (Anyone have source to Solaris, UnixWare, SCO, ......) ;-)
>
solaris 8 I will admit to having source to..  SCO and UnixWare I don't..
and I don't talk about other ones.. =)  If I know what I was looking for
I'd be happy to beg and borrow selective pieces of source code from
friends to investigate.  But I still am not dead sure what to look for.

- Ben



From sturle.sunde at usit.uio.no  Fri Oct  5 09:04:40 2001
From: sturle.sunde at usit.uio.no (Sturle Sunde)
Date: 05 Oct 2001 01:04:40 +0200
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>
References: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>
Message-ID: <riq4rpf2eif.fsf@aqualene.uio.no>

Tim Rice <tim at multitalents.net> writes:

> (Anyone have source to Solaris, UnixWare, SCO, ......) ;-)

Solaris: <URL:http://www.sun.com/software/solaris/source/> 
Don't know about SCO UnixWare.


-- 
Sturle
~~~~~~


From Leakin at dfw.Nostrum.com  Fri Oct  5 09:29:01 2001
From: Leakin at dfw.Nostrum.com (Lee Eakin)
Date: Thu, 4 Oct 2001 18:29:01 -0500
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>
References: <20011004122127.A26615@wdr.com> <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>
Message-ID: <20011004182901.A32345@japh.itg.ti.com>

I'll try to explain the issue here as I see it.  The rsh command (on most
systems) does not hang on exit, and does not cause rcp to lose data.  If
ssh only performed the same function as rsh and rcp we could examine how
various systems handle this and the solve the problem.  We might even be
able to solve it with previous versions of ssh.

The problem is that ssh does more than that (and we all want it to).  It
provides port-forwarding or tunnelling.  This complicates the issue of when
to drop the connection.  The same is true for X applications.  For tunnels
we want the connection to hang until all file descriptors are closed, but
for commands we don't, unless we are transfering files.

I am not in the same league with the developers (or most of the
contributors) when it comes to writing code.  I wish I was.  This is an
interesting problem that I would love to solve, but since I can't I hope
this at least sheds a little light on the problem for those waiting on a
solution, and perhaps even inspires someone with more C skills than I to
look at it from a slightly different angle and maybe even come up with an
elegant solution.

  -Lee

-- 
    Lee Eakin - leakin at dfw.nostrum.com
 
Unix is simple. It just takes a genius to understand its simplicity


From rachit at ensim.com  Fri Oct  5 11:03:34 2001
From: rachit at ensim.com (Rachit Siamwalla)
Date: Thu, 4 Oct 2001 18:03:34 -0700 
Subject: hang on exit - bug or no bug?
Message-ID: <9AC41B8C4781464695BB013F106FCA3102900D03@nasdaq.ms.ensim.com>

Yes, you will have this problem with rsh, but *not* rlogin. This is a key
difference. So you have the same problem in the case of batch processing
(where rsh is invoked) In this case, the hang case can be more than just
annoying; it can break your code). In the case of the interactive login, the
behavior differs (where the hang cases is merely just annoying).

Yes, the applications are broken if they fork and continue without closing
out all file descriptors. However, unfortunately a *lot* of applications are
written that way. 90% of the time when I leave on a long ssh session open,
and do a bunch of random things, I cannot log out without ssh hanging.

-rchit

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
Sent: Thursday, October 04, 2001 9:21 AM
To: Schieber, Dustin; Markus Friedl
Cc: Phil Howard; openssh-unix-dev at mindrot.org
Subject: Re: hang on exit - bug or no bug?


No, don't modify your OS' startup scripts, just run them differently.

Look, the fds are left open, so you potentially lose data, but you don't
care, right? So why not run those scripts like so:

ssh -n root at somehost /etc/init.d/syslog stop
ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1

?

You have this issue with RSH too you know. I long ago learned to deal
with this by manually redirecting stdio to /dev/null. And yes, sometimes
you care about some bit of command's output, because you may want to see
error msgs from /etc/init.d/syslog, say. There's a few solutions:

 - write a separate script for checking that the batch job is doing ok
 - use intr (yes, Solaris doesn't have one -- write one yourself) on the
   client side to set a timeout after which to kill ssh
 - write an intr-like command for the remote side that closes the fds
   after a timeout and which might be used like so:

   ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
 - fix the scripts


Nico


On Thu, Oct 04, 2001 at 12:11:18PM -0400, Schieber, Dustin wrote:
> Yes, I think it would be nice to have this as an option. I'm not that
> concerned about the inconvenience of a hang in an interactive session.
> I've very concerned about batch jobs that hang.
> 
> I agree with you that it's best to just resolve the problem with the
> open fds on the server side.  But again, this is a less than ideal
> solution from a sysadmin's perspective.  Several of the issues I've
> heard of involve scripts included with the OS. For example, I've
> verified the hang occurs when simply restarting syslog or the snmp
> agents on a Sun box.  (/etc/init.d/syslog stop|start)
> (/etc/rc3.d/S76snmpdx stop|start).  Of course I can modify these scripts
> to utilize the workaround. But it would be nice to have another
> option...
> 
> I've also seen this problem with various 3rd party software packages.
> Apparently this is a widespread problem with the open fds.  
> 
> Thanks! 
> -das
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> > Sent: Thursday, October 04, 2001 10:37 AM
> > To: Markus Friedl
> > Cc: Phil Howard; openssh-unix-dev at mindrot.org
> > Subject: Re: hang on exit - bug or no bug?
> > 
> > 
> > I think the requestor here wants this behaviour and wants it to be
> > optional. This seems acceptable to me (not an OpenSSH 
> > maintainer), but:
> > 
> > I also think it's silly -- if you know you'll have children on the
> > server side hanging on to the fildes and you don't want them to, then
> > re-work what you're doing on the server side so that this hack is not
> > necessary.
> > 
> > Nico
> > 
> > 
> > On Thu, Oct 04, 2001 at 04:27:02PM +0200, Markus Friedl wrote:
> > > On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> > > > So is this because the patch itself is undesired (flawed, 
> > incomplete,
> > > > not the right solution, or not a problem to be solved), or is it
> > > > because OS-specific conditional compilation is undesired?
> > > 
> > > it's because calling shutdown() before reading all remainig 
> > data from
> > > the pipe is wrong.
> > > 
> > > it will cause data loss like the older so called bug fixes did.
> > > 
> > > we will include bug fixes, but only if they don't break ssh.
> > --
> > 
> > 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.
> > 
--
-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 tomh at po.crl.go.jp  Fri Oct  5 11:15:28 2001
From: tomh at po.crl.go.jp (Tom Holroyd)
Date: Fri, 5 Oct 2001 10:15:28 +0900 (JST)
Subject: AFS and tokenforwarding
In-Reply-To: <wuzo77p67o.fsf@bg.sics.se>
Message-ID: <Pine.LNX.4.30.0110050959350.4817-100000@holly.crl.go.jp>

On 4 Oct 2001, Bjoern Groenvall wrote:

> I don't think any of the ssh (at least v1) authentication mechanisms
> really authenticate the server. ...
> A similar problem exists with the common "pass passwords in
> the clear" methods used by ssh. Hopefully this is fixed in v2 but I
> never really bothered to check.

Just FYI, the OpenSSH SRP patch (v2 protocol only,
see http://members.tripod.com/professor_tom/archives/index.html) solves
both of these problems -- with SRP you only enter your password/passphrase
on the client side, it's secure against MITM attacks, and it authenticates
the server (i.e. with SRP you KNOW that the server really contains your
secret verifier, and isn't just letting you in) in addition to the client.

SRP can also be forwarded over untrusted hosts, although the current
implementation doesn't do it yet.  This would solve the problem of
entering a password on a client that's running on a remote (and possibly
cracked) host by forwarding the SRP session back to the real (local)
client (or agent).

Dr. Tom Holroyd
"I am, as I said, inspired by the biological phenomena in which
chemical forces are used in repetitious fashion to produce all
kinds of weird effects (one of which is the author)."
	-- Richard Feynman, _There's Plenty of Room at the Bottom_



From tomh at po.crl.go.jp  Fri Oct  5 11:24:04 2001
From: tomh at po.crl.go.jp (Tom Holroyd)
Date: Fri, 5 Oct 2001 10:24:04 +0900 (JST)
Subject: AFS and tokenforwarding
In-Reply-To: <20011004232815.B13911@folly>
Message-ID: <Pine.LNX.4.30.0110051017050.4817-100000@holly.crl.go.jp>

On Thu, 4 Oct 2001, Markus Friedl wrote:

> > A masquerading server can always
> > forward the authentication information to the real server and use that
> > response as a legitimate reply. Thus you may still be passing
> > credentials down to an impostor. Either way you do it, you can always
> > be fooled. A similar problem exists with the common "pass passwords in
> > the clear" methods used by ssh. Hopefully this is fixed in v2 but I
> > never really bothered to check.
>
> same thing can happen in ssh v2 unless you use pubkey authentication.
> successful pubkey authentication is only possible if there is no MITM.

Oh, also with SRP, a MITM can forward the auth session but he gains
nothing by it; SRP doesn't leak information (not even password length).
(Well, if he does a MITM attack against the initial DH he can get your
username...)



From numerical.simulation at web.de  Fri Oct  5 17:08:05 2001
From: numerical.simulation at web.de (Markus Werle)
Date: Fri, 05 Oct 2001 09:08:05 +0200
Subject: Cannot bind any address
Message-ID: <3BBD5C54.6D3C7633@web.de>

Hi!

I just post this as a kind of backup or reminder,
so future searches will lead to the solution.

It is possible to change the openssh version
on the fly without cutting existing connections.
One just moves the old crap to another place,
installs the new binaries and everything is fine.

When users log out and in again they are
using the new version without any further pain.

This works only if You kill -15 the master sshd
(the childs stay alive)
If You do not kill it, You will get error messages of the
form:

# /opt/openssh-2.9.9p2/sbin/sshd -d
[...]
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on ::.
debug1: Bind to port 22 on 0.0.0.0.
Cannot bind any address.

Took me quite a while to find out I forgot to kill
the old one.

feature request:
sshd detects a concurring sshd is running and gives an
appropriate error message.


Markus



From markus at openbsd.org  Fri Oct  5 17:45:09 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 5 Oct 2001 09:45:09 +0200
Subject: Cannot bind any address
In-Reply-To: <3BBD5C54.6D3C7633@web.de>; from numerical.simulation@web.de on Fri, Oct 05, 2001 at 09:08:05AM +0200
References: <3BBD5C54.6D3C7633@web.de>
Message-ID: <20011005094509.A23581@faui02.informatik.uni-erlangen.de>

i think the message is already very appropriate.

On Fri, Oct 05, 2001 at 09:08:05AM +0200, Markus Werle wrote:
> Hi!
> 
> I just post this as a kind of backup or reminder,
> so future searches will lead to the solution.
> 
> It is possible to change the openssh version
> on the fly without cutting existing connections.
> One just moves the old crap to another place,
> installs the new binaries and everything is fine.
> 
> When users log out and in again they are
> using the new version without any further pain.
> 
> This works only if You kill -15 the master sshd
> (the childs stay alive)
> If You do not kill it, You will get error messages of the
> form:
> 
> # /opt/openssh-2.9.9p2/sbin/sshd -d
> [...]
> debug1: read PEM private key done: type DSA
> debug1: private host key: #2 type 2 DSA
> debug1: Bind to port 22 on ::.
> debug1: Bind to port 22 on 0.0.0.0.
> Cannot bind any address.
> 
> Took me quite a while to find out I forgot to kill
> the old one.
> 
> feature request:
> sshd detects a concurring sshd is running and gives an
> appropriate error message.
> 
> 
> Markus
> 


From djm at mindrot.org  Fri Oct  5 18:12:56 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 5 Oct 2001 18:12:56 +1000 (EST)
Subject: patch - forceshell
In-Reply-To: <3BBC7E11.50380983@berkeley.innomedia.com>
Message-ID: <Pine.LNX.4.33.0110051810050.1207-100000@mothra.mindrot.org>

On Thu, 4 Oct 2001, Don Mahurin wrote:

> > > This patch allows you can have some chrooted shell (actually any shell)
> > > associated with a specific key.
> > > You could do this with command=, but then the command given to ssh will
> > > be ignored, and scp will not work.
> >
> > You can get around this by using the $SSH_ORIGINAL_COMMAND env var.
> 
> This env var is really no help.
> 
> You could do:
>    echo '$SSH_ORIGINAL_COMMAND' | ssh Host echo hi world
> But why not just do:
>    echo 'hi world' | ssh Host
> And using scp, will require some wrapper script, or other magic.
>
> I don't want any magic.  With a shell= auth param, the client side
> users need to know nothing, and can use unmodified ssh clients.

I don't see the need for modified ssh clients and I can see why
SSH_ORIGINAL_COMMAND is no help?

cat > /usr/local/sbin/dochroot.sh
#!/bin/sh

chroot /whereever /bin/sh -c '$SSH_ORIGINAL_COMMAND'
^D

cat > /home/blah/.ssh/authorized_keys
command="/usr/local/sbin/dochroot.sh" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA6avTPMW9YhJG39KAGMxxwRpUTlRefxLJvXiEugEy66R/2YaF505iP35ERckSmnPsd5z9vbYBjVfp3XZ2Juf6phBYMUSQ/o8N3yFvsE19xoX+oECMuOlZtJRYRxbK0dxPTLCgEYnHMeqvD2Hs4d3ZI/KQgc7/q7Hjzz3Vz0AfZn8= djm at mothra.mindrot.org
^D

????

-d


-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From numerical.simulation at web.de  Fri Oct  5 19:35:52 2001
From: numerical.simulation at web.de (Markus Werle)
Date: Fri, 05 Oct 2001 11:35:52 +0200
Subject: Cannot bind any address
References: <3BBD5C54.6D3C7633@web.de> <20011005094509.A23581@faui02.informatik.uni-erlangen.de>
Message-ID: <3BBD7EF7.152DBAAF@web.de>

Markus Friedl wrote:

> i think the message is already very appropriate.

Yes, I agree, for someone who knows what it is all about
the message is _very_ appropriate.

So do not hesitate to change it ;-)

I just remember a lecture about computer interface
ergonomy, where we found out that most error messages are
perfect, but sometimes do not help the user to fix the problem
anyway.

We learned about several accidents in nuclear power stations
where correct error messages were misinterpreted by
humans in situations where one does not think clearly anymore.

Several airplane crashs led to the conclusion that
in case of an engine failure the pilot is _not_
interested in a message about pressure loss in tube 233-56,
but rather in a red highlighted engine on his display with
a single "engine failure" message.

We do not have to get paranoid about it, but
I see some analogy for open-ssh:
The bind problem has a reason, but the error message
does not tell me this reason. I have to think about it.
So something is - well - not wrong, but improvable.

I have to know that child processes do not have a bind problem
when the father process is killed. I have to know they
can live even when another sshd comes up. I have to
know that only the first sshds conflict with each other,
not the forked ones.
Since I am not very interested in implementation details
of ssh I just overlooked this and got it plain wrong for
15 minutes.

Conclusion:

Although the message is correct and already very appropriate
it lacks some ergonomy from the viewpoint of people who
investigate human-machine-interaction .


Markus


P.S.:
In the actual discussion about airplane security some people
would like to see airplanes under tele-control in
critical situation. I hope they use open-ssh for that purpose,
just to achieve maximum security.

Since airplane developers take a deep look at software
ergonomy, it still may be a good idea to assume
maximum stupidity on user's side (that's me :-))..

I can imagine critical situations where an ergonomic
error message may save hundreds of lives.

> > feature request:
> > sshd detects a concurring sshd is running and gives an
> > appropriate error message.

Like this (takes 5 minutes to change the source code):

Cannot bind any address. Maybe another sshd is up and running.




From markus at openbsd.org  Fri Oct  5 22:18:00 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 5 Oct 2001 14:18:00 +0200
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110041802390.24291-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Thu, Oct 04, 2001 at 06:04:39PM -0500
References: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net> <Pine.BSO.4.33.0110041802390.24291-100000@etoh.eviladmin.org>
Message-ID: <20011005141800.A19068@folly>

On Thu, Oct 04, 2001 at 06:04:39PM -0500, mouring at etoh.eviladmin.org wrote:
> If I know what I was looking for
> I'd be happy to beg and borrow selective pieces of source code from
> friends to investigate.  But I still am not dead sure what to look for.

look for:
	what happens on SIGCHLD
	how to detect that there is no more data from the child


From mouring at etoh.eviladmin.org  Sat Oct  6 00:17:24 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 5 Oct 2001 09:17:24 -0500 (CDT)
Subject: Cannot bind any address
In-Reply-To: <3BBD7EF7.152DBAAF@web.de>
Message-ID: <Pine.BSO.4.33.0110050911390.12112-100000@etoh.eviladmin.org>


Then you have people that could not understand how to do a simple thing
without it being explained 20 times. If your luckly they will finally get
it.

Every program returns that message.  It is constant.  No amount of
whining will change it.

But I will make a deal with you a life time (since it will take you a
life time to do it). =)

E-mail OpenBSD, NetBSD, FreeBSD, and every Linux distro and get them to
change every instance of that error message to something that "even a
idiot would understanding."  Then I'll back you in this change.

Until then... We shall go on with life.

- Ben

On Fri, 5 Oct 2001, Markus Werle wrote:

> Markus Friedl wrote:
>
> > i think the message is already very appropriate.
>
> Yes, I agree, for someone who knows what it is all about
> the message is _very_ appropriate.
>
> So do not hesitate to change it ;-)
>
> I just remember a lecture about computer interface
> ergonomy, where we found out that most error messages are
> perfect, but sometimes do not help the user to fix the problem
> anyway.
>
> We learned about several accidents in nuclear power stations
> where correct error messages were misinterpreted by
> humans in situations where one does not think clearly anymore.
>
> Several airplane crashs led to the conclusion that
> in case of an engine failure the pilot is _not_
> interested in a message about pressure loss in tube 233-56,
> but rather in a red highlighted engine on his display with
> a single "engine failure" message.
>
> We do not have to get paranoid about it, but
> I see some analogy for open-ssh:
> The bind problem has a reason, but the error message
> does not tell me this reason. I have to think about it.
> So something is - well - not wrong, but improvable.
>
> I have to know that child processes do not have a bind problem
> when the father process is killed. I have to know they
> can live even when another sshd comes up. I have to
> know that only the first sshds conflict with each other,
> not the forked ones.
> Since I am not very interested in implementation details
> of ssh I just overlooked this and got it plain wrong for
> 15 minutes.
>
> Conclusion:
>
> Although the message is correct and already very appropriate
> it lacks some ergonomy from the viewpoint of people who
> investigate human-machine-interaction .
>
>
> Markus
>
>
> P.S.:
> In the actual discussion about airplane security some people
> would like to see airplanes under tele-control in
> critical situation. I hope they use open-ssh for that purpose,
> just to achieve maximum security.
>
> Since airplane developers take a deep look at software
> ergonomy, it still may be a good idea to assume
> maximum stupidity on user's side (that's me :-))..
>
> I can imagine critical situations where an ergonomic
> error message may save hundreds of lives.
>
> > > feature request:
> > > sshd detects a concurring sshd is running and gives an
> > > appropriate error message.
>
> Like this (takes 5 minutes to change the source code):
>
> Cannot bind any address. Maybe another sshd is up and running.
>
>
>



From suk at pobox.com  Fri Oct  5 20:38:00 2001
From: suk at pobox.com (Peter Kwangjun Suk)
Date: Fri, 5 Oct 2001 06:38:00 -0400
Subject: Logging Port Forwards
In-Reply-To: <20011004182901.A32345@japh.itg.ti.com>
References: <20011004122127.A26615@wdr.com>
	<Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net>
	<20011004182901.A32345@japh.itg.ti.com>
Message-ID: <20011005063800.4e749b04.suk@pobox.com>

Hello,

We're using OpenSSH to let our customers set up encrypted port forwarding
tunnels so that we can do support by VNC-ing to their desktops.  We've set
up "session" accounts that have completely restricted shells and randomly
generated passwords which change themselves with every log-in.  

To complete the security for this set-up we'd like sshd to keep a log of
the port forwards.  It appears that the port forwards are logged in DEBUG
mode, but of course this is not acceptable for normal running.  I think
that I know where we would modify the code, but I would like to confirm
that.  

line 1850 of channels.c:

	debug("Local forwarding listening on %s port %s.", ntop, strport);

Also, add something to line 1924.  Am I on the right track, or is this
actually the ssh client side of things?  

I also would like a pointer to logging -- where does the normal logging
for logins happen?

Thanks.  

-- 
Peter Kwangjun Suk
suk at pobox.com
http://ostudio.swiki.net



From Nicolas.Williams at ubsw.com  Sat Oct  6 01:06:01 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 5 Oct 2001 11:06:01 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005141800.A19068@folly>; from markus@openbsd.org on Fri, Oct 05, 2001 at 02:18:00PM +0200
References: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net> <Pine.BSO.4.33.0110041802390.24291-100000@etoh.eviladmin.org> <20011005141800.A19068@folly>
Message-ID: <20011005110600.O5739@sm2p1386swk.wdr.com>

I can certainly confirm, from experience, that, on Solaris,

rsh host command&

hangs if "command" keeps its stdio open. Rlogin is what others are
saying doesn't do this, but, so what?

As Lee Eakin explained yesterday, there's things SSH does that RLOGIN
doesn't, such as agent forwarding, X forwarding, port forwarding, all
of which may or may not be needed by that background command that's
still holding its stdio open.

And how's SSHD to know?

Perhaps there should be an option, that causes SSHD to exit when its
child exits and the session was a TTY session, and to hell with grand-
children's stdio. But the conservative behaviour needs to be available
too.

This is all we're arguing about.

Nico


On Fri, Oct 05, 2001 at 02:18:00PM +0200, Markus Friedl wrote:
> On Thu, Oct 04, 2001 at 06:04:39PM -0500, mouring at etoh.eviladmin.org wrote:
> > If I know what I was looking for
> > I'd be happy to beg and borrow selective pieces of source code from
> > friends to investigate.  But I still am not dead sure what to look for.
> 
> look for:
> 	what happens on SIGCHLD
> 	how to detect that there is no more data from the child
--

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  Sat Oct  6 01:39:08 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 5 Oct 2001 17:39:08 +0200
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005110600.O5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Fri, Oct 05, 2001 at 11:06:01AM -0400
References: <Pine.UW2.4.40.0110041530580.7540-100000@uw711.int.multitalents.net> <Pine.BSO.4.33.0110041802390.24291-100000@etoh.eviladmin.org> <20011005141800.A19068@folly> <20011005110600.O5739@sm2p1386swk.wdr.com>
Message-ID: <20011005173908.A8148@faui02.informatik.uni-erlangen.de>

On Fri, Oct 05, 2001 at 11:06:01AM -0400, Nicolas Williams wrote:
> I can certainly confirm, from experience, that, on Solaris,
> 
> rsh host command&
> 
> hangs if "command" keeps its stdio open. Rlogin is what others are
> saying doesn't do this, but, so what?
> 
> As Lee Eakin explained yesterday, there's things SSH does that RLOGIN
> doesn't, such as agent forwarding, X forwarding, port forwarding, all
> of which may or may not be needed by that background command that's
> still holding its stdio open.

the hang-on-exit problem is not related to forwarding.

> Perhaps there should be an option, that causes SSHD to exit when its
> child exits and the session was a TTY session, and to hell with grand-
> children's stdio. But the conservative behaviour needs to be available
> too.

perhaps it's acceptable to discard data for sessions with ttys,
but i'm not sure yet.

session.c:session_exit_message()

        if (c->ostate != CHAN_OUTPUT_CLOSED)
		chan_write_failed(c);
+	if (s->ttyfd != -1 && option.discard && c->istate == CHAN_INPUT_OPEN)
+		chan_read_failed(c);
        s->chanid = -1;

should help.


-m


From mouring at etoh.eviladmin.org  Sat Oct  6 01:55:10 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 5 Oct 2001 10:55:10 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005173908.A8148@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.BSO.4.33.0110051050110.727-100000@etoh.eviladmin.org>



On Fri, 5 Oct 2001, Markus Friedl wrote:

> On Fri, Oct 05, 2001 at 11:06:01AM -0400, Nicolas Williams wrote:
> > I can certainly confirm, from experience, that, on Solaris,
> >
> > rsh host command&
> >
> > hangs if "command" keeps its stdio open. Rlogin is what others are
> > saying doesn't do this, but, so what?
> >
> > As Lee Eakin explained yesterday, there's things SSH does that RLOGIN
> > doesn't, such as agent forwarding, X forwarding, port forwarding, all
> > of which may or may not be needed by that background command that's
> > still holding its stdio open.
>
> the hang-on-exit problem is not related to forwarding.
>
> > Perhaps there should be an option, that causes SSHD to exit when its
> > child exits and the session was a TTY session, and to hell with grand-
> > children's stdio. But the conservative behaviour needs to be available
> > too.
>
> perhaps it's acceptable to discard data for sessions with ttys,
> but i'm not sure yet.
>
> session.c:session_exit_message()
>
>         if (c->ostate != CHAN_OUTPUT_CLOSED)
> 		chan_write_failed(c);
> +	if (s->ttyfd != -1 && option.discard && c->istate == CHAN_INPUT_OPEN)
> +		chan_read_failed(c);
>         s->chanid = -1;
>
> should help.
>

I assume this is part of a bigger patch  where 'option.discard' exists.

One may suggestion only activing this code for slogin only.  That way it
would mirror rsh/rlogin.

- Ben



From mouring at etoh.eviladmin.org  Sat Oct  6 01:58:05 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 5 Oct 2001 10:58:05 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110051050110.727-100000@etoh.eviladmin.org>
Message-ID: <Pine.BSO.4.33.0110051057500.727-100000@etoh.eviladmin.org>


Plus it works for only protocol v2.  Not protocol v1

On Fri, 5 Oct 2001 mouring at etoh.eviladmin.org wrote:

>
>
> On Fri, 5 Oct 2001, Markus Friedl wrote:
>
> > On Fri, Oct 05, 2001 at 11:06:01AM -0400, Nicolas Williams wrote:
> > > I can certainly confirm, from experience, that, on Solaris,
> > >
> > > rsh host command&
> > >
> > > hangs if "command" keeps its stdio open. Rlogin is what others are
> > > saying doesn't do this, but, so what?
> > >
> > > As Lee Eakin explained yesterday, there's things SSH does that RLOGIN
> > > doesn't, such as agent forwarding, X forwarding, port forwarding, all
> > > of which may or may not be needed by that background command that's
> > > still holding its stdio open.
> >
> > the hang-on-exit problem is not related to forwarding.
> >
> > > Perhaps there should be an option, that causes SSHD to exit when its
> > > child exits and the session was a TTY session, and to hell with grand-
> > > children's stdio. But the conservative behaviour needs to be available
> > > too.
> >
> > perhaps it's acceptable to discard data for sessions with ttys,
> > but i'm not sure yet.
> >
> > session.c:session_exit_message()
> >
> >         if (c->ostate != CHAN_OUTPUT_CLOSED)
> > 		chan_write_failed(c);
> > +	if (s->ttyfd != -1 && option.discard && c->istate == CHAN_INPUT_OPEN)
> > +		chan_read_failed(c);
> >         s->chanid = -1;
> >
> > should help.
> >
>
> I assume this is part of a bigger patch  where 'option.discard' exists.
>
> One may suggestion only activing this code for slogin only.  That way it
> would mirror rsh/rlogin.
>
> - Ben
>
>



From djast at cs.toronto.edu  Sat Oct  6 01:59:14 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Fri, 5 Oct 2001 11:59:14 -0400
Subject: OpenSSH (portable) and entropy gathering 
In-Reply-To: Your message of "Fri, 05 Oct 2001 04:09:18 EDT."
             <Pine.LNX.4.33.0110051806180.1207-100000@mothra.mindrot.org> 
Message-ID: <01Oct5.115921edt.453144-236@jane.cs.toronto.edu>

On Fri, 05 Oct 2001 04:09:18 EDT, Damien Miller writes:
> > Unfortunately, sshd generally needs its entropy when it starts up, which
> > is typically just after boot time, when not that much entropy is
> > available from _any_ local source.
> 
> That is why the portable OpenSSH entropy code stores a seed file 
> between invocations.

Good point.  So, if "fallback to internal entropy" were configured, then
the seed file should be written even when using other sources of entropy
when they're available.  Doing so would actually improve the entropy in
the seed file most of the time.

(If sshd is started only at boot time, and root never runs the ssh
client, how good is the entropy in /.ssh/prng_seed?  I know the seed
file gets rewritten every time a fork()'d sshd exits, but still....)

> > (Suppose your host has crashed, and there's filesystem damage.  You're in
> > single-user mode, and your root filesystem is read-only pending an fsck.
> > Your socket was /etc/entropy, so prngd can't unlink it to start up
> > again.  You're missing a file that you need for the recovery procedure,
> > but you can't scp it over to /tmp because the ssh client won't run while
> > /etc/entropy exists and the daemon isn't up.
> 
> I'd rather not risk compromising the security of the entire system
> because of pathological corner cases. If we put an option in to use
> insecure entropy sources, then people will just use it anyway.

Well, while I can't argue that a system that can't be booted isn't
technically more secure than one using SSH with poor entropy, I'd find
that of little comfort when my phone is ringing off the hook because the
mail server is down.

If the seed file is written even when the internal entropy is not in
use, I don't see how "use EGD when available, fall back to internal
entropy generation" is less secure than "always use the internal entropy
generation" on hosts that don't have it available.

Even if it were less secure, I think that requiring the sysadmin to
explicitly compile in the support to fall back to the builtin code,
_plus_ requiring the user to confirm that they want to connect despite
the poor source of entropy, is a sufficient barrier that admins won't
generally do it unless they've weighed the security considerations
against the availability requirements.

OpenSSH still has the ability to enable RhostsAuthentication, and you
don't even have to explicitly configure that option in at compile time,
if I'm not mistaken.  And for compatability reasons, I believe the
client still supports "cipher none" (though the server, rightly, does
not).  I can't imagine that allowing ssh to be forced to proceed with
poor entropy is a bigger risk than those.

[OpenSSL automagically seeds itself from /dev/urandom, has EGD support:]
> The difficulty lies in knowing whether OpenSSL has been compiled with
> such support and whether or not it is working.

With respect to those sources which OpenSSL uses automatically,
RAND_status() solves that problem.  Entropy.c should probably check
RAND_status() before opening RANDOM_POOL or connecting to EGD.  OpenSSL
uses /dev/urandom transparently, and when OpenSSL 0.9.7 comes out it
will (I'm told) try to connect to EGD, also transparently.  If OpenSSH
also collects entropy from those sources when it doesn't need to, it
will deplete the entropy pool faster than necessary.

(My apologies if I've misread entropy.c and the code already does this.)

I'm not clear enough on the distinction between init_rng() and
seed_rng() to know whether it would be reasonable to check RAND_status()
from init_rng(), so that the internal code wouldn't be called if OpenSSL
could find enough entropy on its own.

Also: currently, OpenSSH compiles in the internal code if it cannot find
another source of entropy.  You could probably make it possible to
configure OpenSSH with *no* sources of entropy, i.e., have OpenSSH rely
entirely on OpenSSL to collect it, if you wanted to.

(I realize you hope to deprecate the internal code entirely; I think we
can substitute "call an external program to collect entropy" for "call
the internal entropy collection code" throughout, and the design issues
don't change much.)

Let me know if there's anything I can do to contribute, code-wise.  I'd
be willing to work on reorganizing the internal entropy collection code
into an external program and rewriting entropy.c to use it, but I don't
want to interfere with existing efforts.

Speaking of interfering with existing efforts, I do hope I'm actually
raising relevant design issues, and not merely distracting and
irritating you with this discussion....

-- 
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 dmahurin at berkeley.innomedia.com  Sat Oct  6 02:41:57 2001
From: dmahurin at berkeley.innomedia.com (Don Mahurin)
Date: Fri, 05 Oct 2001 09:41:57 -0700
Subject: patch - forceshell
References: <Pine.LNX.4.33.0110051810050.1207-100000@mothra.mindrot.org>
Message-ID: <3BBDE2D4.A0FE8FD2@berkeley.innomedia.com>

Damien Miller wrote:

> > I don't want any magic.  With a shell= auth param, the client side
> > users need to know nothing, and can use unmodified ssh clients.
>
> I don't see the need for modified ssh clients and I can see why
> SSH_ORIGINAL_COMMAND is no help?

The patch was a simple server side change. Ordinary ssh clients can be used with this.

You are proposing that instead, the shell ( or wrapper ) must be modified to understand the env var.

With the submitted patch, you could  forget about what is in /etc/passwd, and even do something like shell="/bin/csh.".

With your suggestion, you would need to do command=csh_ssh_command, with csh_ssh_command
being '#!/bin/sh\ncsh $SSH_ORIGINAL_COMMAND'

Even simpler, knowing how ssh works, instead of shell="/bin/csh",
you could do shell="echo $SSH_ORIGINAL_COMMAND | /bin/csh".

But this reliance on SSH_ORIGINAL_COMMAND is somewhat sloppy and could break with an ssh change.
(Imagine if ssh's problem of unquoting commands was fixed).

-don




From phil-openssh-unix-dev at ipal.net  Sat Oct  6 03:32:25 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Fri, 5 Oct 2001 12:32:25 -0500 (CDT)
Subject: [ramble] Re: hang on exit - bug or no bug?
In-Reply-To: <Pine.LNX.4.33.0110041916520.28740-100000@netcore.fi> from "Pekka Savola" at Oct 04, 2001 07:18:17 PM
Message-ID: <20011005173225.91B13236@vega.ipal.net>

Pekka Savola wrote:

> On Thu, 4 Oct 2001, Schieber, Dustin wrote:
> > I've also seen this problem with various 3rd party software packages.
> > Apparently this is a widespread problem with the open fds.
>
> It's probably a bug in the software -- e.g. fds not being closed when
> forking.  This can have grave security considerations also.

However, I see this problem a lot.  Many daemon programs don't
close their std* file descriptors once started up.  I can tell
because I get error messages from said daemons later from the
session where I restarted that service.  Apparently whoever
writes some of these assumes it gets started _only_ at boot
time and would never be restarted manually by the sysadmin from
other than the system console.  My workaround is to use screen.
This is because I _do_ want to see any messages that come out at
the time of starting up in case it isn't starting properly.

<ramble>

I'm currently writing a couple of new servers for some projects
and part of the core server design is that the first process to
be started forks off the actual daemon as a grandchild, and exits
as soon as the actual daemon reports a successful start or dies.
This first process will not pass std* descriptors to the daemon,
but instead will pass pipes to it as std* descriptors, and will
then read from the pipes and write to the original descriptors
until it sees EOF.

Some services don't do a very good job of making sure they go
into the background quickly, while still checking for errors
and returning an error status if the common errors prevent it
from operating.  BIND sometimes hangs for a while.  Sendmail
was particularly bad about this (way way too many DNS queries
before starting up).  Even Apache has problems with the default
or common configurations (I've worked around it).  Sometimes
I wonder if those programmers have ever been a system admin on
a network with 99.999% 24/7/365 uptime requirements for hundreds
of servers, or if their sysadmin experience is keeping their own
file server in their office running during most office hours.

</ramble>

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From jason at ncac.gwu.edu  Sat Oct  6 03:35:03 2001
From: jason at ncac.gwu.edu (Jason Mader)
Date: Fri, 05 Oct 2001 13:35:03 -0400
Subject: openbsd-compat
Message-ID: <423867.1002288903@lombard.ncac.gwu.edu>

When I compile openssh 2.9.9p2 with openssl sources in a relative directory 
I had a problem with the openbsd-compat/Makefile that was generated.

  env CC=cc ./configure --with-ssl-dir=../openssl-0.9.6b

The Makefile is in a subdirectory, but configure didn't append ../ to an -I 
option to accomodate.  Never had this problem with earlier sources and I've 
ran configure the same way before.

I edited that one Makefile by hand and didn't have any trouble in anything 
else.
--
Jason Mader     \\     jason at ncac.gwu.edu     //     703-726-8373


From phil-openssh-unix-dev at ipal.net  Sat Oct  6 03:45:48 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Fri, 5 Oct 2001 12:45:48 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011004122127.A26615@wdr.com> from "Nicolas Williams" at Oct 04, 2001 12:21:27 PM
Message-ID: <20011005174548.8DC15238@vega.ipal.net>

Nicolas Williams wrote:

> No, don't modify your OS' startup scripts, just run them differently.
>
> Look, the fds are left open, so you potentially lose data, but you don't
> care, right? So why not run those scripts like so:
>
> ssh -n root at somehost /etc/init.d/syslog stop
> ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1

I want to see the messages at startup that indicate why it didn't
start, if that happens.  Of course the blame is that many daemons
are not designed to do ths properly.  But the two that I am now
designing/coding will be.  The servers will close the standard
descriptors once it has determined the startup conditions are fine
(of course later failures will have to go to syslog).


> You have this issue with RSH too you know. I long ago learned to deal
> with this by manually redirecting stdio to /dev/null. And yes, sometimes
> you care about some bit of command's output, because you may want to see
> error msgs from /etc/init.d/syslog, say. There's a few solutions:
>
>  - write a separate script for checking that the batch job is doing ok
>  - use intr (yes, Solaris doesn't have one -- write one yourself) on the
>    client side to set a timeout after which to kill ssh
>  - write an intr-like command for the remote side that closes the fds
>    after a timeout and which might be used like so:
>
>    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
>  - fix the scripts

- fix the daemons

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From mouring at etoh.eviladmin.org  Sat Oct  6 03:58:37 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 5 Oct 2001 12:58:37 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005174548.8DC15238@vega.ipal.net>
Message-ID: <Pine.BSO.4.33.0110051257170.2843-100000@etoh.eviladmin.org>


[..]
> >  - write a separate script for checking that the batch job is doing ok
> >  - use intr (yes, Solaris doesn't have one -- write one yourself) on the
> >    client side to set a timeout after which to kill ssh
> >  - write an intr-like command for the remote side that closes the fds
> >    after a timeout and which might be used like so:
> >
> >    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
> >  - fix the scripts
>
> - fix the daemons
>

Finxing daemons will solve part of the problem.. but will not solve the
case when you do:

ssh site.com
vi file
ctrl-z
<wander around>
exit
..[hang]

You sure can't close the std* in vi.. It would make it worthless.

- Ben



From Nicolas.Williams at ubsw.com  Sat Oct  6 04:02:47 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 5 Oct 2001 14:02:47 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110051257170.2843-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Fri, Oct 05, 2001 at 12:58:37PM -0500
References: <20011005174548.8DC15238@vega.ipal.net> <Pine.BSO.4.33.0110051257170.2843-100000@etoh.eviladmin.org>
Message-ID: <20011005140245.Q5739@sm2p1386swk.wdr.com>

On Fri, Oct 05, 2001 at 12:58:37PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> [..]
> > >  - write a separate script for checking that the batch job is doing ok
> > >  - use intr (yes, Solaris doesn't have one -- write one yourself) on the
> > >    client side to set a timeout after which to kill ssh
> > >  - write an intr-like command for the remote side that closes the fds
> > >    after a timeout and which might be used like so:
> > >
> > >    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
> > >  - fix the scripts
> >
> > - fix the daemons
> >
> 
> Finxing daemons will solve part of the problem.. but will not solve the
> case when you do:
> 
> ssh site.com
> vi file
> ctrl-z
> <wander around>
> exit
> ..[hang]

My shell usually tells me that I have suspended jobs and aborts the
exit.

> You sure can't close the std* in vi.. It would make it worthless.

No, vi is no daemon...

> - 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  Sat Oct  6 04:01:42 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 5 Oct 2001 14:01:42 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005174548.8DC15238@vega.ipal.net>; from phil-openssh-unix-dev@ipal.net on Fri, Oct 05, 2001 at 12:45:48PM -0500
References: <20011004122127.A26615@wdr.com> <20011005174548.8DC15238@vega.ipal.net>
Message-ID: <20011005140140.P5739@sm2p1386swk.wdr.com>

On Fri, Oct 05, 2001 at 12:45:48PM -0500, Phil Howard wrote:
> Nicolas Williams wrote:
> 
> > No, don't modify your OS' startup scripts, just run them differently.
> >
> > Look, the fds are left open, so you potentially lose data, but you don't
> > care, right? So why not run those scripts like so:
> >
> > ssh -n root at somehost /etc/init.d/syslog stop
> > ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1
> 
> I want to see the messages at startup that indicate why it didn't
> start, if that happens.  Of course the blame is that many daemons
> are not designed to do ths properly.  But the two that I am now
> designing/coding will be.  The servers will close the standard
> descriptors once it has determined the startup conditions are fine
> (of course later failures will have to go to syslog).

Don't forget to ALWAYS, ALWAYS open() something appropriate for stdio
after closing stdio; /dev/null if nothing else.

...
close(0);
close(1);
close(2);
open("/dev/null", O_RDONLY);
open("/dev/console", O_RDONLY); /* or /dev/null */
open("/dev/console", O_RDONLY); /* or /dev/null */
...

Just in case any stupid library function you might use assumes that
stdio is a place to write error messages, or read from.

> > You have this issue with RSH too you know. I long ago learned to deal
> > with this by manually redirecting stdio to /dev/null. And yes, sometimes
> > you care about some bit of command's output, because you may want to see
> > error msgs from /etc/init.d/syslog, say. There's a few solutions:
> >
> >  - write a separate script for checking that the batch job is doing ok
> >  - use intr (yes, Solaris doesn't have one -- write one yourself) on the
> >    client side to set a timeout after which to kill ssh
> >  - write an intr-like command for the remote side that closes the fds
> >    after a timeout and which might be used like so:
> >
> >    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
> >  - fix the scripts
> 
> - fix the daemons

Right. That's not always an option though... :)

> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
> | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
> -----------------------------------------------------------------


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 mouring at etoh.eviladmin.org  Sat Oct  6 04:07:09 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 5 Oct 2001 13:07:09 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005140245.Q5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.BSO.4.33.0110051305270.2843-100000@etoh.eviladmin.org>



On Fri, 5 Oct 2001, Nicolas Williams wrote:

> On Fri, Oct 05, 2001 at 12:58:37PM -0500, mouring at etoh.eviladmin.org wrote:
> >
> > [..]
> > > >  - write a separate script for checking that the batch job is doing ok
> > > >  - use intr (yes, Solaris doesn't have one -- write one yourself) on the
> > > >    client side to set a timeout after which to kill ssh
> > > >  - write an intr-like command for the remote side that closes the fds
> > > >    after a timeout and which might be used like so:
> > > >
> > > >    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
> > > >  - fix the scripts
> > >
> > > - fix the daemons
> > >
> >
> > Finxing daemons will solve part of the problem.. but will not solve the
> > case when you do:
> >
> > ssh site.com
> > vi file
> > ctrl-z
> > <wander around>
> > exit
> > ..[hang]
>
> My shell usually tells me that I have suspended jobs and aborts the
> exit.
>

First time.. But how many people have you seen in a hurry to leave for
the day go 'Ctrl-D, Ctrl-D'  and ignore the suspended jobs because they
are use to telnet killing the processes or they die due to lack of std*
contact.

I'll admit I've done it a few times.. Not normally under SSH.

- Ben



From phil-openssh-unix-dev at ipal.net  Sat Oct  6 04:24:41 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Fri, 5 Oct 2001 13:24:41 -0500 (CDT)
Subject: [my summary] Re: hang on exit - bug or no bug?
In-Reply-To: <FC1C45AE08EFD211B9C600A0C96B86DA03921E57@rtp-xch1.cisco.com> from "Schieber, Dustin" at Oct 04, 2001 01:18:33 PM
Message-ID: <20011005182441.C662C236@vega.ipal.net>

Schieber, Dustin wrote:

> I definately don't have the same problem with rsh, and never had it with
> ssh 1.2.31.  It was only after upgrading to Openssh that we experienced
> this problem. I can't dispute what has been said about the the code in
> 1.2.31.  I can only state what my experience has been... we did not have
> this hanging problem with 1.2.31.

I have seen the "dangling descriptor" problem with rsh in non-pty
session.  With pty sessions, it did work as telnet worked, and
forced the session down and the pty driver surely sent SIGHUP.

For interactive pty sessions, OpenSSH has this "problem" where
rsh and telnet did not.  But these being manual, ^\. is usable
to force the session down (and presumably SIGHUP on the other
end, if it was still reachable and got the RST).  There's also
kill.

The problem is scripted remote commands.  Data loss prevention
is definitely the #2 goal (security is #1).  The complication is
that if the session parent process exits, is there still some
data that needs to be sent if other processes still hold the
other ends of the pipes open.  It _should_ be easy to make sure
that any data left in the pipe buffer from the exiting process
can be read, even though SIGCHLD will be handled before select()
wakes for the pipe read.  The obvious way is read to EOF.  The
other way is read to EWOULDBLOCK.  But is the EWOULDBLOCK way
really right?  No.  Perhaps on some systems the pipe buffer can
be swapped out even though the writing process has exited and
been waited.  Then there is the issue of background processes.
I do agree that in this case, waiting for EOF is the correct way.
If you're scripting the startup, script it to not pass on the
descriptors to any processes to be sure sshd sees EOF.

Still, a problem remains.  Hangs happen even if there are no other
processes.  These don't happen very often, but I have seen them
happen.  Reproducing them is not easy.  Looking at the sshd with
lsof shows the pipe descriptors still open.  The session process
is gone so they can't be open anywhere else.  Doing strace on the
existing sshd process showed no activity.  I suspected some kind
of corrupted state in serverloop.  I have NOT seen this since 2.9p2
which I've been using for about 3 months.  Maybe it is fixed, but
I've also gone longer than 3 months without the problem happening
even in the earlier versions.  So I am still cautious, but it is
not a regularly occuring problem, either.  THIS is why I was
interested in this thread, hoping someone had see this and figured
out the cause and fixed it.  But it seems the "fix" is for the
dangling descriptor problem (which I can get around).


> Your suggested workarounds have been discussed and in some cases already
> implemented on our hosts.   But the perception in my organization has
> been that Openssh is "broken" because this was not a problem before. The
> FAQ provides very little documentation on this problem, it's unclear if
> it's considered a bug or not.

Maybe it was really "broken" before vis-a-vis data loss from
background processes.  This is why I do think an option to force
down a session if the child of sshd exits (after enough reads to
get EWOULDBLOCK to drain the pipe, or a timeout expires).  I can
see cases where having this option would be useful, but I would
never want it as the default.

I'm thinking of writing a small C program to do this instead.
You would just execute a program via this program.  It would
make a new set of pipes and run the given command, and sit there
and copy data streams.  Then when the process it forked exits,
it would drain the pipes and exit.  The inherited std* descriptors
would not be passed to the child so sshd or rshd they would
definitely see EOF.  Two timeout options would be available.
One indicates the time to wait after the child exist if EOF is
not seen to just go ahead and exit anyway.  The other timeout
option would be used to force an exit when the child does not.
With such a program, adding the option to OpenSSH would not be
of any further need.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From Nicolas.Williams at ubsw.com  Sat Oct  6 04:25:27 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 5 Oct 2001 14:25:27 -0400
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110051050110.727-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Fri, Oct 05, 2001 at 10:55:10AM -0500
References: <20011005173908.A8148@faui02.informatik.uni-erlangen.de> <Pine.BSO.4.33.0110051050110.727-100000@etoh.eviladmin.org>
Message-ID: <20011005142526.R5739@sm2p1386swk.wdr.com>

On Fri, Oct 05, 2001 at 10:55:10AM -0500, mouring at etoh.eviladmin.org wrote:
> On Fri, 5 Oct 2001, Markus Friedl wrote:
> >
> > perhaps it's acceptable to discard data for sessions with ttys,
> > but i'm not sure yet.
> >
> > session.c:session_exit_message()
> >
> >         if (c->ostate != CHAN_OUTPUT_CLOSED)
> > 		chan_write_failed(c);
> > +	if (s->ttyfd != -1 && option.discard && c->istate == CHAN_INPUT_OPEN)
> > +		chan_read_failed(c);
> >         s->chanid = -1;
> >
> > should help.
> >
> 
> I assume this is part of a bigger patch  where 'option.discard' exists.
> 
> One may suggestion only activing this code for slogin only.  That way it
> would mirror rsh/rlogin.

That seems quite reasonable. And make it a named option too...

> - Ben


Nico
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



From phil-openssh-unix-dev at ipal.net  Sat Oct  6 04:41:20 2001
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Fri, 5 Oct 2001 13:41:20 -0500 (CDT)
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110051257170.2843-100000@etoh.eviladmin.org> from "mouring@etoh.eviladmin.org" at Oct 05, 2001 12:58:37 PM
Message-ID: <20011005184121.03551236@vega.ipal.net>

mouring at etoh.eviladmin.org wrote:

> > - fix the daemons
> >
>
> Finxing daemons will solve part of the problem.. but will not solve the
> case when you do:
>
> ssh site.com
> vi file
> ctrl-z
> <wander around>
> exit
> ..[hang]
>
> You sure can't close the std* in vi.. It would make it worthless.

My "man ssh" shows:

=============================================================================
  Escape Characters

     When a pseudo terminal has been requested, ssh supports a number of func-
     tions through the use of an escape character.

     A single tilde character can be sent as ~~ (or by following the tilde by
     a character other than those described above).  The escape character must
     always follow a newline to be interpreted as special.  The escape charac-
     ter can be changed in configuration files using the EscapeChar configura-
     tion directive or on the command line by the -e option.

     The supported escapes (assuming the default `~') are:

     ~.      Disconnect

     ~^Z     Background ssh

     ~#      List forwarded connections

     ~&      Background ssh at logout when waiting for forwarded connection /
             X11 sessions to terminate (protocol version 1 only)

     ~?      Display a list of escape characters

     ~R      Request rekeying of the connection (only useful for SSH protocol
             version 2 and if the peer supports it)
=============================================================================

Which I changed to ^\ using "EscapeChar ^\" in ~/.ssh/config (I had
failed top mention in previous posts because I'm so used to doing
it as ^\. I forgot it was my own idea).  I do this because using ~
as the escape character was problematic.

So do ~. or whatever on the hung ssh client and drop it that way.
Sure it would be nice not to have to.  The issue of data loss in
an interactive tty session is also questionable, too.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------


From joe at zircon.seattle.wa.us  Sat Oct  6 04:43:24 2001
From: joe at zircon.seattle.wa.us (Joe Kelsey)
Date: Fri, 5 Oct 2001 11:43:24 -0700
Subject: [ramble] Re: hang on exit - bug or no bug?
In-Reply-To: <20011005173225.91B13236@vega.ipal.net>
References: <Pine.LNX.4.33.0110041916520.28740-100000@netcore.fi>
	<20011005173225.91B13236@vega.ipal.net>
Message-ID: <15293.65356.406440.392361@zircon.zircon.seattle.wa.us>

Phil Howard writes:
 > <ramble>
 > rambling about daemons deleted...
 > </ramble>

Dan Bernstein has already written the canonical daemon toolkit,
daemontools, abailable from http://cr.yp.to/daemontools.html, just like
all of his other tools.  There is no need to reinvent the wheel over and
over...

Of course, some people object to Bernstein on principle because they do
not want to take the time to understand his software.

/Joe


From markus at openbsd.org  Sat Oct  6 06:05:35 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 5 Oct 2001 22:05:35 +0200
Subject: patch - forceshell
In-Reply-To: <3BBDE2D4.A0FE8FD2@berkeley.innomedia.com>; from dmahurin@berkeley.innomedia.com on Fri, Oct 05, 2001 at 09:41:57AM -0700
References: <Pine.LNX.4.33.0110051810050.1207-100000@mothra.mindrot.org> <3BBDE2D4.A0FE8FD2@berkeley.innomedia.com>
Message-ID: <20011005220535.B29320@folly>

On Fri, Oct 05, 2001 at 09:41:57AM -0700, Don Mahurin wrote:
> (Imagine if ssh's problem of unquoting commands was fixed).

what problem?


From markus at openbsd.org  Sat Oct  6 06:01:04 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 5 Oct 2001 22:01:04 +0200
Subject: OpenSSH (portable) and entropy gathering
In-Reply-To: <01Oct5.115921edt.453144-236@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Fri, Oct 05, 2001 at 11:59:14AM -0400
References: <Pine.LNX.4.33.0110051806180.1207-100000@mothra.mindrot.org> <01Oct5.115921edt.453144-236@jane.cs.toronto.edu>
Message-ID: <20011005220104.A29320@folly>

On Fri, Oct 05, 2001 at 11:59:14AM -0400, Dan Astoorian wrote:
> OpenSSH still has the ability to enable RhostsAuthentication, and you
> don't even have to explicitly configure that option in at compile time,

because openssh should have no compile time option.

> if I'm not mistaken.  And for compatability reasons, I believe the
> client still supports "cipher none"

no, it does not.

> (though the server, rightly, does
> not).  I can't imagine that allowing ssh to be forced to proceed with
> poor entropy is a bigger risk than those.

-m


From stevesk at pobox.com  Sat Oct  6 06:52:37 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 5 Oct 2001 13:52:37 -0700 (PDT)
Subject: Cannot bind any address
In-Reply-To: <3BBD5C54.6D3C7633@web.de>
Message-ID: <Pine.HPX.4.40.0110051346340.1631-100000@jenny>

On Fri, 5 Oct 2001, Markus Werle wrote:
:# /opt/openssh-2.9.9p2/sbin/sshd -d
:[...]
:debug1: read PEM private key done: type DSA
:debug1: private host key: #2 type 2 DSA
:debug1: Bind to port 22 on ::.
:debug1: Bind to port 22 on 0.0.0.0.
:Cannot bind any address.
:
:Took me quite a while to find out I forgot to kill
:the old one.
:
:feature request:
:sshd detects a concurring sshd is running and gives an
:appropriate error message.

are you using linux?  you should have seen something like:

 debug1: Bind to port 22 on ::.
 Bind to port 22 on :: failed: Address already in use.
 debug1: Bind to port 22 on 0.0.0.0.
 Bind to port 22 on 0.0.0.0 failed: Address already in use.
 Cannot bind any address.

where the address already in use gives additional information.

see this thread for details:
http://marc.theaimsgroup.com/?t=98241837100002&w=2&r=1



From dmahurin at berkeley.innomedia.com  Sat Oct  6 07:09:48 2001
From: dmahurin at berkeley.innomedia.com (Don Mahurin)
Date: Fri, 05 Oct 2001 14:09:48 -0700
Subject: patch - forceshell
References: <Pine.LNX.4.33.0110051810050.1207-100000@mothra.mindrot.org> <3BBDE2D4.A0FE8FD2@berkeley.innomedia.com> <20011005220535.B29320@folly>
Message-ID: <3BBE219C.C53F1987@berkeley.innomedia.com>

Markus Friedl wrote:

> On Fri, Oct 05, 2001 at 09:41:57AM -0700, Don Mahurin wrote:
> > (Imagine if ssh's problem of unquoting commands was fixed).
>
> what problem?

ssh localhost echo "lost&&found"

Though it's many a problem that most popular shells can only execute
single string commands at the command line, and ssh relies on the shell.

Either ssh could exec the command itself, or re-quote everything.

-don



From cmadams at hiwaay.net  Sat Oct  6 07:14:01 2001
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 5 Oct 2001 16:14:01 -0500
Subject: [ramble] Re: hang on exit - bug or no bug?
In-Reply-To: <15293.65356.406440.392361@zircon.zircon.seattle.wa.us>; from joe@zircon.seattle.wa.us on Fri, Oct 05, 2001 at 11:43:24AM -0700
References: <Pine.LNX.4.33.0110041916520.28740-100000@netcore.fi> <20011005173225.91B13236@vega.ipal.net> <15293.65356.406440.392361@zircon.zircon.seattle.wa.us>
Message-ID: <20011005161401.L20911@HiWAAY.net>

Once upon a time, Joe Kelsey <joe at zircon.seattle.wa.us> said:
> Of course, some people object to Bernstein on principle because they do
> not want to take the time to understand his software.

Other object because of the license he uses.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From djm at mindrot.org  Sat Oct  6 07:55:12 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 6 Oct 2001 07:55:12 +1000 (EST)
Subject: [ramble] Re: hang on exit - bug or no bug?
In-Reply-To: <15293.65356.406440.392361@zircon.zircon.seattle.wa.us>
Message-ID: <Pine.LNX.4.33.0110060754300.1847-100000@mothra.mindrot.org>

On Fri, 5 Oct 2001, Joe Kelsey wrote:

> Of course, some people object to Bernstein on principle because they do
> not want to take the time to understand his software.

Please keep DJB advocacy and flamebait off this list.

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Sat Oct  6 08:12:37 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 6 Oct 2001 08:12:37 +1000 (EST)
Subject: hang on exit - bug or no bug?
In-Reply-To: <20011005141800.A19068@folly>
Message-ID: <Pine.LNX.4.33.0110060811590.1847-100000@mothra.mindrot.org>

On Fri, 5 Oct 2001, Markus Friedl wrote:

> On Thu, Oct 04, 2001 at 06:04:39PM -0500, mouring at etoh.eviladmin.org wrote:
> > If I know what I was looking for
> > I'd be happy to beg and borrow selective pieces of source code from
> > friends to investigate.  But I still am not dead sure what to look for.
> 
> look for:
> 	what happens on SIGCHLD
> 	how to detect that there is no more data from the child

also truss/strace what happens to the child when its parent exits.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Sat Oct  6 08:13:41 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 6 Oct 2001 08:13:41 +1000 (EST)
Subject: patch - forceshell
In-Reply-To: <3BBDE2D4.A0FE8FD2@berkeley.innomedia.com>
Message-ID: <Pine.LNX.4.33.0110060812550.1847-100000@mothra.mindrot.org>

On Fri, 5 Oct 2001, Don Mahurin wrote:

> Damien Miller wrote:
> 
> > > I don't want any magic.  With a shell= auth param, the client side
> > > users need to know nothing, and can use unmodified ssh clients.
> >
> > I don't see the need for modified ssh clients and I can see why
> > SSH_ORIGINAL_COMMAND is no help?
> 
> The patch was a simple server side change. Ordinary ssh clients can
> be used with this.

Ordinary ssh clients can be used without the patch.

> You are proposing that instead, the shell ( or wrapper ) must be
> modified to understand the env var.

I am proposing a wrapper.

> But this reliance on SSH_ORIGINAL_COMMAND is somewhat sloppy       .
> and could break with an ssh change (Imagine if ssh's problem of    .
> unquoting commands was fixed)                                      .

What problem?

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Sat Oct  6 08:14:25 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 6 Oct 2001 08:14:25 +1000 (EST)
Subject: openbsd-compat
In-Reply-To: <423867.1002288903@lombard.ncac.gwu.edu>
Message-ID: <Pine.LNX.4.33.0110060813560.1847-100000@mothra.mindrot.org>

On Fri, 5 Oct 2001, Jason Mader wrote:

> When I compile openssh 2.9.9p2 with openssl sources in a relative directory 
> I had a problem with the openbsd-compat/Makefile that was generated.
> 
>   env CC=cc ./configure --with-ssl-dir=../openssl-0.9.6b
>
> The Makefile is in a subdirectory, but configure didn't append ../
> to an -I option to accomodate.  Never had this problem with earlier
> sources and I've ran configure the same way before.
>
> I edited that one Makefile by hand and didn't have any trouble in
> anything else.

Using an absolute path will work around this problem.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Sat Oct  6 08:17:32 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 6 Oct 2001 08:17:32 +1000 (EST)
Subject: patch - forceshell
In-Reply-To: <3BBE219C.C53F1987@berkeley.innomedia.com>
Message-ID: <Pine.LNX.4.33.0110060816380.1847-100000@mothra.mindrot.org>

On Fri, 5 Oct 2001, Don Mahurin wrote:

> Markus Friedl wrote:
> 
> > On Fri, Oct 05, 2001 at 09:41:57AM -0700, Don Mahurin wrote:
> > > (Imagine if ssh's problem of unquoting commands was fixed).
> >
> > what problem?
> 
> ssh localhost echo "lost&&found"
> 
> Though it's many a problem that most popular shells can only execute
> single string commands at the command line, and ssh relies on the shell.
> 
> Either ssh could exec the command itself, or re-quote everything.

It is your shell which is messing up the quoting here.

ssh localhost 'echo "lost&&found"'

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From dmahurin at berkeley.innomedia.com  Sat Oct  6 11:01:51 2001
From: dmahurin at berkeley.innomedia.com (Don Mahurin)
Date: Fri, 05 Oct 2001 18:01:51 -0700
Subject: patch - forceshell
References: <Pine.LNX.4.33.0110060816380.1847-100000@mothra.mindrot.org>
Message-ID: <3BBE57FF.D2310E9@berkeley.innomedia.com>



> > ssh localhost echo "lost&&found"
> >
> > Though it's many a problem that most popular shells can only execute
> > single string commands at the command line, and ssh relies on the shell.
> >
> > Either ssh could exec the command itself, or re-quote everything.
>
> It is your shell which is messing up the quoting here.

ssh discards the argument separation, and passes command and arguments as one
string to the shell.

forget the calling shell,
the C call: execlp ("ssh","ssh", "localhost", "echo", "lost&&found", NULL)
does the same thing.

-don




From jasonc at silicondefense.com  Sat Oct  6 11:21:58 2001
From: jasonc at silicondefense.com (C. Jason Coit)
Date: Fri, 05 Oct 2001 18:21:58 -0700
Subject: Defeating Timing Attacks
Message-ID: <3BBE5CB6.A5788E59@silicondefense.com>

Hello,

In response to the timing analysis attacks presented by Dawn Song et.
al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html
we
at Silicon Defense developed a patch for openssh to avoid such
measures.  

Timing Analysis Evasion changes were developed by C. Jason Coit and Roel
Jonkman of Silicon Defense.

These changes cause SSH to send packets unless request not to, exactly
every 50 ms.  IF no data is ready to be sent, SSH will send a bogus
packet with 16 bytes of data (which is the same size as most
keystrokes).  Thus someone performing timing analysis cannot determine
the inter keystroke timing of a user.  SSH will send bogus data for
about 1 second after the last keystroke.  This both increases the
difficulty of determining exact password lengths and conserves bandwidth
when a user is idle (e.g. taking a coffee break).  Both the Server and
the Client exhibit this behavior and yet our code places no limit on the
data rate(i.e. if the server needs to respond with large amounts of data
it will be able to do so with large packets and without the 50 ms timing
constraint).  

The patch is currently for openssh 2.9.2 only (should not be hard to
port) and is available below as well as on the Silicon Defense web site 

http://www.silicondefense.com/software/ssh/ssh-2.9.2-diffs

There is also a tarbal version of the the patched 2.9.2 openssh code
available for download.

http://www.silicondefense.com/software/ssh/opens3h-2.9p2.tar.gz

--

+--                                             --+
|        C. Jason Coit Programmer/Analyst         |
| *Silicon Defense - Technical Support for Snort* |
|        http://www.silicondefense.com/           |
+--                                              -+


From root at bizsystems.com  Sun Oct  7 11:09:09 2001
From: root at bizsystems.com (Michael Robinton)
Date: Sat, 6 Oct 2001 18:09:09 -0700 (PDT)
Subject: socks and misc patch to 2.9.9p2
Message-ID: <Pine.LNX.4.21.0110061757160.10200-200000@rambo.is.bizsystems.com>

Attached is a very small patch that allows the ssh clients to use the
socks5 library. It should work with socks4 but is untested.

Tested on linux only
configure --with-socks
configure --with-socks5


Also included is a configure option to disable scp statistics

--disable-scp-stats

modified files

openssh-2.9.9p2/acconfig.h
openssh-2.9.9p2/channels.c
openssh-2.9.9p2/configure.in
openssh-2.9.9p2/includes.h
openssh-2.9.9p2/scp.c
openssh-2.9.9p2/sshconnect.c

autoconf and autoheader need to be run

patches change only a line or two of actual C code in each file, most of
the changes are in the configure script

Hope this makes it into the distribution :-)

Michael Robinton
michael at bizsystems.com
-------------- next part --------------
diff -u openssh-2.9.9p2.old/acconfig.h openssh-2.9.9p2/acconfig.h
--- openssh-2.9.9p2.old/acconfig.h	Thu Sep 20 12:43:41 2001
+++ openssh-2.9.9p2/acconfig.h	Sat Oct  6 17:44:07 2001
@@ -111,6 +111,9 @@
  * message at run-time. */
 #undef RSAREF
 
+/* Define to disable scp statistics */
+#undef DISABLE_SCP_STATISTICS
+
 /* struct timeval */
 #undef HAVE_STRUCT_TIMEVAL
 
@@ -332,6 +335,30 @@
 
 /* Define if you want smartcard support */
 #undef SMARTCARD
+
+/* The code in sshconnect.c is written for SOCKS4. If SOCKS5 should be used
+   these needs redefining */
+#undef Rconnect
+#undef Rgetsockname
+#undef Rgetpeername
+#undef Rbind
+#undef Raccept
+#undef Rlisten
+#undef Rselect
+#undef Rrecvfrom
+#undef Rsendto
+#undef Rrecv
+#undef Rsend
+#undef Rread
+#undef Rwrite
+#undef Rrresvport
+#undef Rshutdown
+#undef Rlisten
+#undef Rclose
+#undef Rdup
+#undef Rdup2
+#undef Rfclose
+#undef Rgethostbyname
 
 @BOTTOM@
 
diff -u openssh-2.9.9p2.old/channels.c openssh-2.9.9p2/channels.c
--- openssh-2.9.9p2.old/channels.c	Mon Sep 17 22:53:12 2001
+++ openssh-2.9.9p2/channels.c	Sat Oct  6 17:09:30 2001
@@ -2481,7 +2481,12 @@
 		struct hostent *he;
 		struct in_addr my_addr;
 
+#if defined(SOCKS5)
+		he = Rgethostbyname(hostname);
+#else
+
 		he = gethostbyname(hostname);
+#endif
 		if (he == NULL) {
 			error("[X11-broken-fwd-hostname-workaround] Could not get "
 				"IP address for hostname %s.", hostname);
diff -u openssh-2.9.9p2.old/configure.in openssh-2.9.9p2/configure.in
--- openssh-2.9.9p2.old/configure.in	Tue Sep 25 15:39:38 2001
+++ openssh-2.9.9p2/configure.in	Sat Oct  6 17:41:54 2001
@@ -480,6 +480,141 @@
 	]
 )
 
+dnl checkfor SOCKS support
+AC_MSG_CHECKING(whether to support SOCKS)
+AC_ARG_WITH(socks,
+	[  --with-socks            Build with SOCKS firewall support.],
+	[ case "$withval" in
+  no)            
+	AC_MSG_RESULT(no)
+	;;           
+  yes)           
+	AC_MSG_RESULT(yes)
+	AC_CHECK_LIB(socks5, SOCKSconnect, [
+            socks=5
+            LIBS="-lsocks5 $LIBS"], [
+        AC_CHECK_LIB(socks, Rconnect, [
+            socks=4
+            LIBS="-lsocks $LIBS"], [
+                AC_MSG_ERROR(SOCKS library missing.  You must first install socks.) ] ) ] )
+    ;;
+  esac ],        
+	AC_MSG_RESULT(no)
+)                
+
+if test "x$socks" = "x"; then
+        AC_MSG_CHECKING(whether to support SOCKS5)
+        AC_ARG_WITH(socks5,
+        [  --with-socks5[=PATH]    Build with SOCKS5 firewall support.],
+        [ case "$withval" in
+  no)    
+	AC_MSG_RESULT(no)
+        ;;   
+  *)     
+	AC_MSG_RESULT(yes)
+            socks=5
+            if test "x$withval" = "xyes"; then
+              withval="-lsocks5"
+            else 
+              if test -d "$withval"; then
+                if test -d "$withval/include"; then
+                  CFLAGS="$CFLAGS -I$withval/include"
+                else
+                  CFLAGS="$CFLAGS -I$withval"
+                fi
+                if test -d "$withval/lib"; then
+                  withval="-L$withval/lib -lsocks5"
+                else
+                  withval="-L$withval -lsocks5"
+                fi
+              fi 
+            fi   
+            LIBS="$withval $LIBS"
+            # If Socks was compiled with Kerberos support, we will need
+            # to link against kerberos libraries.  Temporarily append
+            # to LIBS.  This is harmless if there is no kerberos support.
+            TMPLIBS="$LIBS"
+            LIBS="$LIBS $KERBEROS_LIBS"
+            AC_TRY_LINK([],
+                        [ SOCKSconnect(); ],
+                        [],
+                        [ AC_MSG_ERROR(Could not find the $withval library. You must first install socks5.) ])
+            LIBS="$TMPLIBS"
+            ;;   
+          esac ],
+          AC_MSG_RESULT(no)
+  )        
+fi
+
+if test "x$socks" = "x"; then
+        AC_MSG_CHECKING(whether to support SOCKS4)
+        AC_ARG_WITH(socks4,
+        [  --with-socks4[=PATH]    Compile with SOCKS4 firewall traversal
+support.],
+        [ case "$withval" in
+          no)    
+            AC_MSG_RESULT(no)
+            ;;   
+          *)     
+            AC_MSG_RESULT(yes)
+            socks=4
+            if test "x$withval" = "xyes"; then
+              withval="-lsocks"
+            else 
+              if test -d "$withval"; then
+                withval="-L$withval -lsocks"
+              fi 
+            fi   
+            LIBS="$withval $LIBS"
+            AC_TRY_LINK([],
+                        [ Rconnect(); ],
+                        [],
+                        [ AC_MSG_ERROR(Could not find the $withval library. 
+You must first install socks.) ])
+            ;;   
+          esac ],
+          AC_MSG_RESULT(no)
+ )        
+fi               
+
+
+
+if test "x$socks" = "x4"; then
+    AC_DEFINE(SOCKS)
+    AC_DEFINE(SOCKS4)
+    CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+    LDFLAGS="$LDFLAGS -L/usr/local/lib"
+fi               
+
+if test "x$socks" = "x5"; then
+    AC_DEFINE(SOCKS)
+    AC_DEFINE(SOCKS5)
+    AC_DEFINE(Rconnect,SOCKSconnect)
+    AC_DEFINE(Rgetsockname,SOCKSgetsockname)
+    AC_DEFINE(Rgetpeername,SOCKSgetpeername)
+    AC_DEFINE(Rbind,SOCKSbind)
+    AC_DEFINE(Raccept,SOCKSaccept)
+    AC_DEFINE(Rlisten,SOCKSlisten)
+    AC_DEFINE(Rselect,SOCKSselect)
+    AC_DEFINE(Rrecvfrom,SOCKSrecvfrom)
+    AC_DEFINE(Rsendto,SOCKSsendto)
+    AC_DEFINE(Rrecv,SOCKSrecv)
+    AC_DEFINE(Rsend,SOCKSsend)
+    AC_DEFINE(Rread,SOCKSread)
+    AC_DEFINE(Rwrite,SOCKSwrite)
+    AC_DEFINE(Rrresvport,SOCKSrresvport)
+    AC_DEFINE(Rshutdown,SOCKSshutdown)
+    AC_DEFINE(Rlisten,SOCKSlisten)
+    AC_DEFINE(Rclose,SOCKSclose)
+    AC_DEFINE(Rdup,SOCKSdup)
+    AC_DEFINE(Rdup2,SOCKSdup2)
+    AC_DEFINE(Rfclose,SOCKSfclose)
+    AC_DEFINE(Rgethostbyname,SOCKSgethostbyname)
+    CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+    CFLAGS="$CFLAGS -DSOCKS"
+    LDFLAGS="$LDFLAGS -L/usr/local/lib"
+fi               
+
 dnl    Checks for library functions.
 AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock dirname fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getopt getnameinfo getrlimit getrusage getttyent glob inet_aton inet_ntoa inet_ntop innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty readpassphrase realpath rresvport_af setdtablesize setenv setegid seteuid setlogin setproctitle setresgid setreuid setrlimit setsid setvbuf sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep sysconf tcgetpgrp utimes vsnprintf vhangup waitpid _getpty __b64_ntop)
 dnl    Checks for time functions
@@ -1838,6 +1973,12 @@
 	[  --disable-pututxline    disable use of pututxline() etc. ([uw]tmpx) [no]],
 	[ AC_DEFINE(DISABLE_PUTUTXLINE) ]
 )
+AC_ARG_ENABLE(scp-stats,
+[  --disable-scp-stats             disable scp statistics display [no]],
+       AC_DEFINE(DISABLE_SCP_STATISTICS)
+       AC_MSG_RESULT(yes)
+)
+
 AC_ARG_WITH(lastlog,
   [  --with-lastlog=FILE|DIR specify lastlog location [common locations]],
 	[
diff -u openssh-2.9.9p2.old/includes.h openssh-2.9.9p2/includes.h
--- openssh-2.9.9p2.old/includes.h	Wed Sep 19 19:07:51 2001
+++ openssh-2.9.9p2/includes.h	Sat Oct  6 17:10:37 2001
@@ -23,6 +23,11 @@
 
 #include "openbsd-compat/bsd-nextstep.h"
 
+#if defined(SOCKS5)
+/* does not support IPV6 */
+#include "socks.h"
+#endif
+
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/ioctl.h>
diff -u openssh-2.9.9p2.old/scp.c openssh-2.9.9p2/scp.c
--- openssh-2.9.9p2.old/scp.c	Wed Sep 19 17:57:56 2001
+++ openssh-2.9.9p2/scp.c	Sat Oct  6 17:42:08 2001
@@ -128,7 +128,11 @@
 int verbose_mode = 0;
 
 /* This is set to zero if the progressmeter is not desired. */
+#if defined(DISABLE_SCP_STATISTICS)
+int showprogress = 0;
+#else
 int showprogress = 1;
+#endif
 
 /* This is the program to execute for the secured connection. ("ssh" or -S) */
 char *ssh_program = _PATH_SSH_PROGRAM;
diff -u openssh-2.9.9p2.old/sshconnect.c openssh-2.9.9p2/sshconnect.c
--- openssh-2.9.9p2.old/sshconnect.c	Tue Aug  7 15:29:09 2001
+++ openssh-2.9.9p2/sshconnect.c	Sat Oct  6 17:10:55 2001
@@ -15,8 +15,6 @@
 #include "includes.h"
 RCSID("$OpenBSD: sshconnect.c,v 1.110 2001/07/25 14:35:18 markus Exp $");
 
-#include <openssl/bn.h>
-
 #include "ssh.h"
 #include "xmalloc.h"
 #include "rsa.h"
@@ -182,7 +180,12 @@
 	 */
 	if (privileged) {
 		int p = IPPORT_RESERVED - 1;
+#if defined(SOCKS)
+/* does not support IPV6 */
+		sock = Rrresvport(&p);
+#else /* SOCKS */  
 		sock = rresvport_af(&p, family);
+#endif /* SOCKS */
 		if (sock < 0)
 			error("rresvport: af=%d %.100s", family, strerror(errno));
 		else
@@ -326,7 +329,12 @@
 			 * the remote uid as root.
 			 */
 			temporarily_use_uid(pw);
-			if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) {
+#if defined(SOCKS)
+			if (Rconnect(sock, ai->ai_addr, ai->ai_addrlen) >= 0)
+#else /* SOCKS */
+			if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) 
+#endif /* SOCKS */
+			{
 				/* Successful connection. */
 				memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen);
 				restore_uid();

From mouring at etoh.eviladmin.org  Sun Oct  7 11:31:38 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sat, 6 Oct 2001 20:31:38 -0500 (CDT)
Subject: socks and misc patch to 2.9.9p2
In-Reply-To: <Pine.LNX.4.21.0110061757160.10200-200000@rambo.is.bizsystems.com>
Message-ID: <Pine.BSO.4.33.0110062025310.15847-100000@etoh.eviladmin.org>


Out of interest what is wrong with 'ProxyCommand' for handling this?  This
is kinda why this was design for to support socks and other proxy type
software without the nasty #ifdef/#endif code.

[.. ssh.1 ..]
     ProxyCommand
             Specifies the command to use to connect to the server.  The
	     command string extends to the end of the line, and is
             executed with /bin/sh. In the command string, `%h' will be
             substituted by the host name to connect and `%p' by the port.
	     The command can be basically anything, and should read from
             its standard input and write to its standard output.  It
             should eventually connect an sshd(8) server running on some
             machine, or execute sshd -i some where.  Host key management
             will be done using the HostName of the host being connected
             (defaulting to the name typed by the user).  Note that
             CheckHostIP is not available for connects with a proxy
             command.
[..]

[.. Example in readconf.c ..]
   Host puukko.hut.fi
     User t35124p
     ProxyCommand ssh-proxy %h %p


- Ben

On Sat, 6 Oct 2001, Michael Robinton wrote:

> Attached is a very small patch that allows the ssh clients to use the
> socks5 library. It should work with socks4 but is untested.
>
> Tested on linux only
> configure --with-socks
> configure --with-socks5
>
>
> Also included is a configure option to disable scp statistics
>
> --disable-scp-stats
>
> modified files
>
> openssh-2.9.9p2/acconfig.h
> openssh-2.9.9p2/channels.c
> openssh-2.9.9p2/configure.in
> openssh-2.9.9p2/includes.h
> openssh-2.9.9p2/scp.c
> openssh-2.9.9p2/sshconnect.c
>
> autoconf and autoheader need to be run
>
> patches change only a line or two of actual C code in each file, most of
> the changes are in the configure script
>
> Hope this makes it into the distribution :-)
>
> Michael Robinton
> michael at bizsystems.com
>



From michael at bizsystems.com  Sun Oct  7 13:09:38 2001
From: michael at bizsystems.com (Michael)
Date: Sat, 6 Oct 2001 19:09:38 -0800
Subject: socks and misc patch to 2.9.9p2
In-Reply-To: <Pine.BSO.4.33.0110062025310.15847-100000@etoh.eviladmin.org>
References: <Pine.LNX.4.21.0110061757160.10200-200000@rambo.is.bizsystems.com>
Message-ID: <200110070209.f9729kA31368@bzs.org>

> 
> Out of interest what is wrong with 'ProxyCommand' for handling this?
>  This is kinda why this was design for to support socks and other
> proxy type software without the nasty #ifdef/#endif code.

There are only 3 or 4 instances of this and no added code lines if 
you consider the effect of the ifdef's

doesn't work for scp, and even if it did, I've got a ton of scripts 
in existence on numerous machines that are using the old ssh-1.2.xx 
reference release. It would be nice to upgrade transparently. I'm 
sure that is why others have tried to add this feature in the past.
Michael

> 
> [.. ssh.1 ..]
>      ProxyCommand
>              Specifies the command to use to connect to the server. 
>              The
>       command string extends to the end of the line, and is
>              executed with /bin/sh. In the command string, `%h' will
>              be substituted by the host name to connect and `%p' by
>              the port.
>       The command can be basically anything, and should read from
>              its standard input and write to its standard output. 
>              It should eventually connect an sshd(8) server running
>              on some machine, or execute sshd -i some where.  Host
>              key management will be done using the HostName of the
>              host being connected (defaulting to the name typed by
>              the user).  Note that CheckHostIP is not available for
>              connects with a proxy command.
> [..]
> 
> [.. Example in readconf.c ..]
>    Host puukko.hut.fi
>      User t35124p
>      ProxyCommand ssh-proxy %h %p
> 
> 
> - Ben
> 
> On Sat, 6 Oct 2001, Michael Robinton wrote:
> 
> > Attached is a very small patch that allows the ssh clients to use the
> > socks5 library. It should work with socks4 but is untested.
> >
> > Tested on linux only
> > configure --with-socks
> > configure --with-socks5
> >
> >
> > Also included is a configure option to disable scp statistics
> >
> > --disable-scp-stats
> >
> > modified files
> >
> > openssh-2.9.9p2/acconfig.h
> > openssh-2.9.9p2/channels.c
> > openssh-2.9.9p2/configure.in
> > openssh-2.9.9p2/includes.h
> > openssh-2.9.9p2/scp.c
> > openssh-2.9.9p2/sshconnect.c
> >
> > autoconf and autoheader need to be run
> >
> > patches change only a line or two of actual C code in each file, most of
> > the changes are in the configure script
> >
> > Hope this makes it into the distribution :-)
> >
> > Michael Robinton
> > michael at bizsystems.com
> >
> 


From lists at fips.de  Sun Oct  7 12:49:15 2001
From: lists at fips.de (Philipp Buehler)
Date: Sun, 7 Oct 2001 04:49:15 +0200
Subject: BadOption failures "annoying"
Message-ID: <20011007044915.A8875@pohl.fips.de>

Hi,

some question about the configuration behaviour of openssh..

sshd.8
     -f configuration_file
             Specifies the name of the configuration file.  The default is
             /etc/sshd_config. sshd refuses to start if there is no configura-
             tion file.

While servconf.c has the routine 
fill_default_server_options(ServerOptions *options)
which sets valid/common options by "itself" - thus I *can* run sshd
w/ an empty configuration file anyway .. hello?

servconf.c also kills the startup if it cant recognize an option - thus
if I make a typo (or in this case use an option from a newer sshd on an
older installation) sshd will fail.

Ok, <paranoia> It's better to refuse starting then *maybe* in an
insecure configuration mode </paranoia> .. and yes <pedantic> test your
stuff before restarting </pedantic> .. but hey, sometimes you are in a 
hurry .. :-}
Or imagine a nulled configuration file (FS fuckup, whatever) sshd will start
also.. w/ possible insecure configuration ....

<rant>
openssh tends to develop major paranoia .. security is also about 
realiablity. sshd is usually a *remote* tool, and way-to-easy-self-shoot-feet
is not fun (yeah, tell me something about terminalservers)
same for removing 'cipher none' .. ever thought of IPsec connected LANs
where maybe a slow machine is connected with "trusted cables" to the IPsec
gateway.. it's nice to still have public keys but not the crypting overhead
while "work" and it's still encrypted via the untrusted path..
</rant>

so long,
ciao
-- 
Philipp Buehler, aka fips | sysfive.com GmbH | BOfH | NUCH | <double-p> 

#1: Break the clue barrier!
#2: Already had buzzword confuseritis ? 


From Matthew_Clarke at mindlink.bc.ca  Sun Oct  7 13:12:17 2001
From: Matthew_Clarke at mindlink.bc.ca (Matthew Clarke)
Date: Sat, 6 Oct 2001 20:12:17 -0700
Subject: trivial grammatical patch
Message-ID: <20011006201217.A9623@ds0.van.maves.ca>

Hi.

Debug message "No RSA1 key file blah" misled me for a few seconds earlier
today.  The message is meaning to say "key file blah is not an RSA1 key
file", whereas I interpreted it to mean "key file blah does not exist".

Trivial patch against 2.9.9p2's authfile.c:

--- authfile.c.orig	Sat Oct  6 19:52:16 2001
+++ authfile.c	Sat Oct  6 19:53:11 2001
@@ -250,7 +250,7 @@
 
 	/* Check that it is at least big enough to contain the ID string. */
 	if (len < sizeof(authfile_id_string)) {
-		debug3("No RSA1 key file %.200s.", filename);
+		debug3("Not RSA1 key file %.200s.", filename);
 		buffer_free(&buffer);
 		return NULL;
 	}
@@ -260,7 +260,7 @@
 	 */
 	for (i = 0; i < sizeof(authfile_id_string); i++)
 		if (buffer_get_char(&buffer) != authfile_id_string[i]) {
-			debug3("No RSA1 key file %.200s.", filename);
+			debug3("Not RSA1 key file %.200s.", filename);
 			buffer_free(&buffer);
 			return NULL;
 		}
@@ -336,7 +336,7 @@
 
 	/* Check that it is at least big enough to contain the ID string. */
 	if (len < sizeof(authfile_id_string)) {
-		debug3("No RSA1 key file %.200s.", filename);
+		debug3("Not RSA1 key file %.200s.", filename);
 		buffer_free(&buffer);
 		close(fd);
 		return NULL;
@@ -347,7 +347,7 @@
 	 */
 	for (i = 0; i < sizeof(authfile_id_string); i++)
 		if (buffer_get_char(&buffer) != authfile_id_string[i]) {
-			debug3("No RSA1 key file %.200s.", filename);
+			debug3("Not RSA1 key file %.200s.", filename);
 			buffer_free(&buffer);
 			close(fd);
 			return NULL;

-- 
"With your own code to haunt you, who needs users?"
				-- Maarten Wiltink


From djm at mindrot.org  Sun Oct  7 15:46:56 2001
From: djm at mindrot.org (Damien Miller)
Date: Sun, 7 Oct 2001 15:46:56 +1000 (EST)
Subject: BadOption failures "annoying"
In-Reply-To: <20011007044915.A8875@pohl.fips.de>
Message-ID: <Pine.LNX.4.33.0110071543050.8181-100000@mothra.mindrot.org>

On Sun, 7 Oct 2001, Philipp Buehler wrote:

> Ok, <paranoia> It's better to refuse starting then *maybe* in an
> insecure configuration mode </paranoia> .. and yes <pedantic> test
> your stuff before restarting </pedantic> .. 

Exactly. We even provide a commandline switch (sshd -t) which will 
test configs for you.

> but hey, sometimes
> you are in a hurry .. :-} Or imagine a nulled configuration file
> (FS fuckup, whatever) sshd will start also.. w/ possible insecure
> configuration ....

sshd's config is secure by default.

> same for removing 'cipher none' .. ever
> thought of IPsec connected LANs where maybe a slow machine is
> connected with "trusted cables" to the IPsec gateway.. it's nice to
> still have public keys but not the crypting overhead while "work"
> and it's still encrypted via the untrusted path..

If you want rlogin, then use rlogin.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From jmknoble at pobox.com  Sun Oct  7 15:55:52 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Sun, 7 Oct 2001 01:55:52 -0400
Subject: BadOption failures "annoying"
In-Reply-To: <20011007044915.A8875@pohl.fips.de>; from lists@fips.de on Sun, Oct 07, 2001 at 04:49:15AM +0200
References: <20011007044915.A8875@pohl.fips.de>
Message-ID: <20011007015552.A1593@quipu.half.pint-stowp.cx>

Circa 2001-Oct-07 04:49:15 +0200 dixit Philipp Buehler:

  [...]
: servconf.c also kills the startup if it cant recognize an option -
: thus if I make a typo (or in this case use an option from a newer
: sshd on an older installation) sshd will fail.
: 
: Ok, <paranoia> It's better to refuse starting then *maybe* in an
: insecure configuration mode </paranoia> .. and yes <pedantic> test
: your stuff before restarting </pedantic> .. but hey, sometimes you
: are in a hurry .. :-}
: Or imagine a nulled configuration file (FS fuckup, whatever) sshd
: will start also.. w/ possible insecure configuration ....

With OpenSSH-2.9.9, sshd has an additional option:

     -t      Test mode.  Only check the validity of the configuration
             file and sanity of the keys.  This is useful for updating
             sshd reliably as configuration options may change.

This may help out the situation you're describing.  For example, if you
have a System V init:

  /usr/sbin/sshd -t && /etc/init.d/sshd restart

Or, if you think the file may be empty:

  SSHD_CONFIG="/etc/ssh/sshd_config"
  [ -s "${SSHD_CONFIG}" ] && /usr/sbin/sshd -t -f "${SSHD_CONFIG}" \
    && /etc/init.d/sshd restart

: <rant>
: openssh tends to develop major paranoia .. security is also about 
: realiablity. sshd is usually a *remote* tool, and
: way-to-easy-self-shoot-feet is not fun (yeah, tell me something
: about terminalservers)

If you're concerned about reliability, you should probably use 'sshd
-t' in combination with version control on the config file, along with
an automated process to move an older, known-good config file into
place and restart sshd if a newly changed one doesn't work.  You'll
probably also want a watchdog process to restart sshd if it falls over
for any reason.

Neither of those things is really a job for OpenSSH.  Besides, if you
need reliability for sshd, you probably need it for other services as
well, and you probably need to customize it according to site-specific
policy.

Let OpenSSH concentrate on what it does: secure remote terminal
sessions and secure remote command execution.  It's quite enough.

: same for removing 'cipher none' .. ever thought of IPsec connected
: LANs where maybe a slow machine is connected with "trusted cables"
: to the IPsec gateway.. it's nice to still have public keys but not
: the crypting overhead while "work" and it's still encrypted via the
: untrusted path..

If you truly need 'cipher none', you should probably know enough about
OpenSSH to be able to put it back easily.  Otherwise, a slow machine
with a fast cipher (blowfish, arcfour) is still liable to be bound by
servicing interrupts on the network adapter more than anything else.
Don't forget to turn off compression over a fast network.

-- 
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: 249 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011007/17fa613e/attachment.bin 

From mouring at etoh.eviladmin.org  Sun Oct  7 17:11:10 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sun, 7 Oct 2001 02:11:10 -0500 (CDT)
Subject: socks and misc patch to 2.9.9p2
In-Reply-To: <200110070209.f9729kA31368@bzs.org>
Message-ID: <Pine.BSO.4.33.0110070151460.2237-100000@etoh.eviladmin.org>



On Sat, 6 Oct 2001, Michael wrote:

> >
> > Out of interest what is wrong with 'ProxyCommand' for handling this?
> >  This is kinda why this was design for to support socks and other
> > proxy type software without the nasty #ifdef/#endif code.
>
> There are only 3 or 4 instances of this and no added code lines if
> you consider the effect of the ifdef's
>
> doesn't work for scp, and even if it did, I've got a ton of scripts
> in existence on numerous machines that are using the old ssh-1.2.xx
> reference release. It would be nice to upgrade transparently. I'm
> sure that is why others have tried to add this feature in the past.
> Michael
>

If it does not work for scp than it should be fixed.  This patch pretty
much is saying.. "I don't care to understand existing features therefor I
will add a different way of doing the same thing."  If you wish to
describe why it breaks, and suggest a solution patch than great.

Besides, anytime you add in #ifdef into code it makes it harder to read
and mentally process.   And if you have done an #ifdef count between the
virgin OpenBSD version and the portable we have 3x (slowly creaping up on
4x) as many which is too may.  The whole thinking.. "It is just 4 more
#ifdef"  leads to crap code like SSH-1.2.x.

I doubt this will be added to the upstream code (in turn it won't get to
the portable tree).  So I think fixing and useing the ProxyCommand or a
local patch will be your only two options.

- Ben



From lists at fips.de  Sun Oct  7 18:43:42 2001
From: lists at fips.de (Philipp Buehler)
Date: Sun, 7 Oct 2001 10:43:42 +0200
Subject: BadOption failures "annoying"
In-Reply-To: <20011007015552.A1593@quipu.half.pint-stowp.cx>; "Jim Knoble" on 07.10.2001 @ 07:55:52 CEST
References: <20011007044915.A8875@pohl.fips.de> <20011007015552.A1593@quipu.half.pint-stowp.cx>
Message-ID: <20011007104342.A9438@pohl.fips.de>

On 07/10/2001, Jim Knoble <jmknoble at pobox.com> wrote To openssh-unix-dev at mindrot.org:
>   SSHD_CONFIG="/etc/ssh/sshd_config"
>   [ -s "${SSHD_CONFIG}" ] && /usr/sbin/sshd -t -f "${SSHD_CONFIG}" \
>     && /etc/init.d/sshd restart

Yeah sure.

> If you're concerned about reliability, you should probably use 'sshd
> -t' in combination with version control on the config file, along with
> an automated process to move an older, known-good config file into
> place and restart sshd if a newly changed one doesn't work.  You'll
> probably also want a watchdog process to restart sshd if it falls over
> for any reason.

Uhuu.. the more 'automated process' the more point of possible failures.
(see below also)

> Neither of those things is really a job for OpenSSH.  Besides, if you
> need reliability for sshd, you probably need it for other services as
> well, and you probably need to customize it according to site-specific
> policy.

The point is:
If $service fails to start at bootup, I still can log in and start by hand.
*But* this is obviously not "valid" for ssh.
 
> Let OpenSSH concentrate on what it does: secure remote terminal
> sessions and secure remote command execution.  It's quite enough.

Sure. My keypoint was (and even Damien told me "default is secure"):
sshd refuses to start, if the config file is broken. WHY?
It's rather a short patch to revert to the "secure default" configuration,
make a critical syslog entry about this and *start*, so I am not forced
to travel to the machine for a possible 2 minute "fix" [1]

Corruption of the config file can occur also several conditions, and
this "reverting" to a "known good" config by some script is errorprone
too.

ciao
[1] Which I have to do now and thus no patch for now, but I will write one.
-- 
Philipp Buehler, aka fips | sysfive.com GmbH | BOfH | NUCH | <double-p> 

#1: Break the clue barrier!
#2: Already had buzzword confuseritis ? 


From jmknoble at pobox.com  Sun Oct  7 19:17:05 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Sun, 7 Oct 2001 05:17:05 -0400
Subject: BadOption failures "annoying"
In-Reply-To: <20011007104342.A9438@pohl.fips.de>; from lists@fips.de on Sun, Oct 07, 2001 at 10:43:42AM +0200
References: <20011007044915.A8875@pohl.fips.de> <20011007015552.A1593@quipu.half.pint-stowp.cx> <20011007104342.A9438@pohl.fips.de>
Message-ID: <20011007051705.C1593@quipu.half.pint-stowp.cx>

Circa 2001-Oct-07 10:43:42 +0200 dixit Philipp Buehler:

: Uhuu.. the more 'automated process' the more point of possible failures.
: (see below also)

I disagree.  Processes that rely on humans are significantly more
error-prone than automated ones.  Viz.: "but ... sometimes you're in a
hurry."  Properly designed automated tools help prevent mistakes, not
cause them.

: The point is:
: If $service fails to start at bootup, I still can log in and start by hand.
: *But* this is obviously not "valid" for ssh.

So check your sshd config file for validity *before* you move it into
place.

: Sure. My keypoint was (and even Damien told me "default is secure"):
: sshd refuses to start, if the config file is broken. WHY?
: It's rather a short patch to revert to the "secure default" configuration,
: make a critical syslog entry about this and *start*, so I am not forced
: to travel to the machine for a possible 2 minute "fix" [1]
: 
: Corruption of the config file can occur also several conditions, and
: this "reverting" to a "known good" config by some script is errorprone
: too.

If you've got filesystem corruption, what makes you think the sshd
binary isn't corrupted as well?  Or /sbin/init, or the OS kernel?  All
bets are off then, no?  (And if filesystem corruption is likelihood,
why not put the critical system components onto a corruption-resistant
read-only medium, such as CD-R)?

So we've solved the problem of operator error (check the config file
before committing it).  And we've admitted that filesystem corruption
can hose a helluva lot more than just sshd_config.

Under what other conditions is the config file liable to be corrupted?
(Note: fires, floods, explosions, nuclear war, natural disasters, or
Acts of God aren't really merely "corruption", but rather "destruction"
or "obliteration").

-- 
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: 249 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011007/b28e4a20/attachment.bin 

From markus at openbsd.org  Sun Oct  7 20:36:31 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 7 Oct 2001 12:36:31 +0200
Subject: BadOption failures "annoying"
In-Reply-To: <20011007044915.A8875@pohl.fips.de>; from lists@fips.de on Sun, Oct 07, 2001 at 04:49:15AM +0200
References: <20011007044915.A8875@pohl.fips.de>
Message-ID: <20011007123630.C26797@folly>

On Sun, Oct 07, 2001 at 04:49:15AM +0200, Philipp Buehler wrote:
> Ok, <paranoia> It's better to refuse starting then *maybe* in an
> insecure configuration mode </paranoia> .. and yes <pedantic> test your
> stuff before restarting </pedantic> .. but hey, sometimes you are in a 
> hurry .. :-}
> Or imagine a nulled configuration file (FS fuckup, whatever) sshd will start
> also.. w/ possible insecure configuration ....

the default is not considered insecure.

sshd assumes that if you do
	sshd -f /dev/null
you know what you are doing.

moreover, if you do
	echo bogusoption yes > sshd_config
	sshd -f sshd_config
then it also assumes that you know what you are doing.

> <rant>
> openssh tends to develop major paranoia .. security is also about 
> realiablity.

please send a bug report if you discover a realiablity bug.

> sshd is usually a *remote* tool, and way-to-easy-self-shoot-feet
> is not fun (yeah, tell me something about terminalservers)

you can start backup daemons if you don't understand the
documentation.

> same for removing 'cipher none'

cipher none support got not removed, it was never supported.

> .. ever thought of IPsec connected LANs
> where maybe a slow machine is connected with "trusted cables" to the IPsec
> gateway..

there is not standard API for figuring out the IPsec SAs
for the underlying TCP connection.

> it's nice to still have public keys but not the crypting overhead
> while "work"

how much overhead is it in interactive sessions?

> and it's still encrypted via the untrusted path..

-m


From markus at openbsd.org  Sun Oct  7 20:41:26 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 7 Oct 2001 12:41:26 +0200
Subject: BadOption failures "annoying"
In-Reply-To: <20011007104342.A9438@pohl.fips.de>; from lists@fips.de on Sun, Oct 07, 2001 at 10:43:42AM +0200
References: <20011007044915.A8875@pohl.fips.de> <20011007015552.A1593@quipu.half.pint-stowp.cx> <20011007104342.A9438@pohl.fips.de>
Message-ID: <20011007124126.D26797@folly>

On Sun, Oct 07, 2001 at 10:43:42AM +0200, Philipp Buehler wrote:
> If $service fails to start at bootup, I still can log in and start by hand.
> *But* this is obviously not "valid" for ssh.

so you test your sshd config by
	# vi sshd_config
	# reboot
?


From dmanton at emea.att.com  Sun Oct  7 21:32:44 2001
From: dmanton at emea.att.com (Manton, Doug)
Date: Sun, 7 Oct 2001 12:32:44 +0100 
Subject: socks and misc patch to 2.9.9p2
Message-ID: <DE57FCAAD8EB8941940801CDCEFD356D6D0A46@gbpormsx02.emea.att.com>


On Sun 07/10/2001 02:32, mouring at etoh.eviladmin.org wrote:
> Out of interest what is wrong with 'ProxyCommand' for handling this?  This
> is kinda why this was design for to support socks and other proxy type
> software without the nasty #ifdef/#endif code.

Can anyone advise a way of using ProxyCommand for socks v4/v5 under AIX
4.3.x?  I use runsocks under Solaris and Linux, but this is not available
for AIX.  I have been using the NEC socks library to socksify OpenSSH at
compile time, but if there is a better way...

BTW, AIX 4.3.2 and above can dynamically socksify connects, but only to
socks v5 servers.

Many thanks,

Doug Manton, AT&T Business Commercial Security


From hpstr at operamail.com  Mon Oct  8 01:04:46 2001
From: hpstr at operamail.com (Hans Peter Stroebel)
Date: Sun, 7 Oct 2001 17:04:46 +0200
Subject: FYI : FiSh connection over SSH fails : midnight commander freezing
Message-ID: <01100716570301.06780@yankee>


Hello List-Members,

the forwarded message below is an excerpt from an actual discussion from the 
Midnigt Commander mailing list (mc at gnome.org, see www.gnome.org/mc/ for 
details).

It`s about a bug and a yet half-implemented feature in the mc fish (File 
transfer over shell) virtual file system support.
The FiSh filesystem allows the user to treat files on a remote server over a 
shell (ssh/rsh) connection as if they were local files, including the 
transfer of files over the shell connection from one filesystem to another.

This feature works fine over a ssh connection if ssh authenticates the user 
with a RSA key that is not protected with any passphrase.

If ssh requires any user interaction (passphrase request) instead, it does so 
on /dev/tty. mc cannot handle this I/O on /dev/tty yet and freezes. This 
problem should affect mc on all operating systems.

We're thinking about several solutions :

One of them would be to extend the ssh client to support an "-I" switch that 
makes it accepting the password on it`s STDIN, and (maybe) surpressing the 
password question or redirect it to it`s STDOUT or /dev/null.

I'm aware that normally this is not a desired behaviour (to avoid that users 
are storing unencrypted passwords ?)
In this case it is not intended to store the unencrypted password in an 
expect script for example, but to enable the midnight commander to request 
the password in a popup window and then feed it to the ssh client`s stdin.
It is, for example, intended for use on computers where it might not be 
desired to store unprotected RSA private keys without passphrase, like 
notebooks.

Reading the code of the ssh client, it seems to me (I'm a C beginner, but 
somewhat intermediate in Perl) that it might be able to read from STDIN, but 
I did not figure out how yet (see below).

Any hints or comments would be highly welcome.

Thank you.


----------  Weitergeleitete Nachricht  ----------
Subject: Re: FiSH Connection fails : mc freezing
Date: Sun, 7 Oct 2001 15:40:58 +0200
From: Hans Peter Stroebel <hpstr at operamail.com>
To: mc at gnome.org


Am Sonntag,  7. Oktober 2001 10:44 schrieb Pavel Roskin:

Hi Pavel, Hi Pavel,   ;-)

> > fish does not suuport password auth because ssh always reads passwd from
> > /ddev/tty. Fixssh to acceptt passwd from stdin, and we an fix mc.
>
> Actually, there is a good reason why ssh uses /dev/tty.  The standard
> channels (stdout, stdin, stderr) are connected to the remote program and
> should be completely independent from the authentication.  At least the
> recent versions of OpenSSH do it this way.  You can do this:
>
> ssh prog <infile >outfile 2>errfile

I tried that; indeed, it is not possible to redirect SSH`s input/output sent
to /dev/tty.

On the other hand, I think it would not be necessary to make SSH accept all
input on it`s stdin, would it ? The passphrase should be sufficient.

I tried to examine the code of OpenSSH 2.3.0p1 and to insert an -I
switch, but it seems to be quite complicated to me.

BTW, who did "invent" this switch ? Google left me completely clueless.

However, the code in cli.c (precisely, the client function
"cli_read_passphrase") seems to have the possibilty to read even from stdin :

  /*
   * Presents a prompt and returns the response allocated with xmalloc().
   * Uses /dev/tty or stdin/out depending on arg.  Optionally disables echo
   * of response depending on arg.  Tries to ensure that no other userland
   * buffer is storing the response.
   */

As one of the arguments a variable "from_stdin" is passed, but I did whether
figure out where this variable is set nor where it is defined, it seems to be
always 0.

Depending on the value of "from_stdin", the function "cli_open" seems to
return the file descriptors of /dev/tty or of stdin/stdout. I have no idea
yet if this behaviour, most probably depending on the value of "from_stdin"
and maybe "cli_input" and "cli_output" (initialized with -1) can be
influenced by an external application like mc _without_ hacking ssh, and if
it concerns only the initial operation of reading the password or _all_ of
SSH`s I/O.

If yes, this might help to solve the problem.

> It is possible to control /dev/tty of ssh if it's run in a pseudoterminal,
> similar to how MC runs the subshell.  Still it will require that mc

I did not get SSH to allocate a pseudoterminal, it refuses if it is not the
controlling tty.

> interprets the output of ssh somehow.  Maybe MC could capture all output
> until ssh runs the fish server _or_ asks for the password/passphrase, but
> I envision problems with making it secure and reliable.

I tried even to surpress SSH`s output of the password request, no success.
After having compiled it for about some 20 times, I gave up (for now...).

At least, I did not break the program with my first tries in C ;-)

However, I`m not sure if this could resolve the problem, as the password has
to be fed to SSH in the right moment anyway.

> Another solution would be to hide the panels and run ssh on the same tty
> as MC.  The panels would be restored when the remote fish server answers.
> This would not be pretty, but it would completely eliminate the need to
> redirect /dev/tty and capture/feed anything.

How would this work ? I found no possibility to hide the panels temporarily ?
Hacking required ?

[...]

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

Regards,

Hans

-- 

Hans Peter Stroebel <hpstr at operamail.com>

Yes, I do. But not Yahoo.


From gotoh at taiyo.co.jp  Mon Oct  8 01:14:15 2001
From: gotoh at taiyo.co.jp (Shun-ichi GOTO)
Date: Mon, 08 Oct 2001 00:14:15 +0900 (JST)
Subject: socks and misc patch to 2.9.9p2
In-Reply-To: <DE57FCAAD8EB8941940801CDCEFD356D6D0A46@gbpormsx02.emea.att.com>
References: <DE57FCAAD8EB8941940801CDCEFD356D6D0A46@gbpormsx02.emea.att.com>
Message-ID: <20011008.001415.109520300.gotoh@taiyo.co.jp>


>>>>> at Sun, 7 Oct 2001 12:32:44 +0100 
>>>>> "Manton, Doug" <dmanton at emea.att.com> said,> 

> Can anyone advise a way of using ProxyCommand for socks v4/v5 under AIX
> 4.3.x?  I use runsocks under Solaris and Linux, but this is not available
> for AIX.  I have been using the NEC socks library to socksify OpenSSH at
> compile time, but if there is a better way...

Try this command for ProxyCommand.
Comment of source describes how to use.
http://www.imasy.or.jp/~gotoh/ssh/connect.c

Current version of connect.c supports SOCKS version 5 and 4 and HTTP
proxy (CONNECT method).  It doesn't have configure program but using
standard functions.  So I expect it can be compiled AIX.

--- Regards,
 Shun-ichi Goto  <gotoh at taiyo.co.jp>
   R&D Group, TAIYO Corp., Tokyo, JAPAN


From markus at openbsd.org  Mon Oct  8 03:29:52 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 7 Oct 2001 19:29:52 +0200
Subject: FYI : FiSh connection over SSH fails : midnight commander freezing
In-Reply-To: <01100716570301.06780@yankee>; from hpstr@operamail.com on Sun, Oct 07, 2001 at 05:04:46PM +0200
References: <01100716570301.06780@yankee>
Message-ID: <20011007192952.A10@folly>

On Sun, Oct 07, 2001 at 05:04:46PM +0200, Hans Peter Stroebel wrote:
> It`s about a bug and a yet half-implemented feature in the mc fish (File 
> transfer over shell) virtual file system support.
> The FiSh filesystem allows the user to treat files on a remote server over a 
> shell (ssh/rsh) connection as if they were local files, including the 
> transfer of files over the shell connection from one filesystem to another.
> 
> This feature works fine over a ssh connection if ssh authenticates the user 
> with a RSA key that is not protected with any passphrase.
> 
> If ssh requires any user interaction (passphrase request) instead, it does so 
> on /dev/tty. mc cannot handle this I/O on /dev/tty yet and freezes. This 
> problem should affect mc on all operating systems.
> 
> We're thinking about several solutions :

you could abuse ssh-askpass:

if $DISPLAY is set and stdin is not a tty then
ssh executes $SSH_ASKPASS and waits for the userinput
on stdin.

-m


From mjt at tls.msk.ru  Mon Oct  8 09:21:56 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Mon, 08 Oct 2001 03:21:56 +0400
Subject: Using -lssh as shared library
Message-ID: <3BC0E394.6F0361A6@tls.msk.ru>

Hello!  This is my first post to this list... ;)

I'm not shure if someone will be interested in this topic.
For me, it has interest, as long as I maintain 100+ unix
(linux) servers with dialup access and every package update
cost some significant time to download, so package size is
somewhat important here.

I looked to openssh and realized that package consists of
several programs, all uses common set of routines from
libssh and libopenbsd-compat.  So I thought about building
those libs as shared objects, instead of linking those
routines statically into every program.  After some minor
tweaks, I successefully did that, saving about 1/3 of
total package size (3 rpms -- openssh, openssh-server
and openssh-clients -- was 650Kb befor and 420Kb after).

While tweaking makefiles and so on, I realized one minor
problem with libssl.a: it is not a complete library per
se.  Yes, I know that it isn't intended to be used by
other programs (btw, pam_ssh uses parts of libssh), but
keeping it in a good state may be helpful anyway.  One
issue with this library is that it refers to an external
variable, IPV4or6, that itself isn't in library, but
defined in several source files instead, repeating the
same lines every time.  So, then libssl is a shared
object, programs like ssh-keygen (those that doesn't
define IPV4or6) will not build.

I hacked source a bit, but not like this hack very well.
What I did is created one extra file, ipv4or6.c, that
contains definition of this variable, added it into
list of objects for libssl, and changed actual declarations
in ssh.c, sshd.c, ssh-keyscan.c and the like to be simple
"extern int IPV4or6".  This allowed me to successefully
use shared libssl.so.  I attached a patch named
openssh-2.9.9p2-ipv4or6.diff, that does exactly this.

Next, some tweaking for Makefile was required.  libssh.a
and libopenbsd-compat.a was "hardcoded" into link and dep
lines in Makefile, so if there is no libopenbsd-compat
(but it's contents is within -lssh), link will be funny.
Second patch, openssh-2.9.9p2-ssh_libs.diff, introduces
two make variables, SSH_LIBS="libopenbsd-compat.a libssl.a",
for dependence lines, and SSH_LDFLAGS="-lssl -lopenbsd-compat",
for link lines, and replaces hardcoded libssl.a etc with
those 2 variables.

Note that before the change, ssh-keyscan linked with -lssh
twice:
 $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
Looking into -lssh and -lopenbsd-compat, I don't think it is
necessary: there is no "back-references" from -lopenbsd-compat
to -lssh.  The patch mentioned above fixes this too.
For now (and I doubt I'll be able to do that at all, as long
as I have little expirience with building/using shared libs
on *many* platforms, only linux and solaris), I didn't changed
makefiles etc to actually *use* shared lib -- steps performed
externally -- but those changes allowed me to do what I wanted
to.

Actual steps are performed from rpm's .spec file:  instead of
just `make', I use the following sequence:

--
make libssh.a CC="gcc -fPIC"
make -C openbsd-compat CC="gcc -fPIC"
gcc -shared -Wl,-soname,libssh-%{version}.so -o libssh.so \
 -Wl,--whole-archive libssh.a openbsd-compat/libopenbsd-compat.a \
 -Wl,--no-whole-archive -lcrypto -lz
make SSH_LIBS=libssh.so SSH_LDFLAGS=-lssh
--

and, at install stage, additional

--
install -m755 libssh.so $RPM_BUILD_ROOT%{_libdir}/libssh-%{version}.so
--

line is needed too, after real `make install'.


Adding real shared lib suport into makefile(s) will require to
create separate directory for libssh, or to use some other
extension instead of .o for all it's components, due to difference
in compiler flags (-fPIC for gcc is needed to compile position-
independant code), and those flags together with command to make
shared lib are very platform-dependant.

And one more issue/question at the end.  I noticied that *all*
openssh programs linked with -lpam, -lwrap, -lutil and so on --
libraries really needed for sshd *only*.  I can't say this is
"bug", but looks somewhat inaccurate.  Looking into configure.in,
it is relatively hard to "clean up" things.  3rd patch attached,
openssh-2.9.9p2-libs.diff, an *alternative* to ssh_libs patch
(both touches the same lines in Makefile.in), is an attempt to
fix this too.  It is only first step into this direction, some
more cleanups should be done (for example, there is no -lz needed
for ssh-keygen, kerberos and s/key libs should be checked too and
so on).

Thank you for great product!

Regards,
 Michael.
-------------- next part --------------
This diff against 2.9.9p2 creates new file, ipv4or6.c, that holds
`int IPV4or6' variable used in other code.  Instead of defining this
variable in other source files, it is now in this file instead, as
part of libssh library.

diff -rNu1 openssh-2.9.9p2.orig/Makefile.in openssh-2.9.9p2/Makefile.in
--- openssh-2.9.9p2.orig/Makefile.in	Tue Sep 18 09:06:22 2001
+++ openssh-2.9.9p2/Makefile.in	Sun Oct  7 23:05:32 2001
@@ -48,3 +48,3 @@
 
-LIBSSH_OBJS=atomicio.o authfd.o authfile.o bufaux.o buffer.o canohost.o channels.o cipher.o compat.o compress.o crc32.o deattack.o dh.o dispatch.o mac.o hostfile.o key.o kex.o kexdh.o kexgex.o log.o match.o misc.o mpaux.o nchan.o packet.o radix.o rijndael.o entropy.o readpass.o rsa.o scard.o ssh-dss.o ssh-rsa.o tildexpand.o ttymodes.o uidswap.o uuencode.o xmalloc.o 
+LIBSSH_OBJS=atomicio.o authfd.o authfile.o bufaux.o buffer.o canohost.o channels.o cipher.o compat.o compress.o crc32.o deattack.o dh.o dispatch.o mac.o hostfile.o key.o kex.o kexdh.o kexgex.o log.o match.o misc.o mpaux.o nchan.o packet.o radix.o rijndael.o entropy.o readpass.o rsa.o scard.o ssh-dss.o ssh-rsa.o tildexpand.o ttymodes.o uidswap.o uuencode.o xmalloc.o ipv4or6.o
 
diff -rNu1 openssh-2.9.9p2.orig/ipv4or6.c openssh-2.9.9p2/ipv4or6.c
--- openssh-2.9.9p2.orig/ipv4or6.c	Thu Jan  1 03:00:00 1970
+++ openssh-2.9.9p2/ipv4or6.c	Sun Oct  7 23:10:32 2001
@@ -0,0 +1,9 @@
+#include "includes.h"
+
+/* Flag indicating whether IPv4 or IPv6.  This can be set on the command line.
+   Default value is AF_UNSPEC means both IPv4 and IPv6. */
+#ifdef IPV4_DEFAULT
+int IPv4or6 = AF_INET;
+#else
+int IPv4or6 = AF_UNSPEC;
+#endif
diff -rNu1 openssh-2.9.9p2.orig/ssh-keyscan.c openssh-2.9.9p2/ssh-keyscan.c
--- openssh-2.9.9p2.orig/ssh-keyscan.c	Fri Sep 21 00:30:09 2001
+++ openssh-2.9.9p2/ssh-keyscan.c	Sun Oct  7 23:08:13 2001
@@ -36,9 +36,4 @@
 
-/* Flag indicating whether IPv4 or IPv6.  This can be set on the command line.
-   Default value is AF_UNSPEC means both IPv4 and IPv6. */
-#ifdef IPV4_DEFAULT
-int IPv4or6 = AF_INET;
-#else
-int IPv4or6 = AF_UNSPEC;
-#endif
+/* AF_UNSPEC or AF_INET or AF_INET6 */
+extern int IPv4or6;
 
diff -rNu1 openssh-2.9.9p2.orig/ssh.c openssh-2.9.9p2/ssh.c
--- openssh-2.9.9p2.orig/ssh.c	Tue Sep 25 02:04:03 2001
+++ openssh-2.9.9p2/ssh.c	Sun Oct  7 23:09:16 2001
@@ -82,9 +82,4 @@
 
-/* Flag indicating whether IPv4 or IPv6.  This can be set on the command line.
-   Default value is AF_UNSPEC means both IPv4 and IPv6. */
-#ifdef IPV4_DEFAULT
-int IPv4or6 = AF_INET;
-#else
-int IPv4or6 = AF_UNSPEC;
-#endif
+/* AF_UNSPEC or AF_INET or AF_INET6 */
+extern int IPv4or6;
 
diff -rNu1 openssh-2.9.9p2.orig/sshd.c openssh-2.9.9p2/sshd.c
--- openssh-2.9.9p2.orig/sshd.c	Tue Sep 18 08:03:04 2001
+++ openssh-2.9.9p2/sshd.c	Sun Oct  7 23:10:04 2001
@@ -97,11 +97,4 @@
 
-/*
- * Flag indicating whether IPv4 or IPv6.  This can be set on the command line.
- * Default value is AF_UNSPEC means both IPv4 and IPv6.
- */
-#ifdef IPV4_DEFAULT
-int IPv4or6 = AF_INET;
-#else
-int IPv4or6 = AF_UNSPEC;
-#endif
+/* AF_UNSPEC or AF_INET or AF_INET6 */
+extern int IPv4or6;
 
-------------- next part --------------
Do not hardcode libssh and libopenbsd-compat into link lines and dependances,
but use make variables instead.  Can be used to build with shared -lssh.

--- openssh-2.9.9p2.orig/Makefile.in.orig	Sun Oct  7 23:45:01 2001
+++ openssh-2.9.9p2/Makefile.in	Sun Oct  7 23:48:31 2001
@@ -95,32 +96,35 @@
 
-ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
-	$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+SSH_LIBS = $(LIBCOMPAT) libssh.a
+SSH_LDFLAGS = -lssh -lopenbsd-compat
 
-sshd$(EXEEXT): libssh.a	$(LIBCOMPAT) $(SSHDOBJS)
-	$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ssh$(EXEEXT): $(SSH_LIBS) $(SSHOBJS)
+	$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
-scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o
-	$(LD) -o $@ scp.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+sshd$(EXEEXT): $(SSH_LIBS) $(SSHDOBJS)
+	$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
-ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o
-	$(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+scp$(EXEEXT): $(SSH_LIBS) scp.o
+	$(LD) -o $@ scp.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
-ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o
-	$(LD) -o $@ ssh-agent.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+ssh-add$(EXEEXT): $(SSH_LIBS) ssh-add.o
+	$(LD) -o $@ ssh-add.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o
-	$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+ssh-agent$(EXEEXT): $(SSH_LIBS) ssh-agent.o
+	$(LD) -o $@ ssh-agent.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o
-	$(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS) 
+ssh-keygen$(EXEEXT): $(SSH_LIBS) ssh-keygen.o
+	$(LD) -o $@ ssh-keygen.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o
-	$(LD) -o $@ sftp-server.o sftp-common.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+ssh-keyscan$(EXEEXT): $(SSH_LIBS) ssh-keyscan.o
+	$(LD) -o $@ ssh-keyscan.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp-common.o sftp-glob.o
-	$(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+sftp-server$(EXEEXT): $(SSH_LIBS) sftp.o sftp-common.o sftp-server.o
+	$(LD) -o $@ sftp-server.o sftp-common.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
+
+sftp$(EXEEXT): $(SSH_LIBS) sftp.o sftp-client.o sftp-int.o sftp-common.o sftp-glob.o
+	$(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
 # test driver for the loginrec code - not built by default
-logintest: logintest.o $(LIBCOMPAT) libssh.a loginrec.o
-	$(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS)
+logintest: logintest.o $(SSH_LIBS) loginrec.o
+	$(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o $(SSH_LDFLAGS) $(LIBS)
 
-------------- next part --------------
diff -rNu1 openssh-2.9.9p2.orig/Makefile.in openssh-2.9.9p2/Makefile.in
--- openssh-2.9.9p2.orig/Makefile.in	Tue Sep 18 09:06:22 2001
+++ openssh-2.9.9p2/Makefile.in	Mon Oct  8 02:12:04 2001
@@ -32,2 +32,4 @@
 LIBS=@LIBS@
+AUTH_LIBS=@AUTH_LIBS@
+LIBWRAP=@LIBWRAP@
 AR=@AR@
@@ -95,32 +97,35 @@
 
-ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
-	$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+SSH_LIBS = $(LIBCOMPAT) libssh.a
+SSH_LDFLAGS = -lssh -lopenbsd-compat
 
-sshd$(EXEEXT): libssh.a	$(LIBCOMPAT) $(SSHDOBJS)
-	$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ssh$(EXEEXT): $(SSH_LIBS) $(SSHOBJS)
+	$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
-scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o
-	$(LD) -o $@ scp.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+sshd$(EXEEXT): $(SSH_LIBS) $(SSHDOBJS)
+	$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) $(SSH_LDFLAGS) $(AUTH_LIBS) $(LIBWRAP) $(LIBS)
 
-ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o
-	$(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+scp$(EXEEXT): $(SSH_LIBS) scp.o
+	$(LD) -o $@ scp.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
-ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o
-	$(LD) -o $@ ssh-agent.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+ssh-add$(EXEEXT): $(SSH_LIBS) ssh-add.o
+	$(LD) -o $@ ssh-add.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o
-	$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+ssh-agent$(EXEEXT): $(SSH_LIBS) ssh-agent.o
+	$(LD) -o $@ ssh-agent.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o
-	$(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS) 
+ssh-keygen$(EXEEXT): $(SSH_LIBS) ssh-keygen.o
+	$(LD) -o $@ ssh-keygen.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o
-	$(LD) -o $@ sftp-server.o sftp-common.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) 
+ssh-keyscan$(EXEEXT): $(SSH_LIBS) ssh-keyscan.o
+	$(LD) -o $@ ssh-keyscan.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
 
-sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp-common.o sftp-glob.o
-	$(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+sftp-server$(EXEEXT): $(SSH_LIBS) sftp.o sftp-common.o sftp-server.o
+	$(LD) -o $@ sftp-server.o sftp-common.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS) 
+
+sftp$(EXEEXT): $(SSH_LIBS) sftp.o sftp-client.o sftp-int.o sftp-common.o sftp-glob.o
+	$(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) $(SSH_LDFLAGS) $(LIBS)
 
 # test driver for the loginrec code - not built by default
-logintest: logintest.o $(LIBCOMPAT) libssh.a loginrec.o
-	$(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS)
+logintest: logintest.o $(SSH_LIBS) loginrec.o
+	$(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o $(SSH_LDFLAGS) $(AUTH_LIBS) $(LIBS)
 
diff -rNu1 openssh-2.9.9p2.orig/configure.in openssh-2.9.9p2/configure.in
--- openssh-2.9.9p2.orig/configure.in	Wed Sep 26 02:39:38 2001
+++ openssh-2.9.9p2/configure.in	Mon Oct  8 02:15:29 2001
@@ -337,2 +337,3 @@
 # Checks for libraries.
+AUTH_LIBS=
 if test -z "$no_libnsl" ; then
@@ -344,8 +345,5 @@
 
-dnl SCO OS3 needs this for libwrap
-AC_CHECK_LIB(rpc, innetgr, LIBS="-lrpc -lyp -lrpc $LIBS" , , -lyp -lrpc)
-
-AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen")
 AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first or check config.log ***]))
-AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil")
+AC_CHECK_LIB(gen, getspnam, AUTH_LIBS="$AUTH_LIBS -lgen")
+AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) AUTH_LIBS="$AUTH_LIBS -lutil")
 
@@ -455,3 +453,4 @@
 # Check whether user wants TCP wrappers support
-TCPW_MSG="no" 
+TCPW_MSG="no"
+LIBWRAP=
 AC_ARG_WITH(tcp-wrappers,
@@ -460,4 +459,7 @@
 		if test "x$withval" != "xno" ; then
+			LIBWRAP="-lwrap"
+			dnl SCO OS3 needs this for libwrap
+			AC_CHECK_LIB(rpc, innetgr, LIBWRAP="$LIBWRAP -lrpc -lyp -lrpc" , , -lyp -lrpc)
 			saved_LIBS="$LIBS"
-			LIBS="-lwrap $LIBS"
+			LIBS="$LIBWRAP $LIBS"
 			AC_MSG_CHECKING(for libwrap)
@@ -472,2 +474,3 @@
 					AC_DEFINE(LIBWRAP)
+					LIBS="$saved_LIBS"
 					TCPW_MSG="yes" 
@@ -481,2 +484,3 @@
 )
+AC_SUBST(LIBWRAP)
 
@@ -503,3 +507,3 @@
 	[AC_DEFINE(HAVE_LOGIN)],
-	[AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])]
+	[AC_CHECK_LIB(bsd, login, [AUTH_LIBS="$AUTH_LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])]
 )
@@ -545,4 +549,4 @@
 
-			AC_CHECK_LIB(dl, dlopen, , )
-			AC_CHECK_LIB(pam, pam_set_item, , AC_MSG_ERROR([*** libpam missing]))
+			AC_CHECK_LIB(dl, dlopen, AUTH_LIBS="-ldl $AUTH_LIBS", )
+			AC_CHECK_LIB(pam, pam_set_item, AUTH_LIBS="-lpam $AUTH_LIBS", AC_MSG_ERROR([*** libpam missing]), $AUTH_LIBS)
 			AC_CHECK_FUNCS(pam_getenvlist)
@@ -743,3 +747,3 @@
 if test "x$PAM_MSG" = "xno" -a "x$check_for_libcrypt_later" = "x1"; then
-	AC_CHECK_LIB(crypt, crypt, LIBS="$LIBS -lcrypt")
+	AC_CHECK_LIB(crypt, crypt, AUTH_LIBS="$AUTH_LIBS -lcrypt")
 fi
@@ -2047,2 +2051,4 @@
 AC_EXEEXT
+
+AC_SUBST(AUTH_LIBS)
 

From mouring at etoh.eviladmin.org  Mon Oct  8 11:51:35 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sun, 7 Oct 2001 20:51:35 -0500 (CDT)
Subject: Using -lssh as shared library
In-Reply-To: <3BC0E394.6F0361A6@tls.msk.ru>
Message-ID: <Pine.BSO.4.33.0110072033470.23894-100000@etoh.eviladmin.org>



On Mon, 8 Oct 2001, Michael Tokarev wrote:

[..]
> I hacked source a bit, but not like this hack very well.
> What I did is created one extra file, ipv4or6.c, that
> contains definition of this variable, added it into
> list of objects for libssl, and changed actual declarations
> in ssh.c, sshd.c, ssh-keyscan.c and the like to be simple
> "extern int IPV4or6".  This allowed me to successefully
> use shared libssl.so.  I attached a patch named
> openssh-2.9.9p2-ipv4or6.diff, that does exactly this.
>

Hmm... This is wrong.   IPV4or6 variable should be in a header file, not a
C file.


> Next, some tweaking for Makefile was required.  libssh.a
> and libopenbsd-compat.a was "hardcoded" into link and dep
> lines in Makefile, so if there is no libopenbsd-compat
> (but it's contents is within -lssh), link will be funny.
> Second patch, openssh-2.9.9p2-ssh_libs.diff, introduces
> two make variables, SSH_LIBS="libopenbsd-compat.a libssl.a",
> for dependence lines, and SSH_LDFLAGS="-lssl -lopenbsd-compat",
> for link lines, and replaces hardcoded libssl.a etc with
> those 2 variables.
>
> Note that before the change, ssh-keyscan linked with -lssh
> twice:
>  $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
> Looking into -lssh and -lopenbsd-compat, I don't think it is
> necessary: there is no "back-references" from -lopenbsd-compat
> to -lssh.  The patch mentioned above fixes this too.

Incorrect.  bsd-arc4random.c refers to seed_rng()  which is part of
entropy.c.  Dynamic linking may remove this issue, but in our current
compile setup this hack is required.

> And one more issue/question at the end.  I noticied that *all*
> openssh programs linked with -lpam, -lwrap, -lutil and so on --
> libraries really needed for sshd *only*.  I can't say this is
> "bug", but looks somewhat inaccurate.  Looking into configure.in,
> it is relatively hard to "clean up" things.  3rd patch attached,
> openssh-2.9.9p2-libs.diff, an *alternative* to ssh_libs patch
> (both touches the same lines in Makefile.in), is an attempt to
> fix this too.  It is only first step into this direction, some
> more cleanups should be done (for example, there is no -lz needed
> for ssh-keygen, kerberos and s/key libs should be checked too and
> so on).
>

It would be nice to support this, but how much more work will it be to
maintain?  Right now it is pretty easy to maintain.  I think we need to
clean up configure.in before implementing this.

Too bad most linkers are brain damaged and don't strip unused dynamically
linked libraries.

- Ben



From dean.domikulic at pbz.hr  Mon Oct  8 20:18:46 2001
From: dean.domikulic at pbz.hr (=?windows-1250?Q?Dean_Luka_Domikuli=E6?=)
Date: Mon, 8 Oct 2001 12:18:46 +0200 
Subject: Executing ssh commands on many computers
Message-ID: <EC719BFDBB12D4119D8F00062939D3E303C6713D@ntd-ksaver2.ksaver.pbz.hr>

We have two SP computers with 8 nodes each and
ocasionaly we have to execute comands on all of them.
We do that with ssh private and public keys without
passphrase. I a loop we do

ssh node* comand

The problem is:
After a few nodes ssh client waits for a long time
and after that every new connection is slower.

It looks to me like ssh client has used all the entropy
for generating session keys and than has to wait for the new
keys to be generated.

I'm just guessing.

OS is AIX 4.3.2 and openssh is 2.3 p1.

Does any body know what could be the problem
and how it can be solved?

We tried executing comands from AIX and linux,
and we get the same problem only on linux
I can execute the command on more nodes before it
starts to be slow.
I tested with loop:

while true
do
ssh node date
done


Any help apreciated.


From mjt at tls.msk.ru  Mon Oct  8 21:33:22 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Mon, 08 Oct 2001 15:33:22 +0400
Subject: Using -lssh as shared library
References: <Pine.BSO.4.33.0110072033470.23894-100000@etoh.eviladmin.org>
Message-ID: <3BC18F02.963BCB02@tls.msk.ru>

mouring at etoh.eviladmin.org wrote:
> 
> On Mon, 8 Oct 2001, Michael Tokarev wrote:
> 
> [..]
> > I hacked source a bit, but not like this hack very well.
> > What I did is created one extra file, ipv4or6.c, that
> > contains definition of this variable, added it into
> > list of objects for libssl, and changed actual declarations
> > in ssh.c, sshd.c, ssh-keyscan.c and the like to be simple
> > "extern int IPV4or6".  This allowed me to successefully
> > use shared libssl.so.  I attached a patch named
> > openssh-2.9.9p2-ipv4or6.diff, that does exactly this.
> >
> 
> Hmm... This is wrong.   IPV4or6 variable should be in a header file, not a
> C file.

I agree, but I don't think it belongs to it's own .h file.  Just
like putting the variable itself into own .c file.  I'm not so
familiar with the whole ssh sources to decide where them should
go.  Variable used in e.g. channels.c, but putting it into this
file will result in linking the whole content of this file into
e.g. ssh-keyscan that doesn't uses other routines from this file.
*Really* clean solution IMHO is to use additional argument in
some routines (in channels.c:channel_request_forwarding(),
channels.c:connect_to(), channels.c:channel_connect_by_listen_address()
and so on.  Note that e.g. last one is pretty obvious: instead of
 int channel_connect_by_listen_address(listen_port)
it becomes
 int channel_connect_by_listen_address(listen_port, int family)
).  But having in mind current unclean separation of library
itself (with many global variables and so on) I don't see this
is a good way alone.

In fact, what I did (I already called that "hack", not a real
solution) is not worse at least that was before -- I just followed
some existed "rules" here, as many source files already declared
"extern int IPv4or6" inside)... ;)

[]
> > Note that before the change, ssh-keyscan linked with -lssh
> > twice:
> >  $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
> > Looking into -lssh and -lopenbsd-compat, I don't think it is
> > necessary: there is no "back-references" from -lopenbsd-compat
> > to -lssh.  The patch mentioned above fixes this too.
> 
> Incorrect.  bsd-arc4random.c refers to seed_rng()  which is part of
> entropy.c.  Dynamic linking may remove this issue, but in our current
> compile setup this hack is required.

Hmm... interesting.  I not noticied this when inspecting source nor
when linking with gcc/gld (I verified this line on non-shared lib
too).  Interesting again -- how arc4random implemented in openbsd,
it obviously should not refer to ssh library's seed_rng() (but see
below).

There is a trivial solution for this "library/linker problem"
introduced by my little changes: instead of having SSH_LIBS/SSH_LDFLAGS
as I did, use two separate variables (e.g. LIBSSH/LIBCOMPAT), but
again as *variables* (to stop "hard-coding" them into Makefile).
BTW, all compilers/linkers support "libstuff.a" in place of -lstuff
(so that e.g. LIBCOMPAT can be used in both dependance and link
lines).  The same, at least partially, true for libstuff.so too.

Looking to bsd-arc4random.c, it seems not obvious to call seed_rng()
from here at all -- seed_rng() will be called at least twice in
some apps (that calls it directly and via arc4random()) -- not
good, esp with implementation without /dev/[u]random.  Note also
that apps used arc4random() *only* (I don't know if such an
application exists in openssh -- it seems that ssh-keyscan is
an example here) will be linked with all the routines from
entropy.c file.  Having that said, I think that a) seed_rng()
should be separated from entropy.c, b) arc4random()
should be moved from openbsd-compat into libssh (may be into
the same source file as seed_rng itself) and c) "first_time"
from arc4random() should be made global and available from
seed_rng() as well (this last point isn't obvious, as it
will stop calling seed_rgn() more than once if *required*).

> > And one more issue/question at the end.  I noticied that *all*
> > openssh programs linked with -lpam, -lwrap, -lutil and so on --
> > libraries really needed for sshd *only*.  I can't say this is
> > "bug", but looks somewhat inaccurate.  Looking into configure.in,
> > it is relatively hard to "clean up" things.  3rd patch attached,
> > openssh-2.9.9p2-libs.diff, an *alternative* to ssh_libs patch
> > (both touches the same lines in Makefile.in), is an attempt to
> > fix this too.  It is only first step into this direction, some
> > more cleanups should be done (for example, there is no -lz needed
> > for ssh-keygen, kerberos and s/key libs should be checked too and
> > so on).
> >
> 
> It would be nice to support this, but how much more work will it be to
> maintain?  Right now it is pretty easy to maintain.  I think we need to
> clean up configure.in before implementing this.

Cleaning up configure.in is defenitely a good idea.  Supporting this
isn't a big issue in clean configure.in, but somewhat hard without
this cleanup.  At least some things was done by this patch -- a small
example, I don't look to "libraries may be needed on SCO for libwrap"
unless tcp-wrappers was really requested.

> Too bad most linkers are brain damaged and don't strip unused dynamically
> linked libraries.

This isn't a "brain-damage" but a feature.  Well, ok, questionable
one but *still* a feature.  Imagine your app uses dlopen() etc to
load some .so at run time (like e.g. pam applications and the like).
That .so may require symbols not present in app itself and in any
library that app linked with.  One may link .so with a library with
those symbols, *or* can link app with that library.  Moreower, .so
may be linked with one such lib, *and* app with another (like
samba's smbshell) -- thus .so will use symbols from app's library
instead of it's own library.  Kind of "LD_PRELOAD" for an .so.
Or, .so is linked with libtermcap, but app "wants" it to be libcurses
but not uses curses itself -- just add -lcurses to app's link line
and "be happy", .so will use curses's tcgetstr() instead of termcap's
one.  There are *very rare cases* when this may be useful (and most
of the time, this can be done programmatically), but them still
exists.

What I really call a MIS-feature of most linkers is that linkers
"propagates" libs "linked with" other dynamic libs to applications.
For example, when -lssh (dynamic) linked with -lz, and one links
an app with -lssh but without -lz, app will list -lz in it's
runtime dependances, while *not uses* -lz directly.  Next, when
I upgrade -lssh (example only!), keeping interface intact, *and* -lz
at the same time, breaking interface, app will stop working, as it
will depend on *old* -lz but new -lssh will use *new* -lz.  I once
worked around this problem, by building "dummy" -lssh (again, example
only!) with all it's own symbols inside but without any code,
then linking app with this dummy -lssh and only after that building
and linking real -lssh with real -lz.  Only this way I managed to
remove -lz from app's dependances and was free to munge both -lssh
and -lz (keeping -lssh's interface intact!) as I wanted to...
(I once realized more "clean" solution for this: building -lssh
with *static* -lz, instead of editing -lssh to be dummy, is a
better way to go; but rebuilding -lssh *after* all apps already
linked with it still required).

Regards,
 Michael.


From ed at UDel.Edu  Mon Oct  8 23:55:27 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 8 Oct 2001 09:55:27 -0400 (EDT)
Subject: FAQ 3.10
Message-ID: <Pine.SOL.4.30.0110080951060.12932-100000@mahler.udel.edu>

I'm having trouble getting any sort of work-around for 3.10 on Solaris 8
with Sun's tcsh.  I've tried using "hup" to correct it but to no avail.
This problem wasn't present with ssh version 1 - it just seem to work.
Now we get all kinds of abandoned ssh processes lying around that have to
be manually killed.  Does anyone know if there is going to be a fix for
this problem or how to make it work correctly?

Here's an example of what I see when I run a remote xterm, and then close
it immediately:

polycut:~> ssh -n mahler xterm

<I immediately hit CTRL-d on the xterm and the the following error in the
original shell>

channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel

<I hit CTRL-c to get control of the original shell>

^CKilled by signal 2.
polycut:~>

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 mouring at etoh.eviladmin.org  Tue Oct  9 00:31:39 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 8 Oct 2001 09:31:39 -0500 (CDT)
Subject: Executing ssh commands on many computers
In-Reply-To: <EC719BFDBB12D4119D8F00062939D3E303C6713D@ntd-ksaver2.ksaver.pbz.hr>
Message-ID: <Pine.BSO.4.33.0110080931150.15573-100000@etoh.eviladmin.org>


Use PRNGd and a newer version of OpenSSH.  PRNGd is a long standing
entropy generation system which should help out in your problem.

- Ben

On Mon, 8 Oct 2001, [windows-1250] Dean Luka Domikuli? wrote:

> We have two SP computers with 8 nodes each and
> ocasionaly we have to execute comands on all of them.
> We do that with ssh private and public keys without
> passphrase. I a loop we do
>
> ssh node* comand
>
> The problem is:
> After a few nodes ssh client waits for a long time
> and after that every new connection is slower.
>
> It looks to me like ssh client has used all the entropy
> for generating session keys and than has to wait for the new
> keys to be generated.
>
> I'm just guessing.
>
> OS is AIX 4.3.2 and openssh is 2.3 p1.
>
> Does any body know what could be the problem
> and how it can be solved?
>
> We tried executing comands from AIX and linux,
> and we get the same problem only on linux
> I can execute the command on more nodes before it
> starts to be slow.
> I tested with loop:
>
> while true
> do
> ssh node date
> done
>
>
> Any help apreciated.
>



From mouring at etoh.eviladmin.org  Tue Oct  9 01:27:21 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 8 Oct 2001 10:27:21 -0500 (CDT)
Subject: Using -lssh as shared library
In-Reply-To: <3BC18F02.963BCB02@tls.msk.ru>
Message-ID: <Pine.BSO.4.33.0110080955220.15573-100000@etoh.eviladmin.org>



On Mon, 8 Oct 2001, Michael Tokarev wrote:

> mouring at etoh.eviladmin.org wrote:
> >
> > On Mon, 8 Oct 2001, Michael Tokarev wrote:
> >
> > [..]
> > > I hacked source a bit, but not like this hack very well.
> > > What I did is created one extra file, ipv4or6.c, that
> > > contains definition of this variable, added it into
> > > list of objects for libssl, and changed actual declarations
> > > in ssh.c, sshd.c, ssh-keyscan.c and the like to be simple
> > > "extern int IPV4or6".  This allowed me to successefully
> > > use shared libssl.so.  I attached a patch named
> > > openssh-2.9.9p2-ipv4or6.diff, that does exactly this.
> > >
> >
> > Hmm... This is wrong.   IPV4or6 variable should be in a header file, not a
> > C file.
>
> I agree, but I don't think it belongs to it's own .h file.  Just
> like putting the variable itself into own .c file.  I'm not so
[..]

Considered ssh.h ?

[..]
> > > Note that before the change, ssh-keyscan linked with -lssh
> > > twice:
> > >  $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
> > > Looking into -lssh and -lopenbsd-compat, I don't think it is
> > > necessary: there is no "back-references" from -lopenbsd-compat
> > > to -lssh.  The patch mentioned above fixes this too.
> >
> > Incorrect.  bsd-arc4random.c refers to seed_rng()  which is part of
> > entropy.c.  Dynamic linking may remove this issue, but in our current
> > compile setup this hack is required.
>
> Hmm... interesting.  I not noticied this when inspecting source nor
> when linking with gcc/gld (I verified this line on non-shared lib
> too).  Interesting again -- how arc4random implemented in openbsd,
> it obviously should not refer to ssh library's seed_rng() (but see
> below).
>
> There is a trivial solution for this "library/linker problem"
> introduced by my little changes: instead of having SSH_LIBS/SSH_LDFLAGS
> as I did, use two separate variables (e.g. LIBSSH/LIBCOMPAT), but
> again as *variables* (to stop "hard-coding" them into Makefile).
> BTW, all compilers/linkers support "libstuff.a" in place of -lstuff
> (so that e.g. LIBCOMPAT can be used in both dependance and link
> lines).  The same, at least partially, true for libstuff.so too.
>
> Looking to bsd-arc4random.c, it seems not obvious to call seed_rng()
> from here at all -- seed_rng() will be called at least twice in
> some apps (that calls it directly and via arc4random()) -- not
> good, esp with implementation without /dev/[u]random.  Note also
> that apps used arc4random() *only* (I don't know if such an
> application exists in openssh -- it seems that ssh-keyscan is
> an example here) will be linked with all the routines from

arc4random() is never used by itself.  It is always used with conjuction
with either /dev/{u}random, PRNGd, EGD, or built-in entropy.  Because
arc4random() is not useful other then 'stiring' the entropy pot.  Which is
all it is used for.

> entropy.c file.  Having that said, I think that a) seed_rng()
> should be separated from entropy.c, b) arc4random()

Won't happen.. It makes no sense.. There are multiple versions of
seed_rng() depending on what type of compiled in entropy support is being
used currently.  Plus the code itself makes no sense by itself.

> should be moved from openbsd-compat into libssh (may be into
> the same source file as seed_rng itself) and c) "first_time"

Won't happen.  arc4random() belongs in the compatiblity library.  If the
native OS has arc4 implementation than we should be using their
implementation not ours.

> from arc4random() should be made global and available from
> seed_rng() as well (this last point isn't obvious, as it
> will stop calling seed_rgn() more than once if *required*).
>

Damien, can we just remove seed_rng() from arc4random?  We are doing
seed_rng() in every major binary that requires entropy collection (except
for ssh-keyscan.c which we need to add it to now).  I know we needed this
when we first started, but I think (from glancing at the code) it is now
dead wood.  I would prefer that than sprinkling portable code around more.

> > > And one more issue/question at the end.  I noticied that *all*
> > > openssh programs linked with -lpam, -lwrap, -lutil and so on --
> > > libraries really needed for sshd *only*.  I can't say this is
> > > "bug", but looks somewhat inaccurate.  Looking into configure.in,
> > > it is relatively hard to "clean up" things.  3rd patch attached,
> > > openssh-2.9.9p2-libs.diff, an *alternative* to ssh_libs patch
> > > (both touches the same lines in Makefile.in), is an attempt to
> > > fix this too.  It is only first step into this direction, some
> > > more cleanups should be done (for example, there is no -lz needed
> > > for ssh-keygen, kerberos and s/key libs should be checked too and
> > > so on).
> > >
> >
> > It would be nice to support this, but how much more work will it be to
> > maintain?  Right now it is pretty easy to maintain.  I think we need to
> > clean up configure.in before implementing this.
>
> Cleaning up configure.in is defenitely a good idea.  Supporting this
> isn't a big issue in clean configure.in, but somewhat hard without
> this cleanup.  At least some things was done by this patch -- a small
> example, I don't look to "libraries may be needed on SCO for libwrap"
> unless tcp-wrappers was really requested.
>

Seperate the patches into smaller ones.  Present a patch that JUST fixes
tcp wrapper and it's dependances.  We will test and if it works commit.

Same goes true for everything else.  OpenSSH is at the point in it's life
that we really should not be doing anything but small well defined
patches.

There are just too many platforms that do too many odd-ball things to just
jump into things head first.

> > Too bad most linkers are brain damaged and don't strip unused dynamically
> > linked libraries.
>
> This isn't a "brain-damage" but a feature.  Well, ok, questionable
> one but *still* a feature.  Imagine your app uses dlopen() etc to
> load some .so at run time (like e.g. pam applications and the like).
> That .so may require symbols not present in app itself and in any
> library that app linked with.  One may link .so with a library with
[..]

Blech, the point of dlopen() and friends is to create the assocation to
the .so at runtime.. Not at linking time.  But that is off topic.

- Ben



From Nicolas.Williams at ubsw.com  Tue Oct  9 01:44:17 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 8 Oct 2001 11:44:17 -0400
Subject: Using -lssh as shared library
In-Reply-To: <3BC0E394.6F0361A6@tls.msk.ru>; from mjt@tls.msk.ru on Mon, Oct 08, 2001 at 03:21:56AM +0400
References: <3BC0E394.6F0361A6@tls.msk.ru>
Message-ID: <20011008114415.S5739@sm2p1386swk.wdr.com>

On Mon, Oct 08, 2001 at 03:21:56AM +0400, Michael Tokarev wrote:
> Hello!  This is my first post to this list... ;)

[...]

> Adding real shared lib suport into makefile(s) will require to
> create separate directory for libssh, or to use some other
> extension instead of .o for all it's components, due to difference
> in compiler flags (-fPIC for gcc is needed to compile position-
> independant code), and those flags together with command to make
> shared lib are very platform-dependant.

Others deal with this problem by using extensions other than .o for PIC
objects, such as .po or .lo. Look at libtool for example.

So you can setup .c.po rules and have libssh.$(SH_EXT) depend on the .po
objects and libssh.a depend on the .o objects, and so on and on.

This is the best way to go, IMHO.

That said, I wonder about the wisdom of this as libssh is a library
internal to OpenSSH, and is not meant to be used by others. But if you
install a shared library it may well lead some to think it's an API.

Also, most of those other programs included with OpenSSH are rarely run,
so that there's little performance or memory footprint savings to gain
from making libssh.a a shared object instead.

> Thank you for great product!
> 
> 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 doctor at doctor.nl2k.ab.ca  Tue Oct  9 01:59:56 2001
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 8 Oct 2001 09:59:56 -0600
Subject: Problem in BSD/OS 4.2
Message-ID: <20011008095956.A22737@doctor.nl2k.ab.ca>

I keep getting:

Script started on Mon Oct  8 09:55:27 2001
doctor.nl2k.ab.ca//usr/source/openssh-2.9.9p2$ gmake
gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib  -lssh -lopenbsd-compat -lz  -lutil -lcrypto 
auth.o: In function `allowed_user':
/usr/source/openssh-2.9.9p2/auth.c:80: undefined reference to `getspnam'
gmake: *** [sshd] Error 1
doctor.nl2k.ab.ca//usr/source/openssh-2.9.9p2$ exit
exit

Script done on Mon Oct  8 09:55:44 2001
-- 
Member - Liberal International	On 11 Sept 2001 the WORLD was violated.
This is doctor at nl2k.ab.ca	Ici doctor at nl2k.ab.ca
Society MUST be saved! Extremists must dissolve.  


From markus at openbsd.org  Tue Oct  9 03:36:26 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 8 Oct 2001 19:36:26 +0200
Subject: FAQ 3.10
In-Reply-To: <Pine.SOL.4.30.0110080951060.12932-100000@mahler.udel.edu>; from ed@UDel.Edu on Mon, Oct 08, 2001 at 09:55:27AM -0400
References: <Pine.SOL.4.30.0110080951060.12932-100000@mahler.udel.edu>
Message-ID: <20011008193626.A23156@folly>

and this happens with version 2.3.4.5.6.7 ?

On Mon, Oct 08, 2001 at 09:55:27AM -0400, Ed Phillips wrote:
> I'm having trouble getting any sort of work-around for 3.10 on Solaris 8
> with Sun's tcsh.  I've tried using "hup" to correct it but to no avail.
> This problem wasn't present with ssh version 1 - it just seem to work.
> Now we get all kinds of abandoned ssh processes lying around that have to
> be manually killed.  Does anyone know if there is going to be a fix for
> this problem or how to make it work correctly?
> 
> Here's an example of what I see when I run a remote xterm, and then close
> it immediately:
> 
> polycut:~> ssh -n mahler xterm
> 
> <I immediately hit CTRL-d on the xterm and the the following error in the
> original shell>
> 
> channel_lookup: 0: bad id: channel free
> client_input_channel_req: channel 0: unknown channel
> 
> <I hit CTRL-c to get control of the original shell>
> 
> ^CKilled by signal 2.
> polycut:~>
> 
> 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 michael at bizsystems.com  Tue Oct  9 04:44:25 2001
From: michael at bizsystems.com (Michael)
Date: Mon, 8 Oct 2001 10:44:25 -0800
Subject: socks and misc patch to 2.9.9p2
In-Reply-To: <Pine.BSO.4.33.0110070151460.2237-100000@etoh.eviladmin.org>
References: <200110070209.f9729kA31368@bzs.org>
Message-ID: <200110081744.f98HiWA11288@bzs.org>

> 
> 
> On Sat, 6 Oct 2001, Michael wrote:
> 
> > >
> > > Out of interest what is wrong with 'ProxyCommand' for handling this?
> > >  This is kinda why this was design for to support socks and other
> > > proxy type software without the nasty #ifdef/#endif code.
> >
> > There are only 3 or 4 instances of this and no added code lines if
> > you consider the effect of the ifdef's
> >
> > doesn't work for scp, and even if it did, I've got a ton of scripts
> > in existence on numerous machines that are using the old ssh-1.2.xx
> > reference release. It would be nice to upgrade transparently. I'm
> > sure that is why others have tried to add this feature in the past.
> > Michael
> >
> 
> If it does not work for scp than it should be fixed.  This patch
> pretty much is saying.. "I don't care to understand existing
> features therefor I will add a different way of doing the same
> thing."  

Not really, what the "patch" says it that I believe that the ssh code 
should be machine and platform independent for the user. I don't 
consider it particularly useful to have to write a different script 
that uses ssh or scp for every platform that must use a socks proxy 
and to have to modify and update that script  every time the sysadmin 
decides to change or eliminate the socks gateway. I currently deply 
scripts to a multitude of hosts that must utilize socks to have 
firewall acess. These hosts are at different sites and thus have 
differing proxy hosts. It is much cleaner to simply deploy a script 
with commands for ssh and scp that are free of direct references to 
unique hosts that differ among sites. I would much prefer to leave 
proxy selection up to the sysadmin of the site when the hosts are 
configured (or re-configured). I think the general idea is that the 
client application should not have to be configured, only the host 
and only once.

The solution I propose is a general solution, not site specific as it 
the present mode of using a socks proxy from the command line.


>If you wish to describe why it breaks, and suggest a
> solution patch than great.

> 
> Besides, anytime you add in #ifdef into code it makes it harder to
> read and mentally process.   And if you have done an #ifdef count
> between the virgin OpenBSD version and the portable we have 3x
> (slowly creaping up on 4x) as many which is too may.  The whole
> thinking.. "It is just 4 more
> #ifdef"  leads to crap code like SSH-1.2.x.
> 

> I doubt this will be added to the upstream code (in turn it won't
> get to the portable tree).  So I think fixing and useing the
> ProxyCommand or a local patch will be your only two options.
> 

I might suggest that usability by the applications developer be 
taken into consideration. As I've already said, having to customize 
every script use of ssh/scp for each site is asking a bit much. 
Generic internal support of socks by the ssh, scp, sftp clients is 
much more useful in my view. Don't get so hung up on the "ifdefs" 
that you forget the reason we write software to begin with.

Respectfully,

Michael Robinton
BizSystems
4600 El Camino Real - Suite 206
Los Altos, CA 94022
Tel: 650 947-3351
Fax: 650 947-3356
michael at bizsystems.com


From ed at UDel.Edu  Tue Oct  9 04:14:29 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 8 Oct 2001 14:14:29 -0400 (EDT)
Subject: FAQ 3.10
In-Reply-To: <20011008193626.A23156@folly>
Message-ID: <Pine.SOL.4.30.0110081412370.19069-100000@mahler.udel.edu>

On Mon, 8 Oct 2001, Markus Friedl wrote:

> Date: Mon, 8 Oct 2001 19:36:26 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: FAQ 3.10
>
> and this happens with version 2.3.4.5.6.7 ?

Sorry... openssh2.9p2 on the client, 2.9p1 on the server side.

	Ed

>
> On Mon, Oct 08, 2001 at 09:55:27AM -0400, Ed Phillips wrote:
> > I'm having trouble getting any sort of work-around for 3.10 on Solaris 8
> > with Sun's tcsh.  I've tried using "hup" to correct it but to no avail.
> > This problem wasn't present with ssh version 1 - it just seem to work.
> > Now we get all kinds of abandoned ssh processes lying around that have to
> > be manually killed.  Does anyone know if there is going to be a fix for
> > this problem or how to make it work correctly?
> >
> > Here's an example of what I see when I run a remote xterm, and then close
> > it immediately:
> >
> > polycut:~> ssh -n mahler xterm
> >
> > <I immediately hit CTRL-d on the xterm and the the following error in the
> > original shell>
> >
> > channel_lookup: 0: bad id: channel free
> > client_input_channel_req: channel 0: unknown channel
> >
> > <I hit CTRL-c to get control of the original shell>
> >
> > ^CKilled by signal 2.
> > polycut:~>
> >
> > 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
> >
> >
>

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 Oct  9 04:21:16 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 8 Oct 2001 20:21:16 +0200
Subject: FAQ 3.10
In-Reply-To: <Pine.SOL.4.30.0110081412370.19069-100000@mahler.udel.edu>; from ed@udel.edu on Mon, Oct 08, 2001 at 02:14:29PM -0400
References: <20011008193626.A23156@folly> <Pine.SOL.4.30.0110081412370.19069-100000@mahler.udel.edu>
Message-ID: <20011008202116.C1092@faui02.informatik.uni-erlangen.de>

could you try 2.9.9p2 ?

On Mon, Oct 08, 2001 at 02:14:29PM -0400, Ed Phillips wrote:
...


From bbense at networking.stanford.edu  Tue Oct  9 04:52:05 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Mon, 8 Oct 2001 11:52:05 -0700 (PDT)
Subject: Patch to improve afs support 
In-Reply-To: <20011005140245.Q5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.GSO.4.33.0110081148040.25416-100000@shred.stanford.edu>


- The following patch moves the chdir(pw->pw_dir) section to
after the afs login attempt section in session.c. This
allows paranoid people that don't want to give

	system:anyuser l

access to their home dir to login.

diff -r1.1.1.1 session.c
1346,1354d1345
<       /* Change current directory to the user\'s home directory. */
<       if (chdir(pw->pw_dir) < 0) {
<               fprintf(stderr, "Could not chdir to home directory %s:
%s\n",
<                       pw->pw_dir, strerror(errno));
< #ifdef HAVE_LOGIN_CAP
<               if (login_getcapbool(lc, "requirehome", 0))
<                       exit(1);
< #endif
<       }
1372a1364,1374
>
>       /* Change current directory to the user\'s home directory. */
>       if (chdir(pw->pw_dir) < 0) {
>               fprintf(stderr, "Could not chdir to home directory %s:
%s\n",
>                       pw->pw_dir, strerror(errno));
> #ifdef HAVE_LOGIN_CAP
>               if (login_getcapbool(lc, "requirehome", 0))
>                       exit(1);
> #endif
>       }
>




From joden at eworld.wox.org  Tue Oct  9 04:52:20 2001
From: joden at eworld.wox.org (James Oden)
Date: Mon, 8 Oct 2001 14:52:20 -0400 (EDT)
Subject: Hanging ssh session...
Message-ID: <200110081852.OAA11071@eworld.wox.org>

Hi All,

I am not sure if this is the same thing as the hang on exit bug, so sorry if
this is a duplication of previous stuff.

Essetntially I am experiencing ssh hangs with about .5% - 1% of my
connections.  I am running 2.9p2, on Solaris 7.  I actually have empirical
data on the hangings, as I wrote a script to create these connections 
in an endless loop, setting an alarm so I could recover from a hang. 
I will place this script at the end of my email.

I am using RSA authentication with no passwords, going over an etherenet 
network.

Here is a dump of running strace and pstack on the remote and local
ssh sessions:

Local:
        truss:
                poll(0xFFBEEFC0, 2, -1)         (sleeping...)
        pstack:
                10879:  ssh epapdev at mate ls /etc/hosts
                 ff217cfc poll     (ffbeefc0, 2, ffffffff)
                 ff1cf6b0 select   (ffbeefd0, ff238bc4, 14b480, ff238bc8, 14b484, a) + 298
                 0004cc44 client_wait_until_can_do_something (ffbef200, ffbef1fc, ffbef1e4, 0, 9, 10000)
+ 3c4
                 0004e8a4 client_loop (0, ffffffff, 0, 14afb8, ff235ad4, 85308) + 6d4
                 00040c94 ssh_session2 (14afb8, 2, ffbef684, 141684, 144da8, 144da8) + 11c
                 0003f41c main     (4, ffbef50c, ffbef520, 131c00, 0, 0) + 1cd4
                 0003cfbc _start   (0, 0, 0, 0, 0, 0) + dc
Remote:
        truss:
                poll(0xFFBEF558, 2, -1)         (sleeping...)
        pstack
                15390:  /opt/TKLCplat/sbin/sshd
                 ff217cfc poll     (ffbef558, 2, ffffffff)
                 ff1cf6b0 select   (ffbef568, ff238bc4, 153230, ff238bc8, 153234, c) + 298
                 00052128 wait_until_can_do_something (ffbef6dc, ffbef6d8, ffbef6d0, 0, 0, 0) + 500
                 0005387c server_loop2 (0, 0, 0, 0, 0, 0) + 19c
                 0005ab60 do_authenticated2 (153ea0, 0, 0, 0, ff235ad4, 54bd0) + 8
                 00054c40 do_authenticated (153ea0, 153ea0, 153ea0, 2000, ffff, 0) + b0
                 0004435c do_authentication2 (1187a0, 7, c30b, ffbefd64, ff235ad4, 41888) + d4
                 00041914 main     (1, ffbefdec, ffbefdf4, 138c00, 0, 0) + 267c
                 0003dedc _start   (0, 0, 0, 0, 0, 0) + dc

truss only yields one call because I am calling it on the process after
the fact.  The one thing I can see with my limited experience is that
both the remote and local processes are in the poll call with no timeout.
Since they are both polling forever, they are in a deadlock I suppose.

I have been somewhat following the hang on exit thread and gathered that 
this might have something to do with tty's so I tried using the -T switch.
This over a six hour period yields the same ratio of hangs to successes 
as not using the switch.

Is there any work around available for this?  Also, do you need any more 
information from me.  If needed I could change my program to run truss 
on every attepted session and save the results of the hung sessions.

Cheers...james

P.S. you must change the $host and $login variables to an RSA authenticated
machine of your choosing in the script below.

<<<Test Program follows>>>
#
my $count   = 0;
my $test    = "~~~ ring ~~~ ring ~~~~\n";
my $sshhung = 0;
my $success = 0;
my $evalerr = 0;
my $pid;
my $childpid;
my $rc;
my $login = "";		# Place your login here
my $host  = "";		# place your host here.

while(1)
{
        $count++;
        print <<EOF;
Test #${count}
=========================
      Hangs:  ${sshhung}
Eval Errors:  ${evalerr}
    Success:  ${success}
EOF

        eval {
                local $SIG{ALRM} = sub { die $test };
                $pid = fork();
                die "Could not fork!" if($pid eq '');
                if($pid == 0)   # I am the child
                {
                        exec('ssh', "${login}@${host}", 'ls', '/etc/hosts');
                        die "EXEC FAILED!!!";
                }       # End of child

                #
                # Ok, back in the parental role...
                $childpid = '';
                alarm(10);
                $childpid = wait();
                $rc = $? >> 8;
                alarm(0);
        };


        #if we timed out then keys have not been exchanged.
        # If any other error occurs we should die.
        if($@)
        {
                # Any sort of error in hear means that the child
                # May still be alive...time to die...
                kill(9, $pid);

                #
                # Was this a syntax error?
                if ($@ ne $test) { $evalerr++; }
                else             { $sshhung++; }
        }
        else { $success++; }
}




From phess at best.com  Tue Oct  9 05:10:34 2001
From: phess at best.com (Patrick Hess)
Date: Mon, 8 Oct 2001 12:10:34 -0700 (PDT)
Subject: Porting OpenSSH 2.9.9p2 to Dynix V4.4.4
Message-ID: <200110081910.MAA22549@shell5.ba.best.com>

Hello Porters,

	I am attempting to compile OpenSSH 2.9.9p2 on a Dynix V4.4.4 host.
I have set USE_PIPES and BROKEN_SAVED_UIDS (the latter because there are
no functions for set{eu,eg}id() that I can find).  I configured with
"./configure  '--with-libs=-lnsl -lsec'".


	Each time I attempt to login, I get this error:

          No utmp entry.  You must exec "login" from the lowest level "sh".


	The Dynix man page for login (1) states:

          No utmp entry. You must exec "login" from the lowest level "sh"
               You attempted to execute login as a command without
               using the shell's exec internal command or from other
               than the initial shell.


	A "truss -aef" tells me that login is being execl'd like:

          27066:  execve("/bin/login", 0x080470FC, 0x0815F6CC) argc = 7
          27066:   argv: login -h <IP> -p -f -- phess
          27066:   envp: TZ=BST11 SSH_CLIENT=<IP> 1471 22 SSH_TTY=/dev/pts/31
          27066:    TERM=vt100


	Do you have any ideas what I can define in order to fix this problem?


	I also found what I believe might be a bug in uidswap.c at line 88.  It
used to look like:

-----
#ifndef SAVED_IDS_WORK_WITH_SETEUID
        /* Propagate the privileged gid to all of our gids. */
        if (setgid(getegid()) < 0)
                debug("setgid %u: %.100s", (u_int) getegid(), strerror(errno));
        /* Propagate the privileged uid to all of our uids. */
        if (setuid(geteuid()) < 0)
                debug("setuid %u: %.100s", (u_int) geteuid(), strerror(errno));
#endif /* SAVED_IDS_WORK_WITH_SETEUID */
        if (setegid(pw->pw_gid) < 0)
                fatal("setegid %u: %.100s", (u_int) pw->pw_gid,
                    strerror(errno));
        if (seteuid(pw->pw_uid) == -1)
                fatal("seteuid %u: %.100s", (u_int) pw->pw_uid,
                    strerror(errno));
-----


It now looks like:

-----
#ifdef SAVED_IDS_WORK_WITH_SETEUID
        if (setegid(pw->pw_gid) < 0)
                fatal("setegid %u: %.100s", (u_int) pw->pw_gid,
                    strerror(errno));
        if (seteuid(pw->pw_uid) == -1)
                fatal("seteuid %u: %.100s", (u_int) pw->pw_uid,
                    strerror(errno));
#else /* SAVED_IDS_WORK_WITH_SETEUID */
        /* Propagate the privileged gid to all of our gids. */
        if (setgid(getegid()) < 0)
                debug("setgid %u: %.100s", (u_int) getegid(), strerror(errno));
        /* Propagate the privileged uid to all of our uids. */
        if (setuid(geteuid()) < 0)
                debug("setuid %u: %.100s", (u_int) geteuid(), strerror(errno));
#endif /* SAVED_IDS_WORK_WITH_SETEUID */
-----


	Otherwise, I've made no changes.

	Thanks in advance.

--
Best regards,
  Patrick                             mailto:phess at best.com


From wendyp at cray.com  Tue Oct  9 05:19:28 2001
From: wendyp at cray.com (Wendy Palm)
Date: Mon, 08 Oct 2001 14:19:28 -0500
Subject: Porting OpenSSH 2.9.9p2 to Dynix V4.4.4
References: <200110081910.MAA22549@shell5.ba.best.com>
Message-ID: <3BC1FC40.2A6CA06F@cray.com>

have you tried using LOGIN_NEEDS_UTMPX ?

Patrick Hess wrote:
> 
> Hello Porters,
> 
>         I am attempting to compile OpenSSH 2.9.9p2 on a Dynix V4.4.4 host.
> I have set USE_PIPES and BROKEN_SAVED_UIDS (the latter because there are
> no functions for set{eu,eg}id() that I can find).  I configured with
> "./configure  '--with-libs=-lnsl -lsec'".
> 
>         Each time I attempt to login, I get this error:
> 
>           No utmp entry.  You must exec "login" from the lowest level "sh".
> 
>         The Dynix man page for login (1) states:
> 
>           No utmp entry. You must exec "login" from the lowest level "sh"
>                You attempted to execute login as a command without
>                using the shell's exec internal command or from other
>                than the initial shell.
> 
>         A "truss -aef" tells me that login is being execl'd like:
> 
>           27066:  execve("/bin/login", 0x080470FC, 0x0815F6CC) argc = 7
>           27066:   argv: login -h <IP> -p -f -- phess
>           27066:   envp: TZ=BST11 SSH_CLIENT=<IP> 1471 22 SSH_TTY=/dev/pts/31
>           27066:    TERM=vt100
> 
>         Do you have any ideas what I can define in order to fix this problem?
> 
>         I also found what I believe might be a bug in uidswap.c at line 88.  It
> used to look like:
> 
> -----
> #ifndef SAVED_IDS_WORK_WITH_SETEUID
>         /* Propagate the privileged gid to all of our gids. */
>         if (setgid(getegid()) < 0)
>                 debug("setgid %u: %.100s", (u_int) getegid(), strerror(errno));
>         /* Propagate the privileged uid to all of our uids. */
>         if (setuid(geteuid()) < 0)
>                 debug("setuid %u: %.100s", (u_int) geteuid(), strerror(errno));
> #endif /* SAVED_IDS_WORK_WITH_SETEUID */
>         if (setegid(pw->pw_gid) < 0)
>                 fatal("setegid %u: %.100s", (u_int) pw->pw_gid,
>                     strerror(errno));
>         if (seteuid(pw->pw_uid) == -1)
>                 fatal("seteuid %u: %.100s", (u_int) pw->pw_uid,
>                     strerror(errno));
> -----
> 
> It now looks like:
> 
> -----
> #ifdef SAVED_IDS_WORK_WITH_SETEUID
>         if (setegid(pw->pw_gid) < 0)
>                 fatal("setegid %u: %.100s", (u_int) pw->pw_gid,
>                     strerror(errno));
>         if (seteuid(pw->pw_uid) == -1)
>                 fatal("seteuid %u: %.100s", (u_int) pw->pw_uid,
>                     strerror(errno));
> #else /* SAVED_IDS_WORK_WITH_SETEUID */
>         /* Propagate the privileged gid to all of our gids. */
>         if (setgid(getegid()) < 0)
>                 debug("setgid %u: %.100s", (u_int) getegid(), strerror(errno));
>         /* Propagate the privileged uid to all of our uids. */
>         if (setuid(geteuid()) < 0)
>                 debug("setuid %u: %.100s", (u_int) geteuid(), strerror(errno));
> #endif /* SAVED_IDS_WORK_WITH_SETEUID */
> -----
> 
>         Otherwise, I've made no changes.
> 
>         Thanks in advance.
> 
> --
> Best regards,
>   Patrick                             mailto:phess at best.com

-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp at cray.com, 651-605-9154


From florin at sgi.com  Tue Oct  9 05:28:51 2001
From: florin at sgi.com (Florin Andrei)
Date: 08 Oct 2001 12:28:51 -0700
Subject: src.rpm rebuild problem
Message-ID: <1002569331.24339.69.camel@stantz.corp.sgi.com>

Trying to rebuild openssh-2.9.9p2-1.src.rpm on Red Hat 6.1:

Script started on Mon Oct  8 11:26:09 2001
[root at five work]# rpm --rebuild openssh-2.9.9p2-1.src.rpm 
Installing openssh-2.9.9p2-1.src.rpm
Bad owner/group: /usr/src/redhat/SOURCES/x11-ssh-askpass-1.2.4.tar.gz
[root at five work]# ls -l /usr/src/redhat/SOURCES/
total 720
-rw-rw-r--   1 500      500        697371 Sep 25 15:50 openssh-2.9.9p2.tar.gz
-rw-rw-r--   1 500      500         29197 Sep 16 15:15 x11-ssh-askpass-1.2.4.tar.gz
[root at five work]# exit
exit
Script done on Mon Oct  8 11:26:27 2001

-- 
Florin Andrei

"In theory, under the new computer security law, anyone whose computer
was infected by Nimda/CodeRed could be imprisoned for life -- the new
law says nothing about intent. So, basically we would have a few million
Microsoft Windows users serving life sentences..." - Dan Hollis



From ed at UDel.Edu  Tue Oct  9 05:53:51 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 8 Oct 2001 15:53:51 -0400 (EDT)
Subject: ssh hangs instead of exiting
In-Reply-To: <200110081852.OAA11071@eworld.wox.org>
Message-ID: <Pine.SOL.4.30.0110081544350.27737-100000@mahler.udel.edu>

On Mon, 8 Oct 2001, James Oden wrote:

> Date: Mon, 8 Oct 2001 14:52:20 -0400 (EDT)
> From: James Oden <joden at eworld.wox.org>
> To: openssh-unix-dev at mindrot.org
> Subject: Hanging ssh session...
>
> Hi All,
>
> I am not sure if this is the same thing as the hang on exit bug, so sorry if
> this is a duplication of previous stuff.
>
> Essetntially I am experiencing ssh hangs with about .5% - 1% of my
> connections.  I am running 2.9p2, on Solaris 7.  I actually have empirical
> data on the hangings, as I wrote a script to create these connections
> in an endless loop, setting an alarm so I could recover from a hang.
> I will place this script at the end of my email.

By the way, in my case, the hang of the orginal ssh process and error
messages occurs more often than not... but strangely enough, not _every_
time.  It must be some kind of race.  The process I use is - do "ssh -n
<host> xterm", and then when the xterm pops up, immediately press CTRL-d
so that the xterm exits.  Here's what I see on the client side for several
runs:

polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
polycut:~> ssh -n mahler xterm
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
channel_lookup: 0: bad id: channel free
client_input_channel_req: channel 0: unknown channel
^CKilled by signal 2.
polycut:~> ssh -n mahler xterm
polycut:~>

Someone has suggested that I try 2.9.9p2 (are there fixes in 2.9.9p2
related to this problem?) and I'll try that ASAP.

Side question:  Can anyone tell me how to build openssh so that it has
"built-in" entropy collection instead of needing to build/install/run
PRNGd?

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 phess at best.com  Tue Oct  9 05:53:08 2001
From: phess at best.com (Patrick Hess)
Date: Mon, 8 Oct 2001 12:53:08 -0700 (PDT)
Subject: Porting OpenSSH 2.9.9p2 to Dynix V4.4.4
In-Reply-To: <3BC1FC40.2A6CA06F@cray.com> from Wendy Palm at "Oct 8, 1 02:19:28 pm"
Message-ID: <200110081953.MAA00640@shell5.ba.best.com>

Yeah, just tried LOGIN_NEEDS_UTMPX and it failed too.  Any other ideas?  :)

			Patrick

Wendy Palm once said:
> have you tried using LOGIN_NEEDS_UTMPX ?
> 
> Patrick Hess wrote:
> > 
> > Hello Porters,
> > 
> >         I am attempting to compile OpenSSH 2.9.9p2 on a Dynix V4.4.4 host.
> > I have set USE_PIPES and BROKEN_SAVED_UIDS (the latter because there are
> > no functions for set{eu,eg}id() that I can find).  I configured with
> > "./configure  '--with-libs=-lnsl -lsec'".
> > 
> >         Each time I attempt to login, I get this error:
> > 
> >           No utmp entry.  You must exec "login" from the lowest level "sh".
> > 
> >         The Dynix man page for login (1) states:
> > 
> >           No utmp entry. You must exec "login" from the lowest level "sh"
> >                You attempted to execute login as a command without
> >                using the shell's exec internal command or from other
> >                than the initial shell.
> > 
> >         A "truss -aef" tells me that login is being execl'd like:
> > 
> >           27066:  execve("/bin/login", 0x080470FC, 0x0815F6CC) argc = 7
> >           27066:   argv: login -h <IP> -p -f -- phess
> >           27066:   envp: TZ=BST11 SSH_CLIENT=<IP> 1471 22 SSH_TTY=/dev/pts/31
> >           27066:    TERM=vt100
> > 
> >         Do you have any ideas what I can define in order to fix this problem?
> >         Thanks in advance.
> > 
> > --
> > Best regards,
> >   Patrick                             mailto:phess at best.com
> 
> -- 
> wendy palm
> Cray OS Sustaining Engineering, Cray Inc.
> wendyp at cray.com, 651-605-9154
> 



From phess at best.com  Tue Oct  9 06:39:21 2001
From: phess at best.com (Patrick Hess)
Date: Mon, 8 Oct 2001 13:39:21 -0700 (PDT)
Subject: Porting OpenSSH 2.9.9p2 to Dynix V4.4.4
In-Reply-To: <3BC20724.99E10BFF@cray.com> from Wendy Palm at "Oct 8, 1 03:05:56 pm"
Message-ID: <200110082039.NAA09093@shell5.ba.best.com>

USE_UTMP and USE_UTMPX and USE_WTMP are set in config.h (correctly).  

UseLogin is just a variable to allow sshd to ignore /etc/nologin.
Just FYI, it's not set.

			Patrick


Wendy Palm once said:
> well, that resolved my problem on the cray.  i'm afraid i hit
> my knowledge limit on that.
> there's also "USE_UTMP", maybe it additionally needs that?
> 
> is your UseLogin set or not?
> 
> -- 
> wendy palm
> Cray OS Sustaining Engineering, Cray Inc.
> wendyp at cray.com, 651-605-9154
> 



From openssh-unix-dev at thewrittenword.com  Tue Oct  9 07:14:46 2001
From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com)
Date: Mon, 8 Oct 2001 16:14:46 -0500
Subject: Using -lssh as shared library
In-Reply-To: <Pine.BSO.4.33.0110072033470.23894-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Sun, Oct 07, 2001 at 08:51:35PM -0500
References: <3BC0E394.6F0361A6@tls.msk.ru> <Pine.BSO.4.33.0110072033470.23894-100000@etoh.eviladmin.org>
Message-ID: <20011008161446.A3853@oolong.il.thewrittenword.com>

On Sun, Oct 07, 2001 at 08:51:35PM -0500, mouring at etoh.eviladmin.org wrote:
> I think we need to clean up configure.in before implementing this.

Amen! One thing that can be done immediately is to refuse any patch
that does the following (unless there is a very very good reason):
  case "$host" in
  *-*-aix*)
    AC_DEFINE(...)
    ...
  ...

This is usually done out of laziness and is gross!

-- 
albert chin (china at thewrittenword.com)


From phess at best.com  Tue Oct  9 07:38:04 2001
From: phess at best.com (Patrick Hess)
Date: Mon, 8 Oct 2001 14:38:04 -0700 (PDT)
Subject: Porting OpenSSH 2.9.9p2 to Dynix V4.4.4
In-Reply-To: <200110082039.NAA09093@shell5.ba.best.com> from Patrick Hess at "Oct 8, 1 01:39:21 pm"
Message-ID: <200110082138.OAA24371@shell5.ba.best.com>

Okay...  :)

	I was wrong.  UseLogin was indeed set, and unsetting it fixed my
problem.  :)  Thank you VERY much.  Apparently I need to go figger out what
UseLogin actually does.  :)

			Patrick


Patrick Hess once said:
> USE_UTMP and USE_UTMPX and USE_WTMP are set in config.h (correctly).  
> 
> UseLogin is just a variable to allow sshd to ignore /etc/nologin.
> Just FYI, it's not set.
> 
> 			Patrick
> 
> 
> Wendy Palm once said:
> > well, that resolved my problem on the cray.  i'm afraid i hit
> > my knowledge limit on that.
> > there's also "USE_UTMP", maybe it additionally needs that?
> > 
> > is your UseLogin set or not?
> > 
> > -- 
> > wendy palm
> > Cray OS Sustaining Engineering, Cray Inc.
> > wendyp at cray.com, 651-605-9154
> > 
> 



From wendyp at cray.com  Tue Oct  9 07:49:42 2001
From: wendyp at cray.com (Wendy Palm)
Date: Mon, 08 Oct 2001 16:49:42 -0500
Subject: Porting OpenSSH 2.9.9p2 to Dynix V4.4.4
References: <200110082138.OAA24371@shell5.ba.best.com>
Message-ID: <3BC21F76.11B89501@cray.com>

ok, in that case, 

the problem is that the utmp is not getting created before calling login.
so there must be something wrong with do_pre_login for your system
(session.c) in that it won't create the utmp properly.

when UseLogin is not set, you are using the login sequence within the
openssh code itself, which seems to work for your os.

good luck,
wendy

Patrick Hess wrote:
> 
> Okay...  :)
> 
>         I was wrong.  UseLogin was indeed set, and unsetting it fixed my
> problem.  :)  Thank you VERY much.  Apparently I need to go figger out what
> UseLogin actually does.  :)
> 
>                         Patrick
> 
> Patrick Hess once said:
> > USE_UTMP and USE_UTMPX and USE_WTMP are set in config.h (correctly).
> >
> > UseLogin is just a variable to allow sshd to ignore /etc/nologin.
> > Just FYI, it's not set.
> >
> >                       Patrick
> >
> >
> > Wendy Palm once said:
> > > well, that resolved my problem on the cray.  i'm afraid i hit
> > > my knowledge limit on that.
> > > there's also "USE_UTMP", maybe it additionally needs that?
> > >
> > > is your UseLogin set or not?
> > >
> > > --
> > > wendy palm
> > > Cray OS Sustaining Engineering, Cray Inc.
> > > wendyp at cray.com, 651-605-9154
> > >
> >

-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp at cray.com, 651-605-9154


From jmknoble at pobox.com  Tue Oct  9 08:38:47 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Mon, 8 Oct 2001 18:38:47 -0400
Subject: src.rpm rebuild problem
In-Reply-To: <1002569331.24339.69.camel@stantz.corp.sgi.com>; from florin@sgi.com on Mon, Oct 08, 2001 at 12:28:51PM -0700
References: <1002569331.24339.69.camel@stantz.corp.sgi.com>
Message-ID: <20011008183847.C2898@zax.half.pint-stowp.cx>

Circa 2001-Oct-08 12:28:51 -0700 dixit Florin Andrei:

: Trying to rebuild openssh-2.9.9p2-1.src.rpm on Red Hat 6.1:
: 
: Script started on Mon Oct  8 11:26:09 2001
: [root at five work]# rpm --rebuild openssh-2.9.9p2-1.src.rpm 
: Installing openssh-2.9.9p2-1.src.rpm
: Bad owner/group: /usr/src/redhat/SOURCES/x11-ssh-askpass-1.2.4.tar.gz
: [root at five work]# ls -l /usr/src/redhat/SOURCES/
: total 720
: -rw-rw-r--   1 500      500        697371 Sep 25 15:50 openssh-2.9.9p2.tar.gz
: -rw-rw-r--   1 500      500         29197 Sep 16 15:15 x11-ssh-askpass-1.2.4.tar.gz
: [root at five work]# exit
: exit
: Script done on Mon Oct  8 11:26:27 2001

What version of RPM?

-- 
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/20011008/80415e58/attachment.bin 

From phess at best.com  Tue Oct  9 08:55:57 2001
From: phess at best.com (Patrick Hess)
Date: Mon, 8 Oct 2001 15:55:57 -0700 (PDT)
Subject: Ported OpenSSH 2.9.9p2 to Dynix
Message-ID: <200110082255.PAA11566@shell5.ba.best.com>

Hello Porters,

	I've finally (thanks to Wendy Palm of Cray) ported OpenSSH to
Dynix v4.4.4.  I had to make sure that "UseLogin" was set to "no" in the
sshd_config file.  Also, here are the old-style contextual diffs (obtained
with 'diff -c' on the Dynix box) of the two files I had to change:

*** configure Sat Jun 16 17:09:50 2001
--- configure.new Mon Oct  8 11:33:09 2001
***************
*** 1960,1965 ****
--- 1960,1985 ----

        LIBS="$LIBS -lgen -lnsl -lucb"
        ;;
+ *-sequent-sysv4*)
+       CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+       LDFLAGS="$LDFLAGS -L/usr/local/lib"
+       LIBS="$LIBS -lnsl -lsec"
+       rsh_path="/usr/bin/resh"
+       conf_utmpx_location="/var/adm/utmpx"
+       cat >> confdefs.h <<\EOF
+ #define USE_PIPES 1
+ EOF
+
+       cat >> confdefs.h <<\EOF
+ #define BROKEN_SAVED_UIDS 1
+ EOF
+
+       cat >> confdefs.h <<\EOF
+ #define LOGIN_NEEDS_UTMPX 1
+ EOF
+
+         MANTYPE=cat
+       ;;
  *-*-sysv4.2*)
        CPPFLAGS="$CPPFLAGS -I/usr/local/include"
        LDFLAGS="$LDFLAGS -L/usr/local/lib"
*** uidswap.c Thu Apr 26 15:10:15 2001
--- uidswap.c.new Mon Oct  8 11:33:42 2001
***************
*** 85,91 ****
        if (setgroups(user_groupslen, user_groups) < 0)
                fatal("setgroups: %.100s", strerror(errno));
  #endif /* !HAVE_CYWIN */
! #ifndef SAVED_IDS_WORK_WITH_SETEUID
        /* Propagate the privileged gid to all of our gids. */
        if (setgid(getegid()) < 0)
                debug("setgid %u: %.100s", (u_int) getegid(), strerror(errno));
--- 85,98 ----
        if (setgroups(user_groupslen, user_groups) < 0)
                fatal("setgroups: %.100s", strerror(errno));
  #endif /* !HAVE_CYWIN */
! #ifdef SAVED_IDS_WORK_WITH_SETEUID
!       if (setegid(pw->pw_gid) < 0)
!               fatal("setegid %u: %.100s", (u_int) pw->pw_gid,
!                   strerror(errno));
!       if (seteuid(pw->pw_uid) == -1)
!               fatal("seteuid %u: %.100s", (u_int) pw->pw_uid,
!                   strerror(errno));
! #else /* SAVED_IDS_WORK_WITH_SETEUID */
        /* Propagate the privileged gid to all of our gids. */
        if (setgid(getegid()) < 0)
                debug("setgid %u: %.100s", (u_int) getegid(), strerror(errno));
*** 93,104 ****
        if (setuid(geteuid()) < 0)
                debug("setuid %u: %.100s", (u_int) geteuid(), strerror(errno));
  #endif /* SAVED_IDS_WORK_WITH_SETEUID */
-       if (setegid(pw->pw_gid) < 0)
-               fatal("setegid %u: %.100s", (u_int) pw->pw_gid,
-                   strerror(errno));
-       if (seteuid(pw->pw_uid) == -1)
-               fatal("seteuid %u: %.100s", (u_int) pw->pw_uid,
-                   strerror(errno));
  }
  
  /*


From djm at mindrot.org  Tue Oct  9 09:50:43 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 9 Oct 2001 09:50:43 +1000 (EST)
Subject: Using -lssh as shared library
In-Reply-To: <Pine.BSO.4.33.0110080955220.15573-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.33.0110090946190.3638-100000@mothra.mindrot.org>

On Mon, 8 Oct 2001 mouring at etoh.eviladmin.org wrote:

> > from arc4random() should be made global and available from
> > seed_rng() as well (this last point isn't obvious, as it
> > will stop calling seed_rgn() more than once if *required*).
> 
> Damien, can we just remove seed_rng() from arc4random?  We are doing
> seed_rng() in every major binary that requires entropy collection (except
> for ssh-keyscan.c which we need to add it to now).  I know we needed this
> when we first started, but I think (from glancing at the code) it is now
> dead wood.  I would prefer that than sprinkling portable code around more.

You can if you can make sure that the arc4 prng gets seeded with good 
entropy. I think OpenSSL provides a way to do that.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From florin at sgi.com  Tue Oct  9 10:15:01 2001
From: florin at sgi.com (Florin Andrei)
Date: 08 Oct 2001 17:15:01 -0700
Subject: src.rpm rebuild problem
In-Reply-To: <20011008183847.C2898@zax.half.pint-stowp.cx>
References: <1002569331.24339.69.camel@stantz.corp.sgi.com> 
	<20011008183847.C2898@zax.half.pint-stowp.cx>
Message-ID: <1002586501.25719.53.camel@stantz.corp.sgi.com>

On Mon, 2001-10-08 at 15:38, Jim Knoble wrote:
> 
> What version of RPM?

The default one, which is extremely older and fails later during the
build anyway. :o)
But the point is - why those strange UID/GID? (500/500)

-- 
Florin Andrei

"In theory, under the new computer security law, anyone whose computer
was infected by Nimda/CodeRed could be imprisoned for life -- the new
law says nothing about intent. So, basically we would have a few million
Microsoft Windows users serving life sentences..." - Dan Hollis



From florin at sgi.com  Tue Oct  9 10:23:27 2001
From: florin at sgi.com (Florin Andrei)
Date: 08 Oct 2001 17:23:27 -0700
Subject: 2.9.9p2 on SGI Irix
Message-ID: <1002587007.26018.62.camel@stantz.corp.sgi.com>

Just a FYI: OpenSSH-2.9.9p2 compiles just fine on Irix 6.5.13, using the
MIPSPro-7.3 compiler (gcc-3.0 creates a binary that gives funny log
messages), linking against the freeware OpenSSL package from
freeware.sgi.com
No PAM, but anyway...

This is how i did it:

bash-2.04# export CC=cc
bash-2.04# ./configure --prefix=/usr/local/openssh \
    --with-ldflags=-L/usr/freeware/lib32 \
    --with-cflags=-I/usr/freeware/include

If you don't tweak those flags it won't compile.

OpenSSH rocks! :o)

-- 
Florin Andrei

"In theory, under the new computer security law, anyone whose computer
was infected by Nimda/CodeRed could be imprisoned for life -- the new
law says nothing about intent. So, basically we would have a few million
Microsoft Windows users serving life sentences..." - Dan Hollis



From jmknoble at pobox.com  Tue Oct  9 13:32:50 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Mon, 8 Oct 2001 23:32:50 -0400
Subject: src.rpm rebuild problem
In-Reply-To: <1002586501.25719.53.camel@stantz.corp.sgi.com>; from florin@sgi.com on Mon, Oct 08, 2001 at 05:15:01PM -0700
References: <1002569331.24339.69.camel@stantz.corp.sgi.com> <20011008183847.C2898@zax.half.pint-stowp.cx> <1002586501.25719.53.camel@stantz.corp.sgi.com>
Message-ID: <20011008233250.D2898@zax.half.pint-stowp.cx>

Circa 2001-Oct-08 17:15:01 -0700 dixit Florin Andrei:

: On Mon, 2001-10-08 at 15:38, Jim Knoble wrote:
: > 
: > What version of RPM?
: 
: The default one, which is extremely older and fails later during the
: build anyway. :o)
: But the point is - why those strange UID/GID? (500/500)

Because those files were owned by UID 500 on the system on which the
source RPM package was built, and your version of RPM doesn't handle
that properly.

Get an updated RPM for your system.  Either this one:

  ftp://ftp.rpm.org/pub/rpm/dist/rpm-3.0.x/rpm-3.0.6-6x.i386.rpm
  ftp://ftp.rpm.org/pub/rpm/dist/rpm-3.0.x/rpm-*-3.0.6-6x.i386.rpm

or this one:

  http://www.redhat.com/support/errata/RHEA-2001-015.html
  http://www.redhat.com/support/errata/RHEA-2001-016.html

They should work fine.

(And if you haven't applied any updates to your system, i'm not sure
you're building OpenSSH, because your system already has holes big
enough to drive a truck through.  Consider applying some of the other
Red Hat Linux 6.x updates as well.)

-- 
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/20011008/f63c39bb/attachment.bin 

From frank at google.com  Tue Oct  9 13:46:33 2001
From: frank at google.com (Frank Cusack)
Date: Mon, 8 Oct 2001 20:46:33 -0700
Subject: TISviaPAM patch
Message-ID: <20011008204633.N16522@google.com>

Here is a patch that does TIS auth via PAM.  It's controlled by a switch
in the sshd_config.  You'd use it by having a PAM module that sets
PAM_PROMPT_ECHO_ON.  eg, you could use it with pam_skey or pam_smxs.

The patch is against the 2.9.9p2 distribution.

I'm not on the list, a reply if this patch is accepted would be great.
(But not required, I know some folks have a distaste for folks asking
for a CC.)  Apologies for the not-quite-diff format, but it should
apply easily (you'll just get complaints about "missing header").

Also, let me know if you have questions, etc.  Hopefully a text/plain
attachment is OK.  It's a little bit big, but not TOO out of control.
I am a US citizen, in the US, but this is a non-crypto patch.

/fc


From mouring at etoh.eviladmin.org  Tue Oct  9 13:49:00 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 8 Oct 2001 22:49:00 -0500 (CDT)
Subject: Patch to improve afs support 
In-Reply-To: <Pine.GSO.4.33.0110081148040.25416-100000@shred.stanford.edu>
Message-ID: <Pine.BSO.4.33.0110082248470.26100-100000@etoh.eviladmin.org>


Please submit all patches in unifed format.

- Ben

On Mon, 8 Oct 2001, Booker C. Bense wrote:

>
> - The following patch moves the chdir(pw->pw_dir) section to
> after the afs login attempt section in session.c. This
> allows paranoid people that don't want to give
>
> 	system:anyuser l
>
> access to their home dir to login.
>
> diff -r1.1.1.1 session.c
> 1346,1354d1345
> <       /* Change current directory to the user\'s home directory. */
> <       if (chdir(pw->pw_dir) < 0) {
> <               fprintf(stderr, "Could not chdir to home directory %s:
> %s\n",
> <                       pw->pw_dir, strerror(errno));
> < #ifdef HAVE_LOGIN_CAP
> <               if (login_getcapbool(lc, "requirehome", 0))
> <                       exit(1);
> < #endif
> <       }
> 1372a1364,1374
> >
> >       /* Change current directory to the user\'s home directory. */
> >       if (chdir(pw->pw_dir) < 0) {
> >               fprintf(stderr, "Could not chdir to home directory %s:
> %s\n",
> >                       pw->pw_dir, strerror(errno));
> > #ifdef HAVE_LOGIN_CAP
> >               if (login_getcapbool(lc, "requirehome", 0))
> >                       exit(1);
> > #endif
> >       }
> >
>
>
>



From bbense at networking.stanford.edu  Tue Oct  9 14:20:03 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Mon, 8 Oct 2001 21:20:03 -0700 (PDT)
Subject: Patch to improve afs support 
In-Reply-To: <Pine.BSO.4.33.0110082248470.26100-100000@etoh.eviladmin.org>
Message-ID: <Pine.GSO.4.33.0110082119290.27341-100000@shred.stanford.edu>

On Mon, 8 Oct 2001 mouring at etoh.eviladmin.org wrote:

>
> Please submit all patches in unifed format.
>
> - Ben
>

Index: session.c
===================================================================
RCS file: /afs/ir/dev/cvs/kerberos/openssh/session.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- session.c	2001/10/01 18:18:47	1.1
+++ session.c	2001/10/08 20:54:01	1.2
@@ -1343,15 +1343,6 @@
 	for (i = 3; i < 64; i++)
 		close(i);

-	/* Change current directory to the user\'s home directory. */
-	if (chdir(pw->pw_dir) < 0) {
-		fprintf(stderr, "Could not chdir to home directory %s: %s\n",
-			pw->pw_dir, strerror(errno));
-#ifdef HAVE_LOGIN_CAP
-		if (login_getcapbool(lc, "requirehome", 0))
-			exit(1);
-#endif
-	}

 	/*
 	 * Must take new environment into use so that .ssh/rc, /etc/sshrc and
@@ -1370,6 +1361,17 @@
 		krb_afslog(0, 0);
 	}
 #endif /* AFS */
+
+	/* Change current directory to the user\'s home directory. */
+	if (chdir(pw->pw_dir) < 0) {
+		fprintf(stderr, "Could not chdir to home directory %s: %s\n",
+			pw->pw_dir, strerror(errno));
+#ifdef HAVE_LOGIN_CAP
+		if (login_getcapbool(lc, "requirehome", 0))
+			exit(1);
+#endif
+	}
+

 	/*
 	 * Run $HOME/.ssh/rc, /etc/sshrc, or xauth (whichever is found first



From mouring at etoh.eviladmin.org  Tue Oct  9 14:43:24 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 8 Oct 2001 23:43:24 -0500 (CDT)
Subject: socks and misc patch to 2.9.9p2
In-Reply-To: <200110081744.f98HiWA11288@bzs.org>
Message-ID: <Pine.BSO.4.33.0110082327530.24935-100000@etoh.eviladmin.org>


> Not really, what the "patch" says it that I believe that the ssh code
> should be machine and platform independent for the user. I don't
> consider it particularly useful to have to write a different script
> that uses ssh or scp for every platform that must use a socks proxy

why do you have to?  You are not understanding ProxyCommand.



> and to have to modify and update that script  every time the sysadmin
> decides to change or eliminate the socks gateway. I currently deply
> scripts to a multitude of hosts that must utilize socks to have
> firewall acess. These hosts are at different sites and thus have
> differing proxy hosts. It is much cleaner to simply deploy a script
> with commands for ssh and scp that are free of direct references to
> unique hosts that differ among sites. I would much prefer to leave
> proxy selection up to the sysadmin of the site when the hosts are
> configured (or re-configured). I think the general idea is that the
> client application should not have to be configured, only the host
> and only once.
>

> The solution I propose is a general solution, not site specific as it
> the present mode of using a socks proxy from the command line.
>

[.. Quote from an old message posted here.. Provides Sock and HTTP
solution that is more 'general' than adding your code..]

I have one proxy command which use SOCKS5 or HTTP-proxy (CONNECT).
I'm using it every day via SOCKS to login to out-side host
from UNIX (BSD/OS) and Windows (CygWin) environments.

If you wanna try, get source "connect.c" from
http://www.imasy.or.jp/~gotoh/connect.c
and compile it.

[for UNIX]
  gcc -o connect connect.c

[for Win32 (Visual C)]
  cl connect.c wsock32.lib

You should add entry to use it in ~/.ssh/config, like:

[for SOCKS5]
Host xxxx
  ProxyCommand connect -S socks-server %h %p

[for HTTP proxy]
Host xxxx
  ProxyCommand connect -H http-server %h %p

 NOTE: "socks-server" and "http-server" is proxy hostname on your site.

It's very simple.
First make connection via SOCKS5 or HTTP-proxy
then relaying socket I/O each direction
But it is written only for my use.
So some functions are lacked.
For example SOCKS4 support and USER/PASS authentication support.
These are easy to implement, but not yet...

I'm welcome your suggestion.

--- Regards,
 Shun-ichi Goto  <gotoh at taiyo.co.jp>
[..]

Again, I say.. if ProxyCommand breaks scp please provide us a hard example
so we can fix it.

- Ben



From vinschen at redhat.com  Tue Oct  9 17:26:53 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 9 Oct 2001 09:26:53 +0200
Subject: Ported OpenSSH 2.9.9p2 to Dynix
In-Reply-To: <200110082255.PAA11566@shell5.ba.best.com>; from phess@best.com on Mon, Oct 08, 2001 at 03:55:57PM -0700
References: <200110082255.PAA11566@shell5.ba.best.com>
Message-ID: <20011009092653.T12872@cygbert.vinschen.de>

On Mon, Oct 08, 2001 at 03:55:57PM -0700, Patrick Hess wrote:
> Hello Porters,
> 
> 	I've finally (thanks to Wendy Palm of Cray) ported OpenSSH to
> Dynix v4.4.4.  I had to make sure that "UseLogin" was set to "no" in the
> sshd_config file.  Also, here are the old-style contextual diffs (obtained
> with 'diff -c' on the Dynix box) of the two files I had to change:
> 
> *** configure Sat Jun 16 17:09:50 2001
> --- configure.new Mon Oct  8 11:33:09 2001
> ***************
> *** 1960,1965 ****
> --- 1960,1985 ----
> 
>         LIBS="$LIBS -lgen -lnsl -lucb"
>         ;;
> + *-sequent-sysv4*)
> +       CPPFLAGS="$CPPFLAGS -I/usr/local/include"
> +       LDFLAGS="$LDFLAGS -L/usr/local/lib"
> +       LIBS="$LIBS -lnsl -lsec"
> +       rsh_path="/usr/bin/resh"
> +       conf_utmpx_location="/var/adm/utmpx"
> +       cat >> confdefs.h <<\EOF
> + #define USE_PIPES 1
> + EOF
> +
> +       cat >> confdefs.h <<\EOF
> + #define BROKEN_SAVED_UIDS 1
> + EOF
> +
> +       cat >> confdefs.h <<\EOF
> + #define LOGIN_NEEDS_UTMPX 1
> + EOF
> +
> +         MANTYPE=cat
> +       ;;
>   *-*-sysv4.2*)
>         CPPFLAGS="$CPPFLAGS -I/usr/local/include"
>         LDFLAGS="$LDFLAGS -L/usr/local/lib"

That's not ok as a patch.  You'll have to change configure.in
to accomodate the new target system.  configure is generated
from configure.in using autoconf.

Corinna

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


From gotoh at taiyo.co.jp  Tue Oct  9 18:07:26 2001
From: gotoh at taiyo.co.jp (Shun-ichi GOTO)
Date: Tue, 09 Oct 2001 17:07:26 +0900 (JST)
Subject: Small patch for ssh_askpass()
Message-ID: <20011009.170726.123584141.gotoh@taiyo.co.jp>

Hi, 
There is small bug in ssh_askpass().
Fix like this.
Additionally removing '\r' is for Win32 environment.


--- readpass.c	2001/10/09 05:42:49	1.1.1.1
+++ readpass.c	2001/10/09 08:06:38
@@ -45,7 +45,7 @@
 {
 	pid_t pid;
 	size_t len;
-	char *nl, *pass;
+	char *pass;
 	int p[2], status;
 	char buf[1024];
 
@@ -71,16 +71,15 @@
 		fatal("ssh_askpass: exec(%s): %s", askpass, strerror(errno));
 	}
 	close(p[1]);
-	len = read(p[0], buf, sizeof buf);
+	len = read(p[0], buf, sizeof buf -1);
 	close(p[0]);
 	while (waitpid(pid, &status, 0) < 0)
 		if (errno != EINTR)
 			break;
 	if (len <= 1)
 		return xstrdup("");
-	nl = strchr(buf, '\n');
-	if (nl)
-		*nl = '\0';
+	buf[len] = '\0';
+	buf[strcspn(buf, "\r\n")] = '\0';
 	pass = xstrdup(buf);
 	memset(buf, 0, sizeof(buf));
 	return pass;

--- Regards,
 Shun-ichi Goto  <gotoh at taiyo.co.jp>
   R&D Group, TAIYO Corp., Tokyo, JAPAN


From frank at google.com  Tue Oct  9 18:14:34 2001
From: frank at google.com (Frank Cusack)
Date: Tue, 9 Oct 2001 01:14:34 -0700
Subject: TISviaPAM patch
In-Reply-To: <20011008204633.N16522@google.com>; from frank@google.com on Mon, Oct 08, 2001 at 08:46:33PM -0700
References: <20011008204633.N16522@google.com>
Message-ID: <20011009011434.B18763@google.com>

On Mon, Oct 08, 2001 at 08:46:33PM -0700, Frank Cusack wrote:
> Here is a patch that does TIS auth via PAM.  It's controlled by a switch
> in the sshd_config.  You'd use it by having a PAM module that sets
> PAM_PROMPT_ECHO_ON.  eg, you could use it with pam_skey or pam_smxs.
> 
> The patch is against the 2.9.9p2 distribution.

oops.  Here's the actual patch.

/fc
-------------- next part --------------
	Add 'TISviaPAM' option, which uses PAM for ssh1 TIS authentication.
	This allows arbitrary challenge/response authentications instead
	of the built-in S/Key.  Also fixed 2-3 small typos and a bug in
	password handling for TIS (turn echo on).
	
Index: openssh/auth-pam.c
@@ -26,6 +26,8 @@
 
 #ifdef USE_PAM
 #include "ssh.h"
+#include "ssh1.h"
+#include "packet.h"
 #include "xmalloc.h"
 #include "log.h"
 #include "auth-pam.h"
@@ -54,6 +56,8 @@
 
 /* states for do_pam_conversation() */
 enum { INITIAL_LOGIN, OTHER } pamstate = INITIAL_LOGIN;
+/* which type of prompts we should handle, set in auth_pam_password */
+static int pamprompt;
 /* remember whether pam_acct_mgmt() returned PAM_NEWAUTHTOK_REQD */
 static int password_change_required = 0;
 /* remember whether the last pam_authenticate() succeeded or not */
@@ -98,6 +102,10 @@
 	int count;
 	char buf[1024];
 
+	u_int dlen;
+	int plen, type;
+	char *response;
+
 	/* PAM will free this later */
 	reply = malloc(num_msg * sizeof(*reply));
 	if (reply == NULL)
@@ -111,10 +119,40 @@
 			 */
 			switch(PAM_MSG_MEMBER(msg, count, msg_style)) {
 			case PAM_PROMPT_ECHO_ON:
-				free(reply);
-				return PAM_CONV_ERR;
+				if (pamprompt != PAM_PROMPT_ECHO_ON ||
+				    (*msg)[count].msg == NULL) {
+					free(reply);
+					return PAM_CONV_ERR;
+				}
+
+				/* handle challenge/response (ssh1 TIS) */
+				/* Send the challenge */
+				strlcpy(buf, PAM_MSG_MEMBER(msg, count, msg),
+					sizeof(buf));
+				debug("sending challenge '%s'", buf);
+				packet_start(SSH_SMSG_AUTH_TIS_CHALLENGE);
+				packet_put_cstring(buf);
+				packet_send();
+				packet_write_wait();
+
+				/* Give the response to the PAM module */
+				if ((type = packet_read(&plen)) !=
+				    SSH_CMSG_AUTH_TIS_RESPONSE) {
+					free(reply);
+					return PAM_CONV_ERR;
+				}
+				debug("rcvd SSH_CMSG_AUTH_TIS_RESPONSE");
+				response = packet_get_string(&dlen);
+				debug("got response '%s'", response);
+				packet_integrity_check(plen, 4 + dlen, type);
+				reply[count].resp = xstrdup(response);
+				reply[count].resp_retcode = PAM_SUCCESS;
+				xfree(response);
+				break;
+
 			case PAM_PROMPT_ECHO_OFF:
-				if (__pampasswd == NULL) {
+				if (__pampasswd == NULL ||
+				    pamprompt != PAM_PROMPT_ECHO_OFF) {
 					free(reply);
 					return PAM_CONV_ERR;
 				}
@@ -198,8 +236,8 @@
 	}
 }
 
-/* Attempt password authentation using PAM */
-int auth_pam_password(struct passwd *pw, const char *password)
+/* Attempt password authentication using PAM */
+int auth_pam_password(struct passwd *pw, const char *password, int prompt_type)
 {
 	extern ServerOptions options;
 	int pam_retval;
@@ -211,12 +249,14 @@
 		return 0;
 	if (pw->pw_uid == 0 && options.permit_root_login == PERMIT_NO_PASSWD)
 		return 0;
-	if (*password == '\0' && options.permit_empty_passwd == 0)
+	if (*password == '\0' && options.permit_empty_passwd == 0 &&
+	    prompt_type == PAM_PROMPT_ECHO_OFF)
 		return 0;
 
 	__pampasswd = password;
 
 	pamstate = INITIAL_LOGIN;
+	pamprompt = prompt_type;
 	pam_retval = do_pam_authenticate(0);
 	if (pam_retval == PAM_SUCCESS) {
 		debug("PAM Password authentication accepted for "

Index: openssh/auth-pam.h
@@ -7,7 +7,7 @@
 
 void start_pam(const char *user);
 void finish_pam(void);
-int auth_pam_password(struct passwd *pw, const char *password);
+int auth_pam_password(struct passwd *pw, const char *password, int prompt_type);
 char **fetch_pam_environment(void);
 int do_pam_authenticate(int flags);
 int do_pam_account(char *username, char *remote_user);

Index: openssh/auth1.c
@@ -89,7 +89,7 @@
 	    (!options.kerberos_authentication || options.kerberos_or_local_passwd) &&
 #endif
 #ifdef USE_PAM
-	    auth_pam_password(pw, "")) {
+	    auth_pam_password(pw, "", PAM_PROMPT_ECHO_OFF)) {
 #elif defined(HAVE_OSF_SIA)
 	    0) {
 #else
@@ -258,7 +258,8 @@
 
 #ifdef USE_PAM
 			/* Do PAM auth with password */
-			authenticated = auth_pam_password(pw, password);
+			authenticated = auth_pam_password(pw, password,
+							  PAM_PROMPT_ECHO_OFF);
 #elif defined(HAVE_OSF_SIA)
 			/* Do SIA auth with password */
 			authenticated = auth_sia_password(authctxt->user, 
@@ -275,6 +276,15 @@
 		case SSH_CMSG_AUTH_TIS:
 			debug("rcvd SSH_CMSG_AUTH_TIS");
 			if (options.challenge_response_authentication == 1) {
+#ifdef USE_PAM
+			    if (options.tis_via_pam == 1) {
+				authenticated = auth_pam_password(pw, "",
+							  PAM_PROMPT_ECHO_ON);
+				break;
+			    } else {
+#else
+			    {
+#endif /* USE_PAM */
 				char *challenge = get_challenge(authctxt);
 				if (challenge != NULL) {
 					debug("sending challenge '%s'", challenge);
@@ -285,6 +295,7 @@
 					packet_write_wait();
 					continue;
 				}
+			    }
 			}
 			break;
 		case SSH_CMSG_AUTH_TIS_RESPONSE:

Index: openssh/auth2-chall.c
@@ -139,7 +139,7 @@
 }
 
 /*
- * try challenge-reponse, set authctxt->postponed if we have to
+ * try challenge-response, set authctxt->postponed if we have to
  * wait for the response.
  */
 int

Index: openssh/auth2.c
@@ -122,7 +122,7 @@
 
 	x_authctxt = authctxt;		/*XXX*/
 
-	/* challenge-reponse is implemented via keyboard interactive */
+	/* challenge-response is implemented via keyboard interactive */
 	if (options.challenge_response_authentication)
 		options.kbd_interactive_authentication = 1;
 	if (options.pam_authentication_via_kbd_int)
@@ -344,7 +344,7 @@
 		return(0);
 #endif
 #ifdef USE_PAM
-	return auth_pam_password(authctxt->pw, "");
+	return auth_pam_password(authctxt->pw, "", PAM_PROMPT_ECHO_OFF);
 #elif defined(HAVE_OSF_SIA)
 	return 0;
 #else /* !HAVE_OSF_SIA && !USE_PAM */
@@ -369,7 +369,7 @@
 		check_nt_auth(1, authctxt->pw->pw_uid) &&
 #endif
 #ifdef USE_PAM
-	    auth_pam_password(authctxt->pw, password) == 1)
+	    auth_pam_password(authctxt->pw, password, PAM_PROMPT_ECHO_OFF) == 1)
 #elif defined(HAVE_OSF_SIA)
 	    auth_sia_password(authctxt->user, password) == 1)
 #else /* !USE_PAM && !HAVE_OSF_SIA */

Index: openssh/servconf.c
@@ -83,6 +83,7 @@
 	options->password_authentication = -1;
 	options->kbd_interactive_authentication = -1;
 	options->challenge_response_authentication = -1;
+	options->tis_via_pam = -1;
 	options->permit_empty_passwd = -1;
 	options->use_login = -1;
 	options->allow_tcp_forwarding = -1;
@@ -234,7 +235,7 @@
 #ifdef AFS
 	sAFSTokenPassing,
 #endif
-	sChallengeResponseAuthentication,
+	sChallengeResponseAuthentication, sTISviaPAM,
 	sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress,
 	sPrintMotd, sPrintLastLog, sIgnoreRhosts,
 	sX11Forwarding, sX11DisplayOffset,
@@ -286,6 +287,7 @@
 	{ "kbdinteractiveauthentication", sKbdInteractiveAuthentication },
 	{ "challengeresponseauthentication", sChallengeResponseAuthentication },
 	{ "skeyauthentication", sChallengeResponseAuthentication }, /* alias */
+	{ "tisviapam", sTISviaPAM },
 	{ "checkmail", sDeprecated },
 	{ "listenaddress", sListenAddress },
 	{ "printmotd", sPrintMotd },
@@ -626,6 +628,10 @@
 			intptr = &options->challenge_response_authentication;
 			goto parse_flag;
 
+		case sTISviaPAM:
+			intptr = &options->tis_via_pam;
+			goto parse_flag;
+
 		case sPrintMotd:
 			intptr = &options->print_motd;
 			goto parse_flag;

Index: openssh/servconf.h
@@ -94,6 +94,7 @@
 						 * authentication. */
 	int     kbd_interactive_authentication;	/* If true, permit */
 	int     challenge_response_authentication;
+	int	tis_via_pam;			/* Use PAM for TIS? */
 	int     permit_empty_passwd;	/* If false, do not permit empty
 					 * passwords. */
 	int     use_login;	/* If true, login(1) is used */

Index: openssh/sshconnect1.c
@@ -821,7 +821,7 @@
 	char prompt[1024];
 	char *challenge, *response;
 	
-	debug("Doing challenge reponse authentication.");
+	debug("Doing challenge response authentication.");
 	
 	for (i = 0; i < options.number_of_password_prompts; i++) {
 		/* request a challenge */
@@ -849,7 +849,7 @@
 		if (options.cipher == SSH_CIPHER_NONE)
 			log("WARNING: Encryption is disabled! "
 			    "Reponse will be transmitted in clear text.");
-		response = read_passphrase(prompt, 0);
+		response = read_passphrase(prompt, RP_ECHO);
 		if (strcmp(response, "") == 0) {
 			xfree(response);
 			break;

Index: openssh/sshd.8
@@ -379,6 +379,12 @@
 are supported.
 The default is
 .Dq yes .
+.It Cm TISviaPAM
+Specifies whether protocol version 1 challenge response authentication (TIS)
+should be handled via PAM.  This is incompatible with with password
+authentication.
+The default is
+.Dq no .
 .It Cm Ciphers
 Specifies the ciphers allowed for protocol version 2.
 Multiple ciphers must be comma-separated.

Index: openssh/sshd_config
@@ -52,6 +52,9 @@
 
 # Uncomment to disable s/key passwords 
 #ChallengeResponseAuthentication no
+# Do ssh1 TIS authentication (challenge/response) via PAM?
+# ChallengeResponseAuthentication must be set for this to take effect.
+#TISviaPAM no
 
 # Uncomment to enable PAM keyboard-interactive authentication 
 # Warning: enabling this may bypass the setting of 'PasswordAuthentication'

From dboldt at usgs.gov  Wed Oct 10 03:53:50 2001
From: dboldt at usgs.gov (David R Boldt)
Date: Tue, 9 Oct 2001 13:53:50 -0400
Subject: Solaris 2.6, and AFS
Message-ID: <OFA81DD731.84EC32C2-ON85256AE0.00603BCA@er.usgs.gov>

With the help of Jan Iven I have been able to compile openssh-2.9.9p2
on Solaris 2.6 with AFS/kerb4 support using gcc.

./configure --sysconfdir=/etc/ssh --with-tcp-wrappers \
            --with-egd-pool=/var/run/egd-pool \
          --with-kerberos4=/usr/athena --with-afs=/usr/afsws


to do this I modified the resulting Makefile,

from:
CPPFLAGS=-I. -I$(srcdir) -I/usr/local/ssl/include  -I/usr/local/include
-I/usr/athena/include -I/usr/afsws/include $(PATHS) -DHAVE_CONFIG_H

to:
CPPFLAGS=-I. -I$(srcdir) -I/usr/local/ssl/include  -I/usr/athena/include
-I/usr/afsws/include $(PATHS) -DHAVE_CONFIG_H


removed  include <crypt.h>   from file auth-passwd.c


and changed the build

from:
 -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib -L/usr/local/ssl/lib
-L/usr/local/lib -R/usr/local/lib -L/usr/athena/lib -R/usr/athena/lib
-L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv -ldes -lkrb -lwrap
-lz -lsocket -lnsl  -lgen -lcrypto -ldes

to:
 -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib -L/usr/local/ssl/lib
-R/usr/local/lib -L/usr/athena/lib -R/usr/athena/lib -L/usr/afsws/lib -lssh
-lopenbsd-compat -lkafs -lresolv -lkrb -lpam -ldl -lwrap -lz -lsocket -lnsl
-lgen -lcrypto


I am not on the mailing list.

                                          -- David Boldt
                                             <dboldt at usgs.gov>




From bbense at networking.stanford.edu  Wed Oct 10 08:04:28 2001
From: bbense at networking.stanford.edu (Booker C. Bense)
Date: Tue, 9 Oct 2001 15:04:28 -0700 (PDT)
Subject: Solaris 2.6, and AFS
In-Reply-To: <OFA81DD731.84EC32C2-ON85256AE0.00603BCA@er.usgs.gov>
Message-ID: <Pine.GSO.4.33.0110091158300.15721-100000@shred.stanford.edu>

On Tue, 9 Oct 2001, David R Boldt wrote:

> With the help of Jan Iven I have been able to compile openssh-2.9.9p2
> on Solaris 2.6 with AFS/kerb4 support using gcc.
>
> ./configure --sysconfdir=/etc/ssh --with-tcp-wrappers \
>             --with-egd-pool=/var/run/egd-pool \
>           --with-kerberos4=/usr/athena --with-afs=/usr/afsws
>
>

- If you are using kth kerberos4, I would highly recommend that
you just use their interface to afs. i.e.

 --with-kerberos4=/usr/athena --with-afs=/usr/athena

- It's a lot simpler and works just as well.

- Booker C. Bense



From david.batterham at lochard.com.au  Wed Oct 10 13:13:53 2001
From: david.batterham at lochard.com.au (David Batterham)
Date: Wed, 10 Oct 2001 13:13:53 +1000
Subject: OpenSSH solaris: bad return code after exec of remote command
Message-ID: <3BC3BCF1.E03BA37E@lochard.com.au>




Hi OpenSSH developers,

I am using openSSH (now 2.9.9p2, but prob occurs in 2.9p2 also) to execute
commands on a remote machine which outputs data to stdout then pipes it to
another invocation of ssh which connects back to the first machine in the same
way, where it starts a program to read and store the output from the command on
the second machine. I am using the "command" option in the keys file to force
execution of a particular command when that key is used for authentication. 

My problem is this. The remote ssh returns an error code of 255 (using echo $?),
or (-1 in the debug), despite the command executing successfully. about 5-10% of
the time it returns 0. In all cases it "appears" the command completed
successully, and is simply an issue of ssh failing to close the channel cleanly.
My guess is that one side is closing before the other acknowledges and therefore
thinks the channel has been prematurely terminated. 

My questions are: How sure can I be that I am indeed getting all data from the
pipe? How can I accurately determine the exit status of the command (ufsdump)
which is piping data into ssh, regardless of ssh's exit status ? Has anyone else
seen this problem and/or resolved it ?

If more debug would be helpful, please let me know...

Below is the debug from the remote side when it fails:

<snip>
debug1: Remote: Forced command: /les/galaxy/sysadmin/backup/sbin/receiver
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 435 lastkey 12bac0 hint 0
debug1: read PEM private key done: type DSA
debug1: sig size 20 20
debug1: Remote: Forced command: /les/galaxy/sysadmin/backup/sbin/receiver
debug1: ssh-userauth2 successful: method publickey
debug1: fd 5 setting O_NONBLOCK
debug1: fd 7 setting O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: channel request 0: shell
debug1: channel 0: open confirm rwindow 0 rmax 16384
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
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)
debug1: channel_free: channel 0: dettaching channel user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 15.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1


This is the debug when it works:

OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /opt/OBSDssh/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
debug1: Connecting to galaxy [my_ip_was_here] port 22.
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /.ssh/backup-sender type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
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: 135/256
debug1: bits set: 1017/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'galaxy' is known and matches the RSA host key.
debug1: Found key in //.ssh/known_hosts2:1
debug1: bits set: 1027/2049
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: /.ssh/backup-sender
debug1: Remote: Forced command: /les/galaxy/sysadmin/backup/sbin/receiver
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 435 lastkey 12bac0 hint 0
debug1: read PEM private key done: type DSA
debug1: sig size 20 20
debug1: Remote: Forced command: /les/galaxy/sysadmin/backup/sbin/receiver
debug1: ssh-userauth2 successful: method publickey
debug1: fd 5 setting O_NONBLOCK
debug1: fd 7 setting O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: channel request 0: shell
debug1: channel 0: open confirm rwindow 0 rmax 16384
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
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)
debug1: channel_free: channel 0: dettaching channel user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 16.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

Thanks,
Dave


-- 
---------------------------------------------------------------
David Batterham                     PHONE: +61 3 95001017
System Administrator                FAX:   +61 3 95001191
Lochard Pty Ltd                     EMAIL: david at lochard.com.au


From phess at best.com  Wed Oct 10 17:48:40 2001
From: phess at best.com (Patrick Hess)
Date: Wed, 10 Oct 2001 00:48:40 -0700 (PDT)
Subject: Ported OpenSSH 2.9.9p2 to Dynix
In-Reply-To: <20011009092653.T12872@cygbert.vinschen.de> from Corinna Vinschen at "Oct 9, 1 09:26:53 am"
Message-ID: <200110100748.AAA04368@shell5.ba.best.com>

Thanks.  I did that already and apparently I forgot to include that in
the patch that I mailed to the list.  When I get back to work after my holiday
(in a couple weeks) I'll be sure to mail it to the list.  

On the other hand, given that I've included the diffs from the configure
script itself, it would be trivial for one of you to reverse engineer
the changes that I made to the configure script and add those changes to the
configure.in file for the distribution.  Please let me know which way you
would prefer to work this out.

Thanks for the wonderful work with OpenSSH.  It was fairly simple to get this
package running even on a dinosaur like Dynix.  :)  Great work!

			Patrick
	

Corinna Vinschen once said:
> 
> That's not ok as a patch.  You'll have to change configure.in
> to accomodate the new target system.  configure is generated
> from configure.in using autoconf.
> 
> Corinna
> 
> -- 
> Corinna Vinschen
> Cygwin Developer
> Red Hat, Inc.
> mailto:vinschen at redhat.com
> 



From a_ghsek at yahoo.co.in  Wed Oct 10 18:24:53 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 09:24:53 +0100 (BST)
Subject: ssh exit mechanism!
Message-ID: <20011010082453.83671.qmail@web8004.mail.in.yahoo.com>

To whomsoever it may concern,
    I use putty-0.51 as ssh client on windows and
openssh-2.9p2 implementation on RedHat 7.0 Linux as
ssh server. For the client to exit, I expected ssh
client to send SSH_CMSG_EOF to the server and the
server respond with SSH_CMSG_EXITSTATUS and finally
close the connection when the client sends
SSH_CMSG_EXIT_CONFIRMATION. This will effectively end
the server_loop in the server. This would close the
connection in a cleaner way. Although the RFC has
stated that either side may send SSH_MSG_DISCONNECT,
for immediate disconnect, I am surprised that this is
the normal exit method used in putty implementation. 
       I fear that any addition of code after
server_loop, to be done once the connection is closed
by the server might not get called, as it now is
redirected to fatal_cleanup(). 
     Is this normal and do other implementations
follow this?

   And I would also like to know about the ssh
hang-on-exit problem. Why is it necessary to redirect
stdin to /dev/null to prevent this? How does this end
processes running in background?

   Expecting your reply,
   Hari.


____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com


From matthew.seaman at tornadogroup.com  Wed Oct 10 20:09:17 2001
From: matthew.seaman at tornadogroup.com (Matthew Seaman)
Date: Wed, 10 Oct 2001 11:09:17 +0100
Subject: OpenSSH solaris: bad return code after exec of remote command
References: <3BC3BCF1.E03BA37E@lochard.com.au>
Message-ID: <3BC41E4D.CC9CA489@tornadogroup.com>

David Batterham wrote:

> I am using openSSH (now 2.9.9p2, but prob occurs in 2.9p2 also) to execute
> commands on a remote machine which outputs data to stdout then pipes it to
> another invocation of ssh which connects back to the first machine in the same
> way, where it starts a program to read and store the output from the command on
> the second machine. I am using the "command" option in the keys file to force
> execution of a particular command when that key is used for authentication.
> 
> My problem is this. The remote ssh returns an error code of 255 (using echo $?),
> or (-1 in the debug), despite the command executing successfully. about 5-10% of
> the time it returns 0. In all cases it "appears" the command completed
> successully, and is simply an issue of ssh failing to close the channel cleanly.
> My guess is that one side is closing before the other acknowledges and therefore
> thinks the channel has been prematurely terminated.
> 
> My questions are: How sure can I be that I am indeed getting all data from the
> pipe? How can I accurately determine the exit status of the command (ufsdump)
> which is piping data into ssh, regardless of ssh's exit status ? Has anyone else
> seen this problem and/or resolved it ?

Damn.  Synchronicity or what.  We've just been struggling with a similar
problem and I was just about to post a bug report when I saw this
message.

What we've been able to determine:

You'll always get a failure exit code from ssh if the following three
things are true:

i) SSH2 protocol
ii) Using a forced command
iii) No stdin on the client --- ie. using `ssh -n' or
`ssh host commands </dev/null'.

Work around is to use rsa1 keys and SSH1.5 protocol.

Verified using OpenSSH 2.3.0p1, 2.9p1, 2.9.9p2 on Solaris 8.  We'll be
glad to supply more detailed debugging output or whatever on request.

	Matthew

-- 
Matthew Seaman                                              01628 498661

                Abeo, abeo, abeo, actum est, comites!


From markus at openbsd.org  Wed Oct 10 20:37:23 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 10 Oct 2001 12:37:23 +0200
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <3BC41E4D.CC9CA489@tornadogroup.com>; from matthew.seaman@tornadogroup.com on Wed, Oct 10, 2001 at 11:09:17AM +0100
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com>
Message-ID: <20011010123723.B23866@faui02.informatik.uni-erlangen.de>

On Wed, Oct 10, 2001 at 11:09:17AM +0100, Matthew Seaman wrote:
> i) SSH2 protocol
> ii) Using a forced command
> iii) No stdin on the client --- ie. using `ssh -n' or
> `ssh host commands </dev/null'.

i don't see how forced commands should change things here.

but, yes there are issues with getting the return code from the
child in ssh2.

what does
	for i in  4 7 44 77; do
		ssh -n host exit $i
		echo $?
	done
print for you?


From matthew.seaman at tornadogroup.com  Wed Oct 10 21:15:31 2001
From: matthew.seaman at tornadogroup.com (Matthew Seaman)
Date: Wed, 10 Oct 2001 12:15:31 +0100
Subject: OpenSSH solaris: bad return code after exec of remote command
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <20011010123723.B23866@faui02.informatik.uni-erlangen.de>
Message-ID: <3BC42DD3.69C1CBDC@tornadogroup.com>

Markus Friedl wrote:
> 
> On Wed, Oct 10, 2001 at 11:09:17AM +0100, Matthew Seaman wrote:
> > i) SSH2 protocol
> > ii) Using a forced command
> > iii) No stdin on the client --- ie. using `ssh -n' or
> > `ssh host commands </dev/null'.
> 
> i don't see how forced commands should change things here.
> 
> but, yes there are issues with getting the return code from the
> child in ssh2.
> 
> what does
>         for i in  4 7 44 77; do
>                 ssh -n host exit $i
>                 echo $?
>         done
> print for you?

Without a forced command we get 255 consistently:

sw-web-2:~$ ssh-add -l 
1024 e5:0d:e6:b0:c3:26:5f:f7:3d:f6:28:1e:8a:cc:09:98
/export/home/matthew/.ssh/id_dsa (DSA)
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
255
255
255
255
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
255
255
255
255
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
255
255
255
255
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
255
255
255
255

With a forced command (/bin/df /tmp) we seem to get either 255 or
occasionally 0:

sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
/tmp               (swap              ): 9723200 blocks   437218 files
255
/tmp               (swap              ): 9723200 blocks   437218 files
255
/tmp               (swap              ): 9723200 blocks   437218 files
0
/tmp               (swap              ): 9723200 blocks   437218 files
255
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
/tmp               (swap              ): 9723200 blocks   437218 files
255
/tmp               (swap              ): 9723152 blocks   437218 files
0
/tmp               (swap              ): 9723152 blocks   437218 files
255
/tmp               (swap              ): 9723200 blocks   437218 files
255
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
/tmp               (swap              ): 9723152 blocks   437218 files
255
/tmp               (swap              ): 9723104 blocks   437218 files
255
/tmp               (swap              ): 9723200 blocks   437218 files
255
/tmp               (swap              ): 9723200 blocks   437218 files
255
sw-web-2:~$ for i in 4 7 44 77 ; do ssh -n sw-web-1 exit $i; echo $?;
done
/tmp               (swap              ): 9723120 blocks   437218 files
0
/tmp               (swap              ): 9723168 blocks   437218 files
255
/tmp               (swap              ): 9723168 blocks   437218 files
255
/tmp               (swap              ): 9723184 blocks   437218 files
255

	Cheers,

	Matthew

-- 
Matthew Seaman                                              01628 498661

                Abeo, abeo, abeo, actum est, comites!


From a_ghsek at yahoo.co.in  Wed Oct 10 23:48:10 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 14:48:10 +0100 (BST)
Subject: sftp localhost exits after authentication?
Message-ID: <20011010134810.35608.qmail@web8007.mail.in.yahoo.com>

Hi,
  I use openssh-2.9p2 on a LynxOS i386 system. The ssh
and scp clients work fine. Even sftp from other Linux
systems works. But, if I make sftp to the localhost
(LynxOS), the authentication succeeds, prints sftp>
prompt and then exits. I don't know why this happens.
I have not set the euid of ssh program to root as it
does not work in LynxOS (may be problem with saved
ids). Might this be a problem. I have attached the
debug output of the client program. 
Can I expect some help,
Hari. 

bash-2.02$ sftp -v hari at localhost
Connecting to localhost...
debug1: SSH args "ssh -l hari -v localhost -s
-oForwardX11=no -oForwardAgent=no -oProtocol=2 sftp"
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL
0x0090600f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 7 geteuid 7 anon 1
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/hari/.ssh/id_rsa type -1
debug1: identity file /home/hari/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
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: 144/256
debug1: bits set: 1006/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Forcing accepting of host key for
loopback/localhost.
debug1: bits set: 1007/2049
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 privkey: /home/hari/.ssh/id_rsa
debug1: try privkey: /home/hari/.ssh/id_dsa
debug1: next auth method to try is password
hari at localhost's password:
debug1: ssh-userauth2 successful: method password
debug1: fd 5 setting O_NONBLOCK
debug1: fd 6 IS O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Sending subsystem: sftp
debug1: channel 0: open confirm rwindow 0 rmax 16384
sftp>
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
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)

debug1: channel_free: channel 0: dettaching channel
user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes
in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0,
stderr 0.0
debug1: Exit status 0
bash-2.02$


____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com


From abush at microcenter.com  Thu Oct 11 00:19:52 2001
From: abush at microcenter.com (Aaron Bush)
Date: Wed, 10 Oct 2001 10:19:52 -0400
Subject: OpenSSH solaris: bad return code after exec of remote command
References: <3BC3BCF1.E03BA37E@lochard.com.au>
Message-ID: <3BC45908.E3FD2153@mail.microcenter.com>

David Batterham wrote:
> 
> My problem is this. The remote ssh returns an error code of 255 (using echo $?),
> or (-1 in the debug), despite the command executing successfully. about 5-10% of
> the time it returns 0. In all cases it "appears" the command completed
> successully, and is simply an issue of ssh failing to close the channel cleanly.
> My guess is that one side is closing before the other acknowledges and therefore
> thinks the channel has been prematurely terminated.

I too have had this problem.  Using 2.9p2 a call such as:
$ ssh host "rm file"
will sometimes return 255 and other times return 0.
when the return value is not 0 i ssh back to host and confirm that the
file is 'really' removed, and in all cases the file had been removed.

-ab


From a_ghsek at yahoo.co.in  Thu Oct 11 00:22:43 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 15:22:43 +0100 (BST)
Subject: openssh on LynxOS issues!
Message-ID: <20011010142243.7695.qmail@web8005.mail.in.yahoo.com>

Hi,
1.  Does ssh, scp and sftp client programs work on
LynxOS? I use openssh-2.9p2 on a LynxOS i386 system.
The ssh and scp clients work fine. Even sftp from
other Linux systems works. But, if I make sftp to the
localhost (LynxOS), the authentication succeeds,
prints sftp> prompt and then exits. I don't know why
this happens. I have not set the euid of ssh program
to root as it does not work in LynxOS (may be problem
with saved ids). Might this be a problem. Does it work
for anyone (sftp localhost)?

2.  Does anyone use ssh client with seteuid to root?
and it still works? or is there a problem with LynxOS
that seteuid() doesn't work with _POSIX_SAVED_IDS?

3.  One more problem. sshd run on LynxOS and ssh
client from Linux system. ssh client hangs on exit.
$ssh hari at lynx (From Linux)
password:
lynx>...
lynx>exit
hangs ......
    I don't think it is the regular hang-on-exit bug,
because there are no background processes running, I
suppose, and I get this hang 90% of time. Ofcourse,
lynx> exit > /dev/null < /dev/null 2>&1
makes it clean, but I want to make sure why this
happens. Does anyone have this problem in your LynxOS
installation? 

4. The TERM environment variable remains xterm.
$echo $TERM
xterm
$ssh hari at lynx  (From Linux)
Password:
lynx>echo $TERM
xterm
lynx>
How to set TERM to vt100at on login.
I hope you do not have problem here!

5. One strange issue. I compiled openssh-2.9p2 on
Redhat 7.0 Linux system. When the compiled server is
used and when I call ssh, prompts for password and
even if I give correct password, says incorrect
password. Ever got this trouble?

Can I expect some help from someone,
Hari. 



____________________________________________________________
Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com


From a_ghsek at yahoo.co.in  Thu Oct 11 00:35:15 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 15:35:15 +0100 (BST)
Subject: LynxOS: ssh client hang on exit?
Message-ID: <20011010143515.39855.qmail@web8007.mail.in.yahoo.com>

Hi,
  I use openssh-2.9p2 on LynxOS i386 system. sshd runs
on LynxOS and ssh client on Redhat 7.0 Linux system
(openssh-2.9p2 ssh client). The ssh client hangs on
exit 90% of times. I don't think this is the usual
hang-on-exit bug, because, there are no background
processes running, I suppose. I attach the server
debug messages.
$ssh -V hari at lynx (From Linux)
...
Password:
...
lynx>
lynx>exit
debug: callback start
debug: client_input_channel_req: rtype exit-status
reply 0
debug: callback done
logout

<HANGS>

server debug messages:
lynx#sshd -d
...
Accepted password for hari from 192.168.0.126 port
1022 ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan
0 win 32768 max 4096
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0
request pty-req reply 0
debug1: session_pty_req: session 0 alloc /dev/ttyp1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0
request x11-req reply 0
debug1: X11 forwarding disabled in server
configuration file.
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0
request shell reply 0
debug1: fd 8 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 19
debug1: session_exit_message: session 0 channel 0 pid
19
debug1: session_exit_message: release channel 0
debug1: channel 0: write failed
debug1: channel 0: output open -> closed
debug1: channel 0: close_write
debug1: session_pty_cleanup: session 0 release
/dev/ttyp1
debug1: session_free: session 0 pid 19

<HANGS>
_______________
Ofcourse,
lynx>exit > /dev/null < /dev/null 2>&1
exits clean.

Can anyone help me as to why this happens and the way
out,
Hari.


____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com


From mouring at etoh.eviladmin.org  Thu Oct 11 00:38:25 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 10 Oct 2001 09:38:25 -0500 (CDT)
Subject: openssh on LynxOS issues!
In-Reply-To: <20011010142243.7695.qmail@web8005.mail.in.yahoo.com>
Message-ID: <Pine.BSO.4.33.0110100937380.344-100000@etoh.eviladmin.org>


> 5. One strange issue. I compiled openssh-2.9p2 on
> Redhat 7.0 Linux system. When the compiled server is
> used and when I call ssh, prompts for password and
> even if I give correct password, says incorrect
> password. Ever got this trouble?
>

Did you compile with --with-pam or if not then with --with-md5-passwords?

- Ben



From a_ghsek at yahoo.co.in  Thu Oct 11 00:42:48 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 15:42:48 +0100 (BST)
Subject: openssh on LynxOS issues!
In-Reply-To: <Pine.BSO.4.33.0110100937380.344-100000@etoh.eviladmin.org>
Message-ID: <20011010144248.32057.qmail@web8005.mail.in.yahoo.com>

 --- mouring at etoh.eviladmin.org wrote: > 
> > 5. One strange issue. I compiled openssh-2.9p2 on
> > Redhat 7.0 Linux system. When the compiled server
> is
> > used and when I call ssh, prompts for password and
> > even if I give correct password, says incorrect
> > password. Ever got this trouble?
> >
> 
> Did you compile with --with-pam or if not then with
> --with-md5-passwords?
> 
> - Ben
>  

I did not specify any option during configure.
I assume then it is with PAM support on Linux system.
-Hari

____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com


From a_ghsek at yahoo.co.in  Thu Oct 11 00:50:07 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 15:50:07 +0100 (BST)
Subject: openssh on LynxOS issues!
In-Reply-To: <Pine.BSO.4.33.0110100943170.344-100000@etoh.eviladmin.org>
Message-ID: <20011010145007.41090.qmail@web8007.mail.in.yahoo.com>

   Thanks for that help! and I will sure try this and
that should work. As for other issues - any help,
Hari.


 --- mouring at etoh.eviladmin.org wrote: > 
> If you did not tell OpenSSH to use pam.. it will
> default all the way back
> to DES hash passwords.. Redhat does MD5 hashed
> passwords.. So you need to
> use one of those two options.
> 
> - Ben
> 
> On Wed, 10 Oct 2001, [iso-8859-1] hari sekar wrote:
> 
> >  --- mouring at etoh.eviladmin.org wrote: >
> > > > 5. One strange issue. I compiled openssh-2.9p2
> on
> > > > Redhat 7.0 Linux system. When the compiled
> server
> > > is
> > > > used and when I call ssh, prompts for password
> and
> > > > even if I give correct password, says
> incorrect
> > > > password. Ever got this trouble?
> > > >
> > >
> > > Did you compile with --with-pam or if not then
> with
> > > --with-md5-passwords?
> > >
> > > - Ben
> > >
> >
> > I did not specify any option during configure.
> > I assume then it is with PAM support on Linux
> system.
> > -Hari
> >
> >
> 

____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com


From dboldt at usgs.gov  Thu Oct 11 00:55:55 2001
From: dboldt at usgs.gov (David R Boldt)
Date: Wed, 10 Oct 2001 10:55:55 -0400
Subject: Solaris 2.6, and AFS
Message-ID: <OFEABE1631.EACCA27A-ON85256AE1.0051BD00@er.usgs.gov>


Booker,

thanks for the tip, I will give it a spin the next time I
compile openssh.

                                          -- David Boldt
                                             <dboldt at usgs.gov>



                                                                                             
                    "Booker C. Bense"                                                        
                    <bbense at networking.sta        To:     David R Boldt <dboldt at usgs.gov>    
                    nford.edu>                    cc:     <openssh-unix-dev at mindrot.org>     
                                                  Subject:     Re: Solaris 2.6, and AFS      
                    10/09/01 06:04 PM                                                        
                                                                                             
                                                                                             



On Tue, 9 Oct 2001, David R Boldt wrote:

> With the help of Jan Iven I have been able to compile openssh-2.9.9p2
> on Solaris 2.6 with AFS/kerb4 support using gcc.
>
> ./configure --sysconfdir=/etc/ssh --with-tcp-wrappers \
>             --with-egd-pool=/var/run/egd-pool \
>           --with-kerberos4=/usr/athena --with-afs=/usr/afsws
>
>

- If you are using kth kerberos4, I would highly recommend that
you just use their interface to afs. i.e.

 --with-kerberos4=/usr/athena --with-afs=/usr/athena

- It's a lot simpler and works just as well.

- Booker C. Bense







From Nicolas.Williams at ubsw.com  Thu Oct 11 01:04:27 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 10 Oct 2001 11:04:27 -0400
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <20011010123723.B23866@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Oct 10, 2001 at 12:37:23PM +0200
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <20011010123723.B23866@faui02.informatik.uni-erlangen.de>
Message-ID: <20011010110425.T5739@sm2p1386swk.wdr.com>

Perhaps wait_status ought to be initialized. Try changing serverloop.c
and initialize wait_status to, say, 51. Then try it again.

Nico


On Wed, Oct 10, 2001 at 12:37:23PM +0200, Markus Friedl wrote:
> On Wed, Oct 10, 2001 at 11:09:17AM +0100, Matthew Seaman wrote:
> > i) SSH2 protocol
> > ii) Using a forced command
> > iii) No stdin on the client --- ie. using `ssh -n' or
> > `ssh host commands </dev/null'.
> 
> i don't see how forced commands should change things here.
> 
> but, yes there are issues with getting the return code from the
> child in ssh2.
> 
> what does
> 	for i in  4 7 44 77; do
> 		ssh -n host exit $i
> 		echo $?
> 	done
> print for you?
--

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  Thu Oct 11 01:12:07 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 10 Oct 2001 17:12:07 +0200
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <20011010110425.T5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Oct 10, 2001 at 11:04:27AM -0400
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <20011010123723.B23866@faui02.informatik.uni-erlangen.de> <20011010110425.T5739@sm2p1386swk.wdr.com>
Message-ID: <20011010171207.A16684@faui02.informatik.uni-erlangen.de>

On Wed, Oct 10, 2001 at 11:04:27AM -0400, Nicolas Williams wrote:
> Perhaps wait_status ought to be initialized. Try changing serverloop.c
> and initialize wait_status to, say, 51. Then try it again.

no.


From markus at openbsd.org  Thu Oct 11 01:17:51 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 10 Oct 2001 17:17:51 +0200
Subject: missing exitcode for remote commands.
In-Reply-To: <3BC3BCF1.E03BA37E@lochard.com.au>; from david.batterham@lochard.com.au on Wed, Oct 10, 2001 at 01:13:53PM +1000
References: <3BC3BCF1.E03BA37E@lochard.com.au>
Message-ID: <20011010171751.B16684@faui02.informatik.uni-erlangen.de>

it's easy to reproduce your problem:

ssh -n localhost 'echo x; exec > /dev/null 2>&1; sleep 3; exit 5;'

will always have an exit status of 255 (the default for the client)
instead of 5 because the sshd sends a CHANNEL CLOSE message (since
all pipes are closed) before the shell exits. so a "exit-status"
messages cannot be sent because the channel is gone at this point.

i'm not sure how to delay the CLOSE message.


From a_ghsek at yahoo.co.in  Thu Oct 11 01:34:45 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 10 Oct 2001 16:34:45 +0100 (BST)
Subject: openssh on LynxOS issues! - Changes and addons.
Message-ID: <20011010153445.21002.qmail@web8004.mail.in.yahoo.com>

Hi,
  With reference to my previous mail:
1.  I use openssh-2.9p2 on a LynxOS i386 system. The
ssh and scp clients work fine. Even sftp from other
Linux systems works. But, if I run the sftp client in
LynxOS to localhost (LynxOS) or remote sshd in Linux,
the authentication succeeds, prints sftp> prompt and
then exits. I don't know why this happens. The problem
is with the sftp client program in LynxOS. Does it
work for anyone (sftp client program in LynxOS)?

2.  Does anyone use ssh client with seteuid to root?
and it still works? or is there a problem with LynxOS
that seteuid() doesn't work with _POSIX_SAVED_IDS?

3.  One more problem. sshd run on LynxOS and ssh
client from Linux system. ssh client hangs on exit.
$ssh hari at lynx (From Linux)
password:
lynx>...
lynx>exit
hangs ......
    I don't think it is the regular hang-on-exit bug,
because there are no background processes running, I
suppose, and I get this hang 90% of time. Ofcourse,
lynx> exit > /dev/null < /dev/null 2>&1
makes it clean, but I want to make sure why this
happens. Do you have this problem in your LynxOS
installation? 

4. The TERM environment variable remains xterm.
$echo $TERM
xterm
$ssh hari at lynx  (From Linux)
Password:
lynx>echo $TERM
xterm
lynx>
How to set TERM to vt100at on login.
I hope you do not have problem here!

5. Addon: In LynxOS, sshd writes to utmp and wtmp on
login, but does not remove entries from utmp on
logout. So, lynx> who
displays the user even after logout. Interestingly,
the  size of utmp and wtmp files change (increase)
after login and logout, i.e., the server writes to
them. Then, is it the way the OS interprets it
different, though the sshd server does its job
perfect. Normal telnet programs to Lynx system do not
alter the size of the utmp file.

NOTE: " One strange issue. I compiled openssh-2.9p2 on
Redhat 7.0 Linux system. When the compiled server is
used and when I call ssh, prompts for password and
even if I give correct password, says incorrect
password. " - This has been solved thanks to Ben.


Can I expect some help from someone,
Hari. 




____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com


From Kathy.Tablan at McKesson.com  Thu Oct 11 02:19:17 2001
From: Kathy.Tablan at McKesson.com (Tablan, Kathy)
Date: Wed, 10 Oct 2001 09:19:17 -0700
Subject: SSH error
Message-ID: <B73F7104E5B44F468AB0FC95DF7884423B4F38@pste0050.mckesson.com>

Hello,

I am working with a customer that has SSH F-Secure (NT windows).  We
currently have OPENSSH installed in our unix server.  We are trying to copy
a file from our unix box to an NT windows and received the following error:


	Remote: Failed to lauch child process!


How can we resolve this problem.

Thanks, 

Kathy Tablan


Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.





From ed at UDel.Edu  Thu Oct 11 05:32:40 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 10 Oct 2001 15:32:40 -0400 (EDT)
Subject: ssh hangs instead of exiting
In-Reply-To: <20011008231241.B12897@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.SOL.4.30.0110101530170.26950-100000@mahler.udel.edu>

On Mon, 8 Oct 2001, Markus Friedl wrote:

> Date: Mon, 8 Oct 2001 23:12:41 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Subject: Re: ssh hangs instead of exiting
>
> On Mon, Oct 08, 2001 at 05:07:12PM -0400, Ed Phillips wrote:
> > On Mon, 8 Oct 2001, Markus Friedl wrote:
> >
> > > Date: Mon, 8 Oct 2001 22:55:56 +0200
> > > From: Markus Friedl <markus at openbsd.org>
> > > To: Ed Phillips <ed at UDel.Edu>
> > > Subject: Re: ssh hangs instead of exiting
> > >
> > > do you have ssh -vvv output?
> >
> > For some reason, "-vvv" is unacceptable to ssh v2.9p2 so I separated them
> > out as 3 separate args and it seems to work... here's the output:
>
> ok, could be fixed in 2.9.9, but i don't remember, in any
> case please try the recent release :) thanks -m

I'm using cc: WorkShop Compilers 5.0 98/12/15 C 5.0 to compile v2.9.9p2.

I get the following error during compilation of v2.9.9p2:

...
cc -g -I. -I. -I. -I/opt/openssl-0.9.6b/include  -I/usr/local/include
-DETCDIR=\"/opt/openssh-2.9.9p2/etc\"
-D_PATH_SSH_PROGRAM=\"/opt/openssh-2.9.9p2/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/openssh-2.9.9p2/libexec/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/opt/openssh-2.9.9p2/libexec/sftp-server\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c session.c
"session.c", line 628: identifier redeclared: do_pre_login
        current : static function(pointer to struct Session {int used, int
self, pointer to struct passwd {..} pw, pointer to struct Authctxt ...
        previous: function() returning int : "session.c", line 581
cc: acomp failed for session.c
*** Error code 2
make: Fatal error: Command failed for target `session.o'

Any ideas?

	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  Thu Oct 11 05:55:46 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 10 Oct 2001 14:55:46 -0500 (CDT)
Subject: SSH error
In-Reply-To: <B73F7104E5B44F468AB0FC95DF7884423B4F38@pste0050.mckesson.com>
Message-ID: <Pine.BSO.4.33.0110101455080.30118-100000@etoh.eviladmin.org>


How are you trying to 'copy a file'?  Can we see a scp -v -v -v or a sftp
-v -v -v ?

- Ben

On Wed, 10 Oct 2001, Tablan, Kathy wrote:

> Hello,
>
> I am working with a customer that has SSH F-Secure (NT windows).  We
> currently have OPENSSH installed in our unix server.  We are trying to copy
> a file from our unix box to an NT windows and received the following error:
>
>
> 	Remote: Failed to lauch child process!
>
>
> How can we resolve this problem.
>
> Thanks,
>
> Kathy Tablan
>
>
> Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
>
>
>
>



From pmenage at ensim.com  Thu Oct 11 05:56:58 2001
From: pmenage at ensim.com (Paul Menage)
Date: Wed, 10 Oct 2001 12:56:58 -0700
Subject: OpenSSH solaris: bad return code after exec of remote command 
In-Reply-To: Your message of "Wed, 10 Oct 2001 13:13:53 +1000."
             <3BC3BCF1.E03BA37E@lochard.com.au> 
Message-ID: <E15rPTO-0006Wx-00@pmenage-dt.ensim.com>


> My problem is this. The remote ssh returns an error code of 255 (using
>echo $?), or (-1 in the debug), despite the command executing
>successfully. about 5-10% of the time it returns 0. In all cases it
>"appears" the command completed successully, and is simply an issue of
>ssh failing to close the channel cleanly.

We've seen this intermittently on Windows - we put it down to bugs in
cygwin, as executing the same scripts (on the server) on Solaris or
Linux has never produced the problem for us.

Paul




From markus at openbsd.org  Thu Oct 11 06:22:50 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 10 Oct 2001 22:22:50 +0200
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <3BC3BCF1.E03BA37E@lochard.com.au>; from david.batterham@lochard.com.au on Wed, Oct 10, 2001 at 01:13:53PM +1000
References: <3BC3BCF1.E03BA37E@lochard.com.au> <20011010171751.B16684@faui02.informatik.uni-erlangen.de> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC45908.E3FD2153@mail.microcenter.com> <3BC3BCF1.E03BA37E@lochard.com.au>
Message-ID: <20011010222250.A2472@faui02.informatik.uni-erlangen.de>

I wrote:

> it's easy to reproduce your problem:
> 
> ssh -n localhost 'echo x; exec > /dev/null 2>&1; sleep 3; exit 5;'

could you please try this diff against the current CVS

hope everything else stil works...

-m

Index: channels.c
===================================================================
RCS file: /cvs/openssh_cvs/channels.c,v
retrieving revision 1.110
diff -u -r1.110 channels.c
--- channels.c	2001/10/10 05:14:38	1.110
+++ channels.c	2001/10/10 20:26:54
@@ -331,10 +331,6 @@
 	debug3("channel_free: status: %s", s);
 	xfree(s);
 
-	if (c->detach_user != NULL) {
-		debug("channel_free: channel %d: detaching channel user", c->self);
-		c->detach_user(c->self, NULL);
-	}
 	if (c->sock != -1)
 		shutdown(c->sock, SHUT_RDWR);
 	channel_close_fds(c);
@@ -1520,6 +1516,30 @@
 		channel_handler_init_15();
 }
 
+/* gc dead channels */
+static void
+channel_garbage_collect(Channel *c)
+{
+	if (c == NULL)
+		return;
+	debug("channel %d: gc called", c->self);
+	if (c->detach_user != NULL) {
+		if (!chan_is_dead(c, 0))
+			return;
+		debug("channel %d: gc: notify user", c->self);
+		c->detach_user(c->self, NULL);
+		/* if we still have a callback */
+		if (c->detach_user != NULL)
+			return;
+		debug("channel %d: gc: user removed callback", c->self);
+	}
+	debug("channel %d: gc: after notify user", c->self);
+	if (!chan_is_dead(c, 1))
+		return;
+	debug("channel %d: garbage collecting", c->self);
+	channel_free(c);
+}
+
 static void
 channel_handler(chan_fn *ftab[], fd_set * readset, fd_set * writeset)
 {
@@ -1537,24 +1557,7 @@
 			continue;
 		if (ftab[c->type] != NULL)
 			(*ftab[c->type])(c, readset, writeset);
-		if (chan_is_dead(c)) {
-			/*
-			 * we have to remove the fd's from the select mask
-			 * before the channels are free'd and the fd's are
-			 * closed
-			 */
-			if (c->wfd != -1)
-				FD_CLR(c->wfd, writeset);
-			if (c->rfd != -1)
-				FD_CLR(c->rfd, readset);
-			if (c->efd != -1) {
-				if (c->extended_usage == CHAN_EXTENDED_READ)
-					FD_CLR(c->efd, readset);
-				if (c->extended_usage == CHAN_EXTENDED_WRITE)
-					FD_CLR(c->efd, writeset);
-			}
-			channel_free(c);
-		}
+		channel_garbage_collect(c);
 	}
 }
 
@@ -1625,7 +1628,7 @@
 		if (compat20 &&
 		    (c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD))) {
 			/* XXX is this true? */
-			debug2("channel %d: no data after CLOSE", c->self);
+			debug3("channel %d: will not send data after CLOSE", c->self);
 			continue;
 		}
 
Index: channels.h
===================================================================
RCS file: /cvs/openssh_cvs/channels.h,v
retrieving revision 1.41
diff -u -r1.41 channels.h
--- channels.h	2001/10/10 05:14:39	1.41
+++ channels.h	2001/10/10 20:26:54
@@ -214,7 +214,7 @@
 
 /* channel close */
 
-int	 chan_is_dead(Channel *);
+int	 chan_is_dead(Channel *, int);
 void	 chan_mark_dead(Channel *);
 void 	 chan_init_iostates(Channel *);
 void	 chan_init(void);
Index: clientloop.c
===================================================================
RCS file: /cvs/openssh_cvs/clientloop.c,v
retrieving revision 1.65
diff -u -r1.65 clientloop.c
--- clientloop.c	2001/09/18 05:51:14	1.65
+++ clientloop.c	2001/10/10 20:26:57
@@ -753,6 +753,7 @@
 	if (id != session_ident)
 		error("client_channel_closed: id %d != session_ident %d",
 		    id, session_ident);
+	channel_cancel_cleanup(id);
 	session_closed = 1;
 	if (in_raw_mode())
 		leave_raw_mode();
Index: nchan.c
===================================================================
RCS file: /cvs/openssh_cvs/nchan.c,v
retrieving revision 1.28
diff -u -r1.28 nchan.c
--- nchan.c	2001/09/20 19:33:33	1.28
+++ nchan.c	2001/10/10 20:26:58
@@ -432,7 +432,7 @@
 }
 
 int
-chan_is_dead(Channel *c)
+chan_is_dead(Channel *c, int send)
 {
 	if (c->type == SSH_CHANNEL_ZOMBIE) {
 		debug("channel %d: zombie", c->self);
@@ -461,7 +461,14 @@
 		       "read": "write");
 	} else {
 		if (!(c->flags & CHAN_CLOSE_SENT)) {
-			chan_send_close2(c);
+			if (send) {
+				chan_send_close2(c);
+			} else {
+				if (c->flags & CHAN_CLOSE_RCVD) {
+					debug("channel %d: XXX almost dead", c->self);
+					return 1;
+				}
+			}
 		}
 		if ((c->flags & CHAN_CLOSE_SENT) &&
 		    (c->flags & CHAN_CLOSE_RCVD)) {
Index: serverloop.c
===================================================================
RCS file: /cvs/openssh_cvs/serverloop.c,v
retrieving revision 1.80
diff -u -r1.80 serverloop.c
--- serverloop.c	2001/10/10 05:14:39	1.80
+++ serverloop.c	2001/10/10 20:26:59
@@ -208,9 +208,6 @@
 		max_time_milliseconds = options.client_alive_interval * 1000;
 	}
 
-	/* When select fails we restart from here. */
-retry_select:
-
 	/* Allocate and update select() masks for channel descriptors. */
 	channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, 0);
 
@@ -275,10 +272,11 @@
 	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
 
 	if (ret == -1) {
+		memset(*readsetp, 0, *maxfdp);
+		memset(*writesetp, 0, *maxfdp);
 		if (errno != EINTR)
 			error("select: %.100s", strerror(errno));
-		else
-			goto retry_select;
+		debug("XXX select: %.100s", strerror(errno));
 	}
 	if (ret == 0 && client_alive_scheduled)
 		client_alive_check();
@@ -668,13 +666,30 @@
 	/* NOTREACHED */
 }
 
+static void
+collect_children(void)
+{
+	pid_t pid;
+	sigset_t oset, nset;
+	int status;
+
+	/* block SIGCHLD while we check for dead children */
+	sigemptyset(&nset);
+	sigaddset(&nset, SIGCHLD);
+	sigprocmask(SIG_BLOCK, &nset, &oset);
+	if (child_terminated) {
+		while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
+			session_close_by_pid(pid, status);
+		child_terminated = 0;
+	}
+	sigprocmask(SIG_SETMASK, &oset, NULL);
+}
+
 void
 server_loop2(Authctxt *authctxt)
 {
 	fd_set *readset = NULL, *writeset = NULL;
-	int rekeying = 0, max_fd, status, nalloc = 0;
-	pid_t pid;
-	sigset_t oset, nset;
+	int rekeying = 0, max_fd, nalloc = 0;
 
 	debug("Entering interactive session for SSH2.");
 
@@ -698,16 +713,7 @@
 		wait_until_can_do_something(&readset, &writeset, &max_fd,
 		    &nalloc, 0);
 
-		/* block SIGCHLD while we check for dead children */
-		sigemptyset(&nset);
-		sigaddset(&nset, SIGCHLD);
-		sigprocmask(SIG_BLOCK, &nset, &oset);
-		if (child_terminated) {
-			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
-				session_close_by_pid(pid, status);
-			child_terminated = 0;
-		}
-		sigprocmask(SIG_SETMASK, &oset, NULL);
+		collect_children();
 		if (!rekeying)
 			channel_after_select(readset, writeset);
 		process_input(readset);
@@ -715,6 +721,8 @@
 			break;
 		process_output(writeset);
 	}
+	collect_children();
+
 	if (readset)
 		xfree(readset);
 	if (writeset)
@@ -722,11 +730,6 @@
 
 	/* free all channels, no more reads and writes */
 	channel_free_all();
-
-	/* collect remaining dead children, XXX not necessary? */
-	mysignal(SIGCHLD, SIG_DFL);
-	while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
-		session_close_by_pid(pid, status);
 
 	/* close remaining sessions, e.g remove wtmp entries */
 	session_close_all();
Index: session.c
===================================================================
RCS file: /cvs/openssh_cvs/session.c,v
retrieving revision 1.152
diff -u -r1.152 session.c
--- session.c	2001/10/10 05:14:39	1.152
+++ session.c	2001/10/10 20:27:03
@@ -1961,18 +1961,15 @@
 		debug("session_close_by_channel: no session for channel %d", id);
 		return;
 	}
-	/* disconnect channel */
-	channel_cancel_cleanup(s->chanid);
-	s->chanid = -1;
-
-	debug("session_close_by_channel: channel %d kill %d", id, s->pid);
+	debug("session_close_by_channel: channel %d child %d", id, s->pid);
 	if (s->pid != 0) {
-		/* notify child */
-		if (kill(s->pid, SIGHUP) < 0)
-			error("session_close_by_channel: kill %d: %s",
-			    s->pid, strerror(errno));
+		debug("session_close_by_channel: channel %d: has child", id);
+		return;
 	}
+	channel_cancel_cleanup(s->chanid);
+	s->chanid = -1;
 	session_close(s);
+	return;
 }
 
 void


From Nicolas.Williams at ubsw.com  Thu Oct 11 06:37:35 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 10 Oct 2001 16:37:35 -0400
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <3BC41E4D.CC9CA489@tornadogroup.com>; from matthew.seaman@tornadogroup.com on Wed, Oct 10, 2001 at 11:09:17AM +0100
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com>
Message-ID: <20011010163734.U5739@sm2p1386swk.wdr.com>

On Wed, Oct 10, 2001 at 11:09:17AM +0100, Matthew Seaman wrote:
> Damn.  Synchronicity or what.  We've just been struggling with a similar
> problem and I was just about to post a bug report when I saw this
> message.
> 
> What we've been able to determine:
> 
> You'll always get a failure exit code from ssh if the following three
> things are true:
> 
> i) SSH2 protocol
> ii) Using a forced command
> iii) No stdin on the client --- ie. using `ssh -n' or
> `ssh host commands </dev/null'.

Note that the "or" clause of (iii) above conflicts with (ii) -- can you
clarify?

I've run into compiler bugs often lately. Check that as well -- i.e.,
rebuild using a different compiler, see what happens.

But, I'm testing this now, and here's what I found:

 - ssh -n -2 host exit $(print $((RANDOM % 91)) |tee /dev/tty) ; echo $?

   (with forced command="exit $SSH_ORIGINAL_COMMAND" and RSA keys):

    - from Solaris 2.6 to Solaris 2.6 consistently works
    - from Solaris 2.6 to Solaris 8 consistently works
    - from Solaris 8 to Solaris 2.6 consistently fails (exit code == 255)

On Solaris 8 I'm using the same binaries as on 2.6, built natively on
2.6. Perhaps therein lies the problem (I hope not).

> Work around is to use rsa1 keys and SSH1.5 protocol.
> 
> Verified using OpenSSH 2.3.0p1, 2.9p1, 2.9.9p2 on Solaris 8.  We'll be
> glad to supply more detailed debugging output or whatever on request.



> 	Matthew
> 
> -- 
> Matthew Seaman                                              01628 498661
> 
>                 Abeo, abeo, abeo, actum est, comites!


Nico
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



From Kathy.Tablan at McKesson.com  Thu Oct 11 06:45:19 2001
From: Kathy.Tablan at McKesson.com (Tablan, Kathy)
Date: Wed, 10 Oct 2001 13:45:19 -0700
Subject: SSH error
Message-ID: <B73F7104E5B44F468AB0FC95DF7884423B4F42@pste0050.mckesson.com>

Yes we are trying to copy a file. We are using command scp.



Kathy



-----Original Message-----
From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
Sent: Wednesday, October 10, 2001 12:56 PM
To: Tablan, Kathy
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: SSH error




How are you trying to 'copy a file'?  Can we see a scp -v -v -v or a sftp

-v -v -v ?



- Ben



On Wed, 10 Oct 2001, Tablan, Kathy wrote:



> Hello,

>

> I am working with a customer that has SSH F-Secure (NT windows).  We

> currently have OPENSSH installed in our unix server.  We are trying to
copy

> a file from our unix box to an NT windows and received the following
error:

>

>

> 	Remote: Failed to lauch child process!

>

>

> How can we resolve this problem.

>

> Thanks,

>

> Kathy Tablan

>

>

> Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

>

>

>

>

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.





From Nicolas.Williams at ubsw.com  Thu Oct 11 06:47:18 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 10 Oct 2001 16:47:18 -0400
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <20011010163734.U5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Oct 10, 2001 at 04:37:35PM -0400
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <20011010163734.U5739@sm2p1386swk.wdr.com>
Message-ID: <20011010164717.V5739@sm2p1386swk.wdr.com>

On Wed, Oct 10, 2001 at 04:37:35PM -0400, Nicolas Williams wrote:
> But, I'm testing this now, and here's what I found:
> 
>  - ssh -n -2 host exit $(print $((RANDOM % 91)) |tee /dev/tty) ; echo $?
> 
>    (with forced command="exit $SSH_ORIGINAL_COMMAND" and RSA keys):
> 

That should read:

 - ssh -n -2 host $(print $((RANDOM % 255)) |tee /dev/tty) ; echo $?

   (with forced command="exit $SSH_ORIGINAL_COMMAND" and RSA keys):

When this works you get two lines of output, the first being a number
0-254 and the second matching the first. When it doesn't work then the
second line is "255."

Nico
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



From mouring at etoh.eviladmin.org  Thu Oct 11 06:51:19 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 10 Oct 2001 15:51:19 -0500 (CDT)
Subject: SSH error
In-Reply-To: <B73F7104E5B44F468AB0FC95DF7884423B4F42@pste0050.mckesson.com>
Message-ID: <Pine.BSO.4.33.0110101549250.29565-100000@etoh.eviladmin.org>


One really does need to provide more useful information.

On a blind guess, I assume F-Secure is protocol 2 only and has no clue
what 'rcp/scp' is.  I suggest you try sftp instead.

- Ben

On Wed, 10 Oct 2001, Tablan, Kathy wrote:

> Yes we are trying to copy a file. We are using command scp.
>
>
>
> Kathy
>
>
>
> -----Original Message-----
> From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org]
> Sent: Wednesday, October 10, 2001 12:56 PM
> To: Tablan, Kathy
> Cc: 'openssh-unix-dev at mindrot.org'
> Subject: Re: SSH error
>
>
>
>
> How are you trying to 'copy a file'?  Can we see a scp -v -v -v or a sftp
>
> -v -v -v ?
>
>
>
> - Ben
>
>
>
> On Wed, 10 Oct 2001, Tablan, Kathy wrote:
>
>
>
> > Hello,
>
> >
>
> > I am working with a customer that has SSH F-Secure (NT windows).  We
>
> > currently have OPENSSH installed in our unix server.  We are trying to
> copy
>
> > a file from our unix box to an NT windows and received the following
> error:
>
> >
>
> >
>
> > 	Remote: Failed to lauch child process!
>
> >
>
> >
>
> > How can we resolve this problem.
>
> >
>
> > Thanks,
>
> >
>
> > Kathy Tablan
>
> >
>
> >
>
> > Confidentiality Notice: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.
>
> >
>
> >
>
> >
>
> >
>
> Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
>
>
>
>



From markus at openbsd.org  Thu Oct 11 06:58:15 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 10 Oct 2001 22:58:15 +0200
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <20011010163734.U5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Oct 10, 2001 at 04:37:35PM -0400
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <20011010163734.U5739@sm2p1386swk.wdr.com>
Message-ID: <20011010225815.A2539@faui02.informatik.uni-erlangen.de>

On Wed, Oct 10, 2001 at 04:37:35PM -0400, Nicolas Williams wrote:
>  - ssh -n -2 host exit $(print $((RANDOM % 91)) |tee /dev/tty) ; echo $?

try this instead:

ssh -n localhost 'echo x; exec > /dev/null 2>&1; sleep 3; exit 5;'

and the patch i sent earlier.


From Jewnix at technohac.com  Thu Oct 11 07:44:39 2001
From: Jewnix at technohac.com (Gil Disatnik)
Date: Wed, 10 Oct 2001 23:44:39 +0200
Subject: OpenSSH name resolving problems
Message-ID: <5.1.0.14.2.20011010233431.025d81c0@pop3.norton.antivirus>

Hello there.
I've noticed a strange problem happen in ALL my linux machines (some of 
them still running OpenSSH 2.9p1 (The one that comes with Slack8) and some 
of them are running 2.9.9p2 (That I have compiled myself).
When I am having a certain host in my /etc/hosts, for example:

192.168.1.12    netinst

When I am running ssh netinst -v -v -v
the last line I could see is: ssh_connect: getuid 0 geteuid 0 anon 1
The next line is telling me that it is connecting to netinst which resolves 
to 192.168.1.12

The problem is that it has a 20 second delay until it really start 
connecting... when using an ip address instead of a hostname I'll have my 
connection running in no time.

/etc/nsswitch.conf showed me that files are before dns, nevertheless - I 
REMOVED dns from the conf file - and it worked great. Of course I can't let 
my machine to run without a dns (Oh... almost forgot about it... the 
machine is internetless and dnsless most of the time, that's why it waits 
for a dead dns, still the /etc/nsswitch should solve that once I am telling 
it to search files before dns...)
Anyways - Looks like a bug to me unless you could state otherwise (Hey, I 
am not criticizing you, just stating that it looks like a bug :))

Thanks.

P.S - I am still waiting for any answer regarding my previous question 
about the fact that I can't exit from a shell when I have background 
jobs... It is really important... please help me here...


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 djm at mindrot.org  Thu Oct 11 09:46:43 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Oct 2001 09:46:43 +1000 (EST)
Subject: OpenSSH name resolving problems
In-Reply-To: <5.1.0.14.2.20011010233431.025d81c0@pop3.norton.antivirus>
Message-ID: <Pine.LNX.4.33.0110110945490.1639-100000@mothra.mindrot.org>

On Wed, 10 Oct 2001, Gil Disatnik wrote:

> The problem is that it has a 20 second delay until it really start 
> connecting... when using an ip address instead of a hostname I'll have my 
> connection running in no time.

The server end is stalling on a reverse lookup. You can switch this 
behaviour off (read the manpage).

> P.S - I am still waiting for any answer regarding my previous question 
> about the fact that I can't exit from a shell when I have background 
> jobs... It is really important... please help me here...

This has been discussed at length, check the archives.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From djm at mindrot.org  Thu Oct 11 10:08:49 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Oct 2001 10:08:49 +1000 (EST)
Subject: openssh on LynxOS issues! - Changes and addons.
In-Reply-To: <20011010153445.21002.qmail@web8004.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.33.0110111006130.1639-100000@mothra.mindrot.org>

On Wed, 10 Oct 2001, hari sekar wrote:

> Hi,
>   With reference to my previous mail:
> 1.  I use openssh-2.9p2 on a LynxOS i386 system. The
> ssh and scp clients work fine. Even sftp from other
> Linux systems works. But, if I run the sftp client in
> LynxOS to localhost (LynxOS) or remote sshd in Linux,
> the authentication succeeds, prints sftp> prompt and
> then exits. I don't know why this happens. The problem
> is with the sftp client program in LynxOS. Does it
> work for anyone (sftp client program in LynxOS)?

No idea here - have you determined whether it is sftp or the underlying
ssh that is exiting.

> 2.  Does anyone use ssh client with seteuid to root?
> and it still works? or is there a problem with LynxOS
> that seteuid() doesn't work with _POSIX_SAVED_IDS?

It works on most systems.

> 3.  One more problem. sshd run on LynxOS and ssh
> client from Linux system. ssh client hangs on exit.
> $ssh hari at lynx (From Linux)
> password:
> lynx>...
> lynx>exit
> hangs ......
>     I don't think it is the regular hang-on-exit bug,
> because there are no background processes running, I
> suppose, and I get this hang 90% of time. Ofcourse,
> lynx> exit > /dev/null < /dev/null 2>&1
> makes it clean, but I want to make sure why this
> happens. Do you have this problem in your LynxOS
> installation? 

Search the mailing list archives, this has been discussed at (great) length.

> 4. The TERM environment variable remains xterm.
> $echo $TERM
> xterm
> $ssh hari at lynx  (From Linux)
> Password:
> lynx>echo $TERM
> xterm
> lynx>
> How to set TERM to vt100at on login.
> I hope you do not have problem here!

This is correct behaviour, $TERM should be propogated across ssh connections.
If you want a different $TERM, set it manually.

> 5. Addon: In LynxOS, sshd writes to utmp and wtmp on
> login, but does not remove entries from utmp on
> logout. So, lynx> who
> displays the user even after logout. Interestingly,
> the  size of utmp and wtmp files change (increase)
> after login and logout, i.e., the server writes to
> them. Then, is it the way the OS interprets it
> different, though the sshd server does its job
> perfect. Normal telnet programs to Lynx system do not
> alter the size of the utmp file.

You may need to doctor loginrec.c to cope with the way that LynxOS handles
utmp, wtmp and lastlog. This is one of the areas of greatest platform 
incompatability.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From slade at shore.net  Thu Oct 11 15:23:09 2001
From: slade at shore.net (Richard E. Silverman)
Date: Thu, 11 Oct 2001 01:23:09 -0400
Subject: OpenSSH name resolving problems
Message-ID: <200110110523.BAA22376@syrinx.oankali.net>


> P.S - I am still waiting for any answer regarding my previous question
> about the fact that I can't exit from a shell when I have background
> jobs... It is really important... please help me here...

http://www.snailbook.com/faq/background-jobs.auto.html

- Richard


From a_ghsek at yahoo.co.in  Thu Oct 11 20:12:36 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Thu, 11 Oct 2001 11:12:36 +0100 (BST)
Subject: openssh on LynxOS issues! - Changes and addons.
In-Reply-To: <Pine.LNX.4.33.0110111006130.1639-100000@mothra.mindrot.org>
Message-ID: <20011011101236.61271.qmail@web8005.mail.in.yahoo.com>

 --- Damien Miller <djm at mindrot.org> wrote: > On Wed,
10 Oct 2001, hari sekar wrote:
> 
> > Hi,
> > 1.  I use openssh-2.9p2 on a LynxOS i386 system.
> The
> > ssh and scp clients work fine. Even sftp from
> other
> > Linux systems works. But, if I run the sftp client
> in
> > LynxOS to localhost (LynxOS) or remote sshd in
> Linux,
> > the authentication succeeds, prints sftp> prompt
> and
> > then exits. I don't know why this happens. The
> problem
> > is with the sftp client program in LynxOS. Does it
> > work for anyone (sftp client program in LynxOS)?
> 
> No idea here - have you determined whether it is
> sftp or the underlying
> ssh that is exiting.

  ssh client program in LynxOS works fine. It is only
the sftp that exits. Anyway, I attah the debug output
from local sftp program (LynxOS) and remote sshd debug
(Linux).

> 
> > 2.  Does anyone use ssh client with seteuid to
> root?
> > and it still works? or is there a problem with
> LynxOS
> > that seteuid() doesn't work with _POSIX_SAVED_IDS?
> 
> It works on most systems.

   Yeah, it works on Linux and other systems. But do
you mean it works fine on LynxOS system. Have you come
across it? 
Thanks for help,
-Hari.

> 
> -d
> 
> -- 
> | Damien Miller <djm at mindrot.org> \ ``E-mail
> attachments are the poor man's 
> | http://www.mindrot.org          /   distributed
> filesystem'' - Dan Geer
>  

/* sftp client in LynxOS connected to sshd in Linux */


lynx> sftp -v hari at linux
Connecting to 192.168.0.126...
debug1: SSH args "ssh -l hari -v 192.168.0.126 -s
-oForwardX11=no -oForwardAgent=no -oProtocol=2 sftp"
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL
0x0090600f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 7 geteuid 7 anon 1
debug1: Connecting to 192.168.0.126 [192.168.0.126]
port 22.
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/hari/.ssh/id_rsa type -1
debug1: identity file /home/hari/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 141/256
debug1: bits set: 1040/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.0.126' is known and matches the
RSA host key.
debug1: Found key in /home/hari/.ssh/known_hosts2:3
debug1: bits set: 1000/2049
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 privkey: /home/hari/.ssh/id_rsa
debug1: try privkey: /home/hari/.ssh/id_dsa
debug1: next auth method to try is password
hari at 192.168.0.126's password:
debug1: ssh-userauth2 successful: method password
debug1: fd 5 setting O_NONBLOCK
debug1: fd 6 IS O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Sending subsystem: sftp
debug1: channel 0: open confirm rwindow 0 rmax 16384
sftp>
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
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)

debug1: channel_free: channel 0: dettaching channel
user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes
in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0,
stderr 0.0
debug1: Exit status 0
lynx>


/* Remote Redhat 7.0 Linux system running sshd server
*/
linux# sshd -d
debug1: Seeding random number generator
debug1: sshd version OpenSSH_2.9p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
socket: Invalid argument
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging
mode.
Connection from 192.168.0.23 port 1046
debug1: Client protocol version 2.0; client software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.9p2
debug1: Rhosts Authentication disabled, originating
port not trusted.
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 132/256
debug1: bits set: 1000/2049
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1040/2049
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
debug1: userauth-request for user hari service
ssh-connection method none
debug1: attempt 0 failures 0
debug1: Starting up PAM with username "hari"
debug1: PAM setting rhost to "ists_ibm23"
Failed none for hari from 192.168.0.23 port 1046 ssh2
debug1: userauth-request for user hari service
ssh-connection method password
debug1: attempt 1 failures 1
debug1: PAM Password authentication accepted for user
"hari"
Accepted password for hari from 192.168.0.23 port 1046
ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan
0 win 65536 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0
request subsystem reply 1subsystem request for sftp
debug1: subsystem: exec()
/usr/local/libexec/sftp-server
debug1: PAM establishing creds
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 1980
debug1: session_exit_message: session 0 channel 0 pid
1980
debug1: session_exit_message: release channel 0
debug1: session_free: session 0 pid 1980
debug1: channel 0: read<=0 rfd 7 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: channel 0: send close
debug1: channel 0: rcvd close
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following
connections are open:
  #0 server-session (t4 r0 i8/0 o128/0 fd 7/7)

Connection closed by remote host.
Closing connection to 192.168.0.23
linux#






____________________________________________________________
Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com


From markus at openbsd.org  Fri Oct 12 01:18:33 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 11 Oct 2001 17:18:33 +0200
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <20011010222250.A2472@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Oct 10, 2001 at 10:22:50PM +0200
References: <3BC3BCF1.E03BA37E@lochard.com.au> <20011010171751.B16684@faui02.informatik.uni-erlangen.de> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC45908.E3FD2153@mail.microcenter.com> <3BC3BCF1.E03BA37E@lochard.com.au> <20011010222250.A2472@faui02.informatik.uni-erlangen.de>
Message-ID: <20011011171833.A27746@faui02.informatik.uni-erlangen.de>

I wrote:

> could you please try this diff against the current CVS

so it works?


From matthew.seaman at tornadogroup.com  Fri Oct 12 02:15:07 2001
From: matthew.seaman at tornadogroup.com (Matthew Seaman)
Date: Thu, 11 Oct 2001 17:15:07 +0100
Subject: OpenSSH solaris: bad return code after exec of remote command
References: <3BC3BCF1.E03BA37E@lochard.com.au> <20011010171751.B16684@faui02.informatik.uni-erlangen.de> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC45908.E3FD2153@mail.microcenter.com> <3BC3BCF1.E03BA37E@lochard.com.au> <20011010222250.A2472@faui02.informatik.uni-erlangen.de>
Message-ID: <3BC5C58B.113489C1@tornadogroup.com>

Markus Friedl wrote:
> 
> I wrote:
> 
> > it's easy to reproduce your problem:
> >
> > ssh -n localhost 'echo x; exec > /dev/null 2>&1; sleep 3; exit 5;'
> 
> could you please try this diff against the current CVS
> 
> hope everything else stil works...

I can report that those patches seem to have corrected the problem we
were experiencing.  I'll install the patched version of openssh in our
development environment so that it gets a good workout and get back to
you if anything goes awry.  

Sorry about taking so long to get back to you.  

	Cheers,

	Matthew

-- 
Matthew Seaman                                              01628 498661

                Abeo, abeo, abeo, actum est, comites!


From markus at openbsd.org  Fri Oct 12 02:50:46 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 11 Oct 2001 18:50:46 +0200
Subject: LynxOS: ssh client hang on exit?
In-Reply-To: <20011010143515.39855.qmail@web8007.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Wed, Oct 10, 2001 at 03:35:15PM +0100
References: <20011010143515.39855.qmail@web8007.mail.in.yahoo.com>
Message-ID: <20011011185046.B26546@folly>

could you please try the latest snapshot and
the patches i sent.


From markus at openbsd.org  Fri Oct 12 02:49:29 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 11 Oct 2001 18:49:29 +0200
Subject: ssh exit mechanism!
In-Reply-To: <20011010082453.83671.qmail@web8004.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Wed, Oct 10, 2001 at 09:24:53AM +0100
References: <20011010082453.83671.qmail@web8004.mail.in.yahoo.com>
Message-ID: <20011011184929.A26546@folly>

On Wed, Oct 10, 2001 at 09:24:53AM +0100, hari sekar wrote:
> To whomsoever it may concern,
>     I use putty-0.51 as ssh client on windows and
> openssh-2.9p2 implementation on RedHat 7.0 Linux as
> ssh server. For the client to exit, I expected ssh
> client to send SSH_CMSG_EOF to the server and the
> server respond with SSH_CMSG_EXITSTATUS and finally
> close the connection when the client sends
> SSH_CMSG_EXIT_CONFIRMATION. This will effectively end
> the server_loop in the server. This would close the
> connection in a cleaner way. Although the RFC has
> stated that either side may send SSH_MSG_DISCONNECT,
> for immediate disconnect, I am surprised that this is
> the normal exit method used in putty implementation. 
>        I fear that any addition of code after
> server_loop, to be done once the connection is closed
> by the server might not get called, as it now is
> redirected to fatal_cleanup(). 
>      Is this normal and do other implementations
> follow this?

openssh's client waits for SSH_CMSG_EXITSTATUS.

> 
>    And I would also like to know about the ssh
> hang-on-exit problem. Why is it necessary to redirect
> stdin to /dev/null to prevent this? How does this end
> processes running in background?

because EOF on PTY's is different on different unices.


From markus at openbsd.org  Fri Oct 12 02:53:10 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 11 Oct 2001 18:53:10 +0200
Subject: OpenSSH solaris: bad return code after exec of remote command
In-Reply-To: <3BC45908.E3FD2153@mail.microcenter.com>; from abush@microcenter.com on Wed, Oct 10, 2001 at 10:19:52AM -0400
References: <3BC3BCF1.E03BA37E@lochard.com.au> <3BC45908.E3FD2153@mail.microcenter.com>
Message-ID: <20011011185310.D26546@folly>

please try the current cvs version and the patch
is sent recently to this list.


From markus at openbsd.org  Fri Oct 12 02:51:44 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 11 Oct 2001 18:51:44 +0200
Subject: openssh on LynxOS issues!
In-Reply-To: <20011010142243.7695.qmail@web8005.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Wed, Oct 10, 2001 at 03:22:43PM +0100
References: <20011010142243.7695.qmail@web8005.mail.in.yahoo.com>
Message-ID: <20011011185144.C26546@folly>

> 4. The TERM environment variable remains xterm.
> $echo $TERM
> xterm
> $ssh hari at lynx  (From Linux)
> Password:
> lynx>echo $TERM
> xterm
> lynx>
> How to set TERM to vt100at on login.
> I hope you do not have problem here!

the ssh protocol transfers the TERM variable
to the remote host.


From Dick.Streefland at xs4all.nl  Fri Oct 12 06:56:38 2001
From: Dick.Streefland at xs4all.nl (Dick Streefland)
Date: Thu, 11 Oct 2001 22:56:38 +0200
Subject: [patch] option to prevent connection timeout
Message-ID: <20011011225638.A11829@zaphod.de.bilt>

Hi,

The firewall at work doesn't allow me to make a direct SSH connection
to the Internet, so I use the ProxyCommand to tunnel SSH through a
HTTP proxy. This works fine, except for the fact that the HTTP proxy
server closes the connection after 60 seconds of inactivity. Attached
below is a patch that implements a new configuration option called
"Idle" that lets you specify the maximum idle time of a connection in
seconds. When this limit is reached, a dummy packet (SSH_MSG_IGNORE)
is sent, to fake activity, and to prevent the timeout. This option
might be usefull for others, so I'm posting it here.

-- 
Dick Streefland                    ////               De Bilt
dick.streefland at xs4all.nl         (@ @)       The Netherlands
------------------------------oOO--(_)--OOo------------------

--- openssh-2.9.9p2/clientloop.c.orig	Tue Sep 18 07:51:14 2001
+++ openssh-2.9.9p2/clientloop.c	Thu Oct 11 22:03:09 2001
@@ -320,6 +320,9 @@
 client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp,
     int *maxfdp, int *nallocp, int rekeying)
 {
+	struct timeval tv;
+	int n;
+
 	/* Add any selections by the channel mechanism. */
 	channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, rekeying);
 
@@ -364,7 +367,24 @@
 	 * SSH_MSG_IGNORE packet when the timeout expires.
 	 */
 
-	if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0) {
+	/*
+	 * When the "Idle" option is set to a non-zero value, a dummy
+	 * packet is sent after the connection is idle for the specified
+	 * number of seconds, to prevent the connection from timing out.
+	 */
+	if (options.idle > 0) {
+		tv.tv_sec = options.idle;
+		tv.tv_usec = 0;
+		n = select((*maxfdp)+1, *readsetp, *writesetp, NULL, &tv);
+		if (n == 0) {
+			debug2("idle");
+			packet_send_ignore(1);
+			packet_send();
+		}
+	} else {
+		n = select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL);
+	}
+	if (n < 0) {
 		char buf[100];
 
 		/*
--- openssh-2.9.9p2/readconf.c.orig	Thu Sep 20 02:57:56 2001
+++ openssh-2.9.9p2/readconf.c	Thu Oct 11 22:03:09 2001
@@ -109,7 +109,7 @@
 	oUser, oHost, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand,
 	oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts,
 	oBatchMode, oCheckHostIP, oStrictHostKeyChecking, oCompression,
-	oCompressionLevel, oKeepAlives, oNumberOfPasswordPrompts,
+	oCompressionLevel, oKeepAlives, oIdle, oNumberOfPasswordPrompts,
 	oUsePrivilegedPort, oLogLevel, oCiphers, oProtocol, oMacs,
 	oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication,
 	oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias,
@@ -178,6 +178,7 @@
 	{ "compression", oCompression },
 	{ "compressionlevel", oCompressionLevel },
 	{ "keepalive", oKeepAlives },
+	{ "idle", oIdle },
 	{ "numberofpasswordprompts", oNumberOfPasswordPrompts },
 	{ "loglevel", oLogLevel },
 	{ "dynamicforward", oDynamicForward },
@@ -415,6 +416,10 @@
 		intptr = &options->keepalives;
 		goto parse_flag;
 
+	case oIdle:
+		intptr = &options->idle;
+		goto parse_int;
+
 	case oNumberOfPasswordPrompts:
 		intptr = &options->number_of_password_prompts;
 		goto parse_int;
@@ -767,6 +772,7 @@
 	options->strict_host_key_checking = -1;
 	options->compression = -1;
 	options->keepalives = -1;
+	options->idle = -1;
 	options->compression_level = -1;
 	options->port = -1;
 	options->connection_attempts = -1;
@@ -859,6 +865,8 @@
 		options->compression = 0;
 	if (options->keepalives == -1)
 		options->keepalives = 1;
+	if (options->idle == -1)
+		options->idle = 0;
 	if (options->compression_level == -1)
 		options->compression_level = 6;
 	if (options->port == -1)
--- openssh-2.9.9p2/readconf.h.orig	Thu Sep 20 02:57:56 2001
+++ openssh-2.9.9p2/readconf.h	Thu Oct 11 22:03:09 2001
@@ -63,6 +63,7 @@
 	int     compression_level;	/* Compression level 1 (fast) to 9
 					 * (best). */
 	int     keepalives;	/* Set SO_KEEPALIVE. */
+	int     idle;		/* prevent idle connection from timing out */
 	LogLevel log_level;	/* Level for logging. */
 
 	int     port;		/* Port to connect. */
--- openssh-2.9.9p2/ssh.1.orig	Thu Sep 20 02:57:56 2001
+++ openssh-2.9.9p2/ssh.1	Thu Oct 11 22:03:09 2001
@@ -926,6 +926,14 @@
 It is possible to have
 multiple identity files specified in configuration files; all these
 identities will be tried in sequence.
+.It Cm Idle
+When this option is set to a non-zero value, a dummy packet is sent
+after the connection is idle for the specified number of seconds.
+This faked activity will prevent the connection from timing out.
+The default value is 0 seconds, which disables this feature.
+Note that this is different from the
+.Cm KeepAlive
+option, which merely sets the SO_KEEPALIVE socket option.
 .It Cm KeepAlive
 Specifies whether the system should send keepalive messages to the
 other side.


From dbt at meat.net  Fri Oct 12 08:41:17 2001
From: dbt at meat.net (David Terrell)
Date: Thu, 11 Oct 2001 15:41:17 -0700
Subject: hang on exit - bug or no bug?
In-Reply-To: <Pine.BSO.4.33.0110051305270.2843-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Fri, Oct 05, 2001 at 01:07:09PM -0500
References: <20011005140245.Q5739@sm2p1386swk.wdr.com> <Pine.BSO.4.33.0110051305270.2843-100000@etoh.eviladmin.org>
Message-ID: <20011011154117.A11405@pianosa.catch22.org>

On Fri, Oct 05, 2001 at 01:07:09PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> 
> On Fri, 5 Oct 2001, Nicolas Williams wrote:
> 
> > On Fri, Oct 05, 2001 at 12:58:37PM -0500, mouring at etoh.eviladmin.org wrote:
> > >
> > > [..]
> > > > >  - write a separate script for checking that the batch job is doing ok
> > > > >  - use intr (yes, Solaris doesn't have one -- write one yourself) on the
> > > > >    client side to set a timeout after which to kill ssh
> > > > >  - write an intr-like command for the remote side that closes the fds
> > > > >    after a timeout and which might be used like so:
> > > > >
> > > > >    ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
> > > > >  - fix the scripts
> > > >
> > > > - fix the daemons
> > > >
> > >
> > > Finxing daemons will solve part of the problem.. but will not solve the
> > > case when you do:
> > >
> > > ssh site.com
> > > vi file
> > > ctrl-z
> > > <wander around>
> > > exit
> > > ..[hang]
> >
> > My shell usually tells me that I have suspended jobs and aborts the
> > exit.
> >
> 
> First time.. But how many people have you seen in a hurry to leave for
> the day go 'Ctrl-D, Ctrl-D'  and ignore the suspended jobs because they
> are use to telnet killing the processes or they die due to lack of std*
> contact.
> 
> I'll admit I've done it a few times.. Not normally under SSH.

This should handled by a sighup to the pgrp, right?

-- 
David Terrell             | "Americans need to watch what they say,
Prime Minister, Nebcorp   | watch what they do, and this is not a
dbt at meat.net              | time for remarks like that; there never
http://wwn.nebcorp.com/   | is." - Ari Fleischer, White House Press Secretary


From david.batterham at lochard.com.au  Fri Oct 12 10:40:34 2001
From: david.batterham at lochard.com.au (David Batterham)
Date: Fri, 12 Oct 2001 10:40:34 +1000
Subject: OpenSSH solaris: bad return code after exec of remote command
References: <3BC3BCF1.E03BA37E@lochard.com.au> <20011010171751.B16684@faui02.informatik.uni-erlangen.de> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC41E4D.CC9CA489@tornadogroup.com> <3BC3BCF1.E03BA37E@lochard.com.au> <3BC45908.E3FD2153@mail.microcenter.com> <3BC3BCF1.E03BA37E@lochard.com.au> <20011010222250.A2472@faui02.informatik.uni-erlangen.de> <3BC5C58B.113489C1@tornadogroup.com>
Message-ID: <3BC63C02.E5271DB6@lochard.com.au>


Guys,

I too can happily report that the patch Markus posted seems to have fixed the
problem. I now consistently get the correct return codes.

Thanks to all of you for your efforts. This was an important factor for me in
being able to do what I wanted with openssh, and being the first time I have
posted to this list (I have only just started to use openssh), I was pleased
with the quick response from all concerned. In fact, the patch came so quickly I
had to find the time to apply and test it!

Regs,
Dave



Matthew Seaman wrote:
> 
> Markus Friedl wrote:
> >
> > I wrote:
> >
> > > it's easy to reproduce your problem:
> > >
> > > ssh -n localhost 'echo x; exec > /dev/null 2>&1; sleep 3; exit 5;'
> >
> > could you please try this diff against the current CVS
> >
> > hope everything else stil works...
> 
> I can report that those patches seem to have corrected the problem we
> were experiencing.  I'll install the patched version of openssh in our
> development environment so that it gets a good workout and get back to
> you if anything goes awry.
> 
> Sorry about taking so long to get back to you.
> 
>         Cheers,
> 
>         Matthew
> 
> --
> Matthew Seaman                                              01628 498661
> 
>                 Abeo, abeo, abeo, actum est, comites!

-- 
---------------------------------------------------------------
David Batterham                     PHONE: +61 3 95001017
System Administrator                FAX:   +61 3 95001191
Lochard Pty Ltd                     EMAIL: david at lochard.com.au


From djm at mindrot.org  Fri Oct 12 11:47:38 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Oct 2001 11:47:38 +1000 (EST)
Subject: Please test snapshots for 3.0 release
Message-ID: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>

Could everyone please test the latest snapshots as we will be making a
new release soon.

If you have any patches you would like us to consider, please resend 
them to the list ASAP.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From tomh at po.crl.go.jp  Fri Oct 12 11:58:52 2001
From: tomh at po.crl.go.jp (Tom Holroyd)
Date: Fri, 12 Oct 2001 10:58:52 +0900 (JST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.30.0110121056400.23351-100000@holly.crl.go.jp>

On Fri, 12 Oct 2001, Damien Miller wrote:

> If you have any patches you would like us to consider, please resend
> them to the list ASAP.

"make veryclean" doesn't remove scard/Makefile

--- #Makefile.in        Tue Sep 18 14:06:22 2001
+++ Makefile.in Fri Oct 12 10:56:08 2001
@@ -158,6 +158,7 @@
        rm -f *.out core
        rm -f Makefile config.h config.status ssh_prng_cmds *~
        (cd openbsd-compat; $(MAKE) distclean)
+       (cd scard; $(MAKE) distclean)

 mrproper: distclean



From djm at mindrot.org  Fri Oct 12 12:05:30 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Oct 2001 12:05:30 +1000 (EST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.30.0110121056400.23351-100000@holly.crl.go.jp>
Message-ID: <Pine.LNX.4.33.0110121204530.1209-100000@mothra.mindrot.org>

On Fri, 12 Oct 2001, Tom Holroyd wrote:

> "make veryclean" doesn't remove scard/Makefile

Arigato gosaimashita :)

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer



From pekkas at netcore.fi  Fri Oct 12 16:44:54 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 12 Oct 2001 09:44:54 +0300 (EEST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots
 for 3.0 release]
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.33.0110120845490.28919-200000@netcore.fi>

On Fri, 12 Oct 2001, Damien Miller wrote:
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
>
> If you have any patches you would like us to consider, please resend
> them to the list ASAP.

1) As sshd -t is used when restarting sshd with RH scripts now, I think
sshd_config is better marked with noreplace as config files should.

2) I'd probably remove '--with-ipv4-default'; it's a major release after
all.  I haven't noticed problems with this, and if you'd have to run 'sshd
-6', IPv4 port forwarding through mapped addresses won't work.

3) Building appears to rely on the existance of rather recent openssl.
This is good from security perspective, but will make building with e.g.
0.9.5a impossible.  If this is intended to be requirement (there _have_
been security fixes), at least Requires:  openssl >= 0.9.6 or whatever
should be added and the requirement noted in the docs.

The build failed on my RHL62 with:

./libssh.a(key.o): In function `write_bignum':
key.o(.text+0x7f7): undefined reference to `OPENSSL_free'

I bet this is an issue that people might complain about.

Build works ok on RHL72 beta w/ openssh 0.9.6b.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
-------------- next part --------------
Index: openssh.spec
===================================================================
RCS file: /cvs/openssh_cvs/contrib/redhat/openssh.spec,v
retrieving revision 1.86
diff -u -r1.86 openssh.spec
--- openssh.spec	2001/09/26 14:24:21	1.86
+++ openssh.spec	2001/09/27 15:51:33
@@ -264,8 +264,7 @@
 %attr(0755,root,root) %{_libexecdir}/openssh/sftp-server
 %attr(0644,root,root) %{_mandir}/man8/sshd.8*
 %attr(0644,root,root) %{_mandir}/man8/sftp-server.8*
-#%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config
-%attr(0600,root,root) %config %{_sysconfdir}/sshd_config
+%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config
 %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd
 %attr(0755,root,root) %config /etc/rc.d/init.d/sshd
 

From serge.droz at psi.ch  Fri Oct 12 20:17:40 2001
From: serge.droz at psi.ch (Serge Droz)
Date: Fri, 12 Oct 2001 12:17:40 +0200
Subject: AFS Token Passing before Auth
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <3BC6C344.E5F15D53@psi.ch>

Hello, 

after the discussion about when to send AFS tokens I've created a pacthc
which includes a new option to ssh and sshd:
If AFSPassTokenBeforeAuth is set to yes (default no)
tokens are passed as they where in releases < 2.9.9p2.

So now the admin has the choice.

Cheers
Serge



-- 
Serge Droz
Paul Scherrer Institut                mailto:serge.droz at psi.ch
CH-5232 Villigen PSI                   Phone: ++41 56 310 3637
-------------- next part --------------
diff -u openssh.orig/auth1.c openssh/auth1.c
--- openssh.orig/auth1.c	Wed Jul  4 06:21:16 2001
+++ openssh/auth1.c	Fri Oct 12 11:57:52 2001
@@ -118,6 +118,24 @@
 		/* 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);
+				   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) {
@@ -168,11 +186,11 @@
 		case SSH_CMSG_HAVE_KERBEROS_TGT:
 			packet_send_debug("Kerberos TGT passing disabled before authentication.");
 			break;
-#ifdef AFS
-		case SSH_CMSG_HAVE_AFS_TOKEN:
-			packet_send_debug("AFS token passing disabled before authentication.");
-			break;
-#endif /* AFS */
+//#ifdef AFS
+//		case SSH_CMSG_HAVE_AFS_TOKEN:
+//		    packet_send_debug("AFS token passing disabled before authentication.");
+//			break;
+//#endif /* AFS */
 #endif /* AFS || KRB5 */
 			
 		case SSH_CMSG_AUTH_RHOSTS:
diff -u openssh.orig/readconf.c openssh/readconf.c
--- openssh.orig/readconf.c	Wed Oct  3 19:39:39 2001
+++ openssh/readconf.c	Fri Oct 12 11:32:50 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 -u openssh.orig/readconf.h openssh/readconf.h
--- openssh.orig/readconf.h	Wed Oct  3 19:39:39 2001
+++ openssh/readconf.h	Fri Oct 12 11:10:56 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 -u openssh.orig/servconf.c openssh/servconf.c
--- openssh.orig/servconf.c	Wed Sep 12 18:32:15 2001
+++ openssh/servconf.c	Fri Oct 12 11:55:46 2001
@@ -79,6 +79,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;
@@ -184,6 +185,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;
@@ -233,6 +236,7 @@
 #endif
 #ifdef AFS
 	sAFSTokenPassing,
+	sAFSPassTokenBeforeAuth,
 #endif
 	sChallengeResponseAuthentication,
 	sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress,
@@ -281,6 +285,7 @@
 #endif
 #ifdef AFS
 	{ "afstokenpassing", sAFSTokenPassing },
+	{ "afspasstokenbeforeauth", sAFSPassTokenBeforeAuth },
 #endif
 	{ "passwordauthentication", sPasswordAuthentication },
 	{ "kbdinteractiveauthentication", sKbdInteractiveAuthentication },
@@ -611,6 +616,9 @@
 #ifdef AFS
 		case sAFSTokenPassing:
 			intptr = &options->afs_token_passing;
+			goto parse_flag;
+		case sAFSPassTokenBeforeAuth:
+			intptr = &options->afs_pass_token_before_auth;
 			goto parse_flag;
 #endif
 
diff -u openssh.orig/servconf.h openssh/servconf.h
--- openssh.orig/servconf.h	Wed Sep 12 18:40:06 2001
+++ openssh/servconf.h	Fri Oct 12 10:49:03 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 -u openssh.orig/ssh.1 openssh/ssh.1
--- openssh.orig/ssh.1	Wed Oct  3 19:39:39 2001
+++ openssh/ssh.1	Fri Oct 12 12:06:14 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 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 -u openssh.orig/sshconnect1.c openssh/sshconnect1.c
--- openssh.orig/sshconnect1.c	Wed Oct 10 07:03:12 2001
+++ openssh/sshconnect1.c	Fri Oct 12 11:48:01 2001
@@ -1139,6 +1139,26 @@
 		goto success;
 	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)) &&
@@ -1256,19 +1276,21 @@
 #endif
 	
 #ifdef AFS
-	/* 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();
+    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 */
 
diff -u openssh.orig/sshd.8 openssh/sshd.8
--- openssh.orig/sshd.8	Wed Oct  3 19:15:32 2001
+++ openssh/sshd.8	Fri Oct 12 12:07:14 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 an AFS token are accepted before the user
+is authenticicated.
+Default is
+.Dq yes .
 .It Cm AllowGroups
 This keyword can be followed by a list of group names, separated
 by spaces.

From jan.iven at cern.ch  Fri Oct 12 20:19:16 2001
From: jan.iven at cern.ch (Jan IVEN)
Date: 12 Oct 2001 12:19:16 +0200
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <unmlmih40uz.fsf@asis-w2.cern.ch>

>>>>> "DM" == Damien Miller <djm at mindrot.org> writes:

 DM> Could everyone please test the latest snapshots as we will be making a
 DM> new release soon.

I am testing against RH7.2beta, including support for KRB4 (kth-1.0.7)
and AFS. Openssh CVS snapshot as of Oct 12 11:52 CEST.

Current problems:

- mkstemp on RH7.2 is detected (so the bsd-mkstemp.o will be empty),
but this version needs "XXXXXX" in the file name template, otherwise
it will return an error (EINVAL). In auth-krb4.c, the current template
includes just pid and uid, no "X"s. Due to the logic in auth-krb4.c
this error is misinterpreted as "file already present", with a
subsequent check on ownership failing. Please not that the bsd-mkstemp()
handles the situation just fine.

- a rather recent autoconf appears to be needed for AC_SYS_LARGEFILE,
RH7.2beta ships with  2.13 (too old).

- compiling openbsd-compat/ shows lots of errors, I haven't sorted
these out yet (and they could be my fault):

(cd openbsd-compat; make)
make[1]: Entering directory `/afs/cern.ch/project/connectivity/openssh-2.cvs-tmp/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/afs/cern.ch/project/connectivity/openssl-0.9.6/i386_linux24/install/include  -I/afs/cern.ch/project/connectivity/krb4-1.0.7/i386_linux24/install/include -I/afs/cern.ch/project/connectivity/krb4-1.0.7/i386_linux24/install/include -DHAVE_CONFIG_H -c bsd-arc4random.c
In file included from ../openbsd-compat/openbsd-compat.h:23,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/strsep.h:9: parse error before `__extension__'
../openbsd-compat/strsep.h:9: parse error before `('
In file included from ../openbsd-compat/openbsd-compat.h:32,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/bsd-misc.h:66: redefinition of `struct timeval'
../openbsd-compat/bsd-misc.h:72: two or more data types in declaration of `utimes'
In file included from ../openbsd-compat/openbsd-compat.h:39,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/fake-socket.h:13: redefinition of `struct sockaddr_storage'
../openbsd-compat/fake-socket.h:27: redefinition of `struct in6_addr'
../openbsd-compat/fake-socket.h:28: warning: no semicolon at end of struct or union
../openbsd-compat/fake-socket.h:28: parse error before `.'
../openbsd-compat/fake-socket.h:33: redefinition of `struct sockaddr_in6'
make[1]: *** [bsd-arc4random.o] Error 1
make[1]: Leaving directory `/afs/cern.ch/project/connectivity/openssh-2.cvs-tmp/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

Best regards
Jan


From djm at mindrot.org  Fri Oct 12 20:45:09 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Oct 2001 20:45:09 +1000 (EST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <unmlmih40uz.fsf@asis-w2.cern.ch>
Message-ID: <Pine.LNX.4.33.0110122040320.1211-100000@mothra.mindrot.org>

On 12 Oct 2001, Jan IVEN wrote:

> >>>>> "DM" == Damien Miller <djm at mindrot.org> writes:
> 
>  DM> Could everyone please test the latest snapshots as we will be making a
>  DM> new release soon.
> 
> I am testing against RH7.2beta, including support for KRB4 (kth-1.0.7)
> and AFS. Openssh CVS snapshot as of Oct 12 11:52 CEST.
> 
> Current problems:
> 
> - mkstemp on RH7.2 is detected (so the bsd-mkstemp.o will be empty),
> but this version needs "XXXXXX" in the file name template, otherwise
> it will return an error (EINVAL). In auth-krb4.c, the current template
> includes just pid and uid, no "X"s. Due to the logic in auth-krb4.c
> this error is misinterpreted as "file already present", with a
> subsequent check on ownership failing. Please not that the bsd-mkstemp()
> handles the situation just fine.

I'll look at this.

> - a rather recent autoconf appears to be needed for AC_SYS_LARGEFILE,
> RH7.2beta ships with  2.13 (too old).

You can get autoconf-2.52 from Redhat Rawhide.

> - compiling openbsd-compat/ shows lots of errors, I haven't sorted
> these out yet (and they could be my fault):

These might be related to Kerberous, I am compiling on RH72beta without
error.

-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 sxw at dcs.ed.ac.uk  Fri Oct 12 23:18:18 2001
From: sxw at dcs.ed.ac.uk (Simon Wilkinson)
Date: Fri, 12 Oct 2001 14:18:18 +0100 (BST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: Damien Miller's message of Fri, 12 Oct 2001 11:47:38 +1000 (EST)
Message-ID: <200110121318.OAA25405@canna.dcs.ed.ac.uk>

> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

Are patches against 2.9.9p2 OK, or would you rather they were against the
latest CVS tree? I've got a set of fixes to make the SSH v1 Kerberos stuff
compile against the MIT libraries.

Cheers,

Simon.


From djm at mindrot.org  Fri Oct 12 23:23:56 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Oct 2001 23:23:56 +1000 (EST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <200110121318.OAA25405@canna.dcs.ed.ac.uk>
Message-ID: <Pine.LNX.4.33.0110122322460.1211-100000@mothra.mindrot.org>

On Fri, 12 Oct 2001, Simon Wilkinson wrote:

> > If you have any patches you would like us to consider, please resend 
> > them to the list ASAP.
> 
> Are patches against 2.9.9p2 OK, or would you rather they were against the
> latest CVS tree? 

Definitely the latest CVS tree.

> I've got a set of fixes to make the SSH v1 Kerberos stuff
> compile against the MIT libraries.

How did you do that? I thought there were fairly terminal conflicts 
between MIT krb4 and libcrypto?

-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 sxw at dcs.ed.ac.uk  Fri Oct 12 23:43:50 2001
From: sxw at dcs.ed.ac.uk (Simon Wilkinson)
Date: Fri, 12 Oct 2001 14:43:50 +0100 (BST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: Damien Miller's message of Fri, 12 Oct 2001 23:23:56 +1000 (EST)
Message-ID: <200110121343.OAA26148@canna.dcs.ed.ac.uk>

> On Fri, 12 Oct 2001, Simon Wilkinson wrote:
> > Are patches against 2.9.9p2 OK, or would you rather they were against the
> > latest CVS tree? 
> 
> Definitely the latest CVS tree.

Ok - I'll pull it over and update my patches.

> > I've got a set of fixes to make the SSH v1 Kerberos stuff
> > compile against the MIT libraries.
> 
> How did you do that? I thought there were fairly terminal conflicts 
> between MIT krb4 and libcrypto?

Not the krb4 stuff (which is where the library conflict is), but the new 
krb5 code. In other words - my patch makes it build with KRB5 defined.

Cheers,

Simon.


From ed at UDel.Edu  Sat Oct 13 00:33:08 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 12 Oct 2001 10:33:08 -0400 (EDT)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <Pine.SOL.4.30.0110121031230.21980-100000@mahler.udel.edu>

On Fri, 12 Oct 2001, Damien Miller wrote:

> Date: Fri, 12 Oct 2001 11:47:38 +1000 (EST)
> From: Damien Miller <djm at mindrot.org>
> To: openssh-unix-dev at mindrot.org
> Subject: Please test snapshots for 3.0 release
>
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
>
> If you have any patches you would like us to consider, please resend
> them to the list ASAP.

I don't know if this has been fixed in the current snapshot... but in
2.9.9p2 the following needs to be fixed to compile cleanly on Sol8 with
Sun's compilers:

*** ./session.c_orig    Wed Oct 10 16:20:37 2001
--- ./session.c Wed Oct 10 16:22:34 2001
***************
*** 139,144 ****
--- 139,148 ----
  static void session_close(Session *);
  static int session_pty_req(Session *);

+ #ifdef LOGIN_NEEDS_UTMPX
+ void do_pre_login(Session *s);
+ #endif
+
  /* import */
  extern ServerOptions options;
  extern char *__progname;


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 mdb at juniper.net  Sat Oct 13 01:10:11 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 12 Oct 2001 08:10:11 -0700
Subject: Please test snapshots for 3.0 release 
In-Reply-To: Mail from Damien Miller <djm@mindrot.org> 
             dated Fri, 12 Oct 2001 20:45:09 +1000
             <Pine.LNX.4.33.0110122040320.1211-100000@mothra.mindrot.org> 
Message-ID: <200110121510.f9CFAB055939@merlot.juniper.net>

Hi Damien,

On Redhat 6.2 Linux, using autoconf-2.52-6 with openssl-0.9.6b

  % cd openssh_cvs
  % autoconf
  % ./configure
  ...
  config.status: error: cannot find input file: config.h.in
  %

make does not get very far as it rally wants there to be a config.h
around somewhere... creating an empty config.h.in file goes through
the configure step without errors...

But then a 'make' has problems in openbsd-compat (info follows my
.signature).

	Thanks,
	-- Mark

% ./configure --prefix=/opt/experimental --with-ssl-dir=/opt/experimental --with-ipv4-default && make
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... 
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking whether byte ordering is bigendian... no
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking for ar... /usr/bin/ar
checking for perl5... no
checking for perl... /usr/local/bin/perl
checking for ent... no
checking for filepriv... no
checking for bash... /bin/bash
checking for ksh... (cached) /bin/bash
checking for sh... (cached) /bin/bash
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGE_FILES value needed for large files... no
checking for login... /bin/login
checking for gcc option to accept ANSI C... none needed
checking for inline... inline
checking for yp_match in -lnsl... yes
checking for main in -lsocket... no
checking for innetgr in -lrpc... no
checking for getspnam in -lgen... no
checking for deflate in -lz... yes
checking for login in -lutil... yes
checking for regcomp... yes
checking for strcasecmp... yes
checking for utimes... yes
checking for strftime... yes
checking for bstring.h... no
checking for crypt.h... yes
checking for endian.h... yes
checking for floatingpoint.h... no
checking for getopt.h... yes
checking for glob.h... yes
checking for lastlog.h... yes
checking for libgen.h... yes
checking for limits.h... yes
checking for login.h... no
checking for login_cap.h... no
checking for maillock.h... no
checking for netdb.h... yes
checking for netgroup.h... no
checking for netinet/in_systm.h... yes
checking for paths.h... yes
checking for poll.h... yes
checking for pty.h... yes
checking for regex.h... yes
checking for shadow.h... yes
checking for security/pam_appl.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/bitypes.h... yes
checking for sys/bsdtty.h... no
checking for sys/cdefs.h... yes
checking for sys/poll.h... yes
checking for sys/queue.h... yes
checking for sys/select.h... yes
checking for sys/stat.h... yes
checking for sys/stropts.h... yes
checking for sys/sysmacros.h... yes
checking for sys/time.h... yes
checking for sys/ttcompat.h... no
checking for sys/un.h... yes
checking for stddef.h... yes
checking for time.h... yes
checking for ttyent.h... yes
checking for usersec.h... no
checking for util.h... no
checking for utime.h... yes
checking for utmp.h... yes
checking for utmpx.h... yes
checking for GLOB_ALTDIRFUNC support... yes
checking for gl_matchc field in glob_t... no
checking whether struct dirent allocates space for d_name... yes
checking for arc4random... no
checking for atexit... yes
checking for b64_ntop... no
checking for bcopy... yes
checking for bindresvport_sa... no
checking for clock... yes
checking for dirname... yes
checking for fchown... yes
checking for fchmod... yes
checking for freeaddrinfo... yes
checking for futimes... no
checking for gai_strerror... yes
checking for getcwd... yes
checking for getaddrinfo... yes
checking for getgrouplist... no
checking for getopt... yes
checking for getnameinfo... yes
checking for getrlimit... yes
checking for getrusage... yes
checking for getttyent... yes
checking for glob... yes
checking for inet_aton... yes
checking for inet_ntoa... yes
checking for inet_ntop... yes
checking for innetgr... yes
checking for login_getcapbool... no
checking for md5_crypt... no
checking for memmove... yes
checking for mkdtemp... no
checking for on_exit... yes
checking for openpty... yes
checking for readpassphrase... no
checking for realpath... yes
checking for rresvport_af... no
checking for setdtablesize... no
checking for setenv... yes
checking for setegid... yes
checking for seteuid... yes
checking for setlogin... no
checking for setproctitle... no
checking for setresgid... yes
checking for setreuid... yes
checking for setrlimit... yes
checking for setsid... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for sigvec... yes
checking for snprintf... yes
checking for strerror... yes
checking for strlcat... no
checking for strlcpy... no
checking for strmode... no
checking for strsep... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for utimes... (cached) yes
checking for vsnprintf... yes
checking for vhangup... yes
checking for waitpid... yes
checking for _getpty... no
checking for __b64_ntop... no
checking for gettimeofday... yes
checking for time... yes
checking for libutil.h... no
checking for login... yes
checking for logout... yes
checking for updwtmp... yes
checking for logwtmp... yes
checking for endutent... yes
checking for getutent... yes
checking for getutid... yes
checking for getutline... yes
checking for pututline... yes
checking for setutent... yes
checking for utmpname... yes
checking for endutxent... yes
checking for getutxent... yes
checking for getutxid... yes
checking for getutxline... yes
checking for pututxline... yes
checking for setutxent... yes
checking for utmpxname... yes
checking for getuserattr... no
checking for getuserattr in -ls... no
checking for login... (cached) yes
checking for daemon... yes
checking for getpagesize... yes
checking whether snprintf correctly terminates long strings... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... (cached) yes
checking for inttypes.h... yes
checking for stdint.h... (cached) yes
checking for unistd.h... yes
checking whether getpgrp takes no argument... yes
checking for OpenSSL directory... /opt/experimental
checking for RSA support... yes
checking for crypt in -lcrypt... yes
checking for char... yes
checking size of char... 1
checking for short int... yes
checking size of short int... 2
checking for int... yes
checking size of int... 4
checking for long int... yes
checking size of long int... 4
checking for long long int... yes
checking size of long long int... 8
checking for u_int type... yes
checking for intXX_t types... yes
checking for int64_t type... yes
checking for u_intXX_t types... yes
checking for u_int64_t types... yes
checking for uintXX_t types in stdint.h... yes
checking for u_char... yes
checking for socklen_t... yes
checking for size_t... yes
checking for ssize_t... yes
checking for clock_t... yes
checking for sa_family_t... yes
checking for pid_t... yes
checking for mode_t... yes
checking for struct sockaddr_storage... yes
checking for struct sockaddr_in6... yes
checking for struct in6_addr... yes
checking for struct addrinfo... yes
checking for struct timeval... yes
checking for ut_host field in utmp.h... yes
checking for ut_host field in utmpx.h... yes
checking for syslen field in utmpx.h... no
checking for ut_pid field in utmp.h... yes
checking for ut_type field in utmp.h... yes
checking for ut_type field in utmpx.h... yes
checking for ut_tv field in utmp.h... yes
checking for ut_id field in utmp.h... yes
checking for ut_id field in utmpx.h... yes
checking for ut_addr field in utmp.h... yes
checking for ut_addr field in utmpx.h... yes
checking for ut_addr_v6 field in utmp.h... yes
checking for ut_addr_v6 field in utmpx.h... yes
checking for ut_exit field in utmp.h... yes
checking for ut_time field in utmp.h... no
checking for ut_time field in utmpx.h... no
checking for ut_tv field in utmpx.h... yes
checking for struct stat.st_blksize... yes
checking for ss_family field in struct sockaddr_storage... no
checking for __ss_family field in struct sockaddr_storage... yes
checking for pw_class field in struct passwd... no
checking for pw_expire field in struct passwd... no
checking for pw_change field in struct passwd... no
checking if libc defines __progname... yes
checking whether getopt has optreset support... no
checking if libc defines sys_errlist... yes
checking if libc defines sys_nerr... yes
checking for rsh... /usr/kerberos/bin/rsh
checking for xauth... /usr/X11R6/bin/xauth
checking for "/dev/ptc"... no
checking for "/dev/urandom"... yes
checking for nroff... /usr/bin/nroff
checking if the systems has expire shadow information... yes
Adding /opt/experimental/bin to USER_PATH so scp will work
checking if we need to convert IPv4 in IPv6-mapped addresses... yes (default)
checking whether to install ssh as suid root... yes
checking if your system defines LASTLOG_FILE... no
checking if your system defines _PATH_LASTLOG... yes
checking if your system defines UTMP_FILE... yes
checking if your system defines WTMP_FILE... yes
checking if your system defines UTMPX_FILE... no
checking if your system defines WTMPX_FILE... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating openbsd-compat/Makefile
config.status: creating scard/Makefile
config.status: creating ssh_prng_cmds
config.status: creating config.h
config.status: config.h is unchanged

OpenSSH has been configured with the following options:
                 User binaries: /opt/experimental/bin
               System binaries: /opt/experimental/sbin
           Configuration files: /opt/experimental/etc
               Askpass program: /opt/experimental/libexec/ssh-askpass
                  Manual pages: /opt/experimental/man/manX
                      PID file: /var/run
        sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/opt/experimental/bin
      Random number collection: Device (/dev/urandom)
                Manpage format: doc
                   PAM support: no
            KerberosIV support: no
             Smartcard support: no
                   AFS support: no
                 S/KEY support: no
          TCP Wrappers support: no
          MD5 password support: no
   IP address in $DISPLAY hack: no
      Use IPv4 by default hack: yes
       Translate v4 in v6 hack: yes

              Host: i686-pc-linux-gnu
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags: -I/opt/experimental/include 
      Linker flags: -L/opt/experimental/lib 
         Libraries: -lz -lnsl  -lutil -lcrypto -lcrypt 

(cd openbsd-compat; make)
make[1]: Entering directory `/home/mdb/src/openssh/openssh_cvs/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/opt/experimental/include  -DHAVE_CONFIG_H -c bsd-arc4random.c
In file included from ../openbsd-compat/openbsd-compat.h:34,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/bsd-waitpid.h:40: warning: `WEXITSTATUS' redefined
/usr/include/sys/wait.h:83: warning: this is the location of the previous definition
../openbsd-compat/bsd-waitpid.h:41: warning: `WTERMSIG' redefined
/usr/include/sys/wait.h:84: warning: this is the location of the previous definition
../openbsd-compat/bsd-waitpid.h:42: warning: `WCOREFLAG' redefined
/usr/include/sys/wait.h:91: warning: this is the location of the previous definition
../openbsd-compat/bsd-waitpid.h:43: warning: `WCOREDUMP' redefined
/usr/include/sys/wait.h:92: warning: this is the location of the previous definition
In file included from ../openbsd-compat/openbsd-compat.h:39,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/fake-socket.h:11: warning: `_SS_PADSIZE' redefined
/usr/include/bits/socket.h:151: warning: this is the location of the previous definition
In file included from ../openbsd-compat/openbsd-compat.h:23,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/strsep.h:9: parse error before `__extension__'
../openbsd-compat/strsep.h:9: parse error before `('
In file included from ../openbsd-compat/openbsd-compat.h:32,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/bsd-misc.h:66: redefinition of `struct timeval'
../openbsd-compat/bsd-misc.h:72: two or more data types in declaration of `utimes'
In file included from ../openbsd-compat/openbsd-compat.h:39,
                 from ../includes.h:102,
                 from bsd-arc4random.c:25:
../openbsd-compat/fake-socket.h:13: redefinition of `struct sockaddr_storage'
../openbsd-compat/fake-socket.h:27: redefinition of `struct in6_addr'
../openbsd-compat/fake-socket.h:28: warning: no semicolon at end of struct or union
../openbsd-compat/fake-socket.h:28: parse error before `.'
../openbsd-compat/fake-socket.h:33: redefinition of `struct sockaddr_in6'
make[1]: *** [bsd-arc4random.o] Error 1
make[1]: Leaving directory `/home/mdb/src/openssh/openssh_cvs/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2


From djm at mindrot.org  Sat Oct 13 01:43:47 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 13 Oct 2001 01:43:47 +1000 (EST)
Subject: Please test snapshots for 3.0 release 
In-Reply-To: <200110121510.f9CFAB055939@merlot.juniper.net>
Message-ID: <Pine.LNX.4.33.0110130142500.1211-100000@mothra.mindrot.org>

On Fri, 12 Oct 2001, Mark D. Baushke wrote:

> Hi Damien,
> 
> On Redhat 6.2 Linux, using autoconf-2.52-6 with openssl-0.9.6b
> 
>   % cd openssh_cvs
>   % autoconf
>   % ./configure
>   ...
>   config.status: error: cannot find input file: config.h.in

I don't think autoconf would have every worked by itself. Do 
"autoreconf" or "autoheader ; autoconf". Expect a few warnings.


-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 Jewnix at technohac.com  Sun Oct 14 01:54:55 2001
From: Jewnix at technohac.com (Gil Disatnik)
Date: Sat, 13 Oct 2001 17:54:55 +0200
Subject: OpenSSH name resolving problems
In-Reply-To: <Pine.LNX.4.33.0110110945490.1639-100000@mothra.mindrot.org
 >
References: <5.1.0.14.2.20011010233431.025d81c0@pop3.norton.antivirus>
Message-ID: <5.1.0.14.2.20011013173120.00aa2670@pop3.norton.antivirus>


>The server end is stalling on a reverse lookup. You can switch this
>behaviour off (read the manpage).

- I believe this is not correct, as I noticed that in case of timeout in 
reverse lookup
I am being stalled right after:
debug1: channel 0: open confirm rwindow 0 rmax 16384

When testing ssh between 2 different machines this is what happens:
root at machine2:~# ssh machine1 -v -v -v
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 1000 geteuid 0 anon 1
<============> HERE IT GETS STALLED FOR A FEW SECONDS...

when running:
root at machine2:~# ssh <ip of machine1> -l root -v -v -v
Everything works fine... don't tell me the other side knows if I had to 
resolve it's IP before ;)

Remember - I have no active DNS working at these machines and 
/etc/resolve.conf had some DNS entries, but /etc/nsswitch.conf shows files 
before DNS... and of course I am having machine1's IP at /etc/hosts of 
machine2 and vice versa.

Another interesting test I have performed:
In my other machine I have commented out all entries at /etc/resolve.conf.
When running ssh localhost -v -v -v - everything works fine. When I 
uncommented the entries - I got the a few seconds delay from the DNS (when 
it told me that it can't resolve localhost...)

> > P.S - I am still waiting for any answer regarding my previous question
> > about the fact that I can't exit from a shell when I have background
> > jobs... It is really important... please help me here...
>
>This has been discussed at length, check the archives.

Yes, I saw it, thanks and sorry... The other issue I was crying about a few 
months ago (wrong returned code when running a remote application (gives 
back 255) is being discussed as well at last, ;))


>-d
>
>--
>| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's
>| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer


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 mdb at juniper.net  Sat Oct 13 02:31:17 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 12 Oct 2001 09:31:17 -0700
Subject: Please test snapshots for 3.0 release 
In-Reply-To: Mail from Damien Miller <djm@mindrot.org> 
             dated Sat, 13 Oct 2001 01:43:47 +1000
             <Pine.LNX.4.33.0110130142500.1211-100000@mothra.mindrot.org> 
Message-ID: <200110121631.f9CGVH059210@merlot.juniper.net>

Hi Damien,

>I don't think autoconf would have every worked by itself. Do 
>"autoreconf" or "autoheader ; autoconf". Expect a few warnings.

Using "autoreconf" let me build with no problems (or warnings).

	Thanks,
	-- Mark


From johnh at aproposretail.com  Sat Oct 13 02:57:56 2001
From: johnh at aproposretail.com (John Hardin)
Date: Fri, 12 Oct 2001 09:57:56 -0700
Subject: OpenSSH name resolving problems
References: <5.1.0.14.2.20011010233431.025d81c0@pop3.norton.antivirus> <5.1.0.14.2.20011013173120.00aa2670@pop3.norton.antivirus>
Message-ID: <3BC72114.3090901@aproposretail.com>

Gil Disatnik wrote:
 >

> Remember - I have no active DNS working at these machines and 
> /etc/resolve.conf had some DNS entries, but /etc/nsswitch.conf shows 
> files before DNS... and of course I am having machine1's IP at 
> /etc/hosts of machine2 and vice versa.

I don't know if this is at all relevant, but I'm seeing similar behavior 
in the latest telnet release from Redhat for 6.2:

Even though the remote host appears in /etc/hosts and /etc/nsswitch.conf 
  has "files" before "dns", when you run "telnet {hostname}" you see a 
delay, but "telnet {ipaddr}" works immediately. "ssh {hostname}" 
(2.5.2p2) and "ping {hostname}" also respond immediately, which is very 
strange.

Might there be some wierdness in the glibc-2.1.3-22 resolver library 
that the new telnet and the new ssh are tickling?

-- 
John Hardin                                   <johnh at aproposretail.com>
Internal Systems Administrator                    voice: (425) 672-1304
Apropos Retail Management Systems, Inc.             fax: (425) 672-0192
-----------------------------------------------------------------------
  16 days until Daylight Savings Time ends



From dwd at bell-labs.com  Sat Oct 13 06:34:52 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 12 Oct 2001 15:34:52 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 12, 2001 at 11:47:38AM +1000
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <20011012153452.A18421@lucent.com>

On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> Subject: Re: Please test snapshots for 3.0 release
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
> 
> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

I have posted this one several times and I ask that you *please* put it
in.  Many people have asked for this one, and Markus has done all the
preparatory work in the base code so changes only need to be made to the
portable code.  It works for all systems that use /etc/shadow, most notably
Solaris and Linux.

Below is the patch updated to the latest CVS.  Don't forget to run
autoheader and autoconf before re-running configure.

- Dave Dykstra


--- auth.c.O	Fri Oct 12 14:42:38 2001
+++ auth.c	Fri Oct 12 14:57:29 2001
@@ -49,6 +49,9 @@
 #include "uidswap.h"
 #include "tildexpand.h"
 
+/* set when password has expired */
+int forced_passwd_change = 0;
+
 /* import */
 extern ServerOptions options;
 
@@ -89,8 +92,12 @@
 
 		/* Check password expiry */
 		if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) &&
-		    (days > (spw->sp_lstchg + spw->sp_max)))
-			return 0;
+		    (days > (spw->sp_lstchg + spw->sp_max))) {
+			if ((pw->pw_uid == 0))
+				return 0;
+
+			forced_passwd_change = 1;
+		}
 	}
 #else
 	/* Shouldn't be called if pw is NULL, but better safe than sorry... */
--- auth.h.O	Thu Aug 23 13:18:52 2001
+++ auth.h	Fri Oct 12 15:00:10 2001
@@ -40,6 +40,9 @@
 #include <krb5.h>
 #endif
 
+/* set when password has expired */
+extern int forced_passwd_change;
+
 typedef struct Authctxt Authctxt;
 typedef struct KbdintDevice KbdintDevice;
 
--- session.c.O	Fri Oct 12 14:42:41 2001
+++ session.c	Fri Oct 12 15:04:29 2001
@@ -656,7 +656,31 @@
 void
 do_exec(Session *s, const char *command)
 {
-	if (forced_command) {
+	if (forced_passwd_change) {
+		char *user = s->pw->pw_name;
+		char *msg;
+
+		if (s->ttyfd != -1) {
+			msg = "Password for %.100s has expired, running 'passwd' to reset it";
+			/*
+			 * Can't pass "user" to 'passwd' because Linux doesn't
+			 * allow it.
+			 * Also, the prompt is friendlier without "user".
+			 */
+			command = PASSWD_PATH;
+		} else {
+			msg = "Password for %.100s has expired and cannot be changed without a pty";
+			/*
+			 * Without a pty, Solaris 'passwd' prints "Permission
+			 * denied", but Linux attempts to change the password
+			 * and fails miserably, so echo an error message instead
+			 */
+			command = "/bin/sh -c 'echo Permission denied >&2; exit 1'";
+		}
+		log(msg, user);
+		packet_send_debug(msg, user);
+
+	} else if (forced_command) {
 		original_command = command;
 		command = forced_command;
 		debug("Forced command '%.900s'", command);
--- configure.in.O	Fri Oct 12 14:42:39 2001
+++ configure.in	Fri Oct 12 15:00:57 2001
@@ -1449,6 +1449,10 @@
 	AC_DEFINE_UNQUOTED(RSH_PATH, "$rsh_path")
 fi
 
+AC_PATH_PROG(PASSWD_PATH, passwd)
+AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
+
+
 # Check for mail directory (last resort if we cannot get it from headers)
 if test ! -z "$MAIL" ; then
 	maildir=`dirname $MAIL`
--- acconfig.h.O	Fri Oct 12 14:42:37 2001
+++ acconfig.h	Fri Oct 12 14:58:43 2001
@@ -214,6 +214,9 @@
 /* Define if rsh is found in your path */
 #undef RSH_PATH
 
+/* Define if passwd is found in your path */
+#undef PASSWD_PATH
+
 /* Define if you want to allow MD5 passwords */
 #undef HAVE_MD5_PASSWORDS
 


From mouring at etoh.eviladmin.org  Sat Oct 13 06:39:14 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 12 Oct 2001 15:39:14 -0500 (CDT)
Subject: Solaris packaging
Message-ID: <Pine.BSO.4.33.0110121532230.32713-100000@etoh.eviladmin.org>


When the new night builds occur (10/13) there should be a new solaris
package for those running Solaris.  Read the 'README' file as to the
current problems.

Please.. please.. *PLEASE*  (begging) test this.  The only feature I'm
going to add before 3.0 is a postinstall script that will handle
sshd_config and ssh_config correctly (which are not.  They are
overwritten.. You have been warned!).  Which will stop sshd_config and
ssh_config from being removed also at deinstall.

=) Have to start somewhere.

Features of this new package script.  It is a 'Fake root' build.  So all
files should be installed correctly, manpages should be done right, and it
is much easier to read scripts.  This script *SHOULD* handle --prefix,
--sysconfdir correctly.  I think the only one I'm not accounting for
currently is --piddir, but if someone that uses that function needs it
drop me a unified diff.

Also, an updated runtime script which handles key creation at startup time
(instead of at install time.  Which should help those doing jump start
installs).

- Ben



From dwd at bell-labs.com  Sat Oct 13 06:40:41 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 12 Oct 2001 15:40:41 -0500
Subject: Patch to workaround host key size mismatch bug in old SSH sshd
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 12, 2001 at 11:47:38AM +1000
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <20011012154041.B18421@lucent.com>

On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> Subject: Re: Please test snapshots for 3.0 release
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
> 
> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

I have posted this one twice.  I have tested it with the latest portable
CVS, but it needs to apply to the openbsd CVS.  It applies cleanly there.
Please apply it, Markus.

- Dave Dykstra


--- compat.h.O	Fri Oct 12 15:26:49 2001
+++ compat.h	Fri Oct 12 15:27:21 2001
@@ -51,6 +51,7 @@
 #define SSH_BUG_OPENFAILURE	0x00020000
 #define SSH_BUG_DERIVEKEY	0x00040000
 #define SSH_BUG_DUMMYCHAN	0x00100000
+#define SSH_BUG_SERVERLIESSIZE	0x00200000
 
 void     enable_compat13(void);
 void     enable_compat20(void);
--- compat.c.O	Fri Oct 12 14:42:39 2001
+++ compat.c	Fri Oct 12 15:27:50 2001
@@ -117,6 +117,8 @@
 		{ "^1\\.7 SecureFX",	SSH_OLD_SESSIONID },
 		{ "^1\\.2\\.1[89]",	SSH_BUG_IGNOREMSG },
 		{ "^1\\.2\\.2[012]",	SSH_BUG_IGNOREMSG },
+		{ "^1\\.2\\.2[3-9]",	SSH_BUG_SERVERLIESSIZE },
+		{ "^1\\.2\\.3[0-1]",	SSH_BUG_SERVERLIESSIZE },
 		{ "^1\\.3\\.2",		SSH_BUG_IGNOREMSG },	/* f-secure */
 		{ "^SSH Compatible Server",			/* Netscreen */
 					SSH_BUG_PASSWORDPAD },
--- sshconnect1.c.O	Fri Oct 12 14:42:43 2001
+++ sshconnect1.c	Fri Oct 12 15:30:16 2001
@@ -37,6 +37,7 @@
 #include "packet.h"
 #include "mpaux.h"
 #include "uidswap.h"
+#include "compat.h"
 #include "log.h"
 #include "readconf.h"
 #include "key.h"
@@ -960,7 +961,8 @@
 	sum_len += clen;
 
 	rbits = BN_num_bits(host_key->n);
-	if (bits != rbits) {
+	if (bits != rbits &&
+	    !((datafellows & SSH_BUG_SERVERLIESSIZE) && (rbits + 1 == bits))) {
 		log("Warning: Server lies about size of server host key: "
 		    "actual size is %d bits vs. announced %d.", rbits, bits);
 		log("Warning: This may be due to an old implementation of ssh.");
--- sshd.c.O	Fri Oct 12 14:42:43 2001
+++ sshd.c	Fri Oct 12 15:31:18 2001
@@ -1263,7 +1263,12 @@
 	packet_put_bignum(sensitive_data.server_key->rsa->n);
 
 	/* Store our public host RSA key. */
-	packet_put_int(BN_num_bits(sensitive_data.ssh1_host_key->rsa->n));
+	len = BN_num_bits(sensitive_data.ssh1_host_key->rsa->n);
+	if ((datafellows & SSH_BUG_SERVERLIESSIZE) && (len & 1)) {
+	    /* old ssh client expects even number for host key */
+	    len += 1;
+	}
+	packet_put_int(len);
 	packet_put_bignum(sensitive_data.ssh1_host_key->rsa->e);
 	packet_put_bignum(sensitive_data.ssh1_host_key->rsa->n);
 


From dwd at bell-labs.com  Sat Oct 13 06:59:39 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 12 Oct 2001 15:59:39 -0500
Subject: Patches for improved logging of allowed_user() failures
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 12, 2001 at 11:47:38AM +1000
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <20011012155939.A18591@lucent.com>

On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> Subject: Re: Please test snapshots for 3.0 release
>
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
> 
> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

I originally included these changes with my patch for changing expired
passwords, but to simplify that submission I left them out.  Attachment #1
contains the patch against the openbsd CVS, and attachment #2 contains the
patch aginst the portable CVS apply after applying my patch for changing
expired passwords.  They could be applied independently, but for
consistency through the function it would make sense for both to be
applied.

- Dave Dykstra
-------------- next part --------------
--- auth.c.O	Fri Oct 12 15:43:11 2001
+++ auth.c	Fri Oct 12 15:43:15 2001
@@ -71,10 +71,16 @@
 	shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell;
 
 	/* deny if shell does not exists or is not executable */
-	if (stat(shell, &st) != 0)
+	if (stat(shell, &st) != 0) {
+		log("User %.100s not allowed because shell %.100s does not exist",
+			pw->pw_name, shell);
 		return 0;
-	if (!((st.st_mode & S_IFREG) && (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP))))
+	}
+	if (!((st.st_mode & S_IFREG) && (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP)))) {
+		log("User %.100s not allowed because shell %.100s is not executable",
+			pw->pw_name, shell);
 		return 0;
+	}
 
 	if (options.num_deny_users > 0 || options.num_allow_users > 0) {
 		hostname = get_canonical_hostname(options.reverse_mapping_check);
@@ -85,8 +91,11 @@
 	if (options.num_deny_users > 0) {
 		for (i = 0; i < options.num_deny_users; i++)
 			if (match_user(pw->pw_name, hostname, ipaddr,
-			    options.deny_users[i]))
+			    options.deny_users[i])) {
+				log("User %.100s not allowed because listed in DenyUsers",
+					pw->pw_name);
 				return 0;
+			}
 	}
 	/* Return false if AllowUsers isn't empty and user isn't listed there */
 	if (options.num_allow_users > 0) {
@@ -95,19 +104,27 @@
 			    options.allow_users[i]))
 				break;
 		/* i < options.num_allow_users iff we break for loop */
-		if (i >= options.num_allow_users)
+		if (i >= options.num_allow_users) {
+			log("User %.100s not allowed because not listed in AllowUsers",
+				pw->pw_name);
 			return 0;
+		}
 	}
 	if (options.num_deny_groups > 0 || options.num_allow_groups > 0) {
 		/* Get the user's group access list (primary and supplementary) */
-		if (ga_init(pw->pw_name, pw->pw_gid) == 0)
+		if (ga_init(pw->pw_name, pw->pw_gid) == 0) {
+			log("User %.100s not allowed because not in any group",
+				pw->pw_name);
 			return 0;
+		}
 
 		/* Return false if one of user's groups is listed in DenyGroups */
 		if (options.num_deny_groups > 0)
 			if (ga_match(options.deny_groups,
 			    options.num_deny_groups)) {
 				ga_free();
+				log("User %.100s not allowed because a group is listed in DenyGroups",
+					pw->pw_name);
 				return 0;
 			}
 		/*
@@ -118,6 +135,8 @@
 			if (!ga_match(options.allow_groups,
 			    options.num_allow_groups)) {
 				ga_free();
+				log("User %.100s not allowed because none of user's group are listed in AllowGroups",
+					pw->pw_name);
 				return 0;
 			}
 		ga_free();
-------------- next part --------------
--- auth.c.N	Fri Oct 12 15:54:56 2001
+++ auth.c	Fri Oct 12 15:56:50 2001
@@ -87,14 +87,20 @@
 		int days = time(NULL) / 86400;
 
 		/* Check account expiry */
-		if ((spw->sp_expire >= 0) && (days > spw->sp_expire))
+		if ((spw->sp_expire >= 0) && (days > spw->sp_expire)) {
+			log("User %.100s not allowed because account expired",
+				pw->pw_name);
 			return 0;
+		}
 
 		/* Check password expiry */
 		if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) &&
 		    (days > (spw->sp_lstchg + spw->sp_max))) {
-			if ((pw->pw_uid == 0))
+			if ((pw->pw_uid == 0)) {
+				log("User %.100s not allowed because password expired",
+					pw->pw_name);
 				return 0;
+			}
 
 			forced_passwd_change = 1;
 		}

From dwd at bell-labs.com  Sat Oct 13 07:16:24 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 12 Oct 2001 16:16:24 -0500
Subject: Patch for openbsd-compat/readpassphrase.c missing _POSIX_VDISABLE
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 12, 2001 at 11:47:38AM +1000
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <20011012161624.A19190@lucent.com>

On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> Subject: Re: Please test snapshots for 3.0 release
>
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
> 
> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

Needed to compile at least on sunos 4.1.4.

- Dave Dykstra


--- openbsd-compat/readpassphrase.c.O	Fri Oct 12 17:12:22 2001
+++ openbsd-compat/readpassphrase.c	Fri Oct 12 17:11:16 2001
@@ -97,11 +97,13 @@
 			term.c_lflag &= ~ECHO;
 		}
 #ifdef VSTATUS
+#ifdef _POSIX_VDISABLE
 		if (term.c_cc[VSTATUS] != _POSIX_VDISABLE) {
 			status = term.c_cc[VSTATUS];
 			term.c_cc[VSTATUS] = _POSIX_VDISABLE;
 		}
 #endif
+#endif
 		(void)tcsetattr(input, _T_FLUSH, &term);
 	}
 	if (!(flags & RPP_ECHO_ON)) {
@@ -138,8 +140,10 @@
 			term.c_lflag |= ECHO;
 		}
 #ifdef VSTATUS
+#ifdef _POSIX_VDISABLE
 		if (status != _POSIX_VDISABLE)
 			term.c_cc[VSTATUS] = status;
+#endif
 #endif
 		(void)tcsetattr(input, _T_FLUSH, &term);
 	}


From stevesk at pobox.com  Sat Oct 13 07:36:06 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 12 Oct 2001 14:36:06 -0700 (PDT)
Subject: Patch for changing expired passwords
In-Reply-To: <20011012153452.A18421@lucent.com>
Message-ID: <Pine.HPX.4.40.0110121429560.1707-100000@jenny>

On Fri, 12 Oct 2001, Dave Dykstra wrote:
:I have posted this one several times and I ask that you *please* put it
:in.  Many people have asked for this one, and Markus has done all the
:preparatory work in the base code so changes only need to be made to the
:portable code.  It works for all systems that use /etc/shadow, most notably
:Solaris and Linux.

as i said i august, i think much of this could be pushed to native.
markus indicated willingness to add something for the non BSD_AUTH case
there.



From imorgan at nas.nasa.gov  Sat Oct 13 07:42:28 2001
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 12 Oct 2001 14:42:28 -0700 (PDT)
Subject: Patch for changing expired passwords
In-Reply-To: <20011012153452.A18421@lucent.com> from "Dave Dykstra" at Oct 12, 2001 03:34:52 PM
Message-ID: <200110122142.OAA555237@nopython.nas.nasa.gov>

A fix for this issue is definitely needed. We have had to back off of
implementing OpenSSH on our SGI's and Crays due to the issue of password
expiration.

At a glance, one item that I would take execption with is the special handling
for root. Perhaps the behaviour for root should be configurable.

On Fri Oct 12 13:34:52 2001, Dave Dykstra wrote:
> 
> On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> > Subject: Re: Please test snapshots for 3.0 release
> > Could everyone please test the latest snapshots as we will be making a
> > new release soon.
> > 
> > If you have any patches you would like us to consider, please resend 
> > them to the list ASAP.
> 
> I have posted this one several times and I ask that you *please* put it
> in.  Many people have asked for this one, and Markus has done all the
> preparatory work in the base code so changes only need to be made to the
> portable code.  It works for all systems that use /etc/shadow, most notably
> Solaris and Linux.
> 
> Below is the patch updated to the latest CVS.  Don't forget to run
> autoheader and autoconf before re-running configure.
> 
> - Dave Dykstra
> 
> 
> --- auth.c.O	Fri Oct 12 14:42:38 2001
> +++ auth.c	Fri Oct 12 14:57:29 2001
> @@ -49,6 +49,9 @@
>  #include "uidswap.h"
>  #include "tildexpand.h"
>  
> +/* set when password has expired */
> +int forced_passwd_change = 0;
> +
>  /* import */
>  extern ServerOptions options;
>  
> @@ -89,8 +92,12 @@
>  
>  		/* Check password expiry */
>  		if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) &&
> -		    (days > (spw->sp_lstchg + spw->sp_max)))
> -			return 0;
> +		    (days > (spw->sp_lstchg + spw->sp_max))) {
> +			if ((pw->pw_uid == 0))
> +				return 0;
> +
> +			forced_passwd_change = 1;
> +		}
>  	}
>  #else
>  	/* Shouldn't be called if pw is NULL, but better safe than sorry... */
> --- auth.h.O	Thu Aug 23 13:18:52 2001
> +++ auth.h	Fri Oct 12 15:00:10 2001
> @@ -40,6 +40,9 @@
>  #include <krb5.h>
>  #endif
>  
> +/* set when password has expired */
> +extern int forced_passwd_change;
> +
>  typedef struct Authctxt Authctxt;
>  typedef struct KbdintDevice KbdintDevice;
>  
> --- session.c.O	Fri Oct 12 14:42:41 2001
> +++ session.c	Fri Oct 12 15:04:29 2001
> @@ -656,7 +656,31 @@
>  void
>  do_exec(Session *s, const char *command)
>  {
> -	if (forced_command) {
> +	if (forced_passwd_change) {
> +		char *user = s->pw->pw_name;
> +		char *msg;
> +
> +		if (s->ttyfd != -1) {
> +			msg = "Password for %.100s has expired, running 'passwd' to reset it";
> +			/*
> +			 * Can't pass "user" to 'passwd' because Linux doesn't
> +			 * allow it.
> +			 * Also, the prompt is friendlier without "user".
> +			 */
> +			command = PASSWD_PATH;
> +		} else {
> +			msg = "Password for %.100s has expired and cannot be changed without a pty";
> +			/*
> +			 * Without a pty, Solaris 'passwd' prints "Permission
> +			 * denied", but Linux attempts to change the password
> +			 * and fails miserably, so echo an error message instead
> +			 */
> +			command = "/bin/sh -c 'echo Permission denied >&2; exit 1'";
> +		}
> +		log(msg, user);
> +		packet_send_debug(msg, user);
> +
> +	} else if (forced_command) {
>  		original_command = command;
>  		command = forced_command;
>  		debug("Forced command '%.900s'", command);
> --- configure.in.O	Fri Oct 12 14:42:39 2001
> +++ configure.in	Fri Oct 12 15:00:57 2001
> @@ -1449,6 +1449,10 @@
>  	AC_DEFINE_UNQUOTED(RSH_PATH, "$rsh_path")
>  fi
>  
> +AC_PATH_PROG(PASSWD_PATH, passwd)
> +AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
> +
> +
>  # Check for mail directory (last resort if we cannot get it from headers)
>  if test ! -z "$MAIL" ; then
>  	maildir=`dirname $MAIL`
> --- acconfig.h.O	Fri Oct 12 14:42:37 2001
> +++ acconfig.h	Fri Oct 12 14:58:43 2001
> @@ -214,6 +214,9 @@
>  /* Define if rsh is found in your path */
>  #undef RSH_PATH
>  
> +/* Define if passwd is found in your path */
> +#undef PASSWD_PATH
> +
>  /* Define if you want to allow MD5 passwords */
>  #undef HAVE_MD5_PASSWORDS
>  
> 


--
Iain Morgan
NAS Desktop Support Group


From stevesk at pobox.com  Sat Oct 13 07:51:14 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 12 Oct 2001 14:51:14 -0700 (PDT)
Subject: bug report: last login time vs PAM in portability release
In-Reply-To: <245260000.1002907128@starscream>
Message-ID: <Pine.HPX.4.40.0110121449370.1707-100000@jenny>

on hp-ux 11 i see:

$ date;ssh jenny
Fri Oct 12 14:44:13 PDT 2001
Last   successful login for stevesk: Fri Oct 12 10:45:42 PST8PDT 2001 on pts/2
Last unsuccessful login for stevesk: Mon Sep 24 22:55:53 PST8PDT 2001
Last login: Fri Oct 12 10:45:43 2001 from 172.31.1.53
You have mail.

so solaris PAM is different.  can other solaris+PAM users confirm this?

On Fri, 12 Oct 2001, Benn Oshrin wrote:
:There appears to be a problem with the reported last login time for
:v2.9.9p2 (and possibly earlier versions).  This is for PAM enabled Solaris
:hosts (Sol 7 and 8).
:
:Login to a host running stock 2.9.9p2:
:
: benno[~] starscream% date ; slogin hola
: Fri Oct 12 13:10:50 EDT 2001
: Last login: Fri Oct 12 13:10:52 2001 from starscream.cc.c
: SunOS hola 5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-60
: You have new mail.
: benno[~] hola%
:
:Note that the last login time reported is two seconds after the connection
:is initiated.  It appears that this is because pam_open_session is called
:before do_login.  pam_open_session updates the lastlog file.  When do_login
:is called, it reads the already updated lastlog file and reports the time
:of the session just started.  To fix this, I moved the pam_open_session
:call into do_login:
:
:--- session.c   Fri Oct 12 13:05:58 2001
:+++ .snapshot/nightly.3/session.c       Mon Oct  8 15:52:02 2001
:@@ -541,6 +541,11 @@
:        ptyfd = s->ptyfd;
:        ttyfd = s->ttyfd;
:
:+#if defined(USE_PAM)
:+       do_pam_session(s->pw->pw_name, s->tty);
:+       do_pam_setcred(1);
:+#endif
:+
:        /* Fork the child. */
:        if ((pid = fork()) == 0) {
:
:@@ -698,11 +703,6 @@
:                last_login_time = get_last_login_time(pw->pw_uid,
:pw->pw_name,
:                    hostname, sizeof(hostname));
:        }
:-
:-#if defined(USE_PAM)
:-       do_pam_session(s->pw->pw_name, s->tty);
:-       do_pam_setcred(1);
:-#endif
:
:        /* Record that there was a login on that tty from the remote host.
:*/
:        record_login(pid, s->tty, pw->pw_name, pw->pw_uid,
:
:And here's a session from to a host running the patched version:
:
: benno[~] starscream% date ; slogin saluton
: Fri Oct 12 13:16:47 EDT 2001
: Last login: Fri Oct 12 13:05:03 2001 from starscream.cc.c
: SunOS saluton 5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-60
: You have new mail.
: benno[~] saluton%
:
:I hope you find this useful.
:
:-Benn-
:




From mouring at etoh.eviladmin.org  Sat Oct 13 07:58:09 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 12 Oct 2001 16:58:09 -0500 (CDT)
Subject: bug report: last login time vs PAM in portability release
In-Reply-To: <Pine.HPX.4.40.0110121449370.1707-100000@jenny>
Message-ID: <Pine.BSO.4.33.0110121656050.32713-100000@etoh.eviladmin.org>


It is a problem with Solaris.

Linux (Mandrake in this case) does not show this bug.

bash-2.05$ date; ssh localhost
Fri Oct 12 16:59:26 CDT 2001
Last login: Fri Oct 12 15:13:24 2001 from karla.eviladmin.org


But my solaris 2.7 does show it.

- Ben

On Fri, 12 Oct 2001, Kevin Steves wrote:

> on hp-ux 11 i see:
>
> $ date;ssh jenny
> Fri Oct 12 14:44:13 PDT 2001
> Last   successful login for stevesk: Fri Oct 12 10:45:42 PST8PDT 2001 on pts/2
> Last unsuccessful login for stevesk: Mon Sep 24 22:55:53 PST8PDT 2001
> Last login: Fri Oct 12 10:45:43 2001 from 172.31.1.53
> You have mail.
>
> so solaris PAM is different.  can other solaris+PAM users confirm this?
>
> On Fri, 12 Oct 2001, Benn Oshrin wrote:
> :There appears to be a problem with the reported last login time for
> :v2.9.9p2 (and possibly earlier versions).  This is for PAM enabled Solaris
> :hosts (Sol 7 and 8).
> :
> :Login to a host running stock 2.9.9p2:
> :
> : benno[~] starscream% date ; slogin hola
> : Fri Oct 12 13:10:50 EDT 2001
> : Last login: Fri Oct 12 13:10:52 2001 from starscream.cc.c
> : SunOS hola 5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-60
> : You have new mail.
> : benno[~] hola%
> :
> :Note that the last login time reported is two seconds after the connection
> :is initiated.  It appears that this is because pam_open_session is called
> :before do_login.  pam_open_session updates the lastlog file.  When do_login
> :is called, it reads the already updated lastlog file and reports the time
> :of the session just started.  To fix this, I moved the pam_open_session
> :call into do_login:
> :
> :--- session.c   Fri Oct 12 13:05:58 2001
> :+++ .snapshot/nightly.3/session.c       Mon Oct  8 15:52:02 2001
> :@@ -541,6 +541,11 @@
> :        ptyfd = s->ptyfd;
> :        ttyfd = s->ttyfd;
> :
> :+#if defined(USE_PAM)
> :+       do_pam_session(s->pw->pw_name, s->tty);
> :+       do_pam_setcred(1);
> :+#endif
> :+
> :        /* Fork the child. */
> :        if ((pid = fork()) == 0) {
> :
> :@@ -698,11 +703,6 @@
> :                last_login_time = get_last_login_time(pw->pw_uid,
> :pw->pw_name,
> :                    hostname, sizeof(hostname));
> :        }
> :-
> :-#if defined(USE_PAM)
> :-       do_pam_session(s->pw->pw_name, s->tty);
> :-       do_pam_setcred(1);
> :-#endif
> :
> :        /* Record that there was a login on that tty from the remote host.
> :*/
> :        record_login(pid, s->tty, pw->pw_name, pw->pw_uid,
> :
> :And here's a session from to a host running the patched version:
> :
> : benno[~] starscream% date ; slogin saluton
> : Fri Oct 12 13:16:47 EDT 2001
> : Last login: Fri Oct 12 13:05:03 2001 from starscream.cc.c
> : SunOS saluton 5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-60
> : You have new mail.
> : benno[~] saluton%
> :
> :I hope you find this useful.
> :
> :-Benn-
> :
>
>
>



From openssh-unix-dev at thewrittenword.com  Sat Oct 13 08:11:52 2001
From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com)
Date: Fri, 12 Oct 2001 17:11:52 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <20011012153452.A18421@lucent.com>; from dwd@bell-labs.com on Fri, Oct 12, 2001 at 03:34:52PM -0500
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org> <20011012153452.A18421@lucent.com>
Message-ID: <20011012171152.A92193@oolong.il.thewrittenword.com>

On Fri, Oct 12, 2001 at 03:34:52PM -0500, Dave Dykstra wrote:
> --- configure.in.O	Fri Oct 12 14:42:39 2001
> +++ configure.in	Fri Oct 12 15:00:57 2001
> @@ -1449,6 +1449,10 @@
>  	AC_DEFINE_UNQUOTED(RSH_PATH, "$rsh_path")
>  fi
>  
> +AC_PATH_PROG(PASSWD_PATH, passwd)
> +AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
> +
> +

If you make this:
  AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH",
    [Define if passwd is found in your path])
you won't need your change to acconfig.h.

>  # Check for mail directory (last resort if we cannot get it from headers)
>  if test ! -z "$MAIL" ; then
>  	maildir=`dirname $MAIL`
> --- acconfig.h.O	Fri Oct 12 14:42:37 2001
> +++ acconfig.h	Fri Oct 12 14:58:43 2001
> @@ -214,6 +214,9 @@
>  /* Define if rsh is found in your path */
>  #undef RSH_PATH
>  
> +/* Define if passwd is found in your path */
> +#undef PASSWD_PATH
> +
>  /* Define if you want to allow MD5 passwords */
>  #undef HAVE_MD5_PASSWORDS

-- 
albert chin (china at thewrittenword.com)


From e-huss at netmeridian.com  Sat Oct 13 10:04:36 2001
From: e-huss at netmeridian.com (Eric Huss)
Date: Fri, 12 Oct 2001 17:04:36 -0700 (PDT)
Subject: local IP in environment
Message-ID: <Pine.GSO.4.40.0110121702540.11679-200000@wintermute>

I'm not sure if this is useful to anyone, but I made a small patch to
include the local IP address that the user connected to in the environment
(the opposite of SSH_CLIENT).  The variable is called SSH_LOCAL.

-Eric
-------------- next part --------------
*** openssh-2.9.9p2/canohost.c.bak	Sun Jun 24 22:01:24 2001
--- openssh-2.9.9p2/canohost.c	Fri Oct 12 16:52:09 2001
***************
*** 255,260 ****
--- 255,281 ----
  	return get_socket_address(socket, 0, NI_NAMEREQD);
  }
  
+ const char *
+ get_local_ipaddr2(void)
+ {
+ 	static char *canonical_host_ip = NULL;
+ 
+ 	/* Check whether we have cached the ipaddr. */
+ 	if (canonical_host_ip == NULL) {
+ 		if (packet_connection_is_on_socket()) {
+ 			canonical_host_ip =
+ 			    get_local_ipaddr(packet_get_connection_out());
+ 			if (canonical_host_ip == NULL)
+ 				fatal_cleanup();
+ 		} else {
+ 			/* If not on socket, return UNKNOWN. */
+ 			canonical_host_ip = xstrdup("UNKNOWN");
+ 		}
+ 	}
+ 	return canonical_host_ip;
+ }
+ 
+ 
  /*
   * Returns the IP-address of the remote host as a string.  The returned
   * string must not be freed.
*** openssh-2.9.9p2/canohost.h.bak	Tue Jul  3 21:46:57 2001
--- openssh-2.9.9p2/canohost.h	Fri Oct 12 16:52:12 2001
***************
*** 14,19 ****
--- 14,20 ----
  
  const char	*get_canonical_hostname(int);
  const char	*get_remote_ipaddr(void);
+ const char      *get_local_ipaddr2(void);
  const char	*get_remote_name_or_ip(u_int, int);
  
  char		*get_peer_ipaddr(int);
*** openssh-2.9.9p2/session.c.bak	Sun Sep 16 15:17:15 2001
--- openssh-2.9.9p2/session.c	Fri Oct 12 16:52:09 2001
***************
*** 1255,1260 ****
--- 1255,1263 ----
  	snprintf(buf, sizeof buf, "%.50s %d %d",
  		 get_remote_ipaddr(), get_remote_port(), get_local_port());
  	child_set_env(&env, &envsize, "SSH_CLIENT", buf);
+ 	snprintf(buf, sizeof buf, "%.50s",
+ 		 get_local_ipaddr2());
+ 	child_set_env(&env, &envsize, "SSH_LOCAL", buf);
  
  	if (s->ttyfd != -1)
  		child_set_env(&env, &envsize, "SSH_TTY", s->tty);

From war at starband.net  Sat Oct 13 10:57:16 2001
From: war at starband.net (war)
Date: Fri, 12 Oct 2001 20:57:16 -0400
Subject: Problem with OpenSSH 2.9p2
Message-ID: <3BC7916C.D992D37A@starband.net>

Hello.

I've recently switched to OpenSSH from the other ssh's.

When I ssh into to a box one at a time, it works fine.

However when I want to connect 4 times quickly, none of them ever
connect.

ie:

Doing this four times:
xterm -e connect-to-box1 &

ssh -v shows the following:

It gets to this part on EACH terminal and it hangs forever.

ssh -v -l war thebox.com
OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /app/openssh-2.9.9p2/etc/ssh_config
debug1: Reading configuration data /home/war/.ssh/config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 500 geteuid 0 anon 1
debug1: Connecting to x-ceed.net [64.249.166.242] port 22.
debug1: temporarily_use_uid: 500/500 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 500/500 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/war/.ssh/identity type -1
debug1: identity file /home/war/.ssh/id_rsa type -1
debug1: identity file /home/war/.ssh/id_dsa type -1

It will sit here until the process is killed.

However if I do one at a time, it works fine!

Any idea?

I've tried all sorts of options in my ~/.ssh/config.

No luck yet.




From stevesk at pobox.com  Sat Oct 13 11:57:54 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 12 Oct 2001 18:57:54 -0700 (PDT)
Subject: bug report: last login time vs PAM in portability release
In-Reply-To: <Pine.BSO.4.33.0110121656050.32713-100000@etoh.eviladmin.org>
Message-ID: <Pine.HPX.4.40.0110121855490.1707-100000@jenny>

On Fri, 12 Oct 2001 mouring at etoh.eviladmin.org wrote:
:It is a problem with Solaris.

is it a defect with Solaris PAM, or incorrect usage?



From mouring at etoh.eviladmin.org  Sat Oct 13 14:09:42 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 12 Oct 2001 23:09:42 -0500 (CDT)
Subject: bug report: last login time vs PAM in portability release
In-Reply-To: <Pine.HPX.4.40.0110121855490.1707-100000@jenny>
Message-ID: <Pine.BSO.4.33.0110122306380.20004-100000@etoh.eviladmin.org>


Can't say.  I would have to venture it may be another 'gray' area of the
specs.  One which has HP/UX and Linux vs Solaris.

If the patch prestend works for Solaris and does not cause harm to HP/UX
nor Linux than I would be up to the change, but I may suggest post 3.0
unless we can test every OS with a PAM setup to ensure it does not break
something else.

Which still brings up back to HP/UX, PAM sessions for non-interactive, and
tty pam hack.  Which really needs to be resolved before 3.0.

- Ben

On Fri, 12 Oct 2001, Kevin Steves wrote:

> On Fri, 12 Oct 2001 mouring at etoh.eviladmin.org wrote:
> :It is a problem with Solaris.
>
> is it a defect with Solaris PAM, or incorrect usage?
>
>



From vinschen at redhat.com  Sat Oct 13 18:48:17 2001
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sat, 13 Oct 2001 10:48:17 +0200
Subject: [PATCH]: scard/Makefile.in broken when srcdir != builddir [was Re: Please test snapshots for 3.0 release]
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 12, 2001 at 11:47:38AM +1000
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <20011013104817.A25451@cygbert.vinschen.de>

On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
> 
> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

scard/Makefile.in doesn't work correctly in srcdir != builddir
build environments. The following patch fixes that:

Index: scard/Makefile.in
===================================================================
RCS file: /cvs/openssh_cvs/scard/Makefile.in,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile.in
--- scard/Makefile.in	2001/09/20 18:39:37	1.2
+++ scard/Makefile.in	2001/10/13 08:52:00
@@ -11,8 +11,8 @@ VPATH=@srcdir@
 
 all:
 
-Ssh.bin:  Ssh.bin.uu
-	uudecode Ssh.bin.uu
+Ssh.bin:  $(srcdir)/Ssh.bin.uu
+	uudecode -o $@ $(srcdir)/Ssh.bin.uu
 
 clean:
 	rm -rf Ssh.bin
@@ -24,4 +24,4 @@ distclean: clean
 
 install: Ssh.bin
 	$(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir)
-	$(INSTALL) -m 0644 $(srcdir)/Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin
+	$(INSTALL) -m 0644 Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin

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


From mstone at cs.loyola.edu  Sat Oct 13 23:07:30 2001
From: mstone at cs.loyola.edu (Michael Stone)
Date: Sat, 13 Oct 2001 09:07:30 -0400
Subject: BadOption failures "annoying"
In-Reply-To: <20011007015552.A1593@quipu.half.pint-stowp.cx>; from jmknoble@pobox.com on Sun, Oct 07, 2001 at 01:55:52AM -0400
References: <20011007044915.A8875@pohl.fips.de> <20011007015552.A1593@quipu.half.pint-stowp.cx>
Message-ID: <20011013090729.S7029@justice.loyola.edu>

On Sun, Oct 07, 2001 at 01:55:52AM -0400, Jim Knoble wrote:
> If you truly need 'cipher none', you should probably know enough about
> OpenSSH to be able to put it back easily.  Otherwise, a slow machine
> with a fast cipher (blowfish, arcfour) is still liable to be bound by
> servicing interrupts on the network adapter more than anything else.
> Don't forget to turn off compression over a fast network.

I wish people would stop saying this without testing and then posting
the results--because several people have pointed out that it's simply
not true on many systems.

-- 
Mike Stone


From tim at multitalents.net  Sun Oct 14 02:06:36 2001
From: tim at multitalents.net (Tim Rice)
Date: Sat, 13 Oct 2001 09:06:36 -0700 (PDT)
Subject: [PATCH]: scard/Makefile.in broken when srcdir != builddir [was
 Re: Please test snapshots for 3.0 release]
In-Reply-To: <20011013104817.A25451@cygbert.vinschen.de>
Message-ID: <Pine.UW2.4.40.0110130854360.16227-100000@uw711.int.multitalents.net>

On Sat, 13 Oct 2001, Corinna Vinschen wrote:

> On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> > Could everyone please test the latest snapshots as we will be making a
> > new release soon.
> >
> > If you have any patches you would like us to consider, please resend
> > them to the list ASAP.
>
> scard/Makefile.in doesn't work correctly in srcdir != builddir
> build environments. The following patch fixes that:

It's been working fine here. And none of my builds are in srcdir.
But then, after I pull CVS i do a "make -f Makefile.in distprep"

I think the patch has merrit. If we dropped the distprep line
from scard/Makefile.in and don't include Ssh.bin in the tarballs
it should be fine.

Comments?

>
> Index: scard/Makefile.in
> ===================================================================
> RCS file: /cvs/openssh_cvs/scard/Makefile.in,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile.in
> --- scard/Makefile.in	2001/09/20 18:39:37	1.2
> +++ scard/Makefile.in	2001/10/13 08:52:00
> @@ -11,8 +11,8 @@ VPATH=@srcdir@
>
>  all:
>
> -Ssh.bin:  Ssh.bin.uu
> -	uudecode Ssh.bin.uu
> +Ssh.bin:  $(srcdir)/Ssh.bin.uu
> +	uudecode -o $@ $(srcdir)/Ssh.bin.uu
>
>  clean:
>  	rm -rf Ssh.bin
> @@ -24,4 +24,4 @@ distclean: clean
>
>  install: Ssh.bin
>  	$(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir)
> -	$(INSTALL) -m 0644 $(srcdir)/Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin
> +	$(INSTALL) -m 0644 Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin
>
> Corinna
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From Lutz.Jaenicke at aet.TU-Cottbus.DE  Sun Oct 14 02:07:48 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Sat, 13 Oct 2001 18:07:48 +0200
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <20011013180748.A1775@serv01.aet.tu-cottbus.de>

On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> Could everyone please test the latest snapshots as we will be making a
> new release soon.

Today's CVS (Oct 13) looks good on HP-UX 10.20.
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From mouring at etoh.eviladmin.org  Sun Oct 14 03:39:34 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sat, 13 Oct 2001 12:39:34 -0500 (CDT)
Subject: [PATCH]: scard/Makefile.in broken when srcdir != builddir [was
 Re: Please test snapshots for 3.0 release]
In-Reply-To: <Pine.UW2.4.40.0110130854360.16227-100000@uw711.int.multitalents.net>
Message-ID: <Pine.BSO.4.33.0110131236130.20004-100000@etoh.eviladmin.org>



On Sat, 13 Oct 2001, Tim Rice wrote:

> On Sat, 13 Oct 2001, Corinna Vinschen wrote:
>
> > On Fri, Oct 12, 2001 at 11:47:38AM +1000, Damien Miller wrote:
> > > Could everyone please test the latest snapshots as we will be making a
> > > new release soon.
> > >
> > > If you have any patches you would like us to consider, please resend
> > > them to the list ASAP.
> >
> > scard/Makefile.in doesn't work correctly in srcdir != builddir
> > build environments. The following patch fixes that:
>
> It's been working fine here. And none of my builds are in srcdir.
> But then, after I pull CVS i do a "make -f Makefile.in distprep"
>
> I think the patch has merrit. If we dropped the distprep line
> from scard/Makefile.in and don't include Ssh.bin in the tarballs
> it should be fine.
>
> Comments?
>

I think that we should be uudecoding Ssh.bin for the tarballs.  We just
get everyone to use 'make -F Makefile.in distprep' if they are doing CVS
tree builds.

As long as people are using 'distprep' as the way it was designed then we
don't have any problems.

- Ben



From stevesk at pobox.com  Sun Oct 14 05:54:39 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Sat, 13 Oct 2001 12:54:39 -0700 (PDT)
Subject: bug report: last login time vs PAM in portability release
In-Reply-To: <Pine.BSO.4.33.0110122306380.20004-100000@etoh.eviladmin.org>
Message-ID: <Pine.HPX.4.40.0110131248130.1460-100000@jenny>

On Fri, 12 Oct 2001 mouring at etoh.eviladmin.org wrote:
:Can't say.  I would have to venture it may be another 'gray' area of the
:specs.  One which has HP/UX and Linux vs Solaris.

can a PAM expert determine if this is a solaris defect, and try to file a
defect report if it is?

:If the patch prestend works for Solaris and does not cause harm to HP/UX
:nor Linux than I would be up to the change, but I may suggest post 3.0
:unless we can test every OS with a PAM setup to ensure it does not break
:something else.

yes, i'm nervous about making a PAM change for that.  but i will look at
it closer.

:Which still brings up back to HP/UX, PAM sessions for non-interactive, and
:tty pam hack.  Which really needs to be resolved before 3.0.

what are the issues again?  PAM_TTY_KLUDGE broke hp-ux last time, and i
doubt there's been a change there.



From stevesk at pobox.com  Sun Oct 14 06:00:06 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Sat, 13 Oct 2001 13:00:06 -0700 (PDT)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <Pine.HPX.4.40.0110131255440.1460-100000@jenny>

On Fri, 12 Oct 2001, Damien Miller wrote:
:Could everyone please test the latest snapshots as we will be making a
:new release soon.

for those involved in the large file support discussion or that have an
interest in that: please test the large file support, as i believe it is
working now.  i have tested hp-ux 11, but there are a number of different
#ifdef paths in loginrec.



From Lutz.Jaenicke at aet.TU-Cottbus.DE  Sun Oct 14 19:49:59 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Sun, 14 Oct 2001 11:49:59 +0200
Subject: ssh-agent doesn't work for all hosts
In-Reply-To: <20011013220610.C25763@diderot.uchicago.edu>
References: <20011013220610.C25763@diderot.uchicago.edu>
Message-ID: <20011014114959.B12463@serv01.aet.tu-cottbus.de>

On Sat, Oct 13, 2001 at 10:06:10PM -0500, Orion Buckminster Montoya wrote:
> I've searched the FAQ and the list archives for the solution to this
> problem, and asked knowlegeable people, but to no avail.  Rather than
> spam the list with tons of ssh-v output, I've put it up at
> http://valla.uchicago.edu/ssh-v/, and referred to it below as
> appropriate.
> 
> I am running OpenSSH_2.9p2 on a Debian GNU/Linux (Sid) system, and I
> can't use ssh-agent to connect to some hosts, but for some I can.
> Some of these are running commerical SSH, but many are running
> OpenSSH.
[rest of information deleted]

If I analyze the output correctly, you only have an RSA1 key available
in your agent. Please understand, that there are 3 types of keys available:
* RSA1: only available for protocol 1 (ssh-1.2.x and OpenSSH running in
  compatibility mode). Check your output: if your logfile says
    Remote protocol version 1.5, remote software version ...
  and
    Host 'dsal.uchicago.edu' is known and matches the RSA1 host key
  you are using the old and deprecated protocol 1.
* DSA: only available for protocol 2 (ssh-2.xx and OpenSSH-2.x.x)
* RSA: only available for protocol 2 (OpenSSH-2.x.x, ssh-3(?)).

Solution: create a new set of public keys for DSA and RSA (protocol 2)
and also load them into the agent. If you use them with the same passphrase,
you can even add them with ssh-add all at once.
If you have all 3 keys available (RSA1, RSA, DSA) you will have all
options available.
Please also check out all of the ssh[d]_config files. You should enable
protocol 2 as the default protocol. This is not yet true in your case.

To the OpenSSH-maintainers: detecting this problem might have been easier,
if ssh -v (and/or sshd -d) would explicitly tell "choosing protocol x.x" :-)

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From sturle.sunde at usit.uio.no  Mon Oct 15 04:19:14 2001
From: sturle.sunde at usit.uio.no (Sturle Sunde)
Date: 14 Oct 2001 20:19:14 +0200
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <riqk7xyt78d.fsf@aqualene.uio.no>

Damien Miller <djm at mindrot.org> writes:

> Could everyone please test the latest snapshots as we will be making a
> new release soon.

I have tested with native compilers on six different platforms, and
get lot's of warnings (mostly prototype/argument mismatches).

Too many errors to send to the list, so I have put the results here: 

  ftp.ifi.uio.no:/pub/tmp/out/sturles/openssh-SNAP-20011012-compileresults.tar.gz

The tar has one directory for each platform tested.  Each directory
contains config.* from each configure, results of make >& make.out, a
file "VERSIONS" with version information from cc and make, and uname
with the output from "uname -a".  Enjoy.

On AIX configure seemed to work fine and exited with status 0, but it
didn't create a Makefile or config.h!  config.log and config.status
are included in the tarball.

> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.

AUTH_FAIL_MAX 6 is too low in some cases.  A simple fix is to increase
the value.  I have explained the bug here:

  http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99727458632585&w=2



--- auth.h.orig Wed Jul  4 06:46:57 2001
+++ auth.h      Fri Oct 12 14:04:09 2001
@@ -149,7 +149,7 @@
 check_key_in_hostfiles(struct passwd *, Key *, const char *,
     const char *, const char *);
 
-#define AUTH_FAIL_MAX 6
+#define AUTH_FAIL_MAX 8
 #define AUTH_FAIL_LOG (AUTH_FAIL_MAX/2)
 #define AUTH_FAIL_MSG "Too many authentication failures for %.100s"



-- 
Sturle      All eyes were on Ford Prefect. Some of them were on stalks.
~~~~~~           -- Douglas Adams, So long, and thanks for all the fish


From tim at multitalents.net  Mon Oct 15 07:08:54 2001
From: tim at multitalents.net (Tim Rice)
Date: Sun, 14 Oct 2001 14:08:54 -0700 (PDT)
Subject: CVS oddness on Solaris.
In-Reply-To: <Pine.BSO.4.33.0108221141300.28670-100000@etoh.eviladmin.org>
Message-ID: <Pine.UW2.4.40.9.0110141314300.26110-100000@uw711.int.multitalents.net>

On Wed, 22 Aug 2001 mouring at etoh.eviladmin.org wrote:

>
> Ok.. While helping someone else out with a Solaris 6 issue.. I'm noticing
> something is broken on Solaris 7.. I've not verified it on Linux.. That is
> my next step.  But this is what I'm seeing.
>
> I installed the latest CVS snapshot (actually from the Developer's tree
> but no changes have been made since 21th), compiled, and installed.. and
> now:
>
> ssh localhost "ps -ef"  does not work.  It acts like it works, -v -v -v
> shows everything right, but.. no output..
>
> [..]
> debug3: clear hostkey 0
> debug3: clear hostkey 1
> debug3: clear hostkey 2
> debug1: channel 0: new [client-session]
> debug3: ssh_session2_command: channel_new: 0
> debug1: send channel open 0
> debug1: Entering interactive session.
> debug2: callback start
> debug1: client_init id 0 arg 0
> debug1: Sending command: ps -ef
> debug2: callback done
> debug1: channel 0: open confirm rwindow 0 rmax 16384
> debug1: channel_free: channel 0: client-session, nchannels 1
> debug3: channel_free: status: The following connections are open:
>   #0 client-session (t4 r0 i1/0 o16/0 fd 6/8)
> [..]
>
> Has anyone else see this?

Yes, It's broken on Solaris 8 too. (14 Oct 2001 CVS)
Truus shows
....
1284:	close(4)					= 0
1284:	stat64("/usr/lib/security/pam_unix.so.1", 0xEFFFEDC0) = 0
1284:	door_info(3, 0xEFFFE150)			= 0
1284:	door_call(3, 0xEFFFE138)			= 0
1284:	open("/var/adm/lastlog", O_RDWR|O_CREAT, 0444)	= 4
1284:	llseek(4, 868, SEEK_SET)			= 868
1284:	time()						= 1003090206
1284:	    Incurred fault #6, FLTBOUNDS  %pc = 0xEF5B361C
1284:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005
1284:	    Received signal #11, SIGSEGV [default]
1284:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005
1284:		*** process killed ***

Still looking.

>
> Well, off to throw up OpenSSH -current on Linux for testing...

UnixWare is fine.

>
> - Ben
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From mouring at etoh.eviladmin.org  Mon Oct 15 07:12:30 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Sun, 14 Oct 2001 16:12:30 -0500 (CDT)
Subject: CVS oddness on Solaris.
In-Reply-To: <Pine.UW2.4.40.9.0110141314300.26110-100000@uw711.int.multitalents.net>
Message-ID: <Pine.BSO.4.33.0110141611320.20004-100000@etoh.eviladmin.org>


This is solved by enabled the PAM TTY hack.. Which breaks HP/UX.  I think
we should enable the PAM TTY hack for Solaris if we are going to keep with
the idea of doing sessions for non-interactive logins.

- Ben

On Sun, 14 Oct 2001, Tim Rice wrote:

> On Wed, 22 Aug 2001 mouring at etoh.eviladmin.org wrote:
>
> >
> > Ok.. While helping someone else out with a Solaris 6 issue.. I'm noticing
> > something is broken on Solaris 7.. I've not verified it on Linux.. That is
> > my next step.  But this is what I'm seeing.
> >
> > I installed the latest CVS snapshot (actually from the Developer's tree
> > but no changes have been made since 21th), compiled, and installed.. and
> > now:
> >
> > ssh localhost "ps -ef"  does not work.  It acts like it works, -v -v -v
> > shows everything right, but.. no output..
> >
> > [..]
> > debug3: clear hostkey 0
> > debug3: clear hostkey 1
> > debug3: clear hostkey 2
> > debug1: channel 0: new [client-session]
> > debug3: ssh_session2_command: channel_new: 0
> > debug1: send channel open 0
> > debug1: Entering interactive session.
> > debug2: callback start
> > debug1: client_init id 0 arg 0
> > debug1: Sending command: ps -ef
> > debug2: callback done
> > debug1: channel 0: open confirm rwindow 0 rmax 16384
> > debug1: channel_free: channel 0: client-session, nchannels 1
> > debug3: channel_free: status: The following connections are open:
> >   #0 client-session (t4 r0 i1/0 o16/0 fd 6/8)
> > [..]
> >
> > Has anyone else see this?
>
> Yes, It's broken on Solaris 8 too. (14 Oct 2001 CVS)
> Truus shows
> ....
> 1284:	close(4)					= 0
> 1284:	stat64("/usr/lib/security/pam_unix.so.1", 0xEFFFEDC0) = 0
> 1284:	door_info(3, 0xEFFFE150)			= 0
> 1284:	door_call(3, 0xEFFFE138)			= 0
> 1284:	open("/var/adm/lastlog", O_RDWR|O_CREAT, 0444)	= 4
> 1284:	llseek(4, 868, SEEK_SET)			= 868
> 1284:	time()						= 1003090206
> 1284:	    Incurred fault #6, FLTBOUNDS  %pc = 0xEF5B361C
> 1284:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005
> 1284:	    Received signal #11, SIGSEGV [default]
> 1284:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005
> 1284:		*** process killed ***
>
> Still looking.
>
> >
> > Well, off to throw up OpenSSH -current on Linux for testing...
>
> UnixWare is fine.
>
> >
> > - Ben
> >
>
> --
> Tim Rice				Multitalents	(707) 887-1469
> tim at multitalents.net
>
>
>



From markm68k at yahoo.com  Mon Oct 15 12:00:21 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Sun, 14 Oct 2001 19:00:21 -0700 (PDT)
Subject: openssh bus error
Message-ID: <20011015020021.41112.qmail@web14502.mail.yahoo.com>

I am seeing a bus error with the latest snapshot on
Mac OS X.

The command I was using was a simple slogin to another
host.


Date/Time:  2001-10-14 18:56:53 -0700
OS Version: 10.1 (Build 5G64)

Command:    ssh
PID:        11669

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000016

Thread 0:
 #0   0x700013e0 in strlen
 #1   0x700024a4 in vfprintf
 #2   0x70012e80 in vsnprintf
 #3   0x0001474c in do_log
 #4   0x00014248 in debug
 #5   0x00005638 in check_host_key
 #6   0x00005cb0 in verify_host_key
 #7   0x00007200 in verify_host_key_callback
 #8   0x00024f5c in kexgex_client
 #9   0x000255b8 in kexgex
 #10  0x0001ef54 in kex_kexinit_finish
 #11  0x0001ee50 in kex_input_kexinit
 #12  0x00014918 in dispatch_run
 #13  0x0000737c in ssh_kex2
 #14  0x00005dcc in ssh_login
 #15  0x00003908 in main
 #16  0x0000233c in _start
 #17  0x0000216c in start


PPC Thread State:
  srr0: 0x700013e0 srr1: 0x0200f030               
vrsave: 0x00000000
   xer: 0x0000000a   lr: 0x700024a4  ctr: 0x700013d0  
mq: 0x00000000
    r0: 0x700024a4   r1: 0xbfffdaa0   r2: 0xbfffe220  
r3: 0x00000016
    r4: 0x0000000a   r5: 0xbfffe68c   r6: 0xbfffe68c  
r7: 0x6c696173
    r8: 0x3a202573   r9: 0x70002424  r10: 0x25730000 
r11: 0x80003244
   r12: 0x700013d0  r13: 0x00000000  r14: 0x00000036 
r15: 0x0004a010
   r16: 0xbfffee70  r17: 0x00000000  r18: 0x00000014 
r19: 0x00002b03
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4 
r23: 0x70004c58
   r24: 0x00000001  r25: 0x0004b060  r26: 0x00000000 
r27: 0x000741e0
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x00000000 
r31: 0x00000001

**********



=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From tomh at po.crl.go.jp  Mon Oct 15 18:48:52 2001
From: tomh at po.crl.go.jp (Tom Holroyd)
Date: Mon, 15 Oct 2001 17:48:52 +0900 (JST)
Subject: cosmetic patch
Message-ID: <Pine.LNX.4.30.0110151743100.558-100000@holly.crl.go.jp>

These get rid of some warnings on picky compilers (like SGI's).  It really
helps to get rid of warnings.

--- openssh-snap/log.c  Wed Jul  4 13:46:58 2001
+++ openssh/log.c       Mon Oct 15 17:34:26 2001
@@ -68,7 +68,7 @@
        { "LOCAL5",     SYSLOG_FACILITY_LOCAL5 },
        { "LOCAL6",     SYSLOG_FACILITY_LOCAL6 },
        { "LOCAL7",     SYSLOG_FACILITY_LOCAL7 },
-       { NULL, 0 }
+       { NULL, (SyslogFacility)0 }
 };

 static struct {
@@ -85,7 +85,7 @@
        { "DEBUG1",     SYSLOG_LEVEL_DEBUG1 },
        { "DEBUG2",     SYSLOG_LEVEL_DEBUG2 },
        { "DEBUG3",     SYSLOG_LEVEL_DEBUG3 },
-       { NULL, 0 }
+       { NULL, (LogLevel)0 }
 };

 static void     do_log(LogLevel level, const char *fmt, va_list args);

--- openssh-snap/readconf.c     Thu Oct  4 02:39:39 2001
+++ openssh/readconf.c  Mon Oct 15 17:34:26 2001
@@ -187,7 +193,7 @@
        { "smartcarddevice", oSmartcardDevice },
        { "clearallforwardings", oClearAllForwardings },
        { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost
-       { NULL, 0 }
+       { NULL, (OpCodes)0 }
 };

 /*

--- openssh-snap/servconf.c     Thu Sep 13 01:32:15 2001
+++ openssh/servconf.c  Mon Oct 15 17:34:26 2001
@@ -317,7 +330,7 @@
        { "authorizedkeysfile", sAuthorizedKeysFile },
        { "authorizedkeysfile2", sAuthorizedKeysFile2 },
        { "PAMAuthenticationViaKbdInt", sPAMAuthenticationViaKbdInt },
-       { NULL, 0 }
+       { NULL, (ServerOpCodes)0 }
 };

 /*




From a_ghsek at yahoo.co.in  Mon Oct 15 23:48:08 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Mon, 15 Oct 2001 14:48:08 +0100 (BST)
Subject: openssh on LynxOS issues! - Changes and addons.
In-Reply-To: <Pine.LNX.4.33.0110111006130.1639-100000@mothra.mindrot.org>
Message-ID: <20011015134808.19886.qmail@web8007.mail.in.yahoo.com>

 --- Damien Miller <djm at mindrot.org> wrote: > On Wed,
10 Oct 2001, hari sekar wrote:
> 
> > Hi,
> >   With reference to my previous mail:
> > 1.  I use openssh-2.9p2 on a LynxOS i386 system.
> The
> > ssh and scp clients work fine. Even sftp from
> other
> > Linux systems works. But, if I run the sftp client
> in
> > LynxOS to localhost (LynxOS) or remote sshd in
> Linux,
> > the authentication succeeds, prints sftp> prompt
> and
> > then exits. I don't know why this happens. The
> problem
> > is with the sftp client program in LynxOS. Does it
> > work for anyone (sftp client program in LynxOS)?
> 
> No idea here - have you determined whether it is
> sftp or the underlying
> ssh that is exiting.

  The sftp-server works fine, i.e., I can make sftp
calls from remote Linux system. Only the sftp client
program running on LynxOS fails. Also, no problem with
ssh client program. I attach the debug output after
authentication, which says that read fails. Why does
read fail?
-Hari.

lynx>sftp -v -v -v hari at linux
...
hari at linux's password:
debug2: packet_inject_ignore: current 58
debug2: packet_inject_ignore: block 16 have 4 nb 4
mini 1 need 4
debug2: we sent a password packet, wait for reply
debug1: ssh-userauth2 successful: method password
debug1: fd 4 setting O_NONBLOCK
debug1: fd 5 IS O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: client_init id 0 arg 0
debug1: Sending subsystem: sftp
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
debug2: Remote version: 3
debug3: Sent message fd 3 T:16 I:1
debug3: SSH_FXP_REALPATH . -> /home/hari
sftp>
debug1: channel 0: read<=0 rfd 4 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
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)
debug1: channel_free: channel 0: dettaching channel
user
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
lynx> 

____________________________________________________________
Do You Yahoo!?
*NEW* Yahoo! Messenger is now on SMS. Visit http://in.mobile.yahoo.com/smsmgr_signin.html


From K.Wolkersdorfer at fz-juelich.de  Tue Oct 16 02:48:00 2001
From: K.Wolkersdorfer at fz-juelich.de (K.Wolkersdorfer at fz-juelich.de)
Date: Mon, 15 Oct 2001 16:48:00 +0000
Subject: openssh bug (AIX only): scp not found
Message-ID: <1011015164800.ZM17044@zam282.zam.kfa-juelich.de>

Hi,

Bug-Description (for AIX - current release 4.3.3 - only):

  Everything installed in /usr/opt/freeware/...
  Client uses in AIX:
    scp <local-file> user at host:<remote-file>
  System response:
    ksh: scp:  not found.
    lost connection

Circumvention:

  In /etc/environment add
  /usr/opt/freeware/bin
  to the PATH-variable.

Suggestion:

  This problem exits in AIX only,
  although openssh seems properly configured with
  --prefix=/usr/opt/freeware
  The culprit seems to be in AIX only code
  in session.c, line 1269 (openssh-2.9.9p2):

#ifdef _AIX
	if ((cp = getenv("AUTHSTATE")) != NULL)
		child_set_env(&env, &envsize, "AUTHSTATE", cp);
	if ((cp = getenv("KRB5CCNAME")) != NULL)
		child_set_env(&env, &envsize, "KRB5CCNAME", cp);
	read_environment_file(&env, &envsize, "/etc/environment");
#endif

  Here /etc/environment overrides unconditionally the PATH variable.
  But _PATH_STDPATH should always be added to the PATH variable
  (see CHANGELOG - tim at mindrot.org 2001/03/10 16:33:42) via:
  	child_set_env(&env, &envsize, "PATH", _PATH_STDPATH);

Bug-Fix:

  The following fix works for us (openssh-2.9.9p2)
------------------------------------------------------------------------
  diff session.c.orig session.c
1275d1274
< 	child_set_env(&env, &envsize, "PATH", _PATH_STDPATH);
-------------------------------------------------------------------------

Many thanks for your attention and best regards from Germany

Klaus

-- 
Klaus Wolkersdorfer                     (K.Wolkersdorfer at fz-juelich.de)
Zentralinstitut fuer Angewandte Mathematik (ZAM)  Tel: +49-2461-61-6579
John von Neumann - Institute for Computing (NIC)  Fax:            -6656
Forschungszentrum Juelich GmbH, D-52425 Juelich,  Germany


From dwd at bell-labs.com  Tue Oct 16 01:30:30 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Mon, 15 Oct 2001 10:30:30 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <20011012171152.A92193@oolong.il.thewrittenword.com>; from openssh-unix-dev@thewrittenword.com on Fri, Oct 12, 2001 at 05:11:52PM -0500
References: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org> <20011012153452.A18421@lucent.com> <20011012171152.A92193@oolong.il.thewrittenword.com>
Message-ID: <20011015103030.A16189@lucent.com>

On Fri, Oct 12, 2001 at 05:11:52PM -0500, openssh-unix-dev at thewrittenword.com wrote:
> On Fri, Oct 12, 2001 at 03:34:52PM -0500, Dave Dykstra wrote:
> > --- configure.in.O	Fri Oct 12 14:42:39 2001
> > +++ configure.in	Fri Oct 12 15:00:57 2001
> > @@ -1449,6 +1449,10 @@
> >  	AC_DEFINE_UNQUOTED(RSH_PATH, "$rsh_path")
> >  fi
> >  
> > +AC_PATH_PROG(PASSWD_PATH, passwd)
> > +AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
> > +
> > +
> 
> If you make this:
>   AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH",
>     [Define if passwd is found in your path])
> you won't need your change to acconfig.h.


Yes, I know, but there's not one precedent for that in configure.in yet
and I'm just following the established style.

- Dave Dykstra


From dwd at bell-labs.com  Tue Oct 16 01:48:51 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Mon, 15 Oct 2001 10:48:51 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <Pine.HPX.4.40.0110121429560.1707-100000@jenny>; from stevesk@pobox.com on Fri, Oct 12, 2001 at 02:36:06PM -0700
References: <20011012153452.A18421@lucent.com> <Pine.HPX.4.40.0110121429560.1707-100000@jenny>
Message-ID: <20011015104851.B16189@lucent.com>

On Fri, Oct 12, 2001 at 02:36:06PM -0700, Kevin Steves wrote:
> On Fri, 12 Oct 2001, Dave Dykstra wrote:
> :I have posted this one several times and I ask that you *please* put it
> :in.  Many people have asked for this one, and Markus has done all the
> :preparatory work in the base code so changes only need to be made to the
> :portable code.  It works for all systems that use /etc/shadow, most notably
> :Solaris and Linux.
> 
> as i said i august, i think much of this could be pushed to native.
> markus indicated willingness to add something for the non BSD_AUTH case
> there.


Can you please be more specific what you think can be pushed to native?  I
do remember Markus saying he'd take a look at the non BSD_AUTH case but I
didn't hear anything after that (and not being an OpenBSD user I really
don't even know what non-BSD_AUTH means).

Clearly the part in auth.c is specific to portable OpenSSH, because it uses
fields specific to /etc/shadow and modifies code that is only in portable.
Also, configure.in and acconfig.h are only in portable.  That leaves
basically the session.c change which could conceivably be used in native,
but if nothing is using it I don't think it makes sense to put it in native
yet.  I suggest putting it into portable and if the time comes that Markus
or somebody else wants to use it in native they can back-port it.  Please
don't put off the whole patch just because nobody has found the time to
address a related case on OpenBSD.  It's really a very small patch and
supplies a very much needed functionality.

- Dave Dykstra


From war at starband.net  Tue Oct 16 03:13:40 2001
From: war at starband.net (war)
Date: Mon, 15 Oct 2001 13:13:40 -0400
Subject: OpenSSH Compatiblity Problems.
Message-ID: <3BCB1944.FAD47D93@starband.net>

Not sure which list this should go to, so I'll include both.

When I SSH from a 2.9.9p2 client to a OpenSSH 2.1.1 server, it often
hangs at this point.

It will hang there for days on end.

If I open up 9 xterms and run that command, 2-3 will login.

I have no problems using ssh1 (commercial).

And openssh has no problems logging into newer servers > 2.1.1.

Anyone know why this might be?


% ssh -v -l war host.com
OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /app/openssh-2.9.9p2/etc/ssh_config
debug1: Reading configuration data /home/war/.ssh/config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 500 geteuid 0 anon 1
debug1: Connecting to host.com [1.2.3.4] port 22.
debug1: temporarily_use_uid: 500/500 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 500/500 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/war/.ssh/identity type -1
debug1: identity file /home/war/.ssh/id_rsa type -1
debug1: identity file /home/war/.ssh/id_dsa type -1




From markus at openbsd.org  Tue Oct 16 03:19:49 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 15 Oct 2001 19:19:49 +0200
Subject: OpenSSH Compatiblity Problems.
In-Reply-To: <3BCB1944.FAD47D93@starband.net>; from war@starband.net on Mon, Oct 15, 2001 at 01:13:40PM -0400
References: <3BCB1944.FAD47D93@starband.net>
Message-ID: <20011015191949.A22329@faui02.informatik.uni-erlangen.de>

On Mon, Oct 15, 2001 at 01:13:40PM -0400, war wrote:
> When I SSH from a 2.9.9p2 client to a OpenSSH 2.1.1 server, it often
> hangs at this point.

openssh < 2.3.x is very broken, please upgrade.


From dwd at bell-labs.com  Tue Oct 16 04:00:54 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Mon, 15 Oct 2001 13:00:54 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <200110122142.OAA555237@nopython.nas.nasa.gov>; from imorgan@nas.nasa.gov on Fri, Oct 12, 2001 at 02:42:28PM -0700
References: <20011012153452.A18421@lucent.com> <200110122142.OAA555237@nopython.nas.nasa.gov>
Message-ID: <20011015130054.C16189@lucent.com>

On Fri, Oct 12, 2001 at 02:42:28PM -0700, Iain Morgan wrote:
> A fix for this issue is definitely needed. We have had to back off of
> implementing OpenSSH on our SGI's and Crays due to the issue of password
> expiration.
> 
> At a glance, one item that I would take execption with is the special handling
> for root. Perhaps the behaviour for root should be configurable.

I certainly wouldn't want an extra configuration option, but looking back I
can't think of any reason why I would have put that check in there.  I took
it out; the updated patch is below.  I tested expiring a root login, and
there's not even any adverse interactions with the PermitRootLogin option,
because that is checked separately before it gets to allowed_user() in
auth.c.

- Dave Dykstra


--- auth.c.O	Fri Oct 12 14:42:38 2001
+++ auth.c	Mon Oct 15 13:57:05 2001
@@ -49,6 +49,9 @@
 #include "uidswap.h"
 #include "tildexpand.h"
 
+/* set when password has expired */
+int forced_passwd_change = 0;
+
 /* import */
 extern ServerOptions options;
 
@@ -90,7 +93,7 @@
 		/* Check password expiry */
 		if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) &&
 		    (days > (spw->sp_lstchg + spw->sp_max)))
-			return 0;
+			forced_passwd_change = 1;
 	}
 #else
 	/* Shouldn't be called if pw is NULL, but better safe than sorry... */
--- auth.h.O	Thu Aug 23 13:18:52 2001
+++ auth.h	Fri Oct 12 15:00:10 2001
@@ -40,6 +40,9 @@
 #include <krb5.h>
 #endif
 
+/* set when password has expired */
+extern int forced_passwd_change;
+
 typedef struct Authctxt Authctxt;
 typedef struct KbdintDevice KbdintDevice;
 
--- session.c.O	Fri Oct 12 14:42:41 2001
+++ session.c	Fri Oct 12 15:04:29 2001
@@ -656,7 +656,31 @@
 void
 do_exec(Session *s, const char *command)
 {
-	if (forced_command) {
+	if (forced_passwd_change) {
+		char *user = s->pw->pw_name;
+		char *msg;
+
+		if (s->ttyfd != -1) {
+			msg = "Password for %.100s has expired, running 'passwd' to reset it";
+			/*
+			 * Can't pass "user" to 'passwd' because Linux doesn't
+			 * allow it.
+			 * Also, the prompt is friendlier without "user".
+			 */
+			command = PASSWD_PATH;
+		} else {
+			msg = "Password for %.100s has expired and cannot be changed without a pty";
+			/*
+			 * Without a pty, Solaris 'passwd' prints "Permission
+			 * denied", but Linux attempts to change the password
+			 * and fails miserably, so echo an error message instead
+			 */
+			command = "/bin/sh -c 'echo Permission denied >&2; exit 1'";
+		}
+		log(msg, user);
+		packet_send_debug(msg, user);
+
+	} else if (forced_command) {
 		original_command = command;
 		command = forced_command;
 		debug("Forced command '%.900s'", command);
--- configure.in.O	Fri Oct 12 14:42:39 2001
+++ configure.in	Fri Oct 12 15:00:57 2001
@@ -1449,6 +1449,10 @@
 	AC_DEFINE_UNQUOTED(RSH_PATH, "$rsh_path")
 fi
 
+AC_PATH_PROG(PASSWD_PATH, passwd)
+AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
+
+
 # Check for mail directory (last resort if we cannot get it from headers)
 if test ! -z "$MAIL" ; then
 	maildir=`dirname $MAIL`
--- acconfig.h.O	Fri Oct 12 14:42:37 2001
+++ acconfig.h	Mon Oct 15 13:59:02 2001
@@ -214,6 +214,9 @@
 /* Define if rsh is found in your path */
 #undef RSH_PATH
 
+/* Define if passwd is found in your path */
+#undef PASSWD_PATH
+
 /* Define if you want to allow MD5 passwords */
 #undef HAVE_MD5_PASSWORDS
 


From markus at openbsd.org  Tue Oct 16 18:44:20 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 16 Oct 2001 10:44:20 +0200
Subject: Patch for changing expired passwords
In-Reply-To: <20011015130054.C16189@lucent.com>; from dwd@bell-labs.com on Mon, Oct 15, 2001 at 01:00:54PM -0500
References: <20011012153452.A18421@lucent.com> <200110122142.OAA555237@nopython.nas.nasa.gov> <20011015130054.C16189@lucent.com>
Message-ID: <20011016104420.A8326@faui02.informatik.uni-erlangen.de>

On Mon, Oct 15, 2001 at 01:00:54PM -0500, Dave Dykstra wrote:
> +		if (s->ttyfd != -1) {
> +			msg = "Password for %.100s has expired, running 'passwd' to reset it";
> +			/*
> +			 * Can't pass "user" to 'passwd' because Linux doesn't
> +			 * allow it.
> +			 * Also, the prompt is friendlier without "user".
> +			 */
> +			command = PASSWD_PATH;

i'd prefer to move this to do_child and call packet_disconnect() if
no tty is available.


From pkamath at india.hp.com  Tue Oct 16 19:01:39 2001
From: pkamath at india.hp.com (Pradeep kamath)
Date: Tue, 16 Oct 2001 14:31:39 +0530
Subject: Security fixes in OpenSSH2.9.9p2
Message-ID: <3BCBF772.CD412634@india.hp.com>

Hello,

  I would like to know what security fixes does OpenSSH2.9.9p2 fix over
OpenSSH2.9p2.
Is there some place where I can get this information?..I was unable to
locate anything on the openssh website.

Thanks in advance,

-Pradeep.



From j.petersen at msh.de  Tue Oct 16 19:49:53 2001
From: j.petersen at msh.de (j.petersen at msh.de)
Date: Tue, 16 Oct 2001 11:49:53 +0200
Subject: Tiny bug in contrib/solaris/opensshd.in
Message-ID: <B56A3A4C735ED2118F25000083687FBB019D6DA2@MSHNTS04>

opensshd.in:

must be:
ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd

instead of
ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd

J?rg
___________________________________________
Dr. J?rg Petersen <j.petersen at msh.de>
Medien System Haus    Tel. 0711/72007-424
Plieninger Str. 150,  D-70567 Stuttgart


From dwd at bell-labs.com  Wed Oct 17 01:57:26 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 16 Oct 2001 10:57:26 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <20011016104420.A8326@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Tue, Oct 16, 2001 at 10:44:20AM +0200
References: <20011012153452.A18421@lucent.com> <200110122142.OAA555237@nopython.nas.nasa.gov> <20011015130054.C16189@lucent.com> <20011016104420.A8326@faui02.informatik.uni-erlangen.de>
Message-ID: <20011016105725.A25928@lucent.com>

On Tue, Oct 16, 2001 at 10:44:20AM +0200, Markus Friedl wrote:
> On Mon, Oct 15, 2001 at 01:00:54PM -0500, Dave Dykstra wrote:
> > +		if (s->ttyfd != -1) {
> > +			msg = "Password for %.100s has expired, running 'passwd' to reset it";
> > +			/*
> > +			 * Can't pass "user" to 'passwd' because Linux doesn't
> > +			 * allow it.
> > +			 * Also, the prompt is friendlier without "user".
> > +			 */
> > +			command = PASSWD_PATH;
> 
> i'd prefer to move this to do_child and call packet_disconnect() if
> no tty is available.


packet_disconnect() is definitely the way to go for the error case, I'm
embarrassed that I didn't figure that out before.

However, I tried moving the forced_passwd_change code to do_child() and it
didn't work because do_exec_pty() (via do_login()/check_quiet_login()) does
different things depending on whether or not command is NULL.

Meanwhile it has occurred to me that I can further simplify the patch by
just running "passwd" out of the default $PATH rather than using a
configure.in macro to find it.  This should also make it easier to accept
most of the patch into native OpenSSH, if you've got another use for it
there.

- Dave Dykstra



--- auth.c.O	Fri Oct 12 14:42:38 2001
+++ auth.c	Tue Oct 16 11:18:36 2001
@@ -49,6 +49,9 @@
 #include "uidswap.h"
 #include "tildexpand.h"
 
+/* set when password has expired */
+int forced_passwd_change = 0;
+
 /* import */
 extern ServerOptions options;
 
@@ -90,7 +93,7 @@
 		/* Check password expiry */
 		if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) &&
 		    (days > (spw->sp_lstchg + spw->sp_max)))
-			return 0;
+			forced_passwd_change = 1;
 	}
 #else
 	/* Shouldn't be called if pw is NULL, but better safe than sorry... */
--- auth.h.O	Thu Aug 23 13:18:52 2001
+++ auth.h	Fri Oct 12 15:00:10 2001
@@ -40,6 +40,9 @@
 #include <krb5.h>
 #endif
 
+/* set when password has expired */
+extern int forced_passwd_change;
+
 typedef struct Authctxt Authctxt;
 typedef struct KbdintDevice KbdintDevice;
 
--- session.c.O	Fri Oct 12 14:42:41 2001
+++ session.c	Tue Oct 16 11:15:48 2001
@@ -656,7 +656,21 @@
 void
 do_exec(Session *s, const char *command)
 {
-	if (forced_command) {
+	if (forced_passwd_change) {
+		char *user = s->pw->pw_name;
+		char *msg;
+
+		if (s->ttyfd == -1) {
+			packet_disconnect("Password for %.100s has expired and cannot be changed without a pty", user);
+			return;
+		}
+
+		msg = "Password for %.100s has expired, running 'passwd' to reset it";
+		command = "passwd";
+		log(msg, user);
+		packet_send_debug(msg, user);
+
+	} else if (forced_command) {
 		original_command = command;
 		command = forced_command;
 		debug("Forced command '%.900s'", command);


From jasonc at silicondefense.com  Wed Oct 17 05:21:00 2001
From: jasonc at silicondefense.com (C. Jason Coit)
Date: Tue, 16 Oct 2001 12:21:00 -0700
Subject: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and 2.9p2
Message-ID: <3BCC889C.AA5C57F0@silicondefense.com>

Hello,

In response to the timing analysis attacks presented by Dawn Song et.
al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html
we
at Silicon Defense developed a patch for openssh to avoid such
measures.  

Timing Analysis Evasion changes were developed by C. Jason Coit and Roel
Jonkman of Silicon Defense.

These changes cause SSH to send packets unless request not to, exactly
every 50 ms.  IF no data is ready to be sent, SSH will send a bogus
packet with 16 bytes of data (which is the same size as most
keystrokes).  Thus someone performing timing analysis cannot determine
the inter keystroke timing of a user.  SSH will send bogus data for
about 1 second after the last keystroke.  This both increases the
difficulty of determining exact password lengths and conserves bandwidth
when a user is idle (e.g. taking a coffee break).  Both the Server and
the Client exhibit this behavior and yet our code places no limit on the
data rate(i.e. if the server needs to respond with large amounts of data
it will be able to do so with large packets and without the 50 ms timing
constraint).  

We currently have patches and modified distributions for OpenSSH 2.9p2
and 2.9.9p2.  
The files for OpenSSH 2.9p2 are available at
http://www.silicondefense.com/software/ssh/ssh-2.9p2-diffs
http://www.silicondefense.com/software/ssh/opens3h-2.9p2.tar.gz

These files for OpenSSH 2.9.9p2 are available at
http://www.silicondefense.com/software/ssh/ssh-2.9.9p2-diffs
http://www.silicondefense.com/software/ssh/opens3h-2.9.9p2.tar.gz

The patch for 2.9.9p2 is available below:

--- channels.c  Mon Sep 17 22:53:12 2001
+++ channels.new.c      Mon Oct 15 14:28:43 2001
@@ -25,6 +25,32 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
@@ -1590,9 +1616,12 @@
 
 
 /* If there is data to send to the connection, enqueue some of it now.
*/
-
+/*
+ * SD Mod: add arguments bogus_send_count and
use_steno_timing_manipulation 
+ * to channel_output_poll.
+*/
 void
-channel_output_poll()
+channel_output_poll(int *bogus_send_count, int
use_steno_timing_manipulation)
 {
        int len, i;
        Channel *c;
@@ -1649,11 +1678,49 @@
                                    SSH2_MSG_CHANNEL_DATA :
SSH_MSG_CHANNEL_DATA);
                                packet_put_int(c->remote_id);
                                packet_put_string(buffer_ptr(&c->input),
len);
+                               /* 
+                                *  Begin SD Mod: if using SSH2 and it
is 
+                                *  desired to use timing manipulation,
reset
+                                *  counter since len > 0 implies packet
will
+                                *  contain geniune data.
+                                */
+                               if(compat20 &&
use_steno_timing_manipulation)
+                                 {
+                                   (*bogus_send_count)=0;
+                                   debug2("reseting count");
+                                 }
+                               /* End SD Mod */
                                packet_send();
                                buffer_consume(&c->input, len);
                                c->remote_window -= len;
                        }
-               } else if (c->istate == CHAN_INPUT_WAIT_DRAIN) {
+               }
+                 /*
+                  * Begin SD Mod:
+                  * packet does not contain data, we are not in a
draining
+                  * state and timing manipulation is desired, check if
bogus 
+                  * count is below threshold.
+                  */
+               else if ((len = buffer_len(&c->input)) == 0 
+                        && !(c->istate == CHAN_INPUT_WAIT_DRAIN) 
+                        && use_steno_timing_manipulation)
{                 
+                   /* 
+                    * If we have not sent too many bogus packets, sent
a 16
+                    * byte ignore packet filled with garbage data and
update
+                    * the bogus_send_count;
+                    */
+
+                   if((*bogus_send_count) < 20){
+                     debug2("sending garbage packet");
+                     packet_send_ignore(16);
+                     packet_send();
+                     (*bogus_send_count)++;
+                   }
+                   else
+                     debug("max number of timeouts exceeded: stop
sending garbage packets");
+                 }
+               /* End SD Mod */ 
+               else if (c->istate == CHAN_INPUT_WAIT_DRAIN) {
                        if (compat13)
                                fatal("cannot happen: istate ==
INPUT_WAIT_DRAIN for proto 1.3");
                        /*
--- channels.h  Mon Sep 17 22:51:14 2001
+++ channels.new.h      Mon Oct 15 14:28:43 2001
@@ -21,6 +21,33 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -173,7 +200,15 @@
 
 void    channel_prepare_select(fd_set **, fd_set **, int *, int*, int);
 void     channel_after_select(fd_set *, fd_set *);
-void     channel_output_poll(void);
+
+/*
+ * SD Mod: added parameters bogus_send_count, and
use_steno_timing_manipulation.
+ * The bogus_send_count keeps track of how many bogus packets have been
sent since
+ * the last packet containing real data.  The
use_steno_timining_manipulation flag
+ * keeps track of whether to perform timing analysis evasion.
+ */
+void channel_output_poll(int *bogus_send_count, int
use_steno_timing_manipulation);
+
 
 int      channel_not_very_much_buffered_data(void);
 void     channel_close_all(void);
--- clientloop.c        Mon Sep 17 22:51:14 2001
+++ clientloop.new.c    Mon Oct 15 14:28:43 2001
@@ -46,6 +46,33 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -315,16 +342,25 @@
  * Waits until the client can do something (some data becomes available
on
  * one of the file descriptors).
  */
-
-static void
+/* 
+ * SD Mod: We changed the return value of
client_wait_until_can_do_something 
+ * from void to int.  It now returns 1 if the steno_timer has expired
and 0 if not.
+ */
+int
 client_wait_until_can_do_something(fd_set **readsetp, fd_set
**writesetp,
     int *maxfdp, int *nallocp, int rekeying)
 {
+        /* SD Mod: added variable steno_timer */
+        static struct timeval steno_timer = {0, 50000};
+
+       int return_val = 0;
+       long int prev_timer_val = 0;
+
        /* Add any selections by the channel mechanism. */
        channel_prepare_select(readsetp, writesetp, maxfdp, nallocp,
rekeying);
 
        if (!compat20) {
-               /* Read from the connection, unless our buffers are
full. */
+         /* Read from the connection, unless our buffers are full. */
                if (buffer_len(&stdout_buffer) < buffer_high &&
                    buffer_len(&stderr_buffer) < buffer_high &&
                    channel_not_very_much_buffered_data())
@@ -342,13 +378,7 @@
                if (buffer_len(&stderr_buffer) > 0)
                        FD_SET(fileno(stderr), *writesetp);
        } else {
-               /* channel_prepare_select could have closed the last
channel */
-               if (session_closed && !channel_still_open()) {
-                       if (!packet_have_data_to_write())
-                               return;
-               } else {
-                       FD_SET(connection_in, *readsetp);
-               }
+               FD_SET(connection_in, *readsetp);
        }
 
        /* Select server connection if have data to write to the server.
*/
@@ -363,9 +393,34 @@
         * it: just have a random timeout for the select, and send a
random
         * SSH_MSG_IGNORE packet when the timeout expires.
         */
+       
+       /*
+        * Begin SD Mod: 
+        * Enforce wait send packets every 50 ms.  To do this add timer
to 
+        * select loop.  Buffer input as it comes and force the timer to
decrement
+        * if select call does not do so.   
+        */
+       prev_timer_val = steno_timer.tv_usec;
+
+       return_val = select((*maxfdp)+1, *readsetp, *writesetp, NULL,
&steno_timer);
 
-       if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0)
{
-               char buf[100];
+       /* SD Mod continued:
+        * If the prev_timer_val is still equal to the
steno_timer.tv_usec value
+        * then select did not decrement timer.  So force decrement so
timer can
+        * expire. This problem arises since the file descriptors change
since they 
+        * were reset just prior to entering the select loop.  This is a
strange
+        * fix but it works.
+        */
+       
+         if(prev_timer_val == steno_timer.tv_usec){
+           debug3("decrementing timer forcefully");
+           steno_timer.tv_usec -= 100;
+         }
+
+         if(return_val < 0){
+       /* end of SD Mod */
+           
+           char buf[100];
 
                /*
                 * We have to clear the select masks, because we return.
@@ -376,14 +431,29 @@
                memset(*writesetp, 0, *maxfdp);
 
                if (errno == EINTR)
-                       return;
+                       return 0;
                /* Note: we might still have data in the buffers. */
                snprintf(buf, sizeof buf, "select: %s\r\n",
strerror(errno));
                buffer_append(&stderr_buffer, buf, strlen(buf));
                quit_pending = 1;
        }
+         /* 
+          * Begin SD Mod: Return to the caller whether the timer has 
+          * expired or not. It is possible that the forced decrement
caused 
+          * the timer value to bbecome negative, if so the consider the 
+          * timer expired, reset it and return 1 to the caller denoting
timer 
+          * expiration.
+          */   
+         if(steno_timer.tv_usec <= 0)
+           {
+             steno_timer.tv_usec = 50000;
+             return 1;  
+           }
+         else
+           return 0;
+         /* End SD Mod */
+                 
 }
-
 static void
 client_suspend_self(Buffer *bin, Buffer *bout, Buffer *berr)
 {
@@ -773,6 +843,15 @@
        int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0;
        char buf[100];
 
+       /*
+        * Begin SD Mod: 
+        * Add counter for number of fake packets that have been sent.
+        * Add time_out flag for marking when timeout has occured.
+        */
+       int bogus_send_count = 0;
+       int time_out = 0;
+       /* End SD Mod */
+
        debug("Entering interactive session.");
 
        start_time = get_current_time();
@@ -861,9 +940,16 @@
                         * Make packets from buffered channel data, and
                         * enqueue them for sending to the server.
                         */
-                       if (packet_not_very_much_data_to_write())
-                               channel_output_poll();
-
+                       /*
+                        * Begin SD Mod: on expiration of 50 ms timer
call 
+                        * channel_ouput 
+                        */
+                       if(time_out){
+                        
channel_output_poll(&bogus_send_count,options.use_steno_timing_manipulation);
+                         time_out = 0;
+                       }
+                       /* End SD Mod */
+                       
                        /*
                         * Check if the window size has changed, and
buffer a
                         * message about it to the server if so.
@@ -878,8 +964,10 @@
                 * available on one of the descriptors).
                 */
                max_fd2 = max_fd;
-               client_wait_until_can_do_something(&readset, &writeset,
-                   &max_fd2, &nalloc, rekeying);
+
+               /* SD Mod: wait for data or timeout */
+               time_out = client_wait_until_can_do_something(&readset,
+                                &writeset, &max_fd2, &nalloc,
rekeying);               
 
                if (quit_pending)
                        break;
@@ -1222,6 +1310,21 @@
                exit_status = packet_get_int();
                packet_done();
        }
+       /*
+        * Begin SD Mod: 
+        * check to see if request from server is to turn off steno.
+        * If so, turn it off if neccessary.  
+        */
+       else if (strcmp(rtype, "no_steno") == 0) { 
+         debug("received request not use use steno");
+         if(options.use_steno_timing_manipulation)
+           {
+             options.use_steno_timing_manipulation = 0;
+           }
+         success = 1;
+         packet_done();
+       }
+       /* End SD Mod */
        if (reply) {
                packet_start(success ?
                    SSH2_MSG_CHANNEL_SUCCESS :
SSH2_MSG_CHANNEL_FAILURE);
--- readconf.c  Wed Sep 19 17:57:56 2001
+++ readconf.new.c      Mon Oct 15 14:28:43 2001
@@ -9,6 +9,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+ *
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
  */
 
 #include "includes.h"
@@ -793,6 +819,12 @@
        options->preferred_authentications = NULL;
        options->bind_address = NULL;
        options->smartcard_device = NULL;
+       /*
+        * SD Mod: Initialize option to use steno timing manipulation.
+        * By default, timing analysis evasion is used.  The -S flag 
+        * must be used to turn off this feature.
+        */
+       options->use_steno_timing_manipulation = 1;
 }
 
 /*
--- readconf.h  Wed Sep 19 17:57:56 2001
+++ readconf.new.h      Mon Oct 15 14:28:43 2001
@@ -9,6 +9,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+ *
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
  */
 
 /* RCSID("$OpenBSD: readconf.h,v 1.39 2001/09/19 19:24:18 stevesk Exp
$"); */
@@ -101,6 +127,14 @@
        int     num_remote_forwards;
        Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION];
        int     clear_forwardings;
+
+       /*
+        * SD Mod: Added option to use steno timing manipulation.
+        * By default, timing analysis evasion is used.  The -S flag 
+        * must be used to turn off this feature.
+        */
+        int     use_steno_timing_manipulation;
+
 }       Options;
 
 
--- servconf.c  Wed Sep 12 09:32:15 2001
+++ servconf.new.c      Mon Oct 15 14:28:43 2001
@@ -7,6 +7,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
+ *
  */
 
 #include "includes.h"
@@ -105,6 +131,12 @@
        options->authorized_keys_file = NULL;
        options->authorized_keys_file2 = NULL;
        options->pam_authentication_via_kbd_int = -1;
+       /*
+        * SD Mod: Initialize option to use steno timing manipulation.
+        * By default, timing analysis evasion is used.  The -S flag 
+        * must be used to turn off this feature.
+        */
+       options->use_steno_timing_manipulation = 1;
 }
 
 void
--- servconf.h  Wed Sep 12 09:40:06 2001
+++ servconf.new.h      Mon Oct 15 14:28:43 2001
@@ -9,6 +9,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
+ *
  */
 
 /* RCSID("$OpenBSD: servconf.h,v 1.49 2001/08/17 18:59:47 stevesk Exp
$"); */
@@ -129,7 +155,12 @@
        char   *authorized_keys_file;   /* File containing public keys
*/
        char   *authorized_keys_file2;
        int     pam_authentication_via_kbd_int;
-
+       /*
+        * SD Mod: Added option to use steno timing manipulation.
+        * By default, timing analysis evasion is used.  The -S flag 
+        * must be used to turn off this feature.
+        */
+        int     use_steno_timing_manipulation;
 }       ServerOptions;
 
 void    initialize_server_options(ServerOptions *);
--- serverloop.c        Mon Sep 17 22:53:13 2001
+++ serverloop.new.c    Mon Oct 15 14:28:43 2001
@@ -21,6 +21,31 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
***************************************************************************
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
@@ -167,15 +192,24 @@
  * have data or can accept data.  Optionally, a maximum time can be
specified
  * for the duration of the wait (0 = infinite).
  */
-static void
+
+/*
+ * SD Mod: 
+ * We changed wait_until_can_do_something's return value from void
+ * to int.  It now returns 1 if the steno_timer has expired and 0 if
not.
+ */
+int
 wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int
*maxfdp,
     int *nallocp, u_int max_time_milliseconds)
 {
-       struct timeval tv, *tvp;
+  
+        struct timeval tv, *tvp;
+       /* SD Mod: added variable steno_timer*/
+       static struct timeval steno_timer = {0, 50000};
        int ret;
        int client_alive_scheduled = 0;
-
-       /*
+       long int prev_timer_val = 0;
+       /* 
         * if using client_alive, set the max timeout accordingly, 
         * and indicate that this particular timeout was for client
         * alive by setting the client_alive_scheduled flag.
@@ -183,11 +217,11 @@
         * this could be randomized somewhat to make traffic
         * analysis more difficult, but we're not doing it yet.  
         */
-       if (compat20 &&
-           max_time_milliseconds == 0 && options.client_alive_interval)
{
-               client_alive_scheduled = 1;
+       if (max_time_milliseconds == 0 && options.client_alive_interval)
{
+               client_alive_scheduled = 1;
                max_time_milliseconds = options.client_alive_interval *
1000;
-       }
+       } else 
+               client_alive_scheduled = 0;
 
        /* When select fails we restart from here. */
 retry_select:
@@ -199,7 +233,8 @@
                /* wrong: bad condition XXX */
                if (channel_not_very_much_buffered_data())
                        FD_SET(connection_in, *readsetp);
-       } else {
+       
+} else {
                /*
                 * Read packets from the client unless we have too much
                 * buffered stdin or channel data.
@@ -250,8 +285,21 @@
        if (tvp!=NULL)
                debug3("tvp!=NULL kid %d mili %d", child_terminated,
max_time_milliseconds);
 
+
+       /* SD Mod: if select does not decrement timer, force it.*/      
+       prev_timer_val = steno_timer.tv_usec;   
+       
+       ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL,
&steno_timer);
+       
+       if(prev_timer_val == steno_timer.tv_usec)
+         {
+           debug3 ("decrementing timer forcefully");
+           steno_timer.tv_usec -= 100;    
+         }
+       /* End SD Mod */
+
        /* Wait for something to happen, or the timeout to expire. */
-       ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
+
 
        if (ret == -1) {
                if (errno != EINTR)
@@ -259,9 +307,11 @@
                else
                        goto retry_select;
        }
+       
        if (ret == 0 && client_alive_scheduled) {
                /* timeout, check to see how many we have had */
-               client_alive_timeouts++;
+         
+         client_alive_timeouts++;
 
                if (client_alive_timeouts >
options.client_alive_count_max ) {
                        packet_disconnect(
@@ -282,9 +332,27 @@
                                packet_disconnect(
                                        "No open channels after
timeout!");
                }
-       } 
+       }
+
+       /* 
+        * Begin SD Mod: Return to the caller whether the timer has 
+        * expired or not. It is possible that the forced decrement
caused 
+        * the timer value to bbecome negative, if so the consider the 
+        * timer expired, reset it and return 1 to the caller denoting
timer 
+        * expiration.
+        */     
+       if(steno_timer.tv_usec <= 0)
+        {
+          steno_timer.tv_usec = 50000;
+          return 1;
+        }      
+       else
+         return 0;
+       /* End SD Mod */
+
 }
 
+
 /*
  * Processes input from the client and the program.  Input data is
stored
  * in buffers and processed later.
@@ -448,6 +516,13 @@
        u_int stdout_buffer_bytes;
        int type;
 
+       /*
+        * Begin SD Mod: 
+        * NOT USED only here for compatibility with
channel_output_poll().
+        */
+       int bogus_send_count = 0;
+       /* End SD Mod */
+
        debug("Entering interactive session.");
 
        /* Initialize the SIGCHLD kludge. */
@@ -549,8 +624,15 @@
                previous_stdout_buffer_bytes =
buffer_len(&stdout_buffer);
 
                /* Send channel data to the client. */
-               if (packet_not_very_much_data_to_write())
-                       channel_output_poll();
+               /* 
+                * Begin SD Mod: use bogus_send_count to comply 
+                * with channel_output_poll definition.
+                */
+               if(packet_not_very_much_data_to_write())
+                 channel_output_poll(&bogus_send_count,0);
+               /*
+                * End SD Mod 
+                */ 
 
                /*
                 * Bail out of the loop if the program has closed its
output
@@ -579,7 +661,7 @@
                max_fd = MAX(max_fd, fderr);
 
                /* Sleep in select() until we can do something. */
-               wait_until_can_do_something(&readset, &writeset,
&max_fd,
+                wait_until_can_do_something(&readset, &writeset,
&max_fd,
                    &nalloc, max_time_milliseconds);
 
                /* Process any channel events. */
@@ -676,6 +758,14 @@
        int rekeying = 0, max_fd, status, nalloc = 0;
        pid_t pid;
 
+       /* 
+        * Begin SD Mod: 
+        * NOT USED only here for compatibility with
channel_output_poll().
+        */
+       int bogus_send_count = 0 ;
+       int time_out = 0;
+       /* End SD Mod */
+
        debug("Entering interactive session for SSH2.");
 
        mysignal(SIGCHLD, sigchld_handler);
@@ -692,30 +782,44 @@
                process_buffered_input_packets();
 
                rekeying = (xxx_kex != NULL && !xxx_kex->done);
-
-               if (!rekeying && packet_not_very_much_data_to_write())
-                       channel_output_poll();
-               wait_until_can_do_something(&readset, &writeset,
&max_fd,
-                   &nalloc, 0);
+               
+               /*
+                * Begin SD Mod: send packets only when not rekeying and
+                * 50 ms timer has expired. 
+                */
+               if (!rekeying && time_out) 
+                 {
+                  
channel_output_poll(&bogus_send_count,options.use_steno_timing_manipulation);
+                   time_out = 0;
+                 }
+               
+
+               /* 
+                * SD Mod: added time_out flag to record when 
+                * 50 ms timer has expired.
+                */
+               time_out = wait_until_can_do_something(&readset,
&writeset, &max_fd, &nalloc, rekeying);
+               /* End SD Mod */
+               
                if (child_terminated) {
-                       while ((pid = waitpid(-1, &status, WNOHANG)) >
0)
-                               session_close_by_pid(pid, status);
-                       child_terminated = 0;
+                 while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
+                   session_close_by_pid(pid, status);
+                 child_terminated = 0;
                }
                if (!rekeying)
-                       channel_after_select(readset, writeset);
+                 channel_after_select(readset, writeset);
                process_input(readset);
                if (connection_closed)
-                       break;
+                 break;
                process_output(writeset);
        }
        if (readset)
-               xfree(readset);
+         xfree(readset);
        if (writeset)
-               xfree(writeset);
+         xfree(writeset);
 
        mysignal(SIGCHLD, SIG_DFL);
-
+       
        while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
                session_close_by_pid(pid, status);
        /*
@@ -894,6 +998,17 @@
                        packet_put_int(c->local_maxpacket);
                        packet_send();
                }
+               /* 
+                * SD Mod: if -S option is used, request 
+                * client to not use stenographic timing manipulation as
well.
+                */
+               if(!options.use_steno_timing_manipulation)
+                 {
+                   debug("sending no steno msg");
+                   channel_request(c->remote_id,"no_steno",0);
+                 }
+               /* End SD Mod */
+
        } else {
                debug("server_input_channel_open: failure %s", ctype);
                packet_start(SSH2_MSG_CHANNEL_OPEN_FAILURE);
--- session.c   Sun Sep 16 15:17:15 2001
+++ session.new.c       Mon Oct 15 14:28:43 2001
@@ -20,6 +20,32 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -1726,6 +1752,24 @@
        return 1;
 }
 
+
+/*
+ * Begin SD Mod: This function is added to handle a request from the 
+ * client to turn off steno timing manipulation.  
+ */
+int
+session_no_steno_req(Session *s)
+{
+       packet_done();
+       debug("handling steno request");
+       if(options.use_steno_timing_manipulation)
+         {
+           options.use_steno_timing_manipulation = 0;
+         }
+       return 1;
+}
+/* End SD Mod */
+
 static int
 session_exec_req(Session *s)
 {
@@ -1795,6 +1839,14 @@
                } else if (strcmp(rtype, "subsystem") == 0) {
                        success = session_subsystem_req(s);
                }
+               /* 
+                * Begin SD Mod: Handle request from the client 
+                * to turn off server's timing manipulation.
+                */ 
+               else if (strcmp(rtype, "no_steno") == 0) {
+                 success = session_no_steno_req(s);
+               }
+               /* End SD Mod */
        }
        if (strcmp(rtype, "window-change") == 0) {
                success = session_window_change_req(s);
--- ssh.c       Mon Sep 24 15:04:03 2001
+++ ssh.new.c   Mon Oct 15 14:28:43 2001
@@ -26,6 +26,31 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+ *
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
***************************************************************************
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -205,6 +230,8 @@
        fprintf(stderr, "  -o 'option' Process the option as if it was
read from a configuration file.\n");
        fprintf(stderr, "  -s          Invoke command (mandatory) as
SSH2 subsystem.\n");
        fprintf(stderr, "  -b addr     Local IP address.\n");
+       /* SD Mod: */
+       fprintf(stderr, "  -S          Don't use stenographic timing
manipulation\n");
        exit(1);
 }
 
@@ -319,8 +346,9 @@
        host = NULL;
 
 again:
+       /* SD Mod: add s option to getopt() call */
        while ((opt = getopt(ac, av,
-           "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) {
+           "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:STVX")) != -1)
{
                switch (opt) {
                case '1':
                        options.protocol = SSH_PROTO_1;
@@ -525,6 +553,14 @@
                case 's':
                        subsystem_flag = 1;
                        break;
+                       /*
+                        * Begin SD Mod: Add case to handle option to
turn off
+                        * steno timing manipulation.
+                        */
+               case 'S':
+                       options.use_steno_timing_manipulation = 0;
+                       break;
+                       /* End SD Mod */
                case 'b':
                        options.bind_address = optarg;
                        break;
@@ -1080,6 +1116,20 @@
                channel_request_start(id, "auth-agent-req at openssh.com",
0);
                packet_send();
        }
+
+       /*
+        * Begin SD Mod: If the client has the option to turn of timing
+        * manipulation set, send a request message to the server to 
+        * turn off its timing manipulation.
+        */
+       if (!options.use_steno_timing_manipulation)
+         {
+           debug("sending request for no steno.");
+           channel_request_start(id, "no_steno",0);
+           packet_send();
+         }
+       /* End SD Mod */
+
 
        len = buffer_len(&command);
        if (len > 0) {
--- sshd.c      Mon Sep 17 21:03:04 2001
+++ sshd.new.c  Mon Oct 15 14:28:43 2001
@@ -26,6 +26,31 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
+ *
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*******************************************************************************
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
@@ -563,6 +588,7 @@
        initialize_server_options(&options);
 
        /* Parse command-line arguments. */
+       /* SD Mod: add s option to getopt() call */
        while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDeiqtQ46")) !=
-1) {
                switch (opt) {
                case '4':
@@ -645,6 +671,14 @@
                case 'u':
                        utmp_len = atoi(optarg);
                        break;
+                       /*
+                        * Begin SD Mod: Add option to handle option to
turn off
+                        * steno timing manipulation. 
+                        */
+               case 'S':
+                       options.use_steno_timing_manipulation = 0;
+                       break;
+                       /* End SD Mod */
                case '?':
                default:
                        fprintf(stderr, "sshd version %s\n",
SSH_VERSION);
@@ -665,6 +699,9 @@
                        fprintf(stderr, "  -u len     Maximum hostname
length for utmp recording\n");
                        fprintf(stderr, "  -4         Use IPv4 only\n");
                        fprintf(stderr, "  -6         Use IPv6 only\n");
+                       /* SD Mod */
+                       fprintf(stderr, "  -S         Don't use
stenographic timing manipulation\n");
+
                        exit(1);
                }
        }




--
regards,

Jason Coit

+--                                             --+
|        C. Jason Coit Programmer/Analyst         |
| *Silicon Defense - Technical Support for Snort* |
|        http://www.silicondefense.com/           |
+--                                              -+


From djast at cs.toronto.edu  Wed Oct 17 05:36:42 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 16 Oct 2001 15:36:42 -0400
Subject: Solaris 2.5.1 dirname() bug in libgen.a affects OpenSSH2.9.9p2 auth.c
Message-ID: <01Oct16.153647edt.453142-8581@jane.cs.toronto.edu>

I've discovered a problem with OpenSSH 2.9.9p2 under Solaris 2.5.1 .

In auth.c, secure_filename() walks upwards toward the user's home
directory or the filesystem root, verifying that no directories along
the way are group or world writable.

Solaris 2.5.1's dirname() function has a bug where dirname("/.ssh")
returns an empty string instead of "/".

This causes secure_filename() to try to stat(""), fail, and report
"bad ownership or modes for directory ".

I discovered this when upgrading from 2.3.0p1 to 2.9.9p2: root was
unable to use RSA authentication because of it.

The bug is in Solaris 2.5.1, not OpenSSH, but it would be helpful if
OpenSSH could work around this bug.  As far as I've been able to
determine, no patch is available for Solaris 2.5.1.

The change I made to OpenSSH 2.9.9p2's auth.c to work around the problem
is attached.

Incidentally: it may be worth considering modifying the code to compare
the device/inode numbers of the directories, rather than the pathnames,
when determining whether the home directory has been reached.  If
pw->pw_dir contains a nonstandard construction (e.g., symbolic links,
extra slashes within the path, or something else that might be changed
by realpath()), the code might continue to walk upwards past the user's
home directory.

Thanks for your attention,

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican
-------------- next part --------------
===================================================================
*** /cs/3/src/openssh-2.9.9p2/auth.c	2001/10/16 18:24:09	1.1
--- /cs/3/src/openssh-2.9.9p2/auth.c	2001/10/16 19:23:33
***************
*** 388,393 ****
--- 388,395 ----
  			snprintf(err, errlen, "dirname() failed");
  			return -1;
  		}
+ 		/* work around Solaris 2.5.1 libgen bug */
+ 		if (cp[0] == '\0') cp = "/";
  		strlcpy(buf, cp, sizeof(buf));
  
  		debug3("secure_filename: checking '%s'", buf);

From Nicolas.Williams at ubsw.com  Wed Oct 17 07:36:18 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Tue, 16 Oct 2001 17:36:18 -0400
Subject: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and 2.9p2
In-Reply-To: <3BCC889C.AA5C57F0@silicondefense.com>; from jasonc@silicondefense.com on Tue, Oct 16, 2001 at 12:21:00PM -0700
References: <3BCC889C.AA5C57F0@silicondefense.com>
Message-ID: <20011016173617.W5739@sm2p1386swk.wdr.com>

Let's see. The timing attack has to do with predictable timing. The
solution would seem to be to add randomness to the packet timing. Your
patch does not do this -- it adds more predictable traffic.

I would think that to defeat the timing attack SSH would have to send
random-sized no-op packets at random intervals, or perhaps just adding
random delays before sending packets. And, of course, we're not talking
IP packets here, but SSH "packets."

But I could be wrong, I'm not an expert on this subject.

Nico


On Tue, Oct 16, 2001 at 12:21:00PM -0700, C. Jason Coit wrote:
> Hello,
> 
> In response to the timing analysis attacks presented by Dawn Song et.
> al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html
> we
> at Silicon Defense developed a patch for openssh to avoid such
> measures.  
> 
> Timing Analysis Evasion changes were developed by C. Jason Coit and Roel
> Jonkman of Silicon Defense.
> 
> These changes cause SSH to send packets unless request not to, exactly
> every 50 ms.  IF no data is ready to be sent, SSH will send a bogus
> packet with 16 bytes of data (which is the same size as most
> keystrokes).  Thus someone performing timing analysis cannot determine
> the inter keystroke timing of a user.  SSH will send bogus data for
> about 1 second after the last keystroke.  This both increases the
> difficulty of determining exact password lengths and conserves bandwidth
> when a user is idle (e.g. taking a coffee break).  Both the Server and
> the Client exhibit this behavior and yet our code places no limit on the
> data rate(i.e. if the server needs to respond with large amounts of data
> it will be able to do so with large packets and without the 50 ms timing
> constraint).  
> 
> We currently have patches and modified distributions for OpenSSH 2.9p2
> and 2.9.9p2.  
> The files for OpenSSH 2.9p2 are available at
> http://www.silicondefense.com/software/ssh/ssh-2.9p2-diffs
> http://www.silicondefense.com/software/ssh/opens3h-2.9p2.tar.gz
> 
> These files for OpenSSH 2.9.9p2 are available at
> http://www.silicondefense.com/software/ssh/ssh-2.9.9p2-diffs
> http://www.silicondefense.com/software/ssh/opens3h-2.9.9p2.tar.gz
> 
> The patch for 2.9.9p2 is available below:
> 
> --- channels.c  Mon Sep 17 22:53:12 2001
> +++ channels.new.c      Mon Oct 15 14:28:43 2001
> @@ -25,6 +25,32 @@
>   * 2. Redistributions in binary form must reproduce the above copyright
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
> +
> ***************************************************************************
> + *
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/13/2001.
> +
> *************************************************************************** 
>   *
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
> @@ -1590,9 +1616,12 @@
>  
>  
>  /* If there is data to send to the connection, enqueue some of it now.
> */
> -
> +/*
> + * SD Mod: add arguments bogus_send_count and
> use_steno_timing_manipulation 
> + * to channel_output_poll.
> +*/
>  void
> -channel_output_poll()
> +channel_output_poll(int *bogus_send_count, int
> use_steno_timing_manipulation)
>  {
>         int len, i;
>         Channel *c;
> @@ -1649,11 +1678,49 @@
>                                     SSH2_MSG_CHANNEL_DATA :
> SSH_MSG_CHANNEL_DATA);
>                                 packet_put_int(c->remote_id);
>                                 packet_put_string(buffer_ptr(&c->input),
> len);
> +                               /* 
> +                                *  Begin SD Mod: if using SSH2 and it
> is 
> +                                *  desired to use timing manipulation,
> reset
> +                                *  counter since len > 0 implies packet
> will
> +                                *  contain geniune data.
> +                                */
> +                               if(compat20 &&
> use_steno_timing_manipulation)
> +                                 {
> +                                   (*bogus_send_count)=0;
> +                                   debug2("reseting count");
> +                                 }
> +                               /* End SD Mod */
>                                 packet_send();
>                                 buffer_consume(&c->input, len);
>                                 c->remote_window -= len;
>                         }
> -               } else if (c->istate == CHAN_INPUT_WAIT_DRAIN) {
> +               }
> +                 /*
> +                  * Begin SD Mod:
> +                  * packet does not contain data, we are not in a
> draining
> +                  * state and timing manipulation is desired, check if
> bogus 
> +                  * count is below threshold.
> +                  */
> +               else if ((len = buffer_len(&c->input)) == 0 
> +                        && !(c->istate == CHAN_INPUT_WAIT_DRAIN) 
> +                        && use_steno_timing_manipulation)
> {                 
> +                   /* 
> +                    * If we have not sent too many bogus packets, sent
> a 16
> +                    * byte ignore packet filled with garbage data and
> update
> +                    * the bogus_send_count;
> +                    */
> +
> +                   if((*bogus_send_count) < 20){
> +                     debug2("sending garbage packet");
> +                     packet_send_ignore(16);
> +                     packet_send();
> +                     (*bogus_send_count)++;
> +                   }
> +                   else
> +                     debug("max number of timeouts exceeded: stop
> sending garbage packets");
> +                 }
> +               /* End SD Mod */ 
> +               else if (c->istate == CHAN_INPUT_WAIT_DRAIN) {
>                         if (compat13)
>                                 fatal("cannot happen: istate ==
> INPUT_WAIT_DRAIN for proto 1.3");
>                         /*
> --- channels.h  Mon Sep 17 22:51:14 2001
> +++ channels.new.h      Mon Oct 15 14:28:43 2001
> @@ -21,6 +21,33 @@
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
>   *
> +
> ***************************************************************************
> + *
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/13/2001.
> +
> *************************************************************************** 
> + *
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
>   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED.
> @@ -173,7 +200,15 @@
>  
>  void    channel_prepare_select(fd_set **, fd_set **, int *, int*, int);
>  void     channel_after_select(fd_set *, fd_set *);
> -void     channel_output_poll(void);
> +
> +/*
> + * SD Mod: added parameters bogus_send_count, and
> use_steno_timing_manipulation.
> + * The bogus_send_count keeps track of how many bogus packets have been
> sent since
> + * the last packet containing real data.  The
> use_steno_timining_manipulation flag
> + * keeps track of whether to perform timing analysis evasion.
> + */
> +void channel_output_poll(int *bogus_send_count, int
> use_steno_timing_manipulation);
> +
>  
>  int      channel_not_very_much_buffered_data(void);
>  void     channel_close_all(void);
> --- clientloop.c        Mon Sep 17 22:51:14 2001
> +++ clientloop.new.c    Mon Oct 15 14:28:43 2001
> @@ -46,6 +46,33 @@
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
>   *
> +
> ***************************************************************************
> + *
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/13/2001.
> +
> *************************************************************************** 
> + *
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
>   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED.
> @@ -315,16 +342,25 @@
>   * Waits until the client can do something (some data becomes available
> on
>   * one of the file descriptors).
>   */
> -
> -static void
> +/* 
> + * SD Mod: We changed the return value of
> client_wait_until_can_do_something 
> + * from void to int.  It now returns 1 if the steno_timer has expired
> and 0 if not.
> + */
> +int
>  client_wait_until_can_do_something(fd_set **readsetp, fd_set
> **writesetp,
>      int *maxfdp, int *nallocp, int rekeying)
>  {
> +        /* SD Mod: added variable steno_timer */
> +        static struct timeval steno_timer = {0, 50000};
> +
> +       int return_val = 0;
> +       long int prev_timer_val = 0;
> +
>         /* Add any selections by the channel mechanism. */
>         channel_prepare_select(readsetp, writesetp, maxfdp, nallocp,
> rekeying);
>  
>         if (!compat20) {
> -               /* Read from the connection, unless our buffers are
> full. */
> +         /* Read from the connection, unless our buffers are full. */
>                 if (buffer_len(&stdout_buffer) < buffer_high &&
>                     buffer_len(&stderr_buffer) < buffer_high &&
>                     channel_not_very_much_buffered_data())
> @@ -342,13 +378,7 @@
>                 if (buffer_len(&stderr_buffer) > 0)
>                         FD_SET(fileno(stderr), *writesetp);
>         } else {
> -               /* channel_prepare_select could have closed the last
> channel */
> -               if (session_closed && !channel_still_open()) {
> -                       if (!packet_have_data_to_write())
> -                               return;
> -               } else {
> -                       FD_SET(connection_in, *readsetp);
> -               }
> +               FD_SET(connection_in, *readsetp);
>         }
>  
>         /* Select server connection if have data to write to the server.
> */
> @@ -363,9 +393,34 @@
>          * it: just have a random timeout for the select, and send a
> random
>          * SSH_MSG_IGNORE packet when the timeout expires.
>          */
> +       
> +       /*
> +        * Begin SD Mod: 
> +        * Enforce wait send packets every 50 ms.  To do this add timer
> to 
> +        * select loop.  Buffer input as it comes and force the timer to
> decrement
> +        * if select call does not do so.   
> +        */
> +       prev_timer_val = steno_timer.tv_usec;
> +
> +       return_val = select((*maxfdp)+1, *readsetp, *writesetp, NULL,
> &steno_timer);
>  
> -       if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0)
> {
> -               char buf[100];
> +       /* SD Mod continued:
> +        * If the prev_timer_val is still equal to the
> steno_timer.tv_usec value
> +        * then select did not decrement timer.  So force decrement so
> timer can
> +        * expire. This problem arises since the file descriptors change
> since they 
> +        * were reset just prior to entering the select loop.  This is a
> strange
> +        * fix but it works.
> +        */
> +       
> +         if(prev_timer_val == steno_timer.tv_usec){
> +           debug3("decrementing timer forcefully");
> +           steno_timer.tv_usec -= 100;
> +         }
> +
> +         if(return_val < 0){
> +       /* end of SD Mod */
> +           
> +           char buf[100];
>  
>                 /*
>                  * We have to clear the select masks, because we return.
> @@ -376,14 +431,29 @@
>                 memset(*writesetp, 0, *maxfdp);
>  
>                 if (errno == EINTR)
> -                       return;
> +                       return 0;
>                 /* Note: we might still have data in the buffers. */
>                 snprintf(buf, sizeof buf, "select: %s\r\n",
> strerror(errno));
>                 buffer_append(&stderr_buffer, buf, strlen(buf));
>                 quit_pending = 1;
>         }
> +         /* 
> +          * Begin SD Mod: Return to the caller whether the timer has 
> +          * expired or not. It is possible that the forced decrement
> caused 
> +          * the timer value to bbecome negative, if so the consider the 
> +          * timer expired, reset it and return 1 to the caller denoting
> timer 
> +          * expiration.
> +          */   
> +         if(steno_timer.tv_usec <= 0)
> +           {
> +             steno_timer.tv_usec = 50000;
> +             return 1;  
> +           }
> +         else
> +           return 0;
> +         /* End SD Mod */
> +                 
>  }
> -
>  static void
>  client_suspend_self(Buffer *bin, Buffer *bout, Buffer *berr)
>  {
> @@ -773,6 +843,15 @@
>         int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0;
>         char buf[100];
>  
> +       /*
> +        * Begin SD Mod: 
> +        * Add counter for number of fake packets that have been sent.
> +        * Add time_out flag for marking when timeout has occured.
> +        */
> +       int bogus_send_count = 0;
> +       int time_out = 0;
> +       /* End SD Mod */
> +
>         debug("Entering interactive session.");
>  
>         start_time = get_current_time();
> @@ -861,9 +940,16 @@
>                          * Make packets from buffered channel data, and
>                          * enqueue them for sending to the server.
>                          */
> -                       if (packet_not_very_much_data_to_write())
> -                               channel_output_poll();
> -
> +                       /*
> +                        * Begin SD Mod: on expiration of 50 ms timer
> call 
> +                        * channel_ouput 
> +                        */
> +                       if(time_out){
> +                        
> channel_output_poll(&bogus_send_count,options.use_steno_timing_manipulation);
> +                         time_out = 0;
> +                       }
> +                       /* End SD Mod */
> +                       
>                         /*
>                          * Check if the window size has changed, and
> buffer a
>                          * message about it to the server if so.
> @@ -878,8 +964,10 @@
>                  * available on one of the descriptors).
>                  */
>                 max_fd2 = max_fd;
> -               client_wait_until_can_do_something(&readset, &writeset,
> -                   &max_fd2, &nalloc, rekeying);
> +
> +               /* SD Mod: wait for data or timeout */
> +               time_out = client_wait_until_can_do_something(&readset,
> +                                &writeset, &max_fd2, &nalloc,
> rekeying);               
>  
>                 if (quit_pending)
>                         break;
> @@ -1222,6 +1310,21 @@
>                 exit_status = packet_get_int();
>                 packet_done();
>         }
> +       /*
> +        * Begin SD Mod: 
> +        * check to see if request from server is to turn off steno.
> +        * If so, turn it off if neccessary.  
> +        */
> +       else if (strcmp(rtype, "no_steno") == 0) { 
> +         debug("received request not use use steno");
> +         if(options.use_steno_timing_manipulation)
> +           {
> +             options.use_steno_timing_manipulation = 0;
> +           }
> +         success = 1;
> +         packet_done();
> +       }
> +       /* End SD Mod */
>         if (reply) {
>                 packet_start(success ?
>                     SSH2_MSG_CHANNEL_SUCCESS :
> SSH2_MSG_CHANNEL_FAILURE);
> --- readconf.c  Wed Sep 19 17:57:56 2001
> +++ readconf.new.c      Mon Oct 15 14:28:43 2001
> @@ -9,6 +9,32 @@
>   * software must be clearly marked as such, and if the derived work is
>   * incompatible with the protocol description in the RFC file, it must
> be
>   * called by a name other than "ssh" or "Secure Shell".
> + *
> +
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/3/2001.
> +
> *************************************************************************** 
>   */
>  
>  #include "includes.h"
> @@ -793,6 +819,12 @@
>         options->preferred_authentications = NULL;
>         options->bind_address = NULL;
>         options->smartcard_device = NULL;
> +       /*
> +        * SD Mod: Initialize option to use steno timing manipulation.
> +        * By default, timing analysis evasion is used.  The -S flag 
> +        * must be used to turn off this feature.
> +        */
> +       options->use_steno_timing_manipulation = 1;
>  }
>  
>  /*
> --- readconf.h  Wed Sep 19 17:57:56 2001
> +++ readconf.new.h      Mon Oct 15 14:28:43 2001
> @@ -9,6 +9,32 @@
>   * software must be clearly marked as such, and if the derived work is
>   * incompatible with the protocol description in the RFC file, it must
> be
>   * called by a name other than "ssh" or "Secure Shell".
> + *
> +
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/3/2001.
> +
> *************************************************************************** 
>   */
>  
>  /* RCSID("$OpenBSD: readconf.h,v 1.39 2001/09/19 19:24:18 stevesk Exp
> $"); */
> @@ -101,6 +127,14 @@
>         int     num_remote_forwards;
>         Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION];
>         int     clear_forwardings;
> +
> +       /*
> +        * SD Mod: Added option to use steno timing manipulation.
> +        * By default, timing analysis evasion is used.  The -S flag 
> +        * must be used to turn off this feature.
> +        */
> +        int     use_steno_timing_manipulation;
> +
>  }       Options;
>  
>  
> --- servconf.c  Wed Sep 12 09:32:15 2001
> +++ servconf.new.c      Mon Oct 15 14:28:43 2001
> @@ -7,6 +7,32 @@
>   * software must be clearly marked as such, and if the derived work is
>   * incompatible with the protocol description in the RFC file, it must
> be
>   * called by a name other than "ssh" or "Secure Shell".
> +
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/3/2001.
> +
> *************************************************************************** 
> + *
>   */
>  
>  #include "includes.h"
> @@ -105,6 +131,12 @@
>         options->authorized_keys_file = NULL;
>         options->authorized_keys_file2 = NULL;
>         options->pam_authentication_via_kbd_int = -1;
> +       /*
> +        * SD Mod: Initialize option to use steno timing manipulation.
> +        * By default, timing analysis evasion is used.  The -S flag 
> +        * must be used to turn off this feature.
> +        */
> +       options->use_steno_timing_manipulation = 1;
>  }
>  
>  void
> --- servconf.h  Wed Sep 12 09:40:06 2001
> +++ servconf.new.h      Mon Oct 15 14:28:43 2001
> @@ -9,6 +9,32 @@
>   * software must be clearly marked as such, and if the derived work is
>   * incompatible with the protocol description in the RFC file, it must
> be
>   * called by a name other than "ssh" or "Secure Shell".
> +
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/3/2001.
> +
> *************************************************************************** 
> + *
>   */
>  
>  /* RCSID("$OpenBSD: servconf.h,v 1.49 2001/08/17 18:59:47 stevesk Exp
> $"); */
> @@ -129,7 +155,12 @@
>         char   *authorized_keys_file;   /* File containing public keys
> */
>         char   *authorized_keys_file2;
>         int     pam_authentication_via_kbd_int;
> -
> +       /*
> +        * SD Mod: Added option to use steno timing manipulation.
> +        * By default, timing analysis evasion is used.  The -S flag 
> +        * must be used to turn off this feature.
> +        */
> +        int     use_steno_timing_manipulation;
>  }       ServerOptions;
>  
>  void    initialize_server_options(ServerOptions *);
> --- serverloop.c        Mon Sep 17 22:53:13 2001
> +++ serverloop.new.c    Mon Oct 15 14:28:43 2001
> @@ -21,6 +21,31 @@
>   * 2. Redistributions in binary form must reproduce the above copyright
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
> +
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/13/2001.
> +
> ***************************************************************************
>   *
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
> @@ -167,15 +192,24 @@
>   * have data or can accept data.  Optionally, a maximum time can be
> specified
>   * for the duration of the wait (0 = infinite).
>   */
> -static void
> +
> +/*
> + * SD Mod: 
> + * We changed wait_until_can_do_something's return value from void
> + * to int.  It now returns 1 if the steno_timer has expired and 0 if
> not.
> + */
> +int
>  wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int
> *maxfdp,
>      int *nallocp, u_int max_time_milliseconds)
>  {
> -       struct timeval tv, *tvp;
> +  
> +        struct timeval tv, *tvp;
> +       /* SD Mod: added variable steno_timer*/
> +       static struct timeval steno_timer = {0, 50000};
>         int ret;
>         int client_alive_scheduled = 0;
> -
> -       /*
> +       long int prev_timer_val = 0;
> +       /* 
>          * if using client_alive, set the max timeout accordingly, 
>          * and indicate that this particular timeout was for client
>          * alive by setting the client_alive_scheduled flag.
> @@ -183,11 +217,11 @@
>          * this could be randomized somewhat to make traffic
>          * analysis more difficult, but we're not doing it yet.  
>          */
> -       if (compat20 &&
> -           max_time_milliseconds == 0 && options.client_alive_interval)
> {
> -               client_alive_scheduled = 1;
> +       if (max_time_milliseconds == 0 && options.client_alive_interval)
> {
> +               client_alive_scheduled = 1;
>                 max_time_milliseconds = options.client_alive_interval *
> 1000;
> -       }
> +       } else 
> +               client_alive_scheduled = 0;
>  
>         /* When select fails we restart from here. */
>  retry_select:
> @@ -199,7 +233,8 @@
>                 /* wrong: bad condition XXX */
>                 if (channel_not_very_much_buffered_data())
>                         FD_SET(connection_in, *readsetp);
> -       } else {
> +       
> +} else {
>                 /*
>                  * Read packets from the client unless we have too much
>                  * buffered stdin or channel data.
> @@ -250,8 +285,21 @@
>         if (tvp!=NULL)
>                 debug3("tvp!=NULL kid %d mili %d", child_terminated,
> max_time_milliseconds);
>  
> +
> +       /* SD Mod: if select does not decrement timer, force it.*/      
> +       prev_timer_val = steno_timer.tv_usec;   
> +       
> +       ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL,
> &steno_timer);
> +       
> +       if(prev_timer_val == steno_timer.tv_usec)
> +         {
> +           debug3 ("decrementing timer forcefully");
> +           steno_timer.tv_usec -= 100;    
> +         }
> +       /* End SD Mod */
> +
>         /* Wait for something to happen, or the timeout to expire. */
> -       ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
> +
>  
>         if (ret == -1) {
>                 if (errno != EINTR)
> @@ -259,9 +307,11 @@
>                 else
>                         goto retry_select;
>         }
> +       
>         if (ret == 0 && client_alive_scheduled) {
>                 /* timeout, check to see how many we have had */
> -               client_alive_timeouts++;
> +         
> +         client_alive_timeouts++;
>  
>                 if (client_alive_timeouts >
> options.client_alive_count_max ) {
>                         packet_disconnect(
> @@ -282,9 +332,27 @@
>                                 packet_disconnect(
>                                         "No open channels after
> timeout!");
>                 }
> -       } 
> +       }
> +
> +       /* 
> +        * Begin SD Mod: Return to the caller whether the timer has 
> +        * expired or not. It is possible that the forced decrement
> caused 
> +        * the timer value to bbecome negative, if so the consider the 
> +        * timer expired, reset it and return 1 to the caller denoting
> timer 
> +        * expiration.
> +        */     
> +       if(steno_timer.tv_usec <= 0)
> +        {
> +          steno_timer.tv_usec = 50000;
> +          return 1;
> +        }      
> +       else
> +         return 0;
> +       /* End SD Mod */
> +
>  }
>  
> +
>  /*
>   * Processes input from the client and the program.  Input data is
> stored
>   * in buffers and processed later.
> @@ -448,6 +516,13 @@
>         u_int stdout_buffer_bytes;
>         int type;
>  
> +       /*
> +        * Begin SD Mod: 
> +        * NOT USED only here for compatibility with
> channel_output_poll().
> +        */
> +       int bogus_send_count = 0;
> +       /* End SD Mod */
> +
>         debug("Entering interactive session.");
>  
>         /* Initialize the SIGCHLD kludge. */
> @@ -549,8 +624,15 @@
>                 previous_stdout_buffer_bytes =
> buffer_len(&stdout_buffer);
>  
>                 /* Send channel data to the client. */
> -               if (packet_not_very_much_data_to_write())
> -                       channel_output_poll();
> +               /* 
> +                * Begin SD Mod: use bogus_send_count to comply 
> +                * with channel_output_poll definition.
> +                */
> +               if(packet_not_very_much_data_to_write())
> +                 channel_output_poll(&bogus_send_count,0);
> +               /*
> +                * End SD Mod 
> +                */ 
>  
>                 /*
>                  * Bail out of the loop if the program has closed its
> output
> @@ -579,7 +661,7 @@
>                 max_fd = MAX(max_fd, fderr);
>  
>                 /* Sleep in select() until we can do something. */
> -               wait_until_can_do_something(&readset, &writeset,
> &max_fd,
> +                wait_until_can_do_something(&readset, &writeset,
> &max_fd,
>                     &nalloc, max_time_milliseconds);
>  
>                 /* Process any channel events. */
> @@ -676,6 +758,14 @@
>         int rekeying = 0, max_fd, status, nalloc = 0;
>         pid_t pid;
>  
> +       /* 
> +        * Begin SD Mod: 
> +        * NOT USED only here for compatibility with
> channel_output_poll().
> +        */
> +       int bogus_send_count = 0 ;
> +       int time_out = 0;
> +       /* End SD Mod */
> +
>         debug("Entering interactive session for SSH2.");
>  
>         mysignal(SIGCHLD, sigchld_handler);
> @@ -692,30 +782,44 @@
>                 process_buffered_input_packets();
>  
>                 rekeying = (xxx_kex != NULL && !xxx_kex->done);
> -
> -               if (!rekeying && packet_not_very_much_data_to_write())
> -                       channel_output_poll();
> -               wait_until_can_do_something(&readset, &writeset,
> &max_fd,
> -                   &nalloc, 0);
> +               
> +               /*
> +                * Begin SD Mod: send packets only when not rekeying and
> +                * 50 ms timer has expired. 
> +                */
> +               if (!rekeying && time_out) 
> +                 {
> +                  
> channel_output_poll(&bogus_send_count,options.use_steno_timing_manipulation);
> +                   time_out = 0;
> +                 }
> +               
> +
> +               /* 
> +                * SD Mod: added time_out flag to record when 
> +                * 50 ms timer has expired.
> +                */
> +               time_out = wait_until_can_do_something(&readset,
> &writeset, &max_fd, &nalloc, rekeying);
> +               /* End SD Mod */
> +               
>                 if (child_terminated) {
> -                       while ((pid = waitpid(-1, &status, WNOHANG)) >
> 0)
> -                               session_close_by_pid(pid, status);
> -                       child_terminated = 0;
> +                 while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> +                   session_close_by_pid(pid, status);
> +                 child_terminated = 0;
>                 }
>                 if (!rekeying)
> -                       channel_after_select(readset, writeset);
> +                 channel_after_select(readset, writeset);
>                 process_input(readset);
>                 if (connection_closed)
> -                       break;
> +                 break;
>                 process_output(writeset);
>         }
>         if (readset)
> -               xfree(readset);
> +         xfree(readset);
>         if (writeset)
> -               xfree(writeset);
> +         xfree(writeset);
>  
>         mysignal(SIGCHLD, SIG_DFL);
> -
> +       
>         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
>                 session_close_by_pid(pid, status);
>         /*
> @@ -894,6 +998,17 @@
>                         packet_put_int(c->local_maxpacket);
>                         packet_send();
>                 }
> +               /* 
> +                * SD Mod: if -S option is used, request 
> +                * client to not use stenographic timing manipulation as
> well.
> +                */
> +               if(!options.use_steno_timing_manipulation)
> +                 {
> +                   debug("sending no steno msg");
> +                   channel_request(c->remote_id,"no_steno",0);
> +                 }
> +               /* End SD Mod */
> +
>         } else {
>                 debug("server_input_channel_open: failure %s", ctype);
>                 packet_start(SSH2_MSG_CHANNEL_OPEN_FAILURE);
> --- session.c   Sun Sep 16 15:17:15 2001
> +++ session.new.c       Mon Oct 15 14:28:43 2001
> @@ -20,6 +20,32 @@
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
>   *
> +
> ***************************************************************************
> + *
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/13/2001.
> +
> *************************************************************************** 
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
>   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED.
> @@ -1726,6 +1752,24 @@
>         return 1;
>  }
>  
> +
> +/*
> + * Begin SD Mod: This function is added to handle a request from the 
> + * client to turn off steno timing manipulation.  
> + */
> +int
> +session_no_steno_req(Session *s)
> +{
> +       packet_done();
> +       debug("handling steno request");
> +       if(options.use_steno_timing_manipulation)
> +         {
> +           options.use_steno_timing_manipulation = 0;
> +         }
> +       return 1;
> +}
> +/* End SD Mod */
> +
>  static int
>  session_exec_req(Session *s)
>  {
> @@ -1795,6 +1839,14 @@
>                 } else if (strcmp(rtype, "subsystem") == 0) {
>                         success = session_subsystem_req(s);
>                 }
> +               /* 
> +                * Begin SD Mod: Handle request from the client 
> +                * to turn off server's timing manipulation.
> +                */ 
> +               else if (strcmp(rtype, "no_steno") == 0) {
> +                 success = session_no_steno_req(s);
> +               }
> +               /* End SD Mod */
>         }
>         if (strcmp(rtype, "window-change") == 0) {
>                 success = session_window_change_req(s);
> --- ssh.c       Mon Sep 24 15:04:03 2001
> +++ ssh.new.c   Mon Oct 15 14:28:43 2001
> @@ -26,6 +26,31 @@
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
>   *
> + *
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/3/2001.
> +
> ***************************************************************************
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
>   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED.
> @@ -205,6 +230,8 @@
>         fprintf(stderr, "  -o 'option' Process the option as if it was
> read from a configuration file.\n");
>         fprintf(stderr, "  -s          Invoke command (mandatory) as
> SSH2 subsystem.\n");
>         fprintf(stderr, "  -b addr     Local IP address.\n");
> +       /* SD Mod: */
> +       fprintf(stderr, "  -S          Don't use stenographic timing
> manipulation\n");
>         exit(1);
>  }
>  
> @@ -319,8 +346,9 @@
>         host = NULL;
>  
>  again:
> +       /* SD Mod: add s option to getopt() call */
>         while ((opt = getopt(ac, av,
> -           "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) {
> +           "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:STVX")) != -1)
> {
>                 switch (opt) {
>                 case '1':
>                         options.protocol = SSH_PROTO_1;
> @@ -525,6 +553,14 @@
>                 case 's':
>                         subsystem_flag = 1;
>                         break;
> +                       /*
> +                        * Begin SD Mod: Add case to handle option to
> turn off
> +                        * steno timing manipulation.
> +                        */
> +               case 'S':
> +                       options.use_steno_timing_manipulation = 0;
> +                       break;
> +                       /* End SD Mod */
>                 case 'b':
>                         options.bind_address = optarg;
>                         break;
> @@ -1080,6 +1116,20 @@
>                 channel_request_start(id, "auth-agent-req at openssh.com",
> 0);
>                 packet_send();
>         }
> +
> +       /*
> +        * Begin SD Mod: If the client has the option to turn of timing
> +        * manipulation set, send a request message to the server to 
> +        * turn off its timing manipulation.
> +        */
> +       if (!options.use_steno_timing_manipulation)
> +         {
> +           debug("sending request for no steno.");
> +           channel_request_start(id, "no_steno",0);
> +           packet_send();
> +         }
> +       /* End SD Mod */
> +
>  
>         len = buffer_len(&command);
>         if (len > 0) {
> --- sshd.c      Mon Sep 17 21:03:04 2001
> +++ sshd.new.c  Mon Oct 15 14:28:43 2001
> @@ -26,6 +26,31 @@
>   * 2. Redistributions in binary form must reproduce the above copyright
>   *    notice, this list of conditions and the following disclaimer in
> the
>   *    documentation and/or other materials provided with the
> distribution.
> + *
> ***************************************************************************
> + * Timing Analysis Evasion changes were developed by C. Jason Coit and
> Roel
> + * Jonkman of Silicon Defense. 
> + *
> + * These changes cause SSH to send packets unless requested not to,
> exactly 
> + * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
> packet 
> + * with 16 bytes of data (which is the same size as most keystrokes). 
> Thus
> + * someone performing timing analysis cannot determine the inter
> keystroke 
> + * timing of a user.  SSH will send bogus data for about 1 sec after
> the last
> + * keystroke.  This both increases the difficulty of determing exact
> password
> + * lengths and conserves bandwith when a user is idle (e.g. taking a
> coffee break).
> + * Both the server and the client exhibit this behavior and yet our
> code places no 
> + * limit on the data rate (i.e if the server needs to respond with
> large amounts 
> + * of data it will be about to do so with large packets able to do so
> with large
> + * packets and without the 50 ms timing constraint).
> + *
> + * All changes were developed in response to timing analysis attack on
> ssh 
> + * published by Dawn Song et. al.  
> + *
> + * The evasion methods are only applicable to SSH2.  All single line
> changes
> + * and small comments are marked by SD Mod.  All multiline
> modifications are 
> + * delimited by Begin SD Mod and End SD Mod.  
> + *
> + * The last change was committed on 10/3/2001.
> +
> *******************************************************************************
>   *
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>   * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES
> @@ -563,6 +588,7 @@
>         initialize_server_options(&options);
>  
>         /* Parse command-line arguments. */
> +       /* SD Mod: add s option to getopt() call */
>         while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDeiqtQ46")) !=
> -1) {
>                 switch (opt) {
>                 case '4':
> @@ -645,6 +671,14 @@
>                 case 'u':
>                         utmp_len = atoi(optarg);
>                         break;
> +                       /*
> +                        * Begin SD Mod: Add option to handle option to
> turn off
> +                        * steno timing manipulation. 
> +                        */
> +               case 'S':
> +                       options.use_steno_timing_manipulation = 0;
> +                       break;
> +                       /* End SD Mod */
>                 case '?':
>                 default:
>                         fprintf(stderr, "sshd version %s\n",
> SSH_VERSION);
> @@ -665,6 +699,9 @@
>                         fprintf(stderr, "  -u len     Maximum hostname
> length for utmp recording\n");
>                         fprintf(stderr, "  -4         Use IPv4 only\n");
>                         fprintf(stderr, "  -6         Use IPv6 only\n");
> +                       /* SD Mod */
> +                       fprintf(stderr, "  -S         Don't use
> stenographic timing manipulation\n");
> +
>                         exit(1);
>                 }
>         }
> 
> 
> 
> 
> --
> regards,
> 
> Jason Coit
> 
> +--                                             --+
> |        C. Jason Coit Programmer/Analyst         |
> | *Silicon Defense - Technical Support for Snort* |
> |        http://www.silicondefense.com/           |
> +--                                              -+
--

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 chua at ayrnetworks.com  Wed Oct 17 08:54:08 2001
From: chua at ayrnetworks.com (Bryan Chua)
Date: Tue, 16 Oct 2001 15:54:08 -0700
Subject: program-prefix does not work
Message-ID: <3BCCBA90.5020801@ayrnetworks.com>

the configure option --program-prefix does not work although it is 
listed in teh configure --help output.

The attached patch fixes these issues:
1) program prefix is not substituted in configure
2) program prefix is not present in Makefile
3) scp requires use of a known "scp" program

-- bryan

diff -cr openssh-2.9.9p2.orig/Makefile.in openssh-2.9.9p2/Makefile.in
*** openssh-2.9.9p2.orig/Makefile.in	Mon Sep 17 22:06:22 2001
--- openssh-2.9.9p2/Makefile.in	Tue Oct 16 15:29:27 2001
***************
*** 12,29 ****
   piddir=@piddir@
   srcdir=@srcdir@
   top_srcdir=@top_srcdir@

   DESTDIR=
   VPATH=@srcdir@
! SSH_PROGRAM=@bindir@/ssh
! ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass
! SFTP_SERVER=$(libexecdir)/sftp-server

   PATHS= -DETCDIR=\"$(sysconfdir)\" \
   	-D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \
   	-D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \
   	-D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \
! 	-D_PATH_SSH_PIDDIR=\"$(piddir)\"

   CC=@CC@
   LD=@LD@
--- 12,31 ----
   piddir=@piddir@
   srcdir=@srcdir@
   top_srcdir=@top_srcdir@
+ program_prefix=@program_prefix@

   DESTDIR=
   VPATH=@srcdir@
! SSH_PROGRAM=@bindir@/$(program_prefix)ssh
! ASKPASS_PROGRAM=$(libexecdir)/$(program_prefix)ssh-askpass
! SFTP_SERVER=$(libexecdir)/$(program_prefix)sftp-server

   PATHS= -DETCDIR=\"$(sysconfdir)\" \
   	-D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \
   	-D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \
   	-D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \
! 	-D_PATH_SSH_PIDDIR=\"$(piddir)\" \
! 	-D_PROGRAM_PREFIX=\"$(program_prefix)\"

   CC=@CC@
   LD=@LD@
***************
*** 60,77 ****
   CONFIGFILES_IN=sshd_config ssh_config moduli

   PATHSUBS	= \
! 	-D/etc/ssh_config=$(sysconfdir)/ssh_config \
! 	-D/etc/ssh_known_hosts=$(sysconfdir)/ssh_known_hosts \
! 	-D/etc/sshd_config=$(sysconfdir)/sshd_config \
   	-D/usr/libexec=$(libexecdir) \
! 	-D/etc/shosts.equiv=$(sysconfdir)/shosts.equiv \
! 	-D/etc/ssh_host_key=$(sysconfdir)/ssh_host_key \
! 	-D/etc/ssh_host_dsa_key=$(sysconfdir)/ssh_host_dsa_key \
! 	-D/etc/ssh_host_rsa_key=$(sysconfdir)/ssh_host_rsa_key \
! 	-D/var/run/sshd.pid=$(piddir)/sshd.pid \
   	-D/etc/moduli=$(sysconfdir)/moduli \
! 	-D/etc/sshrc=$(sysconfdir)/sshrc \
   	-D/usr/X11R6/bin/xauth=$(XAUTH_PATH) \
   	-D/usr/bin:/bin:/usr/sbin:/sbin=@user_path@

   FIXPATHSCMD	= $(PERL) $(srcdir)/fixpaths $(PATHSUBS)
--- 62,86 ----
   CONFIGFILES_IN=sshd_config ssh_config moduli

   PATHSUBS	= \
! 	-D/etc/ssh_config=$(sysconfdir)/$(program_prefix)ssh_config \
! 	-D/etc/ssh_known_hosts=$(sysconfdir)/$(program_prefix)ssh_known_hosts \
! 	-D/etc/sshd_config=$(sysconfdir)/$(program_prefix)sshd_config \
   	-D/usr/libexec=$(libexecdir) \
! 	-D/etc/shosts.equiv=$(sysconfdir)/$(program_prefix)shosts.equiv \
! 	-D/etc/ssh_host_key=$(sysconfdir)/$(program_prefix)ssh_host_key \
! 	-D/etc/ssh_host_dsa_key=$(sysconfdir)/$(program_prefix)ssh_host_dsa_key \
! 	-D/etc/ssh_host_rsa_key=$(sysconfdir)/$(program_prefix)ssh_host_rsa_key \
! 	-D/var/run/sshd.pid=$(piddir)/$(program_prefix)sshd.pid \
   	-D/etc/moduli=$(sysconfdir)/moduli \
! 	-D/etc/sshrc=$(sysconfdir)/$(program_prefix)sshrc \
   	-D/usr/X11R6/bin/xauth=$(XAUTH_PATH) \
+ 	-D/sftp=/$(program_prefix)sftp \
+ 	-D" sftp= $(program_prefix)sftp"\
+ 	-D/ssh=/$(program_prefix)ssh \
+ 	-D/.ssh=/.$(program_prefix)ssh \
+ 	-D" ssh= $(program_prefix)ssh" \
+ 	-D/scp=/$(program_prefix)scp \
+ 	-D" scp= $(program_prefix)scp" \
   	-D/usr/bin:/bin:/usr/sbin:/sbin=@user_path@

   FIXPATHSCMD	= $(PERL) $(srcdir)/fixpaths $(PATHSUBS)
***************
*** 187,234 ****
   	$(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)1
   	$(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)8
   	$(srcdir)/mkinstalldirs $(DESTDIR)$(libexecdir)
! 	$(INSTALL) -m $(SSH_MODE) -s ssh $(DESTDIR)$(bindir)/ssh
! 	$(INSTALL) -m 0755 -s scp $(DESTDIR)$(bindir)/scp
! 	$(INSTALL) -m 0755 -s ssh-add $(DESTDIR)$(bindir)/ssh-add
! 	$(INSTALL) -m 0755 -s ssh-agent $(DESTDIR)$(bindir)/ssh-agent
! 	$(INSTALL) -m 0755 -s ssh-keygen $(DESTDIR)$(bindir)/ssh-keygen
! 	$(INSTALL) -m 0755 -s ssh-keyscan $(DESTDIR)$(bindir)/ssh-keyscan
! 	$(INSTALL) -m 0755 -s sshd $(DESTDIR)$(sbindir)/sshd
! 	@NO_SFTP@$(INSTALL) -m 0755 -s sftp $(DESTDIR)$(bindir)/sftp
   	@NO_SFTP@$(INSTALL) -m 0755 -s sftp-server $(DESTDIR)$(SFTP_SERVER)
! 	$(INSTALL) -m 644 ssh.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1
! 	$(INSTALL) -m 644 scp.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1
! 	$(INSTALL) -m 644 ssh-add.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1
! 	$(INSTALL) -m 644 ssh-agent.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/ssh-agent.1
! 	$(INSTALL) -m 644 ssh-keygen.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keygen.1
! 	$(INSTALL) -m 644 ssh-keyscan.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keyscan.1
! 	$(INSTALL) -m 644 sshd.8.out $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8
! 	@NO_SFTP@$(INSTALL) -m 644 sftp.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/sftp.1
! 	@NO_SFTP@$(INSTALL) -m 644 sftp-server.8.out 
$(DESTDIR)$(mandir)/$(mansubdir)8/sftp-server.8
! 	-rm -f $(DESTDIR)$(bindir)/slogin
! 	ln -s ssh$(EXEEXT) $(DESTDIR)$(bindir)/slogin
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1
! 	ln -s ssh.1 $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1
   	#@FILEPRIV@ -f dev,filesys,driver $(DESTDIR)$(bindir)/ssh 
$(DESTDIR)$(bindir)/slogin
   	if [ ! -d $(DESTDIR)$(sysconfdir) ]; then \
   		$(srcdir)/mkinstalldirs $(DESTDIR)$(sysconfdir); \
   	fi
! 	if [ ! -f $(DESTDIR)$(sysconfdir)/ssh_config ]; then \
! 		$(INSTALL) -m 644 ssh_config.out $(DESTDIR)$(sysconfdir)/ssh_config; \
   	else \
! 		echo "$(DESTDIR)$(sysconfdir)/ssh_config already exists, install will 
not overwrite"; \
   	fi
! 	if [ ! -f $(DESTDIR)$(sysconfdir)/sshd_config ]; then \
! 		$(INSTALL) -m 644 sshd_config.out $(DESTDIR)$(sysconfdir)/sshd_config; \
   	else \
! 		echo "$(DESTDIR)$(sysconfdir)/sshd_config already exists, install will 
not overwrite"; \
   	fi
   	if [ -f ssh_prng_cmds -a ! -z "$(INSTALL_SSH_PRNG_CMDS)" ]; then \
   		$(PERL) $(srcdir)/fixprogs ssh_prng_cmds $(ENT); \
! 		if [ ! -f $(DESTDIR)$(sysconfdir)/ssh_prng_cmds ] ; then \
! 	 
	$(INSTALL) -m 644 ssh_prng_cmds.out $(DESTDIR)$(sysconfdir)/ssh_prng_cmds; \
   		else \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/ssh_prng_cmds already exists, install will 
not overwrite"; \
   		fi ; \
   	fi
   	if [ ! -f $(DESTDIR)$(sysconfdir)/moduli ]; then \
--- 196,243 ----
   	$(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)1
   	$(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)8
   	$(srcdir)/mkinstalldirs $(DESTDIR)$(libexecdir)
! 	$(INSTALL) -m $(SSH_MODE) -s ssh $(DESTDIR)$(bindir)/$(program_prefix)ssh
! 	$(INSTALL) -m 0755 -s scp $(DESTDIR)$(bindir)/$(program_prefix)scp
! 	$(INSTALL) -m 0755 -s ssh-add $(DESTDIR)$(bindir)/$(program_prefix)ssh-add
! 	$(INSTALL) -m 0755 -s ssh-agent 
$(DESTDIR)$(bindir)/$(program_prefix)ssh-agent
! 	$(INSTALL) -m 0755 -s ssh-keygen 
$(DESTDIR)$(bindir)/$(program_prefix)ssh-keygen
! 	$(INSTALL) -m 0755 -s ssh-keyscan 
$(DESTDIR)$(bindir)/$(program_prefix)ssh-keyscan
! 	$(INSTALL) -m 0755 -s sshd $(DESTDIR)$(sbindir)/$(program_prefix)sshd
! 	@NO_SFTP@$(INSTALL) -m 0755 -s sftp 
$(DESTDIR)$(bindir)/$(program_prefix)sftp
   	@NO_SFTP@$(INSTALL) -m 0755 -s sftp-server $(DESTDIR)$(SFTP_SERVER)
! 	$(INSTALL) -m 644 ssh.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh.1
! 	$(INSTALL) -m 644 scp.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)scp.1
! 	$(INSTALL) -m 644 ssh-add.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-add.1
! 	$(INSTALL) -m 644 ssh-agent.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-agent.1
! 	$(INSTALL) -m 644 ssh-keygen.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-keygen.1
! 	$(INSTALL) -m 644 ssh-keyscan.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-keyscan.1
! 	$(INSTALL) -m 644 sshd.8.out 
$(DESTDIR)$(mandir)/$(mansubdir)8/$(program_prefix)sshd.8
! 	@NO_SFTP@$(INSTALL) -m 644 sftp.1.out 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)sftp.1
! 	@NO_SFTP@$(INSTALL) -m 644 sftp-server.8.out 
$(DESTDIR)$(mandir)/$(mansubdir)8/$(program_prefix)sftp-server.8
! 	-rm -f $(DESTDIR)$(bindir)/slogin 
$(DESTDIR)$(bindir)/$(program_prefix)slogin
! 	ln -s $(program_prefix)ssh$(EXEEXT) 
$(DESTDIR)$(bindir)/$(program_prefix)slogin
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)slogin.1 
$(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)slogin.1
! 	ln -s ssh.1 $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)slogin.1
   	#@FILEPRIV@ -f dev,filesys,driver $(DESTDIR)$(bindir)/ssh 
$(DESTDIR)$(bindir)/slogin
   	if [ ! -d $(DESTDIR)$(sysconfdir) ]; then \
   		$(srcdir)/mkinstalldirs $(DESTDIR)$(sysconfdir); \
   	fi
! 	if [ ! -f $(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_config ]; then \
! 		$(INSTALL) -m 644 ssh_config.out 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_config; \
   	else \
! 		echo "$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_config already 
exists, install will not overwrite"; \
   	fi
! 	if [ ! -f $(DESTDIR)$(sysconfdir)/$(program_prefix)sshd_config ]; then \
! 		$(INSTALL) -m 644 sshd_config.out 
$(DESTDIR)$(sysconfdir)/$(program_prefix)sshd_config; \
   	else \
! 		echo "$(DESTDIR)$(sysconfdir)/$(program_prefix)sshd_config already 
exists, install will not overwrite"; \
   	fi
   	if [ -f ssh_prng_cmds -a ! -z "$(INSTALL_SSH_PRNG_CMDS)" ]; then \
   		$(PERL) $(srcdir)/fixprogs ssh_prng_cmds $(ENT); \
! 		if [ ! -f $(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_prng_cmds ] ; then \
! 	 
	$(INSTALL) -m 644 ssh_prng_cmds.out 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_prng_cmds; \
   		else \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_prng_cmds already 
exists, install will not overwrite"; \
   		fi ; \
   	fi
   	if [ ! -f $(DESTDIR)$(sysconfdir)/moduli ]; then \
***************
*** 244,275 ****

   host-key: ssh-keygen$(EXEEXT)
   	if [ -z "$(DESTDIR)" ] ; then \
! 		if [ -f "$(DESTDIR)$(sysconfdir)/ssh_host_key" ] ; then \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/ssh_host_key already exists, skipping." ; \
   		else \
! 	 
	./ssh-keygen -t rsa1 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" ; \
   		fi ; \
! 		if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key ] ; then \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/ssh_host_dsa_key already exists, skipping." ; \
   		else \
! 	 
	./ssh-keygen -t dsa -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" ; \
   		fi ; \
! 		if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key ] ; then \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/ssh_host_rsa_key already exists, skipping." ; \
   		else \
! 	 
	./ssh-keygen -t rsa -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key -N "" ; \
   		fi ; \
   	fi ;

   host-key-force: ssh-keygen$(EXEEXT)
! 	./ssh-keygen -t rsa1 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N ""
! 	./ssh-keygen -t dsa -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N ""
! 	./ssh-keygen -t rsa -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key -N ""

   uninstallall:	uninstall
! 	-rm -f $(DESTDIR)$(sysconfdir)/ssh_config
! 	-rm -f $(DESTDIR)$(sysconfdir)/sshd_config
! 	-rm -f $(DESTDIR)$(sysconfdir)/ssh_prng_cmds
   	-rmdir $(DESTDIR)$(sysconfdir)
   	-rmdir $(DESTDIR)$(bindir)
   	-rmdir $(DESTDIR)$(sbindir)
--- 253,284 ----

   host-key: ssh-keygen$(EXEEXT)
   	if [ -z "$(DESTDIR)" ] ; then \
! 		if [ -f "$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_key" ] ; then \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_key already 
exists, skipping." ; \
   		else \
! 	 
	./ssh-keygen -t rsa1 -f 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_key -N "" ; \
   		fi ; \
! 		if [ -f $(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_dsa_key ] ; then \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_dsa_key already 
exists, skipping." ; \
   		else \
! 	 
	./ssh-keygen -t dsa -f 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_dsa_key -N "" ; \
   		fi ; \
! 		if [ -f $(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_rsa_key ] ; then \
! 	 
	echo "$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_rsa_key already 
exists, skipping." ; \
   		else \
! 	 
	./ssh-keygen -t rsa -f 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_rsa_key -N "" ; \
   		fi ; \
   	fi ;

   host-key-force: ssh-keygen$(EXEEXT)
! 	./ssh-keygen -t rsa1 -f 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_key -N ""
! 	./ssh-keygen -t dsa -f 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_dsa_key -N ""
! 	./ssh-keygen -t rsa -f 
$(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_host_rsa_key -N ""

   uninstallall:	uninstall
! 	-rm -f $(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_config
! 	-rm -f $(DESTDIR)$(sysconfdir)/$(program_prefix)sshd_config
! 	-rm -f $(DESTDIR)$(sysconfdir)/$(program_prefix)ssh_prng_cmds
   	-rmdir $(DESTDIR)$(sysconfdir)
   	-rmdir $(DESTDIR)$(bindir)
   	-rmdir $(DESTDIR)$(sbindir)
***************
*** 279,301 ****
   	-rmdir $(DESTDIR)$(libexecdir)

   uninstall:
! 	-rm -f $(DESTDIR)$(bindir)/slogin
! 	-rm -f $(DESTDIR)$(bindir)/ssh$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/scp$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/ssh-add$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/ssh-agent$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/ssh-keygen$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/sftp$(EXEEXT)
! 	-rm -f $(DESTDIR)$(sbindir)/sshd$(EXEEXT)
   	-rm -r $(DESTDIR)$(SFTP_SERVER)$(EXEEXT)
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-agent.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keygen.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/sftp.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keyscan.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/sftp-server.8
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1
--- 288,310 ----
   	-rmdir $(DESTDIR)$(libexecdir)

   uninstall:
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)slogin
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)ssh$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)scp$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)ssh-add$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)ssh-agent$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)ssh-keygen$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)ssh-keyscan$(EXEEXT)
! 	-rm -f $(DESTDIR)$(bindir)/$(program_prefix)sftp$(EXEEXT)
! 	-rm -f $(DESTDIR)$(sbindir)/$(program_prefix)sshd$(EXEEXT)
   	-rm -r $(DESTDIR)$(SFTP_SERVER)$(EXEEXT)
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)scp.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-add.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-agent.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-keygen.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)sftp.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)ssh-keyscan.1
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/$(program_prefix)sshd.8
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/$(program_prefix)sftp-server.8
! 	-rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/$(program_prefix)slogin.1
diff -cr openssh-2.9.9p2.orig/configure openssh-2.9.9p2/configure
*** openssh-2.9.9p2.orig/configure	Tue Sep 25 15:50:31 2001
--- openssh-2.9.9p2/configure	Tue Oct 16 15:44:21 2001
***************
*** 218,224 ****
     --cache-file=FILE       cache test results in FILE
     --help                  print this message
     --no-create             do not create output files
!   --quiet, --silent       do not print \`checking...' messages
     --version               print the version of autoconf that created 
configure
   Directory and file names:
     --prefix=PREFIX         install architecture-independent files in 
PREFIX
--- 218,224 ----
     --cache-file=FILE       cache test results in FILE
     --help                  print this message
     --no-create             do not create output files
!   --quiet, --silent       do not print \`checking...\' messages
     --version               print the version of autoconf that created 
configure
   Directory and file names:
     --prefix=PREFIX         install architecture-independent files in 
PREFIX
***************
*** 9339,9344 ****
--- 9339,9345 ----
   s%@LIBS@%$LIBS%g
   s%@exec_prefix@%$exec_prefix%g
   s%@prefix@%$prefix%g
+ s%@program_prefix@%$program_prefix%g
   s%@program_transform_name@%$program_transform_name%g
   s%@bindir@%$bindir%g
   s%@sbindir@%$sbindir%g
diff -cr openssh-2.9.9p2.orig/pathnames.h openssh-2.9.9p2/pathnames.h
*** openssh-2.9.9p2.orig/pathnames.h	Wed Jun 27 17:13:48 2001
--- openssh-2.9.9p2/pathnames.h	Tue Oct 16 13:30:09 2001
***************
*** 20,42 ****
   #define _PATH_SSH_PIDDIR		"/var/run"
   #endif

   /*
    * System-wide file containing host keys of known hosts.  This file 
should be
    * world-readable.
    */
! #define _PATH_SSH_SYSTEM_HOSTFILE	ETCDIR "/ssh_known_hosts"
   /* backward compat for protocol 2 */
! #define _PATH_SSH_SYSTEM_HOSTFILE2	ETCDIR "/ssh_known_hosts2"

   /*
    * Of these, ssh_host_key must be readable only by root, whereas 
ssh_config
    * should be world-readable.
    */
! #define _PATH_SERVER_CONFIG_FILE	ETCDIR "/sshd_config"
! #define _PATH_HOST_CONFIG_FILE		ETCDIR "/ssh_config"
! #define _PATH_HOST_KEY_FILE		ETCDIR "/ssh_host_key"
! #define _PATH_HOST_DSA_KEY_FILE		ETCDIR "/ssh_host_dsa_key"
! #define _PATH_HOST_RSA_KEY_FILE		ETCDIR "/ssh_host_rsa_key"
   #define _PATH_DH_MODULI			ETCDIR "/moduli"
   /* Backwards compatibility */
   #define _PATH_DH_PRIMES			ETCDIR "/primes"
--- 20,45 ----
   #define _PATH_SSH_PIDDIR		"/var/run"
   #endif

+ #ifndef _PROGRAM_PREFIX
+ #define _PROGRAM_PREFIX			""
+ #endif
   /*
    * System-wide file containing host keys of known hosts.  This file 
should be
    * world-readable.
    */
! #define _PATH_SSH_SYSTEM_HOSTFILE	ETCDIR "/" _PROGRAM_PREFIX "ssh_known_hosts"
   /* backward compat for protocol 2 */
! #define _PATH_SSH_SYSTEM_HOSTFILE2	ETCDIR "/" _PROGRAM_PREFIX "ssh_known_hosts2"

   /*
    * Of these, ssh_host_key must be readable only by root, whereas 
ssh_config
    * should be world-readable.
    */
! #define _PATH_SERVER_CONFIG_FILE	ETCDIR "/" _PROGRAM_PREFIX "sshd_config"
! #define _PATH_HOST_CONFIG_FILE		ETCDIR "/" _PROGRAM_PREFIX "ssh_config"
! #define _PATH_HOST_KEY_FILE		ETCDIR "/" _PROGRAM_PREFIX "ssh_host_key"
! #define _PATH_HOST_DSA_KEY_FILE		ETCDIR "/" _PROGRAM_PREFIX "ssh_host_dsa_key"
! #define _PATH_HOST_RSA_KEY_FILE		ETCDIR "/" _PROGRAM_PREFIX "ssh_host_rsa_key"
   #define _PATH_DH_MODULI			ETCDIR "/moduli"
   /* Backwards compatibility */
   #define _PATH_DH_PRIMES			ETCDIR "/primes"
***************
*** 45,78 ****
   #define _PATH_SSH_PROGRAM		"/usr/bin/ssh"
   #endif

   /*
    * The process id of the daemon listening for connections is saved 
here to
    * make it easier to kill the correct daemon when necessary.
    */
! #define _PATH_SSH_DAEMON_PID_FILE	_PATH_SSH_PIDDIR "/sshd.pid"

   /*
    * The directory in user\'s home directory in which the files reside. The
    * directory should be world-readable (though not all files are).
    */
! #define _PATH_SSH_USER_DIR		".ssh"

   /*
    * Per-user file containing host keys of known hosts.  This file need 
not be
    * readable by anyone except the user him/herself, though this does not
    * contain anything particularly secret.
    */
! #define _PATH_SSH_USER_HOSTFILE		"~/.ssh/known_hosts"
   /* backward compat for protocol 2 */
! #define _PATH_SSH_USER_HOSTFILE2	"~/.ssh/known_hosts2"

   /*
    * Name of the default file containing client-side authentication 
key. This
    * file should only be readable by the user him/herself.
    */
! #define _PATH_SSH_CLIENT_IDENTITY	".ssh/identity"
! #define _PATH_SSH_CLIENT_ID_DSA		".ssh/id_dsa"
! #define _PATH_SSH_CLIENT_ID_RSA		".ssh/id_rsa"

   /*
    * Configuration file in user\'s home directory.  This file need not be
--- 48,85 ----
   #define _PATH_SSH_PROGRAM		"/usr/bin/ssh"
   #endif

+ #ifndef _PATH_SCP_PROGRAM
+ #define _PATH_SCP_PROGRAM		_PROGRAM_PREFIX "scp"
+ #endif
+
   /*
    * The process id of the daemon listening for connections is saved 
here to
    * make it easier to kill the correct daemon when necessary.
    */
! #define _PATH_SSH_DAEMON_PID_FILE	_PATH_SSH_PIDDIR "/" _PROGRAM_PREFIX "sshd.pid"

   /*
    * The directory in user\'s home directory in which the files reside. The
    * directory should be world-readable (though not all files are).
    */
! #define _PATH_SSH_USER_DIR		"." _PROGRAM_PREFIX "ssh"

   /*
    * Per-user file containing host keys of known hosts.  This file need 
not be
    * readable by anyone except the user him/herself, though this does not
    * contain anything particularly secret.
    */
! #define _PATH_SSH_USER_HOSTFILE		"~/" _PATH_SSH_USER_DIR "/known_hosts"
   /* backward compat for protocol 2 */
! #define _PATH_SSH_USER_HOSTFILE2	"~/" _PATH_SSH_USER_DIR "/known_hosts2"

   /*
    * Name of the default file containing client-side authentication 
key. This
    * file should only be readable by the user him/herself.
    */
! #define _PATH_SSH_CLIENT_IDENTITY	_PATH_SSH_USER_DIR "/identity"
! #define _PATH_SSH_CLIENT_ID_DSA		_PATH_SSH_USER_DIR "/id_dsa"
! #define _PATH_SSH_CLIENT_ID_RSA		_PATH_SSH_USER_DIR "/id_rsa"

   /*
    * Configuration file in user\'s home directory.  This file need not be
***************
*** 80,86 ****
    * particularly secret.  If the user\'s home directory resides on an NFS
    * volume where root is mapped to nobody, this may need to be 
world-readable.
    */
! #define _PATH_SSH_USER_CONFFILE		".ssh/config"

   /*
    * File containing a list of those rsa keys that permit logging in as 
this
--- 87,93 ----
    * particularly secret.  If the user\'s home directory resides on an NFS
    * volume where root is mapped to nobody, this may need to be 
world-readable.
    */
! #define _PATH_SSH_USER_CONFFILE		_PATH_SSH_USER_DIR "/config"

   /*
    * File containing a list of those rsa keys that permit logging in as 
this
***************
*** 90,99 ****
    * may need to be world-readable.  (This file is read by the daemon 
which is
    * running as root.)
    */
! #define _PATH_SSH_USER_PERMITTED_KEYS	".ssh/authorized_keys"

   /* backward compat for protocol v2 */
! #define _PATH_SSH_USER_PERMITTED_KEYS2	".ssh/authorized_keys2"

   /*
    * Per-user and system-wide ssh "rc" files.  These files are executed 
with
--- 97,106 ----
    * may need to be world-readable.  (This file is read by the daemon 
which is
    * running as root.)
    */
! #define _PATH_SSH_USER_PERMITTED_KEYS	_PATH_SSH_USER_DIR "/authorized_keys"

   /* backward compat for protocol v2 */
! #define _PATH_SSH_USER_PERMITTED_KEYS2	_PATH_SSH_USER_DIR "/authorized_keys2"

   /*
    * Per-user and system-wide ssh "rc" files.  These files are executed 
with
***************
*** 101,108 ****
    * passed "proto cookie" as arguments if X11 forwarding with spoofing 
is in
    * use.  xauth will be run if neither of these exists.
    */
! #define _PATH_SSH_USER_RC		".ssh/rc"
! #define _PATH_SSH_SYSTEM_RC		ETCDIR "/sshrc"

   /*
    * Ssh-only version of /etc/hosts.equiv.  Additionally, the daemon 
may use
--- 108,115 ----
    * passed "proto cookie" as arguments if X11 forwarding with spoofing 
is in
    * use.  xauth will be run if neither of these exists.
    */
! #define _PATH_SSH_USER_RC		_PATH_SSH_USER_DIR "/rc"
! #define _PATH_SSH_SYSTEM_RC		ETCDIR "/" _PROGRAM_PREFIX "sshrc"

   /*
    * Ssh-only version of /etc/hosts.equiv.  Additionally, the daemon 
may use
***************
*** 115,121 ****
    * Default location of askpass
    */
   #ifndef _PATH_SSH_ASKPASS_DEFAULT
! #define _PATH_SSH_ASKPASS_DEFAULT	"/usr/X11R6/bin/ssh-askpass"
   #endif

   /* xauth for X11 forwarding */
--- 122,128 ----
    * Default location of askpass
    */
   #ifndef _PATH_SSH_ASKPASS_DEFAULT
! #define _PATH_SSH_ASKPASS_DEFAULT	"/usr/X11R6/bin/" _PROGRAM_PREFIX "ssh-askpass"
   #endif

   /* xauth for X11 forwarding */
***************
*** 130,136 ****

   /* for sftp */
   #ifndef _PATH_SFTP_SERVER
! #define _PATH_SFTP_SERVER		"/usr/libexec/sftp-server"
   #endif
   #ifndef _PATH_LS
   #define _PATH_LS			"ls"
--- 137,143 ----

   /* for sftp */
   #ifndef _PATH_SFTP_SERVER
! #define _PATH_SFTP_SERVER		"/usr/libexec/" _PROGRAM_PREFIX "sftp-server"
   #endif
   #ifndef _PATH_LS
   #define _PATH_LS			"ls"
***************
*** 147,161 ****

   /* Askpass program define */
   #ifndef ASKPASS_PROGRAM
! #define ASKPASS_PROGRAM         "/usr/lib/ssh/ssh-askpass"
   #endif /* ASKPASS_PROGRAM */

   /*
    * Relevant only when using builtin PRNG.
    */
   #ifndef SSH_PRNG_SEED_FILE
! # define SSH_PRNG_SEED_FILE      _PATH_SSH_USER_DIR"/prng_seed"
   #endif /* SSH_PRNG_SEED_FILE */
   #ifndef SSH_PRNG_COMMAND_FILE
! # define SSH_PRNG_COMMAND_FILE   ETCDIR "/ssh_prng_cmds"
   #endif /* SSH_PRNG_COMMAND_FILE */
--- 154,168 ----

   /* Askpass program define */
   #ifndef ASKPASS_PROGRAM
! #define ASKPASS_PROGRAM         "/usr/lib/ssh" "/" _PROGRAM_PREFIX 
"ssh-askpass"
   #endif /* ASKPASS_PROGRAM */

   /*
    * Relevant only when using builtin PRNG.
    */
   #ifndef SSH_PRNG_SEED_FILE
! # define SSH_PRNG_SEED_FILE      _PATH_SSH_USER_DIR "/" 
_PROGRAM_PREFIX "prng_seed"
   #endif /* SSH_PRNG_SEED_FILE */
   #ifndef SSH_PRNG_COMMAND_FILE
! # define SSH_PRNG_COMMAND_FILE   ETCDIR "/" _PROGRAM_PREFIX 
"ssh_prng_cmds"
   #endif /* SSH_PRNG_COMMAND_FILE */
Only in openssh-2.9.9p2.orig/scard: Ssh.bin
diff -cr openssh-2.9.9p2.orig/scp.c openssh-2.9.9p2/scp.c
*** openssh-2.9.9p2.orig/scp.c	Wed Sep 19 17:57:56 2001
--- openssh-2.9.9p2/scp.c	Tue Oct 16 14:14:46 2001
***************
*** 132,137 ****
--- 132,138 ----

   /* This is the program to execute for the secured connection. ("ssh" 
or -S) */
   char *ssh_program = _PATH_SSH_PROGRAM;
+ char *scp_program = _PATH_SCP_PROGRAM;

   /*
    * This function executes the given command as the specified user on the
***************
*** 242,248 ****
   	addargs(&args, "-oClearAllForwardings yes");

   	fflag = tflag = 0;
! 	while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:F:")) != -1)
   		switch (ch) {
   		/* User-visible flags. */
   		case '4':
--- 243,249 ----
   	addargs(&args, "-oClearAllForwardings yes");

   	fflag = tflag = 0;
! 	while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46Ss:o:F:")) != -1)
   		switch (ch) {
   		/* User-visible flags. */
   		case '4':
***************
*** 271,276 ****
--- 272,280 ----
   		case 'S':
   			ssh_program = xstrdup(optarg);
   			break;
+ 		case 's':
+ 	 
	scp_program = xstrdup(optarg);
+ 	 
	break;
   		case 'v':
   			addargs(&args, "-v");
   			verbose_mode = 1;
***************
*** 327,343 ****

   	remin = remout = -1;
   	/* Command to be executed on remote system using "ssh". */
! 	(void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s",
   	    verbose_mode ? " -v" : "",
   	    iamrecursive ? " -r" : "", pflag ? " -p" : "",
! 	    targetshouldbedirectory ? " -d" : "");

   	(void) signal(SIGPIPE, lostconn);

   	if ((targ = colon(argv[argc - 1])))	/* Dest is remote host. */
! 		toremote(targ, argc, argv);
   	else {
! 		tolocal(argc, argv);	/* Dest is local host. */
   		if (targetshouldbedirectory)
   			verifydir(argv[argc - 1]);
   	}
--- 331,349 ----

   	remin = remout = -1;
   	/* Command to be executed on remote system using "ssh". */
! 	if (snprintf(cmd, sizeof cmd, "%s%s%s%s%s",
! 		scp_program,
   	    verbose_mode ? " -v" : "",
   	    iamrecursive ? " -r" : "", pflag ? " -p" : "",
! 	    targetshouldbedirectory ? " -d" : "") < 0)
! 	    fprintf (stderr, "command truncated: %s\n", cmd);

   	(void) signal(SIGPIPE, lostconn);

   	if ((targ = colon(argv[argc - 1])))	/* Dest is remote host. */
! 	    toremote(targ, argc, argv);
   	else {
! 	    tolocal(argc, argv);	/* Dest is local host. */
   		if (targetshouldbedirectory)
   			verifydir(argv[argc - 1]);
   	}
***************
*** 392,413 ****
   		 
		suser = pwd->pw_name;
   		 
	else if (!okname(suser))
   		 
		continue;
! 	 
		snprintf(bp, len,
   		 
	    "%s%s %s -n "
   		 
	    "-l %s %s %s %s '%s%s%s:%s'",
   		 
	    ssh_program, verbose_mode ? " -v" : "",
   		 
	    ssh_options, suser, host, cmd, src,
   		 
	    tuser ? tuser : "", tuser ? "@" : "",
! 	 
		    thost, targ);
   			} else {
   		 
	host = cleanhostname(argv[i]);
! 	 
		snprintf(bp, len,
   		 
	    "exec %s%s %s -n %s "
   		 
	    "%s %s '%s%s%s:%s'",
   		 
	    ssh_program, verbose_mode ? " -v" : "",
   		 
	    ssh_options, host, cmd, src,
   		 
	    tuser ? tuser : "", tuser ? "@" : "",
! 	 
		    thost, targ);
   			}
   			if (verbose_mode)
   		 
	fprintf(stderr, "Executing: %s\n", bp);
--- 398,421 ----
   		 
		suser = pwd->pw_name;
   		 
	else if (!okname(suser))
   		 
		continue;
! 	 
		if (snprintf(bp, len,
   		 
	    "%s%s %s -n "
   		 
	    "-l %s %s %s %s '%s%s%s:%s'",
   		 
	    ssh_program, verbose_mode ? " -v" : "",
   		 
	    ssh_options, suser, host, cmd, src,
   		 
	    tuser ? tuser : "", tuser ? "@" : "",
! 	 
			thost, targ) < 0)
! 	 
		    fprintf(stderr, "command truncated: %s\n", bp);
   			} else {
   		 
	host = cleanhostname(argv[i]);
! 	 
		if (snprintf(bp, len,
   		 
	    "exec %s%s %s -n %s "
   		 
	    "%s %s '%s%s%s:%s'",
   		 
	    ssh_program, verbose_mode ? " -v" : "",
   		 
	    ssh_options, host, cmd, src,
   		 
	    tuser ? tuser : "", tuser ? "@" : "",
! 	 
			thost, targ) < 0)
! 	 
		    fprintf(stderr, "command truncated: %s\n", bp);
   			}
   			if (verbose_mode)
   		 
	fprintf(stderr, "Executing: %s\n", bp);
***************
*** 417,423 ****
   			if (remin == -1) {
   		 
	len = strlen(targ) + CMDNEEDS + 20;
   		 
	bp = xmalloc(len);
! 	 
		(void) snprintf(bp, len, "%s -t %s", cmd, targ);
   		 
	host = cleanhostname(thost);
   		 
	if (do_cmd(host, tuser, bp, &remin,
   		 
	    &remout, argc) < 0)
--- 425,432 ----
   			if (remin == -1) {
   		 
	len = strlen(targ) + CMDNEEDS + 20;
   		 
	bp = xmalloc(len);
! 	 
		if (snprintf(bp, len, "%s -t %s", cmd, targ) < 0)
! 	 
		    fprintf(stderr, "command truncated: %s\n", bp);
   		 
	host = cleanhostname(thost);
   		 
	if (do_cmd(host, tuser, bp, &remin,
   		 
	    &remout, argc) < 0)
***************
*** 444,452 ****
   			len = strlen(_PATH_CP) + strlen(argv[i]) +
   			    strlen(argv[argc - 1]) + 20;
   			bp = xmalloc(len);
! 	 
	(void) snprintf(bp, len, "exec %s%s%s %s %s", _PATH_CP,
   			    iamrecursive ? " -r" : "", pflag ? " -p" : "",
! 	 
	    argv[i], argv[argc - 1]);
   			if (verbose_mode)
   		 
	fprintf(stderr, "Executing: %s\n", bp);
   			if (system(bp))
--- 453,462 ----
   			len = strlen(_PATH_CP) + strlen(argv[i]) +
   			    strlen(argv[argc - 1]) + 20;
   			bp = xmalloc(len);
! 	 
	if (snprintf(bp, len, "exec %s%s%s %s %s", _PATH_CP,
   			    iamrecursive ? " -r" : "", pflag ? " -p" : "",
! 	 
		argv[i], argv[argc - 1]) < 0)
! 	 
	    fprintf (stderr, "command truncated: %s\n", bp);
   			if (verbose_mode)
   		 
	fprintf(stderr, "Executing: %s\n", bp);
   			if (system(bp))
***************
*** 471,477 ****
   		host = cleanhostname(host);
   		len = strlen(src) + CMDNEEDS + 20;
   		bp = xmalloc(len);
! 		(void) snprintf(bp, len, "%s -f %s", cmd, src);
   		if (do_cmd(host, suser, bp, &remin, &remout, argc) < 0) {
   			(void) xfree(bp);
   			++errs;
--- 481,490 ----
   		host = cleanhostname(host);
   		len = strlen(src) + CMDNEEDS + 20;
   		bp = xmalloc(len);
! 		if (snprintf(bp, len, "%s -f %s", cmd, src) < 0)
! 		    fprintf (stderr, "command truncated: %s\n", cmd);
! 		if (verbose_mode)
! 		    fprintf (stderr, "Executing: %s\n", bp);
   		if (do_cmd(host, suser, bp, &remin, &remout, argc) < 0) {
   			(void) xfree(bp);
   			++errs;



From jasonc at silicondefense.com  Wed Oct 17 09:36:15 2001
From: jasonc at silicondefense.com (C. Jason Coit)
Date: Tue, 16 Oct 2001 16:36:15 -0700
Subject: [Fwd: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and 2.9p2]
Message-ID: <3BCCC46F.E21067C2@silicondefense.com>

Nicolas,

The timing attack described in the paper by Dawn Song et al. works by
examining the timing of keystrokes.  Currently OpenSSH sends a packet
every time you press a key, thus it is possible to capture the
approximate inter-keystroke timing of a user (they found minimal
overhead
in time from a key press to packet sent).  Our patch causes a packet to
be sent every 50 ms regardless of whether you type a key or not (sends
an ignore message aka nop).  Thus an attacker cannot be exactly sure of
your inter-keystroke timing.  

It doesn't matter if you are an average user or a fast touch-typing
secretary, your inter-keystroke timing is obscured.  In addition to this
our patch conserves bandwidth by shutting off after about a second after
the last key press.  If you don't stop typing for more than a second, it
appears as if you are constantly send packets to the server every 50
ms.    
Adding random noise would be less effective than what we are doing. 
Random noise would dilute the signal of inter-keystroke timing, we are
eliminating the signal altogether.  By pacing the inter-packet timing we
completely remove the inter-keystroke timing information.

regards,

-Jason Coit

-------- Original Message --------
Subject: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and
2.9p2
Date: Tue, 16 Oct 2001 17:36:18 -0400
From: Nicolas Williams <Nicolas.Williams at ubsw.com>
To: "C. Jason Coit" <jasonc at silicondefense.com>
CC: openssh-unix-dev at mindrot.org
References: <3BCC889C.AA5C57F0 at silicondefense.com>

Let's see. The timing attack has to do with predictable timing. The
solution would seem to be to add randomness to the packet timing. Your
patch does not do this -- it adds more predictable traffic.

I would think that to defeat the timing attack SSH would have to send
random-sized no-op packets at random intervals, or perhaps just adding
random delays before sending packets. And, of course, we're not talking
IP packets here, but SSH "packets."

But I could be wrong, I'm not an expert on this subject.

Nico


From openssh-unix-dev at thewrittenword.com  Wed Oct 17 09:48:35 2001
From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com)
Date: Tue, 16 Oct 2001 18:48:35 -0500
Subject: Solaris 2.5.1 dirname() bug in libgen.a affects OpenSSH2.9.9p2 auth.c
In-Reply-To: <01Oct16.153647edt.453142-8581@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Oct 16, 2001 at 03:36:42PM -0400
References: <01Oct16.153647edt.453142-8581@jane.cs.toronto.edu>
Message-ID: <20011016184835.A58732@oolong.il.thewrittenword.com>

On Tue, Oct 16, 2001 at 03:36:42PM -0400, Dan Astoorian wrote:
> I've discovered a problem with OpenSSH 2.9.9p2 under Solaris 2.5.1 .
> 
> In auth.c, secure_filename() walks upwards toward the user's home
> directory or the filesystem root, verifying that no directories along
> the way are group or world writable.
> 
> Solaris 2.5.1's dirname() function has a bug where dirname("/.ssh")
> returns an empty string instead of "/".

I was able to duplicate this on our 2.5.1 machine. It is reported as
bug id #4055505 at sunsolve.sun.com. There is a libgen patch available
as 106274-01 but it's a fix to some regex issue so I guess there is no
solution from Sun for this problem.

> Dan Astoorian               People shouldn't think that it's better to have

-- 
albert chin (china at thewrittenword.com)


From tim at multitalents.net  Wed Oct 17 11:37:00 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 16 Oct 2001 18:37:00 -0700 (PDT)
Subject: program-prefix does not work
In-Reply-To: <3BCCBA90.5020801@ayrnetworks.com>
Message-ID: <Pine.UW2.4.40.9.0110161834320.163-100000@uw711.int.multitalents.net>


Please resubmit with diff -u

On Tue, 16 Oct 2001, Bryan Chua wrote:

> the configure option --program-prefix does not work although it is
> listed in teh configure --help output.
>
> The attached patch fixes these issues:
> 1) program prefix is not substituted in configure
> 2) program prefix is not present in Makefile
> 3) scp requires use of a known "scp" program
>
> -- bryan
>
> diff -cr openssh-2.9.9p2.orig/Makefile.in openssh-2.9.9p2/Makefile.in
[patch snipped]

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From tim at multitalents.net  Wed Oct 17 12:44:50 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 16 Oct 2001 19:44:50 -0700 (PDT)
Subject: Solaris 2.5.1 dirname() bug in libgen.a affects OpenSSH2.9.9p2
 auth.c
In-Reply-To: <01Oct16.153647edt.453142-8581@jane.cs.toronto.edu>
Message-ID: <Pine.UW2.4.40.9.0110161931540.335-100000@uw711.int.multitalents.net>

On Tue, 16 Oct 2001, Dan Astoorian wrote:

> I've discovered a problem with OpenSSH 2.9.9p2 under Solaris 2.5.1 .
>
> In auth.c, secure_filename() walks upwards toward the user's home
> directory or the filesystem root, verifying that no directories along
> the way are group or world writable.
>
> Solaris 2.5.1's dirname() function has a bug where dirname("/.ssh")
> returns an empty string instead of "/".
>
> This causes secure_filename() to try to stat(""), fail, and report
> "bad ownership or modes for directory ".
>

How about writing a small C we can use to test for this bug
at configure time.  dirname() is allready in openbsd-compat so
we can use that if it's broken.

--------< from autoconf docs >--------

Guidelines for Test Programs
Test programs should not write anything to the standard output.
They should return 0 if the test succeeds, nonzero otherwise, so
that success can be distinguished easily from a core dump or other
failure; segmentation violations and other failures produce a
nonzero exit status. Test programs should exit, not return, from main,
because on some systems (old Suns, at least) the argument to return
in main is ignored.

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

> I discovered this when upgrading from 2.3.0p1 to 2.9.9p2: root was
> unable to use RSA authentication because of it.
[snip]

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From djast at cs.toronto.edu  Wed Oct 17 15:00:55 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Wed, 17 Oct 2001 01:00:55 -0400
Subject: Solaris 2.5.1 dirname() bug in libgen.a affects OpenSSH2.9.9p2 auth.c 
In-Reply-To: Your message of "Tue, 16 Oct 2001 22:44:50 EDT."
             <Pine.UW2.4.40.9.0110161931540.335-100000@uw711.int.multitalents.net> 
Message-ID: <01Oct17.010100edt.453142-8581@jane.cs.toronto.edu>

Albert Chin writes:
> I was able to duplicate this on our 2.5.1 machine. It is reported as
> bug id #4055505 at sunsolve.sun.com. There is a libgen patch available
> as 106274-01 but it's a fix to some regex issue so I guess there is no
> solution from Sun for this problem.

For what it's worth, I did try linking against the library contained in
that patch, and it does not correct the dirname() problem.  (I therefore
didn't consider the patch worth mentioning.)

Tim Rice writes:
> 
> How about writing a small C we can use to test for this bug
> at configure time.  dirname() is allready in openbsd-compat so
> we can use that if it's broken.

Attached.  Returns 1 if dirname("/etc") returns "" instead of "/", 0
otherwise.

Note that on Solaris 2.5.1, the test program must be compiled with
-lgen.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/binary
Size: 218 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011017/0f9abb6f/attachment.bin 

From wpilorz at bdk.pl  Wed Oct 17 18:06:42 2001
From: wpilorz at bdk.pl (Wojtek Pilorz)
Date: Wed, 17 Oct 2001 10:06:42 +0200 (CEST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.33.0110121139030.1209-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.21.0110170955540.6825-100000@celebris.bdk.pl>

On Fri, 12 Oct 2001, Damien Miller wrote:

> Date: Fri, 12 Oct 2001 11:47:38 +1000 (EST)
> From: Damien Miller <djm at mindrot.org>
> To: openssh-unix-dev at mindrot.org
> Subject: Please test snapshots for 3.0 release
> 
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
> 
> If you have any patches you would like us to consider, please resend 
> them to the list ASAP.
> 
Would you consider changing configure
call in openssh/contrib/redhat/openssh.spec

by replacing 
  --with-rsh=/usr/bin/rsh
with
  --without-rsh

thus not encouraging users to install rsh?
This would prevent from connecting to hosts which have rshd, which could
be considered a problem or a feature. I would consider it a feature.

The two other spec files included do not have either --with-rsh or
--without-rsh 

Best regards,

Wojtek
--------------------
Wojtek Pilorz
Wojtek.Pilorz at bdk.pl




From j.petersen at msh.de  Wed Oct 17 19:45:09 2001
From: j.petersen at msh.de (j.petersen at msh.de)
Date: Wed, 17 Oct 2001 11:45:09 +0200
Subject: Again: bugs in contrib/solaris/opensshd.in and buildpkg.sh
Message-ID: <B56A3A4C735ED2118F25000083687FBB019D6DA6@MSHNTS04>

	(Shame on me: wrong filename in last posting, now here are correct
diffs)
in contrib/solaris/ (openssh-SNAP-20011017.tar.gz)

1) buildpkg.sh makes wrong link for /etc/init.d/opensshd
2) /etc/init.d/opensshd has not-working killproc
	here my version tested on Solaris 2.4 and 8
		 (no pgrep with solaris 2.4, XARGS was undefined, simpler
syntax)
J?rg

--- contrib/solaris/buildpkg.sh Fri Oct 12 22:30:53 2001
+++ contrib/solaris/buildpkg.sh Tue Oct 16 13:53:07 2001
@@ -40,9 +40,9 @@
        ../opensshd.in  > $FAKE_ROOT/etc/init.d/opensshd
 chmod 711 $FAKE_ROOT/etc/init.d/opensshd

-ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
-ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
-ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd
+ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
+ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
+ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd


--- contrib/solaris/opensshd.in Fri Oct 12 23:52:39 2001
+++ contrib/solaris/opensshd.in Wed Oct 17 10:49:00 2001
@@ -8,6 +8,7 @@
 EGREP=/usr/bin/egrep
 KILL=/usr/bin/kill
 PS=/usr/bin/ps
+XARGS=/usr/bin/xargs

 prefix=%%openSSHDir%%
 etcdir=%%configDir%%
@@ -21,7 +22,7 @@
 killproc() {
    _procname=$1
    _signal=$2
-   ${PGREP} ${_procname} | ${HEAD} -1 | ${XARGS} -t -I {} ${KILL}
-${_signal} {}
+   ${PS} -u root|${AWK} '/'"$_procname"'$/ {print $1}'| ${XARGS} ${KILL}
-${_signal}
 }

___________________________________________
Dr. J?rg Petersen <j.petersen at msh.de>
Medien System Haus    Tel. 0711/72007-424
Plieninger Str. 150,  D-70567 Stuttgart


From markus at openbsd.org  Wed Oct 17 20:23:19 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Oct 2001 12:23:19 +0200
Subject: Patch for changing expired passwords
In-Reply-To: <20011016105725.A25928@lucent.com>; from dwd@bell-labs.com on Tue, Oct 16, 2001 at 10:57:26AM -0500
References: <20011012153452.A18421@lucent.com> <200110122142.OAA555237@nopython.nas.nasa.gov> <20011015130054.C16189@lucent.com> <20011016104420.A8326@faui02.informatik.uni-erlangen.de> <20011016105725.A25928@lucent.com>
Message-ID: <20011017122319.A574@faui02.informatik.uni-erlangen.de>

On Tue, Oct 16, 2001 at 10:57:26AM -0500, Dave Dykstra wrote:
> However, I tried moving the forced_passwd_change code to do_child() and it
> didn't work because do_exec_pty() (via do_login()/check_quiet_login()) does
> different things depending on whether or not command is NULL.

what does not work? the checks should not be relevant in this case
i think. but we can move it to do_child later.


From Nicolas.Williams at ubsw.com  Wed Oct 17 23:12:00 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 17 Oct 2001 09:12:00 -0400
Subject: [Fwd: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and 2.9p2]
In-Reply-To: <3BCCC46F.E21067C2@silicondefense.com>; from C. Jason Coit on Tue, Oct 16, 2001 at 04:36:15PM -0700
References: <3BCCC46F.E21067C2@silicondefense.com>
Message-ID: <20011017091200.U26615@wdr.com>

Oh, I see. I misunderstood your description of your patch.

Thanks,

Nico


On Tue, Oct 16, 2001 at 04:36:15PM -0700, C. Jason Coit wrote:
> Nicolas,
> 
> The timing attack described in the paper by Dawn Song et al. works by
> examining the timing of keystrokes.  Currently OpenSSH sends a packet
> every time you press a key, thus it is possible to capture the
> approximate inter-keystroke timing of a user (they found minimal
> overhead
> in time from a key press to packet sent).  Our patch causes a packet to
> be sent every 50 ms regardless of whether you type a key or not (sends
> an ignore message aka nop).  Thus an attacker cannot be exactly sure of
> your inter-keystroke timing.  
> 
> It doesn't matter if you are an average user or a fast touch-typing
> secretary, your inter-keystroke timing is obscured.  In addition to this
> our patch conserves bandwidth by shutting off after about a second after
> the last key press.  If you don't stop typing for more than a second, it
> appears as if you are constantly send packets to the server every 50
> ms.    
> Adding random noise would be less effective than what we are doing. 
> Random noise would dilute the signal of inter-keystroke timing, we are
> eliminating the signal altogether.  By pacing the inter-packet timing we
> completely remove the inter-keystroke timing information.
> 
> regards,
> 
> -Jason Coit
> 
> -------- Original Message --------
> Subject: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and
> 2.9p2
> Date: Tue, 16 Oct 2001 17:36:18 -0400
> From: Nicolas Williams <Nicolas.Williams at ubsw.com>
> To: "C. Jason Coit" <jasonc at silicondefense.com>
> CC: openssh-unix-dev at mindrot.org
> References: <3BCC889C.AA5C57F0 at silicondefense.com>
> 
> Let's see. The timing attack has to do with predictable timing. The
> solution would seem to be to add randomness to the packet timing. Your
> patch does not do this -- it adds more predictable traffic.
> 
> I would think that to defeat the timing attack SSH would have to send
> random-sized no-op packets at random intervals, or perhaps just adding
> random delays before sending packets. And, of course, we're not talking
> IP packets here, but SSH "packets."
> 
> But I could be wrong, I'm not an expert on this subject.
> 
> 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 dwd at bell-labs.com  Wed Oct 17 23:21:38 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Wed, 17 Oct 2001 08:21:38 -0500
Subject: Patch for changing expired passwords
In-Reply-To: <20011017122319.A574@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Oct 17, 2001 at 12:23:19PM +0200
References: <20011012153452.A18421@lucent.com> <200110122142.OAA555237@nopython.nas.nasa.gov> <20011015130054.C16189@lucent.com> <20011016104420.A8326@faui02.informatik.uni-erlangen.de> <20011016105725.A25928@lucent.com> <20011017122319.A574@faui02.informatik.uni-erlangen.de>
Message-ID: <20011017082137.A17147@lucent.com>

On Wed, Oct 17, 2001 at 12:23:19PM +0200, Markus Friedl wrote:
> On Tue, Oct 16, 2001 at 10:57:26AM -0500, Dave Dykstra wrote:
> > However, I tried moving the forced_passwd_change code to do_child() and it
> > didn't work because do_exec_pty() (via do_login()/check_quiet_login()) does
> > different things depending on whether or not command is NULL.
> 
> what does not work? the checks should not be relevant in this case
> i think. but we can move it to do_child later.

It turns out it's not quite as bad as I thought, I think because of
something strange in my testing which led me to believe it had an effect on
X forwarding.  The actual difference is that if "command" is NULL because
the user didn't supply any command and intended to login, leaving the check
in do_exec() causes do_login() to exit right after it calls
check_quiet_login() and to not print things it normally prints for
interactive logins such as the last login time or the message of the day.
I don't think it's right to print either of those before prompting for a
password change.

Also, my opinion is that it's cleaner to have the forced_password_change
check in the same place as the forced_command check.

- Dave Dykstra


From j.petersen at msh.de  Thu Oct 18 01:06:19 2001
From: j.petersen at msh.de (j.petersen at msh.de)
Date: Wed, 17 Oct 2001 17:06:19 +0200
Subject: AIX - Compilation issues with openssh
Message-ID: <B56A3A4C735ED2118F25000083687FBB019D6DAA@MSHNTS04>

Hello Developers/users @AIX,

My Question:
What compiler and what configure-Options do you use to build the
ssh-Packages?

My Problem:
   Logging in via self-built sshd:  no problem
but when doing a second "ssh"-step to another host, the tty 
is messed up: 
		 jp $ su -
echos:	 su -
		 [and Password is visible... and cursor keys don't work...]
Problem occurs only when the first step of successive "ssh"'s is
	from Putty (SSH-2) or TeraTerm (SSH-1) to the self-compiled
sshd at AIX...
	Any other combination works fine.

Background:
   openssh-Binaries from Linux-Toolbox and from Bull work nice.
However, I need --with-tcp-wrapper enabled and AIX432.

I tried:
   a) recent daily Snapshots (worked fine with solaris 2.4,2.5,2.6,2.7)
   b) IBMs openssh-2.9.9p2-3.src.rpm
   1) C-Compiler ibmcxx.rte 3.6.6.0 from IBM
   2) gcc 2.95.2 (binaries from bull)
   A) AIX-432-ML2
   B) AIX-433-ML8

   ./configure --prefix=/usr/local --with-prngd-socket=/dev/entropy
--sysconfdir=/etc/ssh
		 --with-default-path=... --with-mantype=man
--with-tcp-wrapper --with-ssl-dir=...
   (SSL was mainly freeware.openssl.rte.0.9.6.0 binary from Bull)

Seems I'm the only AIX-user having this problem???
Must be my compiler(s!), libraries, ... ???

Having no clue how to debug this...

Thanks J?rg


From marc at austin.ibm.com  Thu Oct 18 01:51:10 2001
From: marc at austin.ibm.com (Marc Stephenson)
Date: Wed, 17 Oct 2001 10:51:10 -0500 (CDT)
Subject: [tbox-l] AIX - Compilation issues with openssh
In-Reply-To: <no.id> from "j.petersen@msh.de" at Oct 17, 2001 05:06:19 PM
Message-ID: <200110171551.f9HFpAu41152@yogi.austin.ibm.com>

AIX Toolbox builds openssh with vac.C 5.0.2.0, and configures with very few
options:

export blibpath="/opt/freeware/lib:/usr/lib:/lib"

%configure --prefix=%{prefix} \
	--sysconfdir=/etc/ssh \
	--libexecdir=%{_libexecdir}/openssh \
	--with-ipv4-default \
	--with-rsh=/usr/bin/rsh

If you extract the openshh.spec file from the SRPM, you can see exactly
what we do (you already have it in the /opt/freeware/src/packages/SPECS
directory if you installed the SRPM):
     rpm2cpio openssh*src.rpm | /usr/linux/bin/cpio -iv openssh.spec

Marc

> 
> Hello Developers/users @AIX,
> 
> My Question:
> What compiler and what configure-Options do you use to build the
> ssh-Packages?
> 
> My Problem:
>    Logging in via self-built sshd:  no problem
> but when doing a second "ssh"-step to another host, the tty 
> is messed up: 
> 		 jp $ su -
> echos:	 su -
> 		 [and Password is visible... and cursor keys don't work...]
> Problem occurs only when the first step of successive "ssh"'s is
> 	from Putty (SSH-2) or TeraTerm (SSH-1) to the self-compiled
> sshd at AIX...
> 	Any other combination works fine.
> 
> Background:
>    openssh-Binaries from Linux-Toolbox and from Bull work nice.
> However, I need --with-tcp-wrapper enabled and AIX432.
> 
> I tried:
>    a) recent daily Snapshots (worked fine with solaris 2.4,2.5,2.6,2.7)
>    b) IBMs openssh-2.9.9p2-3.src.rpm
>    1) C-Compiler ibmcxx.rte 3.6.6.0 from IBM
>    2) gcc 2.95.2 (binaries from bull)
>    A) AIX-432-ML2
>    B) AIX-433-ML8
> 
>    ./configure --prefix=/usr/local --with-prngd-socket=/dev/entropy
> --sysconfdir=/etc/ssh
> 		 --with-default-path=... --with-mantype=man
> --with-tcp-wrapper --with-ssl-dir=...
>    (SSL was mainly freeware.openssl.rte.0.9.6.0 binary from Bull)
> 
> Seems I'm the only AIX-user having this problem???
> Must be my compiler(s!), libraries, ... ???
> 
> Having no clue how to debug this...
> 
> Thanks J?rg
> _______________________________________________
> aixtoolbox-list mailing list
> aixtoolbox-list at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/aixtoolbox-list
> 


-- 
Marc Stephenson		                          IBM Server Group - Austin, TX
Internet:  marc at austin.ibm.com                          NOTES: marcs at us.ibm.com
Phone:   512-327-5670                                              T/L 678-3189


From chua at ayrnetworks.com  Thu Oct 18 03:20:41 2001
From: chua at ayrnetworks.com (Bryan Chua)
Date: Wed, 17 Oct 2001 10:20:41 -0700
Subject: program-prefix does not work
References: <Pine.UW2.4.40.9.0110161834320.163-100000@uw711.int.multitalents.net>
Message-ID: <3BCDBDE9.1050802@ayrnetworks.com>

Sorry about that.  I read the FAQ and... spaced.

-- bryan

Tim Rice wrote:

> Please resubmit with diff -u
> 
> On Tue, 16 Oct 2001, Bryan Chua wrote:
> 
> 
>>the configure option --program-prefix does not work although it is
>>listed in teh configure --help output.
>>
>>The attached patch fixes these issues:
>>1) program prefix is not substituted in configure
>>2) program prefix is not present in Makefile
>>3) scp requires use of a known "scp" program
>>
>>-- bryan
>>
>>diff -cr openssh-2.9.9p2.orig/Makefile.in openssh-2.9.9p2/Makefile.in
>>
> [patch snipped]
> 
> 


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs.openssh-2.9.9p2
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011017/f1bd7392/attachment.ksh 

From cheek at mars-systems.com  Thu Oct 18 04:11:03 2001
From: cheek at mars-systems.com (Matt Cheek)
Date: Wed, 17 Oct 2001 14:11:03 -0400
Subject: Password Expiration Issue on Solaris with PAM
Message-ID: <E1018C677CDCA74B8748DBD59E44FB310D0510@exchange-02.mars-systems.com>


I am running v2.9.9p2 on Solaris 8 with PAM support. When I login to an
account with an expired password, I am prompted to change my password (which
is good), however, both the old and new passwords are echoed on the screen
(very bad). For example:

$ ssh nova
Warning: Your password has expired, please change it now
Enter login password: oldpass
New password: newpass
Re-enter new password: newpass
sshd (SYSTEM): passwd successfully changed for cheek
Last login: Wed Oct 17 13:31:31 2001 from quasar
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000
Authorized uses only. All activity may be monitored and reported.
nova$ 

Per the INSTALL doc, I am using the stock Solaris /etc/pam.conf file.

Is this a configuration issue or a bug?
Matt


From bsdguy at noos.fr  Thu Oct 18 04:18:30 2001
From: bsdguy at noos.fr (Saad Kadhi)
Date: 17 Oct 2001 20:18:30 +0200
Subject: OpenSSH 2.9.9p2 on Solaris 8 buffer_get problem
Message-ID: <1003342710.3522.88.camel@kenjiro>

Hi there,

I have a weird problem with OpenSSH 2.9.9p2 on Solaris 8. Whenever I try
to use ssh, scp or sftp to connect to the Solaris box, the connection is
closed by the server and the following msg logged thru syslog:
"sshd[542]: fatal: buffer_get: trying to get more bytes 129 than in
buffer 39"

I tried from an RH 7.1 client (2.9.9p2), from a Solaris 8 client
(2.9.9p2), and an OpenBSD 2.9 client (2.9.9) & the same thing happens.
OpenSSH 2.9.9p2 has been installed from source with the following
required/optional software:
openssl 0.9.6b (compiled with -lsocket -lnsl if that matters)
prngd 0.9.23
zlib 1.1.3
gcc 2.95.3 
Solaris 8 make or GNU make 3.7x (tried both)

I tried an alternate install on another Solaris 8 box (not secured,
Entire Distribution) to no avail.

Here is the debug output (firewall is the problematic machine) [PLEASE
CC me because I'm not subscribed to the list]:
--ssh from a Solaris 8 client:
[root at autoserver /]# /opt/OBSDssh/bin/ssh firewall                    
Connection closed by x.y.z.t

--ssh -vv from a Solaris 8 client:
[root at autoserver /]# /opt/OBSDssh/bin/ssh -vv firewall
OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /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
debug1: Connecting to firewall [x.y.z.t] port 22.
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version
OpenSSH_2.9.9p2
debug1: match: OpenSSH_2.9.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9.9p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
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: 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,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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: 125/256
debug1: bits set: 512/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'firewall' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:3
debug1: bits set: 528/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 privkey: /.ssh/identity
debug1: try privkey: /.ssh/id_rsa
debug1: try pubkey: /.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
Connection closed by x.y.z.t
debug1: Calling cleanup 0x3dd3c(0x0)
[root at autoserver /]# 
--scp from a Solaris 8 client:
[root at autoserver /]# /opt/OBSDssh/bin/scp /etc/hosts firewall:/etc
Connection closed by x.y.z.t
lost connection
[root at autoserver /]#

--scp -vv from a Solaris 8 client:
[root at autoserver /]# /opt/OBSDssh/bin/scp -vv /etc/hosts firewall:/etc
Executing: program /opt/OBSDssh/bin/ssh host firewall, user
(unspecified), command scp -v -t /etc
OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /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
debug1: Connecting to firewall [x.y.z.t] port 22.
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version
OpenSSH_2.9.9p2
debug1: match: OpenSSH_2.9.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9.9p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
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: 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,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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: 117/256
debug1: bits set: 493/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'firewall' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:3
debug1: bits set: 533/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 privkey: /.ssh/identity
debug1: try privkey: /.ssh/id_rsa
debug1: try pubkey: /.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
Connection closed by x.y.z.t
debug1: Calling cleanup 0x3dd3c(0x0)
lost connection
[root at autoserver /]# 


TIA
 
-- 
/saad
[put your signature here]
self-customize-sig(tm). another dumb patent...
nodisclaimer



From monty at mysql.com  Thu Oct 18 05:27:27 2001
From: monty at mysql.com (Michael Widenius)
Date: Wed, 17 Oct 2001 22:27:27 +0300 (EEST)
Subject: Bug when flushing data in openssh 2.9
Message-ID: <15309.56223.967494.575540@narttu.mysql.fi>


Hi!

I am use SuSe 7.2 x86 and openssh-2.9p1-7.rpm

I got a problem using bitkeeper on my laptop where bitkeeper
reported an I/O error while reading data from 'ssh'.

After much debugging, and some help from the bitkeeper people, I found
out that that clientloop.c doesn't handle interrupts gracefully.
(It died when it got an EAGAIN error when writing to the application)

After applying the following patch, everything started to work for me:

*** clientloop-old.c	Wed Oct 17 22:05:30 2001
--- clientloop.c	Wed Oct 17 22:01:46 2001
***************
*** 937,947 ****
  	}
  	/* Output any buffered data for stdout. */
  	while (buffer_len(&stdout_buffer) > 0) {
  		len = write(fileno(stdout), buffer_ptr(&stdout_buffer),
  		    buffer_len(&stdout_buffer));
! 		if (len <= 0) {
! 			error("Write failed flushing stdout buffer.");
! 			break;
  		}
  		buffer_consume(&stdout_buffer, len);
  		stdout_bytes += len;
--- 937,953 ----
  	}
  	/* Output any buffered data for stdout. */
  	while (buffer_len(&stdout_buffer) > 0) {
+ 	        errno=0;		/* Linux doesn't reset this */
  		len = write(fileno(stdout), buffer_ptr(&stdout_buffer),
  		    buffer_len(&stdout_buffer));
! 		if (len <= 0)
! 		{
! 		  if (errno != EAGAIN && errno != EINTR)
! 		  {
! 		    error("Write failed flushing stdout buffer.");
! 		    break;
! 		  }
! 		  continue;
  		}
  		buffer_consume(&stdout_buffer, len);
  		stdout_bytes += len;

Regards,
Monty
CTO of MySQL AB


From markus at openbsd.org  Thu Oct 18 05:48:35 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Oct 2001 21:48:35 +0200
Subject: Bug when flushing data in openssh 2.9
In-Reply-To: <15309.56223.967494.575540@narttu.mysql.fi>; from monty@mysql.com on Wed, Oct 17, 2001 at 10:27:27PM +0300
References: <15309.56223.967494.575540@narttu.mysql.fi>
Message-ID: <20011017214835.A24543@faui02.informatik.uni-erlangen.de>

On Wed, Oct 17, 2001 at 10:27:27PM +0300, Michael Widenius wrote:
> 
> Hi!
> 
> I am use SuSe 7.2 x86 and openssh-2.9p1-7.rpm
> 
> I got a problem using bitkeeper on my laptop where bitkeeper
> reported an I/O error while reading data from 'ssh'.
> 
> After much debugging, and some help from the bitkeeper people, I found
> out that that clientloop.c doesn't handle interrupts gracefully.
> (It died when it got an EAGAIN error when writing to the application)
> 
> After applying the following patch, everything started to work for me:

2.9 is very old, please check 2.9.9 at
	http://www.openssh.com/portable.html
or try a recent snapshot.


From ronis at ronispc.chem.mcgill.ca  Thu Oct 18 06:02:35 2001
From: ronis at ronispc.chem.mcgill.ca (David Ronis)
Date: Wed, 17 Oct 2001 16:02:35 -0400
Subject: OpenSSH_2.9.9p2 Configuration problem
Message-ID: <15309.58331.127416.633599@ronispc.chem.mcgill.ca>

I've recently upgraded some of my machines from an ssh1 environment to
an openssh one, and consequently, I'm now using the ssh2 protocol.  I
can't seem to get it to allow remote logins without prompting for a
passphrase or password.  Is this possible?  I've created id_dsa and
id_rsa files etc., using ssh-keygen and have copied the public
information to the remote authorized_keys files from the other ends of
the connections.

When I try to connect, I get propted for the rsa passphrase, and if I
don't give it, the dsa one, and finally the password.

I prefer the ssh1 behavior, although, adding the information to the
various authorized_keys files is no great hardship.

Any suggestions?

I don't subscribe to this list, so please cc me directly.


David



From vsync at quadium.net  Thu Oct 18 08:14:56 2001
From: vsync at quadium.net (vsync)
Date: Wed, 17 Oct 2001 15:14:56 -0700
Subject: OpenSSH_2.9.9p2 Configuration problem
Message-ID: <2.1-307692-291-A-OEWW@feynman.hurstdog.org>



David Ronis wrote:
> I've created id_dsa and
> id_rsa files etc., using ssh-keygen and have copied the public
> information to the remote authorized_keys files from the other ends of
> the connections.

That's your problem.  After you have created your passwordless key(s), 
you will want to add them to the remote authorized_keys2 file. 
  authorized_keys is only used for ssh1 connexions.

I found this out myself after much pain and error.



From markus at openbsd.org  Thu Oct 18 07:31:02 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Oct 2001 23:31:02 +0200
Subject: OpenSSH_2.9.9p2 Configuration problem
In-Reply-To: <2.1-307692-291-A-OEWW@feynman.hurstdog.org>; from vsync@quadium.net on Wed, Oct 17, 2001 at 03:14:56PM -0700
References: <2.1-307692-291-A-OEWW@feynman.hurstdog.org>
Message-ID: <20011017233102.B24543@faui02.informatik.uni-erlangen.de>

in 2.9.9 authorized_keys is used for both protocol versions.

On Wed, Oct 17, 2001 at 03:14:56PM -0700, vsync wrote:
> 
> 
> David Ronis wrote:
> > I've created id_dsa and
> > id_rsa files etc., using ssh-keygen and have copied the public
> > information to the remote authorized_keys files from the other ends of
> > the connections.
> 
> That's your problem.  After you have created your passwordless key(s), 
> you will want to add them to the remote authorized_keys2 file. 
>   authorized_keys is only used for ssh1 connexions.
> 
> I found this out myself after much pain and error.
> 


From john_van_v at yahoo.com  Thu Oct 18 07:33:50 2001
From: john_van_v at yahoo.com (John van V.)
Date: Wed, 17 Oct 2001 14:33:50 -0700 (PDT)
Subject: OpenSSH on Cybwin... ctl-C kills the session
In-Reply-To: <20011015191949.A22329@faui02.informatik.uni-erlangen.de>
Message-ID: <20011017213350.870.qmail@web10503.mail.yahoo.com>


Hi, I got the OpenSSH binaries from Cygnus to install in my ZSH connectivity
kit, and despite mucho kudos, the cygwin gotchas got me.

Basically, Ctl-C does what Ctl-D is supposed to do.

Run under ZSH the same thing happens, but not with my original SSH1 client from
cygnus.

Why post here ??  I dont really want to subscribe to cygwin lists.

Any Clues ?? 

TIA, John




=====
John van Vlaanderen

      #############################################
      #    CXN, Inc. Contact:  john at thinman.com   #               #
      #      Proud Sponsor of Perl/Unix of NY     #
      #        http://puny.vm.com                 #                 
      #############################################

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From carson at taltos.org  Thu Oct 18 08:58:27 2001
From: carson at taltos.org (Carson Gaspar)
Date: Wed, 17 Oct 2001 15:58:27 -0700
Subject: Bug when flushing data in openssh 2.9
In-Reply-To: <20011017214835.A24543@faui02.informatik.uni-erlangen.de>
References: <20011017214835.A24543@faui02.informatik.uni-erlangen.de>
Message-ID: <3348565468.1003334307@athyra>



--On Wednesday, October 17, 2001 9:48 PM +0200 Markus Friedl 
<markus at openbsd.org> wrote:

> 2.9 is very old, please check 2.9.9 at

You have a rather odd definition of "very old"? 2.9 was released less than 
6 months ago.

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



From qralston+ml.openssh-unix-dev at andrew.cmu.edu  Thu Oct 18 09:01:36 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Wed, 17 Oct 2001 19:01:36 -0400 (EDT)
Subject: CVS oddness on Solaris.
In-Reply-To: <Pine.BSO.4.33.0110141611320.20004-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.33.0110171857320.30612-100000@pcmy.sei.cmu.edu>

On Sun, 14 Oct 2001 mouring at etoh.eviladmin.org wrote:
> This is solved by enabled the PAM TTY hack.. Which breaks HP/UX.  I
> think we should enable the PAM TTY hack for Solaris if we are going
> to keep with the idea of doing sessions for non-interactive logins.

IMO, doing PAM sessions for non-interactive logins is the correct
thing to do; interactive or no, one is still creating a session on the
machine...

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From jmknoble at pobox.com  Thu Oct 18 09:18:54 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 17 Oct 2001 19:18:54 -0400
Subject: Bug when flushing data in openssh 2.9
In-Reply-To: <3348565468.1003334307@athyra>; from carson@taltos.org on Wed, Oct 17, 2001 at 03:58:27PM -0700
References: <20011017214835.A24543@faui02.informatik.uni-erlangen.de> <3348565468.1003334307@athyra>
Message-ID: <20011017191854.B1830@zax.half.pint-stowp.cx>

Circa 2001-Oct-17 15:58:27 -0700 dixit Carson Gaspar:

: --On Wednesday, October 17, 2001 9:48 PM +0200 Markus Friedl
: <markus at openbsd.org> wrote:
: 
: > 2.9 is very old, please check 2.9.9 at
: 
: You have a rather odd definition of "very old"? 2.9 was released less than 
: 6 months ago.

Markus (and Ben, and Damien, and others) are all pretty close to the
code---cut them some slack.  Hell, 2.9.9 is getting old for them, in
code years....

-- 
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/20011017/881b915c/attachment.bin 

From djm at mindrot.org  Thu Oct 18 09:59:11 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 18 Oct 2001 09:59:11 +1000 (EST)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <Pine.LNX.4.21.0110170955540.6825-100000@celebris.bdk.pl>
Message-ID: <Pine.LNX.4.33.0110180956530.10394-100000@mothra.mindrot.org>

On Wed, 17 Oct 2001, Wojtek Pilorz wrote:

> Would you consider changing configure
> call in openssh/contrib/redhat/openssh.spec
> 
> by replacing 
>   --with-rsh=/usr/bin/rsh
> with
>   --without-rsh
> 
> thus not encouraging users to install rsh?
> This would prevent from connecting to hosts which have rshd, which could
> be considered a problem or a feature. I would consider it a feature.

The RPMs don't require the installation of rsh to run. The default of 
FallBackToRsh is no anyway.

-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  Thu Oct 18 10:04:22 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 18 Oct 2001 10:04:22 +1000 (EST)
Subject: program-prefix does not work
In-Reply-To: <3BCDBDE9.1050802@ayrnetworks.com>
Message-ID: <Pine.LNX.4.33.0110181003580.10394-100000@mothra.mindrot.org>

On Wed, 17 Oct 2001, Bryan Chua wrote:

> >>the configure option --program-prefix does not work although it is
> >>listed in teh configure --help output.

What is the purpose of this?

-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 Darren.Moffat at eng.sun.com  Thu Oct 18 10:06:13 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Wed, 17 Oct 2001 17:06:13 -0700 (PDT)
Subject: program-prefix does not work
Message-ID: <200110180007.f9I07VjY808258@jurassic.eng.sun.com>

>> >>the configure option --program-prefix does not work although it is
>> >>listed in teh configure --help output.
>
>What is the purpose of this?

It is quite often used to have things like the GNU version of tar installed
as gtar rather than tar.  This is different to where the binaries get placed.

For OpenSSH I could see people using it to install the binaries with
a prefix of open eg:
	openssh
	openscp
	opensftp
	opensshd
	
--
Darren J Moffat



From djm at mindrot.org  Thu Oct 18 10:15:01 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 18 Oct 2001 10:15:01 +1000 (EST)
Subject: Bugzilla for portable OpenSSH
Message-ID: <Pine.LNX.4.33.0110181010270.10394-100000@mothra.mindrot.org>

To make it easier for us to track bugs (and reduce the likelihood of 
patches falling through the cracks), I have set up a bug tracking 
system using the Mozilla projects Bugzilla software.

You can access Bugzilla at http://bugzilla.mindrot.org/

To do anything useful (esp. enter bugs) you will need to create an 
account. Bugzilla is a little overcomplicated for a small project,
but it handles everything that we need.

It would be good if people start using it ASAP, especially for patches.

If you have any problems, please contact 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 chua at ayrnetworks.com  Thu Oct 18 11:35:40 2001
From: chua at ayrnetworks.com (Bryan Chua)
Date: Wed, 17 Oct 2001 18:35:40 -0700
Subject: program-prefix does not work
References: <200110180007.f9I07VjY808258@jurassic.eng.sun.com>
Message-ID: <3BCE31EC.9030305@ayrnetworks.com>

We are using it to prefix our installation with "ayr-" in a manner that 
can coexist transparently with previous ssh installations, so that is

/etc/ayr-ssh
/usr/lib/ayr-ssh
${HOME}/.ayr-ssh
ayr-ssh
ayr-sshd
...

-- bryan

Darren Moffat wrote:

>>>>>the configure option --program-prefix does not work although it is
>>>>>listed in teh configure --help output.
>>>>>
>>What is the purpose of this?
>>
> 
> It is quite often used to have things like the GNU version of tar installed
> as gtar rather than tar.  This is different to where the binaries get placed.
> 
> For OpenSSH I could see people using it to install the binaries with
> a prefix of open eg:
> 	openssh
> 	openscp
> 	opensftp
> 	opensshd
> 	
> --
> Darren J Moffat
> 
> 





From openssh at jakob.weite-welt.com  Thu Oct 18 21:44:30 2001
From: openssh at jakob.weite-welt.com (Leif Jakob)
Date: Thu, 18 Oct 2001 13:44:30 +0200
Subject: Patch for SSH-tunneling via HTTPS-proxy
Message-ID: <20011018134430.A24158@freya.weite-welt.com>

Hi List,

I have a szenario where I need to reach a host on the internet from a
"firewalled" network but there is a HTTPS-proxy runnnig. As some
people know you can tunnel all TCP-connections through this proxy
because it can't decide if someone is really doing SSL or just Telnet
to port 443 (or use SSH in our case).

So I've written a patch for ssh to make it send the 

CONNECT $host:$port HTTP/1.0\r\n\r\n

to the proxy. The new call is now:

ssh -p 3128 -H host.on.internet.org:443 myuser at local.proxy

All you need is a SSH-Server running on port 443 on
host.on.internet.org, or if the proxy allows (squid doesn't) port 22.


Cheers

Leif

diff --unified --recursive openssh-2.9.9p2.orig/readconf.c openssh-2.9.9p2.httpsproxy/readconf.c
--- openssh-2.9.9p2.orig/readconf.c	Thu Oct 18 11:53:43 2001
+++ openssh-2.9.9p2.httpsproxy/readconf.c	Thu Oct 18 11:55:48 2001
@@ -789,6 +789,7 @@
 	options->num_local_forwards = 0;
 	options->num_remote_forwards = 0;
 	options->clear_forwardings = -1;
+	options->https_proxy = NULL;
 	options->log_level = (LogLevel) - 1;
 	options->preferred_authentications = NULL;
 	options->bind_address = NULL;
diff --unified --recursive openssh-2.9.9p2.orig/readconf.h openssh-2.9.9p2.httpsproxy/readconf.h
--- openssh-2.9.9p2.orig/readconf.h	Thu Oct 18 11:53:43 2001
+++ openssh-2.9.9p2.httpsproxy/readconf.h	Thu Oct 18 11:55:09 2001
@@ -101,6 +101,10 @@
 	int     num_remote_forwards;
 	Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION];
 	int	clear_forwardings;
+
+        /* https proxy options */ 
+	char   *https_proxy;	/* connect string to send to https-proxy */
+
 }       Options;
 
 
diff --unified --recursive openssh-2.9.9p2.orig/ssh.c openssh-2.9.9p2.httpsproxy/ssh.c
--- openssh-2.9.9p2.orig/ssh.c	Thu Oct 18 11:53:43 2001
+++ openssh-2.9.9p2.httpsproxy/ssh.c	Thu Oct 18 13:41:07 2001
@@ -205,6 +205,7 @@
 	fprintf(stderr, "  -o 'option' Process the option as if it was read from a configuration file.\n");
 	fprintf(stderr, "  -s          Invoke command (mandatory) as SSH2 subsystem.\n");
 	fprintf(stderr, "  -b addr     Local IP address.\n");
+	fprintf(stderr, "  -H 'realhost:port'  do HTTPS-proxy negotiation before expecting SSH-version\n");
 	exit(1);
 }
 
@@ -320,7 +321,7 @@
 
 again:
 	while ((opt = getopt(ac, av,
-	    "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) {
+	    "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVXH:")) != -1) {
 		switch (opt) {
 		case '1':
 			options.protocol = SSH_PROTO_1;
@@ -530,6 +531,9 @@
 			break;
 		case 'F':
 			config = optarg;
+			break;
+		case 'H':
+		        options.https_proxy = optarg;
 			break;
 		default:
 			usage();
diff --unified --recursive openssh-2.9.9p2.orig/sshconnect.c openssh-2.9.9p2.httpsproxy/sshconnect.c
--- openssh-2.9.9p2.orig/sshconnect.c	Thu Oct 18 11:53:43 2001
+++ openssh-2.9.9p2.httpsproxy/sshconnect.c	Thu Oct 18 13:20:43 2001
@@ -387,6 +387,34 @@
 	return 0;
 }
 
+/* uses "CONNECT %s HTTP/1.0\r\n\r\n" to access real host via https-proxy 
+ * the SSH-handshake code will handle results from the proxy
+ *
+ * this nice patch was brought to you by Leif Jakob <openssh at jakob.weite-welt.com>, don't blame me
+ * if someone is abusing your misconfigured proxies :) but some broken firewalls require this feature
+ */
+void
+https_proxy_handshake(const char *connect_string)
+{
+  int connection_out = packet_get_connection_out();
+
+#define PROXY1 "CONNECT "
+#define PROXY3 " HTTP/1.0\r\n\r\n"
+
+  if (atomicio(write, connection_out, PROXY1, sizeof(PROXY1)-1) != sizeof(PROXY1)-1)
+    fatal("write proxy1: %.100s", strerror(errno));
+
+  if (atomicio(write, connection_out, (void *)connect_string, strlen(connect_string)) != strlen(connect_string))
+    fatal("write proxy2: %.100s", strerror(errno));
+
+  if (atomicio(write, connection_out, PROXY3, sizeof(PROXY3)-1) != sizeof(PROXY3)-1)
+    fatal("write proxy3: %.100s", strerror(errno));
+  
+#undef PROXY1
+#undef PROXY3
+
+}
+
 /*
  * Waits for the server identification string, and sends our own
  * identification string.
@@ -883,6 +911,10 @@
 	for (cp = host; *cp; cp++)
 		if (isupper(*cp))
 			*cp = tolower(*cp);
+
+	/* do https-handshake with HTTPS-proxy we abuse for SSH tunneling */
+	if ( options.https_proxy )
+	  https_proxy_handshake(options.https_proxy);
 
 	/* Exchange protocol version identification strings with the server. */
 	ssh_exchange_identification();


From ronis at ronispc.chem.mcgill.ca  Fri Oct 19 02:07:33 2001
From: ronis at ronispc.chem.mcgill.ca (David Ronis)
Date: Thu, 18 Oct 2001 12:07:33 -0400
Subject: OpenSSH_2.9.9p2 Configuration problem
Message-ID: <15310.65093.11715.183698@ronispc.chem.mcgill.ca>


Hi Markus,

Thanks for the reply.  I had copied the public keys to authorized_keys
on the remote machine and the remote's to the local.  I did specify a
passphrase when creating the keys.  Is this the problem?

Also, is ssh2 really worth the effort?  I've disabled the traditional
rsh/rlogin/rcp programs on all my machines, so what else would ssh2
offer over ssh1?

David

You wrote:

> in 2.9.9 authorized_keys is used for both protocol versions.
> 
> On Wed, Oct 17, 2001 at 03:14:56PM -0700, vsync wrote:
> > 
> > 
> > David Ronis wrote:
> > > I've created id_dsa and
> > > id_rsa files etc., using ssh-keygen and have copied the public
> > > information to the remote authorized_keys files from the other ends of
> > > the connections.
> > 
> > That's your problem.  After you have created your passwordless key(s), 
> > you will want to add them to the remote authorized_keys2 file. 
> >   authorized_keys is only used for ssh1 connexions.
> > 
> > I found this out myself after much pain and error.
> > 
> 


From stevesk at pobox.com  Fri Oct 19 02:43:54 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Thu, 18 Oct 2001 09:43:54 -0700 (PDT)
Subject: Patch for SSH-tunneling via HTTPS-proxy
In-Reply-To: <20011018134430.A24158@freya.weite-welt.com>
Message-ID: <Pine.HPX.4.40.0110180941130.1393-100000@jenny>

On Thu, 18 Oct 2001, Leif Jakob wrote:
:I have a szenario where I need to reach a host on the internet from a
:"firewalled" network but there is a HTTPS-proxy runnnig.

using ProxyCommand with one of the scripts or programs out there that
handle HTTP CONNECT is best for this.  also, perhaps ssh -D should have
CONNECT handling added back.



From dwd at bell-labs.com  Fri Oct 19 04:06:57 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Thu, 18 Oct 2001 13:06:57 -0500
Subject: Patch to always make openbsd-compat
Message-ID: <20011018130657.A5025@lucent.com>

I found that if I modify a source file in the openbsd-compat directory
and go to the top level and type "make", nothing happens.  Here's a patch
for portable OpenSSH to fix that.

- Dave Dykstra


--- Makefile.in.O	Thu Oct 18 13:57:22 2001
+++ Makefile.in	Thu Oct 18 13:57:45 2001
@@ -86,8 +86,9 @@
 	$(CC) $(CFLAGS) $(CPPFLAGS) -c $<
 
 LIBCOMPAT=openbsd-compat/libopenbsd-compat.a
-$(LIBCOMPAT): config.h
+$(LIBCOMPAT): always
 	(cd openbsd-compat; $(MAKE))
+always:
 
 libssh.a: $(LIBSSH_OBJS)
 	$(AR) rv $@ $(LIBSSH_OBJS)


From mouring at etoh.eviladmin.org  Fri Oct 19 04:47:24 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 18 Oct 2001 13:47:24 -0500 (CDT)
Subject: CVS oddness on Solaris.
In-Reply-To: <Pine.LNX.4.33.0110171857320.30612-100000@pcmy.sei.cmu.edu>
Message-ID: <Pine.BSO.4.33.0110181347000.6009-100000@etoh.eviladmin.org>


Not disputing the fact.  Just stating what needs to be done in order for
Solaris to work right.

- Ben

On Wed, 17 Oct 2001, James Ralston wrote:

> On Sun, 14 Oct 2001 mouring at etoh.eviladmin.org wrote:
> > This is solved by enabled the PAM TTY hack.. Which breaks HP/UX.  I
> > think we should enable the PAM TTY hack for Solaris if we are going
> > to keep with the idea of doing sessions for non-interactive logins.
>
> IMO, doing PAM sessions for non-interactive logins is the correct
> thing to do; interactive or no, one is still creating a session on the
> machine...
>
> --
> James Ralston, Information Technology
> Software Engineering Institute
> Carnegie Mellon University, Pittsburgh, PA, USA
>
>



From mouring at etoh.eviladmin.org  Fri Oct 19 05:14:47 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 18 Oct 2001 14:14:47 -0500 (CDT)
Subject: Again: bugs in contrib/solaris/opensshd.in and buildpkg.sh
In-Reply-To: <B56A3A4C735ED2118F25000083687FBB019D6DA6@MSHNTS04>
Message-ID: <Pine.BSO.4.33.0110181403360.6009-100000@etoh.eviladmin.org>


Sorry to not respond right away.. I had my whole network offline since
Tuesday morning.  Just now starting to get things back together.

On Wed, 17 Oct 2001 j.petersen at msh.de wrote:

> 	(Shame on me: wrong filename in last posting, now here are correct
> diffs)
> in contrib/solaris/ (openssh-SNAP-20011017.tar.gz)
>
> 1) buildpkg.sh makes wrong link for /etc/init.d/opensshd
> 2) /etc/init.d/opensshd has not-working killproc
> 	here my version tested on Solaris 2.4 and 8
> 		 (no pgrep with solaris 2.4, XARGS was undefined, simpler
> syntax)
> J?rg
>
> --- contrib/solaris/buildpkg.sh Fri Oct 12 22:30:53 2001
> +++ contrib/solaris/buildpkg.sh Tue Oct 16 13:53:07 2001
> @@ -40,9 +40,9 @@
>         ../opensshd.in  > $FAKE_ROOT/etc/init.d/opensshd
>  chmod 711 $FAKE_ROOT/etc/init.d/opensshd
>
> -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
> -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
> -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd
> +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
> +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
> +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd
>

Hmm.. Eep.. Your right.  I forgot to verify the init stuff on my test box.

>
> --- contrib/solaris/opensshd.in Fri Oct 12 23:52:39 2001
> +++ contrib/solaris/opensshd.in Wed Oct 17 10:49:00 2001
> @@ -8,6 +8,7 @@
>  EGREP=/usr/bin/egrep
>  KILL=/usr/bin/kill
>  PS=/usr/bin/ps
> +XARGS=/usr/bin/xargs
>
>  prefix=%%openSSHDir%%
>  etcdir=%%configDir%%
> @@ -21,7 +22,7 @@
>  killproc() {
>     _procname=$1
>     _signal=$2
> -   ${PGREP} ${_procname} | ${HEAD} -1 | ${XARGS} -t -I {} ${KILL}
> -${_signal} {}
> +   ${PS} -u root|${AWK} '/'"$_procname"'$/ {print $1}'| ${XARGS} ${KILL}
> -${_signal}
>  }
>
Interesting.. This must have been around for a long time because this
was part of the pre-existing start scripts.  Unless I screwed up in
editing.

Damien, Can you commit the above patch.  It is the correct thing to do.

Thanks.

- Ben



From dwd at bell-labs.com  Fri Oct 19 05:15:57 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Thu, 18 Oct 2001 14:15:57 -0500
Subject: Patch for hanging ssh-add under Solaris CDE
Message-ID: <20011018141557.A5160@lucent.com>

One of my users found that the new ssh-add, from the portable OpenSSH CVS
as of October 12, was hanging in his .profile while trying to start up CDE
(Common Desktop Environment) on Solaris 2.6.  The previous one, which was
from OpenSSH 2.9p2, did not hang.  It turns out that CDE, at least on
Solaris 2.6, 7 and 8, runs the user's .profile with a special startup shell
that allocates a pseudo-tty (I assume so people can use "stty" to set their
preferred settings) but is not attached to anything that can actually
accept user input.   Those of you with Solaris can reproduce with

    DTSOURCEPROFILE=true /usr/dt/bin/sdt_shell -c ssh-add

I discovered that the problem was that the new readpassphrase() function is
flushing (that is, discarding) the terminal input but the old function
cli_read_passphrase() did not.  When input is not flushed, then ssh-add
gets an immediate end of file and exits.  When the input is flushed, a 
subsequent read from stdin hangs.  I see by truss that sdt_shell is actually
write an end-of-file character (^D) to the pseudo-tty, and apparently that
results in a single zero-length read on the other side if it isn't flushed.

You may wonder why the user was calling ssh-add from his .profile; it's
because after CDE comes up the user runs an xterm (dtterm actually) with
"-C -ls", which means a console window running as a login shell, which
executes .profile again, and he goes to that console window to type in his
passphrase.  And actually the user was not following the documented way of
using CDE, in that a comment in ~/.dtprofile says that anything which is
going to result in reading from the user is supposed to be surrounded by a

    if [ ! "$DT" ]; then 
	... read data ...
    fi

On the other hand, the old ssh-add used to work and the new one doesn't
so it may cause problems for more people.

A patch to go back to the old way is attached in case it is wanted.  You
might think that because readpassphrase() usually turns off echoing, that
flushing the input is a good idea.  If that's desired, I suggest either
adding another flag or using the existing RPP_REQUIRE_TTY flag and using
_T_FLUSH only if that is set.  That flag is not set for ssh-add, but it is
set for other things.

- Dave Dykstra


--- openbsd-compat/readpassphrase.c.O	Fri Oct 12 17:12:22 2001
+++ openbsd-compat/readpassphrase.c	Thu Oct 18 13:59:25 2001
@@ -36,12 +36,6 @@
 #include <termios.h>
 #include <readpassphrase.h>
 
-#ifdef TCSASOFT
-# define _T_FLUSH	(TCSAFLUSH|TCSASOFT)
-#else
-# define _T_FLUSH	(TCSAFLUSH)
-#endif
-
 char *
 readpassphrase(prompt, buf, bufsiz, flags)
 	const char *prompt;
@@ -102,13 +96,13 @@
 			term.c_cc[VSTATUS] = _POSIX_VDISABLE;
 		}
 #endif
-		(void)tcsetattr(input, _T_FLUSH, &term);
+		(void)tcsetattr(input, TCSANOW, &term);
 	}
 	if (!(flags & RPP_ECHO_ON)) {
 		if (tcgetattr(input, &term) == 0 && (term.c_lflag & ECHO)) {
 			echo = 1;
 			term.c_lflag &= ~ECHO;
-			(void)tcsetattr(input, _T_FLUSH, &term);
+			(void)tcsetattr(input, TCSANOW, &term);
 		}
 	}
 
@@ -141,7 +135,7 @@
 		if (status != _POSIX_VDISABLE)
 			term.c_cc[VSTATUS] = status;
 #endif
-		(void)tcsetattr(input, _T_FLUSH, &term);
+		(void)tcsetattr(input, TCSANOW, &term);
 	}
 	(void)sigprocmask(SIG_SETMASK, &oset, NULL);
 	if (input != STDIN_FILENO)


From qralston+ml.openssh-unix-dev at andrew.cmu.edu  Fri Oct 19 06:45:13 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Thu, 18 Oct 2001 16:45:13 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
Message-ID: <Pine.LNX.4.33.0110181644260.32328-100000@pcmy.sei.cmu.edu>

I don't like to be the bearer of bad news, but...

In light of the big "ssh hangs on logout" thread (wherein the true
culprit was identified as being programs that don't close inherited
file descriptors), I find it somewhat ironic that one of those "broken
daemon" programs that doesn't close its open fds is sshd.  :(

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

(At least it shouldn't be too difficult to fix...)

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From spaceacademy at hotmail.com  Fri Oct 19 07:54:33 2001
From: spaceacademy at hotmail.com (s c o t t)
Date: Thu, 18 Oct 2001 14:54:33 -0700
Subject: Incorrect return types for snprintf() and vsnprintf()
Message-ID: <F141jPkQTGpaoG1VRIj0000c594@hotmail.com>

Both of these functions are using strlen() to create return value.

Cheers,
Scott Rankin

*** /openbsd-compat/bsd-snprintf.c.orig	Thu Oct 18 13:57:51 2001
--- /openbsd-compat/bsd-snprintf.c	Thu Oct 18 13:58:26 2001
***************
*** 632,638 ****
  #endif /* !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) */

  #ifndef HAVE_VSNPRINTF
! int
  vsnprintf(char *str, size_t count, const char *fmt, va_list args)
  {
  	str[0] = 0;
--- 632,638 ----
  #endif /* !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) */

  #ifndef HAVE_VSNPRINTF
! size_t
  vsnprintf(char *str, size_t count, const char *fmt, va_list args)
  {
  	str[0] = 0;
***************
*** 643,649 ****
  #endif /* !HAVE_VSNPRINTF */

  #ifndef HAVE_SNPRINTF
! int
  snprintf(char *str,size_t count,const char *fmt,...)
  {
  	va_list ap;
--- 643,649 ----
  #endif /* !HAVE_VSNPRINTF */

  #ifndef HAVE_SNPRINTF
! size_t
  snprintf(char *str,size_t count,const char *fmt,...)
  {
  	va_list ap;

*** /openbsd-compat/bsd-snprintf.h.orig	Thu Oct 18 14:00:08 2001
--- /openbsd-compat/bsd-snprintf.h	Thu Oct 18 14:00:35 2001
***************
*** 8,18 ****
  #include <sys/types.h> /* For size_t */

  #ifndef HAVE_SNPRINTF
! int snprintf(char *str, size_t count, const char *fmt, ...);
  #endif /* !HAVE_SNPRINTF */

  #ifndef HAVE_VSNPRINTF
! int vsnprintf(char *str, size_t count, const char *fmt, va_list args);
  #endif /* !HAVE_SNPRINTF */


--- 8,18 ----
  #include <sys/types.h> /* For size_t */

  #ifndef HAVE_SNPRINTF
! size_t snprintf(char *str, size_t count, const char *fmt, ...);
  #endif /* !HAVE_SNPRINTF */

  #ifndef HAVE_VSNPRINTF
! size_t vsnprintf(char *str, size_t count, const char *fmt, va_list args);
  #endif /* !HAVE_SNPRINTF */


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From mjt at tls.msk.ru  Fri Oct 19 12:30:34 2001
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Fri, 19 Oct 2001 06:30:34 +0400
Subject: Again: bugs in contrib/solaris/opensshd.in and buildpkg.sh
References: <Pine.BSO.4.33.0110181403360.6009-100000@etoh.eviladmin.org>
Message-ID: <3BCF904A.95857433@tls.msk.ru>

mouring at etoh.eviladmin.org wrote:
> 
> On Wed, 17 Oct 2001 j.petersen at msh.de wrote:
[]
> > --- contrib/solaris/buildpkg.sh Fri Oct 12 22:30:53 2001
> > +++ contrib/solaris/buildpkg.sh Tue Oct 16 13:53:07 2001
[]
> > -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
> > -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
> > -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd
> > +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
> > +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
> > +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd

That better should be:
     ln -s ../init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
           ^^
this is common practice and Sun people follows it carefully: no
absolute symlinks, only relative ones whenever possible (and the
startup scripts are *good* example where relative symlinks should
be used).  That is to allow mounting root filesystem on another
machine and have all links to point to the right place.  Well, a
minor issue.

> Hmm.. Eep.. Your right.  I forgot to verify the init stuff on my test box.
[]
> Damien, Can you commit the above patch.  It is the correct thing to do.

Regards,
 Michael.


From rayl at otii.com  Fri Oct 19 12:48:00 2001
From: rayl at otii.com (Ray Lehtiniemi)
Date: Thu, 18 Oct 2001 20:48:00 -0600
Subject: cross compiling openssh?
Message-ID: <20011018204800.B8518@otii.com>


hi folks

just wondering what's the official position on cross compiling openssh.  it's
not supported now AFAICT, and i didn;t see much history on the topic in the list
archives.

is cross compilation support planned anytime soon?  if not, what's involved
(technically or otherwise) in making it happen?


thanks

-- 
---------------------------------------------------------------------------
    Ray Lehtiniemi <rayl at mail.com> <rayl at otii.com>


From markus at openbsd.org  Fri Oct 19 18:10:13 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 19 Oct 2001 10:10:13 +0200
Subject: cross compiling openssh?
In-Reply-To: <20011018204800.B8518@otii.com>; from rayl@otii.com on Thu, Oct 18, 2001 at 08:48:00PM -0600
References: <20011018204800.B8518@otii.com>
Message-ID: <20011019101013.A28569@faui02.informatik.uni-erlangen.de>

On Thu, Oct 18, 2001 at 08:48:00PM -0600, Ray Lehtiniemi wrote:
> is cross compilation support planned anytime soon?  if not, what's involved
> (technically or otherwise) in making it happen?

just do it.


From rayl at otii.com  Fri Oct 19 19:12:10 2001
From: rayl at otii.com (Ray Lehtiniemi)
Date: Fri, 19 Oct 2001 03:12:10 -0600
Subject: cross compiling openssh?
In-Reply-To: <20011019101013.A28569@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Fri, Oct 19, 2001 at 10:10:13AM +0200
References: <20011018204800.B8518@otii.com> <20011019101013.A28569@faui02.informatik.uni-erlangen.de>
Message-ID: <20011019031210.D8518@otii.com>

On Fri, Oct 19, 2001 at 10:10:13AM +0200, Markus Friedl wrote:
> On Thu, Oct 18, 2001 at 08:48:00PM -0600, Ray Lehtiniemi wrote:
> > is cross compilation support planned anytime soon?  if not, what's involved
> > (technically or otherwise) in making it happen?
> 
> just do it.

ok, so no issues except just getting it done, then.

some more details on my setup.  i am prototyping a cirrus cs89712 (arm720
based) embedded system using a CDB89712 eval board with:

  - gcc-2.95.3
  - linux-2.4-ac-rmk
  - uClibc-cvs



i grabbed openssh-2.9.9p2.tar.gz, fudged the configure.in AC_TRY_RUN issues and
glossed over a few uClibc issues.  this resulted in an executable that will, in
theory, at least run.  i'll test it out tomorrow or monday, when i again have access
to the devel board.



some questions:

  - is cross-compilation considered a "core development effort" or a "portability
    development effort"?  in other words, which cvs tree am i working against?

  - i found the openbsd style(9) guide.  is there a cross-compilation guide?  are
    there any particularly good examples of cross-compile autoconfigury that i
    should be emulating?

  - is uClibc considered secure?  how "good" will my sshd be if compiled against
    uClibc?



thanks

-- 
---------------------------------------------------------------------------
    Ray Lehtiniemi <rayl at mail.com> <rayl at otii.com>


From ed at UDel.Edu  Fri Oct 19 22:53:56 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 19 Oct 2001 08:53:56 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.LNX.4.33.0110181644260.32328-100000@pcmy.sei.cmu.edu>
Message-ID: <Pine.SOL.4.30.0110190853010.15337-100000@mahler.udel.edu>

On Thu, 18 Oct 2001, James Ralston wrote:

> Date: Thu, 18 Oct 2001 16:45:13 -0400 (EDT)
> From: James Ralston <qralston+ml.openssh-unix-dev at andrew.cmu.edu>
> To: openssh-unix-dev at mindrot.org
> Subject: sshd fails to close open file descriptors when forking
>
> I don't like to be the bearer of bad news, but...
>
> In light of the big "ssh hangs on logout" thread (wherein the true
> culprit was identified as being programs that don't close inherited
> file descriptors), I find it somewhat ironic that one of those "broken
> daemon" programs that doesn't close its open fds is sshd.  :(
>
> http://bugzilla.mindrot.org/show_bug.cgi?id=3
>
> (At least it shouldn't be too difficult to fix...)

So how exactly does sshd exit without closing it's (inherited or other)
file descriptors?

;-)

	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  Sat Oct 20 00:07:25 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 19 Oct 2001 09:07:25 -0500 (CDT)
Subject: cross compiling openssh?
In-Reply-To: <20011019031210.D8518@otii.com>
Message-ID: <Pine.BSO.4.33.0110190902140.22581-100000@etoh.eviladmin.org>


[..]
>
> some questions:
>
>   - is cross-compilation considered a "core development effort" or a "portability
>     development effort"?  in other words, which cvs tree am i working against?
>
It is part of portable effort.  We have never directly supported
cross-compilation because no one has undertaken such a task.  If you want
to help us in that respect great.

>   - i found the openbsd style(9) guide.  is there a cross-compilation guide?  are
>     there any particularly good examples of cross-compile autoconfigury that i
>     should be emulating?
>
autoconf documentation I assume would be your best bet.  I'm not an
autoconf person (as many know already on this list =).

>   - is uClibc considered secure?  how "good" will my sshd be if compiled against
>     uClibc?
>

<shrug> Security is in the beholder of the source.  I'd be more worried
about correctness of implementation when it comes to a libc.

- Ben



From rjk at terraraq.org.uk  Sat Oct 20 00:44:37 2001
From: rjk at terraraq.org.uk (Richard Kettlewell)
Date: 19 Oct 2001 15:44:37 +0100
Subject: Incorrect return types for snprintf() and vsnprintf()
In-Reply-To: "s c o t t"'s message of "Thu, 18 Oct 2001 22:05:07 GMT"
References: <F141jPkQTGpaoG1VRIj0000c594@hotmail.com>
Message-ID: <84itdb3d0q.fsf@rjk.greenend.org.uk>

"s c o t t" <spaceacademy at hotmail.com> writes:

> Both of these functions are using strlen() to create return value.

This patch would make the -compat versions incompatible with the
standard versions of [v]snprintf, which return int (and in particular,
return -1 to signal certain errors).

ttfn/rjk
-- 
http://www.greenend.org.uk/rjk/


From belg4mit at MIT.EDU  Sat Oct 20 06:08:53 2001
From: belg4mit at MIT.EDU (Jerrad Pierce)
Date: Fri, 19 Oct 2001 16:08:53 -0400
Subject: OpenSSH2.9.9p2 fails to configure
Message-ID: <3BD08855.19FA8F88@mit.edu>

I just installed OpenSSL 0.9.6b to the default /usr/local/ssl

And am using:

./configure --with-pam --with-skey=/usr/local/skey --with-tcp-wrappers

Now whether or not I supply --with-ssl-dir or modify the cofig script or
set CFLAGS I still get:

#... other defaults here
configure:4481: gcc -o conftest -L/usr/local/lib -L/usr/local/ssl/lib
-Wall -Wp\
ointer-arith -Wno-uninitialized -I/usr/local/ssl/include 
-I/usr/local/skey/inc\
lude -L/usr/local/ssl/lib  -L/usr/local/skey/lib conftest.c -lpam -ldl
-lwrap -\
lskey -lz -lnsl  -lutil -lcrypto 1>&5
configure: failed program was:
#line 4467 "configure"
#include "confdefs.h"

#include <string.h>
#include <openssl/rand.h>
int main(void)
{
        char a[2048];
        memset(a, 0, sizeof(a));
        RAND_add(a, sizeof(a), sizeof(a));
        return(RAND_status() <= 0);
}
#... other defaults here

SSL works fine (using it for webmin). 

Any ideas? (I did check the list archives but nothing meaningful was
there)


From belg4mit at MIT.EDU  Sat Oct 20 06:17:16 2001
From: belg4mit at MIT.EDU (Jerrad Pierce)
Date: Fri, 19 Oct 2001 16:17:16 -0400
Subject: OpenSSH2.9.9p2 fails to configure
References: <3BD08855.19FA8F88@mit.edu>
Message-ID: <3BD08A4C.B137DD69@mit.edu>

Sorry about that, needed an ldconfig (I had done that several times
already before... :-/)


From mouring at etoh.eviladmin.org  Sat Oct 20 06:39:52 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 19 Oct 2001 15:39:52 -0500 (CDT)
Subject: Again: bugs in contrib/solaris/opensshd.in and buildpkg.sh
In-Reply-To: <B56A3A4C735ED2118F25000083687FBB019D6DA6@MSHNTS04>
Message-ID: <Pine.BSO.4.33.0110191538340.8969-100000@etoh.eviladmin.org>


I just fixed this and missing piddir up in the latest CVS tree (just
commited it now).

I also put in the README file that did not take the first time around.

I was unable to test the changes, but I'll try it on Monday if I have
time..

- Ben

On Wed, 17 Oct 2001 j.petersen at msh.de wrote:

> 	(Shame on me: wrong filename in last posting, now here are correct
> diffs)
> in contrib/solaris/ (openssh-SNAP-20011017.tar.gz)
>
> 1) buildpkg.sh makes wrong link for /etc/init.d/opensshd
> 2) /etc/init.d/opensshd has not-working killproc
> 	here my version tested on Solaris 2.4 and 8
> 		 (no pgrep with solaris 2.4, XARGS was undefined, simpler
> syntax)
> J?rg
>
> --- contrib/solaris/buildpkg.sh Fri Oct 12 22:30:53 2001
> +++ contrib/solaris/buildpkg.sh Tue Oct 16 13:53:07 2001
> @@ -40,9 +40,9 @@
>         ../opensshd.in  > $FAKE_ROOT/etc/init.d/opensshd
>  chmod 711 $FAKE_ROOT/etc/init.d/opensshd
>
> -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
> -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
> -ln -s $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd
> +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd
> +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd
> +ln -s /etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd
>
>
> --- contrib/solaris/opensshd.in Fri Oct 12 23:52:39 2001
> +++ contrib/solaris/opensshd.in Wed Oct 17 10:49:00 2001
> @@ -8,6 +8,7 @@
>  EGREP=/usr/bin/egrep
>  KILL=/usr/bin/kill
>  PS=/usr/bin/ps
> +XARGS=/usr/bin/xargs
>
>  prefix=%%openSSHDir%%
>  etcdir=%%configDir%%
> @@ -21,7 +22,7 @@
>  killproc() {
>     _procname=$1
>     _signal=$2
> -   ${PGREP} ${_procname} | ${HEAD} -1 | ${XARGS} -t -I {} ${KILL}
> -${_signal} {}
> +   ${PS} -u root|${AWK} '/'"$_procname"'$/ {print $1}'| ${XARGS} ${KILL}
> -${_signal}
>  }
>
> ___________________________________________
> Dr. J?rg Petersen <j.petersen at msh.de>
> Medien System Haus    Tel. 0711/72007-424
> Plieninger Str. 150,  D-70567 Stuttgart
>



From mouring at etoh.eviladmin.org  Sat Oct 20 06:41:47 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 19 Oct 2001 15:41:47 -0500 (CDT)
Subject: Incorrect return types for snprintf() and vsnprintf()
In-Reply-To: <F141jPkQTGpaoG1VRIj0000c594@hotmail.com>
Message-ID: <Pine.BSO.4.33.0110191541230.8969-100000@etoh.eviladmin.org>


What platform?  Solaris and Linux return int  even if they use size_t
in their arguments.

- Ben

On Thu, 18 Oct 2001, s c o t t wrote:

> Both of these functions are using strlen() to create return value.
>
> Cheers,
> Scott Rankin
>
> *** /openbsd-compat/bsd-snprintf.c.orig	Thu Oct 18 13:57:51 2001
> --- /openbsd-compat/bsd-snprintf.c	Thu Oct 18 13:58:26 2001
> ***************
> *** 632,638 ****
>   #endif /* !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) */
>
>   #ifndef HAVE_VSNPRINTF
> ! int
>   vsnprintf(char *str, size_t count, const char *fmt, va_list args)
>   {
>   	str[0] = 0;
> --- 632,638 ----
>   #endif /* !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) */
>
>   #ifndef HAVE_VSNPRINTF
> ! size_t
>   vsnprintf(char *str, size_t count, const char *fmt, va_list args)
>   {
>   	str[0] = 0;
> ***************
> *** 643,649 ****
>   #endif /* !HAVE_VSNPRINTF */
>
>   #ifndef HAVE_SNPRINTF
> ! int
>   snprintf(char *str,size_t count,const char *fmt,...)
>   {
>   	va_list ap;
> --- 643,649 ----
>   #endif /* !HAVE_VSNPRINTF */
>
>   #ifndef HAVE_SNPRINTF
> ! size_t
>   snprintf(char *str,size_t count,const char *fmt,...)
>   {
>   	va_list ap;
>
> *** /openbsd-compat/bsd-snprintf.h.orig	Thu Oct 18 14:00:08 2001
> --- /openbsd-compat/bsd-snprintf.h	Thu Oct 18 14:00:35 2001
> ***************
> *** 8,18 ****
>   #include <sys/types.h> /* For size_t */
>
>   #ifndef HAVE_SNPRINTF
> ! int snprintf(char *str, size_t count, const char *fmt, ...);
>   #endif /* !HAVE_SNPRINTF */
>
>   #ifndef HAVE_VSNPRINTF
> ! int vsnprintf(char *str, size_t count, const char *fmt, va_list args);
>   #endif /* !HAVE_SNPRINTF */
>
>
> --- 8,18 ----
>   #include <sys/types.h> /* For size_t */
>
>   #ifndef HAVE_SNPRINTF
> ! size_t snprintf(char *str, size_t count, const char *fmt, ...);
>   #endif /* !HAVE_SNPRINTF */
>
>   #ifndef HAVE_VSNPRINTF
> ! size_t vsnprintf(char *str, size_t count, const char *fmt, va_list args);
>   #endif /* !HAVE_SNPRINTF */
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>



From dwd at bell-labs.com  Sat Oct 20 07:09:28 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 19 Oct 2001 16:09:28 -0500
Subject: program-prefix does not work
In-Reply-To: <3BCCBA90.5020801@ayrnetworks.com>; from chua@ayrnetworks.com on Tue, Oct 16, 2001 at 03:54:08PM -0700
References: <3BCCBA90.5020801@ayrnetworks.com>
Message-ID: <20011019160928.A4866@lucent.com>

On Tue, Oct 16, 2001 at 03:54:08PM -0700, Bryan Chua wrote:
> the configure option --program-prefix does not work although it is 
> listed in the configure --help output.
> 
> The attached patch fixes these issues:
> 1) program prefix is not substituted in configure
> 2) program prefix is not present in Makefile
> 3) scp requires use of a known "scp" program

Won't changing the prefix on #3 cause a problem if you need to
interoperate with other installations that don't have the prefix?
I would think on the wire you'd still need to use "scp" but your sshd
would need to translate that to ${program_prefix}scp.

- Dave Dykstra


From ed at UDel.Edu  Sat Oct 20 07:28:34 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 19 Oct 2001 17:28:34 -0400 (EDT)
Subject: TCP wrappers and 2.9.9p2
Message-ID: <Pine.SOL.4.30.0110191721450.3677-100000@mahler.udel.edu>

I don't know if this is still a problem in the latest snapshot, but with
2.9.9p2, if you do a "./configure ... --with-tcp-wrappers", there's no way
to specify a location for tcpd.h and libwrap.a.  This is troublesome on
Solaris where you might install stuff like that in /opt/lib or
/usr/local/lib or something that is not searched by default.

	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 dwd at bell-labs.com  Sat Oct 20 07:39:36 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 19 Oct 2001 16:39:36 -0500
Subject: Bugzilla for portable OpenSSH
In-Reply-To: <Pine.LNX.4.33.0110181010270.10394-100000@mothra.mindrot.org>; from djm@mindrot.org on Thu, Oct 18, 2001 at 10:15:01AM +1000
References: <Pine.LNX.4.33.0110181010270.10394-100000@mothra.mindrot.org>
Message-ID: <20011019163936.B4866@lucent.com>

On Thu, Oct 18, 2001 at 10:15:01AM +1000, Damien Miller wrote:
> To make it easier for us to track bugs (and reduce the likelihood of 
> patches falling through the cracks), I have set up a bug tracking 
> system using the Mozilla projects Bugzilla software.
> 
> You can access Bugzilla at http://bugzilla.mindrot.org/
> 
> To do anything useful (esp. enter bugs) you will need to create an 
> account. Bugzilla is a little overcomplicated for a small project,
> but it handles everything that we need.
> 
> It would be good if people start using it ASAP, especially for patches.
> 
> If you have any problems, please contact me.

What policy with respect to patches does the team intend to use?

    1. Will you accept patches from both the mailing list and bugzilla?
    2. Will you give preferential treatment to patches coming in from 
	one source or the other?
    3. What about patches for native openssh; should they go to bugzilla
	or the mailing list?
    4. Is this retroactive; that is, must we go back and post all the
	patches we've previously posted to the mailing list if they
	haven't yet been incorporated?

- Dave Dykstra


From chua at ayrnetworks.com  Sat Oct 20 07:57:15 2001
From: chua at ayrnetworks.com (Bryan Chua)
Date: Fri, 19 Oct 2001 14:57:15 -0700
Subject: program-prefix does not work
References: <3BCCBA90.5020801@ayrnetworks.com> <20011019160928.A4866@lucent.com>
Message-ID: <3BD0A1BB.5040600@ayrnetworks.com>

Yes, that is correct -- our sshd does not work without a link from scp 
to ${program-prefix}scp.

I chose to allow sshd to break in this case (scp in from remote) for two 
reasons --
1) there is no clean way to return an exit code while the pipe is open 
without a major re-structuring
2) even if there were a clean way to return a code, it would be more of 
a security hole for sshd to try scp and ${program-prefix}scp in either 
order.

As for scp, I ended up adding a command-line parameter to specify the 
scp program to use on the remote side, -s <scp-program>.  I was not sure 
of how to update the man pages to add the documentation.

-- bryan

Dave Dykstra wrote:

> On Tue, Oct 16, 2001 at 03:54:08PM -0700, Bryan Chua wrote:
> 
>>the configure option --program-prefix does not work although it is 
>>listed in the configure --help output.
>>
>>The attached patch fixes these issues:
>>1) program prefix is not substituted in configure
>>2) program prefix is not present in Makefile
>>3) scp requires use of a known "scp" program
>>
> 
> Won't changing the prefix on #3 cause a problem if you need to
> interoperate with other installations that don't have the prefix?
> I would think on the wire you'd still need to use "scp" but your sshd
> would need to translate that to ${program_prefix}scp.
> 
> - Dave Dykstra
> 
> 





From qralston+ml.openssh-unix-dev at andrew.cmu.edu  Sat Oct 20 08:11:40 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Fri, 19 Oct 2001 18:11:40 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.SOL.4.30.0110190853010.15337-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110191810310.2364-100000@pcmy.sei.cmu.edu>

On Fri, 19 Oct 2001, Ed Phillips wrote:

> On Thu, 18 Oct 2001, James Ralston wrote:
>
> > Date: Thu, 18 Oct 2001 16:45:13 -0400 (EDT)
> > From: James Ralston <qralston+ml.openssh-unix-dev at andrew.cmu.edu>
> > To: openssh-unix-dev at mindrot.org
> > Subject: sshd fails to close open file descriptors when forking
> >
> > I don't like to be the bearer of bad news, but...
> >
> > In light of the big "ssh hangs on logout" thread (wherein the true
> > culprit was identified as being programs that don't close inherited
> > file descriptors), I find it somewhat ironic that one of those "broken
> > daemon" programs that doesn't close its open fds is sshd.  :(
> >
> > http://bugzilla.mindrot.org/show_bug.cgi?id=3
> >
> > (At least it shouldn't be too difficult to fix...)
>
> So how exactly does sshd exit without closing it's (inherited or
> other) file descriptors?  ;-)

I don't understand your question.  Could you rephrase?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From Lutz.Jaenicke at aet.TU-Cottbus.DE  Sat Oct 20 16:15:33 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Sat, 20 Oct 2001 08:15:33 +0200
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.LNX.4.33.0110191810310.2364-100000@pcmy.sei.cmu.edu>
References: <Pine.SOL.4.30.0110190853010.15337-100000@mahler.udel.edu> <Pine.LNX.4.33.0110191810310.2364-100000@pcmy.sei.cmu.edu>
Message-ID: <20011020081533.A24824@serv01.aet.tu-cottbus.de>

On Fri, Oct 19, 2001 at 06:11:40PM -0400, James Ralston wrote:
> On Fri, 19 Oct 2001, Ed Phillips wrote:
> > On Thu, 18 Oct 2001, James Ralston wrote:
> >
> > > Date: Thu, 18 Oct 2001 16:45:13 -0400 (EDT)
> > > From: James Ralston <qralston+ml.openssh-unix-dev at andrew.cmu.edu>
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: sshd fails to close open file descriptors when forking
> > >
> > > I don't like to be the bearer of bad news, but...
> > >
> > > In light of the big "ssh hangs on logout" thread (wherein the true
> > > culprit was identified as being programs that don't close inherited
> > > file descriptors), I find it somewhat ironic that one of those "broken
> > > daemon" programs that doesn't close its open fds is sshd.  :(
> > >
> > > http://bugzilla.mindrot.org/show_bug.cgi?id=3
> > >
> > > (At least it shouldn't be too difficult to fix...)
> >
> > So how exactly does sshd exit without closing it's (inherited or
> > other) file descriptors?  ;-)
> 
> I don't understand your question.  Could you rephrase?

The point is: how do you come to your conclusion?
daemon() calls dup2() for the file descriptors 0, 1, 2 (stdin, stdout, stderr)
and newly assigns them /dev/null. My manual page (HP-UX) says:
      dup2() causes fildes2 to refer to the same file as fildes.  If fildes2
      refers to an already open file, the open file is closed first.
Consequently the open files at 0, 1, 2 are closed.
So without further explanation or evidence I consider your bug report
to be wrong.

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From djm at mindrot.org  Sat Oct 20 18:57:42 2001
From: djm at mindrot.org (Damien Miller)
Date: Sat, 20 Oct 2001 18:57:42 +1000 (EST)
Subject: Bugzilla for portable OpenSSH
In-Reply-To: <20011019163936.B4866@lucent.com>
Message-ID: <Pine.LNX.4.33.0110201851120.1211-100000@mothra.mindrot.org>

On Fri, 19 Oct 2001, Dave Dykstra wrote:

> What policy with respect to patches does the team intend to use?
> 
>     1. Will you accept patches from both the mailing list and bugzilla?

Yes

>     2. Will you give preferential treatment to patches coming in from 
> 	one source or the other?

Only insofar as Bugzilla patches are less likely to "fall through the 
cracks."

>     3. What about patches for native openssh; should they go to bugzilla
> 	or the mailing list?

The right place for OpenBSD OpenSSH patches is OpenBSD GNATS or 
openssh at openssh.com, though the portable developers usually forward or
commit applicable patches anyway (we almost all use OpenBSD too).

>     4. Is this retroactive; that is, must we go back and post all the
> 	patches we've previously posted to the mailing list if they
> 	haven't yet been incorporated?

It would make our lives easier if people did this, but that is no 
edict :)

-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 sam at marrder.com  Sat Oct 20 06:48:35 2001
From: sam at marrder.com (Sergio A. Murillo)
Date: Fri, 19 Oct 2001 15:48:35 -0500
Subject: SSH no Password on Rh 7.1
Message-ID: <000401c158df$6c5eada0$1f64a8c0@hacsc.org>

Markus, did you resolve your RH7.1 ssh with no password problem I'm
having the EXACT problem and don't know what I'm doing wrong..
I will look into the PAM setup.
 
Please let me know if you come up with something. This is driving me
nuts!
 
Thanks  
 
Sergio
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011019/341148dd/attachment.html 

From tim at multitalents.net  Sun Oct 21 02:26:31 2001
From: tim at multitalents.net (Tim Rice)
Date: Sat, 20 Oct 2001 09:26:31 -0700 (PDT)
Subject: TCP wrappers and 2.9.9p2
In-Reply-To: <Pine.SOL.4.30.0110191721450.3677-100000@mahler.udel.edu>
Message-ID: <Pine.UW2.4.40.9.0110200923410.9701-100000@uw711.int.multitalents.net>

On Fri, 19 Oct 2001, Ed Phillips wrote:

> I don't know if this is still a problem in the latest snapshot, but with
> 2.9.9p2, if you do a "./configure ... --with-tcp-wrappers", there's no way
> to specify a location for tcpd.h and libwrap.a.  This is troublesome on
> Solaris where you might install stuff like that in /opt/lib or
> /usr/local/lib or something that is not searched by default.

I'm finishing up some testing on some configure changes that will adderess
thi issue and many others on the list. I should have be ready this weekend.
Stay tuned.

>
> 	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
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net





From pekkas at netcore.fi  Sun Oct 21 06:41:24 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Sat, 20 Oct 2001 23:41:24 +0300 (EEST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots
 for 3.0 release] (fwd)
Message-ID: <Pine.LNX.4.33.0110202340260.10796-200000@netcore.fi>

No response yet, so resending.

-- 
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

---------- Forwarded message ----------
Date: Fri, 12 Oct 2001 09:44:54 +0300 (EEST)
From: Pekka Savola <pekkas at netcore.fi>
To: Damien Miller <djm at mindrot.org>
Cc: openssh-unix-dev at mindrot.org
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
    snapshots for 3.0 release]

On Fri, 12 Oct 2001, Damien Miller wrote:
> Could everyone please test the latest snapshots as we will be making a
> new release soon.
>
> If you have any patches you would like us to consider, please resend
> them to the list ASAP.

1) As sshd -t is used when restarting sshd with RH scripts now, I think
sshd_config is better marked with noreplace as config files should.

2) I'd probably remove '--with-ipv4-default'; it's a major release after
all.  I haven't noticed problems with this, and if you'd have to run 'sshd
-6', IPv4 port forwarding through mapped addresses won't work.

3) Building appears to rely on the existance of rather recent openssl.
This is good from security perspective, but will make building with e.g.
0.9.5a impossible.  If this is intended to be requirement (there _have_
been security fixes), at least Requires:  openssl >= 0.9.6 or whatever
should be added and the requirement noted in the docs.

The build failed on my RHL62 with:

./libssh.a(key.o): In function `write_bignum':
key.o(.text+0x7f7): undefined reference to `OPENSSL_free'

I bet this is an issue that people might complain about.

Build works ok on RHL72 beta w/ openssh 0.9.6b.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
-------------- next part --------------
Index: openssh.spec
===================================================================
RCS file: /cvs/openssh_cvs/contrib/redhat/openssh.spec,v
retrieving revision 1.86
diff -u -r1.86 openssh.spec
--- openssh.spec	2001/09/26 14:24:21	1.86
+++ openssh.spec	2001/09/27 15:51:33
@@ -264,8 +264,7 @@
 %attr(0755,root,root) %{_libexecdir}/openssh/sftp-server
 %attr(0644,root,root) %{_mandir}/man8/sshd.8*
 %attr(0644,root,root) %{_mandir}/man8/sftp-server.8*
-#%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config
-%attr(0600,root,root) %config %{_sysconfdir}/sshd_config
+%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config
 %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd
 %attr(0755,root,root) %config /etc/rc.d/init.d/sshd
 

From Lutz.Jaenicke at aet.TU-Cottbus.DE  Sun Oct 21 19:26:48 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Sun, 21 Oct 2001 11:26:48 +0200
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.LNX.4.33.0110202340260.10796-200000@netcore.fi>
References: <Pine.LNX.4.33.0110202340260.10796-200000@netcore.fi>
Message-ID: <20011021112648.A9749@serv01.aet.tu-cottbus.de>

On Sat, Oct 20, 2001 at 11:41:24PM +0300, Pekka Savola wrote:
> 3) Building appears to rely on the existance of rather recent openssl.
> This is good from security perspective, but will make building with e.g.
> 0.9.5a impossible.  If this is intended to be requirement (there _have_
> been security fixes), at least Requires:  openssl >= 0.9.6 or whatever
> should be added and the requirement noted in the docs.
> 
> The build failed on my RHL62 with:
> 
> ./libssh.a(key.o): In function `write_bignum':
> key.o(.text+0x7f7): undefined reference to `OPENSSL_free'

I just had a look into the source. Since BN_bn2dec() really allocates
the buffer itself (using OPENSSL_malloc() in recent versions), there is
nothing an application writer can do with respect to this inconsistency.
(For all OpenSSL special data types, TYPE_new() and TYPE_free() exist.)
The only thing that could be done is to query the version defined in
opensslv.h and based on that make a #if OPENSSL_VERSION_NUMBER construct.
(The comment on security fixes with respect to OpenSSL 0.9.6 applies,
but the only thing touching OpenSSH would be the PRNG fix, and this one
has been backported by some distributors to older OpenSSL versions in
order to maintain compatibility. And, in fact, OpenSSH was immune to
the PRNG problem anyway.)

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From maf at appgate.com  Mon Oct 22 06:13:40 2001
From: maf at appgate.com (Martin Forssen)
Date: Sun, 21 Oct 2001 22:13:40 +0200 (MEST)
Subject: Converting old F-Secur SSH-keys
Message-ID: <20011021201336.CE6466C007@shala.firedoor.se>

Hi,

I just tries to convert an old ssh2 dsa-key generated by F-Secure SSH in
1998. The problem is that the base64-encoding of this key is bad. They
key works just fine when using F-Secure SSH but openssh will not convert
it.

My question now is if people think it is worth fixing this, and if it is
where should it be fixed? One could either fixed the base64-routines to
be more tolerant, but that only applies to the portable release and I do
not know how it would work on openbsd. The other solution is to have
something which checks the data before decoding it and fixes any
problems, this is more ugly but would work on all platforms. Opinions?

	/MaF



From tim at multitalents.net  Mon Oct 22 11:24:49 2001
From: tim at multitalents.net (Tim Rice)
Date: Sun, 21 Oct 2001 18:24:49 -0700 (PDT)
Subject: configure changes
Message-ID: <Pine.UW2.4.40.9.0110211804210.5753-100000@uw711.int.multitalents.net>


I finally got around to looking at a bunch of patchs to configure.in, some
of them from back in March. One from Carson Gaspar <carson at taltos.org> looked
promissing at first glance but after many hours I just couldn't get it to
work.

Due to much demand, I have added optional PATH to --with-pcre,
--with-zlib, and --with-tcp-wrappers.

I have done extensive testin on --with-zlib, and --with-tcp-wrappers.
Please test --with-pcre. (I don't use it here)

I have added a test for broken dirname() on Solaris 2.5.1 by
Dan Astoorian <djast at cs.toronto.edu>. Dan please test.

I've added a better socklen_t test by albert chin (china at thewrittenword.com)
(This is cool. Thanks Albert)
Do a tail on config.h after running configure and make sure it does
the right thing on your platform.

The changes are in CVS now. A new SNAP should show up shortly.

These changes were tested on the following platforms
SCO Open Server 3	w/gcc
SCO Open Server 5.0.4	w/ native compilers
SCO Open Server 5.0.6	w/ gcc
UnixWare 2.03		w/ native compilers
UnixWare 2.1.3		w/ native compilers
UnixWare 7.1.1		w/ native compilers
Solaris 7		w/gcc
Solaris 8		w/gcc
RedHat 6.2
Caldera eDesktop 2.4
Caldera eServer 2.3.1
Caldera OpenLinux Workstation 3.1
Caldera OpenLinux Server 3.1

Let me know if there are any problems with the changes.
(I expect things will be fine on other platforms as well)

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net






From pedwards at disaster.jaj.com  Mon Oct 22 16:14:57 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Mon, 22 Oct 2001 02:14:57 -0400
Subject: ssh-keygen can't recognize its own keys?
Message-ID: <20011022021457.A11474@disaster.jaj.com>

I'm trying to move from SSH1 to OpenSSH 2.9.9p2, under Solaris 8.  Initial
setup and testing seems to work...  including the generation of a new
RSA key.  The key was created with "ssh-keygen -t rsa" and a passphrase;
nothing unusual.

I can SSH between machines, both running 2.9.9p2, and debug messages show
that this file is being correctly read (I think).  It prompts me for the
passphrase, and all is well.

But ssh-keygen can't list the fingerprints of the key it just created:

    % ssh-keygen -l -f ~/.ssh/id_rsa 
    /[...long path elided...]/.ssh/id_rsa is not a valid key file.
    % 

Huh?  I can use "ssh-keygen -y" on this same file, and after entering the
passphrase, the public key is correctly printed.  What's up?


Please cc me on replies; subscribing is going badly for me for other reasons.

Much thanks for any tips,
Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From bugzilla-daemon at mindrot.org  Mon Oct 22 16:29:42 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon, 22 Oct 2001 16:29:42 +1000 (EST)
Subject: [Bug 7] New: Yet another test bug
Message-ID: <20011022062942.A61BE2DF0E@shitei.mindrot.org>

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

           Summary: Yet another test bug
           Product: Portable OpenSSH
           Version: -current
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Miscellaneous
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: djm at mindrot.org


Testing 1..2...3..



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


From djm at mindrot.org  Mon Oct 22 16:33:53 2001
From: djm at mindrot.org (Damien Miller)
Date: Mon, 22 Oct 2001 16:33:53 +1000 (EST)
Subject: [Bug 7] New: Yet another test bug
In-Reply-To: <20011022062942.A61BE2DF0E@shitei.mindrot.org>
Message-ID: <Pine.LNX.4.33.0110221632280.1939-100000@mothra.mindrot.org>

On Mon, 22 Oct 2001 bugzilla-daemon at mindrot.org wrote:

Bug reports made by bugzilla will now appear on this list. Hopefully I
can figure out the correct Bugzilla voodoo to keep the noise level 
down to just significant changes (bug created, bug deleted, patch added,
etc).

-d

> http://bugzilla.mindrot.org/show_bug.cgi?id=7
> 
>            Summary: Yet another test bug
>            Product: Portable OpenSSH
>            Version: -current
>           Platform: Other
>         OS/Version: other
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: Miscellaneous
>         AssignedTo: openssh-unix-dev at mindrot.org
>         ReportedBy: djm at mindrot.org
> 
> 
> Testing 1..2...3..
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> 

-- 
| 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 Alexander.Dost at drkw.com  Mon Oct 22 17:51:47 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Mon, 22 Oct 2001 09:51:47 +0200
Subject: expired password problems with 2.9.9p2/Solaris8
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BBE9@ibfftc0006.is.de.dresdnerkb.com>

I encounterd some odd problems with OpenSSH 2.9.9p2 compiled with
--tcp-wrappers --with-pam and using the PAM_TTY_KLUDGE. The kludge is needed
to get the password expiration check running.
OS is Solaris8, PAM uses standard Solaris file pam_unix.so (I also tried
extra lines for sshd in the config file).
When asked to change the password the text now entered is not hidden on the
screen (first problem).
Second problem: Changing does not work at all. The following error is
written:

Waring: Your password has expired, please change it now
Enter login password: hans1234
removing root credentials would break the rpc services that
use secure rpc on this host!
root may use keylogout -f to do this (at your own risk)!
Connection to <host> closed by remote host.
Connection to <host> closed.

When trying the same on a machine using nisplus for password checking,
everything works fine.

- Alex


From ed at UDel.Edu  Mon Oct 22 23:36:19 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 09:36:19 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <20011020081533.A24824@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.SOL.4.30.0110220926360.5586-100000@mahler.udel.edu>

On Sat, 20 Oct 2001, Lutz Jaenicke wrote:

> Date: Sat, 20 Oct 2001 08:15:33 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: sshd fails to close open file descriptors when forking
>
> On Fri, Oct 19, 2001 at 06:11:40PM -0400, James Ralston wrote:
> > On Fri, 19 Oct 2001, Ed Phillips wrote:
> > > On Thu, 18 Oct 2001, James Ralston wrote:
> > >
> > > > Date: Thu, 18 Oct 2001 16:45:13 -0400 (EDT)
> > > > From: James Ralston <qralston+ml.openssh-unix-dev at andrew.cmu.edu>
> > > > To: openssh-unix-dev at mindrot.org
> > > > Subject: sshd fails to close open file descriptors when forking
> > > >
> > > > I don't like to be the bearer of bad news, but...
> > > >
> > > > In light of the big "ssh hangs on logout" thread (wherein the true
> > > > culprit was identified as being programs that don't close inherited
> > > > file descriptors), I find it somewhat ironic that one of those "broken
> > > > daemon" programs that doesn't close its open fds is sshd.  :(
> > > >
> > > > http://bugzilla.mindrot.org/show_bug.cgi?id=3
> > > >
> > > > (At least it shouldn't be too difficult to fix...)
> > >
> > > So how exactly does sshd exit without closing it's (inherited or
> > > other) file descriptors?  ;-)
> >
> > I don't understand your question.  Could you rephrase?
>
> The point is: how do you come to your conclusion?
> daemon() calls dup2() for the file descriptors 0, 1, 2 (stdin, stdout, stderr)
> and newly assigns them /dev/null. My manual page (HP-UX) says:
>       dup2() causes fildes2 to refer to the same file as fildes.  If fildes2
>       refers to an already open file, the open file is closed first.
> Consequently the open files at 0, 1, 2 are closed.
> So without further explanation or evidence I consider your bug report
> to be wrong.

Actually, my point was, when sshd exits (calls exit() or whatever), no
matter what file descriptors are open, they'll all get closed as the
actual process exits.  (But even so, ssh on the other end still hangs...
potentially depending on which version of ssh you're running...)

	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 Lutz.Jaenicke at aet.TU-Cottbus.DE  Mon Oct 22 23:46:22 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Mon, 22 Oct 2001 15:46:22 +0200
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.SOL.4.30.0110220926360.5586-100000@mahler.udel.edu>
References: <20011020081533.A24824@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110220926360.5586-100000@mahler.udel.edu>
Message-ID: <20011022154622.A17252@ws01.aet.tu-cottbus.de>

On Mon, Oct 22, 2001 at 09:36:19AM -0400, Ed Phillips wrote:
> On Sat, 20 Oct 2001, Lutz Jaenicke wrote:
> > The point is: how do you come to your conclusion?
> > daemon() calls dup2() for the file descriptors 0, 1, 2 (stdin, stdout, stderr)
> > and newly assigns them /dev/null. My manual page (HP-UX) says:
> >       dup2() causes fildes2 to refer to the same file as fildes.  If fildes2
> >       refers to an already open file, the open file is closed first.
> > Consequently the open files at 0, 1, 2 are closed.
> > So without further explanation or evidence I consider your bug report
> > to be wrong.
> 
> Actually, my point was, when sshd exits (calls exit() or whatever), no
> matter what file descriptors are open, they'll all get closed as the
> actual process exits.  (But even so, ssh on the other end still hangs...
> potentially depending on which version of ssh you're running...)

I still don't get your point. When sshd exits, all of its file descriptors
are being closed (meaning: they are closed with respect to the exiting
process). If a process has forked and the forked process has the
same file descriptors open, they are still open from the system's point
of view. So what?

Best,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From markus at openbsd.org  Mon Oct 22 18:40:41 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 22 Oct 2001 10:40:41 +0200
Subject: ssh-keygen can't recognize its own keys?
In-Reply-To: <20011022021457.A11474@disaster.jaj.com>; from pedwards@disaster.jaj.com on Mon, Oct 22, 2001 at 02:14:57AM -0400
References: <20011022021457.A11474@disaster.jaj.com>
Message-ID: <20011022104041.B24963@faui02.informatik.uni-erlangen.de>

fingerprinting works only for public key files.

try
	ssh-keygen -l -f ~/.ssh/id_rsa.pub
	

On Mon, Oct 22, 2001 at 02:14:57AM -0400, Phil Edwards wrote:
> I'm trying to move from SSH1 to OpenSSH 2.9.9p2, under Solaris 8.  Initial
> setup and testing seems to work...  including the generation of a new
> RSA key.  The key was created with "ssh-keygen -t rsa" and a passphrase;
> nothing unusual.
> 
> I can SSH between machines, both running 2.9.9p2, and debug messages show
> that this file is being correctly read (I think).  It prompts me for the
> passphrase, and all is well.
> 
> But ssh-keygen can't list the fingerprints of the key it just created:
> 
>     % ssh-keygen -l -f ~/.ssh/id_rsa 
>     /[...long path elided...]/.ssh/id_rsa is not a valid key file.
>     % 
> 
> Huh?  I can use "ssh-keygen -y" on this same file, and after entering the
> passphrase, the public key is correctly printed.  What's up?
> 
> 
> Please cc me on replies; subscribing is going badly for me for other reasons.
> 
> Much thanks for any tips,
> Phil
> 
> -- 
> If ye love wealth greater than liberty, the tranquility of servitude greater
> than the animating contest for freedom, go home and leave us in peace.  We seek
> not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
> and may posterity forget that ye were our countrymen.            - Samuel Adams


From ed at UDel.Edu  Tue Oct 23 01:03:26 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 11:03:26 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <20011022154622.A17252@ws01.aet.tu-cottbus.de>
Message-ID: <Pine.SOL.4.30.0110221055170.7286-100000@mahler.udel.edu>

On Mon, 22 Oct 2001, Lutz Jaenicke wrote:

> Date: Mon, 22 Oct 2001 15:46:22 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: sshd fails to close open file descriptors when forking
>
> On Mon, Oct 22, 2001 at 09:36:19AM -0400, Ed Phillips wrote:
> > On Sat, 20 Oct 2001, Lutz Jaenicke wrote:
> > > The point is: how do you come to your conclusion?
> > > daemon() calls dup2() for the file descriptors 0, 1, 2 (stdin, stdout, stderr)
> > > and newly assigns them /dev/null. My manual page (HP-UX) says:
> > >       dup2() causes fildes2 to refer to the same file as fildes.  If fildes2
> > >       refers to an already open file, the open file is closed first.
> > > Consequently the open files at 0, 1, 2 are closed.
> > > So without further explanation or evidence I consider your bug report
> > > to be wrong.
> >
> > Actually, my point was, when sshd exits (calls exit() or whatever), no
> > matter what file descriptors are open, they'll all get closed as the
> > actual process exits.  (But even so, ssh on the other end still hangs...
> > potentially depending on which version of ssh you're running...)
>
> I still don't get your point. When sshd exits, all of its file descriptors
> are being closed (meaning: they are closed with respect to the exiting
> process). If a process has forked and the forked process has the
> same file descriptors open, they are still open from the system's point
> of view. So what?

But the child processes don't have the _same_ file descriptors open, do
they?  I thought they had a pipe(s) back to the sshd for protocol
encoding/decoding.  Regardless, all the children need to exit _before_
sshd exits, and when they do, all of the file descriptors will be closed.
When sshd exits, there should be no open file descriptors, right?  (And if
sshd exits when there is a process that has a file descriptor open that is
a "connection" back to the ssh client, then that's a bug, right?) Am I
missing some key point here?  It seems simple... ;-)

	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  Mon Oct 22 18:52:36 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 22 Oct 2001 10:52:36 +0200
Subject: Converting old F-Secur SSH-keys
In-Reply-To: <20011021201336.CE6466C007@shala.firedoor.se>; from maf@appgate.com on Sun, Oct 21, 2001 at 10:13:40PM +0200
References: <20011021201336.CE6466C007@shala.firedoor.se>
Message-ID: <20011022105236.A17612@folly>

On Sun, Oct 21, 2001 at 10:13:40PM +0200, Martin Forssen wrote:
> I just tries to convert an old ssh2 dsa-key generated by F-Secure SSH in
> 1998. The problem is that the base64-encoding of this key is bad.

what exactly?

could i get the key for my test suite?

> They
> key works just fine when using F-Secure SSH but openssh will not convert
> it.
> 
> My question now is if people think it is worth fixing this, and if it is
> where should it be fixed? One could either fixed the base64-routines to
> be more tolerant, but that only applies to the portable release and I do
> not know how it would work on openbsd. The other solution is to have
> something which checks the data before decoding it and fixes any
> problems, this is more ugly but would work on all platforms. Opinions?

since openssh 'should' use the base64 API of the platform, i think
the checking at the higher level should be preferred.


From Lutz.Jaenicke at aet.TU-Cottbus.DE  Tue Oct 23 01:22:46 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Mon, 22 Oct 2001 17:22:46 +0200
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.SOL.4.30.0110221055170.7286-100000@mahler.udel.edu>
References: <20011022154622.A17252@ws01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110221055170.7286-100000@mahler.udel.edu>
Message-ID: <20011022172246.A17513@serv01.aet.tu-cottbus.de>

On Mon, Oct 22, 2001 at 11:03:26AM -0400, Ed Phillips wrote:
> But the child processes don't have the _same_ file descriptors open, do
> they?  I thought they had a pipe(s) back to the sshd for protocol
> encoding/decoding.  Regardless, all the children need to exit _before_
> sshd exits, and when they do, all of the file descriptors will be closed.
> When sshd exits, there should be no open file descriptors, right?  (And if
> sshd exits when there is a process that has a file descriptor open that is
> a "connection" back to the ssh client, then that's a bug, right?) Am I
> missing some key point here?  It seems simple... ;-)
 
We are talking different issues here.
* sshd daemonizes on startup. In this case it forks and the child process
  (to become the actual server) closes its fds for stdin, stdout, stderr.
* When a new connection comes in, a sshd child process is created, that
  itself will fork()/exec() the user process, normally a shell.
  There are file descriptors for the network connection (channel) and for the
  user process. Typically the 3 default file descriptors for stdin, stdout,
  stderr are open between sshd and user process, but there may be more
  open files when X11 connections or port forwarding is used.
* When the user process dies, it closes all of its file descriptors.
  sshd notes this closure and also closes all file descriptors. On the
  network side the connection is however not simply closed, but a
  handshake specified in the SSH protocol is performed to have the
  encrypted _channel_ closed down before the underlying network
  connection is closed. Then sshd can exit().
  The often experienced "hang on exit()" problem is caused by processes
  started from the main user process. If at shell level a process is
  started with, say "sleep 20000 &", the sleep process may not close
  its file descriptors (stdin, stdout, stderr), which are identical to
  the shell's descriptors. Even when the shell now exits, sleep keeps the
  file descriptors open and therefore the handling sshd process thinks,
  that data may still be exchanged and does not shut down. 
  (Of course, sleep won't exchange data, but there may be other more important
  processes be backgrounded.)

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From pedwards at disaster.jaj.com  Tue Oct 23 02:00:00 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Mon, 22 Oct 2001 12:00:00 -0400
Subject: ssh-keygen can't recognize its own keys?
In-Reply-To: <20011022104041.B24963@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Mon, Oct 22, 2001 at 10:40:41AM +0200
References: <20011022021457.A11474@disaster.jaj.com> <20011022104041.B24963@faui02.informatik.uni-erlangen.de>
Message-ID: <20011022120000.A12814@disaster.jaj.com>

On Mon, Oct 22, 2001 at 10:40:41AM +0200, Markus Friedl wrote:
> fingerprinting works only for public key files.
> 
> try
> 	ssh-keygen -l -f ~/.ssh/id_rsa.pub

Aha!  Works like a charm.  This means I need to send a bug report to the
author of the program that tries to fingerprint the private key....

Thanks again,
Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From ed at UDel.Edu  Tue Oct 23 03:04:52 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 13:04:52 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <20011022172246.A17513@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.SOL.4.30.0110221255300.14936-100000@mahler.udel.edu>

On Mon, 22 Oct 2001, Lutz Jaenicke wrote:

> Date: Mon, 22 Oct 2001 17:22:46 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: sshd fails to close open file descriptors when forking
>
> On Mon, Oct 22, 2001 at 11:03:26AM -0400, Ed Phillips wrote:
> > But the child processes don't have the _same_ file descriptors open, do
> > they?  I thought they had a pipe(s) back to the sshd for protocol
> > encoding/decoding.  Regardless, all the children need to exit _before_
> > sshd exits, and when they do, all of the file descriptors will be closed.
> > When sshd exits, there should be no open file descriptors, right?  (And if
> > sshd exits when there is a process that has a file descriptor open that is
> > a "connection" back to the ssh client, then that's a bug, right?) Am I
> > missing some key point here?  It seems simple... ;-)
>
> We are talking different issues here.
> * sshd daemonizes on startup. In this case it forks and the child process
>   (to become the actual server) closes its fds for stdin, stdout, stderr.
> * When a new connection comes in, a sshd child process is created, that
>   itself will fork()/exec() the user process, normally a shell.
>   There are file descriptors for the network connection (channel) and for the
>   user process. Typically the 3 default file descriptors for stdin, stdout,
>   stderr are open between sshd and user process, but there may be more
>   open files when X11 connections or port forwarding is used.
> * When the user process dies, it closes all of its file descriptors.
>   sshd notes this closure and also closes all file descriptors. On the
>   network side the connection is however not simply closed, but a
>   handshake specified in the SSH protocol is performed to have the
>   encrypted _channel_ closed down before the underlying network
>   connection is closed. Then sshd can exit().

Okay... that makes sense.

>   The often experienced "hang on exit()" problem is caused by processes
>   started from the main user process. If at shell level a process is
>   started with, say "sleep 20000 &", the sleep process may not close
>   its file descriptors (stdin, stdout, stderr), which are identical to
>   the shell's descriptors. Even when the shell now exits, sleep keeps the
>   file descriptors open and therefore the handling sshd process thinks,
>   that data may still be exchanged and does not shut down.
>   (Of course, sleep won't exchange data, but there may be other more important
>   processes be backgrounded.)

The problem I see is that there _are_ no background processes and no file
descriptors left open (there aren't even any processes running on the sshd
side)... but still, ssh hangs on the client side - even though there are
no sockets left on the server side.  Maybe this is a problem with the
protocol implementation in v2.9p2, or maybe it's a problem where ssh
doesn't "know" that the file descriptors are gone (TCP sockets without
keep-alive, client doesn't realize that the count of valid file
descriptors is < 1, etc.).

Hopefully, I'll be able to tell if this is fixed in v2.9.9p2... sometime
today...

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 Oct 23 03:48:25 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 22 Oct 2001 19:48:25 +0200
Subject: ssh-keygen can't recognize its own keys?
In-Reply-To: <20011022120000.A12814@disaster.jaj.com>; from pedwards@disaster.jaj.com on Mon, Oct 22, 2001 at 12:00:00PM -0400
References: <20011022021457.A11474@disaster.jaj.com> <20011022104041.B24963@faui02.informatik.uni-erlangen.de> <20011022120000.A12814@disaster.jaj.com>
Message-ID: <20011022194825.B22318@faui02.informatik.uni-erlangen.de>

On Mon, Oct 22, 2001 at 12:00:00PM -0400, Phil Edwards wrote:
> On Mon, Oct 22, 2001 at 10:40:41AM +0200, Markus Friedl wrote:
> > fingerprinting works only for public key files.
> > 
> > try
> > 	ssh-keygen -l -f ~/.ssh/id_rsa.pub
> 
> Aha!  Works like a charm.  This means I need to send a bug report to the
> author of the program that tries to fingerprint the private key....

ssh-keygen tries to find the matching public key if you give
a private key on the command line.

-m


From ed at UDel.Edu  Tue Oct 23 04:35:35 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 14:35:35 -0400 (EDT)
Subject: sshd dumps core in pam_sm_open_session
Message-ID: <Pine.SOL.4.30.0110221422290.18653-100000@mahler.udel.edu>

(I vaguely remember talk about PAM session stuff recently... please excuse
me if this is the same problem.)

I compiled v2.9.9p2 on Solaris 8 with the following configuration and the
Sun Workshop v5 compiler:

OpenSSH has been configured with the following options:
                 User binaries: /opt/openssh-2.9.9p2/bin
               System binaries: /opt/openssh-2.9.9p2/sbin
           Configuration files: /opt/openssh-2.9.9p2/etc
               Askpass program: /opt/openssh-2.9.9p2/libexec/ssh-askpass
                  Manual pages: /opt/openssh-2.9.9p2/man/manX
                      PID file: /var/run
        sshd default user PATH:
/usr/bin:/bin:/usr/sbin:/sbin:/opt/openssh-2.9.9
p2/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/opt/openssl-0.9.6b/include -I. -I/usr/local/include
      Linker flags: -R/opt/openssl-0.9.6b/lib -L/opt/openssl-0.9.6b/lib
-L. -lwr
ap -L/usr/local/lib -R/usr/local/lib
         Libraries: -lpam -ldl -lwrap -lz -lsocket -lnsl  -lgen -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.

The system is not actually set up to use PAM for sshd specifically (does
that really matter?).

sshd seems to work okay if I just do an interactive session, but if I use
scp or try to run a command, it dumps core.

Here's the traceback for sshd:

(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
=>[1] strncpy(0xffbee4cc, 0x5, 0x7, 0x0, 0x21aa4, 0xffbee4cc), at 0xff133abc
  [2] pam_sm_open_session(0x6, 0x0, 0x70a10, 0x0, 0xff0f6000, 0x0), at 0xff0d61d8
  [3] pam_open_session(0xff3865c8, 0x0, 0xff386000, 0x13, 0x13, 0x0), at 0xff372c50
  [4] do_pam_session(0x147338, 0x0, 0x6, 0x2, 0x1, 0xffbeee44), at 0x34ac0
  [5] do_exec_no_pty(0x13b364, 0x14cc80, 0xffbeef00, 0x0, 0x0, 0xffbeef23), at 0x3e5d0
  [6] do_exec(0x13b364, 0x14cc80, 0xffbeef70, 0xffffffff, 0xfffffff8, 0xffbeef04), at 0x3edcc
  [7] 0x4183c(0x13b364, 0x10ec54, 0x0, 0x0, 0x6f6e00, 0x0), at 0x4183b
  [8] session_input_channel_req(0x0, 0x0, 0x0, 0x4, 0xeb, 0x145918), at 0x41ac8
  [9] channel_input_channel_request(0x62, 0x19, 0x145498, 0x0, 0x0, 0x0), at 0x4e9a0
  [10] dispatch_run(0x1, 0x0, 0x145498, 0x147348, 0x21a54, 0x3bb78), at 0x53790
  [11] 0x3c2c4(0x147348, 0x147348, 0xffbef160, 0xffbef158, 0x0, 0x0), at 0x3c2c3
  [12] server_loop2(0x1456a8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x3cc54
  [13] 0x4284c(0x1456a8, 0x0, 0x0, 0x0, 0x21b6c, 0x3de34), at 0x4284b
  [14] do_authenticated(0x1456a8, 0x1456a8, 0x1456a8, 0x80, 0x8, 0x5e27c), at 0x3de90
  [15] do_authentication2(0x109df0, 0x8, 0xd144, 0x8, 0x2152c, 0x2c38c), at 0x2eef0
  [16] main(0x3, 0xffbefc34, 0xffbefc44, 0x12cc00, 0x0, 0x0), at 0x2c404

Please let me know if you need more info.

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 Oct 23 04:38:30 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 22 Oct 2001 20:38:30 +0200
Subject: sshd dumps core in pam_sm_open_session
In-Reply-To: <Pine.SOL.4.30.0110221422290.18653-100000@mahler.udel.edu>; from ed@UDel.Edu on Mon, Oct 22, 2001 at 02:35:35PM -0400
References: <Pine.SOL.4.30.0110221422290.18653-100000@mahler.udel.edu>
Message-ID: <20011022203830.A24578@faui02.informatik.uni-erlangen.de>

On Mon, Oct 22, 2001 at 02:35:35PM -0400, Ed Phillips wrote:
> (I vaguely remember talk about PAM session stuff recently... please excuse
> me if this is the same problem.)

it is.


From ed at UDel.Edu  Tue Oct 23 04:45:01 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 14:45:01 -0400 (EDT)
Subject: sshd dumps core in pam_sm_open_session
In-Reply-To: <20011022203830.A24578@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.SOL.4.30.0110221444460.19623-100000@mahler.udel.edu>

On Mon, 22 Oct 2001, Markus Friedl wrote:

> Date: Mon, 22 Oct 2001 20:38:30 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: sshd dumps core in pam_sm_open_session
>
> On Mon, Oct 22, 2001 at 02:35:35PM -0400, Ed Phillips wrote:
> > (I vaguely remember talk about PAM session stuff recently... please excuse
> > me if this is the same problem.)
>
> it is.

Is there a patch for 2.9.9p2 that fixes this problem?

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 bugzilla-daemon at mindrot.org  Tue Oct 23 05:18:53 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 23 Oct 2001 05:18:53 +1000 (EST)
Subject: [Bug 3] sshd fails to close open file descriptors when forking
Message-ID: <20011022191853.53FC72DF09@shitei.mindrot.org>

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

markus at openbsd.org changed:

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



------- Additional Comments From markus at openbsd.org  2001-10-23 05:18 -------
daemon() works fine. the hang-on-exit is about fd 0,1,2



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


From Nicolas.Williams at ubsw.com  Tue Oct 23 05:30:43 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 22 Oct 2001 15:30:43 -0400
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.SOL.4.30.0110221255300.14936-100000@mahler.udel.edu>; from ed@UDel.Edu on Mon, Oct 22, 2001 at 01:04:52PM -0400
References: <20011022172246.A17513@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110221255300.14936-100000@mahler.udel.edu>
Message-ID: <20011022153042.X5739@sm2p1386swk.wdr.com>

This is the SIGCHLD race condition that's been hashed to death already.

Nico


On Mon, Oct 22, 2001 at 01:04:52PM -0400, Ed Phillips wrote:
> On Mon, 22 Oct 2001, Lutz Jaenicke wrote:
> 
> > Date: Mon, 22 Oct 2001 17:22:46 +0200
> > From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: sshd fails to close open file descriptors when forking
> >
> > On Mon, Oct 22, 2001 at 11:03:26AM -0400, Ed Phillips wrote:
> > > But the child processes don't have the _same_ file descriptors open, do
> > > they?  I thought they had a pipe(s) back to the sshd for protocol
> > > encoding/decoding.  Regardless, all the children need to exit _before_
> > > sshd exits, and when they do, all of the file descriptors will be closed.
> > > When sshd exits, there should be no open file descriptors, right?  (And if
> > > sshd exits when there is a process that has a file descriptor open that is
> > > a "connection" back to the ssh client, then that's a bug, right?) Am I
> > > missing some key point here?  It seems simple... ;-)
> >
> > We are talking different issues here.
> > * sshd daemonizes on startup. In this case it forks and the child process
> >   (to become the actual server) closes its fds for stdin, stdout, stderr.
> > * When a new connection comes in, a sshd child process is created, that
> >   itself will fork()/exec() the user process, normally a shell.
> >   There are file descriptors for the network connection (channel) and for the
> >   user process. Typically the 3 default file descriptors for stdin, stdout,
> >   stderr are open between sshd and user process, but there may be more
> >   open files when X11 connections or port forwarding is used.
> > * When the user process dies, it closes all of its file descriptors.
> >   sshd notes this closure and also closes all file descriptors. On the
> >   network side the connection is however not simply closed, but a
> >   handshake specified in the SSH protocol is performed to have the
> >   encrypted _channel_ closed down before the underlying network
> >   connection is closed. Then sshd can exit().
> 
> Okay... that makes sense.
> 
> >   The often experienced "hang on exit()" problem is caused by processes
> >   started from the main user process. If at shell level a process is
> >   started with, say "sleep 20000 &", the sleep process may not close
> >   its file descriptors (stdin, stdout, stderr), which are identical to
> >   the shell's descriptors. Even when the shell now exits, sleep keeps the
> >   file descriptors open and therefore the handling sshd process thinks,
> >   that data may still be exchanged and does not shut down.
> >   (Of course, sleep won't exchange data, but there may be other more important
> >   processes be backgrounded.)
> 
> The problem I see is that there _are_ no background processes and no file
> descriptors left open (there aren't even any processes running on the sshd
> side)... but still, ssh hangs on the client side - even though there are
> no sockets left on the server side.  Maybe this is a problem with the
> protocol implementation in v2.9p2, or maybe it's a problem where ssh
> doesn't "know" that the file descriptors are gone (TCP sockets without
> keep-alive, client doesn't realize that the count of valid file
> descriptors is < 1, etc.).
> 
> Hopefully, I'll be able to tell if this is fixed in v2.9.9p2... sometime
> today...
> 
> 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
--

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 ed at UDel.Edu  Tue Oct 23 05:47:21 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 15:47:21 -0400 (EDT)
Subject: sshd fails to close open file descriptors when forking
In-Reply-To: <20011022153042.X5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.SOL.4.30.0110221534001.21420-100000@mahler.udel.edu>

On Mon, 22 Oct 2001, Nicolas Williams wrote:

> Date: Mon, 22 Oct 2001 15:30:43 -0400
> From: Nicolas Williams <Nicolas.Williams at ubsw.com>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>,
>      openssh-unix-dev at mindrot.org
> Subject: Re: sshd fails to close open file descriptors when forking
>
> This is the SIGCHLD race condition that's been hashed to death already.

Okay... so what is the status of hang-on-exit-SIGCHLD-race-condition?  Is
it fixed in 2.9.9p2?  Noone has given me a "clear" answer on this ("I
think that might be fixed in 2.9.9p2" is not exactly a clear answer in my
book).

I've tried 2.9.9p2 and it doesn't seem to hang for a normal interactive
shell (yet - but then 2.9p2 didn't _usually_ hang when exiting an
interactive shell except occasionally).  However, I can't test something
like:

ssh -n sys1 xterm

... because sshd 2.9.9p2 crashes in the PAM code.

Sorry to "hash this to death", but we still don't have a solution here
that works reliably in our very simple environment.  I just want some
version 2.X that works reliably (no abandoned ssh processes left lying
around), doesn't have glaring security holes (are there any 2.X version to
watch out for?), and will work with PAM and TCP Wrappers on Solaris 2.6
thru Solaris 9.  Also, it'd be nice if it was compatible with later
versions that are already released or are currently being worked.  For
example, I heard some mention on this list about putting the stuff from
"authorized_keys2" or "known_hosts2" or one of the v2-named files being
put into the v1-named file... each one of these little "changes" makes
potential problems here for thousands of users on our campus.

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 bugzilla-daemon at mindrot.org  Tue Oct 23 05:48:04 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 23 Oct 2001 05:48:04 +1000 (EST)
Subject: [Bug 3] sshd fails to close open file descriptors when forking
Message-ID: <20011022194804.CC4DF2DF09@shitei.mindrot.org>

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

ralston at pobox.com changed:

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



------- Additional Comments From ralston at pobox.com  2001-10-23 05:48 -------
It doesn't matter whether or not daemon() or some other helper function does it,
but sshd MUST close all fds from 3 to sysconf(_SC_OPEN_MAX) after forking.

If the hang-on-exit bug is with fds 0/1/2, then indeed, this bug isn't related
to the hang-on-exit bug.  But it's still a bug.




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


From ed at UDel.Edu  Tue Oct 23 05:59:08 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Oct 2001 15:59:08 -0400 (EDT)
Subject: [Bug 3] sshd fails to close open file descriptors when forking
In-Reply-To: <20011022194804.CC4DF2DF09@shitei.mindrot.org>
Message-ID: <Pine.SOL.4.30.0110221555530.22617-100000@mahler.udel.edu>

This is a nice example of why I'm so confused about what's going on with
my "ssh hangs on exit"  problem... there seem to be at least two similar
problems occurring here, and it's not clear which one mine is, and which
one(s) is(are) fixed or not.

Sincerely,

	Ed

On Tue, 23 Oct 2001 bugzilla-daemon at mindrot.org wrote:

> Date: Tue, 23 Oct 2001 05:48:04 +1000 (EST)
> From: bugzilla-daemon at mindrot.org
> To: openssh-unix-dev at mindrot.org
> Subject: [Bug 3] sshd fails to close open file descriptors when forking
>
> http://bugzilla.mindrot.org/show_bug.cgi?id=3
>
> ralston at pobox.com changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|INVALID                     |
>
>
>
> ------- Additional Comments From ralston at pobox.com  2001-10-23 05:48 -------
> It doesn't matter whether or not daemon() or some other helper function does it,
> but sshd MUST close all fds from 3 to sysconf(_SC_OPEN_MAX) after forking.
>
> If the hang-on-exit bug is with fds 0/1/2, then indeed, this bug isn't related
> to the hang-on-exit bug.  But it's still a bug.
>
>
>
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>

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 VBrimhall at novell.com  Tue Oct 23 06:29:33 2001
From: VBrimhall at novell.com (Vince Brimhall)
Date: Mon, 22 Oct 2001 14:29:33 -0600
Subject: OpenSSH port to NetWare 6
Message-ID: <sbd42d52.032@prv-mail20.provo.novell.com>

I'm a software developer at Novell.  I have been tasked with porting OpenSSH to the NetWare 6.0 OS.  I would like to include my NetWare specific changes,#ifdef'd of course, in the portable releases at some point.  Whom should I contact with regard to this?  And are there any guidlines I can look at online to minimize any disturbance this may cause to other platforms?
 
Any assistance that can be provided would be appreciated.
 
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vince Brimhall
Senior Software Engineer
Server Communications
801.861.1724
vbrimhall at novell.com
 
Novell, Inc., the leading provider of Net services software.
www.novell.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011022/3dd125a6/attachment.html 

From bugzilla-daemon at mindrot.org  Tue Oct 23 06:34:10 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 23 Oct 2001 06:34:10 +1000 (EST)
Subject: [Bug 3] sshd fails to close open file descriptors when forking
Message-ID: <20011022203410.BD2072DF1E@shitei.mindrot.org>

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

markus at openbsd.org changed:

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



------- Additional Comments From markus at openbsd.org  2001-10-23 06:34 -------
daemons call daemon(), they do not care about filedescriptors > 3.
btw, i was just told that cat(1) does not close extra filedescriptors,
and i don't think there are more important issues.



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


From openssh-unix-dev at thewrittenword.com  Tue Oct 23 09:41:59 2001
From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com)
Date: Mon, 22 Oct 2001 18:41:59 -0500
Subject: OpenSSH port to NetWare 6
In-Reply-To: <sbd42d52.032@prv-mail20.provo.novell.com>; from VBrimhall@novell.com on Mon, Oct 22, 2001 at 02:29:33PM -0600
References: <sbd42d52.032@prv-mail20.provo.novell.com>
Message-ID: <20011022184159.F73829@oolong.il.thewrittenword.com>

On Mon, Oct 22, 2001 at 02:29:33PM -0600, Vince Brimhall wrote:
> I'm a software developer at Novell.  I have been tasked with porting
> OpenSSH to the NetWare 6.0 OS.  I would like to include my NetWare
> specific changes,#ifdef'd of course, in the portable releases at
> some point.  Whom should I contact with regard to this?  And are
> there any guidlines I can look at online to minimize any disturbance
> this may cause to other platforms?

Are your changes #ifdef NOVELL or, hopefully, #ifdef FEATURE in the
autoconf way of doing things, where FEATURE is determined by
configure.in?

-- 
albert chin (china at thewrittenword.com)


From bugzilla-daemon at mindrot.org  Tue Oct 23 10:06:10 2001
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 23 Oct 2001 10:06:10 +1000 (EST)
Subject: [Bug 7] Yet another test bug
Message-ID: <20011023000610.9A1B22DF07@shitei.mindrot.org>

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

djm at mindrot.org changed:

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



------- Additional Comments From djm at mindrot.org  2001-10-23 10:06 -------
Close test bug



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


From qralston+ml.openssh-unix-dev at andrew.cmu.edu  Tue Oct 23 13:29:04 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Mon, 22 Oct 2001 23:29:04 -0400 (EDT)
Subject: [Bug 3] sshd fails to close open file descriptors when forking
In-Reply-To: <Pine.SOL.4.30.0110221555530.22617-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110222309070.6616-100000@shieldbreaker.l33tskillz.org>

On Mon, 22 Oct 2001, Ed Phillips wrote:
> This is a nice example of why I'm so confused about what's going on
> with my "ssh hangs on exit" problem... there seem to be at least two
> similar problems occurring here, and it's not clear which one mine
> is, and which one(s) is(are) fixed or not.

The "hang on exit" problem is a completely different issue.

The bug I am reporting has to do with the actions the sshd program
takes when it is first started (before it even starts listening for
incoming client connections).  Essentially, sshd doesn't daemonizing
itself properly.

I'll clarify tomorrow, when I have my [Stevens] on hand, and can quote
specific sections for Markus.

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From alex at pfts.com  Tue Oct 23 18:30:14 2001
From: alex at pfts.com (Alexander Ignatyev)
Date: Tue, 23 Oct 2001 11:30:14 +0300
Subject: Compilation error on Solaris Workshop 6 (+patch)
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAcnNqxVhPfEWEYz0VN6JRd8KAAAAQAAAArN+P6PnCwEWTjXXF7ZrwbAEAAAAA@pfts.com>

Hi!

At compilation of the openssh-2.9.9p2 with Solaris WorkShop 6.01 the
following compilation error was given out.  

/opt/SUNWspro/bin/cc -Xa -xF -xCC -xildoff -xarch=v9 -xchip=ultra
-dalign -I/usr/include/v9 -D_REENTRANT -xO2 -I. -I.
-I/usr/local/include -DETCDIR=\"/etc/ssh\"
-D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/sbin/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/local/sbin/sftp-server\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c session.c
"session.c", line 628: identifier redeclared: do_pre_login
        current : static function(pointer to struct Session {int used,
int self, pointer to struct passwd {..} pw, pointer to struct Authctxt
{..} authctxt, int pid, pointer to char term, int ptyfd, int ttyfd, int
ptymaster, int row, int col, int xpixel, int ypixel, array[64] of char
tty, pointer to char display, int screen, pointer to char auth_proto,
pointer to char auth_data, int single_connection, int chanid, int
is_subsystem}) returning void
        previous: function() returning int : "session.c", line 581
cc: acomp failed for session.c
*** Error code 2
make: Fatal error: Command failed for target `session.o'


To correct a compilation error it is necessary to make the following
changes (just define function do_pre_login):
================================== %<
===================================================
--- session.c-orig  Tue Oct 23 11:13:06 2001
+++ session.c-patched   Tue Oct 23 11:19:54 2001
@@ -132,6 +132,9 @@
 void   do_child(Session *, const char *);
 void   do_motd(void);
 int    check_quietlogin(Session *, const char *);
+#ifdef LOGIN_NEEDS_UTMPX
+static void do_pre_login(Session *s);
+#endif

 static void do_authenticated1(Authctxt *);
 static void do_authenticated2(Authctxt *);
================================== %<
===================================================

WBR,
Alexander Ignatyev
AI-RIPE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3197 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011023/401f75d7/attachment.bin 

From bsd at openbsd.rutgers.edu  Wed Oct 24 00:05:27 2001
From: bsd at openbsd.rutgers.edu (William Yodlowsky)
Date: Tue, 23 Oct 2001 10:05:27 -0400
Subject: PAM problem - sshd segfault on Solaris
In-Reply-To: <20011019170419.J27698@andromeda.rutgers.edu>; from wyodlows@andromeda.rutgers.edu on Fri, Oct 19, 2001 at 05:04:19PM -0400
References: <20011019170419.J27698@andromeda.rutgers.edu>
Message-ID: <20011023100527.A6251@openbsd.rutgers.edu>

I'm using OpenSSH-2.9.9p2 on Solaris 8 sparc64.  2.9p2 worked fine, but
2.9.9p2+ is giving me trouble with one thing - sshd segfaults if I try to
connect and execute a command, such as "ssh machine ls".  Otherwise it
works great.  sshd will fork, and the child process segfaults.

CVS snapshot does the same thing.

I've narrowed this down somewhat.  It will only happen if you use
./configure --with-pam (see below).

Output from "gdb ./sshd" and "run -p 2022 -d -d -d" (IP obscured):

...
Failed none for wyodlows from a.b.c.d port 45214 ssh2
debug1: userauth-request for user wyodlows service ssh-connection method password
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method password
debug1: PAM Password authentication accepted for user "wyodlows"
Accepted password for wyodlows from a.b.c.d port 45214 ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug2: callback start
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request exec reply 0

Program received signal SIGSEGV, Segmentation fault.
0xff133a9c in strncpy () from /usr/lib/libc.so.1
(gdb) bt
#0  0xff133a9c in strncpy () from /usr/lib/libc.so.1
#1  0xff0b61b0 in pam_sm_open_session () from /usr/lib/security/pam_unix.so.1
#2  0xff372b88 in pam_open_session () from /usr/lib/libpam.so.1
#3  0x2cc88 in do_pam_session (username=0x115fb0 "wyodlows", ttyname=0x0)
    at auth-pam.c:283
#4  0x32360 in do_exec_no_pty (s=0x1108ac, command=0x121950 "ls")
    at session.c:433
#5  0x32884 in do_exec (s=0x1108ac, command=0x121950 "ls") at session.c:668
#6  0x34008 in session_exec_req (s=0x1108ac) at session.c:1742
#7  0x3417c in session_input_channel_req (id=0, arg=0x0) at session.c:1795
#8  0x3a040 in channel_input_channel_request (type=98, plen=19, ctxt=0x116898)
    at channels.c:1974
#9  0x3cae0 in dispatch_run (mode=1, done=0x0, ctxt=0x116898) at dispatch.c:71
#10 0x30e1c in process_buffered_input_packets () at serverloop.c:423
#11 0x314b8 in server_loop2 (authctxt=0xffbef408) at serverloop.c:705
#12 0x348d8 in do_authenticated2 (authctxt=0x1170f0) at session.c:2063
#13 0x31eb4 in do_authenticated (authctxt=0x1170f0) at session.c:199
#14 0x29c68 in do_authentication2 () at auth2.c:134
#15 0x280d4 in main (ac=6, av=0x8) at sshd.c:1204


I do not claim to know what the correct fix is, however I can avoid
the segfault by removing the do_pam_session() call.  This is how the
same code looks in 2.9p2 (which doesn't segfault).

I'll happily provide any information needed to help fix this.  Thanks.


--- openssh/session.c.orig	Mon Oct 22 22:42:46 2001
+++ openssh/session.c	Mon Oct 22 22:43:31 2001
@@ -430,7 +430,7 @@ do_exec_no_pty(Session *s, const char *c
 	session_proctitle(s);
 
 #if defined(USE_PAM)
-	do_pam_session(s->pw->pw_name, NULL);
+/*	do_pam_session(s->pw->pw_name, NULL);		*/
 	do_pam_setcred(1);
 #endif /* USE_PAM */
 


From ed at UDel.Edu  Wed Oct 24 00:05:44 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 10:05:44 -0400 (EDT)
Subject: Compilation error on Solaris Workshop 6 (+patch)
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAcnNqxVhPfEWEYz0VN6JRd8KAAAAQAAAArN+P6PnCwEWTjXXF7ZrwbAEAAAAA@pfts.com>
Message-ID: <Pine.SOL.4.30.0110231004250.28226-100000@mahler.udel.edu>

By the way, I had reported this sometime last week but I guess noone's
tracking it on Bugzilla... or maybe it's already fixed in the lastest CVS
snapshots...

On Tue, 23 Oct 2001, Alexander Ignatyev wrote:

> Date: Tue, 23 Oct 2001 11:30:14 +0300
> From: Alexander Ignatyev <alex at pfts.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Compilation error on Solaris Workshop 6 (+patch)
>
> Hi!
>
> At compilation of the openssh-2.9.9p2 with Solaris WorkShop 6.01 the
> following compilation error was given out.
>
> /opt/SUNWspro/bin/cc -Xa -xF -xCC -xildoff -xarch=v9 -xchip=ultra
> -dalign -I/usr/include/v9 -D_REENTRANT -xO2 -I. -I.
> -I/usr/local/include -DETCDIR=\"/etc/ssh\"
> -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
> -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/sbin/ssh-askpass\"
> -D_PATH_SFTP_SERVER=\"/usr/local/sbin/sftp-server\"
> -D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c session.c
> "session.c", line 628: identifier redeclared: do_pre_login
>         current : static function(pointer to struct Session {int used,
> int self, pointer to struct passwd {..} pw, pointer to struct Authctxt
> {..} authctxt, int pid, pointer to char term, int ptyfd, int ttyfd, int
> ptymaster, int row, int col, int xpixel, int ypixel, array[64] of char
> tty, pointer to char display, int screen, pointer to char auth_proto,
> pointer to char auth_data, int single_connection, int chanid, int
> is_subsystem}) returning void
>         previous: function() returning int : "session.c", line 581
> cc: acomp failed for session.c
> *** Error code 2
> make: Fatal error: Command failed for target `session.o'
>
>
> To correct a compilation error it is necessary to make the following
> changes (just define function do_pre_login):
> ================================== %<
> ===================================================
> --- session.c-orig  Tue Oct 23 11:13:06 2001
> +++ session.c-patched   Tue Oct 23 11:19:54 2001
> @@ -132,6 +132,9 @@
>  void   do_child(Session *, const char *);
>  void   do_motd(void);
>  int    check_quietlogin(Session *, const char *);
> +#ifdef LOGIN_NEEDS_UTMPX
> +static void do_pre_login(Session *s);
> +#endif
>
>  static void do_authenticated1(Authctxt *);
>  static void do_authenticated2(Authctxt *);
> ================================== %<
> ===================================================
>
> WBR,
> Alexander Ignatyev
> AI-RIPE
>

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  Wed Oct 24 00:32:49 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 10:32:49 -0400 (EDT)
Subject: PAM problem - sshd segfault on Solaris
In-Reply-To: <20011023100527.A6251@openbsd.rutgers.edu>
Message-ID: <Pine.SOL.4.30.0110231032160.28226-100000@mahler.udel.edu>

I think this might be the same bug I reported yesterday (and someone
reported before me) - it seems to be some sort of problem in the PAM
related code.

	Ed

On Tue, 23 Oct 2001, William Yodlowsky wrote:

> Date: Tue, 23 Oct 2001 10:05:27 -0400
> From: William Yodlowsky <bsd at openbsd.rutgers.edu>
> To: openssh-unix-dev at mindrot.org
> Subject: PAM problem - sshd segfault on Solaris
>
> I'm using OpenSSH-2.9.9p2 on Solaris 8 sparc64.  2.9p2 worked fine, but
> 2.9.9p2+ is giving me trouble with one thing - sshd segfaults if I try to
> connect and execute a command, such as "ssh machine ls".  Otherwise it
> works great.  sshd will fork, and the child process segfaults.
>
> CVS snapshot does the same thing.
>
> I've narrowed this down somewhat.  It will only happen if you use
> ./configure --with-pam (see below).
>
> Output from "gdb ./sshd" and "run -p 2022 -d -d -d" (IP obscured):
>
> ...
> Failed none for wyodlows from a.b.c.d port 45214 ssh2
> debug1: userauth-request for user wyodlows service ssh-connection method password
> debug1: attempt 1 failures 1
> debug2: input_userauth_request: try method password
> debug1: PAM Password authentication accepted for user "wyodlows"
> Accepted password for wyodlows from a.b.c.d port 45214 ssh2
> debug1: Entering interactive session for SSH2.
> debug1: server_init_dispatch_20
> debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768
> debug1: input_session_request
> debug1: channel 0: new [server-session]
> debug1: session_new: init
> debug1: session_new: session 0
> debug1: session_open: channel 0
> debug1: session_open: session 0: link with channel 0
> debug1: server_input_channel_open: confirm session
> debug2: callback start
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 channel 0 request exec reply 0
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xff133a9c in strncpy () from /usr/lib/libc.so.1
> (gdb) bt
> #0  0xff133a9c in strncpy () from /usr/lib/libc.so.1
> #1  0xff0b61b0 in pam_sm_open_session () from /usr/lib/security/pam_unix.so.1
> #2  0xff372b88 in pam_open_session () from /usr/lib/libpam.so.1
> #3  0x2cc88 in do_pam_session (username=0x115fb0 "wyodlows", ttyname=0x0)
>     at auth-pam.c:283
> #4  0x32360 in do_exec_no_pty (s=0x1108ac, command=0x121950 "ls")
>     at session.c:433
> #5  0x32884 in do_exec (s=0x1108ac, command=0x121950 "ls") at session.c:668
> #6  0x34008 in session_exec_req (s=0x1108ac) at session.c:1742
> #7  0x3417c in session_input_channel_req (id=0, arg=0x0) at session.c:1795
> #8  0x3a040 in channel_input_channel_request (type=98, plen=19, ctxt=0x116898)
>     at channels.c:1974
> #9  0x3cae0 in dispatch_run (mode=1, done=0x0, ctxt=0x116898) at dispatch.c:71
> #10 0x30e1c in process_buffered_input_packets () at serverloop.c:423
> #11 0x314b8 in server_loop2 (authctxt=0xffbef408) at serverloop.c:705
> #12 0x348d8 in do_authenticated2 (authctxt=0x1170f0) at session.c:2063
> #13 0x31eb4 in do_authenticated (authctxt=0x1170f0) at session.c:199
> #14 0x29c68 in do_authentication2 () at auth2.c:134
> #15 0x280d4 in main (ac=6, av=0x8) at sshd.c:1204
>
>
> I do not claim to know what the correct fix is, however I can avoid
> the segfault by removing the do_pam_session() call.  This is how the
> same code looks in 2.9p2 (which doesn't segfault).
>
> I'll happily provide any information needed to help fix this.  Thanks.
>
>
> --- openssh/session.c.orig	Mon Oct 22 22:42:46 2001
> +++ openssh/session.c	Mon Oct 22 22:43:31 2001
> @@ -430,7 +430,7 @@ do_exec_no_pty(Session *s, const char *c
>  	session_proctitle(s);
>
>  #if defined(USE_PAM)
> -	do_pam_session(s->pw->pw_name, NULL);
> +/*	do_pam_session(s->pw->pw_name, NULL);		*/
>  	do_pam_setcred(1);
>  #endif /* USE_PAM */
>
>

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  Wed Oct 24 00:35:25 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 23 Oct 2001 09:35:25 -0500 (CDT)
Subject: Compilation error on Solaris Workshop 6 (+patch)
In-Reply-To: <Pine.SOL.4.30.0110231004250.28226-100000@mahler.udel.edu>
Message-ID: <Pine.BSO.4.33.0110230935000.21704-100000@etoh.eviladmin.org>


It has been fixed in the latest CVS tree about a week or two after 2.9.9
release.

- Ben

On Tue, 23 Oct 2001, Ed Phillips wrote:

> By the way, I had reported this sometime last week but I guess noone's
> tracking it on Bugzilla... or maybe it's already fixed in the lastest CVS
> snapshots...
>
> On Tue, 23 Oct 2001, Alexander Ignatyev wrote:
>
> > Date: Tue, 23 Oct 2001 11:30:14 +0300
> > From: Alexander Ignatyev <alex at pfts.com>
> > To: openssh-unix-dev at mindrot.org
> > Subject: Compilation error on Solaris Workshop 6 (+patch)
> >
> > Hi!
> >
> > At compilation of the openssh-2.9.9p2 with Solaris WorkShop 6.01 the
> > following compilation error was given out.
> >
> > /opt/SUNWspro/bin/cc -Xa -xF -xCC -xildoff -xarch=v9 -xchip=ultra
> > -dalign -I/usr/include/v9 -D_REENTRANT -xO2 -I. -I.
> > -I/usr/local/include -DETCDIR=\"/etc/ssh\"
> > -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
> > -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/sbin/ssh-askpass\"
> > -D_PATH_SFTP_SERVER=\"/usr/local/sbin/sftp-server\"
> > -D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c session.c
> > "session.c", line 628: identifier redeclared: do_pre_login
> >         current : static function(pointer to struct Session {int used,
> > int self, pointer to struct passwd {..} pw, pointer to struct Authctxt
> > {..} authctxt, int pid, pointer to char term, int ptyfd, int ttyfd, int
> > ptymaster, int row, int col, int xpixel, int ypixel, array[64] of char
> > tty, pointer to char display, int screen, pointer to char auth_proto,
> > pointer to char auth_data, int single_connection, int chanid, int
> > is_subsystem}) returning void
> >         previous: function() returning int : "session.c", line 581
> > cc: acomp failed for session.c
> > *** Error code 2
> > make: Fatal error: Command failed for target `session.o'
> >
> >
> > To correct a compilation error it is necessary to make the following
> > changes (just define function do_pre_login):
> > ================================== %<
> > ===================================================
> > --- session.c-orig  Tue Oct 23 11:13:06 2001
> > +++ session.c-patched   Tue Oct 23 11:19:54 2001
> > @@ -132,6 +132,9 @@
> >  void   do_child(Session *, const char *);
> >  void   do_motd(void);
> >  int    check_quietlogin(Session *, const char *);
> > +#ifdef LOGIN_NEEDS_UTMPX
> > +static void do_pre_login(Session *s);
> > +#endif
> >
> >  static void do_authenticated1(Authctxt *);
> >  static void do_authenticated2(Authctxt *);
> > ================================== %<
> > ===================================================
> >
> > WBR,
> > Alexander Ignatyev
> > AI-RIPE
> >
>
> 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  Wed Oct 24 00:38:01 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 23 Oct 2001 09:38:01 -0500 (CDT)
Subject: PAM problem - sshd segfault on Solaris
In-Reply-To: <20011023100527.A6251@openbsd.rutgers.edu>
Message-ID: <Pine.BSO.4.33.0110230936110.21704-100000@etoh.eviladmin.org>


PAM handling changes slightly which broke Solaris.  This is a known
issue and will be resovled in 3.0.

after ./configure  go into your config.h and set 'PAM_TTY_KLUDGE' and
the problem should go away.

- Ben
On Tue, 23 Oct 2001, William Yodlowsky wrote:

> I'm using OpenSSH-2.9.9p2 on Solaris 8 sparc64.  2.9p2 worked fine, but
> 2.9.9p2+ is giving me trouble with one thing - sshd segfaults if I try to
> connect and execute a command, such as "ssh machine ls".  Otherwise it
> works great.  sshd will fork, and the child process segfaults.
>
> CVS snapshot does the same thing.
>
> I've narrowed this down somewhat.  It will only happen if you use
> ./configure --with-pam (see below).
>
> Output from "gdb ./sshd" and "run -p 2022 -d -d -d" (IP obscured):
>
> ...
> Failed none for wyodlows from a.b.c.d port 45214 ssh2
> debug1: userauth-request for user wyodlows service ssh-connection method password
> debug1: attempt 1 failures 1
> debug2: input_userauth_request: try method password
> debug1: PAM Password authentication accepted for user "wyodlows"
> Accepted password for wyodlows from a.b.c.d port 45214 ssh2
> debug1: Entering interactive session for SSH2.
> debug1: server_init_dispatch_20
> debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768
> debug1: input_session_request
> debug1: channel 0: new [server-session]
> debug1: session_new: init
> debug1: session_new: session 0
> debug1: session_open: channel 0
> debug1: session_open: session 0: link with channel 0
> debug1: server_input_channel_open: confirm session
> debug2: callback start
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 channel 0 request exec reply 0
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xff133a9c in strncpy () from /usr/lib/libc.so.1
> (gdb) bt
> #0  0xff133a9c in strncpy () from /usr/lib/libc.so.1
> #1  0xff0b61b0 in pam_sm_open_session () from /usr/lib/security/pam_unix.so.1
> #2  0xff372b88 in pam_open_session () from /usr/lib/libpam.so.1
> #3  0x2cc88 in do_pam_session (username=0x115fb0 "wyodlows", ttyname=0x0)
>     at auth-pam.c:283
> #4  0x32360 in do_exec_no_pty (s=0x1108ac, command=0x121950 "ls")
>     at session.c:433
> #5  0x32884 in do_exec (s=0x1108ac, command=0x121950 "ls") at session.c:668
> #6  0x34008 in session_exec_req (s=0x1108ac) at session.c:1742
> #7  0x3417c in session_input_channel_req (id=0, arg=0x0) at session.c:1795
> #8  0x3a040 in channel_input_channel_request (type=98, plen=19, ctxt=0x116898)
>     at channels.c:1974
> #9  0x3cae0 in dispatch_run (mode=1, done=0x0, ctxt=0x116898) at dispatch.c:71
> #10 0x30e1c in process_buffered_input_packets () at serverloop.c:423
> #11 0x314b8 in server_loop2 (authctxt=0xffbef408) at serverloop.c:705
> #12 0x348d8 in do_authenticated2 (authctxt=0x1170f0) at session.c:2063
> #13 0x31eb4 in do_authenticated (authctxt=0x1170f0) at session.c:199
> #14 0x29c68 in do_authentication2 () at auth2.c:134
> #15 0x280d4 in main (ac=6, av=0x8) at sshd.c:1204
>
>
> I do not claim to know what the correct fix is, however I can avoid
> the segfault by removing the do_pam_session() call.  This is how the
> same code looks in 2.9p2 (which doesn't segfault).
>
> I'll happily provide any information needed to help fix this.  Thanks.
>
>
> --- openssh/session.c.orig	Mon Oct 22 22:42:46 2001
> +++ openssh/session.c	Mon Oct 22 22:43:31 2001
> @@ -430,7 +430,7 @@ do_exec_no_pty(Session *s, const char *c
>  	session_proctitle(s);
>
>  #if defined(USE_PAM)
> -	do_pam_session(s->pw->pw_name, NULL);
> +/*	do_pam_session(s->pw->pw_name, NULL);		*/
>  	do_pam_setcred(1);
>  #endif /* USE_PAM */
>
>




From mouring at etoh.eviladmin.org  Wed Oct 24 00:43:04 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 23 Oct 2001 09:43:04 -0500 (CDT)
Subject: OpenSSH port to NetWare 6
In-Reply-To: <sbd42d52.032@prv-mail20.provo.novell.com>
Message-ID: <Pine.BSO.4.33.0110230938270.23000-100000@etoh.eviladmin.org>


The normal procedure is to post the changes to the list.

Now, as for the rules of the game.  They are easy.  If you have Netware
only routines put them in openbsd-compat/bsd-netware.c.  Keep the #ifdef
mess down as low as possible.  And expect us to deny the patch if any
major changes occur to the OpenSSH tree.

The portable group attempts to keep the differences as low as possible
between it and the upstream (in some cases we fail, but we are starting to
be a bit stricker).

Lastly.  diff -u format please.  It is easier to read.

I have no clue if configure has been ported to Netware.  So you will need
to document the build process so we understand why you are doing things.

- Ben


On Mon, 22 Oct 2001, Vince Brimhall wrote:

> I'm a software developer at Novell.  I have been tasked with porting OpenSSH to the NetWare 6.0 OS.  I would like to include my NetWare specific changes,#ifdef'd of course, in the portable releases at some point.  Whom should I contact with regard to this?  And are there any guidlines I can look at online to minimize any disturbance this may cause to other platforms?
>
> Any assistance that can be provided would be appreciated.
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Vince Brimhall
> Senior Software Engineer
> Server Communications
> 801.861.1724
> vbrimhall at novell.com
>
> Novell, Inc., the leading provider of Net services software.
> www.novell.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>



From markus at openbsd.org  Wed Oct 24 00:59:56 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 23 Oct 2001 16:59:56 +0200
Subject: status of the hang-on-exit-bug
In-Reply-To: <Pine.SOL.4.30.0110221534001.21420-100000@mahler.udel.edu>; from ed@UDel.Edu on Mon, Oct 22, 2001 at 03:47:21PM -0400
References: <20011022153042.X5739@sm2p1386swk.wdr.com> <Pine.SOL.4.30.0110221534001.21420-100000@mahler.udel.edu>
Message-ID: <20011023165956.C18640@folly>

openssh's sshd currently tries to do what the rshd does:

after a SIGCHLD the sshd waits for an EOF from the login shell on
stdout/stderr. this is because we don't want to loose any data.

you can avoid this problem by starting the remote command with
stdin/out/err redirected to /dev/null.

unlike sshd both telnetd and rlogind exit on SIGCHLD. however, this
is because they don't care about lost data. but ssh needs to care.
rlogin does not. this is why ssh hangs and rlogin does not.

-m


From ed at UDel.Edu  Wed Oct 24 01:19:46 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 11:19:46 -0400 (EDT)
Subject: status of the hang-on-exit-bug
In-Reply-To: <20011023165956.C18640@folly>
Message-ID: <Pine.SOL.4.30.0110231112040.28226-100000@mahler.udel.edu>

On Tue, 23 Oct 2001, Markus Friedl wrote:

> Date: Tue, 23 Oct 2001 16:59:56 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org, openssh at openssh.com
> Subject: status of the hang-on-exit-bug
>
> openssh's sshd currently tries to do what the rshd does:
>
> after a SIGCHLD the sshd waits for an EOF from the login shell on
> stdout/stderr. this is because we don't want to loose any data.
>
> you can avoid this problem by starting the remote command with
> stdin/out/err redirected to /dev/null.
>
> unlike sshd both telnetd and rlogind exit on SIGCHLD. however, this
> is because they don't care about lost data. but ssh needs to care.
> rlogin does not. this is why ssh hangs and rlogin does not.

Okay... that sounds like a nice feature - to wait for the shell to end
before having sshd exit.  So, this is the SIGCHLD race condition mentioned
earlier?  Has it been fixed (which version) or is it considered a
non-issue?

It's not clear from your post whether you are describing something that
needs to be fixed or something that is already fixed or something that is
not going to be fixed because it doesn't really need to be fixed.

Sorry for my thick skull...

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 mstone at cs.loyola.edu  Wed Oct 24 01:32:05 2001
From: mstone at cs.loyola.edu (Michael Stone)
Date: Tue, 23 Oct 2001 11:32:05 -0400
Subject: status of the hang-on-exit-bug
In-Reply-To: <20011023165956.C18640@folly>; from markus@openbsd.org on Tue, Oct 23, 2001 at 04:59:56PM +0200
References: <20011022153042.X5739@sm2p1386swk.wdr.com> <Pine.SOL.4.30.0110221534001.21420-100000@mahler.udel.edu> <20011023165956.C18640@folly>
Message-ID: <20011023113205.Q7029@justice.loyola.edu>

On Tue, Oct 23, 2001 at 04:59:56PM +0200, Markus Friedl wrote:
> openssh's sshd currently tries to do what the rshd does:
> 
> after a SIGCHLD the sshd waits for an EOF from the login shell on
> stdout/stderr. this is because we don't want to loose any data.
> 
> you can avoid this problem by starting the remote command with
> stdin/out/err redirected to /dev/null.
> 
> unlike sshd both telnetd and rlogind exit on SIGCHLD. however, this
> is because they don't care about lost data. but ssh needs to care.
> rlogin does not. this is why ssh hangs and rlogin does not.

what's the rationale for not using the rlogin behavior for interactive
sessions and rsh behavior for non-interactive sessions? (tty/notty)

-- 
Mike Stone


From bsd at openbsd.rutgers.edu  Wed Oct 24 01:37:20 2001
From: bsd at openbsd.rutgers.edu (William Yodlowsky)
Date: Tue, 23 Oct 2001 11:37:20 -0400
Subject: PAM problem - sshd segfault on Solaris
In-Reply-To: <Pine.BSO.4.33.0110230936110.21704-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Tue, Oct 23, 2001 at 09:38:01AM -0500
References: <20011023100527.A6251@openbsd.rutgers.edu> <Pine.BSO.4.33.0110230936110.21704-100000@etoh.eviladmin.org>
Message-ID: <20011023113720.B6251@openbsd.rutgers.edu>

On Tuesday, October 23, mouring at etoh.eviladmin.org wrote:
> 
> PAM handling changes slightly which broke Solaris.  This is a known
> issue and will be resovled in 3.0.
> 
> after ./configure  go into your config.h and set 'PAM_TTY_KLUDGE' and
> the problem should go away.

Thanks, that did it.

Sorry for missing the previous posts regarding this issue.


> On Tue, 23 Oct 2001, William Yodlowsky wrote:
> 
> > I'm using OpenSSH-2.9.9p2 on Solaris 8 sparc64.  2.9p2 worked fine, but
> > 2.9.9p2+ is giving me trouble with one thing - sshd segfaults if I try to
> > connect and execute a command, such as "ssh machine ls".  Otherwise it
> > works great.  sshd will fork, and the child process segfaults.
[snip]



From mouring at etoh.eviladmin.org  Wed Oct 24 01:48:28 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 23 Oct 2001 10:48:28 -0500 (CDT)
Subject: status of the hang-on-exit-bug
In-Reply-To: <20011023113205.Q7029@justice.loyola.edu>
Message-ID: <Pine.BSO.4.33.0110231042560.11173-100000@etoh.eviladmin.org>

[..]
> > unlike sshd both telnetd and rlogind exit on SIGCHLD. however, this
> > is because they don't care about lost data. but ssh needs to care.
> > rlogin does not. this is why ssh hangs and rlogin does not.
>
> what's the rationale for not using the rlogin behavior for interactive
> sessions and rsh behavior for non-interactive sessions? (tty/notty)
>

This has been talked about recently amoung the developers.  And we are
still confused why OpenBSD does not result this this bug, but a large
amount of the UNIXes do show it.  It would be nice if we could learn the
'why' and fix the underlying issue we could could.  However, no one seems
to be able to provide such an answer.

There is a v2 patch (I've not checked the latest CVS tree due to personal
issues) that hides this problem for tty sessions connections proposed by
Markus.  It does it by disgarding any left over data in the datastream on
an interactive session.

- Ben



From ed at UDel.Edu  Wed Oct 24 02:04:27 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 12:04:27 -0400 (EDT)
Subject: PAM problem - sshd segfault on Solaris
In-Reply-To: <20011023113720.B6251@openbsd.rutgers.edu>
Message-ID: <Pine.SOL.4.30.0110231204070.28226-100000@mahler.udel.edu>

Okay... that fixes the PAM problem for me too.

	Ed

On Tue, 23 Oct 2001, William Yodlowsky wrote:

> Date: Tue, 23 Oct 2001 11:37:20 -0400
> From: William Yodlowsky <bsd at openbsd.rutgers.edu>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: PAM problem - sshd segfault on Solaris
>
> On Tuesday, October 23, mouring at etoh.eviladmin.org wrote:
> >
> > PAM handling changes slightly which broke Solaris.  This is a known
> > issue and will be resovled in 3.0.
> >
> > after ./configure  go into your config.h and set 'PAM_TTY_KLUDGE' and
> > the problem should go away.
>
> Thanks, that did it.
>
> Sorry for missing the previous posts regarding this issue.
>
>
> > On Tue, 23 Oct 2001, William Yodlowsky wrote:
> >
> > > I'm using OpenSSH-2.9.9p2 on Solaris 8 sparc64.  2.9p2 worked fine, but
> > > 2.9.9p2+ is giving me trouble with one thing - sshd segfaults if I try to
> > > connect and execute a command, such as "ssh machine ls".  Otherwise it
> > > works great.  sshd will fork, and the child process segfaults.
> [snip]
>

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 Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct 24 02:12:59 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Tue, 23 Oct 2001 18:12:59 +0200
Subject: status of the hang-on-exit-bug
In-Reply-To: <Pine.BSO.4.33.0110231042560.11173-100000@etoh.eviladmin.org>
References: <20011023113205.Q7029@justice.loyola.edu> <Pine.BSO.4.33.0110231042560.11173-100000@etoh.eviladmin.org>
Message-ID: <20011023181259.A7531@serv01.aet.tu-cottbus.de>

On Tue, Oct 23, 2001 at 10:48:28AM -0500, mouring at etoh.eviladmin.org wrote:
> [..]
> > > unlike sshd both telnetd and rlogind exit on SIGCHLD. however, this
> > > is because they don't care about lost data. but ssh needs to care.
> > > rlogin does not. this is why ssh hangs and rlogin does not.
> >
> > what's the rationale for not using the rlogin behavior for interactive
> > sessions and rsh behavior for non-interactive sessions? (tty/notty)
> >
> 
> This has been talked about recently amoung the developers.  And we are
> still confused why OpenBSD does not result this this bug, but a large
> amount of the UNIXes do show it.  It would be nice if we could learn the
> 'why' and fix the underlying issue we could could.  However, no one seems
> to be able to provide such an answer.

While this may become a time consuming process, it should be manageable
since at least two OpenSource platforms with the behaviour in question
are available:
* OpenBSD not exhibiting the problem
* Linux having the "hang on exit" effect.
Therefore it is even possible to examine kernel source, if necessary.

As far as I understood the problem, sshd is waiting for the I/O fds
to be closed before actually closing the channel and exiting.
The effect occurs with background processes having the file descriptors
still open.
Questions:
- Is the problem consistent between shells? (Actually: are we looking for
  an operating system dependant problem? The discussion by now says, that
  it is an OS dependant problem.)
- What happens to the open files on exit of the shell?
  As on OpenBSD there is no "hang-on-exit" problem, it seems that the file
  descriptors are being closed immediatly (from the sshd's side of view).
  It should be the kernel performing the close.
  From the backgrounded process side of view: are the files also closed
  on exit of the shell? This would mean, that the backgrounded process
  would also experience an end-of-file condition (and a SIGPIPE on
  write). Should not be too hard to find out..
- Even more: on OpenBSD the connection is closed immediatly. Doesn't this
  mean, that output generated by the backgrounded processes after the
  close would be lost, thus violating the idea of keeping the channel
  open to prevent this data loss...

Just thinking on how to tackle the problem...

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From ed at UDel.Edu  Wed Oct 24 02:18:40 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 12:18:40 -0400 (EDT)
Subject: ssh/sshd go off in limbo-land after closing remote session (v2.9.9p2)
Message-ID: <Pine.SOL.4.30.0110231204310.28226-100000@mahler.udel.edu>

When I run a remote xterm, the ssh hangs even after I quit the xterm.

Below is the output for the following sequence:

client> ssh -v -v -v dazel xterm
xterm> exit
client> ^C

The outcome is always the same - the ssh doesn't exit with I quit the
xterm... I have to hit CTRL-C on the client side.

polycut:~> ssh -v -v -v dazel xterm
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f
debug1: Reading configuration data /opt/openssh2.9p2/etc/ssh_config
debug3: Reading output from 'ls -alni /var/log'
debug3: Time elapsed: 36 msec
debug3: Got 2.00 bytes of entropy from 'ls -alni /var/log'
debug3: Reading output from 'ls -alni /var/adm'
debug3: Time elapsed: 28 msec
debug3: Got 2.00 bytes of entropy from 'ls -alni /var/adm'
debug3: Reading output from 'ls -alni /var/mail'
debug3: Time elapsed: 18 msec
debug3: Got 0.71 bytes of entropy from 'ls -alni /var/mail'
debug3: Reading output from 'ls -alni /proc'
debug3: Time elapsed: 68 msec
debug3: Got 2.00 bytes of entropy from 'ls -alni /proc'
debug3: Reading output from 'ls -alni /tmp'
debug3: Time elapsed: 23 msec
debug3: Got 2.00 bytes of entropy from 'ls -alni /tmp'
debug3: Reading output from 'ls -alni /var/tmp'
debug3: Time elapsed: 119 msec
debug3: Got 2.00 bytes of entropy from 'ls -alni /var/tmp'
debug3: Reading output from 'ls -alni /usr/tmp'
debug3: Time elapsed: 21 msec
debug3: Got 0.18 bytes of entropy from 'ls -alni /usr/tmp'
debug3: Reading output from 'netstat -an'
debug3: Time elapsed: 42 msec
debug3: Got 2.00 bytes of entropy from 'netstat -an'
debug3: Reading output from 'netstat -in'
debug3: Time elapsed: 36 msec
debug3: Got 2.00 bytes of entropy from 'netstat -in'
debug3: Reading output from 'netstat -rn'
debug3: Time elapsed: 35 msec
debug3: Got 1.84 bytes of entropy from 'netstat -rn'
debug3: Reading output from 'netstat -pn'
debug3: Time elapsed: 58 msec
debug3: Got 2.00 bytes of entropy from 'netstat -pn'
debug3: Reading output from 'netstat -s'
debug3: Time elapsed: 42 msec
debug3: Got 2.00 bytes of entropy from 'netstat -s'
debug3: Reading output from 'arp -a -n'
debug3: Time elapsed: 192 msec
debug3: Got 2.00 bytes of entropy from 'arp -a -n'
debug3: Reading output from 'ifconfig -a'
debug3: Time elapsed: 41 msec
debug3: Got 0.86 bytes of entropy from 'ifconfig -a'
debug3: Reading output from 'ps -al'
debug3: Time elapsed: 50 msec
debug3: Got 2.00 bytes of entropy from 'ps -al'
debug3: Reading output from 'ps -efl'
debug3: Time elapsed: 113 msec
debug3: Got 2.00 bytes of entropy from 'ps -efl'
debug3: Reading output from 'w'
debug3: Time elapsed: 79 msec
debug3: Got 2.00 bytes of entropy from 'w'
debug3: Reading output from 'last'
debug3: Time elapsed: 194 msec
debug2: Command 'last' timed out
debug3: Got 2.00 bytes of entropy from 'last'
debug3: Reading output from 'df'
debug3: Time elapsed: 23 msec
debug3: Got 0.71 bytes of entropy from 'df'
debug3: Reading output from 'vmstat'
debug3: Time elapsed: 30 msec
debug3: Got 0.23 bytes of entropy from 'vmstat'
debug3: Reading output from 'uptime'
debug3: Time elapsed: 31 msec
debug3: Got 0.07 bytes of entropy from 'uptime'
debug3: Reading output from 'ipcs -a'
debug3: Time elapsed: 264 msec
debug2: Command 'ipcs -a' timed out
debug3: Got 0.00 bytes of entropy from 'ipcs -a'
debug3: Reading output from 'tail -200 /var/log/syslog'
debug3: Time elapsed: 15 msec
debug3: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog'
debug3: Reading output from 'tail -200 /var/adm/messages'
debug3: Time elapsed: 15 msec
debug3: Got 1.05 bytes of entropy from 'tail -200 /var/adm/messages'
debug1: Seeded RNG with 40 bytes from programs
debug1: Seeded RNG with 3 bytes from system calls
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 16476 geteuid 0 anon 1
debug1: Connecting to dazel [128.175.13.68] port 22.
debug1: temporarily_use_uid: 16476/10 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 16476/10 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/polycut.nss/usra/ed/.ssh/identity type 0
debug3: No RSA1 key file /home/polycut.nss/usra/ed/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/polycut.nss/usra/ed/.ssh/id_rsa type 1
debug1: identity file /home/polycut.nss/usra/ed/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_2.9.9p2
debug1: match: OpenSSH_2.9.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
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: 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,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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: 123/256
debug1: bits set: 1611/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename
/home/polycut.nss/usra/ed/.ssh/known_hosts2
debug3: check_host_in_hostfile: match line 8
debug3: check_host_in_hostfile: filename
/home/polycut.nss/usra/ed/.ssh/known_hosts2
debug3: check_host_in_hostfile: match line 8
debug1: Host 'dazel' is known and matches the RSA host key.
debug1: Found key in /home/polycut.nss/usra/ed/.ssh/known_hosts2:8
debug1: bits set: 1593/3191
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
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,password,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: password,keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: testing agent key
/home/polycut.nss/usra/ed/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 147a50 hint
-1
debug2: input_userauth_pk_ok: fp
f7:19:b1:e8:56:1c:81:55:44:9b:b4:f7:e1:b0:c8:ca
debug3: sign_and_send_pubkey
debug3: clear_auth_state: key_free 147a50
debug1: ssh-userauth2 successful: method publickey
debug3: clear hostkey 0
debug3: clear hostkey 1
debug3: clear hostkey 2
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: client_init id 0 arg 0
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: xterm
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
debug1: client_input_channel_open: ctype x11 rchan 3 win 4096 max 2048
debug1: client_request_x11: request from 128.175.13.68 36968
debug1: fd 10 setting O_NONBLOCK
debug1: fd 10 IS O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd adjust 2088
debug2: channel 1: rcvd adjust 2336
debug2: channel 1: rcvd adjust 3580
debug2: channel 1: rcvd adjust 3744
debug1: channel 1: rcvd eof
debug1: channel 1: output open -> drain
debug1: channel 1: obuf empty
debug1: channel 1: output drain -> closed
debug1: channel 1: close_write
debug1: channel 1: read<=0 rfd 10 len 0
debug1: channel 1: read failed
debug1: channel 1: input open -> drain
debug1: channel 1: close_read
debug1: channel 1: input: no drain shortcut
debug1: channel 1: ibuf empty
debug1: channel 1: input drain -> closed
debug1: channel 1: send eof
debug1: channel 1: send close
debug2: channel 1: no data after CLOSE
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
debug1: channel 0: input open -> closed
debug1: channel 0: close_read
debug2: channel 0: no data after CLOSE
debug2: channel 1: 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)
  #1 x11 (t4 r3 i8/0 o128/0 fd 10/10)

debug1: channel_free: channel 0: dettaching channel user
debug1: channel 1: rcvd close
debug2: channel 1: no data after CLOSE
debug1: channel 1: is dead
debug1: channel_free: channel 1: status: The following connections are
open:
  #1 x11 (t4 r3 i8/0 o128/0 fd 10/10)

^CKilled by signal 2.
debug1: Calling cleanup 0x43e48(0x0)
debug1: Calling cleanup 0x54520(0x0)
debug1: Calling cleanup 0x5de88(0x0)
debug1: writing PRNG seed to file /home/polycut.nss/usra/ed/.ssh/prng_seed

---

I also notice that while the ssh is hanging on the client side, there is
still an sshd running on the server side (which I'd guess is the
encoder/decoder process - which has not detected that it's child has gone
bye-bye or for some reason things there are still file descriptors to be
handled)...

server> ptree 20441
20441 /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config
  20497 /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config
server> pfiles 20497
20497:  /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config
  Current rlimit: 1024 file descriptors
   0: S_IFCHR mode:0666 dev:136,0 ino:37794 uid:0 gid:3 rdev:13,2
      O_RDWR
   1: S_IFCHR mode:0666 dev:136,0 ino:37794 uid:0 gid:3 rdev:13,2
      O_RDWR
   2: S_IFCHR mode:0666 dev:136,0 ino:37794 uid:0 gid:3 rdev:13,2
      O_RDWR
   3: S_IFREG mode:0644 dev:136,5 ino:500893 uid:0 gid:1 size:1999
      O_RDONLY
   4: S_IFDOOR mode:0444 dev:240,0 ino:29463 uid:0 gid:0 size:0
      O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[235]
   5: S_IFCHR mode:0666 dev:136,0 ino:37794 uid:0 gid:3 rdev:13,2
      O_RDWR
   6: S_IFSOCK mode:0666 dev:235,0 ino:43049 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK
        sockname: AF_INET6 ::  port: 6013
   7: S_IFSOCK mode:0666 dev:235,0 ino:39941 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK
        sockname: AF_INET 0.0.0.0  port: 6013
   8: S_IFSOCK mode:0666 dev:235,0 ino:45982 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK
        sockname: AF_INET 128.175.13.68  port: 22
        peername: AF_INET 128.175.13.38  port: 49867

Please help!

	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  Wed Oct 24 02:22:13 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 12:22:13 -0400 (EDT)
Subject: ssh v2.9.9p2 wierdness
Message-ID: <Pine.SOL.4.30.0110231218510.28226-100000@mahler.udel.edu>

When I run a command like on v2.9.9p2 on Solaris 8:

client> ssh server

... and immediately press CTRL-D, I get a shell prompt from the remote
host, but I can't type into it and have to kill the ssh process on the
client.

	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  Wed Oct 24 02:25:52 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 23 Oct 2001 11:25:52 -0500 (CDT)
Subject: Another round of testing calls.
Message-ID: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org>


Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
required.  *WHAT* other issues *MUST* be address before 3.0 which is
approaching fast?

Those running NeXTStep I need conformation that it works under NeXT.  My
current Slab is packed in a storage unit due to a fire in my apartment
complex (happened above me so I'm wrapping up dealing with that crap =).

- Ben



From Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct 24 02:34:22 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Tue, 23 Oct 2001 18:34:22 +0200
Subject: ssh/sshd go off in limbo-land after closing remote session (v2.9.9p2)
In-Reply-To: <Pine.SOL.4.30.0110231204310.28226-100000@mahler.udel.edu>
References: <Pine.SOL.4.30.0110231204310.28226-100000@mahler.udel.edu>
Message-ID: <20011023183422.A8106@serv01.aet.tu-cottbus.de>

On Tue, Oct 23, 2001 at 12:18:40PM -0400, Ed Phillips wrote:
> When I run a remote xterm, the ssh hangs even after I quit the xterm.
> 
> Below is the output for the following sequence:
> 
> client> ssh -v -v -v dazel xterm
> xterm> exit
> client> ^C
> 
> The outcome is always the same - the ssh doesn't exit with I quit the
> xterm... I have to hit CTRL-C on the client side.
> 
> polycut:~> ssh -v -v -v dazel xterm
> OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There was a client side change with respect to hanging SSH connections after
agent forwarding. The same change was made for X11 forwarding.
Please make sure to run your tests with 2.9.9 or current CVS!

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From ed at UDel.Edu  Wed Oct 24 03:37:45 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 23 Oct 2001 13:37:45 -0400 (EDT)
Subject: ssh/sshd go off in limbo-land after closing remote session
 (v2.9.9p2)
In-Reply-To: <20011023183422.A8106@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.SOL.4.30.0110231337170.7544-100000@mahler.udel.edu>

On Tue, 23 Oct 2001, Lutz Jaenicke wrote:

> Date: Tue, 23 Oct 2001 18:34:22 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: ssh/sshd go off in limbo-land after closing remote session
>     (v2.9.9p2)
>
> On Tue, Oct 23, 2001 at 12:18:40PM -0400, Ed Phillips wrote:
> > When I run a remote xterm, the ssh hangs even after I quit the xterm.
> >
> > Below is the output for the following sequence:
> >
> > client> ssh -v -v -v dazel xterm
> > xterm> exit
> > client> ^C
> >
> > The outcome is always the same - the ssh doesn't exit with I quit the
> > xterm... I have to hit CTRL-C on the client side.
> >
> > polycut:~> ssh -v -v -v dazel xterm
> > OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> There was a client side change with respect to hanging SSH connections after
> agent forwarding. The same change was made for X11 forwarding.
> Please make sure to run your tests with 2.9.9 or current CVS!

Sorry... my mistake... I'll rerun with 2.9.9p2 on the client side....

	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 cjc5 at po.cwru.edu  Wed Oct 24 04:06:16 2001
From: cjc5 at po.cwru.edu (Craig J Copi)
Date: Tue, 23 Oct 2001 14:06:16 -0400
Subject: status of the hang-on-exit-bug 
In-Reply-To: Your message of "Tue, 23 Oct 2001 18:12:59 +0200."
             <20011023181259.A7531@serv01.aet.tu-cottbus.de> 
Message-ID: <200110231806.f9NI6GC26057@aether.phys.cwru.edu>

Lutz Jaenicke writes:
>- Even more: on OpenBSD the connection is closed immediatly. Doesn't this
>  mean, that output generated by the backgrounded processes after the
>  close would be lost, thus violating the idea of keeping the channel
>  open to prevent this data loss...

I believe it does mean that data is lost.  I did the following 
simple test:
#>ssh localhost
[ Login ]
%> sleep 10; echo hi &
%> exit

I did this on
(1) OpenBSD 2.9 with OpenSSH_2.9 and tcsh-6.10.00 (from ports)
(2) Linux 2.4.6 with OpenSSH_2.9.9p2 and tcsh-6.10-5 (RH 7.1)

On the OpenBSD box (1) the exit was immediate.  "hi" WAS NOT printed.
On the Linux box (2) the exit hung, after the delay "hi" WAS printed
  then the exit finished.

Craig


From dwd at bell-labs.com  Wed Oct 24 04:13:36 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 23 Oct 2001 13:13:36 -0500
Subject: configure changes
In-Reply-To: <Pine.UW2.4.40.9.0110211804210.5753-100000@uw711.int.multitalents.net>; from tim@multitalents.net on Sun, Oct 21, 2001 at 06:24:49PM -0700
References: <Pine.UW2.4.40.9.0110211804210.5753-100000@uw711.int.multitalents.net>
Message-ID: <20011023131336.A3139@lucent.com>

On Sun, Oct 21, 2001 at 06:24:49PM -0700, Tim Rice wrote:
...
> I have added a test for broken dirname() on Solaris 2.5.1 by
> Dan Astoorian <djast at cs.toronto.edu>. Dan please test.

I tested it and found 3 problems:
    1. -lgen was not being passed to the test program.
    2. the wrong variable $ac_cv_have_getopt_optreset was being tested,
	should have been ac_cv_have_broken_dirname
    3. Can't define HAVE_LIBGEN_H because openbsd-compat/dirname.h defines
	the parameter with "const" but Solaris 2.5.1 libgen.h defines
	it without.

Patch is below.  I tested on Solaris 2.5.1 where it properly detected the
broken dirname and on Irix 6.2 where it found a working dirname in -lgen.

- Dave Dykstra


--- configure.in.O	Tue Oct 23 12:57:41 2001
+++ configure.in	Tue Oct 23 13:49:48 2001
@@ -430,7 +430,7 @@
 
 # Checks for header files.
 AC_CHECK_HEADERS(bstring.h crypt.h endian.h floatingpoint.h \
-	getopt.h glob.h lastlog.h libgen.h limits.h login.h \
+	getopt.h glob.h lastlog.h limits.h login.h \
 	login_cap.h maillock.h netdb.h netgroup.h \
 	netinet/in_systm.h paths.h poll.h pty.h regex.h \
 	security/pam_appl.h shadow.h stddef.h stdint.h \
@@ -584,6 +584,8 @@
 	AC_CHECK_LIB(gen, dirname,[
 		AC_CACHE_CHECK([for broken dirname],
 			ac_cv_have_broken_dirname, [
+			save_LIBS="$LIBS"
+			LIBS="$LIBS -lgen"
 			AC_TRY_RUN(
 				[
 #include <libgen.h>
@@ -604,10 +606,12 @@
 				[ ac_cv_have_broken_dirname="no" ],
 				[ ac_cv_have_broken_dirname="yes" ]
 			)
+			LIBS="$save_LIBS"
 		])
-		if test "x$ac_cv_have_getopt_optreset" = "xno" ; then
+		if test "x$ac_cv_have_broken_dirname" = "xno" ; then
 			LIBS="$LIBS -lgen"
 			AC_DEFINE(HAVE_DIRNAME)
+			AC_CHECK_HEADERS(libgen.h)
 		fi
 	])
 ])


From dwd at bell-labs.com  Wed Oct 24 04:29:05 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 23 Oct 2001 13:29:05 -0500
Subject: Another round of testing calls.
In-Reply-To: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Tue, Oct 23, 2001 at 11:25:52AM -0500
References: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org>
Message-ID: <20011023132904.B3139@lucent.com>

On Tue, Oct 23, 2001 at 11:25:52AM -0500, mouring at etoh.eviladmin.org wrote:
> 
> Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
> required.  *WHAT* other issues *MUST* be address before 3.0 which is
> approaching fast?

I think my patches for expiring shadow passwords and for host key size
mismatch are the highest priority of the patches I've submitted, and should
be put in 3.0.  They will save a lot of people a lot of trouble.  Also, if
you want to it to compile on Sunos4 you need my openbsd-compat/readpassphrase.c
patch.

- Dave Dykstra


From djast at cs.toronto.edu  Wed Oct 24 05:12:32 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 23 Oct 2001 15:12:32 -0400
Subject: configure changes 
In-Reply-To: Message from Dave Dykstra <dwd@bell-labs.com> 
   of "Tue, 23 Oct 2001 14:13:36 EDT." <20011023131336.A3139@lucent.com> 
Message-ID: <01Oct23.151234edt.453153-15834@jane.cs.toronto.edu>

On Tue, 23 Oct 2001 14:13:36 EDT, Dave Dykstra writes:
> On Sun, Oct 21, 2001 at 06:24:49PM -0700, Tim Rice wrote:
> ...
> > I have added a test for broken dirname() on Solaris 2.5.1 by
> > Dan Astoorian <djast at cs.toronto.edu>. Dan please test.
> 
> I tested it and found 3 problems:

I never received Tim's message from Sunday; perhaps he assumed I was on
openssh-unix-dev?

(Since I only have Dave's patch to Tim's patched configure.in, I cannot
test the change; however, it sounds like Dave has already tested it
adequately under Solaris 2.5.1.)

BTW, it occurred to me after sending the test program that:
    if (!s || strncmp(s, "/", 32) != 0) {

would have been more defensive than where I originally wrote:
    if (s && s[0] == '\0') {

in that it would test for any incorrect value, rather than the specific
incorrect value that Solaris 2.5.1 libgen produces.

However, the change may not be worth going to a lot of trouble to
re-test, unless it's suspected that there are other dirname()
implementations that are broken in a different way.

Thanks,

-- 
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 johan.adolfsson at axis.com  Wed Oct 24 05:16:29 2001
From: johan.adolfsson at axis.com (johan.adolfsson at axis.com)
Date: Tue, 23 Oct 2001 21:16:29 +0200
Subject: cross compiling openssh?
References: <20011018204800.B8518@otii.com> <20011019101013.A28569@faui02.informatik.uni-erlangen.de> <20011019031210.D8518@otii.com>
Message-ID: <010801c15bf7$385181c0$9fb270d5@homeip.net>

I have managed to get openssh cross-compiled to our ETRAX100 and
ETRAX100LX chip using either uClibc or glibc.
I posted a patch to configure.in a long time ago (2000-12-18) but I guess
it was to ugly to get accepted or something (I'm not an autoconf guy :)

Regarding uC-libc I guess the current CVS is a lot smoother to work with
than what I had back then, but beware of the regex implementation...

Another problem to is to get a random seed worth thne name in an embedded
diskless (but networked) environment.

/Johan


----- Original Message -----
From: Ray Lehtiniemi <rayl at otii.com>
To: Markus Friedl <markus at openbsd.org>
Cc: <openssh-unix-dev at mindrot.org>
Sent: Friday, October 19, 2001 11:12 AM
Subject: Re: cross compiling openssh?


> On Fri, Oct 19, 2001 at 10:10:13AM +0200, Markus Friedl wrote:
> > On Thu, Oct 18, 2001 at 08:48:00PM -0600, Ray Lehtiniemi wrote:
> > > is cross compilation support planned anytime soon?  if not, what's
involved
> > > (technically or otherwise) in making it happen?
> >
> > just do it.
>
> ok, so no issues except just getting it done, then.
>
> some more details on my setup.  i am prototyping a cirrus cs89712 (arm720
> based) embedded system using a CDB89712 eval board with:
>
>   - gcc-2.95.3
>   - linux-2.4-ac-rmk
>   - uClibc-cvs
>
>
>
> i grabbed openssh-2.9.9p2.tar.gz, fudged the configure.in AC_TRY_RUN
issues and
> glossed over a few uClibc issues.  this resulted in an executable that
will, in
> theory, at least run.  i'll test it out tomorrow or monday, when i again
have access
> to the devel board.
>
>
>
> some questions:
>
>   - is cross-compilation considered a "core development effort" or a
"portability
>     development effort"?  in other words, which cvs tree am i working
against?
>
>   - i found the openbsd style(9) guide.  is there a cross-compilation
guide?  are
>     there any particularly good examples of cross-compile autoconfigury
that i
>     should be emulating?
>
>   - is uClibc considered secure?  how "good" will my sshd be if compiled
against
>     uClibc?
>
>
>
> thanks
>
> --
> --------------------------------------------------------------------------
-
>     Ray Lehtiniemi <rayl at mail.com> <rayl at otii.com>
>



From wayned at users.sourceforge.net  Wed Oct 24 05:15:49 2001
From: wayned at users.sourceforge.net (Wayne Davison)
Date: Tue, 23 Oct 2001 12:15:49 -0700 (PDT)
Subject: Another round of testing calls.
In-Reply-To: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.21.0110231212050.30989-100000@life.blorf.net>

On Tue, 23 Oct 2001 mouring at etoh.eviladmin.org wrote:
> *WHAT* other issues *MUST* be address before 3.0 which is
> approaching fast?

I would greatly appreciate it if you'd apply this patch that I first
submitted back in April:

Index: loginrec.c
--- loginrec.c	2001/10/22 06:49:23	1.36
+++ loginrec.c	2001/10/23 19:22:17
@@ -448,6 +448,8 @@
 login_utmp_only(struct logininfo *li)
 {
 	li->type = LTYPE_LOGIN; 
+	/* set the timestamp */
+	login_set_current_time(li);
 # ifdef USE_UTMP
 	utmp_write_entry(li);
 # endif

It sets the time in the logininfo structure so that the "last" log
doesn't get an event with a timestamp of Dec 31, 1969.  This patch
only affects the LOGIN_NEEDS_UTMPX code path.

..wayne..



From rayl at otii.com  Wed Oct 24 05:54:12 2001
From: rayl at otii.com (Ray Lehtiniemi)
Date: Tue, 23 Oct 2001 13:54:12 -0600
Subject: cross compiling openssh?
In-Reply-To: <010801c15bf7$385181c0$9fb270d5@homeip.net>; from johan.adolfsson@axis.com on Tue, Oct 23, 2001 at 09:16:29PM +0200
References: <20011018204800.B8518@otii.com> <20011019101013.A28569@faui02.informatik.uni-erlangen.de> <20011019031210.D8518@otii.com> <010801c15bf7$385181c0$9fb270d5@homeip.net>
Message-ID: <20011023135412.B3333@otii.com>



hi johan


On Tue, Oct 23, 2001 at 09:16:29PM +0200, johan.adolfsson at axis.com wrote:
> I have managed to get openssh cross-compiled to our ETRAX100 and
> ETRAX100LX chip using either uClibc or glibc.
> I posted a patch to configure.in a long time ago (2000-12-18) but I guess
> it was to ugly to get accepted or something (I'm not an autoconf guy :)

ok, found your post in the archives, and it looks like you patched all the same
places i did.  i'm still busy investigating various cross-compilable packages
for other examples to follow.



> Regarding uC-libc I guess the current CVS is a lot smoother to work with
> than what I had back then, but beware of the regex implementation...

i'll keep an eye on that.  most of my problems thus far have been with
netdb.h and other uclibc headers declaring things that aren;t actually in the
library, causing autoconf to leave out compat stuff i really do need.




> Another problem to is to get a random seed worth thne name in an embedded
> diskless (but networked) environment.

hum...  indeed.  i have some room on the board, maybe i should put some kind of
circuit on there which can generate a reasonable amount of entropy.  time to
hit the library...


thanks!

-- 
---------------------------------------------------------------------------
    Ray Lehtiniemi <rayl at mail.com> <rayl at otii.com>


From pedwards at disaster.jaj.com  Wed Oct 24 08:40:03 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Tue, 23 Oct 2001 18:40:03 -0400
Subject: hanging on logout, can't background client
Message-ID: <20011023184003.A19854@disaster.jaj.com>

I've just recently switched from old ssh to OpenSSH 2.  So far no major
problems, until now.  I'm logging in from Linux to Solaris 8.  Both are
running 2.9.9p2.

Under ssh-1.2.28 I would fire off several xterms, exit, and properly get the
"waiting for forwarded X11 connection" message, and then be able to type ~&
(as documented) to get back to the shell.  The channel was kept open for
the xterms, of course, and when the last xterm closed, a message like "hey,
connected to remote machine finally closed now that you've found that stray
xterm, ya chowderhead" would be printed on the terminal I used to connect.

Now, I do all of that, logout, and the client hangs.  NONE of the escape
sequences work, not even ~. !  Can't background it, can't suspend it.
That bothers me.


Do I need to "sacrifice" a terminal to do my ssh'ing, one per remote
machine?  Start the xterms, exit, then just minimize it as a wasted window?
That'd be a severe PITA.  Is there a configuration option on either side
that I'm missing?

(What's really annoying is when a forwarded X app crashes, and ssh /thinks/
it's still running.  Then the terminal is permanently hung, since the
connection never closes.)


Any tips?  Am I forgetting to tweak something?

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From dunlap at apl.washington.edu  Wed Oct 24 11:16:40 2001
From: dunlap at apl.washington.edu (John Dunlap)
Date: Tue, 23 Oct 2001 18:16:40 -0700 (PDT)
Subject: readpass.c patch
Message-ID: <200110240116.f9O1GeZ10792@henry.apl.washington.edu>

To make readpass.c work on first try with gnome-askpass on RHL 7.1:

wget http://bass.directhit.com/openssh_snap/openssh-SNAP-20011023.tar.gz
tar xfz openssh-SNAP-20011023.tar.gz
cd openssh
./configure --with-pam --enable-gnome-askpass --with-tcp-wrappers
mv readpass.c readpass.c1

new readpass.c according to patch I received from djm 5-13-01:

--------------------- cut here ---------------------------------
--- readpass.c1	Wed Jul 18 08:45:45 2001
+++ readpass.c	Tue Oct 23 18:01:01 2001
@@ -71,12 +71,15 @@
 		fatal("ssh_askpass: exec(%s): %s", askpass, strerror(errno));
 	}
 	close(p[1]);
-	len = read(p[0], buf, sizeof buf);
+//	len = read(p[0], buf, sizeof buf);            // djm 5-13-01
+        memset(buf, 0, sizeof(buf));                  // djm 5-13-01
+        len = atomicio(read, p[0], buf, sizeof buf);  // djm 5-13-01
 	close(p[0]);
 	while (waitpid(pid, &status, 0) < 0)
 		if (errno != EINTR)
 			break;
-	if (len <= 1)
+//	if (len <= 1)                                 // djm 5-13-01
+	if (len == -1)                                // djm 5-13-01
 		return xstrdup("");
 	nl = strchr(buf, '\n');
 	if (nl)
--------------------- cut here ---------------------------------

Regards,
John

-- 
John Dunlap                           University of Washington
Senior Electrical Engineer            Applied Physics Laboratory
dunlap at apl.washington.edu             1013 NE 40th Street
206-543-7207, 543-1300, FAX 543-6785  Seattle, WA   98105-6698


From markm68k at yahoo.com  Wed Oct 24 11:44:04 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Tue, 23 Oct 2001 18:44:04 -0700 (PDT)
Subject: snapshot problems on Mac OS X
Message-ID: <20011024014404.50141.qmail@web14510.mail.yahoo.com>

Here are some problems with the latest snapshot on Mac
OS X:

I am by no means an autoconf expert, but here is what
happens after a "autoreconf":

autoconf: Undefined macros:
configure.in:1291:AC_CHECK_MEMBERS([struct
stat.st_blksize])
configure.in:2168:AC_CONFIG_FILES([Makefile
openbsd-compat/Makefile scard/Makefile ssh_prng_cmds])
configure.in:26:AC_SYS_LARGEFILE
configure.in:4:AC_CONFIG_SRCDIR([ssh.c])
/usr/bin/autoheader: Symbol `socklen_t' is not covered
by /usr/share/autoconf/acconfig.h ./acconfig.h



next, the results from running "configure":

creating cache ./config.cache
./configure: command not found:
AC_CONFIG_SRCDIR(ssh.c) [606]
.
.
.
./configure: command not found: AC_SYS_LARGEFILE
[1403]
.
.
.
./configure: command not found:
AC_CHECK_MEMBERS(struct stat.st_blksize) [7125]
.
.
.
./configure: no such file or directory:
AC_CONFIG_FILES(Makefile openbsd-compat/Makefile
scard/Makefile ssh_prng_cmds) [9802]


There seems to be a pattern here.. but what needs to
be fixed?




=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From mouring at etoh.eviladmin.org  Wed Oct 24 12:17:36 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 23 Oct 2001 21:17:36 -0500 (CDT)
Subject: snapshot problems on Mac OS X
In-Reply-To: <20011024014404.50141.qmail@web14510.mail.yahoo.com>
Message-ID: <Pine.BSO.4.33.0110232117001.7621-100000@etoh.eviladmin.org>

You are on the latest autoconf..RIGHT

If not you need to be.

- Ben

On Tue, 23 Oct 2001, Mark Miller wrote:

> Here are some problems with the latest snapshot on Mac
> OS X:
>
> I am by no means an autoconf expert, but here is what
> happens after a "autoreconf":
>
> autoconf: Undefined macros:
> configure.in:1291:AC_CHECK_MEMBERS([struct
> stat.st_blksize])
> configure.in:2168:AC_CONFIG_FILES([Makefile
> openbsd-compat/Makefile scard/Makefile ssh_prng_cmds])
> configure.in:26:AC_SYS_LARGEFILE
> configure.in:4:AC_CONFIG_SRCDIR([ssh.c])
> /usr/bin/autoheader: Symbol `socklen_t' is not covered
> by /usr/share/autoconf/acconfig.h ./acconfig.h
>
>
>
> next, the results from running "configure":
>
> creating cache ./config.cache
> ./configure: command not found:
> AC_CONFIG_SRCDIR(ssh.c) [606]
> .
> .
> .
> ./configure: command not found: AC_SYS_LARGEFILE
> [1403]
> .
> .
> .
> ./configure: command not found:
> AC_CHECK_MEMBERS(struct stat.st_blksize) [7125]
> .
> .
> .
> ./configure: no such file or directory:
> AC_CONFIG_FILES(Makefile openbsd-compat/Makefile
> scard/Makefile ssh_prng_cmds) [9802]
>
>
> There seems to be a pattern here.. but what needs to
> be fixed?
>
>
>
>
> =====
> Mark Miller
> markm68k at yahoo.com
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
>



From markm68k at yahoo.com  Wed Oct 24 14:09:29 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Tue, 23 Oct 2001 21:09:29 -0700 (PDT)
Subject: snapshot problems on Mac OS X
In-Reply-To: <Pine.BSO.4.33.0110232117001.7621-100000@etoh.eviladmin.org>
Message-ID: <20011024040929.24644.qmail@web14503.mail.yahoo.com>

--- mouring at etoh.eviladmin.org wrote:
> You are on the latest autoconf..RIGHT

Egads!  There is a version 2.52?!  Wow, it looks like
Darwin / Mac OS X comes with 2.13.

> If not you need to be.

Ok, that worked.

Thanks, Ben.

=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From tim at multitalents.net  Wed Oct 24 15:43:16 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 23 Oct 2001 22:43:16 -0700 (PDT)
Subject: configure changes
In-Reply-To: <20011023131336.A3139@lucent.com>
Message-ID: <Pine.UW2.4.40.9.0110232127290.14199-100000@uw711.int.multitalents.net>

On Tue, 23 Oct 2001, Dave Dykstra wrote:

> On Sun, Oct 21, 2001 at 06:24:49PM -0700, Tim Rice wrote:
> ...
> > I have added a test for broken dirname() on Solaris 2.5.1 by
> > Dan Astoorian <djast at cs.toronto.edu>. Dan please test.
>
> I tested it and found 3 problems:
>     1. -lgen was not being passed to the test program.
>     2. the wrong variable $ac_cv_have_getopt_optreset was being tested,
> 	should have been ac_cv_have_broken_dirname
Opps, forgot to update that line after yanking and putting.

>     3. Can't define HAVE_LIBGEN_H because openbsd-compat/dirname.h defines
> 	the parameter with "const" but Solaris 2.5.1 libgen.h defines
> 	it without.

Thanks for catching that. I've commited a slightly modified version
of your patch.

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net





From markm68k at yahoo.com  Wed Oct 24 17:43:59 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Wed, 24 Oct 2001 00:43:59 -0700 (PDT)
Subject: unfilled options in readconf.c
In-Reply-To: <Pine.BSO.4.33.0110232117001.7621-100000@etoh.eviladmin.org>
Message-ID: <20011024074359.94865.qmail@web14501.mail.yahoo.com>

The option "host_key_alias" is purposely not filled by
fill_default_options() in the readconf.c file:

        /* options->host_key_alias should not be set
by default */


As a result, it causes problems (notably a bus error)
in sshconnect.c:

        if (options.host_key_alias != NULL) {
                host = options.host_key_alias;
                debug("using hostkeyalias: %s", host);
        }

When ssh tries to read the contents of
options.host_key_alias, it pukes.

So what happens now?


=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From markm68k at yahoo.com  Wed Oct 24 18:04:49 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Wed, 24 Oct 2001 01:04:49 -0700 (PDT)
Subject: unfilled options in readconf.c
Message-ID: <20011024080449.18494.qmail@web14509.mail.yahoo.com>

--- Mark Miller <markm68k at yahoo.com> wrote:
> So what happens now?

I am guessing that no other platform has seen this
problem and that Darwin / Mac OS X is the only one.

True?


=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From markus at openbsd.org  Wed Oct 24 18:30:51 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 10:30:51 +0200
Subject: disable features
Message-ID: <20011024103051.A15160@folly>

this (uncomplete) patch makes various features compile time
options and saves up to 24K in the resulting
ssh/sshd binaries. i don't know whether this
should be added to the CVS since it makes
the code less readable.

perhaps WITH_COMPRESSION should be added, since
it removes the dependency on libz

-m

Index: Makefile.inc
===================================================================
RCS file: /home/markus/cvs/ssh/Makefile.inc,v
retrieving revision 1.19
diff -u -r1.19 Makefile.inc
--- Makefile.inc	29 Jul 2001 14:00:07 -0000	1.19
+++ Makefile.inc	22 Oct 2001 18:57:12 -0000
@@ -10,7 +10,14 @@
 CDIAGFLAGS+=	-Wmissing-prototypes
 CDIAGFLAGS+=	-Wunused
 
-#DEBUG=-g
+DEBUG=-g
+
+#CFLAGS+=	-DWITH_AGENTFWD
+#CFLAGS+=	-DWITH_COMPRESSION
+#CFLAGS+=	-DWITH_DYNFWD
+#CFLAGS+=	-DWITH_PROTO13
+#CFLAGS+=	-DWITH_TCPFWD
+#CFLAGS+=	-DWITH_X11FWD
 
 #CFLAGS+=	-DSMARTCARD
 #LDADD+=	-lsectok
Index: auth-options.c
===================================================================
RCS file: /home/markus/cvs/ssh/auth-options.c,v
retrieving revision 1.20
diff -u -r1.20 auth-options.c
--- auth-options.c	30 Aug 2001 20:36:34 -0000	1.20
+++ auth-options.c	22 Oct 2001 18:26:52 -0000
@@ -53,7 +53,9 @@
 		xfree(forced_command);
 		forced_command = NULL;
 	}
+#ifdef WITH_TCPFWD
 	channel_clear_permitted_opens();
+#endif
 }
 
 /*
@@ -257,8 +259,10 @@
 				xfree(patterns);
 				goto bad_option;
 			}
+#ifdef WITH_TCPFWD
 			if (options.allow_tcp_forwarding)
 				channel_add_permitted_opens(host, port);
+#endif
 			xfree(patterns);
 			goto next_option;
 		}
Index: channels.c
===================================================================
RCS file: /home/markus/cvs/ssh/channels.c,v
retrieving revision 1.140
diff -u -r1.140 channels.c
--- channels.c	10 Oct 2001 22:18:47 -0000	1.140
+++ channels.c	22 Oct 2001 18:25:31 -0000
@@ -76,7 +76,7 @@
  */
 static int channel_max_fd = 0;
 
-
+#ifdef WITH_TCPFWD
 /* -- tcp forwarding */
 
 /*
@@ -102,8 +102,9 @@
  * anything after logging in anyway.
  */
 static int all_opens_permitted = 0;
+#endif
 
-
+#ifdef WITH_X11FWD
 /* -- X11 forwarding */
 
 /* Maximum number of fake X11 displays to try. */
@@ -122,8 +123,9 @@
  */
 static char *x11_fake_data = NULL;
 static u_int x11_fake_data_len;
+#endif
 
-
+#ifdef WITH_AGENTFWD
 /* -- agent forwarding */
 
 #define	NUM_SOCKS	10
@@ -131,12 +133,15 @@
 /* Name and directory of socket for authentication agent forwarding. */
 static char *auth_sock_name = NULL;
 static char *auth_sock_dir = NULL;
+#endif
 
 /* AF_UNSPEC or AF_INET or AF_INET6 */
 static int IPv4or6 = AF_UNSPEC;
 
+#ifdef WITH_TCPFWD
 /* helper */
 static void port_open_helper(Channel *c, char *rtype);
+#endif
 
 /* -- channel core */
 
@@ -678,6 +683,7 @@
 chan_fn *channel_pre[SSH_CHANNEL_MAX_TYPE];
 chan_fn *channel_post[SSH_CHANNEL_MAX_TYPE];
 
+#ifdef WITH_TCPFWD
 static void
 channel_pre_listener(Channel *c, fd_set * readset, fd_set * writeset)
 {
@@ -690,7 +696,9 @@
 	debug3("channel %d: waiting for connection", c->self);
 	FD_SET(c->sock, writeset);
 }
+#endif
 
+#ifdef WITH_PROTO13
 static void
 channel_pre_open_13(Channel *c, fd_set * readset, fd_set * writeset)
 {
@@ -699,6 +707,7 @@
 	if (buffer_len(&c->output) > 0)
 		FD_SET(c->sock, writeset);
 }
+#endif
 
 static void
 channel_pre_open_15(Channel *c, fd_set * readset, fd_set * writeset)
@@ -743,6 +752,7 @@
 	}
 }
 
+#ifdef WITH_PROTO13
 static void
 channel_pre_input_draining(Channel *c, fd_set * readset, fd_set * writeset)
 {
@@ -763,7 +773,9 @@
 	else
 		FD_SET(c->sock, writeset);
 }
+#endif
 
+#ifdef WITH_X11FWD
 /*
  * This is a special state for X11 authentication spoofing.  An opened X11
  * connection (when authentication spoofing is being done) remains in this
@@ -831,6 +843,7 @@
 	return 1;
 }
 
+#ifdef WITH_PROTO13
 static void
 channel_pre_x11_open_13(Channel *c, fd_set * readset, fd_set * writeset)
 {
@@ -855,6 +868,7 @@
 		packet_send();
 	}
 }
+#endif
 
 static void
 channel_pre_x11_open(Channel *c, fd_set * readset, fd_set * writeset)
@@ -876,7 +890,9 @@
 		debug("X11 closed %d i%d/o%d", c->self, c->istate, c->ostate);
 	}
 }
+#endif /* WITH_X11FWD */
 
+#ifdef WITH_DYNFWD
 /* try to decode a socks4 header */
 static int
 channel_decode_socks4(Channel *c, fd_set * readset, fd_set * writeset)
@@ -986,7 +1002,9 @@
 		port_open_helper(c, "direct-tcpip");
 	}
 }
+#endif
 
+#ifdef WITH_X11FWD
 /* This is our fake X11 server socket. */
 static void
 channel_post_x11_listener(Channel *c, fd_set * readset, fd_set * writeset)
@@ -1045,7 +1063,9 @@
 		xfree(remote_ipaddr);
 	}
 }
+#endif
 
+#ifdef WITH_TCPFWD
 static void
 port_open_helper(Channel *c, char *rtype)
 {
@@ -1158,7 +1178,9 @@
 		}
 	}
 }
+#endif /* WITH_TCPFWD */
 
+#ifdef WITH_AGENTFWD
 /*
  * This is the authentication agent socket listening for connections from
  * clients.
@@ -1202,7 +1224,9 @@
 		packet_send();
 	}
 }
+#endif /* WITH_AGENTFWD */
 
+#ifdef WITH_TCPFWD
 static void
 channel_post_connecting(Channel *c, fd_set * readset, fd_set * writeset)
 {
@@ -1249,6 +1273,7 @@
 		packet_send();
 	}
 }
+#endif /* WITH_TCPFWD */
 
 static int
 channel_handle_rfd(Channel *c, fd_set * readset, fd_set * writeset)
@@ -1423,6 +1448,7 @@
 	channel_check_window(c);
 }
 
+#ifdef WITH_PROTO13
 static void
 channel_post_output_drain_13(Channel *c, fd_set * readset, fd_set * writeset)
 {
@@ -1437,67 +1463,118 @@
 			buffer_consume(&c->output, len);
 	}
 }
+#endif
 
 static void
 channel_handler_init_20(void)
 {
 	channel_pre[SSH_CHANNEL_OPEN] =			&channel_pre_open_20;
-	channel_pre[SSH_CHANNEL_X11_OPEN] =		&channel_pre_x11_open;
+#ifdef WITH_TCPFWD
 	channel_pre[SSH_CHANNEL_PORT_LISTENER] =	&channel_pre_listener;
 	channel_pre[SSH_CHANNEL_RPORT_LISTENER] =	&channel_pre_listener;
-	channel_pre[SSH_CHANNEL_X11_LISTENER] =		&channel_pre_listener;
-	channel_pre[SSH_CHANNEL_AUTH_SOCKET] =		&channel_pre_listener;
 	channel_pre[SSH_CHANNEL_CONNECTING] =		&channel_pre_connecting;
+#ifdef WITH_DYNFWD
 	channel_pre[SSH_CHANNEL_DYNAMIC] =		&channel_pre_dynamic;
+#endif
+#endif
+#ifdef WITH_X11FWD
+	channel_pre[SSH_CHANNEL_X11_OPEN] =		&channel_pre_x11_open;
+	channel_pre[SSH_CHANNEL_X11_LISTENER] =		&channel_pre_listener;
+#endif
+#ifdef WITH_AGENTFWD
+	channel_pre[SSH_CHANNEL_AUTH_SOCKET] =		&channel_pre_listener;
+#endif
 
 	channel_post[SSH_CHANNEL_OPEN] =		&channel_post_open_2;
+#ifdef WITH_TCPFWD
 	channel_post[SSH_CHANNEL_PORT_LISTENER] =	&channel_post_port_listener;
 	channel_post[SSH_CHANNEL_RPORT_LISTENER] =	&channel_post_port_listener;
-	channel_post[SSH_CHANNEL_X11_LISTENER] =	&channel_post_x11_listener;
-	channel_post[SSH_CHANNEL_AUTH_SOCKET] =		&channel_post_auth_listener;
 	channel_post[SSH_CHANNEL_CONNECTING] =		&channel_post_connecting;
+#ifdef WITH_DYNFWD
 	channel_post[SSH_CHANNEL_DYNAMIC] =		&channel_post_open_2;
+#endif
+#endif
+#ifdef WITH_X11FWD
+	channel_post[SSH_CHANNEL_X11_LISTENER] =	&channel_post_x11_listener;
+#endif
+#ifdef WITH_AGENTFWD
+	channel_post[SSH_CHANNEL_AUTH_SOCKET] =		&channel_post_auth_listener;
+#endif
 }
 
+#ifdef WITH_PROTO13
 static void
 channel_handler_init_13(void)
 {
 	channel_pre[SSH_CHANNEL_OPEN] =			&channel_pre_open_13;
+#ifdef WITH_TCPFWD
+	channel_pre[SSH_CHANNEL_PORT_LISTENER] =	&channel_pre_listener;
+	channel_pre[SSH_CHANNEL_CONNECTING] =		&channel_pre_connecting;
+#ifdef WITH_DYNFWD
+	channel_pre[SSH_CHANNEL_DYNAMIC] =		&channel_pre_dynamic;
+#endif
+#endif
+#ifdef WITH_X11FWD
 	channel_pre[SSH_CHANNEL_X11_OPEN] =		&channel_pre_x11_open_13;
 	channel_pre[SSH_CHANNEL_X11_LISTENER] =		&channel_pre_listener;
-	channel_pre[SSH_CHANNEL_PORT_LISTENER] =	&channel_pre_listener;
+#endif
+#ifdef WITH_AGENTFWD
 	channel_pre[SSH_CHANNEL_AUTH_SOCKET] =		&channel_pre_listener;
+#endif
 	channel_pre[SSH_CHANNEL_INPUT_DRAINING] =	&channel_pre_input_draining;
 	channel_pre[SSH_CHANNEL_OUTPUT_DRAINING] =	&channel_pre_output_draining;
-	channel_pre[SSH_CHANNEL_CONNECTING] =		&channel_pre_connecting;
-	channel_pre[SSH_CHANNEL_DYNAMIC] =		&channel_pre_dynamic;
 
 	channel_post[SSH_CHANNEL_OPEN] =		&channel_post_open_1;
-	channel_post[SSH_CHANNEL_X11_LISTENER] =	&channel_post_x11_listener;
+#ifdef WITH_TCPFWD
 	channel_post[SSH_CHANNEL_PORT_LISTENER] =	&channel_post_port_listener;
-	channel_post[SSH_CHANNEL_AUTH_SOCKET] =		&channel_post_auth_listener;
-	channel_post[SSH_CHANNEL_OUTPUT_DRAINING] =	&channel_post_output_drain_13;
 	channel_post[SSH_CHANNEL_CONNECTING] =		&channel_post_connecting;
+#ifdef WITH_DYNFWD
 	channel_post[SSH_CHANNEL_DYNAMIC] =		&channel_post_open_1;
+#endif
+#endif
+#ifdef WITH_X11FWD
+	channel_post[SSH_CHANNEL_X11_LISTENER] =	&channel_post_x11_listener;
+#endif
+#ifdef WITH_AGENTFWD
+	channel_post[SSH_CHANNEL_AUTH_SOCKET] =		&channel_post_auth_listener;
+#endif
+	channel_post[SSH_CHANNEL_OUTPUT_DRAINING] =	&channel_post_output_drain_13;
 }
+#endif
 
 static void
 channel_handler_init_15(void)
 {
 	channel_pre[SSH_CHANNEL_OPEN] =			&channel_pre_open_15;
-	channel_pre[SSH_CHANNEL_X11_OPEN] =		&channel_pre_x11_open;
-	channel_pre[SSH_CHANNEL_X11_LISTENER] =		&channel_pre_listener;
+#ifdef WITH_TCPFWD
 	channel_pre[SSH_CHANNEL_PORT_LISTENER] =	&channel_pre_listener;
-	channel_pre[SSH_CHANNEL_AUTH_SOCKET] =		&channel_pre_listener;
 	channel_pre[SSH_CHANNEL_CONNECTING] =		&channel_pre_connecting;
+#ifdef WITH_DYNFWD
 	channel_pre[SSH_CHANNEL_DYNAMIC] =		&channel_pre_dynamic;
+#endif
+#endif
+#ifdef WITH_X11FWD
+	channel_pre[SSH_CHANNEL_X11_OPEN] =		&channel_pre_x11_open;
+	channel_pre[SSH_CHANNEL_X11_LISTENER] =		&channel_pre_listener;
+#endif
+#ifdef WITH_AGENTFWD
+	channel_pre[SSH_CHANNEL_AUTH_SOCKET] =		&channel_pre_listener;
+#endif
 
-	channel_post[SSH_CHANNEL_X11_LISTENER] =	&channel_post_x11_listener;
+#ifdef WITH_TCPFWD
 	channel_post[SSH_CHANNEL_PORT_LISTENER] =	&channel_post_port_listener;
-	channel_post[SSH_CHANNEL_AUTH_SOCKET] =		&channel_post_auth_listener;
-	channel_post[SSH_CHANNEL_OPEN] =		&channel_post_open_1;
 	channel_post[SSH_CHANNEL_CONNECTING] =		&channel_post_connecting;
+#ifdef WITH_DYNFWD
 	channel_post[SSH_CHANNEL_DYNAMIC] =		&channel_post_open_1;
+#endif
+#endif
+#ifdef WITH_X11FWD
+	channel_post[SSH_CHANNEL_X11_LISTENER] =	&channel_post_x11_listener;
+#endif
+#ifdef WITH_AGENTFWD
+	channel_post[SSH_CHANNEL_AUTH_SOCKET] =		&channel_post_auth_listener;
+#endif
+	channel_post[SSH_CHANNEL_OPEN] =		&channel_post_open_1;
 }
 
 static void
@@ -1510,8 +1587,10 @@
 	}
 	if (compat20)
 		channel_handler_init_20();
+#ifdef WITH_PROTO13
 	else if (compat13)
 		channel_handler_init_13();
+#endif
 	else
 		channel_handler_init_15();
 }
@@ -1806,6 +1885,7 @@
 
 }
 
+#ifdef WITH_PROTO13
 void
 channel_input_close(int type, int plen, void *ctxt)
 {
@@ -1843,6 +1923,7 @@
 		c->type = SSH_CHANNEL_OUTPUT_DRAINING;
 	}
 }
+#endif
 
 /* proto version 1.5 overloads CLOSE_CONFIRMATION with OCLOSE */
 void
@@ -1856,6 +1937,7 @@
 	chan_rcvd_oclose(c);
 }
 
+#ifdef WITH_PROTO13
 void
 channel_input_close_confirmation(int type, int plen, void *ctxt)
 {
@@ -1871,6 +1953,7 @@
 		    "non-closed channel %d (type %d).", id, c->type);
 	channel_free(c);
 }
+#endif
 
 void
 channel_input_open_confirmation(int type, int plen, void *ctxt)
@@ -2005,6 +2088,7 @@
 	c->remote_window += adjust;
 }
 
+#ifdef WITH_TCPFWD
 void
 channel_input_port_open(int type, int plen, void *ctxt)
 {
@@ -2042,7 +2126,7 @@
 	}
 	xfree(host);
 }
-
+#endif
 
 /* -- tcp forwarding */
 
@@ -2052,6 +2136,7 @@
 	IPv4or6 = af;
 }
 
+#ifdef WITH_X11FWD
 /*
  * Initiate forwarding of connections to local port "port" through the secure
  * channel to host:port from remote side.
@@ -2385,7 +2470,9 @@
 	}
 	return connect_to(host, port);
 }
+#endif /* WITH_X11FWD */
 
+#ifdef WITH_X11FWD
 /* -- X11 forwarding */
 
 /*
@@ -2656,6 +2743,7 @@
 	}
 	packet_send();
 }
+#endif /* WITH_X11FWD */
 
 /* dummy protocol handler that denies SSH-1 requests (agent/x11) */
 void
@@ -2679,6 +2767,7 @@
 	packet_send();
 }
 
+#ifdef WITH_X11FWD
 /*
  * Requests forwarding of X11 connections, generates fake authentication
  * data, and enables authentication spoofing.
@@ -2747,8 +2836,9 @@
 	packet_write_wait();
 	xfree(new_data);
 }
+#endif /* WITH_X11FWD */
 
-
+#ifdef WITH_AGENTFWD
 /* -- agent forwarding */
 
 /* Sends a message to the server to request authentication fd forwarding. */
@@ -2919,3 +3009,4 @@
 	}
 	packet_send();
 }
+#endif WITH_AGENTFWD
Index: clientloop.c
===================================================================
RCS file: /home/markus/cvs/ssh/clientloop.c,v
retrieving revision 1.84
diff -u -r1.84 clientloop.c
--- clientloop.c	11 Oct 2001 15:24:00 -0000	1.84
+++ clientloop.c	22 Oct 2001 18:23:38 -0000
@@ -1042,6 +1042,7 @@
 	quit_pending = 1;
 }
 
+#ifdef WITH_TCPFWD
 static Channel *
 client_request_forwarded_tcpip(const char *request_type, int rchan)
 {
@@ -1078,7 +1079,9 @@
 	xfree(listen_address);
 	return c;
 }
+#endif /* WITH_TCPFWD */
 
+#ifdef WITH_X11FWD
 static Channel*
 client_request_x11(const char *request_type, int rchan)
 {
@@ -1118,7 +1121,9 @@
 	c->force_drain = 1;
 	return c;
 }
+#endif /* WITH_X11FWD */
 
+#ifdef WITH_AGENTFWD
 static Channel*
 client_request_agent(const char *request_type, int rchan)
 {
@@ -1144,6 +1149,7 @@
 	c->force_drain = 1;
 	return c;
 }
+#endif
 
 /* XXXX move to generic input handler */
 static void
@@ -1165,11 +1171,17 @@
 	    ctype, rchan, rwindow, rmaxpack);
 
 	if (strcmp(ctype, "forwarded-tcpip") == 0) {
+#ifdef WITH_TCPFWD
 		c = client_request_forwarded_tcpip(ctype, rchan);
+#endif
 	} else if (strcmp(ctype, "x11") == 0) {
+#ifdef WITH_X11FWD
 		c = client_request_x11(ctype, rchan);
+#endif
 	} else if (strcmp(ctype, "auth-agent at openssh.com") == 0) {
+#ifdef WITH_AGENTFWD
 		c = client_request_agent(ctype, rchan);
+#endif
 	}
 /* XXX duplicate : */
 	if (c != NULL) {
@@ -1256,20 +1268,28 @@
 client_init_dispatch_13(void)
 {
 	dispatch_init(NULL);
+#ifdef WITH_PROTO13
 	dispatch_set(SSH_MSG_CHANNEL_CLOSE, &channel_input_close);
 	dispatch_set(SSH_MSG_CHANNEL_CLOSE_CONFIRMATION, &channel_input_close_confirmation);
+#endif
 	dispatch_set(SSH_MSG_CHANNEL_DATA, &channel_input_data);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure);
+#ifdef WITH_TCPFWD
 	dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open);
+#endif
 	dispatch_set(SSH_SMSG_EXITSTATUS, &client_input_exit_status);
 	dispatch_set(SSH_SMSG_STDERR_DATA, &client_input_stderr_data);
 	dispatch_set(SSH_SMSG_STDOUT_DATA, &client_input_stdout_data);
 
+#ifdef WITH_AGENTFWD
 	dispatch_set(SSH_SMSG_AGENT_OPEN, options.forward_agent ?
 	    &auth_input_open_request : &deny_input_open);
+#endif
+#ifdef WITH_X11FWD
 	dispatch_set(SSH_SMSG_X11_OPEN, options.forward_x11 ?
 	    &x11_input_open : &deny_input_open);
+#endif
 }
 static void
 client_init_dispatch_15(void)
Index: compress.c
===================================================================
RCS file: /home/markus/cvs/ssh/compress.c,v
retrieving revision 1.15
diff -u -r1.15 compress.c
--- compress.c	27 Sep 2001 11:58:16 -0000	1.15
+++ compress.c	22 Oct 2001 18:47:06 -0000
@@ -10,6 +10,7 @@
  * incompatible with the protocol description in the RFC file, it must be
  * called by a name other than "ssh" or "Secure Shell".
  */
+#ifdef WITH_COMPRESSION
 
 #include "includes.h"
 RCSID("$OpenBSD: compress.c,v 1.15 2001/09/27 11:58:16 markus Exp $");
@@ -154,3 +155,4 @@
 		}
 	}
 }
+#endif
Index: myproposal.h
===================================================================
RCS file: /home/markus/cvs/ssh/myproposal.h,v
retrieving revision 1.12
diff -u -r1.12 myproposal.h
--- myproposal.h	5 Mar 2001 15:56:16 -0000	1.12
+++ myproposal.h	22 Oct 2001 18:42:06 -0000
@@ -34,7 +34,11 @@
 	"hmac-md5,hmac-sha1,hmac-ripemd160," \
 	"hmac-ripemd160 at openssh.com," \
 	"hmac-sha1-96,hmac-md5-96"
+#ifdef WITH_COMPRESSION
 #define	KEX_DEFAULT_COMP	"none,zlib"
+#else
+#define	KEX_DEFAULT_COMP	"none"
+#endif
 #define	KEX_DEFAULT_LANG	""
 
 
Index: packet.c
===================================================================
RCS file: /home/markus/cvs/ssh/packet.c,v
retrieving revision 1.70
diff -u -r1.70 packet.c
--- packet.c	27 Sep 2001 11:59:37 -0000	1.70
+++ packet.c	22 Oct 2001 18:36:47 -0000
@@ -96,12 +96,14 @@
 /* Buffer for the incoming packet currently being processed. */
 static Buffer incoming_packet;
 
+#ifdef WITH_COMPRESSION
 /* Scratch buffer for packet compression/decompression. */
 static Buffer compression_buffer;
 static int compression_buffer_ready = 0;
 
 /* Flag indicating whether packet compression/decompression is enabled. */
 static int packet_compression = 0;
+#endif
 
 /* default maximum packet size */
 int max_packet_size = 32768;
@@ -233,10 +235,12 @@
 	buffer_free(&output);
 	buffer_free(&outgoing_packet);
 	buffer_free(&incoming_packet);
+#ifdef WITH_COMPRESSION
 	if (compression_buffer_ready) {
 		buffer_free(&compression_buffer);
 		buffer_compress_uninit();
 	}
+#endif
 }
 
 /* Sets remote side protocol flags. */
@@ -255,6 +259,7 @@
 	return remote_protocol_flags;
 }
 
+#ifdef WITH_COMPRESSION
 /*
  * Starts packet compression from the next packet on in both directions.
  * Level is compression level 1 (fastest) - 9 (slow, best) as in gzip.
@@ -279,6 +284,7 @@
 	buffer_compress_init_send(level);
 	buffer_compress_init_recv();
 }
+#endif
 
 /*
  * Causes any further packets to be encrypted using the given key.  The same
@@ -364,6 +370,7 @@
 	u_int checksum;
 	u_int32_t rand = 0;
 
+#ifdef WITH_COMPRESSION
 	/*
 	 * If using packet compression, compress the payload of the outgoing
 	 * packet.
@@ -379,6 +386,7 @@
 		buffer_append(&outgoing_packet, buffer_ptr(&compression_buffer),
 			      buffer_len(&compression_buffer));
 	}
+#endif
 	/* Compute packet length without padding (add checksum, remove padding). */
 	len = buffer_len(&outgoing_packet) + 4 - 8;
 
@@ -467,6 +475,7 @@
 	    enc->iv, enc->cipher->block_size);
 	memset(enc->iv,  0, enc->cipher->block_size);
 	memset(enc->key, 0, enc->cipher->key_len);
+#ifdef WITH_COMPRESSION
 	if (comp->type != 0 && comp->enabled == 0) {
 		packet_init_compression();
 		if (mode == MODE_OUT)
@@ -475,6 +484,7 @@
 			buffer_compress_init_recv();
 		comp->enabled = 1;
 	}
+#endif
 }
 
 /*
@@ -509,6 +519,7 @@
 	buffer_dump(&outgoing_packet);
 #endif
 
+#ifdef WITH_COMPRESSION
 	if (comp && comp->enabled) {
 		len = buffer_len(&outgoing_packet);
 		/* skip header, compress only payload */
@@ -522,6 +533,7 @@
 		DBG(debug("compression: raw %d compressed %d", len,
 		    buffer_len(&outgoing_packet)));
 	}
+#endif
 
 	/* sizeof (packet_len + pad_len + payload) */
 	len = buffer_len(&outgoing_packet);
@@ -749,6 +761,7 @@
 		packet_disconnect("Corrupted check bytes on input.");
 	buffer_consume_end(&incoming_packet, 4);
 
+#ifdef WITH_COMPRESSION
 	if (packet_compression) {
 		buffer_clear(&compression_buffer);
 		buffer_uncompress(&incoming_packet, &compression_buffer);
@@ -756,6 +769,7 @@
 		buffer_append(&incoming_packet, buffer_ptr(&compression_buffer),
 		    buffer_len(&compression_buffer));
 	}
+#endif
 	type = buffer_get_char(&incoming_packet);
 	*payload_len_ptr = buffer_len(&incoming_packet);
 	return type;
@@ -849,6 +863,7 @@
 	buffer_consume(&incoming_packet, 4 + 1);
 	buffer_consume_end(&incoming_packet, padlen);
 
+#ifdef WITH_COMPRESSION
 	DBG(debug("input: len before de-compress %d", buffer_len(&incoming_packet)));
 	if (comp && comp->enabled) {
 		buffer_clear(&compression_buffer);
@@ -858,6 +873,7 @@
 		    buffer_len(&compression_buffer));
 		DBG(debug("input: len after de-compress %d", buffer_len(&incoming_packet)));
 	}
+#endif
 	/*
 	 * get packet type, implies consume.
 	 * return length of payload (without type field)
Index: serverloop.c
===================================================================
RCS file: /home/markus/cvs/ssh/serverloop.c,v
retrieving revision 1.82
diff -u -r1.82 serverloop.c
--- serverloop.c	10 Oct 2001 22:18:47 -0000	1.82
+++ serverloop.c	22 Oct 2001 18:24:43 -0000
@@ -790,6 +790,7 @@
 		pty_change_window_size(fdin, row, col, xpixel, ypixel);
 }
 
+#ifdef WITH_TCPFWD
 static Channel *
 server_request_direct_tcpip(char *ctype)
 {
@@ -822,6 +823,7 @@
 	}
 	return c;
 }
+#endif
 
 static Channel *
 server_request_session(char *ctype)
@@ -874,8 +876,10 @@
 
 	if (strcmp(ctype, "session") == 0) {
 		c = server_request_session(ctype);
+#ifdef WITH_TCPFWD
 	} else if (strcmp(ctype, "direct-tcpip") == 0) {
 		c = server_request_direct_tcpip(ctype);
+#endif
 	}
 	if (c != NULL) {
 		debug("server_input_channel_open: confirm %s", ctype);
@@ -904,6 +908,7 @@
 	xfree(ctype);
 }
 
+#ifdef WITH_TCPFWD
 static void
 server_input_global_request(int type, int plen, void *ctxt)
 {
@@ -953,6 +958,7 @@
 	}
 	xfree(rtype);
 }
+#endif
 
 static void
 server_init_dispatch_20(void)
@@ -968,7 +974,9 @@
 	dispatch_set(SSH2_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure);
 	dispatch_set(SSH2_MSG_CHANNEL_REQUEST, &channel_input_channel_request);
 	dispatch_set(SSH2_MSG_CHANNEL_WINDOW_ADJUST, &channel_input_window_adjust);
+#ifdef WITH_TCPFWD
 	dispatch_set(SSH2_MSG_GLOBAL_REQUEST, &server_input_global_request);
+#endif
 	/* client_alive */
 	dispatch_set(SSH2_MSG_CHANNEL_FAILURE, &server_input_channel_failure);
 	/* rekeying */
@@ -982,12 +990,16 @@
 	dispatch_set(SSH_CMSG_EOF, &server_input_eof);
 	dispatch_set(SSH_CMSG_STDIN_DATA, &server_input_stdin_data);
 	dispatch_set(SSH_CMSG_WINDOW_SIZE, &server_input_window_size);
+#ifdef WITH_PROTO13
 	dispatch_set(SSH_MSG_CHANNEL_CLOSE, &channel_input_close);
 	dispatch_set(SSH_MSG_CHANNEL_CLOSE_CONFIRMATION, &channel_input_close_confirmation);
+#endif
 	dispatch_set(SSH_MSG_CHANNEL_DATA, &channel_input_data);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure);
+#ifdef WITH_TCPFWD
 	dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open);
+#endif
 }
 static void
 server_init_dispatch_15(void)
Index: session.c
===================================================================
RCS file: /home/markus/cvs/ssh/session.c,v
retrieving revision 1.108
diff -u -r1.108 session.c
--- session.c	11 Oct 2001 13:45:21 -0000	1.108
+++ session.c	22 Oct 2001 18:37:43 -0000
@@ -148,18 +148,22 @@
 	}
 #endif
 #endif
+#ifdef WITH_TCPFWD
 	/* setup the channel layer */
 	if (!no_port_forwarding_flag && options.allow_tcp_forwarding)
 		channel_permit_all_opens();
+#endif
 
 	if (compat20)
 		do_authenticated2(authctxt);
 	else
 		do_authenticated1(authctxt);
 
+#ifdef WITH_AGENTFWD
 	/* remove agent socket */
 	if (auth_get_socket_name())
 		auth_sock_cleanup_proc(authctxt->pw);
+#endif
 #ifdef KRB4
 	if (options.kerberos_ticket_cleanup)
 		krb4_cleanup_proc(authctxt);
@@ -181,9 +185,15 @@
 {
 	Session *s;
 	char *command;
-	int success, type, plen, screen_flag;
+	int success, type, plen;
+	u_int dlen;
+#ifdef WITH_COMPRESSION
 	int compression_level = 0, enable_compression_after_reply = 0;
-	u_int proto_len, data_len, dlen;
+#endif
+#ifdef WITH_X11FWD
+	u_int proto_len, data_len;
+	int screen_flag;
+#endif
 
 	s = session_new();
 	s->authctxt = authctxt;
@@ -202,6 +212,7 @@
 		/* Process the packet. */
 		switch (type) {
 		case SSH_CMSG_REQUEST_COMPRESSION:
+#ifdef WITH_COMPRESSION
 			packet_integrity_check(plen, 4, type);
 			compression_level = packet_get_int();
 			if (compression_level < 1 || compression_level > 9) {
@@ -212,6 +223,7 @@
 			/* Enable compression after we have responded with SUCCESS. */
 			enable_compression_after_reply = 1;
 			success = 1;
+#endif
 			break;
 
 		case SSH_CMSG_REQUEST_PTY:
@@ -219,6 +231,7 @@
 			break;
 
 		case SSH_CMSG_X11_REQUEST_FORWARDING:
+#ifdef WITH_X11FWD
 			s->auth_proto = packet_get_string(&proto_len);
 			s->auth_data = packet_get_string(&data_len);
 
@@ -242,18 +255,22 @@
 				s->auth_proto = NULL;
 				s->auth_data = NULL;
 			}
+#endif
 			break;
 
 		case SSH_CMSG_AGENT_REQUEST_FORWARDING:
+#ifdef WITH_AGENTFWD
 			if (no_agent_forwarding_flag || compat13) {
 				debug("Authentication agent forwarding not permitted for this authentication.");
 				break;
 			}
 			debug("Received authentication agent forwarding request.");
 			success = auth_input_request_forwarding(s->pw);
+#endif
 			break;
 
 		case SSH_CMSG_PORT_FORWARD_REQUEST:
+#ifdef WITH_TCPFWD
 			if (no_port_forwarding_flag) {
 				debug("Port forwarding not permitted for this authentication.");
 				break;
@@ -265,6 +282,7 @@
 			debug("Received TCP/IP port forwarding request.");
 			channel_input_port_forward_request(s->pw->pw_uid == 0, options.gateway_ports);
 			success = 1;
+#endif
 			break;
 
 		case SSH_CMSG_MAX_PACKET_SIZE:
@@ -349,11 +367,13 @@
 		packet_send();
 		packet_write_wait();
 
+#ifdef WITH_COMPRESSION
 		/* Enable compression now that we have replied if appropriate. */
 		if (enable_compression_after_reply) {
 			enable_compression_after_reply = 0;
 			packet_start_compression(compression_level);
 		}
+#endif
 	}
 }
 
@@ -912,9 +932,11 @@
 		child_set_env(&env, &envsize, "KRB5CCNAME",
 			      s->authctxt->krb5_ticket_file);
 #endif
+#ifdef WITH_AGENTFWD
 	if (auth_get_socket_name() != NULL)
 		child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME,
 			      auth_get_socket_name());
+#endif
 
 	/* read $HOME/.ssh/environment. */
 	if (!options.use_login) {
@@ -1326,6 +1348,7 @@
 	return success;
 }
 
+#ifdef WITH_X11FWD
 static int
 session_x11_req(Session *s)
 {
@@ -1346,6 +1369,7 @@
 	}
 	return success;
 }
+#endif
 
 static int
 session_shell_req(Session *s)
@@ -1366,6 +1390,7 @@
 	return 1;
 }
 
+#ifdef WITH_AGENTFWD
 static int
 session_auth_agent_req(Session *s)
 {
@@ -1382,6 +1407,7 @@
 		return auth_input_request_forwarding(s->pw);
 	}
 }
+#endif
 
 void
 session_input_channel_req(int id, void *arg)
@@ -1417,10 +1443,14 @@
 			success = session_exec_req(s);
 		} else if (strcmp(rtype, "pty-req") == 0) {
 			success =  session_pty_req(s);
+#ifdef WITH_X11FWD
 		} else if (strcmp(rtype, "x11-req") == 0) {
 			success = session_x11_req(s);
+#endif
+#ifdef WITH_AGENTFWD
 		} else if (strcmp(rtype, "auth-agent-req at openssh.com") == 0) {
 			success = session_auth_agent_req(s);
+#endif
 		} else if (strcmp(rtype, "subsystem") == 0) {
 			success = session_subsystem_req(s);
 		}
@@ -1640,6 +1670,7 @@
 		setproctitle("%s@%s", s->pw->pw_name, session_tty_list());
 }
 
+#ifdef WITH_X11FWD
 int
 session_setup_x11fwd(Session *s)
 {
@@ -1674,6 +1705,7 @@
 	}
 	return 1;
 }
+#endif
 
 static void
 do_authenticated2(Authctxt *authctxt)
Index: ssh.c
===================================================================
RCS file: /home/markus/cvs/ssh/ssh.c,v
retrieving revision 1.147
diff -u -r1.147 ssh.c
--- ssh.c	8 Oct 2001 19:05:05 -0000	1.147
+++ ssh.c	22 Oct 2001 18:40:13 -0000
@@ -772,6 +772,7 @@
 	return exit_status;
 }
 
+#ifdef WITH_X11FWD
 static void
 x11_get_proto(char *proto, int proto_len, char *data, int data_len)
 {
@@ -810,10 +811,12 @@
 		}
 	}
 }
+#endif
 
 static void
 ssh_init_forwarding(void)
 {
+#ifdef WITH_TCPFWD
 	int success = 0;
 	int i;
 
@@ -843,6 +846,7 @@
 		    options.remote_forwards[i].host,
 		    options.remote_forwards[i].host_port);
 	}
+#endif
 }
 
 static void
@@ -868,6 +872,7 @@
 	struct winsize ws;
 	char *cp;
 
+#ifdef WITH_COMPRESSION
 	/* Enable compression if requested. */
 	if (options.compression) {
 		debug("Requesting compression at level %d.", options.compression_level);
@@ -888,6 +893,7 @@
 		else
 			packet_disconnect("Protocol error waiting for compression response.");
 	}
+#endif
 	/* Allocate a pseudo tty if appropriate. */
 	if (tty_flag) {
 		debug("Requesting pty.");
@@ -927,6 +933,7 @@
 		else
 			packet_disconnect("Protocol error waiting for pty request response.");
 	}
+#ifdef WITH_X11FWD
 	/* Request X11 forwarding if enabled and DISPLAY is set. */
 	if (options.forward_x11 && getenv("DISPLAY") != NULL) {
 		char proto[512], data[512];
@@ -946,12 +953,14 @@
 			packet_disconnect("Protocol error waiting for X11 forwarding");
 		}
 	}
+#endif
 	/* Tell the packet module whether this is an interactive session. */
 	packet_set_interactive(interactive);
 
 	/* Request authentication agent forwarding if appropriate. */
 	check_agent_present();
 
+#ifdef WITH_AGENTFWD
 	if (options.forward_agent) {
 		debug("Requesting authentication agent forwarding.");
 		auth_request_forwarding();
@@ -962,6 +971,7 @@
 		if (type != SSH_SMSG_SUCCESS)
 			log("Warning: Remote host denied authentication agent forwarding.");
 	}
+#endif
 
 	/* Initiate port forwardings. */
 	ssh_init_forwarding();
@@ -1043,6 +1053,7 @@
 		interactive = 1;
 		/* XXX wait for reply */
 	}
+#ifdef WITH_X11FWD
 	if (options.forward_x11 &&
 	    getenv("DISPLAY") != NULL) {
 		char proto[512], data[512];
@@ -1054,13 +1065,16 @@
 		interactive = 1;
 		/* XXX wait for reply */
 	}
+#endif
 
+#ifdef WITH_X11FWD
 	check_agent_present();
 	if (options.forward_agent) {
 		debug("Requesting authentication agent forwarding.");
 		channel_request_start(id, "auth-agent-req at openssh.com", 0);
 		packet_send();
 	}
+#endif
 
 	len = buffer_len(&command);
 	if (len > 0) {
Index: sshconnect2.c
===================================================================
RCS file: /home/markus/cvs/ssh/sshconnect2.c,v
retrieving revision 1.83
diff -u -r1.83 sshconnect2.c
--- sshconnect2.c	6 Oct 2001 11:18:19 -0000	1.83
+++ sshconnect2.c	24 Oct 2001 08:07:02 -0000
@@ -99,6 +99,7 @@
 	    compat_cipher_proposal(myproposal[PROPOSAL_ENC_ALGS_CTOS]);
 	myproposal[PROPOSAL_ENC_ALGS_STOC] =
 	    compat_cipher_proposal(myproposal[PROPOSAL_ENC_ALGS_STOC]);
+#ifdef WITH_COMPRESSION
 	if (options.compression) {
 		myproposal[PROPOSAL_COMP_ALGS_CTOS] =
 		myproposal[PROPOSAL_COMP_ALGS_STOC] = "zlib";
@@ -106,6 +107,7 @@
 		myproposal[PROPOSAL_COMP_ALGS_CTOS] =
 		myproposal[PROPOSAL_COMP_ALGS_STOC] = "none";
 	}
+#endif
 	if (options.macs != NULL) {
 		myproposal[PROPOSAL_MAC_ALGS_CTOS] =
 		myproposal[PROPOSAL_MAC_ALGS_STOC] = options.macs;


From markm68k at yahoo.com  Wed Oct 24 18:35:12 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Wed, 24 Oct 2001 01:35:12 -0700 (PDT)
Subject: unfilled options in readconf.c
Message-ID: <20011024083512.95281.qmail@web14502.mail.yahoo.com>

This is part of the debug output:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 134/256
debug1: bits set: 502/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
zsh: 16902 bus error  ./ssh -v localhost




This is the backtrace:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at
0x00000005

Thread 0:
 #0   0x700013e0 in strlen
 #1   0x700024a4 in vfprintf
 #2   0x70012e80 in vsnprintf
 #3   0x0001474c in do_log
 #4   0x00014248 in debug
 #5   0x00005638 in check_host_key
 #6   0x00005cb0 in verify_host_key
 #7   0x00007200 in verify_hot_key_callback
 #8   0x00024f5c in kexgex_client
 #9   0x000255b8 in kexgex
 #10  0x0001ef54 in kex_kexinit_finish
 #11  0x0001ee50 in kex_input_kexinit
 #12  0x00014918 in dispatch_run
 #13  0x0000737c in ssh_kex2
 #14  0x00005dcc in ssh_login
 #15  0x00003908 in main
 #16  0x0000233c in _start
 #17  0x0000216c in start


=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From Alexander.Dost at drkw.com  Wed Oct 24 18:46:57 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Wed, 24 Oct 2001 10:46:57 +0200
Subject: Another round of testing calls.
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BBF8@ibfftc0006.is.de.dresdnerkb.com>

Is the problem with clear-text passwords after using the kludge on Sol8
known and will it be fixed ?
I didn't see any reply on this problem.

- Alex

> -----Original Message-----
> From:	mouring at etoh.eviladmin.org [SMTP:mouring at etoh.eviladmin.org]
> Sent:	Tuesday, October 23, 2001 18:26
> To:	openssh-unix-dev at mindrot.org
> Subject:	Another round of testing calls.
> 
> 
> Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
> required.  *WHAT* other issues *MUST* be address before 3.0 which is
> approaching fast?
> 
> Those running NeXTStep I need conformation that it works under NeXT.  My
> current Slab is packed in a storage unit due to a fire in my apartment
> complex (happened above me so I'm wrapping up dealing with that crap =).
> 
> - Ben


From strube at physik3.gwdg.de  Wed Oct 24 18:51:57 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Wed, 24 Oct 2001 10:51:57 +0200 (MET DST)
Subject: Inconsistent server/client configuration
Message-ID: <200110240851.KAA17099@marc.physik3.gwdg.de>

It appears somewhat inconsistent to me that parameter HostKey is configurable
on the server side but fixed on the client side.
On the client, always _PATH_HOST_KEY_FILE, _PATH_HOST_DSA_KEY_FILE,
_PATH_HOST_RSA_KEY_FILE are used (in this order), whereas on the server,
the paths can be specified by up to three HostKey options as arbitrary names
in arbitrary sequence.
Similarly, option GlobalKnownHostsFile is configurable for the client only
but fixed as _PATH_SSH_SYSTEM_HOSTFILE for the server. (Well, here the meaning
is slightly different, thus this may be o.k.)


From markus at openbsd.org  Wed Oct 24 18:52:40 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 10:52:40 +0200
Subject: unfilled options in readconf.c
In-Reply-To: <20011024074359.94865.qmail@web14501.mail.yahoo.com>; from markm68k@yahoo.com on Wed, Oct 24, 2001 at 12:43:59AM -0700
References: <Pine.BSO.4.33.0110232117001.7621-100000@etoh.eviladmin.org> <20011024074359.94865.qmail@web14501.mail.yahoo.com>
Message-ID: <20011024105240.A13279@faui02.informatik.uni-erlangen.de>

On Wed, Oct 24, 2001 at 12:43:59AM -0700, Mark Miller wrote:
> The option "host_key_alias" is purposely not filled by
> fill_default_options() in the readconf.c file:
> 
>         /* options->host_key_alias should not be set
> by default */

but check also:

initialize_options(Options * options)
        options->host_key_alias = NULL;

so it's set to NULL by default and not overwritten in fill_default_options()

what is host_key_alias set to when it crashes.

-m


From Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct 24 19:46:37 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Wed, 24 Oct 2001 11:46:37 +0200
Subject: disable features
In-Reply-To: <20011024103051.A15160@folly>
References: <20011024103051.A15160@folly>
Message-ID: <20011024114637.A20236@serv01.aet.tu-cottbus.de>

On Wed, Oct 24, 2001 at 10:30:51AM +0200, Markus Friedl wrote:
> this (uncomplete) patch makes various features compile time
> options and saves up to 24K in the resulting
> ssh/sshd binaries. i don't know whether this
> should be added to the CVS since it makes
> the code less readable.

Please allow me a personal comment:
OpenSSL is full of options like these (even though they are treated
the other way round: we have NO_* options to explicitly disable
features). If you ask me: it is pain in the a*. Don't do it, if
it is not really necessary for a particular reason, say patents.
Fortunately, 99% of all OpenSSL users compile without touching these
options, just on some platforms some features are not supported.
I am too lazy to check out the reducement in size and while I hate
creeping featurism, I do think that the tradeoff between size of
the executables and simplicity (and readability) of the code in this
case is not worth the hassle. It is more or less impossible to buy
harddisks below 10GB these days. (Well, I am writing this message
in front of a 10 year old HP-9000/710 with 50MHz and 64MB RAM, but
I still don't care about the 24k you mention :-)

Consider a ssh[d] that has been compiled without X11 forwarding.
Will it require a special ssh[d]_config without the X11Forwarding
keyword (because X11 forwarding is not supported and it should thus
trigger an error message if used)? It will mean that we will not only
have to ask for platforms when bugs are reported but also have to consider
that some option was (not) compiled in...
 
> perhaps WITH_COMPRESSION should be added, since
> it removes the dependency on libz
Maybe yes. However: on all platforms currently supported by OpenSSH
libz is available anyway...

Just speaking for myself,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From johan.adolfsson at axis.com  Wed Oct 24 20:03:20 2001
From: johan.adolfsson at axis.com (Johan Adolfsson)
Date: Wed, 24 Oct 2001 12:03:20 +0200
Subject: disable features
References: <20011024103051.A15160@folly> <20011024114637.A20236@serv01.aet.tu-cottbus.de>
Message-ID: <24b501c15c73$1c2adc90$0a070d0a@axis.se>

For embedded applications the size matters, 
we're talking ~2MB flash memory and 8-16 MB RAM, 
not 10GB harddisks and >64MB :-)
so I would like to see this included. 

I agree that the options in OpenSSL is sort of a pain in the a**, 
but the problem is to find all the possible fetures you can turn 
off and still get a usable system (e.g. for https usage and still be 
compatible with the majority of browsers) :-)

/Johan
 
----- Original Message ----- 
From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
To: <openssh-unix-dev at mindrot.org>; <openssh at openbsd.org>
Sent: Wednesday, October 24, 2001 11:46
Subject: Re: disable features


> On Wed, Oct 24, 2001 at 10:30:51AM +0200, Markus Friedl wrote:
> > this (uncomplete) patch makes various features compile time
> > options and saves up to 24K in the resulting
> > ssh/sshd binaries. i don't know whether this
> > should be added to the CVS since it makes
> > the code less readable.
> 
> Please allow me a personal comment:
> OpenSSL is full of options like these (even though they are treated
> the other way round: we have NO_* options to explicitly disable
> features). If you ask me: it is pain in the a*. Don't do it, if
> it is not really necessary for a particular reason, say patents.
> Fortunately, 99% of all OpenSSL users compile without touching these
> options, just on some platforms some features are not supported.
> I am too lazy to check out the reducement in size and while I hate
> creeping featurism, I do think that the tradeoff between size of
> the executables and simplicity (and readability) of the code in this
> case is not worth the hassle. It is more or less impossible to buy
> harddisks below 10GB these days. (Well, I am writing this message
> in front of a 10 year old HP-9000/710 with 50MHz and 64MB RAM, but
> I still don't care about the 24k you mention :-)
> 
> Consider a ssh[d] that has been compiled without X11 forwarding.
> Will it require a special ssh[d]_config without the X11Forwarding
> keyword (because X11 forwarding is not supported and it should thus
> trigger an error message if used)? It will mean that we will not only
> have to ask for platforms when bugs are reported but also have to consider
> that some option was (not) compiled in...
>  
> > perhaps WITH_COMPRESSION should be added, since
> > it removes the dependency on libz
> Maybe yes. However: on all platforms currently supported by OpenSSH
> libz is available anyway...
> 
> Just speaking for myself,
> Lutz
> -- 
> Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
> BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
> Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
> Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153
> 



From ed at UDel.Edu  Wed Oct 24 23:27:28 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 09:27:28 -0400 (EDT)
Subject: Another round of testing calls.
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BBF8@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <Pine.SOL.4.30.0110240927150.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Dost, Alexander wrote:

> Date: Wed, 24 Oct 2001 10:46:57 +0200
> From: "Dost, Alexander" <Alexander.Dost at drkw.com>
> To: openssh-unix-dev at mindrot.org
> Subject: RE: Another round of testing calls.
>
> Is the problem with clear-text passwords after using the kludge on Sol8
> known and will it be fixed ?
> I didn't see any reply on this problem.

What problem do you mean?

Thanks,

	Ed

>
> - Alex
>
> > -----Original Message-----
> > From:	mouring at etoh.eviladmin.org [SMTP:mouring at etoh.eviladmin.org]
> > Sent:	Tuesday, October 23, 2001 18:26
> > To:	openssh-unix-dev at mindrot.org
> > Subject:	Another round of testing calls.
> >
> >
> > Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
> > required.  *WHAT* other issues *MUST* be address before 3.0 which is
> > approaching fast?
> >
> > Those running NeXTStep I need conformation that it works under NeXT.  My
> > current Slab is packed in a storage unit due to a fire in my apartment
> > complex (happened above me so I'm wrapping up dealing with that crap =).
> >
> > - Ben
>

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  Wed Oct 24 23:35:22 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 09:35:22 -0400 (EDT)
Subject: disable features
In-Reply-To: <20011024114637.A20236@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Lutz Jaenicke wrote:

> Consider a ssh[d] that has been compiled without X11 forwarding.

Speaking of X11Forwarding... is there any particular reason that somewhere
between v2.9p2 and v2.9.9p2 there has been a change to the stock
sshd_config to disable X11Forwarding?

Also, is there any particular reason that authentication forwarding has
been disabled in 2.X (I'm not sure when, execpt that every since we've
been trying out 2.X it has been disabled by default).

In addition, if there is some reason not to use these features (bugs,
unreasonable security risks, etc.)... please let me know.

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 Alexander.Dost at drkw.com  Wed Oct 24 23:47:55 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Wed, 24 Oct 2001 15:47:55 +0200
Subject: Another round of testing calls.
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BBF9@ibfftc0006.is.de.dresdnerkb.com>

I compiled OpenSSH 2.9.9p2 on solaris 8
--with-pam --with-tcp-wrappers
The PAM_TTY_KLUDGE was needed so that password expiration check was done.
But after the message 'password expired, please enter login password', the
pasword now typed is clear-text and not hidden on the screen. Furthermore on
my system the changing of the password failed with a message of something
about removing root credentials and breaking secure rpc...
I posted a message recently with the screenshot of this message. (expired
password problems... from Oct 29, 09:24 number 122 on the web-page).

Alex

> -----Original Message-----
> From:	Ed Phillips [SMTP:ed at UDel.Edu]
> Sent:	Wednesday, October 24, 2001 15:27
> To:	Dost, Alexander
> Cc:	openssh-unix-dev at mindrot.org
> Subject:	RE: Another round of testing calls.
> 
> On Wed, 24 Oct 2001, Dost, Alexander wrote:
> 
> > Date: Wed, 24 Oct 2001 10:46:57 +0200
> > From: "Dost, Alexander" <Alexander.Dost at drkw.com>
> > To: openssh-unix-dev at mindrot.org
> > Subject: RE: Another round of testing calls.
> >
> > Is the problem with clear-text passwords after using the kludge on Sol8
> > known and will it be fixed ?
> > I didn't see any reply on this problem.
> 
> What problem do you mean?
> 
> Thanks,
> 
> 	Ed
> 
> >
> > - Alex
> >
> > > -----Original Message-----
> > > From:	mouring at etoh.eviladmin.org [SMTP:mouring at etoh.eviladmin.org]
> > > Sent:	Tuesday, October 23, 2001 18:26
> > > To:	openssh-unix-dev at mindrot.org
> > > Subject:	Another round of testing calls.
> > >
> > >
> > > Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
> > > required.  *WHAT* other issues *MUST* be address before 3.0 which is
> > > approaching fast?
> > >
> > > Those running NeXTStep I need conformation that it works under NeXT.
> My
> > > current Slab is packed in a storage unit due to a fire in my apartment
> > > complex (happened above me so I'm wrapping up dealing with that crap
> =).
> > >
> > > - Ben
> >
> 
> 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 a_ghsek at yahoo.co.in  Wed Oct 24 23:58:21 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 24 Oct 2001 14:58:21 +0100 (BST)
Subject: sftp interactive mode on LynxOS
Message-ID: <20011024135821.88652.qmail@web8004.mail.in.yahoo.com>

Hi,
  I work on openssh-2.9p2 installed on LynxOS i386
system. sshd, ssh, scp and sftp-server all work fine.
The problem is sftp client, in interactive mode, exits
after authentication printing the sftp prompt. sftp
client works fine in non-interactive mode.
i.e.,
lynxos>sftp hari at linuxsystem:test 
works fine
But,
lynxos>sftp hari at linuxsystem
...
sftp>
lynxos>
Any help, as to why sftp exits in interactive mode.
-Hari.

____________________________________________________
       *NEW*   Yahoo! Messenger for SMS   *NEW*
              Now on your ORANGE phone
 Visit http://in.mobile.yahoo.com/smsmgr_signin.html


From markus at openbsd.org  Wed Oct 24 23:59:29 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 15:59:29 +0200
Subject: hanging on logout, can't background client
In-Reply-To: <20011023184003.A19854@disaster.jaj.com>; from pedwards@disaster.jaj.com on Tue, Oct 23, 2001 at 06:40:03PM -0400
References: <20011023184003.A19854@disaster.jaj.com>
Message-ID: <20011024155929.A11792@folly>

why don't you start the xterm with
	$ ssh -f host xterm

see ssh(1)

     -f      Requests ssh to go to background just before command execution.
             This is useful if ssh is going to ask for passwords or passphras-
             es, but the user wants it in the background.  This implies -n.
             The recommended way to start X11 programs at a remote site is
             with something like ssh -f host xterm.


From markus at openbsd.org  Thu Oct 25 00:03:17 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 16:03:17 +0200
Subject: Inconsistent server/client configuration
In-Reply-To: <200110240851.KAA17099@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Wed, Oct 24, 2001 at 10:51:57AM +0200
References: <200110240851.KAA17099@marc.physik3.gwdg.de>
Message-ID: <20011024160317.B11792@folly>

your mail is missing many details, but i assume you are talking
about hostbased authentication.

On Wed, Oct 24, 2001 at 10:51:57AM +0200, Hans Werner Strube wrote:
> It appears somewhat inconsistent to me that parameter HostKey is configurable
> on the server side but fixed on the client side.
> On the client, always _PATH_HOST_KEY_FILE, _PATH_HOST_DSA_KEY_FILE,
> _PATH_HOST_RSA_KEY_FILE are used (in this order), whereas on the server,
> the paths can be specified by up to three HostKey options as arbitrary names
> in arbitrary sequence.

because the client is setuid root. you don't want to make
ssh read every private key on the system.

the client _could_ get the hostkey pathnames from sshd_config, 
but then you have to hardcode another filename.

-m


From markus at openbsd.org  Thu Oct 25 00:06:20 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 16:06:20 +0200
Subject: Another round of testing calls.
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BBF8@ibfftc0006.is.de.dresdnerkb.com>; from Alexander.Dost@drkw.com on Wed, Oct 24, 2001 at 10:46:57AM +0200
References: <3E16581537ABE44EB18C5206CE79F26B89BBF8@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <20011024160620.C11792@folly>

On Wed, Oct 24, 2001 at 10:46:57AM +0200, Dost, Alexander wrote:
> Is the problem with clear-text passwords after using the kludge on Sol8
> known and will it be fixed ?
> I didn't see any reply on this problem.

this is probably a bug in the PAM: either they should
not depend on the TTY kludge or not ask for a password
if there is not TYY.

-m


From a_ghsek at yahoo.co.in  Thu Oct 25 00:22:30 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Wed, 24 Oct 2001 15:22:30 +0100 (BST)
Subject: sftp interactive mode in LynxOS
Message-ID: <20011024142230.90161.qmail@web8005.mail.in.yahoo.com>

Hi,
  I work on openssh-2.9p2 installed on LynxOS i386
system. sshd, ssh, scp and sftp-server all work fine.
The problem is sftp client, in interactive mode, exits
after authentication printing the sftp prompt. sftp
client works fine in non-interactive mode.
i.e.,
lynxos>sftp hari at linuxsystem:test 
...
lynxos>
works fine
But,
lynxos>sftp hari at linuxsystem
...
sftp>
lynxos>
Any help, as to why sftp exits in interactive mode.
-Hari.

____________________________________________________________
Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com


From mouring at etoh.eviladmin.org  Thu Oct 25 00:27:48 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 24 Oct 2001 09:27:48 -0500 (CDT)
Subject: Another round of testing calls.
In-Reply-To: <20011024160620.C11792@folly>
Message-ID: <Pine.BSO.4.33.0110240926080.7277-100000@etoh.eviladmin.org>


If PAM is doing the password change, then I have to agree with Markus.
Could one of our Lurking Sun experts reproduce this and check if there is
a bug in their PAM code or if we are missing a bit of code?

- Ben

On Wed, 24 Oct 2001, Markus Friedl wrote:

> On Wed, Oct 24, 2001 at 10:46:57AM +0200, Dost, Alexander wrote:
> > Is the problem with clear-text passwords after using the kludge on Sol8
> > known and will it be fixed ?
> > I didn't see any reply on this problem.
>
> this is probably a bug in the PAM: either they should
> not depend on the TTY kludge or not ask for a password
> if there is not TYY.
>
> -m
>



From strube at physik3.gwdg.de  Thu Oct 25 00:41:02 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Wed, 24 Oct 2001 16:41:02 +0200 (MET DST)
Subject: Inconsistent server/client configuration
Message-ID: <200110241441.QAA17440@marc.physik3.gwdg.de>

> your mail is missing many details, but i assume you are talking
> about hostbased authentication.
> 
> On Wed, Oct 24, 2001 at 10:51:57AM +0200, Hans Werner Strube wrote:
> > It appears somewhat inconsistent to me that parameter HostKey is configurable
> > on the server side but fixed on the client side.
> > On the client, always _PATH_HOST_KEY_FILE, _PATH_HOST_DSA_KEY_FILE,
> > _PATH_HOST_RSA_KEY_FILE are used (in this order), whereas on the server,
> > the paths can be specified by up to three HostKey options as arbitrary names
> > in arbitrary sequence.
> 
> because the client is setuid root. you don't want to make
> ssh read every private key on the system.
> 
> the client _could_ get the hostkey pathnames from sshd_config, 
> but then you have to hardcode another filename.

I do not quite understand. I thought that each host would usually have the
same host key(s), regardless whether acting as server or client. The default
setting for the client is _PATH_HOST_KEY_FILE, _PATH_HOST_DSA_KEY_FILE and
_PATH_HOST_RSA_KEY_FILE and for the server _PATH_HOST_KEY_FILE and
_PATH_HOST_DSA_KEY_FILE only; but the server's file names can be configured.
Why should ssh then "read every private key on the system"?
Why do I "have to hardcode another filename"?


From markus at openbsd.org  Thu Oct 25 00:55:47 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 16:55:47 +0200
Subject: Inconsistent server/client configuration
In-Reply-To: <200110241441.QAA17440@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Wed, Oct 24, 2001 at 04:41:02PM +0200
References: <200110241441.QAA17440@marc.physik3.gwdg.de>
Message-ID: <20011024165547.A21594@faui02.informatik.uni-erlangen.de>

On Wed, Oct 24, 2001 at 04:41:02PM +0200, Hans Werner Strube wrote:
> I do not quite understand. I thought that each host would usually have the
> same host key(s), regardless whether acting as server or client. The default
> setting for the client is _PATH_HOST_KEY_FILE, _PATH_HOST_DSA_KEY_FILE and
> _PATH_HOST_RSA_KEY_FILE and for the server _PATH_HOST_KEY_FILE and
> _PATH_HOST_DSA_KEY_FILE only; but the server's file names can be configured.
> Why should ssh then "read every private key on the system"?
> Why do I "have to hardcode another filename"?

ssh(1) needs _PATH_HOST_RSA_KEY_FILE for hostbased authentication.

if we add HostKey to .ssh/config a user can do this:

	% cat > .ssh/config << EOF
	Host myhost
		HostKey /root/.ssh/id_rsa
		PreferredAuthentications hostbased
	EOF
	% ssh myhost

and sign data using the key of user root.

we could force ssh(1) to read sshd_config and check where the hostkey
is, but how does ssh(1) where sshd_config is?


From hari at isofttechindia.com  Thu Oct 25 01:12:56 2001
From: hari at isofttechindia.com (hari at isofttechindia.com)
Date: Wed, 24 Oct 2001 20:42:56 +0530
Subject: sftp client in interactive mode 
Message-ID: <3BD6DA78.9DCB5A8@isofttechindia.com>

Hi,
  I work on openssh-2.9p2 installed on LynxOS i386
system. sshd, ssh, scp and sftp-server all work fine.
The problem is sftp client, in interactive mode, exits
after authentication printing the sftp prompt. sftp
client works fine in non-interactive mode.
i.e.,
lynxos>sftp hari at linuxsystem:test
works fine
But,
lynxos>sftp hari at linuxsystem
...
sftp>
lynxos>
Any help, as to why sftp exits in interactive mode.
-Hari.



From strube at physik3.gwdg.de  Thu Oct 25 01:10:43 2001
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Wed, 24 Oct 2001 17:10:43 +0200 (MET DST)
Subject: Inconsistent server/client configuration
Message-ID: <200110241510.RAA17454@marc.physik3.gwdg.de>

> On Wed, Oct 24, 2001 at 04:41:02PM +0200, Hans Werner Strube wrote:
> > I do not quite understand. I thought that each host would usually have the
> > same host key(s), regardless whether acting as server or client. The default
> > setting for the client is _PATH_HOST_KEY_FILE, _PATH_HOST_DSA_KEY_FILE and
> > _PATH_HOST_RSA_KEY_FILE and for the server _PATH_HOST_KEY_FILE and
> > _PATH_HOST_DSA_KEY_FILE only; but the server's file names can be configured.
> > Why should ssh then "read every private key on the system"?
> > Why do I "have to hardcode another filename"?
> 
> ssh(1) needs _PATH_HOST_RSA_KEY_FILE for hostbased authentication.
> 
> if we add HostKey to .ssh/config a user can do this:
> 
> 	% cat > .ssh/config << EOF
> 	Host myhost
> 		HostKey /root/.ssh/id_rsa
> 		PreferredAuthentications hostbased
> 	EOF
> 	% ssh myhost
> 
> and sign data using the key of user root.

Thank you, now I see your point. But then the configurability of the
server hostkey files seems to be rather superfluous, since they are
usually the same as for an ssh client on this same machine.



From ed at UDel.Edu  Thu Oct 25 01:11:47 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 11:11:47 -0400 (EDT)
Subject: hanging on logout, can't background client
In-Reply-To: <20011024155929.A11792@folly>
Message-ID: <Pine.SOL.4.30.0110241108420.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Markus Friedl wrote:

> Date: Wed, 24 Oct 2001 15:59:29 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Phil Edwards <pedwards at disaster.jaj.com>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: hanging on logout, can't background client
>
> why don't you start the xterm with
> 	$ ssh -f host xterm
>
> see ssh(1)
>
>      -f      Requests ssh to go to background just before command execution.
>              This is useful if ssh is going to ask for passwords or passphras-
>              es, but the user wants it in the background.  This implies -n.
>              The recommended way to start X11 programs at a remote site is
>              with something like ssh -f host xterm.

Right... but what you get currently when you do that is an abandoned ssh
on the client (and an abandoned sshd on the server) that you have to go
find and kill later.  I've been running things like this without "-f" or
"-n" so that I can avoid losing track of the processes that need to be
killed, at the expense of having an extra xterm running on the client.

	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 alexk at demon.net  Thu Oct 25 01:15:07 2001
From: alexk at demon.net (Alex Kiernan)
Date: 24 Oct 2001 16:15:07 +0100
Subject: Borken dirname on Solaris 2.5.1
Message-ID: <72itd5f4sk.fsf@nd1.eng.demon.net>

Discovered this post an upgrade to 2.9.9p2, Solaris 2.5.1 dirname is
busted for paths like "/usr", returning "" rather than "/".

Index: acconfig.h
===================================================================
RCS file: /cvsroot/upstream/openssh/acconfig.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 acconfig.h
--- acconfig.h	2001/10/23 15:18:33	1.1.1.3
+++ acconfig.h	2001/10/24 15:09:49
@@ -333,6 +333,9 @@
 /* Define if you want smartcard support */
 #undef SMARTCARD
 
+/* Define if your dirname is busted */
+#undef BROKEN_DIRNAME
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line ************** */
Index: configure.in
===================================================================
RCS file: /cvsroot/upstream/openssh/configure.in,v
retrieving revision 1.5
diff -u -r1.5 configure.in
--- configure.in	2001/10/23 16:26:00	1.5
+++ configure.in	2001/10/24 15:09:49
@@ -531,6 +531,23 @@
 	)
 fi
 
+# Check for broken dirname (Solaris 2.5.1)
+AC_MSG_CHECKING([whether dirname works correctly for the root directory])
+AC_TRY_RUN(
+	[
+#include <string.h>
+#ifdef HAVE_LIBGEN_H
+#include <libgen.h>
+#endif
+int main(void){char buf[5];strcpy(buf,"/usr");return strlen(dirname(buf))==0;}
+	],
+	[AC_MSG_RESULT(yes)], 
+	[
+		AC_MSG_RESULT(no)
+		AC_DEFINE(BROKEN_DIRNAME)
+	]
+)
+
 AC_FUNC_GETPGRP
 
 # Check for PAM libs
Index: openbsd-compat/dirname.c
===================================================================
RCS file: /cvsroot/upstream/openssh/openbsd-compat/dirname.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 dirname.c
--- openbsd-compat/dirname.c	2001/10/23 15:18:35	1.1.1.1
+++ openbsd-compat/dirname.c	2001/10/24 15:09:49
@@ -28,6 +28,11 @@
  */
 
 #include "includes.h"
+
+#if defined(BROKEN_DIRNAME)		/* For those with broken dirname() */
+# undef HAVE_DIRNAME
+#endif
+
 #ifndef HAVE_DIRNAME
 
 #if defined(LIBC_SCCS) && !defined(lint)

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC


From mouring at etoh.eviladmin.org  Thu Oct 25 01:21:44 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 24 Oct 2001 10:21:44 -0500 (CDT)
Subject: Borken dirname on Solaris 2.5.1
In-Reply-To: <72itd5f4sk.fsf@nd1.eng.demon.net>
Message-ID: <Pine.BSO.4.33.0110241021250.7277-100000@etoh.eviladmin.org>


I believe this has been dealt with in the current CVS tree.

- Ben

On 24 Oct 2001, Alex Kiernan wrote:

> Discovered this post an upgrade to 2.9.9p2, Solaris 2.5.1 dirname is
> busted for paths like "/usr", returning "" rather than "/".
>
> Index: acconfig.h
> ===================================================================
> RCS file: /cvsroot/upstream/openssh/acconfig.h,v
> retrieving revision 1.1.1.3
> diff -u -r1.1.1.3 acconfig.h
> --- acconfig.h	2001/10/23 15:18:33	1.1.1.3
> +++ acconfig.h	2001/10/24 15:09:49
> @@ -333,6 +333,9 @@
>  /* Define if you want smartcard support */
>  #undef SMARTCARD
>
> +/* Define if your dirname is busted */
> +#undef BROKEN_DIRNAME
> +
>  @BOTTOM@
>
>  /* ******************* Shouldn't need to edit below this line ************** */
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/upstream/openssh/configure.in,v
> retrieving revision 1.5
> diff -u -r1.5 configure.in
> --- configure.in	2001/10/23 16:26:00	1.5
> +++ configure.in	2001/10/24 15:09:49
> @@ -531,6 +531,23 @@
>  	)
>  fi
>
> +# Check for broken dirname (Solaris 2.5.1)
> +AC_MSG_CHECKING([whether dirname works correctly for the root directory])
> +AC_TRY_RUN(
> +	[
> +#include <string.h>
> +#ifdef HAVE_LIBGEN_H
> +#include <libgen.h>
> +#endif
> +int main(void){char buf[5];strcpy(buf,"/usr");return strlen(dirname(buf))==0;}
> +	],
> +	[AC_MSG_RESULT(yes)],
> +	[
> +		AC_MSG_RESULT(no)
> +		AC_DEFINE(BROKEN_DIRNAME)
> +	]
> +)
> +
>  AC_FUNC_GETPGRP
>
>  # Check for PAM libs
> Index: openbsd-compat/dirname.c
> ===================================================================
> RCS file: /cvsroot/upstream/openssh/openbsd-compat/dirname.c,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 dirname.c
> --- openbsd-compat/dirname.c	2001/10/23 15:18:35	1.1.1.1
> +++ openbsd-compat/dirname.c	2001/10/24 15:09:49
> @@ -28,6 +28,11 @@
>   */
>
>  #include "includes.h"
> +
> +#if defined(BROKEN_DIRNAME)		/* For those with broken dirname() */
> +# undef HAVE_DIRNAME
> +#endif
> +
>  #ifndef HAVE_DIRNAME
>
>  #if defined(LIBC_SCCS) && !defined(lint)
>
> --
> Alex Kiernan, Principal Engineer, Development, Thus PLC
>



From markm68k at yahoo.com  Thu Oct 25 01:32:58 2001
From: markm68k at yahoo.com (Mark Miller)
Date: Wed, 24 Oct 2001 08:32:58 -0700 (PDT)
Subject: unfilled options in readconf.c
In-Reply-To: <20011024105240.A13279@faui02.informatik.uni-erlangen.de>
Message-ID: <20011024153258.71735.qmail@web14504.mail.yahoo.com>

--- Markus Friedl <markus at openbsd.org> wrote:
> what is host_key_alias set to when it crashes.

(gdb) backtrace
#0  0x700013e0 in strlen ()
#1  0x700024a4 in vfprintf ()
#2  0x70012e80 in vsnprintf ()
#3  0x0001474c in do_log (level=181, fmt=0xb <Address
0xb out of bounds>, args=0xbfffe6ac "") at log.c:378
#4  0x00014248 in debug (fmt=0x29168 "using
hostkeyalias: %s") at log.c:166
#5  0x00005638 in check_host_key (host=0xb5 <Address
0xb5 out of bounds>, hostaddr=0x39a90,
host_key=0x135b40, readonly=0, user_hostfile=0xd0
<Address 0xd0 out of bounds>, system_hostfile=0x43
<Address 0x43 out of bounds>) at sshconnect.c:609
#6  0x00005cb0 in verify_host_key (host=0x139af0
"localhost", hostaddr=0x39a00, host_key=0x135b40) at
sshconnect.c:844
#7  0x00007200 in verify_host_key_callback
(hostkey=0xbfffe6ac) at sshconnect2.c:77
#8  0x00024f5c in kexgex_client (kex=0x135840) at
kexgex.c:182
#9  0x000255b8 in kexgex (kex=0xb5) at kexgex.c:408
#10 0x0001ef54 in kex_kexinit_finish (kex=0x135840) at
kex.c:227
#11 0x0001ee50 in kex_input_kexinit (type=181,
plen=11, ctxt=0xbfffe6ac) at kex.c:192
#12 0x00014918 in dispatch_run (mode=181,
done=0x135884, ctxt=0x135840) at dispatch.c:71
#13 0x0000737c in ssh_kex2 (host=0xb5 <Address 0xb5
out of bounds>, hostaddr=0xb) at sshconnect2.c:125
#14 0x00005dcc in ssh_login (keys=0x139ab0, nkeys=3,
orighost=0x139af9 "", hostaddr=0x39a00, pw=0x6c696173)
at sshconnect.c:880
#15 0x00003908 in main (ac=0, av=0xbffff95c) at
ssh.c:764
#16 0x0000233c in _start ()
#17 0x0000216c in start ()
(gdb) 


Also, it is not set in the /etc/ssh_config file.



=====
Mark Miller
markm68k at yahoo.com

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From markus at openbsd.org  Thu Oct 25 01:39:01 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 17:39:01 +0200
Subject: Inconsistent server/client configuration
In-Reply-To: <200110241510.RAA17454@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Wed, Oct 24, 2001 at 05:10:43PM +0200
References: <200110241510.RAA17454@marc.physik3.gwdg.de>
Message-ID: <20011024173901.A26767@faui02.informatik.uni-erlangen.de>

On Wed, Oct 24, 2001 at 05:10:43PM +0200, Hans Werner Strube wrote:
> Thank you, now I see your point. But then the configurability of the
> server hostkey files seems to be rather superfluous, since they are
> usually the same as for an ssh client on this same machine.

no.

you might want to start a sshd with a different hostkey

or with just one hostkeys.

remember that the primary use of hostkeys is _server_ authentication.

i agree that switching from the default hostkey makes hostbased
authentication hard, but there's no easy way to fix this and 
hostbased is not the primary method.

-m


From markus at openbsd.org  Thu Oct 25 01:42:22 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 17:42:22 +0200
Subject: hanging on logout, can't background client
In-Reply-To: <Pine.SOL.4.30.0110241108420.16569-100000@mahler.udel.edu>; from ed@udel.edu on Wed, Oct 24, 2001 at 11:11:47AM -0400
References: <20011024155929.A11792@folly> <Pine.SOL.4.30.0110241108420.16569-100000@mahler.udel.edu>
Message-ID: <20011024174221.B26767@faui02.informatik.uni-erlangen.de>

On Wed, Oct 24, 2001 at 11:11:47AM -0400, Ed Phillips wrote:
> Right... but what you get currently when you do that is an abandoned ssh
> on the client (and an abandoned sshd on the server) that you have to go
> find and kill later.  I've been running things like this without "-f" or
> "-n" so that I can avoid losing track of the processes that need to be
> killed, at the expense of having an extra xterm running on the client.

no, the ssh dies when the xterm dies. don't use -n, use -f.

i cannot reproduce thist you claim.

please make sure you use the latest openssh snapshot
(see www.openssh.com/portable.html).


From markus at openbsd.org  Thu Oct 25 01:43:38 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 17:43:38 +0200
Subject: unfilled options in readconf.c
In-Reply-To: <20011024153258.71735.qmail@web14504.mail.yahoo.com>; from markm68k@yahoo.com on Wed, Oct 24, 2001 at 08:32:58AM -0700
References: <20011024105240.A13279@faui02.informatik.uni-erlangen.de> <20011024153258.71735.qmail@web14504.mail.yahoo.com>
Message-ID: <20011024174338.C26767@faui02.informatik.uni-erlangen.de>

who sets options.host_key_alias? can you trace this?


From ed at UDel.Edu  Thu Oct 25 02:03:38 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 12:03:38 -0400 (EDT)
Subject: hanging on logout, can't background client
In-Reply-To: <20011024174221.B26767@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.SOL.4.30.0110241158100.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Markus Friedl wrote:

> Date: Wed, 24 Oct 2001 17:42:22 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Phil Edwards <pedwards at disaster.jaj.com>, openssh-unix-dev at mindrot.org
> Subject: Re: hanging on logout, can't background client
>
> On Wed, Oct 24, 2001 at 11:11:47AM -0400, Ed Phillips wrote:
> > Right... but what you get currently when you do that is an abandoned ssh
> > on the client (and an abandoned sshd on the server) that you have to go
> > find and kill later.  I've been running things like this without "-f" or
> > "-n" so that I can avoid losing track of the processes that need to be
> > killed, at the expense of having an extra xterm running on the client.
>
> no, the ssh dies when the xterm dies. don't use -n, use -f.
>
> i cannot reproduce thist you claim.
>
> please make sure you use the latest openssh snapshot
> (see www.openssh.com/portable.html).

Okay... I've correctly set up my test environment to ensure that I have
2.9.9p2 on the client talking to 2.9.9p2 on the server and it appears that
ssh and sshd DO go away properly when I quit the xterm.

Yesterday I was (wrongly) doing the test with 2.9p2 on the client and
2.9.9p2 on the server.

So assuming that nothing has un-fixed this in the latest snapshot (I'll
try and get some time to download this and try it out ASAP), I'm happy to
report that the "ssh doesn't exit" problem seems to be solved in 2.9.9p2.

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 ed at UDel.Edu  Thu Oct 25 02:06:37 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 12:06:37 -0400 (EDT)
Subject: Default X11 forwarding behavior
Message-ID: <Pine.SOL.4.30.0110241203460.16569-100000@mahler.udel.edu>

In addition to sshd now denying X11 forwarding by default, it appears that
ssh does not try to forward X11 by default.  Is this the intended
behavior?

	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 dwd at bell-labs.com  Thu Oct 25 02:05:58 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Wed, 24 Oct 2001 11:05:58 -0500
Subject: configure changes
In-Reply-To: <Pine.UW2.4.40.9.0110232127290.14199-100000@uw711.int.multitalents.net>; from tim@multitalents.net on Tue, Oct 23, 2001 at 10:43:16PM -0700
References: <20011023131336.A3139@lucent.com> <Pine.UW2.4.40.9.0110232127290.14199-100000@uw711.int.multitalents.net>
Message-ID: <20011024110558.A27428@lucent.com>


Aack!  Why are all those -I/usr/local/include in CPPFLAGS and
-L/usr/local/lib in LDFLAGS for many different machine types in
configure.in?  The contents of those directories are different depending on
individual system installations, right?  I can't imagine a good reason for
including them by default.  The Solaris 2.5.1 machine I do my builds on
happens to have a libz.so in /usr/local/lib, and everything compiled and
ran fine on that machine but when I distributed the binaries to all my
solaris machines last night they couldn't find libz.so.  Those /usr/local
flags have been in there for a while (at least in version 2.9p2), but I
just started using the new --with-zlib=PATH option to point configure to a
directory where I have only a libz.a which didn't work because the
-L/usr/local/lib took precedence, and I used to pre-set the *FLAGS
environment variables to find libz so I didn't notice before.

Also, I tried to find some history in a cvsweb but apparently none is
available for OpenSSH portable; can that be made available?

Below is a patch to remove the /usr/local *FLAGS references in
configure.in.  I haven't tried them all, but I have tried the *-irix6*,
*-sysv4.2*, and the *-solaris* cases.

- Dave Dykstra

--- configure.in.O	Wed Oct 24 11:30:58 2001
+++ configure.in	Wed Oct 24 11:30:58 2001
@@ -54,10 +54,8 @@
 case "$host" in
 *-*-aix*)
 	AFS_LIBS="-lld"
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 	if (test "$LD" != "gcc" && test -z "$blibpath"); then
-		blibpath="/usr/lib:/lib:/usr/local/lib"
+		blibpath="/usr/lib:/lib"
 	fi
 	AC_CHECK_FUNC(authenticate, [AC_DEFINE(WITH_AIXAUTHENTICATE)])
 	AC_DEFINE(BROKEN_GETADDRINFO)
@@ -102,14 +100,10 @@
 	LIBS="$LIBS -lxnet -lsec"
 	;;
 *-*-irix5*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS"
 	PATH="$PATH:/usr/etc"
 	AC_DEFINE(BROKEN_INET_NTOA)
 	;;
 *-*-irix6*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS"
 	PATH="$PATH:/usr/etc"
 	AC_DEFINE(WITH_IRIX_ARRAY)
 	AC_DEFINE(WITH_IRIX_PROJECT)
@@ -146,12 +140,8 @@
 	AC_DEFINE(BROKEN_REALPATH)
 	AC_DEFINE(USE_PIPES)
 	AC_DEFINE(BROKEN_SAVED_UIDS)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	CFLAGS="$CFLAGS"
 	;;
 *-*-solaris*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib -R/usr/local/lib" 
 	need_dash_r=1
 	AC_DEFINE(PAM_SUN_CODEBASE)
 	AC_DEFINE(LOGIN_NEEDS_UTMPX)
@@ -179,14 +169,10 @@
 	AC_DEFINE(USE_PIPES)
 	;;
 *-ncr-sysv*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 	LIBS="$LIBS -lc89"
 	AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H)
 	;;
 *-sni-sysv*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib -L/usr/ucblib"
 	IPADDR_IN_DISPLAY=yes
 	AC_DEFINE(USE_PIPES)
 	AC_DEFINE(IP_TOS_IS_BROKEN)
@@ -194,24 +180,17 @@
 	LIBS="$LIBS -lgen -lnsl -lucb"
 	;;
 *-*-sysv4.2*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 #	enable_suid_ssh=no
 	AC_DEFINE(USE_PIPES)
 	;;
 *-*-sysv5*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 #	enable_suid_ssh=no
 	AC_DEFINE(USE_PIPES)
 	;;
 *-*-sysv*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 	;;
 *-*-sco3.2v4*)
-	CPPFLAGS="$CPPFLAGS -Dftruncate=chsize -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
+	CPPFLAGS="$CPPFLAGS -Dftruncate=chsize"
 	LIBS="$LIBS -los -lprot -lx -ltinfo -lm"
 	rsh_path="/usr/bin/rcmd"
 	RANLIB=true
@@ -227,8 +206,6 @@
 	do_sco3_extra_lib_check=yes
 	;;
 *-*-sco3.2v5*)
-	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 	LIBS="$LIBS -lprot -lx -ltinfo -lm"
 	no_dev_ptmx=1
 	rsh_path="/usr/bin/rcmd"
@@ -243,7 +220,7 @@
 	no_libsocket=1
 	no_libnsl=1
 	AC_DEFINE(USE_PIPES)
-	LDFLAGS="$LDFLAGS -Wl,-Dmsglevel=334:fatal,-L/usr/local/lib"
+	LDFLAGS="$LDFLAGS -Wl,-Dmsglevel=334:fatal"
 	LIBS="$LIBS -lgen -lrsc"
 	;;
 *-dec-osf*)


From pedwards at disaster.jaj.com  Thu Oct 25 02:42:25 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Wed, 24 Oct 2001 12:42:25 -0400
Subject: hanging on logout, can't background client
In-Reply-To: <20011024155929.A11792@folly>; from markus@openbsd.org on Wed, Oct 24, 2001 at 03:59:29PM +0200
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly>
Message-ID: <20011024124225.A23138@disaster.jaj.com>

On Wed, Oct 24, 2001 at 03:59:29PM +0200, Markus Friedl wrote:
> why don't you start the xterm with
> 	$ ssh -f host xterm

Because I'm not simply getting an xterm.

    linuxclient%  ssh solarisserver
    solarisserver%  xauth nextract .....
    solarisserver%  /bin/su -
    solarisserver#  xauth nmerge ....
    solarisserver#  DISPLAY=solarisserver:N xterm ....... &
[root's xterm appears]
    solarisserver#  exit
    solarisserver%  [maybe do some more work as me]
    solarisserver%  exit
[linuxclient hangs, I hit ~&, root's xterm continues to run]
    linuxclient%

This way, I have a root shell on the server I'm sysadmining, it's running in
a terminal emulator that I know and trust (xterm), it's securely tunnelled,
and I still have the use of the local (linuxclient) terminal I used to
start the whole thing.

-f won't do that for me.  I didn't mention all this in my original message
because I didn't want to arbitrarily complicate things.

Unfortunately, OpenSSH denies me the use of ~&, which I consider a bug.
It also denies me the use of /any other escape sequence/, which I consider
a serious bug.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From Lutz.Jaenicke at aet.TU-Cottbus.DE  Thu Oct 25 03:24:22 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Wed, 24 Oct 2001 19:24:22 +0200
Subject: disable features
In-Reply-To: <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu>
References: <20011024114637.A20236@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu>
Message-ID: <20011024192422.A27605@serv01.aet.tu-cottbus.de>

On Wed, Oct 24, 2001 at 09:35:22AM -0400, Ed Phillips wrote:
> On Wed, 24 Oct 2001, Lutz Jaenicke wrote:
> 
> > Consider a ssh[d] that has been compiled without X11 forwarding.
> 
> Speaking of X11Forwarding... is there any particular reason that somewhere
> between v2.9p2 and v2.9.9p2 there has been a change to the stock
> sshd_config to disable X11Forwarding?
> 
> Also, is there any particular reason that authentication forwarding has
> been disabled in 2.X (I'm not sure when, execpt that every since we've
> been trying out 2.X it has been disabled by default).
> 
> In addition, if there is some reason not to use these features (bugs,
> unreasonable security risks, etc.)... please let me know.

Both X11 and agent forwarding introduce some risks. If you cannot trust
the admin on the server (or have to consider the system being compromised),
you may experience the following:
* the malicious admin can steal your X-authentication credenticals and via
  the forwarded X11 connection he can open up windows on your display.
  He could therefore e.g. open a transparent window that captures your
  keystrokes.
  (This is however still better than a normal X11 connection, so the only
  way around it is not allow X11 connections from this host at all. The point
  is however, that once X11 forwarding is allowed you won't know which
  connections are opened, for normal X11 connections you at least have to
  type "xhost +host" or something like that before the access would be
  granted.)
* the malicious admin could access your forwarded agent connection and this
  way authenticate with your identity to another host using your public
  keys. He can however not steal your private key.
  (This is still better than performing a slogin on this server and type
  your password which can be captured by this admin. The only way around
  it is to not open another connection from the questionable server at
  all. Only start connections from your trusted system on your desk,
  then create some aliases "alias trustedserver slogin -A trustedserver"
  so that you can use the advantages of agent forwarding on trustedserver
  and are protected elsewhere.

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From alexk at demon.net  Thu Oct 25 03:47:32 2001
From: alexk at demon.net (Alex Kiernan)
Date: 24 Oct 2001 18:47:32 +0100
Subject: Borken dirname on Solaris 2.5.1
In-Reply-To: <Pine.BSO.4.33.0110241021250.7277-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.33.0110241021250.7277-100000@etoh.eviladmin.org>
Message-ID: <72d73dexqj.fsf@nd1.eng.demon.net>

<mouring at etoh.eviladmin.org> writes:

> I believe this has been dealt with in the current CVS tree.
> 

Bother, didn't think to check there!

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC


From markus at openbsd.org  Thu Oct 25 03:58:32 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 19:58:32 +0200
Subject: hanging on logout, can't background client
In-Reply-To: <20011024124225.A23138@disaster.jaj.com>; from pedwards@disaster.jaj.com on Wed, Oct 24, 2001 at 12:42:25PM -0400
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com>
Message-ID: <20011024195832.A25142@folly>

On Wed, Oct 24, 2001 at 12:42:25PM -0400, Phil Edwards wrote:
> Unfortunately, OpenSSH denies me the use of ~&, which I consider a bug.
> It also denies me the use of /any other escape sequence/, which I consider
> a serious bug.

well ~& does not work in ssh2

but ~. should work unless ssh gets EOF from stdin.
at this point ssh cannot read any more ~. escapes.


From markus at openbsd.org  Thu Oct 25 02:56:42 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 18:56:42 +0200
Subject: disable features
In-Reply-To: <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu>; from ed@UDel.Edu on Wed, Oct 24, 2001 at 09:35:22AM -0400
References: <20011024114637.A20236@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu>
Message-ID: <20011024185642.A7393@folly>


both agent and x11 forwarding are off by default since they allow
access to local resource from the remote machine where the sshd is
running.

enable agent and x11 forwarding only if you trust the remote server.


From markus at openbsd.org  Thu Oct 25 02:57:14 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 18:57:14 +0200
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011024142230.90161.qmail@web8005.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Wed, Oct 24, 2001 at 03:22:30PM +0100
References: <20011024142230.90161.qmail@web8005.mail.in.yahoo.com>
Message-ID: <20011024185714.B7393@folly>


please provide some debugging output.


From markus at openbsd.org  Thu Oct 25 02:58:53 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 18:58:53 +0200
Subject: Default X11 forwarding behavior
In-Reply-To: <Pine.SOL.4.30.0110241203460.16569-100000@mahler.udel.edu>; from ed@UDel.Edu on Wed, Oct 24, 2001 at 12:06:37PM -0400
References: <Pine.SOL.4.30.0110241203460.16569-100000@mahler.udel.edu>
Message-ID: <20011024185853.C7393@folly>

On Wed, Oct 24, 2001 at 12:06:37PM -0400, Ed Phillips wrote:
> In addition to sshd now denying X11 forwarding by default, it appears that
> ssh does not try to forward X11 by default.  Is this the intended
> behavior?

for a long long time.


From ed at UDel.Edu  Thu Oct 25 04:01:16 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 14:01:16 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.BSO.4.33.0110240926080.7277-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0110241354180.16569-100000@mahler.udel.edu>

Okay, this appears to be a problem with pam_unix.so - the code in
pam_sm_open_session is written with the assumption that the tty name is of
the form "/dev/" + something else on the end.  I'm not sure why the
existing kludge works without getting a SEGV - but it's probably blind
luck (although I'd think it would fail for someone at some point).  If it
doesn't break anything on other systems, the kludge should probably be
changed to pass "/dev/ssh" or something, just to be safe.

The core dump happens as it's trying to strip "/dev/" off of the tty name
in order to write the tty name (abbreviated) into the lastlog.

	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 peterw at usa.net  Thu Oct 25 04:10:18 2001
From: peterw at usa.net (Peter W)
Date: Wed, 24 Oct 2001 14:10:18 -0400
Subject: disable features
In-Reply-To: <20011024192422.A27605@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Wed, Oct 24, 2001 at 07:24:22PM +0200
References: <20011024114637.A20236@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu> <20011024192422.A27605@serv01.aet.tu-cottbus.de>
Message-ID: <20011024141018.G12985@usa.net>

On Wed, Oct 24, 2001 at 07:24:22PM +0200, Lutz Jaenicke wrote:
> On Wed, Oct 24, 2001 at 09:35:22AM -0400, Ed Phillips wrote:

> > Also, is there any particular reason that authentication forwarding has
> > been disabled in 2.X

> > In addition, if there is some reason not to use these features (bugs,
> > unreasonable security risks, etc.)... please let me know.
> 
> Both X11 and agent forwarding introduce some risks. If you cannot trust
> the admin on the server (or have to consider the system being compromised),
> you may experience the following:

> * the malicious admin could access your forwarded agent connection

Also, IIRC, OpenSSH's client will attempt to use agent/keypair auth when 
initiating a new connection. This means 'ssh'/'sftp' will present your 
keypair "identity" to new servers unless explicitly asked not to do so.
For privacy reasons, you may wish to hide your keypair identities unless 
needed/warranted. It's probably a good thing for users to get in the habit 
of explicitly requesting services like X11 forwarding and agent forwarding 
instead of just expecting things to "work".

I guess I'm arguing that RSAAuthentication in ssh_config perhaps should 
default to "no" as well.

-Peter


From pedwards at disaster.jaj.com  Thu Oct 25 04:27:54 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Wed, 24 Oct 2001 14:27:54 -0400
Subject: hanging on logout, can't background client
In-Reply-To: <20011024195832.A25142@folly>; from markus@openbsd.org on Wed, Oct 24, 2001 at 07:58:32PM +0200
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com> <20011024195832.A25142@folly>
Message-ID: <20011024142754.A23601@disaster.jaj.com>

On Wed, Oct 24, 2001 at 07:58:32PM +0200, Markus Friedl wrote:
> On Wed, Oct 24, 2001 at 12:42:25PM -0400, Phil Edwards wrote:
> > Unfortunately, OpenSSH denies me the use of ~&, which I consider a bug.
> > It also denies me the use of /any other escape sequence/, which I consider
> > a serious bug.
> 
> well ~& does not work in ssh2

Oh, crumbs.  I suppose I need to ask, "why not?"

I just now ran "ssh -1 solarisserver" -- the login was much faster, not
too surprising -- started an xterm in the background, and logged out.
The xterm continued to run as the client "hung".  Then I typed ~&, got the
"backgrounded" message, but the xterm instantly died, and the connection
closed.

Sigh.  It's days like this I feel I should have been a bookstore owner
instead of a computer scientist.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From ed at UDel.Edu  Thu Oct 25 04:49:47 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 14:49:47 -0400 (EDT)
Subject: Default forwarding features; default cipher
In-Reply-To: <20011024192422.A27605@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Lutz Jaenicke wrote:

> Date: Wed, 24 Oct 2001 19:24:22 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: disable features
>
> On Wed, Oct 24, 2001 at 09:35:22AM -0400, Ed Phillips wrote:
> > On Wed, 24 Oct 2001, Lutz Jaenicke wrote:
> >
> > > Consider a ssh[d] that has been compiled without X11 forwarding.
> >
> > Speaking of X11Forwarding... is there any particular reason that somewhere
> > between v2.9p2 and v2.9.9p2 there has been a change to the stock
> > sshd_config to disable X11Forwarding?
> >
> > Also, is there any particular reason that authentication forwarding has
> > been disabled in 2.X (I'm not sure when, execpt that every since we've
> > been trying out 2.X it has been disabled by default).
> >
> > In addition, if there is some reason not to use these features (bugs,
> > unreasonable security risks, etc.)... please let me know.
>
> Both X11 and agent forwarding introduce some risks. If you cannot trust
> the admin on the server (or have to consider the system being compromised),
> you may experience the following:
> * the malicious admin can steal your X-authentication credenticals and via
>   the forwarded X11 connection he can open up windows on your display.
>   He could therefore e.g. open a transparent window that captures your
>   keystrokes.
>   (This is however still better than a normal X11 connection, so the only
>   way around it is not allow X11 connections from this host at all. The point
>   is however, that once X11 forwarding is allowed you won't know which
>   connections are opened, for normal X11 connections you at least have to
>   type "xhost +host" or something like that before the access would be
>   granted.)
> * the malicious admin could access your forwarded agent connection and this
>   way authenticate with your identity to another host using your public
>   keys. He can however not steal your private key.
>   (This is still better than performing a slogin on this server and type
>   your password which can be captured by this admin. The only way around
>   it is to not open another connection from the questionable server at
>   all. Only start connections from your trusted system on your desk,
>   then create some aliases "alias trustedserver slogin -A trustedserver"
>   so that you can use the advantages of agent forwarding on trustedserver
>   and are protected elsewhere.

Okay... that makes sense.  I've been looking at this from the viewpoint of
using ssh between "trusted" machines (managed by our group)... in which
case, we probably want forwarding of X11 connections and authentication
to, at least, be available.  I guess the only gotcha is that you have to
enable X11 forwarding in sshd_config.  It appears that by default "ssh -X"
is silently ignored on the server side, and "ssh -A" works fine... and
normally you get no forwarding from the client without adding the "-A" or
"-X".  Is this correct?

By the way, I notice in the stock ssh_config, it would appear that
"blowfish" is the default cipher.  Is this used for speed or because it
provides the best security or both?

	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  Thu Oct 25 04:50:37 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 20:50:37 +0200
Subject: hanging on logout, can't background client
In-Reply-To: <20011024142754.A23601@disaster.jaj.com>; from pedwards@disaster.jaj.com on Wed, Oct 24, 2001 at 02:27:54PM -0400
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com> <20011024195832.A25142@folly> <20011024142754.A23601@disaster.jaj.com>
Message-ID: <20011024205036.A9877@faui02.informatik.uni-erlangen.de>

well ~& does not work because it's broken.

it could work again in openssh 3.1


From ed at UDel.Edu  Thu Oct 25 04:54:26 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 14:54:26 -0400 (EDT)
Subject: Default X11 forwarding behavior
In-Reply-To: <20011024185853.C7393@folly>
Message-ID: <Pine.SOL.4.30.0110241451470.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Markus Friedl wrote:

> Date: Wed, 24 Oct 2001 18:58:53 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Default X11 forwarding behavior
>
> On Wed, Oct 24, 2001 at 12:06:37PM -0400, Ed Phillips wrote:
> > In addition to sshd now denying X11 forwarding by default, it appears that
> > ssh does not try to forward X11 by default.  Is this the intended
> > behavior?
>
> for a long long time.

Okay, I can see some good reasons why not to use ssh -X to an untrusted
system.  Are there any good reasons why not to sshd allow X11 forwarding
to occur?

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 pekkas at netcore.fi  Thu Oct 25 05:03:19 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 24 Oct 2001 22:03:19 +0300 (EEST)
Subject: Another round of testing calls. (redhat/openssh.spec)
In-Reply-To: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.33.0110242148180.13736-200000@netcore.fi>

On Tue, 23 Oct 2001 mouring at etoh.eviladmin.org wrote:
> Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
> required.  *WHAT* other issues *MUST* be address before 3.0 which is
> approaching fast?

I'm not saying MUST, but I've been trying to suggest a few modifications
(under the OpenSSL_free thread) to contrib/redhat/openssh.spec for some
time now.  I've yet to receive a reply.

Here's a full diff.  It does:

1) As sshd -t is used when restarting sshd with RH scripts now,
sshd_config is better marked with noreplace as all config files should.

2) '--with-ipv4-default' is removed; it's a major release after all.  I
haven't noticed any problems with this (and a lot of Linux distros already
do it, including Red Hat), and if you'd have to run 'sshd -6', IPv4 port
forwarding through mapped addresses won't work.

Caveat: if you haven't patched your tcp_wrappers for IPv6, and IPv6 is
enabled with SSHD, and you have access controls, you won't be let in even
with IPv4 (connections seem to originate from 0.0.0.0 vs.  
::ffff:ipv4addr).  I don't see this as a huge problem, as you have to have
IPv6 enabled.  E.g. RHL72 already has patched tcp_wrappers.

3) Building appears to rely on the existance of openssl >= 0.9.6
(OPENSSL_free function).  Mark the requirement there.

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

-------------- next part --------------
Index: contrib/redhat/openssh.spec
===================================================================
RCS file: /cvs/openssh_cvs/contrib/redhat/openssh.spec,v
retrieving revision 1.89
diff -u -r1.89 openssh.spec
--- contrib/redhat/openssh.spec	2001/10/24 05:36:55	1.89
+++ contrib/redhat/openssh.spec	2001/10/24 19:07:22
@@ -52,7 +52,7 @@
 Group: Applications/Internet
 BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
 Obsoletes: ssh
-BuildPreReq: perl, openssl-devel, tcp_wrappers
+BuildPreReq: perl, openssl-devel >= 0.9.6, tcp_wrappers
 BuildPreReq: /bin/login, /usr/include/security/pam_appl.h
 BuildPreReq: rpm >= 3.0.5
 %if ! %{no_x11_askpass}
@@ -62,9 +62,9 @@
 BuildPreReq: gnome-libs-devel
 %endif
 %if ! %{static_libcrypto}
-PreReq: openssl >= 0.9.5a
+PreReq: openssl >= 0.9.6
 PreReq: openssl = %{exact_openssl_version}
-Requires: openssl >= 0.9.5a
+Requires: openssl >= 0.9.6
 %endif
 Requires: rpm >= 3.0.5
 
@@ -155,7 +155,6 @@
 	--datadir=%{_datadir}/openssh \
 	--with-pam \
 	--with-tcp-wrappers \
-	--with-ipv4-default \
 	--with-rsh=/usr/bin/rsh \
 	--with-default-path=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin \
 	$EXTRA_OPTS
@@ -264,8 +263,7 @@
 %attr(0755,root,root) %{_libexecdir}/openssh/sftp-server
 %attr(0644,root,root) %{_mandir}/man8/sshd.8*
 %attr(0644,root,root) %{_mandir}/man8/sftp-server.8*
-#%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config
-%attr(0600,root,root) %config %{_sysconfdir}/sshd_config
+%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config
 %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd
 %attr(0755,root,root) %config /etc/rc.d/init.d/sshd
 

From ed at UDel.Edu  Thu Oct 25 05:05:56 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 15:05:56 -0400 (EDT)
Subject: disable features
In-Reply-To: <20011024141018.G12985@usa.net>
Message-ID: <Pine.SOL.4.30.0110241456130.16569-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Peter W wrote:

> Date: Wed, 24 Oct 2001 14:10:18 -0400
> From: Peter W <peterw at usa.net>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: disable features
>
> On Wed, Oct 24, 2001 at 07:24:22PM +0200, Lutz Jaenicke wrote:
> > On Wed, Oct 24, 2001 at 09:35:22AM -0400, Ed Phillips wrote:
>
> > > Also, is there any particular reason that authentication forwarding has
> > > been disabled in 2.X
>
> > > In addition, if there is some reason not to use these features (bugs,
> > > unreasonable security risks, etc.)... please let me know.
> >
> > Both X11 and agent forwarding introduce some risks. If you cannot trust
> > the admin on the server (or have to consider the system being compromised),
> > you may experience the following:
>
> > * the malicious admin could access your forwarded agent connection
>
> Also, IIRC, OpenSSH's client will attempt to use agent/keypair auth when
> initiating a new connection. This means 'ssh'/'sftp' will present your
> keypair "identity" to new servers unless explicitly asked not to do so.
>
> For privacy reasons, you may wish to hide your keypair identities unless
> needed/warranted. It's probably a good thing for users to get in the habit
> of explicitly requesting services like X11 forwarding and agent forwarding
> instead of just expecting things to "work".
>
> I guess I'm arguing that RSAAuthentication in ssh_config perhaps should
> default to "no" as well.

Yeah... I've wondered about this.  If passing your private key to the
remote side (of course, how else could RSA auth forwarding work if you
didn't) is too much of a security risk as the default behavior, while
providing no additional security (only the convenience of not having to
type in more passwords), then I'd vote to make PasswordAuthentication be
the only method tried by default.

	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  Thu Oct 25 05:09:09 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 24 Oct 2001 14:09:09 -0500 (CDT)
Subject: configure changes
In-Reply-To: <20011024110558.A27428@lucent.com>
Message-ID: <Pine.BSO.4.33.0110241402520.30136-100000@etoh.eviladmin.org>



On Wed, 24 Oct 2001, Dave Dykstra wrote:

>
> Aack!  Why are all those -I/usr/local/include in CPPFLAGS and
> -L/usr/local/lib in LDFLAGS for many different machine types in
> configure.in?  The contents of those directories are different depending on
> individual system installations, right?  I can't imagine a good reason for
> including them by default.  The Solaris 2.5.1 machine I do my builds on
> happens to have a libz.so in /usr/local/lib, and everything compiled and
> ran fine on that machine but when I distributed the binaries to all my
> solaris machines last night they couldn't find libz.so.  Those /usr/local
> flags have been in there for a while (at least in version 2.9p2), but I
> just started using the new --with-zlib=PATH option to point configure to a
> directory where I have only a libz.a which didn't work because the
> -L/usr/local/lib took precedence, and I used to pre-set the *FLAGS
> environment variables to find libz so I didn't notice before.
>

This may be a good idea.. but I strongly suggest this occur *AFTER* 3.0.
I want a 3.0p1 release that works for the majority with very few
headaches, and I can see this as a potental headache.

> Also, I tried to find some history in a cvsweb but apparently none is
> available for OpenSSH portable; can that be made available?
>
I use to have one on www.eviladmin.org  while it was under Linux, but
I broke it in the transition to OpenBSD/Sparc.  Since I was the only one
using it (since it was not widely published since it was just being
tested) I pretty much removed it.

I'm planning on setting one back up, but it won't be until mid December
when I am happily into my house and my U10 sparc is online.

- Ben




From markus at openbsd.org  Thu Oct 25 05:09:19 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 21:09:19 +0200
Subject: Default X11 forwarding behavior
In-Reply-To: <Pine.SOL.4.30.0110241451470.16569-100000@mahler.udel.edu>; from ed@UDel.Edu on Wed, Oct 24, 2001 at 02:54:26PM -0400
References: <20011024185853.C7393@folly> <Pine.SOL.4.30.0110241451470.16569-100000@mahler.udel.edu>
Message-ID: <20011024210919.A12640@faui02.informatik.uni-erlangen.de>

this has been discussed before.


From djast at cs.toronto.edu  Thu Oct 25 05:11:45 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Wed, 24 Oct 2001 15:11:45 -0400
Subject: Config file semantics change intentional?
Message-ID: <01Oct24.151150edt.453153-15834@jane.cs.toronto.edu>

In 2.3.0, the per-user config file was read before the system-wide
config file, so options set in ~/.ssh/config took precedence over
system-wide defaults.  In 2.9.9, the system-wide file seems to be read
first, contrary to the man page (cf. ssh.c ll. 631-632).

It seems to me that the old behaviour made more sense.  (I discovered
the change because I could not override a "ForwardX11" option for a
particular host when it was specified in the global client config file
for all hosts.)

Is this a deliberate change, and the man page hasn't been updated?  Or
should ssh.c be corrected to read the system-wide config file after the
per-user config file?

-- 
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  Thu Oct 25 05:20:31 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 24 Oct 2001 14:20:31 -0500 (CDT)
Subject: Config file semantics change intentional?
In-Reply-To: <01Oct24.151150edt.453153-15834@jane.cs.toronto.edu>
Message-ID: <Pine.BSO.4.33.0110241420210.30136-100000@etoh.eviladmin.org>


This has been resolved in the latest CVS tree and will be fixed in 3.0

On Wed, 24 Oct 2001, Dan Astoorian wrote:

> In 2.3.0, the per-user config file was read before the system-wide
> config file, so options set in ~/.ssh/config took precedence over
> system-wide defaults.  In 2.9.9, the system-wide file seems to be read
> first, contrary to the man page (cf. ssh.c ll. 631-632).
>
> It seems to me that the old behaviour made more sense.  (I discovered
> the change because I could not override a "ForwardX11" option for a
> particular host when it was specified in the global client config file
> for all hosts.)
>
> Is this a deliberate change, and the man page hasn't been updated?  Or
> should ssh.c be corrected to read the system-wide config file after the
> per-user config file?
>
> --
> 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  Thu Oct 25 05:27:13 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 15:27:13 -0400 (EDT)
Subject: Default X11 forwarding behavior
In-Reply-To: <20011024210919.A12640@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.SOL.4.30.0110241527010.16569-100000@mahler.udel.edu>

Sorry, I only recently joined the list.

	Ed

On Wed, 24 Oct 2001, Markus Friedl wrote:

> Date: Wed, 24 Oct 2001 21:09:19 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Default X11 forwarding behavior
>
> this has been discussed before.
>

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 Nicolas.Williams at ubsw.com  Thu Oct 25 05:47:14 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Wed, 24 Oct 2001 15:47:14 -0400
Subject: hanging on logout, can't background client
In-Reply-To: <20011024205036.A9877@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Oct 24, 2001 at 08:50:37PM +0200
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com> <20011024195832.A25142@folly> <20011024142754.A23601@disaster.jaj.com> <20011024205036.A9877@faui02.informatik.uni-erlangen.de>
Message-ID: <20011024154713.Y5739@sm2p1386swk.wdr.com>

Boy! Solid release! :) :^)

Nico


On Wed, Oct 24, 2001 at 08:50:37PM +0200, Markus Friedl wrote:
> well ~& does not work because it's broken.
> 
> it could work again in openssh 3.1
--
-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 ed at UDel.Edu  Thu Oct 25 05:58:58 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 15:58:58 -0400 (EDT)
Subject: Another round of testing calls.
In-Reply-To: <Pine.BSO.4.33.0110240926080.7277-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0110241548080.16569-100000@mahler.udel.edu>

Is it possible that this is a direct result of using the kludge -
specifying a bogus tty name which can't possibly be used to fetch a
password?  Probably, sshd should not call pam_open_session() in the case
where we are running in non-interactive mode - and sshd should just exit
with a "password expired" error if the password needs to be changed
in.rshd on Sol8 does not does not call the PAM session stuff.
pam_unix.so on Sol8 has a pam_sm_open_session() which requires the tty
name to be available (and my guess is that it must be valid as well -
hence the problems with not passing a tty name).  Sure, it's a bug in Sol8
pam_unix.so, but the docs are pretty thin regarding what
pam_sm_open_session() is supposed to do and whether the PAM_TTY is
required.  My guess that PAM_TTY is actually a required parameter (if
you're going to do PAM session stuff) and unexpected results will occur if
you just fill it with a bogus string.

	Ed

On Wed, 24 Oct 2001 mouring at etoh.eviladmin.org wrote:

> Date: Wed, 24 Oct 2001 09:27:48 -0500 (CDT)
> From: mouring at etoh.eviladmin.org
> Cc: "Dost, Alexander" <Alexander.Dost at drkw.com>, openssh-unix-dev at mindrot.org
> Subject: Re: Another round of testing calls.
>
>
> If PAM is doing the password change, then I have to agree with Markus.
> Could one of our Lurking Sun experts reproduce this and check if there is
> a bug in their PAM code or if we are missing a bit of code?
>
> - Ben
>
> On Wed, 24 Oct 2001, Markus Friedl wrote:
>
> > On Wed, Oct 24, 2001 at 10:46:57AM +0200, Dost, Alexander wrote:
> > > Is the problem with clear-text passwords after using the kludge on Sol8
> > > known and will it be fixed ?
> > > I didn't see any reply on this problem.
> >
> > this is probably a bug in the PAM: either they should
> > not depend on the TTY kludge or not ask for a password
> > if there is not TYY.
> >
> > -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 peterw at usa.net  Thu Oct 25 06:02:28 2001
From: peterw at usa.net (Peter W)
Date: Wed, 24 Oct 2001 16:02:28 -0400
Subject: disable features
In-Reply-To: <Pine.SOL.4.30.0110241456130.16569-100000@mahler.udel.edu>; from ed@UDel.Edu on Wed, Oct 24, 2001 at 03:05:56PM -0400
References: <20011024141018.G12985@usa.net> <Pine.SOL.4.30.0110241456130.16569-100000@mahler.udel.edu>
Message-ID: <20011024160228.B15792@usa.net>

On Wed, Oct 24, 2001 at 03:05:56PM -0400, Ed Phillips wrote:
> On Wed, 24 Oct 2001, Peter W wrote:

> > Also, IIRC, OpenSSH's client will attempt to use agent/keypair auth when
> > initiating a new connection. This means 'ssh'/'sftp' will present your
> > keypair "identity" to new servers unless explicitly asked not to do so.
> >
> > For privacy reasons, you may wish to hide your keypair identities unless
> > needed/warranted.

> > I guess I'm arguing that RSAAuthentication in ssh_config perhaps should
> > default to "no" as well.
> 
> Yeah... I've wondered about this.  If passing your private key to the
> remote side (of course, how else could RSA auth forwarding work if you
> didn't) is too much of a security risk as the default behavior, while
> providing no additional security (only the convenience of not having to
> type in more passwords), then I'd vote to make PasswordAuthentication be
> the only method tried by default.

It's not exposing your private key; it exposes your public key. It's not a
security issue, but rather a privacy issue. You say
 ssh someuser at somehost 
and ssh says "By the way, this user is known as DSA pubkey blah-blah-blah,
would you like us to prove that?" before falling back to password auth;
somehost seeing your pubkey does not threaten your private key, but it might
reveal to somehost a piece of information that somehost does not need. Too
bad there's nothing simple like -a/-A and -x/-X to toggle this keypair-first
behavior. (-k/-K anyone?)

-Peter


From markus at openbsd.org  Thu Oct 25 06:08:16 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 22:08:16 +0200
Subject: disable features
In-Reply-To: <20011024141018.G12985@usa.net>; from peterw@usa.net on Wed, Oct 24, 2001 at 02:10:18PM -0400
References: <20011024114637.A20236@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu> <20011024192422.A27605@serv01.aet.tu-cottbus.de> <20011024141018.G12985@usa.net>
Message-ID: <20011024220816.A15561@faui02.informatik.uni-erlangen.de>

public key authentication is not disabled by default
because it's more secure against MITM then password
authentication.


From markus at openbsd.org  Thu Oct 25 05:42:16 2001
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 24 Oct 2001 21:42:16 +0200
Subject: hanging on logout, can't background client
In-Reply-To: <20011024142754.A23601@disaster.jaj.com>; from pedwards@disaster.jaj.com on Wed, Oct 24, 2001 at 02:27:54PM -0400
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com> <20011024195832.A25142@folly> <20011024142754.A23601@disaster.jaj.com>
Message-ID: <20011024214216.A11531@folly>

On Wed, Oct 24, 2001 at 02:27:54PM -0400, Phil Edwards wrote:
> On Wed, Oct 24, 2001 at 07:58:32PM +0200, Markus Friedl wrote:
> > On Wed, Oct 24, 2001 at 12:42:25PM -0400, Phil Edwards wrote:
> > > Unfortunately, OpenSSH denies me the use of ~&, which I consider a bug.
> > > It also denies me the use of /any other escape sequence/, which I consider
> > > a serious bug.
> > 
> > well ~& does not work in ssh2
> 
> Oh, crumbs.  I suppose I need to ask, "why not?"

please try this experimental patch.  could be included in 3.1

Index: clientloop.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v
retrieving revision 1.85
diff -u -r1.85 clientloop.c
--- clientloop.c	24 Oct 2001 08:51:35 -0000	1.85
+++ clientloop.c	24 Oct 2001 19:40:04 -0000
@@ -522,36 +522,19 @@
 				continue;
 
 			case '&':
-				/* XXX does not work yet with proto 2 */
-				if (compat20)
-					continue;
 				/*
 				 * Detach the program (continue to serve connections,
 				 * but put in background and no more new connections).
 				 */
-				if (!stdin_eof) {
-					/*
-					 * Sending SSH_CMSG_EOF alone does not always appear
-					 * to be enough.  So we try to send an EOF character
-					 * first.
-					 */
-					packet_start(SSH_CMSG_STDIN_DATA);
-					packet_put_string("\004", 1);
-					packet_send();
-					/* Close stdin. */
-					stdin_eof = 1;
-					if (buffer_len(bin) == 0) {
-						packet_start(SSH_CMSG_EOF);
-						packet_send();
-					}
-				}
 				/* Restore tty modes. */
 				leave_raw_mode();
 
 				/* Stop listening for new connections. */
-				channel_close_all();	/* proto1 only XXXX */
+				channel_stop_listening();
 
-				printf("%c& [backgrounded]\n", escape_char);
+				snprintf(string, sizeof string,
+				    "%c& [backgrounded]\n", escape_char);
+				buffer_append(berr, string, strlen(string));
 
 				/* Fork into background. */
 				pid = fork();
@@ -564,7 +547,27 @@
 					exit(0);
 				}
 				/* The child continues serving connections. */
-				continue; /*XXX ? */
+				if (compat20) {
+					buffer_append(bin, "\004", 1);
+					/* fake EOF on stdin */
+					return -1;
+				} else if (!stdin_eof) {
+					/*
+					 * Sending SSH_CMSG_EOF alone does not always appear
+					 * to be enough.  So we try to send an EOF character
+					 * first.
+					 */
+					packet_start(SSH_CMSG_STDIN_DATA);
+					packet_put_string("\004", 1);
+					packet_send();
+					/* Close stdin. */
+					stdin_eof = 1;
+					if (buffer_len(bin) == 0) {
+						packet_start(SSH_CMSG_EOF);
+						packet_send();
+					}
+				}
+				continue;
 
 			case '?':
 				snprintf(string, sizeof string,


From Lutz.Jaenicke at aet.TU-Cottbus.DE  Thu Oct 25 06:30:30 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Wed, 24 Oct 2001 22:30:30 +0200
Subject: Default forwarding features; default cipher
In-Reply-To: <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu>
References: <20011024192422.A27605@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu>
Message-ID: <20011024223030.A185@serv01.aet.tu-cottbus.de>

On Wed, Oct 24, 2001 at 02:49:47PM -0400, Ed Phillips wrote:
> Okay... that makes sense.  I've been looking at this from the viewpoint of
> using ssh between "trusted" machines (managed by our group)... in which
> case, we probably want forwarding of X11 connections and authentication
> to, at least, be available.  I guess the only gotcha is that you have to
> enable X11 forwarding in sshd_config.  It appears that by default "ssh -X"
> is silently ignored on the server side, and "ssh -A" works fine... and
> normally you get no forwarding from the client without adding the "-A" or
> "-X".  Is this correct?

I don't think that X11 forwarding on the server side introduces a problem.
For the client side it is up to you. If your hosts only communicate
between each other, you can enable forwarding globally in ssh_config.
Having the user make a responsible decision itself is even better,
especially when your users also open connections to the outside.
SSH is the recommended protocol for doing this and adding a -A and/or -X
for trusted hosts is more secure than having to remember to add -a/-x
in case one is not sure.
The question, how many users actually understand enough of these problems
to come to a responsible decision or, at least, understand what we are
talking about, is not covered in this discussion :-) (actually this should
be a :-(, as most users don't understand or care about it).

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From mouring at etoh.eviladmin.org  Thu Oct 25 07:03:40 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Wed, 24 Oct 2001 16:03:40 -0500 (CDT)
Subject: Another round of testing calls.
In-Reply-To: <Pine.SOL.4.30.0110241548080.16569-100000@mahler.udel.edu>
Message-ID: <Pine.BSO.4.33.0110241603200.8193-100000@etoh.eviladmin.org>


How do you enforce PAM limits without opening a session then?

- Ben

On Wed, 24 Oct 2001, Ed Phillips wrote:

> Is it possible that this is a direct result of using the kludge -
> specifying a bogus tty name which can't possibly be used to fetch a
> password?  Probably, sshd should not call pam_open_session() in the case
> where we are running in non-interactive mode - and sshd should just exit
> with a "password expired" error if the password needs to be changed
> in.rshd on Sol8 does not does not call the PAM session stuff.
> pam_unix.so on Sol8 has a pam_sm_open_session() which requires the tty
> name to be available (and my guess is that it must be valid as well -
> hence the problems with not passing a tty name).  Sure, it's a bug in Sol8
> pam_unix.so, but the docs are pretty thin regarding what
> pam_sm_open_session() is supposed to do and whether the PAM_TTY is
> required.  My guess that PAM_TTY is actually a required parameter (if
> you're going to do PAM session stuff) and unexpected results will occur if
> you just fill it with a bogus string.
>
> 	Ed
>
> On Wed, 24 Oct 2001 mouring at etoh.eviladmin.org wrote:
>
> > Date: Wed, 24 Oct 2001 09:27:48 -0500 (CDT)
> > From: mouring at etoh.eviladmin.org
> > Cc: "Dost, Alexander" <Alexander.Dost at drkw.com>, openssh-unix-dev at mindrot.org
> > Subject: Re: Another round of testing calls.
> >
> >
> > If PAM is doing the password change, then I have to agree with Markus.
> > Could one of our Lurking Sun experts reproduce this and check if there is
> > a bug in their PAM code or if we are missing a bit of code?
> >
> > - Ben
> >
> > On Wed, 24 Oct 2001, Markus Friedl wrote:
> >
> > > On Wed, Oct 24, 2001 at 10:46:57AM +0200, Dost, Alexander wrote:
> > > > Is the problem with clear-text passwords after using the kludge on Sol8
> > > > known and will it be fixed ?
> > > > I didn't see any reply on this problem.
> > >
> > > this is probably a bug in the PAM: either they should
> > > not depend on the TTY kludge or not ask for a password
> > > if there is not TYY.
> > >
> > > -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  Thu Oct 25 07:23:32 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Wed, 24 Oct 2001 17:23:32 -0400 (EDT)
Subject: Another round of testing calls.
In-Reply-To: <Pine.BSO.4.33.0110241603200.8193-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0110241715560.9148-100000@mahler.udel.edu>

On Wed, 24 Oct 2001 mouring at etoh.eviladmin.org wrote:

> Date: Wed, 24 Oct 2001 16:03:40 -0500 (CDT)
> From: mouring at etoh.eviladmin.org
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Another round of testing calls.
>
>
> How do you enforce PAM limits without opening a session then?

There are no "limits" enforced by pam_sm_open_session() - the current
pam_unix.so just makes a lastlog entry with the TTY set in the PAM handle.
All the "limits" (I assume you mean password expiration and account
expiration and invalid account type stuff) are handled by the
pam_sm_acct_mgmt() (and possibly even pam_sm_authenticate()) which are
also provided pam_unix.so on Sol8 (along with others like pam_nisplus.so,
pam_ldap.so, etc.).  I'll check into the details and see if we could just
"not call pam_open_session() for non-interactive mode" or if we need to
call the acct mgmt front-end in some way first.  My guess is that if you
don't call pam_open_session(), it will prevent the crash, but then the
rest of the PAM calls will eventually get an error that indicates that the
password needs to be changed... and if we don't handle that for
non-interactive mode (like in.rshd), it's no big deal - the user will have
to login interactively first then he can run commands non-interactively.

I'll try to delve deeper tomorrow morning...

	Ed

>
> - Ben
>
> On Wed, 24 Oct 2001, Ed Phillips wrote:
>
> > Is it possible that this is a direct result of using the kludge -
> > specifying a bogus tty name which can't possibly be used to fetch a
> > password?  Probably, sshd should not call pam_open_session() in the case
> > where we are running in non-interactive mode - and sshd should just exit
> > with a "password expired" error if the password needs to be changed
> > in.rshd on Sol8 does not does not call the PAM session stuff.
> > pam_unix.so on Sol8 has a pam_sm_open_session() which requires the tty
> > name to be available (and my guess is that it must be valid as well -
> > hence the problems with not passing a tty name).  Sure, it's a bug in Sol8
> > pam_unix.so, but the docs are pretty thin regarding what
> > pam_sm_open_session() is supposed to do and whether the PAM_TTY is
> > required.  My guess that PAM_TTY is actually a required parameter (if
> > you're going to do PAM session stuff) and unexpected results will occur if
> > you just fill it with a bogus string.
> >
> > 	Ed
> >
> > On Wed, 24 Oct 2001 mouring at etoh.eviladmin.org wrote:
> >
> > > Date: Wed, 24 Oct 2001 09:27:48 -0500 (CDT)
> > > From: mouring at etoh.eviladmin.org
> > > Cc: "Dost, Alexander" <Alexander.Dost at drkw.com>, openssh-unix-dev at mindrot.org
> > > Subject: Re: Another round of testing calls.
> > >
> > >
> > > If PAM is doing the password change, then I have to agree with Markus.
> > > Could one of our Lurking Sun experts reproduce this and check if there is
> > > a bug in their PAM code or if we are missing a bit of code?
> > >
> > > - Ben
> > >
> > > On Wed, 24 Oct 2001, Markus Friedl wrote:
> > >
> > > > On Wed, Oct 24, 2001 at 10:46:57AM +0200, Dost, Alexander wrote:
> > > > > Is the problem with clear-text passwords after using the kludge on Sol8
> > > > > known and will it be fixed ?
> > > > > I didn't see any reply on this problem.
> > > >
> > > > this is probably a bug in the PAM: either they should
> > > > not depend on the TTY kludge or not ask for a password
> > > > if there is not TYY.
> > > >
> > > > -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 qralston+ml.openssh-unix-dev at andrew.cmu.edu  Thu Oct 25 07:24:18 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Wed, 24 Oct 2001 17:24:18 -0400 (EDT)
Subject: Another round of testing calls. (redhat/openssh.spec)
In-Reply-To: <Pine.LNX.4.33.0110242148180.13736-200000@netcore.fi>
Message-ID: <Pine.LNX.4.33.0110241717230.25486-100000@pcmy.sei.cmu.edu>

On Wed, 24 Oct 2001, Pekka Savola wrote:
> 3) Building appears to rely on the existance of openssl >= 0.9.6
> (OPENSSL_free function).  Mark the requirement there.

Don't say:

    Requires: openssl >= 0.9.6

Say:

    Requires: openssl
    Conflicts: openssl < 0.9.6

The former means "this package requires openssl, and will work with
any version of openssl from 0.9.6 on, through the rest of eternity".
That's not what you mean.

The latter means "this package requires openssl, but doesn't work with
versions of openssl less than 0.9.6".  That's what you mean.

(The same applies for PreReq.)

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From jasonm at panix.com  Thu Oct 25 07:34:17 2001
From: jasonm at panix.com (Jason McKay)
Date: Wed, 24 Oct 2001 17:34:17 -0400
Subject: OpenSSH/ls locks term
Message-ID: <20011024173416.A9527@panix.com>

Running "ls" on a large directory (/usr/bin) locks the term when using
protocol 2.0.  A tilde works to escape the session.  

Client: OpenSSH_2.9p2 on NetBSD

Server: OpenSSH_2.3.0 on FreeBSD

Output of ssh -v <FreeBSD host>:
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to myhost [my_ip] port 22.
debug1: restore_uid
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: identity file /net/u/1/j/jasonm/.ssh/identity type 0
debug1: identity file /net/u/1/j/jasonm/.ssh/id_rsa type -1
debug1: identity file /net/u/1/j/jasonm/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_2.3.0 FreeBSD localisations 20010713
debug1: match: OpenSSH_2.3.0 FreeBSD localisations 20010713 pat ^OpenSSH_2\.3\.0
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 193/384
debug1: bits set: 1034/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'myhost' is known and matches the DSA host key.
debug1: Found key in /net/u/1/j/jasonm/.ssh/known_hosts2:1
debug1: bits set: 1012/2049
debug1: len 55 datafellows 53376
debug1: ssh_dss_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
debug1: next auth method to try is publickey
debug1: try privkey: /net/u/1/j/jasonm/.ssh/id_rsa
debug1: try privkey: /net/u/1/j/jasonm/.ssh/id_dsa
debug1: next auth method to try is password






-- 
With all the fancy scientists in the world, why can't they just once
build a nuclear balm?


From pedwards at disaster.jaj.com  Thu Oct 25 07:55:45 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Wed, 24 Oct 2001 17:55:45 -0400
Subject: hanging on logout, can't background client
In-Reply-To: <20011024214216.A11531@folly>; from markus@openbsd.org on Wed, Oct 24, 2001 at 09:42:16PM +0200
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com> <20011024195832.A25142@folly> <20011024142754.A23601@disaster.jaj.com> <20011024214216.A11531@folly>
Message-ID: <20011024175545.A25622@disaster.jaj.com>

On Wed, Oct 24, 2001 at 09:42:16PM +0200, Markus Friedl wrote:
> please try this experimental patch.  could be included in 3.1

I'll try it tomorrow when I get a chance.  May not be until Friday.
And I will report on the results.


Thanks,
Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From monty at mysql.com  Sun Oct 21 15:28:04 2001
From: monty at mysql.com (Michael Widenius)
Date: Sun, 21 Oct 2001 08:28:04 +0300 (EEST)
Subject: Bug when flushing data in openssh 2.9
In-Reply-To: <20011017214835.A24543@faui02.informatik.uni-erlangen.de>
References: <15309.56223.967494.575540@narttu.mysql.fi>
	<20011017214835.A24543@faui02.informatik.uni-erlangen.de>
Message-ID: <15314.23780.317692.425661@tramp.mysql.fi>


Hi!

>>>>> "Markus" == Markus Friedl <markus at openbsd.org> writes:

Markus> On Wed, Oct 17, 2001 at 10:27:27PM +0300, Michael Widenius wrote:
>> 
>> Hi!
>> 
>> I am use SuSe 7.2 x86 and openssh-2.9p1-7.rpm
>> 
>> I got a problem using bitkeeper on my laptop where bitkeeper
>> reported an I/O error while reading data from 'ssh'.
>> 
>> After much debugging, and some help from the bitkeeper people, I found
>> out that that clientloop.c doesn't handle interrupts gracefully.
>> (It died when it got an EAGAIN error when writing to the application)
>> 
>> After applying the following patch, everything started to work for me:

Markus> 2.9 is very old, please check 2.9.9 at
Markus> 	http://www.openssh.com/portable.html
Markus> or try a recent snapshot.

2.9p1-7.rpm is the openssh version distributed with the latest SuSE
(7.2) distribution;  If it's very old, then we should inform SuSE that
they need to release an upgraded RPM to fix this, because this is a serious
bug!

I am now on a conference trip, so I have to delay checking the new
code until I am back.  If the bug still exists, I will repost my patch
to this list.

Thanks for the feedback!

Regards,
Monty


From jasonc at silicondefense.com  Thu Oct 25 10:17:47 2001
From: jasonc at silicondefense.com (C. Jason Coit)
Date: Wed, 24 Oct 2001 17:17:47 -0700
Subject: Defeating Timing Attacks
Message-ID: <3BD75A2B.8D46DC56@silicondefense.com>

All,

Update 10/24/2001
 
Thanks to suggestions by David Wagner (one of the authors of the timing 
analysis attack) and Stuart Staniford,  we have recently updated our SSH 
patch slightly. The original patch turned off the stream of bogus
packets
sent during an idle time after 1 second. This could possibly leak a
small
amount of information about the last genuine packet transmitted. To make
such analysis more difficult, SSH will require 900 ms of idle time
before
considering to shut off the transmission of bogus packets. Then with 
probability 1/5, SSH will shut off the stream at each succeeding packet.
Thus the exponential lifetime decay in the shut off is about 250ms. This 
means that the eavesdropper only knows to within a few packets when the 
last key press was. 

The new patch for 2.9.9p2 is provided below and a gzipped tar file of 
patched versions of 2.9.9p2 and 2.9p2 are available at
http://www.silicondefense.com/software/ssh/index.htm

regards,

-Jason

Patch:
--- channels.c	Mon Sep 17 22:53:12 2001
+++ channels.new.c	Tue Oct 23 12:15:57 2001
@@ -25,6 +25,32 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
@@ -1590,11 +1616,19 @@
 
 
 /* If there is data to send to the connection, enqueue some of it now.
*/
-
+/*
+ * SD Mod: add arguments bogus_send_count and
use_steno_timing_manipulation 
+ * to channel_output_poll.
+*/
 void
-channel_output_poll()
+channel_output_poll(int *bogus_send_count, int
use_steno_timing_manipulation)
 {
 	int len, i;
+	/*
+	 * SD Mod: Added for random shutoff of garbage packets past 900ms of
+	 * no real data sent.
+	 */
+	double rand_shutoff;
 	Channel *c;
 
 	for (i = 0; i < channels_alloc; i++) {
@@ -1649,11 +1683,93 @@
 				    SSH2_MSG_CHANNEL_DATA : SSH_MSG_CHANNEL_DATA);
 				packet_put_int(c->remote_id);
 				packet_put_string(buffer_ptr(&c->input), len);
+				/* 
+				 *  Begin SD Mod: if using SSH2 and it is 
+				 *  desired to use timing manipulation, reset
+				 *  counter since len > 0 implies packet will
+				 *  contain geniune data.
+				 */
+				if(compat20 && use_steno_timing_manipulation)
+				  {
+				    (*bogus_send_count)=0;
+				    debug2("reseting count");
+				  }
+				/* End SD Mod */
 				packet_send();
 				buffer_consume(&c->input, len);
 				c->remote_window -= len;
 			}
-		} else if (c->istate == CHAN_INPUT_WAIT_DRAIN) {
+		}
+		  /*
+		   * Begin SD Mod:
+		   * packet does not contain data, we are not in a draining
+		   * state and timing manipulation is desired,
+		   * check to see if we are to send bogus packets.
+		   */
+		else if ((len = buffer_len(&c->input)) == 0 
+			 && !(c->istate == CHAN_INPUT_WAIT_DRAIN) 
+			 && use_steno_timing_manipulation) {   		     
+		  /* 
+		   * For the first 900 ms, send a 16 byte ignore packet 
+		   * filled with garbage data and update the bogus_send_count;
+		   * Note: 18*50ms = 900 ms.
+		   * Bogus_send count is used to keep state of the first 
+		   * 18 packets and then is set to 20 when we randomly
+		   * shut off flow of garbage packets as described below. 
+		   */
+		  
+		  if((*bogus_send_count) < 18){
+		      debug2("sending garbage packet");
+		      packet_send_ignore(16);
+		      packet_send();
+		      (*bogus_send_count)++;
+		    }
+		    else if((*bogus_send_count) != 20)
+		      {
+			/*
+			 * After 900 ms, shut off garbage output with 
+			 * probability 1/5.  Repeat for each succeeding
+			 * timeout past 900 ms until counter reset (i.e. real
+			 * data has been sent) or rand_shutoff <= .2.
+			 *  
+			 * Thus the exponential lifetime decay in the cutoff
+			 * is 250 ms.  So an eavesdropper only knows 
+			 * within a few packets when the last keypress was.
+			 *
+			 * Keep state by if checking bogus_send_count == 20.
+			 */
+			
+			rand_shutoff = arc4random() / (double) UINT_MAX;  
+			debug("Random is:%lf",rand_shutoff);
+			
+			if(rand_shutoff <= ((double) .2))
+			  {
+			    /* 
+			     * If we have hit that 1/5 chance, shut off 
+			     * the flow of garbage packets. 
+			     * Update bogus_send_count (now used as flag) to 
+			     * be 20.
+			     */
+			    (*bogus_send_count) = 20;
+			    debug("Random shutoff: stop sending garbage packets");
+			  }
+			else
+			  { 
+			    /* 
+			     * Random shutoff did not occur, so send bogus packet.
+			     */
+			    debug2("sending garbage packet");
+			    packet_send_ignore(16);
+			    packet_send();
+			  }
+		      }
+		    else
+		      debug("Random Shutoff past 900ms occurred: stop sending garbage
packets");
+		    
+		  }
+		/* End SD Mod */ 
+
+		else if (c->istate == CHAN_INPUT_WAIT_DRAIN) {
 			if (compat13)
 				fatal("cannot happen: istate == INPUT_WAIT_DRAIN for proto 1.3");
 			/*
--- channels.h	Mon Sep 17 22:51:14 2001
+++ channels.new.h	Tue Oct 23 12:15:57 2001
@@ -21,6 +21,33 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -173,7 +200,15 @@
 
 void	 channel_prepare_select(fd_set **, fd_set **, int *, int*, int);
 void     channel_after_select(fd_set *, fd_set *);
-void     channel_output_poll(void);
+
+/*
+ * SD Mod: added parameters bogus_send_count, and
use_steno_timing_manipulation.
+ * The bogus_send_count keeps track of how many bogus packets have been
sent since
+ * the last packet containing real data.  The
use_steno_timining_manipulation flag
+ * keeps track of whether to perform timing analysis evasion.
+ */
+void channel_output_poll(int *bogus_send_count, int
use_steno_timing_manipulation);
+
 
 int      channel_not_very_much_buffered_data(void);
 void     channel_close_all(void);
--- clientloop.c	Mon Sep 17 22:51:14 2001
+++ clientloop.new.c	Tue Oct 23 12:15:57 2001
@@ -46,6 +46,33 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/22/2001.
+
*************************************************************************** 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -315,16 +342,28 @@
  * Waits until the client can do something (some data becomes available
on
  * one of the file descriptors).
  */
-
-static void
+/* 
+ * SD Mod: We changed the return value of
client_wait_until_can_do_something 
+ * from void to int.  It now returns 1 if the steno_timer has expired
and 0 if not.
+ */
+int
 client_wait_until_can_do_something(fd_set **readsetp, fd_set
**writesetp,
     int *maxfdp, int *nallocp, int rekeying)
 {
+        /*
+	 * SD Mod: added variable steno_timer 
+	 * Added return_val and prev_timer_val
+	 */
+        static struct timeval steno_timer = {0, 50000};
+	int return_val = 0;
+	long int prev_timer_val = 0;
+	/* End SD Mod */
+
 	/* Add any selections by the channel mechanism. */
 	channel_prepare_select(readsetp, writesetp, maxfdp, nallocp,
rekeying);
 
 	if (!compat20) {
-		/* Read from the connection, unless our buffers are full. */
+	  /* Read from the connection, unless our buffers are full. */
 		if (buffer_len(&stdout_buffer) < buffer_high &&
 		    buffer_len(&stderr_buffer) < buffer_high &&
 		    channel_not_very_much_buffered_data())
@@ -342,13 +381,7 @@
 		if (buffer_len(&stderr_buffer) > 0)
 			FD_SET(fileno(stderr), *writesetp);
 	} else {
-		/* channel_prepare_select could have closed the last channel */
-		if (session_closed && !channel_still_open()) {
-			if (!packet_have_data_to_write())
-				return;
-		} else {
-			FD_SET(connection_in, *readsetp);
-		}
+		FD_SET(connection_in, *readsetp);
 	}
 
 	/* Select server connection if have data to write to the server. */
@@ -363,9 +396,34 @@
 	 * it: just have a random timeout for the select, and send a random
 	 * SSH_MSG_IGNORE packet when the timeout expires.
 	 */
+	
+	/*
+	 * Begin SD Mod: 
+	 * Enforce wait send packets every 50 ms.  To do this add timer to 
+	 * select loop.  Buffer input as it comes and force the timer to
decrement
+	 * if select call does not do so.   
+	 */
+	prev_timer_val = steno_timer.tv_usec;
+
+	return_val = select((*maxfdp)+1, *readsetp, *writesetp, NULL,
&steno_timer);
 
-	if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0) {
-		char buf[100];
+	/* SD Mod continued:
+	 * If the prev_timer_val is still equal to the steno_timer.tv_usec
value
+	 * then select did not decrement timer.  So force decrement so timer
can
+	 * expire. This problem arises since the file descriptors change since
they 
+	 * were reset just prior to entering the select loop.  This is a
strange
+	 * fix but it works.
+	 */
+	
+	  if(prev_timer_val == steno_timer.tv_usec){
+	    debug3("decrementing timer forcefully");
+	    steno_timer.tv_usec -= 100;
+	  }
+
+	  if(return_val < 0){
+	/* end of SD Mod */
+	    
+	    char buf[100];
 
 		/*
 		 * We have to clear the select masks, because we return.
@@ -376,14 +434,29 @@
 		memset(*writesetp, 0, *maxfdp);
 
 		if (errno == EINTR)
-			return;
+			return 0;
 		/* Note: we might still have data in the buffers. */
 		snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno));
 		buffer_append(&stderr_buffer, buf, strlen(buf));
 		quit_pending = 1;
 	}
+	  /* 
+	   * Begin SD Mod: Return to the caller whether the timer has 
+	   * expired or not. It is possible that the forced decrement caused 
+	   * the timer value to bbecome negative, if so the consider the 
+	   * timer expired, reset it and return 1 to the caller denoting timer 
+	   * expiration.
+	   */	
+	  if(steno_timer.tv_usec <= 0)
+	    {
+	      steno_timer.tv_usec = 50000;
+	      return 1;  
+	    }
+	  else
+	    return 0;
+	  /* End SD Mod */
+		  
 }
-
 static void
 client_suspend_self(Buffer *bin, Buffer *bout, Buffer *berr)
 {
@@ -773,6 +846,15 @@
 	int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0;
 	char buf[100];
 
+	/*
+	 * Begin SD Mod: 
+	 * Add counter for number of fake packets that have been sent.
+	 * Add time_out flag for marking when timeout has occured.
+	 */
+	int bogus_send_count = 0;
+	int time_out = 0;
+	/* End SD Mod */
+
 	debug("Entering interactive session.");
 
 	start_time = get_current_time();
@@ -861,9 +943,16 @@
 			 * Make packets from buffered channel data, and
 			 * enqueue them for sending to the server.
 			 */
-			if (packet_not_very_much_data_to_write())
-				channel_output_poll();
-
+			/*
+			 * Begin SD Mod: on expiration of 50 ms timer call 
+			 * channel_ouput 
+			 */
+			if(time_out){
+			 
channel_output_poll(&bogus_send_count,options.use_steno_timing_manipulation);
+			  time_out = 0;
+			}
+			/* End SD Mod */
+			
 			/*
 			 * Check if the window size has changed, and buffer a
 			 * message about it to the server if so.
@@ -878,8 +967,10 @@
 		 * available on one of the descriptors).
 		 */
 		max_fd2 = max_fd;
-		client_wait_until_can_do_something(&readset, &writeset,
-		    &max_fd2, &nalloc, rekeying);
+
+		/* SD Mod: wait for data or timeout */
+	        time_out = client_wait_until_can_do_something(&readset,
+				 &writeset, &max_fd2, &nalloc, rekeying);		
 
 		if (quit_pending)
 			break;
@@ -1222,6 +1313,21 @@
 		exit_status = packet_get_int();
 		packet_done();
 	}
+	/*
+	 * Begin SD Mod: 
+	 * check to see if request from server is to turn off steno.
+	 * If so, turn it off if neccessary.  
+	 */
+	else if (strcmp(rtype, "no_steno") == 0) { 
+	  debug("received request not use use steno");
+	  if(options.use_steno_timing_manipulation)
+	    {
+	      options.use_steno_timing_manipulation = 0;
+	    }
+	  success = 1;
+	  packet_done();
+	}
+	/* End SD Mod */
 	if (reply) {
 		packet_start(success ?
 		    SSH2_MSG_CHANNEL_SUCCESS : SSH2_MSG_CHANNEL_FAILURE);
--- readconf.c	Wed Sep 19 17:57:56 2001
+++ readconf.new.c	Tue Oct 23 12:15:57 2001
@@ -9,6 +9,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+ *
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
  */
 
 #include "includes.h"
@@ -793,6 +819,12 @@
 	options->preferred_authentications = NULL;
 	options->bind_address = NULL;
 	options->smartcard_device = NULL;
+	/*
+	 * SD Mod: Initialize option to use steno timing manipulation.
+	 * By default, timing analysis evasion is used.  The -S flag 
+	 * must be used to turn off this feature.
+	 */
+	options->use_steno_timing_manipulation = 1;
 }
 
 /*
--- readconf.h	Wed Sep 19 17:57:56 2001
+++ readconf.new.h	Tue Oct 23 12:15:57 2001
@@ -9,6 +9,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+ *
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
  */
 
 /* RCSID("$OpenBSD: readconf.h,v 1.39 2001/09/19 19:24:18 stevesk Exp
$"); */
@@ -101,6 +127,14 @@
 	int     num_remote_forwards;
 	Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION];
 	int	clear_forwardings;
+
+	/*
+	 * SD Mod: Added option to use steno timing manipulation.
+	 * By default, timing analysis evasion is used.  The -S flag 
+	 * must be used to turn off this feature.
+	 */
+        int     use_steno_timing_manipulation;
+
 }       Options;
 
 
--- servconf.c	Wed Sep 12 09:32:15 2001
+++ servconf.new.c	Tue Oct 23 12:15:57 2001
@@ -7,6 +7,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
+ *
  */
 
 #include "includes.h"
@@ -105,6 +131,12 @@
 	options->authorized_keys_file = NULL;
 	options->authorized_keys_file2 = NULL;
 	options->pam_authentication_via_kbd_int = -1;
+	/*
+	 * SD Mod: Initialize option to use steno timing manipulation.
+	 * By default, timing analysis evasion is used.  The -S flag 
+	 * must be used to turn off this feature.
+	 */
+	options->use_steno_timing_manipulation = 1;
 }
 
 void
--- servconf.h	Wed Sep 12 09:40:06 2001
+++ servconf.new.h	Tue Oct 23 12:15:57 2001
@@ -9,6 +9,32 @@
  * software must be clearly marked as such, and if the derived work is
  * incompatible with the protocol description in the RFC file, it must
be
  * called by a name other than "ssh" or "Secure Shell".
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*************************************************************************** 
+ *
  */
 
 /* RCSID("$OpenBSD: servconf.h,v 1.49 2001/08/17 18:59:47 stevesk Exp
$"); */
@@ -129,7 +155,12 @@
 	char   *authorized_keys_file;	/* File containing public keys */
 	char   *authorized_keys_file2;
 	int	pam_authentication_via_kbd_int;
-
+	/*
+	 * SD Mod: Added option to use steno timing manipulation.
+	 * By default, timing analysis evasion is used.  The -S flag 
+	 * must be used to turn off this feature.
+	 */
+        int     use_steno_timing_manipulation;
 }       ServerOptions;
 
 void	 initialize_server_options(ServerOptions *);
--- serverloop.c	Mon Sep 17 22:53:13 2001
+++ serverloop.new.c	Tue Oct 23 12:15:57 2001
@@ -21,6 +21,31 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
+
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/22/2001.
+
***************************************************************************
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
@@ -167,15 +192,29 @@
  * have data or can accept data.  Optionally, a maximum time can be
specified
  * for the duration of the wait (0 = infinite).
  */
-static void
+
+/*
+ * SD Mod: 
+ * We changed wait_until_can_do_something's return value from void
+ * to int.  It now returns 1 if the steno_timer has expired and 0 if
not.
+ */
+int
 wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int
*maxfdp,
     int *nallocp, u_int max_time_milliseconds)
 {
-	struct timeval tv, *tvp;
+  
+        struct timeval tv, *tvp;
 	int ret;
 	int client_alive_scheduled = 0;
-
 	/*
+	 * SD Mod: added variable steno_timer 
+	 * Added prev_timer_val
+	 */
+	static struct timeval steno_timer = {0, 50000};
+	long int prev_timer_val = 0;
+	/* End SD Mod */
+	
+	/* 
 	 * if using client_alive, set the max timeout accordingly, 
 	 * and indicate that this particular timeout was for client
 	 * alive by setting the client_alive_scheduled flag.
@@ -183,11 +222,11 @@
 	 * this could be randomized somewhat to make traffic
 	 * analysis more difficult, but we're not doing it yet.  
 	 */
-	if (compat20 &&
-	    max_time_milliseconds == 0 && options.client_alive_interval) {
-		client_alive_scheduled = 1;
+	if (max_time_milliseconds == 0 && options.client_alive_interval) {
+	        client_alive_scheduled = 1;
 		max_time_milliseconds = options.client_alive_interval * 1000;
-	}
+	} else 
+	        client_alive_scheduled = 0;
 
 	/* When select fails we restart from here. */
 retry_select:
@@ -199,7 +238,8 @@
 		/* wrong: bad condition XXX */
 		if (channel_not_very_much_buffered_data())
 			FD_SET(connection_in, *readsetp);
-	} else {
+	
+} else {
 		/*
 		 * Read packets from the client unless we have too much
 		 * buffered stdin or channel data.
@@ -250,8 +290,21 @@
 	if (tvp!=NULL)
 		debug3("tvp!=NULL kid %d mili %d", child_terminated,
max_time_milliseconds);
 
+
+	/* SD Mod: if select does not decrement timer, force it.*/	
+	prev_timer_val = steno_timer.tv_usec;   
+	
+	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, &steno_timer);
+	
+	if(prev_timer_val == steno_timer.tv_usec)
+	  {
+	    debug3 ("decrementing timer forcefully");
+	    steno_timer.tv_usec -= 100;    
+	  }
+	/* End SD Mod */
+
 	/* Wait for something to happen, or the timeout to expire. */
-	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
+
 
 	if (ret == -1) {
 		if (errno != EINTR)
@@ -259,9 +312,11 @@
 		else
 			goto retry_select;
 	}
+	
 	if (ret == 0 && client_alive_scheduled) {
 		/* timeout, check to see how many we have had */
-		client_alive_timeouts++;
+	  
+	  client_alive_timeouts++;
 
 		if (client_alive_timeouts > options.client_alive_count_max ) {
 			packet_disconnect(
@@ -282,9 +337,27 @@
 				packet_disconnect(
 					"No open channels after timeout!");
 		}
-	} 
+	}
+
+	/* 
+	 * Begin SD Mod: Return to the caller whether the timer has 
+	 * expired or not. It is possible that the forced decrement caused 
+	 * the timer value to bbecome negative, if so the consider the 
+	 * timer expired, reset it and return 1 to the caller denoting timer 
+	 * expiration.
+	 */	
+	if(steno_timer.tv_usec <= 0)
+	 {
+	   steno_timer.tv_usec = 50000;
+	   return 1;
+	 }	
+	else
+	  return 0;
+	/* End SD Mod */
+
 }
 
+
 /*
  * Processes input from the client and the program.  Input data is
stored
  * in buffers and processed later.
@@ -448,6 +521,13 @@
 	u_int stdout_buffer_bytes;
 	int type;
 
+	/*
+	 * Begin SD Mod: 
+ 	 * NOT USED only here for compatibility with channel_output_poll().
+	 */
+	int bogus_send_count = 0;
+	/* End SD Mod */
+
 	debug("Entering interactive session.");
 
 	/* Initialize the SIGCHLD kludge. */
@@ -549,8 +629,15 @@
 		previous_stdout_buffer_bytes = buffer_len(&stdout_buffer);
 
 		/* Send channel data to the client. */
-		if (packet_not_very_much_data_to_write())
-			channel_output_poll();
+		/* 
+		 * Begin SD Mod: use bogus_send_count to comply 
+		 * with channel_output_poll definition.
+		 */
+		if(packet_not_very_much_data_to_write())
+		  channel_output_poll(&bogus_send_count,0);
+		/*
+		 * End SD Mod 
+		 */ 
 
 		/*
 		 * Bail out of the loop if the program has closed its output
@@ -579,7 +666,7 @@
 		max_fd = MAX(max_fd, fderr);
 
 		/* Sleep in select() until we can do something. */
-		wait_until_can_do_something(&readset, &writeset, &max_fd,
+		 wait_until_can_do_something(&readset, &writeset, &max_fd,
 		    &nalloc, max_time_milliseconds);
 
 		/* Process any channel events. */
@@ -676,6 +763,15 @@
 	int rekeying = 0, max_fd, status, nalloc = 0;
 	pid_t pid;
 
+	/* 
+	 * Begin SD Mod: 
+	 * Add counter for number of fake packets that have been sent.
+	 * Add time_out flag for marking when timeout has occured.
+	 */
+	int bogus_send_count = 0 ;
+	int time_out = 0;
+	/* End SD Mod */
+
 	debug("Entering interactive session for SSH2.");
 
 	mysignal(SIGCHLD, sigchld_handler);
@@ -692,30 +788,44 @@
 		process_buffered_input_packets();
 
 		rekeying = (xxx_kex != NULL && !xxx_kex->done);
-
-		if (!rekeying && packet_not_very_much_data_to_write())
-			channel_output_poll();
-		wait_until_can_do_something(&readset, &writeset, &max_fd,
-		    &nalloc, 0);
+		
+		/*
+		 * Begin SD Mod: send packets only when not rekeying and
+		 * 50 ms timer has expired. 
+		 */
+		if (!rekeying && time_out) 
+		  {
+		   
channel_output_poll(&bogus_send_count,options.use_steno_timing_manipulation);
+		    time_out = 0;
+		  }
+		
+
+		/* 
+		 * SD Mod: added time_out flag to record when 
+		 * 50 ms timer has expired.
+		 */
+		time_out = wait_until_can_do_something(&readset, &writeset, &max_fd,
&nalloc, rekeying);
+		/* End SD Mod */
+		
 		if (child_terminated) {
-			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
-				session_close_by_pid(pid, status);
-			child_terminated = 0;
+		  while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
+		    session_close_by_pid(pid, status);
+		  child_terminated = 0;
 		}
 		if (!rekeying)
-			channel_after_select(readset, writeset);
+		  channel_after_select(readset, writeset);
 		process_input(readset);
 		if (connection_closed)
-			break;
+		  break;
 		process_output(writeset);
 	}
 	if (readset)
-		xfree(readset);
+	  xfree(readset);
 	if (writeset)
-		xfree(writeset);
+	  xfree(writeset);
 
 	mysignal(SIGCHLD, SIG_DFL);
-
+	
 	while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
 		session_close_by_pid(pid, status);
 	/*
@@ -894,6 +1004,17 @@
 			packet_put_int(c->local_maxpacket);
 			packet_send();
 		}
+		/* 
+		 * SD Mod: if -S option is used, request 
+		 * client to not use stenographic timing manipulation as well.
+		 */
+		if(!options.use_steno_timing_manipulation)
+		  {
+		    debug("sending no steno msg");
+		    channel_request(c->remote_id,"no_steno",0);
+		  }
+		/* End SD Mod */
+
 	} else {
 		debug("server_input_channel_open: failure %s", ctype);
 		packet_start(SSH2_MSG_CHANNEL_OPEN_FAILURE);
--- session.c	Sun Sep 16 15:17:15 2001
+++ session.new.c	Tue Oct 23 12:15:57 2001
@@ -20,6 +20,32 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+
***************************************************************************
+ *
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/13/2001.
+
*************************************************************************** 
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -1726,6 +1752,24 @@
 	return 1;
 }
 
+
+/*
+ * Begin SD Mod: This function is added to handle a request from the 
+ * client to turn off steno timing manipulation.  
+ */
+int
+session_no_steno_req(Session *s)
+{
+	packet_done();
+	debug("handling steno request");
+	if(options.use_steno_timing_manipulation)
+	  {
+	    options.use_steno_timing_manipulation = 0;
+	  }
+	return 1;
+}
+/* End SD Mod */
+
 static int
 session_exec_req(Session *s)
 {
@@ -1795,6 +1839,14 @@
 		} else if (strcmp(rtype, "subsystem") == 0) {
 			success = session_subsystem_req(s);
 		}
+		/* 
+		 * Begin SD Mod: Handle request from the client 
+		 * to turn off server's timing manipulation.
+		 */ 
+		else if (strcmp(rtype, "no_steno") == 0) {
+		  success = session_no_steno_req(s);
+		}
+		/* End SD Mod */
 	}
 	if (strcmp(rtype, "window-change") == 0) {
 		success = session_window_change_req(s);
--- ssh.c	Mon Sep 24 15:04:03 2001
+++ ssh.new.c	Tue Oct 23 12:15:57 2001
@@ -26,6 +26,31 @@
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
  *
+ *
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
***************************************************************************
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.
@@ -205,6 +230,8 @@
 	fprintf(stderr, "  -o 'option' Process the option as if it was read
from a configuration file.\n");
 	fprintf(stderr, "  -s          Invoke command (mandatory) as SSH2
subsystem.\n");
 	fprintf(stderr, "  -b addr     Local IP address.\n");
+	/* SD Mod: */
+	fprintf(stderr, "  -S          Don't use stenographic timing
manipulation\n");
 	exit(1);
 }
 
@@ -319,8 +346,9 @@
 	host = NULL;
 
 again:
+	/* SD Mod: add s option to getopt() call */
 	while ((opt = getopt(ac, av,
-	    "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) {
+	    "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:STVX")) != -1) {
 		switch (opt) {
 		case '1':
 			options.protocol = SSH_PROTO_1;
@@ -525,6 +553,14 @@
 		case 's':
 			subsystem_flag = 1;
 			break;
+			/*
+			 * Begin SD Mod: Add case to handle option to turn off
+			 * steno timing manipulation.
+			 */
+		case 'S':
+		        options.use_steno_timing_manipulation = 0;
+			break;
+			/* End SD Mod */
 		case 'b':
 			options.bind_address = optarg;
 			break;
@@ -1080,6 +1116,20 @@
 		channel_request_start(id, "auth-agent-req at openssh.com", 0);
 		packet_send();
 	}
+
+	/*
+	 * Begin SD Mod: If the client has the option to turn of timing
+	 * manipulation set, send a request message to the server to 
+	 * turn off its timing manipulation.
+	 */
+	if (!options.use_steno_timing_manipulation)
+	  {
+	    debug("sending request for no steno.");
+	    channel_request_start(id, "no_steno",0);
+	    packet_send();
+	  }
+	/* End SD Mod */
+
 
 	len = buffer_len(&command);
 	if (len > 0) {
--- sshd.c	Mon Sep 17 21:03:04 2001
+++ sshd.new.c	Tue Oct 23 12:15:57 2001
@@ -26,6 +26,31 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in
the
  *    documentation and/or other materials provided with the
distribution.
+ *
***************************************************************************
+ * Timing Analysis Evasion changes were developed by C. Jason Coit and
Roel
+ * Jonkman of Silicon Defense. 
+ *
+ * These changes cause SSH to send packets unless requested not to,
exactly 
+ * every 50 ms.  If no data is ready to be sent, SSH will send a bogus
packet 
+ * with 16 bytes of data (which is the same size as most keystrokes). 
Thus
+ * someone performing timing analysis cannot determine the inter
keystroke 
+ * timing of a user.  SSH will send bogus data for about 1 sec after
the last
+ * keystroke.  This both increases the difficulty of determing exact
password
+ * lengths and conserves bandwith when a user is idle (e.g. taking a
coffee break).
+ * Both the server and the client exhibit this behavior and yet our
code places no 
+ * limit on the data rate (i.e if the server needs to respond with
large amounts 
+ * of data it will be about to do so with large packets able to do so
with large
+ * packets and without the 50 ms timing constraint).
+ *
+ * All changes were developed in response to timing analysis attack on
ssh 
+ * published by Dawn Song et. al.  
+ *
+ * The evasion methods are only applicable to SSH2.  All single line
changes
+ * and small comments are marked by SD Mod.  All multiline
modifications are 
+ * delimited by Begin SD Mod and End SD Mod.  
+ *
+ * The last change was committed on 10/3/2001.
+
*******************************************************************************
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES
@@ -563,6 +588,7 @@
 	initialize_server_options(&options);
 
 	/* Parse command-line arguments. */
+	/* SD Mod: add s option to getopt() call */
 	while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDeiqtQ46")) != -1) {
 		switch (opt) {
 		case '4':
@@ -645,6 +671,14 @@
 		case 'u':
 			utmp_len = atoi(optarg);
 			break;
+			/*
+			 * Begin SD Mod: Add option to handle option to turn off
+			 * steno timing manipulation. 
+			 */
+		case 'S':
+		        options.use_steno_timing_manipulation = 0;
+			break;
+			/* End SD Mod */
 		case '?':
 		default:
 			fprintf(stderr, "sshd version %s\n", SSH_VERSION);
@@ -665,6 +699,9 @@
 			fprintf(stderr, "  -u len     Maximum hostname length for utmp
recording\n");
 			fprintf(stderr, "  -4         Use IPv4 only\n");
 			fprintf(stderr, "  -6         Use IPv6 only\n");
+			/* SD Mod */
+			fprintf(stderr, "  -S         Don't use stenographic timing
manipulation\n");
+
 			exit(1);
 		}
 	}




+--                                             --+
|        C. Jason Coit Programmer/Analyst          |
| *Silicon Defense - Technical Support for Snort* |
|        http://www.silicondefense.com/           |
+--                                              -+


From djm at mindrot.org  Thu Oct 25 10:32:50 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 Oct 2001 10:32:50 +1000 (EST)
Subject: disable features
In-Reply-To: <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110251030290.6250-100000@mothra.mindrot.org>

On Wed, 24 Oct 2001, Ed Phillips wrote:

> On Wed, 24 Oct 2001, Lutz Jaenicke wrote:
> 
> > Consider a ssh[d] that has been compiled without X11 forwarding.
> 
> Speaking of X11Forwarding... is there any particular reason that somewhere
> between v2.9p2 and v2.9.9p2 there has been a change to the stock
> sshd_config to disable X11Forwarding?

X11Forwarding been off by default for ages (ever?). Perhaps you had a 
vendor RPM which had it enabled by default.

> Also, is there any particular reason that authentication forwarding has
> been disabled in 2.X (I'm not sure when, execpt that every since we've
> been trying out 2.X it has been disabled by default).

If you are forwarding your agent to a malicious host, they can sign 
arbitrary challenges using your keys.

-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  Thu Oct 25 10:37:47 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 Oct 2001 10:37:47 +1000 (EST)
Subject: sftp interactive mode on LynxOS
In-Reply-To: <20011024135821.88652.qmail@web8004.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.33.0110251036000.6250-100000@mothra.mindrot.org>

On Wed, 24 Oct 2001, hari sekar wrote:

> Hi,
>   I work on openssh-2.9p2 installed on LynxOS i386
> system. sshd, ssh, scp and sftp-server all work fine.
> The problem is sftp client, in interactive mode, exits
> after authentication printing the sftp prompt. sftp
> client works fine in non-interactive mode.
> i.e.,
> lynxos>sftp hari at linuxsystem:test 
> works fine
> But,
> lynxos>sftp hari at linuxsystem
> ...
> sftp>
> lynxos>
> Any help, as to why sftp exits in interactive mode.

It appears that either no one else has LynxOS or they won't, can't or 
don't want to help you.

In any case, sending the same message to the list repeatedly is not
going to change this.

-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 Darren.Moffat at eng.sun.com  Thu Oct 25 10:39:19 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Wed, 24 Oct 2001 17:39:19 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
Message-ID: <200110250039.f9P0dJuI276076@jurassic.eng.sun.com>


>Okay, this appears to be a problem with pam_unix.so - the code in
>pam_sm_open_session is written with the assumption that the tty name is of
>the form "/dev/" + something else on the end.  I'm not sure why the

pam_sm_open_session in pam_unix on Solaris now does this:

        /* report error if ttyn or rhost are not set */
        if ((ttyn == NULL) || (rhost == NULL))
                return (PAM_SESSION_ERR);

        /* sanity check on size of tty line */
        if (strlen(ttyn) < sizeof("/dev/"))
                return (PAM_SESSION_ERR);

later on it uses everything after the /dev/ as the short name tty to
write to lastlog.

This was part of the fix for 4250887. The fix will appear in patch
111659-03 (sparc) and 111660-03 (intel) when that patch is released.

--
Darren J Moffat



From Darren.Moffat at eng.sun.com  Thu Oct 25 10:44:25 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Wed, 24 Oct 2001 17:44:25 -0700 (PDT)
Subject: Another round of testing calls.
Message-ID: <200110250044.f9P0iOuI276600@jurassic.eng.sun.com>

>How do you enforce PAM limits without opening a session then?

pam_limits should probably be either an pam_acct_mgmt or pam_setid module.

pam_limits doesn't exist on Solaris.  Solaris does how ever have pam_projects
which deals with setting resource control information for project(4).

It isn't really clear from the man pages what the true purpose of 
pam_open_session is but it can be infered from the Solaris man pages that
it is really about dealing with files like lastlog/utmpx/wtmpx.


--
Darren J Moffat



From djm at mindrot.org  Thu Oct 25 10:45:34 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 Oct 2001 10:45:34 +1000 (EST)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110250039.f9P0dJuI276076@jurassic.eng.sun.com>
Message-ID: <Pine.LNX.4.33.0110251043580.6250-100000@mothra.mindrot.org>

On Wed, 24 Oct 2001, Darren Moffat wrote:

> 
> >Okay, this appears to be a problem with pam_unix.so - the code in
> >pam_sm_open_session is written with the assumption that the tty name is of
> >the form "/dev/" + something else on the end.  I'm not sure why the
> 
> pam_sm_open_session in pam_unix on Solaris now does this:
> 
>         /* report error if ttyn or rhost are not set */
>         if ((ttyn == NULL) || (rhost == NULL))
>                 return (PAM_SESSION_ERR);
> 
>         /* sanity check on size of tty line */
>         if (strlen(ttyn) < sizeof("/dev/"))
>                 return (PAM_SESSION_ERR);
> 
> later on it uses everything after the /dev/ as the short name tty to
> write to lastlog.
> 
> This was part of the fix for 4250887. The fix will appear in patch
> 111659-03 (sparc) and 111660-03 (intel) when that patch is released.

IMO until then we should enable the kludge, but change it as follows.
Kevin, can you check whether the kludge works with this patch on HP/UX?
(is the kludge even needed there?)

Index: auth-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth-pam.c,v
retrieving revision 1.37
diff -u -r1.37 auth-pam.c
--- auth-pam.c	2001/04/23 18:38:37	1.37
+++ auth-pam.c	2001/10/25 00:43:55
@@ -374,7 +374,7 @@
 	 * not even need one (for tty-less connections)
 	 * Kludge: Set a fake PAM_TTY
 	 */
-	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
+	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
 	if (pam_retval != PAM_SUCCESS)
 		fatal("PAM set tty failed[%d]: %.200s",
 		    pam_retval, PAM_STRERROR(__pamh, pam_retval));

-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  Thu Oct 25 10:48:16 2001
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 Oct 2001 10:48:16 +1000 (EST)
Subject: OpenSSH/ls locks term
In-Reply-To: <20011024173416.A9527@panix.com>
Message-ID: <Pine.LNX.4.33.0110251047450.6250-100000@mothra.mindrot.org>

On Wed, 24 Oct 2001, Jason McKay wrote:

> Running "ls" on a large directory (/usr/bin) locks the term when using
> protocol 2.0.  A tilde works to escape the session.  
> 
> Client: OpenSSH_2.9p2 on NetBSD
> 
> Server: OpenSSH_2.3.0 on FreeBSD
> 
> Output of ssh -v <FreeBSD host>:

This output is not complete - it doesn't even complete authentication.

-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  Thu Oct 25 06:26:11 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 24 Oct 2001 16:26:11 -0400
Subject: Default forwarding features; default cipher
In-Reply-To: <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu>; from ed@UDel.Edu on Wed, Oct 24, 2001 at 02:49:47PM -0400
References: <20011024192422.A27605@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu>
Message-ID: <20011024162611.B2657@zax.half.pint-stowp.cx>

Circa 2001-Oct-24 14:49:47 -0400 dixit Ed Phillips:

: I guess the only gotcha is that you have to enable X11 forwarding in
: sshd_config.  It appears that by default "ssh -X" is silently
: ignored on the server side, and "ssh -A" works fine... and normally
: you get no forwarding from the client without adding the "-A" or
: "-X".  Is this correct?

Yes, that's correct.  Both the server and the client must explicitly
allow X11 forwarding; the default configuration allows it in neither
place.

: By the way, I notice in the stock ssh_config, it would appear that
: "blowfish" is the default cipher.  Is this used for speed or because
: it provides the best security or both?

Are you sure you're reading the default ssh_config file, and that
you're reading it correctly?  To my recollection, the default
ssh_config file is "empty" (i.e., contains no non-blank, uncommented
lines).  According to the man page, the default value for the 'Cipher'
keyword is '3des'.  The 'Cipher' (singular) keyword, however, is only
for SSH protocol v1.  For SSH protocol v2, the 'Ciphers' (plural)
keyword applies; the default configuration asks for 'aes128-cbc' first.

That said, i don't know of any reason for you not to configure "Cipher
blowfish" and "Ciphers blowfish-cbc,..." as defaults.  Blowfish is a
fast cipher, and it's been around for quite a while....

-- 
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/20011024/c22b14f5/attachment.bin 

From tim at multitalents.net  Thu Oct 25 13:46:44 2001
From: tim at multitalents.net (Tim Rice)
Date: Wed, 24 Oct 2001 20:46:44 -0700 (PDT)
Subject: configure changes
In-Reply-To: <20011024110558.A27428@lucent.com>
Message-ID: <Pine.UW2.4.40.9.0110242044100.7705-100000@uw711.int.multitalents.net>

On Wed, 24 Oct 2001, Dave Dykstra wrote:

>
> Aack!  Why are all those -I/usr/local/include in CPPFLAGS and
> -L/usr/local/lib in LDFLAGS for many different machine types in
> configure.in?  The contents of those directories are different depending on
> individual system installations, right?  I can't imagine a good reason for
> including them by default.  The Solaris 2.5.1 machine I do my builds on
> happens to have a libz.so in /usr/local/lib, and everything compiled and
> ran fine on that machine but when I distributed the binaries to all my
> solaris machines last night they couldn't find libz.so.  Those /usr/local
> flags have been in there for a while (at least in version 2.9p2), but I
> just started using the new --with-zlib=PATH option to point configure to a
> directory where I have only a libz.a which didn't work because the
> -L/usr/local/lib took precedence, and I used to pre-set the *FLAGS
> environment variables to find libz so I didn't notice before.
>

Does this patch help?

---------------------< cut here >------------------------
--- configure.in.old	Tue Oct 23 22:36:55 2001
+++ configure.in	Wed Oct 24 20:15:32 2001
@@ -324,21 +324,21 @@
 			if test "x$withval" != "xyes"; then
 				if test -d "$withval/lib"; then
 					if test -n "${need_dash_r}"; then
-						LDFLAGS="${LDFLAGS} -L$withval/lib -R$withval/lib"
+						LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}"
 					else
-						LDFLAGS="${LDFLAGS} -L$withval/lib"
+						LDFLAGS="-L${withval}/lib ${LDFLAGS}"
 					fi
 				else
 					if test -n "${need_dash_r}"; then
-						LDFLAGS="${LDFLAGS} -L$withval -R$withval"
+						LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}"
 					else
-						LDFLAGS="${LDFLAGS} -L$withval"
+						LDFLAGS="-L${withval} ${LDFLAGS}"
 					fi
 				fi
 				if test -d "$withval/include"; then
-					CPPFLAGS="${CPPFLAGS} -I$withval/include"
+					CPPFLAGS="-I${withval}/include ${CPPFLAGS}"
 				else
-					CPPFLAGS="${CPPFLAGS} -I$withval"
+					CPPFLAGS="-I${withval} ${CPPFLAGS}"
 				fi
 			fi

@@ -377,21 +377,21 @@
 	[
 		if test -d "$withval/lib"; then
 			if test -n "${need_dash_r}"; then
-				LDFLAGS="${LDFLAGS} -L$withval/lib -R$withval/lib"
+				LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}"
 			else
-				LDFLAGS="${LDFLAGS} -L$withval/lib"
+				LDFLAGS="-L${withval}/lib ${LDFLAGS}"
 			fi
 		else
 			if test -n "${need_dash_r}"; then
-				LDFLAGS="${LDFLAGS} -L$withval -R$withval"
+				LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}"
 			else
-				LDFLAGS="${LDFLAGS} -L$withval"
+				LDFLAGS="-L${withval} ${LDFLAGS}"
 			fi
 		fi
 		if test -d "$withval/include"; then
-			CPPFLAGS="${CPPFLAGS} -I$withval/include"
+			CPPFLAGS="-I${withval}/include ${CPPFLAGS}"
 		else
-			CPPFLAGS="${CPPFLAGS} -I$withval"
+			CPPFLAGS="-I${withval} ${CPPFLAGS}"
 		fi
 	]
 )
@@ -524,23 +524,22 @@
 			if test -n "${withval}" -a "${withval}" != "yes"; then
 				if test -d "${withval}/lib"; then
 					if test -n "${need_dash_r}"; then
-						LDFLAGS="$LDFLAGS -L${withval}/lib -R${withval}/lib"
+						LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}"
 					else
-						LDFLAGS="$LDFLAGS -L${withval}/lib"
+						LDFLAGS="-L${withval}/lib ${LDFLAGS}"
 					fi
 				else
 					if test -n "${need_dash_r}"; then
-						LDFLAGS="$LDFLAGS -L${withval} -R${withval}"
+						LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}"
 					else
-						LDFLAGS="$LDFLAGS -L${withval}"
+						LDFLAGS="-L${withval} ${LDFLAGS}"
 					fi
 				fi
 				if test -d "${withval}/include"; then
-					CPPFLAGS="$CPPFLAGS -I${withval}/include"
+					CPPFLAGS="-I${withval}/include ${CPPFLAGS}"
 				else
-					CPPFLAGS="$CPPFLAGS -I${withval}"
+					CPPFLAGS="-I${withval} ${CPPFLAGS}"
 				fi
-					TCPW_MSG="yes"
 			fi
 			LIBS="-lwrap $LIBS"
 			AC_MSG_CHECKING(for libwrap)
---------------------< end cut >------------------------

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From a_ghsek at yahoo.co.in  Thu Oct 25 15:35:05 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Thu, 25 Oct 2001 06:35:05 +0100 (BST)
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011024185714.B7393@folly>
Message-ID: <20011025053505.15993.qmail@web8004.mail.in.yahoo.com>

 --- Markus Friedl <markus at openbsd.org> wrote: > 
> please provide some debugging output. 

Hi,
  Sorry for the inconvenience. It was not in my
opinion to repeat the same messages. But, I wanted a
quicker reply from someone who notices the message.
OK. I will see to it that I don't repeat any more.
  Fine. Iam attaching herewith the debug output of
both sshd server running in Redhat 7.0 Linux system
and sftp client program running in a LynxOS system.

Any help, please...
Hari.

linux# sshd -d
debug1: Seeding random number generator
debug1: sshd version OpenSSH_2.9p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
socket: Invalid argument
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging
mode.
Connection from 192.168.0.23 port 1028
debug1: Client protocol version 2.0; client software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.9p2
debug1: Rhosts Authentication disabled, originating
port not trusted.
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 122/256
debug1: bits set: 1032/2049
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1029/2049
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
debug1: userauth-request for user hari service
ssh-connection method none
debug1: attempt 0 failures 0
debug1: Starting up PAM with username "hari"
debug1: PAM setting rhost to "ists_ibm23"
Failed none for hari from 192.168.0.23 port 1028 ssh2
debug1: userauth-request for user hari service
ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 501/501 (e=0)
debug1: restore_uid
Failed publickey for hari from 192.168.0.23 port 1028
ssh2
debug1: userauth-request for user hari service
ssh-connection method password
debug1: attempt 2 failures 2
debug1: PAM Password authentication accepted for user
"hari"
Accepted password for hari from 192.168.0.23 port 1028
ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan
0 win 65536 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0
request subsystem reply 1subsystem request for sftp
debug1: subsystem: exec()
/usr/local/libexec/sftp-server
debug1: PAM establishing creds
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 1482
debug1: session_exit_message: session 0 channel 0 pid
1482
debug1: session_exit_message: release channel 0
debug1: session_free: session 0 pid 1482
debug1: channel 0: read<=0 rfd 7 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: channel 0: send close
debug1: channel 0: rcvd close
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following
connections are open:
  #0 server-session (t4 r0 i8/0 o128/0 fd 7/7)

Connection closed by remote host.
Closing connection to 192.168.0.23
linux#


lynxos$ sftp -v hari at hari
Connecting to hari...
debug1: SSH args "ssh -l hari -v hari -s
-oForwardX11=no -oForwardAgent=no -oProtocol=2 sftp"
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL
0x0090600f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 7 geteuid 7 anon 1
debug1: Connecting to hari [192.168.0.126] port 22.
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/hari/.ssh/id_rsa type -1
debug1: identity file /home/hari/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
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: 132/256
debug1: bits set: 1029/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hari' is known and matches the RSA host
key.
debug1: Found key in /home/hari/.ssh/known_hosts2:5
debug1: bits set: 1032/2049
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 privkey: /home/hari/.ssh/id_rsa
debug1: try pubkey: /home/hari/.ssh/id_dsa
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password
hari at hari's password:
debug1: ssh-userauth2 successful: method password
debug1: fd 4 setting O_NONBLOCK
debug1: fd 5 IS O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Sending subsystem: sftp
debug1: channel 0: open confirm rwindow 0 rmax 16384
sftp>
debug1: channel 0: read<=0 rfd 4 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
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)

debug1: channel_free: channel 0: dettaching channel
user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes
in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0,
stderr 0.0
debug1: Exit status 0
lynxos$



Original Message:

Hi,
  I work on openssh-2.9p2 installed on LynxOS i386
system. sshd, ssh, scp and sftp-server all work fine.
The problem is sftp client, in interactive mode, exits
after authentication printing the sftp prompt. sftp
client works fine in non-interactive mode.
i.e.,
lynxos>sftp hari at linuxsystem:test
works fine
But,
lynxos>sftp hari at linuxsystem
...
sftp>
lynxos>
Any help, as to why sftp exits in interactive mode.
-Hari.


___________________________________________________________________
*NEW*   Yahoo! Messenger for SMS. Now on your ORANGE phone    *NEW*
        Visit http://in.mobile.yahoo.com/smsmgr_signin.html


From markus at openbsd.org  Thu Oct 25 20:10:56 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 25 Oct 2001 12:10:56 +0200
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011025053505.15993.qmail@web8004.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Thu, Oct 25, 2001 at 06:35:05AM +0100
References: <20011024185714.B7393@folly> <20011025053505.15993.qmail@web8004.mail.in.yahoo.com>
Message-ID: <20011025121055.B27365@folly>


what does
	ssh -2 host /path/to/sftp-server
say?


From a_ghsek at yahoo.co.in  Thu Oct 25 20:31:18 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Thu, 25 Oct 2001 11:31:18 +0100 (BST)
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011025121055.B27365@folly>
Message-ID: <20011025103118.25026.qmail@web8005.mail.in.yahoo.com>

 --- Markus Friedl <markus at openbsd.org> wrote: > 
> what does
> 	ssh -2 host /path/to/sftp-server
> say? 

  Yes. I've tried this before, but the client just
hangs, and after a series of "enter" keys, prints 
"bad message"
and exits.

 Iam attaching the debug messages for this too!



lynxos$ ssh -2 -v hari at linux
/usr/local/libexec/sftp-server
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL
0x0090600f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 7 geteuid 7 anon 1
debug1: Connecting to hari [192.168.0.126] port 22.
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/hari/.ssh/id_rsa type -1
debug1: identity file /home/hari/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
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: 126/256
debug1: bits set: 1037/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hari' is known and matches the RSA host
key.
debug1: Found key in /home/hari/.ssh/known_hosts2:5
debug1: bits set: 1054/2049
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 privkey: /home/hari/.ssh/id_rsa
debug1: try pubkey: /home/hari/.ssh/id_dsa
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password
hari at hari's password:
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Sending command:
/usr/local/libexec/sftp-server
debug1: channel 0: open confirm rwindow 0 rmax 16384

<just hangs>
<after a series of "enter" keys>

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
debug1: channel 0: input open -> closed
debug1: channel 0: close_read
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
bad message
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)

debug1: channel_free: channel 0: dettaching channel
user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes
in 238.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0,
stderr 0.0
debug1: Exit status 11
lynxos$



___________________________________________________________________
*NEW*   Yahoo! Messenger for SMS. Now on your ORANGE phone    *NEW*
        Visit http://in.mobile.yahoo.com/smsmgr_signin.html


From markus at openbsd.org  Thu Oct 25 20:38:08 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 25 Oct 2001 12:38:08 +0200
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011025103118.25026.qmail@web8005.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Thu, Oct 25, 2001 at 11:31:18AM +0100
References: <20011025121055.B27365@folly> <20011025103118.25026.qmail@web8005.mail.in.yahoo.com>
Message-ID: <20011025123808.A10503@faui02.informatik.uni-erlangen.de>

On Thu, Oct 25, 2001 at 11:31:18AM +0100, hari sekar wrote:
>  --- Markus Friedl <markus at openbsd.org> wrote: > 
> > what does
> > 	ssh -2 host /path/to/sftp-server
> > say? 
> 
>   Yes. I've tried this before, but the client just
> hangs, and after a series of "enter" keys, prints 
> "bad message"
> and exits.

ok. that's ok.

now try
	sftp -s /path/to/sftp-server host

-m


From ed at UDel.Edu  Thu Oct 25 23:20:37 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 09:20:37 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110250039.f9P0dJuI276076@jurassic.eng.sun.com>
Message-ID: <Pine.SOL.4.30.0110250916030.12864-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Darren Moffat wrote:

> Date: Wed, 24 Oct 2001 17:39:19 -0700 (PDT)
> From: Darren Moffat <Darren.Moffat at eng.sun.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
>
> >Okay, this appears to be a problem with pam_unix.so - the code in
> >pam_sm_open_session is written with the assumption that the tty name is of
> >the form "/dev/" + something else on the end.  I'm not sure why the
>
> pam_sm_open_session in pam_unix on Solaris now does this:
>
>         /* report error if ttyn or rhost are not set */
>         if ((ttyn == NULL) || (rhost == NULL))
>                 return (PAM_SESSION_ERR);
>
>         /* sanity check on size of tty line */
>         if (strlen(ttyn) < sizeof("/dev/"))
>                 return (PAM_SESSION_ERR);
>
> later on it uses everything after the /dev/ as the short name tty to
> write to lastlog.
>
> This was part of the fix for 4250887. The fix will appear in patch
> 111659-03 (sparc) and 111660-03 (intel) when that patch is released.

Hi Darren,

Before the 111659-03 patch comes out, this section of code doesn't have
any of the error checking?  What is the target date for this patch
release?

Still I think, in this case, calling pam_open_session() for the
non-interactive case is "wrong" and we should avoid it (especially if we
have to send a bogus tty name just to get it to keep from crashing).  The
strange part about the crashing is that PAM_TTY is not set... so I'm not
exactly sure way it crashes because pam_sm_open_session() will return an
error if PAM_TTY is not set.  I'll investigate further...

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 ed at UDel.Edu  Thu Oct 25 23:38:50 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 09:38:50 -0400 (EDT)
Subject: Another round of testing calls.
In-Reply-To: <200110250044.f9P0iOuI276600@jurassic.eng.sun.com>
Message-ID: <Pine.SOL.4.30.0110250921200.12864-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Darren Moffat wrote:

> Date: Wed, 24 Oct 2001 17:44:25 -0700 (PDT)
> From: Darren Moffat <Darren.Moffat at eng.sun.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Another round of testing calls.
>
> >How do you enforce PAM limits without opening a session then?
>
> pam_limits should probably be either an pam_acct_mgmt or pam_setid module.

What is pam_setid?  Do you mean pam_setcred?  pam_setcred has always been
a little fuzzy... the pam_setcred from pam_unix.so has changed function
between Sol2.6 and Sol7.  In 2.6, pam_sm_setcred did nothing and
initgroups() was called by login or other apps directly.  In Sol7,
pam_sm_setcred actually called initgroups() and the apps were made
to call pam_setcred with expectations of it calling initgroups().

> pam_limits doesn't exist on Solaris.  Solaris does how ever have pam_projects
> which deals with setting resource control information for project(4).

Caveat: You won't see that man page unless you have installed something
like Sol8 1/01 or newer.  If you have FCS + all Recommended Patches, you
won't see it (even though the features exist).

> It isn't really clear from the man pages what the true purpose of
> pam_open_session is but it can be infered from the Solaris man pages that
> it is really about dealing with files like lastlog/utmpx/wtmpx.

Yeah, that's been my feeling too.  Also, I've seen it described somewhere
that pam_session can be used to do site-specific things that your custom
modules implement, like custom logging, etc.  The stock pam_unix.so is
pretty simple and you're suppoesed to stack a home-brew module with it to
do something "meaningful".

	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  Thu Oct 25 23:47:40 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 09:47:40 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.LNX.4.33.0110251043580.6250-100000@mothra.mindrot.org>
Message-ID: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>

What is the reasoning behind this?  Do we want to see a lastlog entry for
"ssh" whenever a user runs remote command?  Do other OSes have
pam_open_session that does more meaningful things than Solaris 8?
Well...  I guess the more I think about it, it's probably better to go
ahead an call pam_open_session even for the non-interactive case since
someone might want to implement a PAM module at their site that logs every
ssh connection... and if we don't call pam_open_session, then they don't
even have that capability if they wanted it.

I agree.  Your patch below will avoid the SEGV on Sol8 regardless of
whether or not the user has installed the patch to fix pam_unix.so.

Also, I'll check with our platinum-beta contact at Sun to see if it's okay
to test openssh on Sol9 Beta and report problems to this list, etc.

	Ed

On Thu, 25 Oct 2001, Damien Miller wrote:

> Date: Thu, 25 Oct 2001 10:45:34 +1000 (EST)
> From: Damien Miller <djm at mindrot.org>
> To: Darren Moffat <Darren.Moffat at eng.sun.com>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
> On Wed, 24 Oct 2001, Darren Moffat wrote:
>
> >
> > >Okay, this appears to be a problem with pam_unix.so - the code in
> > >pam_sm_open_session is written with the assumption that the tty name is of
> > >the form "/dev/" + something else on the end.  I'm not sure why the
> >
> > pam_sm_open_session in pam_unix on Solaris now does this:
> >
> >         /* report error if ttyn or rhost are not set */
> >         if ((ttyn == NULL) || (rhost == NULL))
> >                 return (PAM_SESSION_ERR);
> >
> >         /* sanity check on size of tty line */
> >         if (strlen(ttyn) < sizeof("/dev/"))
> >                 return (PAM_SESSION_ERR);
> >
> > later on it uses everything after the /dev/ as the short name tty to
> > write to lastlog.
> >
> > This was part of the fix for 4250887. The fix will appear in patch
> > 111659-03 (sparc) and 111660-03 (intel) when that patch is released.
>
> IMO until then we should enable the kludge, but change it as follows.
> Kevin, can you check whether the kludge works with this patch on HP/UX?
> (is the kludge even needed there?)
>
> Index: auth-pam.c
> ===================================================================
> RCS file: /var/cvs/openssh/auth-pam.c,v
> retrieving revision 1.37
> diff -u -r1.37 auth-pam.c
> --- auth-pam.c	2001/04/23 18:38:37	1.37
> +++ auth-pam.c	2001/10/25 00:43:55
> @@ -374,7 +374,7 @@
>  	 * not even need one (for tty-less connections)
>  	 * Kludge: Set a fake PAM_TTY
>  	 */
> -	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
> +	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
>  	if (pam_retval != PAM_SUCCESS)
>  		fatal("PAM set tty failed[%d]: %.200s",
>  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
>
> -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)
>

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  Thu Oct 25 23:54:10 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 25 Oct 2001 15:54:10 +0200
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 09:47:40AM -0400
References: <Pine.LNX.4.33.0110251043580.6250-100000@mothra.mindrot.org> <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>
Message-ID: <20011025155410.A6983@faui02.informatik.uni-erlangen.de>

On Thu, Oct 25, 2001 at 09:47:40AM -0400, Ed Phillips wrote:
> Do we want to see a lastlog entry for
> "ssh" whenever a user runs remote command?

no.


From mouring at etoh.eviladmin.org  Fri Oct 26 00:04:47 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 25 Oct 2001 09:04:47 -0500 (CDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>
Message-ID: <Pine.BSO.4.33.0110250900580.22315-100000@etoh.eviladmin.org>


If the patch below gives us a reasonable solution.  Then I guess that is
as much as we can hope for in 3.0p1.

Question still has to be asked is how does this patch handle password
changes on non-interactive.  Does PAM outright fail causing the ssh
connection to quietly fail?  Does PAM whine loud enough to echo through
the failing ssh connection?  Or does it blow off the required password
change and execute the command?

Options #1 and #2 may be acceptable for 3.0p1 release.  Option #3 would be
bad news since some may consider it a security flaw (mainly if you do
passwd -f account  under solaris).

In the end Option #2 would be best.

- Ben

On Thu, 25 Oct 2001, Ed Phillips wrote:

> What is the reasoning behind this?  Do we want to see a lastlog entry for
> "ssh" whenever a user runs remote command?  Do other OSes have
> pam_open_session that does more meaningful things than Solaris 8?
> Well...  I guess the more I think about it, it's probably better to go
> ahead an call pam_open_session even for the non-interactive case since
> someone might want to implement a PAM module at their site that logs every
> ssh connection... and if we don't call pam_open_session, then they don't
> even have that capability if they wanted it.
>
> I agree.  Your patch below will avoid the SEGV on Sol8 regardless of
> whether or not the user has installed the patch to fix pam_unix.so.
>
> Also, I'll check with our platinum-beta contact at Sun to see if it's okay
> to test openssh on Sol9 Beta and report problems to this list, etc.
>
> 	Ed
>
> On Thu, 25 Oct 2001, Damien Miller wrote:
>
> > Date: Thu, 25 Oct 2001 10:45:34 +1000 (EST)
> > From: Damien Miller <djm at mindrot.org>
> > To: Darren Moffat <Darren.Moffat at eng.sun.com>
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> >
> > On Wed, 24 Oct 2001, Darren Moffat wrote:
> >
> > >
> > > >Okay, this appears to be a problem with pam_unix.so - the code in
> > > >pam_sm_open_session is written with the assumption that the tty name is of
> > > >the form "/dev/" + something else on the end.  I'm not sure why the
> > >
> > > pam_sm_open_session in pam_unix on Solaris now does this:
> > >
> > >         /* report error if ttyn or rhost are not set */
> > >         if ((ttyn == NULL) || (rhost == NULL))
> > >                 return (PAM_SESSION_ERR);
> > >
> > >         /* sanity check on size of tty line */
> > >         if (strlen(ttyn) < sizeof("/dev/"))
> > >                 return (PAM_SESSION_ERR);
> > >
> > > later on it uses everything after the /dev/ as the short name tty to
> > > write to lastlog.
> > >
> > > This was part of the fix for 4250887. The fix will appear in patch
> > > 111659-03 (sparc) and 111660-03 (intel) when that patch is released.
> >
> > IMO until then we should enable the kludge, but change it as follows.
> > Kevin, can you check whether the kludge works with this patch on HP/UX?
> > (is the kludge even needed there?)
> >
> > Index: auth-pam.c
> > ===================================================================
> > RCS file: /var/cvs/openssh/auth-pam.c,v
> > retrieving revision 1.37
> > diff -u -r1.37 auth-pam.c
> > --- auth-pam.c	2001/04/23 18:38:37	1.37
> > +++ auth-pam.c	2001/10/25 00:43:55
> > @@ -374,7 +374,7 @@
> >  	 * not even need one (for tty-less connections)
> >  	 * Kludge: Set a fake PAM_TTY
> >  	 */
> > -	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
> > +	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
> >  	if (pam_retval != PAM_SUCCESS)
> >  		fatal("PAM set tty failed[%d]: %.200s",
> >  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
> >
> > -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)
> >
>
> 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 Nicolas.Williams at ubsw.com  Fri Oct 26 00:04:27 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 10:04:27 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 09:47:40AM -0400
References: <Pine.LNX.4.33.0110251043580.6250-100000@mothra.mindrot.org> <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>
Message-ID: <20011025100426.Z5739@sm2p1386swk.wdr.com>

It is possible to move UTMP processing to PAM via pam_open_session() /
pam_close_session(). I believe Linux-PAM includes a pam_utmp for this
very purpose.

Ideally UTMP/UTMPX/... processing, lastlog processing, etc... could all
move to PAM, though I don't know all the issues and I suspect that new
PAM items will be needed to be able to effectively move UTMPX processing
to PAM.

Who knows, PAM session handling could be used for a lot of things.

You can always remove PAM_UNIX from the session stack of SSH. You'll
need to use PAM_PERMIT if you have no other suitable module for the
session stack.

Cheers,

Nico


On Thu, Oct 25, 2001 at 09:47:40AM -0400, Ed Phillips wrote:
> What is the reasoning behind this?  Do we want to see a lastlog entry for
> "ssh" whenever a user runs remote command?  Do other OSes have
> pam_open_session that does more meaningful things than Solaris 8?
> Well...  I guess the more I think about it, it's probably better to go
> ahead an call pam_open_session even for the non-interactive case since
> someone might want to implement a PAM module at their site that logs every
> ssh connection... and if we don't call pam_open_session, then they don't
> even have that capability if they wanted it.
> 
> I agree.  Your patch below will avoid the SEGV on Sol8 regardless of
> whether or not the user has installed the patch to fix pam_unix.so.
> 
> Also, I'll check with our platinum-beta contact at Sun to see if it's okay
> to test openssh on Sol9 Beta and report problems to this list, etc.
> 
> 	Ed
> 
> On Thu, 25 Oct 2001, Damien Miller wrote:
> 
> > Date: Thu, 25 Oct 2001 10:45:34 +1000 (EST)
> > From: Damien Miller <djm at mindrot.org>
> > To: Darren Moffat <Darren.Moffat at eng.sun.com>
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> >
> > On Wed, 24 Oct 2001, Darren Moffat wrote:
> >
> > >
> > > >Okay, this appears to be a problem with pam_unix.so - the code in
> > > >pam_sm_open_session is written with the assumption that the tty name is of
> > > >the form "/dev/" + something else on the end.  I'm not sure why the
> > >
> > > pam_sm_open_session in pam_unix on Solaris now does this:
> > >
> > >         /* report error if ttyn or rhost are not set */
> > >         if ((ttyn == NULL) || (rhost == NULL))
> > >                 return (PAM_SESSION_ERR);
> > >
> > >         /* sanity check on size of tty line */
> > >         if (strlen(ttyn) < sizeof("/dev/"))
> > >                 return (PAM_SESSION_ERR);
> > >
> > > later on it uses everything after the /dev/ as the short name tty to
> > > write to lastlog.
> > >
> > > This was part of the fix for 4250887. The fix will appear in patch
> > > 111659-03 (sparc) and 111660-03 (intel) when that patch is released.
> >
> > IMO until then we should enable the kludge, but change it as follows.
> > Kevin, can you check whether the kludge works with this patch on HP/UX?
> > (is the kludge even needed there?)
> >
> > Index: auth-pam.c
> > ===================================================================
> > RCS file: /var/cvs/openssh/auth-pam.c,v
> > retrieving revision 1.37
> > diff -u -r1.37 auth-pam.c
> > --- auth-pam.c	2001/04/23 18:38:37	1.37
> > +++ auth-pam.c	2001/10/25 00:43:55
> > @@ -374,7 +374,7 @@
> >  	 * not even need one (for tty-less connections)
> >  	 * Kludge: Set a fake PAM_TTY
> >  	 */
> > -	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
> > +	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
> >  	if (pam_retval != PAM_SUCCESS)
> >  		fatal("PAM set tty failed[%d]: %.200s",
> >  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
> >
> > -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)
> >
> 
> 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
--

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 ed at UDel.Edu  Fri Oct 26 00:15:45 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 10:15:45 -0400 (EDT)
Subject: Default forwarding features; default cipher
In-Reply-To: <20011024162611.B2657@zax.half.pint-stowp.cx>
Message-ID: <Pine.SOL.4.30.0110251012570.12864-100000@mahler.udel.edu>

On Wed, 24 Oct 2001, Jim Knoble wrote:

> Date: Wed, 24 Oct 2001 16:26:11 -0400
> From: Jim Knoble <jmknoble at pobox.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Default forwarding features; default cipher
>
> Circa 2001-Oct-24 14:49:47 -0400 dixit Ed Phillips:
>
> : I guess the only gotcha is that you have to enable X11 forwarding in
> : sshd_config.  It appears that by default "ssh -X" is silently
> : ignored on the server side, and "ssh -A" works fine... and normally
> : you get no forwarding from the client without adding the "-A" or
> : "-X".  Is this correct?
>
> Yes, that's correct.  Both the server and the client must explicitly
> allow X11 forwarding; the default configuration allows it in neither
> place.

Okay.

> : By the way, I notice in the stock ssh_config, it would appear that
> : "blowfish" is the default cipher.  Is this used for speed or because
> : it provides the best security or both?
>
> Are you sure you're reading the default ssh_config file, and that
> you're reading it correctly?  To my recollection, the default
> ssh_config file is "empty" (i.e., contains no non-blank, uncommented

Right... I meant the comments that supposedly list the options and their
defaults - which may be out of date.  I find it useful if it's correct.

> lines).  According to the man page, the default value for the 'Cipher'
> keyword is '3des'.  The 'Cipher' (singular) keyword, however, is only
> for SSH protocol v1.  For SSH protocol v2, the 'Ciphers' (plural)
> keyword applies; the default configuration asks for 'aes128-cbc' first.

Okay... what is aes128?

> That said, i don't know of any reason for you not to configure "Cipher
> blowfish" and "Ciphers blowfish-cbc,..." as defaults.  Blowfish is a
> fast cipher, and it's been around for quite a while....

I'd like to use the one that is accepted as being fast yet strong... ;-)

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 mouring at etoh.eviladmin.org  Fri Oct 26 00:21:25 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 25 Oct 2001 09:21:25 -0500 (CDT)
Subject: disable features
In-Reply-To: <20011024103051.A15160@folly>
Message-ID: <Pine.BSO.4.33.0110250915370.22315-100000@etoh.eviladmin.org>


On Wed, 24 Oct 2001, Markus Friedl wrote:

> this (uncomplete) patch makes various features compile time
> options and saves up to 24K in the resulting
> ssh/sshd binaries. i don't know whether this
> should be added to the CVS since it makes
> the code less readable.
>
> perhaps WITH_COMPRESSION should be added, since
> it removes the dependency on libz
>
WTIH_COMPRESSION would be nice.  I could agree with that.

Ability to compile without v1 compatiblity would also be nice down the
road.

However, neither feature are a 'must' on my list.

- Ben



From dwd at bell-labs.com  Fri Oct 26 00:26:24 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Thu, 25 Oct 2001 09:26:24 -0500
Subject: configure changes
In-Reply-To: <Pine.UW2.4.40.9.0110242044100.7705-100000@uw711.int.multitalents.net>; from tim@multitalents.net on Wed, Oct 24, 2001 at 08:46:44PM -0700
References: <20011024110558.A27428@lucent.com> <Pine.UW2.4.40.9.0110242044100.7705-100000@uw711.int.multitalents.net>
Message-ID: <20011025092624.A21910@lucent.com>

Yes, that patch works as an alternative.

- Dave Dykstra

On Wed, Oct 24, 2001 at 08:46:44PM -0700, Tim Rice wrote:
> On Wed, 24 Oct 2001, Dave Dykstra wrote:
> 
> >
> > Aack!  Why are all those -I/usr/local/include in CPPFLAGS and
> > -L/usr/local/lib in LDFLAGS for many different machine types in
> > configure.in?  The contents of those directories are different depending on
> > individual system installations, right?  I can't imagine a good reason for
> > including them by default.  The Solaris 2.5.1 machine I do my builds on
> > happens to have a libz.so in /usr/local/lib, and everything compiled and
> > ran fine on that machine but when I distributed the binaries to all my
> > solaris machines last night they couldn't find libz.so.  Those /usr/local
> > flags have been in there for a while (at least in version 2.9p2), but I
> > just started using the new --with-zlib=PATH option to point configure to a
> > directory where I have only a libz.a which didn't work because the
> > -L/usr/local/lib took precedence, and I used to pre-set the *FLAGS
> > environment variables to find libz so I didn't notice before.
> >
> 
> Does this patch help?
> 
> ---------------------< cut here >------------------------
> --- configure.in.old	Tue Oct 23 22:36:55 2001
> +++ configure.in	Wed Oct 24 20:15:32 2001
> @@ -324,21 +324,21 @@
>  			if test "x$withval" != "xyes"; then
>  				if test -d "$withval/lib"; then
>  					if test -n "${need_dash_r}"; then
> -						LDFLAGS="${LDFLAGS} -L$withval/lib -R$withval/lib"
> +						LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}"
>  					else
> -						LDFLAGS="${LDFLAGS} -L$withval/lib"
> +						LDFLAGS="-L${withval}/lib ${LDFLAGS}"
>  					fi
>  				else
>  					if test -n "${need_dash_r}"; then
> -						LDFLAGS="${LDFLAGS} -L$withval -R$withval"
> +						LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}"
>  					else
> -						LDFLAGS="${LDFLAGS} -L$withval"
> +						LDFLAGS="-L${withval} ${LDFLAGS}"
>  					fi
>  				fi
>  				if test -d "$withval/include"; then
> -					CPPFLAGS="${CPPFLAGS} -I$withval/include"
> +					CPPFLAGS="-I${withval}/include ${CPPFLAGS}"
>  				else
> -					CPPFLAGS="${CPPFLAGS} -I$withval"
> +					CPPFLAGS="-I${withval} ${CPPFLAGS}"
>  				fi
>  			fi
> 
> @@ -377,21 +377,21 @@
>  	[
>  		if test -d "$withval/lib"; then
>  			if test -n "${need_dash_r}"; then
> -				LDFLAGS="${LDFLAGS} -L$withval/lib -R$withval/lib"
> +				LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}"
>  			else
> -				LDFLAGS="${LDFLAGS} -L$withval/lib"
> +				LDFLAGS="-L${withval}/lib ${LDFLAGS}"
>  			fi
>  		else
>  			if test -n "${need_dash_r}"; then
> -				LDFLAGS="${LDFLAGS} -L$withval -R$withval"
> +				LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}"
>  			else
> -				LDFLAGS="${LDFLAGS} -L$withval"
> +				LDFLAGS="-L${withval} ${LDFLAGS}"
>  			fi
>  		fi
>  		if test -d "$withval/include"; then
> -			CPPFLAGS="${CPPFLAGS} -I$withval/include"
> +			CPPFLAGS="-I${withval}/include ${CPPFLAGS}"
>  		else
> -			CPPFLAGS="${CPPFLAGS} -I$withval"
> +			CPPFLAGS="-I${withval} ${CPPFLAGS}"
>  		fi
>  	]
>  )
> @@ -524,23 +524,22 @@
>  			if test -n "${withval}" -a "${withval}" != "yes"; then
>  				if test -d "${withval}/lib"; then
>  					if test -n "${need_dash_r}"; then
> -						LDFLAGS="$LDFLAGS -L${withval}/lib -R${withval}/lib"
> +						LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}"
>  					else
> -						LDFLAGS="$LDFLAGS -L${withval}/lib"
> +						LDFLAGS="-L${withval}/lib ${LDFLAGS}"
>  					fi
>  				else
>  					if test -n "${need_dash_r}"; then
> -						LDFLAGS="$LDFLAGS -L${withval} -R${withval}"
> +						LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}"
>  					else
> -						LDFLAGS="$LDFLAGS -L${withval}"
> +						LDFLAGS="-L${withval} ${LDFLAGS}"
>  					fi
>  				fi
>  				if test -d "${withval}/include"; then
> -					CPPFLAGS="$CPPFLAGS -I${withval}/include"
> +					CPPFLAGS="-I${withval}/include ${CPPFLAGS}"
>  				else
> -					CPPFLAGS="$CPPFLAGS -I${withval}"
> +					CPPFLAGS="-I${withval} ${CPPFLAGS}"
>  				fi
> -					TCPW_MSG="yes"
>  			fi
>  			LIBS="-lwrap $LIBS"
>  			AC_MSG_CHECKING(for libwrap)
> ---------------------< end cut >------------------------
> 
> -- 
> Tim Rice				Multitalents	(707) 887-1469
> tim at multitalents.net
> 


From ed at UDel.Edu  Fri Oct 26 00:31:09 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 10:31:09 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <20011025155410.A6983@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.SOL.4.30.0110251030320.12864-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Markus Friedl wrote:

> Date: Thu, 25 Oct 2001 15:54:10 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Damien Miller <djm at mindrot.org>,
>      Darren Moffat <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
> On Thu, Oct 25, 2001 at 09:47:40AM -0400, Ed Phillips wrote:
> > Do we want to see a lastlog entry for
> > "ssh" whenever a user runs remote command?
>
> no.

Well, that's what happens when you call pam_open_session with TTY set to
"NODEVssh"... ;-)

	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 jmknoble at pobox.com  Fri Oct 26 01:37:57 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 25 Oct 2001 11:37:57 -0400
Subject: Default forwarding features; default cipher
In-Reply-To: <Pine.SOL.4.30.0110251012570.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 10:15:45AM -0400
References: <20011024162611.B2657@zax.half.pint-stowp.cx> <Pine.SOL.4.30.0110251012570.12864-100000@mahler.udel.edu>
Message-ID: <20011025113757.B3438@zax.half.pint-stowp.cx>

Circa 2001-Oct-25 10:15:45 -0400 dixit Ed Phillips:

: On Wed, 24 Oct 2001, Jim Knoble wrote:
: > Are you sure you're reading the default ssh_config file, and that
: > you're reading it correctly?  To my recollection, the default
: > ssh_config file is "empty" (i.e., contains no non-blank, uncommented
: 
: Right... I meant the comments that supposedly list the options and their
: defaults - which may be out of date.  I find it useful if it's correct.

I suspect that interpretation isn't quite spot on:

  $ pwd
  /home/jmknoble/openssh-2.9.9p2
  $ grep -i '^#[ ]*cipher\>' /etc/ssh/ssh_config
  #   Cipher blowfish
  $ fgrep ssh_cipher_default *.c
  sshconnect1.c:  int ssh_cipher_default = SSH_CIPHER_3DES;
                                          ^^^^^^^^^^^^^^^^^^
  sshconnect1.c:          if (cipher_mask_ssh1(1) & supported_ciphers & (1 << ssh_cipher_default))
  sshconnect1.c:                  options.cipher = ssh_cipher_default;
  sshconnect1.c:              cipher_name(ssh_cipher_default));
  sshconnect1.c:          options.cipher = ssh_cipher_default;
  $ 

I'd accept the opinion of the manual page over the comments in the
default config file.

: > [...] For SSH protocol v2, the 'Ciphers' (plural) keyword applies;
: > the default configuration asks for 'aes128-cbc' first.
: 
: Okay... what is aes128?

http://slashdot.org/article.pl?sid=00/10/02/1627222&mode=thread
http://csrc.nist.gov/encryption/aes/

: > That said, i don't know of any reason for you not to configure "Cipher
: > blowfish" and "Ciphers blowfish-cbc,..." as defaults.  Blowfish is a
: > fast cipher, and it's been around for quite a while....
: 
: I'd like to use the one that is accepted as being fast yet strong... ;-)

Feel free:

http://www.counterpane.com/hotlist.html
http://www.eskimo.com/~weidai/algorithms.html
http://www.cs.berkeley.edu/~daw/crypto.html
http://www.cryptography.org/

-- 
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/20011025/9d7a9ac0/attachment.bin 

From Darren.Moffat at eng.sun.com  Fri Oct 26 02:59:50 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 09:59:50 -0700 (PDT)
Subject: Another round of testing calls.
Message-ID: <200110251659.f9PGxouI374734@jurassic.eng.sun.com>

>What is pam_setid?  Do you mean pam_setcred?  pam_setcred has always been

yes I meant setcred.

>a little fuzzy... the pam_setcred from pam_unix.so has changed function
>between Sol2.6 and Sol7.  In 2.6, pam_sm_setcred did nothing and
>initgroups() was called by login or other apps directly.  In Sol7,
>pam_sm_setcred actually called initgroups() and the apps were made
>to call pam_setcred with expectations of it calling initgroups().

That is not correct.  The code for pam_sm_setcred in pam_unix hasn't
actually changed between 2.6 and the current builds of the next release
of Solaris.   Well that isn't quite true there were a few minor changes
but that was fixing a broken cast to remove a compiler warning and
chaning the wording of one of the messages that prints it out.
I've just checked the code (and BTW this is one of my areas of Solaris
responsibility).

The last time that initgroups didn't happen in the application but
happened in the module was 2.5.1 - when PAM was in prerelease state and
not configurable or public.

Having said all of that what you were suggesting had happened is actually
the correct way to go, initgroups probably should be called from the 
pam_unix pam_setcred and not the application since your supplementary groups
are your unix creds.  However we don't currently do that - if Solaris ever
does get to that stage then OpenSSH should be updated to not do the
initgroups calls if being built to run on that release of Solaris.

--
Darren J Moffat



From Darren.Moffat at eng.sun.com  Fri Oct 26 03:06:13 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 10:06:13 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
Message-ID: <200110251706.f9PH6CuI376018@jurassic.eng.sun.com>

>Before the 111659-03 patch comes out, this section of code doesn't have
>any of the error checking? 

Correct, the code neither checks to see if PAM_TTY is set nor does it
check it is long enough.

> What is the target date for this patch release?

I don't know, contact Sun Enterprise Services.  It depends when the
customer who requested the patch verifies that it fixes there problem,
and when the patch completes all the regression testing cycles.

--
Darren J Moffat



From ed at UDel.Edu  Fri Oct 26 03:37:08 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 13:37:08 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.BSO.4.33.0110250900580.22315-100000@etoh.eviladmin.org>
Message-ID: <Pine.SOL.4.30.0110251031490.12864-100000@mahler.udel.edu>

On Thu, 25 Oct 2001 mouring at etoh.eviladmin.org wrote:

> Date: Thu, 25 Oct 2001 09:04:47 -0500 (CDT)
> From: mouring at etoh.eviladmin.org
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Damien Miller <djm at mindrot.org>,
>      Darren Moffat <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
>
> If the patch below gives us a reasonable solution.  Then I guess that is
> as much as we can hope for in 3.0p1.
>
> Question still has to be asked is how does this patch handle password
> changes on non-interactive.  Does PAM outright fail causing the ssh
> connection to quietly fail?  Does PAM whine loud enough to echo through
> the failing ssh connection?  Or does it blow off the required password
> change and execute the command?
>
> Options #1 and #2 may be acceptable for 3.0p1 release.  Option #3 would be
> bad news since some may consider it a security flaw (mainly if you do
> passwd -f account  under solaris).
>
> In the end Option #2 would be best.

Unfortunately, it looks like it's worse that all 3.  It appears that the
crash on Sol8 is not actually due to the PAM_TTY_KLUDGE being set
improperly, but due to a bug where pam_unix.so fetches PAM_TTY and
neglects to check if it's NULL or not.  So, if we set PAM_TTY and call
pam_open_session(), then we have to put in some dummy tty name that is
meaningless and gets logged in the lastlog, but if we don't set PAM_TTY,
we get a core dump on Sol8.

This brings us right back to the question at hand - should we call
pam_open_session() for non-interactive mode?  I've previously said, "Yeah,
go ahead, someone might want to do something useful with
pam_sm_open_session later."  The problem with this is that as long as
Sun's pam_sm_open_session() returns an error if PAM_TTY is not set, then
how can we tell if the error returned by pam_open_session() is just
because we're in non-interactive mode and pam_unix.so on Sol8 returns an
error due to PAM_TTY not being set, or because something failed in another
module besides pam_unix.so that we actually care about and may not want
the user to login as a result.  My gut feeling about this is that errors
from PAM "session" modules should be treated as informational - if a user
can't login, then the "auth" or "account" modules should report the error
back to the caller and the caller should pass it on to the user and close
the connection.  PAM "session" errors should probably be ignored.
Remember, the current Sol8 "pam_unix.so" session module only makes lastlog
entries.  So we don't have a very good example to infer "intentions" from
regarding the session modules.

So, one solution, just so we can get past this and make things "work", is
to include and encourage PAM_TTY_KLUDGE fix (with "NODEVssh"), but also,
ignore any error messages returned by pam_open_session().  Later, when the
fix is available for the pam_unix.so bug in Sol8 (and I'd guess that this
is also a problem in earlier versions and probably even in Sol9), a user
could compile OpenSSH without PAM_TTY_KLUDGE on Solaris, and since we're
ignoring the errors returned by pam_sm_open_session(), it doesn't matter
that pam_unix.so can't create the lastlog entry for the non-existent
PAM_TTY.

Does this make sense?

To proceed and fix the problem where the pam_unix.so code starts prompting
the user for a password in a non-interactive session, I don't know how we
can fix that given the above strategy.  In order to make pam_unix.so "do
the right thing", I'd guess we need to avoid passing PAM_TTY - then it
should figure out there's no tty and return an error at some point.
Darren... is this true - if PAM_TTY is not set and the user needs to
change his password, will pam_sm_acct_mgmt() in pam_unix.so return an
error that sshd can detect and process?

So, a second (and probably better at this point) solution would be to NOT
call pam_open_session() for non-interactive mode (have I sufficiently went
back and forth enough to confuse everybody?).  Maybe there could be a
PAM_OPEN_SESSION_BROKEN flag in config.h, which is defined by default, and
we could document which patch needs to be applied on Solaris in order to
avoid the problem and allow pam_open_session() to be called (with NO
PAM_TTY set).

How does that sound?

Thanks for your patience while I cycle closer to the target... ;-)

	Ed

>
> - Ben
>
> On Thu, 25 Oct 2001, Ed Phillips wrote:
>
> > What is the reasoning behind this?  Do we want to see a lastlog entry for
> > "ssh" whenever a user runs remote command?  Do other OSes have
> > pam_open_session that does more meaningful things than Solaris 8?
> > Well...  I guess the more I think about it, it's probably better to go
> > ahead an call pam_open_session even for the non-interactive case since
> > someone might want to implement a PAM module at their site that logs every
> > ssh connection... and if we don't call pam_open_session, then they don't
> > even have that capability if they wanted it.
> >
> > I agree.  Your patch below will avoid the SEGV on Sol8 regardless of
> > whether or not the user has installed the patch to fix pam_unix.so.
> >
> > Also, I'll check with our platinum-beta contact at Sun to see if it's okay
> > to test openssh on Sol9 Beta and report problems to this list, etc.
> >
> > 	Ed
> >
> > On Thu, 25 Oct 2001, Damien Miller wrote:
> >
> > > Date: Thu, 25 Oct 2001 10:45:34 +1000 (EST)
> > > From: Damien Miller <djm at mindrot.org>
> > > To: Darren Moffat <Darren.Moffat at eng.sun.com>
> > > Cc: openssh-unix-dev at mindrot.org
> > > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> > >
> > > On Wed, 24 Oct 2001, Darren Moffat wrote:
> > >
> > > >
> > > > >Okay, this appears to be a problem with pam_unix.so - the code in
> > > > >pam_sm_open_session is written with the assumption that the tty name is of
> > > > >the form "/dev/" + something else on the end.  I'm not sure why the
> > > >
> > > > pam_sm_open_session in pam_unix on Solaris now does this:
> > > >
> > > >         /* report error if ttyn or rhost are not set */
> > > >         if ((ttyn == NULL) || (rhost == NULL))
> > > >                 return (PAM_SESSION_ERR);
> > > >
> > > >         /* sanity check on size of tty line */
> > > >         if (strlen(ttyn) < sizeof("/dev/"))
> > > >                 return (PAM_SESSION_ERR);
> > > >
> > > > later on it uses everything after the /dev/ as the short name tty to
> > > > write to lastlog.
> > > >
> > > > This was part of the fix for 4250887. The fix will appear in patch
> > > > 111659-03 (sparc) and 111660-03 (intel) when that patch is released.
> > >
> > > IMO until then we should enable the kludge, but change it as follows.
> > > Kevin, can you check whether the kludge works with this patch on HP/UX?
> > > (is the kludge even needed there?)
> > >
> > > Index: auth-pam.c
> > > ===================================================================
> > > RCS file: /var/cvs/openssh/auth-pam.c,v
> > > retrieving revision 1.37
> > > diff -u -r1.37 auth-pam.c
> > > --- auth-pam.c	2001/04/23 18:38:37	1.37
> > > +++ auth-pam.c	2001/10/25 00:43:55
> > > @@ -374,7 +374,7 @@
> > >  	 * not even need one (for tty-less connections)
> > >  	 * Kludge: Set a fake PAM_TTY
> > >  	 */
> > > -	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
> > > +	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
> > >  	if (pam_retval != PAM_SUCCESS)
> > >  		fatal("PAM set tty failed[%d]: %.200s",
> > >  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
> > >
> > > -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)
> > >
> >
> > 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 Darren.Moffat at eng.sun.com  Fri Oct 26 03:51:01 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 10:51:01 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
Message-ID: <200110251751.f9PHp1uI384166@jurassic.eng.sun.com>

>Does this make sense?

All makes sense to me.

Solaris 9 is already fixed, the way we do devlopment in Sun ensures that
we fix the problem in the yet to be released system before we fix it
as a patch other releases.  For some types of fix not only does it need
to be fixed in the future release first but that the fix must sit in the
future release for a couple of weeks to ensure it is the right thing to do.

We have safety checks in place to prevent fixing bugs in older releases
if it hasn't already been fixed in the future release or marked as not 
applicable because some other change made it irrelevant.


>Darren... is this true - if PAM_TTY is not set and the user needs to
>change his password, will pam_sm_acct_mgmt() in pam_unix.so return an
>error that sshd can detect and process?

Nope, and I don't think it should either. The pam modules do not assume
that a tty is present to do the prompting because your converstation
function might actually be a GUI.

It is up to the calling application and its' conversation function to
deal with getting the information from the user.  If pam_acct_mgmt
returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
one (because it has no tty) then it has to make its own choice of what
to do, it can continue and ignore it or it can display a warning or it
can disconnect - it is upto sshd to choose what to do (it could use
SSH_ASKPASS if it is available).


>back and forth enough to confuse everybody?).  Maybe there could be a
>PAM_OPEN_SESSION_BROKEN flag in config.h, which is defined by default, and
>we could document which patch needs to be applied on Solaris in order to
>avoid the problem and allow pam_open_session() to be called (with NO
>PAM_TTY set).

Please do not use that as the option name, instead say something that
says what you are acutally doing - not caling pam_open_session when sshd
doesn't have a tty.  pam_open_session on Solaris is not broken, it is
just that without the patch the pam_sm_open_session in pam_unix assumes
that it is only ever called with a valid PAM_TTY - that was a bug.

--
Darren J Moffat



From pekkas at netcore.fi  Fri Oct 26 04:04:07 2001
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 25 Oct 2001 21:04:07 +0300 (EEST)
Subject: Another round of testing calls. (redhat/openssh.spec)
In-Reply-To: <Pine.LNX.4.33.0110241717230.25486-100000@pcmy.sei.cmu.edu>
Message-ID: <Pine.LNX.4.33.0110252056220.21969-100000@netcore.fi>

On Wed, 24 Oct 2001, James Ralston wrote:
> On Wed, 24 Oct 2001, Pekka Savola wrote:
> > 3) Building appears to rely on the existance of openssl >= 0.9.6
> > (OPENSSL_free function).  Mark the requirement there.
> 
> Don't say:
> 
>     Requires: openssl >= 0.9.6
> 
> Say:
> 
>     Requires: openssl
>     Conflicts: openssl < 0.9.6
> 
> The former means "this package requires openssl, and will work with
> any version of openssl from 0.9.6 on, through the rest of eternity".
> That's not what you mean.

It can be intepreted like that, sure.

I interpret it: "this package requires openssl, and will work with any 
version of openssl from 0.9.6 on until further notice (that is, a new 
version of openssh is released)".

Please note that in addition, openssh keeps track of the dynamic library 
revision automatically.


> The latter means "this package requires openssl, but doesn't work with
> versions of openssl less than 0.9.6".  That's what you mean.

This is slightly better, but I don't see the real point; double the number 
of different dependencies are required, and isn't a common practise.

-- 
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 dwd at bell-labs.com  Fri Oct 26 05:23:57 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Thu, 25 Oct 2001 14:23:57 -0500
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011024223030.A185@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Wed, Oct 24, 2001 at 10:30:30PM +0200
References: <20011024192422.A27605@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu> <20011024223030.A185@serv01.aet.tu-cottbus.de>
Message-ID: <20011025142357.A2299@lucent.com>

On Wed, Oct 24, 2001 at 10:30:30PM +0200, Lutz Jaenicke wrote:
> Subject: Re: Default forwarding features; default cipher
> On Wed, Oct 24, 2001 at 02:49:47PM -0400, Ed Phillips wrote:
> > Okay... that makes sense.  I've been looking at this from the viewpoint of
> > using ssh between "trusted" machines (managed by our group)... in which
> > case, we probably want forwarding of X11 connections and authentication
> > to, at least, be available.  I guess the only gotcha is that you have to
> > enable X11 forwarding in sshd_config.  It appears that by default "ssh -X"
> > is silently ignored on the server side, and "ssh -A" works fine... and
> > normally you get no forwarding from the client without adding the "-A" or
> > "-X".  Is this correct?
> 
> I don't think that X11 forwarding on the server side introduces a problem.
> For the client side it is up to you.

I agree that X11 forwarding on the server is not a problem; the problem is
that a secure client can be put at risk from an insecure server.  If you're
accessing a secure server from an insecure client you've got worse problems
and X11 forwarding won't add any risk to the server.

Why, then, doesn't OpenSSH set X11Forward=yes by default on the server?

- Dave Dykstra


From Nicolas.Williams at ubsw.com  Fri Oct 26 05:25:22 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 15:25:22 -0400
Subject: SIGCHLD race *trivial* patch
Message-ID: <20011025152522.C26615@wdr.com>

Yes, this is a patch against an older version of OpenSSH with other
stuff anyways, BUT, it's so TRIVIAL(*), that you can see how it would
apply to newer versions (which I've not tried).

Here's the gist: server_loop2() has a race condition with respect to
reception of SIGCHLD and checking/setting child_terminated. This patch
does two things: wait_until_can_do_something() adds a 1 second timeout
to select() IF AND ONLY IF (!channel_still_open) AND, server_loop2()
breaks out of its loop when there are no sessions left.

Blocking SIGCHLD before select()ing would not fix the problem, nor would
that be very portable.

So, summary of changes:

 - session.h

   Added prototype for session_still_used() boolean function.

 - session.c

   Added session_still_used() boolean function.

 - serverloop.c

   Added this bit of code to wait_until_can_do_something():

      if (!channel_still_open())
              max_time_milliseconds = 1000;

   before select()ing.

   Added this bit of code to server_loop2():

                if (child_terminated) {
                        while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
                                session_close_by_pid(pid, status);
-                       child_terminated = 0;
+                       if (session_still_used())
+                               child_terminated = 0;
+                    if (child_terminated && !channel_still_open())
+                       break;

   so that child_terminated is not reset after handling SIGCHLD *UNLESS*
   there are no sessions left open.

Also, for server_loop(), perhaps it too should have a check to break
out of its loop if the child is terminated and there are no channels
still open.

(*) I hope :)

Cheers,

Nico


Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
--- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
+++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
@@ -28,6 +28,7 @@
 
 void	do_authenticated(Authctxt *ac);
 
+int	session_still_used();
 int	session_open(int id);
 void	session_input_channel_req(int id, void *arg);
 void	session_close_by_pid(pid_t pid, int status);
Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
--- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
+++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
@@ -1533,18 +1533,18 @@
 	exit(1);
 }
 
+static int did_init_sessions = 0;
 Session *
 session_new(void)
 {
 	int i;
-	static int did_init = 0;
-	if (!did_init) {
+	if (!did_init_sessions) {
 		debug("session_new: init");
 		for(i = 0; i < MAX_SESSIONS; i++) {
 			sessions[i].used = 0;
 			sessions[i].self = i;
 		}
-		did_init = 1;
+		did_init_sessions = 1;
 	}
 	for(i = 0; i < MAX_SESSIONS; i++) {
 		Session *s = &sessions[i];
@@ -1622,6 +1622,27 @@
 	error("session_by_pid: unknown pid %d", pid);
 	session_dump();
 	return NULL;
+}
+
+int
+session_still_used()
+{
+	int i;
+	if (!did_init_sessions) {
+		debug("session_new: init");
+		for(i = 0; i < MAX_SESSIONS; i++) {
+			sessions[i].used = 0;
+			sessions[i].self = i;
+		}
+		did_init_sessions = 1;
+	}
+	debug("session_still_used");
+	for(i = 0; i < MAX_SESSIONS; i++) {
+		Session *s = &sessions[i];
+		if (s->used)
+			return 1;
+	}
+	return 0;
 }
 
 int
Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
--- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
+++ 2_9_p2_w_gss_krb5_named_keys.10(w)/serverloop.c Thu, 25 Oct 2001 15:11:49 -0400 willian (OpenSSH/i/16_serverloop 1.1 644)
@@ -259,18 +259,25 @@
 		if (max_time_milliseconds == 0 || client_alive_scheduled)
 			max_time_milliseconds = 100;
 
+	if (!channel_still_open())
+		max_time_milliseconds = 1000;
+
 	if (max_time_milliseconds == 0)
 		tvp = NULL;
 	else {
 		tv.tv_sec = max_time_milliseconds / 1000;
 		tv.tv_usec = 1000 * (max_time_milliseconds % 1000);
 		tvp = &tv;
+		debug3("select timeout is: tv.tv_sec=%d, tv.tv_usec=%d", (int) max_time_milliseconds /
+			1000, (int) 1000 * (max_time_milliseconds % 1000));
 	}
 	if (tvp!=NULL)
 		debug3("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds);
 
 	/* Wait for something to happen, or the timeout to expire. */
 	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
+	debug("select() returned %d, child_terminated=%d, channel_still_open() returned %d", ret,
+		child_terminated, channel_still_open());
 
 	if (ret == -1) {
 		if (errno != EINTR)
@@ -590,6 +597,8 @@
 		/* Sleep in select() until we can do something. */
 		wait_until_can_do_something(&readset, &writeset, &max_fd,
 		    max_time_milliseconds);
+		debug("wait_until_can_do_something returned; child_terminated=%d, channel_still_open=%d",
+			child_terminated, channel_still_open());
 
 		/* Process any channel events. */
 		channel_after_select(readset, writeset);
@@ -599,6 +608,11 @@
 
 		/* Process output to the client and to program stdin. */
 		process_output(writeset);
+
+		/* Don't know if this is needed -- if it is, uncomment 
+		if (!channel_still_open() && child_terminated)
+			break;
+		*/
 	}
 	if (readset)
 		xfree(readset);
@@ -721,7 +735,10 @@
 		if (child_terminated) {
 			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
 				session_close_by_pid(pid, status);
-			child_terminated = 0;
+			if (session_still_used())
+				child_terminated = 0;
+		     if (child_terminated && !channel_still_open())
+			break;
 		}
 		if (!rekeying)
 			channel_after_select(readset, writeset);

--
-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  Fri Oct 26 05:30:39 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 15:30:39 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110251751.f9PHp1uI384166@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Thu, Oct 25, 2001 at 10:51:01AM -0700
References: <200110251751.f9PHp1uI384166@jurassic.eng.sun.com>
Message-ID: <20011025153038.A5739@sm2p1386swk.wdr.com>

On Thu, Oct 25, 2001 at 10:51:01AM -0700, Darren Moffat wrote:
> It is up to the calling application and its' conversation function to
> deal with getting the information from the user.  If pam_acct_mgmt
> returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
> one (because it has no tty) then it has to make its own choice of what
> to do, it can continue and ignore it or it can display a warning or it
> can disconnect - it is upto sshd to choose what to do (it could use
> SSH_ASKPASS if it is available).

if pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD and the application
can't call pam_chauthtok() or do the subsequent prompting of the user
then the app should NOT just go on.

In the case of Kerberos password validation doing so would open the
application to a major KDC spoofing attack. This is because there is
nothing in the AS-REP to prove to the application that the response came
from a valid KDC -- the host can only validate the KDC by getting a TGT
and then a service ticket for a host principal for which that host has a
valid key stored locally.

> >back and forth enough to confuse everybody?).  Maybe there could be a
> >PAM_OPEN_SESSION_BROKEN flag in config.h, which is defined by default, and
> >we could document which patch needs to be applied on Solaris in order to
> >avoid the problem and allow pam_open_session() to be called (with NO
> >PAM_TTY set).
> 
> Please do not use that as the option name, instead say something that
> says what you are acutally doing - not caling pam_open_session when sshd
> doesn't have a tty.  pam_open_session on Solaris is not broken, it is
> just that without the patch the pam_sm_open_session in pam_unix assumes
> that it is only ever called with a valid PAM_TTY - that was a bug.

Right, PAM_UNIX was broken :)

> --
> Darren J Moffat


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 dwd at bell-labs.com  Fri Oct 26 05:46:17 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Thu, 25 Oct 2001 14:46:17 -0500
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011025142357.A2299@lucent.com>; from dwd@bell-labs.com on Thu, Oct 25, 2001 at 02:23:57PM -0500
References: <20011024192422.A27605@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu> <20011024223030.A185@serv01.aet.tu-cottbus.de> <20011025142357.A2299@lucent.com>
Message-ID: <20011025144617.B2299@lucent.com>

On Thu, Oct 25, 2001 at 02:23:57PM -0500, Dave Dykstra wrote:
> I agree that X11 forwarding on the server is not a problem; the problem is
> that a secure client can be put at risk from an insecure server.  If you're
> accessing a secure server from an insecure client you've got worse problems
> and X11 forwarding won't add any risk to the server.
> 
> Why, then, doesn't OpenSSH set X11Forward=yes by default on the server?

I'm sorry that I hadn't yet gotten to the other thread that brought up the
same question.  Markus said it has been discussed before, I guess I'll
search the archives.

- Dave Dykstra


From Nicolas.Williams at ubsw.com  Fri Oct 26 05:50:29 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 15:50:29 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <20011025153038.A5739@sm2p1386swk.wdr.com>; from willian on Thu, Oct 25, 2001 at 03:30:38PM -0400
References: <200110251751.f9PHp1uI384166@jurassic.eng.sun.com> <20011025153038.A5739@sm2p1386swk.wdr.com>
Message-ID: <20011025155027.O6269@sm2p1386swk.wdr.com>

On Thu, Oct 25, 2001 at 03:30:38PM -0400, Nicolas Williams wrote:
> On Thu, Oct 25, 2001 at 10:51:01AM -0700, Darren Moffat wrote:
> > It is up to the calling application and its' conversation function to
> > deal with getting the information from the user.  If pam_acct_mgmt
> > returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
> > one (because it has no tty) then it has to make its own choice of what
> > to do, it can continue and ignore it or it can display a warning or it
> > can disconnect - it is upto sshd to choose what to do (it could use
> > SSH_ASKPASS if it is available).
> 
> if pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD and the application
> can't call pam_chauthtok() or do the subsequent prompting of the user
> then the app should NOT just go on.

That aside, it would be nice to have two standard PAM conversation
functions, one for conversing on a TTY, the other for conversing via
something like SSH_ASKPASS (or PAM_ASK_ITEM :)

> In the case of Kerberos password validation doing so would open the
> application to a major KDC spoofing attack. This is because there is
> nothing in the AS-REP to prove to the application that the response came
> from a valid KDC -- the host can only validate the KDC by getting a TGT
> and then a service ticket for a host principal for which that host has a
> valid key stored locally.
> 
> > --
> > Darren J Moffat
> 

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 ed at UDel.Edu  Fri Oct 26 05:51:17 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 15:51:17 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110251751.f9PHp1uI384166@jurassic.eng.sun.com>
Message-ID: <Pine.SOL.4.30.0110251536060.12864-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Darren Moffat wrote:

> Date: Thu, 25 Oct 2001 10:51:01 -0700 (PDT)
> From: Darren Moffat <Darren.Moffat at eng.sun.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
> >Does this make sense?
>
> All makes sense to me.

[...snip...]

> >Darren... is this true - if PAM_TTY is not set and the user needs to
> >change his password, will pam_sm_acct_mgmt() in pam_unix.so return an
> >error that sshd can detect and process?
>
> Nope, and I don't think it should either. The pam modules do not assume
> that a tty is present to do the prompting because your converstation
> function might actually be a GUI.

When sshd calls pam_acct_mgmt(), will the conversation routine
automatically get called if the user needs to change his password (to emit
something like "Your password has expired." (The conversation routine
doesn't actually do anything but "print" messages right?)?  After calling
the conversation routine, then pam_acct_mgmt() will return
PAM_NEW_AUTHTOK_REQD (or some other error to indicate what's wrong)?
Then, the right thing to do is have sshd either fetch the password and
call...  what? pam_chauthtok()?  In our case (non-interactive, no tty)
this is the point where sshd could send a failure notice to the client an
close the connection.

> It is up to the calling application and its' conversation function to
> deal with getting the information from the user.  If pam_acct_mgmt
> returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
> one (because it has no tty) then it has to make its own choice of what
> to do, it can continue and ignore it or it can display a warning or it
> can disconnect - it is upto sshd to choose what to do (it could use
> SSH_ASKPASS if it is available).

Okay, this seems to be at least part of the answer I'm looking for above,
but check me to see if I'm getting it right (it's been a while since I was
last neck-deep in this stuff)...

> >back and forth enough to confuse everybody?).  Maybe there could be a
> >PAM_OPEN_SESSION_BROKEN flag in config.h, which is defined by default, and
> >we could document which patch needs to be applied on Solaris in order to
> >avoid the problem and allow pam_open_session() to be called (with NO
> >PAM_TTY set).
>
> Please do not use that as the option name, instead say something that
> says what you are acutally doing - not caling pam_open_session when sshd
> doesn't have a tty.  pam_open_session on Solaris is not broken, it is
> just that without the patch the pam_sm_open_session in pam_unix assumes
> that it is only ever called with a valid PAM_TTY - that was a bug.

Sorry... I was just looking for something to differentiate from the old
PAM_TTY_KLUDGE. ;-)

How about PAM_NO_TTY_NO_SESSION?

	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 jmknoble at pobox.com  Fri Oct 26 06:05:05 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 25 Oct 2001 16:05:05 -0400
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011025142357.A2299@lucent.com>; from dwd@bell-labs.com on Thu, Oct 25, 2001 at 02:23:57PM -0500
References: <20011024192422.A27605@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110241437080.16569-100000@mahler.udel.edu> <20011024223030.A185@serv01.aet.tu-cottbus.de> <20011025142357.A2299@lucent.com>
Message-ID: <20011025160505.D3438@zax.half.pint-stowp.cx>

Circa 2001-Oct-25 14:23:57 -0500 dixit Dave Dykstra:

: Why, then, doesn't OpenSSH set X11Forward=yes by default on the server?

Don't know.  However, i do know that, on servers without xauth present,
sshd emits a nasty warning message when X11 forwarding is turned on but
sshd can't find xauth.  That may be why Markus or someone else decided
to turn it off by default.

-- 
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/20011025/a04d9948/attachment.bin 

From Nicolas.Williams at ubsw.com  Fri Oct 26 05:54:41 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 15:54:41 -0400
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025152522.C26615@wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Oct 25, 2001 at 03:25:22PM -0400
References: <20011025152522.C26615@wdr.com>
Message-ID: <20011025155440.B5739@sm2p1386swk.wdr.com>

I forgot to mention the behaviour that this patch fixes: hang-on-exit
for SSHv2 sessions. See the other "SIGCHLD race condition?" thread for
more details.

Cheers,

Nico


On Thu, Oct 25, 2001 at 03:25:22PM -0400, Nicolas Williams wrote:
> Yes, this is a patch against an older version of OpenSSH with other
> stuff anyways, BUT, it's so TRIVIAL(*), that you can see how it would
> apply to newer versions (which I've not tried).
> 
> Here's the gist: server_loop2() has a race condition with respect to
> reception of SIGCHLD and checking/setting child_terminated. This patch
> does two things: wait_until_can_do_something() adds a 1 second timeout
> to select() IF AND ONLY IF (!channel_still_open) AND, server_loop2()
> breaks out of its loop when there are no sessions left.
> 
> Blocking SIGCHLD before select()ing would not fix the problem, nor would
> that be very portable.
> 
> So, summary of changes:
> 
>  - session.h
> 
>    Added prototype for session_still_used() boolean function.
> 
>  - session.c
> 
>    Added session_still_used() boolean function.
> 
>  - serverloop.c
> 
>    Added this bit of code to wait_until_can_do_something():
> 
>       if (!channel_still_open())
>               max_time_milliseconds = 1000;
> 
>    before select()ing.
> 
>    Added this bit of code to server_loop2():
> 
>                 if (child_terminated) {
>                         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
>                                 session_close_by_pid(pid, status);
> -                       child_terminated = 0;
> +                       if (session_still_used())
> +                               child_terminated = 0;
> +                    if (child_terminated && !channel_still_open())
> +                       break;
> 
>    so that child_terminated is not reset after handling SIGCHLD *UNLESS*
>    there are no sessions left open.
> 
> Also, for server_loop(), perhaps it too should have a check to break
> out of its loop if the child is terminated and there are no channels
> still open.
> 
> (*) I hope :)
> 
> Cheers,
> 
> Nico
> 
> 
> Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
> --- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> @@ -28,6 +28,7 @@
>  
>  void	do_authenticated(Authctxt *ac);
>  
> +int	session_still_used();
>  int	session_open(int id);
>  void	session_input_channel_req(int id, void *arg);
>  void	session_close_by_pid(pid_t pid, int status);
> Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
> --- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> @@ -1533,18 +1533,18 @@
>  	exit(1);
>  }
>  
> +static int did_init_sessions = 0;
>  Session *
>  session_new(void)
>  {
>  	int i;
> -	static int did_init = 0;
> -	if (!did_init) {
> +	if (!did_init_sessions) {
>  		debug("session_new: init");
>  		for(i = 0; i < MAX_SESSIONS; i++) {
>  			sessions[i].used = 0;
>  			sessions[i].self = i;
>  		}
> -		did_init = 1;
> +		did_init_sessions = 1;
>  	}
>  	for(i = 0; i < MAX_SESSIONS; i++) {
>  		Session *s = &sessions[i];
> @@ -1622,6 +1622,27 @@
>  	error("session_by_pid: unknown pid %d", pid);
>  	session_dump();
>  	return NULL;
> +}
> +
> +int
> +session_still_used()
> +{
> +	int i;
> +	if (!did_init_sessions) {
> +		debug("session_new: init");
> +		for(i = 0; i < MAX_SESSIONS; i++) {
> +			sessions[i].used = 0;
> +			sessions[i].self = i;
> +		}
> +		did_init_sessions = 1;
> +	}
> +	debug("session_still_used");
> +	for(i = 0; i < MAX_SESSIONS; i++) {
> +		Session *s = &sessions[i];
> +		if (s->used)
> +			return 1;
> +	}
> +	return 0;
>  }
>  
>  int
> Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
> --- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
> +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/serverloop.c Thu, 25 Oct 2001 15:11:49 -0400 willian (OpenSSH/i/16_serverloop 1.1 644)
> @@ -259,18 +259,25 @@
>  		if (max_time_milliseconds == 0 || client_alive_scheduled)
>  			max_time_milliseconds = 100;
>  
> +	if (!channel_still_open())
> +		max_time_milliseconds = 1000;
> +
>  	if (max_time_milliseconds == 0)
>  		tvp = NULL;
>  	else {
>  		tv.tv_sec = max_time_milliseconds / 1000;
>  		tv.tv_usec = 1000 * (max_time_milliseconds % 1000);
>  		tvp = &tv;
> +		debug3("select timeout is: tv.tv_sec=%d, tv.tv_usec=%d", (int) max_time_milliseconds /
> +			1000, (int) 1000 * (max_time_milliseconds % 1000));
>  	}
>  	if (tvp!=NULL)
>  		debug3("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds);
>  
>  	/* Wait for something to happen, or the timeout to expire. */
>  	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
> +	debug("select() returned %d, child_terminated=%d, channel_still_open() returned %d", ret,
> +		child_terminated, channel_still_open());
>  
>  	if (ret == -1) {
>  		if (errno != EINTR)
> @@ -590,6 +597,8 @@
>  		/* Sleep in select() until we can do something. */
>  		wait_until_can_do_something(&readset, &writeset, &max_fd,
>  		    max_time_milliseconds);
> +		debug("wait_until_can_do_something returned; child_terminated=%d, channel_still_open=%d",
> +			child_terminated, channel_still_open());
>  
>  		/* Process any channel events. */
>  		channel_after_select(readset, writeset);
> @@ -599,6 +608,11 @@
>  
>  		/* Process output to the client and to program stdin. */
>  		process_output(writeset);
> +
> +		/* Don't know if this is needed -- if it is, uncomment 
> +		if (!channel_still_open() && child_terminated)
> +			break;
> +		*/
>  	}
>  	if (readset)
>  		xfree(readset);
> @@ -721,7 +735,10 @@
>  		if (child_terminated) {
>  			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
>  				session_close_by_pid(pid, status);
> -			child_terminated = 0;
> +			if (session_still_used())
> +				child_terminated = 0;
> +		     if (child_terminated && !channel_still_open())
> +			break;
>  		}
>  		if (!rekeying)
>  			channel_after_select(readset, writeset);
> 
--
-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 Darren.Moffat at eng.sun.com  Fri Oct 26 05:57:38 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 12:57:38 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
Message-ID: <200110251957.f9PJvcuI407227@jurassic.eng.sun.com>

>something like SSH_ASKPASS (or PAM_ASK_ITEM :)

What is PAM_ASK_ITEM ?

You can't just add items to the PAM item namespace this is an Open group
administered standard.

--
Darren J Moffat



From Nicolas.Williams at ubsw.com  Fri Oct 26 06:03:14 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 16:03:14 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110251957.f9PJvcuI407227@jurassic.eng.sun.com>; from Darren Moffat on Thu, Oct 25, 2001 at 12:57:38PM -0700
References: <200110251957.f9PJvcuI407227@jurassic.eng.sun.com>
Message-ID: <20011025160314.D26615@wdr.com>

On Thu, Oct 25, 2001 at 12:57:38PM -0700, Darren Moffat wrote:
> >something like SSH_ASKPASS (or PAM_ASK_ITEM :)
> 
> What is PAM_ASK_ITEM ?

I was saying, indirectly, that any such utility library should use the
value of an environment value named "PAM_ASK_ITEM" as the name of the
program to execute for prompting the used for PAM items (e.g., PAM_USER
or PAM_AUTHTOK or PAM_OLDAUTHTOK).

I just invented that :)

> You can't just add items to the PAM item namespace this is an Open group
> administered standard.

I'm doing no such thing. Though  I certainly could: Linux-PAM has done
this sort of thing before :) (but no worries, I have no deisre, yet, to
add PAM items).

> --
> Darren J Moffat


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 Darren.Moffat at eng.sun.com  Fri Oct 26 06:09:39 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 13:09:39 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
Message-ID: <200110252009.f9PK9cuI409165@jurassic.eng.sun.com>

>Mind you, one could use a new PAM item named PAM_ASK_ITEM instead of an
>environment variable for configuring the PAM equivalent of SSH_ASKPASS.
>But I'm not asking for that either.

We already have that it is the conversation function.

--
Darren J Moffat



From Nicolas.Williams at ubsw.com  Fri Oct 26 06:05:01 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 16:05:01 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <20011025160314.D26615@wdr.com>; from willian on Thu, Oct 25, 2001 at 04:03:14PM -0400
References: <200110251957.f9PJvcuI407227@jurassic.eng.sun.com> <20011025160314.D26615@wdr.com>
Message-ID: <20011025160500.P6269@sm2p1386swk.wdr.com>

Mind you, one could use a new PAM item named PAM_ASK_ITEM instead of an
environment variable for configuring the PAM equivalent of SSH_ASKPASS.
But I'm not asking for that either.

Nico

On Thu, Oct 25, 2001 at 04:03:14PM -0400, Nicolas Williams wrote:
> On Thu, Oct 25, 2001 at 12:57:38PM -0700, Darren Moffat wrote:
> > >something like SSH_ASKPASS (or PAM_ASK_ITEM :)
> > 
> > What is PAM_ASK_ITEM ?
> 
> I was saying, indirectly, that any such utility library should use the
> value of an environment value named "PAM_ASK_ITEM" as the name of the
> program to execute for prompting the used for PAM items (e.g., PAM_USER
> or PAM_AUTHTOK or PAM_OLDAUTHTOK).
> 
> I just invented that :)
> 
> > You can't just add items to the PAM item namespace this is an Open group
> > administered standard.
> 
> I'm doing no such thing. Though  I certainly could: Linux-PAM has done
> this sort of thing before :) (but no worries, I have no deisre, yet, to
> add PAM items).
> 
> > --
> > Darren J Moffat
> 
> 
> 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.-
--
-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  Fri Oct 26 06:16:23 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 16:16:23 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110252009.f9PK9cuI409165@jurassic.eng.sun.com>; from Darren Moffat on Thu, Oct 25, 2001 at 01:09:39PM -0700
References: <200110252009.f9PK9cuI409165@jurassic.eng.sun.com>
Message-ID: <20011025161623.E26615@wdr.com>

I understand that. I mean that it would be nice to have such a
conversation function that could be distributed with libpam.

Nico


On Thu, Oct 25, 2001 at 01:09:39PM -0700, Darren Moffat wrote:
> >Mind you, one could use a new PAM item named PAM_ASK_ITEM instead of an
> >environment variable for configuring the PAM equivalent of SSH_ASKPASS.
> >But I'm not asking for that either.
> 
> We already have that it is the conversation function.
> 
> --
> Darren J Moffat
--
-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  Fri Oct 26 06:21:58 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 16:21:58 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110251536060.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 03:51:17PM -0400
References: <200110251751.f9PHp1uI384166@jurassic.eng.sun.com> <Pine.SOL.4.30.0110251536060.12864-100000@mahler.udel.edu>
Message-ID: <20011025162157.C5739@sm2p1386swk.wdr.com>

On Thu, Oct 25, 2001 at 03:51:17PM -0400, Ed Phillips wrote:
> On Thu, 25 Oct 2001, Darren Moffat wrote:
> 
> > Date: Thu, 25 Oct 2001 10:51:01 -0700 (PDT)
> > From: Darren Moffat <Darren.Moffat at eng.sun.com>
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> >
> > >Does this make sense?
> >
> > All makes sense to me.
> 
> [...snip...]
> 
> > >Darren... is this true - if PAM_TTY is not set and the user needs to
> > >change his password, will pam_sm_acct_mgmt() in pam_unix.so return an
> > >error that sshd can detect and process?
> >
> > Nope, and I don't think it should either. The pam modules do not assume
> > that a tty is present to do the prompting because your converstation
> > function might actually be a GUI.
> 
> When sshd calls pam_acct_mgmt(), will the conversation routine
> automatically get called if the user needs to change his password (to emit
> something like "Your password has expired." (The conversation routine
> doesn't actually do anything but "print" messages right?)?  After calling

For that message, yes, the conv function only prints it, though in a GUI
environment it would bring up a dialog with an "Ok" button.

> the conversation routine, then pam_acct_mgmt() will return
> PAM_NEW_AUTHTOK_REQD (or some other error to indicate what's wrong)?
> Then, the right thing to do is have sshd either fetch the password and
> call...  what? pam_chauthtok()?  In our case (non-interactive, no tty)

The right thing to do is to call pam_chauthtok() and let *it* do any
additional conversing with the user that might be needed.

For non-interactive sessions such conversing should/might not be
possible, thus the conversation would return an error to the modules
calling it, which would, depending on the modules and how the PAM
stack is configured, cause pam_chauthtok() to return an error back to
the application, which would then return an error to the user (i.e.,
sshd would close the connection to the client).

> this is the point where sshd could send a failure notice to the client an
> close the connection.
> 
> > It is up to the calling application and its' conversation function to
> > deal with getting the information from the user.  If pam_acct_mgmt
> > returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
> > one (because it has no tty) then it has to make its own choice of what
> > to do, it can continue and ignore it or it can display a warning or it
> > can disconnect - it is upto sshd to choose what to do (it could use
> > SSH_ASKPASS if it is available).
> 
> Okay, this seems to be at least part of the answer I'm looking for above,
> but check me to see if I'm getting it right (it's been a while since I was
> last neck-deep in this stuff)...

Again, it is not ok to just go on if pam_acct_mgmt() returns
PAM_NEW_AUTHTOK_REQD -- pam_chauthtok() must be called *and* it must
return PAM_SUCCESS or the session must be ended.

> 	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


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 mouring at etoh.eviladmin.org  Fri Oct 26 06:25:12 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 25 Oct 2001 15:25:12 -0500 (CDT)
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025155440.B5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.BSO.4.33.0110251524400.4313-100000@etoh.eviladmin.org>


I've not tested this, but have you verified that scp never loses any data?
and the 'ssh site date'  NEVER loses data?

- Ben

On Thu, 25 Oct 2001, Nicolas Williams wrote:

> I forgot to mention the behaviour that this patch fixes: hang-on-exit
> for SSHv2 sessions. See the other "SIGCHLD race condition?" thread for
> more details.
>
> Cheers,
>
> Nico
>
>
> On Thu, Oct 25, 2001 at 03:25:22PM -0400, Nicolas Williams wrote:
> > Yes, this is a patch against an older version of OpenSSH with other
> > stuff anyways, BUT, it's so TRIVIAL(*), that you can see how it would
> > apply to newer versions (which I've not tried).
> >
> > Here's the gist: server_loop2() has a race condition with respect to
> > reception of SIGCHLD and checking/setting child_terminated. This patch
> > does two things: wait_until_can_do_something() adds a 1 second timeout
> > to select() IF AND ONLY IF (!channel_still_open) AND, server_loop2()
> > breaks out of its loop when there are no sessions left.
> >
> > Blocking SIGCHLD before select()ing would not fix the problem, nor would
> > that be very portable.
> >
> > So, summary of changes:
> >
> >  - session.h
> >
> >    Added prototype for session_still_used() boolean function.
> >
> >  - session.c
> >
> >    Added session_still_used() boolean function.
> >
> >  - serverloop.c
> >
> >    Added this bit of code to wait_until_can_do_something():
> >
> >       if (!channel_still_open())
> >               max_time_milliseconds = 1000;
> >
> >    before select()ing.
> >
> >    Added this bit of code to server_loop2():
> >
> >                 if (child_terminated) {
> >                         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> >                                 session_close_by_pid(pid, status);
> > -                       child_terminated = 0;
> > +                       if (session_still_used())
> > +                               child_terminated = 0;
> > +                    if (child_terminated && !channel_still_open())
> > +                       break;
> >
> >    so that child_terminated is not reset after handling SIGCHLD *UNLESS*
> >    there are no sessions left open.
> >
> > Also, for server_loop(), perhaps it too should have a check to break
> > out of its loop if the child is terminated and there are no channels
> > still open.
> >
> > (*) I hope :)
> >
> > Cheers,
> >
> > Nico
> >
> >
> > Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
> > --- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> > +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> > @@ -28,6 +28,7 @@
> >
> >  void	do_authenticated(Authctxt *ac);
> >
> > +int	session_still_used();
> >  int	session_open(int id);
> >  void	session_input_channel_req(int id, void *arg);
> >  void	session_close_by_pid(pid_t pid, int status);
> > Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
> > --- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> > +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> > @@ -1533,18 +1533,18 @@
> >  	exit(1);
> >  }
> >
> > +static int did_init_sessions = 0;
> >  Session *
> >  session_new(void)
> >  {
> >  	int i;
> > -	static int did_init = 0;
> > -	if (!did_init) {
> > +	if (!did_init_sessions) {
> >  		debug("session_new: init");
> >  		for(i = 0; i < MAX_SESSIONS; i++) {
> >  			sessions[i].used = 0;
> >  			sessions[i].self = i;
> >  		}
> > -		did_init = 1;
> > +		did_init_sessions = 1;
> >  	}
> >  	for(i = 0; i < MAX_SESSIONS; i++) {
> >  		Session *s = &sessions[i];
> > @@ -1622,6 +1622,27 @@
> >  	error("session_by_pid: unknown pid %d", pid);
> >  	session_dump();
> >  	return NULL;
> > +}
> > +
> > +int
> > +session_still_used()
> > +{
> > +	int i;
> > +	if (!did_init_sessions) {
> > +		debug("session_new: init");
> > +		for(i = 0; i < MAX_SESSIONS; i++) {
> > +			sessions[i].used = 0;
> > +			sessions[i].self = i;
> > +		}
> > +		did_init_sessions = 1;
> > +	}
> > +	debug("session_still_used");
> > +	for(i = 0; i < MAX_SESSIONS; i++) {
> > +		Session *s = &sessions[i];
> > +		if (s->used)
> > +			return 1;
> > +	}
> > +	return 0;
> >  }
> >
> >  int
> > Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
> > --- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
> > +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/serverloop.c Thu, 25 Oct 2001 15:11:49 -0400 willian (OpenSSH/i/16_serverloop 1.1 644)
> > @@ -259,18 +259,25 @@
> >  		if (max_time_milliseconds == 0 || client_alive_scheduled)
> >  			max_time_milliseconds = 100;
> >
> > +	if (!channel_still_open())
> > +		max_time_milliseconds = 1000;
> > +
> >  	if (max_time_milliseconds == 0)
> >  		tvp = NULL;
> >  	else {
> >  		tv.tv_sec = max_time_milliseconds / 1000;
> >  		tv.tv_usec = 1000 * (max_time_milliseconds % 1000);
> >  		tvp = &tv;
> > +		debug3("select timeout is: tv.tv_sec=%d, tv.tv_usec=%d", (int) max_time_milliseconds /
> > +			1000, (int) 1000 * (max_time_milliseconds % 1000));
> >  	}
> >  	if (tvp!=NULL)
> >  		debug3("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds);
> >
> >  	/* Wait for something to happen, or the timeout to expire. */
> >  	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
> > +	debug("select() returned %d, child_terminated=%d, channel_still_open() returned %d", ret,
> > +		child_terminated, channel_still_open());
> >
> >  	if (ret == -1) {
> >  		if (errno != EINTR)
> > @@ -590,6 +597,8 @@
> >  		/* Sleep in select() until we can do something. */
> >  		wait_until_can_do_something(&readset, &writeset, &max_fd,
> >  		    max_time_milliseconds);
> > +		debug("wait_until_can_do_something returned; child_terminated=%d, channel_still_open=%d",
> > +			child_terminated, channel_still_open());
> >
> >  		/* Process any channel events. */
> >  		channel_after_select(readset, writeset);
> > @@ -599,6 +608,11 @@
> >
> >  		/* Process output to the client and to program stdin. */
> >  		process_output(writeset);
> > +
> > +		/* Don't know if this is needed -- if it is, uncomment
> > +		if (!channel_still_open() && child_terminated)
> > +			break;
> > +		*/
> >  	}
> >  	if (readset)
> >  		xfree(readset);
> > @@ -721,7 +735,10 @@
> >  		if (child_terminated) {
> >  			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> >  				session_close_by_pid(pid, status);
> > -			child_terminated = 0;
> > +			if (session_still_used())
> > +				child_terminated = 0;
> > +		     if (child_terminated && !channel_still_open())
> > +			break;
> >  		}
> >  		if (!rekeying)
> >  			channel_after_select(readset, writeset);
> >
> --
> -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  Fri Oct 26 06:30:09 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 16:30:09 -0400
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <Pine.BSO.4.33.0110251524400.4313-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Thu, Oct 25, 2001 at 03:25:12PM -0500
References: <20011025155440.B5739@sm2p1386swk.wdr.com> <Pine.BSO.4.33.0110251524400.4313-100000@etoh.eviladmin.org>
Message-ID: <20011025163009.F26615@wdr.com>

I've done some testing and no, no data is lost. Look at the new
condition for breaking out of the server loop: if (there's no channels
AND there's no sessions).

Of course, I'm not too familiar with how unsent buffers would be
handled. Can you explain?

Perhaps the (no channels open && no sessions in use) check should be
made at the bottom of the loop, after channel_after_select(),
process_input() and process_output() have been called.

Hmmm,

Nico

On Thu, Oct 25, 2001 at 03:25:12PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> I've not tested this, but have you verified that scp never loses any data?
> and the 'ssh site date'  NEVER loses data?
> 
> - Ben
> 
> On Thu, 25 Oct 2001, Nicolas Williams wrote:
> 
> > I forgot to mention the behaviour that this patch fixes: hang-on-exit
> > for SSHv2 sessions. See the other "SIGCHLD race condition?" thread for
> > more details.
> >
> > Cheers,
> >
> > Nico
> >
> >
> > On Thu, Oct 25, 2001 at 03:25:22PM -0400, Nicolas Williams wrote:
> > > Yes, this is a patch against an older version of OpenSSH with other
> > > stuff anyways, BUT, it's so TRIVIAL(*), that you can see how it would
> > > apply to newer versions (which I've not tried).
> > >
> > > Here's the gist: server_loop2() has a race condition with respect to
> > > reception of SIGCHLD and checking/setting child_terminated. This patch
> > > does two things: wait_until_can_do_something() adds a 1 second timeout
> > > to select() IF AND ONLY IF (!channel_still_open) AND, server_loop2()
> > > breaks out of its loop when there are no sessions left.
> > >
> > > Blocking SIGCHLD before select()ing would not fix the problem, nor would
> > > that be very portable.
> > >
> > > So, summary of changes:
> > >
> > >  - session.h
> > >
> > >    Added prototype for session_still_used() boolean function.
> > >
> > >  - session.c
> > >
> > >    Added session_still_used() boolean function.
> > >
> > >  - serverloop.c
> > >
> > >    Added this bit of code to wait_until_can_do_something():
> > >
> > >       if (!channel_still_open())
> > >               max_time_milliseconds = 1000;
> > >
> > >    before select()ing.
> > >
> > >    Added this bit of code to server_loop2():
> > >
> > >                 if (child_terminated) {
> > >                         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> > >                                 session_close_by_pid(pid, status);
> > > -                       child_terminated = 0;
> > > +                       if (session_still_used())
> > > +                               child_terminated = 0;
> > > +                    if (child_terminated && !channel_still_open())
> > > +                       break;
> > >
> > >    so that child_terminated is not reset after handling SIGCHLD *UNLESS*
> > >    there are no sessions left open.
> > >
> > > Also, for server_loop(), perhaps it too should have a check to break
> > > out of its loop if the child is terminated and there are no channels
> > > still open.
> > >
> > > (*) I hope :)
> > >
> > > Cheers,
> > >
> > > Nico
> > >
> > >
> > > Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
> > > --- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> > > +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> > > @@ -28,6 +28,7 @@
> > >
> > >  void	do_authenticated(Authctxt *ac);
> > >
> > > +int	session_still_used();
> > >  int	session_open(int id);
> > >  void	session_input_channel_req(int id, void *arg);
> > >  void	session_close_by_pid(pid_t pid, int status);
> > > Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
> > > --- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> > > +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> > > @@ -1533,18 +1533,18 @@
> > >  	exit(1);
> > >  }
> > >
> > > +static int did_init_sessions = 0;
> > >  Session *
> > >  session_new(void)
> > >  {
> > >  	int i;
> > > -	static int did_init = 0;
> > > -	if (!did_init) {
> > > +	if (!did_init_sessions) {
> > >  		debug("session_new: init");
> > >  		for(i = 0; i < MAX_SESSIONS; i++) {
> > >  			sessions[i].used = 0;
> > >  			sessions[i].self = i;
> > >  		}
> > > -		did_init = 1;
> > > +		did_init_sessions = 1;
> > >  	}
> > >  	for(i = 0; i < MAX_SESSIONS; i++) {
> > >  		Session *s = &sessions[i];
> > > @@ -1622,6 +1622,27 @@
> > >  	error("session_by_pid: unknown pid %d", pid);
> > >  	session_dump();
> > >  	return NULL;
> > > +}
> > > +
> > > +int
> > > +session_still_used()
> > > +{
> > > +	int i;
> > > +	if (!did_init_sessions) {
> > > +		debug("session_new: init");
> > > +		for(i = 0; i < MAX_SESSIONS; i++) {
> > > +			sessions[i].used = 0;
> > > +			sessions[i].self = i;
> > > +		}
> > > +		did_init_sessions = 1;
> > > +	}
> > > +	debug("session_still_used");
> > > +	for(i = 0; i < MAX_SESSIONS; i++) {
> > > +		Session *s = &sessions[i];
> > > +		if (s->used)
> > > +			return 1;
> > > +	}
> > > +	return 0;
> > >  }
> > >
> > >  int
> > > Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
> > > --- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
> > > +++ 2_9_p2_w_gss_krb5_named_keys.10(w)/serverloop.c Thu, 25 Oct 2001 15:11:49 -0400 willian (OpenSSH/i/16_serverloop 1.1 644)
> > > @@ -259,18 +259,25 @@
> > >  		if (max_time_milliseconds == 0 || client_alive_scheduled)
> > >  			max_time_milliseconds = 100;
> > >
> > > +	if (!channel_still_open())
> > > +		max_time_milliseconds = 1000;
> > > +
> > >  	if (max_time_milliseconds == 0)
> > >  		tvp = NULL;
> > >  	else {
> > >  		tv.tv_sec = max_time_milliseconds / 1000;
> > >  		tv.tv_usec = 1000 * (max_time_milliseconds % 1000);
> > >  		tvp = &tv;
> > > +		debug3("select timeout is: tv.tv_sec=%d, tv.tv_usec=%d", (int) max_time_milliseconds /
> > > +			1000, (int) 1000 * (max_time_milliseconds % 1000));
> > >  	}
> > >  	if (tvp!=NULL)
> > >  		debug3("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds);
> > >
> > >  	/* Wait for something to happen, or the timeout to expire. */
> > >  	ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
> > > +	debug("select() returned %d, child_terminated=%d, channel_still_open() returned %d", ret,
> > > +		child_terminated, channel_still_open());
> > >
> > >  	if (ret == -1) {
> > >  		if (errno != EINTR)
> > > @@ -590,6 +597,8 @@
> > >  		/* Sleep in select() until we can do something. */
> > >  		wait_until_can_do_something(&readset, &writeset, &max_fd,
> > >  		    max_time_milliseconds);
> > > +		debug("wait_until_can_do_something returned; child_terminated=%d, channel_still_open=%d",
> > > +			child_terminated, channel_still_open());
> > >
> > >  		/* Process any channel events. */
> > >  		channel_after_select(readset, writeset);
> > > @@ -599,6 +608,11 @@
> > >
> > >  		/* Process output to the client and to program stdin. */
> > >  		process_output(writeset);
> > > +
> > > +		/* Don't know if this is needed -- if it is, uncomment
> > > +		if (!channel_still_open() && child_terminated)
> > > +			break;
> > > +		*/
> > >  	}
> > >  	if (readset)
> > >  		xfree(readset);
> > > @@ -721,7 +735,10 @@
> > >  		if (child_terminated) {
> > >  			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> > >  				session_close_by_pid(pid, status);
> > > -			child_terminated = 0;
> > > +			if (session_still_used())
> > > +				child_terminated = 0;
> > > +		     if (child_terminated && !channel_still_open())
> > > +			break;
> > >  		}
> > >  		if (!rekeying)
> > >  			channel_after_select(readset, writeset);
> > >
> > --
> > -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.
> >
> >
--
-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 ed at UDel.Edu  Fri Oct 26 06:31:11 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 16:31:11 -0400 (EDT)
Subject: Another round of testing calls.
In-Reply-To: <200110251659.f9PGxouI374734@jurassic.eng.sun.com>
Message-ID: <Pine.SOL.4.30.0110251353430.12864-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Darren Moffat wrote:

> Date: Thu, 25 Oct 2001 09:59:50 -0700 (PDT)
> From: Darren Moffat <Darren.Moffat at eng.sun.com>
> To: ed at UDel.Edu
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Another round of testing calls.
>
> >What is pam_setid?  Do you mean pam_setcred?  pam_setcred has always been
>
> yes I meant setcred.
>
> >a little fuzzy... the pam_setcred from pam_unix.so has changed function
> >between Sol2.6 and Sol7.  In 2.6, pam_sm_setcred did nothing and
> >initgroups() was called by login or other apps directly.  In Sol7,
> >pam_sm_setcred actually called initgroups() and the apps were made
> >to call pam_setcred with expectations of it calling initgroups().
>
> That is not correct.  The code for pam_sm_setcred in pam_unix hasn't
> actually changed between 2.6 and the current builds of the next release
> of Solaris.   Well that isn't quite true there were a few minor changes
> but that was fixing a broken cast to remove a compiler warning and
> chaning the wording of one of the messages that prints it out.
> I've just checked the code (and BTW this is one of my areas of Solaris
> responsibility).

Sorry... I was remembering from the wrong point of view.  When we
implemented our own pam_udel.so modules to stack on top of pam_unix.so,
the behavior of the applications changed such that our pam_sm_setcred() in
2.6 was doing nothing, and our pam_sm_setcred() in 7 and later HAD to call
initgroups() or certain applications would not get the proper set of
groups.  I'm having a hard time remembering why at the moment (and I'm
searching though the Sol8 FCS source but can't seem to locate the 2.6
source at the moment).  Do you recall way back in 2.6 when the
applications didn't all completely use PAM "correctly" and not very
consistently?  Anyway, we had to add a call to initgroups() in our
pam_sm_setcred() to get the correct set of groups in Sol7+ whereas we
didn't back in 2.6.  Also, we have a custom NSS back-end that might have
be a factor at some level (because initgroups() would look up groups in
our backend.

[Where the heck is the source to /usr/bin/login in the Sol8 source tree
anyway?]

On Solaris 8, the basic set of "applications" are:

in.telnetd	(which just runs login)
in.rlogind	(which just runs login)
in.rshd		(which does PAM calls but no pam_open_session() calls)
in.rexecd	(uses PAM now, but didn't in previous versions)
in.ftpd		(does full array of PAM calls + initgroups())
		Side note: in.ftpd set PAM_TTY to "ftp%ld" filling in the
		pid - so it avoids falling prey to the bug in pam_unix.so
login		(does full array of PAM calls + initgroups() + session)
		Side note: login can actually set PAM_TTY to a real tty name ;-)
dtlogin		(we couldn't use dtlogin - we've always compiled our own xdm)

and of course, sshd. ;-)

> The last time that initgroups didn't happen in the application but
> happened in the module was 2.5.1 - when PAM was in prerelease state and
> not configurable or public.
>
> Having said all of that what you were suggesting had happened is actually
> the correct way to go, initgroups probably should be called from the
> pam_unix pam_setcred and not the application since your supplementary groups
> are your unix creds.  However we don't currently do that - if Solaris ever
> does get to that stage then OpenSSH should be updated to not do the
> initgroups calls if being built to run on that release of Solaris.

I agree.

	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  Fri Oct 26 06:34:28 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 16:34:28 -0400 (EDT)
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011025160505.D3438@zax.half.pint-stowp.cx>
Message-ID: <Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Jim Knoble wrote:

> Date: Thu, 25 Oct 2001 16:05:05 -0400
> From: Jim Knoble <jmknoble at pobox.com>
> To: openssh-unix-dev at mindrot.org
> Cc: Dave Dykstra <dwd at bell-labs.com>
> Subject: Re: What risk is X11Forward to a server?
>
> Circa 2001-Oct-25 14:23:57 -0500 dixit Dave Dykstra:
>
> : Why, then, doesn't OpenSSH set X11Forward=yes by default on the server?
>
> Don't know.  However, i do know that, on servers without xauth present,
> sshd emits a nasty warning message when X11 forwarding is turned on but
> sshd can't find xauth.  That may be why Markus or someone else decided
> to turn it off by default.

That brings up a quick question I forgot...

How do you change the compiled-in PATH that sshd uses by default?

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 Nicolas.Williams at ubsw.com  Fri Oct 26 06:57:00 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 16:57:00 -0400
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025163009.F26615@wdr.com>; from willian on Thu, Oct 25, 2001 at 04:30:09PM -0400
References: <20011025155440.B5739@sm2p1386swk.wdr.com> <Pine.BSO.4.33.0110251524400.4313-100000@etoh.eviladmin.org> <20011025163009.F26615@wdr.com>
Message-ID: <20011025165658.Q6269@sm2p1386swk.wdr.com>

SSH_CHANNEL_INPUT_DRAINING and SSH_CHANNEL_OUTPUT_DRAINING channels are
considered "still open" by channel_still_open(), so no, no data can be
lost.

That said, there's no harm in moving the check to the bottom of the
loop.

A new, cleaner patch is attached. Again, against 2.9p2 + stuff, but
conceptually it should apply to any later releases that still have this
bug.

Cheers,

Nico

On Thu, Oct 25, 2001 at 04:30:09PM -0400, Nicolas Williams wrote:
> I've done some testing and no, no data is lost. Look at the new
> condition for breaking out of the server loop: if (there's no channels
> AND there's no sessions).
> 
> Of course, I'm not too familiar with how unsent buffers would be
> handled. Can you explain?
> 
> Perhaps the (no channels open && no sessions in use) check should be
> made at the bottom of the loop, after channel_after_select(),
> process_input() and process_output() have been called.
> 
> Hmmm,
> 
> Nico
> 
> On Thu, Oct 25, 2001 at 03:25:12PM -0500, mouring at etoh.eviladmin.org wrote:
> > 
> > I've not tested this, but have you verified that scp never loses any data?
> > and the 'ssh site date'  NEVER loses data?
> > 
> > - Ben


Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
--- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
+++ 2_9_p2_w_gss_krb5_named_keys.12(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.3 644)
@@ -28,6 +28,7 @@
 
 void	do_authenticated(Authctxt *ac);
 
+int	session_still_used();
 int	session_open(int id);
 void	session_input_channel_req(int id, void *arg);
 void	session_close_by_pid(pid_t pid, int status);
Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
--- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
+++ 2_9_p2_w_gss_krb5_named_keys.12(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.4 644)
@@ -1533,18 +1533,18 @@
 	exit(1);
 }
 
+static int did_init_sessions = 0;
 Session *
 session_new(void)
 {
 	int i;
-	static int did_init = 0;
-	if (!did_init) {
+	if (!did_init_sessions) {
 		debug("session_new: init");
 		for(i = 0; i < MAX_SESSIONS; i++) {
 			sessions[i].used = 0;
 			sessions[i].self = i;
 		}
-		did_init = 1;
+		did_init_sessions = 1;
 	}
 	for(i = 0; i < MAX_SESSIONS; i++) {
 		Session *s = &sessions[i];
@@ -1622,6 +1622,27 @@
 	error("session_by_pid: unknown pid %d", pid);
 	session_dump();
 	return NULL;
+}
+
+int
+session_still_used()
+{
+	int i;
+	if (!did_init_sessions) {
+		debug("session_new: init");
+		for(i = 0; i < MAX_SESSIONS; i++) {
+			sessions[i].used = 0;
+			sessions[i].self = i;
+		}
+		did_init_sessions = 1;
+	}
+	debug("session_still_used");
+	for(i = 0; i < MAX_SESSIONS; i++) {
+		Session *s = &sessions[i];
+		if (s->used)
+			return 1;
+	}
+	return 0;
 }
 
 int
Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
--- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
+++ 2_9_p2_w_gss_krb5_named_keys.12(w)/serverloop.c Thu, 25 Oct 2001 16:35:36 -0400 willian (OpenSSH/i/16_serverloop 1.3 644)
@@ -259,6 +259,9 @@
 		if (max_time_milliseconds == 0 || client_alive_scheduled)
 			max_time_milliseconds = 100;
 
+	if (!channel_still_open())
+		max_time_milliseconds = 1000;
+
 	if (max_time_milliseconds == 0)
 		tvp = NULL;
 	else {
@@ -599,6 +602,11 @@
 
 		/* Process output to the client and to program stdin. */
 		process_output(writeset);
+
+		/* Don't know if this is needed -- if it is, uncomment 
+		if (!channel_still_open() && child_terminated)
+			break;
+		*/
 	}
 	if (readset)
 		xfree(readset);
@@ -721,7 +729,8 @@
 		if (child_terminated) {
 			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
 				session_close_by_pid(pid, status);
-			child_terminated = 0;
+			if (session_still_used())
+				child_terminated = 0;
 		}
 		if (!rekeying)
 			channel_after_select(readset, writeset);
@@ -729,6 +738,8 @@
 		if (connection_closed)
 			break;
 		process_output(writeset);
+		if (child_terminated && !channel_still_open())
+			break;
 	}
 	if (readset)
 		xfree(readset);

--
-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 mouring at etoh.eviladmin.org  Fri Oct 26 07:01:52 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Thu, 25 Oct 2001 16:01:52 -0500 (CDT)
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025165658.Q6269@sm2p1386swk.wdr.com>
Message-ID: <Pine.BSO.4.33.0110251601150.13559-100000@etoh.eviladmin.org>


It won't apply anywhere clean to the current CVS tree.. and when I shoe
horn it.. it provides me with no useful solution.

- Ben

On Thu, 25 Oct 2001, Nicolas Williams wrote:

> SSH_CHANNEL_INPUT_DRAINING and SSH_CHANNEL_OUTPUT_DRAINING channels are
> considered "still open" by channel_still_open(), so no, no data can be
> lost.
>
> That said, there's no harm in moving the check to the bottom of the
> loop.
>
> A new, cleaner patch is attached. Again, against 2.9p2 + stuff, but
> conceptually it should apply to any later releases that still have this
> bug.
>
> Cheers,
>
> Nico
>
> On Thu, Oct 25, 2001 at 04:30:09PM -0400, Nicolas Williams wrote:
> > I've done some testing and no, no data is lost. Look at the new
> > condition for breaking out of the server loop: if (there's no channels
> > AND there's no sessions).
> >
> > Of course, I'm not too familiar with how unsent buffers would be
> > handled. Can you explain?
> >
> > Perhaps the (no channels open && no sessions in use) check should be
> > made at the bottom of the loop, after channel_after_select(),
> > process_input() and process_output() have been called.
> >
> > Hmmm,
> >
> > Nico
> >
> > On Thu, Oct 25, 2001 at 03:25:12PM -0500, mouring at etoh.eviladmin.org wrote:
> > >
> > > I've not tested this, but have you verified that scp never loses any data?
> > > and the 'ssh site date'  NEVER loses data?
> > >
> > > - Ben
>
>
> Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
> --- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> +++ 2_9_p2_w_gss_krb5_named_keys.12(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.3 644)
> @@ -28,6 +28,7 @@
>
>  void	do_authenticated(Authctxt *ac);
>
> +int	session_still_used();
>  int	session_open(int id);
>  void	session_input_channel_req(int id, void *arg);
>  void	session_close_by_pid(pid_t pid, int status);
> Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
> --- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> +++ 2_9_p2_w_gss_krb5_named_keys.12(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.4 644)
> @@ -1533,18 +1533,18 @@
>  	exit(1);
>  }
>
> +static int did_init_sessions = 0;
>  Session *
>  session_new(void)
>  {
>  	int i;
> -	static int did_init = 0;
> -	if (!did_init) {
> +	if (!did_init_sessions) {
>  		debug("session_new: init");
>  		for(i = 0; i < MAX_SESSIONS; i++) {
>  			sessions[i].used = 0;
>  			sessions[i].self = i;
>  		}
> -		did_init = 1;
> +		did_init_sessions = 1;
>  	}
>  	for(i = 0; i < MAX_SESSIONS; i++) {
>  		Session *s = &sessions[i];
> @@ -1622,6 +1622,27 @@
>  	error("session_by_pid: unknown pid %d", pid);
>  	session_dump();
>  	return NULL;
> +}
> +
> +int
> +session_still_used()
> +{
> +	int i;
> +	if (!did_init_sessions) {
> +		debug("session_new: init");
> +		for(i = 0; i < MAX_SESSIONS; i++) {
> +			sessions[i].used = 0;
> +			sessions[i].self = i;
> +		}
> +		did_init_sessions = 1;
> +	}
> +	debug("session_still_used");
> +	for(i = 0; i < MAX_SESSIONS; i++) {
> +		Session *s = &sessions[i];
> +		if (s->used)
> +			return 1;
> +	}
> +	return 0;
>  }
>
>  int
> Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
> --- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
> +++ 2_9_p2_w_gss_krb5_named_keys.12(w)/serverloop.c Thu, 25 Oct 2001 16:35:36 -0400 willian (OpenSSH/i/16_serverloop 1.3 644)
> @@ -259,6 +259,9 @@
>  		if (max_time_milliseconds == 0 || client_alive_scheduled)
>  			max_time_milliseconds = 100;
>
> +	if (!channel_still_open())
> +		max_time_milliseconds = 1000;
> +
>  	if (max_time_milliseconds == 0)
>  		tvp = NULL;
>  	else {
> @@ -599,6 +602,11 @@
>
>  		/* Process output to the client and to program stdin. */
>  		process_output(writeset);
> +
> +		/* Don't know if this is needed -- if it is, uncomment
> +		if (!channel_still_open() && child_terminated)
> +			break;
> +		*/
>  	}
>  	if (readset)
>  		xfree(readset);
> @@ -721,7 +729,8 @@
>  		if (child_terminated) {
>  			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
>  				session_close_by_pid(pid, status);
> -			child_terminated = 0;
> +			if (session_still_used())
> +				child_terminated = 0;
>  		}
>  		if (!rekeying)
>  			channel_after_select(readset, writeset);
> @@ -729,6 +738,8 @@
>  		if (connection_closed)
>  			break;
>  		process_output(writeset);
> +		if (child_terminated && !channel_still_open())
> +			break;
>  	}
>  	if (readset)
>  		xfree(readset);
>
> --
> -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  Fri Oct 26 07:10:00 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 17:10:00 -0400
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <Pine.BSO.4.33.0110251601150.13559-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Thu, Oct 25, 2001 at 04:01:52PM -0500
References: <20011025165658.Q6269@sm2p1386swk.wdr.com> <Pine.BSO.4.33.0110251601150.13559-100000@etoh.eviladmin.org>
Message-ID: <20011025171000.H26615@wdr.com>

Oh, that's too bad. I haven't played with the current CVS.

Nonetheless, you can see what the problem was and how the race was
addressed in our patch. Wether the concept carries over will depend on
how much server_loop2() and friends have changed since 2.9p2.

Specifically,

 - select() must be given a timeout if there are no open channels
 - child_terminated should be true only when there are no more
   sessions in use
 - the main loop should be exited when there are no more sessions in use
   and no more channels open

This way sshd doesn't get stuck in a select() with no timeout, no live
children, and no open file descriptors from its now-dead children.

Since draining channels are considered open no data can be lost.

Nico


On Thu, Oct 25, 2001 at 04:01:52PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> It won't apply anywhere clean to the current CVS tree.. and when I shoe
> horn it.. it provides me with no useful solution.
> 
> - Ben
> 
> On Thu, 25 Oct 2001, Nicolas Williams wrote:
> 
> > SSH_CHANNEL_INPUT_DRAINING and SSH_CHANNEL_OUTPUT_DRAINING channels are
> > considered "still open" by channel_still_open(), so no, no data can be
> > lost.
> >
> > That said, there's no harm in moving the check to the bottom of the
> > loop.
> >
> > A new, cleaner patch is attached. Again, against 2.9p2 + stuff, but
> > conceptually it should apply to any later releases that still have this
> > bug.
> >
> > Cheers,
> >
> > Nico
> >
> > On Thu, Oct 25, 2001 at 04:30:09PM -0400, Nicolas Williams wrote:
> > > I've done some testing and no, no data is lost. Look at the new
> > > condition for breaking out of the server loop: if (there's no channels
> > > AND there's no sessions).
> > >
> > > Of course, I'm not too familiar with how unsent buffers would be
> > > handled. Can you explain?
> > >
> > > Perhaps the (no channels open && no sessions in use) check should be
> > > made at the bottom of the loop, after channel_after_select(),
> > > process_input() and process_output() have been called.
> > >
> > > Hmmm,
> > >
> > > Nico
> > >
> > > On Thu, Oct 25, 2001 at 03:25:12PM -0500, mouring at etoh.eviladmin.org wrote:
> > > >
> > > > I've not tested this, but have you verified that scp never loses any data?
> > > > and the 'ssh site date'  NEVER loses data?
> > > >
> > > > - Ben
> >
> >
> > Index: 2_9_p2_w_gss_krb5_named_keys.10/session.h
> > --- 2_9_p2_w_gss_krb5_named_keys.10/session.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/13_session.h 1.2 644)
> > +++ 2_9_p2_w_gss_krb5_named_keys.12(w)/session.h Thu, 25 Oct 2001 14:58:32 -0400 willian (OpenSSH/i/13_session.h 1.3 644)
> > @@ -28,6 +28,7 @@
> >
> >  void	do_authenticated(Authctxt *ac);
> >
> > +int	session_still_used();
> >  int	session_open(int id);
> >  void	session_input_channel_req(int id, void *arg);
> >  void	session_close_by_pid(pid_t pid, int status);
> > Index: 2_9_p2_w_gss_krb5_named_keys.10/session.c
> > --- 2_9_p2_w_gss_krb5_named_keys.10/session.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/i/14_session.c 1.3 644)
> > +++ 2_9_p2_w_gss_krb5_named_keys.12(w)/session.c Thu, 25 Oct 2001 15:04:21 -0400 willian (OpenSSH/i/14_session.c 1.4 644)
> > @@ -1533,18 +1533,18 @@
> >  	exit(1);
> >  }
> >
> > +static int did_init_sessions = 0;
> >  Session *
> >  session_new(void)
> >  {
> >  	int i;
> > -	static int did_init = 0;
> > -	if (!did_init) {
> > +	if (!did_init_sessions) {
> >  		debug("session_new: init");
> >  		for(i = 0; i < MAX_SESSIONS; i++) {
> >  			sessions[i].used = 0;
> >  			sessions[i].self = i;
> >  		}
> > -		did_init = 1;
> > +		did_init_sessions = 1;
> >  	}
> >  	for(i = 0; i < MAX_SESSIONS; i++) {
> >  		Session *s = &sessions[i];
> > @@ -1622,6 +1622,27 @@
> >  	error("session_by_pid: unknown pid %d", pid);
> >  	session_dump();
> >  	return NULL;
> > +}
> > +
> > +int
> > +session_still_used()
> > +{
> > +	int i;
> > +	if (!did_init_sessions) {
> > +		debug("session_new: init");
> > +		for(i = 0; i < MAX_SESSIONS; i++) {
> > +			sessions[i].used = 0;
> > +			sessions[i].self = i;
> > +		}
> > +		did_init_sessions = 1;
> > +	}
> > +	debug("session_still_used");
> > +	for(i = 0; i < MAX_SESSIONS; i++) {
> > +		Session *s = &sessions[i];
> > +		if (s->used)
> > +			return 1;
> > +	}
> > +	return 0;
> >  }
> >
> >  int
> > Index: 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c
> > --- 2_9_p2_w_gss_krb5_named_keys.10/serverloop.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/i/16_serverloop 1.1 644)
> > +++ 2_9_p2_w_gss_krb5_named_keys.12(w)/serverloop.c Thu, 25 Oct 2001 16:35:36 -0400 willian (OpenSSH/i/16_serverloop 1.3 644)
> > @@ -259,6 +259,9 @@
> >  		if (max_time_milliseconds == 0 || client_alive_scheduled)
> >  			max_time_milliseconds = 100;
> >
> > +	if (!channel_still_open())
> > +		max_time_milliseconds = 1000;
> > +
> >  	if (max_time_milliseconds == 0)
> >  		tvp = NULL;
> >  	else {
> > @@ -599,6 +602,11 @@
> >
> >  		/* Process output to the client and to program stdin. */
> >  		process_output(writeset);
> > +
> > +		/* Don't know if this is needed -- if it is, uncomment
> > +		if (!channel_still_open() && child_terminated)
> > +			break;
> > +		*/
> >  	}
> >  	if (readset)
> >  		xfree(readset);
> > @@ -721,7 +729,8 @@
> >  		if (child_terminated) {
> >  			while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> >  				session_close_by_pid(pid, status);
> > -			child_terminated = 0;
> > +			if (session_still_used())
> > +				child_terminated = 0;
> >  		}
> >  		if (!rekeying)
> >  			channel_after_select(readset, writeset);
> > @@ -729,6 +738,8 @@
> >  		if (connection_closed)
> >  			break;
> >  		process_output(writeset);
> > +		if (child_terminated && !channel_still_open())
> > +			break;
> >  	}
> >  	if (readset)
> >  		xfree(readset);
> >
> > --
> > -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.
> >
> >
--
-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  Fri Oct 26 07:12:28 2001
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 25 Oct 2001 23:12:28 +0200
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025152522.C26615@wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Oct 25, 2001 at 03:25:22PM -0400
References: <20011025152522.C26615@wdr.com>
Message-ID: <20011025231228.B29515@folly>

On Thu, Oct 25, 2001 at 03:25:22PM -0400, Nicolas Williams wrote:
>       if (!channel_still_open())
>               max_time_milliseconds = 1000;

there are no channels when a client authenticates.

just try ssh -N

> 
>    Added this bit of code to server_loop2():
> 
>                 if (child_terminated) {
>                         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
>                                 session_close_by_pid(pid, status);
> -                       child_terminated = 0;
> +                       if (session_still_used())
> +                               child_terminated = 0;
> +                    if (child_terminated && !channel_still_open())
> +                       break;
			^^^^^
you cannot break. the client decides when the connection gets closed.

i think it could still request another login shell.

but yes, the SIGCLD races could be fixed with a select timeout.

but that's ugly. perhaps using siglongjmp is less ugly
and even portable.

-m


From ed at UDel.Edu  Fri Oct 26 07:28:56 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 17:28:56 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <20011025162157.C5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.SOL.4.30.0110251636110.12864-200000@mahler.udel.edu>

On Thu, 25 Oct 2001, Nicolas Williams wrote:

> Again, it is not ok to just go on if pam_acct_mgmt() returns
> PAM_NEW_AUTHTOK_REQD -- pam_chauthtok() must be called *and* it must
> return PAM_SUCCESS or the session must be ended.

I agree.

The more I look at how other applications use pam_open_session() the more
I think it's okay to go ahead and set PAM_TTY to something like "sshdXXXX"
(where XXXX is the pid) for non-interactive sessions.  And, we should call
pam_open_session() no matter what mode we're in.

However, I think a change should be made so that pam_chauthtok() is not
called if we don't have a real TTY.

Attached is a simple patch for 2.9.9p2 for someone who has time to test it
before I can (tomorrow).  It will (hopefully) make sshd set PAM_TTY no
matter what (we might #ifdef this for Solaris if it breaks other OSes...
???), and make sshd "fail" instead of trying to call pam_chauthtok() when
we don't have a real tty (although if we had a DISPLAY we might try
running ssh-askpass?).  Is there anything I'm missing?

	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
-------------- next part --------------
*** auth-pam.c_orig	Thu Oct 25 16:57:38 2001
--- auth-pam.c	Thu Oct 25 17:15:34 2001
***************
*** 58,63 ****
--- 58,65 ----
  static int password_change_required = 0;
  /* remember whether the last pam_authenticate() succeeded or not */
  static int was_authenticated = 0;
+ /* remember whether we have a real TTY for this session */
+ static int have_real_tty = 0;
  
  /* Remember what has been initialised */
  static int session_opened = 0;
***************
*** 269,274 ****
--- 271,277 ----
  void do_pam_session(char *username, const char *ttyname)
  {
  	int pam_retval;
+ 	char ttyfake[50];
  
  	do_pam_set_conv(&conv);
  
***************
*** 278,283 ****
--- 281,295 ----
  		if (pam_retval != PAM_SUCCESS)
  			fatal("PAM set tty failed[%d]: %.200s",
  			    pam_retval, PAM_STRERROR(__pamh, pam_retval));
+ 		have_real_tty = 1;
+ 	} else {
+ 		sprintf(ttyfake, "sshd%ld", getpid());
+ 		debug("PAM setting tty to \"%.50s\"", ttyfake);
+ 		pam_retval = pam_set_item(__pamh, PAM_TTY, ttyfake);
+ 		if (pam_retval != PAM_SUCCESS)
+ 			fatal("PAM set tty failed[%d]: %.200s",
+ 			    pam_retval, PAM_STRERROR(__pamh, pam_retval));
+ 		have_real_tty = 0;
  	}
  
  	pam_retval = pam_open_session(__pamh, 0);
***************
*** 329,338 ****
  
  	if (password_change_required) {
  		pamstate = OTHER;
! 		pam_retval = pam_chauthtok(__pamh, PAM_CHANGE_EXPIRED_AUTHTOK);
! 		if (pam_retval != PAM_SUCCESS)
! 			fatal("PAM pam_chauthtok failed[%d]: %.200s",
! 			    pam_retval, PAM_STRERROR(__pamh, pam_retval));
  	}
  }
  
--- 341,355 ----
  
  	if (password_change_required) {
  		pamstate = OTHER;
! 		if (have_real_tty) {
! 			pam_retval = pam_chauthtok(__pamh,
! 				PAM_CHANGE_EXPIRED_AUTHTOK);
! 			if (pam_retval != PAM_SUCCESS)
! 				fatal("PAM pam_chauthtok failed[%d]: %.200s",
! 				    pam_retval, PAM_STRERROR(__pamh, pam_retval));
! 		} else {
! 			fatal("Can't call pam_chauthtok: no TTY");
! 		}
  	}
  }
  
***************
*** 366,373 ****
  	if (pam_retval != PAM_SUCCESS)
  		fatal("PAM set rhost failed[%d]: %.200s", pam_retval,
  		    PAM_STRERROR(__pamh, pam_retval));
! #ifdef PAM_TTY_KLUDGE
  	/*
  	 * Some PAM modules (e.g. pam_time) require a TTY to operate,
  	 * and will fail in various stupid ways if they don't get one.
  	 * sshd doesn't set the tty until too late in the auth process and may
--- 383,396 ----
  	if (pam_retval != PAM_SUCCESS)
  		fatal("PAM set rhost failed[%d]: %.200s", pam_retval,
  		    PAM_STRERROR(__pamh, pam_retval));
! 
  	/*
+ 	 * Let do_pam_session decide whether or not to include a "dummy"
+ 	 * PAM_TTY in the PAM handle or not. ELP 10/25/2001
+ 	 */
+ 
+ #ifdef xPAM_TTY_KLUDGE
+ 	/*
  	 * Some PAM modules (e.g. pam_time) require a TTY to operate,
  	 * and will fail in various stupid ways if they don't get one.
  	 * sshd doesn't set the tty until too late in the auth process and may
***************
*** 378,384 ****
  	if (pam_retval != PAM_SUCCESS)
  		fatal("PAM set tty failed[%d]: %.200s",
  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
! #endif /* PAM_TTY_KLUDGE */
  
  	fatal_add_cleanup(&do_pam_cleanup_proc, NULL);
  }
--- 401,407 ----
  	if (pam_retval != PAM_SUCCESS)
  		fatal("PAM set tty failed[%d]: %.200s",
  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
! #endif /* xPAM_TTY_KLUDGE */
  
  	fatal_add_cleanup(&do_pam_cleanup_proc, NULL);
  }

From ed at UDel.Edu  Fri Oct 26 07:51:20 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Thu, 25 Oct 2001 17:51:20 -0400 (EDT)
Subject: PAM conversation stuff
Message-ID: <Pine.SOL.4.30.0110251741440.12864-100000@mahler.udel.edu>

Okay, I'm confused again.  They way you guys are talking about the
conversation routine, it would seem that you think it is a way to fetch
something from the user - like a new password.  Is this possible?  Does
calling pam_chauthtok() cause the underlying pam_sm_chauthtok()
eventually print something on stdout and read a new password from stdin
(the socket to the client) using the conversation routine?  If this is
what is happening, then logically the bug is in the part of the
conversation routine that isn't checking to see if stdin/stdout is a TTY
before trying to prompt the user for info.

Conversely, the conversation routine is just a glorified "printf", then
where in the heck is the password read in, and where is pam_set_item()
being called to fill in the details before the call to pam_chauthtok() can
actually update the password?

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 bob at proulx.com  Fri Oct 26 08:49:25 2001
From: bob at proulx.com (Bob Proulx)
Date: Thu, 25 Oct 2001 16:49:25 -0600
Subject: What risk is X11Forward to a server?
In-Reply-To: <Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>
References: <20011025160505.D3438@zax.half.pint-stowp.cx>
	<Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>
Message-ID: <200110252249.f9PMnPa06579@torment.proulx.com>

> That brings up a quick question I forgot...
> 
> How do you change the compiled-in PATH that sshd uses by default?

I don't think it is currently possible.  That is one thing that I have
really needed/wanted with ssh.  The ability to set the PATH in the
site sshd_config file.

Traditionally the rsh command (as implemented on SysV systems such as
hpux which is where my experience comes from) implements
/usr/local/bin:/usr/bin:/bin, etc., the operative directory being
/usr/local/bin.  But openssh does not.  Which means I always need to
recompile with a that path addition in order to make it compatible
with rsh on our systems.  And that really makes sense.  I don't want
to have to include the full path to a command in scripts.  But does
not completely solve the problem because even that does not handle
nonstandard path locations.

I would really like to see /usr/local/bin/ added to the default build.
But I realize that it is a system dependent value.  I don't think it
is possible to implement a one size fits all value.  The best answer
would probably be a way to configure this in the sshd_config file.  It
is high on my wishlist.

Bob


From Darren.Moffat at eng.sun.com  Fri Oct 26 09:07:26 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 16:07:26 -0700 (PDT)
Subject: PAM conversation stuff
Message-ID: <200110252307.f9PN7QuI444520@jurassic.eng.sun.com>


>Okay, I'm confused again.  They way you guys are talking about the
>conversation routine, it would seem that you think it is a way to fetch
>something from the user - like a new password.  Is this possible?  Does
>calling pam_chauthtok() cause the underlying pam_sm_chauthtok()

When an application calls pam_start (or pam_set_item(pamh, PAM_CONV, &conv),
it passes a pointer to a function to be called by any module that needs
to do IO with the user.


pam_chauthok() lives in libpam it calls pam_sm_chauthtok() (twice) for
each module in the password stack (note password != passwd) for the current
service.  If a particular pam_sm_chauthtok() wishes to do IO with the user
it does pam_get_item(pamh, PAM_CONV, &conv) and gets the function pointer
out of that structure, it may set PAM_USER_PROMPT before calling it.

This puts you back into sshd in this case (auth-pam.c) so if sshd can't
do any IO with the user the converstation function should return a failure
message which will cause that pam_sm_chauthtok to fail and (depending on
the control-flags in pam.conf) the whole pam_chauthtok() call which then
puts us backinto sshd gain with something like PAM_AUTHTOK_ERR at which
point it is upto sshd to decied what to do but as many have pointed out
the expected and probably correct thing to do is close the connection.

Closing the connection is consistant with what happens with telent on
Solaris if you don't provide a new password on expiry.

>eventually print something on stdout and read a new password from stdin
>(the socket to the client) using the conversation routine?  If this is
>what is happening, then logically the bug is in the part of the
>conversation routine that isn't checking to see if stdin/stdout is a TTY
>before trying to prompt the user for info.

Correct.

--
Darren J Moffat



From Darren.Moffat at eng.sun.com  Fri Oct 26 09:10:29 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Thu, 25 Oct 2001 16:10:29 -0700 (PDT)
Subject: Default $PATH of rsh (Was Re: What risk is X11Forward to a server?)
Message-ID: <200110252310.f9PNATuI445164@jurassic.eng.sun.com>

>Traditionally the rsh command (as implemented on SysV systems such as
>hpux which is where my experience comes from) implements
>/usr/local/bin:/usr/bin:/bin, etc., the operative directory being
>/usr/local/bin.  But openssh does not.  Which means I always need to

First I wouldn't say that HPUX was a good example of SysV, second 
/usr/local/bin is certainly not ever placed in the PATH under Solaris
(which is an SysV derivative in some ways).

In Solaris you can change the default PATH by either updating one of
the shell init scripts or chaning PATH in /etc/default/login to do it
in a shell independant way.

--
Darren J Moffat



From cmadams at hiwaay.net  Fri Oct 26 09:23:17 2001
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 25 Oct 2001 18:23:17 -0500
Subject: What risk is X11Forward to a server?
In-Reply-To: <Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 04:34:28PM -0400
References: <20011025160505.D3438@zax.half.pint-stowp.cx> <Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>
Message-ID: <20011025182317.A24978@HiWAAY.net>

Once upon a time, Ed Phillips <ed at UDel.Edu> said:
> How do you change the compiled-in PATH that sshd uses by default?

AFAIK it can only be changed at compile time.

If you are on a platform that uses PAM, you could override the compiled
in PATH that way (eg using pam_env.so on Linux).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From djm at mindrot.org  Fri Oct 26 10:14:21 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 10:14:21 +1000 (EST)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110261013040.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Ed Phillips wrote:

> What is the reasoning behind this?  Do we want to see a lastlog entry for
> "ssh" whenever a user runs remote command?  Do other OSes have
> pam_open_session that does more meaningful things than Solaris 8?
> Well...  I guess the more I think about it, it's probably better to go
> ahead an call pam_open_session even for the non-interactive case since
> someone might want to implement a PAM module at their site that logs every
> ssh connection... and if we don't call pam_open_session, then they don't
> even have that capability if they wanted it.

Some people set rlimits using session modules. Someone even filed a Bugtraq
report about 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  Fri Oct 26 10:23:32 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 10:23:32 +1000 (EST)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110251030320.12864-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110261023090.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Ed Phillips wrote:

> On Thu, 25 Oct 2001, Markus Friedl wrote:
> 
> > Date: Thu, 25 Oct 2001 15:54:10 +0200
> > From: Markus Friedl <markus at openbsd.org>
> > To: Ed Phillips <ed at UDel.Edu>
> > Cc: Damien Miller <djm at mindrot.org>,
> >      Darren Moffat <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> >
> > On Thu, Oct 25, 2001 at 09:47:40AM -0400, Ed Phillips wrote:
> > > Do we want to see a lastlog entry for
> > > "ssh" whenever a user runs remote command?
> >
> > no.
> 
> Well, that's what happens when you call pam_open_session with TTY set to
> "NODEVssh"... ;-)

Only because you have a pam_lastlog session module.

-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  Fri Oct 26 10:26:25 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 10:26:25 +1000 (EST)
Subject: Default forwarding features; default cipher
In-Reply-To: <20011025113757.B3438@zax.half.pint-stowp.cx>
Message-ID: <Pine.LNX.4.33.0110261024510.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Jim Knoble wrote:

>   $ fgrep ssh_cipher_default *.c
>   sshconnect1.c:  int ssh_cipher_default = SSH_CIPHER_3DES;
>                                           ^^^^^^^^^^^^^^^^^^
> I'd accept the opinion of the manual page over the comments in the
> default config file.

The defaults for SSH protocol 2 (which you should be using if possible) are: 
"aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour" ...

-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  Fri Oct 26 10:28:55 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 10:28:55 +1000 (EST)
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011025142357.A2299@lucent.com>
Message-ID: <Pine.LNX.4.33.0110261028270.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Dave Dykstra wrote:

> Why, then, doesn't OpenSSH set X11Forward=yes by default on the server?

As Markus said - this has been discussed before, check the archives.

-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  Fri Oct 26 11:21:02 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 25 Oct 2001 21:21:02 -0400
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025231228.B29515@folly>; from markus@openbsd.org on Thu, Oct 25, 2001 at 11:12:28PM +0200
References: <20011025152522.C26615@wdr.com> <20011025231228.B29515@folly>
Message-ID: <20011025212100.D5739@sm2p1386swk.wdr.com>


1. my patch doesn't really fix the race -- signal blocking is needed for
   that. Sigh.

2. I think the normal expectation is that when there are no more open
   sessions or channels or children that sshd should exit. The opposite
   ought to be an option. IMHO

3. If sshd is to exit when (no more sessions && no more channels && no
   more children) then either you must use a select() timeout, at least
   when (no more sessions && no more channels), or sshd must use the
   signal-handler-writes-to-a-pipe-whose-read-end-is-selected-for trick,
   as described in the "SIGCHLD race condition race?" thread by Paul
   Menage.

Cheers,

Nico


On Thu, Oct 25, 2001 at 11:12:28PM +0200, Markus Friedl wrote:
> On Thu, Oct 25, 2001 at 03:25:22PM -0400, Nicolas Williams wrote:
> >       if (!channel_still_open())
> >               max_time_milliseconds = 1000;
> 
> there are no channels when a client authenticates.
> 
> just try ssh -N
> 
> > 
> >    Added this bit of code to server_loop2():
> > 
> >                 if (child_terminated) {
> >                         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> >                                 session_close_by_pid(pid, status);
> > -                       child_terminated = 0;
> > +                       if (session_still_used())
> > +                               child_terminated = 0;
> > +                    if (child_terminated && !channel_still_open())
> > +                       break;
> 			^^^^^
> you cannot break. the client decides when the connection gets closed.
> 
> i think it could still request another login shell.
> 
> but yes, the SIGCLD races could be fixed with a select timeout.
> 
> but that's ugly. perhaps using siglongjmp is less ugly
> and even portable.
> 
> -m
--

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 Oct 26 11:33:16 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 11:33:16 +1000 (EST)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.SOL.4.30.0110251636110.12864-200000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110261104090.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Ed Phillips wrote:

> However, I think a change should be made so that pam_chauthtok() is not
> called if we don't have a real TTY.

> Is there anything I'm missing?

The fact that pam_chauthtok was never getting called without a tty 
anyway.  Look at the code path in session.c. The do_pam_chauthtok() call 
was only being made for the tty case.

If there is a problem, it is that accounts with expired passwords were
still able to execute commands. Please try the patch below for this.

Index: session.c
===================================================================
RCS file: /var/cvs/openssh/session.c,v
retrieving revision 1.154
diff -u -r1.154 session.c
--- session.c	2001/10/12 01:35:51	1.154
+++ session.c	2001/10/26 01:30:29
@@ -432,6 +432,9 @@
 #if defined(USE_PAM)
 	do_pam_session(s->pw->pw_name, NULL);
 	do_pam_setcred(1);
+	if (is_pam_password_change_required())
+		packet_disconnect("Password change required but no "
+		    "TTY available");
 #endif /* USE_PAM */
 
 	/* Fork the child. */

-- 
| 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  Fri Oct 26 11:34:16 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 11:34:16 +1000 (EST)
Subject: What risk is X11Forward to a server?
In-Reply-To: <200110252249.f9PMnPa06579@torment.proulx.com>
Message-ID: <Pine.LNX.4.33.0110261133480.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Bob Proulx wrote:

> > That brings up a quick question I forgot...
> > 
> > How do you change the compiled-in PATH that sshd uses by default?
> 
> I don't think it is currently possible.  That is one thing that I have
> really needed/wanted with ssh.  The ability to set the PATH in the
> site sshd_config file.

RTFM:

configure --with-default-path=xxx

-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 Oct 26 11:42:02 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 25 Oct 2001 21:42:02 -0400
Subject: What risk is X11Forward to a server?
In-Reply-To: <Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 04:34:28PM -0400
References: <20011025160505.D3438@zax.half.pint-stowp.cx> <Pine.SOL.4.30.0110251633081.12864-100000@mahler.udel.edu>
Message-ID: <20011025214202.E3438@zax.half.pint-stowp.cx>

[Please, no CCs.  I'm subscribed to the list.]

Circa 2001-Oct-25 16:34:28 -0400 dixit Ed Phillips:

: That brings up a quick question I forgot...
: 
: How do you change the compiled-in PATH that sshd uses by default?

cd openssh-2.9.9p2
./configure --with-default-path="your:favorite:default:path"

Does no one (besides Markus/Ben/Damien et al.) spend any time with the
source code anymore?  Sheesh.

-- 
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/20011025/925d57a6/attachment.bin 

From djm at mindrot.org  Fri Oct 26 11:35:32 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 11:35:32 +1000 (EST)
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011025182317.A24978@HiWAAY.net>
Message-ID: <Pine.LNX.4.33.0110261134530.2060-100000@mothra.mindrot.org>

On Thu, 25 Oct 2001, Chris Adams wrote:

> Once upon a time, Ed Phillips <ed at UDel.Edu> said:
> > How do you change the compiled-in PATH that sshd uses by default?
> 
> AFAIK it can only be changed at compile time.

You can also change it on a user-by-user basis though ~/.ssh/environment

-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 tomh at po.crl.go.jp  Fri Oct 26 13:58:38 2001
From: tomh at po.crl.go.jp (Tom Holroyd)
Date: Fri, 26 Oct 2001 12:58:38 +0900 (JST)
Subject: strange dir in snapshot
Message-ID: <Pine.LNX.4.30.0110261254530.15686-100000@holly.crl.go.jp>

What is autom4te.cache/ and why is it in the snapshot?



From djm at mindrot.org  Fri Oct 26 14:17:33 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 14:17:33 +1000 (EST)
Subject: strange dir in snapshot
In-Reply-To: <Pine.LNX.4.30.0110261254530.15686-100000@holly.crl.go.jp>
Message-ID: <Pine.LNX.4.33.0110261417010.2060-100000@mothra.mindrot.org>

On Fri, 26 Oct 2001, Tom Holroyd wrote:

> What is autom4te.cache/ and why is it in the snapshot?

It is created by autoconf-2.52, no idea what it 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 tomh at po.crl.go.jp  Fri Oct 26 14:22:16 2001
From: tomh at po.crl.go.jp (Tom Holroyd)
Date: Fri, 26 Oct 2001 13:22:16 +0900 (JST)
Subject: strange dir in snapshot
In-Reply-To: <Pine.LNX.4.33.0110261417010.2060-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.30.0110261320100.15686-100000@holly.crl.go.jp>

> > What is autom4te.cache/ and why is it in the snapshot?
> It is created by autoconf-2.52, no idea what it does.

[/usr/local/src/openssh]% rm -r autom4te.cache/
[/usr/local/src/openssh]% autoconf
[/usr/local/src/openssh]% ls -ld autom4te.cache
ls: autom4te.cache: No such file or directory
[/usr/local/src/openssh]% autoconf --version
autoconf (GNU Autoconf) 2.52
[/usr/local/src/openssh]% autoheader
[/usr/local/src/openssh]% ls -ld autom4te.cache
ls: autom4te.cache: No such file or directory

???



From djm at mindrot.org  Fri Oct 26 14:28:49 2001
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Oct 2001 14:28:49 +1000 (EST)
Subject: strange dir in snapshot
In-Reply-To: <Pine.LNX.4.30.0110261320100.15686-100000@holly.crl.go.jp>
Message-ID: <Pine.LNX.4.33.0110261428360.2060-100000@mothra.mindrot.org>

On Fri, 26 Oct 2001, Tom Holroyd wrote:

> > > What is autom4te.cache/ and why is it in the snapshot?
> > It is created by autoconf-2.52, no idea what it does.
> 
> [/usr/local/src/openssh]% rm -r autom4te.cache/
> [/usr/local/src/openssh]% autoconf
> [/usr/local/src/openssh]% ls -ld autom4te.cache
> ls: autom4te.cache: No such file or directory
> [/usr/local/src/openssh]% autoconf --version
> autoconf (GNU Autoconf) 2.52
> [/usr/local/src/openssh]% autoheader
> [/usr/local/src/openssh]% ls -ld autom4te.cache
> ls: autom4te.cache: No such file or directory
> 
> ???

Try autoreconf

-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 bob at proulx.com  Fri Oct 26 14:41:28 2001
From: bob at proulx.com (Bob Proulx)
Date: Thu, 25 Oct 2001 22:41:28 -0600
Subject: What risk is X11Forward to a server?
In-Reply-To: <Pine.LNX.4.33.0110261133480.2060-100000@mothra.mindrot.org>
References: <200110252249.f9PMnPa06579@torment.proulx.com>
	<Pine.LNX.4.33.0110261133480.2060-100000@mothra.mindrot.org>
Message-ID: <200110260441.f9Q4fSi06892@torment.proulx.com>

> > > How do you change the compiled-in PATH that sshd uses by default?
> > 
> > I don't think it is currently possible.  That is one thing that I have
> > really needed/wanted with ssh.  The ability to set the PATH in the
> > site sshd_config file.
> 
> RTFM:
> configure --with-default-path=xxx

But you cut off the part where I said:

> Which means I always need to recompile with a that path addition in
> order to make it compatible with rsh on our systems.

Which perhaps was not obviously stated as such but I assumed that you
would realize that when I recompile with a system dependent path that
meant configure --with-default-path since that is the most direct way
to recompile using a system dependent path.  I wasn't asking how to do
it.  I was _whining_ that I had to do it at all and couldn't configure
it in sshd_config at startup time instead.

Please RTFM yourself.  In this case the 'M' means my mail message!
:-) :-)

> You can also change it on a user-by-user basis though ~/.ssh/environment

This is not so good and does not work very well in practice.  Let's
say there are utilities installed in some non /usr/bin location.
Normally on a system one would make sure /etc/profile et al sets up
the user's PATH to find those.  Yes a user can freeze any given path
in their dot environment file.  But if updates are made then those
files all become stale.  And you also have to educate a whole user
base about the need to do it at all.  It would be nicer if the user
could be kept blissfully ignorant of the details and have it handled
by the system for everybody all at once.

This is not such a big thing.  I have been building and installing one
version or another ssh for years.  And adapting this every time.  But
it would still be nice.

Bob


From bob at proulx.com  Fri Oct 26 15:02:17 2001
From: bob at proulx.com (Bob Proulx)
Date: Thu, 25 Oct 2001 23:02:17 -0600
Subject: Default $PATH of rsh (Was Re: What risk is X11Forward to a server?)
In-Reply-To: <200110252310.f9PNATuI445164@jurassic.eng.sun.com>
References: <200110252310.f9PNATuI445164@jurassic.eng.sun.com>
Message-ID: <200110260502.f9Q52Hf06966@torment.proulx.com>

> First I wouldn't say that HPUX was a good example of SysV, second 
> /usr/local/bin is certainly not ever placed in the PATH under Solaris
> (which is an SysV derivative in some ways).

I agree hpux is a hybrid.  Which is why I mentioned it, so it would be
a clue about what I was talking about.  I did not realize that Solaris
did not do that.  AIX neither does it place /usr/local/bin in the rsh
path.

> In Solaris you can change the default PATH by either updating one of
> the shell init scripts or chaning PATH in /etc/default/login to do it
> in a shell independant way.

On AIX, PATH and other variables are set in /etc/environment.  HPUX
has /etc/PATH.  Solaris has /etc/default/login.  Hmm... Wish there was
a consistent interface to this.  And on none of those systems do I
know of an easy way to localize it for ssh since usually those are all
read at interative shell startup by /etc/profile and not on
non-interactive shell startup when ssh runs.

Bob


From harvell at aol.net  Fri Oct 26 15:38:26 2001
From: harvell at aol.net (Brian Harvell)
Date: Fri, 26 Oct 2001 01:38:26 -0400 (EDT)
Subject: Default $PATH of rsh (Was Re: What risk is X11Forward to a
 server?)
In-Reply-To: <200110260502.f9Q52Hf06966@torment.proulx.com>
Message-ID: <Pine.GSO.4.40.0110260130450.825-100000@boondoggle.office.aol.com>

On Thu, 25 Oct 2001, Bob Proulx wrote:

> On AIX, PATH and other variables are set in /etc/environment.  HPUX
> has /etc/PATH.  Solaris has /etc/default/login.  Hmm... Wish there was
> a consistent interface to this.  And on none of those systems do I
> know of an easy way to localize it for ssh since usually those are all
> read at interative shell startup by /etc/profile and not on
> non-interactive shell startup when ssh runs.
>

Reads /etc/default/login if detected during compile (ie Solaris)
Reads $sysconfdir/environment all the time if it's there.
Adding checks for other OS's is left as an exercise for the reader.

fyi if you want to use you will also need autoconf to rebuild configure. It's
also had limited testing since I just wrote it.

Brian

Brian Harvell                harvell at aol.net             http://ToolBoy.com/
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc



--------------------------------cut-----------------------------------------
diff -uNr openssh-2.9.9p2.orig/acconfig.h openssh-2.9.9p2/acconfig.h
--- openssh-2.9.9p2.orig/acconfig.h	Thu Sep 20 15:43:41 2001
+++ openssh-2.9.9p2/acconfig.h	Fri Oct 26 01:19:03 2001
@@ -236,6 +236,9 @@
 /* to pam_strerror */
 #undef HAVE_OLD_PAM

+/* Define if you have /etc/default/login to set default environment */
+#undef HAVE_ETC_DEFAULT_LOGIN
+
 /* Define if you are using Solaris-derived PAM which passes pam_messages  */
 /* to the conversation function with an extra level of indirection */
 #undef PAM_SUN_CODEBASE
diff -uNr openssh-2.9.9p2.orig/config.h.in openssh-2.9.9p2/config.h.in
--- openssh-2.9.9p2.orig/config.h.in	Tue Sep 25 18:50:32 2001
+++ openssh-2.9.9p2/config.h.in	Fri Oct 26 01:19:03 2001
@@ -236,6 +236,9 @@
 /* to pam_strerror */
 #undef HAVE_OLD_PAM

+/* Define if you have /etc/default/login to set default environment */
+#undef HAVE_ETC_DEFAULT_LOGIN
+
 /* Define if you are using Solaris-derived PAM which passes pam_messages  */
 /* to the conversation function with an extra level of indirection */
 #undef PAM_SUN_CODEBASE
diff -uNr openssh-2.9.9p2.orig/configure.in openssh-2.9.9p2/configure.in
--- openssh-2.9.9p2.orig/configure.in	Tue Sep 25 18:39:38 2001
+++ openssh-2.9.9p2/configure.in	Fri Oct 26 01:19:03 2001
@@ -159,6 +159,13 @@
 	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
 	LDFLAGS="$LDFLAGS -L/usr/local/lib -R/usr/local/lib"
 	need_dash_r=1
+	AC_MSG_CHECKING(for /etc/default/login)
+	if test -f /etc/default/login; then
+		AC_DEFINE(HAVE_ETC_DEFAULT_LOGIN)
+		AC_MSG_RESULT(yes)
+	else
+		AC_MSG_RESULT(no)
+	fi
 	AC_DEFINE(PAM_SUN_CODEBASE)
 	AC_DEFINE(LOGIN_NEEDS_UTMPX)
 	AC_DEFINE(LOGIN_NEEDS_TERM)
diff -uNr openssh-2.9.9p2.orig/session.c openssh-2.9.9p2/session.c
--- openssh-2.9.9p2.orig/session.c	Sun Sep 16 18:17:15 2001
+++ openssh-2.9.9p2/session.c	Fri Oct 26 01:28:15 2001
@@ -1283,10 +1283,17 @@
 		child_set_env(&env, &envsize, "KRB5CCNAME",
 		    s->authctxt->krb5_ticket_file);
 #endif
+#ifdef HAVE_ETC_DEFAULT_LOGIN
+	/* Add system defaults to environment. */
+	read_environment_file(&env, &envsize, "/etc/default/login");
+#endif
 #ifdef USE_PAM
 	/* Pull in any environment variables that may have been set by PAM. */
 	do_pam_environment(&env, &envsize);
 #endif /* USE_PAM */
+	/* Add ssh specific environment */
+	snprintf(buf, sizeof buf, "%.200s/environment", ETCDIR);
+	read_environment_file(&env, &envsize, buf);

 	if (auth_get_socket_name() != NULL)
 		child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME,

--------------------------------cut-----------------------------------------



From Alexander.Dost at drkw.com  Fri Oct 26 17:09:06 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Fri, 26 Oct 2001 09:09:06 +0200
Subject: PAM conversation stuff
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC01@ibfftc0006.is.de.dresdnerkb.com>

Just to start a new thread in this discussion...
As I asked before, when using an interactive session (plain simple 'ssh
<host>'), and the prompt for changing the password appears, this stuff comes
out of the PAM library, right ?
So the problem that the password (login password first) now entered is
non-hidden on the screen comes from PAM, not from ssh ?
And why does the password-expiration checking work only with the
PAM_TTY_KLUDGE ? If I understood the whole thing, this kludge should only be
activated in conjunction with non-interactive sessions. But without it ssh
(2.9.9p2 on Sol8) just closes the connection without any hint to the expired
password...

- Alex



From markus at openbsd.org  Fri Oct 26 17:51:33 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 09:51:33 +0200
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025212100.D5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Oct 25, 2001 at 09:21:02PM -0400
References: <20011025152522.C26615@wdr.com> <20011025231228.B29515@folly> <20011025212100.D5739@sm2p1386swk.wdr.com>
Message-ID: <20011026095133.A7702@faui02.informatik.uni-erlangen.de>

On Thu, Oct 25, 2001 at 09:21:02PM -0400, Nicolas Williams wrote:
> 1. my patch doesn't really fix the race -- signal blocking is needed for
>    that. Sigh.

i would prefer patches against the recent snapshot to
patches against 2.9 or 2.9.9, since there are several
changes related to this part of the code.


From markus at openbsd.org  Fri Oct 26 17:52:57 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 09:52:57 +0200
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025212100.D5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Oct 25, 2001 at 09:21:02PM -0400
References: <20011025152522.C26615@wdr.com> <20011025231228.B29515@folly> <20011025212100.D5739@sm2p1386swk.wdr.com>
Message-ID: <20011026095257.B7702@faui02.informatik.uni-erlangen.de>

On Thu, Oct 25, 2001 at 09:21:02PM -0400, Nicolas Williams wrote:
> 2. I think the normal expectation is that when there are no more open
>    sessions or channels or children that sshd should exit. The opposite
>    ought to be an option. IMHO

for protocol v2 the client decides when to close the connection.


From wpilorz at bdk.pl  Fri Oct 26 18:53:01 2001
From: wpilorz at bdk.pl (Wojtek Pilorz)
Date: Fri, 26 Oct 2001 10:53:01 +0200 (CEST)
Subject: status of the hang-on-exit-bug 
In-Reply-To: <200110231806.f9NI6GC26057@aether.phys.cwru.edu>
Message-ID: <Pine.LNX.4.21.0110261031090.5064-100000@celebris.bdk.pl>

On Tue, 23 Oct 2001, Craig J Copi wrote:

> Date: Tue, 23 Oct 2001 14:06:16 -0400
> From: Craig J Copi <cjc5 at po.cwru.edu>
> To: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: status of the hang-on-exit-bug 
> 
> Lutz Jaenicke writes:
> >- Even more: on OpenBSD the connection is closed immediatly. Doesn't this
> >  mean, that output generated by the backgrounded processes after the
> >  close would be lost, thus violating the idea of keeping the channel
> >  open to prevent this data loss...
> 
> I believe it does mean that data is lost.  I did the following 
> simple test:
> #>ssh localhost
> [ Login ]
> %> sleep 10; echo hi &
> %> exit
> 
> I did this on
> (1) OpenBSD 2.9 with OpenSSH_2.9 and tcsh-6.10.00 (from ports)
> (2) Linux 2.4.6 with OpenSSH_2.9.9p2 and tcsh-6.10-5 (RH 7.1)
> 
> On the OpenBSD box (1) the exit was immediate.  "hi" WAS NOT printed.
> On the Linux box (2) the exit hung, after the delay "hi" WAS printed
>   then the exit finished.
> 
> Craig
> 
Craig made a very good point here.
I believe the user should be given a choice;

Let me explain with an example first:
Assume a user logs in to another machine interactively using ssh;
At some point (s)he runs a process in the background;
The process can issue some error messages to stdout/stderr, so redirecting
them to /dev/null is not a good idea. And the process can run for many
hours, so the user would want to be able to shut down his workstation and
accept the risk that error messages which did not show soon after start of
the process would be lost.

So I believe the current behaviour on Linux is consistent with the
requirement that data should never be lost, while behaviour on OpenBSD is
not;
Also, I believe that user should be able to conveniently request unsafe
behaviour of allowing data loss from processes run in the background which
have open std*, both for interactive and non-interactive sessions.

I think that an option allowStdxDataLoss={yes,no,ask}
would be a good idea (of course with a much shorter name);
Also, not allowing such option within ssh configuration files might be a
good idea to prevent making unsafe behaviour a silent default on any
system (and then 'my data was lost' complaints).
Also, after escape character is pressed, there might be a command to
inquiry and change state of that option in case user changes her/his mind
during the session.

Best regards,

Wojtek
--------------------
Wojtek Pilorz
Wojtek.Pilorz at bdk.pl




From wpilorz at bdk.pl  Fri Oct 26 19:45:57 2001
From: wpilorz at bdk.pl (Wojtek Pilorz)
Date: Fri, 26 Oct 2001 11:45:57 +0200 (CEST)
Subject: Another round of testing calls.
In-Reply-To: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.21.0110261132400.5064-100000@celebris.bdk.pl>

On Tue, 23 Oct 2001 mouring at etoh.eviladmin.org wrote:

> Date: Tue, 23 Oct 2001 11:25:52 -0500 (CDT)
> From: mouring at etoh.eviladmin.org
> To: openssh-unix-dev at mindrot.org
> Subject: Another round of testing calls.
> 
> 
> Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE'
> required.  *WHAT* other issues *MUST* be address before 3.0 which is
> approaching fast?
> 
> Those running NeXTStep I need conformation that it works under NeXT.  My
> current Slab is packed in a storage unit due to a fire in my apartment
> complex (happened above me so I'm wrapping up dealing with that crap =).
> 
> - Ben
> 

Forgive me if this is stupid, but the following quote from WARNING.RNG
made me wondering whether DSA/DSS could be disabled from SSH:

A particularly pernicious problem arises with DSA keys (used by the
ssh2 protocol). Performing a DSA signature (which is required for
authentication), entails the use of a 160 bit random number.  If an
attacker can predict this number, then they can deduce your *private*
key and impersonate you or your hosts.

I am esp. worried about the systems without kernel supply of strong random
numbers.

So is it possible to disable all use of DSA, or does protocol v2 requires it?
If it is possible, is that enough to set HostKeyAlgorithms to ssh-rsa alone
on client, and remove dsa keys on server,
or should we have a compile-time option to remove DSA code from ssh/sshd?

Best regards,

Wojtek
--------------------
Wojtek Pilorz
Wojtek.Pilorz at bdk.pl




From Florian.Weimer at RUS.Uni-Stuttgart.DE  Fri Oct 26 20:23:10 2001
From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer)
Date: 26 Oct 2001 12:23:10 +0200
Subject: MAXHOSTNAMELEN and Solaris 2.5
Message-ID: <tgzo6ewvht.fsf@mercury.rus.uni-stuttgart.de>

Solaris 2.5 does not seem to define MAXHOSTNAMELEN, and a compilation
of vanilla OpenSSH 2.9.9p2 fails:

> gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.
> -I/usr/local/ssl/include  -I/usr/local/include
> -DETCDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
> -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\"
> -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"
> -D_PATH_SSH_PIDDIR=\"/usr/local/etc\" -DHAVE_CONFIG_H -c channels.c
> channels.c: In function `x11_create_display_inet':
> channels.c:2396: `MAXHOSTNAMELEN' undeclared (first use in this
> function)
> channels.c:2396: (Each undeclared identifier is reported only once
> channels.c:2396: for each function it appears in.)
> channels.c:2468: warning: implicit declaration of function `gethostname'
> 
> channels.c:2396: warning: unused variable `hostname'
> make: *** [channels.o] Error 1

-- 
Florian Weimer 	                  Florian.Weimer at RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From Christopher.Walker at team.telstra.com  Fri Oct 26 09:40:17 2001
From: Christopher.Walker at team.telstra.com (Walker, Christopher)
Date: Fri, 26 Oct 2001 09:40:17 +1000
Subject: ageing passwords
Message-ID: <8F57BB7F31A6D311A2590008C724DDFB04410F06@ntmsg0056.corpmail.telstra.com.au>

hello.

I have recently complied openssh-2.9.9p2 on one of our Solaris boxes (an
E250) which is running Solaris 2.6.

we are using ageing passwords and have noticed that when prompted to change
an expired password, the passwords entered are echoed to the screen rather
than hidden.


Regards,

Chris Walker
Telstra
Internetworking Solutions
Ph: 07 3887 7358 Mob: 0417722751
Email: Christopher.Walker at team.telstra.com

The information contained in this e-mail is confidential. It is only
intended for the recipient/s named above. If you are not the intended or one
of the intended recipient/s any unauthorised use is prohibited. If you have
received this e-mail in error, please notify the sender so that arrangements
can be made for its retrieval or destruction. Confidentiality and legal
privilege are not waived or lost as a result of mistaken delivery. 
Telstra Corporation Limited (ABN 33 051 775 556) .




From markus at openbsd.org  Fri Oct 26 22:11:13 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 14:11:13 +0200
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.LNX.4.33.0110261013040.2060-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 26, 2001 at 10:14:21AM +1000
References: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu> <Pine.LNX.4.33.0110261013040.2060-100000@mothra.mindrot.org>
Message-ID: <20011026141113.A7306@folly>

On Fri, Oct 26, 2001 at 10:14:21AM +1000, Damien Miller wrote:
> On Thu, 25 Oct 2001, Ed Phillips wrote:
> 
> > What is the reasoning behind this?  Do we want to see a lastlog entry for
> > "ssh" whenever a user runs remote command?  Do other OSes have
> > pam_open_session that does more meaningful things than Solaris 8?
> > Well...  I guess the more I think about it, it's probably better to go
> > ahead an call pam_open_session even for the non-interactive case since
> > someone might want to implement a PAM module at their site that logs every
> > ssh connection... and if we don't call pam_open_session, then they don't
> > even have that capability if they wanted it.
> 
> Some people set rlimits using session modules. Someone even filed a Bugtraq
> report about it.

is this the right way?

isn't this an abuse of the PAM module? (perhaps file a Bugtraq report...)


From markus at openbsd.org  Fri Oct 26 22:14:07 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 14:14:07 +0200
Subject: Another round of testing calls.
In-Reply-To: <Pine.LNX.4.21.0110261132400.5064-100000@celebris.bdk.pl>; from wpilorz@bdk.pl on Fri, Oct 26, 2001 at 11:45:57AM +0200
References: <Pine.BSO.4.33.0110231118110.11173-100000@etoh.eviladmin.org> <Pine.LNX.4.21.0110261132400.5064-100000@celebris.bdk.pl>
Message-ID: <20011026141407.B7306@folly>

On Fri, Oct 26, 2001 at 11:45:57AM +0200, Wojtek Pilorz wrote:
> A particularly pernicious problem arises with DSA keys (used by the
> ssh2 protocol). Performing a DSA signature (which is required for
> authentication), entails the use of a 160 bit random number.  If an
> attacker can predict this number, then they can deduce your *private*
> key and impersonate you or your hosts.

don't generate a DSA hostkey if you care about this.


From eddygeez at yahoo.com  Fri Oct 26 22:36:50 2001
From: eddygeez at yahoo.com (Eddy Geez)
Date: Fri, 26 Oct 2001 05:36:50 -0700 (PDT)
Subject: Clean way to monitor status of 'sshd' remotely?
Message-ID: <20011026123650.24707.qmail@web9604.mail.yahoo.com>

I am trying to come up with a "clean" way to check if a machine
is running 'sshd' so it can be included in a NetSaint config.
Currently, there is a NetSaint plugin called "check_ssh", but
it simply connects to port 22, looks for the SSH version response
from the daemon, and then disconnects. This results in the
syslog file where "auth" messages are sent in filling up with
messages like:

  sshd[21795]: Connection closed by 192.168.192.168

every 5 minutes (or whatever the "check" interval is).

I've tried searching for others who have run into this situation,
but have been unable to find anything either in these archives or
in Google's UseNet archives.

I've also looked at the 'sshd.c' source code, and don't see anything
obvious that would easily permit a monitoring tool to close the SSH
connection "properly" and avoid a log-file entry.

Does anybody have any suggestions? (Besides disabling logging at
the .info level, which is useful for other messages.)

Thanks for any insight!
Eddy


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From ed at UDel.Edu  Fri Oct 26 23:11:06 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 09:11:06 -0400 (EDT)
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011025231228.B29515@folly>
Message-ID: <Pine.SOL.4.30.0110260909290.19505-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Markus Friedl wrote:

> Date: Thu, 25 Oct 2001 23:12:28 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: SIGCHLD race *trivial* patch
>
> On Thu, Oct 25, 2001 at 03:25:22PM -0400, Nicolas Williams wrote:
> >       if (!channel_still_open())
> >               max_time_milliseconds = 1000;
>
> there are no channels when a client authenticates.
>
> just try ssh -N
>
> >
> >    Added this bit of code to server_loop2():
> >
> >                 if (child_terminated) {
> >                         while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
> >                                 session_close_by_pid(pid, status);
> > -                       child_terminated = 0;
> > +                       if (session_still_used())
> > +                               child_terminated = 0;
> > +                    if (child_terminated && !channel_still_open())
> > +                       break;
> 			^^^^^
> you cannot break. the client decides when the connection gets closed.
>
> i think it could still request another login shell.
>
> but yes, the SIGCLD races could be fixed with a select timeout.
>
> but that's ugly. perhaps using siglongjmp is less ugly
> and even portable.

siglongjmp?  Talk about ugly... ;-P

Off the cuff... how about alarm() + handler?  Is that more portable than
select() with a
timeout?

	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  Fri Oct 26 23:14:04 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 09:14:04 -0400 (EDT)
Subject: What risk is X11Forward to a server?
In-Reply-To: <200110252249.f9PMnPa06579@torment.proulx.com>
Message-ID: <Pine.SOL.4.30.0110260911530.19505-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Bob Proulx wrote:

> Date: Thu, 25 Oct 2001 16:49:25 -0600
> From: Bob Proulx <bob at proulx.com>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Jim Knoble <jmknoble at pobox.com>, openssh-unix-dev at mindrot.org,
>      Dave Dykstra <dwd at bell-labs.com>
> Subject: Re: What risk is X11Forward to a server?
>
> > That brings up a quick question I forgot...
> >
> > How do you change the compiled-in PATH that sshd uses by default?
>
> I don't think it is currently possible.  That is one thing that I have
> really needed/wanted with ssh.  The ability to set the PATH in the
> site sshd_config file.
>
> Traditionally the rsh command (as implemented on SysV systems such as
> hpux which is where my experience comes from) implements
> /usr/local/bin:/usr/bin:/bin, etc., the operative directory being
> /usr/local/bin.  But openssh does not.  Which means I always need to
> recompile with a that path addition in order to make it compatible
> with rsh on our systems.  And that really makes sense.  I don't want
> to have to include the full path to a command in scripts.  But does
> not completely solve the problem because even that does not handle
> nonstandard path locations.

Yeah... and on Solaris there is the /etc/default/login PATH setting...
which login and other apps honor, but not sshd.  Maybe someone could make
sshd honor that in Solaris?  I'm not sure what that would entail but it
sounds easy in concept...

> I would really like to see /usr/local/bin/ added to the default build.
> But I realize that it is a system dependent value.  I don't think it
> is possible to implement a one size fits all value.  The best answer
> would probably be a way to configure this in the sshd_config file.  It
> is high on my wishlist.

Yes... the sshd_config file would be a good place for setting the default
PATH IMO.  It's something that you can distribute with stock values and
then customize it on particular systems.

	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  Fri Oct 26 23:22:44 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 09:22:44 -0400 (EDT)
Subject: What risk is X11Forward to a server?
In-Reply-To: <20011025182317.A24978@HiWAAY.net>
Message-ID: <Pine.SOL.4.30.0110260921531.19505-100000@mahler.udel.edu>

On Thu, 25 Oct 2001, Chris Adams wrote:

> Date: Thu, 25 Oct 2001 18:23:17 -0500
> From: Chris Adams <cmadams at hiwaay.net>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: What risk is X11Forward to a server?
>
> Once upon a time, Ed Phillips <ed at UDel.Edu> said:
> > How do you change the compiled-in PATH that sshd uses by default?
>
> AFAIK it can only be changed at compile time.

Actually, that's what I was looking to change, since there is no
sshd_config parm to change it.  Where do I change it in the source before
compiling?

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  Fri Oct 26 23:28:00 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 15:28:00 +0200
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <Pine.SOL.4.30.0110260909290.19505-100000@mahler.udel.edu>; from ed@UDel.Edu on Fri, Oct 26, 2001 at 09:11:06AM -0400
References: <20011025231228.B29515@folly> <Pine.SOL.4.30.0110260909290.19505-100000@mahler.udel.edu>
Message-ID: <20011026152800.A7764@faui02.informatik.uni-erlangen.de>

On Fri, Oct 26, 2001 at 09:11:06AM -0400, Ed Phillips wrote:
> Off the cuff... how about alarm() + handler?  Is that more portable than
> select() with a
> timeout?

? we do already call select().


From dwd at bell-labs.com  Fri Oct 26 23:28:06 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 26 Oct 2001 08:28:06 -0500
Subject: What risk is X11Forwarding to a server?
In-Reply-To: <Pine.LNX.4.33.0110261028270.2060-100000@mothra.mindrot.org>; from djm@mindrot.org on Fri, Oct 26, 2001 at 10:28:55AM +1000
References: <20011025142357.A2299@lucent.com> <Pine.LNX.4.33.0110261028270.2060-100000@mothra.mindrot.org>
Message-ID: <20011026082806.A16350@lucent.com>

On Fri, Oct 26, 2001 at 10:28:55AM +1000, Damien Miller wrote:
> On Thu, 25 Oct 2001, Dave Dykstra wrote:
> 
> > Why, then, doesn't OpenSSH set X11Forwarding=yes by default on the server?
> 
> As Markus said - this has been discussed before, check the archives.

Ok, I tried to search the archives and didn't come up with any relevant
discussion.  Can somebody please help me out and tell me where it is?

Thanks,

- Dave Dykstra


From ed at UDel.Edu  Fri Oct 26 23:33:36 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 09:33:36 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.LNX.4.33.0110261023090.2060-100000@mothra.mindrot.org>
Message-ID: <Pine.SOL.4.30.0110260930500.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Damien Miller wrote:

> Date: Fri, 26 Oct 2001 10:23:32 +1000 (EST)
> From: Damien Miller <djm at mindrot.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Markus Friedl <markus at openbsd.org>,
>      Darren Moffat <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
> On Thu, 25 Oct 2001, Ed Phillips wrote:
>
> > On Thu, 25 Oct 2001, Markus Friedl wrote:
> >
> > > Date: Thu, 25 Oct 2001 15:54:10 +0200
> > > From: Markus Friedl <markus at openbsd.org>
> > > To: Ed Phillips <ed at UDel.Edu>
> > > Cc: Damien Miller <djm at mindrot.org>,
> > >      Darren Moffat <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> > > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> > >
> > > On Thu, Oct 25, 2001 at 09:47:40AM -0400, Ed Phillips wrote:
> > > > Do we want to see a lastlog entry for
> > > > "ssh" whenever a user runs remote command?
> > >
> > > no.
> >
> > Well, that's what happens when you call pam_open_session with TTY set to
> > "NODEVssh"... ;-)
>
> Only because you have a pam_lastlog session module.

On Solaris, by default, with pam_unix.so, and that's the only session
module that comes stock AFAIK.

Anyway, even Sun's apps that don't have a tty (like in.ftpd) set PAM_TTY
to something like "sshd<pid>", so who are we to argue... ;-)

	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 Nicolas.Williams at ubsw.com  Fri Oct 26 23:32:44 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 09:32:44 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <200110252009.f9PK9cuI409165@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Thu, Oct 25, 2001 at 01:09:39PM -0700
References: <200110252009.f9PK9cuI409165@jurassic.eng.sun.com>
Message-ID: <20011026093242.E5739@sm2p1386swk.wdr.com>

Clearly. I'd like a utility library for use elsewhere, as discussed
recently on the Linux-PAM list.

On Thu, Oct 25, 2001 at 01:09:39PM -0700, Darren Moffat wrote:
> >Mind you, one could use a new PAM item named PAM_ASK_ITEM instead of an
> >environment variable for configuring the PAM equivalent of SSH_ASKPASS.
> >But I'm not asking for that either.
> 
> We already have that it is the conversation function.
> 
> --
> Darren J Moffat
--

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  Fri Oct 26 23:35:50 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 09:35:50 -0400
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <20011026141113.A7306@folly>; from markus@openbsd.org on Fri, Oct 26, 2001 at 02:11:13PM +0200
References: <Pine.SOL.4.30.0110250940050.12864-100000@mahler.udel.edu> <Pine.LNX.4.33.0110261013040.2060-100000@mothra.mindrot.org> <20011026141113.A7306@folly>
Message-ID: <20011026093549.G5739@sm2p1386swk.wdr.com>

On Fri, Oct 26, 2001 at 02:11:13PM +0200, Markus Friedl wrote:
> On Fri, Oct 26, 2001 at 10:14:21AM +1000, Damien Miller wrote:
> > On Thu, 25 Oct 2001, Ed Phillips wrote:
> > 
> > > What is the reasoning behind this?  Do we want to see a lastlog entry for
> > > "ssh" whenever a user runs remote command?  Do other OSes have
> > > pam_open_session that does more meaningful things than Solaris 8?
> > > Well...  I guess the more I think about it, it's probably better to go
> > > ahead an call pam_open_session even for the non-interactive case since
> > > someone might want to implement a PAM module at their site that logs every
> > > ssh connection... and if we don't call pam_open_session, then they don't
> > > even have that capability if they wanted it.
> > 
> > Some people set rlimits using session modules. Someone even filed a Bugtraq
> > report about it.
> 
> is this the right way?

It's *a* right way.

> isn't this an abuse of the PAM module? (perhaps file a Bugtraq report...)

Why would it be?

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  Fri Oct 26 23:34:21 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 09:34:21 -0400
Subject: SIGCHLD race *trivial* patch
In-Reply-To: <20011026095257.B7702@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Fri, Oct 26, 2001 at 09:52:57AM +0200
References: <20011025152522.C26615@wdr.com> <20011025231228.B29515@folly> <20011025212100.D5739@sm2p1386swk.wdr.com> <20011026095257.B7702@faui02.informatik.uni-erlangen.de>
Message-ID: <20011026093420.F5739@sm2p1386swk.wdr.com>

On Fri, Oct 26, 2001 at 09:52:57AM +0200, Markus Friedl wrote:
> On Thu, Oct 25, 2001 at 09:21:02PM -0400, Nicolas Williams wrote:
> > 2. I think the normal expectation is that when there are no more open
> >    sessions or channels or children that sshd should exit. The opposite
> >    ought to be an option. IMHO
> 
> for protocol v2 the client decides when to close the connection.

Well, that's not the behaviour I see with OpenSSH 2.9p2!

And as I say, I think there should be an option either way.

Most folk expect ssh to exit as soon as all the work is done on the
server side.

Nico
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



From Nicolas.Williams at ubsw.com  Fri Oct 26 23:38:06 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 09:38:06 -0400
Subject: PAM conversation stuff
In-Reply-To: <Pine.SOL.4.30.0110251741440.12864-100000@mahler.udel.edu>; from ed@UDel.Edu on Thu, Oct 25, 2001 at 05:51:20PM -0400
References: <Pine.SOL.4.30.0110251741440.12864-100000@mahler.udel.edu>
Message-ID: <20011026093805.H5739@sm2p1386swk.wdr.com>

See the Linux-PAM, XSSO and Sun PAM docs here:

http://www.kernel.org/pub/linux/libs/pam/

and here:

http://docs.sun.com/

Nico


On Thu, Oct 25, 2001 at 05:51:20PM -0400, Ed Phillips wrote:
> Okay, I'm confused again.  They way you guys are talking about the
> conversation routine, it would seem that you think it is a way to fetch
> something from the user - like a new password.  Is this possible?  Does
> calling pam_chauthtok() cause the underlying pam_sm_chauthtok()
> eventually print something on stdout and read a new password from stdin
> (the socket to the client) using the conversation routine?  If this is
> what is happening, then logically the bug is in the part of the
> conversation routine that isn't checking to see if stdin/stdout is a TTY
> before trying to prompt the user for info.
> 
> Conversely, the conversation routine is just a glorified "printf", then
> where in the heck is the password read in, and where is pam_set_item()
> being called to fill in the details before the call to pam_chauthtok() can
> actually update the password?
> 
> 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
--
-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 mouring at etoh.eviladmin.org  Sat Oct 27 00:07:35 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 26 Oct 2001 09:07:35 -0500 (CDT)
Subject: PAM conversation stuff
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC01@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <Pine.BSO.4.33.0110260904490.12862-100000@etoh.eviladmin.org>


For non-interactive connections it should *NEVER* attempt a password
change, but it should notify the user for the reason of failure to
connect.

The problem is people wanted to have some PAM modules for setting limits,
etc apply to non-interactive session.  Which works fine under Linux, but
failure utterly under Solaris.

Moffat, there is a 'compatibility-a-thon' occuring soon.. Maybe there
should be a 'PAM' booth to get Linux, Sun, HP, etc all on the same page.
<grin>

- Ben

On Fri, 26 Oct 2001, Dost, Alexander wrote:

> Just to start a new thread in this discussion...
> As I asked before, when using an interactive session (plain simple 'ssh
> <host>'), and the prompt for changing the password appears, this stuff comes
> out of the PAM library, right ?
> So the problem that the password (login password first) now entered is
> non-hidden on the screen comes from PAM, not from ssh ?
> And why does the password-expiration checking work only with the
> PAM_TTY_KLUDGE ? If I understood the whole thing, this kludge should only be
> activated in conjunction with non-interactive sessions. But without it ssh
> (2.9.9p2 on Sol8) just closes the connection without any hint to the expired
> password...
>
> - Alex
>
>



From ed at UDel.Edu  Sat Oct 27 00:05:54 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 10:05:54 -0400 (EDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.LNX.4.33.0110261104090.2060-100000@mothra.mindrot.org>
Message-ID: <Pine.SOL.4.30.0110260950040.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Damien Miller wrote:

> Date: Fri, 26 Oct 2001 11:33:16 +1000 (EST)
> From: Damien Miller <djm at mindrot.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
> On Thu, 25 Oct 2001, Ed Phillips wrote:
>
> > However, I think a change should be made so that pam_chauthtok() is not
> > called if we don't have a real TTY.
>
> > Is there anything I'm missing?
>
> The fact that pam_chauthtok was never getting called without a tty
> anyway.  Look at the code path in session.c. The do_pam_chauthtok() call
> was only being made for the tty case.
>
> If there is a problem, it is that accounts with expired passwords were
> still able to execute commands. Please try the patch below for this.

Okay... that makes sense.  But, I thought the report was that when the
user did something like "ssh host ls" and the password needed to be
changed, it prompted for a password (over the non-tty-socket) and
displayed their new password in the clear as they typed it in (no tty =
password chars echo).

Oh well, maybe the guy who reported the echoed-password problem will speak
up... ;-)

	Ed


> Index: session.c
> ===================================================================
> RCS file: /var/cvs/openssh/session.c,v
> retrieving revision 1.154
> diff -u -r1.154 session.c
> --- session.c	2001/10/12 01:35:51	1.154
> +++ session.c	2001/10/26 01:30:29
> @@ -432,6 +432,9 @@
>  #if defined(USE_PAM)
>  	do_pam_session(s->pw->pw_name, NULL);
>  	do_pam_setcred(1);
> +	if (is_pam_password_change_required())
> +		packet_disconnect("Password change required but no "
> +		    "TTY available");
>  #endif /* USE_PAM */
>
>  	/* Fork the child. */
>

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  Sat Oct 27 00:08:31 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 10:08:31 -0400 (EDT)
Subject: What risk is X11Forward to a server?
In-Reply-To: <Pine.LNX.4.33.0110261133480.2060-100000@mothra.mindrot.org>
Message-ID: <Pine.SOL.4.30.0110261007200.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Damien Miller wrote:

> Date: Fri, 26 Oct 2001 11:34:16 +1000 (EST)
> From: Damien Miller <djm at mindrot.org>
> To: Bob Proulx <bob at proulx.com>
> Cc: Ed Phillips <ed at UDel.Edu>, Jim Knoble <jmknoble at pobox.com>,
>      openssh-unix-dev at mindrot.org, Dave Dykstra <dwd at bell-labs.com>
> Subject: Re: What risk is X11Forward to a server?
>
> On Thu, 25 Oct 2001, Bob Proulx wrote:
>
> > > That brings up a quick question I forgot...
> > >
> > > How do you change the compiled-in PATH that sshd uses by default?
> >
> > I don't think it is currently possible.  That is one thing that I have
> > really needed/wanted with ssh.  The ability to set the PATH in the
> > site sshd_config file.
>
> RTFM:
>
> configure --with-default-path=xxx

Duh... it couldn't have been that easy?  :-(

	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 Nicolas.Williams at ubsw.com  Sat Oct 27 00:16:05 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 10:16:05 -0400
Subject: SSHv2 sshd exit criteria
Message-ID: <20011026101603.I5739@sm2p1386swk.wdr.com>

When should sshd disconnect an SSHv2 connection?

Markus Friedl says "for protocol v2 the client decides when to close the
connection."

In principle, I agree, because SSHv2 supports multiple sessions over the
same connection, with the client able to launch new sessions anytime
then it should be upto the client.

But this would be a major cultural change for most users, and would
break any useage of SSHv2 for batch purposes.

So perhaps the sshd exit criteria ought to be defined.

I propose that, if the client never started any session other than the
default session, and if the session ended, and there are no more open
channels, then sshd should exit. But, if the client did open more than
one session, then sshd should not exit, even if there are no more
sessions in use and no more open channels. Fatal errors aside.

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 mstone at cs.loyola.edu  Sat Oct 27 00:19:33 2001
From: mstone at cs.loyola.edu (Michael Stone)
Date: Fri, 26 Oct 2001 10:19:33 -0400
Subject: Clean way to monitor status of 'sshd' remotely?
In-Reply-To: <20011026123650.24707.qmail@web9604.mail.yahoo.com>; from eddygeez@yahoo.com on Fri, Oct 26, 2001 at 05:36:50AM -0700
References: <20011026123650.24707.qmail@web9604.mail.yahoo.com>
Message-ID: <20011026101933.W7029@justice.loyola.edu>

On Fri, Oct 26, 2001 at 05:36:50AM -0700, Eddy Geez wrote:
> I've also looked at the 'sshd.c' source code, and don't see anything
> obvious that would easily permit a monitoring tool to close the SSH
> connection "properly" and avoid a log-file entry.

1) why on earth would it be a feature to have a mechanism that allows
one to connect to ssh without leaving a log entry. (seems like it would
offer a great way to do covert scans.)

2) how often do your sshd's disappear? is this actually something that
needs to be monitored?

-- 
Mike Stone


From Nicolas.Williams at ubsw.com  Sat Oct 27 00:25:18 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 10:25:18 -0400
Subject: PAM conversation stuff
In-Reply-To: <Pine.BSO.4.33.0110260904490.12862-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Fri, Oct 26, 2001 at 09:07:35AM -0500
References: <3E16581537ABE44EB18C5206CE79F26B89BC01@ibfftc0006.is.de.dresdnerkb.com> <Pine.BSO.4.33.0110260904490.12862-100000@etoh.eviladmin.org>
Message-ID: <20011026102516.J5739@sm2p1386swk.wdr.com>

On Fri, Oct 26, 2001 at 09:07:35AM -0500, mouring at etoh.eviladmin.org wrote:
> 
> For non-interactive connections it should *NEVER* attempt a password
> change, but it should notify the user for the reason of failure to
> connect.

Right. Alternatively, pam_chauthtok() can be called, and it can be left
to the conversation function to return an error to the modules'
pam_sm_chauthtok()s, causing pam_chauthtok() to fail.

> The problem is people wanted to have some PAM modules for setting limits,
> etc apply to non-interactive session.  Which works fine under Linux, but
> failure utterly under Solaris.

PAM_UNIX on Solaris was failing, not PAM as a whole. And there's a
simple workaround, namely to supply a bogus TTY when there is none.

> Moffat, there is a 'compatibility-a-thon' occuring soon.. Maybe there
> should be a 'PAM' booth to get Linux, Sun, HP, etc all on the same page.
> <grin>

Oh yes, absolutely. There's too much divergence now between the three,
and XSSO is underspecified. And PAM needs improvements anyways.

> - Ben
> 

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  Sat Oct 27 00:32:34 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 10:32:34 -0400
Subject: SSHv2 sshd exit criteria
In-Reply-To: <20011026101603.I5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Fri, Oct 26, 2001 at 10:16:05AM -0400
References: <20011026101603.I5739@sm2p1386swk.wdr.com>
Message-ID: <20011026103233.K5739@sm2p1386swk.wdr.com>

Oh, never mind. I think I just saw some light...

Yes, the client should be the one to decide that one session is all it
wanted, and the client finds out when that session ends, and the client
knows the status of each channel, so the client *can* choose.

So, never mind. My apologies for wasting your time, and bandwidth.

Nico


On Fri, Oct 26, 2001 at 10:16:05AM -0400, Nicolas Williams wrote:
> When should sshd disconnect an SSHv2 connection?
> 
> Markus Friedl says "for protocol v2 the client decides when to close the
> connection."
> 
> In principle, I agree, because SSHv2 supports multiple sessions over the
> same connection, with the client able to launch new sessions anytime
> then it should be upto the client.
> 
> But this would be a major cultural change for most users, and would
> break any useage of SSHv2 for batch purposes.
> 
> So perhaps the sshd exit criteria ought to be defined.
> 
> I propose that, if the client never started any session other than the
> default session, and if the session ended, and there are no more open
> channels, then sshd should exit. But, if the client did open more than
> one session, then sshd should not exit, even if there are no more
> sessions in use and no more open channels. Fatal errors aside.
> 
> 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.
--

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 dwd at bell-labs.com  Sat Oct 27 00:35:30 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 26 Oct 2001 09:35:30 -0500
Subject: Default $PATH of rsh (Was Re: What risk is X11Forward to a server?)
In-Reply-To: <Pine.GSO.4.40.0110260130450.825-100000@boondoggle.office.aol.com>; from harvell@aol.net on Fri, Oct 26, 2001 at 01:38:26AM -0400
References: <200110260502.f9Q52Hf06966@torment.proulx.com> <Pine.GSO.4.40.0110260130450.825-100000@boondoggle.office.aol.com>
Message-ID: <20011026093530.C2299@lucent.com>

On Fri, Oct 26, 2001 at 01:38:26AM -0400, Brian Harvell wrote:
> On Thu, 25 Oct 2001, Bob Proulx wrote:
> 
> > On AIX, PATH and other variables are set in /etc/environment.  HPUX
> > has /etc/PATH.  Solaris has /etc/default/login.  Hmm... Wish there was
> > a consistent interface to this.  And on none of those systems do I
> > know of an easy way to localize it for ssh since usually those are all
> > read at interative shell startup by /etc/profile and not on
> > non-interactive shell startup when ssh runs.
> >
> 
> Reads /etc/default/login if detected during compile (ie Solaris)

That file is not intended to be environment variables to set in the user's
process, it is intended to be parameters to the login program; it's not
sufficient to just read that file in.  SSH 1.2.27 has a big long
complicated function to read that file that looks for specific variables,
for example:

    1. set $PATH to the $SUPATH value if super user
    2. set the umask to the $UMASK value
    3. set $SHELL if and only if $ALTSHELL is set
    4. set $TZ if $TIMEZONE is set
    5. set the ulimit if $ULIMIT is set

> Reads $sysconfdir/environment all the time if it's there.

session.c is currently reading /etc/environment only on AIX.  I like
Brian's idea to always look for that in $sysconfdir.

- Dave Dykstra


From ed at UDel.Edu  Sat Oct 27 00:36:13 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 10:36:13 -0400 (EDT)
Subject: PAM conversation stuff
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC01@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <Pine.SOL.4.30.0110261033050.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Dost, Alexander wrote:

> Date: Fri, 26 Oct 2001 09:09:06 +0200
> From: "Dost, Alexander" <Alexander.Dost at drkw.com>
> To: 'Darren Moffat' <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> Subject: RE: PAM conversation stuff
>
> Just to start a new thread in this discussion...
> As I asked before, when using an interactive session (plain simple 'ssh
> <host>'), and the prompt for changing the password appears, this stuff comes
> out of the PAM library, right ?
> So the problem that the password (login password first) now entered is
> non-hidden on the screen comes from PAM, not from ssh ?

That's what I'm starting to think...

> And why does the password-expiration checking work only with the
> PAM_TTY_KLUDGE ? If I understood the whole thing, this kludge should only be
> activated in conjunction with non-interactive sessions. But without it ssh

It seems that PAM_TTY_KLUDGE is used to set PAM_TTY to some dummy value so
that pam_unix.so won't crash on Solaris.  However, I'd guess that the
PAM_TTY_KLUDGE could be moved to do_pam_session() and only call
pam_set_item() with the dummy tty if we in fact don't have a tty at that
time.

> (2.9.9p2 on Sol8) just closes the connection without any hint to the expired
> password...

Yes... that's the crash in pam_unix.so.

	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  Sat Oct 27 00:48:08 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 10:48:08 -0400 (EDT)
Subject: MAXHOSTNAMELEN and Solaris 2.5
In-Reply-To: <tgzo6ewvht.fsf@mercury.rus.uni-stuttgart.de>
Message-ID: <Pine.SOL.4.30.0110261046550.19505-100000@mahler.udel.edu>

MAXHOSTNAMELEN is defined in /usr/include/netdb.h on Solaris 2.5... maybe
that's not getting included in channels.c?

On 26 Oct 2001, Florian Weimer wrote:

> Date: 26 Oct 2001 12:23:10 +0200
> From: Florian Weimer <Florian.Weimer at RUS.Uni-Stuttgart.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: MAXHOSTNAMELEN and Solaris 2.5
>
> Solaris 2.5 does not seem to define MAXHOSTNAMELEN, and a compilation
> of vanilla OpenSSH 2.9.9p2 fails:
>
> > gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.
> > -I/usr/local/ssl/include  -I/usr/local/include
> > -DETCDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
> > -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\"
> > -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"
> > -D_PATH_SSH_PIDDIR=\"/usr/local/etc\" -DHAVE_CONFIG_H -c channels.c
> > channels.c: In function `x11_create_display_inet':
> > channels.c:2396: `MAXHOSTNAMELEN' undeclared (first use in this
> > function)
> > channels.c:2396: (Each undeclared identifier is reported only once
> > channels.c:2396: for each function it appears in.)
> > channels.c:2468: warning: implicit declaration of function `gethostname'
> >
> > channels.c:2396: warning: unused variable `hostname'
> > make: *** [channels.o] Error 1
>
> --
> Florian Weimer 	                  Florian.Weimer at RUS.Uni-Stuttgart.DE
> University of Stuttgart           http://cert.uni-stuttgart.de/
> RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
>

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  Sat Oct 27 00:48:54 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 16:48:54 +0200
Subject: SSHv2 sshd exit criteria
In-Reply-To: <20011026101603.I5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Fri, Oct 26, 2001 at 10:16:05AM -0400
References: <20011026101603.I5739@sm2p1386swk.wdr.com>
Message-ID: <20011026164854.A13420@faui02.informatik.uni-erlangen.de>

On Fri, Oct 26, 2001 at 10:16:05AM -0400, Nicolas Williams wrote:
> I propose that, if the client never started any session other than the
> default session, and if the session ended, and there are no more open
> channels, then sshd should exit.

been there, done that. but it's wrong.


From ed at UDel.Edu  Sat Oct 27 00:58:08 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 10:58:08 -0400 (EDT)
Subject: What risk is X11Forward to a server?
In-Reply-To: <Pine.SOL.4.30.0110260911530.19505-100000@mahler.udel.edu>
Message-ID: <Pine.SOL.4.30.0110261057060.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Ed Phillips wrote:

> Date: Fri, 26 Oct 2001 09:14:04 -0400 (EDT)
> From: Ed Phillips <ed at UDel.Edu>
> To: Bob Proulx <bob at proulx.com>
> Cc: Jim Knoble <jmknoble at pobox.com>, openssh-unix-dev at mindrot.org,
>      Dave Dykstra <dwd at bell-labs.com>
> Subject: Re: What risk is X11Forward to a server?
>
> On Thu, 25 Oct 2001, Bob Proulx wrote:
>
> > Date: Thu, 25 Oct 2001 16:49:25 -0600
> > From: Bob Proulx <bob at proulx.com>
> > To: Ed Phillips <ed at UDel.Edu>
> > Cc: Jim Knoble <jmknoble at pobox.com>, openssh-unix-dev at mindrot.org,
> >      Dave Dykstra <dwd at bell-labs.com>
> > Subject: Re: What risk is X11Forward to a server?
> >
> > > That brings up a quick question I forgot...
> > >
> > > How do you change the compiled-in PATH that sshd uses by default?
> >
> > I don't think it is currently possible.  That is one thing that I have
> > really needed/wanted with ssh.  The ability to set the PATH in the
> > site sshd_config file.
> >
> > Traditionally the rsh command (as implemented on SysV systems such as
> > hpux which is where my experience comes from) implements
> > /usr/local/bin:/usr/bin:/bin, etc., the operative directory being
> > /usr/local/bin.  But openssh does not.  Which means I always need to
> > recompile with a that path addition in order to make it compatible
> > with rsh on our systems.  And that really makes sense.  I don't want
> > to have to include the full path to a command in scripts.  But does
> > not completely solve the problem because even that does not handle
> > nonstandard path locations.
>
> Yeah... and on Solaris there is the /etc/default/login PATH setting...
> which login and other apps honor, but not sshd.  Maybe someone could make
> sshd honor that in Solaris?  I'm not sure what that would entail but it
> sounds easy in concept...
>
> > I would really like to see /usr/local/bin/ added to the default build.
> > But I realize that it is a system dependent value.  I don't think it
> > is possible to implement a one size fits all value.  The best answer
> > would probably be a way to configure this in the sshd_config file.  It
> > is high on my wishlist.
>
> Yes... the sshd_config file would be a good place for setting the default
> PATH IMO.  It's something that you can distribute with stock values and
> then customize it on particular systems.

Also, on Solaris, I'd like the default path to be taken from
/etc/default/login if it's not set in sshd_config (with this new feature).

	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  Sat Oct 27 01:01:28 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 11:01:28 -0400 (EDT)
Subject: What risk is X11Forwarding to a server?
In-Reply-To: <20011026082806.A16350@lucent.com>
Message-ID: <Pine.SOL.4.30.0110261100320.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Dave Dykstra wrote:

> Date: Fri, 26 Oct 2001 08:28:06 -0500
> From: Dave Dykstra <dwd at bell-labs.com>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: What risk is X11Forwarding to a server?
>
> On Fri, Oct 26, 2001 at 10:28:55AM +1000, Damien Miller wrote:
> > On Thu, 25 Oct 2001, Dave Dykstra wrote:
> >
> > > Why, then, doesn't OpenSSH set X11Forwarding=yes by default on the server?
> >
> > As Markus said - this has been discussed before, check the archives.
>
> Ok, I tried to search the archives and didn't come up with any relevant
> discussion.  Can somebody please help me out and tell me where it is?

See... responses like that ("go away, we've discussed that before") can
actually generate more list traffic than a simple, brief recap... ;-P

	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  Sat Oct 27 01:09:49 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 17:09:49 +0200
Subject: MAXHOSTNAMELEN and Solaris 2.5
In-Reply-To: <Pine.SOL.4.30.0110261046550.19505-100000@mahler.udel.edu>; from ed@UDel.Edu on Fri, Oct 26, 2001 at 10:48:08AM -0400
References: <tgzo6ewvht.fsf@mercury.rus.uni-stuttgart.de> <Pine.SOL.4.30.0110261046550.19505-100000@mahler.udel.edu>
Message-ID: <20011026170949.A15183@faui02.informatik.uni-erlangen.de>

On Fri, Oct 26, 2001 at 10:48:08AM -0400, Ed Phillips wrote:
> MAXHOSTNAMELEN is defined in /usr/include/netdb.h on Solaris 2.5... maybe
> that's not getting included in channels.c?

why not use grep?

i'd really prefer a list with less noise and code instead of talk.

since there is only talk, i can assume, that everything is fine and we
can release the current code.

if anyone wants to make a guess about this or that feature then i'd
like to ask you to check the current code. please don't speculate.


From markus at openbsd.org  Sat Oct 27 01:11:19 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 17:11:19 +0200
Subject: What risk is X11Forwarding to a server?
In-Reply-To: <20011026082806.A16350@lucent.com>; from dwd@bell-labs.com on Fri, Oct 26, 2001 at 08:28:06AM -0500
References: <20011025142357.A2299@lucent.com> <Pine.LNX.4.33.0110261028270.2060-100000@mothra.mindrot.org> <20011026082806.A16350@lucent.com>
Message-ID: <20011026171119.A21517@folly>

On Fri, Oct 26, 2001 at 08:28:06AM -0500, Dave Dykstra wrote:
> On Fri, Oct 26, 2001 at 10:28:55AM +1000, Damien Miller wrote:
> > On Thu, 25 Oct 2001, Dave Dykstra wrote:
> > 
> > > Why, then, doesn't OpenSSH set X11Forwarding=yes by default on the server?
> > 
> > As Markus said - this has been discussed before, check the archives.
> 
> Ok, I tried to search the archives and didn't come up with any relevant
> discussion.  Can somebody please help me out and tell me where it is?

ask Theo.


From Florian.Weimer at RUS.Uni-Stuttgart.DE  Sat Oct 27 01:24:21 2001
From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer)
Date: 26 Oct 2001 17:24:21 +0200
Subject: README and zlib
Message-ID: <tgsnc6v2ze.fsf@mercury.rus.uni-stuttgart.de>

The README file seems to refer to an old location of zlib.  The
current one seems to be:

        http://www.gzip.org/zlib/

-- 
Florian Weimer 	                  Florian.Weimer at RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From mouring at etoh.eviladmin.org  Sat Oct 27 01:42:51 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 26 Oct 2001 10:42:51 -0500 (CDT)
Subject: README and zlib
In-Reply-To: <tgsnc6v2ze.fsf@mercury.rus.uni-stuttgart.de>
Message-ID: <Pine.BSO.4.33.0110261042350.12862-100000@etoh.eviladmin.org>


Thanks, I've updated it.  It had already been corrected in the INSTALL
file.

- Ben

On 26 Oct 2001, Florian Weimer wrote:

> The README file seems to refer to an old location of zlib.  The
> current one seems to be:
>
>         http://www.gzip.org/zlib/
>
> --
> Florian Weimer 	                  Florian.Weimer at RUS.Uni-Stuttgart.DE
> University of Stuttgart           http://cert.uni-stuttgart.de/
> RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
>



From harvell at aol.net  Sat Oct 27 02:42:19 2001
From: harvell at aol.net (Brian Harvell)
Date: Fri, 26 Oct 2001 12:42:19 -0400 (EDT)
Subject: Default $PATH of rsh (Was Re: What risk is X11Forward to a
 server?)
In-Reply-To: <20011026093530.C2299@lucent.com>
Message-ID: <Pine.GSO.4.40.0110261234060.10108-100000@boondoggle.office.aol.com>

On Fri, 26 Oct 2001, Dave Dykstra wrote:

> > Reads /etc/default/login if detected during compile (ie Solaris)
>
> That file is not intended to be environment variables to set in the user's
> process, it is intended to be parameters to the login program; it's not
> sufficient to just read that file in.  SSH 1.2.27 has a big long
> complicated function to read that file that looks for specific variables,
> for example:

Yes I know it's not intended for that but what do you want for 10 mins
(including testing) of work :-) I was getting tired of all the jabberings and it
is the proper format and does work... The only negative side effect is it sets
a couple of useless env vars.

>     1. set $PATH to the $SUPATH value if super user
>     2. set the umask to the $UMASK value
>     3. set $SHELL if and only if $ALTSHELL is set
>     4. set $TZ if $TIMEZONE is set
>     5. set the ulimit if $ULIMIT is set

yes this would be the proper way to read it.

> > Reads $sysconfdir/environment all the time if it's there.
>
> session.c is currently reading /etc/environment only on AIX.  I like
> Brian's idea to always look for that in $sysconfdir.
>

yes I do too and I think it should be included in the src tree.

Brian


-- 

Brian Harvell                harvell at aol.net             http://ToolBoy.com/
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc



From Robert.Dahlem at siemens.com  Sat Oct 27 03:08:58 2001
From: Robert.Dahlem at siemens.com (Robert Dahlem)
Date: Fri, 26 Oct 2001 19:08:58 +0200
Subject: [PATCH] some patches for Fujitsu-Siemens ReliantUNIX
In-Reply-To: <200108201635.f7KGZVn09514@mail2.siemens.de>
Message-ID: <200110261711.f9QHBof02111@mail2.siemens.de>

Hi,

attached please find some patches against SNAP-20011026 for ReliantUNIX. 
This was tested under ReliantUNIX V5.43C40 with Compiler CDSDEV V2.0C00 
and works with other versions I have access to: 5.43C30, 5.44C20, 
5.45A10, 5.45A30, 5.45B00

I posted some patches like these in August but unfortunately they didn't 
make it into CVS. The configure patch is essential for ReliantUNIX, so 
please put it in. 

The /etc/default/login patch is some kind of convenience stuff and tries 
to follow the principle of always producing the least surprise: 
administrators of systems with /etc/default/login are used to change 
global (SU)PATH settings only there. If this one is not going to make it 
into the source: please tell me so and I will no longer bother anyone 
with this.

Here is what I did:

- there is a common misunderstanding of how to use /usr/libucb/libucb.a 
under ReliantUnix:

There are some library functions only in libucb.a under ReliantUNIX, so 
one needs to bind it. The problem is: there are some other functions in 
this library you should never bind from there (i.e. fopen()). The trick 
is to first search through libc.so and then through libucb.a. Don't let 
ld search in /usr/ucblib, it will virtually always produce nonsense.

- often found mistake with libsocket and libnsl under ReliantUNIX:

Especially libsocket _must_ be bound before libc. Otherwise you will get 
lots of messages like

    unix: syslog: 7784 sshd:_accept: SIOCGPGRP failed errno 22

- /etc/default/login

There is a file /etc/default/login on Solaris 2.x and ReliantUNIX. See

   http://docs.sun.com/ab2/coll.40.6/REFMAN1/@Ab2PageView/171170

for a description. It handles things like setting a different PATH for 
root and normal users at login time and the umask setting, quite a 
convenient feature for administrators.

This was handled in SSH 1 since at least 1998. I rewrote some of the old 
code to gather at least PATH and UMASK. Rest will be done at a later 
time (when I better understand the code :-).

I added a paranoia check to have always a minimum PATH set but take 
care! I fear this changed the semantics of --with-default-path.

Regards,
        Robert

BTW: Thanks to Markus for patching the "bad exit code 255" problem. I 
have been heavily bitten by this one. :-)


-- 
Robert.Dahlem at siemens.com
Siemens Business Services - FS CBS KORDOBA-Outsourcing
Tel: +49-69-797-6530  Fax: +49-69-797-6599
----------------------------------------------------------------------
Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email
software; far better than Outlook. Try it sometime.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 4691 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011026/a3852df3/attachment.obj 

From Robert.Dahlem at siemens.com  Sat Oct 27 03:19:47 2001
From: Robert.Dahlem at siemens.com (Robert Dahlem)
Date: Fri, 26 Oct 2001 19:19:47 +0200
Subject: Default $PATH of rsh (Was Re: What risk is X11Forward to a server?)
In-Reply-To: <Pine.GSO.4.40.0110261234060.10108-100000@boondoggle.office.aol.com>
Message-ID: <200110261722.f9QHMdf04423@mail2.siemens.de>

Hi,

On Fri, 26 Oct 2001 12:42:19 -0400 (EDT), Brian Harvell wrote:

>> > Reads /etc/default/login if detected during compile (ie Solaris)

Oops, what a coincidence: I posted a patch for this in August and (with 
some modifications) again some minutes ago.

>> That file is not intended to be environment variables to set in the 
>> user's process, it is intended to be parameters to the login program; 
>> it's not sufficient to just read that file in.  SSH 1.2.27 has a big 
>> long complicated function to read that file that looks for specific 
>> variables, for example:

>>     1. set $PATH to the $SUPATH value if super user

I already do this.

>>     2. set the umask to the $UMASK value

I already do this.

>>     3. set $SHELL if and only if $ALTSHELL is set

On my todo list.

>>     4. set $TZ if $TIMEZONE is set

Hm. The Solaris man page ist quiet about this, but under ReliantUNIX the 
man page reads like this:

     TIMEZONE                                                              
          The default value for TIMEZONE is defined in /etc/TIMEZONE
          [see timezone(4)]. To change the default time zone, use 
          /etc/TIMEZONE. Do not set TIMEZONE in /etc/default/login, as 
          this will override the value in /etc/TIMEZONE.


>>     5. set the ulimit if $ULIMIT is set

On my todo list.

>yes this would be the proper way to read it.

Thanks. :-)

Regards,
        Robert


-- 
Robert.Dahlem at siemens.com
Siemens Business Services - FS CBS KORDOBA-Outsourcing
Tel: +49-69-797-6530  Fax: +49-69-797-6599
----------------------------------------------------------------------
Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email
software; far better than Outlook. Try it sometime.




From mdb at juniper.net  Sat Oct 27 03:31:53 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 26 Oct 2001 10:31:53 -0700
Subject: minor problem in scard/Makefile when srcdir != objdir
Message-ID: <200110261731.f9QHVr081350@merlot.juniper.net>

Greetings,

There is a minor glitch when --src is not the same as the build tree
location (sometimes needed if you are going to be root for the install
and the sources are on an NFS disk somewhere that does not trust root
on the machine doing the install).

  % uname -a
  FreeBSD mdb-bsd.juniper.net 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Jan 17 12:03:49 PST 2001     root at mdb-bsd.juniper.net:/usr/obj/usr/src/sys/GENERIC  i386
  % make -f Makefile.in distprep
  % cd /some/local/disk
  % mkdir openssh-build
  % /path/to/openssh/configure --src=/path/to/openssh
  % make
  % sudo make install
  ...elided...
  (cd scard; make DESTDIR= install)
  uudecode Ssh.bin.uu
  uudecode: Ssh.bin.uu: No such file or directory
  *** Error code 1
  
  Stop in /some/local/disk/openssh-build/scard.
  *** Error code 1

The following patch works around the problem by assuming that Ssh.bin
must be found in the source distribution.

	Enjoy!
	-- Mark

Index: Makefile.in
===================================================================
RCS file: /cvs/openssh_cvs/scard/Makefile.in,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile.in
--- Makefile.in	2001/09/20 18:39:37	1.2
+++ Makefile.in	2001/10/26 17:39:24
@@ -22,6 +22,6 @@ distprep: Ssh.bin
 distclean: clean
 	rm -f Makefile *~
 
-install: Ssh.bin
+install: $(srcdir)/Ssh.bin
 	$(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir)
 	$(INSTALL) -m 0644 $(srcdir)/Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin


From Nicolas.Williams at ubsw.com  Sat Oct 27 03:36:31 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 13:36:31 -0400
Subject: One last time (Re: SIGCHLD race *trivial* patch)
In-Reply-To: <20011025212100.D5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Oct 25, 2001 at 09:21:02PM -0400
References: <20011025152522.C26615@wdr.com> <20011025231228.B29515@folly> <20011025212100.D5739@sm2p1386swk.wdr.com>
Message-ID: <20011026133630.L5739@sm2p1386swk.wdr.com>

One more time. The SIGCHLD race remains, which means that SSHv2 clients
don't always find out about the exiting of their sessions' lead
processes.

See below.

On Thu, Oct 25, 2001 at 09:21:02PM -0400, Nicolas Williams wrote:
> 
> 1. my patch doesn't really fix the race -- signal blocking is needed for
>    that. Sigh.

I take it that the BSD sigvec() interface is to be used?

If so, that'll require a compatibility shim for Solaris (which has a
sigvec in /usr/ucblib/libucb, but which I am not sure is useable w.
OpenSSH).

> 2. I think the normal expectation is that when there are no more open
>    sessions or channels or children that sshd should exit. The opposite
>    ought to be an option. IMHO

Never mind. It turns out that this should be a client side patch as the
client is told when its sessions end and it knows what channels are
open.

> 3. If sshd is to exit when (no more sessions && no more channels && no
>    more children) then either you must use a select() timeout, at least
>    when (no more sessions && no more channels), or sshd must use the
>    signal-handler-writes-to-a-pipe-whose-read-end-is-selected-for trick,
>    as described in the "SIGCHLD race condition race?" thread by Paul
>    Menage.

If sshd is to inform the client of ended sessions then it must reliably
catch SIGCHLD. That requires blocking.

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 tim at multitalents.net  Sat Oct 27 04:27:03 2001
From: tim at multitalents.net (Tim Rice)
Date: Fri, 26 Oct 2001 11:27:03 -0700 (PDT)
Subject: [PATCH] some patches for Fujitsu-Siemens ReliantUNIX, minor
 fixes and XXXes
In-Reply-To: <200108201635.f7KGZVn09514@mail2.siemens.de>
Message-ID: <Pine.UW2.4.40.9.0110221020280.8464-100000@uw711.int.multitalents.net>

On Mon, 20 Aug 2001, Robert Dahlem wrote:

> Hi,
>
> attached please find some patches for ReliantUNIX. This was tested under
> Reliant UNIX V5.43C40 with Compiler CDSDEV V2.0C00.
>
> Here is what I did:
>
> - there is a common misunderstanding how to use /usr/libucb/libucb.a:
>
> There are some library functions only in libucb.a under ReliantUNIX, so
> one needs to bind it. The problem is: there are some other functions in
> this library you should never bind from there (i.e. fopen()). The trick
> is to first search through libc.so and then through libucb.a. Don't let
> ld search in /usr/ucblib, it will virtually always produce nonsense.
>
I suspect you could remove the libucb stuff altogether and it would work.
Do you really need -ldl ?

Please try this patch.

-------------------------< cut here >------------------
--- configure.ac.old	Thu Oct 25 10:01:31 2001
+++ configure.ac	Fri Oct 26 11:24:05 2001
@@ -187,12 +187,11 @@
 	;;
 *-sni-sysv*)
 	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-	LDFLAGS="$LDFLAGS -L/usr/local/lib -L/usr/ucblib"
+	LDFLAGS="$LDFLAGS -L/usr/local/lib"
 	IPADDR_IN_DISPLAY=yes
 	AC_DEFINE(USE_PIPES)
 	AC_DEFINE(IP_TOS_IS_BROKEN)
 	AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H)
-	LIBS="$LIBS -lgen -lnsl -lucb"
 	;;
 *-*-sysv4.2*)
 	CPPFLAGS="$CPPFLAGS -I/usr/local/include"
-------------------------< end cut >------------------


-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From ed at UDel.Edu  Sat Oct 27 04:30:48 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 14:30:48 -0400 (EDT)
Subject: Expired passwords on Solaris with PAM
Message-ID: <Pine.SOL.4.30.0110261411260.19505-100000@mahler.udel.edu>

I've been doing so more tests with 2.9.9p2 on Sol8.  Here are my
finding so far:

When a user needs to change his password and trys to run a command in
non-interactive mode, it just succeeds without even trying to prompt the
user for a new password.  Damien submitted a fix - it works for me (is it
going into CVS?).

When a user needs to change his password and trys to login in interactive
mode, readpassphrase() gets called, but doesn't seem to be working
correctly on Sol8 - meaning, it doesn't correctly disable echo.  Would it
be possible to use getpass() on Solaris instead for the TTY case
(although, getpass() is not MT-Safe if that matters to anyone).  Any
ideas?

	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 Nicolas.Williams at ubsw.com  Sat Oct 27 04:58:08 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 14:58:08 -0400
Subject: Expired passwords on Solaris with PAM
In-Reply-To: <Pine.SOL.4.30.0110261411260.19505-100000@mahler.udel.edu>; from ed@UDel.Edu on Fri, Oct 26, 2001 at 02:30:48PM -0400
References: <Pine.SOL.4.30.0110261411260.19505-100000@mahler.udel.edu>
Message-ID: <20011026145807.M5739@sm2p1386swk.wdr.com>

Do not use getpass() on Solaris -- it crops the password it reads at 8
characters. Yes, it does.

Use getpassphrase() instead.

Nico


On Fri, Oct 26, 2001 at 02:30:48PM -0400, Ed Phillips wrote:
> I've been doing so more tests with 2.9.9p2 on Sol8.  Here are my
> finding so far:
> 
> When a user needs to change his password and trys to run a command in
> non-interactive mode, it just succeeds without even trying to prompt the
> user for a new password.  Damien submitted a fix - it works for me (is it
> going into CVS?).
> 
> When a user needs to change his password and trys to login in interactive
> mode, readpassphrase() gets called, but doesn't seem to be working
> correctly on Sol8 - meaning, it doesn't correctly disable echo.  Would it
> be possible to use getpass() on Solaris instead for the TTY case
> (although, getpass() is not MT-Safe if that matters to anyone).  Any
> ideas?
> 
> 	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
> 
--

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 ed at UDel.Edu  Sat Oct 27 05:08:29 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 15:08:29 -0400 (EDT)
Subject: Expired passwords on Solaris with PAM
In-Reply-To: <20011026145807.M5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.SOL.4.30.0110261503450.19505-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Nicolas Williams wrote:

> Date: Fri, 26 Oct 2001 14:58:08 -0400
> From: Nicolas Williams <Nicolas.Williams at ubsw.com>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Expired passwords on Solaris with PAM
>
> Do not use getpass() on Solaris -- it crops the password it reads at 8
> characters. Yes, it does.
>
> Use getpassphrase() instead.

Sure... we can use that, but I suggested getpass() because it exists in
older versions of Solaris - for exmple, getpassphrase() doesn't exist in
Solaris 2.5. :-( Of course, nobody runs THAT right?

Trucating to 8 characters would be bad after all, since ssh-keygen uses it
to read a passphrase for your secret key... which is NOT limited to 8
characters like one for Solaris login that as processed by crypt().

	Ed

>
> Nico
>
>
> On Fri, Oct 26, 2001 at 02:30:48PM -0400, Ed Phillips wrote:
> > I've been doing so more tests with 2.9.9p2 on Sol8.  Here are my
> > finding so far:
> >
> > When a user needs to change his password and trys to run a command in
> > non-interactive mode, it just succeeds without even trying to prompt the
> > user for a new password.  Damien submitted a fix - it works for me (is it
> > going into CVS?).
> >
> > When a user needs to change his password and trys to login in interactive
> > mode, readpassphrase() gets called, but doesn't seem to be working
> > correctly on Sol8 - meaning, it doesn't correctly disable echo.  Would it
> > be possible to use getpass() on Solaris instead for the TTY case
> > (although, getpass() is not MT-Safe if that matters to anyone).  Any
> > ideas?
> >
> > 	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
> >
> --
>
> 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.
>

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  Sat Oct 27 05:49:46 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 15:49:46 -0400 (EDT)
Subject: PAM session cleanup on Sol8 with v2.9.9p2
Message-ID: <Pine.SOL.4.30.0110261530570.2476-100000@mahler.udel.edu>

In do_pam_cleanup_proc(), there are 3 calls to PAM:

1) pam_close_session() - do lastlog stuff

2) pam_setcred(PAM_DELETE_CRED) - delete credentials

3) pam_end() - close PAM

It appears that pam_setcred() always fails with the error PAM_PERM_DENIED.
This is due to a check done pam_unix.so to not allow a caller with euid 0
to even try to delete their SECURE_RPC credentials.  When sshd calls
pam_setcred() to delete the credentials, evidentally, it is running with
euid 0, so the checks in pam_unix.so guarantee failure - which means the
user's credentials never get deleted and the user won't know unless they
look for debug1 messages in the syslog (which are suppressed by default).
I excpect this is an annoying problem for anyone doing SECURE_RPC on
Solaris.  I happened to notice this while turning on all kinds of
debugging to figure out what's causing the problem where new passwords are
echoed on Sol8.

	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  Sat Oct 27 05:53:02 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 15:53:02 -0400 (EDT)
Subject: Makefiles in v2.9.9p2
Message-ID: <Pine.SOL.4.30.0110261551180.2476-100000@mahler.udel.edu>

If I change openbsd-compt/readpassphrase.c and type "make" from the
top-level, nothing happens.  I have to remove
openbsd-compat/libopenbsd-compat.a to get "make" to do its thing.

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 stevesk at pobox.com  Sat Oct 27 06:04:50 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 26 Oct 2001 13:04:50 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.LNX.4.33.0110261104090.2060-100000@mothra.mindrot.org>
Message-ID: <Pine.HPX.4.40.0110261301520.2143-100000@jenny>

On Fri, 26 Oct 2001, Damien Miller wrote:
:The fact that pam_chauthtok was never getting called without a tty
:anyway.  Look at the code path in session.c. The do_pam_chauthtok() call
:was only being made for the tty case.

yes, that is a bug.

:If there is a problem, it is that accounts with expired passwords were
:still able to execute commands. Please try the patch below for this.
:
:Index: session.c
:===================================================================
:RCS file: /var/cvs/openssh/session.c,v
:retrieving revision 1.154
:diff -u -r1.154 session.c
:--- session.c	2001/10/12 01:35:51	1.154
:+++ session.c	2001/10/26 01:30:29
:@@ -432,6 +432,9 @@
: #if defined(USE_PAM)
: 	do_pam_session(s->pw->pw_name, NULL);
: 	do_pam_setcred(1);
:+	if (is_pam_password_change_required())
:+		packet_disconnect("Password change required but no "
:+		    "TTY available");
: #endif /* USE_PAM */
:
: 	/* Fork the child. */

that works for me on hp-ux 11 and is one way to fix it.  i'm not sure if
there is a better way.



From ed at UDel.Edu  Sat Oct 27 06:05:48 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 16:05:48 -0400 (EDT)
Subject: PAM session cleanup on Sol8 with v2.9.9p2
In-Reply-To: <Pine.SOL.4.30.0110261530570.2476-100000@mahler.udel.edu>
Message-ID: <Pine.SOL.4.30.0110261602170.2476-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Ed Phillips wrote:

> Date: Fri, 26 Oct 2001 15:49:46 -0400 (EDT)
> From: Ed Phillips <ed at udel.edu>
> To: openssh-unix-dev at mindrot.org
> Subject: PAM session cleanup on Sol8 with v2.9.9p2
>
> In do_pam_cleanup_proc(), there are 3 calls to PAM:
>
> 1) pam_close_session() - do lastlog stuff
>
> 2) pam_setcred(PAM_DELETE_CRED) - delete credentials
>
> 3) pam_end() - close PAM
>
> It appears that pam_setcred() always fails with the error PAM_PERM_DENIED.
> This is due to a check done pam_unix.so to not allow a caller with euid 0
> to even try to delete their SECURE_RPC credentials.  When sshd calls
> pam_setcred() to delete the credentials, evidentally, it is running with
> euid 0, so the checks in pam_unix.so guarantee failure - which means the
> user's credentials never get deleted and the user won't know unless they
> look for debug1 messages in the syslog (which are suppressed by default).
> I excpect this is an annoying problem for anyone doing SECURE_RPC on
> Solaris.  I happened to notice this while turning on all kinds of
> debugging to figure out what's causing the problem where new passwords are
> echoed on Sol8.

Some more info. about the pam_setcred()...

When I login and need to change my password, but type the wrong "old"
password, I can actually see the messages coming from pam_unix.so that
talk about the failure to delete credentials for SECURE_RPC:

polycut:~> ssh dazel
Warning: Your password has expired, please change it now
Enter login password:
sshd(SYSTEM): Sorry, wrong passwd
removing root credentials would break the rpc services that
use secure rpc on this host!
root may use keylogout -f to do this (at your own risk)!
Connection to dazel closed by remote host.
Connection to dazel closed.

FWIW... if nothing else, a check to see if we SHOULD even CALL
pam_setcred() during cleanup should be added.  And, probably a seteuid()
should be done to have hopes that the SECURE_RPC creds can be destroyed.

Anyone care about this?

	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  Sat Oct 27 06:12:35 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 16:12:35 -0400 (EDT)
Subject: New password echoes on Sol8
Message-ID: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>

I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
version that just calls getpassphrase().  It appears to solve the echo
problem when the user tries to login in interactive mode and needs to
change their password.

Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:

#define HAVE_GETPASSPHRASE

... to config.h when compiling (since it's not a configurable option yet).

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

*** openbsd-compat/readpassphrase.c_orig        Fri Oct 26 14:50:44 2001
--- openbsd-compat/readpassphrase.c     Fri Oct 26 15:28:34 2001
***************
*** 33,38 ****
--- 33,40 ----

  #ifndef HAVE_READPASSPHRASE

+ #ifndef HAVE_GETPASSPHRASE
+
  #include <termios.h>
  #include <readpassphrase.h>

***************
*** 148,153 ****
--- 150,176 ----
                (void)close(input);
        return(buf);
  }
+ #else
+
+ #include <unistd.h>
+
+ char *
+ readpassphrase(prompt, buf, bufsiz, flags)
+       const char *prompt;
+       char *buf;
+       size_t bufsiz;
+       int flags;
+ {
+       char    *phrase;
+
+       phrase = getpassphrase(prompt);
+       strncpy(buf, phrase, bufsiz - 1);
+       buf[bufsiz - 1] = '\0';
+       return buf;
+ }
+
+ #endif /* HAVE_GETPASSPHRASE */
+
  #endif /* HAVE_READPASSPHRASE */

  #if 0




From markus at openbsd.org  Sat Oct 27 06:20:28 2001
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 26 Oct 2001 22:20:28 +0200
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>; from ed@UDel.Edu on Fri, Oct 26, 2001 at 04:12:35PM -0400
References: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>
Message-ID: <20011026222028.A1116@faui02.informatik.uni-erlangen.de>

On Fri, Oct 26, 2001 at 04:12:35PM -0400, Ed Phillips wrote:
> I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> version that just calls getpassphrase().  It appears to solve the echo
> problem when the user tries to login in interactive mode and needs to
> change their password.

sorry, perhaps i'm missing something, but how is openssh's
readpassphrase() related to password changeing?


From mouring at etoh.eviladmin.org  Sat Oct 27 06:22:30 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 26 Oct 2001 15:22:30 -0500 (CDT)
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>
Message-ID: <Pine.BSO.4.33.0110261521540.27599-100000@etoh.eviladmin.org>


No.

I'd rather find out WHY readpassphrase() fails.  This could be an issue on
another platform, and I'd rather see it fixed right.

- Ben

On Fri, 26 Oct 2001, Ed Phillips wrote:

> I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> version that just calls getpassphrase().  It appears to solve the echo
> problem when the user tries to login in interactive mode and needs to
> change their password.
>
> Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:
>
> #define HAVE_GETPASSPHRASE
>
> ... to config.h when compiling (since it's not a configurable option yet).
>
> 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
>
> *** openbsd-compat/readpassphrase.c_orig        Fri Oct 26 14:50:44 2001
> --- openbsd-compat/readpassphrase.c     Fri Oct 26 15:28:34 2001
> ***************
> *** 33,38 ****
> --- 33,40 ----
>
>   #ifndef HAVE_READPASSPHRASE
>
> + #ifndef HAVE_GETPASSPHRASE
> +
>   #include <termios.h>
>   #include <readpassphrase.h>
>
> ***************
> *** 148,153 ****
> --- 150,176 ----
>                 (void)close(input);
>         return(buf);
>   }
> + #else
> +
> + #include <unistd.h>
> +
> + char *
> + readpassphrase(prompt, buf, bufsiz, flags)
> +       const char *prompt;
> +       char *buf;
> +       size_t bufsiz;
> +       int flags;
> + {
> +       char    *phrase;
> +
> +       phrase = getpassphrase(prompt);
> +       strncpy(buf, phrase, bufsiz - 1);
> +       buf[bufsiz - 1] = '\0';
> +       return buf;
> + }
> +
> + #endif /* HAVE_GETPASSPHRASE */
> +
>   #endif /* HAVE_READPASSPHRASE */
>
>   #if 0
>
>
>



From Nicolas.Williams at ubsw.com  Sat Oct 27 06:25:23 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 16:25:23 -0400
Subject: PAM session cleanup on Sol8 with v2.9.9p2
In-Reply-To: <Pine.SOL.4.30.0110261602170.2476-100000@mahler.udel.edu>; from ed@UDel.Edu on Fri, Oct 26, 2001 at 04:05:48PM -0400
References: <Pine.SOL.4.30.0110261530570.2476-100000@mahler.udel.edu> <Pine.SOL.4.30.0110261602170.2476-100000@mahler.udel.edu>
Message-ID: <20011026162522.N5739@sm2p1386swk.wdr.com>

I think this may be a bug in PAM_UNIX. As long as PAM_USER is set then
pam_unix's pam_sm_setcred() should *know* to delete that user's creds
instead of the user given by euid.

Nico


On Fri, Oct 26, 2001 at 04:05:48PM -0400, Ed Phillips wrote:
> On Fri, 26 Oct 2001, Ed Phillips wrote:
> 
> > Date: Fri, 26 Oct 2001 15:49:46 -0400 (EDT)
> > From: Ed Phillips <ed at udel.edu>
> > To: openssh-unix-dev at mindrot.org
> > Subject: PAM session cleanup on Sol8 with v2.9.9p2
> >
> > In do_pam_cleanup_proc(), there are 3 calls to PAM:
> >
> > 1) pam_close_session() - do lastlog stuff
> >
> > 2) pam_setcred(PAM_DELETE_CRED) - delete credentials
> >
> > 3) pam_end() - close PAM
> >
> > It appears that pam_setcred() always fails with the error PAM_PERM_DENIED.
> > This is due to a check done pam_unix.so to not allow a caller with euid 0
> > to even try to delete their SECURE_RPC credentials.  When sshd calls
> > pam_setcred() to delete the credentials, evidentally, it is running with
> > euid 0, so the checks in pam_unix.so guarantee failure - which means the
> > user's credentials never get deleted and the user won't know unless they
> > look for debug1 messages in the syslog (which are suppressed by default).
> > I excpect this is an annoying problem for anyone doing SECURE_RPC on
> > Solaris.  I happened to notice this while turning on all kinds of
> > debugging to figure out what's causing the problem where new passwords are
> > echoed on Sol8.
> 
> Some more info. about the pam_setcred()...
> 
> When I login and need to change my password, but type the wrong "old"
> password, I can actually see the messages coming from pam_unix.so that
> talk about the failure to delete credentials for SECURE_RPC:
> 
> polycut:~> ssh dazel
> Warning: Your password has expired, please change it now
> Enter login password:
> sshd(SYSTEM): Sorry, wrong passwd
> removing root credentials would break the rpc services that
> use secure rpc on this host!
> root may use keylogout -f to do this (at your own risk)!
> Connection to dazel closed by remote host.
> Connection to dazel closed.
> 
> FWIW... if nothing else, a check to see if we SHOULD even CALL
> pam_setcred() during cleanup should be added.  And, probably a seteuid()
> should be done to have hopes that the SECURE_RPC creds can be destroyed.
> 
> Anyone care about this?
> 
> 	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
--

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 mouring at etoh.eviladmin.org  Sat Oct 27 06:31:42 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 26 Oct 2001 15:31:42 -0500 (CDT)
Subject: New password echoes on Sol8
In-Reply-To: <20011026222028.A1116@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.BSO.4.33.0110261527140.27599-100000@etoh.eviladmin.org>


It is used (from what I can gleam from the code) to pick up the new
passwords when in a PAM 'expired' password state.  It is used indirectly
by the call to read_passphrase().

Why PAM does not do this on it's own is confusing to me.

- Ben

On Fri, 26 Oct 2001, Markus Friedl wrote:

> On Fri, Oct 26, 2001 at 04:12:35PM -0400, Ed Phillips wrote:
> > I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> > version that just calls getpassphrase().  It appears to solve the echo
> > problem when the user tries to login in interactive mode and needs to
> > change their password.
>
> sorry, perhaps i'm missing something, but how is openssh's
> readpassphrase() related to password changeing?
>



From stevesk at pobox.com  Sat Oct 27 06:31:32 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 26 Oct 2001 13:31:32 -0700 (PDT)
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>
Message-ID: <Pine.HPX.4.40.0110261330050.2143-100000@jenny>

On Fri, 26 Oct 2001, Ed Phillips wrote:
:I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
:version that just calls getpassphrase().  It appears to solve the echo
:problem when the user tries to login in interactive mode and needs to
:change their password.
:
:Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:

no!

try this:

Index: auth-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth-pam.c,v
retrieving revision 1.37
diff -u -r1.37 auth-pam.c
--- auth-pam.c	2001/04/23 18:38:37	1.37
+++ auth-pam.c	2001/10/26 20:30:42
@@ -87,7 +87,7 @@
  * messages with into __pam_msg.  This is used during initial
  * authentication to bypass the normal PAM password prompt.
  *
- * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase(prompt, 1)
+ * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase()
  * and outputs messages to stderr. This mode is used if pam_chauthtok()
  * is called to update expired passwords.
  */
@@ -148,7 +148,7 @@
 			case PAM_PROMPT_ECHO_OFF:
 				reply[count].resp = xstrdup(
 				    read_passphrase(PAM_MSG_MEMBER(msg, count,
-				    msg), 1));
+				    msg), RP_ALLOW_STDIN));
 				reply[count].resp_retcode = PAM_SUCCESS;
 				break;
 			case PAM_ERROR_MSG:



From ed at UDel.Edu  Sat Oct 27 06:42:45 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 16:42:45 -0400 (EDT)
Subject: PAM session cleanup on Sol8 with v2.9.9p2
In-Reply-To: <20011026162522.N5739@sm2p1386swk.wdr.com>
Message-ID: <Pine.SOL.4.30.0110261640530.2476-100000@mahler.udel.edu>

On Fri, 26 Oct 2001, Nicolas Williams wrote:

> Date: Fri, 26 Oct 2001 16:25:23 -0400
> From: Nicolas Williams <Nicolas.Williams at ubsw.com>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: PAM session cleanup on Sol8 with v2.9.9p2
>
> I think this may be a bug in PAM_UNIX. As long as PAM_USER is set then
> pam_unix's pam_sm_setcred() should *know* to delete that user's creds
> instead of the user given by euid.

Sure... but right now, the error is basically getting ignored and the user
is unaware.  What is the "standard" way for pam_sm_setcred() to handle
deletion of credentials?  Does pam_unix.so violate that?  I don't know...

	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 Nicolas.Williams at ubsw.com  Sat Oct 27 06:44:25 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Fri, 26 Oct 2001 16:44:25 -0400
Subject: New password echoes on Sol8
In-Reply-To: <Pine.BSO.4.33.0110261527140.27599-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Fri, Oct 26, 2001 at 03:31:42PM -0500
References: <20011026222028.A1116@faui02.informatik.uni-erlangen.de> <Pine.BSO.4.33.0110261527140.27599-100000@etoh.eviladmin.org>
Message-ID: <20011026164424.O5739@sm2p1386swk.wdr.com>

PAM is using the "conversation" function passed to it by OpenSSH.

That "conversation" function must be using read_passphrase().

Nico


On Fri, Oct 26, 2001 at 03:31:42PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> It is used (from what I can gleam from the code) to pick up the new
> passwords when in a PAM 'expired' password state.  It is used indirectly
> by the call to read_passphrase().
> 
> Why PAM does not do this on it's own is confusing to me.
> 
> - Ben
> 
> On Fri, 26 Oct 2001, Markus Friedl wrote:
> 
> > On Fri, Oct 26, 2001 at 04:12:35PM -0400, Ed Phillips wrote:
> > > I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> > > version that just calls getpassphrase().  It appears to solve the echo
> > > problem when the user tries to login in interactive mode and needs to
> > > change their password.
> >
> > sorry, perhaps i'm missing something, but how is openssh's
> > readpassphrase() related to password changeing?
> >
--

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 ed at UDel.Edu  Sat Oct 27 06:47:18 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Fri, 26 Oct 2001 16:47:18 -0400 (EDT)
Subject: New password echoes on Sol8
In-Reply-To: <Pine.HPX.4.40.0110261330050.2143-100000@jenny>
Message-ID: <Pine.SOL.4.30.0110261646320.2476-100000@mahler.udel.edu>

I'll try it first thing Monday...

On Fri, 26 Oct 2001, Kevin Steves wrote:

> Date: Fri, 26 Oct 2001 13:31:32 -0700 (PDT)
> From: Kevin Steves <stevesk at pobox.com>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>
> Subject: Re: New password echoes on Sol8
>
> On Fri, 26 Oct 2001, Ed Phillips wrote:
> :I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> :version that just calls getpassphrase().  It appears to solve the echo
> :problem when the user tries to login in interactive mode and needs to
> :change their password.
> :
> :Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:
>
> no!
>
> try this:
>
> Index: auth-pam.c
> ===================================================================
> RCS file: /var/cvs/openssh/auth-pam.c,v
> retrieving revision 1.37
> diff -u -r1.37 auth-pam.c
> --- auth-pam.c	2001/04/23 18:38:37	1.37
> +++ auth-pam.c	2001/10/26 20:30:42
> @@ -87,7 +87,7 @@
>   * messages with into __pam_msg.  This is used during initial
>   * authentication to bypass the normal PAM password prompt.
>   *
> - * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase(prompt, 1)
> + * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase()
>   * and outputs messages to stderr. This mode is used if pam_chauthtok()
>   * is called to update expired passwords.
>   */
> @@ -148,7 +148,7 @@
>  			case PAM_PROMPT_ECHO_OFF:
>  				reply[count].resp = xstrdup(
>  				    read_passphrase(PAM_MSG_MEMBER(msg, count,
> -				    msg), 1));
> +				    msg), RP_ALLOW_STDIN));
>  				reply[count].resp_retcode = PAM_SUCCESS;
>  				break;
>  			case PAM_ERROR_MSG:
>

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 stevesk at pobox.com  Sat Oct 27 06:47:38 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 26 Oct 2001 13:47:38 -0700 (PDT)
Subject: Regarding PAM_TTY_KLUDGE and Solaris 8...
In-Reply-To: <Pine.LNX.4.33.0110251043580.6250-100000@mothra.mindrot.org>
Message-ID: <Pine.HPX.4.40.0110261340051.2143-100000@jenny>

On Thu, 25 Oct 2001, Damien Miller wrote:
:IMO until then we should enable the kludge, but change it as follows.
:Kevin, can you check whether the kludge works with this patch on HP/UX?
:(is the kludge even needed there?)

hp-ux 11 does not need PAM_TTY_KLUDGE.  in fact, when it was enabled
last time something broke as i recall.  however, there is a PAM patch
required to fix an incompatibility with expired password checks.
there are some dependencies for the 11.11 patch on NFS/NIS--don't know
about the 11.0 patch.

11.11: PHCO_24839
11.00: PHCO_25527

or something prior with this fix:

	( SR:8606160402 CR:JAGad29724 )
	HP-UX is inconsistent with the PAM standard with respect
	to the return value for an expired password. This
	inconsistency causes a problem for programs written to
	run on multiple platforms.

	Resolution:
	When an expired password is detected, libpam_unix.1 now
	returns standard PAM_NEW_AUTHTOK_REQD instead of
	PAM_AUTHTOK_EXPIRED.

:Index: auth-pam.c
:===================================================================
:RCS file: /var/cvs/openssh/auth-pam.c,v
:retrieving revision 1.37
:diff -u -r1.37 auth-pam.c
:--- auth-pam.c	2001/04/23 18:38:37	1.37
:+++ auth-pam.c	2001/10/25 00:43:55
:@@ -374,7 +374,7 @@
: 	 * not even need one (for tty-less connections)
: 	 * Kludge: Set a fake PAM_TTY
: 	 */
:-	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
:+	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
: 	if (pam_retval != PAM_SUCCESS)
: 		fatal("PAM set tty failed[%d]: %.200s",
: 		    pam_retval, PAM_STRERROR(__pamh, pam_retval));



From tim at multitalents.net  Sat Oct 27 06:50:33 2001
From: tim at multitalents.net (Tim Rice)
Date: Fri, 26 Oct 2001 13:50:33 -0700 (PDT)
Subject: Makefiles in v2.9.9p2
In-Reply-To: <Pine.SOL.4.30.0110261551180.2476-100000@mahler.udel.edu>
Message-ID: <Pine.UW2.4.40.9.0110261350150.14425-100000@uw711.int.multitalents.net>


That's fixed in CVS

On Fri, 26 Oct 2001, Ed Phillips wrote:

> If I change openbsd-compt/readpassphrase.c and type "make" from the
> top-level, nothing happens.  I have to remove
> openbsd-compat/libopenbsd-compat.a to get "make" to do its thing.
>
> 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
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From mdb at juniper.net  Sat Oct 27 07:04:05 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 26 Oct 2001 14:04:05 -0700
Subject: problems building on solaris 2.6
Message-ID: <200110262104.f9QL45093900@merlot.juniper.net>

Using the latest cvs sources, the compilation of ssh.c fails.
The 'struct rlimit rlim;' line is being expanded by cpp into
'struct rlimit64 rlim;' and there is no struct rlimit64 defined.
In order to get the struct rlimit64 to be included when the

  #include <sys/resource.h>

is used, it appears to need the _LARGEFILE64_SOURCE symbol defined OR
it needs the '#if _FILE_OFFSET_BITS == 64' to fail.

I suspect this needs to be done with some kind of confgiure magic, but
I don't have time to figure out what it is right now...
	
	-- Mark

% ./configure --prefix=/usr/local/openssh-3.0p1 --with-pid-dir \
  --with-ipv4-default --sysconfdir=/etc/openssh \
  --with-libs=/usr/local/zlib-1.1.3/lib/libz.a \
  --with-libs=/usr/local/openssl-0.9.6b/lib/libssl.a \
  --with-cflags=-I/usr/local/zlib-1.1.3/include \
  --with-cflags=-I/usr/local/openssl-0.9.6b/include
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... 
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking build system type... sparc-sun-solaris2.6
checking host system type... sparc-sun-solaris2.6
checking whether byte ordering is bigendian... yes
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/local/bin/install -c
checking for ar... /usr/local/bin/ar
checking for perl5... no
checking for perl... /usr/local/bin/perl
checking for ent... no
checking for filepriv... no
checking for bash... /usr/local/bin/bash
checking for ksh... (cached) /usr/local/bin/bash
checking for sh... (cached) /usr/local/bin/bash
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGE_FILES value needed for large files... no
checking for login... /usr/bin/login
checking for gcc option to accept ANSI C... none needed
checking for inline... inline
checking for obsolete utmp and wtmp in solaris2.x... no
checking for yp_match... no
checking for yp_match in -lnsl... yes
checking for setsockopt... no
checking for setsockopt in -lsocket... yes
checking for getspnam... yes
checking for login... no
checking for login in -lutil... no
checking for deflate in -lz... yes
checking for regcomp... yes
checking for strcasecmp... yes
checking for utimes... yes
checking for strftime... yes
checking for bstring.h... no
checking for crypt.h... yes
checking for endian.h... no
checking for floatingpoint.h... yes
checking for getopt.h... no
checking for glob.h... yes
checking for lastlog.h... yes
checking for limits.h... yes
checking for login.h... no
checking for login_cap.h... no
checking for maillock.h... yes
checking for netdb.h... yes
checking for netgroup.h... no
checking for netinet/in_systm.h... yes
checking for paths.h... no
checking for poll.h... yes
checking for pty.h... no
checking for regex.h... yes
checking for security/pam_appl.h... yes
checking for shadow.h... yes
checking for stddef.h... yes
checking for stdint.h... no
checking for strings.h... yes
checking for sys/bitypes.h... no
checking for sys/bsdtty.h... no
checking for sys/cdefs.h... yes
checking for sys/poll.h... yes
checking for sys/queue.h... yes
checking for sys/select.h... yes
checking for sys/stat.h... yes
checking for sys/stropts.h... yes
checking for sys/sysmacros.h... yes
checking for sys/time.h... yes
checking for sys/ttcompat.h... yes
checking for sys/un.h... yes
checking for time.h... yes
checking for ttyent.h... no
checking for usersec.h... no
checking for util.h... no
checking for utime.h... yes
checking for utmp.h... yes
checking for utmpx.h... yes
checking for GLOB_ALTDIRFUNC support... no
checking for gl_matchc field in glob_t... no
checking whether struct dirent allocates space for d_name... no
checking for arc4random... no
checking for atexit... yes
checking for b64_ntop... no
checking for bcopy... yes
checking for bindresvport_sa... no
checking for clock... yes
checking for fchmod... yes
checking for fchown... yes
checking for freeaddrinfo... no
checking for futimes... no
checking for gai_strerror... no
checking for getaddrinfo... no
checking for getcwd... yes
checking for getgrouplist... no
checking for getnameinfo... no
checking for getopt... yes
checking for getrlimit... yes
checking for getrusage... yes
checking for getttyent... no
checking for glob... yes
checking for inet_aton... no
checking for inet_ntoa... yes
checking for inet_ntop... no
checking for innetgr... yes
checking for login_getcapbool... no
checking for md5_crypt... no
checking for memmove... yes
checking for mkdtemp... no
checking for on_exit... no
checking for openpty... no
checking for readpassphrase... no
checking for realpath... yes
checking for rresvport_af... no
checking for setdtablesize... no
checking for setegid... yes
checking for setenv... no
checking for seteuid... yes
checking for setlogin... no
checking for setproctitle... no
checking for setresgid... no
checking for setreuid... yes
checking for setrlimit... yes
checking for setsid... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for sigvec... no
checking for snprintf... yes
checking for strerror... yes
checking for strlcat... no
checking for strlcpy... no
checking for strmode... no
checking for strsep... no
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for utimes... (cached) yes
checking for vhangup... yes
checking for vsnprintf... yes
checking for waitpid... yes
checking for __b64_ntop... no
checking for _getpty... no
checking for dirname... yes
checking for libgen.h... yes
checking for gettimeofday... yes
checking for time... yes
checking for libutil.h... no
checking for login... (cached) no
checking for logout... no
checking for updwtmp... yes
checking for logwtmp... no
checking for endutent... yes
checking for getutent... yes
checking for getutid... yes
checking for getutline... yes
checking for pututline... yes
checking for setutent... yes
checking for utmpname... yes
checking for endutxent... yes
checking for getutxent... yes
checking for getutxid... yes
checking for getutxline... yes
checking for pututxline... yes
checking for setutxent... yes
checking for utmpxname... yes
checking for getuserattr... no
checking for getuserattr in -ls... no
checking for login... (cached) no
checking for login in -lbsd... no
checking for daemon... no
checking for daemon in -lbsd... no
checking for getpagesize... yes
checking whether snprintf correctly terminates long strings... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... (cached) yes
checking for inttypes.h... yes
checking for stdint.h... (cached) no
checking for unistd.h... yes
checking whether getpgrp takes no argument... yes
checking for OpenSSL directory... /usr/local/openssl
checking for RSA support... yes
checking for char... yes
checking size of char... 1
checking for short int... yes
checking size of short int... 2
checking for int... yes
checking size of int... 4
checking for long int... yes
checking size of long int... 4
checking for long long int... yes
checking size of long long int... 8
checking for u_int type... yes
checking for intXX_t types... yes
checking for int64_t type... yes
checking for u_intXX_t types... no
checking for u_intXX_t types in sys/socket.h... no
checking for u_int64_t types... no
checking for uintXX_t types... yes
checking for uintXX_t types in stdint.h... no
checking for u_char... yes
checking for socklen_t... no
checking for socklen_t equivalent... int
checking for size_t... yes
checking for ssize_t... yes
checking for clock_t... yes
checking for sa_family_t... yes
checking for pid_t... yes
checking for mode_t... yes
checking for struct sockaddr_storage... no
checking for struct sockaddr_in6... no
checking for struct in6_addr... no
checking for struct addrinfo... no
checking for struct timeval... yes
checking for ut_host field in utmp.h... no
checking for ut_host field in utmpx.h... yes
checking for syslen field in utmpx.h... yes
checking for ut_pid field in utmp.h... yes
checking for ut_type field in utmp.h... yes
checking for ut_type field in utmpx.h... yes
checking for ut_tv field in utmp.h... no
checking for ut_id field in utmp.h... yes
checking for ut_id field in utmpx.h... yes
checking for ut_addr field in utmp.h... no
checking for ut_addr field in utmpx.h... no
checking for ut_addr_v6 field in utmp.h... no
checking for ut_addr_v6 field in utmpx.h... no
checking for ut_exit field in utmp.h... yes
checking for ut_time field in utmp.h... yes
checking for ut_time field in utmpx.h... yes
checking for ut_tv field in utmpx.h... yes
checking for struct stat.st_blksize... yes
checking for ss_family field in struct sockaddr_storage... no
checking for __ss_family field in struct sockaddr_storage... no
checking for pw_class field in struct passwd... no
checking for pw_expire field in struct passwd... no
checking for pw_change field in struct passwd... no
checking if libc defines __progname... no
checking whether getopt has optreset support... no
checking if libc defines sys_errlist... yes
checking if libc defines sys_nerr... yes
checking for rsh... /usr/bin/rsh
checking for xauth... /usr/openwin/bin/xauth
checking for "/dev/ptmx"... yes
checking for "/dev/ptc"... no
checking for "/dev/urandom"... no
checking for PRNGD/EGD socket... /var/run/egd-pool
checking for ls... /usr/bin/ls
checking for netstat... /usr/bin/netstat
checking for arp... /usr/sbin/arp
checking for ifconfig... /usr/sbin/ifconfig
checking for jstat... no
checking for ps... /usr/bin/ps
checking for sar... /usr/bin/sar
checking for w... /usr/bin/w
checking for who... /usr/bin/who
checking for last... /usr/bin/last
checking for lastlog... no
checking for df... /usr/bin/df
checking for vmstat... /usr/bin/vmstat
checking for uptime... /usr/bin/uptime
checking for ipcs... /usr/bin/ipcs
checking for tail... /usr/bin/tail
checking for nroff... /usr/bin/nroff
checking if the systems has expire shadow information... yes
Adding /usr/local/openssh-3.0p1/bin to USER_PATH so scp will work
checking if we need to convert IPv4 in IPv6-mapped addresses... no (default)
checking whether to install ssh as suid root... yes
checking if your system defines LASTLOG_FILE... no
checking if your system defines _PATH_LASTLOG... no
checking if your system defines UTMP_FILE... yes
checking if your system defines WTMP_FILE... yes
checking if your system defines UTMPX_FILE... yes
checking if your system defines WTMPX_FILE... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating openbsd-compat/Makefile
config.status: creating scard/Makefile
config.status: creating ssh_prng_cmds
config.status: creating config.h

OpenSSH has been configured with the following options:
                 User binaries: /usr/local/openssh-3.0p1/bin
               System binaries: /usr/local/openssh-3.0p1/sbin
           Configuration files: /etc/openssh
               Askpass program: /usr/local/openssh-3.0p1/libexec/ssh-askpass
                  Manual pages: /usr/local/openssh-3.0p1/man/manX
                      PID file: /etc/openssh
        sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/openssh-3.0p1/bin
      Random number collection: PRNGD/EGD (socket /var/run/egd-pool)
                Manpage format: man
                   PAM support: no
            KerberosIV support: no
             Smartcard support: no
                   AFS support: no
                 S/KEY support: no
          TCP Wrappers support: no
          MD5 password support: no
   IP address in $DISPLAY hack: no
      Use IPv4 by default hack: yes
       Translate v4 in v6 hack: no

              Host: sparc-sun-solaris2.6
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/openssl-0.9.6b/include
Preprocessor flags: -I/usr/local/openssl/include  -I/usr/local/include
      Linker flags: -R/usr/local/openssl/lib -L/usr/local/openssl/lib  -L/usr/local/lib -R/usr/local/lib
         Libraries: -lz -lsocket -lnsl  /usr/local/openssl-0.9.6b/lib/libssl.a -lcrypto 

% make
...elided...
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized \
-I/usr/local/openssl-0.9.6b/include \
-I. -I. -I/usr/local/openssl/include -I/usr/local/include \
-DETCDIR=\"/etc/openssh\" \
-D_PATH_SSH_PROGRAM=\"/usr/local/openssh-3.0p1/bin/ssh\" \
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/openssh-3.0p1/libexec/ssh-askpass\" \
-D_PATH_SFTP_SERVER=\"/usr/local/openssh-3.0p1/libexec/sftp-server\" \
-D_PATH_SSH_PIDDIR=\"/etc/openssh\" -DHAVE_CONFIG_H -c ssh.c
In file included from /usr/include/sys/vnode.h:41,
                 from /usr/include/sys/stream.h:21,
                 from /usr/include/netinet/in.h:38,
                 from defines.h:12,
                 from config.h:828,
                 from includes.h:22,
                 from ssh.c:41:
/usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside parameter list
/usr/include/sys/resource.h:148: warning: its scope is only this definition or declaration,
/usr/include/sys/resource.h:148: warning: which is probably not what you want.
/usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside parameter list
ssh.c: In function `main':
ssh.c:283: storage size of `rlim' isn't known
ssh.c:283: warning: unused variable `rlim'
make: *** [ssh.o] Error 1




From dwd at bell-labs.com  Sat Oct 27 07:11:30 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Fri, 26 Oct 2001 16:11:30 -0500
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
Message-ID: <20011026161130.A28674@lucent.com>

Because ForwardX11 and ForwardAgent are so useful but introduce risk when
used to a not well-secured server, I added a "warn" value to the ForwardX11
and ForwardAgent options which causes the ssh client to print a big warning
whenever the forwarding is actually used.  I plan to make "ForwardX11=warn"
the default in my ssh_config distribution.

I'm not proposing that this patch go into 3.0, but hopefully it will go
into the next release.  If the patch is accepted, the team might want to
consider whether -X and -A should set their corresponding option to "warn"
rather than "yes".

This patch is for OpenSSH native.  I tested it on portable, but it applies
cleanly to native.

Damien said that native patch submissions are supposed to go into OpenBSD
GNATS but I don't find any references to GNATS on www.openbsd.com or
www.openssh.com.  How do I submit a patch to it?

- Dave Dykstra


--- readconf.c.O	Fri Oct 26 10:45:15 2001
+++ readconf.c	Fri Oct 26 11:42:22 2001
@@ -296,28 +296,44 @@
 		/* NOTREACHED */
 	case oForwardAgent:
 		intptr = &options->forward_agent;
-parse_flag:
+parse_yesnowarn:
 		arg = strdelim(&s);
 		if (!arg || *arg == '\0')
-			fatal("%.200s line %d: Missing yes/no argument.", filename, linenum);
+			fatal("%.200s line %d: Missing yes/no/warn argument.",
+			      filename, linenum);
 		value = 0;	/* To avoid compiler warning... */
 		if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0)
 			value = 1;
 		else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0)
 			value = 0;
+		else if (strcmp(arg, "warn") == 0)
+			value = 2;
 		else
-			fatal("%.200s line %d: Bad yes/no argument.", filename, linenum);
+			fatal("%.200s line %d: Bad yes/no/warn argument.", filename, linenum);
 		if (*activep && *intptr == -1)
 			*intptr = value;
 		break;
 
 	case oForwardX11:
 		intptr = &options->forward_x11;
-		goto parse_flag;
+		goto parse_yesnowarn;
 
 	case oGatewayPorts:
 		intptr = &options->gateway_ports;
-		goto parse_flag;
+parse_flag:
+		arg = strdelim(&s);
+		if (!arg || *arg == '\0')
+			fatal("%.200s line %d: Missing yes/no argument.", filename, linenum);
+		value = 0;	/* To avoid compiler warning... */
+		if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0)
+			value = 1;
+		else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0)
+			value = 0;
+		else
+			fatal("%.200s line %d: Bad yes/no argument.", filename, linenum);
+		if (*activep && *intptr == -1)
+			*intptr = value;
+		break;
 
 	case oUsePrivilegedPort:
 		intptr = &options->use_privileged_port;
--- clientloop.c.O	Fri Oct 26 11:47:19 2001
+++ clientloop.c	Fri Oct 26 13:32:26 2001
@@ -1234,6 +1234,40 @@
 	}
 	xfree(rtype);
 }
+static void
+client_input_agent_open(int type, int plen, void *ctxt)
+{
+	if (!options.forward_agent) {
+		deny_input_open(type, plen, ctxt);
+		return;
+	}
+	if (options.forward_agent == 2) {
+		error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+		error("@  ssh WARNING: received agent open request from the server.         @");
+		error("@  If you did not initiate it, you are probably under attack.        @");
+		error("@  To eliminate these warnings, set the ForwardAgent option to yes,  @");
+		error("@  but note that that is risky if the server is not well-secured.    @");
+		error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+	}
+	auth_input_open_request(type, plen, ctxt);
+}
+static void
+client_input_x11_open(int type, int plen, void *ctxt)
+{
+	if (!options.forward_x11) {
+		deny_input_open(type, plen, ctxt);
+		return;
+	}
+	if (options.forward_x11 == 2) {
+		error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+		error("@  ssh WARNING: received X11 open request from the server.           @");
+		error("@  If you did not initiate it, you are probably under attack.        @");
+		error("@  To eliminate these warnings, set the ForwardX11 option to yes,    @");
+		error("@  but note that that is risky if the server is not well-secured.    @");
+		error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+	}
+	x11_input_open(type, plen, ctxt);
+}
 
 static void
 client_init_dispatch_20(void)
@@ -1265,11 +1299,8 @@
 	dispatch_set(SSH_SMSG_EXITSTATUS, &client_input_exit_status);
 	dispatch_set(SSH_SMSG_STDERR_DATA, &client_input_stderr_data);
 	dispatch_set(SSH_SMSG_STDOUT_DATA, &client_input_stdout_data);
-
-	dispatch_set(SSH_SMSG_AGENT_OPEN, options.forward_agent ?
-	    &auth_input_open_request : &deny_input_open);
-	dispatch_set(SSH_SMSG_X11_OPEN, options.forward_x11 ?
-	    &x11_input_open : &deny_input_open);
+	dispatch_set(SSH_SMSG_AGENT_OPEN, &client_input_agent_open);
+	dispatch_set(SSH_SMSG_X11_OPEN, &client_input_x11_open);
 }
 static void
 client_init_dispatch_15(void)
--- ssh.1.O	Fri Oct 26 12:56:10 2001
+++ ssh.1	Fri Oct 26 13:12:17 2001
@@ -308,6 +308,8 @@
 .Cm ForwardX11
 variable is set to
 .Dq yes
+or
+.Dq warn
 (or, see the description of the
 .Fl X
 and
@@ -846,9 +848,18 @@
 Specifies whether the connection to the authentication agent (if any)
 will be forwarded to the remote machine.
 The argument must be
-.Dq yes
+.Dq yes ,
+.Dq no ,
 or
-.Dq no .
+.Dq warn .
+If it is set to
+.Dq warn ,
+a warning is printed every time an agent authentication is requested; this
+is highly recommended if the server is not well-secured because an agent
+authentication allows an attacker to log in to any other server that has
+one of the agent's keys in an
+.Pa authorized_keys
+file.
 The default is
 .Dq no .
 .It Cm ForwardX11
@@ -857,9 +868,15 @@
 .Ev DISPLAY
 set.
 The argument must be
-.Dq yes
+.Dq yes ,
+.Dq no ,
 or
-.Dq no .
+.Dq warn .
+If it is set to
+.Dq warn ,
+a warning is printed every time an X11 connection is forwarded; this is
+highly recommended if the server is not well-secured because an X11
+connection can read and write anything on the user's X11 display.
 The default is
 .Dq no .
 .It Cm GatewayPorts


From mouring at etoh.eviladmin.org  Sat Oct 27 07:30:34 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Fri, 26 Oct 2001 16:30:34 -0500 (CDT)
Subject: problems building on solaris 2.6
In-Reply-To: <200110262104.f9QL45093900@merlot.juniper.net>
Message-ID: <Pine.BSO.4.33.0110261630000.27599-100000@etoh.eviladmin.org>


Does it hurt anything if we just include sys/resource.h if it exists
always.  If we are dealing with 64bit off_t or not?

- Ben

On Fri, 26 Oct 2001, Mark D. Baushke wrote:

> Using the latest cvs sources, the compilation of ssh.c fails.
> The 'struct rlimit rlim;' line is being expanded by cpp into
> 'struct rlimit64 rlim;' and there is no struct rlimit64 defined.
> In order to get the struct rlimit64 to be included when the
>
>   #include <sys/resource.h>
>
> is used, it appears to need the _LARGEFILE64_SOURCE symbol defined OR
> it needs the '#if _FILE_OFFSET_BITS == 64' to fail.
>
> I suspect this needs to be done with some kind of confgiure magic, but
> I don't have time to figure out what it is right now...
>
> 	-- Mark
>
> % ./configure --prefix=/usr/local/openssh-3.0p1 --with-pid-dir \
>   --with-ipv4-default --sysconfdir=/etc/openssh \
>   --with-libs=/usr/local/zlib-1.1.3/lib/libz.a \
>   --with-libs=/usr/local/openssl-0.9.6b/lib/libssl.a \
>   --with-cflags=-I/usr/local/zlib-1.1.3/include \
>   --with-cflags=-I/usr/local/openssl-0.9.6b/include
> checking for gcc... gcc
> checking for C compiler default output... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for executable suffix...
> checking for object suffix... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking build system type... sparc-sun-solaris2.6
> checking host system type... sparc-sun-solaris2.6
> checking whether byte ordering is bigendian... yes
> checking how to run the C preprocessor... gcc -E
> checking for ranlib... ranlib
> checking for a BSD compatible install... /usr/local/bin/install -c
> checking for ar... /usr/local/bin/ar
> checking for perl5... no
> checking for perl... /usr/local/bin/perl
> checking for ent... no
> checking for filepriv... no
> checking for bash... /usr/local/bin/bash
> checking for ksh... (cached) /usr/local/bin/bash
> checking for sh... (cached) /usr/local/bin/bash
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... 64
> checking for _LARGE_FILES value needed for large files... no
> checking for login... /usr/bin/login
> checking for gcc option to accept ANSI C... none needed
> checking for inline... inline
> checking for obsolete utmp and wtmp in solaris2.x... no
> checking for yp_match... no
> checking for yp_match in -lnsl... yes
> checking for setsockopt... no
> checking for setsockopt in -lsocket... yes
> checking for getspnam... yes
> checking for login... no
> checking for login in -lutil... no
> checking for deflate in -lz... yes
> checking for regcomp... yes
> checking for strcasecmp... yes
> checking for utimes... yes
> checking for strftime... yes
> checking for bstring.h... no
> checking for crypt.h... yes
> checking for endian.h... no
> checking for floatingpoint.h... yes
> checking for getopt.h... no
> checking for glob.h... yes
> checking for lastlog.h... yes
> checking for limits.h... yes
> checking for login.h... no
> checking for login_cap.h... no
> checking for maillock.h... yes
> checking for netdb.h... yes
> checking for netgroup.h... no
> checking for netinet/in_systm.h... yes
> checking for paths.h... no
> checking for poll.h... yes
> checking for pty.h... no
> checking for regex.h... yes
> checking for security/pam_appl.h... yes
> checking for shadow.h... yes
> checking for stddef.h... yes
> checking for stdint.h... no
> checking for strings.h... yes
> checking for sys/bitypes.h... no
> checking for sys/bsdtty.h... no
> checking for sys/cdefs.h... yes
> checking for sys/poll.h... yes
> checking for sys/queue.h... yes
> checking for sys/select.h... yes
> checking for sys/stat.h... yes
> checking for sys/stropts.h... yes
> checking for sys/sysmacros.h... yes
> checking for sys/time.h... yes
> checking for sys/ttcompat.h... yes
> checking for sys/un.h... yes
> checking for time.h... yes
> checking for ttyent.h... no
> checking for usersec.h... no
> checking for util.h... no
> checking for utime.h... yes
> checking for utmp.h... yes
> checking for utmpx.h... yes
> checking for GLOB_ALTDIRFUNC support... no
> checking for gl_matchc field in glob_t... no
> checking whether struct dirent allocates space for d_name... no
> checking for arc4random... no
> checking for atexit... yes
> checking for b64_ntop... no
> checking for bcopy... yes
> checking for bindresvport_sa... no
> checking for clock... yes
> checking for fchmod... yes
> checking for fchown... yes
> checking for freeaddrinfo... no
> checking for futimes... no
> checking for gai_strerror... no
> checking for getaddrinfo... no
> checking for getcwd... yes
> checking for getgrouplist... no
> checking for getnameinfo... no
> checking for getopt... yes
> checking for getrlimit... yes
> checking for getrusage... yes
> checking for getttyent... no
> checking for glob... yes
> checking for inet_aton... no
> checking for inet_ntoa... yes
> checking for inet_ntop... no
> checking for innetgr... yes
> checking for login_getcapbool... no
> checking for md5_crypt... no
> checking for memmove... yes
> checking for mkdtemp... no
> checking for on_exit... no
> checking for openpty... no
> checking for readpassphrase... no
> checking for realpath... yes
> checking for rresvport_af... no
> checking for setdtablesize... no
> checking for setegid... yes
> checking for setenv... no
> checking for seteuid... yes
> checking for setlogin... no
> checking for setproctitle... no
> checking for setresgid... no
> checking for setreuid... yes
> checking for setrlimit... yes
> checking for setsid... yes
> checking for setvbuf... yes
> checking for sigaction... yes
> checking for sigvec... no
> checking for snprintf... yes
> checking for strerror... yes
> checking for strlcat... no
> checking for strlcpy... no
> checking for strmode... no
> checking for strsep... no
> checking for sysconf... yes
> checking for tcgetpgrp... yes
> checking for utimes... (cached) yes
> checking for vhangup... yes
> checking for vsnprintf... yes
> checking for waitpid... yes
> checking for __b64_ntop... no
> checking for _getpty... no
> checking for dirname... yes
> checking for libgen.h... yes
> checking for gettimeofday... yes
> checking for time... yes
> checking for libutil.h... no
> checking for login... (cached) no
> checking for logout... no
> checking for updwtmp... yes
> checking for logwtmp... no
> checking for endutent... yes
> checking for getutent... yes
> checking for getutid... yes
> checking for getutline... yes
> checking for pututline... yes
> checking for setutent... yes
> checking for utmpname... yes
> checking for endutxent... yes
> checking for getutxent... yes
> checking for getutxid... yes
> checking for getutxline... yes
> checking for pututxline... yes
> checking for setutxent... yes
> checking for utmpxname... yes
> checking for getuserattr... no
> checking for getuserattr in -ls... no
> checking for login... (cached) no
> checking for login in -lbsd... no
> checking for daemon... no
> checking for daemon in -lbsd... no
> checking for getpagesize... yes
> checking whether snprintf correctly terminates long strings... yes
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... (cached) yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... (cached) yes
> checking for inttypes.h... yes
> checking for stdint.h... (cached) no
> checking for unistd.h... yes
> checking whether getpgrp takes no argument... yes
> checking for OpenSSL directory... /usr/local/openssl
> checking for RSA support... yes
> checking for char... yes
> checking size of char... 1
> checking for short int... yes
> checking size of short int... 2
> checking for int... yes
> checking size of int... 4
> checking for long int... yes
> checking size of long int... 4
> checking for long long int... yes
> checking size of long long int... 8
> checking for u_int type... yes
> checking for intXX_t types... yes
> checking for int64_t type... yes
> checking for u_intXX_t types... no
> checking for u_intXX_t types in sys/socket.h... no
> checking for u_int64_t types... no
> checking for uintXX_t types... yes
> checking for uintXX_t types in stdint.h... no
> checking for u_char... yes
> checking for socklen_t... no
> checking for socklen_t equivalent... int
> checking for size_t... yes
> checking for ssize_t... yes
> checking for clock_t... yes
> checking for sa_family_t... yes
> checking for pid_t... yes
> checking for mode_t... yes
> checking for struct sockaddr_storage... no
> checking for struct sockaddr_in6... no
> checking for struct in6_addr... no
> checking for struct addrinfo... no
> checking for struct timeval... yes
> checking for ut_host field in utmp.h... no
> checking for ut_host field in utmpx.h... yes
> checking for syslen field in utmpx.h... yes
> checking for ut_pid field in utmp.h... yes
> checking for ut_type field in utmp.h... yes
> checking for ut_type field in utmpx.h... yes
> checking for ut_tv field in utmp.h... no
> checking for ut_id field in utmp.h... yes
> checking for ut_id field in utmpx.h... yes
> checking for ut_addr field in utmp.h... no
> checking for ut_addr field in utmpx.h... no
> checking for ut_addr_v6 field in utmp.h... no
> checking for ut_addr_v6 field in utmpx.h... no
> checking for ut_exit field in utmp.h... yes
> checking for ut_time field in utmp.h... yes
> checking for ut_time field in utmpx.h... yes
> checking for ut_tv field in utmpx.h... yes
> checking for struct stat.st_blksize... yes
> checking for ss_family field in struct sockaddr_storage... no
> checking for __ss_family field in struct sockaddr_storage... no
> checking for pw_class field in struct passwd... no
> checking for pw_expire field in struct passwd... no
> checking for pw_change field in struct passwd... no
> checking if libc defines __progname... no
> checking whether getopt has optreset support... no
> checking if libc defines sys_errlist... yes
> checking if libc defines sys_nerr... yes
> checking for rsh... /usr/bin/rsh
> checking for xauth... /usr/openwin/bin/xauth
> checking for "/dev/ptmx"... yes
> checking for "/dev/ptc"... no
> checking for "/dev/urandom"... no
> checking for PRNGD/EGD socket... /var/run/egd-pool
> checking for ls... /usr/bin/ls
> checking for netstat... /usr/bin/netstat
> checking for arp... /usr/sbin/arp
> checking for ifconfig... /usr/sbin/ifconfig
> checking for jstat... no
> checking for ps... /usr/bin/ps
> checking for sar... /usr/bin/sar
> checking for w... /usr/bin/w
> checking for who... /usr/bin/who
> checking for last... /usr/bin/last
> checking for lastlog... no
> checking for df... /usr/bin/df
> checking for vmstat... /usr/bin/vmstat
> checking for uptime... /usr/bin/uptime
> checking for ipcs... /usr/bin/ipcs
> checking for tail... /usr/bin/tail
> checking for nroff... /usr/bin/nroff
> checking if the systems has expire shadow information... yes
> Adding /usr/local/openssh-3.0p1/bin to USER_PATH so scp will work
> checking if we need to convert IPv4 in IPv6-mapped addresses... no (default)
> checking whether to install ssh as suid root... yes
> checking if your system defines LASTLOG_FILE... no
> checking if your system defines _PATH_LASTLOG... no
> checking if your system defines UTMP_FILE... yes
> checking if your system defines WTMP_FILE... yes
> checking if your system defines UTMPX_FILE... yes
> checking if your system defines WTMPX_FILE... yes
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating openbsd-compat/Makefile
> config.status: creating scard/Makefile
> config.status: creating ssh_prng_cmds
> config.status: creating config.h
>
> OpenSSH has been configured with the following options:
>                  User binaries: /usr/local/openssh-3.0p1/bin
>                System binaries: /usr/local/openssh-3.0p1/sbin
>            Configuration files: /etc/openssh
>                Askpass program: /usr/local/openssh-3.0p1/libexec/ssh-askpass
>                   Manual pages: /usr/local/openssh-3.0p1/man/manX
>                       PID file: /etc/openssh
>         sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/openssh-3.0p1/bin
>       Random number collection: PRNGD/EGD (socket /var/run/egd-pool)
>                 Manpage format: man
>                    PAM support: no
>             KerberosIV support: no
>              Smartcard support: no
>                    AFS support: no
>                  S/KEY support: no
>           TCP Wrappers support: no
>           MD5 password support: no
>    IP address in $DISPLAY hack: no
>       Use IPv4 by default hack: yes
>        Translate v4 in v6 hack: no
>
>               Host: sparc-sun-solaris2.6
>           Compiler: gcc
>     Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/openssl-0.9.6b/include
> Preprocessor flags: -I/usr/local/openssl/include  -I/usr/local/include
>       Linker flags: -R/usr/local/openssl/lib -L/usr/local/openssl/lib  -L/usr/local/lib -R/usr/local/lib
>          Libraries: -lz -lsocket -lnsl  /usr/local/openssl-0.9.6b/lib/libssl.a -lcrypto
>
> % make
> ...elided...
> gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized \
> -I/usr/local/openssl-0.9.6b/include \
> -I. -I. -I/usr/local/openssl/include -I/usr/local/include \
> -DETCDIR=\"/etc/openssh\" \
> -D_PATH_SSH_PROGRAM=\"/usr/local/openssh-3.0p1/bin/ssh\" \
> -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/openssh-3.0p1/libexec/ssh-askpass\" \
> -D_PATH_SFTP_SERVER=\"/usr/local/openssh-3.0p1/libexec/sftp-server\" \
> -D_PATH_SSH_PIDDIR=\"/etc/openssh\" -DHAVE_CONFIG_H -c ssh.c
> In file included from /usr/include/sys/vnode.h:41,
>                  from /usr/include/sys/stream.h:21,
>                  from /usr/include/netinet/in.h:38,
>                  from defines.h:12,
>                  from config.h:828,
>                  from includes.h:22,
>                  from ssh.c:41:
> /usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside parameter list
> /usr/include/sys/resource.h:148: warning: its scope is only this definition or declaration,
> /usr/include/sys/resource.h:148: warning: which is probably not what you want.
> /usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside parameter list
> ssh.c: In function `main':
> ssh.c:283: storage size of `rlim' isn't known
> ssh.c:283: warning: unused variable `rlim'
> make: *** [ssh.o] Error 1
>
>
>



From mdb at juniper.net  Sat Oct 27 07:47:06 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 26 Oct 2001 14:47:06 -0700
Subject: problems building on solaris 2.6 
In-Reply-To: Mail from <mouring@etoh.eviladmin.org> 
             dated Fri, 26 Oct 2001 16:30:34 CDT
             <Pine.BSO.4.33.0110261630000.27599-100000@etoh.eviladmin.org> 
Message-ID: <200110262147.f9QLl6096442@merlot.juniper.net>

Hi Ben,

> Date: Fri, 26 Oct 2001 16:30:34 -0500 (CDT)
> From: <mouring at etoh.eviladmin.org>
> 
> 
> Does it hurt anything if we just include sys/resource.h if it exists
> always.  If we are dealing with 64bit off_t or not?

I am not sure I understand the question. You NEED to include
<sys/resource.h> so that it will be able to deal with the
'#ifdef HAVE_SETRLIMIT' code.

When I added

    #define _LARGEFILE64_SOURCE

to the config.h file after the 

    #define _FILE_OFFSET_BITS 64

I found that ssh built correctly (modulo having to hit it over the
head to NOT use the /usr/local/openssl version that was 0.9.6a and TO
use the /usr/local/openssl-0.0.6b that I tried to configure it to use.

In any case, I'd suggest a configure test that tries to do something
with the following:

% cat rlimtest.c
#define _FILE_OFFSET_BITS 64
#inlcude <sys/resource.h>
struct rlimit rlim = { 0, 0};
% gcc -g -O2 -c rlimtest.c 
In file included from mdb.test.c:2:
/usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside parameter list
/usr/include/sys/resource.h:148: warning: its scope is only this definition or declaration,
/usr/include/sys/resource.h:148: warning: which is probably not what you want.
/usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside parameter list
rlimtest.c:4: variable `rlim' has initializer but incomplete type
rlimtest.c:4: warning: excess elements in struct initializer after `rlim'
rlimtest.c:4: warning: excess elements in struct initializer after `rlim'
% gcc -g -O2 -D_LARGEFILE64_SOURCE -c rlimtest.c 
%

This is probably suitable for a AC_TRY_COMPILE or something...

	Thanks,
	-- Mark

> - Ben
> 
> On Fri, 26 Oct 2001, Mark D. Baushke wrote:
> 
> > Using the latest cvs sources, the compilation of ssh.c fails.
> > The 'struct rlimit rlim;' line is being expanded by cpp into
> > 'struct rlimit64 rlim;' and there is no struct rlimit64 defined.
> > In order to get the struct rlimit64 to be included when the
> >
> >   #include <sys/resource.h>
> >
> > is used, it appears to need the _LARGEFILE64_SOURCE symbol defined OR
> > it needs the '#if _FILE_OFFSET_BITS == 64' to fail.
> >
> > I suspect this needs to be done with some kind of confgiure magic, but
> > I don't have time to figure out what it is right now...
> >
> > 	-- Mark


From markus at openbsd.org  Sat Oct 27 08:04:30 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 27 Oct 2001 00:04:30 +0200
Subject: New password echoes on Sol8
In-Reply-To: <20011026164424.O5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Fri, Oct 26, 2001 at 04:44:25PM -0400
References: <20011026222028.A1116@faui02.informatik.uni-erlangen.de> <Pine.BSO.4.33.0110261527140.27599-100000@etoh.eviladmin.org> <20011026164424.O5739@sm2p1386swk.wdr.com>
Message-ID: <20011027000430.A4716@faui02.informatik.uni-erlangen.de>

On Fri, Oct 26, 2001 at 04:44:25PM -0400, Nicolas Williams wrote:
> PAM is using the "conversation" function passed to it by OpenSSH.
> 
> That "conversation" function must be using read_passphrase().

so we are talking about this:

	case PAM_PROMPT_ECHO_OFF:
		reply[count].resp = xstrdup(
		    read_passphrase(PAM_MSG_MEMBER(msg, count,
		    msg), 1));
		reply[count].resp_retcode = PAM_SUCCESS;
		break;

the call is wrong:
	1) read_passphrase() does already call xstrdup
	2) 1 is passed as a flag to read_passphrase(), and
	   1 means: RP_ECHO so echo is not turned off.

i suggest:
		reply[count].resp = 
		    read_passphrase(PAM_MSG_MEMBER(msg, count,
		    msg), RP_ALLOW_STDIN);
or
		reply[count].resp = 
		    read_passphrase(PAM_MSG_MEMBER(msg, count,
		    msg), 0);

-m


From markus at openbsd.org  Sat Oct 27 08:09:24 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 27 Oct 2001 00:09:24 +0200
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011026161130.A28674@lucent.com>; from dwd@bell-labs.com on Fri, Oct 26, 2001 at 04:11:30PM -0500
References: <20011026161130.A28674@lucent.com>
Message-ID: <20011027000924.A5122@faui02.informatik.uni-erlangen.de>

On Fri, Oct 26, 2001 at 04:11:30PM -0500, Dave Dykstra wrote:
> Because ForwardX11 and ForwardAgent are so useful but introduce risk when
> used to a not well-secured server, I added a "warn" value to the ForwardX11
> and ForwardAgent options which causes the ssh client to print a big warning
> whenever the forwarding is actually used.  I plan to make "ForwardX11=warn"
> the default in my ssh_config distribution.

why is this better then having
	ForwardX11=no
and using
	-X
to enable forwarding on a 'need' basis?

-m


From stevesk at pobox.com  Sat Oct 27 09:57:26 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 26 Oct 2001 16:57:26 -0700 (PDT)
Subject: Please test snapshots for 3.0 release
In-Reply-To: <riqk7xyt78d.fsf@aqualene.uio.no>
Message-ID: <Pine.HPX.4.40.0110261650520.7815-100000@jenny>

On 14 Oct 2001, Sturle Sunde wrote:
:I have tested with native compilers on six different platforms, and
:get lot's of warnings (mostly prototype/argument mismatches).

after 3.0, we might revisit this:

this patch changes the buffer/packet interface to use void* vs. char*.

Index: buffer.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.h,v
retrieving revision 1.9
diff -u -r1.9 buffer.h
--- buffer.h	2001/06/26 17:27:23	1.9
+++ buffer.h	2001/08/09 17:50:07
@@ -17,7 +17,7 @@
 #define BUFFER_H

 typedef struct {
-	char	*buf;		/* Buffer for data. */
+	u_char	*buf;		/* Buffer for data. */
 	u_int	 alloc;		/* Number of bytes allocated for data. */
 	u_int	 offset;	/* Offset of first byte containing data. */
 	u_int	 end;		/* Offset of last byte containing data. */
@@ -28,12 +28,12 @@
 void	 buffer_free(Buffer *);

 u_int	 buffer_len(Buffer *);
-char	*buffer_ptr(Buffer *);
+void	*buffer_ptr(Buffer *);

-void	 buffer_append(Buffer *, const char *, u_int);
-void	 buffer_append_space(Buffer *, char **, u_int);
+void	 buffer_append(Buffer *, const void *, u_int);
+void	*buffer_append_space(Buffer *, u_int);

-void	 buffer_get(Buffer *, char *, u_int);
+void	 buffer_get(Buffer *, void *, u_int);

 void	 buffer_consume(Buffer *, u_int);
 void	 buffer_consume_end(Buffer *, u_int);
Index: buffer.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.13
diff -u -r1.13 buffer.c
--- buffer.c	2001/04/12 19:15:24	1.13
+++ buffer.c	2001/08/09 17:50:07
@@ -53,11 +53,11 @@
 /* Appends data to the buffer, expanding it if necessary. */

 void
-buffer_append(Buffer *buffer, const char *data, u_int len)
+buffer_append(Buffer *buffer, const void *data, u_int len)
 {
-	char *cp;
-	buffer_append_space(buffer, &cp, len);
-	memcpy(cp, data, len);
+	void *p;
+	p = buffer_append_space(buffer, len);
+	memcpy(p, data, len);
 }

 /*
@@ -66,9 +66,11 @@
  * to the allocated region.
  */

-void
-buffer_append_space(Buffer *buffer, char **datap, u_int len)
+void *
+buffer_append_space(Buffer *buffer, u_int len)
 {
+	void *p;
+
 	/* If the buffer is empty, start using it from the beginning. */
 	if (buffer->offset == buffer->end) {
 		buffer->offset = 0;
@@ -77,9 +79,9 @@
 restart:
 	/* If there is enough space to store all data, store it now. */
 	if (buffer->end + len < buffer->alloc) {
-		*datap = buffer->buf + buffer->end;
+		p = buffer->buf + buffer->end;
 		buffer->end += len;
-		return;
+		return p;
 	}
 	/*
 	 * If the buffer is quite empty, but all data is at the end, move the
@@ -96,6 +98,7 @@
 	buffer->alloc += len + 32768;
 	buffer->buf = xrealloc(buffer->buf, buffer->alloc);
 	goto restart;
+	/* NOTREACHED */
 }

 /* Returns the number of bytes of data in the buffer. */
@@ -109,7 +112,7 @@
 /* Gets data from the beginning of the buffer. */

 void
-buffer_get(Buffer *buffer, char *buf, u_int len)
+buffer_get(Buffer *buffer, void *buf, u_int len)
 {
 	if (len > buffer->end - buffer->offset)
 		fatal("buffer_get: trying to get more bytes %d than in buffer %d",
@@ -140,7 +143,7 @@

 /* Returns a pointer to the first used byte in the buffer. */

-char *
+void *
 buffer_ptr(Buffer *buffer)
 {
 	return buffer->buf + buffer->offset;
Index: bufaux.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/bufaux.h,v
retrieving revision 1.13
diff -u -r1.13 bufaux.h
--- bufaux.h	2001/06/26 17:27:22	1.13
+++ bufaux.h	2001/08/09 17:50:07
@@ -32,7 +32,7 @@
 int     buffer_get_char(Buffer *);
 void    buffer_put_char(Buffer *, int);

-char   *buffer_get_string(Buffer *, u_int *);
+void   *buffer_get_string(Buffer *, u_int *);
 void    buffer_put_string(Buffer *, const void *, u_int);
 void	buffer_put_cstring(Buffer *, const char *);

Index: bufaux.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/bufaux.c,v
retrieving revision 1.17
diff -u -r1.17 bufaux.c
--- bufaux.c	2001/01/21 19:05:45	1.17
+++ bufaux.c	2001/08/09 17:50:07
@@ -187,11 +187,11 @@
  * will be stored there.  A null character will be automatically appended
  * to the returned string, and is not counted in length.
  */
-char *
+void *
 buffer_get_string(Buffer *buffer, u_int *length_ptr)
 {
 	u_int len;
-	char *value;
+	u_char *value;
 	/* Get the length. */
 	len = buffer_get_int(buffer);
 	if (len > 256 * 1024)
Index: packet.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/packet.h,v
retrieving revision 1.25
diff -u -r1.25 packet.h
--- packet.h	2001/06/26 17:27:24	1.25
+++ packet.h	2001/08/09 17:50:08
@@ -35,9 +35,9 @@
 void     packet_put_int(u_int value);
 void     packet_put_bignum(BIGNUM * value);
 void     packet_put_bignum2(BIGNUM * value);
-void     packet_put_string(const char *buf, u_int len);
+void     packet_put_string(const void *buf, u_int len);
 void     packet_put_cstring(const char *str);
-void     packet_put_raw(const char *buf, u_int len);
+void     packet_put_raw(const void *buf, u_int len);
 void     packet_send(void);

 int      packet_read(int *payload_len_ptr);
@@ -49,8 +49,8 @@
 u_int	 packet_get_int(void);
 void     packet_get_bignum(BIGNUM * value, int *length_ptr);
 void     packet_get_bignum2(BIGNUM * value, int *length_ptr);
-char	*packet_get_raw(int *length_ptr);
-char    *packet_get_string(u_int *length_ptr);
+void	*packet_get_raw(int *length_ptr);
+void	*packet_get_string(u_int *length_ptr);
 void     packet_disconnect(const char *fmt,...) __attribute__((format(printf, 1, 2)));
 void     packet_send_debug(const char *fmt,...) __attribute__((format(printf, 1, 2)));

Index: packet.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/packet.c,v
retrieving revision 1.69
diff -u -r1.69 packet.c
--- packet.c	2001/06/25 08:25:38	1.69
+++ packet.c	2001/08/09 17:50:15
@@ -326,7 +326,7 @@
 	buffer_put_int(&outgoing_packet, value);
 }
 void
-packet_put_string(const char *buf, u_int len)
+packet_put_string(const void *buf, u_int len)
 {
 	buffer_put_string(&outgoing_packet, buf, len);
 }
@@ -336,7 +336,7 @@
 	buffer_put_cstring(&outgoing_packet, str);
 }
 void
-packet_put_raw(const char *buf, u_int len)
+packet_put_raw(const void *buf, u_int len)
 {
 	buffer_append(&outgoing_packet, buf, len);
 }
@@ -409,7 +409,7 @@
 	/* Append to output. */
 	PUT_32BIT(buf, len);
 	buffer_append(&output, buf, 4);
-	buffer_append_space(&output, &cp, buffer_len(&outgoing_packet));
+	cp = buffer_append_space(&output, buffer_len(&outgoing_packet));
 	cipher_encrypt(&send_context, cp, buffer_ptr(&outgoing_packet),
 		       buffer_len(&outgoing_packet));

@@ -533,7 +533,7 @@
 	padlen = block_size - (len % block_size);
 	if (padlen < 4)
 		padlen += block_size;
-	buffer_append_space(&outgoing_packet, &cp, padlen);
+	cp = buffer_append_space(&outgoing_packet, padlen);
 	if (enc && enc->cipher->number != SSH_CIPHER_NONE) {
 		/* random padding */
 		for (i = 0; i < padlen; i++) {
@@ -561,7 +561,7 @@
 		DBG(debug("done calc MAC out #%d", seqnr));
 	}
 	/* encrypt packet and append to output buffer. */
-	buffer_append_space(&output, &cp, buffer_len(&outgoing_packet));
+	cp = buffer_append_space(&output, buffer_len(&outgoing_packet));
 	cipher_encrypt(&send_context, cp, buffer_ptr(&outgoing_packet),
 	    buffer_len(&outgoing_packet));
 	/* append unencrypted MAC */
@@ -721,7 +721,7 @@

 	/* Decrypt data to incoming_packet. */
 	buffer_clear(&incoming_packet);
-	buffer_append_space(&incoming_packet, &cp, padded_len);
+	cp = buffer_append_space(&incoming_packet, padded_len);
 	cipher_decrypt(&receive_context, cp, buffer_ptr(&input), padded_len);

 	buffer_consume(&input, padded_len);
@@ -790,7 +790,7 @@
 		if (buffer_len(&input) < block_size)
 			return SSH_MSG_NONE;
 		buffer_clear(&incoming_packet);
-		buffer_append_space(&incoming_packet, &cp, block_size);
+		cp = buffer_append_space(&incoming_packet, block_size);
 		cipher_decrypt(&receive_context, cp, buffer_ptr(&input),
 		    block_size);
 		ucp = (u_char *) buffer_ptr(&incoming_packet);
@@ -819,7 +819,7 @@
 	fprintf(stderr, "read_poll enc/full: ");
 	buffer_dump(&input);
 #endif
-	buffer_append_space(&incoming_packet, &cp, need);
+	cp = buffer_append_space(&incoming_packet, need);
 	cipher_decrypt(&receive_context, cp, buffer_ptr(&input), need);
 	buffer_consume(&input, need);
 	/*
@@ -839,7 +839,8 @@
 		log("incoming seqnr wraps around");

 	/* get padlen */
-	cp = buffer_ptr(&incoming_packet) + 4;
+	cp = buffer_ptr(&incoming_packet);
+	cp += 4;
 	padlen = (u_char) *cp;
 	DBG(debug("input: padlen %d", padlen));
 	if (padlen < 4)
@@ -983,7 +984,7 @@
 	*length_ptr = buffer_get_bignum2(&incoming_packet, value);
 }

-char *
+void *
 packet_get_raw(int *length_ptr)
 {
 	int bytes = buffer_len(&incoming_packet);
@@ -1005,7 +1006,7 @@
  * integer into which the length of the string is stored.
  */

-char *
+void *
 packet_get_string(u_int *length_ptr)
 {
 	return buffer_get_string(&incoming_packet, length_ptr);
Index: authfile.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/authfile.c,v
retrieving revision 1.37
diff -u -r1.37 authfile.c
--- authfile.c	2001/06/23 15:12:17	1.37
+++ authfile.c	2001/08/09 17:50:15
@@ -128,7 +128,7 @@
 	buffer_put_cstring(&encrypted, comment);

 	/* Allocate space for the private part of the key in the buffer. */
-	buffer_append_space(&encrypted, &cp, buffer_len(&buffer));
+	cp = buffer_append_space(&encrypted, buffer_len(&buffer));

 	cipher_set_key_string(&ciphercontext, cipher, passphrase);
 	cipher_encrypt(&ciphercontext, (u_char *) cp,
@@ -239,7 +239,7 @@
 	lseek(fd, (off_t) 0, SEEK_SET);

 	buffer_init(&buffer);
-	buffer_append_space(&buffer, &cp, len);
+	cp = buffer_append_space(&buffer, len);

 	if (read(fd, cp, (size_t) len) != (size_t) len) {
 		debug("Read from key file %.200s failed: %.100s", filename,
@@ -324,7 +324,7 @@
 	lseek(fd, (off_t) 0, SEEK_SET);

 	buffer_init(&buffer);
-	buffer_append_space(&buffer, &cp, len);
+	cp = buffer_append_space(&buffer, len);

 	if (read(fd, cp, (size_t) len) != (size_t) len) {
 		debug("Read from key file %.200s failed: %.100s", filename,
@@ -378,7 +378,7 @@
 	}
 	/* Initialize space for decrypted data. */
 	buffer_init(&decrypted);
-	buffer_append_space(&decrypted, &cp, buffer_len(&buffer));
+	cp = buffer_append_space(&decrypted, buffer_len(&buffer));

 	/* Rest of the buffer is encrypted.  Decrypt it using the passphrase. */
 	cipher_set_key_string(&ciphercontext, cipher, passphrase);




From tim at multitalents.net  Sat Oct 27 10:15:27 2001
From: tim at multitalents.net (Tim Rice)
Date: Fri, 26 Oct 2001 17:15:27 -0700 (PDT)
Subject: problems building on solaris 2.6
In-Reply-To: <200110262104.f9QL45093900@merlot.juniper.net>
Message-ID: <Pine.UW2.4.40.9.0110261711200.19611-100000@uw711.int.multitalents.net>

On Fri, 26 Oct 2001, Mark D. Baushke wrote:

> Using the latest cvs sources, the compilation of ssh.c fails.
[snip]
> 	-- Mark
>
> % ./configure --prefix=/usr/local/openssh-3.0p1 --with-pid-dir \
>   --with-ipv4-default --sysconfdir=/etc/openssh \
>   --with-libs=/usr/local/zlib-1.1.3/lib/libz.a \
>   --with-libs=/usr/local/openssl-0.9.6b/lib/libssl.a \
>   --with-cflags=-I/usr/local/zlib-1.1.3/include \
>   --with-cflags=-I/usr/local/openssl-0.9.6b/include
[snip]
> checking for OpenSSL directory... /usr/local/openssl

I think you want
% ./configure --prefix=/usr/local/openssh-3.0p1 \
  --with-ipv4-default --sysconfdir=/etc/openssh \
  --with-zlib=/usr/local/zlib-1.1.3 \
  --with-ssl-dir=/usr/local/openssl-0.9.6b

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From tim at multitalents.net  Sat Oct 27 10:35:33 2001
From: tim at multitalents.net (Tim Rice)
Date: Fri, 26 Oct 2001 17:35:33 -0700 (PDT)
Subject: minor problem in scard/Makefile when srcdir != objdir
In-Reply-To: <200110261731.f9QHVr081350@merlot.juniper.net>
Message-ID: <Pine.UW2.4.40.9.0110261733430.19611-100000@uw711.int.multitalents.net>

On Fri, 26 Oct 2001, Mark D. Baushke wrote:

> Greetings,
>
> There is a minor glitch when --src is not the same as the build tree
> location (sometimes needed if you are going to be root for the install
> and the sources are on an NFS disk somewhere that does not trust root
> on the machine doing the install).
>

Commited. Thanks.


-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From mdb at juniper.net  Sat Oct 27 12:03:29 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 26 Oct 2001 19:03:29 -0700
Subject: problems building on solaris 2.6 
In-Reply-To: Mail from <mouring@etoh.eviladmin.org> 
             dated Fri, 26 Oct 2001 16:30:34 CDT
             <Pine.BSO.4.33.0110261630000.27599-100000@etoh.eviladmin.org> 
Message-ID: <200110270203.f9R23T008607@merlot.juniper.net>

Hi Ben,

The following patch seems to fix the problem for my Solaris 2.6 system
which seems to need to have _LARGEFILE64_SOURCE defined if a
'#define _FILE_OFFSET_BITS 64' is added to the config.h file.

It would be nice if this were handled as a part of the
AC_SYS_LARGEFILE tests... 

Perhaps someone could pass this along to the correct people working on
autoconf?

	Enjoy!
	-- Mark

Index: acconfig.h
===================================================================
RCS file: /cvs/openssh_cvs/acconfig.h,v
retrieving revision 1.118
diff -u -p -r1.118 acconfig.h
--- acconfig.h	2001/10/22 00:53:59	1.118
+++ acconfig.h	2001/10/27 01:39:03
@@ -332,6 +332,9 @@
 /* Define if you want smartcard support */
 #undef SMARTCARD
 
+/* Define if _FILE_OFFSET_BITS also needs _LARGEFILE64_SOURCE defined */
+#undef _LARGEFILE64_SOURCE
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line ************** */
Index: configure.ac
===================================================================
RCS file: /cvs/openssh_cvs/configure.ac,v
retrieving revision 1.2
diff -u -p -r1.2 configure.ac
--- configure.ac	2001/10/25 17:01:31	1.2
+++ configure.ac	2001/10/27 01:39:03
@@ -24,6 +24,32 @@ AC_PATH_PROG(TEST_MINUS_S_SH, sh)
 
 # System features
 AC_SYS_LARGEFILE
+if test "$ac_cv_sys_file_offset_bits" != no; then
+	AC_MSG_CHECKING(if _LARGEFILE64_SOURCE is needed)
+	AC_TRY_COMPILE(
+		[
+#include "confdefs.h"
+#include <sys/resource.h>
+		],
+		[ struct rlimit rlim; ],
+		[ AC_MSG_RESULT(no) ],
+		[ 
+		AC_TRY_COMPILE(
+			[
+#include "confdefs.h"
+#define _LARGEFILE64_SOURCE
+#include <sys/resource.h>
+			],
+			[ struct rlimit rlim; ],
+			[ 
+				AC_MSG_RESULT(yes)
+				AC_DEFINE(_LARGEFILE64_SOURCE)
+			],
+			[ AC_MSG_RESULT(problems with struct rlimit found) ]
+		)
+		]
+	)
+fi
 
 if test -z "$AR" ; then
 	AC_MSG_ERROR([*** 'ar' missing, please install or fix your \$PATH ***])


From stevesk at pobox.com  Sat Oct 27 12:24:06 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Fri, 26 Oct 2001 19:24:06 -0700 (PDT)
Subject: New password echoes on Sol8
In-Reply-To: <20011027000430.A4716@faui02.informatik.uni-erlangen.de>
Message-ID: <Pine.HPX.4.40.0110261919370.7815-100000@jenny>

On Sat, 27 Oct 2001, Markus Friedl wrote:
:the call is wrong:
:	1) read_passphrase() does already call xstrdup
:	2) 1 is passed as a flag to read_passphrase(), and
:	   1 means: RP_ECHO so echo is not turned off.

thanks for strdup() not needed.  can PAM users test this? i think
RP_ALLOW_STDIN is what we want vs. 0.

Index: auth-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth-pam.c,v
retrieving revision 1.37
diff -u -r1.37 auth-pam.c
--- auth-pam.c	2001/04/23 18:38:37	1.37
+++ auth-pam.c	2001/10/27 02:17:57
@@ -87,7 +87,7 @@
  * messages with into __pam_msg.  This is used during initial
  * authentication to bypass the normal PAM password prompt.
  *
- * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase(prompt, 1)
+ * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase()
  * and outputs messages to stderr. This mode is used if pam_chauthtok()
  * is called to update expired passwords.
  */
@@ -146,9 +146,9 @@
 				reply[count].resp_retcode = PAM_SUCCESS;
 				break;
 			case PAM_PROMPT_ECHO_OFF:
-				reply[count].resp = xstrdup(
-				    read_passphrase(PAM_MSG_MEMBER(msg, count,
-				    msg), 1));
+				reply[count].resp =
+					read_passphrase(PAM_MSG_MEMBER(msg,
+					    count, msg), RP_ALLOW_STDIN);
 				reply[count].resp_retcode = PAM_SUCCESS;
 				break;
 			case PAM_ERROR_MSG:




From Robert.Dahlem at siemens.com  Sun Oct 28 01:32:55 2001
From: Robert.Dahlem at siemens.com (Robert Dahlem)
Date: Sat, 27 Oct 2001 17:32:55 +0200
Subject: [PATCH] some patches for Fujitsu-Siemens ReliantUNIX, minor fixes and XXXes
In-Reply-To: <Pine.UW2.4.40.9.0110221020280.8464-100000@uw711.int.multitalents.net>
Message-ID: <200110271535.f9RFZmf25869@mail2.siemens.de>

Tim,

On Fri, 26 Oct 2001 11:27:03 -0700 (PDT), Tim Rice wrote:

>> attached please find some patches for ReliantUNIX. This was tested 
>> under Reliant UNIX V5.43C40 with Compiler CDSDEV V2.0C00.

>> Here is what I did:

>> - there is a common misunderstanding how to use /usr/libucb/libucb.a:

>> There are some library functions only in libucb.a under ReliantUNIX, 
>> so one needs to bind it. The problem is: there are some other 
>> functions in this library you should never bind from there (i.e. 
>> fopen()). The trick is to first search through libc.so and then 
>> through libucb.a. Don't let ld search in /usr/ucblib, it will 
>> virtually always produce nonsense.

>I suspect you could remove the libucb stuff altogether and it would 
>work.

Yes, you are right. In 2.9p2 it was still needed and I did not check for 
this in 2.9.9p2. In 3.0p1 (snapshot from yesterday) it's obsolete. Seems 
to have to do with a better behaviour of autoconf-2.52 ...

>Do you really need -ldl ?

No longer (you were answering to my old mail from August). My thanks go 
to Lutz for his hint how to compile OpenSSL correctly. :-)

Attached please find the complete patch for ReliantUNIX and 
/etc/default/login.

Regards,
        Robert


-- 
Robert.Dahlem at siemens.com
Siemens Business Services - FS CBS KORDOBA-Outsourcing
Tel: +49-69-797-6530  Fax: +49-69-797-6599
----------------------------------------------------------------------
Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email
software; far better than Outlook. Try it sometime.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 4695 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011027/fefb9595/attachment.obj 

From markus at openbsd.org  Sun Oct 28 04:36:34 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 27 Oct 2001 19:36:34 +0200
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>; from ed@UDel.Edu on Fri, Oct 26, 2001 at 04:12:35PM -0400
References: <Pine.SOL.4.30.0110261554490.2476-100000@mahler.udel.edu>
Message-ID: <20011027193634.B19754@folly>

On Fri, Oct 26, 2001 at 04:12:35PM -0400, Ed Phillips wrote:
> I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> version that just calls getpassphrase().  It appears to solve the echo
> problem when the user tries to login in interactive mode and needs to
> change their password.
> 
> Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:
> 
> #define HAVE_GETPASSPHRASE

no.

the bug should be fixed instead.

we already have enough waste in openssh.


From tim at multitalents.net  Sun Oct 28 04:56:46 2001
From: tim at multitalents.net (Tim Rice)
Date: Sat, 27 Oct 2001 10:56:46 -0700 (PDT)
Subject: [PATCH] some patches for Fujitsu-Siemens ReliantUNIX, minor
 fixes and XXXes
In-Reply-To: <200110271535.f9RFZmf25869@mail2.siemens.de>
Message-ID: <Pine.UW2.4.40.9.0110271052130.22688-100000@uw711.int.multitalents.net>

On Sat, 27 Oct 2001, Robert Dahlem wrote:

> Tim,
>
> On Fri, 26 Oct 2001 11:27:03 -0700 (PDT), Tim Rice wrote:
[snip]
>
> >I suspect you could remove the libucb stuff altogether and it would
> >work.
>
> Yes, you are right. In 2.9p2 it was still needed and I did not check for
> this in 2.9.9p2. In 3.0p1 (snapshot from yesterday) it's obsolete. Seems
> to have to do with a better behaviour of autoconf-2.52 ...
>
> >Do you really need -ldl ?
>
> No longer (you were answering to my old mail from August). My thanks go
> to Lutz for his hint how to compile OpenSSL correctly. :-)

I've commited the configure.ac changes to remove libucb.
I think the /etc/default/login parts will have to wait until after the
3.0 release.

>
> Attached please find the complete patch for ReliantUNIX and
> /etc/default/login.
>
> Regards,
>         Robert
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From duvall at emufarm.org  Sun Oct 28 10:37:37 2001
From: duvall at emufarm.org (Danek Duvall)
Date: Sat, 27 Oct 2001 16:37:37 -0700
Subject: Processes left unkilled (portable)
Message-ID: <20011027163737.B3369@lorien.emufarm.org>

I just came across this problem (on Linux, using OpenSSH 2.9.9p2).  Run

    ssh <host> "tail -f <file> | grep <regexp>"

Let it connect, and then hit ^C.  If you look on <host>, the tail
process has been orphaned, but grep, which was its parent, and a direct
child of sshd, is gone.

It appears that the immediate child of the sshd (grep) is sent a SIGTERM
(on line 1983 of session.c, in the function session_close_by_channel()),
but its child (tail) never finds out about that death, and stays happily
alive.

Killing the process group seems to work around the problem, but I
haven't actually tried doing that in the code by negating the child's
pid in the kill() statement, just killing the process group from the
commandline.

Is this actually a bug, or is it a desired feature?

Thanks,
Danek


From stevesk at pobox.com  Sun Oct 28 10:40:05 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Sat, 27 Oct 2001 16:40:05 -0700 (PDT)
Subject: setlinebuf vs. setvbuf: Caldera OpenUNIX8.
In-Reply-To: <20011026125549.A29390@lerami.lerctr.org>
Message-ID: <Pine.HPX.4.40.0110271635560.1389-100000@jenny>

On Fri, 26 Oct 2001, Larry Rosenman wrote:
:I tried to compile OpenSSH 2.9.9p2 on my Caldera OpenUNIX8 system and
:it couldn't find setlinebuf.  setlinebuf is a BSD compatibility
:function.  It was called from sftp-int.c.  Looking at the code, there
:is a #ifdef for HAVE_SETVBUF, but apparently configure isn't set to
:look for setvbuf (which we DO have).
:
:I added a #define HAVE_SETVBUF 1 to config.h, and this problem goes
:away.

configure does check for setvbuf, so i don't know what i wrong.  i wonder
if the #ifdefs can be removed?  what systems do not have setvbuf()?



From markus at openbsd.org  Sun Oct 28 20:20:57 2001
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 28 Oct 2001 10:20:57 +0100
Subject: Processes left unkilled (portable)
In-Reply-To: <20011027163737.B3369@lorien.emufarm.org>; from duvall@emufarm.org on Sat, Oct 27, 2001 at 04:37:37PM -0700
References: <20011027163737.B3369@lorien.emufarm.org>
Message-ID: <20011028102057.B7553@folly>

On Sat, Oct 27, 2001 at 04:37:37PM -0700, Danek Duvall wrote:
> I just came across this problem (on Linux, using OpenSSH 2.9.9p2).  Run
> 
>     ssh <host> "tail -f <file> | grep <regexp>"
> 
> Let it connect, and then hit ^C.  If you look on <host>, the tail
> process has been orphaned, but grep, which was its parent, and a direct
> child of sshd, is gone.
> 
> It appears that the immediate child of the sshd (grep) is sent a SIGTERM
> (on line 1983 of session.c, in the function session_close_by_channel()),
> but its child (tail) never finds out about that death, and stays happily
> alive.

the killing has been removed completely.
could you please try a recent snapshot from
	http://www.openssh.com/portable.html
thanks, -m


From djm at mindrot.org  Sun Oct 28 22:44:41 2001
From: djm at mindrot.org (Damien Miller)
Date: Sun, 28 Oct 2001 22:44:41 +1100 (EST)
Subject: Expired passwords on Solaris with PAM
In-Reply-To: <Pine.SOL.4.30.0110261411260.19505-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110282244290.2031-100000@mothra.mindrot.org>

On Fri, 26 Oct 2001, Ed Phillips wrote:

> I've been doing so more tests with 2.9.9p2 on Sol8.  Here are my
> finding so far:
> 
> When a user needs to change his password and trys to run a command in
> non-interactive mode, it just succeeds without even trying to prompt the
> user for a new password.  Damien submitted a fix - it works for me (is it
> going into CVS?).

Just committed.

-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 ler at lerctr.org  Mon Oct 29 03:24:50 2001
From: ler at lerctr.org (Larry Rosenman)
Date: Sun, 28 Oct 2001 10:24:50 -0600
Subject: setlinebuf vs. setvbuf: Caldera OpenUNIX8.
In-Reply-To: <Pine.HPX.4.40.0110271635560.1389-100000@jenny>
References: <20011026125549.A29390@lerami.lerctr.org> <Pine.HPX.4.40.0110271635560.1389-100000@jenny>
Message-ID: <20011028102450.B28066@lerami.lerctr.org>

* Kevin Steves <stevesk at pobox.com> [011027 19:40]:
> On Fri, 26 Oct 2001, Larry Rosenman wrote:
> :I tried to compile OpenSSH 2.9.9p2 on my Caldera OpenUNIX8 system and
> :it couldn't find setlinebuf.  setlinebuf is a BSD compatibility
> :function.  It was called from sftp-int.c.  Looking at the code, there
> :is a #ifdef for HAVE_SETVBUF, but apparently configure isn't set to
> :look for setvbuf (which we DO have).
> :
> :I added a #define HAVE_SETVBUF 1 to config.h, and this problem goes
> :away.
> 
> configure does check for setvbuf, so i don't know what i wrong.  i wonder
> if the #ifdefs can be removed?  what systems do not have setvbuf()?
In the configure output, i could *NOT* find setvbuf mentioned at all. 

I wonder what went wrong.

LER

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler at lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


From duvall at emufarm.org  Mon Oct 29 04:13:50 2001
From: duvall at emufarm.org (Danek Duvall)
Date: Sun, 28 Oct 2001 09:13:50 -0800
Subject: Processes left unkilled (portable)
In-Reply-To: <20011028102057.B7553@folly>; from markus@openbsd.org on Sun, Oct 28, 2001 at 10:20:57AM +0100
References: <20011027163737.B3369@lorien.emufarm.org> <20011028102057.B7553@folly>
Message-ID: <20011028091350.A818@lorien.emufarm.org>

On Sun, Oct 28, 2001 at 10:20:57AM +0100, Markus Friedl wrote:

> the killing has been removed completely.
> could you please try a recent snapshot from
> 	http://www.openssh.com/portable.html

Indeed, now both processes are orphaned.  That's not the behavior I'd
expect, honestly.  I would expect that the command started on the remote
end would be the leader of its own process group, and if it didn't want
it and its children to die, that it would call setsid() or setpgid().

I didn't see anything in the ChangeLog that addressed this explicitly;
is there a reason for it?

Thanks,
Danek


From a_ghsek at yahoo.co.in  Mon Oct 29 16:05:26 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Mon, 29 Oct 2001 05:05:26 +0000 (GMT)
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011025123808.A10503@faui02.informatik.uni-erlangen.de>
Message-ID: <20011029050526.60219.qmail@web8005.mail.in.yahoo.com>


Hi,
   Sorry for not the delayed feedback. It was official
holiday for the past 3 days. OK. 
sftp -s /path/to/sftp-server host 
didn't work either.
The same problem - after authentication, prints sftp>
prompt and then exits. Iam sending the debug output of
both the server and sftp client.
-Hari.

 --- Markus Friedl <markus at openbsd.org> wrote: > On
Thu, Oct 25, 2001 at 11:31:18AM +0100, hari sekar
> wrote:
> >  --- Markus Friedl <markus at openbsd.org> wrote: > 
> > > what does
> > > 	ssh -2 host /path/to/sftp-server
> > > say? 
> > 
> >   Yes. I've tried this before, but the client just
> > hangs, and after a series of "enter" keys, prints 
> > "bad message"
> > and exits.
> 
> ok. that's ok.
> 
> now try
> 	sftp -s /path/to/sftp-server host
> 
> -m 

sftp client debug message on LynxOS:

lynxos$ sftp -v -s /usr/local/libexec/sftp-server
hari at hari
Connecting to hari...
debug1: SSH args "ssh -l hari -v hari -oForwardX11=no
-oForwardAgent=no -oProtocol=2
/usr/local/libexec/sftp-server"
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL
0x0090600f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 7 geteuid 7 anon 1
debug1: Connecting to hari [192.168.0.126] port 22.
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/hari/.ssh/id_rsa type -1
debug1: identity file /home/hari/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
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: 134/256
debug1: bits set: 1005/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hari' is known and matches the RSA host
key.
debug1: Found key in /home/hari/.ssh/known_hosts2:5
debug1: bits set: 997/2049
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 privkey: /home/hari/.ssh/id_rsa
debug1: try pubkey: /home/hari/.ssh/id_dsa
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password
hari at hari's password:
debug1: ssh-userauth2 successful: method password
debug1: fd 4 setting O_NONBLOCK
debug1: fd 5 IS O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Sending command:
/usr/local/libexec/sftp-server
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug1: PAM establishing creds
Environment:
  USER=hari
  LOGNAME=hari
  HOME=/home/hari
  PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
  MAIL=/var/mail/hari
  SHELL=/bin/bash
  SSH_CLIENT=192.168.0.23 1055 22
sftp>
debug1: channel 0: read<=0 rfd 4 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
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)

debug1: channel_free: channel 0: dettaching channel
user
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes
in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0,
stderr 0.0
debug1: Exit status 0
lynxos$

sshd server debug message on Redhat Linux system:

linux# sshd -d
debug1: Seeding random number generator
debug1: sshd version OpenSSH_2.9p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
socket: Invalid argument
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging
mode.
Connection from 192.168.0.23 port 1055
debug1: Client protocol version 2.0; client software
version OpenSSH_2.9p2
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.9p2
debug1: Rhosts Authentication disabled, originating
port not trusted.
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 132/256
debug1: bits set: 997/2049
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1005/2049
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
debug1: userauth-request for user hari service
ssh-connection method none
debug1: attempt 0 failures 0
debug1: Starting up PAM with username "hari"
debug1: PAM setting rhost to "ists_ibm23"
Failed none for hari from 192.168.0.23 port 1055 ssh2
debug1: userauth-request for user hari service
ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 501/501 (e=0)
debug1: restore_uid
Failed publickey for hari from 192.168.0.23 port 1055
ssh2
debug1: userauth-request for user hari service
ssh-connection method password
debug1: attempt 2 failures 2
debug1: PAM Password authentication accepted for user
"hari"
Accepted password for hari from 192.168.0.23 port 1055
ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan
0 win 65536 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0
request exec reply 0
debug1: PAM establishing creds
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 9486
debug1: session_exit_message: session 0 channel 0 pid
9486
debug1: session_exit_message: release channel 0
debug1: session_free: session 0 pid 9486
debug1: channel 0: read<=0 rfd 7 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: channel 0: send close
debug1: channel 0: rcvd close
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following
connections are open:
  #0 server-session (t4 r0 i8/0 o128/0 fd 7/7)

Connection closed by remote host.
Closing connection to 192.168.0.23
linux#




___________________________________________________________________
*NEW*   Yahoo! Messenger for SMS. Now on your ORANGE phone    *NEW*
        Visit http://in.mobile.yahoo.com/smsmgr_signin.html


From djm at mindrot.org  Mon Oct 29 17:09:30 2001
From: djm at mindrot.org (Damien Miller)
Date: Mon, 29 Oct 2001 17:09:30 +1100 (EST)
Subject: sftp interactive mode in LynxOS
In-Reply-To: <20011029050526.60219.qmail@web8005.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.33.0110291708510.14726-100000@mothra.mindrot.org>

On Mon, 29 Oct 2001, hari sekar wrote:

> 
> Hi,
>    Sorry for not the delayed feedback. It was official
> holiday for the past 3 days. OK. 
> sftp -s /path/to/sftp-server host 
> didn't work either.
> The same problem - after authentication, prints sftp>
> prompt and then exits. Iam sending the debug output of
> both the server and sftp client.

Can you redo your debug with "sftp -v -v -v"?

-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  Mon Oct 29 19:36:58 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 09:36:58 +0100
Subject: Processes left unkilled (portable)
In-Reply-To: <20011028091350.A818@lorien.emufarm.org>; from duvall@emufarm.org on Sun, Oct 28, 2001 at 09:13:50AM -0800
References: <20011027163737.B3369@lorien.emufarm.org> <20011028102057.B7553@folly> <20011028091350.A818@lorien.emufarm.org>
Message-ID: <20011029093658.A23828@faui02.informatik.uni-erlangen.de>

On Sun, Oct 28, 2001 at 09:13:50AM -0800, Danek Duvall wrote:
> On Sun, Oct 28, 2001 at 10:20:57AM +0100, Markus Friedl wrote:
> 
> > the killing has been removed completely.
> > could you please try a recent snapshot from
> > 	http://www.openssh.com/portable.html
> 
> Indeed, now both processes are orphaned.  That's not the behavior I'd
> expect, honestly.  I would expect that the command started on the remote
> end would be the leader of its own process group, and if it didn't want
> it and its children to die, that it would call setsid() or setpgid().
> 
> I didn't see anything in the ChangeLog that addressed this explicitly;
> is there a reason for it?

the killing was random and very wrong.

the remote commands should die when stdin/out close.

the processes are not killed in this case, otherwise
sshd would kill COMMAND in this case:
 ssh -2n localhost 'exec > /dev/null 2>&1; sleep 10; COMMAND; exit 5'; echo ?

-markus


From Alexander.Dost at drkw.com  Mon Oct 29 21:12:11 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Mon, 29 Oct 2001 11:12:11 +0100
Subject: HostbasedAuthentication problem
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC03@ibfftc0006.is.de.dresdnerkb.com>

I'm trying to use HostbasedAuthentication. Running ssh -v -v -v user at host
the following error occurs:

debug3: authmethod_is_enabled hostbased
debug1: next auth method to try is hostbased
debug2: userauth_hostbased: chost <host>
debug2: we did not send a packet, disable method

What does this mean ? I enabled HostbasedAuthentication in
/etc/ssh/ssh_config and as it looks, this setting is used correctly. So
what's wrong ?

- Alex



From markus at openbsd.org  Mon Oct 29 21:19:46 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 11:19:46 +0100
Subject: HostbasedAuthentication problem
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC03@ibfftc0006.is.de.dresdnerkb.com>; from Alexander.Dost@drkw.com on Mon, Oct 29, 2001 at 11:12:11AM +0100
References: <3E16581537ABE44EB18C5206CE79F26B89BC03@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <20011029111946.A4122@faui02.informatik.uni-erlangen.de>

your ssh client cannot read the hostkey (setuid?).

On Mon, Oct 29, 2001 at 11:12:11AM +0100, Dost, Alexander wrote:
> I'm trying to use HostbasedAuthentication. Running ssh -v -v -v user at host
> the following error occurs:
> 
> debug3: authmethod_is_enabled hostbased
> debug1: next auth method to try is hostbased
> debug2: userauth_hostbased: chost <host>
> debug2: we did not send a packet, disable method
> 
> What does this mean ? I enabled HostbasedAuthentication in
> /etc/ssh/ssh_config and as it looks, this setting is used correctly. So
> what's wrong ?
> 
> - Alex
> 


From a_ghsek at yahoo.co.in  Mon Oct 29 21:22:12 2001
From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=)
Date: Mon, 29 Oct 2001 10:22:12 +0000 (GMT)
Subject: sftp interactive mode in LynxOS
In-Reply-To: <Pine.LNX.4.33.0110291708510.14726-100000@mothra.mindrot.org>
Message-ID: <20011029102212.61623.qmail@web8006.mail.in.yahoo.com>


 I attach herewith the debug output obtained by
sftp -v -v -v -s /path/to/sftp-server host
-Hari.

 --- Damien Miller <djm at mindrot.org> wrote: > On Mon,
29 Oct 2001, hari sekar wrote:
> 
> > 
> > Hi,
> >    Sorry for not the delayed feedback. It was
> official
> > holiday for the past 3 days. OK. 
> > sftp -s /path/to/sftp-server host 
> > didn't work either.
> > The same problem - after authentication, prints
> sftp>
> > prompt and then exits. Iam sending the debug
> output of
> > both the server and sftp client.
> 
> Can you redo your debug with "sftp -v -v -v"?
> 
> -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)
>  

sftp client on lynxos debug output:

lynxos>sftp -v -v -v -s /usr/local/libexec/sftp-server
hari at linux
Connecting to hari...
debug1: SSH args "ssh -l hari -v -v -v hari
-oForwardX11=no -oForwardAgent=no -oProtocol=2
/usr/local/libexec/sftp-server"
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL
0x0090600f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 7 geteuid 7 anon 1
debug1: Connecting to hari [192.168.0.126] port 22.
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: temporarily_use_uid: 7/2 (e=7)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/hari/.ssh/id_rsa type -1
debug3: No RSA1 key file /home/hari/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type
'-----BEGIN'
debug3: key_read: no key found
debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
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: 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,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
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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: 125/256
debug1: bits set: 1019/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename
/home/hari/.ssh/known_hosts2
debug3: check_host_in_hostfile: match line 5
debug3: check_host_in_hostfile: filename
/home/hari/.ssh/known_hosts2
debug3: key_read: type mismatch
debug3: check_host_in_hostfile: match line 3
debug1: Host 'hari' is known and matches the RSA host
key.
debug1: Found key in /home/hari/.ssh/known_hosts2:5
debug1: bits set: 1040/2049
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
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
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred
publickey,password,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred:
password,keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/hari/.ssh/id_rsa
debug3: no such identity: /home/hari/.ssh/id_rsa
debug1: try pubkey: /home/hari/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue:
publickey,password,keyboard-interactidebug2: we did
not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
hari at hari's password:
debug2: packet_inject_ignore: current 58
debug2: packet_inject_ignore: block 16 have 4 nb 4
mini 1 need 4
debug2: we sent a password packet, wait for reply
debug1: ssh-userauth2 successful: method password
debug1: fd 4 setting O_NONBLOCK
debug1: fd 5 IS O_NONBLOCK
debug1: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: client_init id 0 arg 0
debug1: Sending command:
/usr/local/libexec/sftp-server
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: Remote version: 3
debug3: Sent message fd 3 T:16 I:1
debug3: SSH_FXP_REALPATH . -> /home/hari
sftp>
debug1: channel 0: read<=0 rfd 4 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
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
  #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)

debug1: channel_free: channel 0: dettaching channel
user
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
lynxos>




___________________________________________________________________
*NEW*   Yahoo! Messenger for SMS. Now on your ORANGE phone    *NEW*
        Visit http://in.mobile.yahoo.com/smsmgr_signin.html


From Alexander.Dost at drkw.com  Mon Oct 29 21:46:54 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Mon, 29 Oct 2001 11:46:54 +0100
Subject: HostbasedAuthentication problem
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC04@ibfftc0006.is.de.dresdnerkb.com>

Ok. Seems to be a problem within the package we use for ssh. suid was not
set. Thanks.
Next step:
now I get:
debug2: xxx: chost <host>
debug2: we sent a hostbased packet, wait for reply
debug1: Remote: Accepted for <host> by /etc/hosts.equiv.
debug1: authentications that can continue:
publickey,password,keyboard-interactive,hostbased
debug2: userauth_hostbased: chost <host>
debug2: we did not send a packet, disable method
...
now it tries the other authentications..
Whats the problem this time ?

> -----Original Message-----
> From:	Markus Friedl [SMTP:markus at openbsd.org]
> Sent:	Monday, October 29, 2001 11:20
> To:	Dost, Alexander
> Cc:	openssh-unix-dev at mindrot.org
> Subject:	Re: HostbasedAuthentication problem
> 
> your ssh client cannot read the hostkey (setuid?).
> 
> On Mon, Oct 29, 2001 at 11:12:11AM +0100, Dost, Alexander wrote:
> > I'm trying to use HostbasedAuthentication. Running ssh -v -v -v
> user at host
> > the following error occurs:
> > 
> > debug3: authmethod_is_enabled hostbased
> > debug1: next auth method to try is hostbased
> > debug2: userauth_hostbased: chost <host>
> > debug2: we did not send a packet, disable method
> > 
> > What does this mean ? I enabled HostbasedAuthentication in
> > /etc/ssh/ssh_config and as it looks, this setting is used correctly. So
> > what's wrong ?
> > 
> > - Alex
> > 


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 markus at openbsd.org  Mon Oct 29 21:51:04 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 11:51:04 +0100
Subject: HostbasedAuthentication problem
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC04@ibfftc0006.is.de.dresdnerkb.com>; from Alexander.Dost@drkw.com on Mon, Oct 29, 2001 at 11:46:54AM +0100
References: <3E16581537ABE44EB18C5206CE79F26B89BC04@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <20011029115104.A7359@faui02.informatik.uni-erlangen.de>

sshd(8), ssh(1), check /etc/ssh_known_hosts*

On Mon, Oct 29, 2001 at 11:46:54AM +0100, Dost, Alexander wrote:
> Ok. Seems to be a problem within the package we use for ssh. suid was not
> set. Thanks.
> Next step:
> now I get:
> debug2: xxx: chost <host>
> debug2: we sent a hostbased packet, wait for reply
> debug1: Remote: Accepted for <host> by /etc/hosts.equiv.
> debug1: authentications that can continue:
> publickey,password,keyboard-interactive,hostbased
> debug2: userauth_hostbased: chost <host>
> debug2: we did not send a packet, disable method
> ...
> now it tries the other authentications..
> Whats the problem this time ?
> 
> > -----Original Message-----
> > From:	Markus Friedl [SMTP:markus at openbsd.org]
> > Sent:	Monday, October 29, 2001 11:20
> > To:	Dost, Alexander
> > Cc:	openssh-unix-dev at mindrot.org
> > Subject:	Re: HostbasedAuthentication problem
> > 
> > your ssh client cannot read the hostkey (setuid?).
> > 
> > On Mon, Oct 29, 2001 at 11:12:11AM +0100, Dost, Alexander wrote:
> > > I'm trying to use HostbasedAuthentication. Running ssh -v -v -v
> > user at host
> > > the following error occurs:
> > > 
> > > debug3: authmethod_is_enabled hostbased
> > > debug1: next auth method to try is hostbased
> > > debug2: userauth_hostbased: chost <host>
> > > debug2: we did not send a packet, disable method
> > > 
> > > What does this mean ? I enabled HostbasedAuthentication in
> > > /etc/ssh/ssh_config and as it looks, this setting is used correctly. So
> > > what's wrong ?
> > > 
> > > - Alex
> > > 
> 
> 
> 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 markus at openbsd.org  Mon Oct 29 22:46:58 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 12:46:58 +0100
Subject: HostbasedAuthentication problem
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC05@ibfftc0006.is.de.dresdnerkb.com>; from Alexander.Dost@drkw.com on Mon, Oct 29, 2001 at 12:26:11PM +0100
References: <3E16581537ABE44EB18C5206CE79F26B89BC05@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <20011029124658.A13694@faui02.informatik.uni-erlangen.de>

On Mon, Oct 29, 2001 at 12:26:11PM +0100, Dost, Alexander wrote:
> I use another base-dir for the installation, but in the corresponding etc
> directory is the file ssh_known_hosts, which is readable for everyone and
> contains the rsa and dsa keys, I got with ssh-keyscan from the machine,
> where I try to ssh from. Is there anything else to do ? I tried a link to
> /etc/ssh_known_hosts just to see if ssh always looks there...
> On the machine running sshd there is the hint that hostbased auth is tried
> first with ssh-dss and then with ssh-rsa, both of them fail, but no hint,
> why.

what is the sshd debug output?

make sure chost from the ssh output is in ssh_known_hosts

-m


From Alexander.Dost at drkw.com  Mon Oct 29 22:55:04 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Mon, 29 Oct 2001 12:55:04 +0100
Subject: HostbasedAuthentication problem
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC07@ibfftc0006.is.de.dresdnerkb.com>

Ok. That did it. There was a problem with short/long names. As we use DNS,
the names are resolved to long names, and ssh-keyscan delivered only short
names. Changing the ssh_known_hosts-entries to long names made it work.
Thanks a lot

- Alex

> -----Original Message-----
> From:	Markus Friedl [SMTP:markus at openbsd.org]
> Sent:	Monday, October 29, 2001 12:47
> To:	Dost, Alexander
> Cc:	openssh-unix-dev at mindrot.org
> Subject:	Re: HostbasedAuthentication problem
> 
> On Mon, Oct 29, 2001 at 12:26:11PM +0100, Dost, Alexander wrote:
> > I use another base-dir for the installation, but in the corresponding
> etc
> > directory is the file ssh_known_hosts, which is readable for everyone
> and
> > contains the rsa and dsa keys, I got with ssh-keyscan from the machine,
> > where I try to ssh from. Is there anything else to do ? I tried a link
> to
> > /etc/ssh_known_hosts just to see if ssh always looks there...
> > On the machine running sshd there is the hint that hostbased auth is
> tried
> > first with ssh-dss and then with ssh-rsa, both of them fail, but no
> hint,
> > why.
> 
> what is the sshd debug output?
> 
> make sure chost from the ssh output is in ssh_known_hosts
> 
> -m


From Alexander.Dost at drkw.com  Mon Oct 29 22:26:11 2001
From: Alexander.Dost at drkw.com (Dost, Alexander)
Date: Mon, 29 Oct 2001 12:26:11 +0100
Subject: HostbasedAuthentication problem
Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC05@ibfftc0006.is.de.dresdnerkb.com>

I use another base-dir for the installation, but in the corresponding etc
directory is the file ssh_known_hosts, which is readable for everyone and
contains the rsa and dsa keys, I got with ssh-keyscan from the machine,
where I try to ssh from. Is there anything else to do ? I tried a link to
/etc/ssh_known_hosts just to see if ssh always looks there...
On the machine running sshd there is the hint that hostbased auth is tried
first with ssh-dss and then with ssh-rsa, both of them fail, but no hint,
why.

> -----Original Message-----
> From:	Markus Friedl [SMTP:markus at openbsd.org]
> Sent:	Monday, October 29, 2001 11:51
> To:	Dost, Alexander
> Cc:	openssh-unix-dev at mindrot.org
> Subject:	Re: HostbasedAuthentication problem
> 
> sshd(8), ssh(1), check /etc/ssh_known_hosts*
> 
> On Mon, Oct 29, 2001 at 11:46:54AM +0100, Dost, Alexander wrote:
> > Ok. Seems to be a problem within the package we use for ssh. suid was
> not
> > set. Thanks.
> > Next step:
> > now I get:
> > debug2: xxx: chost <host>
> > debug2: we sent a hostbased packet, wait for reply
> > debug1: Remote: Accepted for <host> by /etc/hosts.equiv.
> > debug1: authentications that can continue:
> > publickey,password,keyboard-interactive,hostbased
> > debug2: userauth_hostbased: chost <host>
> > debug2: we did not send a packet, disable method
> > ...
> > now it tries the other authentications..
> > Whats the problem this time ?
> > 
> > > -----Original Message-----
> > > From:	Markus Friedl [SMTP:markus at openbsd.org]
> > > Sent:	Monday, October 29, 2001 11:20
> > > To:	Dost, Alexander
> > > Cc:	openssh-unix-dev at mindrot.org
> > > Subject:	Re: HostbasedAuthentication problem
> > > 
> > > your ssh client cannot read the hostkey (setuid?).
> > > 
> > > On Mon, Oct 29, 2001 at 11:12:11AM +0100, Dost, Alexander wrote:
> > > > I'm trying to use HostbasedAuthentication. Running ssh -v -v -v
> > > user at host
> > > > the following error occurs:
> > > > 
> > > > debug3: authmethod_is_enabled hostbased
> > > > debug1: next auth method to try is hostbased
> > > > debug2: userauth_hostbased: chost <host>
> > > > debug2: we did not send a packet, disable method
> > > > 
> > > > What does this mean ? I enabled HostbasedAuthentication in
> > > > /etc/ssh/ssh_config and as it looks, this setting is used correctly.
> So
> > > > what's wrong ?
> > > > 
> > > > - Alex
> > > > 
> > 
> > 
> > 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 dwd at bell-labs.com  Tue Oct 30 01:26:57 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Mon, 29 Oct 2001 08:26:57 -0600
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011027000924.A5122@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Sat, Oct 27, 2001 at 12:09:24AM +0200
References: <20011026161130.A28674@lucent.com> <20011027000924.A5122@faui02.informatik.uni-erlangen.de>
Message-ID: <20011029082657.A23424@lucent.com>

On Sat, Oct 27, 2001 at 12:09:24AM +0200, Markus Friedl wrote:
> On Fri, Oct 26, 2001 at 04:11:30PM -0500, Dave Dykstra wrote:
> > Because ForwardX11 and ForwardAgent are so useful but introduce risk when
> > used to a not well-secured server, I added a "warn" value to the ForwardX11
> > and ForwardAgent options which causes the ssh client to print a big warning
> > whenever the forwarding is actually used.  I plan to make "ForwardX11=warn"
> > the default in my ssh_config distribution.
> 
> why is this better then having
> 	ForwardX11=no
> and using
> 	-X
> to enable forwarding on a 'need' basis?


With "warn", you can still use forwarding even though you know a server is
not very well secured, and you will be notified if someone does actually
break into the server and try to take over the forwarding on your session.
It can give you a lot more peace of mind about using forwarding.  I know
many people who have well-secured clients, but have to log into not
well-secured servers and need the X forwarding to run applications there.
Their alternative now is to take the risk of enabling forwarding without
any kind of indication when it is being used.  True, they could enable
debugging instead but that spits out so much stuff it isn't very useful for
this purpose.

Do you see what I mean?  Years ago I asked for a feature like this for
ForwardAgent to the original maintainers of the ssh 1.2.X series, but it
didn't dawn on me at the time that ForwardX11 was as big a risk.  They
said back then they thought it should go into the 2.X series which they
had begun to work on but hadn't yet released.

- Dave Dykstra


From ed at UDel.Edu  Tue Oct 30 02:13:08 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 29 Oct 2001 10:13:08 -0500 (EST)
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110261646320.2476-100000@mahler.udel.edu>
Message-ID: <Pine.SOL.4.30.0110291012550.11999-100000@mahler.udel.edu>

It works for me!

	Ed

On Fri, 26 Oct 2001, Ed Phillips wrote:

> Date: Fri, 26 Oct 2001 16:47:18 -0400 (EDT)
> From: Ed Phillips <ed at UDel.Edu>
> To: Kevin Steves <stevesk at pobox.com>
> Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>
> Subject: Re: New password echoes on Sol8
>
> I'll try it first thing Monday...
>
> On Fri, 26 Oct 2001, Kevin Steves wrote:
>
> > Date: Fri, 26 Oct 2001 13:31:32 -0700 (PDT)
> > From: Kevin Steves <stevesk at pobox.com>
> > To: Ed Phillips <ed at UDel.Edu>
> > Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>
> > Subject: Re: New password echoes on Sol8
> >
> > On Fri, 26 Oct 2001, Ed Phillips wrote:
> > :I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> > :version that just calls getpassphrase().  It appears to solve the echo
> > :problem when the user tries to login in interactive mode and needs to
> > :change their password.
> > :
> > :Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:
> >
> > no!
> >
> > try this:
> >
> > Index: auth-pam.c
> > ===================================================================
> > RCS file: /var/cvs/openssh/auth-pam.c,v
> > retrieving revision 1.37
> > diff -u -r1.37 auth-pam.c
> > --- auth-pam.c	2001/04/23 18:38:37	1.37
> > +++ auth-pam.c	2001/10/26 20:30:42
> > @@ -87,7 +87,7 @@
> >   * messages with into __pam_msg.  This is used during initial
> >   * authentication to bypass the normal PAM password prompt.
> >   *
> > - * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase(prompt, 1)
> > + * OTHER mode handles PAM_PROMPT_ECHO_OFF with read_passphrase()
> >   * and outputs messages to stderr. This mode is used if pam_chauthtok()
> >   * is called to update expired passwords.
> >   */
> > @@ -148,7 +148,7 @@
> >  			case PAM_PROMPT_ECHO_OFF:
> >  				reply[count].resp = xstrdup(
> >  				    read_passphrase(PAM_MSG_MEMBER(msg, count,
> > -				    msg), 1));
> > +				    msg), RP_ALLOW_STDIN));
> >  				reply[count].resp_retcode = PAM_SUCCESS;
> >  				break;
> >  			case PAM_ERROR_MSG:
> >
>
> 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 markus at openbsd.org  Tue Oct 30 02:27:05 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 16:27:05 +0100
Subject: HostbasedAuthentication problem
In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC07@ibfftc0006.is.de.dresdnerkb.com>; from Alexander.Dost@drkw.com on Mon, Oct 29, 2001 at 12:55:04PM +0100
References: <3E16581537ABE44EB18C5206CE79F26B89BC07@ibfftc0006.is.de.dresdnerkb.com>
Message-ID: <20011029162705.B8684@faui02.informatik.uni-erlangen.de>

On Mon, Oct 29, 2001 at 12:55:04PM +0100, Dost, Alexander wrote:
> Ok. That did it. There was a problem with short/long names. As we use DNS,
> the names are resolved to long names, and ssh-keyscan delivered only short
> names. Changing the ssh_known_hosts-entries to long names made it work.
> Thanks a lot

ssh-keyscan does not deliver names at all.

i used something like this:

ypcat hosts | \
        tr -s ' ' ',' | \
        sed 's/,$//' | \
        sort -u | \
        ssh-keyscan -T 50 -f -

e.g you can do

echo hosta,hosta.longname,1.2.3.4 | ssh-keyscan -f -


From ed at UDel.Edu  Tue Oct 30 02:36:40 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 29 Oct 2001 10:36:40 -0500 (EST)
Subject: New password echoes on Sol8
In-Reply-To: <20011027193634.B19754@folly>
Message-ID: <Pine.SOL.4.30.0110291025220.11999-100000@mahler.udel.edu>

On Sat, 27 Oct 2001, Markus Friedl wrote:

> Date: Sat, 27 Oct 2001 19:36:34 +0200
> From: Markus Friedl <markus at openbsd.org>
> To: Ed Phillips <ed at UDel.Edu>
> Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>
> Subject: Re: New password echoes on Sol8
>
> On Fri, Oct 26, 2001 at 04:12:35PM -0400, Ed Phillips wrote:
> > I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> > version that just calls getpassphrase().  It appears to solve the echo
> > problem when the user tries to login in interactive mode and needs to
> > change their password.
> >
> > Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:
> >
> > #define HAVE_GETPASSPHRASE
>
> no.
>
> the bug should be fixed instead.

Okay... it appears that the bug has been found and fixed.

> we already have enough waste in openssh.

Some might say it is a "waste" to replace a perfectly good OS-supplied
routine (like getpassphrase()) with yet more code that does the same
thing.

And I agree... a quick glance at what's getting bundled into my ssh/sshd
executables on Solaris - we have the following code getting compiled-in
even though a routine of the same name or another name with the same
function is already availble in libc or other libs:

getcwd
getgrouplist
getopt
inet_ntoa
inet_aton
mktemp
readpassphrase
realpath
rresvport
setenv

... now that's a waste! ;-P

	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 Oct 30 02:53:44 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 16:53:44 +0100
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110291025220.11999-100000@mahler.udel.edu>; from ed@udel.edu on Mon, Oct 29, 2001 at 10:36:40AM -0500
References: <20011027193634.B19754@folly> <Pine.SOL.4.30.0110291025220.11999-100000@mahler.udel.edu>
Message-ID: <20011029165344.D8684@faui02.informatik.uni-erlangen.de>

On Mon, Oct 29, 2001 at 10:36:40AM -0500, Ed Phillips wrote:
> On Sat, 27 Oct 2001, Markus Friedl wrote:
> 
> > Date: Sat, 27 Oct 2001 19:36:34 +0200
> > From: Markus Friedl <markus at openbsd.org>
> > To: Ed Phillips <ed at UDel.Edu>
> > Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>
> > Subject: Re: New password echoes on Sol8
> >
> > On Fri, Oct 26, 2001 at 04:12:35PM -0400, Ed Phillips wrote:
> > > I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different
> > > version that just calls getpassphrase().  It appears to solve the echo
> > > problem when the user tries to login in interactive mode and needs to
> > > change their password.
> > >
> > > Can anyone else try this with v2.9.9p2 on Solaris?  Be sure to add:
> > >
> > > #define HAVE_GETPASSPHRASE
> >
> > no.
> >
> > the bug should be fixed instead.
> 
> Okay... it appears that the bug has been found and fixed.
> 
> > we already have enough waste in openssh.
> 
> Some might say it is a "waste" to replace a perfectly good OS-supplied
> routine (like getpassphrase()) with yet more code that does the same
> thing.

getpassphrase ist not available on all platforms, and
we don't know whether it removes the password from
memory. moreover, different getpassphrase() implementations
have different deficits.

> And I agree... a quick glance at what's getting bundled into my ssh/sshd
> executables on Solaris - we have the following code getting compiled-in
> even though a routine of the same name or another name with the same
> function is already availble in libc or other libs:
> 
> getcwd
> getgrouplist
> getopt
> inet_ntoa
> inet_aton
> mktemp
> readpassphrase
> realpath
> rresvport
> setenv
> 
> ... now that's a waste! ;-P

then it's either a configure.in bug or the system has
a broken implementation.


From mouring at etoh.eviladmin.org  Tue Oct 30 02:58:31 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 29 Oct 2001 09:58:31 -0600 (CST)
Subject: New password echoes on Sol8
In-Reply-To: <Pine.SOL.4.30.0110291025220.11999-100000@mahler.udel.edu>
Message-ID: <Pine.BSO.4.33.0110290950010.894-100000@etoh.eviladmin.org>



On Mon, 29 Oct 2001, Ed Phillips wrote:
[..]
>
> Some might say it is a "waste" to replace a perfectly good OS-supplied
> routine (like getpassphrase()) with yet more code that does the same
> thing.
>
> And I agree... a quick glance at what's getting bundled into my ssh/sshd
> executables on Solaris - we have the following code getting compiled-in
> even though a routine of the same name or another name with the same
> function is already availble in libc or other libs:
>
> getcwd
> getgrouplist
> getopt
Solaris is missing optreset.

> inet_ntoa
Defined 'HAVE_INET_NTOA' will not be used under Solaris.

> inet_aton
Not found on 2.5 - 2.7 solaris.


> mktemp
Not used.. mkdtemp is used.  Solaris does not have it. (I could explain
why it is there, but it is left up the reader to check the OpenBSD tree)


> readpassphrase
This is an OpenBSD function.  Solaris does not support it.


> realpath
It is not enabled on my machine.  'realpath()' was added to portable
because NeXTStep has a command called 'realpath()' but it has nothing to
do with the one we want.

Solaris 7 sets 'HAVE_REALPATH' therefor the libc version will be used.


> rresvport

> setenv
It does?  Solaris 2.5 - 2.7 don't.


>
> ... now that's a waste! ;-P
>

I'll not waste my time with the rest.. I really suggestion you do your
hoomework on such topics.

- Ben



From mouring at etoh.eviladmin.org  Tue Oct 30 03:40:40 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 29 Oct 2001 10:40:40 -0600 (CST)
Subject: Hello Supporters
In-Reply-To: <NEBBLLJMHMLKIDLCIGLOEECICBAA.manoj@ranchnetworks.com>
Message-ID: <Pine.BSO.4.33.0110291040030.894-100000@etoh.eviladmin.org>


I've seen others working on a vxWorks port for OpenSSH.  I'll CC: this to
the OpenSSH dev list.  Maybe they can provide you with the help you need.

- Ben

On Mon, 29 Oct 2001, Manoj Jaitly wrote:

> I need a vxWorks port for openSSH. Can you send me some info on this topic.
> If it is not available, then which is the best version to start porting and
> what all I need to port along with openssh? I mean do I need openssl and
> some other libratries too?
>
> Appreciate help.
> Regards
> Manoj
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com
> For additional commands, e-mail: secureshell-help at securityfocus.com
>
>



From manoj at ranchnetworks.com  Tue Oct 30 03:55:14 2001
From: manoj at ranchnetworks.com (Manoj Jaitly)
Date: Mon, 29 Oct 2001 11:55:14 -0500
Subject: Hello Developers
Message-ID: <NEBBLLJMHMLKIDLCIGLOCECLCBAA.manoj@ranchnetworks.com>

I have joined this mailing list. I am want help in getting/poring vxworks
port for openssh. Ben already forwarded this request to the group. Thanks
ben. I was confirming to be in the mailing list.



From pedwards at disaster.jaj.com  Tue Oct 30 04:39:52 2001
From: pedwards at disaster.jaj.com (Phil Edwards)
Date: Mon, 29 Oct 2001 12:39:52 -0500
Subject: hanging on logout, can't background client
In-Reply-To: <20011024214216.A11531@folly>; from markus@openbsd.org on Wed, Oct 24, 2001 at 09:42:16PM +0200
References: <20011023184003.A19854@disaster.jaj.com> <20011024155929.A11792@folly> <20011024124225.A23138@disaster.jaj.com> <20011024195832.A25142@folly> <20011024142754.A23601@disaster.jaj.com> <20011024214216.A11531@folly>
Message-ID: <20011029123952.A20540@disaster.jaj.com>

On Wed, Oct 24, 2001 at 09:42:16PM +0200, Markus Friedl wrote:
> please try this experimental patch.  could be included in 3.1

This seems to work on Linux and Solaris.  Thanks very much!

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


From carson at taltos.org  Tue Oct 30 04:42:25 2001
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 29 Oct 2001 12:42:25 -0500
Subject: configure changes
In-Reply-To: <20011024110558.A27428@lucent.com>
References: <20011024110558.A27428@lucent.com>
Message-ID: <6628240.1004359344@CJECW95G6PXXT>

Once again, I will state what the _correct_ logic for finding libraries 
should be (and what my old patch implemented):

If --with-pkg=/path/to/pkg was passed, look for lib in /path/to/pkg/lib 
(using /path/to/pkg/include). If it's not there, give up. If found, prepend 
path to LDFLAGS and CPPFLAGS.

If an explicit path was _not_ given, try, in order:

- The system defaults (i.e. do _not_ add any -L/-R/-I flags). If found, 
great - no paths needed. If not found, try next.
- A list of default directories (which should be settable on a per-OS 
basis). The simple default list is /usr/local. If found, append path to 
LDFLAGS and CPPFLAGS. If not found, give up.

Things to note carefully in the above:

- Explicit paths are _prepended_, implicit paths are _appended_
- If explicit paths are specified for everything, implicit paths are 
_never_ used.

-- 
Carson





From manoj at ranchnetworks.com  Tue Oct 30 05:43:29 2001
From: manoj at ranchnetworks.com (Manoj Jaitly)
Date: Mon, 29 Oct 2001 13:43:29 -0500
Subject: Need openSSH for vxWorks
In-Reply-To: <6628240.1004359344@CJECW95G6PXXT>
Message-ID: <NEBBLLJMHMLKIDLCIGLOAECMCBAA.manoj@ranchnetworks.com>

Hi Developers

I need a vxWorks port for openSSH. Can you send me some info on this topic.
WHere can I download it?

If it is not available, then which is the best version to start porting and
what all I need to port along with openssh? I mean do I need openssl and
some other libratries too?

Appreciate help.
Regards
Manoj



From dbutts at maddog.storability.com  Tue Oct 30 07:42:24 2001
From: dbutts at maddog.storability.com (David Butts)
Date: Mon, 29 Oct 2001 15:42:24 -0500
Subject: pam_open_session w/o tty on Solaris
Message-ID: <20011029154224.E14482@storability.com>

Hello, all-

Apparently, under Solaris (I can personally confirm SunOS 5.7 and 5.8),
pam_open_session will generate a segfault if PAM_TTY is not set.  The
obvious symptom of this is that OpenSSH 2.9.9p2 will segfault on any
operation that does not request a tty (do_exec_no_pty).

Based on a quick google search, this seems to have been encountered
by others, though the specific symptoms seem to have changed a bit.

(eg http://www.castaglia.org/proftpd/doc/devel-guide/src/modules/mod_pam.c.html
contains a reference to this problem -- the first instance of PAM_TTY)

I wasn't able to find any other reference to Sun bugid 4250887 that
was mentioned in the comment, and an empty string worked for me as
well.

In any case, the following change appears to address the problem:

diff -ru openssh-2.9.9p2_orig/auth-pam.c openssh-2.9.9p2/auth-pam.c
--- openssh-2.9.9p2_orig/auth-pam.c	Mon Apr 23 14:38:37 2001
+++ openssh-2.9.9p2/auth-pam.c	Mon Oct 29 15:32:08 2001
@@ -272,6 +272,12 @@
 
 	do_pam_set_conv(&conv);
 
+#ifdef PAM_SUN_CODEBASE
+	if (ttyname == NULL) {
+		ttyname = "";
+	}
+#endif /* PAM_SUN_CODEBASE */
+
 	if (ttyname != NULL) {
 		debug("PAM setting tty to \"%.200s\"", ttyname);
 		pam_retval = pam_set_item(__pamh, PAM_TTY, ttyname);

Obviously that expands the meaning of PAM_SUN_CODEBASE a bit from its
current definition, but it seemed a fairly reasonable thing to use,
since this appears to be another misbehavior of PAM under Solaris.

I don't honestly know enough about the inner workings of PAM to know
whether it would be better to use an empty string, or a real but
useless file like /dev/null, though.

Is there a better way to deal with this?

Thanks,
David



From mouring at etoh.eviladmin.org  Tue Oct 30 07:50:26 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Mon, 29 Oct 2001 14:50:26 -0600 (CST)
Subject: pam_open_session w/o tty on Solaris
In-Reply-To: <20011029154224.E14482@storability.com>
Message-ID: <Pine.BSO.4.33.0110291449560.894-100000@etoh.eviladmin.org>


This should have been resolved in the latest snapshot.  Please go to
http://www.openssh.com/portable.html and try the latest snapshot.

- Ben

On Mon, 29 Oct 2001, David Butts wrote:

> Hello, all-
>
> Apparently, under Solaris (I can personally confirm SunOS 5.7 and 5.8),
> pam_open_session will generate a segfault if PAM_TTY is not set.  The
> obvious symptom of this is that OpenSSH 2.9.9p2 will segfault on any
> operation that does not request a tty (do_exec_no_pty).
>
> Based on a quick google search, this seems to have been encountered
> by others, though the specific symptoms seem to have changed a bit.
>
> (eg http://www.castaglia.org/proftpd/doc/devel-guide/src/modules/mod_pam.c.html
> contains a reference to this problem -- the first instance of PAM_TTY)
>
> I wasn't able to find any other reference to Sun bugid 4250887 that
> was mentioned in the comment, and an empty string worked for me as
> well.
>
> In any case, the following change appears to address the problem:
>
> diff -ru openssh-2.9.9p2_orig/auth-pam.c openssh-2.9.9p2/auth-pam.c
> --- openssh-2.9.9p2_orig/auth-pam.c	Mon Apr 23 14:38:37 2001
> +++ openssh-2.9.9p2/auth-pam.c	Mon Oct 29 15:32:08 2001
> @@ -272,6 +272,12 @@
>
>  	do_pam_set_conv(&conv);
>
> +#ifdef PAM_SUN_CODEBASE
> +	if (ttyname == NULL) {
> +		ttyname = "";
> +	}
> +#endif /* PAM_SUN_CODEBASE */
> +
>  	if (ttyname != NULL) {
>  		debug("PAM setting tty to \"%.200s\"", ttyname);
>  		pam_retval = pam_set_item(__pamh, PAM_TTY, ttyname);
>
> Obviously that expands the meaning of PAM_SUN_CODEBASE a bit from its
> current definition, but it seemed a fairly reasonable thing to use,
> since this appears to be another misbehavior of PAM under Solaris.
>
> I don't honestly know enough about the inner workings of PAM to know
> whether it would be better to use an empty string, or a real but
> useless file like /dev/null, though.
>
> Is there a better way to deal with this?
>
> Thanks,
> David
>
>



From Nicolas.Williams at ubsw.com  Tue Oct 30 07:53:28 2001
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Mon, 29 Oct 2001 15:53:28 -0500
Subject: pam_open_session w/o tty on Solaris
In-Reply-To: <20011029154224.E14482@storability.com>; from dbutts@maddog.storability.com on Mon, Oct 29, 2001 at 03:42:24PM -0500
References: <20011029154224.E14482@storability.com>
Message-ID: <20011029155326.Q5739@sm2p1386swk.wdr.com>

This has been hashed over plenty. The bug is in PAM_UNIX, not PAM, and
yes, supplying PAM with a bogus TTY for non-tty SSH sessions suffices to
work around the problem. A Sun patch to PAM_UNIX is available too.

Cheers,

Nico

On Mon, Oct 29, 2001 at 03:42:24PM -0500, David Butts wrote:
> Hello, all-
> 
> Apparently, under Solaris (I can personally confirm SunOS 5.7 and 5.8),
> pam_open_session will generate a segfault if PAM_TTY is not set.  The
> obvious symptom of this is that OpenSSH 2.9.9p2 will segfault on any
> operation that does not request a tty (do_exec_no_pty).
> 
> Based on a quick google search, this seems to have been encountered
> by others, though the specific symptoms seem to have changed a bit.
> 
> (eg http://www.castaglia.org/proftpd/doc/devel-guide/src/modules/mod_pam.c.html
> contains a reference to this problem -- the first instance of PAM_TTY)
> 
> I wasn't able to find any other reference to Sun bugid 4250887 that
> was mentioned in the comment, and an empty string worked for me as
> well.
> 
> In any case, the following change appears to address the problem:
> 
> diff -ru openssh-2.9.9p2_orig/auth-pam.c openssh-2.9.9p2/auth-pam.c
> --- openssh-2.9.9p2_orig/auth-pam.c	Mon Apr 23 14:38:37 2001
> +++ openssh-2.9.9p2/auth-pam.c	Mon Oct 29 15:32:08 2001
> @@ -272,6 +272,12 @@
>  
>  	do_pam_set_conv(&conv);
>  
> +#ifdef PAM_SUN_CODEBASE
> +	if (ttyname == NULL) {
> +		ttyname = "";
> +	}
> +#endif /* PAM_SUN_CODEBASE */
> +
>  	if (ttyname != NULL) {
>  		debug("PAM setting tty to \"%.200s\"", ttyname);
>  		pam_retval = pam_set_item(__pamh, PAM_TTY, ttyname);
> 
> Obviously that expands the meaning of PAM_SUN_CODEBASE a bit from its
> current definition, but it seemed a fairly reasonable thing to use,
> since this appears to be another misbehavior of PAM under Solaris.
> 
> I don't honestly know enough about the inner workings of PAM to know
> whether it would be better to use an empty string, or a real but
> useless file like /dev/null, though.
> 
> Is there a better way to deal with this?
> 
> Thanks,
> David
--

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  Tue Oct 30 08:25:54 2001
From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston)
Date: Mon, 29 Oct 2001 16:25:54 -0500 (EST)
Subject: Another round of testing calls. (redhat/openssh.spec)
In-Reply-To: <Pine.LNX.4.33.0110252056220.21969-100000@netcore.fi>
Message-ID: <Pine.LNX.4.33.0110291620180.17119-100000@pcmy.sei.cmu.edu>

On Thu, 25 Oct 2001, Pekka Savola wrote:

> > The latter means "this package requires openssl, but doesn't work
> > with versions of openssl less than 0.9.6".  That's what you mean.
> 
> This is slightly better, but I don't see the real point; double the
> number of different dependencies are required, and isn't a common
> practise.

IIRC, it was jbj who stated that this:

    Requires: openssl
    Conflicts: openssl < 0.9.6

...was preferred over this:

    Requires: openssl >= 0.9.6

But since I couldn't find anything to back up my recollection, I'll go
ask on rpm-list, just to make sure I'm remembering properly.

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA



From dwd at bell-labs.com  Tue Oct 30 08:27:14 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Mon, 29 Oct 2001 15:27:14 -0600
Subject: Patch for allowing port forward host names > 30 bytes
Message-ID: <20011029152714.A2329@lucent.com>

For some reason OpenSSH only allows 30 bytes in a name for port forwards.
That's very limiting.  SSH 1.2.27 allowed 200 bytes.  Here's a patch to
make it 200 bytes.  The comment on the "path" variable in struct Channel
says the same variable is used to hold unix domain socket names, and surely
they shouldn't be limited to 30 bytes.

Again, this was tested on portable OpenSSH but should be applied to
native.

- Dave Dykstra


--- channels.h.O        Mon Oct 29 15:47:28 2001
+++ channels.h  Mon Oct 29 15:47:47 2001
@@ -56,7 +56,7 @@
 #define SSH_CHANNEL_ZOMBIE             14      /* Almost dead. */
 #define SSH_CHANNEL_MAX_TYPE           15
 
-#define SSH_CHANNEL_PATH_LEN           30
+#define SSH_CHANNEL_PATH_LEN           200
 
 struct Channel;
 typedef struct Channel Channel;



From carson at taltos.org  Tue Oct 30 09:01:37 2001
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 29 Oct 2001 17:01:37 -0500
Subject: One last time (Re: SIGCHLD race *trivial* patch)
In-Reply-To: <20011026133630.L5739@sm2p1386swk.wdr.com>
References: <20011026133630.L5739@sm2p1386swk.wdr.com>
Message-ID: <22180373.1004374896@CJECW95G6PXXT>



--On Friday, October 26, 2001 1:36 PM -0400 Nicolas Williams 
<Nicolas.Williams at ubsw.com> wrote:

> I take it that the BSD sigvec() interface is to be used?
>
> If so, that'll require a compatibility shim for Solaris (which has a

*blech* *retch*

Use the POSIX signal functions, and _only_ the POSIX signal functions. 
Nothing else is portable, and they all have rather nasty race conditions. 
The POSIX signal functions can trivially go back into the OpenBSD main 
source.

(a long-suffering victim of signal() BSD/SYSV semantic wars)

-- 
Carson


From markus at openbsd.org  Tue Oct 30 09:04:53 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 23:04:53 +0100
Subject: One last time (Re: SIGCHLD race *trivial* patch)
In-Reply-To: <22180373.1004374896@CJECW95G6PXXT>; from carson@taltos.org on Mon, Oct 29, 2001 at 05:01:37PM -0500
References: <20011026133630.L5739@sm2p1386swk.wdr.com> <22180373.1004374896@CJECW95G6PXXT>
Message-ID: <20011029230453.A5106@faui02.informatik.uni-erlangen.de>

On Mon, Oct 29, 2001 at 05:01:37PM -0500, Carson Gaspar wrote:
> Use the POSIX signal functions, and _only_ the POSIX signal functions. 
> Nothing else is portable, and they all have rather nasty race conditions. 
> The POSIX signal functions can trivially go back into the OpenBSD main 
> source.

so, and what are we using now?


From markus at openbsd.org  Tue Oct 30 09:06:38 2001
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 29 Oct 2001 23:06:38 +0100
Subject: signal messages
Message-ID: <20011029230638.A26033@folly>

comments?

allows 
	% ssh host 'tail -f /var/log/messages | grep bla'
	^C


Index: clientloop.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v
retrieving revision 1.86
diff -u -r1.86 clientloop.c
--- clientloop.c	24 Oct 2001 19:57:40 -0000	1.86
+++ clientloop.c	29 Oct 2001 19:08:37 -0000
@@ -103,6 +103,8 @@
  */
 static volatile int received_window_change_signal = 0;
 static volatile int received_signal = 0;
+/* send signal to remote program: 0 disabled, 1 enabled, 2 pending */
+static volatile int send_signal = 0;
 
 /* Flag indicating whether the user\'s terminal is in non-blocking mode. */
 static int in_non_blocking_mode = 0;
@@ -173,7 +175,10 @@
 signal_handler(int sig)
 {
 	received_signal = sig;
-	quit_pending = 1;
+	if (send_signal == 1)
+		send_signal = 2;
+	else
+		quit_pending = 1;
 }
 
 /*
@@ -765,6 +770,26 @@
 		leave_raw_mode();
 }
 
+static char *
+sig2name(int sig)
+{
+#define SIG(x) if (sig == SIG ## x) return #x
+	SIG(ABRT);
+	SIG(ALRM);
+	SIG(FPE);
+	SIG(HUP);
+	SIG(ILL);
+	SIG(INT);
+	SIG(KILL);
+	SIG(PIPE);
+	SIG(QUIT);
+	SIG(SEGV);
+	SIG(TERM);
+	SIG(USR1);
+	SIG(USR2);
+	return "";
+}
+
 /*
  * Implements the interactive session with the server.  This is called after
  * the user has been authenticated, and a command has been started on the
@@ -778,7 +803,7 @@
 	fd_set *readset = NULL, *writeset = NULL;
 	double start_time, total_time;
 	int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0;
-	char buf[100];
+	char *signame, buf[100];
 
 	debug("Entering interactive session.");
 
@@ -819,6 +844,10 @@
 
 	client_init_dispatch();
 
+	/* for protocol v2 we try to send the signal to the remote host */
+	if (compat20 && !have_pty && ssh2_chan_id != -1)
+		send_signal = 1;
+
 	/* Set signal handlers to restore non-blocking mode.  */
 	signal(SIGINT, signal_handler);
 	signal(SIGQUIT, signal_handler);
@@ -899,6 +928,18 @@
 				xxx_kex->done = 0;
 				kex_send_kexinit(xxx_kex);
 				need_rekeying = 0;
+			}
+			if (send_signal == 2) {
+				send_signal = 0;
+				signame = sig2name(received_signal);
+				debug("Sending SIG%s to the remote host.",
+				    signame);
+				packet_start(SSH2_MSG_CHANNEL_REQUEST);
+				packet_put_int(session_ident);
+				packet_put_cstring("signal");
+				packet_put_char(0);
+				packet_put_cstring(signame);
+				packet_send();
 			}
 		}
 
Index: session.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/session.c,v
retrieving revision 1.108
diff -u -r1.108 session.c
--- session.c	11 Oct 2001 13:45:21 -0000	1.108
+++ session.c	29 Oct 2001 19:25:44 -0000
@@ -1383,6 +1383,47 @@
 	}
 }
 
+static int
+name2sig(char *name)
+{
+#define SIG(x) if (strcmp(name, #x) == 0) return SIG ## x
+	SIG(ABRT);
+	SIG(ALRM);
+	SIG(FPE);
+	SIG(HUP);
+	SIG(ILL);
+	SIG(INT);
+	SIG(KILL);
+	SIG(PIPE);
+	SIG(QUIT);
+	SIG(SEGV);
+	SIG(TERM);
+	SIG(USR1);
+	SIG(USR2);
+	return -1;
+}
+
+static int
+session_signal_req(Session *s)
+{
+	char *signame;
+	int sig;
+
+	signame = packet_get_string(NULL);
+	sig = name2sig(signame);
+	xfree(signame);
+	packet_done();
+
+	if (sig >= 0 && s->pid > 0) {
+		debug("session_signal_req: killpg(%d, %d)",
+		    s->pid, sig);
+		if (killpg(s->pid, sig) < 0)
+			error("session_signal_req: killpg(%d, %d): %s",
+			    s->pid, sig, strerror(errno));
+	}
+	return 0;
+}
+
 void
 session_input_channel_req(int id, void *arg)
 {
@@ -1427,6 +1468,8 @@
 	}
 	if (strcmp(rtype, "window-change") == 0) {
 		success = session_window_change_req(s);
+	} else if (strcmp(rtype, "signal") == 0) {
+		success = session_signal_req(s);
 	}
 
 	if (reply) {


From orchard at eceserv1.ece.wisc.edu  Tue Oct 30 09:45:51 2001
From: orchard at eceserv1.ece.wisc.edu (orchard at eceserv1.ece.wisc.edu)
Date: Mon, 29 Oct 2001 16:45:51 -0600 (CST)
Subject: Compiling openssh on Solaris 8
Message-ID: <200110292245.f9TMjpi23223@eceserv1.ece.wisc.edu>

Source version:  openssh-2.9.9p2
Operating System:  Solaris 8 (SunOS 5.8)
Compiler:  Sun cc (Workshop 6, I think)

In this environment, the compile of session.c fails with 
an error that the declaration of do_pre_login changed.
I fixed the problem by putting back the prototype of
do_pre_login that had been in earlier versions (right after the 
prototype of do_login)

   132  #ifdef LOGIN_NEEDS_UTMPX
   133  void    do_pre_login(Session *s);
   134  #endif



Bruce Orchard


From carson at taltos.org  Tue Oct 30 10:10:19 2001
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 29 Oct 2001 18:10:19 -0500
Subject: One last time (Re: SIGCHLD race *trivial* patch)
In-Reply-To: <20011029230453.A5106@faui02.informatik.uni-erlangen.de>
References: <20011029230453.A5106@faui02.informatik.uni-erlangen.de>
Message-ID: <26302440.1004379018@CJECW95G6PXXT>



--On Monday, October 29, 2001 11:04 PM +0100 Markus Friedl 
<markus at openbsd.org> wrote:

> On Mon, Oct 29, 2001 at 05:01:37PM -0500, Carson Gaspar wrote:
>> Use the POSIX signal functions, and _only_ the POSIX signal functions.
>> Nothing else is portable, and they all have rather nasty race
>> conditions.  The POSIX signal functions can trivially go back into the
>> OpenBSD main  source.
>
> so, and what are we using now?

I was originally responding to a message that claimed sigvec() was being 
used. It isn't. OpenSSH currently uses a terrible mix of signal() and 
sigaction(). Under Solaris, signal() has SYSV semantics, which is almost 
certainly not what you want. It looks like the source code just needs to 
have signal() replaced with mysignal(), which is defined in terms of 
sigaction in misc.c.

Sadly, the current CVS doesn't have configure.in, so 2.52 autoconf won't 
touch it. I can't check to see if weird macro re-writing of signal() is 
going on.

--
Carson





From dbt at meat.net  Tue Oct 30 10:25:52 2001
From: dbt at meat.net (David Terrell)
Date: Mon, 29 Oct 2001 15:25:52 -0800
Subject: disable features
In-Reply-To: <20011024185642.A7393@folly>; from markus@openbsd.org on Wed, Oct 24, 2001 at 06:56:42PM +0200
References: <20011024114637.A20236@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu> <20011024185642.A7393@folly>
Message-ID: <20011029152552.B17656@pianosa.catch22.org>

On Wed, Oct 24, 2001 at 06:56:42PM +0200, Markus Friedl wrote:
> 
> both agent and x11 forwarding are off by default since they allow
> access to local resource from the remote machine where the sshd is
> running.
> 
> enable agent and x11 forwarding only if you trust the remote server.

Is there any reason why they are disabled in the server, since they 
pose no particular additional security risks to the server itself?
I'd rather see them on by default in the server and off by default
in the client, since the client is both more at risk and easier to 
selectively enable.

-- 
David Terrell             | "Any sufficiently advanced technology 
Prime Minister, Nebcorp   | is indistinguishable from a rigged demo."
dbt at meat.net              |  - Brian Swetland
http://wwn.nebcorp.com/


From carson at taltos.org  Tue Oct 30 10:50:12 2001
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 29 Oct 2001 18:50:12 -0500
Subject: configure.in missing?
Message-ID: <28696243.1004381412@CJECW95G6PXXT>

configure.in seems to be missing from CVS and the snapshot. Am I just 
confused, or is something broken?

-- 
Carson



From dbt at meat.net  Tue Oct 30 10:50:57 2001
From: dbt at meat.net (David Terrell)
Date: Mon, 29 Oct 2001 15:50:57 -0800
Subject: disable features
In-Reply-To: <20011029152552.B17656@pianosa.catch22.org>; from dbt@meat.net on Mon, Oct 29, 2001 at 03:25:52PM -0800
References: <20011024114637.A20236@serv01.aet.tu-cottbus.de> <Pine.SOL.4.30.0110240931210.16569-100000@mahler.udel.edu> <20011024185642.A7393@folly> <20011029152552.B17656@pianosa.catch22.org>
Message-ID: <20011029155057.C17656@pianosa.catch22.org>

On Mon, Oct 29, 2001 at 03:25:52PM -0800, David Terrell wrote:
> On Wed, Oct 24, 2001 at 06:56:42PM +0200, Markus Friedl wrote:
> > 
> > both agent and x11 forwarding are off by default since they allow
> > access to local resource from the remote machine where the sshd is
> > running.
> > 
> > enable agent and x11 forwarding only if you trust the remote server.
> 
> Is there any reason why they are disabled in the server, since they 
> pose no particular additional security risks to the server itself?
> I'd rather see them on by default in the server and off by default
> in the client, since the client is both more at risk and easier to 
> selectively enable.

sorry, please disregard.

I really shouldn't respond to anything when I'm catching up on list
traffic from the previous week...

-- 
David Terrell   | "The reasons for my decision to quit were myriad, but 
Nebcorp PM      | central to the decision was the realization that there are 
dbt at meat.net    | two kinds of companies:  Good ones ask you to think for 
wwn.nebcorp.com | them.  The others tell you to think like them." -Benjy Feen


From stevesk at pobox.com  Tue Oct 30 11:32:36 2001
From: stevesk at pobox.com (Kevin Steves)
Date: Mon, 29 Oct 2001 16:32:36 -0800 (PST)
Subject: configure.in missing?
In-Reply-To: <28696243.1004381412@CJECW95G6PXXT>
Message-ID: <Pine.HPX.4.40.0110291630150.1406-100000@jenny>

On Mon, 29 Oct 2001, Carson Gaspar wrote:
:configure.in seems to be missing from CVS and the snapshot. Am I just
:confused, or is something broken?

ChangeLog:

 - (tim) configure.in -> configure.ac

make -f Makefile.in distprep should work fine with autoconf 2.5.



From djm at mindrot.org  Tue Oct 30 12:03:29 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Oct 2001 12:03:29 +1100 (EST)
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011029082657.A23424@lucent.com>
Message-ID: <Pine.LNX.4.33.0110301202190.2815-100000@mothra.mindrot.org>

On Mon, 29 Oct 2001, Dave Dykstra wrote:

> With "warn", you can still use forwarding even though you know a server is
> not very well secured, and you will be notified if someone does actually
> break into the server and try to take over the forwarding on your session.

By which stage it is too late.

What would be nicer is some way for the client to get the user to accept
/ reject each forwarding request.

-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 tim at multitalents.net  Tue Oct 30 13:32:51 2001
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Oct 2001 18:32:51 -0800 (PST)
Subject: One last time (Re: SIGCHLD race *trivial* patch)
In-Reply-To: <26302440.1004379018@CJECW95G6PXXT>
Message-ID: <Pine.UW2.4.40.9.0110291830500.2660-100000@uw711.int.multitalents.net>

On Mon, 29 Oct 2001, Carson Gaspar wrote:

> Sadly, the current CVS doesn't have configure.in, so 2.52 autoconf won't
> touch it. I can't check to see if weird macro re-writing of signal() is
> going on.

configure.in has been renamed to configure.ac which autoconf 2.52 uses
but autoconf 2.13 does not.

>
> --
> Carson
>
>
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From jmknoble at pobox.com  Tue Oct 30 15:35:57 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Mon, 29 Oct 2001 23:35:57 -0500
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <Pine.LNX.4.33.0110301202190.2815-100000@mothra.mindrot.org>; from djm@mindrot.org on Tue, Oct 30, 2001 at 12:03:29PM +1100
References: <20011029082657.A23424@lucent.com> <Pine.LNX.4.33.0110301202190.2815-100000@mothra.mindrot.org>
Message-ID: <20011029233557.B3914@zax.half.pint-stowp.cx>

Circa 2001-Oct-30 12:03:29 +1100 dixit Damien Miller:

: On Mon, 29 Oct 2001, Dave Dykstra wrote:
: > With "warn", you can still use forwarding even though you know a server is
: > not very well secured, and you will be notified if someone does actually
: > break into the server and try to take over the forwarding on your session.
: 
: By which stage it is too late.
: 
: What would be nicer is some way for the client to get the user to accept
: / reject each forwarding request.

http://c.home.cern.ch/c/cons/www/mxconns/

-- 
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/20011029/72d9f8c0/attachment.bin 

From djm at mindrot.org  Tue Oct 30 22:25:21 2001
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Oct 2001 22:25:21 +1100 (EST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <20011021112648.A9749@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.LNX.4.33.0110302224300.1314-100000@mothra.mindrot.org>

On Sun, 21 Oct 2001, Lutz Jaenicke wrote:

> On Sat, Oct 20, 2001 at 11:41:24PM +0300, Pekka Savola wrote:
> > 3) Building appears to rely on the existance of rather recent openssl.
> > This is good from security perspective, but will make building with e.g.
> > 0.9.5a impossible.  If this is intended to be requirement (there _have_
> > been security fixes), at least Requires:  openssl >= 0.9.6 or whatever
> > should be added and the requirement noted in the docs.
> > 
> > The build failed on my RHL62 with:
> > 
> > ./libssh.a(key.o): In function `write_bignum':
> > key.o(.text+0x7f7): undefined reference to `OPENSSL_free'
> 
> I just had a look into the source. Since BN_bn2dec() really allocates
> the buffer itself (using OPENSSL_malloc() in recent versions), there is
> nothing an application writer can do with respect to this inconsistency.
> (For all OpenSSL special data types, TYPE_new() and TYPE_free() exist.)
> The only thing that could be done is to query the version defined in
> opensslv.h and based on that make a #if OPENSSL_VERSION_NUMBER construct.

Can people try this patch?

Index: defines.h
===================================================================
RCS file: /var/cvs/openssh/defines.h,v
retrieving revision 1.74
diff -u -r1.74 defines.h
--- defines.h	2001/10/30 02:50:40	1.74
+++ defines.h	2001/10/30 11:23:51
@@ -45,6 +45,7 @@
 #include <unistd.h> /* For STDIN_FILENO, etc */
 #include <termios.h> /* Struct winsize */
 #include <fcntl.h> /* For O_NONBLOCK */
+#include <openssl/opensslv.h> /* For OPENSSL_VERSION_NUMBER */
 
 /* *-*-nto-qnx needs these headers for strcasecmp and LASTLOG_FILE respectively */
 #ifdef HAVE_STRINGS_H
@@ -448,6 +449,11 @@
 
 #ifndef GETPGRP_VOID
 # define getpgrp() getpgrp(0)
+#endif
+
+/* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */
+#if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f)
+# define OPENSSL_free(x) free(x)
 #endif
 
 /*

-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 Lutz.Jaenicke at aet.TU-Cottbus.DE  Tue Oct 30 23:18:26 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Tue, 30 Oct 2001 13:18:26 +0100
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.LNX.4.33.0110302224300.1314-100000@mothra.mindrot.org>
References: <20011021112648.A9749@serv01.aet.tu-cottbus.de> <Pine.LNX.4.33.0110302224300.1314-100000@mothra.mindrot.org>
Message-ID: <20011030131826.A4246@ws01.aet.tu-cottbus.de>

On Tue, Oct 30, 2001 at 10:25:21PM +1100, Damien Miller wrote:
> > I just had a look into the source. Since BN_bn2dec() really allocates
> > the buffer itself (using OPENSSL_malloc() in recent versions), there is
> > nothing an application writer can do with respect to this inconsistency.
> > (For all OpenSSL special data types, TYPE_new() and TYPE_free() exist.)
> > The only thing that could be done is to query the version defined in
> > opensslv.h and based on that make a #if OPENSSL_VERSION_NUMBER construct.
> 
> Can people try this patch?
...

Seems to make sense; testcompilation with 0.9.6b succeeded... (still waiting
for 0.9.5 report)

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From sfishback at interpath.net  Wed Oct 31 01:15:11 2001
From: sfishback at interpath.net (Steven Fishback)
Date: Tue, 30 Oct 2001 09:15:11 -0500
Subject: "last" providing incorrect information on Solaris 8
Message-ID: <3BDEB5EF.98A13AD4@interpath.net>

I'm seeing a problem using OpenSSH v2.9.9p2 on solaris and the usage of
the "last" command.

The "last <username>" usage is displaying the sessions as still being
logged on the server when it's really not.  The "last" by itself shows
correct information about the session.     Sometimes using the "last
<username>" syntax  the session shows being terminated but the total
logged in time is hours off.
The console logins are not showing this behavior so Sun Support has been
difficult to get answers on the differences why I'm seeing this strange
behavior.   Sun Support had me apply latest "last" patches and start a
new /var/adm/wtmpx file.     I'm not understanding the tie in between
Solaris OS usage of the wtmpx file and OpenSSH.

I was using OpenSSH v2.5.2p2.  After upgrading and using the pam module
I'm still seeing this problem.   Can some else using Solairs verify this
strange behavior or verify it's a possible bug in OpenSSH?

$ last
fish  pts/4        r2-040.dhcp.in Mon Oct 29 13:47 - 13:47  (00:00)
fish  pts/2        r2-040.dhcp.in Mon Oct 29 12:43   still logged in
fish  console                       Mon Oct 29 12:14 - 12:15  (00:00)
fish  console                       Mon Oct 29 12:12 - 12:14  (00:02)

$ last fish
fish  pts/4        r2-040.dhcp.in Mon Oct 29 13:47   still logged in
fish  pts/2        r2-040.dhcp.in Mon Oct 29 12:43   still logged in
fish  console                       Mon Oct 29 12:14 - 12:15  (00:00)
fish  console                       Mon Oct 29 12:12 - 12:14  (00:02)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sfishback.vcf
Type: text/x-vcard
Size: 285 bytes
Desc: Card for Steven Fishback
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011030/cc5b6316/attachment.vcf 

From mouring at etoh.eviladmin.org  Wed Oct 31 02:17:54 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 30 Oct 2001 09:17:54 -0600 (CST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.LNX.4.33.0110302224300.1314-100000@mothra.mindrot.org>
Message-ID: <Pine.BSO.4.33.0110300916550.29759-100000@etoh.eviladmin.org>


I thought the reason we moved to OPENSSL_free() is because free() does not
do the right thing on OpenSSL data structures.  Why are we reintroducing
this again?  Or did I miss something.

- Ben

On Tue, 30 Oct 2001, Damien Miller wrote:

> On Sun, 21 Oct 2001, Lutz Jaenicke wrote:
>
> > On Sat, Oct 20, 2001 at 11:41:24PM +0300, Pekka Savola wrote:
> > > 3) Building appears to rely on the existance of rather recent openssl.
> > > This is good from security perspective, but will make building with e.g.
> > > 0.9.5a impossible.  If this is intended to be requirement (there _have_
> > > been security fixes), at least Requires:  openssl >= 0.9.6 or whatever
> > > should be added and the requirement noted in the docs.
> > >
> > > The build failed on my RHL62 with:
> > >
> > > ./libssh.a(key.o): In function `write_bignum':
> > > key.o(.text+0x7f7): undefined reference to `OPENSSL_free'
> >
> > I just had a look into the source. Since BN_bn2dec() really allocates
> > the buffer itself (using OPENSSL_malloc() in recent versions), there is
> > nothing an application writer can do with respect to this inconsistency.
> > (For all OpenSSL special data types, TYPE_new() and TYPE_free() exist.)
> > The only thing that could be done is to query the version defined in
> > opensslv.h and based on that make a #if OPENSSL_VERSION_NUMBER construct.
>
> Can people try this patch?
>
> Index: defines.h
> ===================================================================
> RCS file: /var/cvs/openssh/defines.h,v
> retrieving revision 1.74
> diff -u -r1.74 defines.h
> --- defines.h	2001/10/30 02:50:40	1.74
> +++ defines.h	2001/10/30 11:23:51
> @@ -45,6 +45,7 @@
>  #include <unistd.h> /* For STDIN_FILENO, etc */
>  #include <termios.h> /* Struct winsize */
>  #include <fcntl.h> /* For O_NONBLOCK */
> +#include <openssl/opensslv.h> /* For OPENSSL_VERSION_NUMBER */
>
>  /* *-*-nto-qnx needs these headers for strcasecmp and LASTLOG_FILE respectively */
>  #ifdef HAVE_STRINGS_H
> @@ -448,6 +449,11 @@
>
>  #ifndef GETPGRP_VOID
>  # define getpgrp() getpgrp(0)
> +#endif
> +
> +/* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */
> +#if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f)
> +# define OPENSSL_free(x) free(x)
>  #endif
>
>  /*
>
> -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 roberth at edberg-it.se  Wed Oct 31 02:22:58 2001
From: roberth at edberg-it.se (Roberth Edberg)
Date: Tue, 30 Oct 2001 16:22:58 +0100
Subject: What have I done wrong?
Message-ID: <004001c16156$c1d184e0$0201a8c0@edbergit.se>

Hi,

I'm new to both this list and to openssh. I just downloaded 2.9.9 and did ./configure ; make ; make install. Everything was OK, no errors. But I must have done something wrong. Because after I started the sshd daemon, I can only connect with the "root" user. I have done ssh-keygen on other users but they do not work...

I'm running Linux. I havent changed any configurations. What have I done wrong? Any ideas?

Regards,

Roberth Edberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011030/599e2756/attachment.html 

From jerry at nologin.net  Wed Oct 31 02:28:33 2001
From: jerry at nologin.net (Jerry Connolly)
Date: Tue, 30 Oct 2001 15:28:33 +0000
Subject: "last" providing incorrect information on Solaris 8
In-Reply-To: <3BDEB5EF.98A13AD4@interpath.net>; from sfishback@interpath.net on Tue, Oct 30, 2001 at 09:15:11AM -0500
References: <3BDEB5EF.98A13AD4@interpath.net>
Message-ID: <20011030152833.A10247@stealth.spin.ie>

Steven Fishback said the following on Tue, Oct 30, 2001 at 09:15:11AM -0500, 
> I was using OpenSSH v2.5.2p2.  After upgrading and using the pam module
> I'm still seeing this problem.   Can some else using Solairs verify this
> strange behavior or verify it's a possible bug in OpenSSH?
 
I'm a user on a Solaris 8 system where this behaviour is being observed.  I
don't know if OpenSSH was being investigated as a possible cause, but it
fits with your observations.

Version string is SSH-1.99-OpenSSH_2.9p2

-- 
ejrry^[bxpZZ


From mouring at etoh.eviladmin.org  Wed Oct 31 02:38:50 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 30 Oct 2001 09:38:50 -0600 (CST)
Subject: What have I done wrong?
In-Reply-To: <004001c16156$c1d184e0$0201a8c0@edbergit.se>
Message-ID: <Pine.BSO.4.33.0110300938090.29759-100000@etoh.eviladmin.org>


Does your Linux required PAM or MD5 passwords..

If PAM add: --with-pam to your ./configure line
if MD5 passwords add: --with-md5-passwords to your ./configure line

On Tue, 30 Oct 2001, Roberth Edberg wrote:

> Hi,
>
> I'm new to both this list and to openssh. I just downloaded 2.9.9 and did ./configure ; make ; make install. Everything was OK, no errors. But I must have done something wrong. Because after I started the sshd daemon, I can only connect with the "root" user. I have done ssh-keygen on other users but they do not work...
>
> I'm running Linux. I havent changed any configurations. What have I done wrong? Any ideas?
>
> Regards,
>
> Roberth Edberg
>



From manoj at ranchnetworks.com  Wed Oct 31 02:40:34 2001
From: manoj at ranchnetworks.com (Manoj Jaitly)
Date: Tue, 30 Oct 2001 10:40:34 -0500
Subject: Need openSSH for vxWorks
In-Reply-To: <NEBBLLJMHMLKIDLCIGLOAECMCBAA.manoj@ranchnetworks.com>
Message-ID: <NEBBLLJMHMLKIDLCIGLOCEDACBAA.manoj@ranchnetworks.com>

Any help is appreciated.

Thanks
Manoj

-----Original Message-----
From: owner-openssh-unix-dev at mindrot.org
[mailto:owner-openssh-unix-dev at mindrot.org]On Behalf Of Manoj Jaitly
Sent: Monday, October 29, 2001 1:43 PM
To: Carson Gaspar; openssh-unix-dev at mindrot.org
Subject: Need openSSH for vxWorks


Hi Developers

I need a vxWorks port for openSSH. Can you send me some info on this topic.
WHere can I download it?

If it is not available, then which is the best version to start porting and
what all I need to port along with openssh? I mean do I need openssl and
some other libratries too?

Appreciate help.
Regards
Manoj




From Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct 31 02:56:54 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Tue, 30 Oct 2001 16:56:54 +0100
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.BSO.4.33.0110300916550.29759-100000@etoh.eviladmin.org>
References: <Pine.LNX.4.33.0110302224300.1314-100000@mothra.mindrot.org> <Pine.BSO.4.33.0110300916550.29759-100000@etoh.eviladmin.org>
Message-ID: <20011030165654.A6006@serv01.aet.tu-cottbus.de>

On Tue, Oct 30, 2001 at 09:17:54AM -0600, mouring at etoh.eviladmin.org wrote:
> 
> I thought the reason we moved to OPENSSL_free() is because free() does not
> do the right thing on OpenSSL data structures.  Why are we reintroducing
> this again?  Or did I miss something.

OPENSSL_free() was introduced with OpenSSL 0.9.6, for OpenSSL 0.9.5, free()
is the correct way to go. In order to allow the use of 0.9.5, OPENSSL_free()
must be replaced (for <0.9.6 only), because we get an unresolved symbol error
otherwise.

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From mouring at etoh.eviladmin.org  Wed Oct 31 03:12:02 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 30 Oct 2001 10:12:02 -0600 (CST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <20011030165654.A6006@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.BSO.4.33.0110301003150.29759-100000@etoh.eviladmin.org>



On Tue, 30 Oct 2001, Lutz Jaenicke wrote:

> On Tue, Oct 30, 2001 at 09:17:54AM -0600, mouring at etoh.eviladmin.org wrote:
> >
> > I thought the reason we moved to OPENSSL_free() is because free() does not
> > do the right thing on OpenSSL data structures.  Why are we reintroducing
> > this again?  Or did I miss something.
>
> OPENSSL_free() was introduced with OpenSSL 0.9.6, for OpenSSL 0.9.5, free()
> is the correct way to go. In order to allow the use of 0.9.5, OPENSSL_free()
> must be replaced (for <0.9.6 only), because we get an unresolved symbol error
> otherwise.
>

Lutz,

Still does not answer the underlying question.  if OPENSSL_free() ==
free() why have OPENSSL_free()?  Feels like an API for the sake of an API
unless there is plans to make OPENSSL_free() do more.  At which point this
change will be a bad thing.

Not arguing this is not need.  I just would like to get a sense of why.

- Ben



From dwd at bell-labs.com  Wed Oct 31 03:20:53 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 30 Oct 2001 10:20:53 -0600
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011029233557.B3914@zax.half.pint-stowp.cx>; from jmknoble@pobox.com on Mon, Oct 29, 2001 at 11:35:57PM -0500
References: <20011029082657.A23424@lucent.com> <Pine.LNX.4.33.0110301202190.2815-100000@mothra.mindrot.org> <20011029233557.B3914@zax.half.pint-stowp.cx>
Message-ID: <20011030102053.A20295@lucent.com>

On Mon, Oct 29, 2001 at 11:35:57PM -0500, Jim Knoble wrote:
> Circa 2001-Oct-30 12:03:29 +1100 dixit Damien Miller:
> 
> : On Mon, 29 Oct 2001, Dave Dykstra wrote:
> : > With "warn", you can still use forwarding even though you know a server is
> : > not very well secured, and you will be notified if someone does actually
> : > break into the server and try to take over the forwarding on your session.
> : 
> : By which stage it is too late.
> : 
> : What would be nicer is some way for the client to get the user to accept
> : / reject each forwarding request.

I considered that, and maybe it should still be an option, but it has some
problems:
    1. A forward request can come at any time and it could be very awkward
	to prompt in the middle of something that the user is typing into
	such as an editor.  A pop-up window is a possibility but I think
	that's over-engineering.
    2. I think it's much more likely that people will disable a prompt than
	a warning because it's too much pain for the normal case.  Having 
	notification of a compromise is much better than nothing.

If it would help for the patch to be accepted, I will gladly add a fourth
value "ask", but I would still want the "warn" value.


> http://c.home.cern.ch/c/cons/www/mxconns/

Interesting, but not for the masses I don't think, particularly since it
isn't open source and the license doesn't allow use by businesses.

- Dave Dykstra


From djast at cs.toronto.edu  Wed Oct 31 03:53:54 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 30 Oct 2001 11:53:54 -0500
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent 
In-Reply-To: Message from Dave Dykstra <dwd@bell-labs.com> 
   of "Tue, 30 Oct 2001 11:20:53 EST." <20011030102053.A20295@lucent.com> 
Message-ID: <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu>

On Tue, 30 Oct 2001 11:20:53 EST, Dave Dykstra writes:
> > Circa 2001-Oct-30 12:03:29 +1100 dixit Damien Miller:
> > 
> > : What would be nicer is some way for the client to get the user to accept
> > : / reject each forwarding request.
> 
> I considered that, and maybe it should still be an option, but it has some
> problems:
>     1. A forward request can come at any time and it could be very awkward
> 	to prompt in the middle of something that the user is typing into
> 	such as an editor.  A pop-up window is a possibility but I think
> 	that's over-engineering.

Just thinking out loud:

If the feature were to be introduced, perhaps one reasonable way to
design the UI might be for the connection attempt to produce a warning
advising the user to type a newline and a tilde-escape to accept or
reject the connection.  E.g.: introduce the escapes ~+ to accept the
connection, and ~- to reject it; and while we're at it, there should be
a way to redisplay the pending connection(s); perhaps ~# could list
these in addition to established ones.

This, of course, presupposes that a pty has been assigned--but if no pty
has been assigned (or quiet mode is in effect), any sort of prompting is
going to be a problem anyway.

Would such functionality be useful for general port forwardings as well
as X11 and authentication agent forwardings?

-- 
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  Wed Oct 31 03:58:21 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 30 Oct 2001 17:58:21 +0100
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Oct 30, 2001 at 11:53:54AM -0500
References: <dwd@bell-labs.com> <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu>
Message-ID: <20011030175821.A14741@faui02.informatik.uni-erlangen.de>

i think adding some verbose() calls should be enough for all cases.


From Robert.Dahlem at siemens.com  Wed Oct 31 04:11:34 2001
From: Robert.Dahlem at siemens.com (Robert Dahlem)
Date: Tue, 30 Oct 2001 18:11:34 +0100
Subject: [PATCH] some patches for Fujitsu-Siemens ReliantUNIX, minor fixes and XXXes
In-Reply-To: <Pine.UW2.4.40.9.0110271052130.22688-100000@uw711.int.multitalents.net>
Message-ID: <200110301714.f9UHESt19488@mail1.siemens.de>

Tim,

On Sat, 27 Oct 2001 10:56:46 -0700 (PDT), Tim Rice wrote:

>I've commited the configure.ac changes to remove libucb.

Thank you.

>I think the /etc/default/login parts will have to wait until after the
>3.0 release.

Do you expect me to remind you when time has come?

Regards,
        Robert


-- 
Robert.Dahlem at siemens.com
Siemens Business Services - FS GF KORDOBA-Outsourcing
Tel: +49-69-797-6530  Fax: +49-69-797-6599
----------------------------------------------------------------------
Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email
software; far better than Outlook. Try it sometime.




From mouring at etoh.eviladmin.org  Wed Oct 31 04:23:02 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 30 Oct 2001 11:23:02 -0600 (CST)
Subject: [PATCH] some patches for Fujitsu-Siemens ReliantUNIX, minor
 fixes and XXXes
In-Reply-To: <200110301714.f9UHESt19488@mail1.siemens.de>
Message-ID: <Pine.BSO.4.33.0110301120500.8588-100000@etoh.eviladmin.org>


File a bugzilla report at http://bugzilla.mindrot.org/  that will
assure you know the status of it the code and if/when we commit the
change.

- Ben

On Tue, 30 Oct 2001, Robert Dahlem wrote:

> Tim,
>
> On Sat, 27 Oct 2001 10:56:46 -0700 (PDT), Tim Rice wrote:
>
> >I've commited the configure.ac changes to remove libucb.
>
> Thank you.
>
> >I think the /etc/default/login parts will have to wait until after the
> >3.0 release.
>
> Do you expect me to remind you when time has come?
>
> Regards,
>         Robert
>
>
> --
> Robert.Dahlem at siemens.com
> Siemens Business Services - FS GF KORDOBA-Outsourcing
> Tel: +49-69-797-6530  Fax: +49-69-797-6599
> ----------------------------------------------------------------------
> Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email
> software; far better than Outlook. Try it sometime.
>
>
>



From Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct 31 04:49:55 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Tue, 30 Oct 2001 18:49:55 +0100
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.BSO.4.33.0110301003150.29759-100000@etoh.eviladmin.org>
References: <20011030165654.A6006@serv01.aet.tu-cottbus.de> <Pine.BSO.4.33.0110301003150.29759-100000@etoh.eviladmin.org>
Message-ID: <20011030184955.A7654@serv01.aet.tu-cottbus.de>

On Tue, Oct 30, 2001 at 10:12:02AM -0600, mouring at etoh.eviladmin.org wrote:
> On Tue, 30 Oct 2001, Lutz Jaenicke wrote:
> > OPENSSL_free() was introduced with OpenSSL 0.9.6, for OpenSSL 0.9.5, free()
> > is the correct way to go. In order to allow the use of 0.9.5, OPENSSL_free()
> > must be replaced (for <0.9.6 only), because we get an unresolved symbol error
> > otherwise.
> >
> 

> Still does not answer the underlying question.  if OPENSSL_free() ==
> free() why have OPENSSL_free()?  Feels like an API for the sake of an API
> unless there is plans to make OPENSSL_free() do more.  At which point this
> change will be a bad thing.

The following excerpts from the CHANGES file should explain the fundamental
idea behind using specific functions for the memory handling. Practically,
as long as no debugging routines are enabled, it comes done to malloc()
and friends...

...
 Changes between 0.9.5a and 0.9.6  [24 Sep 2000]
...
  *) Rename memory handling macros to avoid conflicts with other
     software:
          Malloc         =>  OPENSSL_malloc
          Malloc_locked  =>  OPENSSL_malloc_locked
          Realloc        =>  OPENSSL_realloc
          Free           =>  OPENSSL_free
...
 Changes between 0.9.4 and 0.9.5  [28 Feb 2000]
...
  *) Rebuild of the memory allocation routines used by OpenSSL code and
     possibly others as well.  The purpose is to make an interface that
     provide hooks so anyone can build a separate set of allocation and
     deallocation routines to be used by OpenSSL, for example memory
     pool implementations, or something else, which was previously hard
     since Malloc(), Realloc() and Free() were defined as macros having
     the values malloc, realloc and free, respectively (except for Win32
     compilations).  The same is provided for memory debugging code.
     OpenSSL already comes with functionality to find memory leaks, but
     this gives people a chance to debug other memory problems.
...

> Not arguing this is not need.  I just would like to get a sense of why.

:-)
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From mouring at etoh.eviladmin.org  Wed Oct 31 04:57:55 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 30 Oct 2001 11:57:55 -0600 (CST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <20011030184955.A7654@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.BSO.4.33.0110301157520.32656-100000@etoh.eviladmin.org>


Thanks.

On Tue, 30 Oct 2001, Lutz Jaenicke wrote:

> On Tue, Oct 30, 2001 at 10:12:02AM -0600, mouring at etoh.eviladmin.org wrote:
> > On Tue, 30 Oct 2001, Lutz Jaenicke wrote:
> > > OPENSSL_free() was introduced with OpenSSL 0.9.6, for OpenSSL 0.9.5, free()
> > > is the correct way to go. In order to allow the use of 0.9.5, OPENSSL_free()
> > > must be replaced (for <0.9.6 only), because we get an unresolved symbol error
> > > otherwise.
> > >
> >
>
> > Still does not answer the underlying question.  if OPENSSL_free() ==
> > free() why have OPENSSL_free()?  Feels like an API for the sake of an API
> > unless there is plans to make OPENSSL_free() do more.  At which point this
> > change will be a bad thing.
>
> The following excerpts from the CHANGES file should explain the fundamental
> idea behind using specific functions for the memory handling. Practically,
> as long as no debugging routines are enabled, it comes done to malloc()
> and friends...
>
> ...
>  Changes between 0.9.5a and 0.9.6  [24 Sep 2000]
> ...
>   *) Rename memory handling macros to avoid conflicts with other
>      software:
>           Malloc         =>  OPENSSL_malloc
>           Malloc_locked  =>  OPENSSL_malloc_locked
>           Realloc        =>  OPENSSL_realloc
>           Free           =>  OPENSSL_free
> ...
>  Changes between 0.9.4 and 0.9.5  [28 Feb 2000]
> ...
>   *) Rebuild of the memory allocation routines used by OpenSSL code and
>      possibly others as well.  The purpose is to make an interface that
>      provide hooks so anyone can build a separate set of allocation and
>      deallocation routines to be used by OpenSSL, for example memory
>      pool implementations, or something else, which was previously hard
>      since Malloc(), Realloc() and Free() were defined as macros having
>      the values malloc, realloc and free, respectively (except for Win32
>      compilations).  The same is provided for memory debugging code.
>      OpenSSL already comes with functionality to find memory leaks, but
>      this gives people a chance to debug other memory problems.
> ...
>
> > Not arguing this is not need.  I just would like to get a sense of why.
>
> :-)
> 	Lutz
> --
> Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
> BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
> Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
> Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153
>



From Darren.Moffat at eng.sun.com  Wed Oct 31 04:58:45 2001
From: Darren.Moffat at eng.sun.com (Darren Moffat)
Date: Tue, 30 Oct 2001 09:58:45 -0800 (PST)
Subject: "last" providing incorrect information on Solaris 8
Message-ID: <200110301800.f9UI0BSI191959@jurassic.eng.sun.com>

>The "last <username>" usage is displaying the sessions as still being
>logged on the server when it's really not.  The "last" by itself shows
>correct information about the session.     Sometimes using the "last
><username>" syntax  the session shows being terminated but the total
>logged in time is hours off.


See the following Sun bugs in SunSolve:

1.  "last" problem - wtmpx entries not properly updated when logging out
    Bug:  1171613
2.  wtmpx entries not properly updated when logging out
    Bug:  4027052
3.  *last* produces inconsistent results when specifying name.
    Bug:  4010009
4.  *last* The last command does not show ftp sessions if using a name
    Bug:  4095482
5.  last command shows still logged on when user is logged out
    Bug:  4119214
6.  *last* last command does not show correct-logout time (ftp login)
    Bug:  1260759


I believe these are releated to the problem you are seeing.
    
--
Darren J Moffat



From Lutz.Jaenicke at aet.TU-Cottbus.DE  Wed Oct 31 05:05:15 2001
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Tue, 30 Oct 2001 19:05:15 +0100
Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd)
In-Reply-To: <20011030184955.A7654@serv01.aet.tu-cottbus.de>
References: <20011030165654.A6006@serv01.aet.tu-cottbus.de> <Pine.BSO.4.33.0110301003150.29759-100000@etoh.eviladmin.org> <20011030184955.A7654@serv01.aet.tu-cottbus.de>
Message-ID: <20011030190515.A8196@serv01.aet.tu-cottbus.de>

On Tue, Oct 30, 2001 at 06:49:55PM +0100, Lutz Jaenicke wrote:
> ...
>  Changes between 0.9.5a and 0.9.6  [24 Sep 2000]
> ...
>   *) Rename memory handling macros to avoid conflicts with other
>      software:
>           Malloc         =>  OPENSSL_malloc
>           Malloc_locked  =>  OPENSSL_malloc_locked
>           Realloc        =>  OPENSSL_realloc
>           Free           =>  OPENSSL_free
> ...

Hmm, while thinking about it: the correct macro substution should therefore
be "Free()" instead of "free()", as we must make sure that the correct
memory handling function (CRYPTO_free()) is being called:

/* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */
#if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f)
# define OPENSSL_free(x) Free(x)
#endif

-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153


From stevev at darkwing.uoregon.edu  Wed Oct 31 05:13:51 2001
From: stevev at darkwing.uoregon.edu (Steve VanDevender)
Date: Tue, 30 Oct 2001 10:13:51 -0800
Subject: "last" providing incorrect information on Solaris 8
In-Reply-To: <200110301800.f9UI0BSI191959@jurassic.eng.sun.com>
References: <200110301800.f9UI0BSI191959@jurassic.eng.sun.com>
Message-ID: <15326.60895.862389.78622@darkwing.uoregon.edu>

Darren Moffat writes:
 > >The "last <username>" usage is displaying the sessions as still being
 > >logged on the server when it's really not.  The "last" by itself shows
 > >correct information about the session.     Sometimes using the "last
 > ><username>" syntax  the session shows being terminated but the total
 > >logged in time is hours off.

I've seen a similar problem, but ascribe it to a discrepancy between the
way Solaris utilities record wtmpx logout records and the way most other
systems do.  Solaris records the username in both login and logout
records, while other systems record the username only in the login
record, and find the matching logout record according to the other
session data in the login record.  The wtmpx handling in OpenSSH does
the latter, so it creates logout records that the Solaris 'last' command
doesn't match up with the corresponding login records.

I hack OpenSSH locally so that in Solaris it does not prematurely return
in the functions that fill in wtmpx logout records.  I've been intending
to float it to the developers for a while, but just haven't sat down to
polish it up for submission.

 > See the following Sun bugs in SunSolve:
 > 
 > 1.  "last" problem - wtmpx entries not properly updated when logging out
 >     Bug:  1171613
 > 2.  wtmpx entries not properly updated when logging out
 >     Bug:  4027052
 > 3.  *last* produces inconsistent results when specifying name.
 >     Bug:  4010009
 > 4.  *last* The last command does not show ftp sessions if using a name
 >     Bug:  4095482
 > 5.  last command shows still logged on when user is logged out
 >     Bug:  4119214
 > 6.  *last* last command does not show correct-logout time (ftp login)
 >     Bug:  1260759
 > 
 > 
 > I believe these are releated to the problem you are seeing.
 >     
 > --
 > Darren J Moffat


From mdb at juniper.net  Wed Oct 31 05:41:10 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Tue, 30 Oct 2001 10:41:10 -0800
Subject: [PATCH] for solaris 2.6
Message-ID: <200110301841.f9UIfA068160@merlot.juniper.net>

I didn't see this one applied to the repository yet. 

It may not be the best patch possible... basic problem is that
_LARGEFILE64_SOURCE needs to be defined on Solaris 2.6 if
AC_SYS_LARGEFILE ends up doing a '#define _FILE_OFFSET_BITS 64'

If _FILE_OFFSET_BITS == 64, then <sys/resource.h> will define a
'struct rlimit64' but NOT define a 'struct rlimit' leading to a
failure to compile ssh.c because 'struct rlimit' is not a complete
type.

When _LARGEFILE64_SOURCE is defined, it adds a #define rlimit rlimit64
so that uses of 'struct rlimit rlim;' will become 'struct rlimit64 rlim;'
by the compiler and the compilation will succeed.

It may be desirable to modify the AC_SYS_LARGEFILE in the autoconf
sources for this situation, but I have not tried to do that.

	Enjoy!
	-- Mark

Index: acconfig.h
===================================================================
RCS file: /cvs/openssh_cvs/acconfig.h,v
retrieving revision 1.118
diff -u -r1.118 acconfig.h
--- acconfig.h	2001/10/22 00:53:59	1.118
+++ acconfig.h	2001/10/30 18:42:56
@@ -332,6 +332,9 @@
 /* Define if you want smartcard support */
 #undef SMARTCARD
 
+/* Define if _FILE_OFFSET_BITS also needs _LARGEFILE64_SOURCE defined */
+#undef _LARGEFILE64_SOURCE
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line ************** */
Index: configure.ac
===================================================================
RCS file: /cvs/openssh_cvs/configure.ac,v
retrieving revision 1.3
diff -u -r1.3 configure.ac
--- configure.ac	2001/10/27 17:45:37	1.3
+++ configure.ac	2001/10/30 18:42:57
@@ -24,6 +24,32 @@
 
 # System features
 AC_SYS_LARGEFILE
+if test "$ac_cv_sys_file_offset_bits" != no; then
+	AC_MSG_CHECKING(if _LARGEFILE64_SOURCE is needed)
+	AC_TRY_COMPILE(
+		[
+#include "confdefs.h"
+#include <sys/resource.h>
+		],
+		[ struct rlimit rlim; ],
+		[ AC_MSG_RESULT(no) ],
+		[ 
+		AC_TRY_COMPILE(
+			[
+#include "confdefs.h"
+#define _LARGEFILE64_SOURCE
+#include <sys/resource.h>
+			],
+			[ struct rlimit rlim; ],
+			[ 
+				AC_MSG_RESULT(yes)
+				AC_DEFINE(_LARGEFILE64_SOURCE)
+			],
+			[ AC_MSG_RESULT(problems with struct rlimit found) ]
+		)
+		]
+	)
+fi
 
 if test -z "$AR" ; then
 	AC_MSG_ERROR([*** 'ar' missing, please install or fix your \$PATH ***])


From roberth at edberg-it.se  Wed Oct 31 05:45:08 2001
From: roberth at edberg-it.se (Roberth Edberg)
Date: Tue, 30 Oct 2001 19:45:08 +0100
Subject: SV: What have I done wrong?
References: <Pine.BSO.4.33.0110300938090.29759-100000@etoh.eviladmin.org>
Message-ID: <000901c16173$03f7f680$0201a8c0@edbergit.se>

How do I know?

\R
----- Original Message ----- 
From: <mouring at etoh.eviladmin.org>
To: Roberth Edberg <roberth at edberg-it.se>
Cc: <openssh-unix-dev at mindrot.org>
Sent: Tuesday, October 30, 2001 4:38 PM
Subject: Re: What have I done wrong?


> 
> Does your Linux required PAM or MD5 passwords..
> 
> If PAM add: --with-pam to your ./configure line
> if MD5 passwords add: --with-md5-passwords to your ./configure line
> 
> On Tue, 30 Oct 2001, Roberth Edberg wrote:
> 
> > Hi,
> >
> > I'm new to both this list and to openssh. I just downloaded 2.9.9 and did ./configure ; make ; make install. Everything was OK, no errors. But I must have done something wrong. Because after I started the sshd daemon, I can only connect with the "root" user. I have done ssh-keygen on other users but they do not work...
> >
> > I'm running Linux. I havent changed any configurations. What have I done wrong? Any ideas?
> >
> > Regards,
> >
> > Roberth Edberg
> >
> 



From mouring at etoh.eviladmin.org  Wed Oct 31 05:51:15 2001
From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org)
Date: Tue, 30 Oct 2001 12:51:15 -0600 (CST)
Subject: SV: What have I done wrong?
In-Reply-To: <000901c16173$03f7f680$0201a8c0@edbergit.se>
Message-ID: <Pine.BSO.4.33.0110301250030.32656-100000@etoh.eviladmin.org>


If you don't know your own OS.. Than you really should not be running it.

Redhat, Mandrake, Suse, TurboLinux -- All are PAM based.

Slackware -- Is not pam based.. required --with-md5-passwords

- Ben

On Tue, 30 Oct 2001, Roberth Edberg wrote:

> How do I know?
>
> \R
> ----- Original Message -----
> From: <mouring at etoh.eviladmin.org>
> To: Roberth Edberg <roberth at edberg-it.se>
> Cc: <openssh-unix-dev at mindrot.org>
> Sent: Tuesday, October 30, 2001 4:38 PM
> Subject: Re: What have I done wrong?
>
>
> >
> > Does your Linux required PAM or MD5 passwords..
> >
> > If PAM add: --with-pam to your ./configure line
> > if MD5 passwords add: --with-md5-passwords to your ./configure line
> >
> > On Tue, 30 Oct 2001, Roberth Edberg wrote:
> >
> > > Hi,
> > >
> > > I'm new to both this list and to openssh. I just downloaded 2.9.9 and did ./configure ; make ; make install. Everything was OK, no errors. But I must have done something wrong. Because after I started the sshd daemon, I can only connect with the "root" user. I have done ssh-keygen on other users but they do not work...
> > >
> > > I'm running Linux. I havent changed any configurations. What have I done wrong? Any ideas?
> > >
> > > Regards,
> > >
> > > Roberth Edberg
> > >
> >
>
>



From roberth at edberg-it.se  Wed Oct 31 05:58:20 2001
From: roberth at edberg-it.se (Roberth Edberg)
Date: Tue, 30 Oct 2001 19:58:20 +0100
Subject: SV: SV: What have I done wrong?
References: <Pine.BSO.4.33.0110301250030.32656-100000@etoh.eviladmin.org>
Message-ID: <001c01c16174$d8949000$0201a8c0@edbergit.se>

Wow, that was a hit under the belt. I've been working with unix since the 80's, but I've never done this.

I think my little StrongArmbased Netwinder is a redhat machine, so I guess I'll try the PAM alternative. Hope it works...

-Rob.
----- Original Message ----- 
From: <mouring at etoh.eviladmin.org>
To: Roberth Edberg <roberth at edberg-it.se>
Cc: <openssh-unix-dev at mindrot.org>
Sent: Tuesday, October 30, 2001 7:51 PM
Subject: Re: SV: What have I done wrong?


> 
> If you don't know your own OS.. Than you really should not be running it.
> 
> Redhat, Mandrake, Suse, TurboLinux -- All are PAM based.
> 
> Slackware -- Is not pam based.. required --with-md5-passwords
> 
> - Ben
> 
> On Tue, 30 Oct 2001, Roberth Edberg wrote:
> 
> > How do I know?
> >
> > \R
> > ----- Original Message -----
> > From: <mouring at etoh.eviladmin.org>
> > To: Roberth Edberg <roberth at edberg-it.se>
> > Cc: <openssh-unix-dev at mindrot.org>
> > Sent: Tuesday, October 30, 2001 4:38 PM
> > Subject: Re: What have I done wrong?
> >
> >
> > >
> > > Does your Linux required PAM or MD5 passwords..
> > >
> > > If PAM add: --with-pam to your ./configure line
> > > if MD5 passwords add: --with-md5-passwords to your ./configure line
> > >
> > > On Tue, 30 Oct 2001, Roberth Edberg wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm new to both this list and to openssh. I just downloaded 2.9.9 and did ./configure ; make ; make install. Everything was OK, no errors. But I must have done something wrong. Because after I started the sshd daemon, I can only connect with the "root" user. I have done ssh-keygen on other users but they do not work...
> > > >
> > > > I'm running Linux. I havent changed any configurations. What have I done wrong? Any ideas?
> > > >
> > > > Regards,
> > > >
> > > > Roberth Edberg
> > > >
> > >
> >
> >
> 



From dwd at bell-labs.com  Wed Oct 31 06:26:46 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 30 Oct 2001 13:26:46 -0600
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011030175821.A14741@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Tue, Oct 30, 2001 at 05:58:21PM +0100
References: <dwd@bell-labs.com> <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu> <20011030175821.A14741@faui02.informatik.uni-erlangen.de>
Message-ID: <20011030132646.C21722@lucent.com>

On Tue, Oct 30, 2001 at 05:58:21PM +0100, Markus Friedl wrote:
> i think adding some verbose() calls should be enough for all cases.

Verbose already has calls during X forwarding but it gets lost in the
noise.  Are you saying verbose should print a stronger warning?

I want something I can enable by default for all my thousand or so users,
and -v prints too much.  If I leave the default as ForwardX11=no, I expect
a lot of people will end up with much worse security because they'll set
DISPLAY and use xhost like they're used to doing without ssh, but I don't
want to enable ForwardX11=yes for everybody because of the risk of the
connections being silently circumvented.

If you still don't agree, I'll keep a private patch, no problem, but I
expect other people might want something like this too.

- Dave Dykstra


From ed at UDel.Edu  Wed Oct 31 06:28:19 2001
From: ed at UDel.Edu (Ed Phillips)
Date: Tue, 30 Oct 2001 14:28:19 -0500 (EST)
Subject: SV: SV: What have I done wrong?
In-Reply-To: <001c01c16174$d8949000$0201a8c0@edbergit.se>
Message-ID: <Pine.SOL.4.30.0110301426100.15543-100000@mahler.udel.edu>

On Tue, 30 Oct 2001, Roberth Edberg wrote:

> Date: Tue, 30 Oct 2001 19:58:20 +0100
> From: Roberth Edberg <roberth at edberg-it.se>
> To: mouring at etoh.eviladmin.org
> Cc: openssh-unix-dev at mindrot.org
> Subject: SV: SV: What have I done wrong?
>
> Wow, that was a hit under the belt. I've been working with unix since
> the 80's, but I've never done this.

Eh... don't worry... they do that to every Openssh-newbie that shows up on
the list asking "silly" questions.  Just persist (and ignore the attitude)
and eventually you'll get the answers you need.  ;-)

	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 djast at cs.toronto.edu  Wed Oct 31 06:30:07 2001
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Tue, 30 Oct 2001 14:30:07 -0500
Subject: [PATCH] for solaris 2.6 
In-Reply-To: Message from "Mark D. Baushke" <mdb@juniper.net> 
   of "Tue, 30 Oct 2001 13:41:10 EST." <200110301841.f9UIfA068160@merlot.juniper.net> 
Message-ID: <01Oct30.143011edt.453139-11303@jane.cs.toronto.edu>

On Tue, 30 Oct 2001 13:41:10 EST, "Mark D. Baushke" writes:
> I didn't see this one applied to the repository yet. 
> 
> It may not be the best patch possible... basic problem is that
> _LARGEFILE64_SOURCE needs to be defined on Solaris 2.6 if
> AC_SYS_LARGEFILE ends up doing a '#define _FILE_OFFSET_BITS 64'
> 
> If _FILE_OFFSET_BITS == 64, then <sys/resource.h> will define a
> 'struct rlimit64' but NOT define a 'struct rlimit' leading to a
> failure to compile ssh.c because 'struct rlimit' is not a complete
> type.
> 
> When _LARGEFILE64_SOURCE is defined, it adds a #define rlimit rlimit64
> so that uses of 'struct rlimit rlim;' will become 'struct rlimit64 rlim;'
> by the compiler and the compilation will succeed.
> 
> It may be desirable to modify the AC_SYS_LARGEFILE in the autoconf
> sources for this situation, but I have not tried to do that.

Caveat: I don't have a Solaris 2.6 machine to test against.  The
following is FYI.

I'm not sure how well-supported an interface _LARGEFILE64_SOURCE is (as
opposed to _LARGEFILE_SOURCE, e.g.); <sys/feature_tests.h> refers to
_LARGEFILE64_SOURCE as a "transitional interface".

The lfcompile(5) man page (Solaris 8 version attached) provides the
supported method of compiling apps with largefile support under Solaris.
Perhaps getconf(1) should be used to define the correct flags (rather
than guessing at which macros need to be defined) to ensure
compatibility with current and future releases of Solaris.

-- 
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
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 7877
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011030/c61d3feb/attachment.mht 

From dwd at bell-labs.com  Wed Oct 31 06:33:25 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 30 Oct 2001 13:33:25 -0600
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Oct 30, 2001 at 11:53:54AM -0500
References: <dwd@bell-labs.com> <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu>
Message-ID: <20011030133324.D21722@lucent.com>

On Tue, Oct 30, 2001 at 11:53:54AM -0500, Dan Astoorian wrote:
> On Tue, 30 Oct 2001 11:20:53 EST, Dave Dykstra writes:
> > > Circa 2001-Oct-30 12:03:29 +1100 dixit Damien Miller:
> > > 
> > > : What would be nicer is some way for the client to get the user to accept
> > > : / reject each forwarding request.
> > 
> > I considered that, and maybe it should still be an option, but it has some
> > problems:
> >     1. A forward request can come at any time and it could be very awkward
> > 	to prompt in the middle of something that the user is typing into
> > 	such as an editor.  A pop-up window is a possibility but I think
> > 	that's over-engineering.
> 
> Just thinking out loud:
> 
> If the feature were to be introduced, perhaps one reasonable way to
> design the UI might be for the connection attempt to produce a warning
> advising the user to type a newline and a tilde-escape to accept or
> reject the connection.  E.g.: introduce the escapes ~+ to accept the
> connection, and ~- to reject it; and while we're at it, there should be
> a way to redisplay the pending connection(s); perhaps ~# could list
> these in addition to established ones.

That makes sense.  Pretty complicated though.


> This, of course, presupposes that a pty has been assigned--but if no pty
> has been assigned (or quiet mode is in effect), any sort of prompting is
> going to be a problem anyway.
> 
> Would such functionality be useful for general port forwardings as well
> as X11 and authentication agent forwardings?

I don't think so.  Whether or not it's a security hole is highly dependent
on the ports being forwarded, and in thinking back on all the times I've
used port forwarding I can't think of any example where it would have been
a security problem if somebody else used the forward.  I'm sure there are
cases, I just don't think it's common enough to put in an option to warn.

- Dave Dykstra


From mdb at juniper.net  Wed Oct 31 06:40:43 2001
From: mdb at juniper.net (Mark D. Baushke)
Date: Tue, 30 Oct 2001 11:40:43 -0800
Subject: [PATCH] for solaris 2.6 
In-Reply-To: Mail from Dan Astoorian <djast@cs.toronto.edu> 
             dated Tue, 30 Oct 2001 14:30:07 EST
             <01Oct30.143011edt.453139-11303@jane.cs.toronto.edu> 
Message-ID: <200110301940.f9UJeh072998@merlot.juniper.net>

Dan wrote:
>Caveat: I don't have a Solaris 2.6 machine to test against.  The
>following is FYI.
>
>I'm not sure how well-supported an interface _LARGEFILE64_SOURCE is (as
>opposed to _LARGEFILE_SOURCE, e.g.); <sys/feature_tests.h> refers to
>_LARGEFILE64_SOURCE as a "transitional interface".

Yes, I was mostly looking at the requirements of getting
<sys/resource.h> to be consistent...

>The lfcompile(5) man page (Solaris 8 version attached) provides the
>supported method of compiling apps with largefile support under Solaris.
>Perhaps getconf(1) should be used to define the correct flags (rather
>than guessing at which macros need to be defined) to ensure
>compatibility with current and future releases of Solaris.

On my Solaris 2.6 box, I see

% getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
% getconf LFS_LINTFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
% getconf LFS_LDFLAGS

% getconf LFS_LIBS

% getconf LFS64_CFLAGS
-D_LARGEFILE64_SOURCE
% getconf LFS64_LINTFLAGS
-D_LARGEFILE64_SOURCE
% getconf LFS64_LIBS

% getconf LFS64_LDFLAGS

%

So, if someone has a 'better' suggested patch that uses getconf on
Solaris, I'm all for it... the alternative would be to 'fix' the
AC_SYS_LARGEFILE so that it does NOT define _FILE_OFFSET_BITS for
Solaris 2.6 boxes.

	Enjoy!
	-- Mark


From tim at multitalents.net  Wed Oct 31 07:00:40 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 30 Oct 2001 12:00:40 -0800 (PST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.LNX.4.33.0110302224300.1314-100000@mothra.mindrot.org>
Message-ID: <Pine.UW2.4.40.9.0110301158370.24889-100000@uw711.int.multitalents.net>

On Tue, 30 Oct 2001, Damien Miller wrote:

> Can people try this patch?

Builds fine with 0.9.5a

>
> Index: defines.h
> ===================================================================
> RCS file: /var/cvs/openssh/defines.h,v
> retrieving revision 1.74
> diff -u -r1.74 defines.h
> --- defines.h	2001/10/30 02:50:40	1.74
> +++ defines.h	2001/10/30 11:23:51
> @@ -45,6 +45,7 @@
>  #include <unistd.h> /* For STDIN_FILENO, etc */
>  #include <termios.h> /* Struct winsize */
>  #include <fcntl.h> /* For O_NONBLOCK */
> +#include <openssl/opensslv.h> /* For OPENSSL_VERSION_NUMBER */
>
>  /* *-*-nto-qnx needs these headers for strcasecmp and LASTLOG_FILE respectively */
>  #ifdef HAVE_STRINGS_H
> @@ -448,6 +449,11 @@
>
>  #ifndef GETPGRP_VOID
>  # define getpgrp() getpgrp(0)
> +#endif
> +
> +/* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */
> +#if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f)
> +# define OPENSSL_free(x) free(x)
>  #endif
>
>  /*
>
> -d
>
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net





From markus at openbsd.org  Wed Oct 31 07:04:50 2001
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 30 Oct 2001 21:04:50 +0100
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011030132646.C21722@lucent.com>; from dwd@bell-labs.com on Tue, Oct 30, 2001 at 01:26:46PM -0600
References: <dwd@bell-labs.com> <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu> <20011030175821.A14741@faui02.informatik.uni-erlangen.de> <20011030132646.C21722@lucent.com>
Message-ID: <20011030210450.A11383@folly>

On Tue, Oct 30, 2001 at 01:26:46PM -0600, Dave Dykstra wrote:
> On Tue, Oct 30, 2001 at 05:58:21PM +0100, Markus Friedl wrote:
> > i think adding some verbose() calls should be enough for all cases.
> 
> Verbose already has calls during X forwarding but it gets lost in the
> noise.  Are you saying verbose should print a stronger warning?

no, currently there are no verbose() calls, just debug().

-m


From tim at multitalents.net  Wed Oct 31 07:28:55 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 30 Oct 2001 12:28:55 -0800 (PST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <20011030190515.A8196@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.UW2.4.40.9.0110301225570.24889-100000@uw711.int.multitalents.net>

On Tue, 30 Oct 2001, Lutz Jaenicke wrote:

> On Tue, Oct 30, 2001 at 06:49:55PM +0100, Lutz Jaenicke wrote:
> > ...
> >  Changes between 0.9.5a and 0.9.6  [24 Sep 2000]
> > ...
> >   *) Rename memory handling macros to avoid conflicts with other
> >      software:
> >           Malloc         =>  OPENSSL_malloc
> >           Malloc_locked  =>  OPENSSL_malloc_locked
> >           Realloc        =>  OPENSSL_realloc
> >           Free           =>  OPENSSL_free
> > ...
>
> Hmm, while thinking about it: the correct macro substution should therefore
> be "Free()" instead of "free()", as we must make sure that the correct
> memory handling function (CRYPTO_free()) is being called:
>
> /* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */
> #if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f)
> # define OPENSSL_free(x) Free(x)
> #endif
>

This builds fine with 0.9.5a also.
But I have not tested it. (I use 0.9.6b on my production versions)

>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From dwd at bell-labs.com  Wed Oct 31 07:31:35 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 30 Oct 2001 14:31:35 -0600
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011030210450.A11383@folly>; from markus@openbsd.org on Tue, Oct 30, 2001 at 09:04:50PM +0100
References: <dwd@bell-labs.com> <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu> <20011030175821.A14741@faui02.informatik.uni-erlangen.de> <20011030132646.C21722@lucent.com> <20011030210450.A11383@folly>
Message-ID: <20011030143135.A24968@lucent.com>

On Tue, Oct 30, 2001 at 09:04:50PM +0100, Markus Friedl wrote:
> On Tue, Oct 30, 2001 at 01:26:46PM -0600, Dave Dykstra wrote:
> > On Tue, Oct 30, 2001 at 05:58:21PM +0100, Markus Friedl wrote:
> > > i think adding some verbose() calls should be enough for all cases.
> > 
> > Verbose already has calls during X forwarding but it gets lost in the
> > noise.  Are you saying verbose should print a stronger warning?
> 
> no, currently there are no verbose() calls, just debug().

Aha, I didn't realize there was a client log level between the default
(INFO) and what -v sets (DEBUG), which one can set with "LogLevel=VERBOSE".
Yes, that will probably do.  I'll try it.

- Dave


From sfishback at interpath.net  Wed Oct 31 08:16:24 2001
From: sfishback at interpath.net (Steven Fishback)
Date: Tue, 30 Oct 2001 16:16:24 -0500
Subject: "last" providing incorrect information on Solaris 8
References: <200110301800.f9UI0BSI191959@jurassic.eng.sun.com> <15326.60895.862389.78622@darkwing.uoregon.edu>
Message-ID: <3BDF18A8.320DA65E@interpath.net>

Thanks guys,
I've seen these Solaris Bug Report items already.   I've already applied all
the latest Solaris 8 Cluster Patches and "last" patches.   None of these work.
I feel strongly it's an OpenSSH  issue since Steve VanDevender has finally
answered my question on how wtmpx handling on Solairs is performed.

Hopefully this code will get pushed to the developers for testing and verify
this is a problem.

Thanks again,
    Steven

Steve VanDevender wrote:

> Darren Moffat writes:
>  > >The "last <username>" usage is displaying the sessions as still being
>  > >logged on the server when it's really not.  The "last" by itself shows
>  > >correct information about the session.     Sometimes using the "last
>  > ><username>" syntax  the session shows being terminated but the total
>  > >logged in time is hours off.
>
> I've seen a similar problem, but ascribe it to a discrepancy between the
> way Solaris utilities record wtmpx logout records and the way most other
> systems do.  Solaris records the username in both login and logout
> records, while other systems record the username only in the login
> record, and find the matching logout record according to the other
> session data in the login record.  The wtmpx handling in OpenSSH does
> the latter, so it creates logout records that the Solaris 'last' command
> doesn't match up with the corresponding login records.
>
> I hack OpenSSH locally so that in Solaris it does not prematurely return
> in the functions that fill in wtmpx logout records.  I've been intending
> to float it to the developers for a while, but just haven't sat down to
> polish it up for submission.
>
>  > See the following Sun bugs in SunSolve:
>  >
>  > 1.  "last" problem - wtmpx entries not properly updated when logging out
>  >     Bug:  1171613
>  > 2.  wtmpx entries not properly updated when logging out
>  >     Bug:  4027052
>  > 3.  *last* produces inconsistent results when specifying name.
>  >     Bug:  4010009
>  > 4.  *last* The last command does not show ftp sessions if using a name
>  >     Bug:  4095482
>  > 5.  last command shows still logged on when user is logged out
>  >     Bug:  4119214
>  > 6.  *last* last command does not show correct-logout time (ftp login)
>  >     Bug:  1260759
>  >
>  >
>  > I believe these are releated to the problem you are seeing.
>  >
>  > --
>  > Darren J Moffat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sfishback.vcf
Type: text/x-vcard
Size: 285 bytes
Desc: Card for Steven Fishback
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011030/8d0e786d/attachment.vcf 

From dwd at bell-labs.com  Wed Oct 31 09:26:47 2001
From: dwd at bell-labs.com (Dave Dykstra)
Date: Tue, 30 Oct 2001 16:26:47 -0600
Subject: Patch to add "warn" value to ForwardX11 and ForwardAgent
In-Reply-To: <20011030143135.A24968@lucent.com>; from dwd@bell-labs.com on Tue, Oct 30, 2001 at 02:31:35PM -0600
References: <dwd@bell-labs.com> <01Oct30.115356edt.453145-11303@jane.cs.toronto.edu> <20011030175821.A14741@faui02.informatik.uni-erlangen.de> <20011030132646.C21722@lucent.com> <20011030210450.A11383@folly> <20011030143135.A24968@lucent.com>
Message-ID: <20011030162647.A29075@lucent.com>

On Tue, Oct 30, 2001 at 02:31:35PM -0600, Dave Dykstra wrote:
> On Tue, Oct 30, 2001 at 05:58:21PM +0100, Markus Friedl wrote:
> > i think adding some verbose() calls should be enough for all cases.
> 
> Aha, I didn't realize there was a client log level between the default
> (INFO) and what -v sets (DEBUG), which one can set with "LogLevel=VERBOSE".
> Yes, that will probably do.  I'll try it.


Yes, I think that works ok, although I am a little concerned about what
other messages might be printed out at the verbose level.  There doesn't
seem to be a lot of calls to verbose(), but I'm not sure if some of those
that are there might be in code that runs in the client.  I think I like
warn better, but if you put this in I'll use it instead.  It still needs
the extra functions in clientloop.c, because channels.c is shared between
the client and the server.

- Dave Dykstra


--- clientloop.c.O	Fri Oct 26 11:47:19 2001
+++ clientloop.c	Tue Oct 30 17:14:44 2001
@@ -1234,6 +1234,36 @@
 	}
 	xfree(rtype);
 }
+static void
+client_input_agent_open(int type, int plen, void *ctxt)
+{
+	if (!options.forward_agent) {
+		deny_input_open(type, plen, ctxt);
+		return;
+	}
+	verbose("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+	verbose("@  ssh NOTICE: received agent open request from the server.        @");
+	verbose("@  If you did not initiate it, you are probably under attack.      @");
+	verbose("@  To eliminate these notices, set the LogLevel option to INFO,    @");
+	verbose("@  but note that that is risky if the server is not well-secured.  @");
+	verbose("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+	auth_input_open_request(type, plen, ctxt);
+}
+static void
+client_input_x11_open(int type, int plen, void *ctxt)
+{
+	if (!options.forward_x11) {
+		deny_input_open(type, plen, ctxt);
+		return;
+	}
+	verbose("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+	verbose("@  ssh NOTICE: received X11 open request from the server.          @");
+	verbose("@  If you did not initiate it, you are probably under attack.      @");
+	verbose("@  To eliminate these notices, set the LogLevel option to INFO,    @");
+	verbose("@  but note that that is risky if the server is not well-secured.  @");
+	verbose("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
+	x11_input_open(type, plen, ctxt);
+}
 
 static void
 client_init_dispatch_20(void)
@@ -1265,11 +1295,8 @@
 	dispatch_set(SSH_SMSG_EXITSTATUS, &client_input_exit_status);
 	dispatch_set(SSH_SMSG_STDERR_DATA, &client_input_stderr_data);
 	dispatch_set(SSH_SMSG_STDOUT_DATA, &client_input_stdout_data);
-
-	dispatch_set(SSH_SMSG_AGENT_OPEN, options.forward_agent ?
-	    &auth_input_open_request : &deny_input_open);
-	dispatch_set(SSH_SMSG_X11_OPEN, options.forward_x11 ?
-	    &x11_input_open : &deny_input_open);
+	dispatch_set(SSH_SMSG_AGENT_OPEN, &client_input_agent_open);
+	dispatch_set(SSH_SMSG_X11_OPEN, &client_input_x11_open);
 }
 static void
 client_init_dispatch_15(void)
--- ssh.1.O	Fri Oct 26 12:56:10 2001
+++ ssh.1	Tue Oct 30 17:22:06 2001
@@ -849,6 +849,14 @@
 .Dq yes
 or
 .Dq no .
+If the
+.Cm LogLevel
+option is set to VERBOSE or higher, a warning is printed every time an
+X11 connection is forwarded; this is highly recommended if the server is
+not well-secured because an agent authentication allows an attacker to
+log in to any other server that has one of the agent's keys in an
+.Pa authorized_keys
+file.
 The default is
 .Dq no .
 .It Cm ForwardX11
@@ -860,6 +868,12 @@
 .Dq yes
 or
 .Dq no .
+If the
+.Cm LogLevel
+option is set to VERBOSE or higher, a warning is printed every time an
+X11 connection is forwarded; this is highly recommended if the server is
+not well-secured because an X11 connection can read and write anything
+on the user's X11 display.
 The default is
 .Dq no .
 .It Cm GatewayPorts


From djm at mindrot.org  Wed Oct 31 10:32:07 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 Oct 2001 10:32:07 +1100 (EST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <Pine.BSO.4.33.0110300916550.29759-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.33.0110311031410.18739-100000@mothra.mindrot.org>

On Tue, 30 Oct 2001 mouring at etoh.eviladmin.org wrote:

> I thought the reason we moved to OPENSSL_free() is because free() does not
> do the right thing on OpenSSL data structures.  Why are we reintroducing
> this again?  Or did I miss something.

Older OpenSSL's don't provide free() themselves.

-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 Oct 31 10:36:04 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 Oct 2001 10:36:04 +1100 (EST)
Subject: Recent openssl is required for OPENSSL_free [Re: Please test
 snapshots for 3.0 release] (fwd)
In-Reply-To: <20011030190515.A8196@serv01.aet.tu-cottbus.de>
Message-ID: <Pine.LNX.4.33.0110311034460.18739-100000@mothra.mindrot.org>

On Tue, 30 Oct 2001, Lutz Jaenicke wrote:

> Hmm, while thinking about it: the correct macro substution should therefore
> be "Free()" instead of "free()", as we must make sure that the correct
> memory handling function (CRYPTO_free()) is being called:

That is (as the OpenSSL developers discovered) a namespace collision 
waiting to happen. Can people try this patch?

Index: defines.h
===================================================================
RCS file: /var/cvs/openssh/defines.h,v
retrieving revision 1.74
diff -u -r1.74 defines.h
--- defines.h	2001/10/30 02:50:40	1.74
+++ defines.h	2001/10/30 23:35:22
@@ -45,6 +45,7 @@
 #include <unistd.h> /* For STDIN_FILENO, etc */
 #include <termios.h> /* Struct winsize */
 #include <fcntl.h> /* For O_NONBLOCK */
+#include <openssl/opensslv.h> /* For OPENSSL_VERSION_NUMBER */
 
 /* *-*-nto-qnx needs these headers for strcasecmp and LASTLOG_FILE respectively */
 #ifdef HAVE_STRINGS_H
@@ -448,6 +449,11 @@
 
 #ifndef GETPGRP_VOID
 # define getpgrp() getpgrp(0)
+#endif
+
+/* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */
+#if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f)
+# define OPENSSL_free(x) Free(x)
 #endif
 
 /*


-- 
| 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 Oct 31 10:37:27 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 Oct 2001 10:37:27 +1100 (EST)
Subject: SV: SV: What have I done wrong?
In-Reply-To: <001c01c16174$d8949000$0201a8c0@edbergit.se>
Message-ID: <Pine.LNX.4.33.0110311036530.18739-100000@mothra.mindrot.org>

On Tue, 30 Oct 2001, Roberth Edberg wrote:

> Wow, that was a hit under the belt. I've been working with unix since the 80's, but I've never done this.
> 
> I think my little StrongArmbased Netwinder is a redhat machine, so I guess I'll try the PAM alternative. Hope it works...

If you are running Redhat, then you are best advised to rebuild from the 
source RPMs - they include all the options you need.

-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 Oct 31 10:38:18 2001
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 Oct 2001 10:38:18 +1100 (EST)
Subject: SV: SV: What have I done wrong?
In-Reply-To: <Pine.SOL.4.30.0110301426100.15543-100000@mahler.udel.edu>
Message-ID: <Pine.LNX.4.33.0110311037531.18739-100000@mothra.mindrot.org>

On Tue, 30 Oct 2001, Ed Phillips wrote:

> Eh... don't worry... they do that to every Openssh-newbie that shows up on
> the list asking "silly" questions.  Just persist (and ignore the attitude)
> and eventually you'll get the answers you need.  ;-)

Reading the FAQ and checking the mailing list archives helps too.

-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  Wed Oct 31 11:24:16 2001
From: jmknoble at pobox.com (Jim Knoble)
Date: Tue, 30 Oct 2001 19:24:16 -0500
Subject: OpenSSH-3.0p1-pre-CVS: configure.ac checks for login in -lutil and -lbsd?
Message-ID: <20011030192416.G3914@zax.half.pint-stowp.cx>

OpenSSH-3.0p1-pre, from CVS as of about 2001-10-30 23:45 UTC.

Any particular reason why configure is checking for login() in -lutil,
finds it, then checks for it again in -lbsd?

Here's the relevant excerpts (Red Hat Linux 6.2, , kernel-2.2.19,
glibc-2.1.3, egcs-1.1.2, autoconf-2.52):

  $ CFLAGS='-O2 -mpentium -Wall'; export CFLAGS
  $ ./configure --prefix=/usr/local/encap/openssh_cvs-2001.10.30.2345UTC
  ...
  checking for yp_match... no
  checking for yp_match in -lnsl... yes
  checking for setsockopt... yes
  checking for getspnam... yes
  checking for login... no
  checking for login in -lutil... yes   <--- #define HAVE_LIBUTIL_LOGIN
              ^^^^^^^^^^^^^^^^^^^^^^^^
  checking for deflate in -lz... yes
  ...
  checking for libutil.h... no
  checking for login... (cached) no
              ^^^^^^^^^^^^^^^^^^^^^^
  checking for logout... yes
  checking for updwtmp... yes
  checking for logwtmp... yes
  ...
  checking for getuserattr... no
  checking for getuserattr in -ls... no
  checking for login... (cached) no
              ^^^^^^^^^^^^^^^^^^^^^^
  checking for login in -lbsd... yes    <--- #define HAVE_LOGIN
              ^^^^^^^^^^^^^^^^^^^^^^^
  checking for daemon... yes
  ...
  OpenSSH has been configured with the following options:
                   User binaries: /usr/local/encap/openssh_cvs-2001.10.30.2345UTC/bin
                 System binaries: /usr/local/encap/openssh_cvs-2001.10.30.2345UTC/sbin
             Configuration files: /usr/local/encap/openssh_cvs-2001.10.30.2345UTC/etc
                 Askpass program: /usr/local/encap/openssh_cvs-2001.10.30.2345UTC/libexec/ssh-askpass
                    Manual pages: /usr/local/encap/openssh_cvs-2001.10.30.2345UTC/man/manX
                        PID file: /var/run
          sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/encap/openssh_cvs-2001.10.30.2345UTC/bin
        Random number collection: Device (/dev/urandom)
                  Manpage format: doc
                     PAM support: no
              KerberosIV support: no
               Smartcard support: no
                     AFS support: no
                   S/KEY support: no
            TCP Wrappers support: no
            MD5 password support: no
     IP address in $DISPLAY hack: no
        Use IPv4 by default hack: no
         Translate v4 in v6 hack: yes
  
                Host: i586-pc-linux-gnu
            Compiler: egcs -pipe
      Compiler flags: -O2 -mpentium -Wall -Wall -Wpointer-arith -Wno-uninitialized
  Preprocessor flags: 
        Linker flags: 
           Libraries: -lz -lnsl  -lutil -lbsd -lcrypto -lcrypt 
                                ^^^^^^^^^^^^^^

Shouldn't finding login() in -lutil define both HAVE_LIBUTIL_LOGIN and
HAVE_LOGIN?  Or am i missing something?

-- 
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/20011030/2d95dfd2/attachment.bin 

From tim at multitalents.net  Wed Oct 31 14:29:53 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 30 Oct 2001 19:29:53 -0800 (PST)
Subject: OpenSSH-3.0p1-pre-CVS: configure.ac checks for login in -lutil
 and -lbsd?
In-Reply-To: <20011030192416.G3914@zax.half.pint-stowp.cx>
Message-ID: <Pine.UW2.4.40.9.0110301900580.5730-100000@uw711.int.multitalents.net>

On Tue, 30 Oct 2001, Jim Knoble wrote:

> OpenSSH-3.0p1-pre, from CVS as of about 2001-10-30 23:45 UTC.
>
> Any particular reason why configure is checking for login() in -lutil,
> finds it, then checks for it again in -lbsd?
>
[snip]
> Shouldn't finding login() in -lutil define both HAVE_LIBUTIL_LOGIN and
> HAVE_LOGIN?  Or am i missing something?
>
Hmm, HAVE_LIBUTIL_LOGIN isn't used anywhere in the source.

Try this patch.

------------< cut >------------
--- acconfig.h.old	Sun Oct 21 17:53:59 2001
+++ acconfig.h	Tue Oct 30 17:57:48 2001
@@ -178,9 +178,6 @@
 /* Define if you want to specify the path to your wtmpx file */
 #undef CONF_WTMPX_FILE

-/* Define is libutil has login() function */
-#undef HAVE_LIBUTIL_LOGIN
-
 /* Define if you want external askpass support */
 #undef USE_EXTERNAL_ASKPASS

--- configure.ac.old	Sat Oct 27 10:45:37 2001
+++ configure.ac	Tue Oct 30 18:03:07 2001
@@ -370,9 +370,6 @@

 AC_CHECK_FUNC(getspnam, ,
 	AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen"))
-AC_CHECK_FUNC(login, ,
-	AC_CHECK_LIB(util, login,
-		AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil"))

 dnl zlib is required
 AC_ARG_WITH(zlib,
@@ -619,7 +616,7 @@
 AC_CHECK_FUNCS(gettimeofday time)
 dnl    Checks for libutil functions
 AC_CHECK_HEADERS(libutil.h)
-AC_CHECK_FUNCS(login logout updwtmp logwtmp)
+AC_CHECK_FUNCS(logout updwtmp logwtmp)
 dnl    Checks for utmp functions
 AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent)
 AC_CHECK_FUNCS(utmpname)
@@ -634,7 +631,9 @@

 AC_CHECK_FUNC(login,
 	[AC_DEFINE(HAVE_LOGIN)],
+	[AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LOGIN) LIBS="$LIBS -lutil",
 	[AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])]
+	)]
 )

 AC_CHECK_FUNC(daemon,
------------< end cut >------------

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net





From tim at multitalents.net  Wed Oct 31 15:10:31 2001
From: tim at multitalents.net (Tim Rice)
Date: Tue, 30 Oct 2001 20:10:31 -0800 (PST)
Subject: OpenSSH-3.0p1-pre-CVS: configure.ac checks for login in -lutil
 and -lbsd?
In-Reply-To: <Pine.UW2.4.40.9.0110301900580.5730-100000@uw711.int.multitalents.net>
Message-ID: <Pine.UW2.4.40.9.0110302006570.5906-100000@uw711.int.multitalents.net>

On Tue, 30 Oct 2001, Tim Rice wrote:

> On Tue, 30 Oct 2001, Jim Knoble wrote:
>
> > OpenSSH-3.0p1-pre, from CVS as of about 2001-10-30 23:45 UTC.
> >
> > Any particular reason why configure is checking for login() in -lutil,
> > finds it, then checks for it again in -lbsd?
> >
> [snip]
> > Shouldn't finding login() in -lutil define both HAVE_LIBUTIL_LOGIN and
> > HAVE_LOGIN?  Or am i missing something?
> >
> Hmm, HAVE_LIBUTIL_LOGIN isn't used anywhere in the source.
>
> Try this patch.
>
> ------------< cut >------------
[snip]
> ------------< end cut >------------
>

Opps, although it compiles fine with the previous patch,
this one is more correct.  (finds login, logout, & logwtmp like it should)
------------< cut >------------
--- acconfig.h.old	Sun Oct 21 17:53:59 2001
+++ acconfig.h	Tue Oct 30 17:57:48 2001
@@ -178,9 +178,6 @@
 /* Define if you want to specify the path to your wtmpx file */
 #undef CONF_WTMPX_FILE

-/* Define is libutil has login() function */
-#undef HAVE_LIBUTIL_LOGIN
-
 /* Define if you want external askpass support */
 #undef USE_EXTERNAL_ASKPASS

--- configure.ac.old	Sat Oct 27 10:45:37 2001
+++ configure.ac	Tue Oct 30 20:02:07 2001
@@ -370,9 +370,6 @@

 AC_CHECK_FUNC(getspnam, ,
 	AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen"))
-AC_CHECK_FUNC(login, ,
-	AC_CHECK_LIB(util, login,
-		AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil"))

 dnl zlib is required
 AC_ARG_WITH(zlib,
@@ -619,7 +616,13 @@
 AC_CHECK_FUNCS(gettimeofday time)
 dnl    Checks for libutil functions
 AC_CHECK_HEADERS(libutil.h)
-AC_CHECK_FUNCS(login logout updwtmp logwtmp)
+AC_CHECK_FUNC(login,
+	[AC_DEFINE(HAVE_LOGIN)],
+	[AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LOGIN) LIBS="$LIBS -lutil",
+	[AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])]
+	)]
+)
+AC_CHECK_FUNCS(logout updwtmp logwtmp)
 dnl    Checks for utmp functions
 AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent)
 AC_CHECK_FUNCS(utmpname)
@@ -630,11 +633,6 @@
 AC_CHECK_FUNC(getuserattr,
 	[AC_DEFINE(HAVE_GETUSERATTR)],
 	[AC_CHECK_LIB(s, getuserattr, [LIBS="$LIBS -ls"; AC_DEFINE(HAVE_GETUSERATTR)])]
-)
-
-AC_CHECK_FUNC(login,
-	[AC_DEFINE(HAVE_LOGIN)],
-	[AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])]
 )

 AC_CHECK_FUNC(daemon,
------------< end cut >------------
>

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From mats.andersson at appgate.com  Wed Oct 31 02:57:44 2001
From: mats.andersson at appgate.com (Andersson, Mats)
Date: Tue, 30 Oct 2001 16:57:44 +0100 (CET)
Subject: SV: SV: What have I done wrong?
In-Reply-To: <Pine.LNX.4.33.0110311036530.18739-100000@mothra.mindrot.org>
Message-ID: <Pine.LNX.4.30.0110301654480.11156-100000@mindbright.sto.appgate.com>


On Wed, 31 Oct 2001, Damien Miller wrote:
> If you are running Redhat, then you are best advised to rebuild from
> the source RPMs - they include all the options you need.

A helpful hint here would be that PAM support is not strictly _needed_
eventhough the platform _supports_ it, however, if the platform has
md5-passwords, you _need_ to have md5-passwords compiled in (if you want
to use passwords).

Cheers,

/Mats