From postmaster at kreditkort.is  Mon Sep  1 10:59:51 2003
From: postmaster at kreditkort.is (postmaster at kreditkort.is)
Date: Mon Sep 01 10:59:51 2003
Subject: Virus Detected by Network Associates, Inc. Webshield SMTP V4.5 MR1a
Message-ID: <20030901105416.CD1B927C19B@shitei.mindrot.org>

Network Associates WebShield SMTP V4.5 MR1a on askur detected virus W32/Sobig.f at MM in
attachment unknown from <openssh-unix-dev at mindrot.org> and it was Deleted and
Quarantined.



From postmaster at kreditkort.is  Mon Sep  1 20:59:51 2003
From: postmaster at kreditkort.is (postmaster at kreditkort.is)
Date: Mon, 1 Sep 2003 10:59:51 +0000
Subject: Delivery Status Notification (Failure)
Message-ID: <38AjrNL4L00000da1@thor.europay.is>

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

       sms at EUROPAY.IS



-------------- next part --------------
An embedded message was scrubbed...
From: <openssh-unix-dev at mindrot.org>
Subject: [SPAM/VIRUS] Re: Your application
Date: Mon, 1 Sep 2003 10:56:15 -0000
Size: 3254
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030901/ad570dd1/attachment.mht 

From qfrederic at cocobar.org  Tue Sep  2 10:13:39 2003
From: qfrederic at cocobar.org (C  B)
Date: Mon, 1 Sep 2003 20:13:39 -0400
Subject: F e d.  p r o v i n c i a l   f i n a n c i n g
Message-ID: <200309020017.h820HEL25952@plugngo.travelnet.ca>


  
  
  

CANADA BOOKS
36 Felix Renaud
Aylmer	
Qc
J9H 7C1
(819)682-7983


PRESS RELEASE

CANADIAN SUBSIDY DIRECTORY YEAR 2003 EDITION

Legal Deposit-National Library of Canada
ISBN 2-922870-05-7

The new revised edition of the Canadian Subsidy Directory 2003 is now
available. 
The new edition is the most complete and affordable reference for anyone
looking for financial support.
It is deemed to be the perfect tool for new or existing businesses,
individual ventures, foundations and associations.

This Publication contains  more than 2000 direct and indirect financial
subsidies, grants and loans offered by government departments and
agencies, foundations, associations and organisations.  In this new 2003
edition
all programs are well described.

The Canadian Subsidy Directory is the most comprehensive tool to start up
a business, improve existent activities, set up a business plan, or obtain
assistance from experts in fields such as: Industry, transport,
agriculture, communications, municipal infrastructure, education,
import-export, labor, construction and renovation, the service sector,
hi-tech industries, research and development, joint ventures, arts,
cinema, theatre, music and recording industry, the self employed,
contests, and new talents.
Assistance from and for foundations and associations, guidance to prepare
a business plan, market surveys, computers, and much more!

The Canadian Subsidy Directory is sold $ 69.95, to obtain a copy please
call:

Canada Books, (819)682-7983















From glen at montreal.hcl.com  Wed Sep  3 23:48:47 2003
From: glen at montreal.hcl.com (Glen Matthews)
Date: Wed, 3 Sep 2003 09:48:47 -0400
Subject: value for SSH_MSG_USERAUTH_GSSAPI_ERRTOK
Message-ID: <GKEILDMJKNCAHMGIGICJEEMDDMAA.glen@montreal.hcl.com>

Hi,

  i notice in draft-ietf-secsh-gsskeyex-06.txt that the value for
SSH_MSG_USERAUTH_GSSAPI_ERRTOK is not defined. does anyone know what this
should be (i guess *will* be in a future rev)? thanks

glen



From openssh-dev at joelweber.com  Thu Sep  4 02:55:55 2003
From: openssh-dev at joelweber.com (Joel N. Weber II)
Date: Wed, 03 Sep 2003 12:55:55 -0400
Subject: value for SSH_MSG_USERAUTH_GSSAPI_ERRTOK
In-Reply-To: <GKEILDMJKNCAHMGIGICJEEMDDMAA.glen@montreal.hcl.com>
References: <GKEILDMJKNCAHMGIGICJEEMDDMAA.glen@montreal.hcl.com>
Message-ID: <E19uavD-0003Qu-00@xanthine.gratuitous.org>

> i notice in draft-ietf-secsh-gsskeyex-06.txt that the value for
> SSH_MSG_USERAUTH_GSSAPI_ERRTOK is not defined. does anyone know what this
> should be (i guess *will* be in a future rev)? thanks

The correct list for such questions would be the IETF working group
list, which happens to be ietf-ssh at netbsd.org







From angus at broadweb.com.tw  Thu Sep  4 13:39:33 2003
From: angus at broadweb.com.tw (=?big5?B?tsCozMDc?=)
Date: Thu, 4 Sep 2003 11:39:33 +0800
Subject: SSH2: How can I forced the server(ssh2) to send messages to client?
Message-ID: <DNEPLHHHNFBGPEPIILIGAEMOCCAA.angus@broadweb.com.tw>

Hi:
My ssh server  ( In ssh2 ) want to send messages to client ( putty ).
But I can't find way to do this.

I write below code :

packet_start( I_DONT_KNOW_WHICH_ID_TO_BE_USED );  <- ???
packet_put_cstring( "Some messages..." );
packet_send( );
packet_write_wait( );


In packet_start( ), Which ID must be used?
Or there is the other way?



From Ulrich.Windl at rz.uni-regensburg.de  Thu Sep  4 17:05:55 2003
From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl)
Date: Thu, 04 Sep 2003 09:05:55 +0200
Subject: OpenSSH 3.5p1 (HP version): permissions of public identity
Message-ID: <3F570074.15709.4A5AA2@localhost>

Hello,

I just received thes odd messages from HP-UX Secure Shell A.03.50.000. 
(OpenSSH 3.5p1):

# ssh-add id_rsa.pub
5215: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
5215: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
5215: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
5215: Permissions 0644 for 'id_rsa.pub' are too open.
5215: It is recommended that your private key files are NOT accessible by 
others.
5215: This private key will be ignored.
5215: bad permissions: ignore key: id_rsa.pub
Enter passphrase for id_rsa.pub:

Now I think the ".pub" is a public key, so what's wrong with the permissions? 
Also, when private key will be ignored, why then ask for a password?

I'm a bit confused.

Regards,
Ulrich



From Ulrich.Windl at rz.uni-regensburg.de  Thu Sep  4 17:08:31 2003
From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl)
Date: Thu, 04 Sep 2003 09:08:31 +0200
Subject: ssh-add -h gives incomplete message
Message-ID: <3F570110.13814.4CBD1F@localhost>

Hi,

I just realized that the help message of "ssh-add -h" is incomplete:

# ssh-add -h
ssh-add: illegal option -- h
Usage: ssh-add [options]
Options:
  -l          List fingerprints of all identities.
  -L          List public key parameters of all identities.
  -d          Delete identity.
  -D          Delete all identities.
  -x          Lock agent.
  -X          Unlock agent.
  -t life     Set lifetime (in seconds) when adding identities.

The manual page says:
 SYNOPSIS
      ssh-add [-lLdDxX] [-t life] [file ...]
      ssh-add -s reader
      ssh-add -e reader

Most important, ssh-add -h does not tell you that you may pass an identity 
file as argument.

Regards,
Ulrich



From maniac at maniac.nl  Thu Sep  4 20:04:48 2003
From: maniac at maniac.nl (Mark Janssen)
Date: Thu, 04 Sep 2003 12:04:48 +0200
Subject: OpenSSH 3.5p1 (HP version): permissions of public identity
In-Reply-To: <3F570074.15709.4A5AA2@localhost>
References: <3F570074.15709.4A5AA2@localhost>
Message-ID: <1062669887.638.0.camel@ninja>

On Thu, 2003-09-04 at 09:05, Ulrich Windl wrote:
> Hello,
> 
> I just received thes odd messages from HP-UX Secure Shell A.03.50.000. 
> (OpenSSH 3.5p1):
> 
> # ssh-add id_rsa.pub
[snipped error messages]

Try ssh-adding your PRIVATE key...
$ ssh-add id_rsa

-- 
Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178
Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT
Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl




From djm at mindrot.org  Thu Sep  4 21:47:06 2003
From: djm at mindrot.org (Damien Miller)
Date: Thu, 04 Sep 2003 11:47:06 -0000
Subject: OpenSSH 3.5p1 (HP version): permissions of public identity
In-Reply-To: <3F570074.15709.4A5AA2@localhost>
References: <3F570074.15709.4A5AA2@localhost>
Message-ID: <1062675845.28417.6.camel@sakura.mindrot.org>

On Thu, 2003-09-04 at 17:05, Ulrich Windl wrote:
> Hello,
> 
> I just received thes odd messages from HP-UX Secure Shell A.03.50.000. 
> (OpenSSH 3.5p1):
> 
> # ssh-add id_rsa.pub

Don't add public keys. 

ssh-add id_rsa

-d




From Ulrich.Windl at rz.uni-regensburg.de  Thu Sep  4 22:32:22 2003
From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl)
Date: Thu, 04 Sep 2003 14:32:22 +0200
Subject: OpenSSH 3.5p1 (HP version): permissions of public identity
In-Reply-To: <1062669887.638.0.camel@ninja>
References: <3F570074.15709.4A5AA2@localhost>
Message-ID: <3F574CF7.27019.1753D30@localhost>

On 4 Sep 2003 at 12:04, Mark Janssen wrote:

> On Thu, 2003-09-04 at 09:05, Ulrich Windl wrote:
> > Hello,
> > 
> > I just received thes odd messages from HP-UX Secure Shell A.03.50.000. 
> > (OpenSSH 3.5p1):
> > 
> > # ssh-add id_rsa.pub
> [snipped error messages]
> 
> Try ssh-adding your PRIVATE key...

You are right; I mixed up the authentication model. Anyway the program was 
asking for a password after telling me that it will ignore the key. 
Inconsistent...

> $ ssh-add id_rsa

Regards,
Ulrich



From vinit.k at sonata-software.com  Fri Sep  5 15:41:31 2003
From: vinit.k at sonata-software.com (Vinit Khandelwal)
Date: Fri, 5 Sep 2003 11:11:31 +0530 
Subject: doing scp from java when file has spaces in it
Message-ID: <30402B4CB8C7D311A3C600C04F1513BC028A9864@bg2ipmail>

Hi,

I am new to scp. I am trying to scp a file from local (m/c) to remote
through a java application running in Tomcat.

When I try to upload a file with no spaces in it, it works. But if spaces
are present (file name is : "Lots of spaces text .txt") it is not working.

Some of the things I tried are mentioned below and they failed. 

scp  [...options]  '/vhosts/dw02411/tmp_daemon/1020046111/Lots of spaces
text .txt' grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111/Lots\\ of\\
spaces\\ text\\ .txt grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111/Lots\ of\ spaces\
text\ .txt grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111/"Lots of spaces
text .txt" grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111//"Lots of spaces
text .txt/" grt0002d at loninwebp7.uk.db.com:uploads 

Is there any other way of running the command for scp from java application?

Thanks in advance.

Vinit
*********************************************************************
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you may
not copy or deliver this message to anyone. In such case, you should destroy
this message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email for
messages of this kind.
*********************************************************************



From vinit.k at sonata-software.com  Fri Sep  5 15:43:17 2003
From: vinit.k at sonata-software.com (Vinit Khandelwal)
Date: Fri, 5 Sep 2003 11:13:17 +0530 
Subject: Recall: doing scp from java when file has spaces in it
Message-ID: <30402B4CB8C7D311A3C600C04F1513BC028A986B@bg2ipmail>

Vinit Khandelwal would like to recall the message, "doing scp from java when
file has spaces in
it".*********************************************************************
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you may
not copy or deliver this message to anyone. In such case, you should destroy
this message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email for
messages of this kind.
*********************************************************************



From josv at osp.nl  Fri Sep  5 16:38:11 2003
From: josv at osp.nl (Jos Visser)
Date: Fri, 5 Sep 2003 08:38:11 +0200
Subject: /dev/random for HP-UX 11.00
Message-ID: <20030905063811.GC934@jadzia.rcc.eu.abnamro.com>

Hi,

I "developed" an implementation of /dev/random for HP-UX 11.00
that can be used to speed up entropy gathering for OpenSSL/OpenSSH
implementations on HP-UX 11.00.

It is still a first release, lots of stuff still to be done, but
interested people can take a look at:

	http://www.josvisser.nl/hpux11-random/

Share and enjoy!

++Jos.nl

P.S. I sent this message to the "user" mailing list too, but that seems
     to be dead... I checked the archives and it's mostly spam in
     there...

-- 
ek is so lug jy vlieg deur my
sonder jou is ek sonder patroon
   "Breyten Breytenbach"



From v_t_m at seznam.cz  Fri Sep  5 19:48:57 2003
From: v_t_m at seznam.cz (=?iso-8859-2?Q?V=E1clav=20Tomec?=)
Date: Fri, 05 Sep 2003 11:48:57 +0200 (CEST)
Subject: SecurID auth for OpenSSH 3.6.1p2 with shared login
Message-ID: <129176.214264-31466-1730832191-1062755337@seznam.cz>

Hello all,

on page http://sweb.cz/v_t_m/ is available new version of
SecurID patch.

changes:
  - corrected small bug
  - this patch is dependent on Auth selection patch
  - added support for shared login - details on web


VT
____________________________________________________________
MMS a? na rok zdarma!
Oskar?v D?rkov? ko? nab?z? i MMSky. A? rok budete MMSkovat zdarma ? a nav?c
po??dite i zv?hodn?n? mobil. http://ad2.seznam.cz/redir.cgi?instance=60091%26url=http://www.oskarmobil.cz/services/whatsnew.php



From stuge-openssh-unix-dev at cdy.org  Fri Sep  5 21:19:47 2003
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 5 Sep 2003 13:19:47 +0200
Subject: authorized_keys options for remote forwarding
In-Reply-To: <20030829120602.GG11415@iwoars.net>
References: <20030829120602.GG11415@iwoars.net>
Message-ID: <20030905111946.GA17851@foo.birdnet.se>

On Fri, Aug 29, 2003 at 02:06:02PM +0200, Thomas Themel wrote:
> Hi,
> 
> I've recently run into a situation where it I want clients (or certain
> keys) to connect to an OpenSSH server and set up a remote port
> forwarding channel (-R) without allowing them to do anything else.

Hmm, do you mean like this?

command="/usr/bin/cat",no-X11-forwarding,no-agent-forwarding,\
permitopen="ip1:port1",permitopen="ip2:port2" ssh-rsa AAAA...

This works very well for me, although I should at least point cat to
/dev/null, or even better code up a client that _only_ does the forwarding.


//Peter



From dan at doxpara.com  Sat Sep  6 02:29:56 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 05 Sep 2003 09:29:56 -0700
Subject: authorized_keys options for remote forwarding
In-Reply-To: <20030905111946.GA17851@foo.birdnet.se>
References: <20030829120602.GG11415@iwoars.net>
	<20030905111946.GA17851@foo.birdnet.se>
Message-ID: <3F58BA04.3080901@doxpara.com>

>
>
>command="/usr/bin/cat",no-X11-forwarding,no-agent-forwarding,\
>permitopen="ip1:port1",permitopen="ip2:port2" ssh-rsa AAAA...
>  
>
Doesn't this allow any file on the system to be read, or written to for 
that matter?

I tend to use either sleep, or a tiny app called sleepy that's the C 
equivalent of:

while [ 1 ] do echo $; sleep 5; done

--Dan




From rac at tenzing.org  Sat Sep  6 02:50:47 2003
From: rac at tenzing.org (Roger Cornelius)
Date: Fri, 5 Sep 2003 12:50:47 -0400
Subject: 3.6p1 bug on SCO OpenServer
Message-ID: <200309051650.h85Gol726140@tenzing.org>

SCO OpenServer 5.0.x
Openssh 3.6p1

loginrec.c writes incorrect data into the ut_id field of the utmp file.
This has been an issue since at least openssh 3.0.2 but I never bothered
to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
the problem.  Below is a brief patch to configure which does this.  You
can observe the errant results in the "Line" column from the output
of /usr/bin/last:

Script started on Fri Sep  5 12:05:37 2003
$ /usr/bin/last -n 5 rac
User     Line  Device       PID    Login time       Elapsed Time Comments
rac      p8    ttyp8        28825  Fri Sep  5 12:14      00:20   logged in
rac      typ2  ttyp2        1168   Thu Sep  4 19:25      16:40   logged in
rac      typ1  ttyp1        1023   Thu Sep  4 19:14      16:51   logged in
rac      typ0  ttyp0        1013   Thu Sep  4 19:14      16:51   logged in
rac      yp24  ttyp24       16191  Wed Sep  3 09:21   1d 23:04          ??
$

Script done on Fri Sep  5 12:05:54 2003

The first entry is a telnet login.  All other entries are ssh logins.
Note the difference in the Line column between the telnet and ssh
entries.  The output should look like this:

User     Line  Device       PID    Login time       Elapsed Time Comments
rac      p8    ttyp8        28825  Fri Sep  5 12:14      00:20   logged in
rac      p2    ttyp2        1168   Thu Sep  4 19:25      16:40   logged in
rac      p1    ttyp1        1023   Thu Sep  4 19:14      16:51   logged in
rac      p0    ttyp0        1013   Thu Sep  4 19:14      16:51   logged in
rac      p24   ttyp24       16191  Wed Sep  3 09:21   1d 23:04          ??

Here's the patch:

--8<-- cut here --8<--
*** configure.orig  2003-03-26 00:12:34.000000000 -0500
--- configure   2003-07-18 17:26:00.000000000 -0400
***************
*** 4588,4593 ****
--- 4588,4597 ----
  #define DISABLE_FD_PASSING 1
  _ACEOF

+   cat >>confdefs.h <<\_ACEOF
+ #define WITH_ABBREV_NO_TTY 1
+ _ACEOF
+

  for ac_func in getluid setluid
--8<-- cut here --8<--

-- 
Roger Cornelius        rac at tenzing.org



From GamlielU at exchange.nih.gov  Sat Sep  6 03:13:10 2003
From: GamlielU at exchange.nih.gov (Gamliel, Udi (NIH/CIT))
Date: Fri, 5 Sep 2003 13:13:10 -0400 
Subject: how to compile ssh with pam
Message-ID: <64BC9A2B18FC5843BA0DE93548F745F31E560403@nihexchange3.nih.gov>




Hello

I am compiled openssh3.6.1p2 with PAM and using RSA Security (ACE) token.

the command I used to compile ssh as follow:

1. ./configure --with-pam

2. make

3. make install

After starting  the sshd daemon, I  authenticate using the command

"ssh xxx.yyy.nih.gov"

On the SecurID server I was watching the log monitor and I saw the following
errors :

"ACCESS DENIED, syntax error" before I get the prompt for Passcode

and when I put my passcode, it let me login. Doing that for several time

SecurID puts me in the "next token code" and then disable my token.

I called RSA security and we found out that the problem was in the openssh.

when RSA sent me a compiled openssh that can be found on the internet, then

everything worked just fine with no errors.

The fact is that we can not depend on finding a compiled openssh with PAM on
the

internet, so I compiled my own version with Pam

but Of course I am sure I am missing some compilation switches and options.

SO my question to you is :

How do I compile an openssh that works with PAM on Unix or Linux.

Than you very much

Udi Gamliel

301-435-1968





Udi Gamliel

DNST/EOS

Tel - 301-435-1968

10401 Fernwood 20814





From mouring at etoh.eviladmin.org  Sat Sep  6 04:37:04 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 5 Sep 2003 13:37:04 -0500 (CDT)
Subject: how to compile ssh with pam
In-Reply-To: <64BC9A2B18FC5843BA0DE93548F745F31E560403@nihexchange3.nih.gov>
Message-ID: <Pine.BSO.4.44.0309051336230.18966-100000@etoh.eviladmin.org>


./configure --with-pam

is all you need to do to compile in PAM support.. you may need a
/etc/pam.conf file depending on your platform.  look on contrib/ directory
for examples.

- Ben

On Fri, 5 Sep 2003, Gamliel, Udi (NIH/CIT) wrote:

>
>
>
> Hello
>
> I am compiled openssh3.6.1p2 with PAM and using RSA Security (ACE) token.
>
> the command I used to compile ssh as follow:
>
> 1. ./configure --with-pam
>
> 2. make
>
> 3. make install
>
> After starting  the sshd daemon, I  authenticate using the command
>
> "ssh xxx.yyy.nih.gov"
>
> On the SecurID server I was watching the log monitor and I saw the following
> errors :
>
> "ACCESS DENIED, syntax error" before I get the prompt for Passcode
>
> and when I put my passcode, it let me login. Doing that for several time
>
> SecurID puts me in the "next token code" and then disable my token.
>
> I called RSA security and we found out that the problem was in the openssh.
>
> when RSA sent me a compiled openssh that can be found on the internet, then
>
> everything worked just fine with no errors.
>
> The fact is that we can not depend on finding a compiled openssh with PAM on
> the
>
> internet, so I compiled my own version with Pam
>
> but Of course I am sure I am missing some compilation switches and options.
>
> SO my question to you is :
>
> How do I compile an openssh that works with PAM on Unix or Linux.
>
> Than you very much
>
> Udi Gamliel
>
> 301-435-1968
>
>
>
>
>
> Udi Gamliel
>
> DNST/EOS
>
> Tel - 301-435-1968
>
> 10401 Fernwood 20814
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dtucker at zip.com.au  Sat Sep  6 11:42:45 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 06 Sep 2003 11:42:45 +1000
Subject: 3.6p1 bug on SCO OpenServer
References: <200309051650.h85Gol726140@tenzing.org>
Message-ID: <3F593B95.19129498@zip.com.au>

Roger Cornelius wrote:
> loginrec.c writes incorrect data into the ut_id field of the utmp file.
> This has been an issue since at least openssh 3.0.2 but I never bothered
> to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
> the problem.

[snip]

> Here's the patch:
> 
> --8<-- cut here --8<--
> *** configure.orig  2003-03-26 00:12:34.000000000 -0500
> --- configure   2003-07-18 17:26:00.000000000 -0400

"configure" is a machine-generated file, you should edit configure.ac and
run "autoreconf" to rebuild it.

Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?

Tim, any issue with doing this?

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



From tim at multitalents.net  Sat Sep  6 14:49:39 2003
From: tim at multitalents.net (Tim Rice)
Date: Fri, 5 Sep 2003 21:49:39 -0700 (PDT)
Subject: 3.6p1 bug on SCO OpenServer
In-Reply-To: <3F593B95.19129498@zip.com.au>
References: <200309051650.h85Gol726140@tenzing.org>
	<3F593B95.19129498@zip.com.au>
Message-ID: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>

On Sat, 6 Sep 2003, Darren Tucker wrote:

> Roger Cornelius wrote:
> > loginrec.c writes incorrect data into the ut_id field of the utmp file.
> > This has been an issue since at least openssh 3.0.2 but I never bothered
> > to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
> > the problem.
> 
> [snip]
> Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?

My 3.2v4.2 box is dead. Can someone check the last(C) output here?

> 
> Tim, any issue with doing this?
 
I've verified the complaint. As soon as I can get "current" to build [1]
on OpenServer I'll test the fix.
 
1. ssh-keygen.c uses PATH_MAX now.
No source file used PATH_MAX in openssh-3.6.1

More to do this weekend. ;-)

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



From mouring at etoh.eviladmin.org  Sat Sep  6 15:47:14 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 6 Sep 2003 00:47:14 -0500 (CDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
Message-ID: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>


On this note I think it would be best to opening the floor for testing of
the current CVS tree.  OpenSSH is in a feature lock and we should be in
in sync with the OpenBSD tree (there may be stray patches, but hopefully
nothing major).

So please if we can get people to start doing tests on their platform is
would help.

The major things that have changed is PAM and Kerb/GSS support.  However,
we did do a clean up of openbsd-compat/ code so I may have broken
platforms I don't own by playing in there.  I also redid how we handle
signal (signal() vs a stricter mysignal() version).  So that is something
to watch out for (basicly made it consistant).

There are a bunch more changes, but I don't have a copy of the proposed
release notes sitting in front of me.

BTW, regression testing should hopefully work for most platforms.  Please
get in the habbit of using this.  It should give us a better handle on
platform breakage.  Darren was nice enough to get that rolling recently.

It should be as simple as ./configure [needed options] && make && make
tests, but I've not had a chance to confirm it with an actually test on my
Solaris test box.

Sooooo... If you wish your platform to work then drop by
http://www.openssh.com/portable.html, pick your favorate ftp server
or grab the the source from the CVS tree.

Thanks,

- Ben && The OpenSSH Portable Team


On Fri, 5 Sep 2003, Tim Rice wrote:

> On Sat, 6 Sep 2003, Darren Tucker wrote:
>
> > Roger Cornelius wrote:
> > > loginrec.c writes incorrect data into the ut_id field of the utmp file.
> > > This has been an issue since at least openssh 3.0.2 but I never bothered
> > > to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
> > > the problem.
> >
> > [snip]
> > Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?
>
> My 3.2v4.2 box is dead. Can someone check the last(C) output here?
>
> >
> > Tim, any issue with doing this?
>
> I've verified the complaint. As soon as I can get "current" to build [1]
> on OpenServer I'll test the fix.
>
> 1. ssh-keygen.c uses PATH_MAX now.
> No source file used PATH_MAX in openssh-3.6.1
>
> More to do this weekend. ;-)
>
> --
> Tim Rice				Multitalents	(707) 887-1469
> tim at multitalents.net
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From vinschen at redhat.com  Sat Sep  6 19:19:05 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sat, 6 Sep 2003 11:19:05 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <20030906091905.GQ1859@cygbert.vinschen.de>

On Sat, Sep 06, 2003 at 12:47:14AM -0500, Ben Lindstrom wrote:
> BTW, regression testing should hopefully work for most platforms.  Please
> get in the habbit of using this.  It should give us a better handle on
> platform breakage.  Darren was nice enough to get that rolling recently.
> 
> It should be as simple as ./configure [needed options] && make && make
> tests, but I've not had a chance to confirm it with an actually test on my
> Solaris test box.
> 
> Sooooo... If you wish your platform to work then drop by
> http://www.openssh.com/portable.html, pick your favorate ftp server
> or grab the the source from the CVS tree.

OpenSSH has been configured with the following options:
                     User binaries: /usr/bin
                   System binaries: /usr/sbin
               Configuration files: /etc
                   Askpass program: ${prefix}/sbin/ssh-askpass
                      Manual pages: /usr/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin
                    Manpage format: doc
                       PAM support: no
                KerberosIV support: no
                 KerberosV support: no
                 Smartcard support: no
                       AFS support: no
                     S/KEY support: no
              TCP Wrappers support: yes
              MD5 password support: no
       IP address in $DISPLAY hack: no
          Use IPv4 by default hack: no
           Translate v4 in v6 hack: no
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: i686-pc-cygwin
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags: 
      Linker flags: 
         Libraries: -lwrap  -lz  /usr/lib/textmode.o -lcrypto -lcrypt  

Builds and runs OOTB.  All regression tests pass, except for the sftp
test trying to manipulate a file with quotation marks.  These characters
aren't allowed in Windows filenames.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From gert at greenie.muc.de  Sat Sep  6 20:51:00 2003
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 6 Sep 2003 12:51:00 +0200
Subject: 3.6p1 bug on SCO OpenServer
In-Reply-To: <3F593B95.19129498@zip.com.au>;
	from dtucker@zip.com.au on Sat, Sep 06, 2003 at 11:42:45AM +1000
References: <200309051650.h85Gol726140@tenzing.org>
	<3F593B95.19129498@zip.com.au>
Message-ID: <20030906125059.G594@greenie.muc.de>

Hi,

On Sat, Sep 06, 2003 at 11:42:45AM +1000, Darren Tucker wrote:
> Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?

OpenServer 5 is "*sco3.2v5*".

On *sco3.2v4*, it's debatable what's "right" - I'd say "it doesn't matter"
(as long as login and logout records use the same ut_id).  

The ut_id isn't used for anything special anyway (except internally between
init/getty/login).

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 at net.informatik.tu-muenchen.de



From gert at greenie.muc.de  Sat Sep  6 20:52:26 2003
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 6 Sep 2003 12:52:26 +0200
Subject: 3.6p1 bug on SCO OpenServer
In-Reply-To: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>;
	from tim@multitalents.net on Fri, Sep 05, 2003 at 09:49:39PM -0700
References: <200309051650.h85Gol726140@tenzing.org>
	<3F593B95.19129498@zip.com.au>
	<Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
Message-ID: <20030906125226.H594@greenie.muc.de>

Hi,

On Fri, Sep 05, 2003 at 09:49:39PM -0700, Tim Rice wrote:
> > Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?
> My 3.2v4.2 box is dead. Can someone check the last(C) output here?

User     Line  Device       PID    Login time       Elapsed Time Comments
Ueisa    g1    tty5d        14971  Sat Sep  6 05:12      00:00
Ueisa    g1    tty5d        23768  Fri Sep  5 05:12      00:00
peterb   typ9  ttyp9        13687  Thu Sep  4 10:13      13:17
Ueisa    g1    tty5d        9838   Thu Sep  4 05:12      00:00
fax_inc  g1    tty5d        2544   Thu Sep  4 01:46      00:00
gert     typ9  ttyp9        24569  Wed Sep  3 17:22      00:00
fax_inc  F8    tty5b        516    Wed Sep  3 08:49      00:00

so regular "init/getty/login" sessions get what's in inittab's first field:

g1:23:respawn:/usr/local/sbin/mgetty.test -n 2 tty5d 
F8:23:respawn:/usr/local/sbin/mgetty tty5b

so it obviously doesn't need to have any relation to the device name...

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 at net.informatik.tu-muenchen.de



From gem at rellim.com  Sun Sep  7 04:49:25 2003
From: gem at rellim.com (Gary E. Miller)
Date: Sat, 6 Sep 2003 11:49:25 -0700 (PDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.56.0309061127410.2930@catbert.rellim.com>

Yo Ben!

Looks almost ready to go.

Small problem here with: openssh-SNAP-20030905.tar.gz

I have a bastard slackware 8.0 laptop with lot's of updates.  Now running
gcc 3.3, glibc 2.3.3 and openssl 0.9.6g

Here is the configure command:

./configure --with-default-path=$PATH --with-md5-passwords \
  --with-mantype=man --with-tcp-wrappers \
  --with-ssl-dir=/usr/local/ssl/lib --with-dns


Here is the config result:

OpenSSH has been configured with the following options:
                     User binaries: /usr/local/bin
                   System binaries: /usr/local/sbin
               Configuration files: /usr/local/etc
                   Askpass program: /usr/local/libexec/ssh-askpass
                      Manual pages: /usr/local/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/local/qt/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/schily/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/enlightenment/bin:/usr/X11R6/bin:/usr/local/samba/bin:/usr/X11R6/bin:/usr/games:.:/opt/gnome/bin:/opt/www/htdig/bin:/opt/kde/bin:/usr/local/java/bin:/usr/share/texmf/bin:/usr/openwin/bin
                    Manpage format: man
                       DNS support: yes
                       PAM support: no
                 KerberosV support: no
                 Smartcard support: no
                     S/KEY support: no
              TCP Wrappers support: yes
              MD5 password support: yes
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: i686-pc-linux-gnu
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags: -I/usr/local/ssl/lib
      Linker flags: -L/usr/local/ssl/lib
         Libraries: -lwrap  -lresolv -lutil -lz -lnsl  -lcrypto -lcrypt


Here is the error:

gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/usr/local/ssl/lib  -DHAVE_CONFIG_H -c xcrypt.c
xcrypt.c:68:3: invalid preprocessing directive #elsif
xcrypt.c: In function `xcrypt':
xcrypt.c:69: warning: implicit declaration of function `iscomsec'
xcrypt.c:70: warning: implicit declaration of function `bigcrypt'
xcrypt.c:70: warning: assignment makes pointer from integer without a cast
xcrypt.c:73:3: invalid preprocessing directive #elsif
xcrypt.c:74: warning: assignment makes pointer from integer without a cast
make[1]: *** [xcrypt.o] Error 1
make[1]: Leaving directory `/usr/local/src/openssh/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

Changing the #elsif to #elif on lines 68 and 73 allows the SNAP to build.

make tests passes fine, except for one thing I did not dig out:

run test dynamic-forward.sh ...
/usr/local/src/openssh/regress/test-exec.sh: [: too many arguments
/usr/local/src/openssh/regress/test-exec.sh: [: too many arguments
skipped (no suitable ProxyCommand found)


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Sat, 6 Sep 2003, Ben Lindstrom wrote:

> Date: Sat, 6 Sep 2003 00:47:14 -0500 (CDT)
> From: Ben Lindstrom <mouring at etoh.eviladmin.org>
> To: OpenSSH Development <openssh-unix-dev at mindrot.org>
> Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
>
>
> On this note I think it would be best to opening the floor for testing of
> the current CVS tree.  OpenSSH is in a feature lock and we should be in
> in sync with the OpenBSD tree (there may be stray patches, but hopefully
> nothing major).
>
> So please if we can get people to start doing tests on their platform is
> would help.
>
> The major things that have changed is PAM and Kerb/GSS support.  However,
> we did do a clean up of openbsd-compat/ code so I may have broken
> platforms I don't own by playing in there.  I also redid how we handle
> signal (signal() vs a stricter mysignal() version).  So that is something
> to watch out for (basicly made it consistant).
>
> There are a bunch more changes, but I don't have a copy of the proposed
> release notes sitting in front of me.
>
> BTW, regression testing should hopefully work for most platforms.  Please
> get in the habbit of using this.  It should give us a better handle on
> platform breakage.  Darren was nice enough to get that rolling recently.
>
> It should be as simple as ./configure [needed options] && make && make
> tests, but I've not had a chance to confirm it with an actually test on my
> Solaris test box.
>
> Sooooo... If you wish your platform to work then drop by
> http://www.openssh.com/portable.html, pick your favorate ftp server
> or grab the the source from the CVS tree.
>
> Thanks,
>
> - Ben && The OpenSSH Portable Team
>
>
> On Fri, 5 Sep 2003, Tim Rice wrote:
>
> > On Sat, 6 Sep 2003, Darren Tucker wrote:
> >
> > > Roger Cornelius wrote:
> > > > loginrec.c writes incorrect data into the ut_id field of the utmp file.
> > > > This has been an issue since at least openssh 3.0.2 but I never bothered
> > > > to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
> > > > the problem.
> > >
> > > [snip]
> > > Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?
> >
> > My 3.2v4.2 box is dead. Can someone check the last(C) output here?
> >
> > >
> > > Tim, any issue with doing this?
> >
> > I've verified the complaint. As soon as I can get "current" to build [1]
> > on OpenServer I'll test the fix.
> >
> > 1. ssh-keygen.c uses PATH_MAX now.
> > No source file used PATH_MAX in openssh-3.6.1
> >
> > More to do this weekend. ;-)
> >
> > --
> > Tim Rice				Multitalents	(707) 887-1469
> > tim at multitalents.net
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From alfred.hovdestad at usask.ca  Sun Sep  7 07:13:57 2003
From: alfred.hovdestad at usask.ca (Alfred Hovdestad)
Date: Sat, 06 Sep 2003 15:13:57 -0600
Subject: ssh_exchange_identification: Connection closed by remote host
In-Reply-To: <3F3899F8.9F88E86D@zip.com.au>
References: <3F37E04A.7050004@usask.ca> <3F3899F8.9F88E86D@zip.com.au>
Message-ID: <3F5A4E15.6090906@usask.ca>

This has taken far too long to get to you, and I apologize for that.

There are four attachments included:

client.working
client.notworking
server.working
server.notworking

I am running RedHat 9.0 on both systems with all of the latest patches 
from RedHat.  The current rpm for openssh is openssh-3.5p1-6.9.  I have 
PAM configured to use kerberos for password authentication.  The only 
difference in the two scenarios is the Kerberos server.  We have a two 
kerberos servers, one a Windows Domain Controller and the other a Sun.

If I use the Windows DC for Kerberos authentication, I can login at the 
console, I can generate a kerberos ticket (kinit), but I cannot login 
with ssh.

If I use the Sun for kerberos authentication, I can login at the 
console, I can generate a kerberos ticket (kinit), and I can login with ssh.

If I downgrade to the previous rpm from RedHat (openssh-3.5p1-6), I can 
login with ssh to the server.  If it would help, I can also generate the 
log file for the previous version.

If you require more information, please let me know.

     Alfred Hovdestad
     System Administrator
     University of Saskatchewan
     RHCE: 807200142604340


Darren Tucker wrote:
> Alfred Hovdestad wrote:
> 
>>I am running RedHat 9.0 with openssh 3.5.  I have tried connecting from
>>a RedHat 8.0 box running openshh 3.4 and a tru64 box also with openssh
>>3.4, with the same results:  I can login to the new account, but not to
>>my existing account.
> 
> 
> Perhaps your password are expiring?
> 
> 
>>The problem is not with tcp wrappers, as I can login to one account, but
>>not another.  I have tried deleting my ssh keys, my host keys, and
>>rebooting my system, none of which has made any difference.
>>
>>Is there anything else I can check?  I can send any log information that
>>you need.
> 
> 
> Yes, you need to post the *server* side debugging, ie:
> 
> /path/to/sshd -ddd -p 2022
> 
> then in another window:
> 
> ssh -p 2022 servername
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: client.working
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030906/eb0498fc/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: client.notworking
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030906/eb0498fc/attachment-0001.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: server.working
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030906/eb0498fc/attachment-0002.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: server.notworking
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030906/eb0498fc/attachment-0003.ksh 

From djm at mindrot.org  Sun Sep  7 09:32:15 2003
From: djm at mindrot.org (Damien Miller)
Date: Sat, 06 Sep 2003 23:32:15 -0000
Subject: authorized_keys options for remote forwarding
In-Reply-To: <3F58BA04.3080901@doxpara.com>
References: <20030829120602.GG11415@iwoars.net>
	<20030905111946.GA17851@foo.birdnet.se> <3F58BA04.3080901@doxpara.com>
Message-ID: <1062890963.9867.6.camel@sakura.mindrot.org>

On Sat, 2003-09-06 at 02:29, Dan Kaminsky wrote:
> >
> >
> >command="/usr/bin/cat",no-X11-forwarding,no-agent-forwarding,\
> >permitopen="ip1:port1",permitopen="ip2:port2" ssh-rsa AAAA...
> >  
> >
> Doesn't this allow any file on the system to be read, or written to for 
> that matter?

No, arguments are not passed to forced commands. Once could also use
/bin/true and connect with "ssh -N -Lxxx".

-d




From dtucker at zip.com.au  Sun Sep  7 09:44:32 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 07 Sep 2003 09:44:32 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<20030906091905.GQ1859@cygbert.vinschen.de>
Message-ID: <3F5A7160.4B76C2B3@zip.com.au>

Corinna Vinschen wrote:
> On Sat, Sep 06, 2003 at 12:47:14AM -0500, Ben Lindstrom wrote:
[regression tests]
> > It should be as simple as ./configure [needed options] && make && make

Actually, the middle "make" is optional :-)

Note that some platforms sshd requires root privileges to work, on such
platforms you will need "sudo" installed, and run the tests like so:

$ SUDO=sudo make tests

Platforms using PAM typically fall into this category, but there may be
others.

[current snapshot]
> Builds and runs OOTB.  All regression tests pass, except for the sftp
> test trying to manipulate a file with quotation marks.  These characters
> aren't allowed in Windows filenames.

Excellent.

I have arranged for that test to be skipped on Cygwin in future.  I also
fixed a couple of other minor regression test issues on Cygwin, and now
the entire suite passes.

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



From dtucker at zip.com.au  Sun Sep  7 09:53:06 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 07 Sep 2003 09:53:06 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<Pine.LNX.4.56.0309061127410.2930@catbert.rellim.com>
Message-ID: <3F5A7362.1BEAEB85@zip.com.au>

"Gary E. Miller" wrote:
[snip]
> gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/usr/local/ssl/lib  -DHAVE_CONFIG_H -c xcrypt.c
> xcrypt.c:68:3: invalid preprocessing directive #elsif
[snip]
> Changing the #elsif to #elif on lines 68 and 73 allows the SNAP to build.

> make tests passes fine, except for one thing I did not dig out:
> 
> run test dynamic-forward.sh ...
> /usr/local/src/openssh/regress/test-exec.sh: [: too many arguments
> /usr/local/src/openssh/regress/test-exec.sh: [: too many arguments
> skipped (no suitable ProxyCommand found)

Thanks for that, both of those have been fixed.  You can try the attached
patch, or wait for tomorrow's snapshot.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: ChangeLog
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ChangeLog,v
retrieving revision 1.2962
retrieving revision 1.2967
diff -u -p -r1.2962 -r1.2967
--- ChangeLog	6 Sep 2003 06:44:39 -0000	1.2962
+++ ChangeLog	6 Sep 2003 23:43:42 -0000	1.2967
@@ -1,3 +1,13 @@
+20030907
+ - (dtucker) [agent-ptrace.sh dynamic-forward.sh (all regress/)]
+   Put "which" inside quotes.
+ - (dtucker) [dynamic-forward.sh forwarding.sh sftp-batch.sh (all regress/)]
+   Add ${EXEEXT}: required to work on Cygwin.
+ - (dtucker) [regress/sftp-batch.sh] Make temporary batch file name more
+   distinctive, so "rm ${BATCH}.*" doesn't match the script itself.
+ - (dtucker) [regress/sftp-cmds.sh] Skip quoted file test on Cygwin.
+ - (dtucker) openbsd-compat/xcrypt.c] #elsif -> #elif
+
 20030906
  - (dtucker) [acconfig.h configure.ac uidswap.c] Prefer setuid/setgid on AIX.
 
@@ -24,7 +34,7 @@
    - [regress/agent-ptrace.sh regress/agent-timeout.sh]
      "grep -q" -> "grep >/dev/null"
    - [regress/agent.sh regress/proto-version.sh regress/ssh-com.sh
-     regress/test-exec.sh] Handle different was of echoing without newlines.
+     regress/test-exec.sh] Handle different ways of echoing without newlines.
    - [regress/dynamic-forward.sh] Some "which" programs output on stderr.
    - [regress/sftp-cmds.sh] Use portable "test" option.
    - [regress/test-exec.sh] Use sudo, search for "whoami" equivalent, always
@@ -1024,4 +1034,4 @@
  - Fix sshd BindAddress and -b options for systems using fake-getaddrinfo.
    Report from murple at murple.net, diagnosis from dtucker at zip.com.au
 
-$Id: ChangeLog,v 1.2962 2003/09/06 06:44:39 dtucker Exp $
+$Id: ChangeLog,v 1.2967 2003/09/06 23:43:42 dtucker Exp $
Index: openbsd-compat/xcrypt.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/xcrypt.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- openbsd-compat/xcrypt.c	11 Aug 2003 13:00:34 -0000	1.3
+++ openbsd-compat/xcrypt.c	6 Sep 2003 23:43:42 -0000	1.4
@@ -65,12 +65,12 @@ xcrypt(const char *password, const char 
                 crypted = md5_crypt(password, salt);
         else
                 crypted = crypt(password, salt);
-# elsif defined(__hpux) && !defined(HAVE_SECUREWARE)
+# elif defined(__hpux) && !defined(HAVE_SECUREWARE)
 	if (iscomsec())
                 crypted = bigcrypt(password, salt);
         else
                 crypted = crypt(password, salt);
-# elsif defined(HAVE_SECUREWARE)
+# elif defined(HAVE_SECUREWARE)
         crypted = bigcrypt(password, salt);
 # else
         crypted = crypt(password, salt);
@@ -99,12 +99,12 @@ shadow_pw(struct passwd *pw)
 	struct passwd_adjunct *spw;
 	if (issecure() && (spw = getpwanam(pw->pw_name)) != NULL)
 		pw_password = spw->pwa_passwd;
-# elsif defined(HAVE_SECUREWARE)
+# elif defined(HAVE_SECUREWARE)
 	struct pr_passwd *spw = getprpwnam(pw->pw_name);
 
 	if (spw != NULL)
 		pw_password = spw->ufld.fd_encrypt;
-# elsif defined(__hpux) && !defined(HAVE_SECUREWARE)
+# elif defined(__hpux) && !defined(HAVE_SECUREWARE)
 	struct pr_passwd *spw;
         if (iscomsec() && (spw = getprpwnam(pw->pw_name)) != NULL)
                 pw_password = spw->ufld.fd_encrypt;
Index: regress/agent-ptrace.sh
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/agent-ptrace.sh,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- regress/agent-ptrace.sh	4 Sep 2003 12:06:16 -0000	1.4
+++ regress/agent-ptrace.sh	6 Sep 2003 23:22:22 -0000	1.5
@@ -3,7 +3,7 @@
 
 tid="disallow agent ptrace attach"
 
-if [ -x `which uname 2>&1` ]; then
+if [ -x "`which uname 2>&1`" ]; then
 	case `uname` in
 	Linux|HP-UX|SunOS|NetBSD|AIX|CYGWIN*)
 		echo "skipped (not supported on this platform)"
@@ -12,7 +12,7 @@ if [ -x `which uname 2>&1` ]; then
 	esac
 fi
 
-if [ ! -x `which gdb 2>&1` ]; then
+if [ ! -x "`which gdb 2>&1`" ]; then
 	echo "skipped (gdb not found)"
 	exit 0
 fi
Index: regress/dynamic-forward.sh
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/dynamic-forward.sh,v
retrieving revision 1.3
retrieving revision 1.5
diff -u -p -r1.3 -r1.5
--- regress/dynamic-forward.sh	4 Sep 2003 05:22:01 -0000	1.3
+++ regress/dynamic-forward.sh	6 Sep 2003 23:28:04 -0000	1.5
@@ -5,10 +5,11 @@ tid="dynamic forwarding"
 
 PORT=4242
 FWDPORT=4243
+DATA=/bin/ls${EXEEXT}
 
-if [ -x `which nc 2>&1` ] && nc -h 2>&1 | grep "x proxy address" >/dev/null; then
+if [ -x "`which nc 2>&1`" ] && nc -h 2>&1 | grep "x proxy address" >/dev/null; then
 	proxycmd="nc -x 127.0.0.1:$FWDPORT -X"
-elif [ -x `which connect 2>&1` ]; then
+elif [ -x "`which connect 2>&1`" ]; then
 	proxycmd="connect -S 127.0.0.1:$FWDPORT -"
 else
 	echo "skipped (no suitable ProxyCommand found)"
@@ -28,9 +29,9 @@ for p in 1 2; do
 		trace "testing ssh protocol $p socks version $s host $h"
 		${SSH} -F $OBJ/ssh_config \
 			-o "ProxyCommand ${proxycmd}${s} $h $PORT" \
-			somehost cat /bin/ls > $OBJ/ls.copy
-		test -f $OBJ/ls.copy	 || fail "failed copy /bin/ls"
-		cmp /bin/ls $OBJ/ls.copy || fail "corrupted copy of /bin/ls"
+			somehost cat $DATA > $OBJ/ls.copy
+		test -f $OBJ/ls.copy	 || fail "failed copy $DATA"
+		cmp $DATA $OBJ/ls.copy || fail "corrupted copy of $DATA"
 	    done
 	done
 
Index: regress/forwarding.sh
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/forwarding.sh,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- regress/forwarding.sh	1 May 2002 03:17:34 -0000	1.1
+++ regress/forwarding.sh	6 Sep 2003 23:28:04 -0000	1.2
@@ -2,6 +2,7 @@
 #	Placed in the Public Domain.
 
 tid="local and remote forwarding"
+DATA=/bin/ls${EXEEXT}
 
 start_sshd
 
@@ -25,9 +26,9 @@ for p in 1 2; do
 
 	trace "transfer over forwarded channels and check result"
 	${SSH} -$q -F $OBJ/ssh_config -p$last -o 'ConnectionAttempts=4' \
-		somehost cat /bin/ls > $OBJ/ls.copy
-	test -f $OBJ/ls.copy			|| fail "failed copy /bin/ls"
-	cmp /bin/ls $OBJ/ls.copy		|| fail "corrupted copy of /bin/ls"
+		somehost cat $DATA > $OBJ/ls.copy
+	test -f $OBJ/ls.copy			|| fail "failed copy $DATA"
+	cmp $DATA $OBJ/ls.copy			|| fail "corrupted copy of $DATA"
 
 	sleep 10
 done
Index: regress/sftp-batch.sh
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/sftp-batch.sh,v
retrieving revision 1.1
retrieving revision 1.3
diff -u -p -r1.1 -r1.3
--- regress/sftp-batch.sh	22 Jan 2003 06:53:17 -0000	1.1
+++ regress/sftp-batch.sh	6 Sep 2003 23:31:02 -0000	1.3
@@ -3,9 +3,9 @@
 
 tid="sftp batchfile"
 
-DATA=/bin/ls
+DATA=/bin/ls${EXEEXT}
 COPY=${OBJ}/copy
-BATCH=${OBJ}/sftp-batch
+BATCH=${OBJ}/sftp-batch.tmp
 
 rm -rf ${COPY} ${COPY}.1 ${COPY}.2 ${COPY}.dd ${BATCH}.*
 
Index: regress/sftp-cmds.sh
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/sftp-cmds.sh,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- regress/sftp-cmds.sh	4 Sep 2003 05:24:50 -0000	1.7
+++ regress/sftp-cmds.sh	6 Sep 2003 23:32:59 -0000	1.8
@@ -17,6 +17,20 @@ do
 	fi
 done
 
+if [ -x "`which uname 2>&1`" ]
+then
+	case `uname` in
+	CYGWIN*)
+		os=cygwin
+		;;
+	*)
+		os=`uname`
+		;;
+	esac
+else
+	os="unknown"
+fi
+
 # Path with embedded quote
 QUOTECOPY=${COPY}".\"blah\""
 QUOTECOPY_ARG=${COPY}'.\"blah\"'
@@ -99,11 +113,13 @@ echo "put $DATA $COPY" | ${SFTP} -P ${SF
 	|| fail "put failed"
 cmp $DATA ${COPY} || fail "corrupted copy after put"
 
+if [ "$os" != "cygwin" ]; then
 rm -f ${QUOTECOPY}
 verbose "$tid: put filename with quotes"
 echo "put $DATA \"$QUOTECOPY_ARG\"" | ${SFTP} -P ${SFTPSERVER} >/dev/null 2>&1 \
 	|| fail "put failed"
 cmp $DATA ${QUOTECOPY} || fail "corrupted copy after put with quotes"
+fi
 
 rm -f ${COPY}.dd/*
 verbose "$tid: put to directory"

From dtucker at zip.com.au  Sun Sep  7 10:28:07 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 07 Sep 2003 10:28:07 +1000
Subject: ssh_exchange_identification: Connection closed by remote host
References: <3F37E04A.7050004@usask.ca> <3F3899F8.9F88E86D@zip.com.au>
	<3F5A4E15.6090906@usask.ca>
Message-ID: <3F5A7B97.1687766E@zip.com.au>

Alfred Hovdestad wrote:
[snip]
> I am running RedHat 9.0 on both systems with all of the latest patches
> from RedHat.  The current rpm for openssh is openssh-3.5p1-6.9.  I have
> PAM configured to use kerberos for password authentication.  The only
> difference in the two scenarios is the Kerberos server.  We have a two
> kerberos servers, one a Windows Domain Controller and the other a Sun.
> 
> If I use the Windows DC for Kerberos authentication, I can login at the
> console, I can generate a kerberos ticket (kinit), but I cannot login
> with ssh.
> 
> If I use the Sun for kerberos authentication, I can login at the
> console, I can generate a kerberos ticket (kinit), and I can login with ssh.
> 
> If I downgrade to the previous rpm from RedHat (openssh-3.5p1-6), I can
> login with ssh to the server.  If it would help, I can also generate the
> log file for the previous version.

It sounds like you need to ask Redhat about this one.  Both packages use
the same base OpenSSH version with (presumably) different patches.

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



From mcIntoshfq at discountsweb.com  Mon Sep  8 20:08:11 2003
From: mcIntoshfq at discountsweb.com (Hilario N. McIntosh)
Date: Mon, 08 Sep 2003 10:08:11 +0000
Subject: order your drugs today
Message-ID: <2b7c01c375f1$395d753a$0f06f5a8@981tqf2>






From dtucker at zip.com.au  Mon Sep  8 16:59:02 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 08 Sep 2003 16:59:02 +1000
Subject: Variable declarations in xcrypt.c
Message-ID: <3F5C28B6.7FC2463C@zip.com.au>

Hi All.
	I noticed that xcrypt.c now has some variable declarations after code
within a block (for some sets of #ifdef's).  Won't that choke some
compilers?  Should it do something like the attached?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: openbsd-compat/xcrypt.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/xcrypt.c,v
retrieving revision 1.4
diff -u -p -r1.4 xcrypt.c
--- openbsd-compat/xcrypt.c	6 Sep 2003 23:43:42 -0000	1.4
+++ openbsd-compat/xcrypt.c	8 Sep 2003 06:52:26 -0000
@@ -96,18 +96,25 @@ shadow_pw(struct passwd *pw)
 		pw_password = spw->sp_pwdp;
 # endif
 # if defined(HAVE_GETPWANAM) && !defined(DISABLE_SHADOW)
-	struct passwd_adjunct *spw;
-	if (issecure() && (spw = getpwanam(pw->pw_name)) != NULL)
-		pw_password = spw->pwa_passwd;
+	if (issecure()) {
+		struct passwd_adjunct *spw;
+
+		if (spw = getpwanam(pw->pw_name) != NULL)
+			pw_password = spw->pwa_passwd;
+	}
 # elif defined(HAVE_SECUREWARE)
-	struct pr_passwd *spw = getprpwnam(pw->pw_name);
+	if (spw != NULL) {
+		struct pr_passwd *spw = getprpwnam(pw->pw_name);
 
-	if (spw != NULL)
 		pw_password = spw->ufld.fd_encrypt;
+	}
 # elif defined(__hpux) && !defined(HAVE_SECUREWARE)
-	struct pr_passwd *spw;
-        if (iscomsec() && (spw = getprpwnam(pw->pw_name)) != NULL)
-                pw_password = spw->ufld.fd_encrypt;
+        if (iscomsec()) {
+		struct pr_passwd *spw;
+
+		if (spw = getprpwnam(pw->pw_name) != NULL)
+                	pw_password = spw->ufld.fd_encrypt;
+	}
 # endif
 
 	return pw_password;

From openssh at roumenpetrov.info  Mon Sep  8 17:57:05 2003
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Mon, 08 Sep 2003 10:57:05 +0300
Subject: Variable declarations in xcrypt.c
References: <3F5C28B6.7FC2463C@zip.com.au>
Message-ID: <3F5C3651.8000508@roumenpetrov.info>

Darren Tucker wrote:

>Hi All.
>	I noticed that xcrypt.c now has some variable declarations after code
>within a block (for some sets of #ifdef's).  Won't that choke some
>compilers?  Should it do something like the attached?
>  
>
This should work on all compilers.

Only aCC (HP) compiler fail on variable declaration with same name in blocks inside switch statement, i.e.
switch (...) {
  ...
  case ... 
    {
       int var;
       ...
    }
  ...
  case ... 
    {
       int var; /* FAIL ON HP. work arround - to rename variable */
       ...
    }
  ...
}





From rac at tenzing.org  Mon Sep  8 23:48:51 2003
From: rac at tenzing.org (Roger Cornelius)
Date: Mon, 8 Sep 2003 09:48:51 -0400
Subject: 3.6p1 bug on SCO OpenServer
In-Reply-To: <3F593B95.19129498@zip.com.au>
Message-ID: <200309081348.h88DmpI06516@tenzing.org>

Darren Tucker (dtucker at zip.com.au) wrote:

>Roger Cornelius wrote:
>> loginrec.c writes incorrect data into the ut_id field of the utmp file.
>> This has been an issue since at least openssh 3.0.2 but I never bothered
>> to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
>> the problem.
>
>[snip]
>
>> Here's the patch:
>> 
>> --8<-- cut here --8<--
>> *** configure.orig  2003-03-26 00:12:34.000000000 -0500
>> --- configure   2003-07-18 17:26:00.000000000 -0400
>
>"configure" is a machine-generated file, you should edit configure.ac and
>run "autoreconf" to rebuild it.
>
>Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?
>
>Tim, any issue with doing this?

I know that configure is auto-generated somehow but am unfamiliar with
the process.  The patch I supplied was just an example - I was hoping
the powers that be would do whatever is necessary to incorporate it into
the build process.

I was referring specifically to sco3.2v5*.  My best guess would be that
this should be applied to 3.2v4* as well, but I don't have a system to
test on.

-- 
Roger Cornelius        rac at tenzing.org



From mouring at etoh.eviladmin.org  Tue Sep  9 00:55:34 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 8 Sep 2003 09:55:34 -0500 (CDT)
Subject: Variable declarations in xcrypt.c
In-Reply-To: <3F5C28B6.7FC2463C@zip.com.au>
Message-ID: <Pine.BSO.4.44.0309080953500.29487-100000@etoh.eviladmin.org>



On Mon, 8 Sep 2003, Darren Tucker wrote:

> Hi All.
> 	I noticed that xcrypt.c now has some variable declarations after code
> within a block (for some sets of #ifdef's).  Won't that choke some
> compilers?  Should it do something like the attached?
>

Well.. the first #ifdef will never be triggered with the second set.  You
can't set shadowed and HAVE_GETPWANAM.  So it should be safe as it is.
However maybe it should be an #elif instead of a #endif #if ..

- Ben



From GamlielU at exchange.nih.gov  Tue Sep  9 01:22:51 2003
From: GamlielU at exchange.nih.gov (Gamliel, Udi (NIH/CIT))
Date: Mon, 8 Sep 2003 11:22:51 -0400 
Subject: how to compile ssh with Pam using securid
Message-ID: <64BC9A2B18FC5843BA0DE93548F745F31E560814@nihexchange3.nih.gov>




> Hello 
> I complied openssh like this "./configure --with-pam" and I did configure
> /etc/pam.conf as follows
> 	# PAM configuration
> 	#
> 	# Authentication management
> 	#
> 	sshd    auth required   /lib/security/pam_securid.so reserve
> 	sftp    auth required   /lib/security/pam_securid.so reserve
> 	#
> 	login   auth required   /usr/lib/security/$ISA/pam_unix.so.1
> 	login   auth required   /usr/lib/security/$ISA/pam_dial_auth.so.1
>
> where "/lib/security/pam_securid.so" is an RSA security lib"
> I have no error when I compile the openssh but I do have problem when I
use
> openssh with RSA security library.
> when I type the command "ssh machine_name.xxx.xxx.xxx" while watching
> securid log monitor
> so before I get the prompt to enter my PASSCODE I see on the log monitor
> "ACCESS DENIED, syntax error"
> then I get the prompt
> "ENTER PASSCODE "
> when I put my passcode and allows me to get in (login successfully)
> (but when I ssh  several times and because of ACCESS DENIED message, the
> securid
> lock me and disable my token).
>
>
> One may think the RSA security library is the problem BUT
> when I use the below compiled package
> openssh-3.6.1p1-sol8-sparc-local (size 623506)
> openssl-0.9.7b-sol8-sparc-local (size 3553460)
> everything works just fine no problem at all. But now you will ask me why
> don't you use it ?
> well, I have to know how to compile ssh in case when there is a
> vulnerability we easily can go to another
> version of ssh.
>
>  I hope I gave you enough info
> one more detail
> when I compile openssh ./configure --with-pam
> at the END I get the message
> =======================================================================
>               Random number source: OpenSSL internal ONLY
>
>               Host: sparc-sun-solaris2.8
>           Compiler: gcc
>     Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
> Preprocessor flags: -I/usr/local/ssl/include  -I/usr/local/include
>       Linker flags: -L/usr/local/ssl/lib -R/usr/local/ssl/lib
> -L/usr/local/lib -R/usr/local/lib
>          Libraries:  -lpam -ldl -lrt -lz -lsocket -lnsl -lcrypto
>
> PAM is enabled. You may need to install a PAM control file
> for sshd, otherwise password authentication may fail.
> Example PAM control files can be found in the contrib/
> subdirectory
>
============================================================================
> I am not sure if I have to edit the files in
> /contrib/sshd.pam.freebsd
> /contrib/sshd.pam.generic
> before I compile the new ssh and put the RSA securid lib as follows
> sshd auth required /lib/security/pam_securid.so reserve
>
>  thank you very much again
> Udi
> 301-435-1968
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Friday, September 05, 2003 2:37 PM
> To: Gamliel, Udi (NIH/CIT)
> Cc: 'openssh-unix-dev at mindrot.org'; 'Udi (E-mail)'
> Subject: Re: how to compile ssh with pam
>
>
>
> ./configure --with-pam
>
> is all you need to do to compile in PAM support.. you may need a
> /etc/pam.conf file depending on your platform.  look on contrib/ directory
> for examples.
>
> - Ben
>
> On Fri, 5 Sep 2003, Gamliel, Udi (NIH/CIT) wrote:
>
> >
> >
> >
> > Hello
> >
> > I am compiled openssh3.6.1p2 with PAM and using RSA Security (ACE)
token.
> >
> > the command I used to compile ssh as follow:
> >
> > 1. ./configure --with-pam
> >
> > 2. make
> >
> > 3. make install
> >
> > After starting  the sshd daemon, I  authenticate using the command
> >
> > "ssh xxx.yyy.nih.gov"
> >
> > On the SecurID server I was watching the log monitor and I saw the
> following
> > errors :
> >
> > "ACCESS DENIED, syntax error" before I get the prompt for Passcode
> >
> > and when I put my passcode, it let me login. Doing that for several time
> >
> > SecurID puts me in the "next token code" and then disable my token.
> >
> > I called RSA security and we found out that the problem was in the
> openssh.
> >
> > when RSA sent me a compiled openssh that can be found on the internet,
> then
> >
> > everything worked just fine with no errors.
> >
> > The fact is that we can not depend on finding a compiled openssh with
PAM
> on
> > the
> >
> > internet, so I compiled my own version with Pam
> >
> > but Of course I am sure I am missing some compilation switches and
> options.
> >
> > SO my question to you is :
> >
> > How do I compile an openssh that works with PAM on Unix or Linux.
> >
> > Than you very much
> >
> > Udi Gamliel
> >
> > 301-435-1968
> >
> >
> >
> >
> >
> > Udi Gamliel
> >
> > DNST/EOS
> >
> > Tel - 301-435-1968
> >
> > 10401 Fernwood 20814
> >
> >
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>



From GamlielU at exchange.nih.gov  Tue Sep  9 01:34:21 2003
From: GamlielU at exchange.nih.gov (Gamliel, Udi (NIH/CIT))
Date: Mon, 8 Sep 2003 11:34:21 -0400 
Subject: how to compile ssh with Pam using securid
Message-ID: <64BC9A2B18FC5843BA0DE93548F745F31E560824@nihexchange3.nih.gov>


 Hello 
 I complied openssh-3.6.1p2 like this "./configure --with-pam" and I did
configure
 /etc/pam.conf as follows
 	# PAM configuration
 	#
 	# Authentication management
 	#
 	sshd    auth required   /lib/security/pam_securid.so reserve
 	sftp    auth required   /lib/security/pam_securid.so reserve
 	#
 	login   auth required   /usr/lib/security/$ISA/pam_unix.so.1
 	login   auth required   /usr/lib/security/$ISA/pam_dial_auth.so.1

 where "/lib/security/pam_securid.so" is an RSA security lib"
 I have no error when I compile the openssh but I do have problem when I use
 openssh with RSA security library.
 when I type the command "ssh machine_name.xxx.xxx.xxx" and  watching
 securid log monitor. I see on securid log monitor before I get the prompt
to enter my PASSCODE

 "ACCESS DENIED, syntax error"

 then I get the prompt
 "ENTER PASSCODE "
 when I put my passcode and allows me to get in (login successfully)
 (but when I ssh  several times and because of ACCESS DENIED message, the
 securid locks me and disable my token).


 One may think the RSA security library is the problem BUT
 when I use the below compiled package
 openssh-3.6.1p1-sol8-sparc-local (size 623506)
 openssl-0.9.7b-sol8-sparc-local (size 3553460)
 everything works just fine no problem at all. But now you will ask me why
 don't you use it ?
 well, I have to know how to compile ssh like the one I downloaded from the
internet
in case when there is a vulnerability we easily can go to another version of
ssh.

  I hope I gave you enough info
 one more detail
 when I compile openssh ./configure --with-pam
 at the END I get the message
 =======================================================================
               Random number source: OpenSSL internal ONLY

               Host: sparc-sun-solaris2.8
           Compiler: gcc
     Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
 Preprocessor flags: -I/usr/local/ssl/include  -I/usr/local/include
       Linker flags: -L/usr/local/ssl/lib -R/usr/local/ssl/lib
 -L/usr/local/lib -R/usr/local/lib
          Libraries:  -lpam -ldl -lrt -lz -lsocket -lnsl -lcrypto

 PAM is enabled. You may need to install a PAM control file
 for sshd, otherwise password authentication may fail.
 Example PAM control files can be found in the contrib/
 subdirectory

============================================================================
 I am not sure if I have to edit the files in
 /contrib/sshd.pam.freebsd
 /contrib/sshd.pam.generic
 before I compile the new ssh and put the RSA securid library in
/etc/pam.conf  as follows

 sshd auth required /lib/security/pam_securid.so reserve

  thank you very much again
 Udi
 301-435-1968




From tim at multitalents.net  Tue Sep  9 03:29:18 2003
From: tim at multitalents.net (Tim Rice)
Date: Mon, 8 Sep 2003 10:29:18 -0700 (PDT)
Subject: please test (HEADER.ad)
Message-ID: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>


Could someone with HEADER.ad in arpa/nameser.h please test the
attached patch (against current) to see it it's detected.

None of my platforms have the ad member.

config.h will end up with "#define HAVE_HEADER_AD".

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net
-------------- next part --------------
--- openssh/configure.ac.old	2003-09-08 06:33:33.000000000 -0700
+++ openssh/configure.ac	2003-09-08 10:07:44.849040019 -0700
@@ -1913,6 +1913,9 @@
 					AC_SEARCH_LIBS(res_query, resolv)
 					AC_SEARCH_LIBS(dn_expand, resolv)
 					AC_CHECK_FUNCS(_getshort _getlong)
+					AC_CHECK_MEMBER(struct HEADER.ad,
+						[AC_DEFINE(HAVE_HEADER_AD)],,
+						[#include arpa/nameser.h])
 				])
 		fi
 	]
--- openssh/acconfig.h.old	2003-09-07 11:01:43.989760001 -0700
+++ openssh/acconfig.h	2003-09-08 09:58:18.714080015 -0700
@@ -418,6 +418,9 @@
 /* Define if getrrsetbyname() exists */
 #undef HAVE_GETRRSETBYNAME
 
+/* Define if HEADER.ad exists in arpa/nameser.h */
+#undef HAVE_HEADER_AD
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line ************** */
--- openssh/openbsd-compat/getrrsetbyname.c.old	2003-09-08 06:29:05.644640000 -0700
+++ openssh/openbsd-compat/getrrsetbyname.c	2003-09-08 10:08:28.004080003 -0700
@@ -243,9 +243,11 @@
 	rrset->rri_ttl = response->answer->ttl;
 	rrset->rri_nrdatas = response->header.ancount;
 
+#ifdef HAVE_HEADER_AD
 	/* check for authenticated data */
 	if (response->header.ad == 1)
 		rrset->rri_flags |= RRSET_VALIDATED;
+#endif
 
 	/* copy name from answer section */
 	length = strlen(response->answer->name);

From tim at multitalents.net  Tue Sep  9 03:32:31 2003
From: tim at multitalents.net (Tim Rice)
Date: Mon, 8 Sep 2003 10:32:31 -0700 (PDT)
Subject: please test (HEADER.ad)
In-Reply-To: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
Message-ID: <Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>


Sorry, forgot to mention you must use the --with-dns option to configure.

On Mon, 8 Sep 2003, Tim Rice wrote:

> 
> Could someone with HEADER.ad in arpa/nameser.h please test the
> attached patch (against current) to see it it's detected.
> 
> None of my platforms have the ad member.
> 
> config.h will end up with "#define HAVE_HEADER_AD".
> 
> 

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net
-------------- next part --------------
--- openssh/configure.ac.old	2003-09-08 06:33:33.000000000 -0700
+++ openssh/configure.ac	2003-09-08 10:07:44.849040019 -0700
@@ -1913,6 +1913,9 @@
 					AC_SEARCH_LIBS(res_query, resolv)
 					AC_SEARCH_LIBS(dn_expand, resolv)
 					AC_CHECK_FUNCS(_getshort _getlong)
+					AC_CHECK_MEMBER(struct HEADER.ad,
+						[AC_DEFINE(HAVE_HEADER_AD)],,
+						[#include arpa/nameser.h])
 				])
 		fi
 	]
--- openssh/acconfig.h.old	2003-09-07 11:01:43.989760001 -0700
+++ openssh/acconfig.h	2003-09-08 09:58:18.714080015 -0700
@@ -418,6 +418,9 @@
 /* Define if getrrsetbyname() exists */
 #undef HAVE_GETRRSETBYNAME
 
+/* Define if HEADER.ad exists in arpa/nameser.h */
+#undef HAVE_HEADER_AD
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line ************** */
--- openssh/openbsd-compat/getrrsetbyname.c.old	2003-09-08 06:29:05.644640000 -0700
+++ openssh/openbsd-compat/getrrsetbyname.c	2003-09-08 10:08:28.004080003 -0700
@@ -243,9 +243,11 @@
 	rrset->rri_ttl = response->answer->ttl;
 	rrset->rri_nrdatas = response->header.ancount;
 
+#ifdef HAVE_HEADER_AD
 	/* check for authenticated data */
 	if (response->header.ad == 1)
 		rrset->rri_flags |= RRSET_VALIDATED;
+#endif
 
 	/* copy name from answer section */
 	length = strlen(response->answer->name);

From Eric.Ladner at chevrontexaco.com  Tue Sep  9 05:44:31 2003
From: Eric.Ladner at chevrontexaco.com (Ladner, Eric (Eric.Ladner))
Date: Mon, 8 Sep 2003 14:44:31 -0500
Subject: doing scp from java when file has spaces in it
Message-ID: <53D65D67C6AA694284F7584E25ADD354E959F0@nor935nte2k1.nor935.chevrontexaco.net>


Did you try this:

scp  [...options]  "/vhosts/dw02411/tmp_daemon/1020046111/Lots of spaces
text.txt" grt0002d at loninwebp7.uk.db.com:uploads

(although, I'm surprised the one with single quotes failed).

What OS is this on?  What command line shell?  Escaping of spaces is
depending on the environment you are in, not what kind of scp binary you
use.  The first, third and fourth examples should have worked in a
Bourne shell, Korn shell or BASH (I think).

Eric

-----Original Message-----
From: Vinit Khandelwal [mailto:vinit.k at sonata-software.com] 
Sent: Friday, September 05, 2003 12:42 AM
To: openssh-unix-dev at mindrot.org
Subject: doing scp from java when file has spaces in it


Hi,

I am new to scp. I am trying to scp a file from local (m/c) to remote
through a java application running in Tomcat.

When I try to upload a file with no spaces in it, it works. But if
spaces are present (file name is : "Lots of spaces text .txt") it is not
working.

Some of the things I tried are mentioned below and they failed. 

scp  [...options]  '/vhosts/dw02411/tmp_daemon/1020046111/Lots of spaces
text .txt' grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111/Lots\\ of\\
spaces\\ text\\ .txt grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111/Lots\ of\
spaces\ text\ .txt grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111/"Lots of spaces
text .txt" grt0002d at loninwebp7.uk.db.com:uploads 

scp  [...options]  /vhosts/dw02411/tmp_daemon/1020046111//"Lots of
spaces text .txt/" grt0002d at loninwebp7.uk.db.com:uploads 

Is there any other way of running the command for scp from java
application?

Thanks in advance.

Vinit
*********************************************************************
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you
may not copy or deliver this message to anyone. In such case, you should
destroy this message and kindly notify the sender by reply email. Please
advise immediately if you or your employer does not consent to Internet
email for messages of this kind.
*********************************************************************

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




From tim at multitalents.net  Tue Sep  9 06:27:40 2003
From: tim at multitalents.net (Tim Rice)
Date: Mon, 8 Sep 2003 13:27:40 -0700 (PDT)
Subject: please test (HEADER.ad)
In-Reply-To: <Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
	<Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
Message-ID: <Pine.UW2.4.53.0309081325070.26496@ou8.int.multitalents.net>


Never mind.
Not only is there a mistake in the patch, but I don't think
the AC_CHECK_MEMBER macro will work here.

On Mon, 8 Sep 2003, Tim Rice wrote:

> 
> Sorry, forgot to mention you must use the --with-dns option to configure.
> 
> On Mon, 8 Sep 2003, Tim Rice wrote:
> 
> > 
> > Could someone with HEADER.ad in arpa/nameser.h please test the
> > attached patch (against current) to see it it's detected.
> > 
> > None of my platforms have the ad member.
> > 
> > config.h will end up with "#define HAVE_HEADER_AD".
> > 

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




From scott.burch at camberwind.com  Tue Sep  9 07:12:43 2003
From: scott.burch at camberwind.com (Scott Burch)
Date: Mon, 08 Sep 2003 21:12:43 -0000
Subject: how to compile ssh with Pam using securid
In-Reply-To: <64BC9A2B18FC5843BA0DE93548F745F31E560824@nihexchange3.nih.gov>
References: <64BC9A2B18FC5843BA0DE93548F745F31E560824@nihexchange3.nih.gov>
Message-ID: <1063055732.8040.9.camel@localhost>

Udi,

Do you have privsep disabled? The RSA pam module for SecurID
authentication does not work with privsep enabled. If you want to use
privsep and still do your securid authentication then I strongly
recommend you use Vaclav's patch:

http://sweb.cz/v_t_m/

This is by far the most functional implementation of SecurID
authentication for OpenSSH and it works great.

-Scott


On Mon, 2003-09-08 at 10:34, Gamliel, Udi (NIH/CIT) wrote:
>  Hello 
>  I complied openssh-3.6.1p2 like this "./configure --with-pam" and I did
> configure
>  /etc/pam.conf as follows
>  	# PAM configuration
>  	#
>  	# Authentication management
>  	#
>  	sshd    auth required   /lib/security/pam_securid.so reserve
>  	sftp    auth required   /lib/security/pam_securid.so reserve
>  	#
>  	login   auth required   /usr/lib/security/$ISA/pam_unix.so.1
>  	login   auth required   /usr/lib/security/$ISA/pam_dial_auth.so.1
> 
>  where "/lib/security/pam_securid.so" is an RSA security lib"
>  I have no error when I compile the openssh but I do have problem when I use
>  openssh with RSA security library.
>  when I type the command "ssh machine_name.xxx.xxx.xxx" and  watching
>  securid log monitor. I see on securid log monitor before I get the prompt
> to enter my PASSCODE
> 
>  "ACCESS DENIED, syntax error"
> 
>  then I get the prompt
>  "ENTER PASSCODE "
>  when I put my passcode and allows me to get in (login successfully)
>  (but when I ssh  several times and because of ACCESS DENIED message, the
>  securid locks me and disable my token).
> 
> 
>  One may think the RSA security library is the problem BUT
>  when I use the below compiled package
>  openssh-3.6.1p1-sol8-sparc-local (size 623506)
>  openssl-0.9.7b-sol8-sparc-local (size 3553460)
>  everything works just fine no problem at all. But now you will ask me why
>  don't you use it ?
>  well, I have to know how to compile ssh like the one I downloaded from the
> internet
> in case when there is a vulnerability we easily can go to another version of
> ssh.
> 
>   I hope I gave you enough info
>  one more detail
>  when I compile openssh ./configure --with-pam
>  at the END I get the message
>  =======================================================================
>                Random number source: OpenSSL internal ONLY
> 
>                Host: sparc-sun-solaris2.8
>            Compiler: gcc
>      Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
>  Preprocessor flags: -I/usr/local/ssl/include  -I/usr/local/include
>        Linker flags: -L/usr/local/ssl/lib -R/usr/local/ssl/lib
>  -L/usr/local/lib -R/usr/local/lib
>           Libraries:  -lpam -ldl -lrt -lz -lsocket -lnsl -lcrypto
> 
>  PAM is enabled. You may need to install a PAM control file
>  for sshd, otherwise password authentication may fail.
>  Example PAM control files can be found in the contrib/
>  subdirectory
> 
> ============================================================================
>  I am not sure if I have to edit the files in
>  /contrib/sshd.pam.freebsd
>  /contrib/sshd.pam.generic
>  before I compile the new ssh and put the RSA securid library in
> /etc/pam.conf  as follows
> 
>  sshd auth required /lib/security/pam_securid.so reserve
> 
>   thank you very much again
>  Udi
>  301-435-1968
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 
Scott Burch <scott.burch at camberwind.com>



From wendyp at cray.com  Tue Sep  9 07:40:50 2003
From: wendyp at cray.com (Wendy Palm)
Date: Mon, 08 Sep 2003 16:40:50 -0500
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <3F5CF762.7020907@cray.com>

i'm getting a fatal compiler error in do_upload() in sftp-client.c -

CC-167 cc: WARNING File = sftp-client.c, Line = 1046
   Argument of type "u_int64_t *" is incompatible with parameter of type "off_t *"
           .

                 start_progress_meter(local_path, sb.st_size, &offset);

due to offset being defined as u_int64_t rather than off_t.

off_t on the machines i checked is signed, and other calls to start_progress_meter in
other functions seem to be correct.

% diff -c sftp-client.c.orig sftp-client.c
*** sftp-client.c.orig  Mon Sep  8 16:22:30 2003
--- sftp-client.c       Mon Sep  8 16:34:06 2003
***************
*** 974,980 ****
   {
         int local_fd, status;
         u_int handle_len, id, type;
!       u_int64_t offset;
         char *handle, *data;
         Buffer msg;
         struct stat sb;
--- 974,980 ----
   {
         int local_fd, status;
         u_int handle_len, id, type;
!       off_t offset;
         char *handle, *data;
         Buffer msg;
         struct stat sb;
***************
*** 984,990 ****
         struct outstanding_ack {
                 u_int id;
                 u_int len;
!               u_int64_t offset;
                 TAILQ_ENTRY(outstanding_ack) tq;
         };
         TAILQ_HEAD(ackhead, outstanding_ack) acks;
--- 984,990 ----
         struct outstanding_ack {
                 u_int id;
                 u_int len;
!               off_t offset;
                 TAILQ_ENTRY(outstanding_ack) tq;
         };
         TAILQ_HEAD(ackhead, outstanding_ack) acks;

Ben Lindstrom wrote:

> On this note I think it would be best to opening the floor for testing of
> the current CVS tree.  OpenSSH is in a feature lock and we should be in
> in sync with the OpenBSD tree (there may be stray patches, but hopefully
> nothing major).
> 
> So please if we can get people to start doing tests on their platform is
> would help.
> 
> The major things that have changed is PAM and Kerb/GSS support.  However,
> we did do a clean up of openbsd-compat/ code so I may have broken
> platforms I don't own by playing in there.  I also redid how we handle
> signal (signal() vs a stricter mysignal() version).  So that is something
> to watch out for (basicly made it consistant).
> 
> There are a bunch more changes, but I don't have a copy of the proposed
> release notes sitting in front of me.
> 
> BTW, regression testing should hopefully work for most platforms.  Please
> get in the habbit of using this.  It should give us a better handle on
> platform breakage.  Darren was nice enough to get that rolling recently.
> 
> It should be as simple as ./configure [needed options] && make && make
> tests, but I've not had a chance to confirm it with an actually test on my
> Solaris test box.
> 
> Sooooo... If you wish your platform to work then drop by
> http://www.openssh.com/portable.html, pick your favorate ftp server
> or grab the the source from the CVS tree.
> 
> Thanks,
> 
> - Ben && The OpenSSH Portable Team



-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From Vinnyandmaria at aol.com  Tue Sep  9 10:34:40 2003
From: Vinnyandmaria at aol.com (Vinnyandmaria at aol.com)
Date: Mon, 8 Sep 2003 20:34:40 EDT
Subject: OpenSSH Performance
Message-ID: <a1.3da5c965.2c8e7a20@aol.com>

I am running the latest release of OpenSSH and looking for ways to improve 
performance of scp and sftp. Can you give some suggestions..

Thanks...


From dtucker at zip.com.au  Tue Sep  9 12:12:39 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 09 Sep 2003 12:12:39 +1000
Subject: Variable declarations in xcrypt.c
References: <Pine.BSO.4.44.0309080953500.29487-100000@etoh.eviladmin.org>
Message-ID: <3F5D3717.9B03D49@zip.com.au>

Ben Lindstrom wrote:
> On Mon, 8 Sep 2003, Darren Tucker wrote:
> >       I noticed that xcrypt.c now has some variable declarations after code
> > within a block (for some sets of #ifdef's).  Won't that choke some
> > compilers?  Should it do something like the attached?
> >
> 
> Well.. the first #ifdef will never be triggered with the second set.  You
> can't set shadowed and HAVE_GETPWANAM.  So it should be safe as it is.
> However maybe it should be an #elif instead of a #endif #if ..

I was thinking of it from the POV of removing DISABLE_SHADOW for HP-UX
(Bug #633) but leaving the __hpux section there to support older versions
(I'm not sure about that, Kevin has said he'll look at it).

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



From dtucker at zip.com.au  Tue Sep  9 12:39:19 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 09 Sep 2003 12:39:19 +1000
Subject: 3.6p1 bug on SCO OpenServer
References: <200309081348.h88DmpI06516@tenzing.org>
Message-ID: <3F5D3D57.EF92332D@zip.com.au>

Roger Cornelius wrote:
> Darren Tucker (dtucker at zip.com.au) wrote:
> >"configure" is a machine-generated file, you should edit configure.ac and
> >run "autoreconf" to rebuild it.
> >
> >Are you talking about "*-*-sco3.2v4*" or "*-*-sco3.2v5*" or both?
> >
> >Tim, any issue with doing this?
> 
> I know that configure is auto-generated somehow but am unfamiliar with
> the process.  The patch I supplied was just an example - I was hoping
> the powers that be would do whatever is necessary to incorporate it into
> the build process.

That wasn't intended as a criticism, just for future reference (for
yourself and others).  It's simply a matter of editting configure.ac then
running "autoconf" or "autoreconf", although that does require GNU
autoconf and possibly GNU m4.

That particular change is easy to figure out once you know which version
it applies to, which is why I asked.  More involved patches against
configure can be difficult to convert into the required changes to
configure.ac (and we may get it wrong, particularly if it's on a platform
we can't test).

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



From dtucker at zip.com.au  Tue Sep  9 14:02:18 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 09 Sep 2003 14:02:18 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<3F5CF762.7020907@cray.com>
Message-ID: <3F5D50CA.41BC9A49@zip.com.au>

Wendy Palm wrote:
> i'm getting a fatal compiler error in do_upload() in sftp-client.c -
> 
> CC-167 cc: WARNING File = sftp-client.c, Line = 1046
>    Argument of type "u_int64_t *" is incompatible with parameter of type "off_t *"
>            .
> 
>                  start_progress_meter(local_path, sb.st_size, &offset);
> 
> due to offset being defined as u_int64_t rather than off_t.
> 
> off_t on the machines i checked is signed, and other calls to start_progress_meter in
> other functions seem to be correct.

I'm not sure that's the right solution, since offset is used for
populating the packet and is defined in the (expired)
draft-ietf-secsh-filexfer as uint64.

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



From mouring at etoh.eviladmin.org  Tue Sep  9 14:40:54 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 8 Sep 2003 23:40:54 -0500 (CDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F5D50CA.41BC9A49@zip.com.au>
Message-ID: <Pine.BSO.4.44.0309082330050.29487-100000@etoh.eviladmin.org>



On Tue, 9 Sep 2003, Darren Tucker wrote:

> Wendy Palm wrote:
> > i'm getting a fatal compiler error in do_upload() in sftp-client.c -
> >
> > CC-167 cc: WARNING File = sftp-client.c, Line = 1046
> >    Argument of type "u_int64_t *" is incompatible with parameter of type "off_t *"
> >            .
> >
> >                  start_progress_meter(local_path, sb.st_size, &offset);
> >
> > due to offset being defined as u_int64_t rather than off_t.
> >
> > off_t on the machines i checked is signed, and other calls to start_progress_meter in

Eep.. am I the only one that thinks that is wrong? =)  off_t signed?
sounds like a bad deal.

> > other functions seem to be correct.
>
> I'm not sure that's the right solution, since offset is used for
> populating the packet and is defined in the (expired)
> draft-ietf-secsh-filexfer as uint64.
>

In either case there are places were we will need too typecast to ensure
the compiler does not screw up.

In either case not sure how often we will hit that signed vs unsigned
boundry.  In either case it will screw up on Cray or any other OS with
this issue.

The simple solution is to find the lseek (which I think is the only issue)
and typecast it to (off_t).  Which it more than likely should have been to
start with.

What does Cray do if  lseek is given a negative number?  Does it convert
it to unsigned or is it 'undefined' or a 'fubar case'?

- Ben



From mouring at etoh.eviladmin.org  Tue Sep  9 14:43:03 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 8 Sep 2003 23:43:03 -0500 (CDT)
Subject: Variable declarations in xcrypt.c
In-Reply-To: <3F5D3717.9B03D49@zip.com.au>
Message-ID: <Pine.BSO.4.44.0309082341360.29487-100000@etoh.eviladmin.org>


That makes sense, but is now the right time? =)  I'd vote for this
being a post.

- Ben

On Tue, 9 Sep 2003, Darren Tucker wrote:

> Ben Lindstrom wrote:
> > On Mon, 8 Sep 2003, Darren Tucker wrote:
> > >       I noticed that xcrypt.c now has some variable declarations after code
> > > within a block (for some sets of #ifdef's).  Won't that choke some
> > > compilers?  Should it do something like the attached?
> > >
> >
> > Well.. the first #ifdef will never be triggered with the second set.  You
> > can't set shadowed and HAVE_GETPWANAM.  So it should be safe as it is.
> > However maybe it should be an #elif instead of a #endif #if ..
>
> I was thinking of it from the POV of removing DISABLE_SHADOW for HP-UX
> (Bug #633) but leaving the __hpux section there to support older versions
> (I'm not sure about that, Kevin has said he'll look at it).
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>



From dtucker at zip.com.au  Tue Sep  9 15:05:52 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 09 Sep 2003 15:05:52 +1000
Subject: Variable declarations in xcrypt.c
References: <Pine.BSO.4.44.0309082341360.29487-100000@etoh.eviladmin.org>
Message-ID: <3F5D5FB0.3DC9E0DA@zip.com.au>

Ben Lindstrom wrote:
> That makes sense, but is now the right time? =)  I'd vote for this
> being a post.

Depends on what happens with the HP-UX/trusted mode bug #633.  I think
that has to be fixed before 3.7 ships (3.6.1p2 worked on that config), and
doing so will probably unearth this problem.

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



From mouring at etoh.eviladmin.org  Tue Sep  9 15:18:59 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 9 Sep 2003 00:18:59 -0500 (CDT)
Subject: Variable declarations in xcrypt.c
In-Reply-To: <3F5D5FB0.3DC9E0DA@zip.com.au>
Message-ID: <Pine.BSO.4.44.0309090016270.29487-100000@etoh.eviladmin.org>



On Tue, 9 Sep 2003, Darren Tucker wrote:

> Ben Lindstrom wrote:
> > That makes sense, but is now the right time? =)  I'd vote for this
> > being a post.
>
> Depends on what happens with the HP-UX/trusted mode bug #633.  I think
> that has to be fixed before 3.7 ships (3.6.1p2 worked on that config), and
> doing so will probably unearth this problem.
>

That code was put in during:

Revision 1.10 / (download) - [select for diffs] , Tue Dec 21 10:03:09 1999
UTC (3 years, 8 months ago) by damien
CVS Tags: V_1_2_1_PRE19
Changes since 1.9: +15 -5 lines
Diff to previous 1.9 (colored)
 - Fix DISABLE_SHADOW support
 - Allow MD5 passwords even if shadow passwords are disabled


Long ago code.. Not sure even Damien would remember what he did almost 4
years ago..=) I know I can't remember what I did last year most days.

<shrug>  My HP days ended with 9.x series long time ago.

- Ben



From djm at mindrot.org  Tue Sep  9 16:18:37 2003
From: djm at mindrot.org (Damien Miller)
Date: Tue, 09 Sep 2003 16:18:37 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309082330050.29487-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309082330050.29487-100000@etoh.eviladmin.org>
Message-ID: <3F5D70BD.8030800@mindrot.org>

Ben Lindstrom wrote:
> 
> On Tue, 9 Sep 2003, Darren Tucker wrote:
> 
> 
>>Wendy Palm wrote:
>>
>>>i'm getting a fatal compiler error in do_upload() in sftp-client.c -
>>>
>>>CC-167 cc: WARNING File = sftp-client.c, Line = 1046
>>>   Argument of type "u_int64_t *" is incompatible with parameter of type "off_t *"
>>>           .
>>>
>>>                 start_progress_meter(local_path, sb.st_size, &offset);
>>>
>>>due to offset being defined as u_int64_t rather than off_t.
>>>
>>>off_t on the machines i checked is signed, and other calls to start_progress_meter in
> 
> 
> Eep.. am I the only one that thinks that is wrong? =)  off_t signed?
> sounds like a bad deal.

IIRC off_t should be signed - one must be able to specify negative file 
offsets for things like lseek() with SEEK_CUR or SEEK_END. OpenBSD i386 
typedefs it to "long long".

-d





From cmadams at hiwaay.net  Wed Sep 10 00:55:09 2003
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 9 Sep 2003 09:55:09 -0500
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309082330050.29487-100000@etoh.eviladmin.org>
References: <3F5D50CA.41BC9A49@zip.com.au>
	<Pine.BSO.4.44.0309082330050.29487-100000@etoh.eviladmin.org>
Message-ID: <20030909145509.GC966924@hiwaay.net>

Once upon a time, Ben Lindstrom <mouring at etoh.eviladmin.org> said:
> Eep.. am I the only one that thinks that is wrong? =)  off_t signed?
> sounds like a bad deal.

off_t is required to be signed (think seeking backwards in a file).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From Curtis.Steward at goodrich.com  Wed Sep 10 05:40:34 2003
From: Curtis.Steward at goodrich.com (STEWARD, Curtis (Jamestown))
Date: Tue, 9 Sep 2003 15:40:34 -0400 
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
Message-ID: <809D3CD3C504D711A7810008C709B597368490@jamesx.jms.lucascargo.com>

Tried the user discussion list to no avail, can't get 3.6.p2 
portable running due to buffer_get errors.  Does the
latest portable SNAP incorporate the latest patches?

Running Red Hat 8.0

AS SHIPPED
/usr/sbin/sshd
...
cool, listens on 22 with 3.4p1

WITH 3.6.1p2
./configure
make
make install
...
/usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
buffer_get: trying to get more bytes 1 than in buffer 0
make: [check-config] Error 255 (ignored)

WITH 3.5p1
./configure
make
make install
...
cool, listens on 22 with 3.5p1

WITH SNAP-20030830 (had to go to 8/30 since strlcat.h was missing!?
./configure
make
make install
...
/usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
buffer_get: trying to get more bytes 1 than in buffer 0
make: [check-config] Error 255 (ignored)

What's up?

cs



From wendyp at cray.com  Wed Sep 10 09:16:57 2003
From: wendyp at cray.com (Wendy Palm)
Date: Tue, 09 Sep 2003 18:16:57 -0500
Subject: please test (HEADER.ad)
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
	<Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
Message-ID: <3F5E5F69.7020309@cray.com>

no, i'm sorry, it didn't work.  a couple of problems-

1.  you forgot the "<" and ">" for the include file

so, i changed configure.ac to

--- 1916,1925 ----
                                         # Needed by our getrrsetbyname()
                                         AC_SEARCH_LIBS(res_query, resolv)
                                         AC_SEARCH_LIBS(dn_expand, resolv)
+                                       AC_CHECK_FUNCS(_getshort _getlong)
+                                       AC_CHECK_MEMBER(struct HEADER.ad,
+                                       [AC_DEFINE(HAVE_HEADER_AD)],,
+                                       [#include <arpa/nameser.h>])
                                 ])
                 fi


which generates a configure with a conftest.c looking like -
#include <arpa/nameser.h>

int
main ()
{
static struct HEADER ac_aggr;
if (sizeof ac_aggr.ad)
return 0;
   ;
   return 0;
}

2. which has the error-
   The indicated type is incomplete.

   static struct HEADER ac_aggr;
                        ^

HEADER is defined as a bit field, so sizeof doesn't really work.

typedef struct {
         unsigned        id :16;         /* query identification number */
#if BYTE_ORDER == BIG_ENDIAN
                         /* fields in third byte */
         unsigned        qr: 1;          /* response flag */
         unsigned        opcode: 4;      /* purpose of message */
         unsigned        aa: 1;          /* authoritive answer */
         unsigned        tc: 1;          /* truncated message */
         unsigned        rd: 1;          /* recursion desired */
                         /* fields in fourth byte */
         unsigned        ra: 1;          /* recursion available */
         unsigned        unused :1;      /* unused bits (MBZ as of 4.9.3a3) */
         unsigned        ad: 1;          /* authentic data from named */
         unsigned        cd: 1;          /* checking disabled by resolver */
         unsigned        rcode :4;       /* response code */
#endif
#if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN
                         /* fields in third byte */
         unsigned        rd :1;          /* recursion desired */
         unsigned        tc :1;          /* truncated message */
         unsigned        aa :1;          /* authoritive answer */
         unsigned        opcode :4;      /* purpose of message */
         unsigned        qr :1;          /* response flag */
                         /* fields in fourth byte */
         unsigned        rcode :4;       /* response code */
         unsigned        cd: 1;          /* checking disabled by resolver */
         unsigned        ad: 1;          /* authentic data from named */
         unsigned        unused :1;      /* unused bits (MBZ as of 4.9.3a3) */
         unsigned        ra :1;          /* recursion available */
#endif
                         /* remaining bytes */
         unsigned        qdcount :16;    /* number of question entries */
         unsigned        ancount :16;    /* number of answer entries */
         unsigned        nscount :16;    /* number of authority entries */
         unsigned        arcount :16;    /* number of resource entries */
} HEADER;

this works, kind of (leaves WARNING message about using variable before
it's defined).   i don't know anything about autoconf, so i'm not sure how to
create it in configure.ac.

#include <arpa/nameser.h>
int
main ()
{
HEADER ac_aggr;
if (ac_aggr.ad)
return 0;
   ;
   return 0;
}

i'm happy to test anything changes.
wendy


Tim Rice wrote:

> Sorry, forgot to mention you must use the --with-dns option to configure.
> 
> On Mon, 8 Sep 2003, Tim Rice wrote:
> 
> 
>>Could someone with HEADER.ad in arpa/nameser.h please test the
>>attached patch (against current) to see it it's detected.
>>
>>None of my platforms have the ad member.
>>
>>config.h will end up with "#define HAVE_HEADER_AD".
>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> --- openssh/configure.ac.old	2003-09-08 06:33:33.000000000 -0700
> +++ openssh/configure.ac	2003-09-08 10:07:44.849040019 -0700
> @@ -1913,6 +1913,9 @@
>  					AC_SEARCH_LIBS(res_query, resolv)
>  					AC_SEARCH_LIBS(dn_expand, resolv)
>  					AC_CHECK_FUNCS(_getshort _getlong)
> +					AC_CHECK_MEMBER(struct HEADER.ad,
> +						[AC_DEFINE(HAVE_HEADER_AD)],,
> +						[#include arpa/nameser.h])
>  				])
>  		fi
>  	]
> --- openssh/acconfig.h.old	2003-09-07 11:01:43.989760001 -0700
> +++ openssh/acconfig.h	2003-09-08 09:58:18.714080015 -0700
> @@ -418,6 +418,9 @@
>  /* Define if getrrsetbyname() exists */
>  #undef HAVE_GETRRSETBYNAME
>  
> +/* Define if HEADER.ad exists in arpa/nameser.h */
> +#undef HAVE_HEADER_AD
> +
>  @BOTTOM@
>  
>  /* ******************* Shouldn't need to edit below this line ************** */
> --- openssh/openbsd-compat/getrrsetbyname.c.old	2003-09-08 06:29:05.644640000 -0700
> +++ openssh/openbsd-compat/getrrsetbyname.c	2003-09-08 10:08:28.004080003 -0700
> @@ -243,9 +243,11 @@
>  	rrset->rri_ttl = response->answer->ttl;
>  	rrset->rri_nrdatas = response->header.ancount;
>  
> +#ifdef HAVE_HEADER_AD
>  	/* check for authenticated data */
>  	if (response->header.ad == 1)
>  		rrset->rri_flags |= RRSET_VALIDATED;
> +#endif
>  
>  	/* copy name from answer section */
>  	length = strlen(response->answer->name);
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From wendyp at cray.com  Wed Sep 10 09:34:22 2003
From: wendyp at cray.com (Wendy Palm)
Date: Tue, 09 Sep 2003 18:34:22 -0500
Subject: please test (HEADER.ad)
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>	<Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
	<3F5E5F69.7020309@cray.com>
Message-ID: <3F5E637E.3010309@cray.com>

update - actually, the WARNING message mentioned below is now gone.

Wendy Palm wrote:

> no, i'm sorry, it didn't work.  a couple of problems-
> 
> 1.  you forgot the "<" and ">" for the include file
> 
> so, i changed configure.ac to
> 
> --- 1916,1925 ----
>                                         # Needed by our getrrsetbyname()
>                                         AC_SEARCH_LIBS(res_query, resolv)
>                                         AC_SEARCH_LIBS(dn_expand, resolv)
> +                                       AC_CHECK_FUNCS(_getshort _getlong)
> +                                       AC_CHECK_MEMBER(struct HEADER.ad,
> +                                       [AC_DEFINE(HAVE_HEADER_AD)],,
> +                                       [#include <arpa/nameser.h>])
>                                 ])
>                 fi
> 
> 
> which generates a configure with a conftest.c looking like -
> #include <arpa/nameser.h>
> 
> int
> main ()
> {
> static struct HEADER ac_aggr;
> if (sizeof ac_aggr.ad)
> return 0;
>   ;
>   return 0;
> }
> 
> 2. which has the error-
>   The indicated type is incomplete.
> 
>   static struct HEADER ac_aggr;
>                        ^
> 
> HEADER is defined as a bit field, so sizeof doesn't really work.
> 
> typedef struct {
>         unsigned        id :16;         /* query identification number */
> #if BYTE_ORDER == BIG_ENDIAN
>                         /* fields in third byte */
>         unsigned        qr: 1;          /* response flag */
>         unsigned        opcode: 4;      /* purpose of message */
>         unsigned        aa: 1;          /* authoritive answer */
>         unsigned        tc: 1;          /* truncated message */
>         unsigned        rd: 1;          /* recursion desired */
>                         /* fields in fourth byte */
>         unsigned        ra: 1;          /* recursion available */
>         unsigned        unused :1;      /* unused bits (MBZ as of 
> 4.9.3a3) */
>         unsigned        ad: 1;          /* authentic data from named */
>         unsigned        cd: 1;          /* checking disabled by resolver */
>         unsigned        rcode :4;       /* response code */
> #endif
> #if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN
>                         /* fields in third byte */
>         unsigned        rd :1;          /* recursion desired */
>         unsigned        tc :1;          /* truncated message */
>         unsigned        aa :1;          /* authoritive answer */
>         unsigned        opcode :4;      /* purpose of message */
>         unsigned        qr :1;          /* response flag */
>                         /* fields in fourth byte */
>         unsigned        rcode :4;       /* response code */
>         unsigned        cd: 1;          /* checking disabled by resolver */
>         unsigned        ad: 1;          /* authentic data from named */
>         unsigned        unused :1;      /* unused bits (MBZ as of 
> 4.9.3a3) */
>         unsigned        ra :1;          /* recursion available */
> #endif
>                         /* remaining bytes */
>         unsigned        qdcount :16;    /* number of question entries */
>         unsigned        ancount :16;    /* number of answer entries */
>         unsigned        nscount :16;    /* number of authority entries */
>         unsigned        arcount :16;    /* number of resource entries */
> } HEADER;
> 
> this works, kind of (leaves WARNING message about using variable before
> it's defined).   i don't know anything about autoconf, so i'm not sure 
> how to
> create it in configure.ac.
> 
> #include <arpa/nameser.h>
> int
> main ()
> {
> HEADER ac_aggr;
> if (ac_aggr.ad)
> return 0;
>   ;
>   return 0;
> }
> 
> i'm happy to test anything changes.
> wendy
> 
> 
> Tim Rice wrote:
> 
>> Sorry, forgot to mention you must use the --with-dns option to configure.
>>
>> On Mon, 8 Sep 2003, Tim Rice wrote:
>>
>>
>>> Could someone with HEADER.ad in arpa/nameser.h please test the
>>> attached patch (against current) to see it it's detected.
>>>
>>> None of my platforms have the ad member.
>>>
>>> config.h will end up with "#define HAVE_HEADER_AD".
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> --- openssh/configure.ac.old    2003-09-08 06:33:33.000000000 -0700
>> +++ openssh/configure.ac    2003-09-08 10:07:44.849040019 -0700
>> @@ -1913,6 +1913,9 @@
>>                      AC_SEARCH_LIBS(res_query, resolv)
>>                      AC_SEARCH_LIBS(dn_expand, resolv)
>>                      AC_CHECK_FUNCS(_getshort _getlong)
>> +                    AC_CHECK_MEMBER(struct HEADER.ad,
>> +                        [AC_DEFINE(HAVE_HEADER_AD)],,
>> +                        [#include arpa/nameser.h])
>>                  ])
>>          fi
>>      ]
>> --- openssh/acconfig.h.old    2003-09-07 11:01:43.989760001 -0700
>> +++ openssh/acconfig.h    2003-09-08 09:58:18.714080015 -0700
>> @@ -418,6 +418,9 @@
>>  /* Define if getrrsetbyname() exists */
>>  #undef HAVE_GETRRSETBYNAME
>>  
>> +/* Define if HEADER.ad exists in arpa/nameser.h */
>> +#undef HAVE_HEADER_AD
>> +
>>  @BOTTOM@
>>  
>>  /* ******************* Shouldn't need to edit below this line 
>> ************** */
>> --- openssh/openbsd-compat/getrrsetbyname.c.old    2003-09-08 
>> 06:29:05.644640000 -0700
>> +++ openssh/openbsd-compat/getrrsetbyname.c    2003-09-08 
>> 10:08:28.004080003 -0700
>> @@ -243,9 +243,11 @@
>>      rrset->rri_ttl = response->answer->ttl;
>>      rrset->rri_nrdatas = response->header.ancount;
>>  
>> +#ifdef HAVE_HEADER_AD
>>      /* check for authenticated data */
>>      if (response->header.ad == 1)
>>          rrset->rri_flags |= RRSET_VALIDATED;
>> +#endif
>>  
>>      /* copy name from answer section */
>>      length = strlen(response->answer->name);
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> 
> 


-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From tim at multitalents.net  Wed Sep 10 09:45:42 2003
From: tim at multitalents.net (Tim Rice)
Date: Tue, 9 Sep 2003 16:45:42 -0700 (PDT)
Subject: please test (HEADER.ad)
In-Reply-To: <3F5E5F69.7020309@cray.com>
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
	<Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
	<3F5E5F69.7020309@cray.com>
Message-ID: <Pine.UW2.4.53.0309091626440.19084@ou8.int.multitalents.net>

On Tue, 9 Sep 2003, Wendy Palm wrote:

> no, i'm sorry, it didn't work.  a couple of problems-

Yes, I discovered the problems too.
I ended up hacking a copy of arpa/nameser.h to test and commited
something on the 8th.

Please test today's snapshot.


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




From wendyp at cray.com  Wed Sep 10 10:10:40 2003
From: wendyp at cray.com (Wendy Palm)
Date: Tue, 09 Sep 2003 19:10:40 -0500
Subject: please test (HEADER.ad)
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
	<Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
	<3F5E5F69.7020309@cray.com>
	<Pine.UW2.4.53.0309091626440.19084@ou8.int.multitalents.net>
Message-ID: <3F5E6C00.5000404@cray.com>

have snapshots been taken?

last one i see is 0906.

Tim Rice wrote:

> On Tue, 9 Sep 2003, Wendy Palm wrote:
> 
> 
>>no, i'm sorry, it didn't work.  a couple of problems-
>>
> 
> Yes, I discovered the problems too.
> I ended up hacking a copy of arpa/nameser.h to test and commited
> something on the 8th.
> 
> Please test today's snapshot.
> 
> 
> 


-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From dtucker at zip.com.au  Wed Sep 10 11:31:30 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Sep 2003 11:31:30 +1000
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
References: <809D3CD3C504D711A7810008C709B597368490@jamesx.jms.lucascargo.com>
Message-ID: <3F5E7EF2.3FA4AA43@zip.com.au>

"STEWARD, Curtis (Jamestown)" wrote:
> Tried the user discussion list to no avail, can't get 3.6.p2
> portable running due to buffer_get errors.  Does the
> latest portable SNAP incorporate the latest patches?

The snapshots contain everything committed to the CVS tree at the point
that they were generated.

> Running Red Hat 8.0
[snip]
> /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
> buffer_get: trying to get more bytes 1 than in buffer 0
> make: [check-config] Error 255 (ignored)

I build and test on Redhat 8 and I've never seen those errors.  What
versions of OpenSSL and zlib do you have?  Which version of gcc?

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



From gem at rellim.com  Wed Sep 10 15:19:37 2003
From: gem at rellim.com (Gary E. Miller)
Date: Tue, 9 Sep 2003 22:19:37 -0700 (PDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F5A7362.1BEAEB85@zip.com.au>
References: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<Pine.LNX.4.56.0309061127410.2930@catbert.rellim.com>
	<3F5A7362.1BEAEB85@zip.com.au>
Message-ID: <Pine.LNX.4.56.0309092021210.2057@catbert.rellim.com>

Yo Darren!

On Sun, 7 Sep 2003, Darren Tucker wrote:

> Thanks for that, both of those have been fixed.  You can try the attached
> patch, or wait for tomorrow's snapshot.

Thanks for the quick patch.  I grabbed the 10 Sep snapshot.  Works well
for me now. "make tests" runs fine.

Couple of issues with the key in DNS.  Not exactly sure what is going on
yet.  I have the key in my dnssec zone now.

I have my local domain, rellim.com, set up in my /etc/resolv.conf so I can
use short names.  Then if I do this it does not check the key in DNS:
	ssh hobbes

But this does:
	ssh hobbes.rellim.com

Seems this should be fixable?

When I put a BAD fingerprint in the DS, then try to connect, ssh will not
let me continue.  Here is the message I get:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Please contact your system administrator.
Host key verification failed.

It would be nice if it mentioned that it is the DNSSEC key that failed,
what the bad fingerprint was, etc.  That would save a LOT of looking around...

At this point, some of my DNSSEC keys work and some do not.  Could be
operator error, maybe not.

So why is it that the fingerprint generated with "ssh-keygen -l" is not
the same as the fingerprint from "sshkeygen -r hostname -f keyfile" ?

This is on a heavily patched Slackware 8.0, running gcc 3.3, glibc 2.3.2 and
openssl 0.9.7b.  Here is the config output:

                    Manpage format: man
                       DNS support: yes
                       PAM support: no
                 KerberosV support: no
                 Smartcard support: no
                     S/KEY support: no
              TCP Wrappers support: yes
              MD5 password support: yes
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: i686-pc-linux-gnu
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags: -I/usr/local/ssl/lib
      Linker flags: -L/usr/local/ssl/lib
         Libraries: -lwrap  -lresolv -lutil -lz -lnsl  -lcrypto -lcrypt



RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676



From dtucker at zip.com.au  Wed Sep 10 17:08:31 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Sep 2003 17:08:31 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<Pine.LNX.4.56.0309061127410.2930@catbert.rellim.com>
	<3F5A7362.1BEAEB85@zip.com.au>
	<Pine.LNX.4.56.0309092021210.2057@catbert.rellim.com>
Message-ID: <3F5ECDEF.20021E62@zip.com.au>

"Gary E. Miller" wrote:
> Thanks for the quick patch.  I grabbed the 10 Sep snapshot.  Works well
> for me now. "make tests" runs fine.

Excellent, thank you.

The rest is about DNS host key support (which I've never used) which is
experimental.  It comes directly from OpenBSD's OpenSSH, so any changes
would have to be done there first.  They're currently in a freeze for
release and I don't know if they'd make changes to it right now.  Anyone?

> I have my local domain, rellim.com, set up in my /etc/resolv.conf so I can
> use short names.  Then if I do this it does not check the key in DNS:
>         ssh hobbes
> 
> But this does:
>         ssh hobbes.rellim.com
> 
> Seems this should be fixable?

Possibly.  I looked quickly at it but I couldn't see a simple way of doing
it.  You probably want the ai->ai_canonname from whichever 
address you ended up connecting to.

> When I put a BAD fingerprint in the DS, then try to connect, ssh will not
> let me continue.  Here is the message I get:
[snip message]
> It would be nice if it mentioned that it is the DNSSEC key that failed,
> what the bad fingerprint was, etc.  That would save a LOT of looking around...

That looks like it could be trivially added to dns.c.

> So why is it that the fingerprint generated with "ssh-keygen -l" is not
> the same as the fingerprint from "sshkeygen -r hostname -f keyfile" ?

Sorry, no idea.

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



From Curtis.Steward at goodrich.com  Wed Sep 10 23:08:03 2003
From: Curtis.Steward at goodrich.com (STEWARD, Curtis (Jamestown))
Date: Wed, 10 Sep 2003 09:08:03 -0400
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
Message-ID: <809D3CD3C504D711A7810008C709B597368492@jamesx.jms.lucascargo.com>

I've been running gcc 3.2, OpenSSL 0.9.7b and zlib 1.1.4.  After
receiving your reply I tried both OpenSSL 0.9.6.b and pulled
/usr/local/bin and /usr/local/sbin out of the PATH only
to get the same results.  I don't have any OS patches on 8.0,
so I can only guess I have something flakey on my box since
your up and running with the same release?  Let me know if 
you have any other ideas.

Thanks,

cs

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Tuesday, September 09, 2003 8:32 PM
To: STEWARD, Curtis (Jamestown)
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: 3.6p2 build errors on buffer_get with latest portable/SNAP


"STEWARD, Curtis (Jamestown)" wrote:
> Tried the user discussion list to no avail, can't get 3.6.p2
> portable running due to buffer_get errors.  Does the
> latest portable SNAP incorporate the latest patches?

The snapshots contain everything committed to the CVS tree at the point
that they were generated.

> Running Red Hat 8.0
[snip]
> /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
> buffer_get: trying to get more bytes 1 than in buffer 0
> make: [check-config] Error 255 (ignored)

I build and test on Redhat 8 and I've never seen those errors.  What
versions of OpenSSL and zlib do you have?  Which version of gcc?

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



From dtucker at zip.com.au  Wed Sep 10 23:31:59 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Sep 2003 23:31:59 +1000
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
References: <809D3CD3C504D711A7810008C709B597368492@jamesx.jms.lucascargo.com>
Message-ID: <3F5F27CF.E2801158@zip.com.au>

"STEWARD, Curtis (Jamestown)" wrote:
> I've been running gcc 3.2, OpenSSL 0.9.7b and zlib 1.1.4.  After
> receiving your reply I tried both OpenSSL 0.9.6.b and pulled
> /usr/local/bin and /usr/local/sbin out of the PATH only
> to get the same results.  I don't have any OS patches on 8.0,
> so I can only guess I have something flakey on my box since
> your up and running with the same release?  Let me know if
> you have any other ideas.

Do you have openssl or zlib libraries in /usr/local?  Something odd in
your sshd_config triggering the problem?  Corrupt public/private keys?

You can use "-ddd" for a little more debug info:
# ./sshd -ddd -t
debug2: read_server_config: filename /usr/local/etc/sshd_config
debug1: sshd version OpenSSH_3.7p1
debug3: Not a RSA1 key file /usr/local/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 /usr/local/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA

Here's the versions I have:
# rpm -q openssl openssl-devel zlib zlib-devel gcc glibc-devel
openssl-0.9.6b-33
openssl-devel-0.9.6b-33
zlib-1.1.4-8.8x
zlib-devel-1.1.4-8.8x
gcc-3.2-7
glibc-devel-2.3.2-4.80.6

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



From Curtis.Steward at goodrich.com  Wed Sep 10 23:49:41 2003
From: Curtis.Steward at goodrich.com (STEWARD, Curtis (Jamestown))
Date: Wed, 10 Sep 2003 09:49:41 -0400
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
Message-ID: <809D3CD3C504D711A7810008C709B597368493@jamesx.jms.lucascargo.com>

I took out /usr/local path's just to eliminate something
that might be interfering.  I've tested both sshd_config and
ssh_host_rsa_key as provided by the "make install" with 
the same errors.  Here's the debug:

# /usr/local/sbin/sshd -ddd -t
debug2: read_server_config: filename /usr/local/etc/sshd_config
debug1: sshd version OpenSSH_3.7p1
buffer_get: trying to get more bytes 1 than in buffer 0

But look at my 8.0 rpm's... ?!
# rpm -q openssl openssl-devel zlib zlib-devel gcc glibc-devel
openssl-0.9.6b-29
openssl-devel-0.9.6b-29
zlib-1.1.4-4
zlib-devel-1.1.4-4
gcc-3.2-7
glibc-devel-2.2.93-5

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Wednesday, September 10, 2003 8:32 AM
To: STEWARD, Curtis (Jamestown)
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: 3.6p2 build errors on buffer_get with latest portable/SNAP


"STEWARD, Curtis (Jamestown)" wrote:
> I've been running gcc 3.2, OpenSSL 0.9.7b and zlib 1.1.4.  After
> receiving your reply I tried both OpenSSL 0.9.6.b and pulled
> /usr/local/bin and /usr/local/sbin out of the PATH only
> to get the same results.  I don't have any OS patches on 8.0,
> so I can only guess I have something flakey on my box since
> your up and running with the same release?  Let me know if
> you have any other ideas.

Do you have openssl or zlib libraries in /usr/local?  Something odd in
your sshd_config triggering the problem?  Corrupt public/private keys?

You can use "-ddd" for a little more debug info:
# ./sshd -ddd -t
debug2: read_server_config: filename /usr/local/etc/sshd_config
debug1: sshd version OpenSSH_3.7p1
debug3: Not a RSA1 key file /usr/local/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 /usr/local/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA

Here's the versions I have:
# rpm -q openssl openssl-devel zlib zlib-devel gcc glibc-devel
openssl-0.9.6b-33
openssl-devel-0.9.6b-33
zlib-1.1.4-8.8x
zlib-devel-1.1.4-8.8x
gcc-3.2-7
glibc-devel-2.3.2-4.80.6

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



From dtucker at zip.com.au  Thu Sep 11 00:13:57 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Sep 2003 00:13:57 +1000
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
References: <809D3CD3C504D711A7810008C709B597368493@jamesx.jms.lucascargo.com>
Message-ID: <3F5F31A5.E25EE347@zip.com.au>

"STEWARD, Curtis (Jamestown)" wrote:
> 
> I took out /usr/local path's just to eliminate something
> that might be interfering.  I've tested both sshd_config and
> ssh_host_rsa_key as provided by the "make install" with
> the same errors.  Here's the debug:
> 
> # /usr/local/sbin/sshd -ddd -t
> debug2: read_server_config: filename /usr/local/etc/sshd_config
> debug1: sshd version OpenSSH_3.7p1
> buffer_get: trying to get more bytes 1 than in buffer 0

Try moving the host keys and generating new ones (particularly the SSH V1
ssh_host_key which was not shown in my debugging) for a test.  That would
be my guess.

If it's not that, you can use gdb to set a breakpoint for that line of
code, then use "bt" to get a stack trace to fund out where in the code the
failing call is coming from:

# gdb -q ./sshd
(gdb) set args -t
(gdb) break buffer.c:124
Breakpoint 1 at 0x8062bfc: file ../buffer.c, line 124.
(gdb) run
[wait for failure]
(gdb) bt

> But look at my 8.0 rpm's... ?!
> # rpm -q openssl openssl-devel zlib zlib-devel gcc glibc-devel

You could try updating those.

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



From wendyp at cray.com  Thu Sep 11 02:03:42 2003
From: wendyp at cray.com (Wendy Palm)
Date: Wed, 10 Sep 2003 11:03:42 -0500
Subject: please test (HEADER.ad)
References: <Pine.UW2.4.53.0309081022290.6069@ou8.int.multitalents.net>
	<Pine.UW2.4.53.0309081030500.6243@ou8.int.multitalents.net>
	<3F5E5F69.7020309@cray.com>
	<Pine.UW2.4.53.0309091626440.19084@ou8.int.multitalents.net>
Message-ID: <3F5F4B5E.5020009@cray.com>

just tested today's snapshot and works correctly to figure it out
for both new and old crays.

thanks,
wendy

Tim Rice wrote:

> On Tue, 9 Sep 2003, Wendy Palm wrote:
> 
> 
>>no, i'm sorry, it didn't work.  a couple of problems-
>>
> 
> Yes, I discovered the problems too.
> I ended up hacking a copy of arpa/nameser.h to test and commited
> something on the 8th.
> 
> Please test today's snapshot.
> 
> 
> 


-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From Curtis.Steward at goodrich.com  Thu Sep 11 02:42:57 2003
From: Curtis.Steward at goodrich.com (STEWARD, Curtis (Jamestown))
Date: Wed, 10 Sep 2003 12:42:57 -0400
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
Message-ID: <809D3CD3C504D711A7810008C709B597368494@jamesx.jms.lucascargo.com>

Darren,

FYI, I tried a 2nd machine (this time with VMWare and 8.0)
had the same results.  The 2nd machine had identical gcc,
ssl, zlib, etc.  Here's the debug.  From what I could figure
out I could get the error on both buffer_init() 
and buffer_get().  xmalloc()?

BUFFER_INIT
# gdb -q ./sshd
(gdb) set args -t
(gdb) break buffer.c:30
Breakpoint 1 at 0x80687ce: file buffer.c, line 30.
(gdb) break buffer.c:31
Breakpoint 2 at 0x8068670: file buffer.c, line 31.
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x080687ce in buffer_init at buffer.c:30
2   breakpoint     keep y   0x08068670 in buffer_free at buffer.c:31
(gdb) run
Starting program: /root/gz/openssh/sshd -t

Breakpoint 1, buffer_init (buffer=0xbffff1f0) at buffer.c:30
30      }
(gdb) c
Continuing.
buffer_get: trying to get more bytes 1 than in buffer 0

Program exited with code 0377.
(gdb) bt
No stack.
(gdb)

BUFFER_GET
# gdb -q ./sshd
(gdb) set args -t
(gdb) break buffer.c:124
Breakpoint 1 at 0x8068896: file buffer.c, line 124.
(gdb) break buffer.c:125
Breakpoint 2 at 0x806886f: file buffer.c, line 125.
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x08068896 in buffer_get at buffer.c:124
2   breakpoint     keep y   0x0806886f in buffer_get at buffer.c:125
(gdb) run
Starting program: /root/gz/openssh/sshd -t

Breakpoint 1, buffer_get (buffer=0xbffff1f0, buf=0x0, len=1) at buffer.c:124
124                     fatal("buffer_get: trying to get more bytes %d than
in buffer %d",
(gdb) c
Continuing.
buffer_get: trying to get more bytes 1 than in buffer 0

Program exited with code 0377.
(gdb) bt
No stack.
(gdb)



Regards,

cs

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Wednesday, September 10, 2003 9:14 AM
To: STEWARD, Curtis (Jamestown)
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: 3.6p2 build errors on buffer_get with latest portable/SNAP


"STEWARD, Curtis (Jamestown)" wrote:
> 
> I took out /usr/local path's just to eliminate something
> that might be interfering.  I've tested both sshd_config and
> ssh_host_rsa_key as provided by the "make install" with
> the same errors.  Here's the debug:
> 
> # /usr/local/sbin/sshd -ddd -t
> debug2: read_server_config: filename /usr/local/etc/sshd_config
> debug1: sshd version OpenSSH_3.7p1
> buffer_get: trying to get more bytes 1 than in buffer 0

Try moving the host keys and generating new ones (particularly the SSH V1
ssh_host_key which was not shown in my debugging) for a test.  That would
be my guess.

If it's not that, you can use gdb to set a breakpoint for that line of
code, then use "bt" to get a stack trace to fund out where in the code the
failing call is coming from:

# gdb -q ./sshd
(gdb) set args -t
(gdb) break buffer.c:124
Breakpoint 1 at 0x8062bfc: file ../buffer.c, line 124.
(gdb) run
[wait for failure]
(gdb) bt

> But look at my 8.0 rpm's... ?!
> # rpm -q openssl openssl-devel zlib zlib-devel gcc glibc-devel

You could try updating those.

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



From vinschen at redhat.com  Thu Sep 11 04:59:47 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 10 Sep 2003 20:59:47 +0200
Subject: [PATCH] No extern declarations of optarg & co if getopt.h is
	available
Message-ID: <20030910185947.GI9981@cygbert.vinschen.de>

Hi,

I have a problem with the extern declarations of optarg, optind, etc.

We're currently moving getopt from being a statically linked function
to a dynamically linked function as part of the Cygwin DLL.  On Windows,
this requires to generate special symbols (__imp__optarg, etc.), which
is done by marking the exported variables in the corresponding header. 
Instead of

  extern char *optarg;

getopt.h now contains

  extern char __declspec(dllimport) *optarg;

I'm sorry, but that's not my invention.

Now the problem.  ssh.c, sshd.c and a lot of other files do explicitely
declare the opt* variables at the beginning of main(), even when a
getopt.h file is available.  The problem with this is, that this
explicit extern declaration overrides the declaration from getopt.h.
So instead of linking against the correct __imp__optarg symbol, the
linker tries to linked against the normal _optarg.

This could be easily circumvented by either not declaring the variables
at all in these main() funcs, or by surrounding the declarations with

  #ifndef HAVE_GETOPT_H
      extern char *optarg;
      ...
  #endif

The patch is attached.

Thanks,
Corinna

Index: scp.c
===================================================================
RCS file: /cvs/openssh_cvs/scp.c,v
retrieving revision 1.118
diff -p -u -r1.118 scp.c
--- scp.c	21 Aug 2003 23:34:41 -0000	1.118
+++ scp.c	10 Sep 2003 18:59:00 -0000
@@ -219,8 +219,10 @@ main(int argc, char **argv)
 	int ch, fflag, tflag, status;
 	double speed;
 	char *targ, *endp;
+#ifndef HAVE_GETOPT_H
 	extern char *optarg;
 	extern int optind;
+#endif
 
 	__progname = ssh_get_progname(argv[0]);
 
Index: sftp.c
===================================================================
RCS file: /cvs/openssh_cvs/sftp.c,v
retrieving revision 1.38
diff -p -u -r1.38 sftp.c
--- sftp.c	21 Aug 2003 23:34:41 -0000	1.38
+++ sftp.c	10 Sep 2003 18:59:00 -0000
@@ -129,8 +129,10 @@ main(int argc, char **argv)
 	char *ssh_program = _PATH_SSH_PROGRAM, *sftp_direct = NULL;
 	LogLevel ll = SYSLOG_LEVEL_INFO;
 	arglist args;
+#ifndef HAVE_GETOPT_H
 	extern int optind;
 	extern char *optarg;
+#endif
 
 	__progname = ssh_get_progname(argv[0]);
 	args.list = NULL;
Index: ssh-add.c
===================================================================
RCS file: /cvs/openssh_cvs/ssh-add.c,v
retrieving revision 1.74
diff -p -u -r1.74 ssh-add.c
--- ssh-add.c	21 Aug 2003 23:34:41 -0000	1.74
+++ ssh-add.c	10 Sep 2003 18:59:00 -0000
@@ -313,8 +313,10 @@ usage(void)
 int
 main(int argc, char **argv)
 {
+#ifndef HAVE_GETOPT_H
 	extern char *optarg;
 	extern int optind;
+#endif
 	AuthenticationConnection *ac = NULL;
 	char *sc_reader_id = NULL;
 	int i, ch, deleting = 0, ret = 0;
Index: ssh-agent.c
===================================================================
RCS file: /cvs/openssh_cvs/ssh-agent.c,v
retrieving revision 1.122
diff -p -u -r1.122 ssh-agent.c
--- ssh-agent.c	21 Aug 2003 23:34:41 -0000	1.122
+++ ssh-agent.c	10 Sep 2003 18:59:01 -0000
@@ -1013,8 +1013,10 @@ main(int ac, char **av)
 #ifdef HAVE_CYGWIN
 	int prev_mask;
 #endif
+#ifndef HAVE_GETOPT_H
 	extern int optind;
 	extern char *optarg;
+#endif
 	pid_t pid;
 	char pidstrbuf[1 + 3 * sizeof pid];
 
Index: ssh-keygen.c
===================================================================
RCS file: /cvs/openssh_cvs/ssh-keygen.c,v
retrieving revision 1.111
diff -p -u -r1.111 ssh-keygen.c
--- ssh-keygen.c	8 Sep 2003 23:11:33 -0000	1.111
+++ ssh-keygen.c	10 Sep 2003 18:59:01 -0000
@@ -806,8 +806,10 @@ main(int ac, char **av)
 	BIGNUM *start = NULL;
 	FILE *f;
 
+#ifndef HAVE_GETOPT_H
 	extern int optind;
 	extern char *optarg;
+#endif
 
 	__progname = ssh_get_progname(av[0]);
 
Index: ssh-keyscan.c
===================================================================
RCS file: /cvs/openssh_cvs/ssh-keyscan.c,v
retrieving revision 1.56
diff -p -u -r1.56 ssh-keyscan.c
--- ssh-keyscan.c	21 Aug 2003 23:34:41 -0000	1.56
+++ ssh-keyscan.c	10 Sep 2003 18:59:01 -0000
@@ -694,8 +694,10 @@ main(int argc, char **argv)
 	int opt, fopt_count = 0;
 	char *tname;
 
+#ifndef HAVE_GETOPT_H
 	extern int optind;
 	extern char *optarg;
+#endif
 
 	__progname = ssh_get_progname(argv[0]);
 	init_rng();
Index: ssh-rand-helper.c
===================================================================
RCS file: /cvs/openssh_cvs/ssh-rand-helper.c,v
retrieving revision 1.13
diff -p -u -r1.13 ssh-rand-helper.c
--- ssh-rand-helper.c	21 Aug 2003 23:34:41 -0000	1.13
+++ ssh-rand-helper.c	10 Sep 2003 18:59:01 -0000
@@ -766,7 +766,9 @@ main(int argc, char **argv)
 {
 	unsigned char *buf;
 	int ret, ch, debug_level, output_hex, bytes;
+#ifndef HAVE_GETOPT_H
 	extern char *optarg;
+#endif
 	LogLevel ll;
 
 	__progname = ssh_get_progname(argv[0]);
Index: ssh.c
===================================================================
RCS file: /cvs/openssh_cvs/ssh.c,v
retrieving revision 1.181
diff -p -u -r1.181 ssh.c
--- ssh.c	2 Sep 2003 12:58:22 -0000	1.181
+++ ssh.c	10 Sep 2003 18:59:02 -0000
@@ -208,8 +208,10 @@ main(int ac, char **av)
 	struct stat st;
 	struct passwd *pw;
 	int dummy;
+#ifndef HAVE_GETOPT_H
 	extern int optind, optreset;
 	extern char *optarg;
+#endif
 
 	__progname = ssh_get_progname(av[0]);
 	init_rng();
Index: sshd.c
===================================================================
RCS file: /cvs/openssh_cvs/sshd.c,v
retrieving revision 1.260
diff -p -u -r1.260 sshd.c
--- sshd.c	2 Sep 2003 12:51:17 -0000	1.260
+++ sshd.c	10 Sep 2003 18:59:02 -0000
@@ -797,8 +797,10 @@ usage(void)
 int
 main(int ac, char **av)
 {
+#ifndef HAVE_GETOPT_H
 	extern char *optarg;
 	extern int optind;
+#endif
 	int opt, sock_in = 0, sock_out = 0, newsock, j, i, fdsetsz, on = 1;
 	pid_t pid;
 	socklen_t fromlen;

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From tamaster at spamblocked.earthlink.net  Thu Sep 11 05:24:21 2003
From: tamaster at spamblocked.earthlink.net (Greg Houlette)
Date: Wed, 10 Sep 2003 14:24:21 -0500
Subject: Combining Transparent Proxying with SSH Port Forwarding
Message-ID: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>

I've wondered if this topic has been discussed relative to enhancing
the current capabilities of OpenSSH.  Please forgive me if I don't
use the exact terminology that you may be used to in describing SSH
or Transparent Proxy operation.  I continue to learn.  Always...

Here's what I mean:

1) Port forwarding through SSH is generally a configuration that is
   "port selective".  What I mean by that is there is a port selection
   process via the localhost mapping of the SSH daemon on the local
   server and the SSH client on the remote system (the ports need NOT
   be the same) and a "shared" localhost mapping of the SSH client and
   any configured client programs on the remote system (the ports MUST
   be the same).  The remote client programs must be configured to use
   the "shared" localhost mapping of tunneled ports.  Once configured,
   the selected port traffic of these client programs is then forwarded
   through the SSH tunnel 'by proxy'.

2) Transparent proxying (as I understand it) eliminates the requirement
   to formally configure client programs (some of which may be server
   daemons) to explicitly send their traffic to a proxy service (local
   or remote).  This is accomplished through a mechanism of redirection
   of traffic (the specificity of which is under considerable control).
   By making this redirection effectively invisible and under specific
   control, the COMPATABILITY of the application of the proxying of
   traffic of the client programs (some of which may be server daemons)
   is considerably increased.  It can also allows enabling and disabling
   of the proxying on a process by process basis (specificity) on such
   criteria as performance impact and security requirements.

3) Combining Transparent Proxying with Port Forwarding using the SSH
   protocol would entail the addition of traffic redirection capability
   first to the SSH client, but additionally to the SSH server daemon.
   The tunneling selection criteria would then no longer be bound just
   to "port selection" (which any client program can access via the
   localhost mapping) as is currently defined.  Additionally, using the
   transparent proxying to perform protocol conversion would allow for
   the tunneling of other IP traffic such as UDP to be performed.  And
   it should be possible, if the capability for supporting multiple
   SSH sessions were build into the transparent proxy for the SSH
   client, to do more advanced and dynamic redirection of tunneled
   traffic such as load balancing, process by process tunnel mapping,
   and redundant reliability improvements via failover switching of
   tunnels.

I've believed for some time that the SSH capability could be enhanced
considerably by combining it with other traffic control capabilities.

Not a simple undertaking though...

GregH

All direct responses should use the following e-mail address rather
than the one in the from: header (which will get you NOWHERE).


-------------------------------------------------------------------------
Greg Houlette <tamaster at pobox dot com>    *  Give me the graphical UI
Do you know who owns your network today?     *  that will "condense fact
GPG 1.2.2 Public Keys available upon request *  from the vapor of nuance"




From dan at doxpara.com  Thu Sep 11 06:28:46 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 10 Sep 2003 13:28:46 -0700
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
References: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
Message-ID: <3F5F897E.2030904@doxpara.com>

Greg--

    OpenSSH has supported Dynamic Forwarding (using SOCKS to direct a 
port forward) for several years now; see the -D option.  OpenSSH 3.7 
will support SOCKS5; builds back through 2.9 support SOCKS4.   SOCKS was 
selected because it provided a well-supported, OS independent method of 
providing external control over port selection.  Sadly, good socksifiers 
are relatively unstable and rare, which is surprising given the utter 
simplicity of the protocol.

    There are intrinsic problems with running UDP payloads inside of a 
TCP stream.  We'd also need a new SSH payload type, and I don't expect 
to see that happen without a very good reason.  Provide a list of 
circumstances where UDP forwarding would be extremely useful...this 
might help.

--Dan


Greg Houlette wrote:

>I've wondered if this topic has been discussed relative to enhancing
>the current capabilities of OpenSSH.  Please forgive me if I don't
>use the exact terminology that you may be used to in describing SSH
>or Transparent Proxy operation.  I continue to learn.  Always...
>
>Here's what I mean:
>
>1) Port forwarding through SSH is generally a configuration that is
>   "port selective".  What I mean by that is there is a port selection
>   process via the localhost mapping of the SSH daemon on the local
>   server and the SSH client on the remote system (the ports need NOT
>   be the same) and a "shared" localhost mapping of the SSH client and
>   any configured client programs on the remote system (the ports MUST
>   be the same).  The remote client programs must be configured to use
>   the "shared" localhost mapping of tunneled ports.  Once configured,
>   the selected port traffic of these client programs is then forwarded
>   through the SSH tunnel 'by proxy'.
>
>2) Transparent proxying (as I understand it) eliminates the requirement
>   to formally configure client programs (some of which may be server
>   daemons) to explicitly send their traffic to a proxy service (local
>   or remote).  This is accomplished through a mechanism of redirection
>   of traffic (the specificity of which is under considerable control).
>   By making this redirection effectively invisible and under specific
>   control, the COMPATABILITY of the application of the proxying of
>   traffic of the client programs (some of which may be server daemons)
>   is considerably increased.  It can also allows enabling and disabling
>   of the proxying on a process by process basis (specificity) on such
>   criteria as performance impact and security requirements.
>
>3) Combining Transparent Proxying with Port Forwarding using the SSH
>   protocol would entail the addition of traffic redirection capability
>   first to the SSH client, but additionally to the SSH server daemon.
>   The tunneling selection criteria would then no longer be bound just
>   to "port selection" (which any client program can access via the
>   localhost mapping) as is currently defined.  Additionally, using the
>   transparent proxying to perform protocol conversion would allow for
>   the tunneling of other IP traffic such as UDP to be performed.  And
>   it should be possible, if the capability for supporting multiple
>   SSH sessions were build into the transparent proxy for the SSH
>   client, to do more advanced and dynamic redirection of tunneled
>   traffic such as load balancing, process by process tunnel mapping,
>   and redundant reliability improvements via failover switching of
>   tunnels.
>
>I've believed for some time that the SSH capability could be enhanced
>considerably by combining it with other traffic control capabilities.
>
>Not a simple undertaking though...
>
>GregH
>
>All direct responses should use the following e-mail address rather
>than the one in the from: header (which will get you NOWHERE).
>
>
>-------------------------------------------------------------------------
>Greg Houlette <tamaster at pobox dot com>    *  Give me the graphical UI
>Do you know who owns your network today?     *  that will "condense fact
>GPG 1.2.2 Public Keys available upon request *  from the vapor of nuance"
>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>




From mouring at etoh.eviladmin.org  Thu Sep 11 06:32:10 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 10 Sep 2003 15:32:10 -0500 (CDT)
Subject: [PATCH] No extern declarations of optarg & co if getopt.h is
 available
In-Reply-To: <20030910185947.GI9981@cygbert.vinschen.de>
Message-ID: <Pine.BSO.4.44.0309101526190.29487-100000@etoh.eviladmin.org>



On Wed, 10 Sep 2003, Corinna Vinschen wrote:

> Hi,
>
> I have a problem with the extern declarations of optarg, optind, etc.
>
> We're currently moving getopt from being a statically linked function
> to a dynamically linked function as part of the Cygwin DLL.  On Windows,
> this requires to generate special symbols (__imp__optarg, etc.), which
> is done by marking the exported variables in the corresponding header.
> Instead of
>
>   extern char *optarg;
>
> getopt.h now contains
>
>   extern char __declspec(dllimport) *optarg;
>
> I'm sorry, but that's not my invention.
>
> Now the problem.  ssh.c, sshd.c and a lot of other files do explicitely
> declare the opt* variables at the beginning of main(), even when a
> getopt.h file is available.  The problem with this is, that this
> explicit extern declaration overrides the declaration from getopt.h.
> So instead of linking against the correct __imp__optarg symbol, the
> linker tries to linked against the normal _optarg.
>
> This could be easily circumvented by either not declaring the variables
> at all in these main() funcs, or by surrounding the declarations with
>
>   #ifndef HAVE_GETOPT_H
>       extern char *optarg;
>       ...
>   #endif

No, I don't think that is right, and in fact it will break older
platforms.

I think your linker/compiler is doing it wrong.  My understand of the C
defintions of 'extern' is it requires that the variable pre-exist (either
fleshed out in headers or in an assocated *.c file or library).

'extern' should never define it's own variable space.

- Ben



From vinschen at redhat.com  Thu Sep 11 07:10:07 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 10 Sep 2003 23:10:07 +0200
Subject: [PATCH] No extern declarations of optarg & co if getopt.h is
	available
In-Reply-To: <Pine.BSO.4.44.0309101526190.29487-100000@etoh.eviladmin.org>
References: <20030910185947.GI9981@cygbert.vinschen.de>
	<Pine.BSO.4.44.0309101526190.29487-100000@etoh.eviladmin.org>
Message-ID: <20030910211007.GL9981@cygbert.vinschen.de>

On Wed, Sep 10, 2003 at 03:32:10PM -0500, Ben Lindstrom wrote:
> On Wed, 10 Sep 2003, Corinna Vinschen wrote:
> 
> > Hi,
> >
> > I have a problem with the extern declarations of optarg, optind, etc.
> >
> > We're currently moving getopt from being a statically linked function
> > to a dynamically linked function as part of the Cygwin DLL.  On Windows,
> > this requires to generate special symbols (__imp__optarg, etc.), which
> > is done by marking the exported variables in the corresponding header.
> > Instead of
> >
> >   extern char *optarg;
> >
> > getopt.h now contains
> >
> >   extern char __declspec(dllimport) *optarg;
> >
> > I'm sorry, but that's not my invention.
> >
> > Now the problem.  ssh.c, sshd.c and a lot of other files do explicitely
> > declare the opt* variables at the beginning of main(), even when a
> > getopt.h file is available.  The problem with this is, that this
> > explicit extern declaration overrides the declaration from getopt.h.
> > So instead of linking against the correct __imp__optarg symbol, the
> > linker tries to linked against the normal _optarg.
> >
> > This could be easily circumvented by either not declaring the variables
> > at all in these main() funcs, or by surrounding the declarations with
> >
> >   #ifndef HAVE_GETOPT_H
> >       extern char *optarg;
> >       ...
> >   #endif
> 
> No, I don't think that is right, and in fact it will break older
> platforms.
> 
> I think your linker/compiler is doing it wrong.  My understand of the C

It's not *my* compiler, it's gcc.  And it's not wrong but it's the way
dynamic imorting/exporting works on Windows platforms.  What I don't get
is why extern declarations are duplicated here.  Either they exist in
getopt.h or they should be declared explicitely in the source but not both. 
So I think my patch is correct.  The other way is to substitute the

  #ifndef HAVE_GETOPT_H

by

  #ifndef HAVE_CYGWIN

if you like this better.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From dtucker at zip.com.au  Thu Sep 11 10:40:59 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Sep 2003 10:40:59 +1000
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
References: <809D3CD3C504D711A7810008C709B597368494@jamesx.jms.lucascargo.com>
Message-ID: <3F5FC49B.3FDAF265@zip.com.au>

"STEWARD, Curtis (Jamestown)" wrote:
> FYI, I tried a 2nd machine (this time with VMWare and 8.0)
> had the same results.  The 2nd machine had identical gcc,
> ssl, zlib, etc.  Here's the debug.  From what I could figure
> out I could get the error on both buffer_init()
> and buffer_get().  xmalloc()?

The error you posted earlier shows the error coming from buffer_get.

[snip]

> # gdb -q ./sshd
> (gdb) set args -t
> (gdb) break buffer.c:124
> Breakpoint 1 at 0x8068896: file buffer.c, line 124.
> (gdb) break buffer.c:125
> Breakpoint 2 at 0x806886f: file buffer.c, line 125.
> (gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x08068896 in buffer_get at buffer.c:124
> 2   breakpoint     keep y   0x0806886f in buffer_get at buffer.c:125
> (gdb) run
> Starting program: /root/gz/openssh/sshd -t
> 
> Breakpoint 1, buffer_get (buffer=0xbffff1f0, buf=0x0, len=1) at buffer.c:124
> 124                     fatal("buffer_get: trying to get more bytes %d than
> in buffer %d",
> (gdb) c

The bit I wanted to see is the stack trace at this point.  Could you plese
repeat this test, but do "bt" here instead of continuing?

> Continuing.
> buffer_get: trying to get more bytes 1 than in buffer 0


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



From djm at mindrot.org  Thu Sep 11 12:25:09 2003
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Sep 2003 12:25:09 +1000
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
References: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
Message-ID: <3F5FDD05.1080107@mindrot.org>

Greg Houlette wrote:
> I've wondered if this topic has been discussed relative to enhancing
> the current capabilities of OpenSSH.  Please forgive me if I don't
> use the exact terminology that you may be used to in describing SSH
> or Transparent Proxy operation.  I continue to learn.  Always...

There are patches around to use OpenSSH dynamic portforwarding as a 
transparent gateway under OpenBSD pf's NAT. I don't know whether we want 
to support and maintain variants for every OS's favourite packet filter 
in the tree though...

-d







From mouring at etoh.eviladmin.org  Thu Sep 11 12:25:21 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 10 Sep 2003 21:25:21 -0500 (CDT)
Subject: [PATCH] No extern declarations of optarg & co if getopt.h is
 available
In-Reply-To: <20030910211007.GL9981@cygbert.vinschen.de>
Message-ID: <Pine.BSO.4.44.0309102122110.29487-100000@etoh.eviladmin.org>



On Wed, 10 Sep 2003, Corinna Vinschen wrote:

> On Wed, Sep 10, 2003 at 03:32:10PM -0500, Ben Lindstrom wrote:
> > On Wed, 10 Sep 2003, Corinna Vinschen wrote:
> >
> > > Hi,
> > >
> > > I have a problem with the extern declarations of optarg, optind, etc.
> > >
> > > We're currently moving getopt from being a statically linked function
> > > to a dynamically linked function as part of the Cygwin DLL.  On Windows,
> > > this requires to generate special symbols (__imp__optarg, etc.), which
> > > is done by marking the exported variables in the corresponding header.
> > > Instead of
> > >
> > >   extern char *optarg;
> > >
> > > getopt.h now contains
> > >
> > >   extern char __declspec(dllimport) *optarg;
> > >
> > > I'm sorry, but that's not my invention.
> > >
> > > Now the problem.  ssh.c, sshd.c and a lot of other files do explicitely
> > > declare the opt* variables at the beginning of main(), even when a
> > > getopt.h file is available.  The problem with this is, that this
> > > explicit extern declaration overrides the declaration from getopt.h.
> > > So instead of linking against the correct __imp__optarg symbol, the
> > > linker tries to linked against the normal _optarg.
> > >
> > > This could be easily circumvented by either not declaring the variables
> > > at all in these main() funcs, or by surrounding the declarations with
> > >
> > >   #ifndef HAVE_GETOPT_H
> > >       extern char *optarg;
> > >       ...
> > >   #endif
> >
> > No, I don't think that is right, and in fact it will break older
> > platforms.
> >
> > I think your linker/compiler is doing it wrong.  My understand of the C
>
> It's not *my* compiler, it's gcc.  And it's not wrong but it's the way
> dynamic imorting/exporting works on Windows platforms.  What I don't get
> is why extern declarations are duplicated here.  Either they exist in
> getopt.h or they should be declared explicitely in the source but not both.
> So I think my patch is correct.  The other way is to substitute the

Track someone down with a native Windows C compiler and setup a proof
test.  Never seen any native compiler have problems with this.  Otherwise
one of my old favorite BBSes (WWIV 4.x) would have been horrible broken
and I know folks that ran WWIV + Multi-line Mods on Windows boxes for the
longest time.

I suspect you have deeper issues with your GNU LD port.

- Ben



From djm at mindrot.org  Thu Sep 11 12:27:22 2003
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Sep 2003 12:27:22 +1000
Subject: [PATCH] No extern declarations of optarg & co if getopt.h is
 available
In-Reply-To: <20030910185947.GI9981@cygbert.vinschen.de>
References: <20030910185947.GI9981@cygbert.vinschen.de>
Message-ID: <3F5FDD8A.9070608@mindrot.org>

Corinna Vinschen wrote:

> This could be easily circumvented by either not declaring the variables
> at all in these main() funcs, or by surrounding the declarations with
> 
>   #ifndef HAVE_GETOPT_H
>       extern char *optarg;
>       ...
>   #endif

We would also need to test whether GETOPT_H declared the variables we 
want. E.g. an AC_TRY_COMPILE test in configure, then

#ifndef GETOPT_H_DECL
...

-d



From dan at doxpara.com  Thu Sep 11 13:26:26 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 10 Sep 2003 20:26:26 -0700
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <3F5FDD05.1080107@mindrot.org>
References: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
	<3F5FDD05.1080107@mindrot.org>
Message-ID: <3F5FEB62.6070208@doxpara.com>


> There are patches around to use OpenSSH dynamic portforwarding as a 
> transparent gateway under OpenBSD pf's NAT. I don't know whether we 
> want to support and maintain variants for every OS's favourite packet 
> filter in the tree though...

We should encourage good, implementation-independent SOCKSifiers for the 
various OS's, but that's the extent I see it being appropriate to dive 
into kernelspace.

I wouldn't mind a patch to automatically reconnect a SSH session that's 
failing keepalives, though.

--Dan




From dan at doxpara.com  Thu Sep 11 13:37:40 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 10 Sep 2003 20:37:40 -0700
Subject: Blocking spamblocked.earthlink.net
Message-ID: <3F5FEE04.7070105@doxpara.com>

For those who don't know, Greg Houlette sent in a request from an 
address that doesn't conveniently accept replies.

If people can't be bothered to read our replies, we shouldn't be 
bothered by their requests.

Just a note.  Maybe a request for a killfile.

--Dan




From djm at mindrot.org  Thu Sep 11 13:38:10 2003
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Sep 2003 13:38:10 +1000
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <3F5FEB62.6070208@doxpara.com>
References: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
	<3F5FDD05.1080107@mindrot.org> <3F5FEB62.6070208@doxpara.com>
Message-ID: <3F5FEE22.2020509@mindrot.org>

Dan Kaminsky wrote:
> 
>> There are patches around to use OpenSSH dynamic portforwarding as a 
>> transparent gateway under OpenBSD pf's NAT. I don't know whether we 
>> want to support and maintain variants for every OS's favourite packet 
>> filter in the tree though...
> 
> We should encourage good, implementation-independent SOCKSifiers for the 
> various OS's, but that's the extent I see it being appropriate to dive 
> into kernelspace.

That may be a better idea - instead of N different transparent NAT -> 
Dynamic portforward implementations living in OpenSSH, do N standalone 
transparent NAT -> SOCKS gateway daemons. We could keep complexity out 
of OpenSSH and the daemons would have independant utility.

> I wouldn't mind a patch to automatically reconnect a SSH session that's 
> failing keepalives, though.

How to retain session state?

-d



From dtucker at zip.com.au  Thu Sep 11 13:50:00 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Sep 2003 13:50:00 +1000
Subject: Combining Transparent Proxying with SSH Port Forwarding
References: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
	<3F5FDD05.1080107@mindrot.org> <3F5FEB62.6070208@doxpara.com>
Message-ID: <3F5FF0E8.47911161@zip.com.au>

Dan Kaminsky wrote:
> We should encourage good, implementation-independent SOCKSifiers for the
> various OS's, but that's the extent I see it being appropriate to dive
> into kernelspace.

If people are looking for something like that, there's Dante, which is a
Free ("BSD/CMU-type license") SOCKS 4/5 implementation that has a dynamic
(LD_PRELOAD-style) "socksify" program.

That won't help on platforms that don't support LD_PRELOAD. (eg some
AIXes, but AIX has had built-in SOCKS support since at least 4.3.2).

> I wouldn't mind a patch to automatically reconnect a SSH session that's
> failing keepalives, though.

Have you looked at autossh [1]?

[0] http://www.inet.no/dante/
[1] http://www.harding.motd.ca/autossh/

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



From GILBERT.R.LOOMIS at saic.com  Thu Sep 11 14:08:34 2003
From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip)
Date: Thu, 11 Sep 2003 00:08:34 -0400
Subject: Blocking spamblocked.earthlink.net
Message-ID: <4E25ECBBC03F874CBAD03399254ADFDE104CEA@US-Columbia-CIST.mail.saic.com>

Dan Kaminsky wrote:
> For those who don't know, Greg Houlette sent in a request from an 
> address that doesn't conveniently accept replies.

> If people can't be bothered to read our replies, we shouldn't be 
> bothered by their requests.

> Just a note.  Maybe a request for a killfile.

Hmm.  I've got Earthlink at home, so I have some experience with
their spam-blocking system.  If one turns it on in the "normal" mode
then it's *very* easy to accidentally add an address to the blocklist
and I've done it three+ times myself to senders who I didn't intend
to block.  If one cranks it up a notch to the "block anyone not in
one's address book" mode, then it's even more of an overkill (unless
someone really is religious in adding all possible correspondents to
Earthlink's online address book as opposed to the address book that
one maintains in one's MUA).  In other words, the fact that you can't
send e-mail directly to Greg H. could be operator error on the other
end rather than malevolence--even smart people make dumb mistakes
occasionally (or so the smart people tell me...)

Be that as it may, isn't the list archived?  And although it's been
a point of netiquette disagreement since at least 1988, what's the
big deal with just posting replies back to the list?

Methinks, Dan, that there are more important things about which to
get fired up [0].

  --Rip

[0]  Try as I might, I couldn't end that sentence without a dangling
     participle.  Grammar fascists please form a line to the left...



From dan at doxpara.com  Thu Sep 11 14:42:05 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 10 Sep 2003 21:42:05 -0700
Subject: Blocking spamblocked.earthlink.net
In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104CEA@US-Columbia-CIST.mail.saic.com>
References: <4E25ECBBC03F874CBAD03399254ADFDE104CEA@US-Columbia-CIST.mail.saic.com>
Message-ID: <3F5FFD1D.1070908@doxpara.com>

>
>
>Methinks, Dan, that there are more important things about which to
>get fired up [0].
>
I hit Reply All, and answer Greg's question.

Immediate bounce:  The mailing address is invalid; I need to strip the 
spamblocked.  OK.

I send mail to the correct address.  Now it's a whitelister.  I need to 
click a link.  OK.

I'm directed to a page:  Apparently, Greg _may_ be willing to receive my 
message, if I provide 1) A Reason and 2) A string of characters.  WTF?

He came to us.  The anti-spam gateway should be smart enough to note at 
least the matching _subject_ lines.  It's not.  I'm aware that mailing 
lists and spam look quite similar -- but if he wants to come here for a 
service, it would behoove him not to make me go through three hoops to 
be kind.

My point is, at some point what he's providing diverges so far from what 
an email address is that it might as well be president at whitehouse.gov. 
 At least that address is preferable, as it does not bounce.

As for posting replies to the list, given the amount of discussion 
recently on the topic of Dynamic Forwarding (really, I must sound like a 
broken record, or at best a one trick pony to the rest of you!  I'm so 
sorry!) it was pretty clear he wasn't a subscriber.

--Dan




From dtucker at zip.com.au  Thu Sep 11 14:44:06 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Sep 2003 14:44:06 +1000
Subject: [PATCH] No extern declarations of optarg & co if getopt.h 
 isavailable
References: <20030910185947.GI9981@cygbert.vinschen.de>
	<3F5FDD8A.9070608@mindrot.org>
Message-ID: <3F5FFD96.8F460B3D@zip.com.au>

Damien Miller wrote:
> Corinna Vinschen wrote:
> > This could be easily circumvented by either not declaring the variables
> > at all in these main() funcs, or by surrounding the declarations with
> >
> >   #ifndef HAVE_GETOPT_H
> >       extern char *optarg;
> >       ...
> >   #endif
> 
> We would also need to test whether GETOPT_H declared the variables we
> want. E.g. an AC_TRY_COMPILE test in configure, then

How about the attached patch?  It banishes the extern declarations to the
system headers (if appropriate) or defines.h.  It even compiles (on Redhat
8).

Those declarations can probably be deleted from OpenBSD too, when
convenient.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: configure.ac
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v
retrieving revision 1.149
diff -u -p -r1.149 configure.ac
--- configure.ac	10 Sep 2003 05:22:45 -0000	1.149
+++ configure.ac	11 Sep 2003 04:08:16 -0000
@@ -689,6 +689,9 @@ AC_CHECK_DECL(tcsendbreak,
 	[#include <termios.h>]
 )
 
+AC_CHECK_DECLS(optarg, , ,[#include <getopt.h>])
+AC_CHECK_DECLS(optind, , ,[#include <getopt.h>])
+
 dnl IRIX and Solaris 2.5.1 have dirname() in libgen
 AC_CHECK_FUNCS(dirname, [AC_CHECK_HEADERS(libgen.h)] ,[
 	AC_CHECK_LIB(gen, dirname,[
Index: defines.h
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/defines.h,v
retrieving revision 1.102
diff -u -p -r1.102 defines.h
--- defines.h	26 Aug 2003 01:58:16 -0000	1.102
+++ defines.h	11 Sep 2003 04:05:41 -0000
@@ -596,6 +596,13 @@ struct winsize {
 #  define USE_LASTLOG
 #endif
 
+#ifndef HAVE_DECL_OPTARG
+extern char *optarg;
+#endif
+#ifndef HAVE_DECL_OPTIND
+extern int optind;
+#endif
+
 /** end of login recorder definitions */
 
 #endif /* _DEFINES_H */
Index: scp.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/scp.c,v
retrieving revision 1.118
diff -u -p -r1.118 scp.c
--- scp.c	21 Aug 2003 23:34:41 -0000	1.118
+++ scp.c	11 Sep 2003 04:02:35 -0000
@@ -219,8 +219,6 @@ main(int argc, char **argv)
 	int ch, fflag, tflag, status;
 	double speed;
 	char *targ, *endp;
-	extern char *optarg;
-	extern int optind;
 
 	__progname = ssh_get_progname(argv[0]);
 
Index: sftp.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sftp.c,v
retrieving revision 1.38
diff -u -p -r1.38 sftp.c
--- sftp.c	21 Aug 2003 23:34:41 -0000	1.38
+++ sftp.c	11 Sep 2003 04:02:35 -0000
@@ -129,8 +129,6 @@ main(int argc, char **argv)
 	char *ssh_program = _PATH_SSH_PROGRAM, *sftp_direct = NULL;
 	LogLevel ll = SYSLOG_LEVEL_INFO;
 	arglist args;
-	extern int optind;
-	extern char *optarg;
 
 	__progname = ssh_get_progname(argv[0]);
 	args.list = NULL;
Index: ssh-add.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-add.c,v
retrieving revision 1.74
diff -u -p -r1.74 ssh-add.c
--- ssh-add.c	21 Aug 2003 23:34:41 -0000	1.74
+++ ssh-add.c	11 Sep 2003 04:02:35 -0000
@@ -313,8 +313,6 @@ usage(void)
 int
 main(int argc, char **argv)
 {
-	extern char *optarg;
-	extern int optind;
 	AuthenticationConnection *ac = NULL;
 	char *sc_reader_id = NULL;
 	int i, ch, deleting = 0, ret = 0;
Index: ssh-agent.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-agent.c,v
retrieving revision 1.122
diff -u -p -r1.122 ssh-agent.c
--- ssh-agent.c	21 Aug 2003 23:34:41 -0000	1.122
+++ ssh-agent.c	11 Sep 2003 04:03:03 -0000
@@ -1013,8 +1013,6 @@ main(int ac, char **av)
 #ifdef HAVE_CYGWIN
 	int prev_mask;
 #endif
-	extern int optind;
-	extern char *optarg;
 	pid_t pid;
 	char pidstrbuf[1 + 3 * sizeof pid];
 
Index: ssh-keygen.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-keygen.c,v
retrieving revision 1.111
diff -u -p -r1.111 ssh-keygen.c
--- ssh-keygen.c	8 Sep 2003 23:11:33 -0000	1.111
+++ ssh-keygen.c	11 Sep 2003 04:03:15 -0000
@@ -806,9 +806,6 @@ main(int ac, char **av)
 	BIGNUM *start = NULL;
 	FILE *f;
 
-	extern int optind;
-	extern char *optarg;
-
 	__progname = ssh_get_progname(av[0]);
 
 	SSLeay_add_all_algorithms();
Index: ssh-keyscan.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-keyscan.c,v
retrieving revision 1.56
diff -u -p -r1.56 ssh-keyscan.c
--- ssh-keyscan.c	21 Aug 2003 23:34:41 -0000	1.56
+++ ssh-keyscan.c	11 Sep 2003 04:03:29 -0000
@@ -694,9 +694,6 @@ main(int argc, char **argv)
 	int opt, fopt_count = 0;
 	char *tname;
 
-	extern int optind;
-	extern char *optarg;
-
 	__progname = ssh_get_progname(argv[0]);
 	init_rng();
 	seed_rng();
Index: ssh-rand-helper.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-rand-helper.c,v
retrieving revision 1.13
diff -u -p -r1.13 ssh-rand-helper.c
--- ssh-rand-helper.c	21 Aug 2003 23:34:41 -0000	1.13
+++ ssh-rand-helper.c	11 Sep 2003 04:03:56 -0000
@@ -766,7 +766,6 @@ main(int argc, char **argv)
 {
 	unsigned char *buf;
 	int ret, ch, debug_level, output_hex, bytes;
-	extern char *optarg;
 	LogLevel ll;
 
 	__progname = ssh_get_progname(argv[0]);
Index: ssh.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh.c,v
retrieving revision 1.181
diff -u -p -r1.181 ssh.c
--- ssh.c	2 Sep 2003 12:58:22 -0000	1.181
+++ ssh.c	11 Sep 2003 04:02:44 -0000
@@ -208,8 +208,6 @@ main(int ac, char **av)
 	struct stat st;
 	struct passwd *pw;
 	int dummy;
-	extern int optind, optreset;
-	extern char *optarg;
 
 	__progname = ssh_get_progname(av[0]);
 	init_rng();
Index: sshd.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v
retrieving revision 1.260
diff -u -p -r1.260 sshd.c
--- sshd.c	2 Sep 2003 12:51:17 -0000	1.260
+++ sshd.c	11 Sep 2003 04:02:44 -0000
@@ -797,8 +797,6 @@ usage(void)
 int
 main(int ac, char **av)
 {
-	extern char *optarg;
-	extern int optind;
 	int opt, sock_in = 0, sock_out = 0, newsock, j, i, fdsetsz, on = 1;
 	pid_t pid;
 	socklen_t fromlen;
Index: openbsd-compat/openbsd-compat.h
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openbsd-compat.h,v
retrieving revision 1.24
diff -u -p -r1.24 openbsd-compat.h
--- openbsd-compat/openbsd-compat.h	29 Aug 2003 16:59:52 -0000	1.24
+++ openbsd-compat/openbsd-compat.h	11 Sep 2003 04:31:10 -0000
@@ -120,6 +120,9 @@ int getgrouplist(const char *, gid_t, gi
 
 #if !defined(HAVE_GETOPT) || !defined(HAVE_GETOPT_OPTRESET)
 int BSDgetopt(int argc, char * const *argv, const char *opts);
+extern char *BSDoptarg;
+extern int BSDoptind;
+extern int BSDoptreset;
 #endif
 
 

From vinschen at redhat.com  Thu Sep 11 17:27:52 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 11 Sep 2003 09:27:52 +0200
Subject: [PATCH] No extern declarations of optarg & co if getopt.h
	isavailable
In-Reply-To: <3F5FFD96.8F460B3D@zip.com.au>
References: <20030910185947.GI9981@cygbert.vinschen.de>
	<3F5FDD8A.9070608@mindrot.org> <3F5FFD96.8F460B3D@zip.com.au>
Message-ID: <20030911072752.GA32358@cygbert.vinschen.de>

On Thu, Sep 11, 2003 at 02:44:06PM +1000, Darren Tucker wrote:
> Damien Miller wrote:
> > Corinna Vinschen wrote:
> > > This could be easily circumvented by either not declaring the variables
> > > at all in these main() funcs, or by surrounding the declarations with
> > >
> > >   #ifndef HAVE_GETOPT_H
> > >       extern char *optarg;
> > >       ...
> > >   #endif

Please don't take that serious.  I had an apparently bad day yesterday
and took warnings of the linker as errors.  Actually the applications
do link ok, the linker throws just a warning like this:

  Info: resolving _optarg by linking to __imp__optarg (auto-import)

However, Darren's patch is IMHO cleaner than the unconditional extern
declarations and it works fine on Cygwin.


Sorry again for the uprising,
Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From Ulrich.Windl at rz.uni-regensburg.de  Thu Sep 11 17:50:46 2003
From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl)
Date: Thu, 11 Sep 2003 09:50:46 +0200
Subject: connecting to a virtual host: host key mismatch
Message-ID: <3F604577.27202.69ECA5@localhost>

Hello,

I have a kind of problem: I need to connect to a virtual host (a f "floating" 
IP address) that is one of two physical hosts in a HA environment. Yesterday 
the virtual IP address was moved to another host.

Today ssh refuses to connect, because the host key is different. Reading the 
documentation I found that there is no command line option (documented) to 
temporarily bypass "StrictHostKeyChecking", and it seems to be impossible to 
specify multiple alternative hostkeys for a virtual host in "knows_hosts" (it 
would make sense however IMHO).

Using the same host keys for both machines is not what I would like to do 
(assuming it would help), and I don't want to disable "StrictHostKeyChecking" 
globally.

So what's the (or a good) solution?

Regards,
Ulrich
P.S. openssh-3.5p1



From dtucker at zip.com.au  Thu Sep 11 18:36:04 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Sep 2003 18:36:04 +1000
Subject: connecting to a virtual host: host key mismatch
References: <3F604577.27202.69ECA5@localhost>
Message-ID: <3F6033F4.D51FD206@zip.com.au>

Ulrich Windl wrote:
> I have a kind of problem: I need to connect to a virtual host (a f "floating"
> IP address) that is one of two physical hosts in a HA environment. Yesterday
> the virtual IP address was moved to another host.
> 
> Today ssh refuses to connect, because the host key is different. Reading the
> documentation I found that there is no command line option (documented) to
> temporarily bypass "StrictHostKeyChecking", and it seems to be impossible to
> specify multiple alternative hostkeys for a virtual host in "knows_hosts" (it
> would make sense however IMHO).

ssh -o StrictHostKeyChecking=no clusterhost ?

> Using the same host keys for both machines is not what I would like to do
> (assuming it would help), and I don't want to disable "StrictHostKeyChecking"
> globally.

In ssh_config or $HOME/.ssh/config:
Host clusterhost
	StrictHostKeyChecking no

> So what's the (or a good) solution?

Generate a set of keys for each node, plus a set for each floating
address.  Have each node run its own sshd listening on its main IP address
with its "node" keys, and the machine with the production address run
another sshd on it with the "floating" keys.  Note that this means you
have to migrate the production sshd along with the rest of your production
services.

I'd probably just use the same keys for all the machines in the cluster. 
The keys are to prevent a MITM attack, and since all of the machines in
the cluster are presumably under the same administrative control, I don't
think separate keys buy you much.

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



From dtucker at zip.com.au  Thu Sep 11 18:41:17 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Sep 2003 18:41:17 +1000
Subject: [PATCH] No extern declarations of optarg & co if
	getopt.hisavailable
References: <20030910185947.GI9981@cygbert.vinschen.de>
	<3F5FDD8A.9070608@mindrot.org> <3F5FFD96.8F460B3D@zip.com.au>
	<20030911072752.GA32358@cygbert.vinschen.de>
Message-ID: <3F60352D.A62EB489@zip.com.au>

Corinna Vinschen wrote:
> Please don't take that serious.  I had an apparently bad day yesterday
> and took warnings of the linker as errors.  Actually the applications
> do link ok, the linker throws just a warning like this:

OK then, if it's non-fatal I think we should wait until after the 3.7
release before doing anything regarding this.

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



From wpilorz at bdk.pl  Thu Sep 11 19:23:02 2003
From: wpilorz at bdk.pl (Wojtek Pilorz)
Date: Thu, 11 Sep 2003 11:23:02 +0200 (CEST)
Subject: connecting to a virtual host: host key mismatch
In-Reply-To: <3F604577.27202.69ECA5@localhost>
Message-ID: <Pine.LNX.4.44.0309111120420.15945-100000@celebris.bdk.pl>

On Thu, 11 Sep 2003, Ulrich Windl wrote:

[...]
> Today ssh refuses to connect, because the host key is different. Reading the 
> documentation I found that there is no command line option (documented) to 

Have you tried -o "StrictHostKeyChecking ask" ?
(or no instead of ask, if you prefer)

Actually -o option have been documented since quite a long time ago.

> temporarily bypass "StrictHostKeyChecking", and it seems to be impossible to 
> specify multiple alternative hostkeys for a virtual host in "knows_hosts" (it 
> would make sense however IMHO).
> 
> Using the same host keys for both machines is not what I would like to do 
> (assuming it would help), and I don't want to disable "StrictHostKeyChecking" 
> globally.
> 
> So what's the (or a good) solution?
> 
> Regards,
> Ulrich
> P.S. openssh-3.5p1
Best regards,

Wojtek



From Ulrich.Windl at rz.uni-regensburg.de  Thu Sep 11 19:02:01 2003
From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl)
Date: Thu, 11 Sep 2003 11:02:01 +0200
Subject: connecting to a virtual host: host key mismatch
In-Reply-To: <3F6033F4.D51FD206@zip.com.au>
Message-ID: <3F60562B.28197.AB299D@localhost>

On 11 Sep 2003 at 18:36, Darren Tucker wrote:

> Ulrich Windl wrote:
> > I have a kind of problem: I need to connect to a virtual host (a f "floating"
> > IP address) that is one of two physical hosts in a HA environment. Yesterday
> > the virtual IP address was moved to another host.
> > 
> > Today ssh refuses to connect, because the host key is different. Reading the
> > documentation I found that there is no command line option (documented) to
> > temporarily bypass "StrictHostKeyChecking", and it seems to be impossible to
> > specify multiple alternative hostkeys for a virtual host in "knows_hosts" (it
> > would make sense however IMHO).
> 
> ssh -o StrictHostKeyChecking=no clusterhost ?

Yes, I found that out myself in the meantime. Thanks anyway.

> 
> > Using the same host keys for both machines is not what I would like to do
> > (assuming it would help), and I don't want to disable "StrictHostKeyChecking"
> > globally.
> 
> In ssh_config or $HOME/.ssh/config:
> Host clusterhost
> 	StrictHostKeyChecking no
> 
> > So what's the (or a good) solution?
> 
> Generate a set of keys for each node, plus a set for each floating
> address.  Have each node run its own sshd listening on its main IP address
> with its "node" keys, and the machine with the production address run
> another sshd on it with the "floating" keys.  Note that this means you
> have to migrate the production sshd along with the rest of your production
> services.

A clever suggestion. I have something similar for Samba already.

> 
> I'd probably just use the same keys for all the machines in the cluster. 
> The keys are to prevent a MITM attack, and since all of the machines in
> the cluster are presumably under the same administrative control, I don't
> think separate keys buy you much.


Also true. So I conclude that SSH will not complain if different hosts use 
the same key.

Thanks a lot!
Regards,
Ulrich



From Curtis.Steward at goodrich.com  Thu Sep 11 23:00:22 2003
From: Curtis.Steward at goodrich.com (STEWARD, Curtis (Jamestown))
Date: Thu, 11 Sep 2003 09:00:22 -0400
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
Message-ID: <809D3CD3C504D711A7810008C709B597368496@jamesx.jms.lucascargo.com>

I'm new to some of this so bear with me, I did post a 
buffer_get() error but while debugging I could make it fail
on buffer_init() 31, weird.  Here's the bt without 
the continue:

gdb -q ./sshd
(gdb) set args -t
(gdb) break buffer.c:124
Breakpoint 1 at 0x8068896: file buffer.c, line 124.
(gdb) run
Starting program: /root/gz/openssh/sshd -t

Breakpoint 1, buffer_get (buffer=0xbffff210, buf=0x0, len=1) at buffer.c:124
124                     fatal("buffer_get: trying to get more bytes %d than
in buffer %d",
(gdb) bt
#0  buffer_get (buffer=0xbffff210, buf=0x0, len=1) at buffer.c:124
#1  0x00000000 in ?? ()
(gdb)

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Wednesday, September 10, 2003 7:41 PM
To: STEWARD, Curtis (Jamestown)
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: 3.6p2 build errors on buffer_get with latest portable/SNAP


"STEWARD, Curtis (Jamestown)" wrote:
> FYI, I tried a 2nd machine (this time with VMWare and 8.0)
> had the same results.  The 2nd machine had identical gcc,
> ssl, zlib, etc.  Here's the debug.  From what I could figure
> out I could get the error on both buffer_init()
> and buffer_get().  xmalloc()?

The error you posted earlier shows the error coming from buffer_get.

[snip]

> # gdb -q ./sshd
> (gdb) set args -t
> (gdb) break buffer.c:124
> Breakpoint 1 at 0x8068896: file buffer.c, line 124.
> (gdb) break buffer.c:125
> Breakpoint 2 at 0x806886f: file buffer.c, line 125.
> (gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x08068896 in buffer_get at buffer.c:124
> 2   breakpoint     keep y   0x0806886f in buffer_get at buffer.c:125
> (gdb) run
> Starting program: /root/gz/openssh/sshd -t
> 
> Breakpoint 1, buffer_get (buffer=0xbffff1f0, buf=0x0, len=1) at
buffer.c:124
> 124                     fatal("buffer_get: trying to get more bytes %d
than
> in buffer %d",
> (gdb) c

The bit I wanted to see is the stack trace at this point.  Could you plese
repeat this test, but do "bt" here instead of continuing?

> Continuing.
> buffer_get: trying to get more bytes 1 than in buffer 0


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



From djm at mindrot.org  Thu Sep 11 23:23:20 2003
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Sep 2003 13:23:20 -0000
Subject: connecting to a virtual host: host key mismatch
In-Reply-To: <3F60562B.28197.AB299D@localhost>
References: <3F60562B.28197.AB299D@localhost>
Message-ID: <1063286436.8866.21.camel@sakura.mindrot.org>

On Thu, 2003-09-11 at 19:02, Ulrich Windl wrote:
>  
> > I'd probably just use the same keys for all the machines in the cluster. 
> > The keys are to prevent a MITM attack, and since all of the machines in
> > the cluster are presumably under the same administrative control, I don't
> > think separate keys buy you much.
> 
> 
> Also true. So I conclude that SSH will not complain if different hosts use 
> the same key.

It won't mind, but it will initially prompt you for each ip
address/hostname that you connect to.

-d




From markus at openbsd.org  Fri Sep 12 02:03:50 2003
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 11 Sep 2003 18:03:50 +0200
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <3F5FEE22.2020509@mindrot.org>
References: <5.2.1.1.2.20030910135056.009f1080@pop.earthlink.net>
	<3F5FDD05.1080107@mindrot.org> <3F5FEB62.6070208@doxpara.com>
	<3F5FEE22.2020509@mindrot.org>
Message-ID: <20030911160349.GB25554@folly>

On Thu, Sep 11, 2003 at 01:38:10PM +1000, Damien Miller wrote:
> >We should encourage good, implementation-independent SOCKSifiers for the 
> >various OS's, but that's the extent I see it being appropriate to dive 
> >into kernelspace.
> 
> That may be a better idea - instead of N different transparent NAT -> 
> Dynamic portforward implementations living in OpenSSH, do N standalone 
> transparent NAT -> SOCKS gateway daemons. We could keep complexity out 
> of OpenSSH and the daemons would have independant utility.

i'm using something similar. kjell suggested adding the NAT->SOCKS
code to netcat.



From gene.salasih at ginster.de  Fri Sep 12 11:45:15 2003
From: gene.salasih at ginster.de (Gene Salas)
Date: Fri, 12 Sep 2003 01:45:15 +0000
Subject: Your fri end said t his
Message-ID: <91cc01c378cf$189fee1d$83d02d22@fk1acf2>



From dtucker at zip.com.au  Fri Sep 12 12:31:01 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 12 Sep 2003 12:31:01 +1000
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
References: <809D3CD3C504D711A7810008C709B597368496@jamesx.jms.lucascargo.com>
Message-ID: <3F612FE5.98565985@zip.com.au>

"STEWARD, Curtis (Jamestown)" wrote:
> I'm new to some of this so bear with me, I did post a
> buffer_get() error but while debugging I could make it fail
> on buffer_init() 31, weird.  Here's the bt without
> the continue:

> (gdb) bt
> #0  buffer_get (buffer=0xbffff210, buf=0x0, len=1) at buffer.c:124
> #1  0x00000000 in ?? ()

Hmm, there should be more here, I don't know what there isn't.

Plan B: if you insert an abort(); immediately before the fatal at
buffer.c:124 then run it normally, you should get a core dump which you
can generate the backtrace from.  It should look something like this:

# ./sshd -t
[core dumps]
# gdb -q ./sshd core
Core was generated by `./sshd -t'.
[snip]
#0  0x4020bfd1 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x4020bfd1 in kill () from /lib/libc.so.6
#1  0x4020bc94 in raise () from /lib/libc.so.6
#2  0x4020d04d in abort () from /lib/libc.so.6
#3  0x08062bd7 in buffer_get () at ../buffer.c:123
#4  0x08062a1c in buffer_get_char (buffer=0xbfffd4f0) at ../bufaux.c:262
#5  0x08061ac5 in key_load_public_rsa1 (fd=3,
    filename=0x8079e80 "/usr/local/etc/ssh_host_rsa_key", commentp=0x0)
    at ../authfile.c:268
#6  0x080622f3 in key_load_private (
    filename=0x8079e80 "/usr/local/etc/ssh_host_rsa_key",
    passphrase=0x8078c1a "", commentp=0x0) at ../authfile.c:573
#7  0x0804d8ae in main (ac=2, av=0x8092f68) at ../sshd.c:978
#8  0x401fa4ed in __libc_start_main () from /lib/libc.so.6

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



From alberta.maloneot at pobox.sk  Fri Sep 12 11:57:09 2003
From: alberta.maloneot at pobox.sk (Alberta Malone)
Date: Fri, 12 Sep 2003 01:57:09 +0000
Subject: never be embarrassed again     o    vw7rq430
Message-ID: <495f01c378d1$80201f68$3cfa7ba0@zbdqsb2>


            Genital Enlargement - Medical Breakthrough For Men!
           2 amazing ways to enlarge your manhood - read below..

   Doctors worked for years creating a pill to enlarge the male genitalia
   by length and width.
   The years of work produced a pill called "VPRX", - [1]VPRX Pills info
   click here.
   and also a patch similair to the quit smoking patch. - [2]Penis
   Patches info click here.

   [3]delete yourself from our database.

References

   1. http://www.naturalherbal.biz/info/v/
   2. http://www.naturalherbal.biz/info/p/
   3. http://www.naturalherbal.biz/info/out.html


From tamaster at spamblocked.earthlink.net  Fri Sep 12 15:04:33 2003
From: tamaster at spamblocked.earthlink.net (Greg Houlette)
Date: Fri, 12 Sep 2003 00:04:33 -0500
Subject: Combining Transparent Proxying with SSH Port Forwarding
Message-ID: <5.2.1.1.2.20030911085152.009f8b40@pop.earthlink.net>

Thanks for the feedback.  I still have a few questions of course...

The Dynamic Forwarding that is currently in OpenSSH (-D option)
which uses the SOCKS protocol, still requires an application-level
'socksifier' to provide transparency on the client side, but lacks
other features of a traditional transparent proxy (such as NAT)?

I haven't seen or used any of the patches that Damien mentioned, and
I can understand why, for the sake of utility, it would be preferable
to keep this kind of feature as a seperate connector module.

I just don't have a feel for how much bloat a transparent NAT -> SSH
proxy capability would add, but I suspect that once in place it might
get to be pretty sizable as more advanced features were added.

The idea of a standalone transparent NAT -> SOCKS gateway daemon
is something that I haven't seen, let alone with the other features
that I mentioned in my post.  That does seem like a good starting
point though.  And I like the independent utility aspect of it.

I wish Markus would elaborate about what he's using?

GregH

    ||||||||        ||||||||        ||||||||       ||||||||
    vvvvvvvv        vvvvvvvv        vvvvvvvv       vvvvvvvv
All direct responses should use the following e-mail address rather
than the one in the from: header (which will get you NOWHERE).



-------------------------------------------------------------------------
Greg Houlette <tamaster at pobox dot com>    *  Give me the graphical UI
Do you know who owns your network today?     *  that will "condense fact
GPG 1.2.2 Public Keys available upon request *  from the vapor of nuance"




From tamaster at spamblocked.earthlink.net  Fri Sep 12 14:57:16 2003
From: tamaster at spamblocked.earthlink.net (Greg Houlette)
Date: Thu, 11 Sep 2003 23:57:16 -0500
Subject: Blocking spamblocked.earthlink.net
Message-ID: <5.2.1.1.2.20030911231315.009f3ec0@pop.earthlink.net>

What Dan neglects to tell you is that at the end of my initial post
(and this one too) are instructions for avoiding this whole annoyance.
No Dan, I'm really not trying to make ANYONE jump through hoops for me.

I've had to resort to triple-spam-filtering my e-mail to get the
Hormel out (first at pobox.com, second at earthlink.net and finally
with Spamnix on my workstation).  And spam still gets thru!
(I've just got to try that new Bayesian filtering after the beta)

I've had three pobox 'lifetime' aliases for about 8 years and have
learned: spammers *_WILL_* go to just about any length to harvest
your address; posting without obscuring to just about *_ANY_* list
leaves you susceptible; even the very best, well managed lists can
be harvested by a smart-bot.

I apologize to everyone on this list for even having to respond to
this.  I read the archive.  After I'm done with my insignificant and
useless questions regarding Transparent Proxying and SSH, you will
probably not see me here again...   until I have another question...

Back to your normal programming...  Nothing to see here... you know
the rest...

Dan Kaminsky <dan () doxpara ! com> wrote:
>>
>>
>>Methinks, Dan, that there are more important things about which to
>>get fired up [0].
>>
>I hit Reply All, and answer Greg's question.
>
>Immediate bounce:  The mailing address is invalid; I need to strip the 
>spamblocked.  OK.
>
>I send mail to the correct address.  Now it's a whitelister.  I need to 
>click a link.  OK.
>
>I'm directed to a page:  Apparently, Greg _may_ be willing to receive my 
>message, if I provide 1) A Reason and 2) A string of characters.  WTF?
>
>He came to us.  The anti-spam gateway should be smart enough to note at 
>least the matching _subject_ lines.  It's not.  I'm aware that mailing 
>lists and spam look quite similar -- but if he wants to come here for a 
>service, it would behoove him not to make me go through three hoops to 
>be kind.
>
>My point is, at some point what he's providing diverges so far from what 
>an email address is that it might as well be president at whitehouse.gov. 
> At least that address is preferable, as it does not bounce.
>
>As for posting replies to the list, given the amount of discussion 
>recently on the topic of Dynamic Forwarding (really, I must sound like a 
>broken record, or at best a one trick pony to the rest of you!  I'm so 
>sorry!) it was pretty clear he wasn't a subscriber.
>
>--Dan

Dan, I can say RTFM too [read the friggin' message]
Don't like it...   Just killfile me O.K?

All direct responses should use the following e-mail address rather
than the one in the from: header (which will get you NOWHERE).


-------------------------------------------------------------------------
Greg Houlette <tamaster at pobox dot com>    *  Give me the graphical UI
Do you know who owns your network today?     *  that will "condense fact
GPG 1.2.2 Public Keys available upon request *  from the vapor of nuance"




From eric-list-openssh at catastrophe.net  Fri Sep 12 15:51:36 2003
From: eric-list-openssh at catastrophe.net (Eric)
Date: Fri, 12 Sep 2003 00:51:36 -0500
Subject: Agent Forwarding Anomalies on OpenBSD 3.3/OpenSSH 3.6.1
Message-ID: <20030912005136.N86384@catastrophe.net>

I have a curious situation with four OpenBSD 3.3 hosts.
Each of these has public/private keys on each other for inter-host
authentication using RSA2 keys. 

For instance, they're called hostA-to-hostBCD, hostB-to-hostACD,
hostC-to-hostABD, and hostD-to-hostABC.

The sshd_config files, on each host, look as follows...

  #;
  #; /etc/ssh/sshd_config
  #;
  Port 22
  Protocol 2
  ListenAddress 0.0.0.0
  HostKey /etc/ssh/ssh_host_key
  HostKey /etc/ssh/ssh_host_rsa_key
  HostKey /etc/ssh/ssh_host_dsa_key
  SyslogFacility AUTH
  LogLevel INFO
  LoginGraceTime 30
  PermitRootLogin no
  StrictModes yes
  RSAAuthentication yes
  PubkeyAuthentication yes
  AuthorizedKeysFile      .ssh/authorized_keys
  IgnoreRhosts yes
  RhostsRSAAuthentication no
  HostbasedAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no
  ChallengeResponseAuthentication yes
  X11Forwarding no
  X11DisplayOffset 10
  X11UseLocalhost yes
  PrintMotd yes
  PrintLastLog yes
  KeepAlive yes
  UseLogin no
  UsePrivilegeSeparation yes
  PermitUserEnvironment no
  Compression yes
  MaxStartups 24
  Banner /etc/issue.net
  Subsystem       sftp    /usr/libexec/sftp-server

HostA allows ssh from the world to hosts B, C and D -- which have
SSH filtered. HostA also has ssh-agent running on it; and allows
me to login to B,C,D w/o problems, so long as the agent is
unlocked. This looks like...

Now, the tricky part....if I log into HostB, from HostA (which has
ssh-agent running, unlocked), I can log into HostC and HostD w/o a
password. HostA's public key is on all the other machines...I
would expect to be able to login to the other hosts directly from
HostA, but not using HostB as a stepping stone w/o require
authenticating with HostB's key, when logging into HostC or HostD.

A verbose output shows the following... I've marked the strange
part with "^^^"'s.

debug1: identity file /home/eric/.ssh/keys/hostB-to-hostACD type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1
debug1: match: OpenSSH_3.6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1
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: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: using hostkeyalias: HostC
debug1: Host 'mars' is known and matches the RSA host key.
debug1: Found key in /home/eric/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering agent key: /home/eric/.ssh/keys/prv/HostA-to-HostBCD
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug1: Server accepts key: pkalg ssh-rsa blen 277 lastkey 0x4c0a0 hint -1
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: Requesting authentication agent forwarding.
debug1: channel 0: request auth-agent-req at openssh.com
debug1: channel 0: request shell

Why is hostB forwarding hostA's keys to HostC? This also works
logging into HostD too.

Note that with the exact same configuration, going from HostA to
HostC to HostD (instead of using HostB) does not work. Nor does
going from HostA to HostD to HostC, etc..

Someone hit me with a cluestick please! This is making me crazy.

Thanks.

- Eric



From markus at openbsd.org  Fri Sep 12 19:05:15 2003
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 12 Sep 2003 11:05:15 +0200
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <5.2.1.1.2.20030911085152.009f8b40@pop.earthlink.net>
References: <5.2.1.1.2.20030911085152.009f8b40@pop.earthlink.net>
Message-ID: <20030912090514.GA1191@folly>

On Fri, Sep 12, 2003 at 12:04:33AM -0500, Greg Houlette wrote:
> The Dynamic Forwarding that is currently in OpenSSH (-D option)
> which uses the SOCKS protocol, still requires an application-level
> 'socksifier' to provide transparency on the client side, but lacks
> other features of a traditional transparent proxy (such as NAT)?

using the attached patch you can redirect
traffic to the -D port.  using OpenBSD's NAT
this wold look like:

   rdr on eth0 inet proto tcp from any to 10/8 -> 127.0.0.1 port 8080

> I haven't seen or used any of the patches that Damien mentioned, and

see below.

> [...]
> The idea of a standalone transparent NAT -> SOCKS gateway daemon
> is something that I haven't seen, let alone with the other features
> that I mentioned in my post.  That does seem like a good starting
> point though.  And I like the independent utility aspect of it.
> 
> I wish Markus would elaborate about what he's using?

a process listens to a port, the kernel NAT rules redirect traffic
to this port, process does NAT lookup and connects to ssh's -D port
after converting the NAT state to a SOCKS4 request.

Index: channels.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.194
diff -u -r1.194 channels.c
--- channels.c	29 Aug 2003 10:04:36 -0000	1.194
+++ channels.c	11 Sep 2003 15:59:59 -0000
@@ -41,6 +41,10 @@
 #include "includes.h"
 RCSID("$OpenBSD: channels.c,v 1.194 2003/08/29 10:04:36 markus Exp $");
 
+#include <netinet/in.h>
+#include <net/if.h>
+#include <net/pfvar.h>
+
 #include "ssh.h"
 #include "ssh1.h"
 #include "ssh2.h"
@@ -870,6 +874,73 @@
 	}
 }
 
+static int
+natlookup(int fd, struct sockaddr_in *server)
+{
+	struct pfioc_natlook natlook;
+	struct sockaddr_in from, to;
+	socklen_t slen;
+	int pfd;
+
+	slen = sizeof(from);
+	if (getpeername(fd, (struct sockaddr *)&from, &slen) != 0) {
+		debug("getpeername failed: %s", strerror(errno));
+		return (-1);
+	}
+	slen = sizeof(to);
+	if (getsockname(fd, (struct sockaddr *)&to, &slen) != 0) {
+		debug("getsockname failed: %s", strerror(errno));
+		return (-1);
+	}
+
+	memset(&natlook, 0, sizeof(natlook));
+	natlook.af = AF_INET;
+	natlook.saddr.addr32[0] = from.sin_addr.s_addr;
+	natlook.daddr.addr32[0] = to.sin_addr.s_addr;
+	natlook.proto = IPPROTO_TCP;
+	natlook.sport = from.sin_port;
+	natlook.dport = to.sin_port;
+	natlook.direction = PF_OUT;
+
+	if ((pfd = open("/dev/pf", O_RDWR)) == -1) {
+		debug("open /dev/pf failed: %s", strerror(errno));
+		return (-1);
+	}
+	if (ioctl(pfd, DIOCNATLOOK, &natlook) == -1) {
+		error("pf nat lookup failed: %s", strerror(errno));
+		close(pfd);
+		return (-1);
+	}
+	close(pfd);
+
+	server->sin_port = natlook.rdport;
+	server->sin_addr.s_addr = natlook.rdaddr.addr32[0];
+	server->sin_len = sizeof(struct sockaddr_in);
+	server->sin_family = AF_INET;
+	return (0);
+}
+
+static int
+channel_try_nat(Channel *c)
+{
+	char *host;
+	struct sockaddr_in server;
+
+	memset(&server, 0, sizeof(server));
+
+	if (natlookup(c->rfd, &server) < 0)
+		return (0);
+
+	host = inet_ntoa(server.sin_addr);
+	strlcpy(c->path, host, sizeof(c->path));
+	c->host_port = ntohs(server.sin_port);
+
+	debug("channel %d: nat request: host %s port %u",
+	    c->self, host, c->host_port);
+
+	return (1);
+}
+
 /* try to decode a socks4 header */
 static int
 channel_decode_socks4(Channel *c, fd_set * readset, fd_set * writeset)
@@ -1060,6 +1131,10 @@
 
 	have = buffer_len(&c->input);
 	c->delayed = 0;
+
+	if ((ret = channel_try_nat(c)))
+		goto done;
+
 	debug2("channel %d: pre_dynamic: have %d", c->self, have);
 	/* buffer_dump(&c->input); */
 	/* check if the fixed size part of the packet is in buffer. */
@@ -1081,6 +1156,8 @@
 		ret = -1;
 		break;
 	}
+
+done:
 	if (ret < 0) {
 		chan_mark_dead(c);
 	} else if (ret == 0) {
@@ -1168,6 +1245,8 @@
 	    "connect from %.200s port %d",
 	    rtype, c->listening_port, c->path, c->host_port,
 	    remote_ipaddr, remote_port);
+
+debug("%s", buf);
 
 	xfree(c->remote_name);
 	c->remote_name = xstrdup(buf);



From dtucker at zip.com.au  Fri Sep 12 21:12:48 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 12 Sep 2003 21:12:48 +1000
Subject: Possible new configure option: --with-fatal-coredumps?
Message-ID: <3F61AA30.35960457@zip.com.au>

Hi all.
	What's the feeling about adding a new configure-time option to generate a
core dump on when fatal() is called?

	It might help debug certain types of problems, but runs the risk of
sensitive information being left in the core dump.  Obviously, it should
default to "no".

	Anyone like the idea?  Anyone hate it?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: acconfig.h
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/acconfig.h,v
retrieving revision 1.165
diff -u -p -r1.165 acconfig.h
--- acconfig.h	8 Sep 2003 21:35:17 -0000	1.165
+++ acconfig.h	12 Sep 2003 10:05:51 -0000
@@ -421,6 +421,9 @@
 /* Define if HEADER.ad exists in arpa/nameser.h */
 #undef HAVE_HEADER_AD
 
+/* Enable core dumps on fatal errors */
+#undef WITH_FATAL_COREDUMPS
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line ************** */
Index: configure.ac
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v
retrieving revision 1.150
diff -u -p -r1.150 configure.ac
--- configure.ac	11 Sep 2003 04:42:56 -0000	1.150
+++ configure.ac	12 Sep 2003 10:27:24 -0000
@@ -2398,6 +2398,14 @@ AC_ARG_WITH(lastlog,
 		fi
 	]
 )
+AC_ARG_WITH(fatal-coredumps,
+    [  --with-fatal-coredumps  Create core dumps on fatal errors [no]],
+	[
+		if test "x$withval" = "xyes" ; then	
+			AC_DEFINE(WITH_FATAL_COREDUMPS)
+		fi
+	]
+)
 
 dnl lastlog, [uw]tmpx? detection
 dnl  NOTE: set the paths in the platform section to avoid the
Index: fatal.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/fatal.c,v
retrieving revision 1.1
diff -u -p -r1.1 fatal.c
--- fatal.c	26 Feb 2002 19:24:22 -0000	1.1
+++ fatal.c	12 Sep 2003 09:54:15 -0000
@@ -36,5 +36,8 @@ fatal(const char *fmt,...)
 	va_start(args, fmt);
 	do_log(SYSLOG_LEVEL_FATAL, fmt, args);
 	va_end(args);
+#ifdef WITH_FATAL_COREDUMPS
+	abort();
+#endif
 	fatal_cleanup();
 }

From eau at phear.org  Fri Sep 12 21:17:18 2003
From: eau at phear.org (Eric AUGE)
Date: Fri, 12 Sep 2003 13:17:18 +0200
Subject: openssh ldap public key patch
Message-ID: <20030912111718.GA22194@phear.org>

Hello All,

New version of the openssh ldap public key patch
is available at :

http://ldappubkey.gcu-squad.org/

Changes :

Full RSA1/RSA/DSA options+key supports
LDAP based group management
Multiple keys per user
Bugfixes + Partial patch rewrite

Hope it helps,

Best Regards,

Eric.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030912/352dbec0/attachment.bin 

From markus at openbsd.org  Fri Sep 12 21:40:49 2003
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 12 Sep 2003 13:40:49 +0200
Subject: Possible new configure option: --with-fatal-coredumps?
In-Reply-To: <3F61AA30.35960457@zip.com.au>
References: <3F61AA30.35960457@zip.com.au>
Message-ID: <20030912114049.GA11575@folly>

On Fri, Sep 12, 2003 at 09:12:48PM +1000, Darren Tucker wrote:
> Hi all.
> 	What's the feeling about adding a new configure-time option to generate a
> core dump on when fatal() is called?
> 
> 	It might help debug certain types of problems, but runs the risk of
> sensitive information being left in the core dump.  Obviously, it should
> default to "no".
> 
> 	Anyone like the idea?  Anyone hate it?

i like the idea, but it should also try to enable compile with
-g or something similar.



From dtucker at zip.com.au  Fri Sep 12 21:55:21 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 12 Sep 2003 21:55:21 +1000
Subject: Possible new configure option: --with-fatal-coredumps?
References: <3F61AA30.35960457@zip.com.au> <20030912114049.GA11575@folly>
Message-ID: <3F61B429.1129DB51@zip.com.au>

Markus Friedl wrote:
>
> On Fri, Sep 12, 2003 at 09:12:48PM +1000, Darren Tucker wrote:
> >       Anyone like the idea?  Anyone hate it?
> 
> i like the idea, but it should also try to enable compile with
> -g or something similar.

Configure already adds -g to CFLAGS by default.

Some compilers don't like -g with -O, though.  I'm not sure how it deals
with that.

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



From mouring at etoh.eviladmin.org  Fri Sep 12 23:28:46 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 12 Sep 2003 08:28:46 -0500 (CDT)
Subject: Agent Forwarding Anomalies on OpenBSD 3.3/OpenSSH 3.6.1
In-Reply-To: <20030912005136.N86384@catastrophe.net>
Message-ID: <Pine.BSO.4.44.0309120825010.29487-100000@etoh.eviladmin.org>



On Fri, 12 Sep 2003, Eric wrote:

> I have a curious situation with four OpenBSD 3.3 hosts.
> Each of these has public/private keys on each other for inter-host
> authentication using RSA2 keys.
>
> For instance, they're called hostA-to-hostBCD, hostB-to-hostACD,
> hostC-to-hostABD, and hostD-to-hostABC.
>
> The sshd_config files, on each host, look as follows...
>
[..]

In this case your global ssh_config and personal ssh_config would be
more interesting.

>
> HostA allows ssh from the world to hosts B, C and D -- which have
> SSH filtered. HostA also has ssh-agent running on it; and allows
> me to login to B,C,D w/o problems, so long as the agent is
> unlocked. This looks like...
>
> Now, the tricky part....if I log into HostB, from HostA (which has
> ssh-agent running, unlocked), I can log into HostC and HostD w/o a
> password. HostA's public key is on all the other machines...I
> would expect to be able to login to the other hosts directly from
> HostA, but not using HostB as a stepping stone w/o require
> authenticating with HostB's key, when logging into HostC or HostD.
>

This is called Agent forwarding.

man ssh_config
[..]
     ForwardAgent
             Specifies whether the connection to the authentication agent (if
             any) will be forwarded to the remote machine.  The argument must
             be ``yes'' or ``no''. The default is ``no''.

             Agent forwarding should be enabled with caution.  Users with the
             ability to bypass file permissions on the remote host (for the
             agent's Unix-domain socket) can access the local agent through
             the forwarded connection.  An attacker cannot obtain key material
             from the agent, however they can perform operations on the keys
             that enable them to authenticate using the identities loaded into
             the agent.

[..]
> debug1: channel 0: request pty-req
> debug1: Requesting authentication agent forwarding.
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> debug1: channel 0: request auth-agent-req at openssh.com
[..]

- Ben



From eric-list-openssh at catastrophe.net  Sat Sep 13 02:17:30 2003
From: eric-list-openssh at catastrophe.net (Eric)
Date: Fri, 12 Sep 2003 11:17:30 -0500
Subject: Agent Forwarding Anomalies on OpenBSD 3.3/OpenSSH 3.6.1
In-Reply-To: <Pine.BSO.4.44.0309120825010.29487-100000@etoh.eviladmin.org>;
	from mouring@etoh.eviladmin.org on Fri, Sep 12, 2003 at
	08:28:46AM -0500
References: <20030912005136.N86384@catastrophe.net>
	<Pine.BSO.4.44.0309120825010.29487-100000@etoh.eviladmin.org>
Message-ID: <20030912111730.R86384@catastrophe.net>

On Fri, 2003-09-12 at 08:28:46 -0500, Ben Lindstrom proclaimed...

> In this case your global ssh_config and personal ssh_config would be
> more interesting.

Ok, I forgot to send that along. Basically, it's the same on all
hosts...

  Host *
  Cipher 3des
  ForwardAgent yes
  ForwardX11 yes
  KeepAlive yes
  NumberOfPasswordPrompts 3
  UsePrivilegedPort no
  Protocol 2,1
  
  #; HostA
  Host hostA
  HostName 10.6.6.6
  HostKeyAlias hostA
  StrictHostKeyChecking yes
  IdentityFile ~/.ssh/keys/hostA
  
  #; HostB
  Host hostB
  HostName 10.6.6.7
  HostKeyAlias hostB
  StrictHostKeyChecking yes
  IdentityFile ~/.ssh/keys/hostB

  [etc..]

> This is called Agent forwarding.
> 
> man ssh_config
> [..]
>      ForwardAgent
>              Specifies whether the connection to the authentication agent (if
>              any) will be forwarded to the remote machine.  The argument must
>              be ``yes'' or ``no''. The default is ``no''.
> 
>              Agent forwarding should be enabled with caution.  Users with the
>              ability to bypass file permissions on the remote host (for the
>              agent's Unix-domain socket) can access the local agent through
>              the forwarded connection.  An attacker cannot obtain key material
>              from the agent, however they can perform operations on the keys
>              that enable them to authenticate using the identities loaded into
>              the agent.
> 
> [..]
> > debug1: channel 0: request pty-req
> > debug1: Requesting authentication agent forwarding.
> 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > debug1: channel 0: request auth-agent-req at openssh.com
> [..]

Yes, but do you have any idea why it would work on one host and
not the others?



From tim at multitalents.net  Sat Sep 13 02:25:05 2003
From: tim at multitalents.net (Tim Rice)
Date: Fri, 12 Sep 2003 09:25:05 -0700 (PDT)
Subject: Possible new configure option: --with-fatal-coredumps?
In-Reply-To: <3F61B429.1129DB51@zip.com.au>
References: <3F61AA30.35960457@zip.com.au> <20030912114049.GA11575@folly>
	<3F61B429.1129DB51@zip.com.au>
Message-ID: <Pine.UW2.4.53.0309120918560.2360@ou8.int.multitalents.net>

On Fri, 12 Sep 2003, Darren Tucker wrote:

> Markus Friedl wrote:
> >
> > On Fri, Sep 12, 2003 at 09:12:48PM +1000, Darren Tucker wrote:
> > >       Anyone like the idea?  Anyone hate it?
> > 
> > i like the idea, but it should also try to enable compile with
> > -g or something similar.
> 
> Configure already adds -g to CFLAGS by default.
> 
> Some compilers don't like -g with -O, though.  I'm not sure how it deals
> with that.

I have some of those. It's just a warning and -O is disabled.

> 
> 

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




From Darren.Moffat at Sun.COM  Sat Sep 13 04:01:41 2003
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Fri, 12 Sep 2003 11:01:41 -0700 (PDT)
Subject: Possible new configure option: --with-fatal-coredumps?
In-Reply-To: <3F61AA30.35960457@zip.com.au>
Message-ID: <Pine.GSO.4.44.0309121100430.907-100000@localhost>

On Fri, 12 Sep 2003, Darren Tucker wrote:

> Hi all.
> 	What's the feeling about adding a new configure-time option to generate a
> core dump on when fatal() is called?

Are all calls to fatal() considered "this shouldn't happen" cases ?  I'm
sure I've seen cases where fatal() is called that are "normal operation"
but it is time to drop the connection, eg an auth failure.

--
Darren J Moffat



From Darren.Moffat at Sun.COM  Sat Sep 13 04:06:23 2003
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Fri, 12 Sep 2003 11:06:23 -0700 (PDT)
Subject: openssh ldap public key patch
In-Reply-To: <20030912111718.GA22194@phear.org>
Message-ID: <Pine.GSO.4.44.0309121102510.907-100000@localhost>

On Fri, 12 Sep 2003, Eric AUGE wrote:

> New version of the openssh ldap public key patch
> is available at :
>
> http://ldappubkey.gcu-squad.org/

Where is the IETF Internet Draft for this ?

Are you really releasing patches to a BSD licensed program under GPL ? Your
diffs don't contain a license but your README starts with the GPL.

--
Darren J Moffat



From eau at phear.org  Sat Sep 13 07:35:17 2003
From: eau at phear.org (Eric AUGE)
Date: Fri, 12 Sep 2003 23:35:17 +0200
Subject: openssh ldap public key patch
In-Reply-To: <Pine.GSO.4.44.0309121102510.907-100000@localhost>
References: <20030912111718.GA22194@phear.org>
	<Pine.GSO.4.44.0309121102510.907-100000@localhost>
Message-ID: <20030912213517.GA2676@phear.org>

On Fri, Sep 12, 2003 at 11:06:23AM -0700, Darren J Moffat wrote:
> On Fri, 12 Sep 2003, Eric AUGE wrote:
> 
> > New version of the openssh ldap public key patch
> > is available at :
> >
> > http://ldappubkey.gcu-squad.org/
> 
> Where is the IETF Internet Draft for this ?

afaik there is only a draft regarding the way x509 certificates
are stored in the LDAP directory. 
(PKIX : http://www.ietf.org/html.charters/pkix-charter.html)

I haven't seen any draft related on the way the public keys 
should be retrieved or matched, may be i missed something, did i ?.

> Are you really releasing patches to a BSD licensed program under GPL ? Your
> diffs don't contain a license but your README starts with the GPL.

it is under BSD license, i made a mistake in the README file,
which is now fixed, thanks noticing it :).

Hope it helps,
Best Regards,

Eric.

> --
> Darren J Moffat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030912/27d22817/attachment.bin 

From dtucker at zip.com.au  Sat Sep 13 09:04:28 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 13 Sep 2003 09:04:28 +1000
Subject: Possible new configure option: --with-fatal-coredumps?
References: <Pine.GSO.4.44.0309121100430.907-100000@localhost>
Message-ID: <3F6250FC.F15F779E@zip.com.au>

Darren J Moffat wrote:
> 
> On Fri, 12 Sep 2003, Darren Tucker wrote:
> >       What's the feeling about adding a new configure-time option to generate a
> > core dump on when fatal() is called?
> 
> Are all calls to fatal() considered "this shouldn't happen" cases ?  I'm
> sure I've seen cases where fatal() is called that are "normal operation"
> but it is time to drop the connection, eg an auth failure.

A quick grep shows that most, but not all, calls to fatal() are "shouldn't
happen" cases.

Counterexamples:
auth2.c:	fatal("Access denied for user %s.",authctxt->user);
readconf.c:	fatal("%s line %d: missing time value.",
readconf.c:	fatal("%s: terminating, %d bad configuration options",
sshconnect1.c:  fatal("Permission denied.");

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



From tim at multitalents.net  Sat Sep 13 11:20:37 2003
From: tim at multitalents.net (Tim Rice)
Date: Fri, 12 Sep 2003 18:20:37 -0700 (PDT)
Subject: 3.6p1 bug on SCO OpenServer
In-Reply-To: <200309051650.h85Gol726140@tenzing.org>
References: <200309051650.h85Gol726140@tenzing.org>
Message-ID: <Pine.UW2.4.53.0309121819100.15553@ou8.int.multitalents.net>

On Fri, 5 Sep 2003, Roger Cornelius wrote:

> SCO OpenServer 5.0.x
> Openssh 3.6p1
> 
> loginrec.c writes incorrect data into the ut_id field of the utmp file.
> This has been an issue since at least openssh 3.0.2 but I never bothered
> to report it.  For Openssh 3.6p1, defining WITH_ABBREV_NO_TTY corrects
> the problem.  Below is a brief patch to configure which does this.  You

I've commited the fix to CVS. It should show up in the next snapshot.
Thanks for the report.

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




From carson at taltos.org  Sat Sep 13 16:03:43 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sat, 13 Sep 2003 02:03:43 -0400
Subject: make install fails with current CVS due to commented out target
Message-ID: <112976984.1063418623@[192.168.20.2]>

Solaris x86 8
autoconf 2.57

autoconf; autoheader; ./configure ....; make

all goes fine

make install fails on Ssh.bin. scard/Makefile has a commented out target 
for it - is there some reason for the target being commented out?

-- 
Carson



From dtucker at zip.com.au  Sat Sep 13 16:45:33 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 13 Sep 2003 16:45:33 +1000
Subject: make install fails with current CVS due to commented out target
References: <112976984.1063418623@[192.168.20.2]>
Message-ID: <3F62BD0C.2721BAA6@zip.com.au>

Carson Gaspar wrote: 
> make install fails on Ssh.bin. scard/Makefile has a commented out target
> for it - is there some reason for the target being commented out?

>From the CVS log for scard/Makefile.in:

revision 1.4
date: 2002/04/26 01:25:41;  author: djm;  state: Exp;  lines: +6 -5
 - (djm) Bug #137, #209: fix make problems for scard/Ssh.bin, do uudecode
   during distprep only

If you want to do a distprep on a clean checkout, do:
make -f Makefile.in distprep

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



From carson at taltos.org  Sat Sep 13 16:51:45 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sat, 13 Sep 2003 02:51:45 -0400
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
Message-ID: <115858843.1063421505@[192.168.20.2]>

I'm attaching a simple doc patch against current CVS - feel free to re-word 
it as you see fit. I also noticed that if UseDNS is no, 
HostbasedUsesNameFromPacketOnly _must_ be yes if you want 
HostbasedAuthentication to work.

-- 
Carson
-------------- next part --------------
--- sshd_config.5.DIST	2003-09-13 02:25:18.365707000 -0400+++ sshd_config.5	2003-09-13 02:46:29.430974000 -0400@@ -245,6 +245,16 @@ and applies to protocol version 2 only. The default is .Dq no .+.It Cm HostbasedUsesNameFromPacketOnly+Specifies whether HostbasedAuthentication fails if the client supplied+hostname does not match the hostname derived by reverse resolving the+client's IP address. If UseDNS is set to+.Dq no ,+the client supplied hostname will be compared with the client's IP address, and+authentication will probably fail, unless this is set to+.Dq yes .+The default is+.Dq no . .It Cm HostKey Specifies a file containing a private host key used by SSH.

From carson at taltos.org  Sat Sep 13 17:19:44 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sat, 13 Sep 2003 03:19:44 -0400
Subject: Trailing dot is not removed from client hostname if
 HostbasedUsesNameFromPacketOnly is yes
Message-ID: <3F62C510.9050509@taltos.org>

If HostbasedUsesNameFromPacketOnly is set to yes, sshd does not remove 
the trailing dot from the client supplied hostname, causing sshd to 
attempt to look up "foo.example.com." (note trailing period) in 
known_hosts and .shosts instead of "foo.example.com"

Trivial patch attached.

-- 
Carson
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: auth2-hostbased.c.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030913/797d8e45/attachment.ksh 

From cjwatson at debian.org  Sat Sep 13 21:07:07 2003
From: cjwatson at debian.org (Colin Watson)
Date: Sat, 13 Sep 2003 12:07:07 +0100
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <E19y8F9-0003JJ-00@chiark.greenend.org.uk>

Ben Lindstrom wrote:
>On this note I think it would be best to opening the floor for testing of
>the current CVS tree.  OpenSSH is in a feature lock and we should be in
>in sync with the OpenBSD tree (there may be stray patches, but hopefully
>nothing major).

Debian unstable, Linux/i386. Configured roughly in accordance with the
current Debian package as follows:

  LOGIN_PROGRAM=/bin/login ./configure --prefix=/usr --sysconfdir=/etc/ssh --libexecdir=/usr/lib --mandir=/usr/share/man --with-tcp-wrappers --with-xauth=/usr/bin/X11/xauth --with-default-path=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin --with-superuser-path=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin --with-pam --with-4in6 --with-privsep-path=/var/run/sshd --without-rand-helper

  OpenSSH has been configured with the following options:
		       User binaries: /usr/bin
		     System binaries: /usr/sbin
		 Configuration files: /etc/ssh
		     Askpass program: /usr/lib/ssh-askpass
			Manual pages: /usr/share/man/manX
			    PID file: /var/run
    Privilege separation chroot path: /var/run/sshd
	      sshd default user PATH: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
	    sshd superuser user PATH: /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
		      Manpage format: doc
			 PAM support: yes
		  KerberosIV support: no
		   KerberosV support: no
		   Smartcard support: no
			 AFS support: no
		       S/KEY support: no
		TCP Wrappers support: yes
		MD5 password support: no
	 IP address in $DISPLAY hack: no
	    Use IPv4 by default hack: no
	     Translate v4 in v6 hack: yes
		    BSD Auth support: no
		Random number source: OpenSSL internal ONLY

		Host: i686-pc-linux-gnu
	    Compiler: gcc
      Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
  Preprocessor flags:
	Linker flags:
	   Libraries: -lwrap -lpam -ldl -lutil -lz -lnsl -lcrypto

  PAM is enabled. You may need to install a PAM control file
  for sshd, otherwise password authentication may fail.
  Example PAM control files can be found in the contrib/
  subdirectory

Then:

  make CFLAGS='-g -O2 -Wall -Wpointer-arith -Wno-uninitialized -DLOGIN_NO_ENDOPT -DSSHD_PAM_SERVICE=\"ssh\"'

Some compiler warnings:

  gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -DLOGIN_NO_ENDOPT -DSSHD_PAM_SERVICE=\"ssh\" -I. -I.  -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/lib/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/lib/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/lib/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/run/sshd\" -DSSH_RAND_HELPER=\"/usr/lib/ssh-rand-helper\" -DHAVE_CONFIG_H -c auth-pam.c
  auth-pam.c: In function `sshpam_thread':
  auth-pam.c:206: warning: dereferencing type-punned pointer will break strict-aliasing rules
  auth-pam.c: In function `sshpam_init':
  auth-pam.c:284: warning: dereferencing type-punned pointer will break strict-aliasing rules
  auth-pam.c: In function `do_pam_putenv':
  auth-pam.c:673: warning: unused variable `compound'

And an error:

  gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o uidswap.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o monitor_mm.o monitor.o monitor_wrap.o monitor_fdpass.o kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o auth-sia.o md5crypt.o -L. -Lopenbsd-compat/  -lssh -lopenbsd-compat -lwrap -lpam -ldl -lutil -lz -lnsl -lcrypto
  openbsd-compat//libopenbsd-compat.a(xcrypt.o)(.text+0x5): In function `xcrypt':
  /home/cjwatson/src/debian/openssh/upstream/openssh/openbsd-compat/xcrypt.c:76: undefined reference to `crypt'
  collect2: ld returned 1 exit status
  make: *** [sshd] Error 1

My platform's libcrypto doesn't have a crypt() symbol. It used to be
that crypt() was only needed if !defined(USE_PAM), but now it's needed
unconditionally (unnecessarily)?

I worked around this by adding -lcrypt, and continued. All regression
tests pass. However, when I tried testing sshd manually I noticed that
the PAM session modules configured on my system no longer seem to be
called (most noticeably the motd doesn't get displayed, despite
pam_motd). I first found that SSHD_PAM_SERVICE no longer works: minimal
patch follows, but perhaps somebody will want to restore the old argv[0]
behaviour. Even after that, though, I'm still having problems. sshd's
debug output suggests that pam_open_session() is being called (as uid 0)
but for some reason isn't doing what it should. I'm going to keep
investigating.

Index: auth-pam.c
===================================================================
RCS file: /cvs/openssh/auth-pam.c,v
retrieving revision 1.70
diff -p -u -r1.70 auth-pam.c
--- auth-pam.c	2 Sep 2003 13:18:53 -0000	1.70
+++ auth-pam.c	13 Sep 2003 10:58:12 -0000
@@ -289,7 +289,8 @@ sshpam_init(const char *user)
 		sshpam_handle = NULL;
 	}
 	debug("PAM: initializing for \"%s\"", user);
-	sshpam_err = pam_start("sshd", user, &null_conv, &sshpam_handle);
+	sshpam_err =
+	    pam_start(SSHD_PAM_SERVICE, user, &null_conv, &sshpam_handle);
 	if (sshpam_err != PAM_SUCCESS) {
 		pam_end(sshpam_handle, sshpam_err);
 		sshpam_handle = NULL;

>The major things that have changed is PAM and Kerb/GSS support.

Am I right in saying that Kerberos V support has been completely merged?
I'd like to get rid of our separate patched openssh-krb5 source package
if possible, although I think we'll still need a separate build for
Kerberos to avoid unwanted library linkage.

Cheers,

-- 
Colin Watson                                       [cjwatson at debian.org]



From dtucker at zip.com.au  Sat Sep 13 21:49:58 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 13 Sep 2003 21:49:58 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <E19y8F9-0003JJ-00@chiark.greenend.org.uk>
Message-ID: <3F630466.9474754D@zip.com.au>

Colin Watson wrote:
[snip]
>   openbsd-compat//libopenbsd-compat.a(xcrypt.o)(.text+0x5): In function `xcrypt':
>   xcrypt.c:76: undefined reference to `crypt'
>   collect2: ld returned 1 exit status
>   make: *** [sshd] Error 1
> 
> My platform's libcrypto doesn't have a crypt() symbol. It used to be
> that crypt() was only needed if !defined(USE_PAM), but now it's needed
> unconditionally (unnecessarily)?

No, it still needs to be linked as PAM is now a run-time option (UsePAM in
sshd_config).  Perhaps configure needs to be taught where else too look?

[snip]
> I first found that SSHD_PAM_SERVICE no longer works: minimal
> patch follows, but perhaps somebody will want to restore the old argv[0]
> behaviour.

Sounds like a good idea.

> Am I right in saying that Kerberos V support has been completely merged?

The Krb5/GSSAPI support is based on Simon Wilkinson's work, but it's a
subset, not the lot.  The previous krb4, krb5 and AFS support is gone.

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



From markus at openbsd.org  Sun Sep 14 01:31:08 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 13 Sep 2003 17:31:08 +0200
Subject: 3.6.1p2 - UsePAM & challenge response
In-Reply-To: <77F055FA968580429F4546414D8C10E7011D078D@s102b.rhcci.net>
References: <77F055FA968580429F4546414D8C10E7011D078D@s102b.rhcci.net>
Message-ID: <20030913153107.GA5647@folly>

hi, i don't understand how 3.6.1p2 breaks ssh1....


On Fri, Sep 12, 2003 at 10:27:15AM -0700, Mike Bethune wrote:
> Hello,
> the new way this works breaks windows ssh clients using v1 (I know, who cares :)
> since when these options are enabled and you connect w/v1, the server asks:
> Password:
> Response: 
> and I guess these clients (tested putty, pscp, vandyke) expect just "Password:"
> 
> v2 is fine though.  But it's still a pain because I have customers who need v1 or are too dumb to select v2 in their client.  Also, pscp only uses v1 as far as I can see :(
> 
> (Sorry if there's already discussion on this, I didn't find any but the issue is probably known since even I noticed it back in June.)
> 
> Thanks,
> Mike



From markus at openbsd.org  Sun Sep 14 01:33:28 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 13 Sep 2003 17:33:28 +0200
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
In-Reply-To: <115858843.1063421505@[192.168.20.2]>
References: <115858843.1063421505@[192.168.20.2]>
Message-ID: <20030913153328.GB5647@folly>

HostbasedUsesNameFromPacketOnly is experimental and
not documented. i think it violates the spec.

On Sat, Sep 13, 2003 at 02:51:45AM -0400, Carson Gaspar wrote:
> I'm attaching a simple doc patch against current CVS - feel free to re-word 
> it as you see fit. I also noticed that if UseDNS is no, 
> HostbasedUsesNameFromPacketOnly _must_ be yes if you want 
> HostbasedAuthentication to work.

than it's a bug.



From markus at openbsd.org  Sun Sep 14 01:34:56 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 13 Sep 2003 17:34:56 +0200
Subject: Trailing dot is not removed from client hostname if
	HostbasedUsesNameFromPacketOnly is yes
In-Reply-To: <3F62C510.9050509@taltos.org>
References: <3F62C510.9050509@taltos.org>
Message-ID: <20030913153456.GC5647@folly>

AFAIK HostbasedUsesNameFromPacketOnly means: use the _exact_
value from the packet.  This is why the dot is not
removed.  Moreover, HostbasedUsesNameFromPacketOnly is
not recommended and experimental.  The client
needs to be changed to have truely random names in
the hostbased packets.

On Sat, Sep 13, 2003 at 03:19:44AM -0400, Carson Gaspar wrote:
> If HostbasedUsesNameFromPacketOnly is set to yes, sshd does not remove 
> the trailing dot from the client supplied hostname, causing sshd to 
> attempt to look up "foo.example.com." (note trailing period) in 
> known_hosts and .shosts instead of "foo.example.com"
> 
> Trivial patch attached.
> 
> -- 
> Carson

> --- auth2-hostbased.c.DIST	2003-09-13 03:05:22.921075000 -0400
> +++ auth2-hostbased.c	2003-09-13 03:06:10.206073000 -0400
> @@ -142,15 +142,15 @@
>  	debug2("userauth_hostbased: chost %s resolvedname %s ipaddr %s",
>  	    chost, resolvedname, ipaddr);
>  
> +	if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') {
> +		debug2("stripping trailing dot from chost %s", chost);
> +		chost[len - 1] = '\0';
> +	}
>  	if (options.hostbased_uses_name_from_packet_only) {
>  		if (auth_rhosts2(pw, cuser, chost, chost) == 0)
>  			return 0;
>  		lookup = chost;
>  	} else {
> -		if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') {
> -			debug2("stripping trailing dot from chost %s", chost);
> -			chost[len - 1] = '\0';
> -		}
>  		if (strcasecmp(resolvedname, chost) != 0)
>  			logit("userauth_hostbased mismatch: "
>  			    "client sends %s, but we resolve %s to %s",

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



From markus at openbsd.org  Sun Sep 14 01:36:43 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 13 Sep 2003 17:36:43 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F630466.9474754D@zip.com.au>
References: <E19y8F9-0003JJ-00@chiark.greenend.org.uk>
	<3F630466.9474754D@zip.com.au>
Message-ID: <20030913153643.GD5647@folly>

On Sat, Sep 13, 2003 at 09:49:58PM +1000, Darren Tucker wrote:
> The Krb5/GSSAPI support is based on Simon Wilkinson's work, but it's a
> subset, not the lot.  The previous krb4, krb5 and AFS support is gone.

I just want to add that the Krb5/GSSAPI is roughly equivalent
to the old code, but with ssh1 replaced by ssh2.

So the new release will only support Kerberos in protocol v2.



From rouilj at cs.umb.edu  Sun Sep 14 01:51:56 2003
From: rouilj at cs.umb.edu (John P. Rouillard)
Date: Sat, 13 Sep 2003 11:51:56 -0400
Subject: Combining Transparent Proxying with SSH Port Forwarding 
In-Reply-To: Your message of "Wed, 10 Sep 2003 13:28:46 PDT."
	<3F5F897E.2030904@doxpara.com> 
Message-ID: <200309131551.h8DFpu6K027025@mx1.cs.umb.edu>


In message <3F5F897E.2030904 at doxpara.com>,
Dan Kaminsky writes:
[...]
>    There are intrinsic problems with running UDP payloads inside of a 
>TCP stream.  We'd also need a new SSH payload type, and I don't expect 
>to see that happen without a very good reason.  Provide a list of 
>circumstances where UDP forwarding would be extremely useful...this 
>might help.

We access other sites remotely using ssh. We tunnel device error
streams (log files, console servers) back to our site for developing
monitoring application. We also tunnel VNC and X over ssh.

We would like to make SNMP queries over ssh in the same way we can
talk to tcp services over ssh.

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



From markus at openbsd.org  Sun Sep 14 02:26:00 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 13 Sep 2003 18:26:00 +0200
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <200309131551.h8DFpu6K027025@mx1.cs.umb.edu>
References: <3F5F897E.2030904@doxpara.com>
	<200309131551.h8DFpu6K027025@mx1.cs.umb.edu>
Message-ID: <20030913162559.GB31194@folly>

On Sat, Sep 13, 2003 at 11:51:56AM -0400, John P. Rouillard wrote:
> 
> In message <3F5F897E.2030904 at doxpara.com>,
> Dan Kaminsky writes:
> [...]
> >    There are intrinsic problems with running UDP payloads inside of a 
> >TCP stream.  We'd also need a new SSH payload type, and I don't expect 
> >to see that happen without a very good reason.  Provide a list of 
> >circumstances where UDP forwarding would be extremely useful...this 
> >might help.
> 
> We access other sites remotely using ssh. We tunnel device error
> streams (log files, console servers) back to our site for developing
> monitoring application. We also tunnel VNC and X over ssh.
> 
> We would like to make SNMP queries over ssh in the same way we can
> talk to tcp services over ssh.

just tunnel udp over tcp, there are proxies for this.



From Mike.Bethune at fusepoint.com  Sun Sep 14 03:31:08 2003
From: Mike.Bethune at fusepoint.com (Mike Bethune)
Date: Sat, 13 Sep 2003 10:31:08 -0700
Subject: 3.6.1p2 - UsePAM & challenge response
Message-ID: <77F055FA968580429F4546414D8C10E7011D0799@s102b.rhcci.net>

it doesn't break ssh1, it breaks these windows clients trying to auth w/v1
for how please read past the first line in my email...

> hi, i don't understand how 3.6.1p2 breaks ssh1....
> 
> 
> On Fri, Sep 12, 2003 at 10:27:15AM -0700, Mike Bethune wrote:
> > Hello,
> > the new way this works breaks windows ssh clients using v1 
> (I know, who cares :)
> > since when these options are enabled and you connect w/v1, 
> the server asks:
> > Password:
> > Response: 
> > and I guess these clients (tested putty, pscp, vandyke) 
> expect just "Password:"
> > 
> > v2 is fine though.  But it's still a pain because I have 
> customers who need v1 or are too dumb to select v2 in their 
> client.  Also, pscp only uses v1 as far as I can see :(
> > 
> > (Sorry if there's already discussion on this, I didn't find 
> any but the issue is probably known since even I noticed it 
> back in June.)
> > 
> > Thanks,
> > Mike
> 



From raj at cerias.purdue.edu  Sun Sep 14 03:53:42 2003
From: raj at cerias.purdue.edu (Brian Poole)
Date: Sat, 13 Sep 2003 12:53:42 -0500
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <20030913175342.GA24719@basm.cerias.purdue.edu>

Quoting Ben Lindstrom (mouring at etoh.eviladmin.org) from  6 September 2003:
> 
> On this note I think it would be best to opening the floor for testing of
> the current CVS tree.  OpenSSH is in a feature lock and we should be in
> in sync with the OpenBSD tree (there may be stray patches, but hopefully
> nothing major).
> 
> So please if we can get people to start doing tests on their platform is
> would help.

I've done some testing on Solaris and found one problem and another nit.
Testing was done on Solaris 7, 8 & 9, with various OpenSSL versions, and
Forte & GCC compilers.

It appears that the regress Makefile is not portable enough. Solaris 
make in particular pukes on it currently (GNU make works fine.)

$ make clean
rm -f *.o *.a ssh sshd ssh-add ssh-keygen ssh-keyscan ssh-keysign ssh-agent scp ssh-rand-helper sftp-server sftp logintest config.cache config.log
rm -f *.out core
(cd openbsd-compat && make clean)
rm -f *.o *.a core
(cd regress && make clean)
make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment
Current working directory /tmp/openssh-cvs/regress
*** Error code 1
make: Fatal error: Command failed for target `clean'

> BTW, regression testing should hopefully work for most platforms.  Please
> get in the habbit of using this.  It should give us a better handle on
> platform breakage.  Darren was nice enough to get that rolling recently.
> 
> It should be as simple as ./configure [needed options] && make && make
> tests, but I've not had a chance to confirm it with an actually test on my
> Solaris test box.

The regress suite looks good, a big thanks for getting it working. My 
nit here is that I think the yes-head test should verify that yes exists
before it tries to use it. I dislike the idea of a test failing because a
prereq isn't there, it should simply be skipped. I however don't have a 
good patch so I won't whine about it too much, I'll just politely request 
it be fixed when someone has too much time ;-) This one stuck out at me 
because Solaris 7 & 8 do not have yes installed by default (and yes, I know
its in sh-utils.) 

Everything else is looking good so far, looking forward to 3.7.


-b



From mouring at etoh.eviladmin.org  Sun Sep 14 05:09:35 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 13 Sep 2003 14:09:35 -0500 (CDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <20030913175342.GA24719@basm.cerias.purdue.edu>
Message-ID: <Pine.BSO.4.44.0309131355240.29487-100000@etoh.eviladmin.org>



On Sat, 13 Sep 2003, Brian Poole wrote:

> Quoting Ben Lindstrom (mouring at etoh.eviladmin.org) from  6 September 2003:
> >
> > On this note I think it would be best to opening the floor for testing of
> > the current CVS tree.  OpenSSH is in a feature lock and we should be in
> > in sync with the OpenBSD tree (there may be stray patches, but hopefully
> > nothing major).
> >
> > So please if we can get people to start doing tests on their platform is
> > would help.
>
> I've done some testing on Solaris and found one problem and another nit.
> Testing was done on Solaris 7, 8 & 9, with various OpenSSL versions, and
> Forte & GCC compilers.
>
> It appears that the regress Makefile is not portable enough. Solaris
> make in particular pukes on it currently (GNU make works fine.)
>
> $ make clean
> rm -f *.o *.a ssh sshd ssh-add ssh-keygen ssh-keyscan ssh-keysign ssh-agent scp ssh-rand-helper sftp-server sftp logintest config.cache config.log
> rm -f *.out core
> (cd openbsd-compat && make clean)
> rm -f *.o *.a core
> (cd regress && make clean)
> make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment
> Current working directory /tmp/openssh-cvs/regress
> *** Error code 1
> make: Fatal error: Command failed for target `clean'
>


but t-exec: works?

Does it work if you do:

clean:
        @for F in $(CLEANFILES); do rm -f $(OBJ)/${F}; done
	rm -f authorized_keys_${USER}

[..]

CLEANFILES += known_hosts pidfile \
                ssh_config ssh_proxy sshd_config sshd_proxy \
                rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1 \
                rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub \
                ls.copy remote_pid

I'm wondering if the $${F} is tripping up Solaris' makefile.

> > BTW, regression testing should hopefully work for most platforms.  Please
> > get in the habbit of using this.  It should give us a better handle on
> > platform breakage.  Darren was nice enough to get that rolling recently.
> >
> > It should be as simple as ./configure [needed options] && make && make
> > tests, but I've not had a chance to confirm it with an actually test on my
> > Solaris test box.
>
> The regress suite looks good, a big thanks for getting it working. My
> nit here is that I think the yes-head test should verify that yes exists

Darren and Tim already fixed this so it should be more portable.

- Ben



From dan at doxpara.com  Sun Sep 14 07:29:57 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Sat, 13 Sep 2003 14:29:57 -0700
Subject: Combining Transparent Proxying with SSH Port Forwarding
In-Reply-To: <20030913162559.GB31194@folly>
References: <3F5F897E.2030904@doxpara.com>	<200309131551.h8DFpu6K027025@mx1.cs.umb.edu>
	<20030913162559.GB31194@folly>
Message-ID: <3F638C55.40506@doxpara.com>


>just tunnel udp over tcp, there are proxies for this.
>  
>
Redundant code; we'd be running one proxy inside another.  Inelegant, 
not hugely secure.  Plus, SNMP security is in fact a big, big problem 
(indeed, we really do not have a way to easily secure UDP services.)

John -- everything else you named was TCP only.

--Dan




From djm at mindrot.org  Sun Sep 14 08:34:05 2003
From: djm at mindrot.org (Damien Miller)
Date: Sat, 13 Sep 2003 22:34:05 -0000
Subject: 3.6.1p2 - UsePAM & challenge response
In-Reply-To: <77F055FA968580429F4546414D8C10E7011D0799@s102b.rhcci.net>
References: <77F055FA968580429F4546414D8C10E7011D0799@s102b.rhcci.net>
Message-ID: <1063492283.17783.1.camel@sakura.mindrot.org>

On Sun, 2003-09-14 at 03:31, Mike Bethune wrote:

Please tell us how the clients are broken. You didn't even get the
version number right. 3.6.1p2 doesn't have UsePAM, that feature is only
in the CVS snapshots.

> it doesn't break ssh1, it breaks these windows clients trying to auth w/v1
> for how please read past the first line in my email...
> 
> > hi, i don't understand how 3.6.1p2 breaks ssh1....
> > 
> > 
> > On Fri, Sep 12, 2003 at 10:27:15AM -0700, Mike Bethune wrote:
> > > Hello,
> > > the new way this works breaks windows ssh clients using v1 
> > (I know, who cares :)
> > > since when these options are enabled and you connect w/v1, 
> > the server asks:
> > > Password:
> > > Response: 
> > > and I guess these clients (tested putty, pscp, vandyke) 
> > expect just "Password:"
> > > 
> > > v2 is fine though.  But it's still a pain because I have 
> > customers who need v1 or are too dumb to select v2 in their 
> > client.  Also, pscp only uses v1 as far as I can see :(
> > > 
> > > (Sorry if there's already discussion on this, I didn't find 
> > any but the issue is probably known since even I noticed it 
> > back in June.)
> > > 
> > > Thanks,
> > > Mike
> > 



From raj at cerias.purdue.edu  Sun Sep 14 09:42:21 2003
From: raj at cerias.purdue.edu (Brian Poole)
Date: Sat, 13 Sep 2003 18:42:21 -0500
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309131355240.29487-100000@etoh.eviladmin.org>
References: <20030913175342.GA24719@basm.cerias.purdue.edu>
	<Pine.BSO.4.44.0309131355240.29487-100000@etoh.eviladmin.org>
Message-ID: <20030913234221.GB24719@basm.cerias.purdue.edu>

Quoting Ben Lindstrom (mouring at etoh.eviladmin.org) from 13 September 2003:
> 
> 
> On Sat, 13 Sep 2003, Brian Poole wrote:
> 
> > It appears that the regress Makefile is not portable enough. Solaris
> > make in particular pukes on it currently (GNU make works fine.)
> >
> > $ make clean
> > rm -f *.o *.a ssh sshd ssh-add ssh-keygen ssh-keyscan ssh-keysign ssh-agent scp ssh-rand-helper sftp-server sftp logintest config.cache config.log
> > rm -f *.out core
> > (cd openbsd-compat && make clean)
> > rm -f *.o *.a core
> > (cd regress && make clean)
> > make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment
> > Current working directory /tmp/openssh-cvs/regress
> > *** Error code 1
> > make: Fatal error: Command failed for target `clean'
> 
> but t-exec: works?

No, the Makefile was pretty much worthless for Solaris's make.
I was doing all the regression testing with gmake.

> Does it work if you do:
> 
> clean:
>         @for F in $(CLEANFILES); do rm -f $(OBJ)/${F}; done
> 	rm -f authorized_keys_${USER}
> 
> [..]
> 
> CLEANFILES += known_hosts pidfile \
>                 ssh_config ssh_proxy sshd_config sshd_proxy \
>                 rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1 \
>                 rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub \
>                 ls.copy remote_pid
> 
> I'm wondering if the $${F} is tripping up Solaris' makefile.

This didn't work either.. I had a few minutes to poke at this and
I think I've got the problems down, though I may be a bit off as
my Makefile fu is pretty much non-existent.

problem #1, line #3 is unacceptable for Solaris's make:

basm 263 $ make clean
make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment

Commenting that line out gives me (obviously not acceptable for the
real solution, just wanting to see if that was a separate problem):

$ cvs diff -u Makefile
Index: Makefile
===================================================================
RCS file: /cvs/openssh/regress/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile    9 Sep 2003 13:07:10 -0000       1.8
+++ Makefile    13 Sep 2003 23:31:51 -0000
@@ -1,6 +1,6 @@
 #      $OpenBSD: Makefile,v 1.24 2003/07/03 08:24:13 markus Exp $

-OBJ ?= `pwd`
+# OBJ ?= `pwd`

 REGRESS_TARGETS=       t1 t2 t3 t4 t5 t6 t7 t-exec
 tests:         $(REGRESS_TARGETS)

$ make clean
sh: syntax error at line 1: `;' unexpected
*** Error code 2
make: Fatal error: Command failed for target `clean'

Mmmkay, error has changed at least.. this problem turns out to be in
spacing around the +=.. From the man page of Solaris make:

     +=    When used in place of `=', appends a string to a macro
           definition  (must be surrounded by white space, unlike
           `=').

Must be surrounded by white space.. adding that in (and a change
so we can see what exactly its cleaning) gives us:

$ make clean
for F in t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2 authorized_keys_raj known_hosts pidfile  ssh_config ssh_proxy sshd_config sshd_proxy  rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1  rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub  ls.copy remote_pid; do rm -f /${F}; done
$ make distclean
for F in t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2 authorized_keys_raj known_hosts pidfile  ssh_config ssh_proxy sshd_config sshd_proxy  rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1  rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub  ls.copy remote_pid; do rm -f /${F}; done

Thats with the following patch:

Index: Makefile
===================================================================
RCS file: /cvs/openssh/regress/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile	9 Sep 2003 13:07:10 -0000	1.8
+++ Makefile	13 Sep 2003 23:41:22 -0000
@@ -1,13 +1,13 @@
 #	$OpenBSD: Makefile,v 1.24 2003/07/03 08:24:13 markus Exp $
 
-OBJ ?= `pwd`
+# OBJ ?= `pwd`
 
 REGRESS_TARGETS=	t1 t2 t3 t4 t5 t6 t7 t-exec
 tests:		$(REGRESS_TARGETS)
 
-CLEANFILES+=	t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2
+CLEANFILES   += t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2
 clean:
-	@for F in $(CLEANFILES); do rm -f $(OBJ)/$${F}; done
+	for F in $(CLEANFILES); do rm -f $(OBJ)/$${F}; done
 distclean:	clean
 
 LTESTS= 	connect \
@@ -38,13 +38,13 @@
 		forwarding
 
 USER!=		id -un
-CLEANFILES+=	authorized_keys_${USER} known_hosts pidfile \
+CLEANFILES   += authorized_keys_${USER} known_hosts pidfile \
 		ssh_config ssh_proxy sshd_config sshd_proxy \
 		rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1 \
 		rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub \
 		ls.copy remote_pid
 
-#LTESTS+=	ssh-com ssh-com-client ssh-com-keygen ssh-com-sftp
+#LTESTS +=	ssh-com ssh-com-client ssh-com-keygen ssh-com-sftp
 
 t1:
 	ssh-keygen -if ${.CURDIR}/rsa_ssh2.prv | diff - ${.CURDIR}/rsa_openssh.prv


So.. #1 is still a problem, perhaps someone better versed with Makefiles
can fix it. I'm getting twitchy just fiddling with it ;-). #2 seems to be
fixed by adding white space, though I'm suspicious that clean & distclean
are cleaning the exact same set of files. Is this correct? Why are there
two assignment statements if it is supposed to be always cleaning the 
same set of files?

> Darren and Tim already fixed this so it should be more portable.

So it was.. started testing on a SNAP and noticed it there. Moved up
to CVS a bit later and didn't recheck it. Much obliged.


-b



From mouring at etoh.eviladmin.org  Sun Sep 14 09:56:27 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 13 Sep 2003 18:56:27 -0500 (CDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <20030913234221.GB24719@basm.cerias.purdue.edu>
Message-ID: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>



On Sat, 13 Sep 2003, Brian Poole wrote:

[..]
> Commenting that line out gives me (obviously not acceptable for the
> real solution, just wanting to see if that was a separate problem):
>
> $ cvs diff -u Makefile
> Index: Makefile
> ===================================================================
> RCS file: /cvs/openssh/regress/Makefile,v
> retrieving revision 1.8
> diff -u -r1.8 Makefile
> --- Makefile    9 Sep 2003 13:07:10 -0000       1.8
> +++ Makefile    13 Sep 2003 23:31:51 -0000
> @@ -1,6 +1,6 @@
>  #      $OpenBSD: Makefile,v 1.24 2003/07/03 08:24:13 markus Exp $
>
> -OBJ ?= `pwd`
> +# OBJ ?= `pwd`
>

Hmm.. This is required for building outside of the tree.  Tim or someone
that does this will have to address this.  I don't normally.

[..]
> So.. #1 is still a problem, perhaps someone better versed with Makefiles
> can fix it. I'm getting twitchy just fiddling with it ;-). #2 seems to be
> fixed by adding white space, though I'm suspicious that clean & distclean
> are cleaning the exact same set of files. Is this correct? Why are there
> two assignment statements if it is supposed to be always cleaning the
> same set of files?
>

In general the patch looks sane.  Outside of the above comment about OBJ.

As for clean and distclean being the same.  That is fine.  'clean' is
normally used between 'make && make install'.  'distclean' actually
strips out stuff that 'make -f Makefile.in distprep' does.  So it should
bring it close to the same state as if you'd pull it from the CVS tree.

Since 'make -f Makefile.in distprep' does not do any work in regress/ tree
they are extactly the same.  Some day down the road this may change.

- Ben



From dtucker at zip.com.au  Sun Sep 14 09:59:53 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 14 Sep 2003 09:59:53 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<20030913175342.GA24719@basm.cerias.purdue.edu>
Message-ID: <3F63AF78.B1B13013@zip.com.au>

Brian Poole wrote:
> It appears that the regress Makefile is not portable enough. Solaris
> make in particular pukes on it currently (GNU make works fine.)

> make: Fatal error: Command failed for target `clean'

It's just the "clean" target, not the tests themselves?  I'll take a look
at that.

> The regress suite looks good, a big thanks for getting it working. My
> nit here is that I think the yes-head test should verify that yes exists
> before it tries to use it.

We fixed that a day or two ago.  "yes" is not used now.

I didn't realise it wasn't on Solaris until recently (I have GNU sh-utils
on mine), then replaced it with the equivalent do-while loop.

That proptly broke for people using csh as their login shell.  Sigh.  Tim
fixed that, so now instead of 'yes', we use the more portable but much
less readable 'sh -c "while true;do echo yes; done"'.  Don't you love
portable shell scripting?

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



From raj at cerias.purdue.edu  Sun Sep 14 10:19:57 2003
From: raj at cerias.purdue.edu (Brian Poole)
Date: Sat, 13 Sep 2003 19:19:57 -0500
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F63AF78.B1B13013@zip.com.au>
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<20030913175342.GA24719@basm.cerias.purdue.edu>
	<3F63AF78.B1B13013@zip.com.au>
Message-ID: <20030914001957.GC24719@basm.cerias.purdue.edu>

Quoting Darren Tucker (dtucker at zip.com.au) from 14 September 2003:
> Brian Poole wrote:
> > It appears that the regress Makefile is not portable enough. Solaris
> > make in particular pukes on it currently (GNU make works fine.)
> 
> > make: Fatal error: Command failed for target `clean'
> 
> It's just the "clean" target, not the tests themselves?  I'll take a look
> at that.

Rather it is the Makefile, not the tests themselves.. more than just the
clean target is affected.

$ make
make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment
$ make tests
make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment
$ make clean
make: Fatal error in reader: Makefile, line 3: Badly formed macro assignment
$ pwd
/d0/source/openssh/openssh-cvs/regress



-b



From Mike.Bethune at fusepoint.com  Sun Sep 14 10:32:27 2003
From: Mike.Bethune at fusepoint.com (Mike Bethune)
Date: Sat, 13 Sep 2003 17:32:27 -0700
Subject: 3.6.1p2 - UsePAM & challenge response
Message-ID: <77F055FA968580429F4546414D8C10E7011D079A@s102b.rhcci.net>

this is simple, here's a step-by-step:
1) get a version of openssh past 3.6.1p2 that has the UsePAM option (latest snapshot even)
2) sshd_config: default is probably fine, but specifically:
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
3) get a windows ssh client like putty (which will try to connect with v1 by default)
4) try to connect to your server with it: it doesn't work.
5) configure putty to use v2: it works.

as mentioned below, the response from the server when using v1 is:
Password:
Response:

which is different from they way it responds when connecting with v2:
Password:

this may be why it doesn't work.


> Please tell us how the clients are broken. You didn't even get the
> version number right. 3.6.1p2 doesn't have UsePAM, that 
> feature is only
> in the CVS snapshots.
> 
> > it doesn't break ssh1, it breaks these windows clients 
> trying to auth w/v1
> > for how please read past the first line in my email...
> > 
> > > hi, i don't understand how 3.6.1p2 breaks ssh1....
> > > 
> > > 
> > > On Fri, Sep 12, 2003 at 10:27:15AM -0700, Mike Bethune wrote:
> > > > Hello,
> > > > the new way this works breaks windows ssh clients using v1 
> > > (I know, who cares :)
> > > > since when these options are enabled and you connect w/v1, 
> > > the server asks:
> > > > Password:
> > > > Response: 
> > > > and I guess these clients (tested putty, pscp, vandyke) 
> > > expect just "Password:"
> > > > 
> > > > v2 is fine though.  But it's still a pain because I have 
> > > customers who need v1 or are too dumb to select v2 in their 
> > > client.  Also, pscp only uses v1 as far as I can see :(
> > > > 
> > > > (Sorry if there's already discussion on this, I didn't find 
> > > any but the issue is probably known since even I noticed it 
> > > back in June.)
> > > > 
> > > > Thanks,
> > > > Mike
> > > 
> 
> 



From dtucker at zip.com.au  Sun Sep 14 10:33:55 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 14 Sep 2003 10:33:55 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
Message-ID: <3F63B773.77018710@zip.com.au>

Ben Lindstrom wrote:
> On Sat, 13 Sep 2003, Brian Poole wrote:
> > -OBJ ?= `pwd`
> > +# OBJ ?= `pwd`
> >
> 
> Hmm.. This is required for building outside of the tree.  Tim or someone
> that does this will have to address this.  I don't normally.

Actually, that now gets passed from the top-level Makefile (it didn't in
the early portable regression patches).  We can probably do without it.

> In general the patch looks sane.  Outside of the above comment about OBJ.

Agreed.  I'm going to run through a test here, but it looks fine.  Do you
want me to commit it if it tests OK?

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



From mouring at etoh.eviladmin.org  Sun Sep 14 10:51:22 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 13 Sep 2003 19:51:22 -0500 (CDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F63B773.77018710@zip.com.au>
Message-ID: <Pine.BSO.4.44.0309131951070.29487-100000@etoh.eviladmin.org>



On Sun, 14 Sep 2003, Darren Tucker wrote:

> Ben Lindstrom wrote:
> > On Sat, 13 Sep 2003, Brian Poole wrote:
> > > -OBJ ?= `pwd`
> > > +# OBJ ?= `pwd`
> > >
> >
> > Hmm.. This is required for building outside of the tree.  Tim or someone
> > that does this will have to address this.  I don't normally.
>
> Actually, that now gets passed from the top-level Makefile (it didn't in
> the early portable regression patches).  We can probably do without it.
>
> > In general the patch looks sane.  Outside of the above comment about OBJ.
>
> Agreed.  I'm going to run through a test here, but it looks fine.  Do you
> want me to commit it if it tests OK?
>

Go for it.

- Ben



From djm at mindrot.org  Sun Sep 14 11:30:48 2003
From: djm at mindrot.org (Damien Miller)
Date: Sun, 14 Sep 2003 01:30:48 -0000
Subject: 3.6.1p2 - UsePAM & challenge response
In-Reply-To: <77F055FA968580429F4546414D8C10E7011D079A@s102b.rhcci.net>
References: <77F055FA968580429F4546414D8C10E7011D079A@s102b.rhcci.net>
Message-ID: <1063502886.17783.4.camel@sakura.mindrot.org>

On Sun, 2003-09-14 at 10:32, Mike Bethune wrote:
> 4) try to connect to your server with it: it doesn't work.

"It doesn't work" is not a bug report.




From dtucker at zip.com.au  Sun Sep 14 11:43:55 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 14 Sep 2003 11:43:55 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309131951070.29487-100000@etoh.eviladmin.org>
Message-ID: <3F63C7DB.7F99F076@zip.com.au>

Ben Lindstrom wrote:
> 
> On Sun, 14 Sep 2003, Darren Tucker wrote:
> > Agreed.  I'm going to run through a test here, but it looks fine.  Do you
> > want me to commit it if it tests OK?
> >
> 
> Go for it.

Done.  There's still a couple of things:

1) "make clean" doesn't work in an out-of-tree build
2) "USER != id -un" isn't portable.
3) I rely on a trailing "/" on $OBJ so "rm ${OBJ}$$F works in the current
dir if OBJ isn't set.  Nasty but it works.

#2 Can be replaced by a script that does the same search that test-exec.sh
does.  Not sure about #1.  (Maybe ln -s $srcdir/regress/Makefile
$obj/regress/Makefile?)

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



From dtucker at zip.com.au  Sun Sep 14 13:14:54 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 14 Sep 2003 13:14:54 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <20030913175342.GA24719@basm.cerias.purdue.edu>
	<Pine.BSO.4.44.0309131355240.29487-100000@etoh.eviladmin.org>
	<20030913234221.GB24719@basm.cerias.purdue.edu>
Message-ID: <3F63DD2E.AE9FB477@zip.com.au>

Brian Poole wrote:
> Mmmkay, error has changed at least.. this problem turns out to be in
> spacing around the +=.. From the man page of Solaris make:
> 
>      +=    When used in place of `=', appends a string to a macro
>            definition  (must be surrounded by white space, unlike
>            `=').
> 
> Must be surrounded by white space.. adding that in (and a change
> so we can see what exactly its cleaning) gives us:

[snip]

>  USER!=         id -un
> -CLEANFILES+=   authorized_keys_${USER} known_hosts pidfile \
> +CLEANFILES   += authorized_keys_${USER} known_hosts pidfile \

As it turns out, that extra space breaks AIX's native make.  Sigh.  It
works without it, but with it you get:

"Makefile", line 6: make: 1254-055 Dependency line needs colon or double
colon operator.
"Makefile", line 43: make: 1254-055 Dependency line needs colon or double
colon operator.
make: 1254-058 Fatal errors encountered -- cannot continue.
make: 1254-004 The error code from the last command is 2.

Anyone object to tossing out the "+=" like so?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: regress/Makefile
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- regress/Makefile	14 Sep 2003 01:40:36 -0000	1.9
+++ regress/Makefile	14 Sep 2003 03:10:48 -0000
@@ -3,7 +3,6 @@
 REGRESS_TARGETS=	t1 t2 t3 t4 t5 t6 t7 t-exec
 tests:		$(REGRESS_TARGETS)
 
-CLEANFILES +=	t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2
 clean:
 	for F in $(CLEANFILES); do rm -f $(OBJ)$$F; done
 distclean:	clean
@@ -36,7 +35,8 @@ LTESTS= 	connect \
 		forwarding
 
 USER!=		id -un
-CLEANFILES +=	authorized_keys_${USER} known_hosts pidfile \
+CLEANFILES=	t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2 \
+		authorized_keys_${USER} known_hosts pidfile \
 		ssh_config ssh_proxy sshd_config sshd_proxy \
 		rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1 \
 		rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub \

From Mike.Bethune at fusepoint.com  Sun Sep 14 15:33:26 2003
From: Mike.Bethune at fusepoint.com (Mike Bethune)
Date: Sat, 13 Sep 2003 22:33:26 -0700
Subject: 3.6.1p2 - UsePAM & challenge response
Message-ID: <77F055FA968580429F4546414D8C10E7011D079B@s102b.rhcci.net>

This is how you alienate anyone from reporting anything. If you understood english, this would be good enough.  Why develop open source software if you don't want to get feedback.  Now, I'll just fix the code myself and not give it to you.

> 
> On Sun, 2003-09-14 at 10:32, Mike Bethune wrote:
> > 4) try to connect to your server with it: it doesn't work.
> 
> "It doesn't work" is not a bug report.
> 
> 
> 



From dtucker at zip.com.au  Mon Sep 15 10:21:50 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 14 Sep 2003 17:21:50 -0700
Subject: 3.6.1p2 - UsePAM & challenge response
References: <77F055FA968580429F4546414D8C10E7011D079B@s102b.rhcci.net>
Message-ID: <3F65061E.54AFA1A8@zip.com.au>

Mike Bethune wrote:
> > On Sun, 2003-09-14 at 10:32, Mike Bethune wrote:
> > > 4) try to connect to your server with it: it doesn't work.

> djm at mindrot.org wrote:
> > "It doesn't work" is not a bug report.

> This is how you alienate anyone from reporting anything. If you
> understood english, this would be good enough.  Why develop open source
> software if you don't want to get feedback.  Now, I'll just fix the
> code myself and not give it to you.

It's disappointing that you feel that way, but that is of course you right
to behave that way should you choose to do so.

First, if you haven't read Simon Tatham's "How to Report Bugs Effectively"
[0], go do so now.  We'll wait.

Now, consider Damien's point of view.  OpenSSH has a number of
configure-time options, runs on dozens of platforms out of the box, each
of which have potentially dozens of variants.  This means there are
literally thousands of possible combinations.

So far, in the 4 messages you have sent, you have not provided:

* Server operating system type and version
* Configure and compile-time options (except you're probably using
--with-pam)
* Version of PuTTY

You have, however, provided a lot of attitude.  This is not a substitute.

To assist in diagnosing your problem, you could also supply
* server-side debugging for your failed connection [1]
* PuTTY packet log (be aware that your password will be logged if you type
it, so delete it from the log before sending it).

Now, it so happens that I have PuTTY (0.53b) handy so I attempted to
reproduce your problem.  I was unable to do so.  I configured PuTTY to
connect with SSHv1 only and attempt "TIS or Cryptocard auth".  The server
is Redhat 8, OpenSSH code from today's CVS, configured with "./configure
--with-pam".  Here's what I got in the PuTTY window:

login as: dtucker
Sent username "dtucker"
Password:
Response: [type my password here]
Last login: Sun Sep 14 16:44:59 2003 from dingo.dodgy.net.au
debug1: PAM: reinitializing credentials
debug1: permanently_set_uid: 500/500
debug1: PAM: retrieving environment
[login stuff snipped]

[dtucker at gate dtucker]$ logout

I have attached my server-side debugging for your comparison.

[0] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
[1] http://www.snailbook.com/faq/general-debugging.auto.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
# ./sshd -o PasswordAuthentication=no -o ChallengeResponseAuthentication=yes -o UsePAM=yes -o UsePrivilegeSeparation=no -p 2022 -ddd -o Protocol=1
debug2: read_server_config: filename /usr/local/etc/sshd_config
debug1: sshd version OpenSSH_3.7p1
debug1: private host key: #0 type 0 RSA1
socket: Address family not supported by protocol
debug1: Bind to port 2022 on 0.0.0.0.
Server listening on 0.0.0.0 port 2022.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from 192.168.32.2 port 1148
debug1: Client protocol version 1.5; client software version PuTTY-Release-0.53b
debug1: no match: PuTTY-Release-0.53b
debug1: Local version string SSH-1.5-OpenSSH_3.7p1
debug1: Sent 768 bit server key and 1024 bit host key.
debug1: Encryption type: blowfish
debug1: Received session key; encryption turned on.
debug1: Installing crc compensation attack detector.
debug1: PAM: initializing for "dtucker"
debug3: Trying to reverse map address 192.168.32.2.
debug1: PAM: setting PAM_RHOST to "dingo.dodgy.net.au"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: Attempting authentication for dtucker.
debug1: rcvd SSH_CMSG_AUTH_TIS
debug3: ssh_msg_recv entering
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug1: sending challenge 'Password: '
debug1: rcvd SSH_CMSG_AUTH_TIS_RESPONSE
debug2: PAM: sshpam_respond
debug3: ssh_msg_send: type 6
debug3: ssh_msg_recv entering
debug3: ssh_msg_send: type 0
debug3: do_pam_account: pam_acct_mgmt = 0
Accepted challenge-response for dtucker from 192.168.32.2 port 1148
debug1: session_new: init
debug1: session_new: session 0
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/7
debug1: PAM: setting PAM_TTY to "/dev/pts/7"
debug1: PAM: establishing credentials
debug2: fd 4 setting TCP_NODELAY
debug1: Entering interactive session.
debug2: fd 3 setting O_NONBLOCK
debug2: fd 7 is O_NONBLOCK
debug2: fd 9 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug1: server_init_dispatch_13
debug1: server_init_dispatch_15
debug1: Setting controlling tty using TIOCSCTTY.


From markus at openbsd.org  Sun Sep 14 20:38:28 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 14 Sep 2003 12:38:28 +0200
Subject: 3.6.1p2 - UsePAM & challenge response
In-Reply-To: <77F055FA968580429F4546414D8C10E7011D0799@s102b.rhcci.net>
References: <77F055FA968580429F4546414D8C10E7011D0799@s102b.rhcci.net>
Message-ID: <20030914103828.GA5432@folly>

On Sat, Sep 13, 2003 at 10:31:08AM -0700, Mike Bethune wrote:
> it doesn't break ssh1, it breaks these windows clients trying to auth w/v1
> for how please read past the first line in my email...

i still don't understand.

> > On Fri, Sep 12, 2003 at 10:27:15AM -0700, Mike Bethune wrote:
> > > Hello,
> > > the new way this works breaks windows ssh clients using v1 
> > (I know, who cares :)
> > > since when these options are enabled and you connect w/v1, 
> > the server asks:
> > > Password:
> > > Response: 
> > > and I guess these clients (tested putty, pscp, vandyke) 
> > expect just "Password:"
> > > 
> > > v2 is fine though.  But it's still a pain because I have 
> > customers who need v1 or are too dumb to select v2 in their 
> > client.  Also, pscp only uses v1 as far as I can see :(
> > > 
> > > (Sorry if there's already discussion on this, I didn't find 
> > any but the issue is probably known since even I noticed it 
> > back in June.)
> > > 
> > > Thanks,
> > > Mike
> > 



From markus at openbsd.org  Sun Sep 14 20:41:26 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 14 Sep 2003 12:41:26 +0200
Subject: 3.6.1p2 - UsePAM & challenge response
In-Reply-To: <1063502886.17783.4.camel@sakura.mindrot.org>
References: <77F055FA968580429F4546414D8C10E7011D079A@s102b.rhcci.net>
	<1063502886.17783.4.camel@sakura.mindrot.org>
Message-ID: <20030914104126.GC5432@folly>

On Sun, Sep 14, 2003 at 11:28:07AM +1000, Damien Miller wrote:
> On Sun, 2003-09-14 at 10:32, Mike Bethune wrote:
> > 4) try to connect to your server with it: it doesn't work.
> 
> "It doesn't work" is not a bug report.

can someone else try this as well?



From djm at mindrot.org  Sun Sep 14 21:00:51 2003
From: djm at mindrot.org (Damien Miller)
Date: Sun, 14 Sep 2003 11:00:51 -0000
Subject: 3.6.1p2 - UsePAM & challenge response
In-Reply-To: <20030914104126.GC5432@folly>
References: <77F055FA968580429F4546414D8C10E7011D079A@s102b.rhcci.net>
	<1063502886.17783.4.camel@sakura.mindrot.org>
	<20030914104126.GC5432@folly>
Message-ID: <1063537088.27771.0.camel@sakura.mindrot.org>

On Sun, 2003-09-14 at 20:41, Markus Friedl wrote:
> On Sun, Sep 14, 2003 at 11:28:07AM +1000, Damien Miller wrote:
> > On Sun, 2003-09-14 at 10:32, Mike Bethune wrote:
> > > 4) try to connect to your server with it: it doesn't work.
> > 
> > "It doesn't work" is not a bug report.
> 
> can someone else try this as well?

It works, but putty doesn't enable TIS auth by default. 

-d




From markus at openbsd.org  Sun Sep 14 21:04:18 2003
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 14 Sep 2003 13:04:18 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <20030914110418.GD5432@folly>

On Sat, Sep 06, 2003 at 12:47:14AM -0500, Ben Lindstrom wrote:
> 
> On this note I think it would be best to opening the floor for testing of
> the current CVS tree.  OpenSSH is in a feature lock and we should be in
> in sync with the OpenBSD tree (there may be stray patches, but hopefully
> nothing major).
> 
> So please if we can get people to start doing tests on their platform is
> would help.

I would also appreciate if you could test the ssh(1) ReykeyLimit
option against all kinds of ssh servers, e.g. with
	% ssh -2v -o 'RekeyLimit 1K' server



From carson at taltos.org  Mon Sep 15 03:59:47 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sun, 14 Sep 2003 13:59:47 -0400
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
In-Reply-To: <20030913153328.GB5647@folly>
References: <115858843.1063421505@[192.168.20.2]> <20030913153328.GB5647@folly>
Message-ID: <242341671.1063547987@[192.168.20.2]>

--On Saturday, September 13, 2003 5:33 PM +0200 Markus Friedl 
<markus at openbsd.org> wrote:

> HostbasedUsesNameFromPacketOnly is experimental and
> not documented. i think it violates the spec.

Can you please elaborate? From my point of view, it is the _only_ sane way 
to operate, as anything else looks at useless (from a security perspective) 
IP and DNS data, as opposed to the cryptographically authenticated data 
sent by the client.

It also makes HostbasedAuthentication survive NAT, which is nice.

-- 
Carson



From carson at taltos.org  Mon Sep 15 04:00:25 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sun, 14 Sep 2003 14:00:25 -0400
Subject: Trailing dot is not removed from client hostname
 if	HostbasedUsesNameFromPacketOnly is yes
In-Reply-To: <20030913153456.GC5647@folly>
References: <3F62C510.9050509@taltos.org> <20030913153456.GC5647@folly>
Message-ID: <242379171.1063548025@[192.168.20.2]>



--On Saturday, September 13, 2003 5:34 PM +0200 Markus Friedl 
<markus at openbsd.org> wrote:

> AFAIK HostbasedUsesNameFromPacketOnly means: use the _exact_
> value from the packet.  This is why the dot is not
> removed.  Moreover, HostbasedUsesNameFromPacketOnly is
> not recommended and experimental.  The client
> needs to be changed to have truly random names in
> the hostbased packets.

WTF? Why would you want random names?!

-- 
Carson



From tim at multitalents.net  Mon Sep 15 05:16:51 2003
From: tim at multitalents.net (Tim Rice)
Date: Sun, 14 Sep 2003 12:16:51 -0700 (PDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
Message-ID: <Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net>

On Sat, 13 Sep 2003, Ben Lindstrom wrote:

> >
> > -OBJ ?= `pwd`
> > +# OBJ ?= `pwd`
> >
> 
> Hmm.. This is required for building outside of the tree.  Tim or someone
> that does this will have to address this.  I don't normally.

There are other problems building outside the source tree.
Like "(cd regress && $(MAKE) clean)" doesn't work because there is no Makefile.

I'd like to see Makefile get generated from Makefile.in at configure time.

I'm pressed for time right now, so I can't get to it right away.

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




From bnewman_eo at imail.ru  Mon Sep 15 10:32:30 2003
From: bnewman_eo at imail.ru (Benjamin Newman)
Date: Mon, 15 Sep 2003 00:32:30 +0000
Subject: give her something to talk about         o    2agwn03go01y7
Message-ID: <dbbf01c37b20$d2a8f9c8$c5dba253@di3jk7r>


            Genital Enlargement - Medical Breakthrough For Men!
           2 amazing ways to enlarge your manhood - read below..

   Doctors worked for years creating a pill to enlarge the male genitalia
   by length and width.
   The years of work produced a pill called "VPRX", - [1]VPRX Pills info
   click here.
   and also a patch similair to the quit smoking patch. - [2]Penis
   Patches info click here.

   [3]delete yourself from our database.

References

   1. http://www.naturalherbal.biz/info/v/
   2. http://www.naturalherbal.biz/info/p/
   3. http://www.naturalherbal.biz/info/out.html


From dtucker at zip.com.au  Mon Sep 15 13:13:02 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 15 Sep 2003 13:13:02 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
	<Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net>
Message-ID: <3F652E3E.2FF7E456@zip.com.au>

Tim Rice wrote:
> There are other problems building outside the source tree.
> Like "(cd regress && $(MAKE) clean)" doesn't work because there is no Makefile.
> 
> I'd like to see Makefile get generated from Makefile.in at configure time.

I noticed that too.  What do you think of the attached patch?  It's ugly
but it works.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: Makefile.in
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/Makefile.in,v
retrieving revision 1.249
diff -u -p -r1.249 Makefile.in
--- Makefile.in	14 Sep 2003 01:40:36 -0000	1.249
+++ Makefile.in	15 Sep 2003 03:11:13 -0000
@@ -192,20 +192,18 @@ ssh_prng_cmds.out:	ssh_prng_cmds
 moduli:
 	echo
 
-clean:
+clean:	regressclean
 	rm -f *.o *.a $(TARGETS) logintest config.cache config.log 
 	rm -f *.out core 
 	(cd openbsd-compat && $(MAKE) clean)
-	(cd regress && $(MAKE) clean)
 
-distclean:
+distclean:	regressclean
 	rm -f *.o *.a $(TARGETS) logintest config.cache config.log 
 	rm -f *.out core
 	rm -f Makefile config.h config.status ssh_prng_cmds *~
 	rm -rf autom4te.cache
 	(cd openbsd-compat && $(MAKE) distclean)
 	(cd scard && $(MAKE) distclean)
-	(cd regress && $(MAKE) distclean)
 
 veryclean: distclean
 	rm -f configure config.h.in *.0
@@ -373,6 +371,8 @@ uninstall: 
 tests:	$(TARGETS)
 	BUILDDIR=`pwd`; \
 	[ -d `pwd`/regress ]  ||  mkdir -p `pwd`/regress; \
+	[ -f `pwd`/regress/Makefile ]  || \
+	    ln -s $(srcdir)/regress/Makefile `pwd`/regress/Makefile ; \
 	TEST_SSH_SSH="$${BUILDDIR}/ssh"; \
 	TEST_SSH_SSHD="$${BUILDDIR}/sshd"; \
 	TEST_SSH_SSHAGENT="$${BUILDDIR}/ssh-agent"; \
@@ -398,3 +398,8 @@ tests:	$(TARGETS)
 		TEST_SSH_SFTPSERVER="$${TEST_SSH_SFTPSERVER}" \
 		EXEEXT="$(EXEEXT)" \
 		$@
+
+regressclean:
+	if [ -e regress/Makefile ]; then \
+		(cd regress && $(MAKE) clean) \
+	fi

From hfalan at publica.bj.cninfo.net  Mon Sep 15 13:48:07 2003
From: hfalan at publica.bj.cninfo.net (China-TravelGuide)
Date: Mon, 15 Sep 2003 11:48:07 +0800
Subject: Tools for Inbound travel agents
Message-ID: <20030915033134.D298B27C187@shitei.mindrot.org>

Dear Colleagues,

Greetings from http://www.China-TravelGuide.com.
Email Promoter - Currently a total more than 46,000 travel agents, tour operators and national tourist offices have been submitted to the China-TravelGuide.com.
Swiftly and directly send your advertisement to more than 46,000 travel agents, tour operators and national tourist offices & build bridges for you and your new partners around the globe!
Advertisement once only $220
Monthly managed advertisement = 12 times only $1,980
Banner Advertising:
Promotion of your web site by displaying your banner to visitors throughout our web site. If you require a new banner, our graphic designers will create one for you. 
- half year: USD300
- one year: USD480
- Banner Advertising Creation (If you do not have one already): USD60
What is banner advertising? 
A banner ad is a rectangular image that promotes your web site, it functions like a billboard and is displayed on a web site. Visitors can click on these banners and be transported to your web site immediately. 
What you receive: 
Your banner will be displayed and rotated on the top or bottom of the various pages of our web site for all of our visitors to view. Visitors can click on these banners and be transported to your web site immediately. 
Specifications of the Banner Image: 
a) GIF or JPG files only. 
b) Dimensions: Width - 450 pixels, Height - 60 pixels. 
c) File size: Images must be less than 10k in size. 
If you have any further questions...
Please do not hesitate to contact us by link below and one of our support staff will reply within one working day. 
Thanks for your time and welcome to China!

looking forward to hearing from you soon and starting a good cooperation between us.

Sincerely yours

Advertisement Department
China-TravelGuide Inc.

*********************************************************
Contact: Ms. Helen Xu
Add: Room 316 of A, ZhongKe Mansion, No.75 Dengshikou Street, Dongchen District
Postcode: 100006 Beijing, CHINA
Tel: 86-10-51668586 (English 3 lines), 51668587 (Chinese 3 lines)
Fax: 86-10-89547689
mailto:alanhf at public.bta.net.cn
mailto:hfalan at publica.bj.cninfo.net
http://www.china-travelguide.com/
*********************************************************



From tim at multitalents.net  Mon Sep 15 14:39:46 2003
From: tim at multitalents.net (Tim Rice)
Date: Sun, 14 Sep 2003 21:39:46 -0700 (PDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F652E3E.2FF7E456@zip.com.au>
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
	<Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net>
	<3F652E3E.2FF7E456@zip.com.au>
Message-ID: <Pine.UW2.4.53.0309142135410.2212@ou8.int.multitalents.net>

On Mon, 15 Sep 2003, Darren Tucker wrote:

> Tim Rice wrote:
> > There are other problems building outside the source tree. Like "(cd
> > regress && $(MAKE) clean)" doesn't work because there is no Makefile.
> > 
> > I'd like to see Makefile get generated from Makefile.in at configure time.
> 
> I noticed that too.  What do you think of the attached patch?  It's ugly
> but it works.
> 
> 
+
+regressclean:
+       if [ -e regress/Makefile ]; then \
             ^^
-e is not portable.
+               (cd regress && $(MAKE) clean) \
+       fi

Your patch could work (after fixing the -e) but I still think
generating Makefile at configure time is the way to go.
It would fix the "OBJ ?= `pwd`" problem too.


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




From dtucker at zip.com.au  Mon Sep 15 14:43:16 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 15 Sep 2003 14:43:16 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<20030914110418.GD5432@folly>
Message-ID: <3F654364.E1F165FB@zip.com.au>

Markus Friedl wrote:
> I would also appreciate if you could test the ssh(1) ReykeyLimit
> option against all kinds of ssh servers, e.g. with
>         % ssh -2v -o 'RekeyLimit 1K' server

I tested SSH.com's SSH (v3.2.5), dropbear (0.36) and VanDyke's VShell
(2.2.0 eval), all on Redhat 8. 

All seemed to work fine, with lots of rekey messages in ssh's debug
output.

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



From dtucker at zip.com.au  Mon Sep 15 14:50:00 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 15 Sep 2003 14:50:00 +1000
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
	<Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net>
	<3F652E3E.2FF7E456@zip.com.au>
	<Pine.UW2.4.53.0309142135410.2212@ou8.int.multitalents.net>
Message-ID: <3F6544F8.A4EC80CC@zip.com.au>

Tim Rice wrote:
> On Mon, 15 Sep 2003, Darren Tucker wrote:
> +regressclean:
> +       if [ -e regress/Makefile ]; then \
>              ^^
> -e is not portable.

Oops.  Is there a portable equivalent?

> Your patch could work (after fixing the -e) but I still think
> generating Makefile at configure time is the way to go.
> It would fix the "OBJ ?= `pwd`" problem too.

I thought that was already fixed?  Either OBJ is set by the top-level
Makefile (for "make tests") or it's not set at all (for "make clean"). "rm
-f $(OBJ)$$F" works either way.

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



From VikashB at ComparexAfrica.co.za  Mon Sep 15 15:43:51 2003
From: VikashB at ComparexAfrica.co.za (Vikash Badal - PCS)
Date: Mon, 15 Sep 2003 07:43:51 +0200
Subject: SCO 3.2v4.2 and OpenSSH -current --> connection hangs and does no
	t close
Message-ID: <501BF453CDCFD111A6E40080C83DAC0402696820@PSICS001>

Greetings,

I have a problem with OpenSSH -current and SCO 3.2v4.2,
when I execute a remote command or exit from a session,
the connection hangs, ( line 326 of serverloop.c).

This problem only exists when using ssh2.

server side debug (-d -d -d ):
debug1: Received SIGCHLD.
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf_empty delayed efd 12/(0)
debug2: notify_done: reading
debug2: channel 0: read 0 from efd 12
debug2: channel 0: closing read-efd 12
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
-------------------

I have tried my hand at gdb, and this is the output and backtrace
before the session hangs.

(gdb)
wait_until_can_do_something (readsetp=0x7ffff8e4, writesetp=0x7ffff8e0,
    maxfdp=0x7ffff8dc, nallocp=0x7ffff8d8, max_time_milliseconds=0)
    at serverloop.c:313
313             if (child_terminated &&
packet_not_very_much_data_to_write())
(gdb)
317             if (max_time_milliseconds == 0)
(gdb)
318                     tvp = NULL;
(gdb)
326             ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
(gdb) p connection_closed
$1 = 0
(gdb) bt
#0  wait_until_can_do_something (readsetp=0x7ffff8e4, writesetp=0x7ffff8e0,
    maxfdp=0x7ffff8dc, nallocp=0x7ffff8d8, max_time_milliseconds=0)
    at serverloop.c:326
#1  0x8bfc in server_loop2 (authctxt=0x42f91c) at serverloop.c:771
#2  0x1030f in do_authenticated2 (authctxt=0x42f91c) at session.c:2086
#3  0xcc19 in do_authenticated (authctxt=0x42f91c) at session.c:216
#4  0x2eaa in main (ac=6, av=0x7ffffe28) at sshd.c:1506
(gdb) s

at this point the connection this hangs.

I do not know how to process from here, please advise

Vikash


From henry_vy at di-net.ru  Tue Sep 16 01:01:21 2003
From: henry_vy at di-net.ru (Earline Henry)
Date: Mon, 15 Sep 2003 15:01:21 +0000
Subject: expect the unexpected when the juice has been injected o dxvt982pdqu
Message-ID: <f4c401c37b9a$e929c8bd$f80bf3a2@y44mij3>


            Genital Enlargement - Medical Breakthrough For Men!
           2 amazing ways to enlarge your manhood - read below..

   Doctors worked for years creating a pill to enlarge the male genitalia
   by length and width.
   The years of work produced a pill called "VPRX", - [1]VPRX Pills info
   click here.
   and also a patch similair to the quit smoking patch. - [2]Penis
   Patches info click here.

   [3]delete yourself from our database.

References

   1. http://www.naturalherbal.biz/info/v/
   2. http://www.naturalherbal.biz/info/p/
   3. http://www.naturalherbal.biz/info/out.html


From mouring at etoh.eviladmin.org  Mon Sep 15 16:52:31 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 15 Sep 2003 01:52:31 -0500 (CDT)
Subject: SCO 3.2v4.2 and OpenSSH -current --> connection hangs and does
 no t close
In-Reply-To: <501BF453CDCFD111A6E40080C83DAC0402696820@PSICS001>
Message-ID: <Pine.BSO.4.44.0309150151340.842-100000@etoh.eviladmin.org>


 - (bal) redo how we handle 'mysignal()'.  Move it to
   openbsd-compat/bsd-misc.c, s/mysignal/signal/ and #define signal to
   be our 'mysignal' by default.  OK djm@

go into bsd-misc.c and comment out the define and try it again.  We should
be using mysignal by default now, but it may have disagreeable results.

- Ben

On Mon, 15 Sep 2003, Vikash Badal - PCS wrote:

> Greetings,
>
> I have a problem with OpenSSH -current and SCO 3.2v4.2,
> when I execute a remote command or exit from a session,
> the connection hangs, ( line 326 of serverloop.c).
>
> This problem only exists when using ssh2.
>
> server side debug (-d -d -d ):
> debug1: Received SIGCHLD.
> debug2: channel 0: read failed
> debug2: channel 0: close_read
> debug2: channel 0: input open -> drain
> debug2: channel 0: ibuf_empty delayed efd 12/(0)
> debug2: notify_done: reading
> debug2: channel 0: read 0 from efd 12
> debug2: channel 0: closing read-efd 12
> debug2: channel 0: ibuf empty
> debug2: channel 0: send eof
> debug2: channel 0: input drain -> closed
> -------------------
>
> I have tried my hand at gdb, and this is the output and backtrace
> before the session hangs.
>
> (gdb)
> wait_until_can_do_something (readsetp=0x7ffff8e4, writesetp=0x7ffff8e0,
>     maxfdp=0x7ffff8dc, nallocp=0x7ffff8d8, max_time_milliseconds=0)
>     at serverloop.c:313
> 313             if (child_terminated &&
> packet_not_very_much_data_to_write())
> (gdb)
> 317             if (max_time_milliseconds == 0)
> (gdb)
> 318                     tvp = NULL;
> (gdb)
> 326             ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
> (gdb) p connection_closed
> $1 = 0
> (gdb) bt
> #0  wait_until_can_do_something (readsetp=0x7ffff8e4, writesetp=0x7ffff8e0,
>     maxfdp=0x7ffff8dc, nallocp=0x7ffff8d8, max_time_milliseconds=0)
>     at serverloop.c:326
> #1  0x8bfc in server_loop2 (authctxt=0x42f91c) at serverloop.c:771
> #2  0x1030f in do_authenticated2 (authctxt=0x42f91c) at session.c:2086
> #3  0xcc19 in do_authenticated (authctxt=0x42f91c) at session.c:216
> #4  0x2eaa in main (ac=6, av=0x7ffffe28) at sshd.c:1506
> (gdb) s
>
> at this point the connection this hangs.
>
> I do not know how to process from here, please advise
>
> Vikash
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From VikashB at ComparexAfrica.co.za  Mon Sep 15 17:44:39 2003
From: VikashB at ComparexAfrica.co.za (Vikash Badal - PCS)
Date: Mon, 15 Sep 2003 09:44:39 +0200
Subject: SCO 3.2v4.2 and OpenSSH -current --> connection hangs and does n
	o t close
Message-ID: <501BF453CDCFD111A6E40080C83DAC0402696824@PSICS001>


> -----Original Message-----
> From: Ben Lindstrom 
> Sent: 15 September 2003 08:53
> To: Vikash Badal - PCS
> Cc: 'openssh-unix-dev at mindrot.org'
> Subject: Re: SCO 3.2v4.2 and OpenSSH -current --> connection hangs and
> does no t close
> 
 
> go into bsd-misc.c and comment out the define and try it 
> again.  We should
> be using mysignal by default now, but it may have 
> disagreeable results.
> 
> - Ben
> 
Commented out the 
#define signal (a,b) mysignal(a,b)
 in bsd-misc.h,

recompiled ( make clean && make )

still the same problem exists:
(gdb)
wait_until_can_do_something (readsetp=0x7ffff8e4, writesetp=0x7ffff8e0,
    maxfdp=0x7ffff8dc, nallocp=0x7ffff8d8, max_time_milliseconds=0)
    at serverloop.c:313
313             if (child_terminated &&
packet_not_very_much_data_to_write())
(gdb)
317             if (max_time_milliseconds == 0)
(gdb)
318                     tvp = NULL;
(gdb)
326             ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
(gdb) bt
#0  wait_until_can_do_something (readsetp=0x7ffff8e4, writesetp=0x7ffff8e0,
    maxfdp=0x7ffff8dc, nallocp=0x7ffff8d8, max_time_milliseconds=0)
    at serverloop.c:326
#1  0x8bfc in server_loop2 (authctxt=0x42f91c) at serverloop.c:771
#2  0x1030f in do_authenticated2 (authctxt=0x42f91c) at session.c:2086
#3  0xcc19 in do_authenticated (authctxt=0x42f91c) at session.c:216
#4  0x2eaa in main (ac=6, av=0x7ffffe28) at sshd.c:1506
(gdb) s


From markus at openbsd.org  Mon Sep 15 18:04:27 2003
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 15 Sep 2003 10:04:27 +0200
Subject: Trailing dot is not removed from client hostname
	if	HostbasedUsesNameFromPacketOnly is yes
In-Reply-To: <242379171.1063548025@[192.168.20.2]>
References: <3F62C510.9050509@taltos.org> <20030913153456.GC5647@folly>
	<242379171.1063548025@[192.168.20.2]>
Message-ID: <20030915080426.GA13516@folly>

On Sun, Sep 14, 2003 at 02:00:25PM -0400, Carson Gaspar wrote:
> 
> 
> --On Saturday, September 13, 2003 5:34 PM +0200 Markus Friedl 
> <markus at openbsd.org> wrote:
> 
> >AFAIK HostbasedUsesNameFromPacketOnly means: use the _exact_
> >value from the packet.  This is why the dot is not
> >removed.  Moreover, HostbasedUsesNameFromPacketOnly is
> >not recommended and experimental.  The client
> >needs to be changed to have truly random names in
> >the hostbased packets.
> 
> WTF? Why would you want random names?!

you might want to use UFQDN as in IKE.



From markus at openbsd.org  Mon Sep 15 18:05:24 2003
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 15 Sep 2003 10:05:24 +0200
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
In-Reply-To: <242341671.1063547987@[192.168.20.2]>
References: <115858843.1063421505@[192.168.20.2]> <20030913153328.GB5647@folly>
	<242341671.1063547987@[192.168.20.2]>
Message-ID: <20030915080524.GB13516@folly>

On Sun, Sep 14, 2003 at 01:59:47PM -0400, Carson Gaspar wrote:
> --On Saturday, September 13, 2003 5:33 PM +0200 Markus Friedl 
> <markus at openbsd.org> wrote:
> 
> >HostbasedUsesNameFromPacketOnly is experimental and
> >not documented. i think it violates the spec.
> 
> Can you please elaborate? From my point of view, it is the _only_ sane way 
> to operate, as anything else looks at useless (from a security perspective) 
> IP and DNS data, as opposed to the cryptographically authenticated data 
> sent by the client.
> 
> It also makes HostbasedAuthentication survive NAT, which is nice.

than add dot in shosts and it works.

this won't/cannot be changed for 3.7



From binder at arago.de  Mon Sep 15 19:30:10 2003
From: binder at arago.de (Thomas Binder)
Date: Mon, 15 Sep 2003 11:30:10 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F6544F8.A4EC80CC@zip.com.au>
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
	<Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net>
	<3F652E3E.2FF7E456@zip.com.au>
	<Pine.UW2.4.53.0309142135410.2212@ou8.int.multitalents.net>
	<3F6544F8.A4EC80CC@zip.com.au>
Message-ID: <20030915093010.GA10898291@ohm.arago.de>

Hi!

On Mon, Sep 15, 2003 at 02:50:00PM +1000, Darren Tucker wrote:
> > +       if [ -e regress/Makefile ]; then \
> >              ^^
> > -e is not portable.
> 
> Oops.  Is there a portable equivalent?

I usually use

if ls file-to-test >/dev/null 2>&1
then
	[...]
fi

for that, though it's a lot slower as it needs to run an external
command.

But aside from that, is -e actually what you want to use here? It
would also report OK for a directory, a fifo or a device named
Makefile (though you might consider that nitpicking). Wouldn't

[ -f regress/Makefile -a -r regress/Makefile ]

do what you want? -f reports OK for symlinks to a file as well, at
least with bash, Solaris /bin/sh and IRIX /bin/sh.


Ciao

Thomas



From tim at multitalents.net  Mon Sep 15 23:24:14 2003
From: tim at multitalents.net (Tim Rice)
Date: Mon, 15 Sep 2003 06:24:14 -0700 (PDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <3F6544F8.A4EC80CC@zip.com.au>
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org> 
	<Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net> 
	<3F652E3E.2FF7E456@zip.com.au>
	<Pine.UW2.4.53.0309142135410.2212@ou8.int.multitalents.net>
	<3F6544F8.A4EC80CC@zip.com.au>
Message-ID: <Pine.UW2.4.53.0309150621580.4362@ou8.int.multitalents.net>

On Mon, 15 Sep 2003, Darren Tucker wrote:

> Tim Rice wrote:
> > On Mon, 15 Sep 2003, Darren Tucker wrote:
> > +regressclean:
> > +       if [ -e regress/Makefile ]; then \
> >              ^^
> > -e is not portable.
> 
> Oops.  Is there a portable equivalent?

Just use -f

> 
> > Your patch could work (after fixing the -e) but I still think
> > generating Makefile at configure time is the way to go.
> > It would fix the "OBJ ?= `pwd`" problem too.
> 
> I thought that was already fixed?  Either OBJ is set by the top-level
> Makefile (for "make tests") or it's not set at all (for "make clean"). "rm
> -f $(OBJ)$$F" works either way.

Opps. I forgot I saw that change come through.


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




From gert at greenie.muc.de  Mon Sep 15 23:47:01 2003
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 15 Sep 2003 15:47:01 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <20030915093010.GA10898291@ohm.arago.de>;
	from binder@arago.de on Mon, Sep 15, 2003 at 11:30:10AM +0200
References: <Pine.BSO.4.44.0309131850240.29487-100000@etoh.eviladmin.org>
	<Pine.UW2.4.53.0309141211090.7890@ou8.int.multitalents.net>
	<3F652E3E.2FF7E456@zip.com.au>
	<Pine.UW2.4.53.0309142135410.2212@ou8.int.multitalents.net>
	<3F6544F8.A4EC80CC@zip.com.au>
	<20030915093010.GA10898291@ohm.arago.de>
Message-ID: <20030915154701.N28768@greenie.muc.de>

Hi,

On Mon, Sep 15, 2003 at 11:30:10AM +0200, Thomas Binder wrote:
> On Mon, Sep 15, 2003 at 02:50:00PM +1000, Darren Tucker wrote:
> > > +       if [ -e regress/Makefile ]; then \
> > >              ^^
> > > -e is not portable.
> > 
> > Oops.  Is there a portable equivalent?
> 
> I usually use
> 
> if ls file-to-test >/dev/null 2>&1
> then
> 	[...]
> fi

if [ -f ... ] ; then \
   ...;   \
fi

should be reasonably portable.  That is, it works on SCO 3.2v4.2.

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 at net.informatik.tu-muenchen.de



From carson at taltos.org  Tue Sep 16 04:17:49 2003
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 15 Sep 2003 14:17:49 -0400
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
In-Reply-To: <20030915080524.GB13516@folly>
References: <115858843.1063421505@[192.168.20.2]>
	<20030913153328.GB5647@folly>	<242341671.1063547987@[192.168.20.2]>
	<20030915080524.GB13516@folly>
Message-ID: <4540000.1063649869@taltos.ny.ficc.gs.com>


--On Monday, September 15, 2003 10:05:24 +0200 Markus Friedl 
<markus at openbsd.org> wrote:

> On Sun, Sep 14, 2003 at 01:59:47PM -0400, Carson Gaspar wrote:
>> --On Saturday, September 13, 2003 5:33 PM +0200 Markus Friedl
>> <markus at openbsd.org> wrote:
>>
>> > HostbasedUsesNameFromPacketOnly is experimental and
>> > not documented. i think it violates the spec.
>>
>> Can you please elaborate? From my point of view, it is the _only_ sane
>> way  to operate, as anything else looks at useless (from a security
>> perspective)  IP and DNS data, as opposed to the cryptographically
>> authenticated data  sent by the client.
>>
>> It also makes HostbasedAuthentication survive NAT, which is nice.
>
> than add dot in shosts and it works.
>
> this won't/cannot be changed for 3.7

No, it doesn't. Add a trailing dot in .shosts and in known_hosts and you 
get a crypto error. The option is completely broken in current CVS. Moving 
the trailing dot stripper up fixes it so it works just fine. You may 
_choose_ not to fix it for 3.7, but there's absolutely no reason that you 
couldn't, as it changes _nothing_ if you don't use 
HostbasedUsesNameFromPacketOnly, and fixes the option being broken. You 
just don't care if it works or not.

I really wonder why I bother wasting my time with this crap.

-- 
Carson





From markus at openbsd.org  Tue Sep 16 05:29:20 2003
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 15 Sep 2003 21:29:20 +0200
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
In-Reply-To: <4540000.1063649869@taltos.ny.ficc.gs.com>
References: <115858843.1063421505@[192.168.20.2]> <20030913153328.GB5647@folly>
	<242341671.1063547987@[192.168.20.2]>
	<20030915080524.GB13516@folly>
	<4540000.1063649869@taltos.ny.ficc.gs.com>
Message-ID: <20030915192920.GA14704@folly>

On Mon, Sep 15, 2003 at 02:17:49PM -0400, Carson Gaspar wrote:
> 
> --On Monday, September 15, 2003 10:05:24 +0200 Markus Friedl 
> <markus at openbsd.org> wrote:
> 
> >On Sun, Sep 14, 2003 at 01:59:47PM -0400, Carson Gaspar wrote:
> >>--On Saturday, September 13, 2003 5:33 PM +0200 Markus Friedl
> >><markus at openbsd.org> wrote:
> >>
> >>> HostbasedUsesNameFromPacketOnly is experimental and
> >>> not documented. i think it violates the spec.
> >>
> >>Can you please elaborate? From my point of view, it is the _only_ sane
> >>way  to operate, as anything else looks at useless (from a security
> >>perspective)  IP and DNS data, as opposed to the cryptographically
> >>authenticated data  sent by the client.
> >>
> >>It also makes HostbasedAuthentication survive NAT, which is nice.
> >
> >than add dot in shosts and it works.
> >
> >this won't/cannot be changed for 3.7
> 
> No, it doesn't. Add a trailing dot in .shosts and in known_hosts and you 
> get a crypto error.

crypto error?

> The option is completely broken in current CVS. Moving 

I don't see what's different from the last release.

I just tested HostbasedAuthentication again and it works
without problems.  Even with UseDNS=no.

> the trailing dot stripper up fixes it so it works just fine. You may 
> _choose_ not to fix it for 3.7, but there's absolutely no reason that you 
> couldn't, as it changes _nothing_ if you don't use 
> HostbasedUsesNameFromPacketOnly, and fixes the option being broken. You 

As I said before, I'm sorry it's too late to change this for 3.7.

Moreover, HostbasedUsesNameFromPacketOnly is experimental
and not a recommended.

> just don't care if it works or not.
> 
> I really wonder why I bother wasting my time with this crap.

-m



From newsletter at bellabyte.ch  Tue Sep 16 06:23:13 2003
From: newsletter at bellabyte.ch (BellaByte)
Date: Tue, 16 Sep 2003 06:23:13 +1000 (EST)
Subject: GRATIS und sehr guenstig
Message-ID: <20030915202313.69B7627C187@shitei.mindrot.org>

Der aktuelle Newsletter von BellaByte (September 2003)

Liebe Internauten
Auch im September-Newsletter haben wir wieder ein paar sehr interessante
Angebote, lassen Sie sich ueberraschen:

1. GRATIS GRATIS GRATIS
2. Professionelle Homepage fuer wenig Geld
3. Weihnachts-Kalender auf CD-Rom
4. Lebensqualitaet aus Finnland

++++++++++++++++++++++++++++++++++++++++++++++++++

1. GRATIS GRATIS GRATIS

Wir haben einige GRATIS-Angebote im Sortiment:

- Suchmaschinen-Anmeldungen, von GRATIS bis sehr guenstig.
   http://www.bellabyte.ch/search.php
- Online-Virenscanner um Ihr System zu ueberpruefen.
   http://www.bellabyte.ch/virus.php
- Anti-Viren-Tools um Ihr System zu desinfizieren.
   http://www.bellabyte.ch/virentools.php

++++++++++++++++++++++++++++++++++++++++++++++++++

2. Professionelle Homepage fuer wenig Geld

Bereiten Sie sich oder Ihre Firma auf den kommenden Aufschwung vor und
praesentieren Sie sich im Internet mit einer professionellen Homepage.
Die Zeit der selbst gebastelten Webseiten ist endgueltig vorbei.
Wir bieten Ihnen professionelle Einsteiger-Pakete zu sensationellen Preisen.
   http://www.bellabyte.ch/design.php

++++++++++++++++++++++++++++++++++++++++++++++++++

3. Weihnachts-Kalender auf CD-Rom

Der erste Weihnachts-Kalender auf CD-Rom mit 25 Kurzgeschichten zu
Weihnachten.
Vom 1. bis 25. Dezember oeffnet sich taeglich ein neues Bild-Puzzle in 5
Varianten mit anschliessender Kurzgeschichte zum Bild.
Machen Sie Ihren Kleinen eine Freude und sparen Sie erst noch 20% auf den
Normalpreis.
   http://www.bellabyte.ch/kalender.php

++++++++++++++++++++++++++++++++++++++++++++++++++

4. Lebensqualitaet aus Finnland

KOTA GRILL-, SAUNA- und FREIZEIT-Haeuser aus Finnland f?r Sie und Ihre
Freunde.

Ab CHF 7'800.-, Direktimport aus zuverlaessiger Hand.

Informationen:
IMPO GmbH, CH-8479 Altikon, Tel. +41 (0)52 336 23 75
Fax: +41 (0)52 338 11 36,  http://www.swissgeneralimport.ch

++++++++++++++++++++++++++++++++++++++++++++++++++

IMPRESSUM

Dies ist eine einmalige E-Mail.
Sollten Sie keine weiteren Newsletter erhalten wollen, so muessen Sie nichts
tun. Sind Sie an weiteren News von BelleByte interessiert, klicken Sie bitte
hier:
http://www.bellabyte.ch/newsletter.php

BellaByte, Rosenbergstrasse 23, CH-8212 Neuhausen

info at bellabyte.ch
http://www.bellabyte.ch



From wendyp at cray.com  Tue Sep 16 07:22:39 2003
From: wendyp at cray.com (Wendy Palm)
Date: Mon, 15 Sep 2003 16:22:39 -0500
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
References: <20030913175342.GA24719@basm.cerias.purdue.edu>	<Pine.BSO.4.44.0309131355240.29487-100000@etoh.eviladmin.org>	<20030913234221.GB24719@basm.cerias.purdue.edu>
	<3F63DD2E.AE9FB477@zip.com.au>
Message-ID: <3F662D9F.2080604@cray.com>

Crays make had the same problem brian reported.

i just downloaded the cvs tree and i'm not having a problem
with the regress makefile anymore.

Darren Tucker wrote:

> Brian Poole wrote:
> 
>>Mmmkay, error has changed at least.. this problem turns out to be in
>>spacing around the +=.. From the man page of Solaris make:
>>
>>     +=    When used in place of `=', appends a string to a macro
>>           definition  (must be surrounded by white space, unlike
>>           `=').
>>
>>Must be surrounded by white space.. adding that in (and a change
>>so we can see what exactly its cleaning) gives us:
>>
> 
> [snip]
> 
> 
>> USER!=         id -un
>>-CLEANFILES+=   authorized_keys_${USER} known_hosts pidfile \
>>+CLEANFILES   += authorized_keys_${USER} known_hosts pidfile \
>>
> 
> As it turns out, that extra space breaks AIX's native make.  Sigh.  It
> works without it, but with it you get:
> 
> "Makefile", line 6: make: 1254-055 Dependency line needs colon or double
> colon operator.
> "Makefile", line 43: make: 1254-055 Dependency line needs colon or double
> colon operator.
> make: 1254-058 Fatal errors encountered -- cannot continue.
> make: 1254-004 The error code from the last command is 2.
> 
> Anyone object to tossing out the "+=" like so?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: regress/Makefile
> ===================================================================
> RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- regress/Makefile	14 Sep 2003 01:40:36 -0000	1.9
> +++ regress/Makefile	14 Sep 2003 03:10:48 -0000
> @@ -3,7 +3,6 @@
>  REGRESS_TARGETS=	t1 t2 t3 t4 t5 t6 t7 t-exec
>  tests:		$(REGRESS_TARGETS)
>  
> -CLEANFILES +=	t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2
>  clean:
>  	for F in $(CLEANFILES); do rm -f $(OBJ)$$F; done
>  distclean:	clean
> @@ -36,7 +35,8 @@ LTESTS= 	connect \
>  		forwarding
>  
>  USER!=		id -un
> -CLEANFILES +=	authorized_keys_${USER} known_hosts pidfile \
> +CLEANFILES=	t2.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2 \
> +		authorized_keys_${USER} known_hosts pidfile \
>  		ssh_config ssh_proxy sshd_config sshd_proxy \
>  		rsa.pub rsa rsa1.pub rsa1 host.rsa host.rsa1 \
>  		rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub \
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From carson at taltos.org  Tue Sep 16 07:54:00 2003
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 15 Sep 2003 17:54:00 -0400
Subject: CVS is missing documentation for HostbasedUsesNameFromPacketOnly
In-Reply-To: <20030915192920.GA14704@folly>
References: <115858843.1063421505@[192.168.20.2]>
	<20030913153328.GB5647@folly>	<242341671.1063547987@[192.168.20.2]>
	<20030915080524.GB13516@folly>	<4540000.1063649869@taltos.ny.ficc.gs.com>
	<20030915192920.GA14704@folly>
Message-ID: <40680000.1063662840@taltos.ny.ficc.gs.com>



--On Monday, September 15, 2003 21:29:20 +0200 Markus Friedl 
<markus at openbsd.org> wrote:

> On Mon, Sep 15, 2003 at 02:17:49PM -0400, Carson Gaspar wrote:
>>
>>
>> No, it doesn't. Add a trailing dot in .shosts and in known_hosts and you
>> get a crypto error.
>
> crypto error?

I was getting a signature error, but I can no longer reproduce it after 
re-CVS-up'ing. I'll chalk it up to operator error.

Which means that yes, adding trailing dots (to both rhosts/shosts and 
known_hosts) works.

-- 
Carson



From Curtis.Steward at goodrich.com  Tue Sep 16 08:02:14 2003
From: Curtis.Steward at goodrich.com (STEWARD, Curtis (Jamestown))
Date: Mon, 15 Sep 2003 18:02:14 -0400
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
Message-ID: <809D3CD3C504D711A7810008C709B597368499@jamesx.jms.lucascargo.com>

Ok, this is what I did:

  1)  I reinstalled psyche (8.0) w/3.7p1 - no problems with OpenSSH.
  2)  Put on 3.7p1 on a vm (VMWare) - no problems with OpenSSH.
  3)  Put on my usual config onto vm - no problems with OpenSSH.
  4)  At this point I can only assume the other two examples
fail because of some bogus configuration that I can't duplicate...  
Anyways I proceeded in forcing the core dump and received a
memory access error on the old machine:

# gdb -q ./sshd core.27823
Core was generated by `./sshd -t'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libcrypto.so.2...done.
Loaded symbols for /lib/libcrypto.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x42028ac8 in raise () from /lib/i686/libc.so.6
#2  0x4202a019 in abort () from /lib/i686/libc.so.6
#3  0x080688b2 in buffer_get ()
Cannot access memory at address 0x3
(gdb)

It looks like I can run now despite the above, if you want 
to continue to pursue the memory problem let me know, I'll 
hang onto the problematic machine :)

cs

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Thursday, September 11, 2003 9:31 PM
To: STEWARD, Curtis (Jamestown)
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: 3.6p2 build errors on buffer_get with latest portable/SNAP


"STEWARD, Curtis (Jamestown)" wrote:
> I'm new to some of this so bear with me, I did post a
> buffer_get() error but while debugging I could make it fail
> on buffer_init() 31, weird.  Here's the bt without
> the continue:

> (gdb) bt
> #0  buffer_get (buffer=0xbffff210, buf=0x0, len=1) at buffer.c:124
> #1  0x00000000 in ?? ()

Hmm, there should be more here, I don't know what there isn't.

Plan B: if you insert an abort(); immediately before the fatal at
buffer.c:124 then run it normally, you should get a core dump which you
can generate the backtrace from.  It should look something like this:

# ./sshd -t
[core dumps]
# gdb -q ./sshd core
Core was generated by `./sshd -t'.
[snip]
#0  0x4020bfd1 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x4020bfd1 in kill () from /lib/libc.so.6
#1  0x4020bc94 in raise () from /lib/libc.so.6
#2  0x4020d04d in abort () from /lib/libc.so.6
#3  0x08062bd7 in buffer_get () at ../buffer.c:123
#4  0x08062a1c in buffer_get_char (buffer=0xbfffd4f0) at ../bufaux.c:262
#5  0x08061ac5 in key_load_public_rsa1 (fd=3,
    filename=0x8079e80 "/usr/local/etc/ssh_host_rsa_key", commentp=0x0)
    at ../authfile.c:268
#6  0x080622f3 in key_load_private (
    filename=0x8079e80 "/usr/local/etc/ssh_host_rsa_key",
    passphrase=0x8078c1a "", commentp=0x0) at ../authfile.c:573
#7  0x0804d8ae in main (ac=2, av=0x8092f68) at ../sshd.c:978
#8  0x401fa4ed in __libc_start_main () from /lib/libc.so.6

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



From samuel at bcgreen.com  Tue Sep 16 08:37:20 2003
From: samuel at bcgreen.com (Stephen Samuel)
Date: Mon, 15 Sep 2003 15:37:20 -0700
Subject: Trailing dot is not removed from client hostname
 if	HostbasedUsesNameFromPacketOnly is yes
In-Reply-To: <242379171.1063548025@[192.168.20.2]>
References: <3F62C510.9050509@taltos.org> <20030913153456.GC5647@folly>
	<242379171.1063548025@[192.168.20.2]>
Message-ID: <3F663F20.4010706@bcgreen.com>

Normallly a machine is considered to be part of a domain.
Nameservers use this fact to allow for short name lookups.

eg: let's say that  my machine is part of bcgreen.com.

If I do a nslookup for server , dns will normally look for
the tld of 'server'. Then it will look for server.bcgreen.com

similarly, a hunt for www.mindrott.org (note the double 't')
would cause a look for www.mindrot.org and then for www.mindrot.org.bcgreen.com

This gets real nasty if you have a wildcard for your domain...
eg: if i have
*.bcgreen.com 	IN	A 10.11.12.13
then the search for www.mindrot.org.bcgreen.com will return 10.11.12.13

On the other hand, if I specify www.mindrott.org. (note the trailing dot),
DNS recognizes that trailing dot as an indicator that this is EXACTLY the
name I'm looking for and DO NOT look for www.mindrot.org.bcgreen.com.

I just got bit by this the other day, where I was checking to see if
directory names corresponded to domain names,  The easy choice was to
simply do a `ping -c2 $dirname`  but it turns out that the machine I
was on was in a domain that had a wildcard DNS entry (grr!) so the
ping would always succeeed as some.filename.c.mydomain.com

ping -c2 ${dirname}.

did the trick.

Carson Gaspar wrote:
> 
> 
> --On Saturday, September 13, 2003 5:34 PM +0200 Markus Friedl 
> <markus at openbsd.org> wrote:
> 
>> AFAIK HostbasedUsesNameFromPacketOnly means: use the _exact_
>> value from the packet.  This is why the dot is not
>> removed.  Moreover, HostbasedUsesNameFromPacketOnly is
>> not recommended and experimental.  The client
>> needs to be changed to have truly random names in
>> the hostbased packets.
> 
> 
> WTF? Why would you want random names?!
> 


-- 
Stephen Samuel +1(604)876-0426                samuel at bcgreen.com
		   http://www.bcgreen.com/~samuel/
    Powerful committed communication. Transformation touching
        the jewel within each person and bring it to life.



From david-bronder at uiowa.edu  Tue Sep 16 10:23:50 2003
From: david-bronder at uiowa.edu (David Bronder)
Date: Mon, 15 Sep 2003 19:23:50 -0500 (CDT)
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
Message-ID: <200309160023.h8G0Noqp046080@fire.its.uiowa.edu>

I'm seeing a problem under AIX (4.3.3, 5.1, 5.2) very similar to bug
#178.  It occurs with both 3.6.1p1 and openssh-SNAP-20030910.

If /etc/nologin is present, a session requesting a pty will hang,
apparently when the sshd parent tries to close the pty slave.  As in
bug #178, adding a brief sleep to the child sshd anytime after the fork
seems to clear up the problem (though I agree that this is not the
correct solution).  It seems as Darren suggested in #178 that it may be
a timing thing, only for me the hang is the rule, not the exception.

In this case, with the nologin exception to the AIX loginrestrictions()
code, the program continues and the child calls do_nologin().  However,
just like in bug #178, the nologin output is not seen by the client.
The child's fflush() call added to do_nologin() by bug #178 does not
solve the problem for me.

It's almost as though, if the child exits before the parent closes the
pty slave, the hang occurs; but if the parent closes the pty slave and
then the child exits, everything works correctly (based on the fact
that it works with the sleep and doesn't without).  Pty games aren't my
strong suit, and I'm out of ideas at the moment.

Is anyone else seeing this behavior, or is it just me?

I can provide full (-ddd, -vvv) debugging if anyone would like to see
it.  I'm not doing anything especially odd with the build options:

  ./configure --libexecdir='${exec_prefix}/bin' --sysconfdir=/etc/ssh 
              --with-pid-dir=/etc/ssh --with-privsep-path=/var/empty/sshd
              --with-tcp-wrappers=/usr/local --with-kerberos5=/usr/local
              --with-cflags="-O3 -qstrict"

I did try w/o Kerberos, not expecting and not seeing any difference
in the problem behavior.  /etc/ssh/sshd_config only differs from the
defaults by enabling X11Forwarding, restricting to protocol 2, and
disabling Compression.

Thanks for any insight (or solutions! :).

=Dave

-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu



From Zube at CS.ColoState.EDU  Tue Sep 16 11:08:23 2003
From: Zube at CS.ColoState.EDU (Zube)
Date: Mon, 15 Sep 2003 19:08:23 -0600
Subject: two potentially troubling posts to full-disclosure
Message-ID: <20030916010823.GA18869@mozart.cs.colostate.edu>

I haven't seen anything about this here and thought I should pass it along.
christopher neitzert <chris at neitzert.com> made two postings to the 
full-disclosure list earlier today.  They stated, in part:

*****
Does anyone know of or have source related to a new, and unpublished ssh
exploit?  An ISP I work with has filtered all SSH connections due to
several root level incidents involving ssh. Any information is
appreciated.
*****

and later:

*****
More on this;

The systems in question are FreeBSD, RedHat, Gentoo, and Debian all
running the latest versions of OpenSSH.

The attack makes an enormous amount of ssh connections and attempts
various offsets until it finds one that works permitting root login.

I have received numerous messages from folks requesting anonymity or
direct-off-list-reply confirming this exploit;
*****

Later, Justin Kreger <jkreger at lwolenczak.net> reported that he had heard
that privsec had been enabled on the compromised machines.

I am aware that much of this is hearsay, but sometimes smoke -> fire. 
Anyone have any further information?

Cheers,
Zube  



From dtucker at zip.com.au  Tue Sep 16 11:29:54 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Sep 2003 11:29:54 +1000
Subject: 3.6p2 build errors on buffer_get with latest portable/SNAP
References: <809D3CD3C504D711A7810008C709B597368499@jamesx.jms.lucascargo.com>
Message-ID: <3F666792.319D0EDF@zip.com.au>

"STEWARD, Curtis (Jamestown)" wrote:
> 
> Ok, this is what I did:
> 
>   1)  I reinstalled psyche (8.0) w/3.7p1 - no problems with OpenSSH.
>   2)  Put on 3.7p1 on a vm (VMWare) - no problems with OpenSSH.
>   3)  Put on my usual config onto vm - no problems with OpenSSH.
>   4)  At this point I can only assume the other two examples
> fail because of some bogus configuration that I can't duplicate...
> Anyways I proceeded in forcing the core dump and received a
> memory access error on the old machine:

I don't know what else to suggest, other than "it's something odd with
that machine", possibly one of the libraries trashing the heap.

If you're now running happily, I'd just forget about it and move on.

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



From dtucker at zip.com.au  Tue Sep 16 11:34:15 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Sep 2003 11:34:15 +1000
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
References: <200309160023.h8G0Noqp046080@fire.its.uiowa.edu>
Message-ID: <3F666897.8A5124AD@zip.com.au>

David Bronder wrote:
> I'm seeing a problem under AIX (4.3.3, 5.1, 5.2) very similar to bug
> #178.  It occurs with both 3.6.1p1 and openssh-SNAP-20030910.
>
> If /etc/nologin is present, a session requesting a pty will hang,
> apparently when the sshd parent tries to close the pty slave.

That's not something I test often but last time I did it worked OK for me
(on AIX 5.2).

What maintenance levels do you have on your boxes, and which SSH client
(and protocol version) are you using?

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



From david-bronder at uiowa.edu  Tue Sep 16 13:18:45 2003
From: david-bronder at uiowa.edu (David Bronder)
Date: Mon, 15 Sep 2003 22:18:45 -0500 (CDT)
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
In-Reply-To: <3F666897.8A5124AD@zip.com.au> from "Darren Tucker" at Sep 16,
	2003 11:34:15 AM
Message-ID: <200309160318.h8G3IjwZ043490@fire.its.uiowa.edu>

Darren Tucker wrote:
> 
> David Bronder wrote:
> > I'm seeing a problem under AIX (4.3.3, 5.1, 5.2) very similar to bug
> > #178.  It occurs with both 3.6.1p1 and openssh-SNAP-20030910.
> >
> > If /etc/nologin is present, a session requesting a pty will hang,
> > apparently when the sshd parent tries to close the pty slave.
> 
> That's not something I test often but last time I did it worked OK for me
> (on AIX 5.2).

Just retried on an AIX 5.2 ML1 box with 3.6.1p1 and reproduced the
problem with both authorized key and password authentication.

> What maintenance levels do you have on your boxes, and which SSH client
> (and protocol version) are you using?

Running on AIX 4.3.3 ML11, 5.1 ML3 and ML4, and 5.2 ML1; built on 4.3.3
ML11, 5.1 ML3 and 5.2 ML1.  Protocol 2 in all cases, with clients from
the same OpenSSH versions on AIX 5.1 ML3 and RedHat 9, as well as
SecureCRT 4.0.  Just gave it a try with protocol 1 on a 5.2 ML1 box
(from 3.6.1p1 client on 5.1 ML3) and it seems to behave the same way
(though I haven't dug into the code path yet to see if it's really the
same thing, it definitely hangs).

=Dave

-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu



From dtucker at zip.com.au  Tue Sep 16 17:52:44 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Sep 2003 17:52:44 +1000
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
References: <200309160318.h8G3IjwZ043490@fire.its.uiowa.edu>
Message-ID: <3F66C14C.A385435C@zip.com.au>

David Bronder wrote:
> Just retried on an AIX 5.2 ML1 box with 3.6.1p1 and reproduced the
> problem with both authorized key and password authentication.

One other thing: how big is the /etc/nologin file?

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



From david-bronder at uiowa.edu  Tue Sep 16 18:04:23 2003
From: david-bronder at uiowa.edu (David Bronder)
Date: Tue, 16 Sep 2003 03:04:23 -0500 (CDT)
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
In-Reply-To: <3F66C14C.A385435C@zip.com.au> from "Darren Tucker" at Sep 16,
	2003 05:52:44 PM
Message-ID: <200309160804.h8G84N2N044900@fire.its.uiowa.edu>

Darren Tucker wrote:
> 
> David Bronder wrote:
> > Just retried on an AIX 5.2 ML1 box with 3.6.1p1 and reproduced the
> > problem with both authorized key and password authentication.
> 
> One other thing: how big is the /etc/nologin file?

For the purpose of testing, I've tried one line with just the text
"testing sshd and nologin" (including newline at the end), and two
short lines of text with a blank line between (60-odd bytes).

-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu



From dtucker at zip.com.au  Tue Sep 16 18:26:30 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Sep 2003 18:26:30 +1000
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
References: <200309160804.h8G84N2N044900@fire.its.uiowa.edu>
Message-ID: <3F66C936.31D7B993@zip.com.au>

David Bronder wrote:
> For the purpose of testing, I've tried one line with just the text
> "testing sshd and nologin" (including newline at the end), and two
> short lines of text with a blank line between (60-odd bytes).

I just tried it with the current CVS tree (AIX 5.1 ML4) and it worked
(although it printed the contents of nologin twice, not sure why).  No
hangs though.  Will build and test 3.6.1p1 to match your config.

$ ssh zilker  -p 2022
testing sshd and nologin

User dtucker not allowed because /etc/nologin exists
testing sshd and nologin

Connection to zilker closed.

Hmm, actually I think the contents of /etc/nologin gets returned by
loginrestrictions() which would explain why it got printed twice: once by
printf("%s", loginmsg) and once by do_motd.

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



From dtucker at zip.com.au  Tue Sep 16 19:01:20 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Sep 2003 19:01:20 +1000
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
References: <200309160804.h8G84N2N044900@fire.its.uiowa.edu>
	<3F66C936.31D7B993@zip.com.au>
Message-ID: <3F66D160.6C121DCD@zip.com.au>

Darren Tucker wrote:
> 
> David Bronder wrote:
> > For the purpose of testing, I've tried one line with just the text
> > "testing sshd and nologin" (including newline at the end), and two
> > short lines of text with a blank line between (60-odd bytes).
> 
> I just tried it with the current CVS tree (AIX 5.1 ML4) and it worked
> (although it printed the contents of nologin twice, not sure why).  No
> hangs though.  Will build and test 3.6.1p1 to match your config.

3.6.1p1 worked fine for me too.

A hunch: does this patch make a difference?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: session.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v
retrieving revision 1.232
diff -u -p -r1.232 session.c
--- session.c	21 Mar 2003 01:18:09 -0000	1.232
+++ session.c	16 Sep 2003 08:59:09 -0000
@@ -1197,7 +1197,8 @@ do_nologin(struct passwd *pw)
 		while (fgets(buf, sizeof(buf), f))
 			fputs(buf, stderr);
 		fclose(f);
-		fflush(NULL);
+		fflush(stderr);
+		close(STDERR_FILENO);
 		exit(254);
 	}
 }

From markus at openbsd.org  Tue Sep 16 22:07:00 2003
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 16 Sep 2003 14:07:00 +0200
Subject: OpenSSH 3.7 released
Message-ID: <20030916120700.GA26891@folly>

OpenSSH 3.7 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu

Security Changes:
=================

  All versions of OpenSSH's sshd prior to 3.7 contain a buffer
  management error.  It is uncertain whether this error is
  potentially exploitable, however, we prefer to see bugs
  fixed proactively.

  OpenSSH 3.7 fixes this bug.

Changes since OpenSSH 3.6.1:
============================ 

* The entire OpenSSH code-base has undergone a license review. As
  a result, all non-ssh1.x code is under a BSD-style license with no
  advertising requirement. Please refer to README in the source
  distribution for the exact license terms.

* Rhosts authentication has been removed in ssh(1) and sshd(8).

* Changes in Kerberos support:

    - KerberosV password support now uses a file cache instead of
      a memory cache.

    - KerberosIV and AFS support has been removed.

    - KerberosV support has been removed from SSH protocol 1.

    - KerberosV password authentication support remains for SSH
      protocols 1 and 2.

    - This release contains some GSSAPI user authentication support
      to replace legacy KerberosV authentication support. At present
      this code is still considered experimental and SHOULD NOT BE
      USED.
  
* Changed order that keys are tried in public key authentication.
  The ssh(1) client tries the keys in the following order:

     1. ssh-agent(1) keys that are found in the ssh_config(5) file
     2. remaining ssh-agent(1) keys
     3. keys that are only listed in the ssh_config(5) file

  This helps when an ssh-agent(1) has many keys, where the sshd(8)
  server might close the connection before the correct key is tried.

* SOCKS5 support has been added to the dynamic forwarding mode
  in ssh(1).

* Removed implementation barriers to operation of SSH over SCTP.

* sftp(1) client can now transfer files with quote characters in
  their filenames.

* Replaced sshd(8)'s VerifyReverseMapping with UseDNS option.
  When UseDNS option is on, reverse hostname lookups are always
  performed.

* Fix a number of memory leaks.

* Support for sending tty BREAK over SSH protocol 2.

* Workaround for other vendor bugs in KEX guess handling.

* Support for generating KEX-GEX groups (/etc/moduli) in ssh-keygen(1).

* Automatic re-keying based on amount of data sent over connection.

* New AddressFamily option on client to select protocol to use (IPv4
  or IPv6).

* Experimental support for the "aes128-ctr", "aes192-ctr", and
  "aes256-ctr" ciphers for SSH protocol 2.

* Experimental support for host keys in DNS (draft-ietf-secsh-dns-xx.txt).
  Please see README.dns in the source distribution for details.

* Portable OpenSSH:

    - Replace PAM password authentication kludge with a more correct
      PAM challenge-response module from FreeBSD.

    - PAM support may now be enabled/disabled at runtime using the
      UsePAM directive.

    - Many improvements to the OpenSC smartcard support.

    - Regression tests now work with portable OpenSSH.
      Please refer to regress/README.regress in the source distribution.

    - On platforms that support it, portable OpenSSH now honors the
      UMASK, PATH and SUPATH attributes set in /etc/default/login.

    - Deny access to locked accounts, regardless of authentication
      method in use.

Checksums:
==========

- MD5 (openssh-3.7.tgz) = 86864ecc276c5f75b06d4872a553fa70
- MD5 (openssh-3.7p1.tar.gz) = 77662801ba2a9cadc0ac10054bc6cb37


Reporting Bugs:
===============

- please read http://www.openssh.com/report.html
  and http://bugzilla.mindrot.org/

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



From markus at openbsd.org  Tue Sep 16 22:32:19 2003
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 16 Sep 2003 14:32:19 +0200
Subject: OpenSSH Security Advisory: buffer.adv
Message-ID: <20030916123219.GA7772@folly>

This is the 1st revision of the Advisory.

This document can be found at:  http://www.openssh.com/txt/buffer.adv

1. Versions affected:

        All versions of OpenSSH's sshd prior to 3.7 contain a buffer
        management error.  It is uncertain whether this error is
        potentially exploitable, however, we prefer to see bugs
        fixed proactively.

2. Solution:

	Upgrade to OpenSSH 3.7 or apply the following patch.

Appendix:

Index: buffer.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- buffer.c	26 Jun 2002 08:54:18 -0000	1.16
+++ buffer.c	16 Sep 2003 03:03:47 -0000	1.17
@@ -69,6 +69,7 @@
 void *
 buffer_append_space(Buffer *buffer, u_int len)
 {
+	u_int newlen;
 	void *p;
 
 	if (len > 0x100000)
@@ -98,11 +99,13 @@
 		goto restart;
 	}
 	/* Increase the size of the buffer and retry. */
-	buffer->alloc += len + 32768;
-	if (buffer->alloc > 0xa00000)
+	
+	newlen = buffer->alloc + len + 32768;
+	if (newlen > 0xa00000)
 		fatal("buffer_append_space: alloc %u not supported",
-		    buffer->alloc);
-	buffer->buf = xrealloc(buffer->buf, buffer->alloc);
+		    newlen);
+	buffer->buf = xrealloc(buffer->buf, newlen);
+	buffer->alloc = newlen;
 	goto restart;
 	/* NOTREACHED */
 }



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 01:01:13 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Tue, 16 Sep 2003 10:01:13 -0500
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
Message-ID: <20030916150113.GA46811@spuckler.il.thewrittenword.com>

On IRIX 6.5:
cc -Wl,-woff,84 -Wl,-woff,85 -woff 1429 -O2
-I/opt/TWWfsw/tcpwrap/include -I. -I.. -I. -I./..
-I/opt/TWWfsw/libopenssl097s/include -I/opt/TWWfsw/zlib11s/include
-DHAVE_CONFIG_H -c inet_ntoa.c
cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5
  #error directive:  This header file is to be used only for c99 mode
          compilations

  #error This header file is to be used only for c99 mode compilations
   ^

cc-1005 cc: ERROR File = inet_ntoa.c, Line = 46
  The source file "inet_ntoa.h" is unavailable.

  #include "inet_ntoa.h"
                        ^
Is openbsd-compat/inet_ntoa.h missing or is openbsd-compat/inet_ntoa.c
wrong?

-- 
albert chin (china at thewrittenword.com)



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 01:17:44 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Tue, 16 Sep 2003 10:17:44 -0500
Subject: openbsd-compat/port-aix.c fix for 3.7p1
Message-ID: <20030916151744.GA47276@spuckler.il.thewrittenword.com>

1. Need a prototype for get_canonical_hostname().
2. -I.. is used to build port-aix.c so why not just #include
   <xmalloc.h> rather than <../xmalloc.h>?

-- 
albert chin (china at thewrittenword.com)

-- snip snip
--- openbsd-compat/port-aix.c.orig	Tue Sep 16 10:07:47 2003
+++ openbsd-compat/port-aix.c	Tue Sep 16 10:08:09 2003
@@ -27,11 +27,12 @@
 #include "ssh.h"
 #include "log.h"
 #include "servconf.h"
+#include "canohost.h"
 
 #ifdef _AIX
 
 #include <uinfo.h>
-#include <../xmalloc.h>
+#include <xmalloc.h>
 #include "port-aix.h"
 
 extern ServerOptions options;



From serge.droz at psi.ch  Wed Sep 17 01:18:10 2003
From: serge.droz at psi.ch (Serge Droz)
Date: Tue, 16 Sep 2003 17:18:10 +0200
Subject: OpenSSH 3.7 released
In-Reply-To: <20030916120700.GA26891@folly>
References: <20030916120700.GA26891@folly>
Message-ID: <3F6729B2.2050505@psi.ch>

...
> Security Changes:
> =================
> 
>   All versions of OpenSSH's sshd prior to 3.7 contain a buffer
>   management error.  It is uncertain whether this error is
>   potentially exploitable, however, we prefer to see bugs
>   fixed proactively.
> 
>   OpenSSH 3.7 fixes this bug.
> 
  Great !

> Changes since OpenSSH 3.6.1:
> ============================ 
.> * Changes in Kerberos support:
> 
>     - KerberosV password support now uses a file cache instead of
>       a memory cache.
> 
>     - KerberosIV and AFS support has been removed.

Could you release just the patch for the security fix?
We do need AFS support and thus can't just roll out 3.7

Cheers
Serge



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



From eric-list-openssh at catastrophe.net  Wed Sep 17 00:43:10 2003
From: eric-list-openssh at catastrophe.net (Eric)
Date: Tue, 16 Sep 2003 09:43:10 -0500
Subject: OpenBSD 3.3 x86 Build Problem
Message-ID: <20030916094310.Q86384@catastrophe.net>


I'm seeing this on a clean build after downloading 3.7 to my
OpenBSD source tree...

 bash-2.05b# make

 [...]

 ===> lib
 ===> ssh
 ===> sshd
 cc   -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o
 auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o
 uidswap.o auth.o auth1.o auth2.o auth-options.o session.o
 auth-chall.o auth2-chall.o groupaccess.o auth-skey.o
 auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o
 auth2-passwd.o auth2-pubkey.o monitor_mm.o monitor.o
 monitor_wrap.o monitor_fdpass.o kexdhs.o kexgexs.o auth-krb5.o
 auth2-gss.o gss-serv.o gss-serv-krb5.o
 -L/var/src/usr.bin/ssh/sshd/../lib/obj -lssh -lgssapi -lkrb5
 -lcrypto -lutil -lz -ldes -lwrap
 gss-serv-krb5.o: Undefined symbol `_gss_krb5_copy_ccache'
 referenced from text segment
 collect2: ld returned 1 exit status
 *** Error code 1
 
 Stop in /var/src/usr.bin/ssh/sshd (line 122 of
 /usr/share/mk/bsd.prog.mk).
 *** Error code 1
 
 Stop in /var/src/usr.bin/ssh.

Does anything need to be sync'ed in the source tree?

I'm on OpenBSD 3.3, x86.

Thanks.

- Eric



From david-bronder at uiowa.edu  Wed Sep 17 01:58:34 2003
From: david-bronder at uiowa.edu (David Bronder)
Date: Tue, 16 Sep 2003 10:58:34 -0500 (CDT)
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
In-Reply-To: <3F66D160.6C121DCD@zip.com.au> from "Darren Tucker" at Sep 16,
	2003 07:01:20 PM
Message-ID: <200309161558.h8GFwYeS045708@fire.its.uiowa.edu>

Darren Tucker wrote:
> 
> Darren Tucker wrote:
> > 
> > David Bronder wrote:
> > > For the purpose of testing, I've tried one line with just the text
> > > "testing sshd and nologin" (including newline at the end), and two
> > > short lines of text with a blank line between (60-odd bytes).
> > 
> > I just tried it with the current CVS tree (AIX 5.1 ML4) and it worked
> > (although it printed the contents of nologin twice, not sure why).  No
> > hangs though.  Will build and test 3.6.1p1 to match your config.
> 
> 3.6.1p1 worked fine for me too.
> 
> A hunch: does this patch make a difference?

Nope, no joy.  I tried explicitly flushing stdout and stderr when I
was testing prior to posting to the list, but I hadn't tried closing
stderr.

One thought I had about differences between my failing config and your
working config is compilers.  I'm using IBM's VAC 6.0.0.2 compliler.

(Of course, this little problem will take a back seat to getting 3.7p1
out in light of the big security vulnerability hubbub.)

=Dave

> Index: session.c
> ===================================================================
> RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v
> retrieving revision 1.232
> diff -u -p -r1.232 session.c
> --- session.c	21 Mar 2003 01:18:09 -0000	1.232
> +++ session.c	16 Sep 2003 08:59:09 -0000
> @@ -1197,7 +1197,8 @@ do_nologin(struct passwd *pw)
>  		while (fgets(buf, sizeof(buf), f))
>  			fputs(buf, stderr);
>  		fclose(f);
> -		fflush(NULL);
> +		fflush(stderr);
> +		close(STDERR_FILENO);
>  		exit(254);
>  	}
>  }


-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu



From dtucker at zip.com.au  Wed Sep 17 02:11:50 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 02:11:50 +1000
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
References: <200309161558.h8GFwYeS045708@fire.its.uiowa.edu>
Message-ID: <3F673646.950DDF45@zip.com.au>

David Bronder wrote:
> One thought I had about differences between my failing config and your
> working config is compilers.  I'm using IBM's VAC 6.0.0.2 compliler.

I'm using gcc-3.3.

In one of the 4.3.3 maintenance releases, IBM made some changes to the pty
driver that caused some problems: from memory it was a zero-length write
to the pty would result in a zero-length read on the pty, which sshd (and
POSIX :-) interpret to mean a read failure.  Sshd would then close the
session (since it thought the pty had closed).  This resulted in the
session hanging.

I'm wondering if it's related (and it makes me wonder about races hiding
in the pty layer).

Hmm, timing.  What speed are your systems?  Mine's a 375 MHz 7043.

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



From vinschen at redhat.com  Wed Sep 17 00:57:57 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 16 Sep 2003 16:57:57 +0200
Subject: [PATCH] permanently_set_uid fails on Cygwin :-(
In-Reply-To: <20030916145309.GR9981@cygbert.vinschen.de>
References: <20030916145309.GR9981@cygbert.vinschen.de>
Message-ID: <20030916145757.GS9981@cygbert.vinschen.de>

On Tue, Sep 16, 2003 at 04:53:09PM +0200, Corinna Vinschen wrote:
> Index: uidswap.c

Sigh, new patch.  Should be #ifndef, not #ifdef.

Corinna

===================================================================
RCS file: /cvs/openssh_cvs/uidswap.c,v
retrieving revision 1.39
diff -p -u -r1.39 uidswap.c
--- uidswap.c	6 Sep 2003 06:44:39 -0000	1.39
+++ uidswap.c	16 Sep 2003 14:47:54 -0000
@@ -191,10 +191,12 @@ permanently_set_uid(struct passwd *pw)
 		    (u_int)pw->pw_gid);
 	}
 
+#ifndef HAVE_CYGWIN
 	/* Try restoration of UID if changed (test clearing of saved uid) */
 	if (old_uid != pw->pw_uid && 
 	    (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
 		fatal("%s: was able to restore old [e]uid", __func__);
+#endif
 
 	/* Verify UID drop was successful */
 	if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) {


-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From david-bronder at uiowa.edu  Wed Sep 17 03:19:23 2003
From: david-bronder at uiowa.edu (David Bronder)
Date: Tue, 16 Sep 2003 12:19:23 -0500 (CDT)
Subject: 3.6.1p1/SNAP-20030910, AIX & /etc/nologin (similar to bug #178)
In-Reply-To: <3F673646.950DDF45@zip.com.au> from "Darren Tucker" at Sep 17,
	2003 02:11:50 AM
Message-ID: <200309161719.h8GHJNUm045132@fire.its.uiowa.edu>

Darren Tucker wrote:
> 
> David Bronder wrote:
> > One thought I had about differences between my failing config and your
> > working config is compilers.  I'm using IBM's VAC 6.0.0.2 compliler.
> 
> I'm using gcc-3.3.
> 
> In one of the 4.3.3 maintenance releases, IBM made some changes to the pty
> driver that caused some problems: from memory it was a zero-length write
> to the pty would result in a zero-length read on the pty, which sshd (and
> POSIX :-) interpret to mean a read failure.  Sshd would then close the
> session (since it thought the pty had closed).  This resulted in the
> session hanging.
> 
> I'm wondering if it's related (and it makes me wonder about races hiding
> in the pty layer).

I knew there was a reason I didn't like mucking around with ptys.

> Hmm, timing.  What speed are your systems?  Mine's a 375 MHz 7043.

I'm doing my main testing on the same, but it doubles as my desktop, so
it's a little resource-starved (X, Netscape, etc.).  I've seen it occur
consistently on an idle box of the same class, though.

Just tried it on a 2x450 7026-H80 that's less loaded at this instant,
and everything worked like it should.  I know I've seen it hang on
higher-end boxes though.  I've also seen it work correctly, rarely, on
the 7043.

=Dave

-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu



From gem at rellim.com  Wed Sep 17 03:32:34 2003
From: gem at rellim.com (Gary E. Miller)
Date: Tue, 16 Sep 2003 10:32:34 -0700 (PDT)
Subject: OpenSSH 3.7 released
In-Reply-To: <20030916120700.GA26891@folly>
References: <20030916120700.GA26891@folly>
Message-ID: <Pine.LNX.4.58.0309161031590.30110@catbert.rellim.com>

Yo Markus and Co.!

On Tue, 16 Sep 2003, Markus Friedl wrote:

> OpenSSH 3.7 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.

Hooray!  Once again a great job well done!

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676



From vinschen at redhat.com  Wed Sep 17 00:53:09 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 16 Sep 2003 16:53:09 +0200
Subject: [PATCH] permanently_set_uid fails on Cygwin :-(
Message-ID: <20030916145309.GR9981@cygbert.vinschen.de>

Hi,

I'm terribly sorry that I missed this before 3.7p1 was out.  The
permanently_set_uid() function fails on Cygwin since the test to
revert to the saved uid unfortunately works on Cygwin though it
shouldn't.  The reason is that a Windows NT process always can
revert to its previous privileges.  There's no such concept of
giving up rights in a process permanently. This is only possible
for a child process.

Corinna


Index: uidswap.c
===================================================================
RCS file: /cvs/openssh_cvs/uidswap.c,v
retrieving revision 1.39
diff -p -u -r1.39 uidswap.c
--- uidswap.c	6 Sep 2003 06:44:39 -0000	1.39
+++ uidswap.c	16 Sep 2003 14:47:54 -0000
@@ -191,10 +191,12 @@ permanently_set_uid(struct passwd *pw)
 		    (u_int)pw->pw_gid);
 	}
 
+#ifdef HAVE_CYGWIN
 	/* Try restoration of UID if changed (test clearing of saved uid) */
 	if (old_uid != pw->pw_uid && 
 	    (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
 		fatal("%s: was able to restore old [e]uid", __func__);
+#endif
 
 	/* Verify UID drop was successful */
 	if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) {


-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From mouring at etoh.eviladmin.org  Wed Sep 17 04:37:21 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 16 Sep 2003 13:37:21 -0500 (CDT)
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
In-Reply-To: <20030916150113.GA46811@spuckler.il.thewrittenword.com>
Message-ID: <Pine.BSO.4.44.0309161336410.842-100000@etoh.eviladmin.org>



On Tue, 16 Sep 2003, Albert Chin wrote:

[..]
>   The source file "inet_ntoa.h" is unavailable.
>
>   #include "inet_ntoa.h"
>                         ^
> Is openbsd-compat/inet_ntoa.h missing or is openbsd-compat/inet_ntoa.c
> wrong?
>

It was merged into openbsd-compat.h.  I corrected this issue this morning.
So just remove the #include file.  It is dead code.

- Ben



From mouring at etoh.eviladmin.org  Wed Sep 17 04:38:07 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 16 Sep 2003 13:38:07 -0500 (CDT)
Subject: OpenSSH 3.7 released
In-Reply-To: <3F6729B2.2050505@psi.ch>
Message-ID: <Pine.BSO.4.44.0309161338010.842-100000@etoh.eviladmin.org>


http://www.openssh.com/txt/buffer.adv

Includes patch

On Tue, 16 Sep 2003, Serge Droz wrote:

> ...
> > Security Changes:
> > =================
> >
> >   All versions of OpenSSH's sshd prior to 3.7 contain a buffer
> >   management error.  It is uncertain whether this error is
> >   potentially exploitable, however, we prefer to see bugs
> >   fixed proactively.
> >
> >   OpenSSH 3.7 fixes this bug.
> >
>   Great !
>
> > Changes since OpenSSH 3.6.1:
> > ============================
> .> * Changes in Kerberos support:
> >
> >     - KerberosV password support now uses a file cache instead of
> >       a memory cache.
> >
> >     - KerberosIV and AFS support has been removed.
>
> Could you release just the patch for the security fix?
> We do need AFS support and thus can't just roll out 3.7
>
> Cheers
> Serge
>
>
>
> --
> Serge Droz
> Paul Scherrer Institut                mailto:serge.droz at psi.ch
> CH-5232 Villigen PSI                   Phone: ++41 56 310 3637
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mouring at etoh.eviladmin.org  Wed Sep 17 04:42:57 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 16 Sep 2003 13:42:57 -0500 (CDT)
Subject: OpenBSD 3.3 x86 Build Problem
In-Reply-To: <20030916094310.Q86384@catastrophe.net>
Message-ID: <Pine.BSO.4.44.0309161341300.842-100000@etoh.eviladmin.org>


Assuming you don't need Kerb you can do:

KERBEROS5=no make

I was fighting with this problem before we had to release 3.7.  I have no
solution for those that require kerb. =(

- Ben

On Tue, 16 Sep 2003, Eric wrote:

>
> I'm seeing this on a clean build after downloading 3.7 to my
> OpenBSD source tree...
>
>  bash-2.05b# make
>
>  [...]
>
>  ===> lib
>  ===> ssh
>  ===> sshd
>  cc   -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o
>  auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o
>  uidswap.o auth.o auth1.o auth2.o auth-options.o session.o
>  auth-chall.o auth2-chall.o groupaccess.o auth-skey.o
>  auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o
>  auth2-passwd.o auth2-pubkey.o monitor_mm.o monitor.o
>  monitor_wrap.o monitor_fdpass.o kexdhs.o kexgexs.o auth-krb5.o
>  auth2-gss.o gss-serv.o gss-serv-krb5.o
>  -L/var/src/usr.bin/ssh/sshd/../lib/obj -lssh -lgssapi -lkrb5
>  -lcrypto -lutil -lz -ldes -lwrap
>  gss-serv-krb5.o: Undefined symbol `_gss_krb5_copy_ccache'
>  referenced from text segment
>  collect2: ld returned 1 exit status
>  *** Error code 1
>
>  Stop in /var/src/usr.bin/ssh/sshd (line 122 of
>  /usr/share/mk/bsd.prog.mk).
>  *** Error code 1
>
>  Stop in /var/src/usr.bin/ssh.
>
> Does anything need to be sync'ed in the source tree?
>
> I'm on OpenBSD 3.3, x86.
>
> Thanks.
>
> - Eric
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From ayamura at ayamura.org  Wed Sep 17 04:43:22 2003
From: ayamura at ayamura.org (Ayamura KIKUCHI)
Date: Wed, 17 Sep 2003 03:43:22 +0900
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
In-Reply-To: <20030916150113.GA46811@spuckler.il.thewrittenword.com>
References: <20030916150113.GA46811@spuckler.il.thewrittenword.com>
Message-ID: <86pti08th1.wl@sea.ayamura.org>

> On IRIX 6.5:

> cc-1005 cc: ERROR File = inet_ntoa.c, Line = 46
>   The source file "inet_ntoa.h" is unavailable.
> 
>   #include "inet_ntoa.h"
>                         ^
> Is openbsd-compat/inet_ntoa.h missing or is openbsd-compat/inet_ntoa.c
> wrong?

The include file openbsd-compat/inet_ntoa.h is not needed to compile
openbsd-compat/inet_ntoa.c on IRIX.

Why BROKEN_INET_NTOA should be defined on IRIX 5/6?

openbsd-compat/inet_ntoa.c:
#if defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA)
	...
	char *inet_ntoa(struct in_addr in) { ... }
#endif /* defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA) */

configure.ac:
*-*-irix5*)
	...
	AC_DEFINE(BROKEN_INET_NTOA)
	...
*-*-irix6*)
	...
	AC_DEFINE(BROKEN_INET_NTOA)
	...

p.s.
3.7p1's sshd daemon can not work on IRIX 6.5.21.

-- ayamura



From heiko at FU-Berlin.DE  Wed Sep 17 04:45:09 2003
From: heiko at FU-Berlin.DE (Heiko Schlichting)
Date: Tue, 16 Sep 2003 20:45:09 +0200
Subject: Compilation of 3.7p1 failed on IRIX (missing file)
Message-ID: <20030916184508.GB83092@CIS.FU-Berlin.DE>

Version 3.7p1 of OpenSSH can't be compiled on IRIX 6.5 because the file
    openbsd-compat/inet_ntoa.h
is missing. It is possible to compile successfully using this file out of
version 3.6.1p2.

Heiko

Heiko Schlichting        | Freie Universit?t Berlin
heiko at FU-Berlin.DE       | Zentraleinrichtung f?r Datenverarbeitung (ZEDAT)
Telefon +49 30 838-54327 | Fabeckstra?e 32
Telefax +49 30 838454327 | 14195 Berlin



From cmadams at hiwaay.net  Wed Sep 17 05:27:44 2003
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 16 Sep 2003 14:27:44 -0500
Subject: OpenSSH 3.7p1, PrivSep, and Tru64 broken (sorry)
Message-ID: <20030916192744.GB1009987@hiwaay.net>

Well, I had just finally gotten around to downloading a snapshot to test
the latest on Tru64 a couple of days ago but hadn't had a chance to
build it yet, and 3.7p1 has now been released.  Sigh.

The problem is that Tru64 setreuid() and setregid() are broken, so
privsep doesn't work.

This could also be a security problem for SIA authentication in general
(any version of OpenSSH on Tru64, using PrivSep or not), as I wrote
auth-sia.c to use setreuid() (per the Tru64 SIA documentation), so the
saved UID carries forward there.

Patch below.  It includes a patch to configure (so it is vs. the
distributed .tar.gz file), so if applying to CVS, leave that part out.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


diff -urN openssh-3.7p1-dist/auth-sia.c openssh-3.7p1/auth-sia.c
--- openssh-3.7p1-dist/auth-sia.c	Mon Jun  2 19:25:48 2003
+++ openssh-3.7p1/auth-sia.c	Tue Sep 16 14:02:56 2003
@@ -80,6 +80,7 @@
 {
 	SIAENTITY *ent = NULL;
 	const char *host;
+	uid_t uid;
 
 	host = get_canonical_hostname(options.use_dns);
 
@@ -103,8 +104,11 @@
 	
 	sia_ses_release(&ent);
 
-	if (setreuid(geteuid(), geteuid()) < 0)
-		fatal("setreuid: %s", strerror(errno));
+	uid = geteuid();
+	if (setuid(0) < 0)
+		fatal("setuid: %s", strerror(errno));
+	if (setuid(uid) < 0)
+		fatal("setuid: %s", strerror(errno));
 }
 
 #endif /* HAVE_OSF_SIA */
diff -urN openssh-3.7p1-dist/configure openssh-3.7p1/configure
--- openssh-3.7p1-dist/configure	Tue Sep 16 01:19:17 2003
+++ openssh-3.7p1/configure	Tue Sep 16 14:11:31 2003
@@ -4532,6 +4532,18 @@
 EOF
 
 			cat >>confdefs.h <<\EOF
+#define SETEUID_BREAKS_SETUID 1
+EOF
+
+			cat >>confdefs.h <<\EOF
+#define BROKEN_SETREGID 1
+EOF
+
+			cat >>confdefs.h <<\EOF
+#define BROKEN_SETREUID 1
+EOF
+
+			cat >>confdefs.h <<\EOF
 #define DISABLE_LOGIN 1
 EOF
 
diff -urN openssh-3.7p1-dist/configure.ac openssh-3.7p1/configure.ac
--- openssh-3.7p1-dist/configure.ac	Tue Sep 16 00:48:15 2003
+++ openssh-3.7p1/configure.ac	Tue Sep 16 14:03:51 2003
@@ -395,6 +395,9 @@
 	fi
 	AC_DEFINE(DISABLE_FD_PASSING)
 	AC_DEFINE(BROKEN_GETADDRINFO)
+	AC_DEFINE(SETEUID_BREAKS_SETUID)
+	AC_DEFINE(BROKEN_SETREUID)
+	AC_DEFINE(BROKEN_SETREGID)
 	AC_DEFINE(LOCKED_PASSWD_SUBSTR, "Nologin")
 	;;
 



From jason at devrandom.org  Wed Sep 17 05:31:39 2003
From: jason at devrandom.org (Jason McCormick)
Date: Tue, 16 Sep 2003 15:31:39 -0400
Subject: Pre-RedHat 9.0 RPM Packages
Message-ID: <200309161531.39978.jason@devrandom.org>

  Since I have a mixture of RH 7.1, 7.2, 7.3 and Advanced Server 2.1 
boxes, I've made a set of RPMs for those platforms.  I do not have a 
RedHat 8.0 box to make RPMs. Since RedHat <= 7.2 is out of support by 
RedHat, I don't think we'll see any officially created RPMs (but I 
could be wrong about that) so I thought I'd offer these to the general 
community.  These were all built against up-to-date patched boxes for 
the respective RedHat releases.  These all appear to work on my various 
boxes, but feedback would be appreciated if you run into a dependency 
problem.  

You can get them all from http://bamboo.lexi.com/openssh or anonymous 
FTP at bamboo.lexi.com/pub/openssh/rpm .  If anyone from the 
development team is interested, I'd be willing to make RPMs for older 
platforms to go on the main FTP site.  I'm not sure what sorts of 
security procedures are in place with the team to make sure these are 
viable for inclusion on openssh.com but I'd be willing to assist in any 
way possible.

-- 
Jason McCormick
jason at devrandom.org



From markus at openbsd.org  Wed Sep 17 05:45:08 2003
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 16 Sep 2003 21:45:08 +0200
Subject: OpenBSD 3.3 x86 Build Problem
In-Reply-To: <20030916094310.Q86384@catastrophe.net>
References: <20030916094310.Q86384@catastrophe.net>
Message-ID: <20030916194508.GB9769@folly>


check www.openssh.com/openbsd.html for a patch



From markus at openbsd.org  Wed Sep 17 05:46:36 2003
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 16 Sep 2003 21:46:36 +0200
Subject: OpenSSH 3.7 released
In-Reply-To: <3F6729B2.2050505@psi.ch>
References: <20030916120700.GA26891@folly> <3F6729B2.2050505@psi.ch>
Message-ID: <20030916194636.GC9769@folly>

On Tue, Sep 16, 2003 at 05:18:10PM +0200, Serge Droz wrote:
> ...
> >Security Changes:
> >=================
> >
> >  All versions of OpenSSH's sshd prior to 3.7 contain a buffer
> >  management error.  It is uncertain whether this error is
> >  potentially exploitable, however, we prefer to see bugs
> >  fixed proactively.
> >
> >  OpenSSH 3.7 fixes this bug.
> >
>  Great !
> 
> >Changes since OpenSSH 3.6.1:
> >============================ 
> .> * Changes in Kerberos support:
> >
> >    - KerberosV password support now uses a file cache instead of
> >      a memory cache.
> >
> >    - KerberosIV and AFS support has been removed.
> 
> Could you release just the patch for the security fix?
> We do need AFS support and thus can't just roll out 3.7

there was an additional advisory, here's the patch:

Index: buffer.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- buffer.c	26 Jun 2002 08:54:18 -0000	1.16
+++ buffer.c	16 Sep 2003 03:03:47 -0000	1.17
@@ -69,6 +69,7 @@
 void *
 buffer_append_space(Buffer *buffer, u_int len)
 {
+	u_int newlen;
 	void *p;
 
 	if (len > 0x100000)
@@ -98,11 +99,13 @@
 		goto restart;
 	}
 	/* Increase the size of the buffer and retry. */
-	buffer->alloc += len + 32768;
-	if (buffer->alloc > 0xa00000)
+	
+	newlen = buffer->alloc + len + 32768;
+	if (newlen > 0xa00000)
 		fatal("buffer_append_space: alloc %u not supported",
-		    buffer->alloc);
-	buffer->buf = xrealloc(buffer->buf, buffer->alloc);
+		    newlen);
+	buffer->buf = xrealloc(buffer->buf, newlen);
+	buffer->alloc = newlen;
 	goto restart;
 	/* NOTREACHED */
 }



From pekkas at netcore.fi  Wed Sep 17 05:49:09 2003
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 16 Sep 2003 22:49:09 +0300 (EEST)
Subject: OpenSSH 3.7 released
In-Reply-To: <20030916120700.GA26891@folly>
Message-ID: <Pine.LNX.4.44.0309162247350.24960-100000@netcore.fi>

On Tue, 16 Sep 2003, Markus Friedl wrote:
> Security Changes:
> =================
> 
>   All versions of OpenSSH's sshd prior to 3.7 contain a buffer
>   management error.  It is uncertain whether this error is
>   potentially exploitable, however, we prefer to see bugs
>   fixed proactively.
> 
>   OpenSSH 3.7 fixes this bug.

My (very!) quick look at this would seem to indicate that buffer_append() 
is not called with any useful or user-given input before TCP wrappers 
checks are activated.

Has anyone (else) looked into this?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From jparsons-lists at saffron.net  Wed Sep 17 05:53:39 2003
From: jparsons-lists at saffron.net (Jason Parsons)
Date: Tue, 16 Sep 2003 15:53:39 -0400
Subject: openssh 3.7p1 bus error on sparcv9
Message-ID: <775215DA-E87F-11D7-91BA-00039385FC52@saffron.net>


openssh 3.7p1 sshd on Solaris 8 / sparcv9:

sshd runs fine, and starts to allow the login.  However, when reading 
from /etc/default/login, I get a bus error.  I am able to get sshd to 
work by commenting out these lines in session.c:

1015,1018c1015
< #  ifdef HAVE_ETC_DEFAULT_LOGIN
<               read_etc_default_login(&env, &envsize, pw->pw_uid);
<               path = child_get_env(env, "PATH");
< #  endif /* HAVE_ETC_DEFAULT_LOGIN */

Here is an truss of the failure:

1904:   open("/etc/default/login", O_RDONLY)            = 7
1904:   fstat(7, 0xFFFFFFFF7FFFD7F0)                    = 0
1904:   ioctl(7, TCGETA, 0xFFFFFFFF7FFFD72C)            Err#25 ENOTTY
1904:   read(7, " #   i d e n t\t " @ ( #".., 8192)     = 2042
1904:   read(7, 0x1001D23B4, 8192)                      = 0
1904:   lseek(7, 0, SEEK_CUR)                           = 2042
1904:   close(7)                                        = 0
1904:       Incurred fault #5, FLTACCESS  %pc = 0xFFFFFFFF7E299934
1904:         siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7FFFEA9C
1904:       Received signal #10, SIGBUS [default]
1904:         siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7FFFEA9C
1904:           *** process killed ***
1900:       Received signal #18, SIGCLD [caught]
1900:         siginfo: SIGCLD CLD_KILLED pid=1904 status=0x000A
1900:   sigaction(SIGCLD, 0x00000000, 0xFFFFFFFF7FFFE950) = 0
1900:   write(4, "\0", 1)                               = 1
1900:   setcontext(0xFFFFFFFF7FFFEBD0)
1900:   close(8)                                        = 0
1900:   dup(7)                                          = 8
1900:   dup(7)                                          = 9

The problem seems to be that read_etc_default_login() assumes that a 
u_int (unsigned int) is the same size as a size_t.  This is true in 
sparcv7, but not in sparcv9:

jparsons at sparc64:~# cat test.c
#include <stdio.h>

int main() {

int n;
size_t size;
unsigned int uint;

   printf ("size_t: %d, u_int: %d\n", sizeof(size), sizeof(uint));

}

jparsons at sparc64:~# gcc -v
Reading specs from 
/usr/local/lib/gcc-lib/sparc64-sun-solaris2.8/3.3/specs
Configured with: ../gcc-3.3/configure --enable-threads=posix 
--enable-shared --build=sparc64-sun-solaris2.8 
--host=sparc64-sun-solaris2.8 --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.3

jparsons at sparc64:~# gcc -o test ./test.c
jparsons at sparc64:~# ./test
size_t: 8, u_int: 4

jparsons at sparc:~# gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3/specs
Configured with: ../gcc-3.3/configure --host=sparc-sun-solaris2.8 
--enable-threads=posix --enable-shared --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.3

jparsons at sparc:~# ./test
size_t: 4, u_int: 4

I imagine this effects other 64-bit platforms as well.

  - Jason Parsons



--

Saffron Solutions, LLC	<http://www.saffron.net>	
	System, Network, and Security Consulting
	E-Commerce, Web Site, and E-Mail Hosting



From serge.droz at psi.ch  Wed Sep 17 05:57:10 2003
From: serge.droz at psi.ch (Serge Droz)
Date: Tue, 16 Sep 2003 21:57:10 +0200
Subject: OpenSSH 3.7 released
In-Reply-To: <20030916194636.GC9769@folly>
References: <20030916120700.GA26891@folly> <3F6729B2.2050505@psi.ch>
	<20030916194636.GC9769@folly>
Message-ID: <3F676B16.6070706@psi.ch>

Thanks for the prompt response.

It's very much appreciated

Serge

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



From sxw at inf.ed.ac.uk  Wed Sep 17 06:05:08 2003
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Tue, 16 Sep 2003 21:05:08 +0100 (BST)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <E19y8F9-0003JJ-00@chiark.greenend.org.uk>
Message-ID: <Pine.LNX.4.44.0309162059410.21017-100000@shrike.inf.ed.ac.uk>

On Sat, 13 Sep 2003, Colin Watson wrote:
> Am I right in saying that Kerberos V support has been completely merged?
> I'd like to get rid of our separate patched openssh-krb5 source package
> if possible, although I think we'll still need a separate build for
> Kerberos to avoid unwanted library linkage.

It's only been partially merged. Basically Kerberos authentication as part
of the user authentication process is there, but using Kerberos to secure
the initial key exchange isn't.

Smaller organisations, and those which already maintain and distribute 
ssh_known_hosts maps, should find that the userauth support is sufficient. 
Those that wish to use Kerberos to avoid the overheads of managing ssh 
host keys will need key exchange support.

I intend on continuing to maintain my patches for key exchange support. 
However, note that due to protocol changes, simply forward porting my 
current patches to 3.7p1 is strongly discouraged. A new set of patches 
will be available shortly.

Cheers,

Simon.




From sss_c_2003 at yahoo.com  Wed Sep 17 06:08:15 2003
From: sss_c_2003 at yahoo.com (Senthil kumar)
Date: Tue, 16 Sep 2003 13:08:15 -0700 (PDT)
Subject: Help :: Openshh tunnel or proxy support
Message-ID: <20030916200815.72396.qmail@web80710.mail.yahoo.com>

Dear sir,

own telnet server  + openssh server <====> ssh client

I have a own telnet server, but it doesn't support
ssh. Is it possible to communicate my telnet server
through open ssh server.

I was not able to find any source code that gives me
a starting point maybe one of you has done that
already and can post some  c code or a link where i
can start.


Requirements ::
------------
Could you please help me how to configure my tcp/ip
server over openssh tunnel support.

TCP/IP server <+> openssl server  <----- ssh client


Thanks,
skumar.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com



From phil-openssh-unix-dev at ipal.net  Wed Sep 17 06:30:54 2003
From: phil-openssh-unix-dev at ipal.net (Phil Howard)
Date: Tue, 16 Sep 2003 15:30:54 -0500
Subject: SIGHUP fails to restart (3.6.1p2 -> 3.7p1)
Message-ID: <20030916203054.GA5278@vega.ipal.net>

I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have
more than one daemon with separate executable images).  After upgrading from
3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing
over the existing image), I do SIGHUP and get this message logged:

Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting.
Sep 16 15:07:36 vega sshd_22[22552]: RESTART FAILED: av[0]='/sbin/sshd_22', error: Bad address.

Relevant source code looks like:

=============================================================================
/*
 * Called from the main program after receiving SIGHUP.
 * Restarts the server.
 */
static void
sighup_restart(void)
{
        logit("Received SIGHUP; restarting.");
        close_listen_socks();
        close_startup_pipes();
        execv(saved_argv[0], saved_argv);
        logit("RESTART FAILED: av[0]='%.100s', error: %.100s.", saved_argv[0],
            strerror(errno));
        exit(1);
}
=============================================================================

The process is now gone.  After coming back in via my backdoor port (still on
sshd version 3.6.1p2 ... now you can see why I run separate images), I find
I can simply restart the port 22 instance and now it works fine.

So I repeat the SIGHUP, this time with 3.7p1 running, which will as shown in
the source code above, re-run the same executable path, which this time is
the same image file as it is currently running.  This time it works OK.

So for yet another test, I make a copy of the executable image, and mv the
new copy in place of the one that is running.  So now it's a different inode
to be run than is running, although the images are identical.  This also runs
OK.

1. So what's the deal?
2. Was 3.6.1p2 broken in that respect?
3. Make a saved arg after av[0] was invalid?
4. Is there some weird sensitivity to a version change?
5. What is the "correct" way to upgrade a _remote_ machine (and not get locked
   out in the process)?

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------



From smoogen at lanl.gov  Wed Sep 17 06:31:41 2003
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 16 Sep 2003 14:31:41 -0600
Subject: OpenSSH Security Advisory: buffer.adv
In-Reply-To: <20030916123219.GA7772@folly>
References: <20030916123219.GA7772@folly>
Message-ID: <1063744301.4754.6.camel@smoogen1.lanl.gov>

I would like to thank the OpenBSD and OpenSSH teams on getting these
updates out so quickly and all the work they have done on the IETF lists
recently to see what/why/etc things are headed too. I think they have
really helped in getting the next-gen SSH done.

[Off to order a bunch of CD's or figure out how to do a direct paypal to
help pay for all this work.]


On Tue, 2003-09-16 at 06:32, Markus Friedl wrote:
> This is the 1st revision of the Advisory.
> 
> This document can be found at:  http://www.openssh.com/txt/buffer.adv
> 
> 1. Versions affected:
> 
>         All versions of OpenSSH's sshd prior to 3.7 contain a buffer
>         management error.  It is uncertain whether this error is
>         potentially exploitable, however, we prefer to see bugs
>         fixed proactively.
> 
> 2. Solution:
> 
> 	Upgrade to OpenSSH 3.7 or apply the following patch.
> 
> Appendix:
> 
> Index: buffer.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
> retrieving revision 1.16
> retrieving revision 1.17
> diff -u -r1.16 -r1.17
> --- buffer.c	26 Jun 2002 08:54:18 -0000	1.16
> +++ buffer.c	16 Sep 2003 03:03:47 -0000	1.17
> @@ -69,6 +69,7 @@
>  void *
>  buffer_append_space(Buffer *buffer, u_int len)
>  {
> +	u_int newlen;
>  	void *p;
>  
>  	if (len > 0x100000)
> @@ -98,11 +99,13 @@
>  		goto restart;
>  	}
>  	/* Increase the size of the buffer and retry. */
> -	buffer->alloc += len + 32768;
> -	if (buffer->alloc > 0xa00000)
> +	
> +	newlen = buffer->alloc + len + 32768;
> +	if (newlen > 0xa00000)
>  		fatal("buffer_append_space: alloc %u not supported",
> -		    buffer->alloc);
> -	buffer->buf = xrealloc(buffer->buf, buffer->alloc);
> +		    newlen);
> +	buffer->buf = xrealloc(buffer->buf, newlen);
> +	buffer->alloc = newlen;
>  	goto restart;
>  	/* NOTREACHED */
>  }
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Labrador  CCN-5 Sched 5/40  PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --



From sss_c_2003 at yahoo.com  Wed Sep 17 06:31:51 2003
From: sss_c_2003 at yahoo.com (Senthil kumar)
Date: Tue, 16 Sep 2003 13:31:51 -0700 (PDT)
Subject: Example for register user tcp services 
Message-ID: <20030916203151.4814.qmail@web80707.mail.yahoo.com>

Hi all,

Is there is any examples ,to register the user TCP
service into the openssh server.(The openssh gets the
command message from the openssh client and then
forwarding the command message to the user tcp
services.The openssh server will act like
proxy/tunnel/forwarder messages).


If example is there, please forward it to me.

if example is not there, please help me to configure
my tcp service into the openssh server.

Advance thanks
Skumar.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 06:42:17 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Tue, 16 Sep 2003 15:42:17 -0500
Subject: Problems with 3.7p1 on IRIX 6.5
Message-ID: <20030916204217.GA57630@spuckler.il.thewrittenword.com>

$ uname -R
6.5 6.5.19m
$ cc -v
MIPSpro Compilers: Version 7.4

$ sshd -p 8022
[client]$ ssh -p 8022 -v [host]
$ par -s -SS -i -p [pid]
...
   12mS            sshd(3664039): fork()
   12mS            sshd(3664039): END-fork() = 3639808
   12mS            sshd(3639808): END-fork() = 0
   13mS            sshd(3639808): close(5) OK
   13mS            sshd(3639808): getuid() = 0, euid=0
   14mS            sshd(3639808): stat("/etc/passwd", 0x7ffc5010) OK
   14mS            sshd(3639808): time() = 1063744582
   14mS            sshd(3639808): stat("/etc/shadow", 0x7ffc4ed0) OK
   14mS            sshd(3639808): time() = 1063744582
   14mS            sshd(3639808): chroot("/var/opt/fsw/openssh37/chroot") OK
   14mS            sshd(3639808): chdir("/") OK
   14mS            sshd(3639808): setgroups(1, 0x7ffc555c) = 0
   14mS            sshd(3639808): getuid() = 0, euid=0
   14mS            sshd(3639808): getgid() = 0 egid=0
   14mS            sshd(3639808): setregid(1013, 1013) OK
   14mS            sshd(3639808): setreuid(1013, 1013) OK
   14mS            sshd(3639808): setgid(0) OK
   15mS            sshd(3639808): open("/dev/log", O_WRONLY, 0) errno = 2 (No such file or directory)
   15mS            sshd(3639808): fcntl(-1, F_SETFD, 1) errno = 9 (Bad file number)
   15mS            sshd(3639808): time() = 1063744582
   15mS            sshd(3639808): getpid() = 3639808, ppid=3664039
   15mS            sshd(3639808): putmsg(-1, 0x7ffc4758, 0x7ffc4768, 0) errno = 9 (Bad file number)
   15mS            sshd(3639808): close(-1) errno = 9 (Bad file number)
   15mS            sshd(3639808): shutdown(4, 2) OK
   15mS            sshd(3639808): close(4) OK
   15mS            sshd(3639808): prctl(PR_LASTSHEXIT) = 1
   15mS                (3664039): was sent signal SIGCLD

If I run sshd in debug mode:
  $ sshd -p 8022 -D -d -d
  debug2: read_server_config: filename /etc/opt/fsw/openssh37/sshd_config
  debug1: sshd version OpenSSH_3.7p1
  debug1: read PEM private key done: type RSA
  debug1: private host key: #0 type 1 RSA
  debug1: read PEM private key done: type DSA
  debug1: private host key: #1 type 2 DSA
  debug1: Bind to port 8022 on 0.0.0.0.
  Server listening on 0.0.0.0 port 8022.
  zsh: bus error (core dumped)  /opt/fsw/openssh37/sbin/sshd -p 8022 -D -d -d

I don't get a core file but various printf's fault xmalloc() which
leads me to believe something else is going wrong.

The 'ssh' binary works fine.

-- 
albert chin (china at thewrittenword.com)



From lbecke at mchsi.com  Wed Sep 17 06:51:06 2003
From: lbecke at mchsi.com (lbecke at mchsi.com)
Date: Tue, 16 Sep 2003 20:51:06 +0000
Subject: openssh-3.7p1-pwexp24.patch
Message-ID: <20030916204757.2F1D027C1C6@shitei.mindrot.org>

The patch does not include a method to modify the config.h file with the define 
PASSWD_PROGRAM_PATH "/path/to/passwd" entry.  Once I manually added the line, 
the make worked properly.



From sxw at inf.ed.ac.uk  Wed Sep 17 07:07:14 2003
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Tue, 16 Sep 2003 22:07:14 +0100 (BST)
Subject: OpenBSD 3.3 x86 Build Problem
In-Reply-To: <Pine.BSO.4.44.0309161341300.842-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.44.0309162156520.29337-100000@warspite.inf.ed.ac.uk>


On Tue, 16 Sep 2003, Ben Lindstrom wrote:

> Assuming you don't need Kerb you can do:
>
> KERBEROS5=no make
>
> I was fighting with this problem before we had to release 3.7.  I have no
> solution for those that require kerb. =(

If I'm correct in thinking that OpenBSD builds use the stuff in
src/kerberosV/lib/gssapi to do the build, rather than Heimdal's own
Makefile.in, it looks like OpenBSD doesn't include
src/lib/gssapi/copy_ccache.c when it builds Heimdal.

Cheers,

Simon.



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 07:10:17 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Tue, 16 Sep 2003 16:10:17 -0500
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
In-Reply-To: <86pti08th1.wl@sea.ayamura.org>
References: <20030916150113.GA46811@spuckler.il.thewrittenword.com>
	<86pti08th1.wl@sea.ayamura.org>
Message-ID: <20030916211017.GA58646@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 03:43:22AM +0900, Ayamura KIKUCHI wrote:
> p.s.
> 3.7p1's sshd daemon can not work on IRIX 6.5.21.

I just posted a message about this for IRIX 6.5.19m. It doesn't work
for Tru64 UNIX 4.0D, 5.1 either.

-- 
albert chin (china at thewrittenword.com)



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 07:13:54 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Tue, 16 Sep 2003 16:13:54 -0500
Subject: Compilation of 3.7p1 failed on IRIX (missing file)
In-Reply-To: <20030916184508.GB83092@CIS.FU-Berlin.DE>
References: <20030916184508.GB83092@CIS.FU-Berlin.DE>
Message-ID: <20030916211354.GB58646@spuckler.il.thewrittenword.com>

On Tue, Sep 16, 2003 at 08:45:09PM +0200, Heiko Schlichting wrote:
> Version 3.7p1 of OpenSSH can't be compiled on IRIX 6.5 because the file
>     openbsd-compat/inet_ntoa.h
> is missing. It is possible to compile successfully using this file out of
> version 3.6.1p2.

Just remove the #include in openbsd-compat/inet_ntoa.c. I posted about
the problem earlier and this was the recommended fix.

Does the resulting sshd work on your IRIX machine?

-- 
albert chin (china at thewrittenword.com)



From distler at golem.ph.utexas.edu  Wed Sep 17 07:53:28 2003
From: distler at golem.ph.utexas.edu (Jacques Distler)
Date: Tue, 16 Sep 2003 16:53:28 -0500
Subject: sshd 3.7p1 dies on MacOSX
Message-ID: <345A6FD0-E890-11D7-9027-00039344D894@golem.ph.utexas.edu>

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

Here's the output from running sshd in debug mode:

   debug1: sshd version OpenSSH_3.7p1
   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: setgroups() failed: Invalid argument
   debug1: Bind to port 22 on 0.0.0.0.
   Server listening on 0.0.0.0 port 22.
   Generating 768 bit RSA key.
   RSA key generation complete.
   debug1: Server will not fork when running in debugging mode.
   Connection from 127.0.0.1 port 59687
   debug1: Client protocol version 2.0; client software version 
OpenSSH_3.7p1
   debug1: match: OpenSSH_3.7p1 pat OpenSSH*
   debug1: Enabling compatibility mode for protocol 2.0
   debug1: Local version string SSH-1.99-OpenSSH_3.7p1
   debug1: permanently_set_uid: 17/17
   setuid 17: Operation not permitted
   debug1: Calling cleanup 0x24c8c(0x0)

Replacing uidswap.c with the version from 3.6p1 and recompiling 
produces a working sshd.
I have not tracked down which change caused the breakage, but it should 
be easy enough.

Jacques Distler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc

iD8DBQE/Z4ZgnyqPIXpYcjcRAvD9AJ4koreDrIZTZFb17gR5hWdXdokdtgCdF8wC
Ll5bysCtwPV3QVnZ7BIhgck=
=XbuY
-----END PGP SIGNATURE-----



From crh at ubiqx.mn.org  Wed Sep 17 07:53:32 2003
From: crh at ubiqx.mn.org (Christopher R. Hertel)
Date: Tue, 16 Sep 2003 16:53:32 -0500
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
Message-ID: <20030916215332.GN5170@Favog.ubiqx.mn.org>

I found this in config.h:

/* Define if you system's inet_ntoa is busted (e.g. Irix gcc issue) */
#define BROKEN_INET_NTOA 1

I am using Irix, but I'm using SGI's compiler, not GCC, so I commented out 
the line.  OpenSSH then compiled.

As the note below mentions, however, "3.7p1's sshd daemon can not work on 
IRIX 6.5.21."  I am running 6.5.8m and I have the same problem.  It 
*appears* as though the child process is dying when sshd tries to spawn 
off a child to handle an incomming connection:

# /usr/local/sbin/sshd -dddD
debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper
debug2: read_server_config: filename /usr/local/etc//sshd_config
debug1: sshd version OpenSSH_3.7p1
debug1: private host key: #0 type 0 RSA1
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 160.94.7.28 port 43692
debug1: Client protocol version 1.5; client software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat 
OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
debug1: Local version string SSH-1.5-OpenSSH_3.7p1
debug3: privsep user:group 6666:6666
debug1: permanently_set_uid: 6666/6666
: was able to restore old [e]gid
debug1: Calling cleanup 0x100538b4(0x0)
debug2: Network child is on pid 71668
debug3: preauth child monitor started
debug3:  entering



...and that's that.

Note that Irix C does not support the __func__ macro, which is why that 
last message is odd.

When I look through the ps output, I can't find pid 71668.

Chris Hertel -)-----
[Not on this list...on too many others.  :(]

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

From:     Ayamura KIKUCHI <ayamura () ayamura ! org>
Date:     2003-09-16 18:43:22

> On IRIX 6.5:

> cc-1005 cc: ERROR File = inet_ntoa.c, Line = 46
>   The source file "inet_ntoa.h" is unavailable.
> 
>   #include "inet_ntoa.h"
>                         ^
> Is openbsd-compat/inet_ntoa.h missing or is openbsd-compat/inet_ntoa.c
> wrong?

The include file openbsd-compat/inet_ntoa.h is not needed to compile
openbsd-compat/inet_ntoa.c on IRIX.

Why BROKEN_INET_NTOA should be defined on IRIX 5/6?

openbsd-compat/inet_ntoa.c:
#if defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA)
        ...
        char *inet_ntoa(struct in_addr in) { ... }
#endif /* defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA) */

configure.ac:
*-*-irix5*)
        ...
        AC_DEFINE(BROKEN_INET_NTOA)
        ...
*-*-irix6*)
        ...
        AC_DEFINE(BROKEN_INET_NTOA)
        ...

p.s.
3.7p1's sshd daemon can not work on IRIX 6.5.21.

-- ayamura


-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org



From gert at greenie.muc.de  Wed Sep 17 08:13:58 2003
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 17 Sep 2003 00:13:58 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>;
	from mouring@etoh.eviladmin.org on Sat, Sep 06, 2003 at
	12:47:14AM -0500
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
Message-ID: <20030917001356.E28768@greenie.muc.de>

Hi,

On Sat, Sep 06, 2003 at 12:47:14AM -0500, Ben Lindstrom wrote:
> On this note I think it would be best to opening the floor for testing of
> the current CVS tree.  OpenSSH is in a feature lock and we should be in
> in sync with the OpenBSD tree (there may be stray patches, but hopefully
> nothing major).

SCO 3.2v4.2 is broken in horrible ways :-(

* I need to set the following things in config.h manually, because configure
  doesn't find them:

#define HAVE_TCSENDBREAK 1
#define BROKEN_SETREUID 1
#define SETEUID_BREAKS_SETUID 1

* configure creates "#define BROKEN_SAVED_UIDS 1", which leads to 
  non-working UID swapping - removing that makes *that* work

* waitpid(-1, ...) is weird on this platform - when the server loop for
  ssh1 terminates, I get an error about "no child processes".  If I
  change the "-1" to "waitpid(pid, ...") it works.  Weird.

* ssh2 connections do not terminate - after logout, I get (sshd -d -d -d):

debug2: channel 0: read<=0 rfd 10 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed

  and then nothing any more.  The client side (-v -v) shows:

gert at greenie:/u/gert$ exit
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed

  and the nothing more.  GDB shows sshd hanging in select().

  Termination of the client (~.) leads to:

client:
debug2: channel 0: filter stops
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug1: channel 0: free: client-session, nchannels 1
Connection to XXX closed.

server:
Connection closed by 195.30.X.X
debug1: collect_children MID, ct=0
debug1: collect_children END
debug1: channel 0: free: server-session, nchannels 2
debug3: channel 0: status: The following connections are open:
  #0 server-session (t4 r0 i3/0 o0/0 fd -1/9)

debug3: channel 0: close_fds r -1 w 9 e -1
debug1: channel 1: free: X11 inet listener, nchannels 1
debug3: channel 1: status: The following connections are open:

debug3: channel 1: close_fds r 11 w 11 e -1
debug1: session_close: session 0 pid 28075
debug1: session_pty_cleanup: session 0 release /dev/ttyp22
Closing connection to 195.30.X.X


This last one seems hard enough to give up on it, unless someone else 
is also still interested in making 3.2v4.2 work.  If not, I'll probably
go for 3.5p1 plus buffer.c patch and we can declare this platform "dead".

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 at net.informatik.tu-muenchen.de



From jas at extundo.com  Wed Sep 17 08:23:46 2003
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 17 Sep 2003 00:23:46 +0200
Subject: ANNOUNCE: GSSLib support for OpenSSH (patch)
Message-ID: <ilu7k48v0ct.fsf@latte.josefsson.org>

Hello,

Based on the GSS userauth code that went into 3.7p1, I have made a
patch to make OpenSSH support an alternative Kerberos 5 implementation
called Shishi, via an alternative GSS-API implementation called GSSLib.

The reason behind this message is mostly to let you know that another
pair of eyes has been reading GSS userauth code in OpenSSH, and my
impression is that it looks pretty good.  I found one instance where
OpenSSH cause the GSS library to follow a dangling pointer and write
to likely unallocated memory (see patch), and several constructs that
aren't likely to work with generic GSS mechanisms (e.g., the flags to
gss_accept_sec_context() are set to 0 by OpenSSH, better would be
GSS_C_MUTUAL_FLAG|GSS_C_INTEG_FLAG since that is what the code later
check for), etc.

Another, more egoistic, purpose is to get people to look at an
alternative GSSAPI and Kerberos 5 implementation.

Caveats: Only client mode is supported; the GSS server code in OpenSSH
require too much non-GSS code that I didn't bother finish it.

More information at <http://josefsson.org/gss/gss-openssh.html>.

Thanks.



From connolly at w3.org  Wed Sep 17 08:29:10 2003
From: connolly at w3.org (Dan Connolly)
Date: Tue, 16 Sep 2003 17:29:10 -0500
Subject: help verifying ssh-agent signature from python?
Message-ID: <1063751349.5534.266.camel@dirk.dm93.org>

ssh-agent is clearly the greatest thing since sliced
bread. The python cryptography toolkit wicked cool too.
I'd like to use them together. So I read the ssh-agent
man page and the source code and wrote some python code
  http://www.w3.org/2000/10/swap/util/sshAuth.py
  v 1.4 2003/09/16 04:36:24
to talk to ssh-agent; in particular, to get it to RSA-sign
a string passed from the command line, ala:

  $ python sshAuth.py abc
  signature: ssh-rsa 5560602945671...37036908994L

After getting the protocol wrong and killing my ssh-agent
a few dozen times, I got it working: decoding the
key from the uuencoded blob in my ~/.ssh/authorized_keys
file, finding the socket, formatting the request,
and decoding the reply.

Now I'm trying to verify the signature in the reply
using the python Crypto.PublicKey.RSA module, but
it keeps failing to verify. I've stared at it
for about 5 hours now... I went and read
RFC 2437... that seemed straightforward. I tried
to read the underlying RSA signature code in
the openssl library; truth be told, I couldn't follow
that. But I'm pretty sure the SSH2_AGENT_SIGN_RESPONSE
message carries just the key type name ("ssh-rsa")
and the signature data in buffer_put_bignum2 SSH2 format;
I should be able to just decode that bignum and
pass it right to k.verify(dh, (sigdata,)) no?

Are there some padding bytes or encoding or something
that I'm missing? Help?!?!

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030916/041d30bd/attachment.bin 

From gert at greenie.muc.de  Wed Sep 17 08:36:46 2003
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 17 Sep 2003 00:36:46 +0200
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <20030917001356.E28768@greenie.muc.de>;
	from gert@greenie.muc.de on Wed, Sep 17, 2003 at 12:13:56AM +0200
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<20030917001356.E28768@greenie.muc.de>
Message-ID: <20030917003646.A5700@greenie.muc.de>

Hi,

On Wed, Sep 17, 2003 at 12:13:56AM +0200, Gert Doering wrote:
> SCO 3.2v4.2 is broken in horrible ways :-(
> 
> * I need to set the following things in config.h manually, because configure
>   doesn't find them:
> 
> #define HAVE_TCSENDBREAK 1

*That* was something weird in my setup which was cured by "rm conf* ; 
cvs update ; autoreconf".

> #define BROKEN_SETREUID 1
> #define SETEUID_BREAKS_SETUID 1
> 
> * configure creates "#define BROKEN_SAVED_UIDS 1", which leads to 
>   non-working UID swapping - removing that makes *that* work

These are still wrong.

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 at net.informatik.tu-muenchen.de



From crh at ubiqx.mn.org  Wed Sep 17 08:39:48 2003
From: crh at ubiqx.mn.org (Christopher R. Hertel)
Date: Tue, 16 Sep 2003 17:39:48 -0500
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
Message-ID: <20030916223948.GA11474@Favog.ubiqx.mn.org>

Yeah, I know I'm messing up the threads...

Anyway, I wanted to add that defining

  UsePrivilegeSeparation no

gets me one step further.  I am prompted for my password before sshd 
closes the connection.  Hmmm...

Chris -)-----
[Again, I'm on too many lists to be on this one too.  Sorry.  Hope my 
comments are useful.]

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org



From vinschen at redhat.com  Wed Sep 17 08:40:39 2003
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 17 Sep 2003 00:40:39 +0200
Subject: [PATCH] contrib/cygwin: ssh-host-config and README file update
Message-ID: <20030916224039.GB23530@cygbert.vinschen.de>

Hi,

could anybody with check in privileges apply the following patch to the
contrib cygwin directory?  It only updates ssh-host-config to create the
*_config files matching the latest versions in the top level dir and it
updates a version number in README.

Thanks in advance,
Corinna

Index: contrib/cygwin/README
===================================================================
RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v
retrieving revision 1.10
diff -p -u -r1.10 README
--- contrib/cygwin/README	3 Jul 2002 23:33:20 -0000	1.10
+++ contrib/cygwin/README	16 Sep 2003 22:34:43 -0000
@@ -1,4 +1,4 @@
-This package is the actual port of OpenSSH to Cygwin 1.3.
+This package is the actual port of OpenSSH to Cygwin 1.5.
 
 ===========================================================================
 Important change since 3.4p1-2:
Index: contrib/cygwin/ssh-host-config
===================================================================
RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v
retrieving revision 1.10
diff -p -u -r1.10 ssh-host-config
--- contrib/cygwin/ssh-host-config	9 Nov 2002 15:59:29 -0000	1.10
+++ contrib/cygwin/ssh-host-config	16 Sep 2003 22:34:43 -0000
@@ -279,12 +279,14 @@ then
 # Host *
 #   ForwardAgent no
 #   ForwardX11 no
-#   RhostsAuthentication no
 #   RhostsRSAAuthentication no
 #   RSAAuthentication yes
 #   PasswordAuthentication yes
+#   HostbasedAuthentication no
 #   BatchMode no
 #   CheckHostIP yes
+#   AddressFamily any
+#   ConnectTimeout 0
 #   StrictHostKeyChecking ask
 #   IdentityFile ~/.ssh/identity
 #   IdentityFile ~/.ssh/id_dsa
@@ -397,7 +399,7 @@ Port $port_number
 #HostKey ${SYSCONFDIR}/ssh_host_dsa_key
 
 # Lifetime and size of ephemeral version 1 server key
-#KeyRegenerationInterval 3600
+#KeyRegenerationInterval 1h
 #ServerKeyBits 768
 
 # Logging
@@ -407,7 +409,7 @@ Port $port_number
 
 # Authentication:
 
-#LoginGraceTime 120
+#LoginGraceTime 2m
 #PermitRootLogin yes
 # The following setting overrides permission checks on host key files
 # and directories. For security reasons set this to "yes" when running
@@ -418,10 +420,6 @@ StrictModes no
 #PubkeyAuthentication yes
 #AuthorizedKeysFile     .ssh/authorized_keys
 
-# rhosts authentication should not be used
-#RhostsAuthentication no
-# Don't read the user's ~/.rhosts and ~/.shosts files
-#IgnoreRhosts yes
 # For this to work you will also need host keys in ${SYSCONFDIR}/ssh_known_hosts
 #RhostsRSAAuthentication no
 # similar for protocol version 2
@@ -429,6 +427,8 @@ StrictModes no
 # Change to yes if you don't trust ~/.ssh/known_hosts for
 # RhostsRSAAuthentication and HostbasedAuthentication
 #IgnoreUserKnownHosts no
+# Don't read the user's ~/.rhosts and ~/.shosts files
+#IgnoreRhosts yes
 
 # To disable tunneled clear text passwords, change to no here!
 #PasswordAuthentication yes
@@ -437,6 +437,8 @@ StrictModes no
 # Change to no to disable s/key passwords
 #ChallengeResponseAuthentication yes
 
+#AllowTcpForwarding yes
+#GatewayPorts no
 #X11Forwarding no
 #X11DisplayOffset 10
 #X11UseLocalhost yes
@@ -447,11 +449,14 @@ StrictModes no
 UsePrivilegeSeparation $privsep_used
 #PermitUserEnvironment no
 #Compression yes
-
+#ClientAliveInterval 0
+#ClientAliveCountMax 3
+#UseDNS yes
+#PidFile /var/run/sshd.pid
 #MaxStartups 10
+
 # no default banner path
 #Banner /some/path
-#VerifyReverseMapping no
 
 # override default of no subsystems
 Subsystem      sftp    /usr/sbin/sftp-server

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From markus at openbsd.org  Wed Sep 17 09:13:12 2003
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Sep 2003 01:13:12 +0200
Subject: OpenSSH 3.7.1 released
Message-ID: <20030916231312.GA4926@folly>

OpenSSH 3.7.1 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

For international orders use https://https.openbsd.org/cgi-bin/order
and for European orders, use https://https.openbsd.org/cgi-bin/order.eu

Security Changes:
=================

  All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
  management errors.  It is uncertain whether these errors are
  potentially exploitable, however, we prefer to see bugs
  fixed proactively.

  OpenSSH 3.7 fixed one of these bugs.

  OpenSSH 3.7.1 fixes more similar bugs.

Changes since OpenSSH 3.6.1:
============================ 

* The entire OpenSSH code-base has undergone a license review. As
  a result, all non-ssh1.x code is under a BSD-style license with no
  advertising requirement. Please refer to README in the source
  distribution for the exact license terms.

* Rhosts authentication has been removed in ssh(1) and sshd(8).

* Changes in Kerberos support:

    - KerberosV password support now uses a file cache instead of
      a memory cache.

    - KerberosIV and AFS support has been removed.

    - KerberosV support has been removed from SSH protocol 1.

    - KerberosV password authentication support remains for SSH
      protocols 1 and 2.

    - This release contains some GSSAPI user authentication support
      to replace legacy KerberosV authentication support. At present
      this code is still considered experimental and SHOULD NOT BE
      USED.
  
* Changed order that keys are tried in public key authentication.
  The ssh(1) client tries the keys in the following order:

     1. ssh-agent(1) keys that are found in the ssh_config(5) file
     2. remaining ssh-agent(1) keys
     3. keys that are only listed in the ssh_config(5) file

  This helps when an ssh-agent(1) has many keys, where the sshd(8)
  server might close the connection before the correct key is tried.

* SOCKS5 support has been added to the dynamic forwarding mode
  in ssh(1).

* Removed implementation barriers to operation of SSH over SCTP.

* sftp(1) client can now transfer files with quote characters in
  their filenames.

* Replaced sshd(8)'s VerifyReverseMapping with UseDNS option.
  When UseDNS option is on, reverse hostname lookups are always
  performed.

* Fix a number of memory leaks.

* Support for sending tty BREAK over SSH protocol 2.

* Workaround for other vendor bugs in KEX guess handling.

* Support for generating KEX-GEX groups (/etc/moduli) in ssh-keygen(1).

* Automatic re-keying based on amount of data sent over connection.

* New AddressFamily option on client to select protocol to use (IPv4
  or IPv6).

* Experimental support for the "aes128-ctr", "aes192-ctr", and
  "aes256-ctr" ciphers for SSH protocol 2.

* Experimental support for host keys in DNS (draft-ietf-secsh-dns-xx.txt).
  Please see README.dns in the source distribution for details.

* Portable OpenSSH:

    - Replace PAM password authentication kludge with a more correct
      PAM challenge-response module from FreeBSD.

    - PAM support may now be enabled/disabled at runtime using the
      UsePAM directive.

    - Many improvements to the OpenSC smartcard support.

    - Regression tests now work with portable OpenSSH.
      Please refer to regress/README.regress in the source distribution.

    - On platforms that support it, portable OpenSSH now honors the
      UMASK, PATH and SUPATH attributes set in /etc/default/login.

    - Deny access to locked accounts, regardless of authentication
      method in use.

Checksums:
==========

- MD5 (openssh-3.7.1.tgz) = 3d2f1644d6a3d3267e5e2421f1385129
- MD5 (openssh-3.7.1p1.tar.gz) = f54e574e606c08ef63ebb1ab2f7689dc


Reporting Bugs:
===============

- please read http://www.openssh.com/report.html
  and http://bugzilla.mindrot.org/

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



From markus at openbsd.org  Wed Sep 17 09:14:08 2003
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Sep 2003 01:14:08 +0200
Subject: OpenSSH Security Advisory: buffer.adv
Message-ID: <20030916231408.GA14378@folly>

This is the 2nd revision of the Advisory.

This document can be found at:  http://www.openssh.com/txt/buffer.adv

1. Versions affected:

        All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
        management errors.  It is uncertain whether these errors are
        potentially exploitable, however, we prefer to see bugs
        fixed proactively.

        Other implementations sharing common origin may also have
        these issues.

2. Solution:

	Upgrade to OpenSSH 3.7.1 or apply the following patch.

===================================================================
Appendix A: patch for OpenSSH 3.6.1 and earlier

Index: buffer.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.16
retrieving revision 1.18
diff -u -r1.16 -r1.18
--- buffer.c	26 Jun 2002 08:54:18 -0000	1.16
+++ buffer.c	16 Sep 2003 21:02:39 -0000	1.18
@@ -23,8 +23,11 @@
 void
 buffer_init(Buffer *buffer)
 {
-	buffer->alloc = 4096;
-	buffer->buf = xmalloc(buffer->alloc);
+	const u_int len = 4096;
+
+	buffer->alloc = 0;
+	buffer->buf = xmalloc(len);
+	buffer->alloc = len;
 	buffer->offset = 0;
 	buffer->end = 0;
 }
@@ -34,8 +37,10 @@
 void
 buffer_free(Buffer *buffer)
 {
-	memset(buffer->buf, 0, buffer->alloc);
-	xfree(buffer->buf);
+	if (buffer->alloc > 0) {
+		memset(buffer->buf, 0, buffer->alloc);
+		xfree(buffer->buf);
+	}
 }
 
 /*
@@ -69,6 +74,7 @@
 void *
 buffer_append_space(Buffer *buffer, u_int len)
 {
+	u_int newlen;
 	void *p;
 
 	if (len > 0x100000)
@@ -98,11 +104,13 @@
 		goto restart;
 	}
 	/* Increase the size of the buffer and retry. */
-	buffer->alloc += len + 32768;
-	if (buffer->alloc > 0xa00000)
+	
+	newlen = buffer->alloc + len + 32768;
+	if (newlen > 0xa00000)
 		fatal("buffer_append_space: alloc %u not supported",
-		    buffer->alloc);
-	buffer->buf = xrealloc(buffer->buf, buffer->alloc);
+		    newlen);
+	buffer->buf = xrealloc(buffer->buf, newlen);
+	buffer->alloc = newlen;
 	goto restart;
 	/* NOTREACHED */
 }
Index: channels.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.194
retrieving revision 1.195
diff -u -r1.194 -r1.195
--- channels.c	29 Aug 2003 10:04:36 -0000	1.194
+++ channels.c	16 Sep 2003 21:02:40 -0000	1.195
@@ -228,12 +228,13 @@
 	if (found == -1) {
 		/* There are no free slots.  Take last+1 slot and expand the array.  */
 		found = channels_alloc;
-		channels_alloc += 10;
 		if (channels_alloc > 10000)
 			fatal("channel_new: internal error: channels_alloc %d "
 			    "too big.", channels_alloc);
+		channels = xrealloc(channels,
+		    (channels_alloc + 10) * sizeof(Channel *));
+		channels_alloc += 10;
 		debug2("channel: expanding %d", channels_alloc);
-		channels = xrealloc(channels, channels_alloc * sizeof(Channel *));
 		for (i = found; i < channels_alloc; i++)
 			channels[i] = NULL;
 	}


===================================================================
Appendix B: patch for OpenSSH 3.7

Index: buffer.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- buffer.c	16 Sep 2003 03:03:47 -0000	1.17
+++ buffer.c	16 Sep 2003 21:02:39 -0000	1.18
@@ -23,8 +23,11 @@
 void
 buffer_init(Buffer *buffer)
 {
-	buffer->alloc = 4096;
-	buffer->buf = xmalloc(buffer->alloc);
+	const u_int len = 4096;
+
+	buffer->alloc = 0;
+	buffer->buf = xmalloc(len);
+	buffer->alloc = len;
 	buffer->offset = 0;
 	buffer->end = 0;
 }
@@ -34,8 +37,10 @@
 void
 buffer_free(Buffer *buffer)
 {
-	memset(buffer->buf, 0, buffer->alloc);
-	xfree(buffer->buf);
+	if (buffer->alloc > 0) {
+		memset(buffer->buf, 0, buffer->alloc);
+		xfree(buffer->buf);
+	}
 }
 
 /*
Index: channels.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.194
retrieving revision 1.195
diff -u -r1.194 -r1.195
--- channels.c	29 Aug 2003 10:04:36 -0000	1.194
+++ channels.c	16 Sep 2003 21:02:40 -0000	1.195
@@ -228,12 +228,13 @@
 	if (found == -1) {
 		/* There are no free slots.  Take last+1 slot and expand the array.  */
 		found = channels_alloc;
-		channels_alloc += 10;
 		if (channels_alloc > 10000)
 			fatal("channel_new: internal error: channels_alloc %d "
 			    "too big.", channels_alloc);
+		channels = xrealloc(channels,
+		    (channels_alloc + 10) * sizeof(Channel *));
+		channels_alloc += 10;
 		debug2("channel: expanding %d", channels_alloc);
-		channels = xrealloc(channels, channels_alloc * sizeof(Channel *));
 		for (i = found; i < channels_alloc; i++)
 			channels[i] = NULL;
 	}

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



From dtucker at zip.com.au  Wed Sep 17 09:39:16 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 09:39:16 +1000
Subject: openssh 3.7p1 bus error on sparcv9
References: <775215DA-E87F-11D7-91BA-00039385FC52@saffron.net>
Message-ID: <3F679F24.F9D3AC45@zip.com.au>

Jason Parsons wrote:
> 
> openssh 3.7p1 sshd on Solaris 8 / sparcv9:
> 
> sshd runs fine, and starts to allow the login.  However, when reading
> from /etc/default/login, I get a bus error.  I am able to get sshd to
> work by commenting out these lines in session.c:
[snip]
> The problem seems to be that read_etc_default_login() assumes that a
> u_int (unsigned int) is the same size as a size_t.  This is true in
> sparcv7, but not in sparcv9:

Damn, I tested it on a sun4m.  Does the attached patch fix it?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: session.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v
retrieving revision 1.253
diff -u -p -r1.253 session.c
--- session.c	16 Sep 2003 01:52:19 -0000	1.253
+++ session.c	16 Sep 2003 23:36:08 -0000
@@ -912,8 +912,7 @@ static void
 read_etc_default_login(char ***env, u_int *envsize, uid_t uid)
 {
 	char **tmpenv = NULL, *var;
-	u_int i;
-	size_t tmpenvsize = 0;
+	u_int i, tmpenvsize = 0;
 	mode_t mask;
 
 	/*

From jnysen-openssh at triaptic.com.au  Wed Sep 17 11:00:18 2003
From: jnysen-openssh at triaptic.com.au (Jeremy Nysen)
Date: Wed, 17 Sep 2003 11:00:18 +1000
Subject: SRP secure remote password authentication
Message-ID: <8463549.1063796418@[192.168.1.14]>

Are there any plans to include support for SRP or a similar zero-knowledge password 
protocol into OpenSSH?

-- 
Jeremy



From tim at multitalents.net  Wed Sep 17 11:44:02 2003
From: tim at multitalents.net (Tim Rice)
Date: Tue, 16 Sep 2003 18:44:02 -0700 (PDT)
Subject: Compilation of 3.7p1 failed on IRIX (missing file)
In-Reply-To: <20030916184508.GB83092@CIS.FU-Berlin.DE>
References: <20030916184508.GB83092@CIS.FU-Berlin.DE>
Message-ID: <Pine.UW2.4.58.0309161842320.5771@ou8.int.multitalents.net>

On Tue, 16 Sep 2003, Heiko Schlichting wrote:

> Version 3.7p1 of OpenSSH can't be compiled on IRIX 6.5 because the file
>     openbsd-compat/inet_ntoa.h
> is missing. It is possible to compile successfully using this file out of
> version 3.6.1p2.

Remove the #include "inet_ntoa.h" line from openbsd-compat/inet_ntoa.c

> 
> Heiko
> 
> Heiko Schlichting        | Freie Universit?t Berlin
> heiko at FU-Berlin.DE       | Zentraleinrichtung f?r Datenverarbeitung (ZEDAT)
> Telefon +49 30 838-54327 | Fabeckstra?e 32
> Telefax +49 30 838454327 | 14195 Berlin
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 

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




From jparsons-lists at saffron.net  Wed Sep 17 12:03:56 2003
From: jparsons-lists at saffron.net (Jason Parsons)
Date: Tue, 16 Sep 2003 22:03:56 -0400
Subject: openssh 3.7p1 bus error on sparcv9
In-Reply-To: <3F679F24.F9D3AC45@zip.com.au>
Message-ID: <31DC7C38-E8B3-11D7-91BA-00039385FC52@saffron.net>


> Damn, I tested it on a sun4m.  Does the attached patch fix it?

It seems to.  Thank you.

   - Jason Parsons

> RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v
> retrieving revision 1.253
> diff -u -p -r1.253 session.c
> --- session.c	16 Sep 2003 01:52:19 -0000	1.253
> +++ session.c	16 Sep 2003 23:36:08 -0000
> @@ -912,8 +912,7 @@ static void
>  read_etc_default_login(char ***env, u_int *envsize, uid_t uid)
>  {
>  	char **tmpenv = NULL, *var;
> -	u_int i;
> -	size_t tmpenvsize = 0;
> +	u_int i, tmpenvsize = 0;
>  	mode_t mask;
>
>  	/*



From mjo at dojo.mi.org  Wed Sep 17 12:19:31 2003
From: mjo at dojo.mi.org (Mike O'Connor)
Date: Tue, 16 Sep 2003 22:19:31 -0400 (EDT)
Subject: Use the OpenSSH 3.6 uidwrap.c for building 3.7 under IRIX
Message-ID: <030916221931.mjo@dojo.mi.org>

Once I got past the missing inet_ntoa.h weirdness, I ran into an sshd
that died a lot.  It appears that IRIX doesn't like some of the extra
checks added between 1.23 and 1.24 of uidwrap.c.  Not sure if that
constitutes an IRIX bug or not, but helpfully this helps someone.

-- 
 Mail: mjo at dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Never never never never never never NEVER trust a tiger."            -Calvin



From dtucker at zip.com.au  Wed Sep 17 12:33:17 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 12:33:17 +1000
Subject: openssh 3.7p1 bus error on sparcv9
References: <31DC7C38-E8B3-11D7-91BA-00039385FC52@saffron.net>
Message-ID: <3F67C7ED.F4C35148@zip.com.au>

Jason Parsons wrote:
> > Damn, I tested it on a sun4m.  Does the attached patch fix it?
> 
> It seems to.  Thank you.

Excellent, thank you.

I've opened a bugzilla bug for this so we track it:
http://bugzilla.mindrot.org/show_bug.cgi?id=643

The same patch is attached to the bug.  If you have anything to add,
please update the bug.

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



From mjo at dojo.mi.org  Wed Sep 17 12:45:02 2003
From: mjo at dojo.mi.org (Mike O'Connor)
Date: Tue, 16 Sep 2003 22:45:02 -0400 (EDT)
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
Message-ID: <030916224501.mjo@dojo.mi.org>

[resending with uidswap.c instead of uidwrap.c]


Once I got past the missing inet_ntoa.h weirdness, I ran into an sshd
that died a lot.  It appears that IRIX doesn't like some of the extra
checks added between 1.23 and 1.24 of uidswap.c.  Not sure if that
constitutes an IRIX bug or not, but helpfully this helps someone.

-- 
 Mail: mjo at dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Never never never never never never NEVER trust a tiger."            -Calvin



From siegert at sfu.ca  Wed Sep 17 12:52:30 2003
From: siegert at sfu.ca (Martin Siegert)
Date: Tue, 16 Sep 2003 19:52:30 -0700
Subject: openssh-3.7.1p1 segfaults
Message-ID: <20030917025230.GA18824@stikine.ucs.sfu.ca>

Hi,

the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
both show the same behaviour.

openssh is configure with:

CC='gcc -L/usr/LOCAL/lib -I/usr/LOCAL/include' ./configure --prefix=/usr/LOCAL --sysconfdir=/etc/ssh --sbindir=/usr/local/sbin --libexecdir=/usr/local/libexec --with-pam --with-tcp-wrappers --with-ssl-dir=/usr/LOCAL/ssl --with-default-path='/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/LOCAL/bin'

and compiles, installs fine, even sshd starts fine.
However, connecting to it from a client fails, leading to a segfault in 
one of the childs that sshd spawns on the server.

I append output from the client session (ssh -v -v -v ...), truss output
of sshd on the server (truss -f -p 4415, where 4415 is the pid of the
"master" sshd process), and output from "gdb sshd".

I hope this helps to fix the problem.

Martin

-- 
Martin Siegert
Manager, Research Services
WestGrid Site Manager
Academic Computing Services                        phone: (604) 291-4691
Simon Fraser University                            fax:   (604) 291-4242
Burnaby, British Columbia                          email: siegert at sfu.ca
Canada  V5A 1S6

===<client output>======================================================
# ssh -v -v -v harrison
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 11168 geteuid 0 anon 1
debug1: Connecting to harrison [142.58.200.80] port 22.
debug1: temporarily_use_uid: 11168/1000 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 11168/1000 (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/siegert/.ssh/identity type -1
debug3: Not a RSA1 key file /home/siegert/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
... <snip>
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/siegert/.ssh/id_rsa type 1
debug1: identity file /home/siegert/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p1
... <snip>
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

at which point the client hangs.
=========================================================================

===<truss -f -p 4415; 4455 is the pid of the child the segfaults>========
... <snip>
4455:	open("/dev/udp", O_RDWR)			= 8
4455:	ioctl(8, I_FIND, "timod")			= 0
4455:	ioctl(8, I_PUSH, "timod")			= 0
4455:	sigprocmask(SIG_SETMASK, 0xEFFFDD70, 0xEFFFDD60) = 0
4455:	ioctl(8, I_STR, 0xEFFFDBE8)			= 0
4455:	sigprocmask(SIG_SETMASK, 0xEFFFDD60, 0x00000000) = 0
4455:	ioctl(8, I_FLUSH, FLUSHRW)			= 0
4455:	sigprocmask(SIG_SETMASK, 0xEFFFDD70, 0xEFFFDD60) = 0
4455:	ioctl(8, I_STR, 0xEFFFDCD8)			= 0
4455:	sigprocmask(SIG_SETMASK, 0xEFFFDD60, 0x00000000) = 0
4455:	ioctl(8, I_STR, 0xEFFFDBE0)			= 0
4455:	getpid()					= 4455 [4451]
4455:	ioctl(8, I_STR, 0xEFFFDC2C)			= 0
4455:	fstat(8, 0xEFFFDD74)				= 0
4455:	fcntl(8, F_SETFD, 0x00000001)			= 0
4455:	fstat(8, 0xEFFFDE48)				= 0
4455:	putmsg(8, 0xEFFFDD34, 0xEFFFDE74, 0)		= 0
4455:	poll(0x00094A84, 1, 15000)			= 1
4455:	getmsg(8, 0xEFFFDD30, 0x00081A48, 0xEFFFDD5C)	= 0
4455:	getpid()					= 4455 [4451]
4455:	fstat(8, 0xEFFFDD40)				= 0
4455:	putmsg(8, 0xEFFFDC2C, 0xEFFFDD6C, 0)		= 0
4455:	poll(0x00094A84, 1, 15000)			= 1
4455:	getmsg(8, 0xEFFFDC28, 0x00081A48, 0xEFFFDC54)	= 0
4455:	getpid()					= 4455 [4451]
4455:	fstat(8, 0xEFFFDD40)				= 0
4455:	putmsg(8, 0xEFFFDC2C, 0xEFFFDD6C, 0)		= 0
4455:	poll(0x00094A84, 1, 15000)			= 1
4455:	getmsg(8, 0xEFFFDC28, 0x00081A48, 0xEFFFDC54)	= 0
4455:	getpid()					= 4455 [4451]
4455:	fstat(8, 0xEFFFDD40)				= 0
4455:	putmsg(8, 0xEFFFDC2C, 0xEFFFDD6C, 0)		= 0
4455:	poll(0x00094A84, 1, 15000)			= 1
4455:	getmsg(8, 0xEFFFDC28, 0x00081A48, 0xEFFFDC54)	= 0
4455:	llseek(4, 0xFFFFFFFFFFFFFFC7, SEEK_CUR)		= 541
4455:	close(4)					= 0
4455:	    Incurred fault #6, FLTBOUNDS  %pc = 0x0003172C
4455:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000008
4455:	    Received signal #11, SIGSEGV [default]
4455:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000008
4455:		*** process killed ***
4451:	write(6, "\0\0\005 /", 5)			= 5
4451:	write(6, "\0\0\001", 4)				= 4
4453:	read(8, "\0\0\005", 4)				= 4
4453:	read(8, " /\0\0\001", 5)			= 5
4453:	write(8, "\0\0\001 0", 5)			= 5
4451:	read(6, "\0\0\001", 4)				= 4
4451:	read(6, " 0", 1)				= 1
4415:	poll(0xEFFFD150, 2, -1)		(sleeping...)
4451:	read(10, 0xEFFFEDE8, 4)		(sleeping...)
4453:	read(8, 0xEFFFECB8, 4)		(sleeping...)
========================================================================

===<gdb sshd>
# gdb sshd
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.6"...
(gdb) run -d -d -d
Starting program: /usr/LOCAL/src/openssh-3.7.1p1/sshd -d -d -d
debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper
debug2: read_server_config: filename /etc/ssh/sshd_config
debug1: sshd version OpenSSH_3.7.1p1
... <snip>
Failed publickey for siegert from 142.58.1.216 port 52124 ssh2
debug1: userauth-request for user siegert service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=siegert devs=
debug1: kbdint_alloc: devices 'pam'
debug2: auth2_challenge_start: devices pam
debug2: kbdint_next_device: devices <empty>
debug1: auth2_challenge_start: trying authentication method 'pam'
debug3: mm_sshpam_init_ctx
debug3: mm_request_send entering: type 46
debug3: monitor_read: checking request 46
debug3: mm_answer_pam_init_ctx
debug3: mm_sshpam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX
debug3: mm_request_receive_expect entering: type 47
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 47
debug3: mm_sshpam_query
debug3: mm_request_send entering: type 48
debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY
debug3: mm_request_receive_expect entering: type 49
debug3: mm_request_receive entering
debug3: mm_request_receive entering
debug3: monitor_read: checking request 48
debug3: mm_answer_pam_query
debug3: ssh_msg_recv entering
^C           [at this point the program hangs; Ctr-C is the only way out]
Program received signal SIGINT, Interrupt.
0xef438680 in _read () from /usr/lib/libc.so.1
(gdb) where
#0  0xef438680 in _read () from /usr/lib/libc.so.1
#1  0x410a4 in atomicio (f=0x74198 <read>, fd=11, _s=0xefffeda8, n=4)
    at atomicio.c:45
#2  0x45970 in ssh_msg_recv (fd=11, m=0xefffee58) at msg.c:58
#3  0x31e64 in sshpam_query (ctx=0x88850, name=0xefffef1c, info=0xefffef18, 
    num=0xefffef14, prompts=0xefffef10, echo_on=0xefffef0c) at auth-pam.c:433
#4  0x2bd84 in mm_answer_pam_query (socket=8, m=0xefffef90) at monitor.c:847
#5  0x2b494 in monitor_read (pmonitor=0x7c7c8, ent=0x75320, pent=0xeffff044)
    at monitor.c:413
#6  0x2b12c in monitor_child_preauth (pmonitor=0x7c7c8) at monitor.c:299
#7  0x1b40c in privsep_preauth () at sshd.c:595
#8  0x1ce94 in main (ac=38, av=0xffffffff) at sshd.c:1472
(gdb) quit
==========================================================================



From imorgan at nas.nasa.gov  Wed Sep 17 13:00:09 2003
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 16 Sep 2003 20:00:09 -0700 (PDT)
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
In-Reply-To: <86pti08th1.wl@sea.ayamura.org> from "Ayamura KIKUCHI" at Sep 17,
	2003 03:43:22 AM
Message-ID: <200309170300.h8H309119690@sun601.nas.nasa.gov>

On Tue Sep 16 11:43:22 2003, Ayamura KIKUCHI wrote:
> 
> > On IRIX 6.5:
> 
> > cc-1005 cc: ERROR File = inet_ntoa.c, Line = 46
> >   The source file "inet_ntoa.h" is unavailable.
> > 
> >   #include "inet_ntoa.h"
> >                         ^
> > Is openbsd-compat/inet_ntoa.h missing or is openbsd-compat/inet_ntoa.c
> > wrong?
> 
> The include file openbsd-compat/inet_ntoa.h is not needed to compile
> openbsd-compat/inet_ntoa.c on IRIX.
> 
> Why BROKEN_INET_NTOA should be defined on IRIX 5/6?
> 
> openbsd-compat/inet_ntoa.c:
> #if defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA)
> 	...
> 	char *inet_ntoa(struct in_addr in) { ... }
> #endif /* defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA) */
> 
> configure.ac:
> *-*-irix5*)
> 	...
> 	AC_DEFINE(BROKEN_INET_NTOA)
> 	...
> *-*-irix6*)
> 	...
> 	AC_DEFINE(BROKEN_INET_NTOA)
> 	...
> 
> p.s.
> 3.7p1's sshd daemon can not work on IRIX 6.5.21.
> 
> -- ayamura
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

As I recall, there is a classic issue with inet_ntoa() under IRIX
when using gcc. I believe it was a padding and alignment issue, but
I don't have the information handy at the moment. Assuming the 
problem still exists, it would seem reasonable to consider 
inet_ntoa() to be broken when using gcc. However, when using the
MIPSpro compilers it should not be an issue.

--
Iain Morgan
NAS Desktop Support Group



From sq at oganer.net  Wed Sep 17 13:12:36 2003
From: sq at oganer.net (Dmitry Lohansky)
Date: Wed, 17 Sep 2003 11:12:36 +0800
Subject: sftp reget/reput
Message-ID: <1178101319.20030917111236@oganer.net>

Hello openssh@

I thought about sftp's reget/reput commands.

Several days ago, Damien Miller write to tech at openbsd.org (it was
reply for my letter):

> Herein lies a problem which is not easy to detect or solve. For
> performance reasons, the sftp client does pipelined reads/writes when
> transferring files. The protocol spec allows for a server to process
> these requests out of order. For example:

> client                     server
> ------                     ------
> open file                  your file handle is "blah"
> gimme bytes 0-8191
> gimme bytes 8192-16383
> gimme bytes 16384-24575
> gimme bytes 24576-32767    here are bytes 24576-32767
> close file                 here are bytes 16384-24575
>                            here are bytes 8192-16383
>                            here are bytes 0-8191
>                            close successful

> If the client writes the bytes our in the order they are received (which
> it probably should, to avoid buffering large amounts of data) then an
> interruption will leave a full-length, but "holey" file on disk. There
> is no general way to determine how to do resume such a transfer.

> The best the client can do to make transfers resumable is ftruncate()
> the file at the highest contiguous byte received. This will stop the
> potential corruption on resume.

This is good method, but if client crash, we also may get a "hole".
What your think about next way?

Storing extra-data at the end of file, for example:

<---orig-part-><-extra->
[*][ ][*][ ][*][*******]
<---------file--------->

where [*] - already loaded data, [ ] - not yet

In extra part, we may store which block was already loaded and it
offset and size. After download, extra part will be removed.

Comments?
-- 
 Dmitry Lohansky



From jet at spies.com  Wed Sep 17 13:27:34 2003
From: jet at spies.com (jet)
Date: Tue, 16 Sep 2003 20:27:34 -0700
Subject: ssh 3.7p1 working fine on my redhat 6.2 box
In-Reply-To: <345A6FD0-E890-11D7-9027-00039344D894@golem.ph.utexas.edu>
References: <345A6FD0-E890-11D7-9027-00039344D894@golem.ph.utexas.edu>
Message-ID: <p06002049bb8d847cd977@[10.0.1.25]>

Just a note, running 3.7p1 on one of my Redhat 6.2 boxes with no problems.

The fact that I have to run a Redhat 6.2 box is a huge problem, however.

-- 
J. Eric Townsend -- jet spies com
buy stuff, damnit: http://www.spies.com/jet/store.html



From dtucker at zip.com.au  Wed Sep 17 13:34:01 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 13:34:01 +1000
Subject: Problems with 3.7p1 on IRIX 6.5
References: <20030916204217.GA57630@spuckler.il.thewrittenword.com>
Message-ID: <3F67D629.DF213651@zip.com.au>

Albert Chin wrote:
> $ uname -R
> 6.5 6.5.19m
[snip]
> If I run sshd in debug mode:
>   $ sshd -p 8022 -D -d -d
>   debug2: read_server_config: filename /etc/opt/fsw/openssh37/sshd_config
>   debug1: sshd version OpenSSH_3.7p1
>   debug1: read PEM private key done: type RSA
>   debug1: private host key: #0 type 1 RSA
>   debug1: read PEM private key done: type DSA
>   debug1: private host key: #1 type 2 DSA
>   debug1: Bind to port 8022 on 0.0.0.0.
>   Server listening on 0.0.0.0 port 8022.
>   zsh: bus error (core dumped)  /opt/fsw/openssh37/sbin/sshd -p 8022 -D -d -d

Try defining BROKEN_GETADDRINFO in config.h and recompiling.

There is some suspicion about IRIX's getaddrinfo, see:
http://bugzilla.mindrot.org/show_bug.cgi?id=585

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



From dtucker at zip.com.au  Wed Sep 17 13:41:38 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 13:41:38 +1000
Subject: openssh-3.7p1-pwexp24.patch
References: <20030916204757.2F1D027C1C6@shitei.mindrot.org>
Message-ID: <3F67D7F2.B7E801E5@zip.com.au>

lbecke at mchsi.com wrote:
> 
> The patch does not include a method to modify the config.h file with the define
> PASSWD_PROGRAM_PATH "/path/to/passwd" entry.  Once I manually added the line,
> the make worked properly.

Thanks, that was an oversight in my generation of the diffs against the
OpenSSH Portable releases.  An updated patch with this fixed (no
functional changes) will be on the page in 15 minutes or so.

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



From eric-list-openssh at catastrophe.net  Wed Sep 17 13:55:53 2003
From: eric-list-openssh at catastrophe.net (Eric)
Date: Tue, 16 Sep 2003 22:55:53 -0500
Subject: OpenSSH <= 3.7 Truncating /etc/issue
Message-ID: <20030916225553.X86384@catastrophe.net>

I'm in a situation where a rather lengthy /etc/issue file is used
to state standard disclaimers of acceptable use. I noticed that
OpenSSH 3.7 and above started truncating this to 1023 characters;
the ssh client, that is.

Is this is simple variable change that wouldn't break anything?
I'll look through the code, but it might be wise to make this
buffer a bit larger since many organizations, unfortunately, now
have to state large policies prior to login.

Thanks.

- Eric



From jhy at io.harvard.edu  Wed Sep 17 14:04:31 2003
From: jhy at io.harvard.edu (Jack Yatteau)
Date: Wed, 17 Sep 2003 00:04:31 -0400
Subject: openssh-3.7.1p1
Message-ID: <BB8D558F.DC9%jhy@io.harvard.edu>

Attempted compilation of openssh v3.7.1p1 on SGI IRIX 6.5.13.  Compilation
failed due to missing inet_ntoa.h in openbsd-compat.  Copied inet_ntoa.h
from older openssh distribution to that directory and compilation completed,
but the new sshd is giving me trouble, possibly due to something else.

Regards,

    Jack



From djm at mindrot.org  Wed Sep 17 15:26:16 2003
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 Sep 2003 15:26:16 +1000
Subject: SRP secure remote password authentication
In-Reply-To: <8463549.1063796418@[192.168.1.14]>
References: <8463549.1063796418@[192.168.1.14]>
Message-ID: <3F67F078.5000605@mindrot.org>

Jeremy Nysen wrote:
> Are there any plans to include support for SRP or a similar 
> zero-knowledge password protocol into OpenSSH?

No, they are tainted by patents.

-d




From secure_bsd at yahoo.com  Wed Sep 17 15:41:07 2003
From: secure_bsd at yahoo.com (Joule)
Date: Tue, 16 Sep 2003 22:41:07 -0700 (PDT)
Subject: does ssh honor /etc/default/security file
Message-ID: <20030917054107.9181.qmail@web13306.mail.yahoo.com>

Does ssh check /etc/default/security file. Is there
any patches available to support this.

--
Joule

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com



From jnysen-openssh at triaptic.com.au  Wed Sep 17 16:03:44 2003
From: jnysen-openssh at triaptic.com.au (Jeremy Nysen)
Date: Wed, 17 Sep 2003 16:03:44 +1000
Subject: SRP secure remote password authentication
In-Reply-To: <3F67F078.5000605@mindrot.org>
References: <8463549.1063796418@[192.168.1.14]> <3F67F078.5000605@mindrot.org>
Message-ID: <26669989.1063814624@[192.168.1.14]>

--On Wednesday, 17 September 2003 3:26 PM +1000 Damien Miller <djm at mindrot.org> wrote:
> Jeremy Nysen wrote:
>> Are there any plans to include support for SRP or a similar
>> zero-knowledge password protocol into OpenSSH?
>
> No, they are tainted by patents.

Are these (software?) patents licensable in any way that disencumbers their use in 
OpenSSH (under the BSD license)? Also, are these particular patents a USA only problem, 
or are some granted in other countries?

It seems that software patents are a growing concern around the world, with the USA 
seeming to be beyond hope.

Anyway, it would be great to have an SRP type authentication built into OpenSSH - without 
resorting to patching the source with Dr. Tom Holroyd's patch everytime a new version is 
released.

--
Jeremy



From dtucker at zip.com.au  Wed Sep 17 16:25:23 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 16:25:23 +1000
Subject: sshd 3.7p1 dies on MacOSX
References: <345A6FD0-E890-11D7-9027-00039344D894@golem.ph.utexas.edu>
Message-ID: <3F67FE53.A0DDC992@zip.com.au>

Jacques Distler wrote:
>    debug1: permanently_set_uid: 17/17
>    setuid 17: Operation not permitted
>    debug1: Calling cleanup 0x24c8c(0x0)

Please try adding "#define SETEUID_BREAKS_SETUID 1" to config.h and
recompiling.

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



From dtucker at zip.com.au  Wed Sep 17 16:44:12 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 16:44:12 +1000
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
References: <20030916215332.GN5170@Favog.ubiqx.mn.org>
Message-ID: <3F6802BC.7F633AB5@zip.com.au>

"Christopher R. Hertel" wrote:
> I am using Irix, but I'm using SGI's compiler, not GCC, so I commented out
> the line.  OpenSSH then compiled.

> debug1: Local version string SSH-1.5-OpenSSH_3.7p1
> debug3: privsep user:group 6666:6666
> debug1: permanently_set_uid: 6666/6666
> : was able to restore old [e]gid

This is the problem here.  What are all of the SET*[UG]ID defines set to
in config.h?

Quick way to find out:
$ egrep 'SET.*ID' config.h

You may be able to sort it by out by defining "BROKEN_SETREUID" and
"BROKEN_SETREGID", and possibly SETEUID_BREAKS_SETUID.

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



From chris at obelix.hedonism.cx  Wed Sep 17 17:09:24 2003
From: chris at obelix.hedonism.cx (Christian Vogel)
Date: Wed, 17 Sep 2003 09:09:24 +0200
Subject: Pre-RedHat 9.0 RPM Packages
In-Reply-To: <200309161531.39978.jason@devrandom.org>;
	from jason@devrandom.org on Tue, Sep 16, 2003 at 03:31:39PM -0400
References: <200309161531.39978.jason@devrandom.org>
Message-ID: <20030917090924.B13916@obelix.frop.org>

Hi,

On Tue, Sep 16, 2003 at 03:31:39PM -0400, Jason McCormick wrote:
>   Since I have a mixture of RH 7.1, 7.2, 7.3 and Advanced Server 2.1 
> boxes, I've made a set of RPMs for those platforms.  I do not have a 

if anyone is interested, I also built RPMs on RH 7.0.

	http://www.hedonism.cx/openssh-3.7p1/

Please note: my RPMs are all without x11/gnome askpass!

    Chris

-- 
Dilbert: Nature compensates for weaknesses, that's why blind
people have good hearing. -- Dogbert: I guess that also explains
why dumb people have big mouths. (An old Dilbert. http://www.dilbert.com)



From tempalias-openssh-list at ipi.fi  Wed Sep 17 17:41:36 2003
From: tempalias-openssh-list at ipi.fi (Osmo Paananen)
Date: Wed, 17 Sep 2003 10:41:36 +0300
Subject: Weird behaviour
Message-ID: <20030917074136.GA32294@ipi.fi>

Hi!

I just compiled/installed openssh 3.7p1 (and 3.7.1p1) for solaris some
time ago.  It has weird behaviour.

When I run ssh <hostname> and I enter invalid password I get six
password
prompts:

using new version of openssh:
% ssh hostname
Password:
Password:
Password:
user at hosts's password:
Permission denied, please try again.
user at hosts's password:
Permission denied, please try again.
user at hosts's password:

and this is how it works on the previous version:

ssh host
user at hosts's password:
Permission denied, please try again.
user at hosts's password:
Permission denied, please try again.
user at hosts's password:


What might cause this? I compiled the same version for linux,
it doesn't do this.

--
  Osmo Paananen



From markus at openbsd.org  Wed Sep 17 17:00:01 2003
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Sep 2003 09:00:01 +0200
Subject: SRP secure remote password authentication
In-Reply-To: <8463549.1063796418@[192.168.1.14]>
References: <8463549.1063796418@[192.168.1.14]>
Message-ID: <20030917070001.GB24913@folly>

SRP and similar protocols have patent problems.

are there any without?

On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
> Are there any plans to include support for SRP or a similar zero-knowledge 
> password protocol into OpenSSH?
> 
> -- 
> Jeremy
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From dan at doxpara.com  Wed Sep 17 06:02:35 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 16 Sep 2003 13:02:35 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <8463549.1063796418@[192.168.1.14]>
References: <8463549.1063796418@[192.168.1.14]>
Message-ID: <3F676C5B.5000105@doxpara.com>

Jeremy Nysen wrote:

> Are there any plans to include support for SRP or a similar 
> zero-knowledge password protocol into OpenSSH?
>
Talked about, at length.  Even got code working.  Came to the conclusion 
that until we find a workable system of using it to support centralized 
authentication, it's not worth the surprisingly small gains.

Consider:  You end up having to abandon OS level password systems.  No 
PAM, no MD5 passwords...SSH needs to take it all inhouse, because the 
daemon never receives the plaintext to toss elsewhere.  Each account 
ends up with a password equivalent of a pubkey, which (as we discovered 
through testing) is fundamentally crackable given the amount of entropy 
contained within.

Now, there is a really interesting model by which you validate unknown 
host keys because the password mutually authenticates, but it's 
surprisingly tricky to make it work right...and until it works right, 
it's better not to do at all.

Search for Tom Holroyd's (Dr. Tom) work on this subject.

--Dan




From stas at zend.com  Wed Sep 17 18:54:40 2003
From: stas at zend.com (Stanislav Malyshev)
Date: Wed, 17 Sep 2003 11:54:40 +0300 (IDT)
Subject: OpenSSH 3.7.1 compatibility problems on Linux
Message-ID: <Pine.LNX.4.44.0309171127300.31409-100000@shire.zend.office>

I have build OpenSSH 3.7.1p1 on Linux from src.rpm available for download 
on the site, and after installation I have discovered that this version of 
openssh has many compatibility problems with old and third-party clients 
that previous versions did not have. 
For example:

PuTTY (very popular free Windows client) cannot authenticate user when 
using protocol version 1. Works with protocol version 2.

SecureCRT (another popular commercial Windows client) cannot authenticate 
with password authentication using both protocols 1 and 2, but succeeds 
using "keyboard interactive" authentication.

Various older Unix clients (such as SSH 2.0 or 1.2.27 from ssh.fi, etc.) 
fail to authenticate with both ptotocols 1 and 2. 

With newer clients, using protocol 1 gives very strange greeting - first
Password: 
Response: 
and then if password not given, <user>@<hostname>'s password:
Authentication with the latter never works, however works with the former.

I understand that somehow password authenticatiom method became broken or 
disabled. Is there a way to restore it?

I understand this is very hard to be compatible with all variety of 
existing SSH clients, however all mentioned applications were working 
flawlessly with previous versions of OpenSSH and only after upgrade to 
latest 3.7 version the problems started. Could you give an advice where to 
look for solution or what can be changed to make these clients work again? 
Is there any logging options that could help to see why the server fails 
to authenticate? Syslog shows just "Failed password for <username>" which 
is not very helpful.

-- 
Stanislav Malyshev, Zend Products Engineer   
stas at zend.com  http://www.zend.com/ +972-3-6139665 ext.109






From heiko at FU-Berlin.DE  Wed Sep 17 19:10:09 2003
From: heiko at FU-Berlin.DE (Heiko Schlichting)
Date: Wed, 17 Sep 2003 11:10:09 +0200
Subject: Compilation of 3.7p1 failed on IRIX (missing file)
In-Reply-To: <20030916211354.GB58646@spuckler.il.thewrittenword.com>
References: <20030916184508.GB83092@CIS.FU-Berlin.DE>
	<20030916211354.GB58646@spuckler.il.thewrittenword.com>
Message-ID: <20030917091009.GB84073@CIS.FU-Berlin.DE>

Albert Chin wrote:
> Does the resulting sshd work on your IRIX machine?

No, it does not:

$ ./sshd -de
debug1: sshd version OpenSSH_3.7p1
[...]
debug1: Server will not fork when running in debugging mode.
Connection from 160.45.11.131 port 6000
debug1: Client protocol version 2.0; client software version
OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.7p1
debug1: permanently_set_uid: 60002/60002
: was able to restore old [e]gid
debug1: Calling cleanup 0x1004ce90(0x0)

Heiko

Heiko Schlichting        | Freie Universit?t Berlin
heiko at FU-Berlin.DE       | Zentraleinrichtung f?r Datenverarbeitung (ZEDAT)
Telefon +49 30 838-54327 | Fabeckstra?e 32
Telefax +49 30 838454327 | 14195 Berlin



From markus at openbsd.org  Wed Sep 17 19:18:11 2003
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Sep 2003 11:18:11 +0200
Subject: sftp reget/reput
In-Reply-To: <1178101319.20030917111236@oganer.net>
References: <1178101319.20030917111236@oganer.net>
Message-ID: <20030917091810.GA8916@folly>

we could modify the protocol and implement
rolling checksums like Niels Provos suggests:

	MD5_CTX ctx1, ctx2;

	MD5_Init(&ctx1);

	while new page in data
	  MD5_Update(&ctx1, newpage, pagesize)
	  ctx2 = ctx1;
	  MD5_Final(digest, &ctx2)
	  if (compare with remote not equal)
	     break;
	end while

	continue data transfer.

On Wed, Sep 17, 2003 at 11:12:36AM +0800, Dmitry Lohansky wrote:
> Hello openssh@
> 
> I thought about sftp's reget/reput commands.
> 
> Several days ago, Damien Miller write to tech at openbsd.org (it was
> reply for my letter):
> 
> > Herein lies a problem which is not easy to detect or solve. For
> > performance reasons, the sftp client does pipelined reads/writes when
> > transferring files. The protocol spec allows for a server to process
> > these requests out of order. For example:
> 
> > client                     server
> > ------                     ------
> > open file                  your file handle is "blah"
> > gimme bytes 0-8191
> > gimme bytes 8192-16383
> > gimme bytes 16384-24575
> > gimme bytes 24576-32767    here are bytes 24576-32767
> > close file                 here are bytes 16384-24575
> >                            here are bytes 8192-16383
> >                            here are bytes 0-8191
> >                            close successful
> 
> > If the client writes the bytes our in the order they are received (which
> > it probably should, to avoid buffering large amounts of data) then an
> > interruption will leave a full-length, but "holey" file on disk. There
> > is no general way to determine how to do resume such a transfer.
> 
> > The best the client can do to make transfers resumable is ftruncate()
> > the file at the highest contiguous byte received. This will stop the
> > potential corruption on resume.
> 
> This is good method, but if client crash, we also may get a "hole".
> What your think about next way?
> 
> Storing extra-data at the end of file, for example:
> 
> <---orig-part-><-extra->
> [*][ ][*][ ][*][*******]
> <---------file--------->
> 
> where [*] - already loaded data, [ ] - not yet
> 
> In extra part, we may store which block was already loaded and it
> offset and size. After download, extra part will be removed.
> 
> Comments?
> -- 
>  Dmitry Lohansky
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From markus at openbsd.org  Wed Sep 17 19:40:02 2003
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Sep 2003 11:40:02 +0200
Subject: SRP secure remote password authentication
In-Reply-To: <26669989.1063814624@[192.168.1.14]>
References: <8463549.1063796418@[192.168.1.14]> <3F67F078.5000605@mindrot.org>
	<26669989.1063814624@[192.168.1.14]>
Message-ID: <20030917094002.GB14408@folly>

we cannot add them if they are tainted.

we don't care if they are granted in _some_ countries.


On Wed, Sep 17, 2003 at 04:03:44PM +1000, Jeremy Nysen wrote:
> --On Wednesday, 17 September 2003 3:26 PM +1000 Damien Miller 
> <djm at mindrot.org> wrote:
> >Jeremy Nysen wrote:
> >>Are there any plans to include support for SRP or a similar
> >>zero-knowledge password protocol into OpenSSH?
> >
> >No, they are tainted by patents.
> 
> Are these (software?) patents licensable in any way that disencumbers their 
> use in OpenSSH (under the BSD license)? Also, are these particular patents 
> a USA only problem, or are some granted in other countries?
> 
> It seems that software patents are a growing concern around the world, with 
> the USA seeming to be beyond hope.
> 
> Anyway, it would be great to have an SRP type authentication built into 
> OpenSSH - without resorting to patching the source with Dr. Tom Holroyd's 
> patch everytime a new version is released.
> 
> --
> Jeremy
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From flavien at lebarbe.net  Wed Sep 17 20:02:45 2003
From: flavien at lebarbe.net (Flavien Lebarbe)
Date: Wed, 17 Sep 2003 12:02:45 +0200
Subject: 3.7p1 build fails with openssl 0.9.5a
Message-ID: <20030917100245.GB16775@lebarbe.net>


Hello,



I'm having trouble recompiling openssh 3.7p1 on an old RedHat (6.1).
OpenSSL Version is on this system is "openssl-0.9.5a-1". 

    ./configure --sysconfdir=/etc/ssh --with-pam
    make
    [...]
    make cipher-aes.o 
    gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.
    -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
    -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\"
    -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"
    -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\"
    -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\"
    -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H
    -c cipher-aes.c
    cipher-aes.c: In function `ssh_rijndael_init':
    cipher-aes.c:50: warning: assignment from incompatible pointer type
    cipher-aes.c: In function `ssh_rijndael_cbc':
    cipher-aes.c:78: warning: assignment from incompatible pointer type
    cipher-aes.c: In function `ssh_rijndael_cleanup':
    cipher-aes.c:116: warning: assignment from incompatible pointer type
    cipher-aes.c: In function `ssh_rijndael_iv':
    cipher-aes.c:129: warning: assignment from incompatible pointer type
    cipher-aes.c: In function `evp_rijndael':
    cipher-aes.c:147: warning: assignment from incompatible pointer type
    cipher-aes.c:148: warning: assignment from incompatible pointer type
    cipher-aes.c:149: warning: assignment from incompatible pointer type
    cipher-aes.c:151: structure has no member named `flags'
    cipher-aes.c:151: `EVP_CIPH_CBC_MODE' undeclared (first use in this
    function)
    cipher-aes.c:151: (Each undeclared identifier is reported only once
    cipher-aes.c:151: for each function it appears in.)
    cipher-aes.c:151: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in
    this function)
    cipher-aes.c:152: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in
    this function)
    cipher-aes.c:152: `EVP_CIPH_CUSTOM_IV' undeclared (first use in this
    function)
    make: *** [cipher-aes.o] Error 1

Any idea anyone ? Should SSH_OLD_EVP be defined ? I guess may  be
it should, as it's defined in cipher.c if ssl version is old. I'm
trying playing with this right now but  would  appreciate  advice
from people in the know. Thanks.


Flavien.



From markus at openbsd.org  Wed Sep 17 20:17:09 2003
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 17 Sep 2003 12:17:09 +0200
Subject: Weird behaviour
In-Reply-To: <20030917074136.GA32294@ipi.fi>
References: <20030917074136.GA32294@ipi.fi>
Message-ID: <20030917101709.GA9129@folly>

On Wed, Sep 17, 2003 at 10:41:36AM +0300, Osmo Paananen wrote:
> Hi!
> 
> I just compiled/installed openssh 3.7p1 (and 3.7.1p1) for solaris some
> time ago.  It has weird behaviour.
> 
> When I run ssh <hostname> and I enter invalid password I get six
> password
> prompts:
> 
> using new version of openssh:
> % ssh hostname
> Password:
> Password:
> Password:

hm, this indicates pam, or challenge response...

> user at hosts's password:
> Permission denied, please try again.
> user at hosts's password:
> Permission denied, please try again.
> user at hosts's password:
> 
> and this is how it works on the previous version:
> 
> ssh host
> user at hosts's password:
> Permission denied, please try again.
> user at hosts's password:
> Permission denied, please try again.
> user at hosts's password:
> 
> 
> What might cause this? I compiled the same version for linux,
> it doesn't do this.
> 
> --
>   Osmo Paananen
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From openssh at roumenpetrov.info  Wed Sep 17 21:41:55 2003
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Wed, 17 Sep 2003 14:41:55 +0300
Subject: X.509v3 certificates support  in OpenSSH-3.7.1p1
Message-ID: <3F684883.6010809@roumenpetrov.info>

Diff of "X.509v3 certificates support for OpenSSH" version g2 (code name 
Compatibility) for OpenSSH-3.7.1p1 is ready for download.

Go to "http://roumenpetrov.info/openssh" and get it.




From Bob.Edgar at commerzbankib.com  Wed Sep 17 22:07:02 2003
From: Bob.Edgar at commerzbankib.com (Edgar, Bob)
Date: Wed, 17 Sep 2003 14:07:02 +0200
Subject: OpenSSH 3.7 and BSM for Solaris
Message-ID: <9D248E1E43ABD411A9B600508BAF6E9B076B4469@xmx7fraib.fra.ib.commerzbank.com>

I know it was decided not to integrate the Sun BSM support into the
portable release but I was wondering if there is a new version of the
BSM patch available for 3.7 and if so where can it be had?

Thanks,
bob



From dtucker at zip.com.au  Wed Sep 17 22:15:20 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 22:15:20 +1000
Subject: openssh-3.7.1p1 segfaults
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
Message-ID: <3F685058.5C328C07@zip.com.au>

Martin Siegert wrote:
> the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> both show the same behaviour.

Does the patch here resolve it?
http://bugzilla.mindrot.org/show_bug.cgi?id=643

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



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 22:22:30 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 07:22:30 -0500
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
In-Reply-To: <030916224501.mjo@dojo.mi.org>
References: <030916224501.mjo@dojo.mi.org>
Message-ID: <20030917122230.GB74179@spuckler.il.thewrittenword.com>

On Tue, Sep 16, 2003 at 10:45:02PM -0400, Mike O'Connor wrote:
> [resending with uidswap.c instead of uidwrap.c]
> 
> 
> Once I got past the missing inet_ntoa.h weirdness, I ran into an sshd
> that died a lot.  It appears that IRIX doesn't like some of the extra
> checks added between 1.23 and 1.24 of uidswap.c.  Not sure if that
> constitutes an IRIX bug or not, but helpfully this helps someone.

It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
BROKEN_SETREUID, and BROKEN_SETREGID.

-- 
albert chin (china at thewrittenword.com)



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 22:32:09 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 07:32:09 -0500
Subject: Problems with 3.7p1 on IRIX 6.5
In-Reply-To: <3F67D629.DF213651@zip.com.au>
References: <20030916204217.GA57630@spuckler.il.thewrittenword.com>
	<3F67D629.DF213651@zip.com.au>
Message-ID: <20030917123209.GC74179@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 01:34:01PM +1000, Darren Tucker wrote:
> Albert Chin wrote:
> > $ uname -R
> > 6.5 6.5.19m
> [snip]
> > If I run sshd in debug mode:
> >   $ sshd -p 8022 -D -d -d
> >   debug2: read_server_config: filename /etc/opt/fsw/openssh37/sshd_config
> >   debug1: sshd version OpenSSH_3.7p1
> >   debug1: read PEM private key done: type RSA
> >   debug1: private host key: #0 type 1 RSA
> >   debug1: read PEM private key done: type DSA
> >   debug1: private host key: #1 type 2 DSA
> >   debug1: Bind to port 8022 on 0.0.0.0.
> >   Server listening on 0.0.0.0 port 8022.
> >   zsh: bus error (core dumped)  /opt/fsw/openssh37/sbin/sshd -p 8022 -D -d -d
> 
> Try defining BROKEN_GETADDRINFO in config.h and recompiling.
> 
> There is some suspicion about IRIX's getaddrinfo, see:
> http://bugzilla.mindrot.org/show_bug.cgi?id=585

It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
BROKEN_SETREUID, and BROKEN_SETREGID.

-- 
albert chin (china at thewrittenword.com)



From mjo at dojo.mi.org  Wed Sep 17 22:46:05 2003
From: mjo at dojo.mi.org (Mike O'Connor)
Date: Wed, 17 Sep 2003 08:46:05 -0400 (EDT)
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
Message-ID: <030917084605.mjo@dojo.mi.org>

:It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
:BROKEN_SETREUID, and BROKEN_SETREGID.

FWIW, the broken getaddrinfo() should only be needed for pre-6.5.20.

-- 
 Mail: mjo at dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"What kind of world is this?!  You only get five years to be a kid??" -Calvin



From v.pennington at man.ac.uk  Wed Sep 17 22:59:46 2003
From: v.pennington at man.ac.uk (Victoria Pennington)
Date: Wed, 17 Sep 2003 13:59:46 +0100
Subject: problems with 3.7.1p1 on IRIX (again)
Message-ID: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>

Hi,

I've seen a few messages re. problems with 3.7.1p1 on IRIX 6.5...
I'm using 6.5.19 and having no trouble compiling, installing and
starting, but sshd just closes the connection with no explanation.
debug/verbose modes don't seem to give any clues.

Darren Tucker suggested defining BROKEN_GETADDRINFO in config.h,
but I find that compilation then fails (assuming I've implemented this
right).

Has anyone had any success yet?

Thanks.

---
Victoria Pennington
Manchester Computing, Kilburn Building,
University of Manchester,
Oxford Road, Manchester M13 9PL
tel. 0161 275 6830, email: v.pennington at man.ac.uk



From distler at golem.ph.utexas.edu  Wed Sep 17 22:58:13 2003
From: distler at golem.ph.utexas.edu (Jacques Distler)
Date: Wed, 17 Sep 2003 07:58:13 -0500
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <3F680164.4212DA2A@zip.com.au>
Message-ID: <98F937AC-E90E-11D7-9027-00039344D894@golem.ph.utexas.edu>

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


On Wednesday, September 17, 2003, at 01:38  AM, Darren Tucker wrote:

> Jacques Distler wrote:
>>    debug1: permanently_set_uid: 17/17
>>    setuid 17: Operation not permitted
>>    debug1: Calling cleanup 0x24c8c(0x0)
>
> Please try adding "#define SETEUID_BREAKS_SETUID 1" to config.h and
> recompiling.


Tried that; had no effect (now verified with 3.7.1p1). Daemon still 
dies when a client connects.

I'm going back to uidswap.c from 3.6.1p1 until this gets sorted out.

(I'm surprised noone else has reported this problem. Is everyone just 
waiting for Apple to release a binary?)


jacques
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc

iD8DBQE/aFpunyqPIXpYcjcRAolYAKDgxNHmAXzaV6DYHJvctPDEc7QALACgnPcJ
C5TdlftglIbVoM2N/c6v3bQ=
=1fT6
-----END PGP SIGNATURE-----



From v.pennington at man.ac.uk  Wed Sep 17 23:11:35 2003
From: v.pennington at man.ac.uk (Victoria Pennington)
Date: Wed, 17 Sep 2003 14:11:35 +0100
Subject: Problems with 3.7p1 on IRIX 6.5
In-Reply-To: <20030917123209.GC74179@spuckler.il.thewrittenword.com>
References: <20030916204217.GA57630@spuckler.il.thewrittenword.com>
	<3F67D629.DF213651@zip.com.au>
	<20030917123209.GC74179@spuckler.il.thewrittenword.com>
Message-ID: <Pine.SGI.4.56.0309171407170.11830@troll.mcc.ac.uk>

On Wed, 17 Sep 2003, Albert Chin wrote:

> It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
> BROKEN_SETREUID, and BROKEN_SETREGID.

Do you define them all to be 1?  e.g.

#define BROKEN_GETADDRINFO 1

I tried this, but get the following compilation error:

# make
        cc -g -I. -I. -I/usr/local/ssl/include  -I/usr/local/include -DSSHDIR=\"/usr/local/etc\"  -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"  -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\"  -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"  -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\"  -D_PATH_SSH_PIDDIR=\"/usr/local/etc\"  -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\"  -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c moduli.c
cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5
  #error directive:  This header file is to be used only for c99 mode
          compilations

  #error This header file is to be used only for c99 mode compilations
   ^

cc-1143 cc: ERROR File = openbsd-compat/fake-rfc2553.h, Line = 141
  Declaration is incompatible with "const char *gai_strerror(int)" (declared at
          line 147 of "/usr/include/netdb.h").

  char *gai_strerror(int);
        ^

1 error detected in the compilation of "moduli.c".
*** Error code 2 (bu21)

Victoria



From DPurks at Cogentco.com  Wed Sep 17 23:23:39 2003
From: DPurks at Cogentco.com (Purks, Dave)
Date: Wed, 17 Sep 2003 09:23:39 -0400
Subject: problem with configure in openssh-3.7p1
Message-ID: <E15A0A26BB57B845AF909DA6C14EBEE1105D53FB@dca-03.ms.cogentco.com>


Problem: setting --with-tcpwrappers does not configure code to be compiled
with wrapper support

Solution: references to with_tcp_wrappers (lines 4975, 6396, 6397) need to
be changed to with_tcpwrappers


David Purks
Sr Sys Admin
Cogent Communications



From dtucker at zip.com.au  Wed Sep 17 23:28:13 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 23:28:13 +1000
Subject: sshd 3.7p1 dies on MacOSX
References: <98F937AC-E90E-11D7-9027-00039344D894@golem.ph.utexas.edu>
Message-ID: <3F68616D.537AD9AF@zip.com.au>

Jacques Distler wrote:
> On Wednesday, September 17, 2003, at 01:38  AM, Darren Tucker wrote:
> 
> > Jacques Distler wrote:
> >>    debug1: permanently_set_uid: 17/17
> >>    setuid 17: Operation not permitted
> >>    debug1: Calling cleanup 0x24c8c(0x0)
> >
> > Please try adding "#define SETEUID_BREAKS_SETUID 1" to config.h and
> > recompiling.
[didn't help]

What are the SET*ID defines in config.h?
Try "egrep 'SET.*ID' config.h" or whatever that translates to on MacOS X.

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



From janfrode at parallab.uib.no  Wed Sep 17 23:35:27 2003
From: janfrode at parallab.uib.no (Jan-Frode Myklebust)
Date: Wed, 17 Sep 2003 15:35:27 +0200
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
In-Reply-To: <030917084605.mjo@dojo.mi.org>
References: <030917084605.mjo@dojo.mi.org>
Message-ID: <20030917133527.GA30120@ii.uib.no>

On Wed, Sep 17, 2003 at 08:46:05AM -0400, Mike O'Connor wrote:
> :It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
> :BROKEN_SETREUID, and BROKEN_SETREGID.
> 
> FWIW, the broken getaddrinfo() should only be needed for pre-6.5.20.

Doesn't seem needed on 6.5.17m, it even broke if I defined it.
Building with MIPSPro and SETEUID_BREAKS_SETUID, BROKEN_SETREUID, 
BROKEN_SETREGID and removed inet_ntoa.h seems to work for me.

Hope an "official" fix soon will emerge..

  
  -jf



From distler at golem.ph.utexas.edu  Wed Sep 17 23:37:20 2003
From: distler at golem.ph.utexas.edu (Jacques Distler)
Date: Wed, 17 Sep 2003 08:37:20 -0500
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <3F68616D.537AD9AF@zip.com.au>
Message-ID: <0FCF079E-E914-11D7-9027-00039344D894@golem.ph.utexas.edu>

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


On Wednesday, September 17, 2003, at 08:28  AM, Darren Tucker wrote:

>>> Jacques Distler wrote:
>>>>    debug1: permanently_set_uid: 17/17
>>>>    setuid 17: Operation not permitted
>>>>    debug1: Calling cleanup 0x24c8c(0x0)
>>>
>>> Please try adding "#define SETEUID_BREAKS_SETUID 1" to config.h and
>>> recompiling.
> [didn't help]
>
> What are the SET*ID defines in config.h?
> Try "egrep 'SET.*ID' config.h" or whatever that translates to on MacOS 
> X.

   % egrep 'SET.*ID' config.h
   /* #undef SETEUID_BREAKS_SETUID */
   /* #undef BROKEN_SETREUID */
   /* #undef BROKEN_SETREGID */
   #define HAVE_SETEGID 1
   #define HAVE_SETEUID 1
   /* #undef HAVE_SETLUID */
   #define HAVE_SETREGID 1
   /* #undef HAVE_SETRESGID */
   /* #undef HAVE_SETRESUID */
   #define HAVE_SETREUID 1
   #define HAVE_SETSID 1

Jacques
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc

iD8DBQE/aGOYnyqPIXpYcjcRAq5QAJ0XufAW3CMNeJdcMWeQHgALJNLdhwCaAhj7
gQKbEFhBBbZhp0bs32OVLow=
=EbiR
-----END PGP SIGNATURE-----



From ayamura at ayamura.org  Wed Sep 17 23:48:50 2003
From: ayamura at ayamura.org (Ayamura KIKUCHI)
Date: Wed, 17 Sep 2003 22:48:50 +0900
Subject: Problems with 3.7p1 on IRIX 6.5
In-Reply-To: <20030917123209.GC74179@spuckler.il.thewrittenword.com>
References: <20030916204217.GA57630@spuckler.il.thewrittenword.com>
	<3F67D629.DF213651@zip.com.au>
	<20030917123209.GC74179@spuckler.il.thewrittenword.com>
Message-ID: <8665jr8r0d.wl@sea.ayamura.org>

> It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
> BROKEN_SETREUID, and BROKEN_SETREGID.

required macro preprocessors for IRIX 6.5.21:
	SETEUID_BREAKS_SETUID/BROKEN_SETREUID/BROKEN_SETREGID
no required:
	BROKEN_GETADDRINFO/BROKEN_INET_NTOA

-- ayamura



From dtucker at zip.com.au  Wed Sep 17 23:53:44 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Sep 2003 23:53:44 +1000
Subject: sshd 3.7p1 dies on MacOSX
References: <0FCF079E-E914-11D7-9027-00039344D894@golem.ph.utexas.edu>
Message-ID: <3F686768.2550F24@zip.com.au>

Jacques Distler wrote:
>    % egrep 'SET.*ID' config.h
>    /* #undef SETEUID_BREAKS_SETUID */
>    /* #undef BROKEN_SETREUID */
>    /* #undef BROKEN_SETREGID */
>    #define HAVE_SETEGID 1
>    #define HAVE_SETEUID 1
>    /* #undef HAVE_SETLUID */
>    #define HAVE_SETREGID 1
>    /* #undef HAVE_SETRESGID */
>    /* #undef HAVE_SETRESUID */
>    #define HAVE_SETREUID 1
>    #define HAVE_SETSID 1

With those defines, I'd expect the same behaviour as 3.6.1p2, and I'd also
expect SETEUID_BREAKS_SETUID to resolve it.  I dunno. 

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



From openssh-unix-dev at thewrittenword.com  Wed Sep 17 23:57:27 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 08:57:27 -0500
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
In-Reply-To: <030917084605.mjo@dojo.mi.org>
References: <030917084605.mjo@dojo.mi.org>
Message-ID: <20030917135727.GA79823@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 08:46:05AM -0400, Mike O'Connor wrote:
> :It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
> :BROKEN_SETREUID, and BROKEN_SETREGID.
> 
> FWIW, the broken getaddrinfo() should only be needed for pre-6.5.20.

Do you know how we can test for a broken getaddrinfo?

-- 
albert chin (china at thewrittenword.com)



From eddy at cdf-imaging.com  Thu Sep 18 00:24:25 2003
From: eddy at cdf-imaging.com (Edward Flick)
Date: Wed, 17 Sep 2003 09:24:25 -0500
Subject: SRP Support
Message-ID: <DBEJKFKIDIDOKKCGEDHMGEJECIAA.eddy@cdf-imaging.com>

Just wondering if there were any plans to integrate SRP support into
OpenSSH.  And if there aren't would a patch be accepted that would enable
such.  And if so could anyone give me a couple of pointers as to where the
authentication code goes.

Edward Flick



From distler at golem.ph.utexas.edu  Thu Sep 18 00:15:51 2003
From: distler at golem.ph.utexas.edu (Jacques Distler)
Date: Wed, 17 Sep 2003 09:15:51 -0500
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <3F686768.2550F24@zip.com.au>
Message-ID: <71664806-E919-11D7-9027-00039344D894@golem.ph.utexas.edu>

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


On Wednesday, September 17, 2003, at 08:53  AM, Darren Tucker wrote:

> Jacques Distler wrote:
>>    % egrep 'SET.*ID' config.h
>>    /* #undef SETEUID_BREAKS_SETUID */
>>    /* #undef BROKEN_SETREUID */
>>    /* #undef BROKEN_SETREGID */
>>    #define HAVE_SETEGID 1
>>    #define HAVE_SETEUID 1
>>    /* #undef HAVE_SETLUID */
>>    #define HAVE_SETREGID 1
>>    /* #undef HAVE_SETRESGID */
>>    /* #undef HAVE_SETRESUID */
>>    #define HAVE_SETREUID 1
>>    #define HAVE_SETSID 1
>
> With those defines, I'd expect the same behaviour as 3.6.1p2, and I'd 
> also
> expect SETEUID_BREAKS_SETUID to resolve it.  I dunno.


Well, thanks for trying. I've posted a note 
<http://golem.ph.utexas.edu/~distler/blog/archives/000221.html> on my 
weblog warning MacOSX users about this.

Jacques
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc

iD8DBQE/aGyfnyqPIXpYcjcRApg2AKCgBG5e3J6NwdFAXcY8BrhpfwAD0wCglrf3
XhN4mLfUH4UuXYnd1IzNjv4=
=tnZH
-----END PGP SIGNATURE-----



From jmknoble at pobox.com  Thu Sep 18 00:29:58 2003
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 17 Sep 2003 10:29:58 -0400
Subject: OpenBSD 3.3 x86 Build Problem
In-Reply-To: <20030916094310.Q86384@catastrophe.net>
References: <20030916094310.Q86384@catastrophe.net>
Message-ID: <20030917142957.GA566@crawfish.ais.com>

Circa 2003-09-16 09:43:10 -0500 dixit Eric:

: I'm seeing this on a clean build after downloading 3.7 to my
: OpenBSD source tree...
  [...]
:  gss-serv-krb5.o: Undefined symbol `_gss_krb5_copy_ccache'
:  referenced from text segment
:  collect2: ld returned 1 exit status
:  *** Error code 1
  [...]
: Does anything need to be sync'ed in the source tree?
: 
: I'm on OpenBSD 3.3, x86.

No troubles here (OBSD 3.3/i386).  How did you get the sources---by
downloading the tarball, or via CVS?  If via CVS, perhaps you managed
to provoke a race condition (since CVS doesn't have atomic filegroup
commits) and only got a portion of the full 3.7 update; try updating
from CVS again.

When was the last time you updated your /usr/src/ tree from CVS?
Perhaps you need more than merely an updated ssh?

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
"We have guided missiles and misguided men." --Martin Luther King, Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 256 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/dcc1603f/attachment.bin 

From janfrode at parallab.uib.no  Thu Sep 18 00:41:09 2003
From: janfrode at parallab.uib.no (Jan-Frode Myklebust)
Date: Wed, 17 Sep 2003 16:41:09 +0200
Subject: Problems with 3.7p1 on IRIX 6.5
In-Reply-To: <Pine.SGI.4.56.0309171407170.11830@troll.mcc.ac.uk>
References: <20030916204217.GA57630@spuckler.il.thewrittenword.com>
	<3F67D629.DF213651@zip.com.au>
	<20030917123209.GC74179@spuckler.il.thewrittenword.com>
	<Pine.SGI.4.56.0309171407170.11830@troll.mcc.ac.uk>
Message-ID: <20030917144109.GD30120@ii.uib.no>

On Wed, Sep 17, 2003 at 02:11:35PM +0100, Victoria Pennington wrote:
> On Wed, 17 Sep 2003, Albert Chin wrote:
> 
> > It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
> > BROKEN_SETREUID, and BROKEN_SETREGID.
> 
> Do you define them all to be 1?  e.g.
> 
> #define BROKEN_GETADDRINFO 1

Just define them:

% egrep 'BROKEN_GETADDRINFO|SETEUID_BREAKS_SETUID|BROKEN_SETREUID|BROKEN_SETREGID' config.h
#define SETEUID_BREAKS_SETUID
#define BROKEN_SETREUID
#define BROKEN_SETREGID
/* #define BROKEN_GETADDRINFO */


> 
> I tried this, but get the following compilation error:

I got the same problem with BROKEN_GETADDRINFO, but removed 
it from config.h, and then it worked.

% uname -R
6.5 6.5.17m
% cc -version
MIPSpro Compilers: Version 7.3.1.3m
% setenv CC cc
% ./configure --prefix=/usr/openssh --with-ssl-dir=/usr/local/ssl --with-rsh=/usr/bsd/rsh --with-default-path=/usr/bin:/bin:/usr/sbin:/sbin:/usr/openssh/bin --disable-suid-ssh
% make
% make install


   -jf



From mouring at etoh.eviladmin.org  Thu Sep 18 00:48:34 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 17 Sep 2003 09:48:34 -0500 (CDT)
Subject: sftp reget/reput
In-Reply-To: <20030917091810.GA8916@folly>
Message-ID: <Pine.BSO.4.44.0309170946390.842-100000@etoh.eviladmin.org>


I would love to see a modification to the SSH protocol to support the
ability for the client to ask the sever for a checksum without getting the
physical data.

It would be useful in reget, and would be useful for people building more
advanced features to detect file changes and download only the blocks that
need updating.

I've thought of it off and on, but never sat down and implemented and
wrote up a document on it.

- Ben


On Wed, 17 Sep 2003, Markus Friedl wrote:

> we could modify the protocol and implement
> rolling checksums like Niels Provos suggests:
>
> 	MD5_CTX ctx1, ctx2;
>
> 	MD5_Init(&ctx1);
>
> 	while new page in data
> 	  MD5_Update(&ctx1, newpage, pagesize)
> 	  ctx2 = ctx1;
> 	  MD5_Final(digest, &ctx2)
> 	  if (compare with remote not equal)
> 	     break;
> 	end while
>
> 	continue data transfer.
>
> On Wed, Sep 17, 2003 at 11:12:36AM +0800, Dmitry Lohansky wrote:
> > Hello openssh@
> >
> > I thought about sftp's reget/reput commands.
> >
> > Several days ago, Damien Miller write to tech at openbsd.org (it was
> > reply for my letter):
> >
> > > Herein lies a problem which is not easy to detect or solve. For
> > > performance reasons, the sftp client does pipelined reads/writes when
> > > transferring files. The protocol spec allows for a server to process
> > > these requests out of order. For example:
> >
> > > client                     server
> > > ------                     ------
> > > open file                  your file handle is "blah"
> > > gimme bytes 0-8191
> > > gimme bytes 8192-16383
> > > gimme bytes 16384-24575
> > > gimme bytes 24576-32767    here are bytes 24576-32767
> > > close file                 here are bytes 16384-24575
> > >                            here are bytes 8192-16383
> > >                            here are bytes 0-8191
> > >                            close successful
> >
> > > If the client writes the bytes our in the order they are received (which
> > > it probably should, to avoid buffering large amounts of data) then an
> > > interruption will leave a full-length, but "holey" file on disk. There
> > > is no general way to determine how to do resume such a transfer.
> >
> > > The best the client can do to make transfers resumable is ftruncate()
> > > the file at the highest contiguous byte received. This will stop the
> > > potential corruption on resume.
> >
> > This is good method, but if client crash, we also may get a "hole".
> > What your think about next way?
> >
> > Storing extra-data at the end of file, for example:
> >
> > <---orig-part-><-extra->
> > [*][ ][*][ ][*][*******]
> > <---------file--------->
> >
> > where [*] - already loaded data, [ ] - not yet
> >
> > In extra part, we may store which block was already loaded and it
> > offset and size. After download, extra part will be removed.
> >
> > Comments?
> > --
> >  Dmitry Lohansky
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From flash at itp.tu-graz.ac.at  Thu Sep 18 00:58:02 2003
From: flash at itp.tu-graz.ac.at (Christian Pfaffel)
Date: Wed, 17 Sep 2003 14:58:02 -0000
Subject: gssapi and pam problems with 3.7.1p1
Message-ID: <7gn0d3ihmw.fsf@faeppc20.tu-graz.ac.at>

Hello everybody!

I have the following problem using version 3.7.1p1 on redhat linux 7.3
and 9. We are running a system where users home directories reside on
AFS.

Up to and including version 3.6.1p2 we used Simon Wilkinson's gssapi
patch in conjunction with a pam_module, which executed 'aklog', a
program that converts a kerberos ticket to an AFS token.

This does not work anymore with priv separation enabled. I had a look
at the sources and found out, that the transferred Kerberos
credentials got stored after the pam_session module was executed. I
therefor created the attached small patch, which makes it work for
me. I am sure that it is not an elegant method, but...

If there is a different way to go please let me know.

regards,
Christian Pfaffel

-- 
Christian Pfaffel <flash at itp.tu-graz.ac.at>
Technische Universit?t Graz                 Telefon: +43 / 316 / 873 - 81 90
Institut f?r Theoretische Physik            Telefax: +43 / 316 / 873 - 86 78
Petersgasse 16, A-8010 Graz   http://fubphpc.tu-graz.ac.at/~flash/pubkey.gpg



From openssh-unix-dev at thewrittenword.com  Thu Sep 18 01:02:16 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 10:02:16 -0500
Subject: problems with 3.7.1p1 on IRIX (again)
In-Reply-To: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
References: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
Message-ID: <20030917150216.GA80595@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 01:59:46PM +0100, Victoria Pennington wrote:
> I've seen a few messages re. problems with 3.7.1p1 on IRIX 6.5...
> I'm using 6.5.19 and having no trouble compiling, installing and
> starting, but sshd just closes the connection with no explanation.
> debug/verbose modes don't seem to give any clues.
> 
> Darren Tucker suggested defining BROKEN_GETADDRINFO in config.h,
> but I find that compilation then fails (assuming I've implemented this
> right).
> 
> Has anyone had any success yet?

I use the following patch for IRIX. Rerun autoconf and autoheader.

-- 
albert chin (china at thewrittenword.com)

-- snip snip
--- configure.ac.orig	Tue Sep 16 09:39:55 2003
+++ configure.ac	Wed Sep 17 09:22:03 2003
@@ -198,6 +178,10 @@
 	AC_DEFINE(WITH_IRIX_AUDIT)
 	AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)])
 	AC_DEFINE(BROKEN_INET_NTOA)
+	AC_DEFINE(BROKEN_GETADDRINFO)
+	AC_DEFINE(SETEUID_BREAKS_SETUID)
+	AC_DEFINE(BROKEN_SETREUID)
+	AC_DEFINE(BROKEN_SETREGID)
 	AC_DEFINE(WITH_ABBREV_NO_TTY)
 	AC_DEFINE(LOCKED_PASSWD_STRING, "*LK*")
 	;;
@@ -714,7 +699,7 @@
 AC_CHECK_FUNCS(\
 	arc4random __b64_ntop b64_ntop __b64_pton b64_pton basename \
 	bcopy bindresvport_sa clock fchmod fchown freeaddrinfo futimes \
-	gai_strerror getaddrinfo getcwd getgrouplist getnameinfo getopt \
+	getaddrinfo getcwd getgrouplist getnameinfo getopt \
 	getpeereid _getpty getrlimit getttyent glob inet_aton \
 	inet_ntoa inet_ntop innetgr login_getcapbool md5_crypt memmove \
 	mkdtemp mmap ngetaddrinfo nsleep ogetaddrinfo openlog_r openpty \
@@ -725,6 +710,21 @@
 	strlcat strlcpy strmode strnvis sysconf tcgetpgrp \
 	truncate utimes vhangup vsnprintf waitpid \
 )
+
+# IRIX has a const char return value for gai_strerror()
+AC_CHECK_FUNCS(gai_strerror,[
+	AC_DEFINE(HAVE_GAI_STRERROR)
+	AC_TRY_COMPILE([
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <netdb.h>
+
+const char *gai_strerror(int);],[
+char *str;
+
+str = gai_strerror(0);],[
+		AC_DEFINE(HAVE_CONST_GAI_STRERROR_PROTO, 1,
+		[Define if gai_strerror() returns const char *])])])
 
 AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP))
 
--- openbsd-compat/fake-rfc2553.h.orig	Wed Sep 17 05:45:58 2003
+++ openbsd-compat/fake-rfc2553.h	Wed Sep 17 08:55:52 2003
@@ -137,7 +137,7 @@
     const struct addrinfo *, struct addrinfo **);
 #endif /* !HAVE_GETADDRINFO */
 
-#ifndef HAVE_GAI_STRERROR
+#if !defined(HAVE_GAI_STRERROR) && !defined(HAVE_CONST_GAI_STRERROR_PROTO)
 char *gai_strerror(int);
 #endif /* !HAVE_GAI_STRERROR */
 
--- openbsd-compat/fake-rfc2553.c.orig	Wed Sep 17 05:46:02 2003
+++ openbsd-compat/fake-rfc2553.c	Wed Sep 17 08:55:11 2003
@@ -77,7 +77,11 @@
 #endif /* !HAVE_GETNAMEINFO */
 
 #ifndef HAVE_GAI_STRERROR
+#ifdef HAVE_CONST_GAI_STRERROR_PROTO
+const char *
+#else
 char *
+#endif
 gai_strerror(int err)
 {
 	switch (err) {



From csoler at nextel.es  Thu Sep 18 01:05:22 2003
From: csoler at nextel.es (=?ISO-8859-1?B?Q+lzYXIgU29sZXI=?=)
Date: Wed, 17 Sep 2003 17:05:22 +0200
Subject: upgrade from 2.2p1 to 3.Xp1
Message-ID: <15831426000.20030917170522@nextel.es>

Hi,

at the begining of summer we were planning to upgrade the openssh
version up to 3.4, but nowadays we would like to upgrade to 3.7...

now we have the same problems we found with the 3.4 version: it seems
as 2.2 and 3.X are incompatible versions, or they use incompatible
methods to exchange some information that we don't know how to
change...

we need interoperation during the upgrade progress, because there are
a lot of cron process that need ssh to connect to other machines...

if somebody could help in away or give us any clue about the problem or
error, we should be very very grateful.

Anyway, thanks for reading and your help!

Pd.- I attach some files with debug information, in case somebody could
read them... There are two tries of connection between 2.2 and 3.6
clients and a 2.2 server, changing the client binaries only (the
private/public keys and configuration files are the same).

-- 
Best regards,

En fecha Tuesday, June 17, 2003, 5:56:03 PM, escribi?:

MF> On Tue, Jun 17, 2003 at 05:21:32PM +0200, C?sar Soler wrote:
>> Hi,
>> 
>> We are trying to upgrade the openssh version from 2.2p1 to 3.4p1, but
>> we have found many issues/problems. If somebody could tell us any clue
>> to solve them, it would be appreciated:
>> 
>> - ssh client version 3.4 seems to be incompatible with sshd 2.2. is
>> this true or just we have not found the right options at the command line?

MF> there should be no problems for interoperation.

MF> however, 3.4 might not like all the config file options
MF> from 2.2 and vice versa.

 C?sar                            mailto:csoler at nextel.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.server2.2-client2.2
Type: application/octet-stream
Size: 4414 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/2169558d/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.server2.2-client3.6
Type: application/octet-stream
Size: 2078 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/2169558d/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.server2.2-client2.2
Type: application/octet-stream
Size: 3851 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/2169558d/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.server2.2-client3.6
Type: application/octet-stream
Size: 2472 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/2169558d/attachment-0003.obj 

From doctor at doctor.nl2k.ab.ca  Thu Sep 18 01:19:44 2003
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 17 Sep 2003 09:19:44 -0600
Subject: problems with 3.7.1p1 on BSD/OS
In-Reply-To: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
References: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
Message-ID: <20030917151944.GA17099@doctor.nl2k.ab.ca>

This is what is happening on BSD/OS.


Script started on Wed Sep 17 06:20:55 2003
doctor.nl2k.ab.ca/~$ssh -v -2 -i ~doctor/.ssh/id_rsa -l doctor uucp
OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.6j [engine] 10 Apr 2003
debug1: Reading configuration data /usr/contrib/etc/ssh_config
debug1: Connecting to uucp [204.209.81.3] port 22.
debug1: Connection established.
debug1: identity file /usr/home/doctor/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p1
debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p1
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 204.209.81.3
debug1: Calling cleanup 0x80608b0(0x0)
doctor.nl2k.ab.ca/~$exit
exit

Script done on Wed Sep 17 06:21:34 2003

Before I was able to get in 0 problems.

-- 
Member - Liberal International	On 11 Sept 2001 the WORLD was violated.
This is doctor at nl2k.ab.ca	Ici doctor at nl2k.ab.ca
Society MUST be saved! Extremists must dissolve.  
Ontario on 2 Octo 2003, VOTE LIBERAL!!



From florian at void.s.bawue.de  Thu Sep 18 01:32:19 2003
From: florian at void.s.bawue.de (Florian Laws)
Date: Wed, 17 Sep 2003 17:32:19 +0200
Subject: openssh-unix-dev@mindrot.org 
Message-ID: <20030917173219.A21614@helena.bawue.de>

Hello,

I'm getting compile errors on AIX 5.1,
not defining WITH_AIXAUTHENTICATE in config.h seems to solve the problem.

I have configured with --syscondir=/etc/ssh and --with-ssl-dir=/usr/local/ssl
and I am using gcc 2.95.3 
The error messages is included below.

Regards,

Florian

----

make[1]: Entering directory `/home/dmc/src/openssh-3.7.1p1/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/usr/local/ssl/include  -I/usr/local/include -DHAVE_CONFIG_H -c bsd-arc4random.c
In file included from ../openbsd-compat/port-aix.h:33,
                 from ../openbsd-compat/openbsd-compat.h:166,
                 from ../includes.h:173,
                 from bsd-arc4random.c:25:
/usr/include/usersec.h:625: warning: `struct aud_rec' declared inside parameter list
/usr/include/usersec.h:625: warning: its scope is only this definition or declaration, which is probably not what you want.
/usr/include/usersec.h:626: warning: `struct aud_rec' declared inside parameter list
In file included from ../openbsd-compat/port-aix.h:35,
                 from ../openbsd-compat/openbsd-compat.h:166,
                 from ../includes.h:173,
                 from bsd-arc4random.c:25:
/usr/include/sys/audit.h:271: parse error before `0200'
/usr/include/sys/audit.h:286: parse error before `}'
make[1]: *** [bsd-arc4random.o] Error 1
make[1]: Leaving directory `/home/dmc/src/openssh-3.7.1p1/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2



From mjo at dojo.mi.org  Thu Sep 18 01:34:34 2003
From: mjo at dojo.mi.org (Mike O'Connor)
Date: Wed, 17 Sep 2003 11:34:34 -0400 (EDT)
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
Message-ID: <030917113434.mjo@dojo.mi.org>

:
:On Wed, Sep 17, 2003 at 08:46:05AM -0400, Mike O'Connor wrote:
:> :It works if I define BROKEN_GETADDRINFO, SETEUID_BREAKS_SETUID,
:> :BROKEN_SETREUID, and BROKEN_SETREGID.
:> 
:> FWIW, the broken getaddrinfo() should only be needed for pre-6.5.20.
:
:Doesn't seem needed on 6.5.17m, it even broke if I defined it.

That's because getaddrinfo() didn't exist prior to 6.5.18 -- was
introduced as a logical prelude to the IPv6 support in 6.5.19.  :)

:Building with MIPSPro and SETEUID_BREAKS_SETUID, BROKEN_SETREUID, 
:BROKEN_SETREGID and removed inet_ntoa.h seems to work for me.
:
:Hope an "official" fix soon will emerge..
:
:  
:  -jf
:


-- 
 Mail: mjo at dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Don't improve the product, just find dumber customers!"    -Bob the Dinosaur



From jclonguet at free.fr  Thu Sep 18 01:38:59 2003
From: jclonguet at free.fr (jclonguet at free.fr)
Date: Wed, 17 Sep 2003 17:38:59 +0200
Subject: ConnectTimeout option is broken
Message-ID: <1063813139.3f6880134ba58@imp3-l.free.fr>


 Some code was added which break this functionnality. Patches are
attached and details are on http://bugzilla.mindrot.org/show_bug.cgi?id=656




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-3.7.1p1-timeout-1.00.patch.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/561aa41f/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-3.7.1-timeout-1.00.patch.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/561aa41f/attachment-0001.txt 

From crh at ubiqx.mn.org  Thu Sep 18 01:48:50 2003
From: crh at ubiqx.mn.org (Christopher R. Hertel)
Date: Wed, 17 Sep 2003 10:48:50 -0500
Subject: openbsd-compat/inet_ntoa.h missing from 3.7p1?
In-Reply-To: <3F6802BC.7F633AB5@zip.com.au>
References: <20030916215332.GN5170@Favog.ubiqx.mn.org>
	<3F6802BC.7F633AB5@zip.com.au>
Message-ID: <20030917154850.GA12632@Favog.ubiqx.mn.org>

On Wed, Sep 17, 2003 at 04:44:12PM +1000, Darren Tucker wrote:
> "Christopher R. Hertel" wrote:
> > I am using Irix, but I'm using SGI's compiler, not GCC, so I commented out
> > the line.  OpenSSH then compiled.
> 
> > debug1: Local version string SSH-1.5-OpenSSH_3.7p1
> > debug3: privsep user:group 6666:6666
> > debug1: permanently_set_uid: 6666/6666
> > : was able to restore old [e]gid
> 
> This is the problem here.  What are all of the SET*[UG]ID defines set to
> in config.h?

#define HAVE_SETEGID 1
#define HAVE_SETEUID 1
#define HAVE_SETREGID 1  
#define HAVE_SETREUID 1
#define HAVE_SETSID 1  

> You may be able to sort it by out by defining "BROKEN_SETREUID" and
> "BROKEN_SETREGID", and possibly SETEUID_BREAKS_SETUID.

I will give those a try if I still have the same problems with 3.7.1p1.  

Thanks!

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org



From dan at doxpara.com  Wed Sep 17 14:03:13 2003
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 16 Sep 2003 21:03:13 -0700
Subject: sftp reget/reput
In-Reply-To: <20030917091810.GA8916@folly>
References: <1178101319.20030917111236@oganer.net>
	<20030917091810.GA8916@folly>
Message-ID: <3F67DD01.5070904@doxpara.com>

It's a mighty inefficient codepath that literally reads data out of 
order and sends it such; disk seek times are deadly.  That being said, 
simply implement a cache that handles out of order transactions and only 
writes to disk complete windows of data.  This does mean memory usage 
can grow in case of a small missing block, but certainly we can control 
that by monitoring our number of outstanding requests and failing to 
issue more when the server obstinately refuses to give us one particular 
entry.

This is, of course, directly analogous to a TCP Window.

--Dan


Markus Friedl wrote:

>we could modify the protocol and implement
>rolling checksums like Niels Provos suggests:
>
>	MD5_CTX ctx1, ctx2;
>
>	MD5_Init(&ctx1);
>
>	while new page in data
>	  MD5_Update(&ctx1, newpage, pagesize)
>	  ctx2 = ctx1;
>	  MD5_Final(digest, &ctx2)
>	  if (compare with remote not equal)
>	     break;
>	end while
>
>	continue data transfer.
>
>On Wed, Sep 17, 2003 at 11:12:36AM +0800, Dmitry Lohansky wrote:
>  
>
>>Hello openssh@
>>
>>I thought about sftp's reget/reput commands.
>>
>>Several days ago, Damien Miller write to tech at openbsd.org (it was
>>reply for my letter):
>>
>>    
>>
>>>Herein lies a problem which is not easy to detect or solve. For
>>>performance reasons, the sftp client does pipelined reads/writes when
>>>transferring files. The protocol spec allows for a server to process
>>>these requests out of order. For example:
>>>      
>>>
>>>client                     server
>>>------                     ------
>>>open file                  your file handle is "blah"
>>>gimme bytes 0-8191
>>>gimme bytes 8192-16383
>>>gimme bytes 16384-24575
>>>gimme bytes 24576-32767    here are bytes 24576-32767
>>>close file                 here are bytes 16384-24575
>>>                           here are bytes 8192-16383
>>>                           here are bytes 0-8191
>>>                           close successful
>>>      
>>>
>>>If the client writes the bytes our in the order they are received (which
>>>it probably should, to avoid buffering large amounts of data) then an
>>>interruption will leave a full-length, but "holey" file on disk. There
>>>is no general way to determine how to do resume such a transfer.
>>>      
>>>
>>>The best the client can do to make transfers resumable is ftruncate()
>>>the file at the highest contiguous byte received. This will stop the
>>>potential corruption on resume.
>>>      
>>>
>>This is good method, but if client crash, we also may get a "hole".
>>What your think about next way?
>>
>>Storing extra-data at the end of file, for example:
>>
>><---orig-part-><-extra->
>>[*][ ][*][ ][*][*******]
>><---------file--------->
>>
>>where [*] - already loaded data, [ ] - not yet
>>
>>In extra part, we may store which block was already loaded and it
>>offset and size. After download, extra part will be removed.
>>
>>Comments?
>>-- 
>> Dmitry Lohansky
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>    
>>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>




From gwyllion at ace.ulyssis.org  Thu Sep 18 02:10:10 2003
From: gwyllion at ace.ulyssis.org (Dries Schellekens)
Date: Wed, 17 Sep 2003 18:10:10 +0200 (CEST)
Subject: OpenSSH Security Advisory: buffer.adv
Message-ID: <Pine.LNX.4.50.0309171809130.19495-100000@alf.ulyssis.org>

On Wed, 17 Sep 2003, Markus Friedl wrote:

> This is the 2nd revision of the Advisory.
>
> This document can be found at:  http://www.openssh.com/txt/buffer.adv
>
> 1. Versions affected:
>
>         All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
>         management errors.  It is uncertain whether these errors are
>         potentially exploitable, however, we prefer to see bugs
>         fixed proactively.
>
>         Other implementations sharing common origin may also have
>         these issues.
>
> 2. Solution:
>
> 	Upgrade to OpenSSH 3.7.1 or apply the following patch.
>
> ===================================================================
> Appendix A: patch for OpenSSH 3.6.1 and earlier

[snip]

> ===================================================================
> Appendix B: patch for OpenSSH 3.7

[snip]

Will the 4 extra fixes by Solar Designer be included as well?

>From the Owl Changelog
2003/09/17	Package: openssh
SECURITY FIX	Severity: medium, remote, active

Multiple memory management errors have been discovered in OpenSSH, and
this update corrects 6 such real or potential errors based on an
exhaustive review of the OpenSSH source code for uses of *realloc()
functions. At this time, it is uncertain whether and which of these bugs
are exploitable. If exploits are possible, due to privilege separation,
the worst direct impact should be limited to arbitrary code execution
under the sshd pseudo-user account restricted within the chroot jail
/var/empty, or under the logged in user account. Reference:
http://www.openssh.com/txt/buffer.adv


openssh-3.6.1p2-owl-realloc.diff looks like this

diff -urp openssh-3.6.1p2.orig/deattack.c openssh-3.6.1p2/deattack.c
--- openssh-3.6.1p2.orig/deattack.c	Tue Mar  5 01:53:05 2002
+++ openssh-3.6.1p2/deattack.c	Wed Sep 17 00:18:30 2003
@@ -100,12 +100,12 @@ detect_attack(u_char *buf, u_int32_t len

 	if (h == NULL) {
 		debug("Installing crc compensation attack detector.");
+		h = (u_int16_t *) xmalloc(l * HASH_ENTRYSIZE);
 		n = l;
-		h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
 	} else {
 		if (l > n) {
+			h = (u_int16_t *) xrealloc(h, l * HASH_ENTRYSIZE);
 			n = l;
-			h = (u_int16_t *) xrealloc(h, n * HASH_ENTRYSIZE);
 		}
 	}

diff -urp openssh-3.6.1p2.orig/misc.c openssh-3.6.1p2/misc.c
--- openssh-3.6.1p2.orig/misc.c	Mon Dec 23 02:44:36 2002
+++ openssh-3.6.1p2/misc.c	Wed Sep 17 00:50:27 2003
@@ -308,18 +308,21 @@ addargs(arglist *args, char *fmt, ...)
 {
 	va_list ap;
 	char buf[1024];
+	int nalloc;

 	va_start(ap, fmt);
 	vsnprintf(buf, sizeof(buf), fmt, ap);
 	va_end(ap);

+	nalloc = args->nalloc;
 	if (args->list == NULL) {
-		args->nalloc = 32;
+		nalloc = 32;
 		args->num = 0;
-	} else if (args->num+2 >= args->nalloc)
-		args->nalloc *= 2;
+	} else if (args->num+2 >= nalloc)
+		nalloc *= 2;

-	args->list = xrealloc(args->list, args->nalloc * sizeof(char *));
+	args->list = xrealloc(args->list, nalloc * sizeof(char *));
+	args->nalloc = nalloc;
 	args->list[args->num++] = xstrdup(buf);
 	args->list[args->num] = NULL;
 }
diff -urp openssh-3.6.1p2.orig/session.c openssh-3.6.1p2/session.c
--- openssh-3.6.1p2.orig/session.c	Fri Mar 21 01:18:09 2003
+++ openssh-3.6.1p2/session.c	Wed Sep 17 00:34:35 2003
@@ -844,8 +844,9 @@ static void
 child_set_env(char ***envp, u_int *envsizep, const char *name,
 	const char *value)
 {
-	u_int i, namelen;
 	char **env;
+	u_int envsize;
+	u_int i, namelen;

 	/*
 	 * Find the slot where the value should be stored.  If the variable
@@ -862,12 +863,13 @@ child_set_env(char ***envp, u_int *envsi
 		xfree(env[i]);
 	} else {
 		/* New variable.  Expand if necessary. */
-		if (i >= (*envsizep) - 1) {
-			if (*envsizep >= 1000)
-				fatal("child_set_env: too many env vars,"
-				    " skipping: %.100s", name);
-			(*envsizep) += 50;
-			env = (*envp) = xrealloc(env, (*envsizep) * sizeof(char *));
+		envsize = *envsizep;
+		if (i >= envsize - 1) {
+			if (envsize >= 1000)
+				fatal("child_set_env: too many env vars");
+			envsize += 50;
+			env = (*envp) = xrealloc(env, envsize * sizeof(char *));
+			*envsizep = envsize;
 		}
 		/* Need to set the NULL pointer at end of array beyond the new slot. */
 		env[i + 1] = NULL;
diff -urp openssh-3.6.1p2.orig/ssh-agent.c openssh-3.6.1p2/ssh-agent.c
--- openssh-3.6.1p2.orig/ssh-agent.c	Sat Mar 15 00:37:09 2003
+++ openssh-3.6.1p2/ssh-agent.c	Wed Sep 17 00:42:15 2003
@@ -767,7 +767,7 @@ process_message(SocketEntry *e)
 static void
 new_socket(sock_type type, int fd)
 {
-	u_int i, old_alloc;
+	u_int i, old_alloc, new_alloc;

 	if (fcntl(fd, F_SETFL, O_NONBLOCK) < 0)
 		error("fcntl O_NONBLOCK: %s", strerror(errno));
@@ -778,25 +778,26 @@ new_socket(sock_type type, int fd)
 	for (i = 0; i < sockets_alloc; i++)
 		if (sockets[i].type == AUTH_UNUSED) {
 			sockets[i].fd = fd;
-			sockets[i].type = type;
 			buffer_init(&sockets[i].input);
 			buffer_init(&sockets[i].output);
 			buffer_init(&sockets[i].request);
+			sockets[i].type = type;
 			return;
 		}
 	old_alloc = sockets_alloc;
-	sockets_alloc += 10;
+	new_alloc = sockets_alloc + 10;
 	if (sockets)
-		sockets = xrealloc(sockets, sockets_alloc * sizeof(sockets[0]));
+		sockets = xrealloc(sockets, new_alloc * sizeof(sockets[0]));
 	else
-		sockets = xmalloc(sockets_alloc * sizeof(sockets[0]));
-	for (i = old_alloc; i < sockets_alloc; i++)
+		sockets = xmalloc(new_alloc * sizeof(sockets[0]));
+	for (i = old_alloc; i < new_alloc; i++)
 		sockets[i].type = AUTH_UNUSED;
-	sockets[old_alloc].type = type;
+	sockets_alloc = new_alloc;
 	sockets[old_alloc].fd = fd;
 	buffer_init(&sockets[old_alloc].input);
 	buffer_init(&sockets[old_alloc].output);
 	buffer_init(&sockets[old_alloc].request);
+	sockets[old_alloc].type = type;
 }

 static int



Cheers,

Dries
--
Dries Schellekens
email: gwyllion at ulyssis.org



From WadellJS at BP.com  Thu Sep 18 02:04:58 2003
From: WadellJS at BP.com (Wadell, Jim S (SAIC))
Date: Wed, 17 Sep 2003 11:04:58 -0500
Subject: RE Openssh-3.7.1p1
Message-ID: <2B83AA9F6C5DC04090999EE05C0229B7515BBC@bp1ancex002.bp1.ad.bp.com>

I tried the same work-around on Irix 6.5.15, with both GCC and SGI C
compilers. I was able to get it to run and prompt for a password, then it
just shut down. Still no solution, but I will continue working. Anyone get
it to run on Irix yet?

Jim


Attempted compilation of openssh v3.7.1p1 on SGI IRIX 6.5.13. Compilation
failed due to missing inet_ntoa.h in openbsd-compat. Copied inet_ntoa.h from
older openssh distribution to that directory and compilation completed, but
the new sshd is giving me trouble, possibly due to something else. Regards,
Jack _______________________________________________ openssh-unix-dev
mailing list openssh-unix-dev at mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From scott.burch at camberwind.com  Thu Sep 18 02:12:24 2003
From: scott.burch at camberwind.com (Scott Burch)
Date: Wed, 17 Sep 2003 16:12:24 -0000
Subject: problem with configure in openssh-3.7p1
In-Reply-To: <E15A0A26BB57B845AF909DA6C14EBEE1105D53FB@dca-03.ms.cogentco.com>
References: <E15A0A26BB57B845AF909DA6C14EBEE1105D53FB@dca-03.ms.cogentco.com>
Message-ID: <1063815355.7827.10.camel@localhost>

Dave,

With 3.7.1p1 and 3.6.1p2, tcp_wrappers works without making the changes
you suggested below. I have the following line in my configure script:

--with-tcp-wrappers=$SRC/tcp_wrappers_7.6-ipv6.1_sol8_build

I then create the appropriate /etc/hosts.allow and /etc/hosts.deny and
everything works fine.

-Scott

On Wed, 2003-09-17 at 08:23, Purks, Dave wrote:
> Problem: setting --with-tcpwrappers does not configure code to be compiled
> with wrapper support
> 
> Solution: references to with_tcp_wrappers (lines 4975, 6396, 6397) need to
> be changed to with_tcpwrappers
> 
> 
> David Purks
> Sr Sys Admin
> Cogent Communications
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 
Scott Burch <scott.burch at camberwind.com>



From eric-list-openssh at catastrophe.net  Thu Sep 18 02:33:19 2003
From: eric-list-openssh at catastrophe.net (Eric)
Date: Wed, 17 Sep 2003 11:33:19 -0500
Subject: OpenBSD 3.3 x86 Build Problem
In-Reply-To: <20030917142957.GA566@crawfish.ais.com>;
	from jmknoble@pobox.com on Wed, Sep 17, 2003 at 10:29:58AM -0400
References: <20030916094310.Q86384@catastrophe.net>
	<20030917142957.GA566@crawfish.ais.com>
Message-ID: <20030917113319.D86384@catastrophe.net>

On Wed, 2003-09-17 at 10:29:58 -0400, Jim Knoble proclaimed...

> No troubles here (OBSD 3.3/i386).  How did you get the sources---by
> downloading the tarball, or via CVS?  If via CVS, perhaps you managed
> to provoke a race condition (since CVS doesn't have atomic filegroup
> commits) and only got a portion of the full 3.7 update; try updating
> from CVS again.
> 
> When was the last time you updated your /usr/src/ tree from CVS?
> Perhaps you need more than merely an updated ssh?

After I went to 3.7.1 and applied the necessary patches found in
[1], everything works fine.

Thanks.

- Eric

[1] ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openbsd3x_3.7.1.patch



From guenth at eece.ksu.edu  Thu Sep 18 02:50:11 2003
From: guenth at eece.ksu.edu (Bradley Guenther)
Date: Wed, 17 Sep 2003 11:50:11 -0500
Subject: openssh 3.7p1 and 3.7.1p1 Solaris problems
Message-ID: <3F6890C3.5060309@eece.ksu.edu>

I have some Solaris 7 boxes (Ultra 3 and Ultra Enterprise 250 hardware) 
that I have compiled both 3.7p1 and 3.7.1p1 on and am having some 
problems.  I am using the same "configure" options that I have in the 
past (without problems).  I have tried both new and existing (previously 
working) ssh_config and sshd_config files.  The new versions seem to 
have broken SSH 1 support (and maybe cause a bit of SSH 2 problems).  
All of my unix boxes can ssh into the server fine.  Cygwin users can ssh 
in fine.  TeraTerm Pro (both the old one that supports ssh1 only and the 
new one which <allegedly> supports ssh2) both just keep prompting me for 
my password over and over again.  Putty v.52 (older version) crashes 
when I try  to connect via ssh2, and gives me "Access denied" on 
attempts via ssh1.  The latest version (as of last night at least) of 
Putty works on ssh2 but still gives me the "Access denied" over and over 
again on ssh1 attempts.  Winscp basically works, but prompts for the 
password twice.

I looked at a previous post to your list archives about a bus error on 
Solaris and tried that patch to no avail.  I have experienced no crashes 
on the server side.  Any ideas on this would be welcomed.

Thank you for your time,

Brad

-- 
=========================================================
Bradley Guenther
Computer Information Specialist

Dept. of Electrical and Computer Engineering
Kansas State University

Office: 290 Rathbone Hall
Phone:  785-532-4690
Email:  brad at ksu.edu
=========================================================




From siegert at sfu.ca  Thu Sep 18 03:35:28 2003
From: siegert at sfu.ca (Martin Siegert)
Date: Wed, 17 Sep 2003 10:35:28 -0700
Subject: openssh-3.7.1p1 segfaults
In-Reply-To: <3F685058.5C328C07@zip.com.au>
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F685058.5C328C07@zip.com.au>
Message-ID: <20030917173528.GA19609@stikine.ucs.sfu.ca>

On Wed, Sep 17, 2003 at 10:15:20PM +1000, Darren Tucker wrote:
> Martin Siegert wrote:
> > the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> > both show the same behaviour.
> 
> Does the patch here resolve it?
> http://bugzilla.mindrot.org/show_bug.cgi?id=643

No, it does not.

Would have been surprising anyway because I am running the 32bit version.

Martin



From siegert at sfu.ca  Thu Sep 18 04:23:04 2003
From: siegert at sfu.ca (Martin Siegert)
Date: Wed, 17 Sep 2003 11:23:04 -0700
Subject: openssh-3.7.1p1 segfaults
In-Reply-To: <3F685058.5C328C07@zip.com.au>
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F685058.5C328C07@zip.com.au>
Message-ID: <20030917182303.GA19664@stikine.ucs.sfu.ca>

On Wed, Sep 17, 2003 at 10:15:20PM +1000, Darren Tucker wrote:
> Martin Siegert wrote:
> > the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> > both show the same behaviour.

Some more information: this bug seems to be limited to solaris 2.6.
I just tried openssh-3.7.1p1 on solaris 8 (32 bit) and it works fine.

Martin



From tom at arcot.com  Thu Sep 18 05:19:58 2003
From: tom at arcot.com (Tom Wu)
Date: Wed, 17 Sep 2003 12:19:58 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <20030917070001.GB24913@folly>
References: <8463549.1063796418@[192.168.1.14]> <20030917070001.GB24913@folly>
Message-ID: <3F68B3DE.2050704@arcot.com>

SRP is, if anything, the protocol with the *least* problematic patent 
license:

   http://www.ietf.org/ietf/IPR/WU-SRP

since royalty-free terms are offered.  If that isn't good enough for 
OpenSSH, then neither is DSA.

Tom

Markus Friedl wrote:
> SRP and similar protocols have patent problems.
> 
> are there any without?
> 
> On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
> 
>>Are there any plans to include support for SRP or a similar zero-knowledge 
>>password protocol into OpenSSH?
>>
>>-- 
>>Jeremy
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From openssh-unix-dev at thewrittenword.com  Thu Sep 18 04:50:22 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 13:50:22 -0500
Subject: problems with 3.7.1p1 on BSD/OS
In-Reply-To: <20030917151944.GA17099@doctor.nl2k.ab.ca>
References: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
	<20030917151944.GA17099@doctor.nl2k.ab.ca>
Message-ID: <20030917185022.GA90499@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 09:19:44AM -0600, The Doctor wrote:
> This is what is happening on BSD/OS.
> 
> 
> Script started on Wed Sep 17 06:20:55 2003
> doctor.nl2k.ab.ca/~$ssh -v -2 -i ~doctor/.ssh/id_rsa -l doctor uucp
> OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.6j [engine] 10 Apr 2003
> debug1: Reading configuration data /usr/contrib/etc/ssh_config
> debug1: Connecting to uucp [204.209.81.3] port 22.
> debug1: Connection established.
> debug1: identity file /usr/home/doctor/.ssh/id_rsa type 1
> debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p1
> debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.7.1p1
> debug1: SSH2_MSG_KEXINIT sent
> Connection closed by 204.209.81.3
> debug1: Calling cleanup 0x80608b0(0x0)
> doctor.nl2k.ab.ca/~$exit
> exit
> 
> Script done on Wed Sep 17 06:21:34 2003

Run sshd in debug mode (-D -d -d) and send the output.

-- 
albert chin (china at thewrittenword.com)



From tim at multitalents.net  Thu Sep 18 04:51:23 2003
From: tim at multitalents.net (Tim Rice)
Date: Wed, 17 Sep 2003 11:51:23 -0700 (PDT)
Subject: OpenSSH 3.7 testing (Re: 3.6p1 bug on SCO OpenServer)
In-Reply-To: <20030917003646.A5700@greenie.muc.de>
References: <Pine.UW2.4.53.0309052143040.18381@ou8.int.multitalents.net>
	<Pine.BSO.4.44.0309060023450.18966-100000@etoh.eviladmin.org>
	<20030917001356.E28768@greenie.muc.de>
	<20030917003646.A5700@greenie.muc.de>
Message-ID: <Pine.UW2.4.58.0309171148100.11341@ou8.int.multitalents.net>

On Wed, 17 Sep 2003, Gert Doering wrote:

> Hi,
> 
> On Wed, Sep 17, 2003 at 12:13:56AM +0200, Gert Doering wrote:
> > SCO 3.2v4.2 is broken in horrible ways :-(
> 
> > #define BROKEN_SETREUID 1
> > #define SETEUID_BREAKS_SETUID 1
> > 
> > * configure creates "#define BROKEN_SAVED_UIDS 1", which leads to 
> >   non-working UID swapping - removing that makes *that* work
> 
> These are still wrong.

I had to add 
AC_DEFINE(SETEUID_BREAKS_SETUID)
AC_DEFINE(BROKEN_SETREUID)
AC_DEFINE(BROKEN_SETREGID)
to the *-*-sco3.2v5*) section of configure.ac but I was unable to test 
3.2v4.2

I still need to come up with a 50pin SCSI drive to get my
Open Server 3 box working again. (short on funds right now)

> 
> gert
> 

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




From tom at arcot.com  Thu Sep 18 05:25:27 2003
From: tom at arcot.com (Tom Wu)
Date: Wed, 17 Sep 2003 12:25:27 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <3F676C5B.5000105@doxpara.com>
References: <8463549.1063796418@[192.168.1.14]> <3F676C5B.5000105@doxpara.com>
Message-ID: <3F68B527.4040702@arcot.com>

Dan Kaminsky wrote:
> Consider:  You end up having to abandon OS level password systems.  No 
> PAM, no MD5 passwords...SSH needs to take it all inhouse, because the 

Actually, it's just a different "format" for OS-level password systems, 
implemented via PAM to support the new EPS password records.  So yes, 
you can't use crypt() or MD5, but EPS is merely a substitute for those. 
The PAM modules make EPS look like just another hash/salt algorithm.

> 
> Search for Tom Holroyd's (Dr. Tom) work on this subject.
> 
> --Dan
> 
Tom
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From openssh-unix-dev at thewrittenword.com  Thu Sep 18 05:01:25 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 14:01:25 -0500
Subject: openssh-unix-dev@mindrot.org
In-Reply-To: <20030917173219.A21614@helena.bawue.de>
References: <20030917173219.A21614@helena.bawue.de>
Message-ID: <20030917190125.GA90887@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 05:32:19PM +0200, Florian Laws wrote:
> I'm getting compile errors on AIX 5.1,
> not defining WITH_AIXAUTHENTICATE in config.h seems to solve the problem.
> 
> I have configured with --syscondir=/etc/ssh and --with-ssl-dir=/usr/local/ssl
> and I am using gcc 2.95.3 
> The error messages is included below.

Works fine for me with IBM C compiler v6.0.

-- 
albert chin (china at thewrittenword.com)



From kjs at uchicago.edu  Thu Sep 18 05:07:48 2003
From: kjs at uchicago.edu (Kim Scarborough)
Date: Wed, 17 Sep 2003 14:07:48 -0500
Subject: 3.7p1 & PAM on Solaris
Message-ID: <3F68B104.9030407@uchicago.edu>

I have OpenSSH 3.7p1 running under a chroot, authenticating through PAM to an 
LDAP server. I'm also getting reports of problems with the new PAM code from 
Windows users. ssh.com's Windows client (v. 3.2.5) says  "Enter your 
authentication response" now, and after you enter the password and hit OK, it 
says it again, although this time with no entry box. You hit OK again and 
you're logged in. This isn't such a big deal, but I've also gotten a report 
that some stupid Macromedia client is saying "password denied" now that I've 
upgraded.

Sorry, I know this is kinda vague. Is there a way to revert the PAM auth 
mechanism back to password, not challenge-response? (That is the problem, 
right?) Why are these Windows clients getting confused?

-- 
----------------------------------------------------------------------------
Kim Scarborough                                  Web Systems Administrator
University of Chicago/NSIT                       (773) 834-7740
----------------------------------------------------------------------------
Now listening to: Velvet Underground - "The Nothing Song"
----------------------------------------------------------------------------




From siegert at sfu.ca  Thu Sep 18 05:23:14 2003
From: siegert at sfu.ca (Martin Siegert)
Date: Wed, 17 Sep 2003 12:23:14 -0700
Subject: openssh-3.7.1p1 segfaults
In-Reply-To: <3F685058.5C328C07@zip.com.au>
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F685058.5C328C07@zip.com.au>
Message-ID: <20030917192314.GA19783@stikine.ucs.sfu.ca>

On Wed, Sep 17, 2003 at 10:15:20PM +1000, Darren Tucker wrote:
> Martin Siegert wrote:
> > the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> > both show the same behaviour.

additional info:

openssh-3.6.1p2 + the patch from
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106378044112153&w=2

works under Solaris 2.6 (whereas openssh-3.7.1p1 segfaults).

Martin



From bennett at wyomissing.com  Thu Sep 18 05:27:55 2003
From: bennett at wyomissing.com (Ron Bennett)
Date: Wed, 17 Sep 2003 15:27:55 -0400
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
Message-ID: <5.2.1.1.2.20030917151822.029a8720@wyomissing.com>

I've corresponded with several different techs at a
major dedicated webhosting provider and they too
so far have not been able to determine why the
newest version of OpenSSH 3.7.1p1 is conflicting
with PAM on our server running RedHat linux 6.2.

I've also tried installing 3.7.1p1 on other RedHat 6.2
servers and the exact same PAM problems. But on
7.1 RedHat servers I've had absolutely no problems.

When I revert back to 3.5p1 with the exact same
config/install procedure everything works just fine.

In short, have others experienced similar problems
installing the newest OpenSSH on RedHat 6.2?

Welcome suggestions...

Ron Bennett




From mouring at etoh.eviladmin.org  Thu Sep 18 05:46:27 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 17 Sep 2003 14:46:27 -0500 (CDT)
Subject: SRP Support
In-Reply-To: <DBEJKFKIDIDOKKCGEDHMGEJECIAA.eddy@cdf-imaging.com>
Message-ID: <Pine.BSO.4.44.0309171446010.842-100000@etoh.eviladmin.org>


Until all IP issues are resolved and it is provided in a 100% free and
usable way it will *NEVER* be included.

- Ben

On Wed, 17 Sep 2003, Edward Flick wrote:

> Just wondering if there were any plans to integrate SRP support into
> OpenSSH.  And if there aren't would a patch be accepted that would enable
> such.  And if so could anyone give me a couple of pointers as to where the
> authentication code goes.
>
> Edward Flick
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mouring at etoh.eviladmin.org  Thu Sep 18 06:04:05 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 17 Sep 2003 15:04:05 -0500 (CDT)
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <71664806-E919-11D7-9027-00039344D894@golem.ph.utexas.edu>
Message-ID: <Pine.BSO.4.44.0309171501460.842-100000@etoh.eviladmin.org>


Would have been nice if someone from Apple or the MacOSX community tested
when we called for testing.. <COUGH>  <WEAK SMILE>

Not as if this was a fully out of the blue release. =)

- Ben

On Wed, 17 Sep 2003, Jacques Distler wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Wednesday, September 17, 2003, at 08:53  AM, Darren Tucker wrote:
>
> > Jacques Distler wrote:
> >>    % egrep 'SET.*ID' config.h
> >>    /* #undef SETEUID_BREAKS_SETUID */
> >>    /* #undef BROKEN_SETREUID */
> >>    /* #undef BROKEN_SETREGID */
> >>    #define HAVE_SETEGID 1
> >>    #define HAVE_SETEUID 1
> >>    /* #undef HAVE_SETLUID */
> >>    #define HAVE_SETREGID 1
> >>    /* #undef HAVE_SETRESGID */
> >>    /* #undef HAVE_SETRESUID */
> >>    #define HAVE_SETREUID 1
> >>    #define HAVE_SETSID 1
> >
> > With those defines, I'd expect the same behaviour as 3.6.1p2, and I'd
> > also
> > expect SETEUID_BREAKS_SETUID to resolve it.  I dunno.
>
>
> Well, thanks for trying. I've posted a note
> <http://golem.ph.utexas.edu/~distler/blog/archives/000221.html> on my
> weblog warning MacOSX users about this.
>
> Jacques
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (Darwin)
> Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc
>
> iD8DBQE/aGyfnyqPIXpYcjcRApg2AKCgBG5e3J6NwdFAXcY8BrhpfwAD0wCglrf3
> XhN4mLfUH4UuXYnd1IzNjv4=
> =tnZH
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From spike at indra.com  Thu Sep 18 06:04:42 2003
From: spike at indra.com (Spike Ilacqua)
Date: Wed, 17 Sep 2003 14:04:42 -0600
Subject: bad include in inet_ntoa.c (versions openssh-3.7p1 &
	openssh-3.7.1p1)
Message-ID: <200309172004.h8HK4g6n018483@net.indra.com>


"openbsd-compat/inet_ntoa.c" includes "inet_ntoa.h" which doesn't exist.
Deleting the "#include" line allows inet_ntoa.c to compile and the
resulting programs work fine.

->Spike



From bennett at wyomissing.com  Thu Sep 18 06:24:44 2003
From: bennett at wyomissing.com (Ron Bennett)
Date: Wed, 17 Sep 2003 16:24:44 -0400
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
Message-ID: <5.2.1.1.2.20030917162438.029addd0@wyomissing.com>

I've corresponded with several different techs at a
major dedicated webhosting provider and they too
so far have not been able to determine why the
newest version of OpenSSH 3.7.1p1 is conflicting
with PAM on our server running RedHat linux 6.2.

I've also tried installing 3.7.1p1 on other RedHat 6.2
servers and the exact same PAM problems. But on
7.1 RedHat servers I've had absolutely no problems.

When I revert back to 3.5p1 with the exact same
config/install procedure everything works just fine.

In short, have others experienced similar problems
installing the newest OpenSSH on RedHat 6.2?

Welcome suggestions...

Ron Bennett



From openssh-unix-dev at thewrittenword.com  Thu Sep 18 06:27:43 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Wed, 17 Sep 2003 15:27:43 -0500
Subject: RE Openssh-3.7.1p1
In-Reply-To: <2B83AA9F6C5DC04090999EE05C0229B7515BBC@bp1ancex002.bp1.ad.bp.com>
References: <2B83AA9F6C5DC04090999EE05C0229B7515BBC@bp1ancex002.bp1.ad.bp.com>
Message-ID: <20030917202743.GA92546@spuckler.il.thewrittenword.com>

On Wed, Sep 17, 2003 at 11:04:58AM -0500, Wadell, Jim S (SAIC) wrote:
> I tried the same work-around on Irix 6.5.15, with both GCC and SGI C
> compilers. I was able to get it to run and prompt for a password, then it
> just shut down. Still no solution, but I will continue working. Anyone get
> it to run on Irix yet?

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

-- 
albert chin (china at thewrittenword.com)



From eddy at cdf-imaging.com  Thu Sep 18 06:59:21 2003
From: eddy at cdf-imaging.com (Edward Flick)
Date: Wed, 17 Sep 2003 15:59:21 -0500
Subject: SRP secure remote password authentication
In-Reply-To: <3F68B3DE.2050704@arcot.com>
Message-ID: <DBEJKFKIDIDOKKCGEDHMCEKHCIAA.eddy@cdf-imaging.com>

Hello Tom,
Since I am just now realizing you monitor this list.  Exactly, what is
implied by the SRP-Z license?  As you can implicitly determine (by
successful negotation) if the server on the other end is the server you
intended to communicate with, exactly what is the differentiating factor
between SRP and SRP-Z.

Edward Flick

-----Original Message-----
From: openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org
[mailto:openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org]On
Behalf Of Tom Wu
Sent: Wednesday, September 17, 2003 2:20 PM
To: Markus Friedl
Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
Subject: Re: SRP secure remote password authentication


SRP is, if anything, the protocol with the *least* problematic patent
license:

   http://www.ietf.org/ietf/IPR/WU-SRP

since royalty-free terms are offered.  If that isn't good enough for
OpenSSH, then neither is DSA.

Tom

Markus Friedl wrote:
> SRP and similar protocols have patent problems.
>
> are there any without?
>
> On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
>
>>Are there any plans to include support for SRP or a similar zero-knowledge
>>password protocol into OpenSSH?
>>
>>--
>>Jeremy
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

--
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124

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



From WadellJS at BP.com  Thu Sep 18 06:52:54 2003
From: WadellJS at BP.com (Wadell, Jim S (SAIC))
Date: Wed, 17 Sep 2003 15:52:54 -0500
Subject: RE Openssh-3.7.1p1
Message-ID: <2B83AA9F6C5DC04090999EE05C0229B7515BC3@bp1ancex002.bp1.ad.bp.com>

Thanks, Albert!

-----Original Message-----
From: Albert Chin [mailto:openssh-unix-dev at thewrittenword.com]
Sent: Wednesday, September 17, 2003 12:28 PM
To: Wadell, Jim S (SAIC)
Cc: openssh-unix-dev at mindrot.org
Subject: Re: RE Openssh-3.7.1p1


On Wed, Sep 17, 2003 at 11:04:58AM -0500, Wadell, Jim S (SAIC) wrote:
> I tried the same work-around on Irix 6.5.15, with both GCC and SGI C
> compilers. I was able to get it to run and prompt for a password, then it
> just shut down. Still no solution, but I will continue working. Anyone get
> it to run on Irix yet?

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

-- 
albert chin (china at thewrittenword.com)



From tom at arcot.com  Thu Sep 18 07:28:48 2003
From: tom at arcot.com (Tom Wu)
Date: Wed, 17 Sep 2003 14:28:48 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <DBEJKFKIDIDOKKCGEDHMCEKHCIAA.eddy@cdf-imaging.com>
References: <DBEJKFKIDIDOKKCGEDHMCEKHCIAA.eddy@cdf-imaging.com>
Message-ID: <3F68D210.4090902@arcot.com>

Edward,

With "plain" SRP, the server has a verifier and the client has the 
actual password.  The server's long-term secret is derivable from the 
client's long-term secret but not vice-versa.  SRP-Z adds a server 
"password" and a client "verifier", which assures the client explicitly 
that the server knows its password.  With "plain" SRP, all you know is 
that the server has the right verifier.  For example, under "plain" SRP, 
if you wrote your password on your monitor, an attacker could use that 
information to impersonate a server that you were SSHing to, but SRP-Z 
would prevent that.  The downside is that clients need to keep 
information about specific servers' "verifier" info around.

SSH/OpenSSH doesn't really need SRP-Z since it already uses host keys to 
authenticate the server.  Tom Holroyd's patches to OpenSSH implement 
"plain" royalty-free SRP as a result.

Tom

Edward Flick wrote:
> Hello Tom,
> Since I am just now realizing you monitor this list.  Exactly, what is
> implied by the SRP-Z license?  As you can implicitly determine (by
> successful negotation) if the server on the other end is the server you
> intended to communicate with, exactly what is the differentiating factor
> between SRP and SRP-Z.
> 
> Edward Flick
> 
> -----Original Message-----
> From: openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org]On
> Behalf Of Tom Wu
> Sent: Wednesday, September 17, 2003 2:20 PM
> To: Markus Friedl
> Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
> Subject: Re: SRP secure remote password authentication
> 
> 
> SRP is, if anything, the protocol with the *least* problematic patent
> license:
> 
>    http://www.ietf.org/ietf/IPR/WU-SRP
> 
> since royalty-free terms are offered.  If that isn't good enough for
> OpenSSH, then neither is DSA.
> 
> Tom
> 
> Markus Friedl wrote:
> 
>>SRP and similar protocols have patent problems.
>>
>>are there any without?
>>
>>On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
>>
>>
>>>Are there any plans to include support for SRP or a similar zero-knowledge
>>>password protocol into OpenSSH?
>>>
>>>--
>>>Jeremy
>>>
>>>_______________________________________________
>>>openssh-unix-dev mailing list
>>>openssh-unix-dev at mindrot.org
>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> --
> Tom Wu
> Chief Security Architect
> Arcot Systems
> (408) 969-6124
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From eddy at cdf-imaging.com  Thu Sep 18 07:46:17 2003
From: eddy at cdf-imaging.com (Edward Flick)
Date: Wed, 17 Sep 2003 16:46:17 -0500
Subject: SRP secure remote password authentication
In-Reply-To: <3F68D210.4090902@arcot.com>
Message-ID: <DBEJKFKIDIDOKKCGEDHMGEKICIAA.eddy@cdf-imaging.com>

So, SRP-Z is essentially the process of initiating SRP on the client and
then the server side?  Couldn't you literally take the preexisting SRP
implementation, have the client initiate SRP communications with the server,
and then have the server initiate SRP communications with the client, and
achieve the same result?  Just wondering.

Edward

-----Original Message-----
From: Tom Wu [mailto:tom at arcot.com]
Sent: Wednesday, September 17, 2003 4:29 PM
To: Edward Flick
Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
Subject: Re: SRP secure remote password authentication


Edward,

With "plain" SRP, the server has a verifier and the client has the
actual password.  The server's long-term secret is derivable from the
client's long-term secret but not vice-versa.  SRP-Z adds a server
"password" and a client "verifier", which assures the client explicitly
that the server knows its password.  With "plain" SRP, all you know is
that the server has the right verifier.  For example, under "plain" SRP,
if you wrote your password on your monitor, an attacker could use that
information to impersonate a server that you were SSHing to, but SRP-Z
would prevent that.  The downside is that clients need to keep
information about specific servers' "verifier" info around.

SSH/OpenSSH doesn't really need SRP-Z since it already uses host keys to
authenticate the server.  Tom Holroyd's patches to OpenSSH implement
"plain" royalty-free SRP as a result.

Tom

Edward Flick wrote:
> Hello Tom,
> Since I am just now realizing you monitor this list.  Exactly, what is
> implied by the SRP-Z license?  As you can implicitly determine (by
> successful negotation) if the server on the other end is the server you
> intended to communicate with, exactly what is the differentiating factor
> between SRP and SRP-Z.
>
> Edward Flick
>
> -----Original Message-----
> From: openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org]On
> Behalf Of Tom Wu
> Sent: Wednesday, September 17, 2003 2:20 PM
> To: Markus Friedl
> Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
> Subject: Re: SRP secure remote password authentication
>
>
> SRP is, if anything, the protocol with the *least* problematic patent
> license:
>
>    http://www.ietf.org/ietf/IPR/WU-SRP
>
> since royalty-free terms are offered.  If that isn't good enough for
> OpenSSH, then neither is DSA.
>
> Tom
>
> Markus Friedl wrote:
>
>>SRP and similar protocols have patent problems.
>>
>>are there any without?
>>
>>On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
>>
>>
>>>Are there any plans to include support for SRP or a similar
zero-knowledge
>>>password protocol into OpenSSH?
>>>
>>>--
>>>Jeremy
>>>
>>>_______________________________________________
>>>openssh-unix-dev mailing list
>>>openssh-unix-dev at mindrot.org
>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>
> --
> Tom Wu
> Chief Security Architect
> Arcot Systems
> (408) 969-6124
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

--
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From tom at arcot.com  Thu Sep 18 08:14:26 2003
From: tom at arcot.com (Tom Wu)
Date: Wed, 17 Sep 2003 15:14:26 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <DBEJKFKIDIDOKKCGEDHMGEKICIAA.eddy@cdf-imaging.com>
References: <DBEJKFKIDIDOKKCGEDHMGEKICIAA.eddy@cdf-imaging.com>
Message-ID: <3F68DCC2.1090709@arcot.com>

Edward,

SRP-Z has the same effect as what you describe, but integrates both 
pairs of secrets into a single authentication step, which is almost as 
efficient as a single SRP authentication, whereas what you describe 
would require double the amount of processing power, network trips, and 
message size as a single "one-way" authentication.

Tom

Edward Flick wrote:
> So, SRP-Z is essentially the process of initiating SRP on the client and
> then the server side?  Couldn't you literally take the preexisting SRP
> implementation, have the client initiate SRP communications with the server,
> and then have the server initiate SRP communications with the client, and
> achieve the same result?  Just wondering.
> 
> Edward
> 
> -----Original Message-----
> From: Tom Wu [mailto:tom at arcot.com]
> Sent: Wednesday, September 17, 2003 4:29 PM
> To: Edward Flick
> Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
> Subject: Re: SRP secure remote password authentication
> 
> 
> Edward,
> 
> With "plain" SRP, the server has a verifier and the client has the
> actual password.  The server's long-term secret is derivable from the
> client's long-term secret but not vice-versa.  SRP-Z adds a server
> "password" and a client "verifier", which assures the client explicitly
> that the server knows its password.  With "plain" SRP, all you know is
> that the server has the right verifier.  For example, under "plain" SRP,
> if you wrote your password on your monitor, an attacker could use that
> information to impersonate a server that you were SSHing to, but SRP-Z
> would prevent that.  The downside is that clients need to keep
> information about specific servers' "verifier" info around.
> 
> SSH/OpenSSH doesn't really need SRP-Z since it already uses host keys to
> authenticate the server.  Tom Holroyd's patches to OpenSSH implement
> "plain" royalty-free SRP as a result.
> 
> Tom
> 
> Edward Flick wrote:
> 
>>Hello Tom,
>>Since I am just now realizing you monitor this list.  Exactly, what is
>>implied by the SRP-Z license?  As you can implicitly determine (by
>>successful negotation) if the server on the other end is the server you
>>intended to communicate with, exactly what is the differentiating factor
>>between SRP and SRP-Z.
>>
>>Edward Flick
>>
>>-----Original Message-----
>>From: openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org
>>[mailto:openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org]On
>>Behalf Of Tom Wu
>>Sent: Wednesday, September 17, 2003 2:20 PM
>>To: Markus Friedl
>>Cc: openssh-unix-dev at mindrot.org; Jeremy Nysen
>>Subject: Re: SRP secure remote password authentication
>>
>>
>>SRP is, if anything, the protocol with the *least* problematic patent
>>license:
>>
>>   http://www.ietf.org/ietf/IPR/WU-SRP
>>
>>since royalty-free terms are offered.  If that isn't good enough for
>>OpenSSH, then neither is DSA.
>>
>>Tom
>>
>>Markus Friedl wrote:
>>
>>
>>>SRP and similar protocols have patent problems.
>>>
>>>are there any without?
>>>
>>>On Wed, Sep 17, 2003 at 11:00:18AM +1000, Jeremy Nysen wrote:
>>>
>>>
>>>
>>>>Are there any plans to include support for SRP or a similar
> 
> zero-knowledge
> 
>>>>password protocol into OpenSSH?
>>>>
>>>>--
>>>>Jeremy
>>>>
>>>>_______________________________________________
>>>>openssh-unix-dev mailing list
>>>>openssh-unix-dev at mindrot.org
>>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>>>
>>>_______________________________________________
>>>openssh-unix-dev mailing list
>>>openssh-unix-dev at mindrot.org
>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>>--
>>Tom Wu
>>Chief Security Architect
>>Arcot Systems
>>(408) 969-6124
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> --
> Tom Wu
> Chief Security Architect
> Arcot Systems
> (408) 969-6124

-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From djm at mindrot.org  Thu Sep 18 08:12:12 2003
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 Sep 2003 22:12:12 -0000
Subject: sftp reget/reput
In-Reply-To: <20030917091810.GA8916@folly>
References: <1178101319.20030917111236@oganer.net>
	<20030917091810.GA8916@folly>
Message-ID: <1063836570.6486.855.camel@sakura.mindrot.org>

On Wed, 2003-09-17 at 19:18, Markus Friedl wrote:
> we could modify the protocol and implement
> rolling checksums like Niels Provos suggests:
> 
> 	MD5_CTX ctx1, ctx2;
> 
> 	MD5_Init(&ctx1);
> 
> 	while new page in data
> 	  MD5_Update(&ctx1, newpage, pagesize)
> 	  ctx2 = ctx1;
> 	  MD5_Final(digest, &ctx2)
> 	  if (compare with remote not equal)
> 	     break;
> 	end while
> 
> 	continue data transfer.

That is a nice idea. Poor man's rsync :)

-d

> On Wed, Sep 17, 2003 at 11:12:36AM +0800, Dmitry Lohansky wrote:
> > Hello openssh@
> > 
> > I thought about sftp's reget/reput commands.
> > 
> > Several days ago, Damien Miller write to tech at openbsd.org (it was
> > reply for my letter):
> > 
> > > Herein lies a problem which is not easy to detect or solve. For
> > > performance reasons, the sftp client does pipelined reads/writes when
> > > transferring files. The protocol spec allows for a server to process
> > > these requests out of order. For example:
> > 
> > > client                     server
> > > ------                     ------
> > > open file                  your file handle is "blah"
> > > gimme bytes 0-8191
> > > gimme bytes 8192-16383
> > > gimme bytes 16384-24575
> > > gimme bytes 24576-32767    here are bytes 24576-32767
> > > close file                 here are bytes 16384-24575
> > >                            here are bytes 8192-16383
> > >                            here are bytes 0-8191
> > >                            close successful
> > 
> > > If the client writes the bytes our in the order they are received (which
> > > it probably should, to avoid buffering large amounts of data) then an
> > > interruption will leave a full-length, but "holey" file on disk. There
> > > is no general way to determine how to do resume such a transfer.
> > 
> > > The best the client can do to make transfers resumable is ftruncate()
> > > the file at the highest contiguous byte received. This will stop the
> > > potential corruption on resume.
> > 
> > This is good method, but if client crash, we also may get a "hole".
> > What your think about next way?
> > 
> > Storing extra-data at the end of file, for example:
> > 
> > <---orig-part-><-extra->
> > [*][ ][*][ ][*][*******]
> > <---------file--------->
> > 
> > where [*] - already loaded data, [ ] - not yet
> > 
> > In extra part, we may store which block was already loaded and it
> > offset and size. After download, extra part will be removed.
> > 
> > Comments?
> > -- 
> >  Dmitry Lohansky



From djm at mindrot.org  Thu Sep 18 08:27:57 2003
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 Sep 2003 22:27:57 -0000
Subject: SRP secure remote password authentication
In-Reply-To: <3F68B3DE.2050704@arcot.com>
References: <8463549.1063796418@[192.168.1.14]>
	<20030917070001.GB24913@folly>  <3F68B3DE.2050704@arcot.com>
Message-ID: <1063837516.5329.5.camel@sakura.mindrot.org>

On Thu, 2003-09-18 at 05:19, Tom Wu wrote:
> SRP is, if anything, the protocol with the *least* problematic patent 
> license:
> 
>    http://www.ietf.org/ietf/IPR/WU-SRP

And what about the claims that other companies make on SRP? E.g.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09292.html

You know about those and yet you fail to mention them.

-d




From jnysen-openssh at triaptic.com.au  Thu Sep 18 08:58:34 2003
From: jnysen-openssh at triaptic.com.au (Jeremy Nysen)
Date: Thu, 18 Sep 2003 08:58:34 +1000
Subject: SRP secure remote password authentication
In-Reply-To: <3F68B527.4040702@arcot.com>
References: <8463549.1063796418@[192.168.1.14]> <3F676C5B.5000105@doxpara.com>
	<3F68B527.4040702@arcot.com>
Message-ID: <1931307.1063875514@[192.168.1.14]>

--On Wednesday, 17 September 2003 12:25 PM -0700 Tom Wu <tom at arcot.com> wrote:

> Dan Kaminsky wrote:
>> Consider:  You end up having to abandon OS level password systems.  No
>> PAM, no MD5 passwords...SSH needs to take it all inhouse, because the
>
> Actually, it's just a different "format" for OS-level password systems, implemented via
> PAM to support the new EPS password records.  So yes, you can't use crypt() or MD5, but
> EPS is merely a substitute for those. The PAM modules make EPS look like just another
> hash/salt algorithm.

I've been using Tom Holroyd's OpenSSH SRP patches for quite a while and they do exactly 
that. Under Redhat, the PAM module makes the EPS verifiers transparent to the 
applications, and lets EPS work with anything that uses PAM, (eg. Samba, login, imap, 
pop, ldap, etc). OpenSSH can still authenticate with EPS without the SRP patches through 
the PAM subsystem, but obviously this doesn't use the SRP protocol.

Also, looking at the SRP terms of use license, it seems to me that although there is a 
patent, there is not a patent problem. I would be all for the inclusion of something like 
Tom Holroyd's patch into the official OpenSSH tree - even if it was only included as an 
explicit compile time switch.

-- 
Jeremy



From dtucker at zip.com.au  Thu Sep 18 09:04:18 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 09:04:18 +1000
Subject: openssh-3.7.1p1 segfaults
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F685058.5C328C07@zip.com.au>
	<20030917173528.GA19609@stikine.ucs.sfu.ca>
Message-ID: <3F68E872.1C726EF@zip.com.au>

Martin Siegert wrote:
> On Wed, Sep 17, 2003 at 10:15:20PM +1000, Darren Tucker wrote:
> > Martin Siegert wrote:
> > > the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> > > both show the same behaviour.
> >
> > Does the patch here resolve it?
> > http://bugzilla.mindrot.org/show_bug.cgi?id=643
> 
> No, it does not.
> 
> Would have been surprising anyway because I am running the 32bit version.

There's a second patch there now (id #410) that affects 32-bit platforms
as well, please try it if you haven't already.

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



From abartlet at samba.org  Thu Sep 18 09:04:06 2003
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 17 Sep 2003 23:04:06 -0000
Subject: sftp reget/reput
In-Reply-To: <Pine.BSO.4.44.0309170946390.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309170946390.842-100000@etoh.eviladmin.org>
Message-ID: <1063840005.21414.723.camel@piglett.bartlett.house>

On Thu, 2003-09-18 at 00:48, Ben Lindstrom wrote:
> I would love to see a modification to the SSH protocol to support the
> ability for the client to ask the sever for a checksum without getting the
> physical data.
> 
> It would be useful in reget, and would be useful for people building more
> advanced features to detect file changes and download only the blocks that
> need updating.
> 
> I've thought of it off and on, but never sat down and implemented and
> wrote up a document on it.

Why not just run rsync? ;-)

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030917/5c791b52/attachment.bin 

From tom at arcot.com  Thu Sep 18 09:38:17 2003
From: tom at arcot.com (Tom Wu)
Date: Wed, 17 Sep 2003 16:38:17 -0700
Subject: SRP Support
In-Reply-To: <Pine.BSO.4.44.0309171446010.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309171446010.842-100000@etoh.eviladmin.org>
Message-ID: <3F68F069.7000802@arcot.com>

Ben,

Can you be more specific about these "IP issues" you are referring to? 
Is the IETF royalty-free statement insufficiently clear?  AFAIK, 
Stanford *has* done precisely what you indicate by providing SRP in a 
100% free and usable way, judging by adoption in other OSS software 
projects.

Tom

Ben Lindstrom wrote:
> Until all IP issues are resolved and it is provided in a 100% free and
> usable way it will *NEVER* be included.
> 
> - Ben
> 
> On Wed, 17 Sep 2003, Edward Flick wrote:
> 
> 
>>Just wondering if there were any plans to integrate SRP support into
>>OpenSSH.  And if there aren't would a patch be accepted that would enable
>>such.  And if so could anyone give me a couple of pointers as to where the
>>authentication code goes.
>>
>>Edward Flick
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From bennett at wyomissing.com  Thu Sep 18 09:36:53 2003
From: bennett at wyomissing.com (Ron Bennett)
Date: Wed, 17 Sep 2003 19:36:53 -0400
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
Message-ID: <5.2.1.1.2.20030917193436.029af600@wyomissing.com>

I've corresponded with several different techs at a
major dedicated webhosting provider and they too
so far have not been able to determine why the
newest version of OpenSSH 3.7.1p1 is conflicting
with PAM on our server running RedHat linux 6.2.

I've also tried installing 3.7.1p1 on other RedHat 6.2
servers and the exact same PAM problems. But on
7.1 RedHat servers I've had absolutely no problems.

When I revert back to 3.5p1 with the exact same
config/install procedure everything works just fine.

In short, have others experienced similar problems
installing the newest OpenSSH on RedHat 6.2?

Welcome suggestions...

p.s. I apologize if this posted twice - it didn't appear
in archives so I assume it didn't post the first time.

Ron Bennett



From gwyllion at ace.ulyssis.org  Thu Sep 18 09:41:06 2003
From: gwyllion at ace.ulyssis.org (Dries Schellekens)
Date: Thu, 18 Sep 2003 01:41:06 +0200 (CEST)
Subject: OpenSSH Security Advisory: buffer.adv
In-Reply-To: <Pine.LNX.4.50.0309171741110.14873-100000@alf.ulyssis.org>
References: <20030916231330.GA26489@folly>
	<Pine.LNX.4.50.0309171741110.14873-100000@alf.ulyssis.org>
Message-ID: <Pine.LNX.4.50.0309180139130.31145-100000@alf.ulyssis.org>

On Wed, 17 Sep 2003, Dries Schellekens wrote:

> Will the 4 extra fixes by Solar Designer be included as well?
>
> >From the Owl Changelog
> 2003/09/17	Package: openssh
> SECURITY FIX	Severity: medium, remote, active
>
> Multiple memory management errors have been discovered in OpenSSH, and
> this update corrects 6 such real or potential errors based on an
> exhaustive review of the OpenSSH source code for uses of *realloc()
> functions. At this time, it is uncertain whether and which of these bugs
> are exploitable. If exploits are possible, due to privilege separation,
> the worst direct impact should be limited to arbitrary code execution
> under the sshd pseudo-user account restricted within the chroot jail
> /var/empty, or under the logged in user account. Reference:
> http://www.openssh.com/txt/buffer.adv

So is there no urgent need to include these fixes?


Cheers,

Dries
--
Dries Schellekens
email: gwyllion at ulyssis.org



From doctor at doctor.nl2k.ab.ca  Thu Sep 18 09:43:41 2003
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 17 Sep 2003 17:43:41 -0600
Subject: problems with 3.7.1p1 on BSD/OS
In-Reply-To: <20030917185022.GA90499@spuckler.il.thewrittenword.com>
References: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
	<20030917151944.GA17099@doctor.nl2k.ab.ca>
	<20030917185022.GA90499@spuckler.il.thewrittenword.com>
Message-ID: <20030917234341.GA23254@doctor.nl2k.ab.ca>

On Wed, Sep 17, 2003 at 01:50:22PM -0500, Albert Chin wrote:
> On Wed, Sep 17, 2003 at 09:19:44AM -0600, The Doctor wrote:
> > This is what is happening on BSD/OS.
> > 
> > 
> > Script started on Wed Sep 17 06:20:55 2003
> > doctor.nl2k.ab.ca/~$ssh -v -2 -i ~doctor/.ssh/id_rsa -l doctor uucp
> > OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.6j [engine] 10 Apr 2003
> > debug1: Reading configuration data /usr/contrib/etc/ssh_config
> > debug1: Connecting to uucp [204.209.81.3] port 22.
> > debug1: Connection established.
> > debug1: identity file /usr/home/doctor/.ssh/id_rsa type 1
> > debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p1
> > debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_3.7.1p1
> > debug1: SSH2_MSG_KEXINIT sent
> > Connection closed by 204.209.81.3
> > debug1: Calling cleanup 0x80608b0(0x0)
> > doctor.nl2k.ab.ca/~$exit
> > exit
> > 
> > Script done on Wed Sep 17 06:21:34 2003
> 
> Run sshd in debug mode (-D -d -d) and send the output.
>

Output

gallifrey.nk.ca//usr/source/openssh-3.7.1p1$ sshd -d -d -d
debug2: read_server_config: filename /etc/sshd_config
/etc/sshd_config line 36: Deprecated option RhostsAuthentication
/etc/sshd_config line 57: Unsupported option KerberosAuthentication
/etc/sshd_config line 58: Unsupported option KerberosOrLocalPasswd
/etc/sshd_config line 59: Unsupported option AFSTokenPassing
/etc/sshd_config line 60: Unsupported option KerberosTicketCleanup
debug1: sshd version OpenSSH_3.7.1p1
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file /etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: setgroups() failed: Invalid argument
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. 
> -- 
> albert chin (china at thewrittenword.com)

-- 
Member - Liberal International	On 11 Sept 2001 the WORLD was violated.
This is doctor at nl2k.ab.ca	Ici doctor at nl2k.ab.ca
Society MUST be saved! Extremists must dissolve.  
Ontario on 2 Octo 2003, VOTE LIBERAL!!



From dtucker at zip.com.au  Thu Sep 18 10:06:51 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 10:06:51 +1000
Subject: sshd 3.7p1 dies on MacOSX
References: <98F937AC-E90E-11D7-9027-00039344D894@golem.ph.utexas.edu>
Message-ID: <3F68F71B.4800AC88@zip.com.au>

Jacques Distler wrote:
> Tried that; had no effect (now verified with 3.7.1p1). Daemon still
> dies when a client connects.

It looks like OS X needs:
#define SETEUID_BREAKS_SETUID 1
#define BROKEN_SETREUID 1
#define BROKEN_SETREGID 1

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

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



From josh-lists at untruth.org  Thu Sep 18 10:57:05 2003
From: josh-lists at untruth.org (Joshua Hill)
Date: Wed, 17 Sep 2003 17:57:05 -0700
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
In-Reply-To: <5.2.1.1.2.20030917151822.029a8720@wyomissing.com>;
	from bennett@wyomissing.com on Wed, Sep 17, 2003 at 03:27:55PM
	-0400
References: <5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
Message-ID: <20030917175705.A20529@delusion.private.untruth.org>

On Wed, Sep 17, 2003 at 03:27:55PM -0400, Ron Bennett wrote:
> the
> newest version of OpenSSH 3.7.1p1 is conflicting
> with PAM on our server running RedHat linux 6.2.

What behavior are you seeing?  I'm running a RH 6.2 install, and 3.7.1p1
generally seemed to work, other than PermitEmptyPasswords, which seemed
to do nothing when pam was enabled.

There seems to be significant PAM related trauma resulting from the 3.7+
PAM code re-write in Solaris and (at least older) Linuxes.

Patched versions of 3.6.1p1 seem to work just fine. :-)

				Josh



From tom at arcot.com  Thu Sep 18 11:58:41 2003
From: tom at arcot.com (Tom Wu)
Date: Wed, 17 Sep 2003 18:58:41 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <1063837516.5329.5.camel@sakura.mindrot.org>
References: <8463549.1063796418@[192.168.1.14]>	
	<20030917070001.GB24913@folly> <3F68B3DE.2050704@arcot.com>
	<1063837516.5329.5.camel@sakura.mindrot.org>
Message-ID: <3F691151.7090406@arcot.com>

Damien Miller wrote:
> On Thu, 2003-09-18 at 05:19, Tom Wu wrote:
> 
>>SRP is, if anything, the protocol with the *least* problematic patent 
>>license:
>>
>>   http://www.ietf.org/ietf/IPR/WU-SRP
> 
> 
> And what about the claims that other companies make on SRP? E.g.
> 
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09292.html
> 
> You know about those and yet you fail to mention them.

If you look carefully at such "claims", you'll see that they are filled 
with "may"s and "might"s, if in fact there is any claim being made at 
all.  Unless there is some more substantiation that would allow one to 
distinguish them from frivolous claims designed to cause marketplace 
confusion/fear, I don't see why anyone, especially OSS projects 
ostensibly opposed to precisely this kind of patent abuse, should grant 
them any kind of legitimacy.

> 
> -d
> 

Tom
-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From tim at multitalents.net  Thu Sep 18 11:31:08 2003
From: tim at multitalents.net (Tim Rice)
Date: Wed, 17 Sep 2003 18:31:08 -0700 (PDT)
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <3F68616D.537AD9AF@zip.com.au>
References: <98F937AC-E90E-11D7-9027-00039344D894@golem.ph.utexas.edu>
	<3F68616D.537AD9AF@zip.com.au>
Message-ID: <Pine.UW2.4.58.0309171829460.16453@ou8.int.multitalents.net>


The attached patch will do the trick.

On Wed, 17 Sep 2003, Darren Tucker wrote:

> Jacques Distler wrote:
> > On Wednesday, September 17, 2003, at 01:38  AM, Darren Tucker wrote:
> > 
> > > Jacques Distler wrote:
> > >>    debug1: permanently_set_uid: 17/17
> > >>    setuid 17: Operation not permitted
> > >>    debug1: Calling cleanup 0x24c8c(0x0)
> > >
> > > Please try adding "#define SETEUID_BREAKS_SETUID 1" to config.h and
> > > recompiling.
> [didn't help]
> 
> What are the SET*ID defines in config.h?
> Try "egrep 'SET.*ID' config.h" or whatever that translates to on MacOS X.
> 
> 

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net
-------------- next part --------------
--- openssh/configure.ac.old	2003-09-15 22:40:49.000000000 -0700
+++ openssh/configure.ac	2003-09-17 11:36:14.528240062 -0700
@@ -131,6 +131,9 @@
 }], [AC_MSG_RESULT(working)],
 	[AC_MSG_RESULT(buggy)
 	AC_DEFINE(BROKEN_GETADDRINFO)],
+	AC_DEFINE(SETEUID_BREAKS_SETUID)
+	AC_DEFINE(BROKEN_SETREUID)
+	AC_DEFINE(BROKEN_SETREGID)
 	[AC_MSG_RESULT(assume it is working)])
 	;;
 *-*-hpux10.26)

From siegert at sfu.ca  Thu Sep 18 11:32:47 2003
From: siegert at sfu.ca (Martin Siegert)
Date: Wed, 17 Sep 2003 18:32:47 -0700
Subject: openssh-3.7.1p1 segfaults
In-Reply-To: <3F68E872.1C726EF@zip.com.au>
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F685058.5C328C07@zip.com.au>
	<20030917173528.GA19609@stikine.ucs.sfu.ca>
	<3F68E872.1C726EF@zip.com.au>
Message-ID: <20030918013247.GC20142@stikine.ucs.sfu.ca>

On Thu, Sep 18, 2003 at 09:04:18AM +1000, Darren Tucker wrote:
> Martin Siegert wrote:
> > On Wed, Sep 17, 2003 at 10:15:20PM +1000, Darren Tucker wrote:
> > > Martin Siegert wrote:
> > > > the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> > > > both show the same behaviour.
> > >
> > > Does the patch here resolve it?
> > > http://bugzilla.mindrot.org/show_bug.cgi?id=643
> > 
> > No, it does not.
> > 
> > Would have been surprising anyway because I am running the 32bit version.
> 
> There's a second patch there now (id #410) that affects 32-bit platforms
> as well, please try it if you haven't already.

I've tried it on Solaris 2.6 and 8 and 9. On Solaris 8 and 9 openssh-3.7.1p1
plus this patch work fine, on Solaris 2.6 sshd still segfaults.

I doubt somewhat that this segfault has to do with the reading
of /etc/default/login - in the truss output there is no open call
of /etc/default/login in the vicinity of the segfault.
Hence, I believe it is a different problem.

Martin



From bennett at wyomissing.com  Thu Sep 18 11:55:33 2003
From: bennett at wyomissing.com (Ron Bennett)
Date: Wed, 17 Sep 2003 21:55:33 -0400
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
In-Reply-To: <20030917175705.A20529@delusion.private.untruth.org>
References: <5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
	<5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
Message-ID: <5.2.1.1.2.20030917214350.031b5458@wyomissing.com>

Ok...I've found the problem...actually others have
hinted to it in older posts, but I didn't even think of
trying a different ssh client until I started looking at
the configs as Vincent had suggested...the sshd
files turned out to be exactly identical so that wasn't
it, and tech support stated emphatically that ssh
was working for them; it wasn't consistently before
which had really confused the issue.

In a nutshell, there is a compatibility problem with
the sshd 3.7 series and SecureCRT 3.4.6. My next
stop is the SecureCRT site and Google for details
about changes I need to make SecureCRT work...for
now I'm simply sshing in from another linux machine.

Anyone know what changed to make SecureCRT
not work anymore with some sshd installs? Bizarre!

Thank you in advance for your continued assistance.

Ron


At 05:57 PM 9/17/2003 -0700, Joshua Hill wrote:
>On Wed, Sep 17, 2003 at 03:27:55PM -0400, Ron Bennett wrote:
> > the
> > newest version of OpenSSH 3.7.1p1 is conflicting
> > with PAM on our server running RedHat linux 6.2.
>
>What behavior are you seeing?  I'm running a RH 6.2 install, and 3.7.1p1
>generally seemed to work, other than PermitEmptyPasswords, which seemed
>to do nothing when pam was enabled.
>
>There seems to be significant PAM related trauma resulting from the 3.7+
>PAM code re-write in Solaris and (at least older) Linuxes.
>
>Patched versions of 3.6.1p1 seem to work just fine. :-)
>
>                                 Josh



From sq at oganer.net  Thu Sep 18 11:57:10 2003
From: sq at oganer.net (Dmitry Lohansky)
Date: Thu, 18 Sep 2003 09:57:10 +0800
Subject: sftp reget/reput
In-Reply-To: <3F67DD01.5070904@doxpara.com>
References: <1178101319.20030917111236@oganer.net>
	<20030917091810.GA8916@folly> <3F67DD01.5070904@doxpara.com>
Message-ID: <993550425.20030918095710@oganer.net>

Hello Dan,

Wednesday, September 17, 2003, 12:03:13 PM, you wrote:

DK> It's a mighty inefficient codepath that literally reads data out of 
DK> order and sends it such; disk seek times are deadly.  That being said, 
DK> simply implement a cache that handles out of order transactions and only 
DK> writes to disk complete windows of data.  This does mean memory usage 
DK> can grow in case of a small missing block, but certainly we can control 
DK> that by monitoring our number of outstanding requests and failing to 
DK> issue more when the server obstinately refuses to give us one particular 
DK> entry.

DK> This is, of course, directly analogous to a TCP Window.

I agree with Dan Kaminsky, this method is also nice.
User can use -B and -R options for manually controling size of received buffer
and number of outstanding request.

-- 
Best regards,
 Dmitry Lohansky



From dtucker at zip.com.au  Thu Sep 18 12:23:39 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 12:23:39 +1000
Subject: problem with configure in openssh-3.7p1
References: <E15A0A26BB57B845AF909DA6C14EBEE1105D53FB@dca-03.ms.cogentco.com>
Message-ID: <3F69172B.DD6887C2@zip.com.au>

"Purks, Dave" wrote:
> Problem: setting --with-tcpwrappers does not configure code to be compiled
> with wrapper support
> 
> Solution: references to with_tcp_wrappers (lines 4975, 6396, 6397) need to
> be changed to with_tcpwrappers

I don't think so.  The existing usage corresponds to both configure's help
and the comments in the INSTALL file.  What makes you think you should use
"--with-tcpwrappers"?

$ ./configure --help |grep wrapper
  --with-tcp-wrappers[=PATH]      Enable tcpwrappers support
$ grep wrapper INSTALL
--with-tcp-wrappers will enable TCP Wrappers (/etc/hosts.allow|deny)

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



From dtucker at zip.com.au  Thu Sep 18 12:56:39 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 12:56:39 +1000
Subject: Use the OpenSSH 3.6 uidswap.c for building 3.7 under IRIX
References: <030917084605.mjo@dojo.mi.org>
	<20030917135727.GA79823@spuckler.il.thewrittenword.com>
Message-ID: <3F691EE7.83F0EFD2@zip.com.au>

Albert Chin wrote:
> Do you know how we can test for a broken getaddrinfo?

I don't think you can. Take a look at the sordid details in bug #585.

Maybe we need to define BROKEN_GETADDRINFO except on known-good versions?

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



From dtucker at zip.com.au  Thu Sep 18 13:01:23 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 13:01:23 +1000
Subject: openssh-3.7.1p1 segfaults
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
Message-ID: <3F692003.7C8C9E9F@zip.com.au>

Martin Siegert wrote:
> the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> both show the same behaviour.

I've had a closer look at the debugging here (pretty good info, BTW). 
Your gdb+backtrace doesn't capture the problem, however, since the
backtrace is from the privileged process and the SEGV appears to be
occurring in the unprivileged child.

Can you try:
1) Reproducing the problem with "UsePrivilegeSeparation=no".
If it happens with privsep=no, use gdb to get a backtrace and post it.

2) If it doesn't happend with privsep, you need to try and debug the
child, which can be tricky.  I suggest setting a breakpoint for sshd.c:650
(just before the fork), then set "set follow-fork child", then continue. 
Hopefully this will catch it so you can do a backtrace.

I also suggest that if you haven't already, open a bug at
bugzilla.mindrot.org (check for dupes first) as this looks like it might
take a bit of work and it's easier to track if it's in bugzilla.

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



From admorten at umich.edu  Thu Sep 18 13:35:25 2003
From: admorten at umich.edu (Andrew Mortensen)
Date: Wed, 17 Sep 2003 23:35:25 -0400
Subject: sshd 3.7p1 dies on MacOSX
Message-ID: <240FD74A-E989-11D7-A9D7-000A9590AFE2@umich.edu>

If you define BROKEN_SETREUID and BROKEN_SETREGID, the problem goes 
away. A short test program calling setreuid on OS X will fail with the 
same error you encountered with sshd.

andrew

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Wednesday, September 17, 2003, at 08:53  AM, Darren Tucker wrote:
>
> > Jacques Distler wrote:
> >>    % egrep 'SET.*ID' config.h
> >>    /* #undef SETEUID_BREAKS_SETUID */
> >>    /* #undef BROKEN_SETREUID */
> >>    /* #undef BROKEN_SETREGID */
> >>    #define HAVE_SETEGID 1
> >>    #define HAVE_SETEUID 1
> >>    /* #undef HAVE_SETLUID */
> >>    #define HAVE_SETREGID 1
> >>    /* #undef HAVE_SETRESGID */
> >>    /* #undef HAVE_SETRESUID */
> >>    #define HAVE_SETREUID 1
> >>    #define HAVE_SETSID 1
> >
> > With those defines, I'd expect the same behaviour as 3.6.1p2, and I'd
> > also
> > expect SETEUID_BREAKS_SETUID to resolve it.  I dunno.
>
>
> Well, thanks for trying. I've posted a note
> <http://golem.ph.utexas.edu/~distler/blog/archives/000221.html> on my
> weblog warning MacOSX users about this.
>
> Jacques
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (Darwin)
> Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc
>
> iD8DBQE/aGyfnyqPIXpYcjcRApg2AKCgBG5e3J6NwdFAXcY8BrhpfwAD0wCglrf3
> XhN4mLfUH4UuXYnd1IzNjv4=
> =tnZH
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From bennett at wyomissing.com  Thu Sep 18 13:37:27 2003
From: bennett at wyomissing.com (Ron Bennett)
Date: Wed, 17 Sep 2003 23:37:27 -0400
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
In-Reply-To: <5.2.1.1.2.20030917214350.031b5458@wyomissing.com>
References: <20030917175705.A20529@delusion.private.untruth.org>
	<5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
	<5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
Message-ID: <5.2.1.1.2.20030917232858.029bb5c8@wyomissing.com>

At 09:55 PM 9/17/2003 -0400, Ron Bennett wrote:

<snipped>

>Anyone know what changed to make SecureCRT
>not work anymore with some sshd installs? Bizarre!

Addendum...keyboard interactive *on* in sshd_config
and using ssh2 with keyboard interactive logins in
SecureCRT works like a charm...

Not sure if this is an ideal login setup, but at this
point it's the only way I'm able to login into servers
and get work done. Welcome further suggestions.

On an aside, this only seems to be necessary for the
RedHat linux 6.2 servers I maintain...newer Redhat
versions work like a charm without keyboard interactive.

Ron



From distler at golem.ph.utexas.edu  Thu Sep 18 14:10:47 2003
From: distler at golem.ph.utexas.edu (Jacques Distler)
Date: Wed, 17 Sep 2003 23:10:47 -0500
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <Pine.UW2.4.58.0309171829460.16453@ou8.int.multitalents.net>
Message-ID: <14AFACFC-E98E-11D7-9027-00039344D894@golem.ph.utexas.edu>

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


On Wednesday, September 17, 2003, at 08:31  PM, Tim Rice wrote:

>
> The attached patch will do the trick.
>

Didn't work for me (since you put the DEFINEs in a conditional). 
Slightly re-ordering your patch did the trick.

- --- configure.ac~       Tue Sep 16 00:48:15 2003
+++ configure.ac        Wed Sep 17 22:00:46 2003
@@ -122,6 +122,9 @@
         AC_DEFINE(IP_TOS_IS_BROKEN)
         ;;
  *-*-darwin*)
+       AC_DEFINE(SETEUID_BREAKS_SETUID)
+       AC_DEFINE(BROKEN_SETREUID)
+       AC_DEFINE(BROKEN_SETREGID)
         AC_MSG_CHECKING(if we have working getaddrinfo)
         AC_TRY_RUN([#include <mach-o/dyld.h>
  main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16))



Jacques
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc

iD8DBQE/aTBQnyqPIXpYcjcRAn2lAKDKsB11HOu0nZ0qFD2nkoVdmxI2NACfQVDb
HK77BDpPKNXj/hr6FfPp28U=
=g0b+
-----END PGP SIGNATURE-----



From openssh at roumenpetrov.info  Wed Sep 17 21:41:55 2003
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Wed, 17 Sep 2003 14:41:55 +0300
Subject: X.509v3 certificates support  in OpenSSH-3.7.1p1
Message-ID: <3F684883.6010809@roumenpetrov.info>

Diff of "X.509v3 certificates support for OpenSSH" version g2 (code name 
Compatibility) for OpenSSH-3.7.1p1 is ready for download.

Go to "http://roumenpetrov.info/openssh" and get it.



From dtucker at zip.com.au  Thu Sep 18 15:33:15 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 15:33:15 +1000
Subject: openssh-unix-dev@mindrot.org
References: <20030917173219.A21614@helena.bawue.de>
Message-ID: <3F69439B.2C37D7DC@zip.com.au>

Florian Laws wrote:
> I'm getting compile errors on AIX 5.1,
> not defining WITH_AIXAUTHENTICATE in config.h seems to solve the problem.
[snip
> /usr/include/usersec.h:625: warning: `struct aud_rec' declared inside parameter list
> /usr/include/usersec.h:625: warning: its scope is only this definition or declaration, which is probably not what you want.
> /usr/include/usersec.h:626: warning: `struct aud_rec' declared inside parameter list

Please try the patch at:
http://bugzilla.mindrot.org/show_bug.cgi?id=640

BTW, I test on AIX 5.1 but I use gcc-3.3 and it seems to work fine.

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



From dtucker at zip.com.au  Thu Sep 18 15:35:22 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 15:35:22 +1000
Subject: problems with 3.7.1p1 on BSD/OS
References: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
	<20030917151944.GA17099@doctor.nl2k.ab.ca>
Message-ID: <3F69441A.3C769B16@zip.com.au>

The Doctor wrote:
> 
> This is what is happening on BSD/OS.

Please see this bug:
http://bugzilla.mindrot.org/show_bug.cgi?id=657

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



From distler at golem.ph.utexas.edu  Thu Sep 18 15:48:03 2003
From: distler at golem.ph.utexas.edu (Jacques Distler)
Date: Thu, 18 Sep 2003 00:48:03 -0500
Subject: SRP secure remote password authentication
Message-ID: <AB334C5E-E99B-11D7-9027-00039344D894@golem.ph.utexas.edu>

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

Markus Friedl wrote:

> we cannot add them if they are tainted.
>
> we don't care if they are granted in _some_ countries.

What am I missing?

 From the SRP License <http://srp.stanford.edu/license.txt> :

     SRP is royalty-free worldwide for commercial and non-commercial use.
     The SRP library has been carefully written not to depend on any
     encumbered algorithms, and it is distributed under a standard
     BSD-style Open Source license which is shown below.  This license
     covers implementations based on the SRP library as well as
     independent implementations based on RFC 2945.


Jacques Distler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc

iD8DBQE/aUcbnyqPIXpYcjcRAqSEAJ41h43GKudyz8mGm8aJwGMEERvOVwCfTon8
MxA/cFy6AJpum7LjMM7I13w=
=uz6/
-----END PGP SIGNATURE-----



From dtucker at zip.com.au  Thu Sep 18 16:33:24 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 16:33:24 +1000
Subject: openssh 3.7p1 and 3.7.1p1 Solaris problems
References: <3F6890C3.5060309@eece.ksu.edu>
Message-ID: <3F6951B4.E3B1A2D4@zip.com.au>

Bradley Guenther wrote:
> 
> I have some Solaris 7 boxes (Ultra 3 and Ultra Enterprise 250 hardware)
> that I have compiled both 3.7p1 and 3.7.1p1 on and am having some
> problems.  I am using the same "configure" options that I have in the
> past (without problems).  I have tried both new and existing (previously
> working) ssh_config and sshd_config files.  The new versions seem to
> have broken SSH 1 support (and maybe cause a bit of SSH 2 problems).
> All of my unix boxes can ssh into the server fine.  Cygwin users can ssh
> in fine.  TeraTerm Pro (both the old one that supports ssh1 only and the
> new one which <allegedly> supports ssh2) both just keep prompting me for
> my password over and over again.  Putty v.52 (older version) crashes
> when I try  to connect via ssh2, and gives me "Access denied" on
> attempts via ssh1.  The latest version (as of last night at least) of
> Putty works on ssh2 but still gives me the "Access denied" over and over
> again on ssh1 attempts.  Winscp basically works, but prompts for the
> password twice.

Try turning on TIS authentication in PuTTY:
Connection -> SSH -> Auth -> Attempt TIS or cryptocard authentication.

If you're using WithPAM=yes, you should probably set
PasswordAuthentication=no.  From the sshd_config man page:
"UsePAM  Enables PAM authentication (via challenge?response) and session
        set up.  If you enable this, you should probably disable
        PasswordAuthentication."

See also:
http://bugzilla.mindrot.org/show_bug.cgi?id=669

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



From proclus at gnu-darwin.org  Thu Sep 18 16:37:02 2003
From: proclus at gnu-darwin.org (proclus at gnu-darwin.org)
Date: Thu, 18 Sep 2003 02:37:02 -0400 (EDT)
Subject: Darwin notes for openssh-3.7.1p1
Message-ID: <20030918063738.9C405E8E48@gnu-darwin.org>


I was able to build working openssh-3.7.1p1 on the Darwin-ppc-1.4 , 5.5, and 6.0 platform, by
setting the following by hand in config.h.

#define SETEUID_BREAKS_SETUID 
#define BROKEN_SETREUID
#define HAVE_SETEUID 1
/* #undef HAVE_SETREUID 1 */

For Darwin-x86-6.6.1, it built with the following.

#define SETEUID_BREAKS_SETUID 
/* #undef BROKEN_SETREUID */
#define HAVE_SETEUID 1
/* #undef HAVE_SETREUID 1 */

Here is what I get from configure.

/* #undef SETEUID_BREAKS_SETUID */
/* #undef BROKEN_SETREUID */
#define HAVE_SETEUID 1
#define HAVE_SETREUID 1

Without this change, the implementation for SETREUID is apparently
broken in Darwin, which in turn breaks sshd.   Sorry, if this is old
news, which might be fixed in Darwin-7, but it would be good to have
this working with the older versions of Darwin as well.

I am not subscribed to this list, so if you want to contact me, please
send directly to me.

Regards,
proclus
http://www.gnu-darwin.org/



-- 
Visit proclus realm! http://proclus.tripod.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GMU/S d+@ s: a+ C++++ UBOULI++++$ P+ L+++(++++) E--- W++ N- !o K- w--- !O
M++@ V-- PS+++ PE Y+ PGP-- t+++(+) 5+++ X+ R tv-(--)@ b !DI D- G e++++
h--- r+++ y++++
------END GEEK CODE BLOCK------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030918/2380fba5/attachment.bin 

From djm at mindrot.org  Thu Sep 18 17:38:49 2003
From: djm at mindrot.org (Damien Miller)
Date: Thu, 18 Sep 2003 07:38:49 -0000
Subject: sftp reget/reput
In-Reply-To: <3F67DD01.5070904@doxpara.com>
References: <1178101319.20030917111236@oganer.net>
	<20030917091810.GA8916@folly>  <3F67DD01.5070904@doxpara.com>
Message-ID: <1063870569.5329.29.camel@sakura.mindrot.org>

On Wed, 2003-09-17 at 14:03, Dan Kaminsky wrote:
> It's a mighty inefficient codepath that literally reads data out of 
> order and sends it such; disk seek times are deadly.  That being said, 
> simply implement a cache that handles out of order transactions and only 
> writes to disk complete windows of data. 

Given that I know of no sftp server implementations that actually do out
of order replies, I don't think we should complexify our client with
such an algorithm.

Even if some braindead vendor decided to do this, I'd probably not
change our client to 1) keep it simple and 2) punish the fools.

-d




From dtucker at zip.com.au  Thu Sep 18 17:57:54 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 17:57:54 +1000
Subject: openssh-3.7.1p1 segfaults
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F685058.5C328C07@zip.com.au>
	<20030917173528.GA19609@stikine.ucs.sfu.ca>
	<3F68E872.1C726EF@zip.com.au>
	<20030918013247.GC20142@stikine.ucs.sfu.ca>
Message-ID: <3F696582.3EA87A35@zip.com.au>

Martin Siegert wrote:
> I've tried it on Solaris 2.6 and 8 and 9. On Solaris 8 and 9 openssh-3.7.1p1
> plus this patch work fine, on Solaris 2.6 sshd still segfaults.

Please try patch #422 here:
http://bugzilla.mindrot.org/show_bug.cgi?id=647

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



From cdewick at lios.apana.org.au  Thu Sep 18 18:22:19 2003
From: cdewick at lios.apana.org.au (Craig Dewick)
Date: Thu, 18 Sep 2003 18:22:19 +1000 (EST)
Subject: Problem building OpenSSH on Cobalt Raq2i running standard Linux  
Message-ID: <Pine.GSO.4.56.0309181819580.13105@lios.apana.org.au>


Hi everyone,

I'm trying to build OpenSSH on my Cobalt Raq2i box which is running the
standard Linux installation with all patches installed.

I had no problems building OpenSSL v0.9.7b and it installed without
problems as well.

However, the OpenSSH build keeps failing at a certain point:

gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.
-I/usr/local/ssl/include -DSSHDIR=\"/usr/local/etc\"
-D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"
-D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\"
-DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H
-c monitor_fdpass.c
monitor_fdpass.c: In function `mm_send_fd':
monitor_fdpass.c:57: `SCM_RIGHTS' undeclared (first use this function)
monitor_fdpass.c:57: (Each undeclared identifier is reported only once
monitor_fdpass.c:57: for each function it appears in.) make: ***
[monitor_fdpass.o] Error 1

I'm trying to build v3.7.1p1 at the moment, and I have also tried v3.4p1
as well as several in between releases.

Has anyone else come across this problem? The version of gcc which comes
with Linux for the Raq2's is v2.7.2. I wouldn't expect that the be too
old, but it might be.  If the problem has nothing to do with OpenSSH I'll
need to look elsewhere...

Craig.



From mouring at etoh.eviladmin.org  Thu Sep 18 19:13:10 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 18 Sep 2003 04:13:10 -0500 (CDT)
Subject: SRP Support
In-Reply-To: <3F68F069.7000802@arcot.com>
Message-ID: <Pine.BSO.4.44.0309180411360.842-100000@etoh.eviladmin.org>



On Wed, 17 Sep 2003, Tom Wu wrote:

> Ben,
>
> Can you be more specific about these "IP issues" you are referring to?
> Is the IETF royalty-free statement insufficiently clear?  AFAIK,
> Stanford *has* done precisely what you indicate by providing SRP in a
> 100% free and usable way, judging by adoption in other OSS software
> projects.
>

It is not Stanford we worry about.  It is Lucent and others that claim
that it may infringe on their patents.  You seem to forget about these
claims.

- Ben

> Tom
>
> Ben Lindstrom wrote:
> > Until all IP issues are resolved and it is provided in a 100% free and
> > usable way it will *NEVER* be included.
> >
> > - Ben
> >
> > On Wed, 17 Sep 2003, Edward Flick wrote:
> >
> >
> >>Just wondering if there were any plans to integrate SRP support into
> >>OpenSSH.  And if there aren't would a patch be accepted that would enable
> >>such.  And if so could anyone give me a couple of pointers as to where the
> >>authentication code goes.
> >>
> >>Edward Flick
> >>
> >>_______________________________________________
> >>openssh-unix-dev mailing list
> >>openssh-unix-dev at mindrot.org
> >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >>
> >
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
> --
> Tom Wu
> Chief Security Architect
> Arcot Systems
> (408) 969-6124
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mouring at etoh.eviladmin.org  Thu Sep 18 19:21:26 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 18 Sep 2003 04:21:26 -0500 (CDT)
Subject: SRP secure remote password authentication
In-Reply-To: <3F691151.7090406@arcot.com>
Message-ID: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>



On Wed, 17 Sep 2003, Tom Wu wrote:

> Damien Miller wrote:
> > On Thu, 2003-09-18 at 05:19, Tom Wu wrote:
> >
> >>SRP is, if anything, the protocol with the *least* problematic patent
> >>license:
> >>
> >>   http://www.ietf.org/ietf/IPR/WU-SRP
> >
> >
> > And what about the claims that other companies make on SRP? E.g.
> >
> > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09292.html
> >
> > You know about those and yet you fail to mention them.
>
> If you look carefully at such "claims", you'll see that they are filled
> with "may"s and "might"s, if in fact there is any claim being made at
> all.  Unless there is some more substantiation that would allow one to
> distinguish them from frivolous claims designed to cause marketplace
> confusion/fear, I don't see why anyone, especially OSS projects
> ostensibly opposed to precisely this kind of patent abuse, should grant
> them any kind of legitimacy.
>

NORMALLY companies don't say "may" or "might" unless there is a damn good
reason.  Most business really do want to be upfront and honest (there are
accepts to this rule).

Personally, I'd rather not touch it until those companies make an official
announcement clearing or granted.  And so far neither are forth coming.
So I don't see a need to be the first to jump into the pool just to be bit
in the ass by the shark

- Ben



From v.pennington at man.ac.uk  Thu Sep 18 19:24:34 2003
From: v.pennington at man.ac.uk (Victoria Pennington)
Date: Thu, 18 Sep 2003 10:24:34 +0100
Subject: problems with 3.7.1p1 on IRIX (again)
In-Reply-To: <20030917150216.GA80595@spuckler.il.thewrittenword.com>
References: <Pine.SGI.4.56.0309171345211.11830@troll.mcc.ac.uk>
	<20030917150216.GA80595@spuckler.il.thewrittenword.com>
Message-ID: <Pine.SGI.4.56.0309181012390.35208@troll.mcc.ac.uk>

Thanks to all who replied on this.
I find that the following definitions are needed:

SETEUID_BREAKS_SETUID
BROKEN_SETREUID
BROKEN_SETREGID

BROKEN_GETADDRINFO doesn't seem to be needed for IRIX 6.5.19.

I'm slightly concerned though that these definitions may have broken something
important, e.g. Priv separation...  Can anyone reassure me?

Thanks
Victoria
---
Dr Victoria Pennington
Manchester Computing, Kilburn Building,
University of Manchester,
Oxford Road, Manchester M13 9PL
tel. 0161 275 6830, email: v.pennington at man.ac.uk

On Wed, 17 Sep 2003, Albert Chin wrote:

> On Wed, Sep 17, 2003 at 01:59:46PM +0100, Victoria Pennington wrote:
> > I've seen a few messages re. problems with 3.7.1p1 on IRIX 6.5...
> > I'm using 6.5.19 and having no trouble compiling, installing and
> > starting, but sshd just closes the connection with no explanation.
> > debug/verbose modes don't seem to give any clues.
> >
> > Darren Tucker suggested defining BROKEN_GETADDRINFO in config.h,
> > but I find that compilation then fails (assuming I've implemented this
> > right).
> >
> > Has anyone had any success yet?
>
> I use the following patch for IRIX. Rerun autoconf and autoheader.
>
> --
> albert chin (china at thewrittenword.com)
>
> -- snip snip
> --- configure.ac.orig	Tue Sep 16 09:39:55 2003
> +++ configure.ac	Wed Sep 17 09:22:03 2003
> @@ -198,6 +178,10 @@
>  	AC_DEFINE(WITH_IRIX_AUDIT)
>  	AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)])
>  	AC_DEFINE(BROKEN_INET_NTOA)
> +	AC_DEFINE(BROKEN_GETADDRINFO)
> +	AC_DEFINE(SETEUID_BREAKS_SETUID)
> +	AC_DEFINE(BROKEN_SETREUID)
> +	AC_DEFINE(BROKEN_SETREGID)
>  	AC_DEFINE(WITH_ABBREV_NO_TTY)
>  	AC_DEFINE(LOCKED_PASSWD_STRING, "*LK*")
>  	;;
> @@ -714,7 +699,7 @@
>  AC_CHECK_FUNCS(\
>  	arc4random __b64_ntop b64_ntop __b64_pton b64_pton basename \
>  	bcopy bindresvport_sa clock fchmod fchown freeaddrinfo futimes \
> -	gai_strerror getaddrinfo getcwd getgrouplist getnameinfo getopt \
> +	getaddrinfo getcwd getgrouplist getnameinfo getopt \
>  	getpeereid _getpty getrlimit getttyent glob inet_aton \
>  	inet_ntoa inet_ntop innetgr login_getcapbool md5_crypt memmove \
>  	mkdtemp mmap ngetaddrinfo nsleep ogetaddrinfo openlog_r openpty \
> @@ -725,6 +710,21 @@
>  	strlcat strlcpy strmode strnvis sysconf tcgetpgrp \
>  	truncate utimes vhangup vsnprintf waitpid \
>  )
> +
> +# IRIX has a const char return value for gai_strerror()
> +AC_CHECK_FUNCS(gai_strerror,[
> +	AC_DEFINE(HAVE_GAI_STRERROR)
> +	AC_TRY_COMPILE([
> +#include <sys/types.h>
> +#include <sys/socket.h>
> +#include <netdb.h>
> +
> +const char *gai_strerror(int);],[
> +char *str;
> +
> +str = gai_strerror(0);],[
> +		AC_DEFINE(HAVE_CONST_GAI_STRERROR_PROTO, 1,
> +		[Define if gai_strerror() returns const char *])])])
>
>  AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP))
>
> --- openbsd-compat/fake-rfc2553.h.orig	Wed Sep 17 05:45:58 2003
> +++ openbsd-compat/fake-rfc2553.h	Wed Sep 17 08:55:52 2003
> @@ -137,7 +137,7 @@
>      const struct addrinfo *, struct addrinfo **);
>  #endif /* !HAVE_GETADDRINFO */
>
> -#ifndef HAVE_GAI_STRERROR
> +#if !defined(HAVE_GAI_STRERROR) && !defined(HAVE_CONST_GAI_STRERROR_PROTO)
>  char *gai_strerror(int);
>  #endif /* !HAVE_GAI_STRERROR */
>
> --- openbsd-compat/fake-rfc2553.c.orig	Wed Sep 17 05:46:02 2003
> +++ openbsd-compat/fake-rfc2553.c	Wed Sep 17 08:55:11 2003
> @@ -77,7 +77,11 @@
>  #endif /* !HAVE_GETNAMEINFO */
>
>  #ifndef HAVE_GAI_STRERROR
> +#ifdef HAVE_CONST_GAI_STRERROR_PROTO
> +const char *
> +#else
>  char *
> +#endif
>  gai_strerror(int err)
>  {
>  	switch (err) {
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dtucker at zip.com.au  Thu Sep 18 19:25:12 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 19:25:12 +1000
Subject: 3.7.1p1 PAM Problems in RedHat 6.2
References: <5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
	<5.2.1.1.2.20030917151822.029a8720@wyomissing.com>
	<5.2.1.1.2.20030917214350.031b5458@wyomissing.com>
Message-ID: <3F6979F8.DE99373D@zip.com.au>

Ron Bennett wrote:
> Anyone know what changed to make SecureCRT
> not work anymore with some sshd installs? Bizarre!

Check if it has "keyboard-interactive" authentication enabled.

See:
http://bugzilla.mindrot.org/show_bug.cgi?id=648
http://bugzilla.mindrot.org/show_bug.cgi?id=669

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



From markus at openbsd.org  Thu Sep 18 20:16:11 2003
From: markus at openbsd.org (Markus Friedl)
Date: Thu, 18 Sep 2003 12:16:11 +0200
Subject: sftp reget/reput
In-Reply-To: <3F67DD01.5070904@doxpara.com>
References: <1178101319.20030917111236@oganer.net>
	<20030917091810.GA8916@folly> <3F67DD01.5070904@doxpara.com>
Message-ID: <20030918101611.GB5919@folly>

imho, rolling checksums would be more useable. e.g.
if a file changes.

On Tue, Sep 16, 2003 at 09:03:13PM -0700, Dan Kaminsky wrote:
> It's a mighty inefficient codepath that literally reads data out of 
> order and sends it such; disk seek times are deadly.  That being said, 
> simply implement a cache that handles out of order transactions and only 
> writes to disk complete windows of data.  This does mean memory usage 
> can grow in case of a small missing block, but certainly we can control 
> that by monitoring our number of outstanding requests and failing to 
> issue more when the server obstinately refuses to give us one particular 
> entry.
> 
> This is, of course, directly analogous to a TCP Window.
> 
> --Dan
> 
> 
> Markus Friedl wrote:
> 
> >we could modify the protocol and implement
> >rolling checksums like Niels Provos suggests:
> >
> >	MD5_CTX ctx1, ctx2;
> >
> >	MD5_Init(&ctx1);
> >
> >	while new page in data
> >	  MD5_Update(&ctx1, newpage, pagesize)
> >	  ctx2 = ctx1;
> >	  MD5_Final(digest, &ctx2)
> >	  if (compare with remote not equal)
> >	     break;
> >	end while
> >
> >	continue data transfer.
> >
> >On Wed, Sep 17, 2003 at 11:12:36AM +0800, Dmitry Lohansky wrote:
> > 
> >
> >>Hello openssh@
> >>
> >>I thought about sftp's reget/reput commands.
> >>
> >>Several days ago, Damien Miller write to tech at openbsd.org (it was
> >>reply for my letter):
> >>
> >>   
> >>
> >>>Herein lies a problem which is not easy to detect or solve. For
> >>>performance reasons, the sftp client does pipelined reads/writes when
> >>>transferring files. The protocol spec allows for a server to process
> >>>these requests out of order. For example:
> >>>     
> >>>
> >>>client                     server
> >>>------                     ------
> >>>open file                  your file handle is "blah"
> >>>gimme bytes 0-8191
> >>>gimme bytes 8192-16383
> >>>gimme bytes 16384-24575
> >>>gimme bytes 24576-32767    here are bytes 24576-32767
> >>>close file                 here are bytes 16384-24575
> >>>                          here are bytes 8192-16383
> >>>                          here are bytes 0-8191
> >>>                          close successful
> >>>     
> >>>
> >>>If the client writes the bytes our in the order they are received (which
> >>>it probably should, to avoid buffering large amounts of data) then an
> >>>interruption will leave a full-length, but "holey" file on disk. There
> >>>is no general way to determine how to do resume such a transfer.
> >>>     
> >>>
> >>>The best the client can do to make transfers resumable is ftruncate()
> >>>the file at the highest contiguous byte received. This will stop the
> >>>potential corruption on resume.
> >>>     
> >>>
> >>This is good method, but if client crash, we also may get a "hole".
> >>What your think about next way?
> >>
> >>Storing extra-data at the end of file, for example:
> >>
> >><---orig-part-><-extra->
> >>[*][ ][*][ ][*][*******]
> >><---------file--------->
> >>
> >>where [*] - already loaded data, [ ] - not yet
> >>
> >>In extra part, we may store which block was already loaded and it
> >>offset and size. After download, extra part will be removed.
> >>
> >>Comments?
> >>-- 
> >>Dmitry Lohansky
> >>
> >>_______________________________________________
> >>openssh-unix-dev mailing list
> >>openssh-unix-dev at mindrot.org
> >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >>   
> >>
> >
> >_______________________________________________
> >openssh-unix-dev mailing list
> >openssh-unix-dev at mindrot.org
> >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > 
> >
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From florian at void.s.bawue.de  Thu Sep 18 20:41:45 2003
From: florian at void.s.bawue.de (Florian Laws)
Date: Thu, 18 Sep 2003 12:41:45 +0200
Subject: openssh-unix-dev@mindrot.org
In-Reply-To: <3F69439B.2C37D7DC@zip.com.au>
References: <20030917173219.A21614@helena.bawue.de>
	<3F69439B.2C37D7DC@zip.com.au>
Message-ID: <20030918104145.GA1476@void.s.bawue.de>

On Thu, Sep 18, 2003 at 03:33:15PM +1000, Darren Tucker wrote:
> Florian Laws wrote:
> > I'm getting compile errors on AIX 5.1,
> > not defining WITH_AIXAUTHENTICATE in config.h seems to solve the problem.
> [snip
> > /usr/include/usersec.h:625: warning: `struct aud_rec' declared inside parameter list
> > /usr/include/usersec.h:625: warning: its scope is only this definition or declaration, which is probably not what you want.
> > /usr/include/usersec.h:626: warning: `struct aud_rec' declared inside parameter list
> 
> Please try the patch at:
> http://bugzilla.mindrot.org/show_bug.cgi?id=640

That patch seems to solve to problem.

Thanks a lot.

Regards,

Florian



From pekkas at netcore.fi  Thu Sep 18 21:32:03 2003
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 18 Sep 2003 14:32:03 +0300 (EEST)
Subject: OpenSSH Security Advisory: buffer.adv
In-Reply-To: <Pine.LNX.4.50.0309180139130.31145-100000@alf.ulyssis.org>
Message-ID: <Pine.LNX.4.44.0309181430550.17805-100000@netcore.fi>

Seem to have merged two hours ago.

Some of those are just cleanups though, e.g. the deattack.c change (at 
least, I fail to see how that would change the functional behaviour).

On Thu, 18 Sep 2003, Dries Schellekens wrote:
> On Wed, 17 Sep 2003, Dries Schellekens wrote:
> 
> > Will the 4 extra fixes by Solar Designer be included as well?
> >
> > >From the Owl Changelog
> > 2003/09/17	Package: openssh
> > SECURITY FIX	Severity: medium, remote, active
> >
> > Multiple memory management errors have been discovered in OpenSSH, and
> > this update corrects 6 such real or potential errors based on an
> > exhaustive review of the OpenSSH source code for uses of *realloc()
> > functions. At this time, it is uncertain whether and which of these bugs
> > are exploitable. If exploits are possible, due to privilege separation,
> > the worst direct impact should be limited to arbitrary code execution
> > under the sshd pseudo-user account restricted within the chroot jail
> > /var/empty, or under the logged in user account. Reference:
> > http://www.openssh.com/txt/buffer.adv
> 
> So is there no urgent need to include these fixes?
> 
> 
> Cheers,
> 
> Dries
> --
> Dries Schellekens
> email: gwyllion at ulyssis.org
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From dtucker at zip.com.au  Thu Sep 18 21:36:32 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Sep 2003 21:36:32 +1000
Subject: Problem building OpenSSH on Cobalt Raq2i running standard Linux
References: <Pine.GSO.4.56.0309181819580.13105@lios.apana.org.au>
Message-ID: <3F6998C0.F59C661@zip.com.au>

Craig Dewick wrote:
> I'm trying to build OpenSSH on my Cobalt Raq2i box which is running the
> standard Linux installation with all patches installed.
[snip]
> monitor_fdpass.c: In function `mm_send_fd':
> monitor_fdpass.c:57: `SCM_RIGHTS' undeclared (first use this function)
> monitor_fdpass.c:57: (Each undeclared identifier is reported only once
> monitor_fdpass.c:57: for each function it appears in.) make: ***
> [monitor_fdpass.o] Error 1

Your headers (and possibly kernel?) appear to be missing the parts
required to do descriptor passing, but have enough to fool configure's
tests.

What are HAVE_SENDMSG, HAVE_ACCRIGHTS_IN_MSGHDR and HAVE_CONTROL_IN_MSGHDR
set to in config.h?

If you comment out "#define HAVE_SENDMSG" from config.h, you should be
able to compile OK (however you'll have to run without
PrivilegeSeparation).

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



From mstone at mathom.us  Thu Sep 18 23:55:38 2003
From: mstone at mathom.us (Michael Stone)
Date: Thu, 18 Sep 2003 09:55:38 -0400
Subject: SRP secure remote password authentication
In-Reply-To: <1931307.1063875514@[192.168.1.14]>
References: <8463549.1063796418@[192.168.1.14]> <3F676C5B.5000105@doxpara.com>
	<3F68B527.4040702@arcot.com> <1931307.1063875514@[192.168.1.14]>
Message-ID: <20030918135538.GM14852@mathom.us>

On Thu, Sep 18, 2003 at 08:58:34AM +1000, Jeremy Nysen wrote:
>I've been using Tom Holroyd's OpenSSH SRP patches for quite a while and 
>they do exactly that. Under Redhat, the PAM module makes the EPS verifiers 
>transparent to the applications, and lets EPS work with anything that uses 
>PAM, (eg. Samba, login, imap, pop, ldap, etc). OpenSSH can still 
>authenticate with EPS without the SRP patches through the PAM subsystem, 
>but obviously this doesn't use the SRP protocol.

I'm confused. If you can implement this via PAM why do you need special
patches? What's the difference between the two approaches?

Mike Stone



From eddy at cdf-imaging.com  Fri Sep 19 00:22:42 2003
From: eddy at cdf-imaging.com (Edward Flick)
Date: Thu, 18 Sep 2003 09:22:42 -0500
Subject: SRP secure remote password authentication
In-Reply-To: <20030918135538.GM14852@mathom.us>
Message-ID: <DBEJKFKIDIDOKKCGEDHMAELGCIAA.eddy@cdf-imaging.com>

I'm assuming PAM is just for local authentication as it does not dictate the
method by which the client and the authenticator exchange the user/pass
which SRP and other remote authentication methods do.

Edward Flick

-----Original Message-----
From: openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org
[mailto:openssh-unix-dev-bounces+eddy=cdf-imaging.com at mindrot.org]On
Behalf Of Michael Stone
Sent: Thursday, September 18, 2003 8:56 AM
To: openssh-unix-dev at mindrot.org
Subject: Re: SRP secure remote password authentication


On Thu, Sep 18, 2003 at 08:58:34AM +1000, Jeremy Nysen wrote:
>I've been using Tom Holroyd's OpenSSH SRP patches for quite a while and
>they do exactly that. Under Redhat, the PAM module makes the EPS verifiers
>transparent to the applications, and lets EPS work with anything that uses
>PAM, (eg. Samba, login, imap, pop, ldap, etc). OpenSSH can still
>authenticate with EPS without the SRP patches through the PAM subsystem,
>but obviously this doesn't use the SRP protocol.

I'm confused. If you can implement this via PAM why do you need special
patches? What's the difference between the two approaches?

Mike Stone

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



From ramses at smeyers.be  Fri Sep 19 00:29:35 2003
From: ramses at smeyers.be (Ramses Smeyers)
Date: Thu, 18 Sep 2003 16:29:35 +0200 (CEST)
Subject: compille errors on AIX 5.1ML04 and AIX 4.3.3ML10
Message-ID: <Pine.LNX.4.44.0309181627110.26534-100000@horsea.3ti.be>

Hi,

OpenSSH 3.7.1p1 doesn't compille on AIX 4.3.3 ml09 and AIX 5.1.0 ml04

previous versions worked fine
gcc used:   gcc-2.9.aix51.020209-3

configure:
./configure --with-default-path=/usr/local/bin:/usr/bin:/bin
--sysconfdir=/etc/openssh --with-pid-dir=/etc/openssh --
with-xauth=/usr/bin/X11/xauth --prefix=/usr/local

I applied the following patch

[root at bedsd188:/home/root/build/openssh] cat aix.patch
35c35
< #  include <sys/audit.h>
---
> //#  include <sys/audit.h>
[root at bedsd188:/home/root/build/openssh]

and now it compilles fine

can somebody look whats going wrong with including audit.h ?

        gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I.
-I./..  -I/usr/local/include -DHAVE_CONFIG_H -c bsd-arc4random.c
In file included from ../openbsd-compat/port-aix.h:35,
                 from ../openbsd-compat/openbsd-compat.h:166,
                 from ../includes.h:173,
                 from bsd-arc4random.c:25:
/usr/include/sys/audit.h:291: warning: `\' followed by white space at end
of line
/usr/include/sys/audit.h:294: warning: `\' followed by white space at end
of line
In file included from ../openbsd-compat/port-aix.h:33,
                 from ../openbsd-compat/openbsd-compat.h:166,
                 from ../includes.h:173,
                 from bsd-arc4random.c:25:
/usr/include/usersec.h:625: warning: `struct aud_rec' declared inside
parameter list
/usr/include/usersec.h:625: warning: its scope is only this definition or
declaration, which is probably not what you want.
/usr/include/usersec.h:626: warning: `struct aud_rec' declared inside
parameter list
In file included from ../openbsd-compat/port-aix.h:35,
                 from ../openbsd-compat/openbsd-compat.h:166,
                 from ../includes.h:173,
                 from bsd-arc4random.c:25:
/usr/include/sys/audit.h:292: parse error before `0200'
/usr/include/sys/audit.h:307: parse error before `}'
make: 1254-004 The error code from the last command is 1.


ys,
Ramses Smeyers

-- 
>From Winnie-the-Pooh's Little Book of Wisdom:
Solving Storage Problems: A Useful Pot can make you glad. It;s for putting things in.






From dtucker at zip.com.au  Fri Sep 19 01:06:00 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 19 Sep 2003 01:06:00 +1000
Subject: compille errors on AIX 5.1ML04 and AIX 4.3.3ML10
References: <Pine.LNX.4.44.0309181627110.26534-100000@horsea.3ti.be>
Message-ID: <3F69C9D8.CBA2EB2B@zip.com.au>

Ramses Smeyers wrote:
> OpenSSH 3.7.1p1 doesn't compille on AIX 4.3.3 ml09 and AIX 5.1.0 ml04
> 
> previous versions worked fine
> gcc used:   gcc-2.9.aix51.020209-3

This is a known issue, please see:
http://bugzilla.mindrot.org/show_bug.cgi?id=640
There is patch there should work for all versions of AIX.

audit.h is only required on AIX 5.2 for the 4th argument to
loginfailed().  I have seen reports that the compile error is due to extra
whitespace at the end of audit.h, but I have not confirmed that.

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



From beebe at math.utah.edu  Fri Sep 19 03:55:39 2003
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 18 Sep 2003 11:55:39 -0600 (MDT)
Subject: ssh-openbsd-2003091700 distribution missing gss_krb5_copy_ccache
Message-ID: <CMM.0.92.0.1063907739.beebe@psi.math.utah.edu>

Build attempts of the new ssh-openbsd-2003091700 distribution fail
like this on OpenBSD 3.2:

	cc   -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o
	serverloop.o uidswap.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o
	groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o
	auth2-pubkey.o monitor_mm.o monitor.o monitor_wrap.o monitor_fdpass.o kexdhs.o kexgexs.o auth-krb5.o
	auth2-gss.o gss-serv.o gss-serv-krb5.o -L/local/build/ssh-openbsd-2003091700/sshd/../lib -lssh -lgssapi
	-lkrb5 -lcrypto -lutil -lz -ldes -lwrap
	gss-serv-krb5.o: Undefined symbol `_gss_krb5_copy_ccache' referenced from text segment
	collect2: ld returned 1 exit status

A search of the source tree finds a single reference to that symbol in
ssh-openbsd-2003091700/gss-serv-krb5.c, but nowhere is there a
definition of it as a function.  Neither is there a definition of that
symbol in any of the /usr/lib/*.a files.

Please include me directly in any replies; I'm not a list member.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: beebe at math.utah.edu  -
- Department of Mathematics, 110 LCB        beebe at acm.org  beebe at computer.org -
- 155 S 1400 E RM 233                                                         -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------



From beebe at math.utah.edu  Fri Sep 19 04:06:12 2003
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 18 Sep 2003 12:06:12 -0600 (MDT)
Subject: openssh-3.7.1p1 distribution missing inet_ntoa.h header file
Message-ID: <CMM.0.92.0.1063908372.beebe@psi.math.utah.edu>

A build of the new openssh-3.7.1p1 distribution failed on SGI IRIX 6.5
because the inet_ntoa.h header file is not part of the openssh-3.7.1p1
distribution:

	cc -I/usr/local/include -I. -I.. -I. -I./.. -I/usr/local/include  -I/usr/local/include -DHAVE_CONFIG_H -c inet_ntoa.c
	cc-1005 cc: ERROR File = inet_ntoa.c, Line = 46
	  The source file "inet_ntoa.h" is unavailable.

	  #include "inet_ntoa.h"
				^

	1 catastrophic error detected in the compilation of "inet_ntoa.c".

As a workaround, I grabbed a copy of that file from the
openssh-3.6.1p2 distribution, and got the build to succeed.

For the record, I configured like this:

	env CC=cc \
		CFLAGS=-I/usr/local/include \
		CXX=CC \
		LDFLAGS=-Wl,-rpath,/usr/local/lib \
		./configure \
			--sysconfdir=/etc/ssh \
			--with-pid-dir=/var/run \
			--with-ssl-dir=/usr/local \
			--with-tcp-wrappers \
			--with-libs="/usr/local/lib/libwrap.a /usr/local/lib/libz.a /usr/local/lib/libcrypto.a"
	
configure then reported:

	OpenSSH has been configured with the following options:
			     User binaries: /usr/local/bin
			   System binaries: /usr/local/sbin
		       Configuration files: /etc/ssh
			   Askpass program: /usr/local/libexec/ssh-askpass
			      Manual pages: /usr/local/man/manX
				  PID file: /var/run
	  Privilege separation chroot path: /var/empty
		    sshd default user PATH: /usr/sbin:/usr/bsd:/sbin:/usr/bin:/usr/bin/X11::/usr/local/bin
	   (If PATH is set in /etc/default/login it will be used instead. If
	   used, ensure the path to scp is present, otherwise scp will not work.)
			    Manpage format: man
			       DNS support: no
			       PAM support: no
			 KerberosV support: no
			 Smartcard support: no
			     S/KEY support: no
		      TCP Wrappers support: yes
		      MD5 password support: no
	       IP address in $DISPLAY hack: no
		   Translate v4 in v6 hack: no
			  BSD Auth support: no
		      Random number source: OpenSSL internal ONLY

		      Host: mips-sgi-irix6.5
		  Compiler: cc
	    Compiler flags: -I/usr/local/include
	Preprocessor flags: -I/usr/local/include  -I/usr/local/include
	      Linker flags: -L/usr/local/lib -L/usr/local/lib -Wl,-rpath,/usr/local/lib
		 Libraries: -lwrap  -lz  /usr/local/lib/libwrap.a /usr/local/lib/libz.a /usr/local/lib/libcrypto.a -lgen -lcrypto

Please include me directly in any replies; I'm not a list member.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: beebe at math.utah.edu  -
- Department of Mathematics, 110 LCB        beebe at acm.org  beebe at computer.org -
- 155 S 1400 E RM 233                                                         -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------



From tom at arcot.com  Fri Sep 19 04:48:42 2003
From: tom at arcot.com (Tom Wu)
Date: Thu, 18 Sep 2003 11:48:42 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>
Message-ID: <3F69FE0A.3000201@arcot.com>

Ben Lindstrom wrote:
> 
> Personally, I'd rather not touch it until those companies make an official
> announcement clearing or granted.  And so far neither are forth coming.

It seems a bit naive to expect a company who patents technology A and 
wants to make money licensing it, to issue a statement saying technology 
B (which happens to workaround the patent) is not covered by their 
patents.  They have no obligation to and do not stand to profit from this.

And the comment about being "bit in the ass by the shark" seems a bit of 
a red herring fallacy, since other Open Source projects include support 
for algorithms that are known to be patented with royalties required 
(OpenSSL/IDEA) and allow the customer to compile/not-compile support in. 
  To date I have heard no reports of sharks.

If the OpenSSH group wants to adopt this kind of policy, despite the 
fact that this strengthens the hand of software patent holders and 
legitimizes the "DoS" technique of scaring people away from competing 
open/free technology with intimidating IP claims, that's their perogative.

Frankly, I see integrating SRP as a compile-time choice as the best 
compromise, so the customer can make this decision instead of having it 
forced on him/her.  It can be default enabled or disabled, at the 
discretion of the OpenSSH devs.  The code's already written, and it 
should be fairly easy to audit - I'd even volunteer to help in that regard.

Tom
-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From tom at arcot.com  Fri Sep 19 05:22:24 2003
From: tom at arcot.com (Tom Wu)
Date: Thu, 18 Sep 2003 12:22:24 -0700
Subject: SRP secure remote password authentication
In-Reply-To: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>
Message-ID: <3F6A05F0.7030209@arcot.com>

Ben Lindstrom wrote:
> 
> Personally, I'd rather not touch it until those companies make an official
> announcement clearing or granted.

Has Schnorr ever made an official announcement "clearing or granted" for 
DSA?

Tom
-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From admorten at umich.edu  Fri Sep 19 05:07:48 2003
From: admorten at umich.edu (Andrew Mortensen)
Date: Thu, 18 Sep 2003 15:07:48 -0400
Subject: sftp quote parsing broken in OpenSSH 3.7.1 portable
Message-ID: <647E948F-EA0B-11D7-A0A9-000A9590AFE2@umich.edu>

In 3.7.1 portable, sftp no longer correctly parses filenames enclosed 
in quotation marks. Below is an short transcript describing the bug.

sftp> ls
                     .                   ..                  
test_archive.tgz
sftp> get "test_archive.tgz"
Unterminated quote
sftp> get "test_archive.tgz" "test_archive.tgz"
Fetching /Users/admorten/testdir/test_archive.tgz to
/Users/admorten/testdir/test_archive.tgz      100%  773KB   0.0KB/s   
00:00
sftp> lls -l
total 780
-rw-r--r--    1 admorten staff      791161 Sep 18 14:49
sftp> get test_archive.tgz
Fetching /Users/admorten/testdir/test_archive.tgz to test_archive.tgz
/Users/admorten/testdir/test_archive.tgz      100%  773KB   0.0KB/s   
00:00
sftp> lls -l
total 1560
-rw-r--r--    1 admorten staff      791161 Sep 18 14:49
-rw-r--r--    1 admorten staff      791161 Sep 18 14:51 test_archive.tgz
sftp>

--

The problem is that the position counter in sftp-int.c is not 
incremented when the terminating quote is located. This causes the 
"Unterminated quote" error when no destination is given. When a 
destination is given, and is also wrapped in quotes, the characters 
between the terminating quote of the source and the beginning quote of 
the destination are taken to be the destination filename, resulting in 
writes, above, to a file named " ". This behavior can also be 
demonstrated using only three quotes:

sftp> get "test_archive.tgz"New_test_archive.tgz"
Fetching /Users/admorten/testdir/test_archive.tgz to 
New_test_archive.tgz
/Users/admorten/testdir/test_archive.tgz      100%  773KB   0.0KB/s   
00:00
sftp> lls -l
total 2340
-rw-r--r--    1 admorten staff      791161 Sep 18 14:49
-rw-r--r--    1 admorten staff      791161 Sep 18 14:57 
New_test_archive.tgz
-rw-r--r--    1 admorten staff      791161 Sep 18 14:51 test_archive.tgz
sftp>

Below is a patch fixing the increment:

--- sftp-int-orig.c     Thu Sep 18 13:52:40 2003
+++ sftp-int.c  Thu Sep 18 13:53:11 2003
@@ -351,6 +351,7 @@
                 for (i = j = 0; i <= strlen(cp); i++) {
                         if (cp[i] == quot) {    /* Found quote */
                                 (*path)[j] = '\0';
+                               i++;
                                 break;
                         }
                         if (cp[i] == '\0') {    /* End of string */


andrew



From Ladamiec at kentlaw.edu  Fri Sep 19 05:45:48 2003
From: Ladamiec at kentlaw.edu (Adamiec, Larry)
Date: Thu, 18 Sep 2003 14:45:48 -0500
Subject: make errors
Message-ID: <31CD8B871F233D4E9ACBFEE61566E3E00457B866@mail2.kentlaw.edu>

I am trying to upgrade my ssh to 3.7p1 on a Solaris 8 Enterprise 450 server.
I receive the following errors:

gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.
-I/usr/local/ssl/inc
lude  -I/usr/local/include -DSSHDIR=\"/usr/local/etc\"
-D_PATH_SSH_PROGRAM=\"/u
sr/local/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass
\"  -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"
-D_PATH_SSH_KEY_SIGN
=\"/usr/local/libexec/ssh-keysign\"  -D_PATH_SSH_PIDDIR=\"/var/run\"
-D_PATH_PR
IVSEP_CHROOT_DIR=\"/var/empty\"
-DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand
-helper\" -DHAVE_CONFIG_H -c cipher-aes.c
cipher-aes.c: In function `ssh_rijndael_init':
cipher-aes.c:50: warning: assignment from incompatible pointer type
cipher-aes.c: In function `ssh_rijndael_cbc':
cipher-aes.c:78: warning: assignment from incompatible pointer type
cipher-aes.c: In function `ssh_rijndael_cleanup':
cipher-aes.c:116: warning: assignment from incompatible pointer type
cipher-aes.c: In function `ssh_rijndael_iv':
cipher-aes.c:129: warning: assignment from incompatible pointer type
cipher-aes.c: In function `evp_rijndael':
cipher-aes.c:147: warning: assignment from incompatible pointer type
cipher-aes.c:148: warning: assignment from incompatible pointer type
cipher-aes.c:149: warning: assignment from incompatible pointer type
cipher-aes.c:151: structure has no member named `flags'
cipher-aes.c:151: `EVP_CIPH_CBC_MODE' undeclared (first use in this
function)
cipher-aes.c:151: (Each undeclared identifier is reported only once
cipher-aes.c:151: for each function it appears in.)
cipher-aes.c:151: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this
funct
ion)
cipher-aes.c:152: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this
func
tion)
cipher-aes.c:152: `EVP_CIPH_CUSTOM_IV' undeclared (first use in this
function)
*** Error code 1
make: Fatal error: Command failed for target `cipher-aes.o'

I have been unable to find a solution in the archives.  Any ideas?

Larry


From jorn.amundsen at itea.ntnu.no  Fri Sep 19 05:59:50 2003
From: jorn.amundsen at itea.ntnu.no (=?iso-8859-1?Q?=22J=F8rn_Aslak_Amundsen=22?=)
Date: Thu, 18 Sep 2003 21:59:50 +0200
Subject: bsd-cray.c r.1.12: multiple syntax errors
Message-ID: <1030918215950.ZM10337@mysil.itea.ntnu.no>

There appears to be multiple errors in release 1.12 of bsd-cray.c as released
with 3.7.1p1:

1) line 62: missing #include "defines.h" in front of #include "log.h", causing
compiler errors due to undefined cpp macro __attribute__(x).

2) line 185: declaration ``ia_user_t usent'' is not terminated with a
semicolon.

3) line 469: while loop ``while (valid_acct == -1) {'' ends in ``} else {'' at
line 533. This else statement should probably match the if statement beginning
at line 467.

In addition there is probably an error in the ``switch (acct_name[0]) {''
``default'' tag at line 502: there is a ``break'' at line 509, inside an if
statement, but no break to logically end the default tag.

Best Regards --J?rn Amundsen



From wendyp at cray.com  Fri Sep 19 06:03:09 2003
From: wendyp at cray.com (Wendy Palm)
Date: Thu, 18 Sep 2003 15:03:09 -0500
Subject: bsd-cray.c r.1.12: multiple syntax errors
References: <1030918215950.ZM10337@mysil.itea.ntnu.no>
Message-ID: <3F6A0F7D.8080805@cray.com>

yes, thanks.  i'm working on them.  there seem to be other problems too.
what arch are you working on?

Jxrn Aslak Amundsen wrote:

> There appears to be multiple errors in release 1.12 of bsd-cray.c as released
> with 3.7.1p1:
> 
> 1) line 62: missing #include "defines.h" in front of #include "log.h", causing
> compiler errors due to undefined cpp macro __attribute__(x).
> 
> 2) line 185: declaration ``ia_user_t usent'' is not terminated with a
> semicolon.
> 
> 3) line 469: while loop ``while (valid_acct == -1) {'' ends in ``} else {'' at
> line 533. This else statement should probably match the if statement beginning
> at line 467.
> 
> In addition there is probably an error in the ``switch (acct_name[0]) {''
> ``default'' tag at line 502: there is a ``break'' at line 509, inside an if
> statement, but no break to logically end the default tag.
> 
> Best Regards --Jxrn Amundsen
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From bukys at cs.rochester.edu  Fri Sep 19 04:26:13 2003
From: bukys at cs.rochester.edu (Liudvikas Bukys)
Date: Thu, 18 Sep 2003 14:26:13 -0400 (EDT)
Subject: privsep lost sometime between 3.5p1 and 3.7.1p1?
Message-ID: <200309181826.OAA09424@heart.cs.rochester.edu>

I haven't recompiled since 3.5p1.
I compile --with-privsep-user=nobody

* I observe that none of my processes is uid "nobody".

In addition, previously I had to disable privsep on either AIX or OSF1
(I forget which), this time it just worked.  I was thinking it was
because Progress Had Been Made.  Now, observing so many root processes,
I think it's because privsep is not actually in effect.

* Did a default change, or is there a bug in the code?  More later.



From dtucker at zip.com.au  Fri Sep 19 07:35:20 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 19 Sep 2003 07:35:20 +1000
Subject: make errors
References: <31CD8B871F233D4E9ACBFEE61566E3E00457B866@mail2.kentlaw.edu>
Message-ID: <3F6A2518.3259533D@zip.com.au>

"Adamiec, Larry" wrote:
> I am trying to upgrade my ssh to 3.7p1 on a Solaris 8 Enterprise 450 server.
> I receive the following errors:
[snip]
> cipher-aes.c:151: structure has no member named `flags'
> cipher-aes.c:151: `EVP_CIPH_CBC_MODE' undeclared (first use in this
> function)

There appear to be issues compiling against openssl-0.9.5, I suggest you
upgrade to openssl-0.9.7b.

You should also be using OpenSSH 3.7.1p1, it has additional fixes.

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



From dtucker at zip.com.au  Fri Sep 19 07:38:51 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 19 Sep 2003 07:38:51 +1000
Subject: openssh-3.7.1p1 distribution missing inet_ntoa.h header file
References: <CMM.0.92.0.1063908372.beebe@psi.math.utah.edu>
Message-ID: <3F6A25EA.7724638E@zip.com.au>

"Nelson H. F. Beebe" wrote:
> 
> A build of the new openssh-3.7.1p1 distribution failed on SGI IRIX 6.5
> because the inet_ntoa.h header file is not part of the openssh-3.7.1p1
> distribution:

IRIX issues here:
http://bugzilla.mindrot.org/show_bug.cgi?id=650
http://bugzilla.mindrot.org/show_bug.cgi?id=659

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



From tom at arcot.com  Fri Sep 19 08:24:13 2003
From: tom at arcot.com (Tom Wu)
Date: Thu, 18 Sep 2003 15:24:13 -0700
Subject: SRP Support
In-Reply-To: <Pine.BSO.4.44.0309180411360.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309180411360.842-100000@etoh.eviladmin.org>
Message-ID: <3F6A308D.3030301@arcot.com>

Ben Lindstrom wrote:
> 
> On Wed, 17 Sep 2003, Tom Wu wrote:
> 
> 
>>Ben,
>>
>>Can you be more specific about these "IP issues" you are referring to?
>>Is the IETF royalty-free statement insufficiently clear?  AFAIK,
>>Stanford *has* done precisely what you indicate by providing SRP in a
>>100% free and usable way, judging by adoption in other OSS software
>>projects.
>>
> 
> 
> It is not Stanford we worry about.  It is Lucent and others that claim
> that it may infringe on their patents.  You seem to forget about these
> claims.

Can you substantiate the assertion that Lucent has made this claim?  The 
IETF IPR statement from them certainly doesn't support it, since it is 
as clear a non-claim as you can get ("has not conducted a search").  If 
there is no supporting evidence, please retract the statement.

Tom
-- 
Tom Wu
Chief Security Architect
Arcot Systems
(408) 969-6124



From jnysen-openssh at triaptic.com.au  Fri Sep 19 09:39:43 2003
From: jnysen-openssh at triaptic.com.au (Jeremy Nysen)
Date: Fri, 19 Sep 2003 09:39:43 +1000
Subject: SRP secure remote password authentication
In-Reply-To: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309180417230.842-100000@etoh.eviladmin.org>
Message-ID: <3773335.1063964383@[192.168.1.14]>

--On Thursday, 18 September 2003 4:21 AM -0500 Ben Lindstrom <mouring at etoh.eviladmin.org> 
wrote:

>> If you look carefully at such "claims", you'll see that they are filled
>> with "may"s and "might"s, if in fact there is any claim being made at
>> all.  Unless there is some more substantiation that would allow one to
>> distinguish them from frivolous claims designed to cause marketplace
>> confusion/fear, I don't see why anyone, especially OSS projects
>> ostensibly opposed to precisely this kind of patent abuse, should grant
>> them any kind of legitimacy.
>
> NORMALLY companies don't say "may" or "might" unless there is a damn good
> reason.  Most business really do want to be upfront and honest (there are
> accepts to this rule).
>
> Personally, I'd rather not touch it until those companies make an official
> announcement clearing or granted.  And so far neither are forth coming.
> So I don't see a need to be the first to jump into the pool just to be bit
> in the ass by the shark
>
> - Ben

SRP has already been implemented in many other opensource and commercial tools including 
Tom Wu's SRPTelnet/FTP, the Cryptix SASL library, the GNU gnutls library, lsh, C-Kermit, 
Netterm, Anzioterm and I'm sure many others. So OpenSSH will definitely not be the first 
to jump into the pool.

Do you have a list of the companies (besides Stanford) that are claiming ownership over 
some aspect of SRP? If so, it might be worthwhile having the inventor of SRP, Tom Wu, 
contacting them for clarification.

I know when speaking to Lucent, IBM, and other entities with large patent portfolios, 
they usually make the blanket statement that you are likely to be infringing on their IP. 
This is because they have so many claims across so many patents that pretty much anything 
is at risk - and this includes simple things that most programmers would deem blatantly 
obvious and non-inventive.

Statements like the 'might's and 'may's of the above are par for the course and it is up 
to the implementer seek clarification to reduce the risks.

If you were to approach the same companies and ask if OpenSSH _without SRP_ is infringing 
any of their patents, you would likely get the same 'might/may's. This is why it is 
important to have someone seek further clarification, and not be scared off by the 'cover 
all bases' approach of patent holders (or abusers).

-- 
Jeremy



From djm at mindrot.org  Fri Sep 19 10:34:01 2003
From: djm at mindrot.org (Damien Miller)
Date: Fri, 19 Sep 2003 10:34:01 +1000
Subject: ssh-openbsd-2003091700 distribution missing gss_krb5_copy_ccache
In-Reply-To: <CMM.0.92.0.1063907739.beebe@psi.math.utah.edu>
References: <CMM.0.92.0.1063907739.beebe@psi.math.utah.edu>
Message-ID: <3F6A4EF9.2000000@mindrot.org>

Nelson H. F. Beebe wrote:
> Build attempts of the new ssh-openbsd-2003091700 distribution fail

Don't use that - it is just included for comparison. If you are using 
OpenBSD, use an official release. If you are using another OS, use a 
portable release.

-d




From bmcuppy at qwest.net  Fri Sep 19 12:15:49 2003
From: bmcuppy at qwest.net (bmcuppy at qwest.net)
Date: Thu, 18 Sep 2003 20:15:49 -0600 (MDT)
Subject: int64_t compile problem
Message-ID: <200309190215.h8J2FnkY026358@leadfoot.org>

I run Linux 2.2.21 w/ gcc version 2.7.2.3 and it does not even configure. I am interested
in a workaround on this. OpenSSH 3.61p1 configures and compiles but not 3.7.1p1.

Here is a "tail" of the configure below.

     Thx,
     Brad



checking for mode_t... yes
checking for struct sockaddr_storage... no
checking for struct sockaddr_in6... no
checking for struct in6_addr... no
checking for struct addrinfo... no
checking for struct timeval... yes
checking for struct timespec... no
OpenSSH requires int64_t support.  Contact your vendor or install
an alternative compiler (I.E., GCC) before continuing.



From dtucker at zip.com.au  Fri Sep 19 12:31:53 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 19 Sep 2003 12:31:53 +1000
Subject: int64_t compile problem
References: <200309190215.h8J2FnkY026358@leadfoot.org>
Message-ID: <3F6A6A99.CA160268@zip.com.au>

bmcuppy at qwest.net wrote:
> I run Linux 2.2.21 w/ gcc version 2.7.2.3 and it does not even configure. I am interested
> in a workaround on this. OpenSSH 3.61p1 configures and compiles but not 3.7.1p1.
[snip]
> OpenSSH requires int64_t support.  Contact your vendor or install
> an alternative compiler (I.E., GCC) before continuing.

OpenSSH now requires "long long" support.  Does your version of gcc
support that?  Also have a look in config.log for the error given where
the test failed, perhaps there's another reason for the failure.

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



From siegert at sfu.ca  Fri Sep 19 15:08:26 2003
From: siegert at sfu.ca (Martin Siegert)
Date: Thu, 18 Sep 2003 22:08:26 -0700
Subject: openssh-3.7.1p1 segfaults
In-Reply-To: <3F692003.7C8C9E9F@zip.com.au>
References: <20030917025230.GA18824@stikine.ucs.sfu.ca>
	<3F692003.7C8C9E9F@zip.com.au>
Message-ID: <20030919050826.GA25548@stikine.ucs.sfu.ca>

On Thu, Sep 18, 2003 at 01:01:23PM +1000, Darren Tucker wrote:
> Martin Siegert wrote:
> > the following problem occurs on Solaris 2.6. openssh-3.7p1 and openssh-3.7.1p1
> > both show the same behaviour.
> 
> I've had a closer look at the debugging here (pretty good info, BTW). 
> Your gdb+backtrace doesn't capture the problem, however, since the
> backtrace is from the privileged process and the SEGV appears to be
> occurring in the unprivileged child.
> 
> Can you try:
> 1) Reproducing the problem with "UsePrivilegeSeparation=no".
> If it happens with privsep=no, use gdb to get a backtrace and post it.

Yes, it happens with privsep=no.

> 2) If it doesn't happend with privsep, you need to try and debug the
> child, which can be tricky.  I suggest setting a breakpoint for sshd.c:650
> (just before the fork), then set "set follow-fork child", then continue. 
> Hopefully this will catch it so you can do a backtrace.

It seems to happen in the child that is forked in pthread_create in
auth-pam.c although I failed to used "set follow-fork child" - gdb
followed the parent nevertheless. I inserted a sleep(20) and attached
a second gdb to the child.

> I also suggest that if you haven't already, open a bug at
> bugzilla.mindrot.org (check for dupes first) as this looks like it might
> take a bit of work and it's easier to track if it's in bugzilla.

Did that: bug #687 with attachment #431.

-- 
Martin Siegert
Manager, Research Services
WestGrid Site Manager
Academic Computing Services                        phone: (604) 291-4691
Simon Fraser University                            fax:   (604) 291-4242
Burnaby, British Columbia                          email: siegert at sfu.ca
Canada  V5A 1S6



From peter.kohnke at nl.abnamro.com  Fri Sep 19 19:59:56 2003
From: peter.kohnke at nl.abnamro.com (peter.kohnke at nl.abnamro.com)
Date: Fri, 19 Sep 2003 11:59:56 +0200
Subject: /dev/random HP-UX 11.0
Message-ID: <OF0A1EDC42.844D7727-ONC1256DA6.0036CB8E@abnamro.com>

There is a /dev/random available now for HP-UX 11.0, see
http://www.josvisser.nl/hpux11-random/


Regards.
---------------------------------------------------------------------------
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorised
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change.
ABN AMRO Bank N.V. (including its group companies) shall not be liable for
the improper or incomplete transmission of the information contained in
this communication nor for any delay in its receipt or damage to your
system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that
the integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.
---------------------------------------------------------------------------







From des at des.no  Fri Sep 19 20:46:03 2003
From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Date: Fri, 19 Sep 2003 12:46:03 +0200
Subject: Weird behaviour
In-Reply-To: <20030917074136.GA32294@ipi.fi> (Osmo Paananen's message of
	"Wed, 17 Sep 2003 10:41:36 +0300")
References: <20030917074136.GA32294@ipi.fi>
Message-ID: <xzpn0d1rr84.fsf@dwp.des.no>

tempalias-openssh-list at ipi.fi (Osmo Paananen) writes:
> When I run ssh <hostname> and I enter invalid password I get six
> password prompts:

The first three are from PAM (through keyboard-interactive), the last
three from regular password authentication.  You should probably
disable either PAM or password authentication.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From des at des.no  Fri Sep 19 20:48:40 2003
From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Date: Fri, 19 Sep 2003 12:48:40 +0200
Subject: OpenSSH 3.7.1 compatibility problems on Linux
In-Reply-To: <Pine.LNX.4.44.0309171127300.31409-100000@shire.zend.office>
	(Stanislav
	Malyshev's message of "Wed, 17 Sep 2003 11:54:40 +0300 (IDT)")
References: <Pine.LNX.4.44.0309171127300.31409-100000@shire.zend.office>
Message-ID: <xzpisnprr3r.fsf@dwp.des.no>

Stanislav Malyshev <stas at zend.com> writes:
> With newer clients, using protocol 1 gives very strange greeting - first
> Password: 
> Response: 

This is PAM mediated through ssh1's TIS authentication feature.

> and then if password not given, <user>@<hostname>'s password:

This is regular ssh1 password authentication.

> Authentication with the latter never works, however works with the former.

If password authentication fails when you type the correct password,
you probably did something wrong at build time (like disable shadow
passwords).

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From jfh at cise.ufl.edu  Sat Sep 20 00:14:30 2003
From: jfh at cise.ufl.edu (James F.  Hranicky)
Date: Fri, 19 Sep 2003 10:14:30 -0400
Subject: Patch to restrict other auth methods from allowing root password
 authentication
Message-ID: <20030919101430.334ed2f8.jfh@cise.ufl.edu>

The attached patch restricts any keyboard-int method from allowing root
password authentication. Other methods (bsdauth? I don't even really know what
that is) could be added as well. 

FWIW, it appears that when using the "password" method the code in auth.c 
is never reached due to the following code in auth-passwd.c:

    #ifndef HAVE_CYGWIN
            if (pw && pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES)
                    ok = 0;
    #endif

meaning that this message in auth.c isn't logged in this case:

    logit("ROOT LOGIN REFUSED FROM %.200s", get_remote_ipaddr());

If no one has any problems with the patch I'll open a bugzilla PR.

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh at cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
                          About politics:
                     Don't worry about results
                   It's the thought that counts
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ossh-auth.c.patch.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030919/9dc1fed6/attachment.txt 

From Sergio.Gelato at astro.su.se  Sat Sep 20 03:07:34 2003
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Fri, 19 Sep 2003 19:07:34 +0200
Subject: configure fixes for Tru64 UNIX V4.0x
Message-ID: <20030919170732.GA4606@hanuman.astro.su.se>

1) Testing of uidswap.c on a Tru64 UNIX V4.0G PK4 (BL22) machine shows the
following defines to be required for correct uid changing semantics:

#define BROKEN_SETREGID 1
#define BROKEN_SETREUID 1
#define SETEUID_BREAKS_SETUID 1

Failure to fix these contributes to breaking privilege separation
(in a safe way: connections will fail while UsePrivilegeSeparation=yes,
thanks to permanently_set_uid()'s built-in sanity checks).

I don't know what the situation is on later (V5.x) releases of Tru64.
But for $host matching *-dec-osf4.0* the above settings should help.

2) The configure script as distributed with 3.7.1p1 has some cpp directives
with leading space before the #. The /usr/bin/cc bundled with Tru64 V4.0G
chokes on these unless an explicit -std option (e.g., cc -std1) is given.
Unfortunately, turning on this option creates other compilation problems.

It would be safest to make all cpp directives start with the # in column 1,
since that's more portable.

3) I'm also working on auth-sia.c fixes; will submit them once I'm satisfied
that they work. My interest is in the BSD and Heimdal (krb5) modules; I'm
unfortunately not in a position to test with the OSFC2 module.



From jbourne at hardrock.org  Sat Sep 20 03:49:07 2003
From: jbourne at hardrock.org (James Bourne)
Date: Fri, 19 Sep 2003 11:49:07 -0600 (MDT)
Subject: OpenSSH 3.7.1 compatibility problems on Linux
Message-ID: <Pine.LNX.4.44.0309190804180.22924-100000@cafe.hardrock.org>

> Stanislav Malyshev <stas at zend.com> writes:
> > With newer clients, using protocol 1 gives very strange greeting - first
> > Password: 
> > Response: 
> 
> This is PAM mediated through ssh1's TIS authentication feature.

IMHO, this should be a single prompt, not 2 seperate prompts and BTW, this
comes from the client NOT the server.  The "Response: " portion is actually
completely superfluous output...

Also, this only happens when connecting to a newer version server.  For
example, connecting to a server running 3.7.1p1 you get the second prompt,
but connecting to a server with a patched 3.1p1 (ala Red Hat) from the same
host using the same client, you get user at host's password: 

With other older clients (putty < 0.53) you can not authenticate at all!

> > and then if password not given, <user>@<hostname>'s password:
> 
> This is regular ssh1 password authentication.
> 
> > Authentication with the latter never works, however works with the former.
> 
> If password authentication fails when you type the correct password,
> you probably did something wrong at build time (like disable shadow
> passwords).

No actually, it is some incompatability with clients which do not support
"keyboard-interactive" authentication.

Was this intended breakage or accidental breakage?

Regards
James Bourne

> DES
> -- 
> Dag-Erling Sm?rgrav - des at des.no

-- 
James Bourne                  | Email:            jbourne at hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  




From des at des.no  Sat Sep 20 03:58:10 2003
From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Date: Fri, 19 Sep 2003 19:58:10 +0200
Subject: OpenSSH 3.7.1 compatibility problems on Linux
In-Reply-To: <Pine.LNX.4.44.0309190804180.22924-100000@cafe.hardrock.org>
	(James
	Bourne's message of "Fri, 19 Sep 2003 11:49:07 -0600 (MDT)")
References: <Pine.LNX.4.44.0309190804180.22924-100000@cafe.hardrock.org>
Message-ID: <xzpn0d0fyod.fsf@dwp.des.no>

James Bourne <jbourne at hardrock.org> writes:
> > Stanislav Malyshev <stas at zend.com> writes:
> > > With newer clients, using protocol 1 gives very strange greeting - first
> > > Password: 
> > > Response: 
> > This is PAM mediated through ssh1's TIS authentication feature.
> IMHO, this should be a single prompt, not 2 seperate prompts and BTW, this
> comes from the client NOT the server.  The "Response: " portion is actually
> completely superfluous output...

Then turn PAM off and stop whining.  The only way to implement PAM
authentication in ssh1 is to abuse the TIS authentication protocol, so
you have a choice between 1) PAM authentication that looks like crap
and 2) no PAM authentication.  Take your pick.

> Also, this only happens when connecting to a newer version server.  For
> example, connecting to a server running 3.7.1p1 you get the second prompt,
> but connecting to a server with a patched 3.1p1 (ala Red Hat) from the same
> host using the same client, you get user at host's password:

because 3.1 didn't have (proper) PAM support.

> > > Authentication with the latter never works, however works with the former.
> > If password authentication fails when you type the correct password,
> > you probably did something wrong at build time (like disable shadow
> > passwords).
> No actually, it is some incompatability with clients which do not support
> "keyboard-interactive" authentication.

There is no "keyboard-interactive" authentication in ssh1.  You need
to get better at that "reading" thing you've been hearing about.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From jbourne at hardrock.org  Sat Sep 20 05:03:07 2003
From: jbourne at hardrock.org (James Bourne)
Date: Fri, 19 Sep 2003 13:03:07 -0600 (MDT)
Subject: OpenSSH 3.7.1 compatibility problems on Linux
In-Reply-To: <xzpn0d0fyod.fsf@dwp.des.no>
Message-ID: <Pine.LNX.4.44.0309191250270.24765-200000@cafe.hardrock.org>

On Fri, 19 Sep 2003, Dag-Erling Sm?rgrav wrote:

> James Bourne <jbourne at hardrock.org> writes:
> > > This is PAM mediated through ssh1's TIS authentication feature.
> > IMHO, this should be a single prompt, not 2 seperate prompts and BTW, this
> > comes from the client NOT the server.  The "Response: " portion is actually
> > completely superfluous output...
> 
> Then turn PAM off and stop whining.  The only way to implement PAM
> authentication in ssh1 is to abuse the TIS authentication protocol, so

A little difficult when the only way to get LDAP support into ssh is by
using pam, and besides, *why* would anyone even contemplate using different
auth implementations for the various services on a server when you can use a
single framework to auth with?

> you have a choice between 1) PAM authentication that looks like crap
> and 2) no PAM authentication.  Take your pick.

Apply the attached patch and you don't have a problem with double prompts. 
Not saying it's the right solution but it works...

> > Also, this only happens when connecting to a newer version server.  For
> > example, connecting to a server running 3.7.1p1 you get the second prompt,
> > but connecting to a server with a patched 3.1p1 (ala Red Hat) from the same
> > host using the same client, you get user at host's password:
> 
> because 3.1 didn't have (proper) PAM support.

Fine, granted.

> 
> > > > Authentication with the latter never works, however works with the former.
> > > If password authentication fails when you type the correct password,
> > > you probably did something wrong at build time (like disable shadow
> > > passwords).
> > No actually, it is some incompatability with clients which do not support
> > "keyboard-interactive" authentication.
> 
> There is no "keyboard-interactive" authentication in ssh1.  You need
> to get better at that "reading" thing you've been hearing about.

No kidding, that's why those clients don't support keyboard-interactive...

There's no way in ssh1 to authenticate with a password then?  Doesn't make
much sense does it?  It was doing password authentication before with
version 1, now it can't and it breaks clients which can't do ssh v2?

What I'm trying to say is that for the authentication sequence you should
be able to pass the user and creds off to "pick your service"; pam, sia,
glibc getpwent/crypt/strcmp or what ever; and get back an ack or a nak to say
it's authenticated with ssh1 clients.  You shouldn't have to jump through
hoops to get those authenticated...  Otherwise, just drop the v1 support all
together because those clients will never work properly with this version,
but then SAY you're going to break it first please...

Regards
James

> 
> DES
> 

-- 
James Bourne                  | Email:            jbourne at hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  
-------------- next part --------------
--- openssh-3.7.1p1/sshconnect1.c.orig	Fri Sep 19 12:28:03 2003
+++ openssh-3.7.1p1/sshconnect1.c	Fri Sep 19 12:48:33 2003
@@ -376,7 +376,7 @@
 	int type, i;
 	u_int clen;
 	char prompt[1024];
-	char *challenge, *response;
+	char *challenge, *response, *ptr;
 
 	debug("Doing challenge response authentication.");
 
@@ -398,8 +398,13 @@
 		}
 		challenge = packet_get_string(&clen);
 		packet_check_eom();
-		snprintf(prompt, sizeof prompt, "%s%s", challenge,
-		    strchr(challenge, '\n') ? "" : "\nResponse: ");
+
+		if((ptr = strchr(challenge, '\n')) != NULL)
+			*ptr = '\0';
+		
+		snprintf(prompt, sizeof prompt, "%s",
+			strlen(challenge) > 1 ? challenge : "Response: ");
+		
 		xfree(challenge);
 		if (i != 0)
 			error("Permission denied, please try again.");

From des at des.no  Sat Sep 20 05:39:00 2003
From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Date: Fri, 19 Sep 2003 21:39:00 +0200
Subject: OpenSSH 3.7.1 compatibility problems on Linux
In-Reply-To: <Pine.LNX.4.44.0309191250270.24765-200000@cafe.hardrock.org>
	(James
	Bourne's message of "Fri, 19 Sep 2003 13:03:07 -0600 (MDT)")
References: <Pine.LNX.4.44.0309191250270.24765-200000@cafe.hardrock.org>
Message-ID: <xzpekycfu0b.fsf@dwp.des.no>

James Bourne <jbourne at hardrock.org> writes:
> On Fri, 19 Sep 2003, Dag-Erling Sm?rgrav wrote:
> > Then turn PAM off and stop whining.  The only way to implement PAM
> > authentication in ssh1 is to abuse the TIS authentication protocol, so
> A little difficult when the only way to get LDAP support into ssh is by
> using pam, and besides, *why* would anyone even contemplate using different
> auth implementations for the various services on a server when you can use a
> single framework to auth with?

Sorry, but PAM and ssh1 just don't go along very well.  One more
reason to use ssh2 instead.

>> you have a choice between 1) PAM authentication that looks like crap
>> and 2) no PAM authentication.  Take your pick.
> Apply the attached patch and you don't have a problem with double prompts. 
> Not saying it's the right solution but it works...

It's definitely not the right solution, as it breaks the cases where
the challenge is an actual challenge (e.g. pam_opie).

> > There is no "keyboard-interactive" authentication in ssh1.  You need
> > to get better at that "reading" thing you've been hearing about.
> No kidding, that's why those clients don't support keyboard-interactive...

This is not the problem here.  You're confusing two issues: one,
mentioned in this thread, is a failure of ssh1's regular password
authentication method, and the other, which was *not* mentioned in
this thread, is the lack of keyboard-interactive support in some
Windows-based ssh2 clients.

> There's no way in ssh1 to authenticate with a password then?  Doesn't make
> much sense does it?  It was doing password authentication before with
> version 1, now it can't and it breaks clients which can't do ssh v2?

ssh1 has a very limited range of authentication options.  One of those
is simple password authentication, another is TIS authentication
(which can also be used for any challenge/response authentication
scheme using only one challenge).

ssh2 has a wider range of options, including keyboard-interactive
which allows for longer exchanges of prompts and responses, and can
thus be used for challenge/response schemes where multiple challenges
may be required (such as PAM).

PAM can be shoe-horned into ssh1's TIS authentication method, but
it'll break if more than one challenge is needed (whether that is the
case depends on the contents of /etc/pam.conf or /etc/pam.d/sshd)

The original poster's problem, apart from the double prompt, seems to
be that PAM worked but ssh's builtin password authentication didn't,
for unknown reasons.  The fact that password authentication didn't
work for him is a completely separate problem from the whole PAM
issue.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From dtucker at zip.com.au  Sat Sep 20 10:52:51 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 20 Sep 2003 10:52:51 +1000
Subject: [Bug 692] Can't make OpenSSH-3.7.1p1 on OpenBSD 3.0
References: <20030919232737.9852927C188@shitei.mindrot.org>
Message-ID: <3F6BA4E3.4D6171E8@zip.com.au>

bugzilla-daemon at mindrot.org wrote:
> ------- Additional Comments From djm at mindrot.org  2003-09-20 09:27 -------
> Don't people check the bug list before adding new ones?

Maybe the default search should search closed bugs too?

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



From openssh-unix-dev at thewrittenword.com  Sat Sep 20 11:06:18 2003
From: openssh-unix-dev at thewrittenword.com (Albert Chin)
Date: Fri, 19 Sep 2003 20:06:18 -0500
Subject: configure fixes for Tru64 UNIX V4.0x
In-Reply-To: <20030919170732.GA4606@hanuman.astro.su.se>
References: <20030919170732.GA4606@hanuman.astro.su.se>
Message-ID: <20030920010618.GA64193@spuckler.il.thewrittenword.com>

On Fri, Sep 19, 2003 at 07:07:34PM +0200, Sergio Gelato wrote:
> 1) Testing of uidswap.c on a Tru64 UNIX V4.0G PK4 (BL22) machine shows the
> following defines to be required for correct uid changing semantics:
> 
> #define BROKEN_SETREGID 1
> #define BROKEN_SETREUID 1
> #define SETEUID_BREAKS_SETUID 1
> 
> Failure to fix these contributes to breaking privilege separation
> (in a safe way: connections will fail while UsePrivilegeSeparation=yes,
> thanks to permanently_set_uid()'s built-in sanity checks).
> 
> I don't know what the situation is on later (V5.x) releases of Tru64.
> But for $host matching *-dec-osf4.0* the above settings should help.

Noted by:
  http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106375128220498&w=2

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

-- 
albert chin (china at thewrittenword.com)



From dtucker at zip.com.au  Sat Sep 20 11:43:15 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 20 Sep 2003 11:43:15 +1000
Subject: [PATCH] permanently_set_uid fails on Cygwin :-(
References: <20030916145309.GR9981@cygbert.vinschen.de>
	<20030916145757.GS9981@cygbert.vinschen.de>
Message-ID: <3F6BB0B3.EC710BB6@zip.com.au>

Corinna Vinschen wrote:
> +#ifndef HAVE_CYGWIN
>         /* Try restoration of UID if changed (test clearing of saved uid) */
>         if (old_uid != pw->pw_uid &&
>             (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
>                 fatal("%s: was able to restore old [e]uid", __func__);
> +#endif

Is this OK, or should we have a define like "OS_CANT_DROP_PRIVS"?  Are
there any other OSes (that we support) to which this might apply?

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



From djm at mindrot.org  Sat Sep 20 15:22:57 2003
From: djm at mindrot.org (Damien Miller)
Date: Sat, 20 Sep 2003 05:22:57 -0000
Subject: [Bug 692] Can't make OpenSSH-3.7.1p1 on OpenBSD 3.0
In-Reply-To: <3F6BA4E3.4D6171E8@zip.com.au>
References: <20030919232737.9852927C188@shitei.mindrot.org>
	<3F6BA4E3.4D6171E8@zip.com.au>
Message-ID: <1064035216.9807.34.camel@sakura.mindrot.org>

On Sat, 2003-09-20 at 10:52, Darren Tucker wrote:
> bugzilla-daemon at mindrot.org wrote:
> > ------- Additional Comments From djm at mindrot.org  2003-09-20 09:27 -------
> > Don't people check the bug list before adding new ones?
> 
> Maybe the default search should search closed bugs too?

Maybe, the bug it was a dup of is still open.

-d




From stas at zend.com  Sun Sep 21 20:17:11 2003
From: stas at zend.com (Stanislav Malyshev)
Date: Sun, 21 Sep 2003 13:17:11 +0300 (IDT)
Subject: Solved: OpenSSH 3.7.1 compatibility problems on Linux
In-Reply-To: <Pine.LNX.4.44.0309171127300.31409-100000@shire.zend.office>
Message-ID: <Pine.LNX.4.44.0309211309260.2344-100000@shire.zend.office>

SM>> I have build OpenSSH 3.7.1p1 on Linux from src.rpm available for
SM>> download on the site, and after installation I have discovered that
SM>> this version of openssh has many compatibility problems with old and
SM>> third-party clients that previous versions did not have.  For
SM>> example:

With generous help of Yuri Nosyrev, I have found the cure for the problem:

The problem seems to be in the mechanism that governs password 
authentication and in the fact that I use md5-encoded passwords in 
/etc/shadow (must be standard RedHat setting since I have never changed 
anything there). 

The problem was solved by editing openssh.spec in the package before
building the RPM and adding --with-md5-passwords to the configure line
(around line 194 in original openssh.spec) then proceeding with building
the RPM as usual. Seems to make all the clients that didn't work
previously happy.

-- 
Stanislav Malyshev, Zend Products Engineer   
stas at zend.com  http://www.zend.com/ +972-3-6139665 ext.109






From dtucker at zip.com.au  Sun Sep 21 22:41:17 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 21 Sep 2003 22:41:17 +1000
Subject: OpenSSH 3.7p1, PrivSep, and Tru64 broken (sorry)
References: <20030916192744.GB1009987@hiwaay.net>
Message-ID: <3F6D9C6D.3F6DDAA0@zip.com.au>

Chris Adams wrote:
> This could also be a security problem for SIA authentication in general
> (any version of OpenSSH on Tru64, using PrivSep or not), as I wrote
> auth-sia.c to use setreuid() (per the Tru64 SIA documentation), so the
> saved UID carries forward there.
[snip]
(patch to auth-sia.c)
> -       if (setreuid(geteuid(), geteuid()) < 0)
> -               fatal("setreuid: %s", strerror(errno));
> +       uid = geteuid();
> +       if (setuid(0) < 0)
> +               fatal("setuid: %s", strerror(errno));
> +       if (setuid(uid) < 0)
> +               fatal("setuid: %s", strerror(errno));

Any reason not to use permanently_set_uid() here?

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



From dtucker at zip.com.au  Sun Sep 21 22:44:38 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 21 Sep 2003 22:44:38 +1000
Subject: SIGHUP fails to restart (3.6.1p2 -> 3.7p1)
References: <20030916203054.GA5278@vega.ipal.net>
Message-ID: <3F6D9D36.DE604993@zip.com.au>

Phil Howard wrote:
> I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have
> more than one daemon with separate executable images).  After upgrading from
> 3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing
> over the existing image), I do SIGHUP and get this message logged:

> 2. Was 3.6.1p2 broken in that respect?

Saving argv[0] was broken in 3.6.1p2 in some cases, it's since been fixed.

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



From dtucker at zip.com.au  Sun Sep 21 23:19:40 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 21 Sep 2003 23:19:40 +1000
Subject: Security Problem with OPENSSH 3.7.1
References: <1063998077.1154.51.camel@idefix>
Message-ID: <3F6DA56C.9FBBDF08@zip.com.au>

Thomas Boernert wrote:
> we've a big problem with the new version.
> we're using key authentication and in the
> sshd_config on the server ist "PasswordAuthentication no".
> in this case password authentication should be rejected.
> But in the new release it does'nt work !!!
> 
> i do
> # ssh server
> Enter passphrase for key '/home/tboernert/.ssh/id_rsa': [Now i press
> only Enter]
> -> normaly now should come ->
> Permission denied (publickey,keyboard-interactive).
> -> but it comes ->
> Password: :-( !!! and i can log in !!!!

It looks like you compiled with PAM and you're authenticating via
keyboard-interactive.  You probably need to set
ChallengeResponseAuthentication to "no", or turn of PAM ("UsePam no").

> The next strange problem, i've try login as root, but root login
> is disabeld and normaly now should come ->
> Permission denied (publickey,keyboard-interactive).
> -> but it comes ->
> Password: :-( !!! i can't login, but it can be a feature that the
> root login is globaly disabled in /etc/securetty !!! )

Set "PermitRootLogin no" if you want to disable root.

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



From Robert at 1internetdrive.com  Tue Sep 23 00:12:43 2003
From: Robert at 1internetdrive.com (Robert)
Date: Mon, 22 Sep 2003 14:12:43 +0000
Subject: Important Penis enlargement info
In-Reply-To: <9B380H71HF59127H@mindrot.org>
References: <9B380H71HF59127H@mindrot.org>
Message-ID: <H5BBGC4G69E8FIC2@1internetdrive.com>

Dear Customer,

I know what you think about this, but I finally got a result! You know
the size really matter and she was fucking happy! My dick was
so fucking big :) hehe

I bought this VRX fucking bottle at http://211.142.226.167:1794/cgi-bin/vrx.pl?123

Call me today :)

Jim

----------------------------------------------------------------------
You may remove your email at http://unsubscribe.vrx-penis-pills.com/




From dtucker at zip.com.au  Mon Sep 22 13:11:45 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 22 Sep 2003 13:11:45 +1000
Subject: openbsd-compat/port-aix.c fix for 3.7p1
References: <20030916151744.GA47276@spuckler.il.thewrittenword.com>
Message-ID: <3F6E6871.2BD295B3@zip.com.au>

Albert Chin wrote:
> 
> 1. Need a prototype for get_canonical_hostname().
> 2. -I.. is used to build port-aix.c so why not just #include
>    <xmalloc.h> rather than <../xmalloc.h>?

Thanks.  We did something like your patch, but used #include "xmalloc.h"
instead, since it's a local not a system header.

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



From dtucker at zip.com.au  Mon Sep 22 13:54:02 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 22 Sep 2003 13:54:02 +1000
Subject: Compiling issues in HPUX 11.11 for 3.7.1
References: <5711843190575E4C812FE6BA469A247002441AE6@toebe001.europe.nokia.com>
Message-ID: <3F6E725A.5731BB57@zip.com.au>

The openssh-unix-dev list is the correct place for questions about OpenSSH
Portable.

chi-leung.wong at nokia.com wrote:
> 
> Hi,
> 
>         Sorry to send you this issue but I haven't been able to find
> this issue anywhere on the net and we have tried to compile on a few
> HPUX 11.11 systems ending up with the same situation. We cheated so the
> compile works but does openssh function correctly? Below is a breakdown
> of the compile:
> 
> 1)      ./configure --prefix=/usr --sysconfdir=/etc/ssh
> --with-rsh=/usr/bin/oldremsh/remsh --with-tcp-wrappers
> --with-ipv4-default --with-ssl-dir=/opt/openssl --with-pam
> --with-ipaddr-display
> 
>                 goes smoothly
> 
> 2)      make
>                 compile errors: Nothing I do to change the configure
> options work. Even newest version of gcc does nothing.
> 
> gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./..
> -I/opt/openssl/include  -D_HPUX_SOURCE -D_XOPEN_SOURCE
> -D_XOPEN_SOURCE_EXTENDED=1 -DHAVE_CONFIG_H -c xcrypt.c
> In file included from /usr/include/sys/user.h:52,
>                  from
> /opt/apps/gcc-v3.0.1/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.0.1/include/rpc
> /auth.h:30,
>                  from /usr/include/rpc/rpc.h:61,
>                  from /usr/include/rpcsvc/nis.h:9,
>                  from /usr/include/prot.h:23,
>                  from xcrypt.c:35:
> /usr/include/machine/sys/setjmp.h:45: redefinition of `struct label_t'
> xcrypt.c: In function `xcrypt':
> xcrypt.c:70: warning: passing arg 1 of `bigcrypt' discards qualifiers
> from pointer target type
> xcrypt.c:70: warning: passing arg 2 of `bigcrypt' discards qualifiers
> from pointer target type
> make[1]: *** [xcrypt.o] Error 1
> make[1]: Leaving directory
> `/disks/tousers01/chiwong/openssh/openssh-3.7.1p1/openbsd-compat'
> make: *** [openbsd-compat/libopenbsd-compat.a] Error 2
> 
> 3)      manual compile of xcrypt.c and manual defining of LABEL_T
> (cheating). Couldn't find anywhere that LABEL_T was actaully being used.
> 
>         a)  cd openbsd-compat
>         b)  gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I..
> -I. -I./.. -I/opt/openssl/include -D_HPUX_SOURCE -D_XOPEN_SOURCE
> -D_XOPEN_SOURCE_EXTENDED=1 -DHAVE_CONFIG_H -D_LABEL_T -c xcrypt.c
> 
> 4)      make
>                 compiles fine
> 
> Now the question. Do you see any problems this would cause to the
> stability of functionality of openssh???
> 
> Thank you for your time and thanks a lot for such a great security
> tool!!!
> 
> Cheers,
> -Alan
> 
> -==============================-
> Alan Wong
> APAC PCPS Regional Manager
> Nokia-Japan Co., Ltd.
> +81 3 5759 7314
> -==============================-


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



From russell at coker.com.au  Mon Sep 22 15:25:50 2003
From: russell at coker.com.au (Russell Coker)
Date: Mon, 22 Sep 2003 15:25:50 +1000
Subject: Fwd: privsep in ssh
Message-ID: <200309221525.50087.russell@coker.com.au>

It was suggested to me that I forward this message to you.

----------  Forwarded Message  ----------

Subject: privsep in ssh
Date: Fri, 19 Sep 2003 12:22
From: Russell Coker <russell at coker.com.au>
To: SE Linux <selinux at tycho.nsa.gov>
Cc: Colin Watson <cjwatson at debian.org>

#ifdef DISABLE_FD_PASSING
        if (1) {
#else
        if (authctxt->pw->pw_uid == 0 || options.use_login) {
#endif
                /* File descriptor passing is broken or root login */
                monitor_apply_keystate(pmonitor);
                use_privsep = 0;
                return;
        }

When browsing the ssh source I noticed the above in sshd.c.  It appears from
 a casual inspection that we should change this and remove the check for
 pw_uid == 0.  Logging in as root in SE Linux does not mean that we have full
 administrative privs, so I think that we should have privsep enabled all the
 time.

I have compiled a sshd with privsep for root logins and it seems to work
 fine.

I have attached the patch against ssh 3.6.1p2, I expect that the same thing
would be necessary in 3.7.1 and the same patch probably applies (but I
haven't checked).

I believe that this patch is worthy of inclusion in the standard distribution
of ssh.  The only drawback is that it uses a small amount of extra CPU power
for root logins, and on systems such as SE Linux it provides security
benefits.

Anyone who wants to use the SE Linux PAM module for sshd probably wants this.

--
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: text/x-diff
Size: 381 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030922/c1a58cda/attachment.bin 

From djm at shitei.mindrot.org  Mon Sep 22 15:44:58 2003
From: djm at shitei.mindrot.org (Damien Miller)
Date: Mon, 22 Sep 2003 15:44:58 +1000 (EST)
Subject: Fwd: privsep in ssh
In-Reply-To: <200309221525.50087.russell@coker.com.au>
References: <200309221525.50087.russell@coker.com.au>
Message-ID: <Pine.BSO.4.56.0309221540340.22107@shitei.mindrot.org>



> #ifdef DISABLE_FD_PASSING
>         if (1) {
> #else
>         if (authctxt->pw->pw_uid == 0 || options.use_login) {
> #endif

I think we should change this test to something like:

if (!ALWAYS_POSTAUTH_PRIVSEP && 
    (authctxt->pw->pw_uid == 0 || options.use_login || 
    NEVER_POSTAUTH_PRIVSEP)) {

Then we can set NEVER_POSTAUTH_PRIVSEP and ALWAYS_POSTAUTH_PRIVSEP (to 1) 
in autoconf as appropriate.

Comments?

-d



From russell at coker.com.au  Mon Sep 22 15:55:39 2003
From: russell at coker.com.au (Russell Coker)
Date: Mon, 22 Sep 2003 15:55:39 +1000
Subject: Fwd: privsep in ssh
In-Reply-To: <Pine.BSO.4.56.0309221540340.22107@shitei.mindrot.org>
References: <200309221525.50087.russell@coker.com.au>
	<Pine.BSO.4.56.0309221540340.22107@shitei.mindrot.org>
Message-ID: <200309221555.39553.russell@coker.com.au>

On Mon, 22 Sep 2003 15:44, Damien Miller wrote:
> > #ifdef DISABLE_FD_PASSING
> >         if (1) {
> > #else
> >         if (authctxt->pw->pw_uid == 0 || options.use_login) {
> > #endif
>
> I think we should change this test to something like:
>
> if (!ALWAYS_POSTAUTH_PRIVSEP &&
>     (authctxt->pw->pw_uid == 0 || options.use_login ||
>     NEVER_POSTAUTH_PRIVSEP)) {
>
> Then we can set NEVER_POSTAUTH_PRIVSEP and ALWAYS_POSTAUTH_PRIVSEP (to 1)
> in autoconf as appropriate.
>
> Comments?

Sounds reasonable to me.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From djm at shitei.mindrot.org  Mon Sep 22 15:55:34 2003
From: djm at shitei.mindrot.org (Damien Miller)
Date: Mon, 22 Sep 2003 15:55:34 +1000 (EST)
Subject: Fwd: privsep in ssh
In-Reply-To: <200309221555.39553.russell@coker.com.au>
References: <200309221525.50087.russell@coker.com.au>
	<Pine.BSO.4.56.0309221540340.22107@shitei.mindrot.org>
	<200309221555.39553.russell@coker.com.au>
Message-ID: <Pine.BSO.4.56.0309221554480.22107@shitei.mindrot.org>



On Mon, 22 Sep 2003, Russell Coker wrote:

> On Mon, 22 Sep 2003 15:44, Damien Miller wrote:
> > > #ifdef DISABLE_FD_PASSING
> > >         if (1) {
> > > #else
> > >         if (authctxt->pw->pw_uid == 0 || options.use_login) {
> > > #endif
> >
> > I think we should change this test to something like:
> >
> > if (!ALWAYS_POSTAUTH_PRIVSEP &&
> >     (authctxt->pw->pw_uid == 0 || options.use_login ||
> >     NEVER_POSTAUTH_PRIVSEP)) {
> >
> > Then we can set NEVER_POSTAUTH_PRIVSEP and ALWAYS_POSTAUTH_PRIVSEP (to 1)
> > in autoconf as appropriate.
> >
> > Comments?
> 
> Sounds reasonable to me.

How can we unambiguously identify SELinux at ./configure time? Does it 
return a different platform string?

-d



From russell at coker.com.au  Mon Sep 22 16:33:29 2003
From: russell at coker.com.au (Russell Coker)
Date: Mon, 22 Sep 2003 16:33:29 +1000
Subject: Fwd: privsep in ssh
In-Reply-To: <Pine.BSO.4.56.0309221554480.22107@shitei.mindrot.org>
References: <200309221525.50087.russell@coker.com.au>
	<200309221555.39553.russell@coker.com.au>
	<Pine.BSO.4.56.0309221554480.22107@shitei.mindrot.org>
Message-ID: <200309221633.29674.russell@coker.com.au>

On Mon, 22 Sep 2003 15:55, Damien Miller wrote:
> > > Then we can set NEVER_POSTAUTH_PRIVSEP and ALWAYS_POSTAUTH_PRIVSEP (to
> > > 1) in autoconf as appropriate.
> > >
> > > Comments?
> >
> > Sounds reasonable to me.
>
> How can we unambiguously identify SELinux at ./configure time? Does it
> return a different platform string?

Detecting SE Linux at ./configure time is wrong.  Using a non-SE machine to 
compile programs for a SE machine (or the other way around) is quite common.

We can detect SE Linux at run time, but there seems little point in that.  The 
issue of privsep for root doesn't seem to add enough cost to make it worth 
such efforts to avoid it.

Having an option for ./configure that a distribution vendor can use to 
determine this is reasonable.  But I'm still in favour of just using a flag 
in sshd_config to determine whether privsep should be used.  I think that if 
the sshd_config says to use privsep then it should be used regardless of what 
user you are logging in as or the OS that's running on the machine.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From skeleten at shillest.net  Mon Sep 22 19:31:29 2003
From: skeleten at shillest.net (Norihiko Murase)
Date: Mon, 22 Sep 2003 18:31:29 +0900
Subject: MANY obsolete descriptions in INSTALL
Message-ID: <20030922183129.8cf498%skeleten@shillest.net>

Hi, develop members:


When I read the document INSTALL in order to install
OpenSSH-3.7.1p1, I noticed that MANY obsolete descriptions
do remain still now.

(1) The configure options '--with-kerberos4' and
    '--with-afs' were obsoleted because Kerberos IV support
    and AFS support were removed; however the descriptions
    remain still now.
(2) The configure option '--with-kerberos5' for Kerberos V
    support is missing.
(3) The configure option '--with-ipv4-default' was
    obsoleted; however the description remains in the
    document Ver.1.56. (It is deleted in Ver.1.58, which is
    attached to snapshot-20030921.)
(4) The option '--enable-gnome-askpass' is not described in
    the output of "configure --help". If this option had
    been already obsoleted, the description in INSTALL
    should be deleted, too.
(5) CFLAGS="-a" LDFLAGS="-s" LIBS="-lx" ./configure
    is equivalent to
    ./configure --with-cflags="-a" --with-ldflags="-s" --with-libs="-lx"


The following is the patch against *Ver.1.58* for solving
the above problems (1), (2), (4), and (5).

---(cut here)---
--- INSTALL_1.58	Fri Sep 19 07:05:24 2003
+++ INSTALL	Mon Sep 22 17:53:45 2003
@@ -104,8 +104,4 @@
 --with-pam enables PAM support.
 
---enable-gnome-askpass will build the GNOME passphrase dialog. You
-need a working installation of GNOME, including the development
-headers, for this to work.
-
 --with-prngd-socket=/some/file allows you to enable EGD or PRNGD 
 support and to specify a PRNGd socket. Use this if your Unix lacks 
@@ -127,14 +123,9 @@
 Integration Architecture.  The default for OSF1 machines is enable.
 
---with-kerberos4=PATH will enable Kerberos IV support. You will need
+--with-kerberos5=PATH will enable Kerberos V support. You will need
 to have the Kerberos libraries and header files installed for this
 to work. Use the optional PATH argument to specify the root of your
 Kerberos installation.
 
---with-afs=PATH will enable AFS support. You will need to have the
-Kerberos IV and the AFS libraries and header files installed for this
-to work.  Use the optional PATH argument to specify the root of your
-AFS installation. AFS requires Kerberos support to be enabled.
-
 --with-skey=PATH will enable S/Key one time password support. You will 
 need the S/Key libraries and header files installed for this to work.
@@ -175,6 +166,14 @@
 can specify these as environment variables before running ./configure.
 For example:
-
-CFLAGS="-O -m486" LDFLAGS="-s" LIBS="-lrubbish" LD="/usr/foo/ld" ./configure
+  CFLAGS="-O -m486" LDFLAGS="-s" LIBS="-lrubbish" ./configure
+Also, you can do as the values of the options to the configure script.
+For example:
+  ./configure --with-cflags="-O -m486" \
+              --with-ldflags="-s"      \
+              --with-libs="-lrubbish"
+
+The entire list of the options to the configure script is available
+from the output of
+  ./configure --help
 
 3. Configuration
---(cut here)---
# The new version in which the above patch is applied is
# defined as 1.59 in the below...


It may be better for the order of the options mentioned in
the INSTALL document to correspond with that of the output
of './configure --help'. I put the new version (1.60) at
http://skeleten.shillest.net/tmp/INSTALL_1.60

# 1.58: The version attached in snapshot-20030921
# 1.59: The above patch was applied against 1.58
# 1.60: The same orders (changed from 1.59)


I hope the INSTALL document is updated before the new release.


---
Norihiko Murase <skeleten at shillest.net>



From skeleten at shillest.net  Mon Sep 22 20:09:16 2003
From: skeleten at shillest.net (Norihiko Murase)
Date: Mon, 22 Sep 2003 19:09:16 +0900
Subject: Unnecessary configure option '--(enable|disable)-lastlog'
Message-ID: <20030922190916.af8c4e%skeleten@shillest.net>

Hi, develop members:

When I checked the output of './configure --help', I noticed
that the '--(enable|disable)-lastlog' option was
unnecessary any longer. This option can be replaced by the
'--with(out)-lastlog'.

Thanks.

---
Norihiko Murase <skeleten at shillest.net>



From SCHNEIDEV at aol.com  Mon Sep 22 22:15:53 2003
From: SCHNEIDEV at aol.com (SCHNEIDEV at aol.com)
Date: Mon, 22 Sep 2003 08:15:53 EDT
Subject: (no subject)
Message-ID: <1a8.19b7c20a.2ca041f9@aol.com>

UNIVERSAL BROADBAND ACCESS. www.broadcom.com


From mweiser at fachschaft.imn.htwk-leipzig.de  Tue Sep 23 00:04:03 2003
From: mweiser at fachschaft.imn.htwk-leipzig.de (Michael Weiser)
Date: Mon, 22 Sep 2003 16:04:03 +0200 (CEST)
Subject: openssh on NeXTstep
Message-ID: <Pine.LNX.4.58.0309221600440.13284@heinz.dinsnail.net>

Hi all,

I've been running OpenSSH portable on NeXTstep 3.3 since version 
2.5.something with no/little problems. 3.7.1p1 still compiles fine but 
sshd hangs at startup. I've tried to debug it but when stepping through 
sshd using gdb it segfaults in mysignal in bsd-misc.c instead of hanging. 
Before I dig any deeper into this I'd like to know if there's anybody else 
running openssh who is perhaps not/as well experiencing these problems. Is 
hanging/segfaulting in mysignal perhaps experienced on other platforms as 
well?
-- 
bye, Michael
a dinsnail email - best viewed using heinz



From mehdi.lavasani at connectinternetsolutions.com  Mon Sep 22 23:30:31 2003
From: mehdi.lavasani at connectinternetsolutions.com (M. Lavasani)
Date: Mon, 22 Sep 2003 14:30:31 +0100 (BST)
Subject: compile error on HPUX
Message-ID: <200309221330.h8MDUVV03891@quioch.cis>

Hi

I am trying to compile openssh-3.7.1p1 on HPUX version 11.00 and 11.22.

I ran the configure with "--with-dns" option ( I know it is still in 
experimental stage ). The configure ran ok and in compile time I got the error:

gmake[1]: Entering directory `/net/ia64/lavasani/ssh/openssh-3.7.1p1/openssh-3.7.1p1/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./..  -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -DHAVE_CONFIG_H -c xcrypt.c
In file included from /usr/include/prot.h:24,
                 from xcrypt.c:35:
/usr/include/rpcsvc/nis.h:79: error: parse error before numeric constant

I realised that when the prolem has been caused by:

#define DNS 1 


in config.h


I 've changed all the instance of "DNS" to "_DNS", and It compled ok.

--- config.h.in 2003-09-22 12:34:55.000000000 +0100
+++ config.h.in.cln     2003-09-16 22:38:13.000000000 +0100
@@ -417,7 +417,7 @@
 #undef LOCKED_PASSWD_SUBSTR
 
 /* Define if DNS support is to be activated */
-#undef _DNS
+#undef DNS


Obviously I had to change any instance of the DNS in the following files also:

./openbsd-compat/getrrsetbyname.c
./openbsd-compat/getrrsetbyname.h
./configure.cln
./acconfig.h
./dns.c
./dns.h
./readconf.c
./ssh-keygen.c
./sshconnect.c


Has anyone had this problem??

Thanks



			__Mehdi
PS: I am not part of the list, can you email me directly please.



From mehdi.lavasani at connectinternetsolutions.com  Mon Sep 22 23:30:31 2003
From: mehdi.lavasani at connectinternetsolutions.com (M. Lavasani)
Date: Mon, 22 Sep 2003 14:30:31 +0100 (BST)
Subject: compile error on HPUX
Message-ID: <200309221330.h8MDUVV03891@quioch.cis>

Hi

I am trying to compile openssh-3.7.1p1 on HPUX version 11.00 and 11.22.

I ran the configure with "--with-dns" option ( I know it is still in 
experimental stage ). The configure ran ok and in compile time I got the error:

gmake[1]: Entering directory `/net/ia64/lavasani/ssh/openssh-3.7.1p1/openssh-3.7.1p1/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./..  -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -DHAVE_CONFIG_H -c xcrypt.c
In file included from /usr/include/prot.h:24,
                 from xcrypt.c:35:
/usr/include/rpcsvc/nis.h:79: error: parse error before numeric constant

I realised that when the prolem has been caused by:

#define DNS 1 


in config.h


I 've changed all the instance of "DNS" to "_DNS", and It compled ok.

--- config.h.in 2003-09-22 12:34:55.000000000 +0100
+++ config.h.in.cln     2003-09-16 22:38:13.000000000 +0100
@@ -417,7 +417,7 @@
 #undef LOCKED_PASSWD_SUBSTR
 
 /* Define if DNS support is to be activated */
-#undef _DNS
+#undef DNS


Obviously I had to change any instance of the DNS in the following files also:

./openbsd-compat/getrrsetbyname.c
./openbsd-compat/getrrsetbyname.h
./configure.cln
./acconfig.h
./dns.c
./dns.h
./readconf.c
./ssh-keygen.c
./sshconnect.c


Has anyone had this problem??

Thanks



			__Mehdi
PS: I am not part of the list, can you email me directly please.



From mouring at etoh.eviladmin.org  Tue Sep 23 00:16:05 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 22 Sep 2003 09:16:05 -0500 (CDT)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.LNX.4.58.0309221600440.13284@heinz.dinsnail.net>
Message-ID: <Pine.BSO.4.44.0309220911330.842-100000@etoh.eviladmin.org>


NeXT platform has really not been directly supported since 3.5. =)  I'm
surprised it even compiles since I've had to pull harddrives from my next
box to do SCSI card testing under my Ultra 10 sparc box.

Not sure why it would crash in mysignal()  that code had been pretty
constant.

As for 'other platforms'.. NeXT and SonyOS both use sigact.[ch] for signal
management (IIRC, It's been over a year and half since I've looked at that
bit =), and I doubt anyone else (well, maybe older SCO boxes) even gets it
compiled in.

- Ben

On Mon, 22 Sep 2003, Michael Weiser wrote:

> Hi all,
>
> I've been running OpenSSH portable on NeXTstep 3.3 since version
> 2.5.something with no/little problems. 3.7.1p1 still compiles fine but
> sshd hangs at startup. I've tried to debug it but when stepping through
> sshd using gdb it segfaults in mysignal in bsd-misc.c instead of hanging.
> Before I dig any deeper into this I'd like to know if there's anybody else
> running openssh who is perhaps not/as well experiencing these problems. Is
> hanging/segfaulting in mysignal perhaps experienced on other platforms as
> well?
> --
> bye, Michael
> a dinsnail email - best viewed using heinz
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From ed at UDel.Edu  Tue Sep 23 03:29:50 2003
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Sep 2003 13:29:50 -0400 (EDT)
Subject: Problem with non-interactive shells on Sol8 with 3.7.1p1
Message-ID: <Pine.SOL.4.58L.0309221314150.3319@mahler.udel.edu>

We recently started upgrading OpenSSH on our Sol8 systems and we've run
into a problem were we can run commands on a remote system since we
installed 3.7.1p1.  The debug output from sshd is attached below.  We use
PAM in our environment, and have since 2.9.9p2.  I think most of the
systems were running 3.4p1 prior installing 3.7.1p1 and they were working
- the only thing we replaced was OpenSSH itself, without changing any
PAM/system configuration, etc.

The strange part is that it's only some of our Sol8 systems that don't
work (appears somewhat random which do/don't).  For machines that work,
they always work ("ssh sys1 ls -al" works all the time).  For those that
don't work, they never work ("ssh sys1 ls -al" exits with no output).

Interactive logins are unaffected.  Of course, "scp", etc., also don't
work on the affected systems.  Other Solaris systems running a Solaris
version other than 8 are don't seem to have the problem with
non-interactive commands.

>From the debug log on an affected system, it appears to be a problem
encountered in do_pam_session().  I searched some old messages and there
was talk about some TTY stuff that appears to have been taken out around
3.6.1p2, but nothing that came right out and stated, "Yep, this is a
problem we see on Solaris <version>".

Has anyone else seen this?  Any ideas how to trouble-shoot and solve this
problem?  Meanwhile, we'll keep digging...

Thanks,

	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services

Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection from 128.175.2.36 port 47865
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection from 128.175.2.36 port 47865
Sep 22 13:12:39 ldap1.udel.edu sshd[21118]: [ID 800047 local4.debug] debug1: Forked child 21223.
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p1
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Enabling compatibility mode for protocol 2.0
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Local version string SSH-1.99-OpenSSH_3.7.1p1
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEXINIT sent
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEXINIT received
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: kex: client->server aes128-cbc hmac-md5 none
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: kex: server->client aes128-cbc hmac-md5 none
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_NEWKEYS sent
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: expecting SSH2_MSG_NEWKEYS
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_NEWKEYS received
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: KEX done
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: userauth-request for user ed service ssh-connection method none
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: attempt 0 failures 0
Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: initializing for "ed"
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: setting PAM_RHOST to "polycut.nss.udel.edu"
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(4)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: setting PAM_TTY to "ssh"
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(3)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Failed none for ed from 128.175.2.36 port 47865 ssh2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Failed none for ed from 128.175.2.36 port 47865 ssh2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: userauth-request for user ed service ssh-connection method publickey
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: attempt 1 failures 1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: test whether pkalg/pkblob are acceptable
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: matching key found: file /home/ldap1/usra/ed/.ssh/authorized_keys2, line 1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Postponed publickey for ed from 128.175.2.36 port 47865 ssh2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Postponed publickey for ed from 128.175.2.36 port 47865 ssh2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: userauth-request for user ed service ssh-connection method publickey
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: attempt 2 failures 1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: matching key found: file /home/ldap1/usra/ed/.ssh/authorized_keys2, line 1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: ssh_rsa_verify: signature correct
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 997726 local4.debug] pam_acct_mgmt()
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_roles.so.1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_acct_mgmt
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_projects.so.1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_acct_mgmt
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_acct_mgmt
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Accepted publickey for ed from 128.175.2.36 port 47865 ssh2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Accepted publickey for ed from 128.175.2.36 port 47865 ssh2
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Entering interactive session for SSH2.
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_init_dispatch_20
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: input_session_request
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: channel 0: new [server-session]
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_new: init
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_new: session 0
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_open: channel 0
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_open: session 0: link with channel 0
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_input_channel_open: confirm session
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_input_channel_req: channel 0 request exec reply 0
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_by_channel: session 0 channel 0
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_input_channel_req: session 0 req exec
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(5)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: establishing credentials
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 942022 local4.debug] pam_setcred()
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_setcred
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 859314 local4.debug] pam_set_item(5)
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 750988 local4.debug] pam_open_session()
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 265225 local4.debug] load_function: successful load of pam_sm_open_session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 770223 local4.debug] pam_open_session: error Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Received SIGCHLD.
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_by_pid: pid 21224
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_exit_message: session 0 channel 0 pid 21224
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_exit_message: release channel 0
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_close: session 0 pid 21224
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: channel 0: free: server-session, nchannels 1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection closed by 128.175.2.36
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection closed by 128.175.2.36
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Closing connection to 128.175.2.36
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Closing connection to 128.175.2.36
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: cleanup
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(5)
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 942022 local4.debug] pam_setcred()
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 833576 local4.debug] pam_setcred: error Permission denied
Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 690057 local4.debug] pam_end(): status = Success



From ed at UDel.Edu  Tue Sep 23 03:36:53 2003
From: ed at UDel.Edu (Ed Phillips)
Date: Mon, 22 Sep 2003 13:36:53 -0400 (EDT)
Subject: Problem with non-interactive shells on Sol8 with 3.7.1p1
In-Reply-To: <Pine.SOL.4.58L.0309221314150.3319@mahler.udel.edu>
References: <Pine.SOL.4.58L.0309221314150.3319@mahler.udel.edu>
Message-ID: <Pine.SOL.4.58L.0309221335400.3583@mahler.udel.edu>

One more item that might help:

"ssh -t sys1 ls -al" seems to work on the affected systems.  So it would
seem there's something going wrong on these systems whenever sshd isn't
allocating a tty...

	Ed

On Mon, 22 Sep 2003, Ed Phillips wrote:

> We recently started upgrading OpenSSH on our Sol8 systems and we've run
> into a problem were we can run commands on a remote system since we
> installed 3.7.1p1.  The debug output from sshd is attached below.  We use
> PAM in our environment, and have since 2.9.9p2.  I think most of the
> systems were running 3.4p1 prior installing 3.7.1p1 and they were working
> - the only thing we replaced was OpenSSH itself, without changing any
> PAM/system configuration, etc.
>
> The strange part is that it's only some of our Sol8 systems that don't
> work (appears somewhat random which do/don't).  For machines that work,
> they always work ("ssh sys1 ls -al" works all the time).  For those that
> don't work, they never work ("ssh sys1 ls -al" exits with no output).
>
> Interactive logins are unaffected.  Of course, "scp", etc., also don't
> work on the affected systems.  Other Solaris systems running a Solaris
> version other than 8 are don't seem to have the problem with
> non-interactive commands.
>
> From the debug log on an affected system, it appears to be a problem
> encountered in do_pam_session().  I searched some old messages and there
> was talk about some TTY stuff that appears to have been taken out around
> 3.6.1p2, but nothing that came right out and stated, "Yep, this is a
> problem we see on Solaris <version>".
>
> Has anyone else seen this?  Any ideas how to trouble-shoot and solve this
> problem?  Meanwhile, we'll keep digging...
>
> Thanks,
>
> 	Ed
>
> Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
> Systems Programmer III, Network and Systems Services
>
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection from 128.175.2.36 port 47865
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection from 128.175.2.36 port 47865
> Sep 22 13:12:39 ldap1.udel.edu sshd[21118]: [ID 800047 local4.debug] debug1: Forked child 21223.
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p1
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Enabling compatibility mode for protocol 2.0
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Local version string SSH-1.99-OpenSSH_3.7.1p1
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEXINIT sent
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEXINIT received
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: kex: client->server aes128-cbc hmac-md5 none
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: kex: server->client aes128-cbc hmac-md5 none
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
> Sep 22 13:12:39 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_NEWKEYS sent
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: expecting SSH2_MSG_NEWKEYS
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: SSH2_MSG_NEWKEYS received
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: KEX done
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: userauth-request for user ed service ssh-connection method none
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: attempt 0 failures 0
> Sep 22 13:12:40 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: initializing for "ed"
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: setting PAM_RHOST to "polycut.nss.udel.edu"
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(4)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: setting PAM_TTY to "ssh"
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(3)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Failed none for ed from 128.175.2.36 port 47865 ssh2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Failed none for ed from 128.175.2.36 port 47865 ssh2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: userauth-request for user ed service ssh-connection method publickey
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: attempt 1 failures 1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: test whether pkalg/pkblob are acceptable
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: matching key found: file /home/ldap1/usra/ed/.ssh/authorized_keys2, line 1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Postponed publickey for ed from 128.175.2.36 port 47865 ssh2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Postponed publickey for ed from 128.175.2.36 port 47865 ssh2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: userauth-request for user ed service ssh-connection method publickey
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: attempt 2 failures 1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: temporarily_use_uid: 16476/10 (e=0/1)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: trying public key file /home/ldap1/usra/ed/.ssh/authorized_keys2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: matching key found: file /home/ldap1/usra/ed/.ssh/authorized_keys2, line 1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Found matching RSA key: fd:fe:6f:ce:e8:26:bb:2e:58:65:1e:8c:12:00:92:16
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: restore_uid: 0/1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: ssh_rsa_verify: signature correct
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 997726 local4.debug] pam_acct_mgmt()
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_roles.so.1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_acct_mgmt
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_projects.so.1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_acct_mgmt
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_acct_mgmt
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Accepted publickey for ed from 128.175.2.36 port 47865 ssh2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Accepted publickey for ed from 128.175.2.36 port 47865 ssh2
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Entering interactive session for SSH2.
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_init_dispatch_20
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: input_session_request
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: channel 0: new [server-session]
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_new: init
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_new: session 0
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_open: channel 0
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_open: session 0: link with channel 0
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_input_channel_open: confirm session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: server_input_channel_req: channel 0 request exec reply 0
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_by_channel: session 0 channel 0
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_input_channel_req: session 0 req exec
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(5)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: establishing credentials
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 942022 local4.debug] pam_setcred()
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 265225 local4.debug] load_function: successful load of pam_sm_setcred
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 859314 local4.debug] pam_set_item(5)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 750988 local4.debug] pam_open_session()
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 265225 local4.debug] load_function: successful load of pam_sm_open_session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 770223 local4.debug] pam_open_session: error Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21224]: [ID 800047 local4.crit] fatal: PAM: pam_open_session(): Can not make/remove entry for session
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: Received SIGCHLD.
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_by_pid: pid 21224
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_exit_message: session 0 channel 0 pid 21224
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_exit_message: release channel 0
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: session_close: session 0 pid 21224
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: channel 0: free: server-session, nchannels 1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection closed by 128.175.2.36
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Connection closed by 128.175.2.36
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Closing connection to 128.175.2.36
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.info] Closing connection to 128.175.2.36
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 800047 local4.debug] debug1: PAM: cleanup
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 859314 local4.debug] pam_set_item(5)
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 942022 local4.debug] pam_setcred()
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 305314 local4.debug] load_modules: /usr/lib/security/pam_unix.so.1
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 833576 local4.debug] pam_setcred: error Permission denied
> Sep 22 13:12:41 ldap1.udel.edu sshd[21223]: [ID 690057 local4.debug] pam_end(): status = Success
>

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services



From david.r.steiner at Dartmouth.EDU  Tue Sep 23 06:10:29 2003
From: david.r.steiner at Dartmouth.EDU (David R. Steiner)
Date: Mon, 22 Sep 2003 16:10:29 -0400
Subject: Explanation Please: No more AFS support
Message-ID: <a06002006bb9505ca51ca@[129.170.18.88]>

Please excuse me if this was discussed before and I missed it but 
could someone please explain why AFS support was dropped from OpenSSH 
3.7.1p1?

Since OpenAFS does not seem to show any signs of going away, it seems 
like this kind of puts those of us who use AFS in the position of 
having to apply patches to and maintain our own source tree for 
3.6.1p1 whenever a change is made if we want to continue to use 
OpenSSH and AFS on our machines. This strategy is working for the 
moment but as new versions of OpenSSH are released, I can foresee a 
point when this is no longer going to be viable.

I am not trying to start any wars here but I am curious as to the 
rationale behind decision.

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



From kuenne at rentec.com  Tue Sep 23 08:00:38 2003
From: kuenne at rentec.com (Karsten =?iso-8859-1?q?K=FCnne?=)
Date: Mon, 22 Sep 2003 18:00:38 -0400
Subject: problems with non-interactive shells on Solaris 8 with 3.7.1p1
Message-ID: <200309221800.40050.kuenne@rentec.com>

In case you have problems with 3.7.1p1 on Solaris 8 and have the following 
messages logged:

fatal: PAM: pam_open_session(): Can not make/remove entry for session

Try installing Sun patch 111659-07 or later (or some later patch which 
incorporates this patch). This fixed it for me, YMMV.

-- 
Karsten.

'Nobody Expects the Spanish Inquisition'
    -Monty Python



From ralf.hack at gxn.net  Tue Sep 23 19:10:05 2003
From: ralf.hack at gxn.net (Ralf Hack (new ext. 1216))
Date: Tue, 23 Sep 2003 10:10:05 +0100
Subject: 3.7.1p1 appears to break pam session.
Message-ID: <a0521020ebb95b9450a88@[192.168.2.131]>

Hi,
	I am running FreeBSD 4.7 and openssh 3.7.1p1. I have enabled 
PAM usage and indeed, I can use PAM for authentication purposes. 
Since configure does login_cap.h, the preprocessor is side stepping 
do_pam_session()
altogether in session.c:do_setusercontext().

	Here is my patch for session.c. My understanding about 
portability issues is rather limited. I would very much appreciate if 
you guys could check this and verify that I am not introducing more 
problems with this. So far this works for me.

--- session.c   Tue Sep 23 10:14:47 2003
+++ session.c.orig      Tue Sep 23 10:04:02 2003
@@ -1240,15 +1240,6 @@
  # ifdef __bsdi__
                 setpgid(0, 0);
  # endif
-# ifdef USE_PAM
-               /*
-                * PAM session wants to be run for LOGIN_CAP systems too!
-                */
-               if (options.use_pam) {
-                       do_pam_session();
-                       do_pam_setcred(0);
-               }
-# endif /* USE_PAM */
                 if (setusercontext(lc, pw, pw->pw_uid,
                     (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) {
                         perror("unable to set user context");



From christian.bolliger at id.unizh.ch  Tue Sep 23 19:47:26 2003
From: christian.bolliger at id.unizh.ch (Christian Bolliger)
Date: Tue, 23 Sep 2003 09:47:26 -0000
Subject: openssh-3.7.1p1 -- openbsd-compat/inet_ntoa.h missing
Message-ID: <1064310646.16069.8.camel@zipcchb>

Hello
I just installed openssh-3.7.1p1 on IRIX64 6.5 04100802 IP27. 
The compilation failed since the header file 
openbsd-compat/inet_ntoa.h 
was missing. I downloaded the package from different sources including
ftp.openbsd.org, there was no difference.

Since inet_ntoa.c has not been changed, copying the inet_ntoa.h from
openssh-3.6p1 fixed the problem. 

The package should be fixed anyway.

Many thanks for your valuable work.

Christian Bolliger
-- 
=============================================================================
Christian Bolliger                 
IT Services                      | http://www.id.unizh.ch/
Central Systems / Biocomputing   | http://www.bio.unizh.ch/
University of  Zuerich           | E-Mail:
christian.bolliger at id.unizh.ch
Winterthurerstr. 190             | Tel: +41 (0)1 63 56775
CH-8057 Zuerich; Switzerland     | Fax: +41 (0)1 63 54505
My PGP-Keys:
http://www.id.unizh.ch/publications/ueber/visitenk/chribo.html



From cjwatson at debian.org  Tue Sep 23 21:30:36 2003
From: cjwatson at debian.org (Colin Watson)
Date: Tue, 23 Sep 2003 12:30:36 +0100
Subject: 3.7.1p1 appears to break pam session.
In-Reply-To: <a0521020ebb95b9450a88@[192.168.2.131]>
Message-ID: <E1A1lNM-0003Wk-00@chiark.greenend.org.uk>

Ralf Hack wrote:
>	I am running FreeBSD 4.7 and openssh 3.7.1p1. I have enabled 
>PAM usage and indeed, I can use PAM for authentication purposes. 
>Since configure does login_cap.h, the preprocessor is side stepping 
>do_pam_session() altogether in session.c:do_setusercontext().

FWIW I noticed the same symptoms on Debian GNU/Linux unstable, but
hadn't had time to track it down. I'll try your patch next time I have a
chance.

-- 
Colin Watson                                       [cjwatson at debian.org]



From mweiser at fachschaft.imn.htwk-leipzig.de  Tue Sep 23 22:33:20 2003
From: mweiser at fachschaft.imn.htwk-leipzig.de (Michael Weiser)
Date: Tue, 23 Sep 2003 14:33:20 +0200 (CEST)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.BSO.4.44.0309220911330.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309220911330.842-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.58.0309231427230.18394@heinz.dinsnail.net>

On Mon, 22 Sep 2003, Ben Lindstrom wrote:

> NeXT platform has really not been directly supported since 3.5. =)  I'm
> surprised it even compiles since I've had to pull harddrives from my next
> box to do SCSI card testing under my Ultra 10 sparc box.
That's a pity - I've got two NeXTstep m68k boxes here which run quite
smoothly.  If it's only access to a machine it's perhaps a possibility to
run NeXTstep i386 in VMware or bochs. I used it in both and they work
quite alright, although the NE2000 emulation of bochs doesn't work with
the NeXTstep 3.3 NE2000 driver.

> Not sure why it would crash in mysignal()  that code had been pretty
> constant.
It still seems to have something to do with it since sshd comes up and 
complains about unfound keys when I comment the signal define in 
bsd-misc.h like:

/* #define signal(a,b) mysignal(a,b) */

What is the actual purpose of mysignal()? Is it safe to just remove that 
define? I've diff'ed openssh 3.7.1p1 against 3.6.1p2 and found that in 
some places mysignal was replaced by signal and in others the other way 
round. Also the above define was added. *confused shrug*
-- 
Micha



From djm at cvs.openbsd.org  Tue Sep 23 22:39:50 2003
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 23 Sep 2003 06:39:50 -0600 (MDT)
Subject: Portable OpenSSH 3.7.1p2 released
Message-ID: <200309231239.h8NCdocm023804@cvs.openbsd.org>

Portable OpenSSH 3.7.1p2  has just been released. It will be available 
from the mirrors listed at http://www.openssh.com/portable.html shortly.

Please note that this is a release to address issues in the portable 
version only. The items mentioned below do not affect the OpenBSD 
version.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu

Security Changes:
=================

  Portable OpenSSH version 3.7p1 and 3.7.1p1 contain multiple 
  vulnerabilities in the new PAM authentication code. At least one of
  these bugs is remotely exploitable (under a non-standard 
  configuration, with privsep disabled).

  OpenSSH 3.7.1p2 fixes these bugs. Please note that these bugs do not 
  exist in OpenBSD's releases of OpenSSH.

Changes since OpenSSH 3.7.1p1:
==============================

* This release disables PAM by default. To enable it, set "UsePAM yes" in 
  sshd_config. Due to complexity, inconsistencies in the specification and
  differences between vendors' PAM implementations we recommend that PAM 
  be left disabled in sshd_config unless there is a need for its use. 
  Sites using only public key or simple password authentication usually 
  have little need to enable PAM support.

* This release now requires zlib 1.1.4 to build correctly. Previous 
  versions have security problems.

* Fix compilation for versions of OpenSSL before 0.9.6. Some cipher modes 
  are not supported for older OpenSSL versions.

* Fix compilation problems on systems with a missing or lacking inet_ntoa()
  function.

* Workaround problems related to unimplemented or broken setresuid/setreuid 
  functions on several platforms.

* Fix compilation on older OpenBSD systems.

* Fix handling of password-less authentication (PermitEmptyPasswords=yes) 
  that has not worked since the 3.7p1 release.

Checksums:
==========

- MD5 (openssh-3.7.1p2.tar.gz) = 61cf5b059938718308836d00f6764a94


Reporting Bugs:
===============

- please read http://www.openssh.com/report.html
  and http://bugzilla.mindrot.org/

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



From djm at cvs.openbsd.org  Tue Sep 23 22:40:25 2003
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 23 Sep 2003 06:40:25 -0600 (MDT)
Subject: Multiple PAM vulnerabilities in portable OpenSSH
Message-ID: <200309231240.h8NCePCd025947@cvs.openbsd.org>

Subject: Portable OpenSSH Security Advisory: sshpam.adv

This document can be found at:  http://www.openssh.com/txt/sshpam.adv

1. Versions affected:

        Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple 
        vulnerabilities in the new PAM code. At least one of these bugs 
        is remotely exploitable (under a non-standard configuration, 
        with privsep disabled). 

        The OpenBSD releases of OpenSSH do not contain this code and 
        are not vulnerable. Older versions of portable OpenSSH are not 
        vulnerable.

2. Solution:

        Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM 
        support ("UsePam no" in sshd_config). 

        Due to complexity, inconsistencies in the specification and 
        differences between vendors' PAM implementations we recommend 
        that PAM be left disabled in sshd_config unless there is a need 
        for its use. Sites only using public key or simple password 
        authentication usually have little need to enable PAM support.



From mouring at etoh.eviladmin.org  Wed Sep 24 00:24:29 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 23 Sep 2003 09:24:29 -0500 (CDT)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.LNX.4.58.0309231427230.18394@heinz.dinsnail.net>
Message-ID: <Pine.BSO.4.44.0309230911190.842-100000@etoh.eviladmin.org>



On Tue, 23 Sep 2003, Michael Weiser wrote:

> On Mon, 22 Sep 2003, Ben Lindstrom wrote:
>
> > NeXT platform has really not been directly supported since 3.5. =)  I'm
> > surprised it even compiles since I've had to pull harddrives from my next
> > box to do SCSI card testing under my Ultra 10 sparc box.

> That's a pity - I've got two NeXTstep m68k boxes here which run quite
> smoothly.  If it's only access to a machine it's perhaps a possibility to
> run NeXTstep i386 in VMware or bochs. I used it in both and they work
> quite alright, although the NE2000 emulation of bochs doesn't work with
> the NeXTstep 3.3 NE2000 driver.
>

I have a nice 25mhz Slab sitting on a desk at home.. Access has never been
an issue.  It is willingness to baby the platform.  At 25mhz a build
takes around 15 - 20 minutes (assuming all goes well).  And it seems to
get worse. =)

I love my NeXT box.. I actually fell in love with the OS back seven years
ago when we placed our aging Sun Stations w/ Intel NeXT in a college lab I
maintained (they are all Linux boxes now).


> > Not sure why it would crash in mysignal()  that code had been pretty
> > constant.
> It still seems to have something to do with it since sshd comes up and
> complains about unfound keys when I comment the signal define in
> bsd-misc.h like:
>
> /* #define signal(a,b) mysignal(a,b) */
>
> What is the actual purpose of mysignal()? Is it safe to just remove that
> define? I've diff'ed openssh 3.7.1p1 against 3.6.1p2 and found that in
> some places mysignal was replaced by signal and in others the other way
> round. Also the above define was added. *confused shrug*

No we can't remove it.  It actually is there for a very good reason.
Partly to solve issues with different singal() versions.  mysignal() is
suppose to be an extremely strict version of signal().  In a few spots of
our code we have needed it.  Between 3.6.1 and now we decided to use
mysignal() by default for every signal() in our tree.

I knew it would cause some breakage on platforms. =)  Just was not sure
when/where.

It would be nice to know what signal() location it is causing the
behavior.  Maybe a backtrace from gdb and server side -ddd reports.

If it is tripping over a single instance.. Then we can handle it for that
instance.

It also be nice to see a copy of your config.

I am planning on getting a new "NeXT" laptop in a few months.. Oddly
enough they mispelt the name of it.. It has "Apple" written on it.

- Ben



From jason at devrandom.org  Wed Sep 24 01:24:34 2003
From: jason at devrandom.org (Jason McCormick)
Date: Tue, 23 Sep 2003 11:24:34 -0400
Subject: RPM Packages for 3.7.1p2
Message-ID: <200309231124.34638.jason@devrandom.org>

My personal archive of RPM packages for RedHat 7.1 - 7.3, Redhat 9.0 and 
Redhat Advanced Server 2.1 are updated for OpenSSH 3.7.1p2 at 
http://bamboo.lexi.com/openssh

-- Jason



From lcars at infis.univ.trieste.it  Wed Sep 24 02:27:41 2003
From: lcars at infis.univ.trieste.it (Andrea Barisani)
Date: Tue, 23 Sep 2003 18:27:41 +0200
Subject: Portable OpenSSH 3.7.1p2 released
In-Reply-To: <200309231239.h8NCdocm023804@cvs.openbsd.org>
References: <200309231239.h8NCdocm023804@cvs.openbsd.org>
Message-ID: <20030923162741.GA26709@sole.infis.univ.trieste.it>

> 
> Changes since OpenSSH 3.7.1p1:
> ==============================
> 
> * This release disables PAM by default. To enable it, set "UsePAM yes" in 
>   sshd_config. Due to complexity, inconsistencies in the specification and
>   differences between vendors' PAM implementations we recommend that PAM 
>   be left disabled in sshd_config unless there is a need for its use. 
>   Sites using only public key or simple password authentication usually 
>   have little need to enable PAM support.

Hi,

right now PAM is widely use with the pam_listfile.so module to grant access
for specific users only from certain hosts (es. root is allowed only from
10.1.7.1)

I beleive that this is not possible with AllowUsers and DenyUsers unless some
! (negation) operator is introduced in the configuration. That's because

AllowUsers * root at 10.1.7.1

or other variations won't work.

Do you think would be possible adding such feature or is there any other way
I'm missing for doing that :).

Bye and thanks

--
------------------------------------------------------------
INFIS Network Administrator & Security Officer         .*. 
Department of Physics       - University of Trieste    /V\
lcars at infis.univ.trieste.it - PGP Key 0x8E21FE82      (/ \)
----------------------------------------------------  (   )
"How would you know I'm mad?" said Alice.             ^^-^^
"You must be,'said the Cat,'or you wouldn't have come here."
------------------------------------------------------------



From samuel at ait.nrl.navy.mil  Wed Sep 24 03:56:48 2003
From: samuel at ait.nrl.navy.mil (Gary Samuel)
Date: Tue, 23 Sep 2003 13:56:48 -0400
Subject: inet_ntoaHi,
Message-ID: <3F708960.7020408@ait.nrl.navy.mil>

Hi,
Trying to compile under IRIX 6.5.21 and keep getting the error " 
inet_ntoa.c:46: inet_ntoa.h: No such file or directory". Looked at the 
source code and found that unlike previous versions of the ssh software, 
inet_ntoa.h was not included. How do I get the software to compile?
Thanks for your help,

-- 
Gary Samuel 




From mouring at etoh.eviladmin.org  Wed Sep 24 04:00:27 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 23 Sep 2003 13:00:27 -0500 (CDT)
Subject: inet_ntoaHi,
In-Reply-To: <3F708960.7020408@ait.nrl.navy.mil>
Message-ID: <Pine.BSO.4.44.0309231300200.842-100000@etoh.eviladmin.org>



Use 3.7.1p2 release.

- Ben

On Tue, 23 Sep 2003, Gary Samuel wrote:

> Hi,
> Trying to compile under IRIX 6.5.21 and keep getting the error "
> inet_ntoa.c:46: inet_ntoa.h: No such file or directory". Looked at the
> source code and found that unlike previous versions of the ssh software,
> inet_ntoa.h was not included. How do I get the software to compile?
> Thanks for your help,
>
> --
> Gary Samuel
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From lbecke at mchsi.com  Wed Sep 24 06:25:18 2003
From: lbecke at mchsi.com (lbecke at mchsi.com)
Date: Tue, 23 Sep 2003 20:25:18 +0000
Subject: OpenSSH 3.7.1p2-pwexp24.patch
Message-ID: <20030923202155.BEEC727C189@shitei.mindrot.org>

For those of us who do require / use PAM, will the expired password patch be 
ported to 3.7.1p2?

If so, any kind of estimate on when?

Thanks



From mariox19 at mac.com  Wed Sep 24 06:42:14 2003
From: mariox19 at mac.com (Mario Diana)
Date: Tue, 23 Sep 2003 16:42:14 -0400
Subject: sshd 3.7p1 dies on MacOSX
Message-ID: <69C0C66C-EE06-11D7-B031-003065E88CAC@mac.com>

Sorry to bust in on the list, but I have been trying to get OpenSSH to 
work for several days on OS X, rather than wait for the update (which 
is now released). I suffered a lot of frustration, tried many fixes on 
my own, searched Google, and only today managed to find the thread on 
this list.

Though Apple's update has got me a patched SSH package, I would like to 
solve the problem in the source distribution I compiled and installed 
(in an alternate location).

I know this is a developers list, but if someone would be kind enough 
to help me, I would appreciate it. I realize the patch has to do with 
the configure.ac file, but I'm unsure as to how to proceed. Where in 
the file would I insert this patch?Is the patch to be inserted all in 
one place, or are the lines broken up and inserted in various places in 
the file?

I really have never done this much "tweaking" to get something to work, 
but I'm eager to learn something more about UNIX.

Cordially,

Mario Diana

P.S.

I may need you to "spell it out" a little more than you are used to 
doing among one another, though maybe all that means is you would have 
to tell me where to cut and paste. Thank you.



From dtucker at zip.com.au  Wed Sep 24 07:05:26 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 24 Sep 2003 07:05:26 +1000
Subject: OpenSSH 3.7.1p2-pwexp24.patch
References: <20030923202155.BEEC727C189@shitei.mindrot.org>
Message-ID: <3F70B596.1FFAED1C@zip.com.au>

lbecke at mchsi.com wrote:
> 
> For those of us who do require / use PAM, will the expired password patch be
> ported to 3.7.1p2?
> 
> If so, any kind of estimate on when?

I've just ported the patch to 3.7.1p2 and the new patch is at [1].  I
haven't done any testing of it, however the parts that didn't apply were
trivial.

[1] http://www.zip.com.au/~dtucker/openssh/

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



From tim at multitalents.net  Wed Sep 24 07:27:23 2003
From: tim at multitalents.net (Tim Rice)
Date: Tue, 23 Sep 2003 14:27:23 -0700 (PDT)
Subject: sshd 3.7p1 dies on MacOSX
In-Reply-To: <69C0C66C-EE06-11D7-B031-003065E88CAC@mac.com>
References: <69C0C66C-EE06-11D7-B031-003065E88CAC@mac.com>
Message-ID: <Pine.UW2.4.58.0309231425240.6477@ou8.int.multitalents.net>

On Tue, 23 Sep 2003, Mario Diana wrote:

> Though Apple's update has got me a patched SSH package, I would like to 
> solve the problem in the source distribution I compiled and installed 
> (in an alternate location).

Download 3.7.1p2
The problem has been fixed.

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




From djm at mindrot.org  Wed Sep 24 07:53:23 2003
From: djm at mindrot.org (Damien Miller)
Date: Tue, 23 Sep 2003 21:53:23 -0000
Subject: OpenSSH 3.7.1p2-pwexp24.patch
In-Reply-To: <20030923202155.BEEC727C189@shitei.mindrot.org>
References: <20030923202155.BEEC727C189@shitei.mindrot.org>
Message-ID: <1064353837.21615.127.camel@sakura.mindrot.org>

On Wed, 2003-09-24 at 06:25, lbecke at mchsi.com wrote:
> For those of us who do require / use PAM, will the expired password patch be 
> ported to 3.7.1p2?
> 
> If so, any kind of estimate on when?

I see that Darren has already replied. 

We will probably be adding expired password changing support to the CVS
version shortly (after we all catch up on our sleep). We'd appreciate
help in testing it when it goes in.

-d




From carson at taltos.org  Wed Sep 24 08:25:31 2003
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 23 Sep 2003 18:25:31 -0400
Subject: (Trivial oddity) Old version in Portable CVS HEAD
Message-ID: <142640000.1064355931@taltos.ny.ficc.gs.com>

I assume this is a branching issue, but in case anyone else notices, CVS 
HEAD currently declares itself as OpenSSH_3.7.1p1, not OpenSSH_3.7.1p2. The 
3.7.1p2 tarball has the correct version.

It'll be interesting to watch my logs and see who tries to exploit my 
server based on banner version ;-)

-- 
Carson



From djm at mindrot.org  Wed Sep 24 08:30:47 2003
From: djm at mindrot.org (Damien Miller)
Date: Tue, 23 Sep 2003 22:30:47 -0000
Subject: (Trivial oddity) Old version in Portable CVS HEAD
In-Reply-To: <142640000.1064355931@taltos.ny.ficc.gs.com>
References: <142640000.1064355931@taltos.ny.ficc.gs.com>
Message-ID: <1064356082.21615.145.camel@sakura.mindrot.org>

On Wed, 2003-09-24 at 08:25, Carson Gaspar wrote:
> I assume this is a branching issue, but in case anyone else notices, CVS 
> HEAD currently declares itself as OpenSSH_3.7.1p1, not OpenSSH_3.7.1p2. The 
> 3.7.1p2 tarball has the correct version.

fixed - thanks for reminding me.

-d



From cjwatson at debian.org  Wed Sep 24 08:56:29 2003
From: cjwatson at debian.org (Colin Watson)
Date: Tue, 23 Sep 2003 23:56:29 +0100
Subject: PAM sessions and conversation functions
Message-ID: <20030923225629.GB27077@riva.ucam.org>

In OpenSSH 3.6.1p2, pam_open_session() ran with a conversation function,
do_pam_conversation(), that fed text to the client. In OpenSSH 3.7.1p2,
this is no longer the case: session modules run with a conversation
function that just returns PAM_CONV_ERR. This means that simple session
modules whose job involves printing text on the user's terminal no
longer work: pam_lastlog, pam_mail, and pam_motd.

Can somebody explain to me why this change was made (as part of the
FreeBSD PAM merge, apparently), or if it was a mistake? I realize that
session modules are now run as root, but I'd have thought that modules
should be trusted code and don't need to have their output sanitized.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]



From Darren.Moffat at Sun.COM  Wed Sep 24 10:12:22 2003
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Tue, 23 Sep 2003 17:12:22 -0700 (PDT)
Subject: PAM sessions and conversation functions
In-Reply-To: <20030923225629.GB27077@riva.ucam.org>
Message-ID: <Pine.GSO.4.44.0309231711090.847-100000@localhost>

On Tue, 23 Sep 2003, Colin Watson wrote:

> In OpenSSH 3.6.1p2, pam_open_session() ran with a conversation function,
> do_pam_conversation(), that fed text to the client. In OpenSSH 3.7.1p2,
> this is no longer the case: session modules run with a conversation
> function that just returns PAM_CONV_ERR. This means that simple session
> modules whose job involves printing text on the user's terminal no
> longer work: pam_lastlog, pam_mail, and pam_motd.

For the "password" authentication that is perfectly correct behaviour
because there is no where to send that output at that time.

For keyboard-interactive you can print the messages so that can have a
"real" conversation function.

--
Darren J Moffat



From hwolff at uolinc.com  Wed Sep 24 08:25:32 2003
From: hwolff at uolinc.com (Hugo Leonardo Wolff de Souza)
Date: Tue, 23 Sep 2003 19:25:32 -0300
Subject: (no subject)
Message-ID: <9076D31467800141870B38CCEDF8F37008E423@saurus>



--
Hugo Souza - Tecnologia/UOL Inc.
hwolff at uolinc.com


From mouring at etoh.eviladmin.org  Wed Sep 24 11:15:44 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 23 Sep 2003 20:15:44 -0500 (CDT)
Subject: (Trivial oddity) Old version in Portable CVS HEAD
In-Reply-To: <1064356082.21615.145.camel@sakura.mindrot.org>
Message-ID: <Pine.BSO.4.44.0309232014440.842-100000@etoh.eviladmin.org>



On 24 Sep 2003, Damien Miller wrote:

> On Wed, 2003-09-24 at 08:25, Carson Gaspar wrote:
> > I assume this is a branching issue, but in case anyone else notices, CVS
> > HEAD currently declares itself as OpenSSH_3.7.1p1, not OpenSSH_3.7.1p2. The
> > 3.7.1p2 tarball has the correct version.
>
> fixed - thanks for reminding me.
>

Well.. Technically --head is not 3.7.1p2.

If you look at the CVS tree you'll notice that p2 has a few less patches
(like a lot of the fatal() clean up).  So to claim it is p2 is kinda a
falsity.

- Ben



From djm at shitei.mindrot.org  Wed Sep 24 11:18:11 2003
From: djm at shitei.mindrot.org (Damien Miller)
Date: Wed, 24 Sep 2003 11:18:11 +1000 (EST)
Subject: PAM sessions and conversation functions
In-Reply-To: <20030923225629.GB27077@riva.ucam.org>
References: <20030923225629.GB27077@riva.ucam.org>
Message-ID: <Pine.BSO.4.56.0309241116580.6211@shitei.mindrot.org>



On Tue, 23 Sep 2003, Colin Watson wrote:

> In OpenSSH 3.6.1p2, pam_open_session() ran with a conversation function,
> do_pam_conversation(), that fed text to the client. In OpenSSH 3.7.1p2,
> this is no longer the case: session modules run with a conversation
> function that just returns PAM_CONV_ERR. This means that simple session
> modules whose job involves printing text on the user's terminal no
> longer work: pam_lastlog, pam_mail, and pam_motd.

If someone wants to do a patch to add a simple conversation function
that just prints messages to stdout, I will review it for inclusion.

-d



From djm at cvs.openbsd.org  Tue Sep 23 22:40:25 2003
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 23 Sep 2003 06:40:25 -0600 (MDT)
Subject: Multiple PAM vulnerabilities in portable OpenSSH
Message-ID: <200309231240.h8NCePCd025947@cvs.openbsd.org>

Subject: Portable OpenSSH Security Advisory: sshpam.adv

This document can be found at:  http://www.openssh.com/txt/sshpam.adv

1. Versions affected:

        Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple 
        vulnerabilities in the new PAM code. At least one of these bugs 
        is remotely exploitable (under a non-standard configuration, 
        with privsep disabled). 

        The OpenBSD releases of OpenSSH do not contain this code and 
        are not vulnerable. Older versions of portable OpenSSH are not 
        vulnerable.

2. Solution:

        Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM 
        support ("UsePam no" in sshd_config). 

        Due to complexity, inconsistencies in the specification and 
        differences between vendors' PAM implementations we recommend 
        that PAM be left disabled in sshd_config unless there is a need 
        for its use. Sites only using public key or simple password 
        authentication usually have little need to enable PAM support.



From djm at cvs.openbsd.org  Tue Sep 23 22:39:50 2003
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 23 Sep 2003 06:39:50 -0600 (MDT)
Subject: Portable OpenSSH 3.7.1p2 released
Message-ID: <200309231239.h8NCdocm023804@cvs.openbsd.org>

Portable OpenSSH 3.7.1p2  has just been released. It will be available 
from the mirrors listed at http://www.openssh.com/portable.html shortly.

Please note that this is a release to address issues in the portable 
version only. The items mentioned below do not affect the OpenBSD 
version.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu

Security Changes:
=================

  Portable OpenSSH version 3.7p1 and 3.7.1p1 contain multiple 
  vulnerabilities in the new PAM authentication code. At least one of
  these bugs is remotely exploitable (under a non-standard 
  configuration, with privsep disabled).

  OpenSSH 3.7.1p2 fixes these bugs. Please note that these bugs do not 
  exist in OpenBSD's releases of OpenSSH.

Changes since OpenSSH 3.7.1p1:
==============================

* This release disables PAM by default. To enable it, set "UsePAM yes" in 
  sshd_config. Due to complexity, inconsistencies in the specification and
  differences between vendors' PAM implementations we recommend that PAM 
  be left disabled in sshd_config unless there is a need for its use. 
  Sites using only public key or simple password authentication usually 
  have little need to enable PAM support.

* This release now requires zlib 1.1.4 to build correctly. Previous 
  versions have security problems.

* Fix compilation for versions of OpenSSL before 0.9.6. Some cipher modes 
  are not supported for older OpenSSL versions.

* Fix compilation problems on systems with a missing or lacking inet_ntoa()
  function.

* Workaround problems related to unimplemented or broken setresuid/setreuid 
  functions on several platforms.

* Fix compilation on older OpenBSD systems.

* Fix handling of password-less authentication (PermitEmptyPasswords=yes) 
  that has not worked since the 3.7p1 release.

Checksums:
==========

- MD5 (openssh-3.7.1p2.tar.gz) = 61cf5b059938718308836d00f6764a94


Reporting Bugs:
===============

- please read http://www.openssh.com/report.html
  and http://bugzilla.mindrot.org/

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



From djm at cvs.openbsd.org  Tue Sep 23 22:39:50 2003
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 23 Sep 2003 06:39:50 -0600 (MDT)
Subject: Portable OpenSSH 3.7.1p2 released
Message-ID: <200309231239.h8NCdocm023804@cvs.openbsd.org>

Portable OpenSSH 3.7.1p2  has just been released. It will be available 
from the mirrors listed at http://www.openssh.com/portable.html shortly.

Please note that this is a release to address issues in the portable 
version only. The items mentioned below do not affect the OpenBSD 
version.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu

Security Changes:
=================

  Portable OpenSSH version 3.7p1 and 3.7.1p1 contain multiple 
  vulnerabilities in the new PAM authentication code. At least one of
  these bugs is remotely exploitable (under a non-standard 
  configuration, with privsep disabled).

  OpenSSH 3.7.1p2 fixes these bugs. Please note that these bugs do not 
  exist in OpenBSD's releases of OpenSSH.

Changes since OpenSSH 3.7.1p1:
==============================

* This release disables PAM by default. To enable it, set "UsePAM yes" in 
  sshd_config. Due to complexity, inconsistencies in the specification and
  differences between vendors' PAM implementations we recommend that PAM 
  be left disabled in sshd_config unless there is a need for its use. 
  Sites using only public key or simple password authentication usually 
  have little need to enable PAM support.

* This release now requires zlib 1.1.4 to build correctly. Previous 
  versions have security problems.

* Fix compilation for versions of OpenSSL before 0.9.6. Some cipher modes 
  are not supported for older OpenSSL versions.

* Fix compilation problems on systems with a missing or lacking inet_ntoa()
  function.

* Workaround problems related to unimplemented or broken setresuid/setreuid 
  functions on several platforms.

* Fix compilation on older OpenBSD systems.

* Fix handling of password-less authentication (PermitEmptyPasswords=yes) 
  that has not worked since the 3.7p1 release.

Checksums:
==========

- MD5 (openssh-3.7.1p2.tar.gz) = 61cf5b059938718308836d00f6764a94


Reporting Bugs:
===============

- please read http://www.openssh.com/report.html
  and http://bugzilla.mindrot.org/

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



From djm at cvs.openbsd.org  Tue Sep 23 22:39:50 2003
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 23 Sep 2003 06:39:50 -0600 (MDT)
Subject: Portable OpenSSH 3.7.1p2 released
Message-ID: <200309231239.h8NCdocm023804@cvs.openbsd.org>

Portable OpenSSH 3.7.1p2  has just been released. It will be available 
from the mirrors listed at http://www.openssh.com/portable.html shortly.

Please note that this is a release to address issues in the portable 
version only. The items mentioned below do not affect the OpenBSD 
version.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu

Security Changes:
=================

  Portable OpenSSH version 3.7p1 and 3.7.1p1 contain multiple 
  vulnerabilities in the new PAM authentication code. At least one of
  these bugs is remotely exploitable (under a non-standard 
  configuration, with privsep disabled).

  OpenSSH 3.7.1p2 fixes these bugs. Please note that these bugs do not 
  exist in OpenBSD's releases of OpenSSH.

Changes since OpenSSH 3.7.1p1:
==============================

* This release disables PAM by default. To enable it, set "UsePAM yes" in 
  sshd_config. Due to complexity, inconsistencies in the specification and
  differences between vendors' PAM implementations we recommend that PAM 
  be left disabled in sshd_config unless there is a need for its use. 
  Sites using only public key or simple password authentication usually 
  have little need to enable PAM support.

* This release now requires zlib 1.1.4 to build correctly. Previous 
  versions have security problems.

* Fix compilation for versions of OpenSSL before 0.9.6. Some cipher modes 
  are not supported for older OpenSSL versions.

* Fix compilation problems on systems with a missing or lacking inet_ntoa()
  function.

* Workaround problems related to unimplemented or broken setresuid/setreuid 
  functions on several platforms.

* Fix compilation on older OpenBSD systems.

* Fix handling of password-less authentication (PermitEmptyPasswords=yes) 
  that has not worked since the 3.7p1 release.

Checksums:
==========

- MD5 (openssh-3.7.1p2.tar.gz) = 61cf5b059938718308836d00f6764a94


Reporting Bugs:
===============

- please read http://www.openssh.com/report.html
  and http://bugzilla.mindrot.org/

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



From djm at mindrot.org  Wed Sep 24 08:11:41 2003
From: djm at mindrot.org (Damien Miller)
Date: Tue, 23 Sep 2003 22:11:41 -0000
Subject: PAM vulnerability in portable OpenSSH
In-Reply-To: <200309232101.h8NL1R3J020159@cvs.openbsd.org>
References: <200309232101.h8NL1R3J020159@cvs.openbsd.org>
Message-ID: <1064354936.21615.143.camel@sakura.mindrot.org>


> Interesting quote:
> 
> "Due to complexity, inconsistencies in the specification and differences
> between vendors' PAM implementations we recommend that PAM be left disabled
> in sshd_config unless there is a need for its use. Sites only using public
> key or simple password authentication usually have little need to enable PAM
> support."
> 
> Slander? Don't think so.

It is only slander if it is false. Let's look at the charges:

1. Complexity - it is self-evident that PAM adds complexity to 
login-like program's implementation. This is before one has to 
take into account its horribly broken, non-interruptible 
conversation function.

2. Inconsistencies in the specification - these have been documented 
by a PAM implementor at http://www.openpam.org/errata.html If you like 
reading vague specs, try reading the original PAM DCE RFC. This 
vagueness contributed to one of the vulnerabilities mentioned. 

3. Differences between vendors' implementations. Solaris PAM passes 
message arguments differently to LinuxPAM and OpenPAM. Some PAM 
implementations fatally break unless you set a PAM_TTY. There are 
differences in how implementations respond to credential 
(re-)initialisation and operation across different processes.

So I think that the recommendation to disable PAM unless you need it is 
a conservative one. For sites that just use password or OpenSSH's native
authentication methods, the only thing that PAM really buys you is a 
standard log message.

-d



From djm at shitei.mindrot.org  Wed Sep 24 11:21:12 2003
From: djm at shitei.mindrot.org (Damien Miller)
Date: Wed, 24 Sep 2003 11:21:12 +1000 (EST)
Subject: (Trivial oddity) Old version in Portable CVS HEAD
In-Reply-To: <Pine.BSO.4.44.0309232014440.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309232014440.842-100000@etoh.eviladmin.org>
Message-ID: <Pine.BSO.4.56.0309241120090.6211@shitei.mindrot.org>



On Tue, 23 Sep 2003, Ben Lindstrom wrote:

> 
> 
> On 24 Sep 2003, Damien Miller wrote:
> 
> > On Wed, 2003-09-24 at 08:25, Carson Gaspar wrote:
> > > I assume this is a branching issue, but in case anyone else notices, CVS
> > > HEAD currently declares itself as OpenSSH_3.7.1p1, not OpenSSH_3.7.1p2. The
> > > 3.7.1p2 tarball has the correct version.
> >
> > fixed - thanks for reminding me.
> >
> 
> Well.. Technically --head is not 3.7.1p2.
> 
> If you look at the CVS tree you'll notice that p2 has a few less patches
> (like a lot of the fatal() clean up).  So to claim it is p2 is kinda a
> falsity.

It has the security fixes (which are what matter the most) and dtucker@
has already merged most of the other ones. Please sync if there are any 
stragglers.

-d



From djm at shitei.mindrot.org  Wed Sep 24 11:22:54 2003
From: djm at shitei.mindrot.org (Damien Miller)
Date: Wed, 24 Sep 2003 11:22:54 +1000 (EST)
Subject: PAM sessions and conversation functions
In-Reply-To: <Pine.BSO.4.56.0309241116580.6211@shitei.mindrot.org>
References: <20030923225629.GB27077@riva.ucam.org>
	<Pine.BSO.4.56.0309241116580.6211@shitei.mindrot.org>
Message-ID: <Pine.BSO.4.56.0309241122340.6211@shitei.mindrot.org>


> If someone wants to do a patch to add a simple conversation function
> that just prints messages to stdout, I will review it for inclusion.

hmm, make that stderr

-d



From djm at shitei.mindrot.org  Wed Sep 24 11:24:42 2003
From: djm at shitei.mindrot.org (Damien Miller)
Date: Wed, 24 Sep 2003 11:24:42 +1000 (EST)
Subject: Delay in anncouncements
Message-ID: <Pine.BSO.4.56.0309241123060.6211@shitei.mindrot.org>

Apologies for the delay for the announcement messages to reach the list.
For some reason the list manager (Mailman) decided that the messages 
needed approval twice. 



From peter at irba.co.nz  Wed Sep 24 14:47:22 2003
From: peter at irba.co.nz (Peter Wood)
Date: Wed, 24 Sep 2003 16:47:22 +1200
Subject: IRIX 5.3 permanently_set_uid problem
Message-ID: <3F7121DA.80201@irba.co.nz>

Hello,

I have tried running OpenSSH 3.7.1p2 on an Indy running IRIX 5.3.  It 
compiled and installed without any problems.

However, I get the fatal error, which originates from uidswap.c in 
function permanently_set_uid():

    fatal: permanently_set_uid: was able to restore old [e]uid

This happens even if  "UsePrivilegeSeparation no" is used in sshd_config.
 
It seems to be a problem with IRIX 5.3 rather than OpenSSH.  I have 
searched for possible patches for IRIX 5.3, but haven't found anything 
likely yet.

Any suggestions?

Regards
Peter



From mweiser at fachschaft.imn.htwk-leipzig.de  Wed Sep 24 17:19:27 2003
From: mweiser at fachschaft.imn.htwk-leipzig.de (Michael Weiser)
Date: Wed, 24 Sep 2003 09:19:27 +0200 (CEST)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.BSO.4.44.0309230911190.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309230911190.842-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.58.0309240902390.24988@heinz.dinsnail.net>

On Tue, 23 Sep 2003, Ben Lindstrom wrote:

> > That's a pity - I've got two NeXTstep m68k boxes here which run quite
> I have a nice 25mhz Slab sitting on a desk at home.. Access has never been
> an issue.  It is willingness to baby the platform.  At 25mhz a build
> takes around 15 - 20 minutes (assuming all goes well).  And it seems to
> get worse. =)
I'm used to that and willing to do testing if that'd help you continue 
supporting the port.

> > What is the actual purpose of mysignal()? Is it safe to just remove that
> > define? I've diff'ed openssh 3.7.1p1 against 3.6.1p2 and found that in
> No we can't remove it.  It actually is there for a very good reason.
> Partly to solve issues with different singal() versions.  mysignal() is
> suppose to be an extremely strict version of signal().  In a few spots of
> our code we have needed it.  Between 3.6.1 and now we decided to use
> mysignal() by default for every signal() in our tree.
Okay. 

> It would be nice to know what signal() location it is causing the
> behavior.  Maybe a backtrace from gdb and server side -ddd reports.
It's the very first call from seed_rng called in main. The debug session
with backtraces is below. Funnily enough it doesn't segfault any more but 
recall mysignal!? Is perhaps the #define wreaking havoc with the actual 
signal call in bsd-misc.h so that it recursively calls itself until it 
crashes?

(gdb) break mysignal
Reading in symbols for bsd-misc.c...done.
Breakpoint 1 at 0x33f46: bsd-misc.c:206.
(gdb) cd openbsd-compat
Working directory /private/tmp/openssh-3.7.1p2/openbsd-compat.
(gdb) run -p 2222
Starting program: /private/tmp/openssh-3.7.1p2/sshd -p 2222

Breakpoint 1, mysignal (sig=?, act=void) at bsd-misc.c:206
206     {
(gdb) n
mysignal (sig=?, act=void) at bsd-misc.c:226
226             return (signal(sig, act));
(gdb) 

Breakpoint 1, mysignal (sig=?, act=void) at bsd-misc.c:206
206     {
(gdb) bt
Reading in symbols for entropy.c...done.
Reading in symbols for sshd.c...done.
#0  mysignal (sig=?, act=void) at bsd-misc.c:206
#1  0x33f58 in mysignal (sig=?, act=void) at bsd-misc.c:226
#2  0x24590 in seed_rng () at entropy.c:78
#3  0x4f82 in main (ac=?, av=0x33820c) at sshd.c:951
(gdb) n
mysignal (sig=?, act=void) at bsd-misc.c:226
226             return (signal(sig, act));
(gdb) 

Breakpoint 1, mysignal (sig=?, act=void) at bsd-misc.c:206
206     {
(gdb) bt
#0  mysignal (sig=?, act=void) at bsd-misc.c:206
#1  0x33f58 in mysignal (sig=?, act=void) at bsd-misc.c:226
#2  0x33f58 in mysignal (sig=?, act=void) at bsd-misc.c:226
#3  0x24590 in seed_rng () at entropy.c:78
#4  0x4f82 in main (ac=?, av=0x33820c) at sshd.c:951
(gdb) 

> It also be nice to see a copy of your config.
Attached. I had to manually remove HAVE_MMAP and HAVE_TCSENDBREAK because 
they were misdetected. Otherwise it's as configure wrote it.

> I am planning on getting a new "NeXT" laptop in a few months.. Oddly
> enough they mispelt the name of it.. It has "Apple" written on it.
Same for me. ;)
-- 
bye, Micha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.h.gz
Type: application/x-gzip
Size: 7092 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030924/bed34fa5/attachment.bin 

From Sebastian.Roth at frm2.tum.de  Wed Sep 24 18:44:36 2003
From: Sebastian.Roth at frm2.tum.de (Sebastian Roth)
Date: Wed, 24 Sep 2003 10:44:36 +0200 (CEST)
Subject: [ GSSAPI ] Environment settings
Message-ID: <Pine.LNX.4.58.0309241033330.22535@taco22.sun.frm2>

Hi there,

well, I just upgraded to OpenSSH 3.7.1p2 and noticed the GSSAPI-Changes.
Well it worked like a charm. No PAM, no problems while authenticating to
Kerberos 5. But now there is a small problem. We need an pam module
called pam_gssklog.so to authenticate. This modules obtains a token from 
the kerberos ticket. 

The single executable (which is execle'd out of the pam module) works if
an environment variable called KRB5CCNAME is set.

So I integrated the PAM into my ssh-config again, with the Kerberos and
GSSAPI stuff in sshd enabled. Authentication works, my pam module gets
called, but it doesn't find the environment var. After the
authentication succeeds, an single "gssklog" works because the var is
set.

So my question is:

Is there an good way to set the var KRB5CCNAME before the pam module(s)
are called and access them out of the pam-stuff?

Thank you in advance!

		<Seb />



From dtucker at zip.com.au  Wed Sep 24 20:08:11 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 24 Sep 2003 20:08:11 +1000
Subject: IRIX 5.3 permanently_set_uid problem
References: <3F7121DA.80201@irba.co.nz>
Message-ID: <3F716D0B.A3CC2FF5@zip.com.au>

Peter Wood wrote:
> I have tried running OpenSSH 3.7.1p2 on an Indy running IRIX 5.3.  It
> compiled and installed without any problems.
> 
> However, I get the fatal error, which originates from uidswap.c in
> function permanently_set_uid():
> 
>     fatal: permanently_set_uid: was able to restore old [e]uid

Looks like IRIX 5 needs the same defines IRIX 6 does.  I've just added
them.

> It seems to be a problem with IRIX 5.3 rather than OpenSSH.  I have
> searched for possible patches for IRIX 5.3, but haven't found anything
> likely yet.
> 
> Any suggestions?

See here:
http://bugzilla.mindrot.org/show_bug.cgi?id=659

You need to add those #defines to config.h and recompile, or try
tomorrow's snapshot.

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



From tkn at cadsy.me.tut.fi  Wed Sep 24 21:37:00 2003
From: tkn at cadsy.me.tut.fi (Tero Knuutila)
Date: Wed, 24 Sep 2003 14:37:00 +0300 (DST)
Subject: stty: : Operation not supported on transport endpoint
Message-ID: <Pine.SGI.3.96.1030924142306.14863A-100000@cadsy.me.tut.fi>

Hi!

I am using OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f on
my Mandrake 9.1 machine. I used to run fetchmail to get emails from IRIX
6.3 system which has OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL
0x0090602f.

I had to reinstall my Mandrake, and after that ssh gives me strange error
messages. 

When I run command:  
	ssh -f   -L 1234:irixhost.somedomain.fi:110 irixhost.somedomain.fi sleep 5
on my Mandrake I get stty error mentioned on subject line.

Also when I run:
	[tkn at localhost tkn]$ scp  foobar.txt irixhost

I get no error message, but when I run: 
	[tkn at localhost tkn]$ scp  foobar.txt irixhost:
I get error again:
	stty: : Operation not supported on transport endpoint

I am using rsa_key with password, and I use ssh-add to give password only
once.

What can I do to get rid of this error? I already installed latest mdk rpm
but it didn't help. Now I have version mentioned on beginning of this
message.

With best regards,
	Tero Knuutila, Finland 



From japs at garm.adm.ku.dk  Wed Sep 24 21:26:33 2003
From: japs at garm.adm.ku.dk (Jan P. Sorensen)
Date: Wed, 24 Sep 2003 13:26:33 +0200 (METDST)
Subject: SSHD 3.7.1p2 on HP-UX
Message-ID: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>


I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works
correctly and the entry in the logfile is:

Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from
192.38.97.131 port 2463

Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not
accept the password any more and the entries in the logfile are:

Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is
locked
Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from
130.225.127.34 port 50593 ssh2
Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs
from 130.225.127.34 port 50593 ssh2

The /etc/sshd_config is the same in the two cases.

Jan P. Sorensen



From gert at greenie.muc.de  Wed Sep 24 21:38:10 2003
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 24 Sep 2003 13:38:10 +0200
Subject: stty: : Operation not supported on transport endpoint
In-Reply-To: <Pine.SGI.3.96.1030924142306.14863A-100000@cadsy.me.tut.fi>;
	from tkn@cadsy.me.tut.fi on Wed, Sep 24, 2003 at 02:37:00PM +0300
References: <Pine.SGI.3.96.1030924142306.14863A-100000@cadsy.me.tut.fi>
Message-ID: <20030924133809.R26276@greenie.muc.de>

Hi,

On Wed, Sep 24, 2003 at 02:37:00PM +0300, Tero Knuutila wrote:
> When I run command:  
> 	ssh -f   -L 1234:irixhost.somedomain.fi:110 irixhost.somedomain.fi sleep 5
> on my Mandrake I get stty error mentioned on subject line.

Something in your .profile or .bashrc or .kshrc (or whatever script is
executed upon startup of a non-interactive shell) calls "stty".  For 
"ssh-with-command" and "scp", this MUST NOT be done, as there is no tty,
and the error message will mess up the protocol.

The error comes from the remote end.

> Also when I run:
> 	[tkn at localhost tkn]$ scp  foobar.txt irixhost
> 
> I get no error message, 

Of course.  You're just doing a local copy here, with the destination
*file* named "irixhost".

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 at net.informatik.tu-muenchen.de



From postadal at suse.cz  Wed Sep 24 21:47:29 2003
From: postadal at suse.cz (Petr Ostadal)
Date: Wed, 24 Sep 2003 13:47:29 +0200 (CEST)
Subject: [ GSSAPI ] Environment settings
In-Reply-To: <Pine.LNX.4.58.0309241033330.22535@taco22.sun.frm2>
References: <Pine.LNX.4.58.0309241033330.22535@taco22.sun.frm2>
Message-ID: <Pine.LNX.4.53.0309241346070.3778@basilisk.suse.cz>

I think it solves my patch , which I added to openssh bugzilla some day
ago. See http://bugzilla.mindrot.org/show_bug.cgi?id=698

	Petr

On Wed, 24 Sep 2003, Sebastian Roth wrote:

> Hi there,
>
> well, I just upgraded to OpenSSH 3.7.1p2 and noticed the GSSAPI-Changes.
> Well it worked like a charm. No PAM, no problems while authenticating to
> Kerberos 5. But now there is a small problem. We need an pam module
> called pam_gssklog.so to authenticate. This modules obtains a token from
> the kerberos ticket.
>
> The single executable (which is execle'd out of the pam module) works if
> an environment variable called KRB5CCNAME is set.
>
> So I integrated the PAM into my ssh-config again, with the Kerberos and
> GSSAPI stuff in sshd enabled. Authentication works, my pam module gets
> called, but it doesn't find the environment var. After the
> authentication succeeds, an single "gssklog" works because the var is
> set.
>
> So my question is:
>
> Is there an good way to set the var KRB5CCNAME before the pam module(s)
> are called and access them out of the pam-stuff?
>
> Thank you in advance!
>
> 		<Seb />
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From michael.steffens at hp.com  Wed Sep 24 21:56:10 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Wed, 24 Sep 2003 13:56:10 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
Message-ID: <3F71865A.60306@hp.com>

Jan P. Sorensen wrote:
> I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works
> correctly and the entry in the logfile is:
> 
> Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from
> 192.38.97.131 port 2463
> 
> Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not
> accept the password any more and the entries in the logfile are:
> 
> Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is
> locked
> Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from
> 130.225.127.34 port 50593 ssh2
> Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs
> from 130.225.127.34 port 50593 ssh2
> 
> The /etc/sshd_config is the same in the two cases.

May I guess it is because PAM has been disabled, and you are running
ShadowPassword on 11.11?

Non-PAM password authentication is not able to pickup shadow passwords,
because this is disabled, too.

(See also http://bugzilla.mindrot.org/show_bug.cgi?id=633)

Cheers!
Michael



From dtucker at zip.com.au  Wed Sep 24 22:12:00 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 24 Sep 2003 22:12:00 +1000
Subject: SSHD 3.7.1p2 on HP-UX
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
Message-ID: <3F718A10.6AFD97DB@zip.com.au>

"Jan P. Sorensen" wrote:
> 
> I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works
> correctly and the entry in the logfile is:
> 
> Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from
> 192.38.97.131 port 2463
> 
> Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not
> accept the password any more and the entries in the logfile are:
> 
> Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is
> locked
> Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from
> 130.225.127.34 port 50593 ssh2
> Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs
> from 130.225.127.34 port 50593 ssh2

Is that box in trusted mode? Does this help:
http://bugzilla.mindrot.org/show_bug.cgi?id=633

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



From japs at garm.adm.ku.dk  Wed Sep 24 22:31:08 2003
From: japs at garm.adm.ku.dk (Jan P. Sorensen)
Date: Wed, 24 Sep 2003 14:31:08 +0200 (METDST)
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F718A10.6AFD97DB@zip.com.au>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
Message-ID: <Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>

Yes, HP-UX is run in trusted mode.

Notice that the problem first appeared today when I upgraded from p1 to
p2.

Jan P. Sorensen

On Wed, 24 Sep 2003, Darren Tucker wrote:

> "Jan P. Sorensen" wrote:
> >
> > I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works
> > correctly and the entry in the logfile is:
> >
> > Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from
> > 192.38.97.131 port 2463
> >
> > Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not
> > accept the password any more and the entries in the logfile are:
> >
> > Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is
> > locked
> > Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from
> > 130.225.127.34 port 50593 ssh2
> > Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs
> > from 130.225.127.34 port 50593 ssh2
>
> Is that box in trusted mode? Does this help:
> http://bugzilla.mindrot.org/show_bug.cgi?id=633
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>



From michael.steffens at hp.com  Wed Sep 24 22:47:06 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Wed, 24 Sep 2003 14:47:06 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
Message-ID: <3F71924A.30501@hp.com>

Jan P. Sorensen wrote:
> Yes, HP-UX is run in trusted mode.
> 
> Notice that the problem first appeared today when I upgraded from p1 to
> p2.

The relevant difference is that p1 had PAM enabled by default, while
it was disabled in p2.

So it refers to non-PAM password authentication, which is broken
in both for trusted systems and those using shadow passwords.

Does

   http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view

fix it?

Alternatively, you may explicitly enable PAM in sshd_config
and contemplate about whether this is secure or not...

Cheers!
Michael



From michael.steffens at hp.com  Wed Sep 24 23:10:39 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Wed, 24 Sep 2003 15:10:39 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F71924A.30501@hp.com>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>	<3F718A10.6AFD97DB@zip.com.au>	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com>
Message-ID: <3F7197CF.6040907@hp.com>

Michael Steffens wrote:
> Jan P. Sorensen wrote:
> 
>> Yes, HP-UX is run in trusted mode.
>>
>> Notice that the problem first appeared today when I upgraded from p1 to
>> p2.
> 
> 
> The relevant difference is that p1 had PAM enabled by default, while
> it was disabled in p2.
> 
> So it refers to non-PAM password authentication, which is broken
> in both for trusted systems and those using shadow passwords.
> 
> Does
> 
>   http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view
> 
> fix it?

Sorry, the patch above is against CVS version and needs autoconf
and autoheader to be run before configure.

In order to achieve the same result in release version without these
tools you may comment out or remove

   #define DISABLE_SHADOW

in config.h after running configure.  Then apply the patch above
concerning openbsd-compat/xcrypt.c




From schaefert at tomcat.umsl.edu  Thu Sep 25 00:17:11 2003
From: schaefert at tomcat.umsl.edu (Tom Schaefer)
Date: Wed, 24 Sep 2003 09:17:11 -0500
Subject: 3.7.1p1 and PAM
Message-ID: <20030924091711.02a24b35.schaefert@tomcat.umsl.edu>

Hi,

I've spent a lot of time digging the last couple days and seen some talk about how now with 3.7.1p1 the PAM challenge response requiring keyboard interactive on the client is "right" and no longer a kludge.  I understand that.

Unfortunately I've got a bunch of users who's client (www.ssh.com's client version 3.2.3)  doesn't function without a kludged server.

The package from www.ssh.com come's with a Windows GUI based client and a "DOS" command line only client.The GUI client does suport keyboard interactive and thus does work ok with PAM and 3.7.1p1 server but the "DOS" command line only client (ssh2.exe) does NOT.

This stinks for me since its the command line version I've got them all using in a DOS batch file.  All it does is connect to the server and forward local port 139 in order to encrypt samba.  Authentication is done with pam_smb PAM module.

Anyhow, I realize its a client side problem but I'm writing to suggest an option be put into the next version of openssh to revert to the old "kludged" method of challenge response giving administrators the ability to maintain compabitability with broken and handicapped clients if they wish to do so.

As it stands I've been forced to revert to an older version of sshd and am going to have to get some firewall rules in place real soon now.

Thankyou,
Tom Schaefer
UNIX Administrator
University of Missouri Saint Louis 


I put openssh 3.7.1p1 on a server and 



From jaearick at colby.edu  Thu Sep 25 00:18:34 2003
From: jaearick at colby.edu (Jeff A. Earickson)
Date: Wed, 24 Sep 2003 10:18:34 -0400 (EDT)
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F71924A.30501@hp.com>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com>
Message-ID: <Pine.GSO.4.58.0309241009530.2935@cayuga>

Hi,
   I have a related problem with 3.7.1p2 and HPUX 11.0.  After
I built and installed it, it doesn't work.  And I don't get any
useful info in my syslogs.  We use PAM heavily
(we use DCE behind the scenes), so we are NOT using trusted mode
or shadow passwords.  The /etc/password file just has asterisks
in the password field because authentication goes thru PAM.
3.6.1p1 works fine with this setup.

My sshd_config file is attached.  The same config file and 3.7.1p2
works great on Solaris 7/8/9.  Is the a bug or a config problem?

--- Jeff Earickson
    Colby College

On Wed, 24 Sep 2003, Michael Steffens wrote:

> Date: Wed, 24 Sep 2003 14:47:06 +0200
> From: Michael Steffens <michael.steffens at hp.com>
> To: Jan P. Sorensen <japs at garm.adm.ku.dk>
> Cc: openssh-unix-dev at mindrot.org, Darren Tucker <dtucker at zip.com.au>
> Subject: Re: SSHD 3.7.1p2 on HP-UX
>
> Jan P. Sorensen wrote:
> > Yes, HP-UX is run in trusted mode.
> >
> > Notice that the problem first appeared today when I upgraded from p1 to
> > p2.
>
> The relevant difference is that p1 had PAM enabled by default, while
> it was disabled in p2.
>
> So it refers to non-PAM password authentication, which is broken
> in both for trusted systems and those using shadow passwords.
>
> Does
>
>    http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view
>
> fix it?
>
> Alternatively, you may explicitly enable PAM in sshd_config
> and contemplate about whether this is secure or not...
>
> Cheers!
> Michael
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
-------------- next part --------------
#	$OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/openssh/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#--- NOTE: Configured for Colby settings, as of 3.7.1p2

#Port 22
#(jae) only allow protocol 2
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#(jae) only allow dsa keys
HostKey /etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#(jae) keybits boosted from 768 to 2048
ServerKeyBits 2048

# Logging
#obsoletes QuietMode and FascistLogging
#(jae) specify the logging (defaults in 3.7.1p2)
SyslogFacility AUTH
LogLevel INFO

# Authentication:

#(jae) 60 sec login window, no root login
LoginGraceTime 60s
PermitRootLogin no
StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh_known_hosts
#(jae) no rhost login, don't trust anything in this section
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#(jae) using PAM, disable per sshd_config(5) manpage, no empty pw!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#(jae) using PAM on Solaris and HPUX
UsePAM yes

#AllowTcpForwarding yes
#(jae) do not allow port forwarding
GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#(jae) do not print motd because shell does this
PrintMotd no
#(jae) print the last login
PrintLastLog yes
#KeepAlive yes
#UseLogin no
#(jae) break apart root and user privs
UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#(jae) client can only stay connected but idle 30 minutes (60x3)
ClientAliveInterval 600
ClientAliveCountMax 3
#(jae) use DNS to map remote logins
UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#(jae) show our pre-login banner
Banner /etc/issue

# override default of no subsystems
Subsystem	sftp	/opt/openssh/libexec/sftp-server

#(jae)deny specific users
DenyUsers daemon bin sys adm mail lp uucp nuucp listen nobody bind radius

From olemx at ans.pl  Thu Sep 25 00:54:32 2003
From: olemx at ans.pl (Krzysztof Oledzki)
Date: Wed, 24 Sep 2003 16:54:32 +0200 (CEST)
Subject: Fix checking password from /etc/passwd and /etc/shadow
Message-ID: <Pine.LNX.4.33.0309241637240.19909-101000@dark.pcgames.pl>

Hello,

This patch fix order of checking password in systems that contains
/etc/shadow file (Linux for example). The order is exactly like in
linux-shadow-password package. First is checked /etc/passwd but if
password field contains "x" then password is read from /etc/shadow
instead.

Best regards,


				Krzysztof Ol?dzki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: passwd-shadow-check-order.gz
Type: application/octet-stream
Size: 378 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030924/f15e0296/attachment.obj 

From mouring at etoh.eviladmin.org  Thu Sep 25 01:07:54 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 24 Sep 2003 10:07:54 -0500 (CDT)
Subject: Fix checking password from /etc/passwd and /etc/shadow
In-Reply-To: <Pine.LNX.4.33.0309241637240.19909-101000@dark.pcgames.pl>
Message-ID: <Pine.BSO.4.44.0309241007160.842-100000@etoh.eviladmin.org>


Umm.. Two words on this patch..


	"HELL NO"

- Ben

On Wed, 24 Sep 2003, Krzysztof Oledzki wrote:

> Hello,
>
> This patch fix order of checking password in systems that contains
> /etc/shadow file (Linux for example). The order is exactly like in
> linux-shadow-password package. First is checked /etc/passwd but if
> password field contains "x" then password is read from /etc/shadow
> instead.
>
> Best regards,
>
>
> 				Krzysztof Ol?dzki
>



From michael.steffens at hp.com  Thu Sep 25 01:12:27 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Wed, 24 Sep 2003 17:12:27 +0200
Subject: Fix checking password from /etc/passwd and /etc/shadow
In-Reply-To: <Pine.LNX.4.33.0309241637240.19909-101000@dark.pcgames.pl>
References: <Pine.LNX.4.33.0309241637240.19909-101000@dark.pcgames.pl>
Message-ID: <3F71B45B.8030801@hp.com>

Krzysztof Oledzki wrote:
> Hello,
> 
> This patch fix order of checking password in systems that contains
> /etc/shadow file (Linux for example). The order is exactly like in
> linux-shadow-password package. First is checked /etc/passwd but if
> password field contains "x" then password is read from /etc/shadow
> instead.

What is wrong with the current approach of first checking /etc/shadow
using getspnam, falling back to /etc/passwd if the first didn't return
anything?

Reversing that order and making the decision depend on a non-zero
value returned from /etc/passwd ("x", "*", whatever?) looks like
making it more complicated to me.

Cheers!
Michael



From Sergio.Gelato at astro.su.se  Thu Sep 25 01:20:13 2003
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Wed, 24 Sep 2003 17:20:13 +0200
Subject: Patches for compatibility with Heimdal's libsia_krb5 SIA module
Message-ID: <20030924152013.GA3495@hanuman.astro.su.se>

I have found the following patches to be desirable for using sshd on a
Tru64 UNIX system with the Kerberos 5 SIA module (libsia_krb5.so) from
Heimdal.

These patches do the following:

1) preserve context between the password authentication and the session
setup phases. This is necessary because the Heimdal SIA module stores
Kerberos context information as mechanism-specific data in ent->mech[].

2) Allow for the KRB5CCNAME environment variable (potentially set in
session_setup_sia()) to be propagated to the session environment.

Caveat: I have only tested this with the BSD and Heimdal KRB5 modules, 
not with OSFC2 or any other SIA module.

To do:

* clean up the Kerberos credentials cache at session exit. Unfortunately
SIA is not invoked at this time, so this cannot be done in the SIA module.

* review what happens if authentication succeeds but session_setup_sia() is 
not invoked for some reason. Currently the sia_ses_release() clean-up
code will not be invoked in this case. For most SIA modules this shouldn't
matter, as resources will be released at process exit; but it would be
nice to get it right anyway.
-------------- next part --------------
diff -aruN openssh-3.7.1p2.orig/auth-passwd.c openssh-3.7.1p2/auth-passwd.c
--- openssh-3.7.1p2.orig/auth-passwd.c	Thu Sep 18 10:26:48 2003
+++ openssh-3.7.1p2/auth-passwd.c	Wed Sep 24 00:04:40 2003
@@ -42,6 +42,9 @@
 #include "log.h"
 #include "servconf.h"
 #include "auth.h"
+#ifdef HAVE_OSF_SIA
+#include "auth-sia.h"
+#endif
 #ifdef WITH_AIXAUTHENTICATE
 # include "buffer.h"
 # include "canohost.h"
diff -aruN openssh-3.7.1p2.orig/auth-sia.c openssh-3.7.1p2/auth-sia.c
--- openssh-3.7.1p2.orig/auth-sia.c	Tue Jun  3 02:25:48 2003
+++ openssh-3.7.1p2/auth-sia.c	Wed Sep 24 00:05:39 2003
@@ -31,6 +31,7 @@
 #include "log.h"
 #include "servconf.h"
 #include "canohost.h"
+#include "xmalloc.h"
 
 #include <sia.h>
 #include <siad.h>
@@ -45,11 +46,12 @@
 extern int saved_argc;
 extern char **saved_argv;
 
+static SIAENTITY *ent = NULL;
+
 int
 auth_sia_password(Authctxt *authctxt, char *pass)
 {
 	int ret;
-	SIAENTITY *ent = NULL;
 	const char *host;
 
 	host = get_canonical_hostname(options.use_dns);
@@ -57,6 +59,12 @@
 	if (!authctxt->user || pass == NULL || pass[0] == '\0')
 		return (0);
 
+	if (ent) {
+		debug("Releasing old SIAENTITY!");
+		sia_ses_release(&ent);
+		ent = NULL;
+	}
+	
 	if (sia_ses_init(&ent, saved_argc, saved_argv, host, authctxt->user,
 	    NULL, 0, NULL) != SIASUCCESS)
 		return (0);
@@ -64,31 +72,36 @@
 	if ((ret = sia_ses_authent(NULL, pass, ent)) != SIASUCCESS) {
 		error("Couldn't authenticate %s from %s",
 		    authctxt->user, host);
-		if (ret & SIASTOP)
+		if (ret & SIASTOP) {
 			sia_ses_release(&ent);
+			ent = NULL;
+		}
 
 		return (0);
 	}
 
-	sia_ses_release(&ent);
-
 	return (1);
 }
 
 void
 session_setup_sia(struct passwd *pw, char *tty)
 {
-	SIAENTITY *ent = NULL;
 	const char *host;
 
 	host = get_canonical_hostname(options.use_dns);
 
-	if (sia_ses_init(&ent, saved_argc, saved_argv, host, pw->pw_name, 
-	    tty, 0, NULL) != SIASUCCESS)
-		fatal("sia_ses_init failed");
+	if (ent) {
+		if (tty)
+			ent->tty = xstrdup(tty);
+	} else {
+		if (sia_ses_init(&ent, saved_argc, saved_argv, host, pw->pw_name, 
+	    		tty, 0, NULL) != SIASUCCESS)
+			fatal("sia_ses_init failed");
+	}
 
 	if (sia_make_entity_pwd(pw, ent) != SIASUCCESS) {
 		sia_ses_release(&ent);
+		ent = NULL;
 		fatal("sia_make_entity_pwd failed");
 	}
 
@@ -102,6 +115,7 @@
 		    pw->pw_name, host);
 	
 	sia_ses_release(&ent);
+	ent = NULL;
 
 	if (setreuid(geteuid(), geteuid()) < 0)
 		fatal("setreuid: %s", strerror(errno));
diff -aruN openssh-3.7.1p2.orig/session.c openssh-3.7.1p2/session.c
--- openssh-3.7.1p2.orig/session.c	Tue Sep 23 10:59:08 2003
+++ openssh-3.7.1p2/session.c	Wed Sep 24 00:04:41 2003
@@ -49,6 +49,9 @@
 #include "bufaux.h"
 #include "auth.h"
 #include "auth-options.h"
+#ifdef HAVE_OSF_SIA
+#include "auth-sia.h"
+#endif
 #include "pathnames.h"
 #include "log.h"
 #include "servconf.h"
-------------- next part --------------
diff -aruN openssh-3.7.1p2.orig/session.c openssh-3.7.1p2/session.c
--- openssh-3.7.1p2.orig/session.c	Tue Sep 23 10:59:08 2003
+++ openssh-3.7.1p2/session.c	Wed Sep 24 00:02:15 2003
@@ -1093,6 +1093,14 @@
 		read_environment_file(&env, &envsize, "/etc/environment");
 	}
 #endif
+#ifdef HAVE_OSF_SIA
+	{
+		char *cp;
+
+		if ((cp = getenv("KRB5CCNAME")) != NULL)
+			child_set_env(&env, &envsize, "KRB5CCNAME", cp);
+	}
+#endif
 #ifdef KRB5
 	if (s->authctxt->krb5_ticket_file)
 		child_set_env(&env, &envsize, "KRB5CCNAME",
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030924/cb239059/attachment.bin 

From olemx at ans.pl  Thu Sep 25 01:26:03 2003
From: olemx at ans.pl (Krzysztof Oledzki)
Date: Wed, 24 Sep 2003 17:26:03 +0200 (CEST)
Subject: Fix checking password from /etc/passwd and /etc/shadow
In-Reply-To: <3F71B45B.8030801@hp.com>
Message-ID: <Pine.LNX.4.33.0309241723520.19909-100000@dark.pcgames.pl>



On Wed, 24 Sep 2003, Michael Steffens wrote:

> Krzysztof Oledzki wrote:
> > Hello,
> >
> > This patch fix order of checking password in systems that contains
> > /etc/shadow file (Linux for example). The order is exactly like in
> > linux-shadow-password package. First is checked /etc/passwd but if
> > password field contains "x" then password is read from /etc/shadow
> > instead.
>
> What is wrong with the current approach of first checking /etc/shadow
> using getspnam, falling back to /etc/passwd if the first didn't return
> anything?
>
> Reversing that order and making the decision depend on a non-zero
> value returned from /etc/passwd ("x", "*", whatever?) looks like
> making it more complicated to me.

If /etc/passwd contains:

aqq::1001:100:Aqq:/home/aqq:/bin/bash

and /etc/shadow:
aqq:!:12319:0:99999:7:::

Then login allows to log this user with empty password but openssh not.

Best Regards,

			Krzysztof Ol?dzki



From michael.steffens at hp.com  Thu Sep 25 01:27:20 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Wed, 24 Sep 2003 17:27:20 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <Pine.GSO.4.58.0309241009530.2935@cayuga>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com> <Pine.GSO.4.58.0309241009530.2935@cayuga>
Message-ID: <3F71B7D8.8060707@hp.com>

Jeff A. Earickson wrote:
> Hi,
>    I have a related problem with 3.7.1p2 and HPUX 11.0.  After
> I built and installed it, it doesn't work.  And I don't get any
> useful info in my syslogs.  We use PAM heavily
> (we use DCE behind the scenes), so we are NOT using trusted mode
> or shadow passwords.  The /etc/password file just has asterisks
> in the password field because authentication goes thru PAM.
> 3.6.1p1 works fine with this setup.
> 
> My sshd_config file is attached.  The same config file and 3.7.1p2
> works great on Solaris 7/8/9.  Is the a bug or a config problem?

Wouldn't consider this directly related to the non-PAM stuff
discussed so far, as you are using PAM. Hmm, and fail.

Does anyone know whether the 3.6.1 series is also affected by
the PAM vulnerabilities found in 3.7?

Cheers!
Michael



From austin at coremetrics.com  Thu Sep 25 02:24:11 2003
From: austin at coremetrics.com (Austin Gonyou)
Date: Wed, 24 Sep 2003 11:24:11 -0500
Subject: 3.7.1p1 and PAM
In-Reply-To: <20030924091711.02a24b35.schaefert@tomcat.umsl.edu>
References: <20030924091711.02a24b35.schaefert@tomcat.umsl.edu>
Message-ID: <1064420651.1931.2.camel@localhost.localdomain>

On Wed, 2003-09-24 at 09:17, Tom Schaefer wrote:
> Hi,
> 
[...]
> Anyhow, I realize its a client side problem but I'm writing to suggest
> an option be put into the next version of openssh to revert to the old
> "kludged" method of challenge response giving administrators the
> ability to maintain compabitability with broken and handicapped
> clients if they wish to do so.

Yikes. I hear your pain, but it's almost like buying a new car with an
option for a "recalled" feature that causes the brakes to fail
intermittently, but otherwise things are "normal."

> As it stands I've been forced to revert to an older version of sshd
> and am going to have to get some firewall rules in place real soon
> now.

Any chance of using putty or some such thing, instead?? It doesn't seem
to be b0rk3n.


-- 
Austin Gonyou <austin at coremetrics.com>
Coremetrics, Inc.



From iqbala at qwestip.net  Thu Sep 25 02:46:41 2003
From: iqbala at qwestip.net (Asif Iqbal)
Date: Wed, 24 Sep 2003 12:46:41 -0400 (EDT)
Subject: OpenSSH 3.7.1p2-pwexp24.patch
In-Reply-To: <3F70B596.1FFAED1C@zip.com.au>
Message-ID: <Pine.GSO.4.30L2.0309241245300.11260-100000@qmail>

I just tested this patch. It works fine.

I forced expire my account and go prompted to change it at ssh prompt. Awesome
!! . I went ahead and changed my password and then sshd let me in

Thanks for this patch

On Wed, 24 Sep 2003, Darren Tucker wrote:

> lbecke at mchsi.com wrote:
> >
> > For those of us who do require / use PAM, will the expired password patch be
> > ported to 3.7.1p2?
> >
> > If so, any kind of estimate on when?
>
> I've just ported the patch to 3.7.1p2 and the new patch is at [1].  I
> haven't done any testing of it, however the parts that didn't apply were
> trivial.
>
> [1] http://www.zip.com.au/~dtucker/openssh/
>
>

-- 
Asif Iqbal
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x8B686E08
There's no place like 127.0.0.1



From mouring at etoh.eviladmin.org  Thu Sep 25 03:18:58 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 24 Sep 2003 12:18:58 -0500 (CDT)
Subject: Fix checking password from /etc/passwd and /etc/shadow
In-Reply-To: <Pine.LNX.4.33.0309241723520.19909-100000@dark.pcgames.pl>
Message-ID: <Pine.BSO.4.44.0309241150160.842-100000@etoh.eviladmin.org>



On Wed, 24 Sep 2003, Krzysztof Oledzki wrote:

>
>
> On Wed, 24 Sep 2003, Michael Steffens wrote:
>
> > Krzysztof Oledzki wrote:
> > > Hello,
> > >
> > > This patch fix order of checking password in systems that contains
> > > /etc/shadow file (Linux for example). The order is exactly like in
> > > linux-shadow-password package. First is checked /etc/passwd but if
> > > password field contains "x" then password is read from /etc/shadow
> > > instead.
> >
> > What is wrong with the current approach of first checking /etc/shadow
> > using getspnam, falling back to /etc/passwd if the first didn't return
> > anything?
> >
> > Reversing that order and making the decision depend on a non-zero
> > value returned from /etc/passwd ("x", "*", whatever?) looks like
> > making it more complicated to me.
>
> If /etc/passwd contains:
>
> aqq::1001:100:Aqq:/home/aqq:/bin/bash
>
> and /etc/shadow:
> aqq:!:12319:0:99999:7:::
>
> Then login allows to log this user with empty password but openssh not.
>

To me this is a bug in the Linux code.   /etc/shadow should take priority
over /etc/password.  ALWAYS.

- Ben



From mouring at etoh.eviladmin.org  Thu Sep 25 03:21:24 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 24 Sep 2003 12:21:24 -0500 (CDT)
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F71B7D8.8060707@hp.com>
Message-ID: <Pine.BSO.4.44.0309241220530.842-100000@etoh.eviladmin.org>


[..]
> Does anyone know whether the 3.6.1 series is also affected by
> the PAM vulnerabilities found in 3.7?
>

No, the vulnerability was in the new PAM code only.

- Ben



From japs at garm.adm.ku.dk  Thu Sep 25 03:56:48 2003
From: japs at garm.adm.ku.dk (Jan P. Sorensen)
Date: Wed, 24 Sep 2003 19:56:48 +0200 (METDST)
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F7197CF.6040907@hp.com>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com> <3F7197CF.6040907@hp.com>
Message-ID: <Pine.GHP.4.52.0309241954380.17818@garm.adm.ku.dk>

I have tried the two changes but the login/password continues to fail.

Jan p. Sorensen

On Wed, 24 Sep 2003, Michael Steffens wrote:

> Michael Steffens wrote:
> > Jan P. Sorensen wrote:
> >
> >> Yes, HP-UX is run in trusted mode.
> >>
> >> Notice that the problem first appeared today when I upgraded from p1 to
> >> p2.
> >
> >
> > The relevant difference is that p1 had PAM enabled by default, while
> > it was disabled in p2.
> >
> > So it refers to non-PAM password authentication, which is broken
> > in both for trusted systems and those using shadow passwords.
> >
> > Does
> >
> >   http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view
> >
> > fix it?
>
> Sorry, the patch above is against CVS version and needs autoconf
> and autoheader to be run before configure.
>
> In order to achieve the same result in release version without these
> tools you may comment out or remove
>
>    #define DISABLE_SHADOW
>
> in config.h after running configure.  Then apply the patch above
> concerning openbsd-compat/xcrypt.c
>
>
>



From olemx at ans.pl  Thu Sep 25 04:43:25 2003
From: olemx at ans.pl (Krzysztof Oledzki)
Date: Wed, 24 Sep 2003 20:43:25 +0200 (CEST)
Subject: Fix checking password from /etc/passwd and /etc/shadow
In-Reply-To: <Pine.BSO.4.44.0309241150160.842-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.33.0309242040050.24088-100000@dark.pcgames.pl>



On Wed, 24 Sep 2003, Ben Lindstrom wrote:

>
>
> On Wed, 24 Sep 2003, Krzysztof Oledzki wrote:
>
> >
> >
> > On Wed, 24 Sep 2003, Michael Steffens wrote:
> >
> > > Krzysztof Oledzki wrote:
> > > > Hello,
> > > >
> > > > This patch fix order of checking password in systems that contains
> > > > /etc/shadow file (Linux for example). The order is exactly like in
> > > > linux-shadow-password package. First is checked /etc/passwd but if
> > > > password field contains "x" then password is read from /etc/shadow
> > > > instead.
> > >
> > > What is wrong with the current approach of first checking /etc/shadow
> > > using getspnam, falling back to /etc/passwd if the first didn't return
> > > anything?
> > >
> > > Reversing that order and making the decision depend on a non-zero
> > > value returned from /etc/passwd ("x", "*", whatever?) looks like
> > > making it more complicated to me.
> >
> > If /etc/passwd contains:
> >
> > aqq::1001:100:Aqq:/home/aqq:/bin/bash
> >
> > and /etc/shadow:
> > aqq:!:12319:0:99999:7:::
> >
> > Then login allows to log this user with empty password but openssh not.
> >
>
> To me this is a bug in the Linux code.   /etc/shadow should take priority
> over /etc/password.

OK. This "bug" looks like this:

#ifdef SHADOWPWD
                spwd = NULL;
                if (pwd
                    && strcmp (pwd->pw_passwd,
                               SHADOW_PASSWD_STRING) == 0) {
                        spwd = getspnam (username);
                        if (spwd)
                                pwent.pw_passwd = spwd->sp_pwdp;
                        else
                                SYSLOG ((LOG_WARN,
                                         "no shadow password for `%s'%s",
                                         username, fromhost));
                }
#endif                          /* SHADOWPWD */


>  ALWAYS.
If you say so... ;-)


Best Regards,

				Krzysztof Ol?dzki



From km172 at daimlerchrysler.com  Thu Sep 25 05:07:57 2003
From: km172 at daimlerchrysler.com (km172 at daimlerchrysler.com)
Date: Wed, 24 Sep 2003 15:07:57 -0400
Subject: sshd terminates a session after a successful login
Message-ID: <OF1BFBD0D1.BCE267CE-ON85256DAB.00674CEE@wk.dcx.com>

I've recently upgraded our environment to OpenSSH-3.7.1p1 on Solaris, AIX
and IRIX.  I have had no luck when it comes to getting the IRIX environment
to work.  With sshd running on an IRIX server, I connect with any other
version/OS ssh, watch the connection establish, get right up to the point
where the shell should spawn and sshd terminates.  I have been unable to
find any information online regarding this behavior and am looking for any
assistance possible.  I upgraded the IRIX version to OpenSSH-3.7.1p2, but
the behavior still happens.  Interestingly, OpenSSH-3.4p1 works properly in
this environment.

The servers are running IRIX 6.5.13m.

Please cc: me on any replies as I am not subscribed to this list.

Thanks in advance,
Ken Monville

(I'm running the new version on port 2200 for testing purposes, I have the
same result if it's on port 22 as well.)

IRIX sshd 3.7.1p2 output:
{root at dsm1} /etc/ssh2 % /usr/local/openssh-3.7.1p2/sbin/sshd -dd -f
/etc/ssh2/sshd_config
debug2: read_server_config: filename /etc/ssh2/sshd_config
debug1: sshd version OpenSSH_3.7.1p2
debug1: read PEM private key done: type DSA
debug1: private host key: #0 type 2 DSA
debug1: Bind to port 2200 on 0.0.0.0.
Server listening on 0.0.0.0 port 2200.
debug1: Server will not fork when running in debugging mode.
Connection from 53.233.36.117 port 42662
debug1: Client protocol version 2.0; client software version
OpenSSH_3.7.1p1
debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: list_hostkey_types: 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-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
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: 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
debug2: dh_gen_key: priv key bits set: 136/256
debug2: bits set: 1602/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 1607/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user kjm service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for kjm
debug2: input_userauth_request: try method none
Failed none for kjm from 53.233.36.117 port 42662 ssh2
debug1: userauth-request for user kjm 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: 2196/20 (e=0/0)
debug1: trying public key file /usr/people/kjm/.ssh/authorized_keys2
debug1: matching key found: file /usr/people/kjm/.ssh/authorized_keys2,
line 1
Found matching DSA key: 3f:00:1c:20:01:12:7e:be:ee:6b:4e:d8:cb:8a:b5:29
debug1: restore_uid: 0/0
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Postponed publickey for kjm from 53.233.36.117 port 42662 ssh2
debug1: userauth-request for user kjm service ssh-connection method
publickey
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method publickey
debug1: temporarily_use_uid: 2196/20 (e=0/0)
debug1: trying public key file /usr/people/kjm/.ssh/authorized_keys2
debug1: matching key found: file /usr/people/kjm/.ssh/authorized_keys2,
line 1
Found matching DSA key: 3f:00:1c:20:01:12:7e:be:ee:6b:4e:d8:cb:8a:b5:29
debug1: restore_uid: 0/0
debug1: ssh_dss_verify: signature correct
debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss
Accepted publickey for kjm from 53.233.36.117 port 42662 ssh2
debug1: Entering interactive session for SSH2.
debug2: fd 3 setting O_NONBLOCK
debug2: fd 7 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/ttyq2
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
debug2: bind port 6010: Address already in use
debug2: fd 10 setting O_NONBLOCK
debug2: fd 10 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
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: rfd 9 isatty
debug2: fd 9 setting O_NONBLOCK
debug2: fd 8 is O_NONBLOCK
debug2: channel 0: read<=0 rfd 9 len 0   <<<<<<<<<<--------- Appears to be
where it is closing the connection?
debug1: Received SIGCHLD.
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug2: notify_done: reading
debug1: session_by_pid: pid 50804544
debug1: session_exit_message: session 0 channel 0 pid 50804544
debug2: channel 0: request exit-signal
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug1: session_close: session 0 pid 50804544
debug1: session_pty_cleanup: session 0 release /dev/ttyq2
debug2: channel 0: send close
debug2: channel 0: rcvd close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: server-session, nchannels 2
Connection closed by 53.233.36.117
debug1: channel 1: free: X11 inet listener, nchannels 1
Closing connection to 53.233.36.117


Linux ssh 3.7.1p1 output:
{kjm at agusta} /home/kjm % ssh -vv -p 2200 dsm1
OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to dsm1 [152.116.117.24] port 2200.
debug1: Connection established.
debug1: identity file /home/kjm/.ssh/identity type -1
debug1: identity file /home/kjm/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/kjm/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p1
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,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
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
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 1625/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'dsm1' is known and matches the DSA host key.
debug1: Found key in /home/kjm/.ssh/known_hosts:188
debug2: bits set: 1627/3191
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/kjm/.ssh/identity ((nil))
debug2: key: /home/kjm/.ssh/id_rsa ((nil))
debug2: key: /home/kjm/.ssh/id_dsa (0x8103d58)
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kjm/.ssh/identity
debug1: Trying private key: /home/kjm/.ssh/id_rsa
debug1: Offering public key: /home/kjm/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok: fp
3f:00:1c:20:01:12:7e:be:ee:6b:4e:d8:cb:8a:b5:29
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug2: channel 0: request pty-req
debug2: x11_get_proto: /usr/X11R6/bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req
debug2: channel 0: request shell
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Wed Sep 24 15:02:08 2003 from agusta.tcc.chrysler.com
<<<<<<------- Successful authentication? Then terminates...
debug1: permanently_set_uid: 2196/20
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
Connection to dsm1 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 28 bytes in 0.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 64.9
debug1: Exit status -1

--
Ken Monville - <km172 at daimlerchrysler.com>
DaimlerChrysler Corporation
Unix System Administrator - Unix Systems Management Group
Tel: 248.576.3842




From lbecke at mchsi.com  Thu Sep 25 05:51:36 2003
From: lbecke at mchsi.com (lbecke at mchsi.com)
Date: Wed, 24 Sep 2003 19:51:36 +0000
Subject: OpenSSH 3.7.1p2-pwexp24.patch
Message-ID: <20030924194807.BAE7C27C187@shitei.mindrot.org>

I would also like to thank the group for this patch.
The patch applied without error.
The configure worked as expected.
The make built the binaries properly.
The sshd server worked properly, when tested with the UsePAM=yes and UsePAM=no 
on Solaris 5.8.  
I've built the packages, and currently await approval to distribute the package 
to the remainder of our servers.

Job well done, and greatly appreciated.

Let's hope this is the last round of emergency changes for a bit, so you all 
can get some sleep.



From mouring at etoh.eviladmin.org  Thu Sep 25 06:55:25 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 24 Sep 2003 15:55:25 -0500 (CDT)
Subject: Fix checking password from /etc/passwd and /etc/shadow
In-Reply-To: <Pine.LNX.4.33.0309242040050.24088-100000@dark.pcgames.pl>
Message-ID: <Pine.BSO.4.44.0309241548040.842-100000@etoh.eviladmin.org>



On Wed, 24 Sep 2003, Krzysztof Oledzki wrote:

[..]
> > To me this is a bug in the Linux code.   /etc/shadow should take priority
> > over /etc/password.
>
> OK. This "bug" looks like this:
[..]

Great, this goes to show when you get a bunch of monkeys in a room they
can implement things incorrectly.  Actually, I change my mind.  This is
not a 'bug'.  Moronic misfeature is a better term.

>
> >  ALWAYS.
> If you say so... ;-)
>

Not only I, but other well-established commerical UNIX vendors implement
it is /etc/shadow then /etc/passwd.

- Ben



From dtucker at zip.com.au  Thu Sep 25 07:04:29 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 25 Sep 2003 07:04:29 +1000
Subject: sshd terminates a session after a successful login
References: <OF1BFBD0D1.BCE267CE-ON85256DAB.00674CEE@wk.dcx.com>
Message-ID: <3F7206DD.20C8E201@zip.com.au>

km172 at daimlerchrysler.com wrote:
> 
> I've recently upgraded our environment to OpenSSH-3.7.1p1 on Solaris, AIX
> and IRIX.  I have had no luck when it comes to getting the IRIX environment
> to work.  With sshd running on an IRIX server, I connect with any other
> version/OS ssh, watch the connection establish, get right up to the point
> where the shell should spawn and sshd terminates.  I have been unable to
> find any information online regarding this behavior and am looking for any
> assistance possible.  I upgraded the IRIX version to OpenSSH-3.7.1p2, but
> the behavior still happens.  Interestingly, OpenSSH-3.4p1 works properly in
> this environment.
> 
> The servers are running IRIX 6.5.13m.

Hmm, I thought that problem has been fixed in openssh-3.7.1p2.

Please post the server-side debugging (eg "sshd -ddd -p 2022" and "ssh -p
2022 localhost").

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



From dustin at intrcomm.net  Thu Sep 25 09:07:45 2003
From: dustin at intrcomm.net (Dustin D Butler)
Date: Wed, 24 Sep 2003 17:07:45 -0600
Subject: Bug #652 and PermitEmptyPasswords
Message-ID: <200309242307.h8ON7jNH008440@intrbox.co.intrcomm.net>

If I have

PasswordAuthentication yes
PermitEmptyPasswords no

I'm not able to log in using authorized key authentication if my password is blank.  This changed when upgrading from portable 3.7.1p1 to 3.7.1p2.  My thoughts were PermitEmptyPasswords would only be used if authenticating with a password.

./configure --with-pam --prefix=/usr --sysconfdir=/etc/ssh --with-default-path=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Peace,
Dustin
ICQ: 77617603



From jeremyp8 at hotmail.com  Thu Sep 25 09:18:15 2003
From: jeremyp8 at hotmail.com (Jeremy Peterson)
Date: Wed, 24 Sep 2003 19:18:15 -0400
Subject: hostbased authentication/reverse name lookup
Message-ID: <BAY9-F681djns2vUJEx00021289@hotmail.com>

Hi,

I'm not sure if this is the right place to post this... sorry in advance if 
it's not.

I've been trying to use ip addresses for hostbased authentication. It 
doesn't seem to work unless the ip addresses can be reverse resolved. I've 
found some messages related to this. In fact, it seems that this question 
was asked before on this list, but I could not find a direct answer to this 
question.

Is it possible to use ip addresses that cannot be reverse resolved for 
hostbased authentication?
If so, how?
If not, why not?

Is there any documentation I missed?

Thanks,
JP

_________________________________________________________________
Frustrated with dial-up? Get high-speed for as low as $29.95/month 
(depending on the local service providers in your area).  
https://broadband.msn.com



From mouring at etoh.eviladmin.org  Thu Sep 25 10:04:00 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 24 Sep 2003 19:04:00 -0500 (CDT)
Subject: Patches for compatibility with Heimdal's libsia_krb5 SIA module
In-Reply-To: <20030924152013.GA3495@hanuman.astro.su.se>
Message-ID: <Pine.BSO.4.44.0309241900340.842-100000@etoh.eviladmin.org>


Is SIA used on any other platform besides Tru64/OSF?  I'm thinking if not
it should be moved to openbsd-compat/port-osf.[ch] and the two definitions
put into openbsd-compat/openbsd-compat.h.

- Ben


On Wed, 24 Sep 2003, Sergio Gelato wrote:

> I have found the following patches to be desirable for using sshd on a
> Tru64 UNIX system with the Kerberos 5 SIA module (libsia_krb5.so) from
> Heimdal.
>
> These patches do the following:
>
> 1) preserve context between the password authentication and the session
> setup phases. This is necessary because the Heimdal SIA module stores
> Kerberos context information as mechanism-specific data in ent->mech[].
>
> 2) Allow for the KRB5CCNAME environment variable (potentially set in
> session_setup_sia()) to be propagated to the session environment.
>
> Caveat: I have only tested this with the BSD and Heimdal KRB5 modules,
> not with OSFC2 or any other SIA module.
>
> To do:
>
> * clean up the Kerberos credentials cache at session exit. Unfortunately
> SIA is not invoked at this time, so this cannot be done in the SIA module.
>
> * review what happens if authentication succeeds but session_setup_sia() is
> not invoked for some reason. Currently the sia_ses_release() clean-up
> code will not be invoked in this case. For most SIA modules this shouldn't
> matter, as resources will be released at process exit; but it would be
> nice to get it right anyway.
>



From Brian.Williams at NBNZ.CO.NZ  Thu Sep 25 12:16:12 2003
From: Brian.Williams at NBNZ.CO.NZ (Wiliams, Brian)
Date: Thu, 25 Sep 2003 14:16:12 +1200
Subject: sshd (openssh 3.7.1p1) dies during login on Solaris 8 system with
	SRM installed
Message-ID: <5FA85DB5FB07D7118CF50002A5754C0901D442A5@nbnzhexch2.nbnz.co.nz>


I have compiled ssh 3.7.1p1 using gcc and am trying to get it to run on our
Solaris 8 systems running Sun's SRM system.
With existing users it is fine, but with a new user, the user can not ssh in
on the first login, they get the message from SRM that no lnode has been
created.

I put sshd in debug and found that it SEG's here:

debug3: mm_sshpam_free_ctx: waiting for MONITOR_ANS_PAM_FREE_CTX
debug3: monitor_read: checking request 52
debug3: mm_answer_pam_free_ctx
debug3: mm_request_receive_expect entering: type 53
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 53
debug2: monitor_read: 52 used once, disabling now
debug3: mm_do_pam_account entering
debug3: mm_request_receive_expect entering: type 44
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 44
debug3: mm_request_receive_expect entering: type 45
debug3: mm_request_receive entering
debug1: Calling cleanup 0x4af30(0x0)
Bus Error


I trussed the process and see :

1061:   time()                                          = 1064443974
1061:   sigaction(0x0000000C, 0xFFBEEDD8, 0xFFBEEE58)   = 0
1061:       new: hand = 0xFF19E92C mask = 0 0 0 0 flags = 0x0012
1061:       old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0000
1061:   sys#177(0x0000007B, 0xFFBEEEFC, 0xFEE090A0)     = 0x00000000
[0x0000007B]
1061:   sigaction(0x0000000C, 0xFFBEEDD8, 0xFFBEEE58)   = 0
1061:       new: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0012
1061:       old: hand = 0xFF19E92C mask = 0 0 0 0 flags = 0x0012
1061:   door(3, 0xFFBEE9E8)                             = 0
1061:   door(3, 0xFFBEE9D0)                             = 0
1061:   open(0xFF0C4D94, 0)                             = 9
1061:        0xFF0C4D94: "/etc/passwd"
1061:   fstat64(9, 0xFFBEE630)                          = 0
1061:       d=0x0154000A i=197963 m=0100444 l=1  u=0     g=3     sz=1462
1061:           at = Sep 25 10:52:54 NZST 2003  [ 1064443974 ]
1061:           mt = Sep 25 10:45:07 NZST 2003  [ 1064443507 ]
1061:           ct = Sep 25 10:45:07 NZST 2003  [ 1064443507 ]
1061:       bsz=8192  blks=4     fs=ufs
1061:   ioctl(9, 0x00005401, 0xFFBEE5BC)                Err#25 ENOTTY
1061:   read(9, 0x00160CCC, 8192)                       = 1462
1061:        0x00160CCC: " r o o t : x : 0 : 1 : S"..
1061:   llseek(9, 0xFFFFFFFFFFFFFFBF, 1)                = 1397
1061:   close(9)                                        = 0
1061:   sys#177(0x00000079, 0x000023B8, 0x001608C8)     Err#2 ENOENT
1061:       Incurred fault #5, FLTACCESS  %pc = 0xFEE129C0
1061:         siginfo: SIGBUS BUS_ADRALN addr=0xFF1BFAE6
1061:       Received signal #10, SIGBUS [default]
1061:         siginfo: SIGBUS BUS_ADRALN addr=0xFF1BFAE6
1061:           *** process killed ***
1062:   read(9, 0xFFBEF320, 4)                          = 0
1062:   write(2, 0xFFBEEDD0, 38)                        = 38
1062:        0xFFBEEDD0: " d e b u g 1 :   C a l l"..
1062:   shutdown(6, 2, 1)                               = 0
1062:   close(6)                                        = 0
1062:   llseek(0, 0, 1)                                 = 209524
1062:   _exit(255)

does any one know why sshd is getting the bus error?

anyone seen something similar? 

could this be similar to the sparcv9 issue?

Thanks
Brian

Brian Williams
Contractor
National Bank of New Zealand
Phone: IN 247451


This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.



From mouring at etoh.eviladmin.org  Thu Sep 25 12:24:05 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 24 Sep 2003 21:24:05 -0500 (CDT)
Subject: sshd (openssh 3.7.1p1) dies during login on Solaris 8 system
 with SRM installed
In-Reply-To: <5FA85DB5FB07D7118CF50002A5754C0901D442A5@nbnzhexch2.nbnz.co.nz>
Message-ID: <Pine.BSO.4.44.0309242123570.842-100000@etoh.eviladmin.org>


Try 3.7.1p2

On Thu, 25 Sep 2003, Wiliams, Brian wrote:

>
> I have compiled ssh 3.7.1p1 using gcc and am trying to get it to run on our
> Solaris 8 systems running Sun's SRM system.
> With existing users it is fine, but with a new user, the user can not ssh in
> on the first login, they get the message from SRM that no lnode has been
> created.
>
> I put sshd in debug and found that it SEG's here:
>
> debug3: mm_sshpam_free_ctx: waiting for MONITOR_ANS_PAM_FREE_CTX
> debug3: monitor_read: checking request 52
> debug3: mm_answer_pam_free_ctx
> debug3: mm_request_receive_expect entering: type 53
> debug3: mm_request_receive entering
> debug3: mm_request_send entering: type 53
> debug2: monitor_read: 52 used once, disabling now
> debug3: mm_do_pam_account entering
> debug3: mm_request_receive_expect entering: type 44
> debug3: mm_request_receive entering
> debug3: mm_request_send entering: type 44
> debug3: mm_request_receive_expect entering: type 45
> debug3: mm_request_receive entering
> debug1: Calling cleanup 0x4af30(0x0)
> Bus Error
>
>
> I trussed the process and see :
>
> 1061:   time()                                          = 1064443974
> 1061:   sigaction(0x0000000C, 0xFFBEEDD8, 0xFFBEEE58)   = 0
> 1061:       new: hand = 0xFF19E92C mask = 0 0 0 0 flags = 0x0012
> 1061:       old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0000
> 1061:   sys#177(0x0000007B, 0xFFBEEEFC, 0xFEE090A0)     = 0x00000000
> [0x0000007B]
> 1061:   sigaction(0x0000000C, 0xFFBEEDD8, 0xFFBEEE58)   = 0
> 1061:       new: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0012
> 1061:       old: hand = 0xFF19E92C mask = 0 0 0 0 flags = 0x0012
> 1061:   door(3, 0xFFBEE9E8)                             = 0
> 1061:   door(3, 0xFFBEE9D0)                             = 0
> 1061:   open(0xFF0C4D94, 0)                             = 9
> 1061:        0xFF0C4D94: "/etc/passwd"
> 1061:   fstat64(9, 0xFFBEE630)                          = 0
> 1061:       d=0x0154000A i=197963 m=0100444 l=1  u=0     g=3     sz=1462
> 1061:           at = Sep 25 10:52:54 NZST 2003  [ 1064443974 ]
> 1061:           mt = Sep 25 10:45:07 NZST 2003  [ 1064443507 ]
> 1061:           ct = Sep 25 10:45:07 NZST 2003  [ 1064443507 ]
> 1061:       bsz=8192  blks=4     fs=ufs
> 1061:   ioctl(9, 0x00005401, 0xFFBEE5BC)                Err#25 ENOTTY
> 1061:   read(9, 0x00160CCC, 8192)                       = 1462
> 1061:        0x00160CCC: " r o o t : x : 0 : 1 : S"..
> 1061:   llseek(9, 0xFFFFFFFFFFFFFFBF, 1)                = 1397
> 1061:   close(9)                                        = 0
> 1061:   sys#177(0x00000079, 0x000023B8, 0x001608C8)     Err#2 ENOENT
> 1061:       Incurred fault #5, FLTACCESS  %pc = 0xFEE129C0
> 1061:         siginfo: SIGBUS BUS_ADRALN addr=0xFF1BFAE6
> 1061:       Received signal #10, SIGBUS [default]
> 1061:         siginfo: SIGBUS BUS_ADRALN addr=0xFF1BFAE6
> 1061:           *** process killed ***
> 1062:   read(9, 0xFFBEF320, 4)                          = 0
> 1062:   write(2, 0xFFBEEDD0, 38)                        = 38
> 1062:        0xFFBEEDD0: " d e b u g 1 :   C a l l"..
> 1062:   shutdown(6, 2, 1)                               = 0
> 1062:   close(6)                                        = 0
> 1062:   llseek(0, 0, 1)                                 = 209524
> 1062:   _exit(255)
>
> does any one know why sshd is getting the bus error?
>
> anyone seen something similar?
>
> could this be similar to the sparcv9 issue?
>
> Thanks
> Brian
>
> Brian Williams
> Contractor
> National Bank of New Zealand
> Phone: IN 247451
>
>
> This communication is confidential and may contain privileged material.
> If you are not the intended recipient you must not use, disclose, copy or retain it.
> If you have received it in error please immediately notify me by return email
> and delete the emails.
> Thank you.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dtucker at zip.com.au  Thu Sep 25 12:31:47 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 25 Sep 2003 12:31:47 +1000
Subject: sshd (openssh 3.7.1p1) dies during login on Solaris 8 system
 withSRM installed
References: <5FA85DB5FB07D7118CF50002A5754C0901D442A5@nbnzhexch2.nbnz.co.nz>
Message-ID: <3F725393.311CDAB6@zip.com.au>

"Wiliams, Brian" wrote:
> 
> I have compiled ssh 3.7.1p1 using gcc and am trying to get it to run on our
> Solaris 8 systems running Sun's SRM system.
> With existing users it is fine, but with a new user, the user can not ssh in
> on the first login, they get the message from SRM that no lnode has been
> created.

Please try 3.7.1p2 as there have been fixes for PAM and the handling of
/etc/default/login on Solaris.

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



From mweiser at fachschaft.imn.htwk-leipzig.de  Thu Sep 25 16:41:10 2003
From: mweiser at fachschaft.imn.htwk-leipzig.de (Michael Weiser)
Date: Thu, 25 Sep 2003 08:41:10 +0200 (CEST)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.LNX.4.58.0309240902390.24988@heinz.dinsnail.net>
References: <Pine.BSO.4.44.0309230911190.842-100000@etoh.eviladmin.org>
	<Pine.LNX.4.58.0309240902390.24988@heinz.dinsnail.net>
Message-ID: <Pine.LNX.4.58.0309250837050.12554@heinz.dinsnail.net>

On Wed, 24 Sep 2003, Michael Weiser wrote:

> recall mysignal!? Is perhaps the #define wreaking havoc with the actual 
> signal call in bsd-misc.h so that it recursively calls itself until it 
> crashes?
Indeed it seems to be that the #define signal mysignal changes the
signal() call in mysignal() into mysignal() and thus makes it resursive
which looks like hanging or gives a segfault in gdb (perhaps because of a
smaller stack there). If I add an #undef signal just before the signal
call in bsd-misc.c sshd behaves normally. This would seem to be a bug for
all platforms that doen't have sigaction() and use just signal. Another
workaround might be to always employ the sigaction() emulation of
openbsd-compat for bsd-misc, even if HAVE_SIGACTION is undefined.

Hope that helps.
-- 
bye, Micha
heinz rulez!



From km172 at daimlerchrysler.com  Thu Sep 25 22:54:39 2003
From: km172 at daimlerchrysler.com (km172 at daimlerchrysler.com)
Date: Thu, 25 Sep 2003 08:54:39 -0400
Subject: sshd terminates a session after a successful login
Message-ID: <OF863997A5.3A3A2D26-ON85256DAC.0045D776@wkamerica.notes.chrysler.com>





Darren Tucker wrote:
>Hmm, I thought that problem has been fixed in openssh-3.7.1p2.
>
>Please post the server-side debugging (eg "sshd -ddd -p 2022" and "ssh -p
>2022 localhost").

Server side debugging:

debug3: Seeding PRNG from /usr/local/openssh-3.7.1
p2/libexec/ssh-rand-helper
debug2: read_server_config: filename /etc/ssh/sshd_config
debug1: sshd version OpenSSH_3.7.1p2
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #0 type 2 DSA
debug1: Bind to port 2200 on 0.0.0.0.
Server listening on 0.0.0.0 port 2200.
debug1: Server will not fork when running in debugging mode.
Connection from 127.0.0.1 port 45662
debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat
OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: list_hostkey_types: 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-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,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
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 112/256
debug2: bits set: 1592/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 1597/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user kjm service ssh-connection method none
debug1: attempt 0 failures 0
debug3: allowed_user: today 12320 sp_expire -1 sp_lstchg 12026 sp_max -1
debug2: input_userauth_request: setting up authctxt for kjm
debug2: input_userauth_request: try method none
Failed none for kjm from 127.0.0.1 port 45662 ssh2
debug1: userauth-request for user kjm 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: 2196/20 (e=0/0)
debug1: trying public key file /usr/people/kjm/.ssh/authorized_keys2
debug3: secure_filename: checking '/usr/people/kjm/.ssh'
debug3: secure_filename: checking '/usr/people/kjm'
debug3: secure_filename: terminating check at '/usr/people/kjm'
debug1: restore_uid: 0/0
debug2: key not found
debug1: temporarily_use_uid: 2196/20 (e=0/0)
debug1: trying public key file /usr/people/kjm/.ssh/authorized_keys2
debug3: secure_filename: checking '/usr/people/kjm/.ssh'
debug3: secure_filename: checking '/usr/people/kjm'
debug3: secure_filename: terminating check at '/usr/people/kjm'
debug1: restore_uid: 0/0
debug2: key not found
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Failed publickey for kjm from 127.0.0.1 port 45662 ssh2
debug1: userauth-request for user kjm service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=kjm devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
Failed keyboard-interactive for kjm from 127.0.0.1 port 45662 ssh2
debug1: userauth-request for user kjm service ssh-connection method password
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method password
Accepted password for kjm from 127.0.0.1 port 45662 ssh2
debug1: Entering interactive session for SSH2.
debug2: fd 3 setting O_NONBLOCK
debug2: fd 7 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/ttyq5
debug3: tty_parse_modes: SSH2 n_bytes 266
debug3: tty_parse_modes: ospeed 38400
debug3: tty_parse_modes: ispeed 38400
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 0
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 0
debug3: tty_parse_modes: 31 0
debug3: tty_parse_modes: 32 0
debug3: tty_parse_modes: 33 0
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 0
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 x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: X11 forwarding disabled in server configuration file.
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
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: rfd 9 isatty
debug2: fd 9 setting O_NONBLOCK
debug2: fd 8 is O_NONBLOCK
debug2: channel 0: read<=0 rfd 9 len 0
debug1: Received SIGCHLD.
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug2: notify_done: reading
debug1: session_by_pid: pid 56395638
debug1: session_exit_message: session 0 channel 0 pid 56395638
debug2: channel 0: request exit-signal
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug1: session_close: session 0 pid 56395638
debug1: session_pty_cleanup: session 0 release /dev/ttyq5
debug2: channel 0: send close
debug3: channel 0: will not send data after close
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: server-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel 0: close_fds r -1 w -1 e -1
Connection closed by 127.0.0.1
Closing connection to 127.0.0.1
--
Ken Monville - <km172 at daimlerchrysler.com>
DaimlerChrysler Corporation
Unix System Administrator - Unix Systems Management Group
Tel: 248.576.3842



From michael.steffens at hp.com  Thu Sep 25 23:30:41 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Thu, 25 Sep 2003 15:30:41 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <Pine.GHP.4.52.0309241954380.17818@garm.adm.ku.dk>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com> <3F7197CF.6040907@hp.com>
	<Pine.GHP.4.52.0309241954380.17818@garm.adm.ku.dk>
Message-ID: <3F72EE01.1020507@hp.com>

Jan P. Sorensen wrote:
> I have tried the two changes but the login/password continues to fail.

I have attached a patch against 3.7.1p2, which worked for me in trusted
and non-trusted mode, including long passwords in trusted mode, with and
without privsep, both proto 1 and 2.

Does that help?

Cheers!
Michael
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hpux-shadow.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030925/809b0ddb/attachment.ksh 

From mouring at etoh.eviladmin.org  Thu Sep 25 23:32:40 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 25 Sep 2003 08:32:40 -0500 (CDT)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.LNX.4.58.0309250837050.12554@heinz.dinsnail.net>
Message-ID: <Pine.BSO.4.44.0309250824430.842-100000@etoh.eviladmin.org>


Right.. Right.. I didn't see it when I running cpp over the file since for
some reason my preproccessor under Linux didn't change signal() to
mysignal() in bsd-misc.c, but there should be an #undef signal before the
return(signal(..)) to ensure the real signal gets used.

I'm still puzzled why NeXT triggers this because NeXT's signal() has too
loose of sementics for what we want and it should have defaulted to using
the HAVE_SIGACTION.

I remember having to dig around for a tolerable replacement for NeXT

Revision 1.1 / (download) - [select for diffs] , Sun Jul 9 13:26:27 2000
UTC (3 years, 2 months ago) by djm
- (djm) More NeXT compatibility from Ben Lindstrom <mouring at pconline.com>
   Including sigaction() et al. replacements

This troubles me greatly.

- Ben


On Thu, 25 Sep 2003, Michael Weiser wrote:

> On Wed, 24 Sep 2003, Michael Weiser wrote:
>
> > recall mysignal!? Is perhaps the #define wreaking havoc with the actual
> > signal call in bsd-misc.h so that it recursively calls itself until it
> > crashes?
> Indeed it seems to be that the #define signal mysignal changes the
> signal() call in mysignal() into mysignal() and thus makes it resursive
> which looks like hanging or gives a segfault in gdb (perhaps because of a
> smaller stack there). If I add an #undef signal just before the signal
> call in bsd-misc.c sshd behaves normally. This would seem to be a bug for
> all platforms that doen't have sigaction() and use just signal. Another
> workaround might be to always employ the sigaction() emulation of
> openbsd-compat for bsd-misc, even if HAVE_SIGACTION is undefined.
>
> Hope that helps.
> --
> bye, Micha
> heinz rulez!
>



From mweiser at fachschaft.imn.htwk-leipzig.de  Fri Sep 26 00:21:30 2003
From: mweiser at fachschaft.imn.htwk-leipzig.de (Michael Weiser)
Date: Thu, 25 Sep 2003 16:21:30 +0200 (CEST)
Subject: openssh on NeXTstep
In-Reply-To: <Pine.BSO.4.44.0309250824430.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309250824430.842-100000@etoh.eviladmin.org>
Message-ID: <Pine.LNX.4.58.0309251616200.26287@heinz.dinsnail.net>

On Thu, 25 Sep 2003, Ben Lindstrom wrote:

> I'm still puzzled why NeXT triggers this because NeXT's signal() has too
> loose of sementics for what we want and it should have defaulted to using
> the HAVE_SIGACTION.
Might it have something to do with the fact that I'm using a self-compiled
gcc-2.95.4 instead of the system's gcc-2.5.8? I don't really think so but
there is libiberty and libgcc which might provide another signal(). Also
configure often gets confused by the fact that there are headers and
function definitions where there are no real implementations for. Not
least mysignal() has been moved to bsd-misc.c inbetween openssh-3.6.1p2
and openssh-3.7p1 which might have caused the #if's to break.

One example: mmap is there and works, but not on /dev/zero and munmap can
only be reached via an explicit syscall - there's no stub in
libsys_s.shlib or any other library. So I agree that NeXTstep is quite
weird in some respects but this is continued in MacOS X as well.
-- 
bye, Micha



From ekcheu at uncg.edu  Fri Sep 26 00:24:08 2003
From: ekcheu at uncg.edu (ERIC K. CHEU)
Date: Thu, 25 Sep 2003 10:24:08 -0400 (EDT)
Subject: openssh 3.7.1p2 afs/pam issues
Message-ID: <Pine.GSO.4.58.0309251019580.1411@supernova.uncg.edu>


I've been trying to get a working version of openssh-3.7.1p2 as well.
Unfortunately, afs support has been pulled, and the patch posted on the
openafs list coredumps when I compile it.  The new way that pam is done
also introduces errors since pam_authenticate is supposedly called in a
seperate thread so that the correct environmental variables are not
passed.  Even after applying some changes on the openafs list, I'm still
not able to get tokens (although I am able to log in at least) when
logging in.

I've noticed that the new version also breaks Putty using protocol version
2 with AFS (although it works okay if you don't use pam or if you log into
a local account, such as root).



From eddy at cdf-imaging.com  Fri Sep 26 00:56:46 2003
From: eddy at cdf-imaging.com (Edward Flick)
Date: Thu, 25 Sep 2003 09:56:46 -0500
Subject: Apology
Message-ID: <DBEJKFKIDIDOKKCGEDHMOEAICJAA.eddy@cdf-imaging.com>

Hello everyone,
I have recently sent out a message to all my contacts, forgetting to take
out all of my list-addresses.  I am sincerely sorry if this message got
through to you, and if it offended you.  I meant it only for the people that
I knew.  Again, if the possibly offending message even got through onto the
list (I think most of the lists bounced it anyways), then I apologize for
any problems this may have caused.

Sincerely,
Edward Flick



From djast at cs.toronto.edu  Fri Sep 26 02:00:53 2003
From: djast at cs.toronto.edu (Dan Astoorian)
Date: Thu, 25 Sep 2003 12:00:53 -0400
Subject: unexpected change in "locked account" behaviour
Message-ID: <03Sep25.120054edt.453264-9446@jane.cs.toronto.edu>

I just ran into what I'd describe as an unexpected side-effect.  I don't
think it's necessarily a bug, and I don't need any assistance in working
around it, but this information might be useful to others for
troubleshooting.

This was using OpenSSH built under Solaris 2.5.1, and running under
2.5.1 or 8.

The symptom was that after upgrading from 3.7.1p1 to 3.7.1p2, some
accounts could no longer log in via ssh using hostbased authentication.

The affected accounts were those with "*LK*" in the shadow file's
password field (and my actual problem was that I had "*LK*" where I
should have had "NP").

I believe the reason for the behaviour change is the change of the
default for options.use_pam.  The reason I find this particularly
strange is that USE_PAM is not even #defined (e.g., UsePam cannot be
specified in sshd_config).

The code which is being affected by the
change is in auth.c:

|         /* check for locked account */
|         if (!options.use_pam && passwd && *passwd) {
|                 int locked = 0;
| 
| #ifdef LOCKED_PASSWD_STRING
|                 if (strcmp(passwd, LOCKED_PASSWD_STRING) == 0)
|                          locked = 1;
| #endif
[...]

I think the current behaviour is more correct than the previous
behaviour, so I haven't filed a bug.

I haven't checked whether there are other places in the code where
options.use_pam has side effects that could be affected by the change in
the default.

If other people who compile OpenSSH without PAM support have similar
problems, this might be helpful to know.

Is this a known behaviour?

Thanks,

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican



From mouring at etoh.eviladmin.org  Fri Sep 26 02:13:08 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 25 Sep 2003 11:13:08 -0500 (CDT)
Subject: unexpected change in "locked account" behaviour
In-Reply-To: <03Sep25.120054edt.453264-9446@jane.cs.toronto.edu>
Message-ID: <Pine.BSO.4.44.0309251111270.842-100000@etoh.eviladmin.org>



On Thu, 25 Sep 2003, Dan Astoorian wrote:
[..]
>
> Is this a known behaviour?
>

This had been discussed a lot over the last few months prior to release.
People were complaining (and semi-rightfully so) that OpenSSH was not
honoring *LK* or each platform's version of it.  So user keys were still
usable even after the account itself was locked.

It was decided that we should honor it.=)

- Ben



From mkoeppe at mail.math.uni-magdeburg.de  Fri Sep 26 02:54:43 2003
From: mkoeppe at mail.math.uni-magdeburg.de (Matthias Koeppe)
Date: Thu, 25 Sep 2003 18:54:43 +0200
Subject: Bus Error with openssh 3.7.1p1 on 64-bit Sparc/Solaris
Message-ID: <uw5ad8sdd0s.fsf@merkur.math.uni-magdeburg.de>

I compiled openssh 3.7.1p1 on Solaris 9 with the Forte compiler in
64-bit mode.  After authentication, a forked child of sshd dies with a
Bus Error in `read_etc_default_login' (session.c).

The reason is the use of `sscanf' with control string "%5lo" on a
`mode_t' value.  On Solaris in 64-bit mode, `mode_t' is an `unsigned
int' (32 bits), whereas `long' is 64 bits.

Here is a change that fixed the problem for me.  You might want to fix
it in cleaner way, however.

Regards,
Matthias

diff -u /home/mkoeppe/s/ATTIC/openssh-3.7.1p1/session.c\~ /home/mkoeppe/s/ATTIC/openssh-3.7.1p1/session.c
--- /home/mkoeppe/s/ATTIC/openssh-3.7.1p1/session.c~	Tue Sep 16 03:52:19 2003
+++ /home/mkoeppe/s/ATTIC/openssh-3.7.1p1/session.c	Thu Sep 25 18:50:00 2003
@@ -915,6 +915,7 @@
 	u_int i;
 	size_t tmpenvsize = 0;
 	mode_t mask;
+	unsigned long long_mask;
 
 	/*
 	 * We don't want to copy the whole file to the child's environment,
@@ -931,8 +932,10 @@
 		child_set_env(env, envsize, "PATH", var);
 	
 	if ((var = child_get_env(tmpenv, "UMASK")) != NULL)
-		if (sscanf(var, "%5lo", &mask) == 1)
+		if (sscanf(var, "%5lo", &long_mask) == 1) {
+			mask = (mode_t) long_mask;
 			umask(mask);
+		}
 	
 	for (i = 0; tmpenv[i] != NULL; i++)
 		xfree(tmpenv[i]);

-- 
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe



From tim at multitalents.net  Fri Sep 26 03:41:08 2003
From: tim at multitalents.net (Tim Rice)
Date: Thu, 25 Sep 2003 10:41:08 -0700 (PDT)
Subject: Bus Error with openssh 3.7.1p1 on 64-bit Sparc/Solaris
In-Reply-To: <uw5ad8sdd0s.fsf@merkur.math.uni-magdeburg.de>
References: <uw5ad8sdd0s.fsf@merkur.math.uni-magdeburg.de>
Message-ID: <Pine.UW2.4.58.0309251040100.22465@ou8.int.multitalents.net>

On Thu, 25 Sep 2003, Matthias Koeppe wrote:

> I compiled openssh 3.7.1p1 on Solaris 9 with the Forte compiler in
> 64-bit mode.  After authentication, a forked child of sshd dies with a
> Bus Error in `read_etc_default_login' (session.c).

I think that was fixed in 3.7.1p2

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




From dtucker at zip.com.au  Fri Sep 26 06:55:14 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 26 Sep 2003 06:55:14 +1000
Subject: unexpected change in "locked account" behaviour
References: <03Sep25.120054edt.453264-9446@jane.cs.toronto.edu>
Message-ID: <3F735632.FB6039F9@zip.com.au>

Dan Astoorian wrote:
> The affected accounts were those with "*LK*" in the shadow file's
> password field (and my actual problem was that I had "*LK*" where I
> should have had "NP").
> 
> I believe the reason for the behaviour change is the change of the
> default for options.use_pam.  The reason I find this particularly
> strange is that USE_PAM is not even #defined (e.g., UsePam cannot be
> specified in sshd_config).

In 3.7p1 and 3.7.1p1, if sshd was compiled without USE_PAM,
options.use_pam would still end up being set, even though almost all of
the code that used it was #ifdef'ed out.  The code you quoted still
checked it.

> Is this a known behaviour?

Yes.  The behaviour of 3.7p1 and 3.7.1p1 (ie not checking) when compiled
without PAM was a bug.

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



From vherva at niksula.hut.fi  Fri Sep 26 16:21:28 2003
From: vherva at niksula.hut.fi (Ville Herva)
Date: Fri, 26 Sep 2003 09:21:28 +0300
Subject: 3.7.1p1 (possibly p2, too): two small compilation nits on RedHats
In-Reply-To: <Pine.GSO.4.44.0309250942440.26600-100000@enterprise>
References: <Pine.GSO.4.44.0309250942440.26600-100000@enterprise>
Message-ID: <20030926062128.GA3031@niksula.cs.hut.fi>

(These are compiling the .src.rpm from 
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm/SRPMS/openssh-3.7.1p1-1.src.rpm)

1) On Red Hat 7.3, with gcc-3.2 with the SSP patch 
   (http://www.research.ibm.com/trl/projects/security/ssp/),
  
     rpm --rebuild --define "static_libcrypto 1" openssh-3.7.1p1-1.src.rpm
  
   - I needed to add -ldl to the linker flags before it linked.

2) On Red Hat 5.2, with gcc-2.7.2.3, kernel 2.2.20
  
      rpm -bb openssh-3.7.1p1.src.rpm

   - openbsd-compat/bsd-getpeereid.c didn't find the struct ucred definition
   from /usr/include/linux/socket.h, where it is defined. The reason
   is that linux/socket.h comes from kernel-2.2.x, and sys/socket.h
   (that openssh includes) comes from glibc-devel-2.0.7-29.4, and does not
   include linux/socket.h (and probably assumes kernel-2.0).

   I don't know if configure should pick this up... Probably not.
   I ended up adding the ucred defintion to sys/socket.h because I 
   happened to be in a hurry...

(I admit that I didn't check -p2, but I assume these are not changed since
p1.)

BTW: Does -p2 include the Solar Designer fixes
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0682)?



-- v --

v at iki.fi



From japs at garm.adm.ku.dk  Fri Sep 26 19:12:08 2003
From: japs at garm.adm.ku.dk (Jan P. Sorensen)
Date: Fri, 26 Sep 2003 11:12:08 +0200 (METDST)
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F72EE01.1020507@hp.com>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com> <3F7197CF.6040907@hp.com>
	<Pine.GHP.4.52.0309241954380.17818@garm.adm.ku.dk>
	<3F72EE01.1020507@hp.com>
Message-ID: <Pine.GHP.4.52.0309261111050.7131@garm.adm.ku.dk>

No, it did not help.

Jan p. Sorensen

On Thu, 25 Sep 2003, Michael Steffens wrote:

> Jan P. Sorensen wrote:
> > I have tried the two changes but the login/password continues to fail.
>
> I have attached a patch against 3.7.1p2, which worked for me in trusted
> and non-trusted mode, including long passwords in trusted mode, with and
> without privsep, both proto 1 and 2.
>
> Does that help?
>
> Cheers!
> Michael
>



From cheewai_yeung at yahoo.com  Fri Sep 26 19:15:47 2003
From: cheewai_yeung at yahoo.com (Chee-Wai Yeung)
Date: Fri, 26 Sep 2003 02:15:47 -0700 (PDT)
Subject: openssh 3.7.1p2 linux port problem
Message-ID: <20030926091547.59069.qmail@web12107.mail.yahoo.com>

Hello,

after upgrading my redhat 8.0 notebook to
openssh3.7.1p2 linux port I now could not login/scp
into it (as root or myself). /var/log/messages said
the authentication was successful, then the connection
closed immediately. I was using the default
sshd_config that comes from the installation (via
rpmbuild from the srpms file under the portable
directory).

(The client connection was initiated from openssh
3.6.1p2. And reverting the notebook version of sshd
back to 3.6.1p2 worked. The 3.6.1p2 was also rpmbuild
from the  srpms under the portable directory)

I am attaching the sshd -d -d -d and ssh -v -v -v
outputs here. Hope someone can help to shred some
light on this.

# sshd -d -d -d

# /usr/sbin/sshd -d -d -d
debug2: read_server_config: filename
/etc/ssh/sshd_config
debug1: sshd version OpenSSH_3.7.1p2
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
socket: Address family not supported by protocol
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging
mode.
Connection from 192.168.1.253 port 32896
debug1: Client protocol version 2.0; client software
version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.7.1p2
debug2: Network child is on pid 2854
debug3: privsep user:group 74:74
debug1: permanently_set_uid: 74/74
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,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,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: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
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
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
debug2: dh_gen_key: priv key bits set: 137/256
debug2: bits set: 1641/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 1626/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 0x80a5b90(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
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_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
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 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
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 root from 192.168.1.253 port 32896
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 root from 192.168.1.253 port 32896
ssh2
debug1: userauth-request for user root service
ssh-connection method keyboard-interactive
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method
keyboard-interactive
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=root devs=
debug1: kbdint_alloc: devices 'pam'
debug2: auth2_challenge_start: devices pam
debug2: kbdint_next_device: devices <empty>
debug1: auth2_challenge_start: trying authentication
method 'pam'
debug3: mm_sshpam_init_ctx
debug3: mm_request_send entering: type 46
debug3: monitor_read: checking request 46
debug3: mm_answer_pam_init_ctx
debug3: mm_request_send entering: type 47
debug3: mm_request_receive entering
debug3: mm_sshpam_init_ctx: waiting for
MONITOR_ANS_PAM_INIT_CTX
debug3: mm_request_receive_expect entering: type 47
debug3: mm_request_receive entering
debug3: mm_sshpam_init_ctx: pam_init_ctx failed
Failed keyboard-interactive for root from
192.168.1.253 port 32896 ssh2
debug1: userauth-request for user root service
ssh-connection method password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
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 10
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_send entering: type 11
Accepted password for root from 192.168.1.253 port
32896 ssh2
debug1: monitor_child_preauth: root has been
authenticated by privileged process
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_request_receive entering
debug3: mm_auth_password: user authenticated
Accepted password for root from 192.168.1.253 port
32896 ssh2
debug3: mm_send_keystate: Sending new keys: 0x80a3f98
0x80a3f50
debug3: mm_newkeys_to_blob: converting 0x80a3f98
debug3: mm_newkeys_to_blob: converting 0x80a3f50
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 24
debug3: mm_send_keystate: Finished sending state
debug3: mm_newkeys_from_blob: 0x80a5ac0(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x80a5ac0(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug2: set_newkeys: mode 0
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug2: fd 3 setting O_NONBLOCK
debug2: fd 7 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/3
debug3: tty_parse_modes: SSH2 n_bytes 256
debug3: tty_parse_modes: ospeed 38400
debug3: tty_parse_modes: ispeed 38400
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: 12 18
debug3: tty_parse_modes: 13 23
debug3: tty_parse_modes: 14 22
debug3: tty_parse_modes: 18 15
debug3: tty_parse_modes: 30 0
debug3: tty_parse_modes: 31 0
debug3: tty_parse_modes: 32 0
debug3: tty_parse_modes: 33 0
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 0
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
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: rfd 9 isatty
debug2: fd 9 setting O_NONBLOCK
debug2: fd 8 is O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.
debug2: channel 0: read<=0 rfd 9 len -1
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 2855
debug1: session_exit_message: session 0 channel 0 pid
2855
debug2: channel 0: request exit-signal
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug1: session_close: session 0 pid 2855
debug1: session_pty_cleanup: session 0 release
/dev/pts/3
debug2: channel 0: send close
debug3: channel 0: will not send data after close
debug2: notify_done: reading
debug3: channel 0: will not send data after close
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: server-session, nchannels 1
debug3: channel 0: status: The following connections
are open:
  #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel 0: close_fds r -1 w -1 e -1
Connection closed by 192.168.1.253
debug1: krb5_cleanup_proc called
Closing connection to 192.168.1.253

# ssh -v -v -v output

OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL
0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating
port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.200 [192.168.1.200]
port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software
version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
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,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,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
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
debug2: dh_gen_key: priv key bits set: 131/256
debug2: bits set: 1626/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 1
debug1: Host '192.168.1.200' is known and matches the
RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 1641/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
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 authentication method: publickey
debug2: userauth_pubkey_agent: no keys at all
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.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 authentication method:
keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait
for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: 
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root at 192.168.1.200's password: 
debug3: packet_send2: adding 64 (len 58 padlen 6
extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug1: channel 0: request 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 0: request shell
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug3: Trying to reverse map address 192.168.1.253.
Last login: Fri Sep 26 15:42:25 2003 from
192.168.1.253
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: client_input_channel_req: channel 0 rtype
exit-signal reply 0
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:\015
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)\015

debug3: channel_close_fds: channel 0: r -1 w -1 e 6
Connection to 192.168.1.200 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 37
bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0,
stderr 656.4
debug1: Exit status -1


=====
~~~~~~~~~~~~~~
Chee-Wai Yeung
Email: cheewai_yeung at yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From michael.steffens at hp.com  Fri Sep 26 21:09:01 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Fri, 26 Sep 2003 13:09:01 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <Pine.GHP.4.52.0309261111050.7131@garm.adm.ku.dk>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>
	<3F718A10.6AFD97DB@zip.com.au>
	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>
	<3F71924A.30501@hp.com> <3F7197CF.6040907@hp.com>
	<Pine.GHP.4.52.0309241954380.17818@garm.adm.ku.dk>
	<3F72EE01.1020507@hp.com>
	<Pine.GHP.4.52.0309261111050.7131@garm.adm.ku.dk>
Message-ID: <3F741E4D.5090600@hp.com>

Jan P. Sorensen wrote:
> No, it did not help.
> 
> Jan p. Sorensen
> 
> On Thu, 25 Sep 2003, Michael Steffens wrote:
> 
> 
>>Jan P. Sorensen wrote:
>>
>>>I have tried the two changes but the login/password continues to fail.
>>
>>I have attached a patch against 3.7.1p2, which worked for me in trusted
>>and non-trusted mode, including long passwords in trusted mode, with and
>>without privsep, both proto 1 and 2.
>>
>>Does that help?

Did it change anything about the failures? What does syslog report now?
What does sshd report in debugging mode?

Cheers!
Michael




From michael.steffens at hp.com  Fri Sep 26 21:33:57 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Fri, 26 Sep 2003 13:33:57 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F741E4D.5090600@hp.com>
References: <Pine.GHP.4.52.0309241315160.27095@garm.adm.ku.dk>	<3F718A10.6AFD97DB@zip.com.au>	<Pine.GHP.4.52.0309241428490.28856@garm.adm.ku.dk>	<3F71924A.30501@hp.com>
	<3F7197CF.6040907@hp.com>	<Pine.GHP.4.52.0309241954380.17818@garm.adm.ku.dk>	<3F72EE01.1020507@hp.com>	<Pine.GHP.4.52.0309261111050.7131@garm.adm.ku.dk>
	<3F741E4D.5090600@hp.com>
Message-ID: <3F742425.80109@hp.com>

Michael Steffens wrote:
> Jan P. Sorensen wrote:
> 
>> No, it did not help.
>>
>> Jan p. Sorensen
>>
>> On Thu, 25 Sep 2003, Michael Steffens wrote:
>>
>>
>>> Jan P. Sorensen wrote:
>>>
>>>> I have tried the two changes but the login/password continues to fail.
>>>
>>>
>>> I have attached a patch against 3.7.1p2, which worked for me in trusted
>>> and non-trusted mode, including long passwords in trusted mode, with and
>>> without privsep, both proto 1 and 2.
>>>
>>> Does that help?
> 
> 
> Did it change anything about the failures? What does syslog report now?
> What does sshd report in debugging mode?

Further possibilty: When testing do you toggle sshd versions or
trusted mode? In case you do the latter, did you change user
passwords after converting to trusted mode?

Cheers!
Michael



From Carsten.Benecke at rrz.uni-hamburg.de  Fri Sep 26 23:01:59 2003
From: Carsten.Benecke at rrz.uni-hamburg.de (Dr. Carsten Benecke)
Date: Fri, 26 Sep 2003 15:01:59 +0200
Subject: openssh-3.7.1p2: no pam_close_session() invocation
Message-ID: <3F7438C7.5070301@rrz.uni-hamburg.de>

Hello,

I would like to use PAM. All PAM interaction worked well with openssh-3.5

Now that I have tried to upgrade to 3.7.1p1/p2 the pam_close_session()
function won't get invoked. Some debugging shows, that the call is 
protected by an if-statement (module auth-pam.c, function sshpam_cleanup):

	if (sshpam_session_open) {
		pam_close_session(sshpam_handle, PAM_SILENT);
		/* cb, 26.09.03 */
		debug2("\n\nin sshpam_cleanup: mypid = %d\n\n", getpid());		
		sshpam_session_open = 0;
	}

I guess that the forked child process that calls the sshpam_cleanup() 
function is forked before the parent calls do_pam_session() (which sets 
sshpam_session_open to true).

pam_close_session() will be invoked by removing surrounding if-statement.

Is this a bug?


My changes to the default sshd_conf are:

72c72
< UsePAM yes
---
 > #UsePAM yes
83c83
< UsePrivilegeSeparation no
---
 > #UsePrivilegeSeparation yes
96c96
< #Subsystem    sftp    /local/libexec/sftp-server
---
 > Subsystem     sftp    /local/libexec/sftp-server


By the way: This is a bug in the documentation: The default for UsePAM in 
3.7.1p2 is "no" while "#UsePAM yes" implies the opposite.

Regards,
   Carsten

-- 
Dr. Carsten Benecke, Regionales Rechenzentrum, Universit?t Hamburg,
Schl?terstr. 70, D-20146 Hamburg, Tel.: ++49 40 42838 3097,
Fax: ++49 40 42838 3096, mailto: Carsten.Benecke at rrz.uni-hamburg.de




From musunuru_s at yahoo.com  Sat Sep 27 02:07:59 2003
From: musunuru_s at yahoo.com (srinivasa rao musunuru)
Date: Fri, 26 Sep 2003 09:07:59 -0700 (PDT)
Subject: OpenSSH 3.7.1p1
Message-ID: <20030926160759.41765.qmail@web13509.mail.yahoo.com>

Hi,

  RE: OPenSSH Problems

  I created a package for OpenSSH 3.7.1p1 (by using
openssl-0.9.7b and zlib-1.1.4). We are trying to
deploy the created package in all of our servers,
which is already installed different versions of
OpenSSH and SSH. I was successful for few servers. In
one of our server after doing pkgadd and when i am
trying to generate keys i am getting the following
errors. 
  Generating OpenSSH server DSA (protocol version 2)
key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
libz.so: open failed: No such file or directory
Killed
failed!
Generating OpenSSH server RSA (protocol version 2)
key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
libz.so: open failed: No such file or directory
Killed
failed!
Generating OpenSSH server RSA (protocol version 1)
key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
libz.so: open failed: No such file or directory
Killed
failed!
ld.so.1: /usr/local/sbin/sshd: fatal: libz.so: open
failed: No such file or directory
Killed
 
Could you pls help me regarding this problem.
if you need any information regarding this problem pls
let me know.


Thanks,
Srinivas 
musunuru_s at yahoo.com
   

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From v_t_m at seznam.cz  Sat Sep 27 02:32:29 2003
From: v_t_m at seznam.cz (=?iso-8859-2?Q?V=E1clav=20Tomec?=)
Date: Fri, 26 Sep 2003 18:32:29 +0200 (CEST)
Subject: SecurID patch for OpenSSH 3.7.1p2
In-Reply-To: <1063811852.7827.5.camel@localhost>
Message-ID: <58109.183988-26465-632434844-1064593949@seznam.cz>

Hello all,

new version of SecurID patch is available on
http://sweb.cz/v_t_m/

The new version of the patch is extended with "shared logins" possibility.
It means that SecurID token can be used to login to an account shared
by several persons.
This cannot be solved using ACE server standard means.

This patch depends on the AuthSelection patch (http://sweb.cz/v_t_m).
After applying AuthSelection patch, you can specify
server-supported authentication methods per user to authenticate with
OpenSSH server.


Vaclav
____________________________________________________________
Vyzkou?ejte si Oskarovy MMS zdarma!
http://ad2.seznam.cz/redir.cgi?instance=60950%26url=http://www.oskarmobil.cz/services/whatsnew.php#moje



From tim at multitalents.net  Sat Sep 27 02:44:18 2003
From: tim at multitalents.net (Tim Rice)
Date: Fri, 26 Sep 2003 09:44:18 -0700 (PDT)
Subject: OpenSSH 3.7.1p1
In-Reply-To: <20030926160759.41765.qmail@web13509.mail.yahoo.com>
References: <20030926160759.41765.qmail@web13509.mail.yahoo.com>
Message-ID: <Pine.UW2.4.58.0309260939580.3644@ou8.int.multitalents.net>

On Fri, 26 Sep 2003, srinivasa rao musunuru wrote:

> Hi,
> 
>   RE: OPenSSH Problems
> 
>   I created a package for OpenSSH 3.7.1p1 (by using
> openssl-0.9.7b and zlib-1.1.4). We are trying to
> deploy the created package in all of our servers,
> which is already installed different versions of
> OpenSSH and SSH. I was successful for few servers. In
> one of our server after doing pkgadd and when i am
> trying to generate keys i am getting the following
> errors. 
>   Generating OpenSSH server DSA (protocol version 2)
> key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
> libz.so: open failed: No such file or directory
> Killed
> failed!

You are missing libz.so on that server.
Ethier build OpenSSH with libz.a or add zlib libraries to the problem server.

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




From scott.burch at camberwind.com  Sat Sep 27 02:43:52 2003
From: scott.burch at camberwind.com (Scott Burch)
Date: Fri, 26 Sep 2003 16:43:52 -0000
Subject: OpenSSH 3.7.1p1
In-Reply-To: <20030926160759.41765.qmail@web13509.mail.yahoo.com>
References: <20030926160759.41765.qmail@web13509.mail.yahoo.com>
Message-ID: <1064594837.7489.5.camel@localhost>

Hi,

You compiled with a shared libz and your binary can't find libz on the
target system. Make sure you have libz on the target system or rebuild
your source code with a static library.

-Scott

On Fri, 2003-09-26 at 11:07, srinivasa rao musunuru wrote:
> Hi,
> 
>   RE: OPenSSH Problems
> 
>   I created a package for OpenSSH 3.7.1p1 (by using
> openssl-0.9.7b and zlib-1.1.4). We are trying to
> deploy the created package in all of our servers,
> which is already installed different versions of
> OpenSSH and SSH. I was successful for few servers. In
> one of our server after doing pkgadd and when i am
> trying to generate keys i am getting the following
> errors. 
>   Generating OpenSSH server DSA (protocol version 2)
> key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
> libz.so: open failed: No such file or directory
> Killed
> failed!
> Generating OpenSSH server RSA (protocol version 2)
> key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
> libz.so: open failed: No such file or directory
> Killed
> failed!
> Generating OpenSSH server RSA (protocol version 1)
> key...ld.so.1: /usr/local/bin/ssh-keygen: fatal:
> libz.so: open failed: No such file or directory
> Killed
> failed!
> ld.so.1: /usr/local/sbin/sshd: fatal: libz.so: open
> failed: No such file or directory
> Killed
>  
> Could you pls help me regarding this problem.
> if you need any information regarding this problem pls
> let me know.
> 
> 
> Thanks,
> Srinivas 
> musunuru_s at yahoo.com
>    
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 
Scott Burch <scott.burch at camberwind.com>



From openssh at rufey.net  Sat Sep 27 05:49:28 2003
From: openssh at rufey.net (Craig Ruefenacht)
Date: Fri, 26 Sep 2003 13:49:28 -0600
Subject: (no subject)
Message-ID: <1064605768.3f749848ce94d@smtp.rufey.net>

Hi,

I'm not on the openss-unix-dev mailing list, but I want to ask about a feature
that I've put into my local implementation of OpenSSH the past year or so, and I
wanted to know if it was worthwile to add it to the sources so that I don't have
to add it myself each time I upgrade...

About a year ago I was working for a company that wanted to use OpenSSH as a
server (on a Linux platform) for port forwarding.  We didn't want the users
connecting to the ssh server to be able to run a shell.  All we wanted them to
do was this:

     ssh -N -L <somePort>:localhost:<someOtherPort> foo.bar.com

We only wanted them to port forward to one host, localhost.  We didn't want them
to be able to forward any ports to any other host, like this:

    ssh -N -L <somePort>:someRandomMachine:<someOtherPort> foo.bar.com

While a firewall would block anyone from trying to port forward to *any* host on
the Internet, if you allow port forwarding, the user can port forward to
machines that are on the same network as the ssh server which don't have
personal firewalls installed, et al.

We didn't find anything that would make OpenSSH server behave like this.  So we
edited the code and added a config file option called
"allow_nonlocal_port_forward_destinations" and corresponding code in
serverloop.c in the server_request_direct_tcpip function:

        if (((strcmp(target, "localhost") == 0) &&
            (!options.allow_nonlocal_port_forward_destinations)) ||
            (options.allow_nonlocal_port_forward_destinations)) {
          debug("port forwarding to target %s allowed", target);
          sock = channel_connect_to(target, target_port);
        } else {
          debug("port forwarding to target %s not allowed", target);
          sock = -1;
        }

This code effecitvely allows the OpenSSH server to be configured to only allow
port forwarding if the destination host is the OpenSSH server itself (or, more
technically, whatever "localhost" resolves to on the OpenSSH server).

If anyone on the dev list thinks this is a worthwile option to add to OpenSSH,
please let me know.  I can provide diffs for OpenSSH-3.7.1p1 for servconf.c,
servconf.h, and serverloop.c.  Alternatively, you can simply incorporate the
above code into serverloop.c, and corresponding changes in the servconf.c/h files.  

I'm not sure how this would affect the -D option (dynamic application-level port
forwarding, I've never used it).  

In any case, I'd like to be able to deny all port forwardings except to
"localhost" (maybe even change it so that you can specify a host or list of
hosts to which ports can be forwarded to).

Please let me know what the concensus is.  I realize that this may not be a
high-demand type option, ie not many people would be in a configuration where
the feature would be useful, and bloating software to incorporate every
imaginable function isn't desirable, but I think it could be useful enough to at
least consider inserting it into the code base.

Again, I'm not on the openssh-unix-dev mailing list, so send me a reply to
openssh at rufey.net.

Thanks for your time.

--Craig Ruefenacht






From samuel at bcgreen.com  Sun Sep 28 12:21:24 2003
From: samuel at bcgreen.com (Stephen Samuel)
Date: Sat, 27 Sep 2003 19:21:24 -0700
Subject: sshd as non-root
In-Reply-To: <sf42116d.059@lvnbb.brandenburg.de>
References: <sf42116d.059@lvnbb.brandenburg.de>
Message-ID: <3F7645A4.8090007@bcgreen.com>

I'm trying to get sshd to the point where it can run as non-root.
I think that this is quite doable if using rsa-key authentication
So far, I've run into and fixed the proben that chgroups only works
if you're root and I've added a ModulusFile option to sshd_config
(not necessary, but nice).

Now I've run into the fact that the system attempts to do PAM
authentication, even though you're root.  Are there any other
problems I'm likely to run into?  Has this already been fixed
somewhere?

This is mostly out of curiosity, but I see a few real uses for
non-root ssh -- ranging from special-purpose security lockdowns
to bootstrapping ssh on a remote machine without having to log
onto root via an open channel.

-- 
Stephen Samuel +1(604)876-0426                samuel at bcgreen.com
		   http://www.bcgreen.com/~samuel/
    Powerful committed communication. Transformation touching
      the jewel within each person and bringing it to light.



From mouring at etoh.eviladmin.org  Sun Sep 28 12:32:35 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 27 Sep 2003 21:32:35 -0500 (CDT)
Subject: sshd as non-root
In-Reply-To: <3F7645A4.8090007@bcgreen.com>
Message-ID: <Pine.BSO.4.44.0309272130260.842-100000@etoh.eviladmin.org>



On Sat, 27 Sep 2003, Stephen Samuel wrote:

> I'm trying to get sshd to the point where it can run as non-root.
> I think that this is quite doable if using rsa-key authentication
> So far, I've run into and fixed the proben that chgroups only works
> if you're root and I've added a ModulusFile option to sshd_config
> (not necessary, but nice).
>
> Now I've run into the fact that the system attempts to do PAM
> authentication, even though you're root.  Are there any other
> problems I'm likely to run into?  Has this already been fixed
> somewhere?
>

The solution is NOT to use pam.

Plus it is not going to be universally possible to support sshd as
non-root since some systems require root for assigning TTYs.

Depending on the changes we may consider them, but honestly =) don't keep
your hopes up about integration.

- Ben



From djm at mindrot.org  Sun Sep 28 16:41:49 2003
From: djm at mindrot.org (Damien Miller)
Date: Sun, 28 Sep 2003 06:41:49 -0000
Subject: sshd as non-root
In-Reply-To: <Pine.BSO.4.44.0309272130260.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309272130260.842-100000@etoh.eviladmin.org>
Message-ID: <1064731160.14070.9.camel@sakura.mindrot.org>

On Sun, 2003-09-28 at 12:32, Ben Lindstrom wrote:
> On Sat, 27 Sep 2003, Stephen Samuel wrote:

> > Now I've run into the fact that the system attempts to do PAM
> > authentication, even though you're root.  Are there any other
> > problems I'm likely to run into?  Has this already been fixed
> > somewhere?
> >
> 
> The solution is NOT to use pam.

Correct, don't add a UsePAM=yes to the config (assuming you are using
3.7.1p2). On some other platforms, non-root may break platform native
authentication systems. Darren, can you comment on AIX?

> Plus it is not going to be universally possible to support sshd as
> non-root since some systems require root for assigning TTYs.

I think that all platforms supported by portable OpenSSH require root
for TTY assignment. I believe that some platforms can get away with
non-root, but with a sgid helper but we haven't followed that up.

> Depending on the changes we may consider them, but honestly =) don't keep
> your hopes up about integration.

Apart from PAM and TTY allocation, I'd be interested in hearing bug
reports. A non-root sshd is very useful for things like anonymous cvs
and sftp servers and I'd like to ensure it works on as many platforms as
possible. IIRC the regress tests can be run as non-root too (which
necessarily include sshd tests).

-d




From carson at taltos.org  Sun Sep 28 17:36:08 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sun, 28 Sep 2003 03:36:08 -0400
Subject: sshd as non-root
In-Reply-To: <1064731160.14070.9.camel@sakura.mindrot.org>
References: <Pine.BSO.4.44.0309272130260.842-100000@etoh.eviladmin.org>
	<1064731160.14070.9.camel@sakura.mindrot.org>
Message-ID: <4836031.1064720168@[192.168.20.2]>



--On Sunday, September 28, 2003 4:39 PM +1000 Damien Miller 
<djm at mindrot.org> wrote:

> I think that all platforms supported by portable OpenSSH require root
> for TTY assignment. I believe that some platforms can get away with
> non-root, but with a sgid helper but we haven't followed that up.

If the platform supports grantpt() (part of SUSv2), why is root needed?

-- 
Carson



From dtucker at zip.com.au  Sun Sep 28 21:33:14 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 28 Sep 2003 21:33:14 +1000
Subject: sshd as non-root
References: <Pine.BSO.4.44.0309272130260.842-100000@etoh.eviladmin.org>
	<1064731160.14070.9.camel@sakura.mindrot.org>
Message-ID: <3F76C6FA.C3934D05@zip.com.au>

Damien Miller wrote:
> Correct, don't add a UsePAM=yes to the config (assuming you are using
> 3.7.1p2). On some other platforms, non-root may break platform native
> authentication systems. Darren, can you comment on AIX?

Sure.  AIX has a number of account check functions (eg is the account
locked, is it allowed to log in at this time, that kind of thing) that can
only be checked if the process has root privs [0] because the details
stored in files that aren't world readable. 

Currently, sshd does not perform those tests when running with uid != 0,
since they will always fail.  This was done mainly for the regression
tests, but also acknowledging that their may be legitimate uses for a
non-root sshd.  The previous discussion is in the mail archives.

> I think that all platforms supported by portable OpenSSH require root
> for TTY assignment. I believe that some platforms can get away with
> non-root, but with a sgid helper but we haven't followed that up.

Hm, I though most didn't need root for ptys.  ISTR in the doco for
"expect" they only mention Crays as needing root for ptys.  Redhat 8 seems
to work OK for ssh -t without root, dunno about other platforms.

[0] Actually, uid == 0 or gid "security", although sshd currently does not
check for the latter.

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



From mouring at etoh.eviladmin.org  Mon Sep 29 03:59:51 2003
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sun, 28 Sep 2003 12:59:51 -0500 (CDT)
Subject: sshd as non-root
In-Reply-To: <4836031.1064720168@[192.168.20.2]>
Message-ID: <Pine.BSO.4.44.0309281257070.842-100000@etoh.eviladmin.org>



On Sun, 28 Sep 2003, Carson Gaspar wrote:

>
>
> --On Sunday, September 28, 2003 4:39 PM +1000 Damien Miller
> <djm at mindrot.org> wrote:
>
> > I think that all platforms supported by portable OpenSSH require root
> > for TTY assignment. I believe that some platforms can get away with
> > non-root, but with a sgid helper but we haven't followed that up.
>
> If the platform supports grantpt() (part of SUSv2), why is root needed?
>

I don't see how grantpt() solves anything unless your implying that by
default every tty is 777 so anything can grab and modify the permissions.

Which is still insecure because someone could open the TTY for read/write
before grantpt() does.

I suspect on most systems you'd get:

[EACCES]
The corresponding slave pseudo-terminal device could not be accessed.

if you tried it as a user.

- Ben



From carson at taltos.org  Mon Sep 29 04:19:52 2003
From: carson at taltos.org (Carson Gaspar)
Date: Sun, 28 Sep 2003 14:19:52 -0400
Subject: sshd as non-root
In-Reply-To: <Pine.BSO.4.44.0309281257070.842-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0309281257070.842-100000@etoh.eviladmin.org>
Message-ID: <43460218.1064758792@[192.168.20.2]>



--On Sunday, September 28, 2003 12:59 PM -0500 Ben Lindstrom 
<mouring at etoh.eviladmin.org> wrote:

>
>
> On Sun, 28 Sep 2003, Carson Gaspar wrote:
>
>> If the platform supports grantpt() (part of SUSv2), why is root needed?
>
> I don't see how grantpt() solves anything unless your implying that by
> default every tty is 777 so anything can grab and modify the permissions.

On most systems, grantpt() uses a setuid helper program. That's the whole 
_point_ of grantpt(). Take a look at a Solaris box, and note the caution 
about SIGCHLD.

-- 
Carson



From djm at mindrot.org  Mon Sep 29 07:53:30 2003
From: djm at mindrot.org (Damien Miller)
Date: Sun, 28 Sep 2003 21:53:30 -0000
Subject: sshd as non-root
In-Reply-To: <4836031.1064720168@[192.168.20.2]>
References: <Pine.BSO.4.44.0309272130260.842-100000@etoh.eviladmin.org>
	<1064731160.14070.9.camel@sakura.mindrot.org>
	<4836031.1064720168@[192.168.20.2]>
Message-ID: <1064785859.14070.16.camel@sakura.mindrot.org>

On Sun, 2003-09-28 at 17:36, Carson Gaspar wrote:
> --On Sunday, September 28, 2003 4:39 PM +1000 Damien Miller 
> <djm at mindrot.org> wrote:
> 
> > I think that all platforms supported by portable OpenSSH require root
> > for TTY assignment. I believe that some platforms can get away with
> > non-root, but with a sgid helper but we haven't followed that up.
> 
> If the platform supports grantpt() (part of SUSv2), why is root needed?

We keep root anyway to update wtmp and friends. Perhaps this could be
done by keeping open fds around to these files...

-d




From James.Roberts-Thomson at NBNZ.CO.NZ  Mon Sep 29 12:07:05 2003
From: James.Roberts-Thomson at NBNZ.CO.NZ (Roberts-Thomson, James)
Date: Mon, 29 Sep 2003 14:07:05 +1200
Subject: Environment passing in Solaris 8 with later versions of SSH and U
	seLogin=yes
Message-ID: <DDF9139AA996D511BBDE00508BB927450697F4D9@nbhexch1.nbnz.co.nz>

Hi,

I've got the following issue, which I'm unable to resolve by myself.
Hopefully, someone on the list will be able to guide me, or provide more
information towards resolving this.

We've compiled OpenSSH v3.7.1p1 (which I know is not the most recent
version) on Solaris 8 SPARC, and have noticed that when the "UseLogin=yes"
parameter is set in the sshd_config file, the environment which SSH builds
for the child shell isn't making into the shell.  When running both client
and server in debug mode, I can see the following when the client attempts
to login: (the JRT lines are my attempting to trace the program execution
flow)

debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: JRT-03: do_pre_login
debug1: JRT-04: do_child
Environment:
  TZ=NZ
  SSH_CLIENT=xxx.xx.xx.xxx 34811 2222
  SSH_CONNECTION=xxx.xx.xx.xxx 34811 xxx.xx.xx.xx 2222
  SSH_TTY=/dev/pts/6
  TERM=xterm
debug1: JRT-05: launch_login

However, if I then query the environment of the logged in process, none of
the variables have been set properly, thus:

user at host:~$ echo $SSH_CLIENT

user at host:~$ echo $SSH_TTY

user at host:~$ echo $TERM
sun

I don't mind the loss of SSH_CLIENT and SSH_TTY; but the fact that my TERM
is not being set correctly is causing all sorts of problems.

This DOES work in OpenSSH 3.0p1, with the same configuration file.  Turning
UseLogin OFF in OpenSSH 3.7.1p1 also works; but causes other issues with
Solaris password aging, so isn't an option (madated by our Information
Security people).  This has been tested on the SAME machine in the SAME
interactive session, so I know it isn't an issue with different OS / build /
runtime factors.

As far as I can tell, the environment etc is all done in "session.c".  I've
looked at the code to the best of my ability (I'm not a C guru, but can do
basic things), and the two versions of code is doing much the same stuff:

1.  Define char **env
2.  Define "extern char **environ", which I assume will reach the
environment setup by the C RTL.
3.  Populate "env" by various calls to child_set_env (which in OpenSSH
3.7.1p1 is called in another routine, by env = do_setup_env - is this the
problem??)
4.  "environ = env", which I assume will set the external environment to the
newly defined environment stored in "env".
5.  Call "execl(LOGIN_PROGRAM, "login", "-h", hostname, "-p" ,"-f", "--",
pw-<pw_name, (char *) NULL)" to exec the login process.  The "-p" flag is
supposed to get login to read the current environment.

Hints / Help / Suggestions all welcome.  Solutions are preferred  <grin>.

Please ensure any responses are cc'ed to myself directly as well as the
list, as I'm not a subscriber to the list currently (too many viruses on the
list!)

Thanks in advance,

James Roberts-Thomson
Senior Systems Engineer	DDI +64 4 494 4436
Infrastructure Projects	Tel +64 4 494 4000
The National Bank of New Zealand Limited	Fax +64 4 802 8509
----------
If at first you don't succeed, redefine success.

(Note:  This .sig is not an option for this problem!)

This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.


From djm at mindrot.org  Mon Sep 29 12:37:02 2003
From: djm at mindrot.org (Damien Miller)
Date: Mon, 29 Sep 2003 12:37:02 +1000
Subject: Environment passing in Solaris 8 with later versions of SSH and
 U	seLogin=yes
In-Reply-To: <DDF9139AA996D511BBDE00508BB927450697F4D9@nbhexch1.nbnz.co.nz>
References: <DDF9139AA996D511BBDE00508BB927450697F4D9@nbhexch1.nbnz.co.nz>
Message-ID: <3F779ACE.7080502@mindrot.org>

Roberts-Thomson, James wrote:
> Hi,
> 
> I've got the following issue, which I'm unable to resolve by myself.
> Hopefully, someone on the list will be able to guide me, or provide more
> information towards resolving this.
> 
> We've compiled OpenSSH v3.7.1p1 (which I know is not the most recent
> version) on Solaris 8 SPARC, and have noticed that when the "UseLogin=yes"
> parameter is set in the sshd_config file, the environment which SSH builds
> for the child shell isn't making into the shell.  When running both client
> and server in debug mode, I can see the following when the client attempts
> to login: (the JRT lines are my attempting to trace the program execution
> flow)

IIRC some platforms like the environment passed as arguments to 
/bin/login rather than as traditional environment strings. What does 
login's manpage say?

If this is the case, it wouldn't be too change the invocation of login 
to pass them. We already have code to manage argument lists (used by scp 
and sftp).

-d



From James.Roberts-Thomson at NBNZ.CO.NZ  Mon Sep 29 12:48:49 2003
From: James.Roberts-Thomson at NBNZ.CO.NZ (Roberts-Thomson, James)
Date: Mon, 29 Sep 2003 14:48:49 +1200
Subject: Environment passing in Solaris 8 with later versions of SSH a
	nd U	seLogin=yes
Message-ID: <DDF9139AA996D511BBDE00508BB927450697F4DB@nbhexch1.nbnz.co.nz>

Damien,

>IIRC some platforms like the environment passed as arguments to 
>/bin/login rather than as traditional environment strings. What does 
>login's manpage say?

<quote>
SYNOPSIS
     login [ -p ]  [ -d device ]  [ -h hostname | [ terminal ]  |
     -r hostname ]  [   name  [ environ ]  ...  ]

...

The environment may be expanded  or  modified  by  supplying
additional  arguments  to login, either at execution time or
when login requests your login name. The arguments may  take
either  the  form  xxx  or  xxx=yyy.

...

Alternatively, you can pass the current environment by  sup-
plying  the  -p  flag to login. This flag indicates that all
currently defined environment variables should be passed, if
possible,  to  the  new  environment
</quote>

Basically, I can supply environment options, but passing "-p" should "just
work".

>If this is the case, it wouldn't be too change the invocation of login 
>to pass them. We already have code to manage argument lists (used by scp 
>and sftp).

Well, the execl function call to call login is identical in both versions
("working" and "nonworking"), so I doubt that is the issue.  I'm not sure if
I can fudge the calls to supply env variables on the command line, but could
give it a try...

James Roberts-Thomson
Senior Systems Engineer	DDI +64 4 494 4436
Infrastructure Projects	Tel +64 4 494 4000
The National Bank of New Zealand Limited	Fax +64 4 802 8509
----------
If at first you do succeed, try to hide your astonishment.

This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.



From strube at physik3.gwdg.de  Tue Sep 30 02:04:02 2003
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Mon, 29 Sep 2003 18:04:02 +0200 (MET DST)
Subject: Man Pages
Message-ID: <200309291604.SAA00631@r2d2.physik3.gwdg.de>

OpenSSH 3.7.1p2, Solaris: The man pages are converted by the awk script
mdoc2man.awk. But some commands are not recognized and remain as such,
but without the leading dot:
.Bk -words
.Ek
.CM (is .Cm intended?)
The script should be enhanced or these commands avoided.
I also tried the perl script mdoc2man.pl from OpenSSH 3.5p1, which gives
exactly the same results.



From picasso at madflower.com  Tue Sep 30 04:41:18 2003
From: picasso at madflower.com (Sean O'Malley)
Date: Mon, 29 Sep 2003 14:41:18 -0400 (EDT)
Subject: openssh 3.7.1p2 afs/pam issues
Message-ID: <Pine.GSO.4.33.0309291435070.728-100000@eclipse.cl.msu.edu>

Does anyone have a patch to get this working? We would really like to
upgrade to a newer version of OpenSSH but PAM support (esp w/pam_afs) is
essential.

Sean



From jpoc at us.ibm.com  Tue Sep 30 05:39:31 2003
From: jpoc at us.ibm.com (James O'Connor)
Date: Mon, 29 Sep 2003 14:39:31 -0500
Subject: OpenSSH 3.7.1p2  AIX loginsuccess() issue
Message-ID: <OFA14DF772.15E3C7CC-ON86256DB0.00682756-86256DB0.006BFCA9@us.ibm.com>

On AIX 4.3.3 and AIX 5.1, the last successful and unsuccessful logins are 
no longer printer prior to the motd with either the stock openssh-3.7.1p2 
or Darren's openssh-3.7.1p2-pwexp24.patch.  In both cases it appears that 
the loginsuccess() call (auth-passwd.c stock or auth.c Darren's patch) is 
returning -1 and msg is not appended to loginmsg.  /etc/security/lastlog 
is updated despite the negative return code from loginsuccess().  I am not 
using privilege separation.  The last successful and unsuccessful logins 
are printed using openssh-3.6.1p2.

James O'Connor
IBM Global Services
jpoc at us.ibm.com



From ecunningham at whoi.edu  Tue Sep 30 06:29:26 2003
From: ecunningham at whoi.edu (Eric Cunningham)
Date: Mon, 29 Sep 2003 16:29:26 -0400
Subject: SSHD 3.7.1p2 on HP-UX
Message-ID: <3F789626.4040904@whoi.edu>

When I applied the patches/mods to openssh-3.7.1p2/configure and 
openbsd-compat/xcrypt.c password authentication still fails, though 
differently from the "account is locked" message.  syslog now reports:

User eric password has expired (password aged)
Failed none for illegal user eric from 128.128.64.78 port 53132 ssh2
Failed password for illegal user eric from 128.128.64.78 port 53132 ssh2

Needless to say, the password hasn't expired.

=============================================================
   Eric Cunningham
   Computer and Information Services - http://www.whoi.edu/CIS
   Woods Hole Oceanographic Institution - http://www.whoi.edu
   Woods Hole, MA  02543-1541     phone: (508) 289-2224
   fax: (508) 457-2174           e-mail: ecunningham at whoi.edu
=============================================================



From keithkm at fusion.gat.com  Tue Sep 30 07:24:38 2003
From: keithkm at fusion.gat.com (Kristi Keith)
Date: Mon, 29 Sep 2003 14:24:38 -0700
Subject: Openssh-3.7.1p2 install on HP-UX 11i not working
Message-ID: <3F78A316.D16D954B@fusion.gat.com>

I downloaded
http://gatekeep.cs.utah.edu/hppd/hpux/Networking/Admin/openssh-3.7.1p2/
and have been trying to install it on our HP-UX 11i system. Although
configure completes successfully, make give the following errors:

        gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I.
-I./..
-I/usr/local/ssl/include  -D_HPUX_SOURCE -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDE
D=1 -DHAVE_CONFIG_H -c xcrypt.c
In file included from /usr/include/sys/user.h:52,
                 from
/usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.2/include/r
pc/auth.h:30,
                 from /usr/include/rpc/rpc.h:61,
                 from /usr/include/rpcsvc/nis.h:9,
                 from /usr/include/prot.h:23,
                 from xcrypt.c:35:
/usr/include/machine/sys/setjmp.h:45: redefinition of `struct label_t'
xcrypt.c: In function `xcrypt':


xcrypt.c:70: warning: passing arg 1 of `bigcrypt' discards qualifiers
from pointer target type
xcrypt.c:70: warning: passing arg 2 of `bigcrypt' discards qualifiers
from pointer target type
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.


I ran configure as follows:

   ./configure --with-ssl-dir=/usr/local/ssl --with-pam --without-shadow
--without-tcp-wrappers

I can't find what is causing the problem. btw, the same errors occur
with the OpenSource distribution. The errors also occur if I turn pam
off. We are running gcc v3.2.1.

Any idea of what is wrong? Any enlightenment would be appreciated! I am
not a member of this list, please reply directly to me. I will post the
solution.


Thanks...Kristi Keith


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kristi Keith                                  858-455-3939
General Atomics, Fusion User Services         858-455-4515 FAX
San Diego, CA

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From lindysandiego at yahoo.com  Tue Sep 30 07:37:49 2003
From: lindysandiego at yahoo.com (Thomas Baden)
Date: Mon, 29 Sep 2003 14:37:49 -0700 (PDT)
Subject: Bus Error with OpenSSH 3.7.1p2 on Solaris 8, SPARC 64-bit, YASSP
Message-ID: <20030929213749.24434.qmail@web20709.mail.yahoo.com>

I had a problem much like the one that Matthias Koeppe
experienced.  I would only get the BUS error when
running in a YASSP-modified system, though.  The
binary worked fine on a non-YASSP host.

I applied his change to use a long for the mask, and
it works now.

Cheers,
-Thomas

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From dtucker at zip.com.au  Tue Sep 30 08:21:13 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 30 Sep 2003 08:21:13 +1000
Subject: OpenSSH 3.7.1p2  AIX loginsuccess() issue
References: <OFA14DF772.15E3C7CC-ON86256DB0.00682756-86256DB0.006BFCA9@us.ibm.com>
Message-ID: <3F78B059.412B98F6@zip.com.au>

James O'Connor wrote:
> 
> On AIX 4.3.3 and AIX 5.1, the last successful and unsuccessful logins are
> no longer printer prior to the motd with either the stock openssh-3.7.1p2
> or Darren's openssh-3.7.1p2-pwexp24.patch.  In both cases it appears that
> the loginsuccess() call (auth-passwd.c stock or auth.c Darren's patch) is
> returning -1 and msg is not appended to loginmsg.  /etc/security/lastlog
> is updated despite the negative return code from loginsuccess().  I am not
> using privilege separation.  The last successful and unsuccessful logins
> are printed using openssh-3.6.1p2.

What password registry does the account use?  If you put "return;" at the
top of aix_setauthdb() in openbsd-compat/port-aix.c does that make the
difference?  (after recompiling, obviously.)

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



From dtucker at zip.com.au  Tue Sep 30 08:51:57 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 30 Sep 2003 08:51:57 +1000
Subject: openssh-3-7-1p2 compiling problems on Reliant UNIX
References: <0C93F14B44CBD711910E0010E3B97A6A020BEC4F@N999EXK0>
Message-ID: <3F78B78D.8E226E38@zip.com.au>

Martin.Rottler at nuernberger.de wrote:
> I have problems compiling openssh-3-7-1p2 on Reliant UNIX.
> (same problem with 3-7-1p1)
> 
> first error was:
> ../defines.h 144: [error] CFE1101 "int8_t" has already been declared in the
> current scope
> typedef char int8_t;

The configure test tests for int8_t, int16_t and int32_t before defining
HAVE_INTXX_T.  Does your system define all three (possibly in
/usr/include/sys/types.h)?

>         cc -o ssh ssh.o readconf.o clientloop.o sshtty.o  sshconnect.o
> sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib
> -L/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl  -lgen -lcrypto
> Undefined                       first referenced
>  symbol                             in file
> gmtime_r                            /usr/local/ssl/lib/libcrypto.a(o_time.o)
> cma_sigaction
> /usr/local/ssl/lib/libcrypto.a(ui_openssl.o)
> ld: ssh: fatal error: Symbol referencing errors. No output written to ssh
> make: *** Error code 1

That looks like your libcrypto is compiled with the re-entrant (threaded)
C library.  Try adding "-lc_r" to your LDFLAGS or recompile OpenSSL with
the same flags you're using with OpenSSH.  Alternatively you could compile
OpenSSH with -lc_r, however you might need to invoke your compiler as
"cc_r" or something for that to work properly.

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



From dtucker at zip.com.au  Tue Sep 30 09:08:44 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 30 Sep 2003 09:08:44 +1000
Subject: Bus Error with OpenSSH 3.7.1p2 on Solaris 8, SPARC 64-bit, YASSP
References: <20030929213749.24434.qmail@web20709.mail.yahoo.com>
Message-ID: <3F78BB7C.F6F166FF@zip.com.au>

Thomas Baden wrote:
> 
> I had a problem much like the one that Matthias Koeppe
> experienced.  I would only get the BUS error when
> running in a YASSP-modified system, though.  The
> binary worked fine on a non-YASSP host.
> 
> I applied his change to use a long for the mask, and
> it works now.

I must admit I missed Matthias' original post.  The problem as I
understand it is that mode_t can be a (32bit) uint, which messes up the
(64bit) long format in sscanf in some 64bit configurations.

Matthias' original patch is attached, and I don't see a cleaner way to do
it except maybe

mode_t mask;
if (sscanf(var, "%5lo", &(mode_t)mask) == 1)

I don't even know if that will fix it.  I can't test it.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: session.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v
retrieving revision 1.255
diff -u -p -r1.255 session.c
--- session.c	22 Sep 2003 11:04:23 -0000	1.255
+++ session.c	29 Sep 2003 22:27:39 -0000
@@ -916,6 +916,7 @@ read_etc_default_login(char ***env, u_in
 	char **tmpenv = NULL, *var;
 	u_int i, tmpenvsize = 0;
 	mode_t mask;
+	unsigned long long_mask;
 
 	/*
 	 * We don't want to copy the whole file to the child's environment,
@@ -934,9 +935,11 @@ read_etc_default_login(char ***env, u_in
 	if (var != NULL)
 		child_set_env(env, envsize, "PATH", var);
 	
-	if ((var = child_get_env(tmpenv, "UMASK")) != NULL)
-		if (sscanf(var, "%5lo", &mask) == 1)
+	if ((var = child_get_env(tmpenv, "UMASK")) != NULL) {
+		if (sscanf(var, "%5lo", &long_mask) == 1)
+			mask = (mode_t)long_mask;
 			umask(mask);
+	}
 	
 	for (i = 0; tmpenv[i] != NULL; i++)
 		xfree(tmpenv[i]);

From djm at mindrot.org  Tue Sep 30 10:40:17 2003
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Sep 2003 10:40:17 +1000
Subject: openssh 3.7.1p2 afs/pam issues
In-Reply-To: <Pine.GSO.4.33.0309291435070.728-100000@eclipse.cl.msu.edu>
References: <Pine.GSO.4.33.0309291435070.728-100000@eclipse.cl.msu.edu>
Message-ID: <3F78D0F1.3020803@mindrot.org>

Sean O'Malley wrote:
> Does anyone have a patch to get this working? We would really like to
> upgrade to a newer version of OpenSSH but PAM support (esp w/pam_afs) is
> essential.

Please try the patch at http://bugzilla.mindrot.org/show_bug.cgi?id=717

-d





From Nick_Chi at manulife.com  Tue Sep 30 14:22:00 2003
From: Nick_Chi at manulife.com (Nick_Chi at manulife.com)
Date: Tue, 30 Sep 2003 12:22:00 +0800
Subject: OpenSSH 3.7.1p1 installation on AIX 4.3.3 enquiry?
Message-ID: <OF024365E0.F2C848CB-ON48256DB1.0017C801@manulife.com>

Dear Sir,

I try to install OpenSSH 3.7.1p1 on AIX 4.3.3, but I find the following
problem.
Would you please give some advices for me?

I try to configure the s/w by entering

../configure --prefix=OPENSSH_PATH \
--sysconfdir=OPENSSH_PATH/etc/openssh \
--without-pam \
--without-prngd-socket \
--without-prngd-port \
--with-tcp-wrappers=TCPWRAPPER_PATH \
--with-pid-dir=OPENSSH_PATH/var/run/openssh \
--with-ssl-dir=OPENSSL_PATH \
--with-zlib=ZLIB_PATH

The following warning appears at the end.
=====================================================
WARNING: you are using the builtin random number collection
service. Please read WARNING.RNG and request that your OS
vendor includes kernel-based random number collection in
future versions of your OS.

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

Then, I try to make the s/w by entering

make

The following error shows at the end.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
(cd openbsd-compat && make)
make[1]: Entering directory
`/tech/src/SSH-3.7.1p1/openssh-3.7.1p1/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./..
-I/tech/OPENSSH-3.7.1p1/openssl/include -I/usr/tcpwrap -I/usr/local/include
-I/usr/local/include -DHAVE_CONFIG_H -c bsd-arc4random.c
In file included from /usr/include/sys/user.h:77,
                 from /usr/include/sys/audit.h:38,
                 from ../openbsd-compat/port-aix.h:35,
                 from ../openbsd-compat/openbsd-compat.h:166,
                 from ../includes.h:173,
                 from bsd-arc4random.c:25:
/usr/include/sys/proc.h:203: error: parse error before "crid_t"
/usr/include/sys/proc.h:212: error: parse error before "p_class"
/usr/include/sys/proc.h:355: error: parse error before '}' token
make[1]: *** [bsd-arc4random.o] Error 1
make[1]: Leaving directory
`/tech/src/SSH-3.7.1p1/openssh-3.7.1p1/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hope you can reply me when you are free.

Thanks.

Best Regards,

Nick CHI
Regional Technology Team,
Regional I.T.,
I.T. Asia,
Manulife International Limited
Tel: (852) 2510 3273
Fax: (852) 2510 0244
Email: Nick_Chi at manulife.com



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

This message is confidential and may also be privileged.  If you are not
the intended recipient, please notify me by return e-mail and delete this
message from your system.  If you are not the intended recipient, any use
by you of this message is strictly prohibited.



From dtucker at zip.com.au  Tue Sep 30 14:44:09 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 30 Sep 2003 14:44:09 +1000
Subject: OpenSSH 3.7.1p1 installation on AIX 4.3.3 enquiry?
References: <OF024365E0.F2C848CB-ON48256DB1.0017C801@manulife.com>
Message-ID: <3F790A19.33D8C09A@zip.com.au>

Nick_Chi at manulife.com wrote:
> I try to install OpenSSH 3.7.1p1 on AIX 4.3.3, but I find the following
> problem.
[snip]
> The following warning appears at the end.
> =====================================================
> WARNING: you are using the builtin random number collection
> service.

That's normal.  AIX (up to but not including 5.2, I think) does not have a
/dev/random device.

> make[1]: Entering directory
> `/tech/src/SSH-3.7.1p1/openssh-3.7.1p1/openbsd-compat'
> gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./..
> -I/tech/OPENSSH-3.7.1p1/openssl/include -I/usr/tcpwrap -I/usr/local/include
> -I/usr/local/include -DHAVE_CONFIG_H -c bsd-arc4random.c
> In file included from /usr/include/sys/user.h:77,
>                  from /usr/include/sys/audit.h:38,
>                  from ../openbsd-compat/port-aix.h:35,
>                  from ../openbsd-compat/openbsd-compat.h:166,
>                  from ../includes.h:173,
>                  from bsd-arc4random.c:25:
> /usr/include/sys/proc.h:203: error: parse error before "crid_t"
> /usr/include/sys/proc.h:212: error: parse error before "p_class"
> /usr/include/sys/proc.h:355: error: parse error before '}' token
> make[1]: *** [bsd-arc4random.o] Error 1
> make[1]: Leaving directory
> `/tech/src/SSH-3.7.1p1/openssh-3.7.1p1/openbsd-compat'
> make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

That's actually caused by a problem in the AIX system headers that trips
up earlier gcc's, but openssh-3.7.1p2 will work around it on AIX 4.3.3.

Your options are: use openssh-3.7.1p2, upgrade your gcc or edit the system
headers.

For details see:
http://bugzilla.mindrot.org/show_bug.cgi?id=640

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



From strube at physik3.gwdg.de  Tue Sep 30 18:13:44 2003
From: strube at physik3.gwdg.de (Hans Werner Strube)
Date: Tue, 30 Sep 2003 10:13:44 +0200 (MET DST)
Subject: auth-pam.c, USE_POSIX_THREADS
Message-ID: <200309300813.KAA00846@r2d2.physik3.gwdg.de>

OpenSSH 3.7.1p2 contains an #ifdef USE_POSIX_THREADS and simulates threads
by processes if this is not defined. However, configure and config.h do not
provide any means to define this. Is this already included for future
releases but does not function properly if defined? Or could it be set
manually in config.h and would work in Solaris?



From markus at openbsd.org  Tue Sep 30 19:16:55 2003
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 30 Sep 2003 11:16:55 +0200
Subject: auth-pam.c, USE_POSIX_THREADS
In-Reply-To: <200309300813.KAA00846@r2d2.physik3.gwdg.de>
References: <200309300813.KAA00846@r2d2.physik3.gwdg.de>
Message-ID: <20030930091655.GA29939@folly>

AFAIK USE_POSIX_THREADS is considered experimental
and is not recommended as it will run PAM in the 
privileged process.

On Tue, Sep 30, 2003 at 10:13:44AM +0200, Hans Werner Strube wrote:
> OpenSSH 3.7.1p2 contains an #ifdef USE_POSIX_THREADS and simulates threads
> by processes if this is not defined. However, configure and config.h do not
> provide any means to define this. Is this already included for future
> releases but does not function properly if defined? Or could it be set
> manually in config.h and would work in Solaris?
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From michael.steffens at hp.com  Tue Sep 30 20:53:05 2003
From: michael.steffens at hp.com (Michael Steffens)
Date: Tue, 30 Sep 2003 12:53:05 +0200
Subject: SSHD 3.7.1p2 on HP-UX
In-Reply-To: <3F789626.4040904@whoi.edu>
References: <3F789626.4040904@whoi.edu>
Message-ID: <3F796091.9060209@hp.com>

Eric Cunningham wrote:
> When I applied the patches/mods to openssh-3.7.1p2/configure and 
> openbsd-compat/xcrypt.c password authentication still fails, though 
> differently from the "account is locked" message.  syslog now reports:
> 
> User eric password has expired (password aged)
> Failed none for illegal user eric from 128.128.64.78 port 53132 ssh2
> Failed password for illegal user eric from 128.128.64.78 port 53132 ssh2
> 
> Needless to say, the password hasn't expired.

Could you please check what sshd in debugging mode "sshd -ddd" reports
about aging? For me it's

   debug3: allowed_user: today 12325 sp_expire -1 sp_lstchg 12324 sp_max 182

for an account having the password changed yesterday, and it let's me
log in.

Could you please also check what

   /usr/lbin/getprpw <username>

reports about the account being rejected?

Cheers!
Michael






From ecunningham at whoi.edu  Tue Sep 30 22:43:39 2003
From: ecunningham at whoi.edu (Eric Cunningham)
Date: Tue, 30 Sep 2003 08:43:39 -0400
Subject: SSHD 3.7.1p2 on HP-UX
References: <3F789626.4040904@whoi.edu> <3F796091.9060209@hp.com>
Message-ID: <3F797A7B.8070909@whoi.edu>

> Could you please check what sshd in debugging mode "sshd -ddd" reports
> about aging?

<snip>

debug3: allowed_user: today 12325 sp_expire -1 sp_lstchg -1 sp_max 0
User eric password has expired (password aged)

<snip>


> Could you please also check what
> 
>   /usr/lbin/getprpw <username>
> 
> reports about the account being rejected?

root:#-> /usr/lbin/getprpw eric
uid=5928, bootpw=NO, audid=10, audflg=1, mintm=-1, maxpwln=-1, exptm=-1, 
lftm=-1, spwchg=-1, upwchg=Fri Mar 31 15:18:43 2000, acctexp=-1, 
llog=-1, expwarn=-1, usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, 
admnum=-1, syschpw=DFT, sysltpw=DFT, timeod=-1, slogint=Tue Sep 30 
08:26:48 2003, ulogint=Thu Sep 25 14:03:12 2003, sloginy=pts/ta, 
culogin=-1, uloginy=-1, umaxlntr=-1, alock=NO, lockout=0000000

For kicks, after this, I reset my password and tried again.  It worked. 
I hadn't thought my password was expired...I had no trouble logging in 
via non-ssh methods (ie, @console, telnet).  Thanks very much for the clues!

I'm a little embarrassed but grateful...

			-Eric



From slipcon at mercea.net  Tue Sep 30 22:55:40 2003
From: slipcon at mercea.net (Scott Lipcon)
Date: Tue, 30 Sep 2003 08:55:40 -0400
Subject: 3.7.1p2 on OpenBSD 2.8/sparc
Message-ID: <20030930125540.9770CC3@mercea.net>

Hello,

I'm trying to compile openssh 3.7.1p2 on a sparc 5 running OpenBSD
2.8.  

I compiled and installed OpenSSL 0.9.7b, and the tests all pass
without error.  

I configured openssh with --with-ssl-dir=/usr/local/ssl and ssh
compiles fine, however when it attepts to make a rsa1 key, ssh-keygen
core dumps:

oldyeek# make host-key
(cd openbsd-compat && make)
gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/
-L/usr/local/ssl/lib -lssh -lopenbsd-compat -lutil -lz  -lcrypto
Generating public/private rsa1 key pair.
Memory fault (core dumped) 
*** Error code 139

Stop in /usr/local/src/openssh-3.7.1p2 (line 326 of Makefile).

the same thing happens if I run the ssh-keygen command by hand:

oldyeek# ./ssh-keygen -t rsa1 -f ssh_host_key -N ""
Generating public/private rsa1 key pair.
zsh: segmentation fault (core dumped)  ./ssh-keygen -t rsa1 -f
ssh_host_key -N 

Ths dsa and rsa keys generate fine - its just the rsa1 key with a
problem.  Running ssh-keygen through gdb, I get:

(gdb) run -t rsa1 -f ssh_host_key -N ""
Starting program: /usr/local/src/openssh-3.7.1p2/./ssh-keygen -t rsa1
-f ssh_host_key -N ""
Generating public/private rsa1 key pair.

Program received signal SIGSEGV, Segmentation fault.
0x1c338 in BN_num_bits ()
(gdb) bt
#0  0x1c338 in BN_num_bits ()
#1  0x5d9c in key_save_private_rsa1 (key=0xd0600, filename=0xcaec8
"ssh_host_key", passphrase=0xd0670 "", 
    comment=0xf7fff2f8 "root at oldyeek.mercea.net") at authfile.c:124
#2  0x617c in key_save_private (key=0xd0600, filename=0xcaec8
"ssh_host_key", passphrase=0xd0670 "", 
    comment=0xf7fff2f8 "root at oldyeek.mercea.net") at authfile.c:209
#3  0x58e8 in main (ac=7, av=0xcaec8) at ssh-keygen.c:1095


Any ideas?   the bn_tests for openssl did pass, so I'm not sure if
this is a openssh or openssl problem.

Please cc me on any replies -
Thanks,

Scott







From jpoc at us.ibm.com  Tue Sep 30 23:37:02 2003
From: jpoc at us.ibm.com (James O'Connor)
Date: Tue, 30 Sep 2003 08:37:02 -0500
Subject: OpenSSH 3.7.1p2  AIX loginsuccess() issue
Message-ID: <OF8A3A793D.B6D6F131-ON86256DB1.0049D231-86256DB1.004ACD23@us.ibm.com>

Darren Tucker wrote:
> What password registry does the account use?  If you put "return;" at 
the
> top of aix_setauthdb() in openbsd-compat/port-aix.c does that make the
> difference?  (after recompiling, obviously.)

Running sshd at debug level 3 shows:

debug3: aix_setauthdb: AIX/setauthdb set registry to AFS

After inserting "return;" at the top of aix_setauthdb() in 
openbsd-compat/port-aix.c, loginsuccess() returns successfully and the 
last successful and unsuccessful logins are printed prior to the motd.

If I short circuit the aix_setauthdb() routine, will that cause any 
problems?

Thanks for the help and the excellent password expiry patch!

James O'Connor



From dtucker at zip.com.au  Tue Sep 30 23:55:42 2003
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 30 Sep 2003 23:55:42 +1000
Subject: OpenSSH 3.7.1p2  AIX loginsuccess() issue
References: <OF8A3A793D.B6D6F131-ON86256DB1.0049D231-86256DB1.004ACD23@us.ibm.com>
Message-ID: <3F798B5E.96A3F1A2@zip.com.au>

James O'Connor wrote:
> Running sshd at debug level 3 shows:
> 
> debug3: aix_setauthdb: AIX/setauthdb set registry to AFS
> 
> After inserting "return;" at the top of aix_setauthdb() in
> openbsd-compat/port-aix.c, loginsuccess() returns successfully and the
> last successful and unsuccessful logins are printed prior to the motd.
> 
> If I short circuit the aix_setauthdb() routine, will that cause any
> problems?

Possibly: you are probably no longer recording failed login attempts or
successful logins to your password registry.

It appears that your AFS password registry module does not support
loginsuccess(), or if it does then it doesn't work.  Does AFS have a
concept of "last logon"?

> Thanks for the help and the excellent password expiry patch!

You're welcome.

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