From ltsao at talk21.com  Thu Jun  2 01:30:58 2005
From: ltsao at talk21.com (Lewis Tsao)
Date: Wed, 1 Jun 2005 16:30:58 +0100 (BST)
Subject: x11 forwarding problem
Message-ID: <20050601153058.66480.qmail@web86601.mail.ukl.yahoo.com>

I login from system using Openssh 4.0p1 or 4.1p1 to
systems running Openssh before 3.9p1 or 3.7p1.

It appears the X11 stuff are either blocked or not
recognised. I get errors like

"xterm Xt error: Can't open display: <host>:10.0" or

"X11 connection rejected because of wrong
authentication.
X connection to localhost:10.0 broken....."

depending on whether I use "localhost" or not.

Connecting to systems running Openssh 4.0p1 or later
appear to be OK.


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com



From rtsai1111 at comcast.net  Thu Jun  2 03:17:31 2005
From: rtsai1111 at comcast.net (Robert Tsai)
Date: Wed, 1 Jun 2005 13:17:31 -0400
Subject: openssh-4.1p1 SFTP client directory listing sorting bug
Message-ID: <20050601171731.GA2366@post.harvard.edu>

Hello openssh developers--

The SFTP client has a bug that appears to have been in since
openssh-3.5p1 and onwards, when "ls" flags were introduced. The
symptom is that "ls -1" does not sort the directory entries. The
problem is that the call to qsort() is supplies a value of zero for
the number of elements in the array.

I've attached a patch that works for me (and should work for
everyone).

Please include me in any replies (that you want me to see); I'm not
subscribed to this list.

Thanks,
--Rob
-------------- next part --------------
--- openssh-4.1p1/sftp.c	Mon Mar 14 07:08:12 2005
+++ openssh-4.1p1-1/sftp.c	Wed Jun  1 12:50:47 2005
@@ -696,6 +696,7 @@
 	}
 
 	if (lflag & SORT_FLAGS) {
+		for (n = 0; d[n] != NULL; n++);
 		sort_flag = lflag & (SORT_FLAGS|LS_REVERSE_SORT);
 		qsort(d, n, sizeof(*d), sdirent_comp);
 	}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050601/98364e3d/attachment.bin 

From deengert at anl.gov  Thu Jun  2 04:00:58 2005
From: deengert at anl.gov (Douglas E. Engert)
Date: Wed, 01 Jun 2005 13:00:58 -0500
Subject: x11 forwarding problem
In-Reply-To: <20050601153058.66480.qmail@web86601.mail.ukl.yahoo.com>
References: <20050601153058.66480.qmail@web86601.mail.ukl.yahoo.com>
Message-ID: <429DF7DA.6000701@anl.gov>

Works for me from 4.1p1 to 3.8p1.

The man pages for sshd talk about how to setup ~/.ssh/rc to call xauth
and pass in the proto and cookie depending on how X11UseLocalhost is set.

What does xauth show?

Is the .Xauthority file shared between machines?


Lewis Tsao wrote:

> I login from system using Openssh 4.0p1 or 4.1p1 to
> systems running Openssh before 3.9p1 or 3.7p1.
> 
> It appears the X11 stuff are either blocked or not
> recognised. I get errors like
> 
> "xterm Xt error: Can't open display: <host>:10.0" or
> 
> "X11 connection rejected because of wrong
> authentication.
> X connection to localhost:10.0 broken....."
> 
> depending on whether I use "localhost" or not.
> 
> Connecting to systems running Openssh 4.0p1 or later
> appear to be OK.
> 
> 
> 	
> 	
> 		
> ___________________________________________________________ 
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



From frederik at a5.repetae.net  Thu Jun  2 10:54:39 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Wed, 1 Jun 2005 17:54:39 -0700
Subject: openssh timeouts
Message-ID: <20050602005439.GA15730@a5.repetae.net>

It appears that there are quite a lot of things that can cause ssh to
become incredibly slow - the problem is that ssh or programs that it
invokes depend on timeouts to try to maintain basic functionality in
cases where expected functionality is missing. I've experienced delays
stemming from timeouts from 'xauth', nis, DNS, and probably others.
These kinds of problems are very hard to debug, since recovery from
the error condition happens behind the scenes (or within sshd) and the
user never gets a warning message saying what went wrong.

I can see why some amount of resilience would be desired - you don't
want to be prevented from logging into a system just because X
forwarding doesn't work - but I wish I could be notified - in normal,
not verbose mode - of what the problems were, so that I didn't have to
go guessing whether it was just network slowness or not, and then
squinting at 'strace' logs and running 'sshd' in debug mode, every
time one of ssh's many dependencies got misconfigured. If there could
even just be a warning message "Warning - 'xauth add ...' taking too
long" or "Warning - DNS timed out, check /etc/resolv.conf or set
configuration option X to disable host IP checking" when a sub-task
takes longer than a certain amount of time, I think it would be very
helpful.

Has anyone given this kind of enhancement any thought?

Frederik

-- 
http://ofb.net/~frederik/



From goudron_et_plumes at yahoo.fr  Thu Jun  2 20:36:28 2005
From: goudron_et_plumes at yahoo.fr (Nestor Burma)
Date: Thu, 2 Jun 2005 12:36:28 +0200 (CEST)
Subject: Public key authentication and logging
Message-ID: <20050602103628.87249.qmail@web26704.mail.ukl.yahoo.com>

Hello,

[This message has been sent previously to the
ssh-users list, but got no answer, so maybe it's not a
usage problem. Sorry for the crossposting]

We are using OpenSSH 4.1p1 on a Linux box. The only
authentication method allowed is by public key.
Everything works without any problem, EXCEPT logging
in one situation :

1/ if a known user tries to log, with a proper (known)
key, as expected, we get a success message through
syslog, such as
:

Accepted publickey for USER from IP

2/ if an unknow user tries to log (obviously with or
without a "proper key"), again as expecte, we get a
failure message through syslog, such as :

Invalid user USER from IP

3/ but if a KNOWN user tries to log without a known
key, we get no message whatsoever.

Taking into account all the current brute forcing
tools, we feel this is somehow wrong. Of course, we
get bazillions of failures for unknown users, but
unfortunately some tools we saw just hammered 'root'
and a few, well-known account names. So getting no
failure message is bad for us.

Is it a misconfiguration on our part ? And if so, how
to change that ?

Sincerely,

-- Nb







	

	
		
_____________________________________________________________________________ 
D?couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid?os ! 
Cr?ez votre Yahoo! Mail sur http://fr.mail.yahoo.com



From djm at mindrot.org  Thu Jun  2 22:50:21 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 02 Jun 2005 22:50:21 +1000
Subject: Public key authentication and logging
In-Reply-To: <20050602103628.87249.qmail@web26704.mail.ukl.yahoo.com>
References: <20050602103628.87249.qmail@web26704.mail.ukl.yahoo.com>
Message-ID: <429F008D.3000702@mindrot.org>

Nestor Burma wrote:
> 3/ but if a KNOWN user tries to log without a known
> key, we get no message whatsoever.
> 
> Taking into account all the current brute forcing
> tools, we feel this is somehow wrong. Of course, we
> get bazillions of failures for unknown users, but
> unfortunately some tools we saw just hammered 'root'
> and a few, well-known account names. So getting no
> failure message is bad for us.

"LogLevel verbose" might give you some more details, but the
probability of someone guessing a private key are infintisimal.

-d



From goudron_et_plumes at yahoo.fr  Fri Jun  3 00:05:17 2005
From: goudron_et_plumes at yahoo.fr (Nestor Burma)
Date: Thu, 2 Jun 2005 16:05:17 +0200 (CEST)
Subject: Public key authentication and logging
In-Reply-To: <429F008D.3000702@mindrot.org>
Message-ID: <20050602140517.28627.qmail@web26702.mail.ukl.yahoo.com>

Hi Damien,

--- Damien Miller <djm at mindrot.org> a ?crit :

> Nestor Burma wrote:
> > 3/ but if a KNOWN user tries to log without a
> known
> > key, we get no message whatsoever.
> > 
> > Taking into account all the current brute forcing
> > tools, we feel this is somehow wrong. Of course,
> we
> > get bazillions of failures for unknown users, but
> > unfortunately some tools we saw just hammered
> 'root'
> > and a few, well-known account names. So getting no
> > failure message is bad for us.
> 
> "LogLevel verbose" might give you some more details,
> but the
> probability of someone guessing a private key are
> infintisimal.

This is true, but it is not where our problem lies. We
have some particularly painful
blockhead-with-authority reasonning along the line
"privileged accounts are _not_ concerned by all
bruteforcing programs since we see no error messages
in log files".
I know I should just throw him through the nearest
window (17th floor) but hey. Let's find a marginally
more civilized solution :-) So if those reject
messages were in the logfiles, he would see the light.
Maybe.
And is is somehow interesting to know, for example,
what the ratio "root account bruteforcing" to
"non-root account bruteforcing" looks like. Just for
the sake of statistics, flashy graphics and the like.
We'll test "LogLevel verbose", of course.
Thanks,

-- Nb


	

	
		
_____________________________________________________________________________ 
D?couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid?os ! 
Cr?ez votre Yahoo! Mail sur http://fr.mail.yahoo.com



From Searcy.Simpson at acxiom.com  Fri Jun  3 05:02:53 2005
From: Searcy.Simpson at acxiom.com (Simpson Searcy - ssimps)
Date: Thu, 2 Jun 2005 14:02:53 -0500
Subject: FW: openssh 4.0 - sftp batch mode behavior
Message-ID: <4C29A168DC38374589FA39FFD05362FAFF2E20@CWYMSX03.Corp.Acxiom.net>


Hello,
I just installed the openssh 4.0 for Solaris. The users have reported a
difference in behavior when using the batch mode of sftp client.

Previously they could issue the following command sftp -b batchfile
user at hostname and in the absence of publickey authentication they would
be issued the password prompt and they could enter password and the
process would continue.
After upgrading from 3.1 to 4.0 of ssh, now when the same command is
entered they get the following error message and are not receiving the
password prompt. 
       
       Permission denied (publickey,password,keyboard-interactive).

I have included the output from session in debug mode. Apparently, the
client is not trying any of the other authentication methods.

In the ssh_config file the PasswordAuthentication is set to yes.
       
OpenSSH_4.0p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to hostname [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /home/ssimps/.ssh/id_rsa type -1
debug1: identity file /home/ssimps/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostname' is known and matches the RSA host key.
debug1: Found key in /home/ssimps/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ssimps/.ssh/id_rsa
debug1: Trying private key: /home/ssimps/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
Connection closed

Any assistance would be greatly appreciated.

Thanks,
Searcy Simpson
Acxiom Corporation
501-342-4535
Searcy.Simpson at acxiom.com


**********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.



From djm at mindrot.org  Fri Jun  3 16:07:27 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 03 Jun 2005 16:07:27 +1000
Subject: FW: openssh 4.0 - sftp batch mode behavior
In-Reply-To: <4C29A168DC38374589FA39FFD05362FAFF2E20@CWYMSX03.Corp.Acxiom.net>
References: <4C29A168DC38374589FA39FFD05362FAFF2E20@CWYMSX03.Corp.Acxiom.net>
Message-ID: <429FF39F.1060702@mindrot.org>

Simpson Searcy - ssimps wrote:
> Hello,
> I just installed the openssh 4.0 for Solaris. The users have reported a
> difference in behavior when using the batch mode of sftp client.
> 
> Previously they could issue the following command sftp -b batchfile
> user at hostname and in the absence of publickey authentication they would
> be issued the password prompt and they could enter password and the
> process would continue.

The old behaviour was buggy: sftp's -b uses ssh's BatchMode config
option. From ssh_config(5):

> BatchMode
>    If set to ``yes'', passphrase/password querying will be disabled.
>    This option is useful in scripts and other batch jobs where no
>    user is present to supply the password.  The argument must be
>    ``yes'' or ``no''.  The default is ``no''.

I.e. a sftp client in batch mode shouldn't require any interaction to
function. This stops it from blocking or otherwise misbehaving in
scripts.

If your users need scripted transfers, they can try:

sftp user at host < batchfile

-d



From djm at mindrot.org  Sun Jun  5 15:00:39 2005
From: djm at mindrot.org (Damien Miller)
Date: Sun, 05 Jun 2005 05:00:39 -0000
Subject: The OpenSSH project turns five years old
Message-ID: <4158BEC0.50201@mindrot.org>

The OpenSSH project turns five years old
----------------------------------------

Five years ago, in late September 1999, the OpenSSH project was started.
It began with an audit, cleanup and update of the last free version
of Tatu Ylonen's legacy ssh-1.2.12 code. The project quickly gathered
pace, attracting a portability effort and, in early 2000, an independent
implementation of version 2 of the SSH protocol. Since then, OpenSSH
has led in the implementation of proactive security techniques such as
privilege separation & auto-reexecution.

The free software community were rapid adopters of OpenSSH, with most
free operating systems shipping OpenSSH within its first year of
existence. Over the last five years OpenSSH has become the most widely
used SSH protocol implementation (by a large margin) and has been
included in products from major vendors including IBM, Apple, HP, Sun,
Cisco and NetScreen. Today, OpenSSH runs on everything from mobile
phones to Cray supercomputers.

In providing a free, popular and easy to use secure login and command
execution protocol OpenSSH has been instrumental in speeding the
deprecation of insecure protocols like telnet and rlogin.

The OpenSSH team would like to thank all those who have supported the
project over the last five years, including individuals and vendors who
have donated funds or hardware. An extra special thanks to those who
have reported bugs or sent patches to the project.

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

http://www.openssh.com/



From djm at mindrot.org  Sun Jun  5 19:14:29 2005
From: djm at mindrot.org (Damien Miller)
Date: Sun, 05 Jun 2005 19:14:29 +1000
Subject: The OpenSSH project turns five years old
In-Reply-To: <4158BEC0.50201@mindrot.org>
References: <4158BEC0.50201@mindrot.org>
Message-ID: <42A2C275.7060106@mindrot.org>

Damien Miller wrote:
> The OpenSSH project turns five years old
> ----------------------------------------

If the following looks like you, then please fix your software and stop
replaying messages to the list:

> Received: from warr.ath.cx (70-32-9-83.frdrmd.adelphia.net [70.32.9.83])
> 	by shitei.mindrot.org (Postfix) with SMTP id 1A8A927C196
> 	for <openssh-unix-dev at mindrot.org>;
> 	Sun,  5 Jun 2005 15:00:29 +1000 (EST)
> Received: (qmail 30775 invoked by uid 1000); 5 Jun 2005 05:00:27 -0000
> Delivered-To: unknown
> Received: from suen.ed.psu.edu (146.186.175.19) by myria.szcat.lan with POP3; 
> 	05 Jun 2005 05:00:27 -0000
> Delivered-To: asuen at cdr19.ed.psu.edu
> Received: (qmail 6581 invoked from network); 28 Sep 2004 14:46:23 -0000
> Received: from tr12g04.aset.psu.edu (HELO tr12n04.aset.psu.edu)
> 	(128.118.146.130)
> 	by cdr19.ed.psu.edu with SMTP; 28 Sep 2004 14:46:23 -0000


Much as we love to relive the moment...



From tvpk at macnews.de  Sun Jun  5 16:36:56 2005
From: tvpk at macnews.de (Thorsten von Plotho-Kettner)
Date: Sun, 5 Jun 2005 08:36:56 +0200
Subject: (no subject)
Message-ID: <6E611615-E02A-4305-A6AD-336B0C55DE9B@macnews.de>




From Peter_Losher at isc.org  Tue Jun  7 15:04:46 2005
From: Peter_Losher at isc.org (Peter Losher)
Date: Mon, 6 Jun 2005 22:04:46 -0700
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <428F0B80.20404@zip.com.au>
References: <200505210249.02881.Peter_Losher@isc.org>
	<428F08E9.4060907@zip.com.au> <428F0B80.20404@zip.com.au>
Message-ID: <200506062204.55768.Peter_Losher@isc.org>

On Saturday 21 May 2005 03:20 am, Darren Tucker wrote:

> Darren Tucker wrote:
> > That version of OpenSSL may not work since the one that ships with
> > Solaris is missing some AES functions.
>
> Forgot to add: apparently if you install the "Solaris Data Encryption
> Supplement" (SUNWcry and SUNWcryr packages) then it will restore the
> missing functions.

tried that:

-=-
% pkginfo | grep SUNWcry
system      SUNWcry                          Crypt Utilities
system      SUNWcryr                         Solaris Root Crypto
-=-

... and it still blows up in the same place...

-=-
(cd openbsd-compat && gmake)
gmake[1]: Entering directory `/var/tmp/openssh-4.1p1/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. 
-I/usr/sfw/include  -I/usr/local/krb5/include -DHAVE_CONFIG_H -c 
bsd-arc4random.c
In file included from bsd-arc4random.c:18:
../log.h: In function `fatal':
../log.h:56: warning: empty declaration
../log.h:65: error: parse error before "volatile"
../log.h:65: error: old-style parameter declarations in prototyped function 
definition
../log.h:56: error: parameter name omitted
bsd-arc4random.c:20: error: `rcsid' undeclared (first use in this function)
bsd-arc4random.c:20: error: (Each undeclared identifier is reported only once
bsd-arc4random.c:20: error: for each function it appears in.)
bsd-arc4random.c:20: warning: left-hand operand of comma expression has no 
effect
bsd-arc4random.c:20: error: parse error before '}' token
gmake[1]: *** [bsd-arc4random.o] Error 1
gmake[1]: Leaving directory `/var/tmp/openssh-4.1p1/openbsd-compat'
gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2
-=-

Note that I am calling up the ssl bits from /opt/sfw where the version of 
OpenSSH that comes w/ Solaris resides.  (attempts to compile OpenSSL from 
source have been unsuccessful...)

Has anyone successfully compiled 4.1p1 on a Solaris 10 system?

-Peter
-- 
Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050606/4e86a6c4/attachment.bin 

From dtucker at zip.com.au  Tue Jun  7 15:17:34 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 07 Jun 2005 15:17:34 +1000
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <200506062204.55768.Peter_Losher@isc.org>
References: <200505210249.02881.Peter_Losher@isc.org>
	<428F08E9.4060907@zip.com.au> <428F0B80.20404@zip.com.au>
	<200506062204.55768.Peter_Losher@isc.org>
Message-ID: <42A52DEE.9050302@zip.com.au>

Peter Losher wrote:
[...]
> gmake[1]: Entering directory `/var/tmp/openssh-4.1p1/openbsd-compat'
> gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. 
> -I/usr/sfw/include  -I/usr/local/krb5/include -DHAVE_CONFIG_H -c 
> bsd-arc4random.c
> In file included from bsd-arc4random.c:18:
> ../log.h: In function `fatal':
> ../log.h:56: warning: empty declaration
> ../log.h:65: error: parse error before "volatile"
> ../log.h:65: error: old-style parameter declarations in prototyped function 
> definition

Others have reported these errors can be caused by an old sys/cdefs.h 
header left over from previous gcc installation:
http://bugzilla.mindrot.org/show_bug.cgi?id=1013

> Has anyone successfully compiled 4.1p1 on a Solaris 10 system?

I built 4.0p1 on Solaris 10/x86 a while back but not 4.1p1.

-- 
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 Peter_Losher at isc.org  Tue Jun  7 18:55:05 2005
From: Peter_Losher at isc.org (Peter Losher)
Date: Tue, 07 Jun 2005 01:55:05 -0700
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <42A52DEE.9050302@zip.com.au>
References: <200505210249.02881.Peter_Losher@isc.org>	<428F08E9.4060907@zip.com.au>
	<428F0B80.20404@zip.com.au>	<200506062204.55768.Peter_Losher@isc.org>
	<42A52DEE.9050302@zip.com.au>
Message-ID: <42A560E9.7030907@isc.org>

Darren Tucker wrote:

> Others have reported these errors can be caused by an old sys/cdefs.h
> header left over from previous gcc installation:
> http://bugzilla.mindrot.org/show_bug.cgi?id=1013

Grr, this was a fresh Solaris 10 install (which comes w/ gcc-3.4.2) so
there was no 'previous gcc' install for the file to be orphaned by...

>> Has anyone successfully compiled 4.1p1 on a Solaris 10 system?
>
>
> I built 4.0p1 on Solaris 10/x86 a while back but not 4.1p1.

Well after hearing the trouble other folks had w/ the gcc that came w/
Solaris 10, I went off and built 3.4.4...

-=-
% /usr/local/bin/gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.4/specs
Configured with: ./configure : (reconfigured) ./configure
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.4.4
-=-

And that fixed the first problem, but it now barfs at the linking phase...

-=-
/usr/local/bin/gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o
sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/
-L/usr/sfw/lib -R/usr/sfw/lib  -R/usr/local/krb5/lib -lssh
-lopenbsd-compat -lresolv -lcrypto -lrt -lz -lsocket -lnsl
-L/usr/local/krb5/lib -R/usr/local/krb5/lib -lgssapi_krb5 -lkrb5
-lk5crypto -lkrb5support -lcom_err -lresolv -lsocket -lnsl
Undefined                       first referenced
 symbol                             in file
EVP_aes_192_cbc                     ./libssh.a(cipher.o)
EVP_aes_256_cbc                     ./libssh.a(cipher.o)
ld: fatal: Symbol referencing errors. No output written to ssh
collect2: ld returned 1 exit status
gmake: *** [ssh] Error 1
-=-

Looks like more OpenSSL issues?

Best Wishes - Peter
--
Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050607/9d04dc8c/attachment.bin 

From dtucker at zip.com.au  Tue Jun  7 19:17:21 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 07 Jun 2005 19:17:21 +1000
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <42A560E9.7030907@isc.org>
References: <200505210249.02881.Peter_Losher@isc.org>	<428F08E9.4060907@zip.com.au>	<428F0B80.20404@zip.com.au>	<200506062204.55768.Peter_Losher@isc.org>	<42A52DEE.9050302@zip.com.au>
	<42A560E9.7030907@isc.org>
Message-ID: <42A56621.7090809@zip.com.au>

Peter Losher wrote:
> Undefined                       first referenced
>  symbol                             in file
> EVP_aes_192_cbc                     ./libssh.a(cipher.o)
> EVP_aes_256_cbc                     ./libssh.a(cipher.o)
> ld: fatal: Symbol referencing errors. No output written to ssh
[...]
> Looks like more OpenSSL issues?

Yeah that's the missing strong ciphers in the Solaris OpenSSL.  If the 
packages I mentioned earlier don't provide it (maybe it sticks the 
libraries in a non-standard path?) then you ought to be able to build it 
with the vanilla OpenSSL distribution, configure'ed --with-ssl-dir.

-- 
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  Tue Jun  7 20:52:28 2005
From: f_mohr at yahoo.de (frank)
Date: Tue, 07 Jun 2005 12:52:28 +0200
Subject: Known problems OpenSSH 2.5 -> 4.0p1?
Message-ID: <42A57C6C.7000505@yahoo.de>

Are there any known problems with scp from OpenSSH 2.5 clients to a
4.0p1 server (both AIX - the new one AIX 5.2)?

A customer is migrating data from a old system using OpenSSH 2.5 to our
system and complains about not terminating scp transfers.
On the new system I see the ssh processes running since a few days with
1 sec CPU time - but no scp process.

Frank

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



From snuggles at acampo.net  Wed Jun  8 17:13:00 2005
From: snuggles at acampo.net (Martin Kiepfer)
Date: Wed,  8 Jun 2005 09:13:00 +0200
Subject: Error when allocating PTY
Message-ID: <200506080713.j587D0rZ032122@mail.acampo.net>

hi everybody,

I'm working on an boot image and actually try to get an ssh server working on clients, booting that 
image over the net. I want to authenticate with my public key on the client, which seems to work fine.
The only problem I have is that the sshd couldn't open an console. I've allready tested some things,
but didn't fix it, yet. in den dev directory all tty's and pty's () exists but I suppose my problem
has somethinkg to do with a missing kernel configuration.
Here is the corresponding debug output of sshd:

debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: Received SIGCHLD.
openpty: Exec format error
session_pty_req: session 0 alloc failed
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Received SIGCHLD.

Perhaps some of you can give me a hint or even had the same problem and can tell me how to fix it. Am I right that "openpty" is a syscall? I've taken a look into the System.map from my kernel
but didn't find it.

regards,
Martin

_____________________________________________________
Kostenloser Mailservice von Acampo
http://www.acampo.net/
100MB Mailspeicher + 50MB Webdisk

From dtucker at zip.com.au  Wed Jun  8 19:27:31 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 08 Jun 2005 19:27:31 +1000
Subject: Error when allocating PTY
In-Reply-To: <200506080713.j587D0rZ032122@mail.acampo.net>
References: <200506080713.j587D0rZ032122@mail.acampo.net>
Message-ID: <42A6BA03.4000706@zip.com.au>

Martin Kiepfer wrote:
> I'm working on an boot image and actually try to get an ssh server
> working on clients, booting that  image over the net.

Using what OS and what libraries?  Configured OpenSSH with what options? 
  You mentioned System.map so I'm guessing the kernel is Linux but the 
rest is not specified.

> Here is the corresponding debug output of sshd:
[...]
> debug1: Allocating pty.
> debug1: Received SIGCHLD.
> openpty: Exec format error

Some platforms use a privileged helper program to set permissions and 
perform other operations on ptys that require privileges.  I suspect 
this is also the case for yours, and that the helper is missing or broken.

 > Am I right that "openpty" is a syscall?

It's usually a library function (probably in libc but possibly elsewhere).

-- 
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 snuggles at acampo.net  Wed Jun  8 19:27:43 2005
From: snuggles at acampo.net (Martin Kiepfer)
Date: Wed,  8 Jun 2005 11:27:43 +0200
Subject: Error when allocating PTY - supplement
Message-ID: <200506080927.j589RhHM001226@mail.acampo.net>

I'm running a debian linux (sarge - kernel 2.6.11)

> I'm working on an boot image and actually try to get an ssh server working on clients, booting that
> image over the net. I want to authenticate with my public key on the client, which seems to work fine.
> The only problem I have is that the sshd couldn't open an console. I've allready tested some things,
> but didn't fix it, yet. in den dev directory all tty's and pty's () exists but I suppose my problem
> has somethinkg to do with a missing kernel configuration.
> Here is the corresponding debug output of sshd:
> 
> debug1: server_input_channel_req: channel 0 request pty-req reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req pty-req
> debug1: Allocating pty.
> debug1: Received SIGCHLD.
> openpty: Exec format error
> session_pty_req: session 0 alloc failed
> debug1: server_input_channel_req: channel 0 request shell reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req shell
> debug1: Received SIGCHLD.
> 
> Perhaps some of you can give me a hint or even had the same problem and can tell me how to fix it. Am I right that "openpty" is a syscall? I've taken a look into the System.map from my kernel
> but didn't find it.
 
regards,
Martin


_____________________________________________________
Kostenloser Mailservice von Acampo
http://www.acampo.net/
100MB Mailspeicher + 50MB Webdisk

From dan at lightwave.net.ru  Wed Jun  8 22:32:16 2005
From: dan at lightwave.net.ru (Dan Yefimov)
Date: Wed, 8 Jun 2005 16:32:16 +0400 (MSD)
Subject: Error when allocating PTY
In-Reply-To: <200506080713.j587D0rZ032122@mail.acampo.net>
Message-ID: <Pine.LNX.4.44.0506081620560.19120-100000@D00M.lightwave.net.ru>

On Wed, 8 Jun 2005, Martin Kiepfer wrote:

> hi everybody,
> 
> I'm working on an boot image and actually try to get an ssh server working on clients, booting that 
> image over the net. I want to authenticate with my public key on the client, which seems to work fine.
> The only problem I have is that the sshd couldn't open an console. I've allready tested some things,
> but didn't fix it, yet. in den dev directory all tty's and pty's () exists but I suppose my problem
> has somethinkg to do with a missing kernel configuration.
> Here is the corresponding debug output of sshd:
> 
> debug1: channel 0: new [server-session]
> debug1: session_new: init
> debug1: session_new: session 0
> debug1: session_open: channel 0
> debug1: session_open: session 0: link with channel 0
> debug1: server_input_channel_open: confirm session
> debug1: server_input_channel_req: channel 0 request pty-req reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req pty-req
> debug1: Allocating pty.
> debug1: Received SIGCHLD.
> openpty: Exec format error
> session_pty_req: session 0 alloc failed
> debug1: server_input_channel_req: channel 0 request shell reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req shell
> debug1: Received SIGCHLD.
> 
> Perhaps some of you can give me a hint or even had the same problem and can tell me how to fix it. Am I right that "openpty" is a syscall? I've taken a look into the System.map from my kernel
> but didn't find it.
> 
The matter is that openpty is not a syscall but is a library function. Your
LIBC needs to exec some SUID helper to do chown/chmod on a pty, but it didn't 
find it. You can find that helper under /usr/libexec directory or, in some 
systems, under /lib directory, and you should copy that helper to the same
place in your boot image in order to fix your problem.
-- 

    Sincerely Your, Dan.



From quellyn at lanl.gov  Thu Jun  9 00:11:07 2005
From: quellyn at lanl.gov (Quellyn L. Snead)
Date: Wed, 08 Jun 2005 08:11:07 -0600
Subject: Compiling openssh-4.0p1 on Solaris 10.
Message-ID: <42A6FC7B.7010803@lanl.gov>


>>Darren Tucker wrote:
>>    
>>
>>>That version of OpenSSL may not work since the one that ships with
>>>Solaris is missing some AES functions.
>>>      
>>>
>>Forgot to add: apparently if you install the "Solaris Data Encryption
>>Supplement" (SUNWcry and SUNWcryr packages) then it will restore the
>>missing functions.
>>    
>>
>
>tried that:
>
>-=-
>% pkginfo | grep SUNWcry
>system      SUNWcry                          Crypt Utilities
>system      SUNWcryr                         Solaris Root Crypto
>-=-
>
>... and it still blows up in the same place...
>
>-=-
>(cd openbsd-compat && gmake)
>gmake[1]: Entering directory `/var/tmp/openssh-4.1p1/openbsd-compat'
>gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. 
>-I/usr/sfw/include  -I/usr/local/krb5/include -DHAVE_CONFIG_H -c 
>bsd-arc4random.c
>In file included from bsd-arc4random.c:18:
>../log.h: In function `fatal':
>../log.h:56: warning: empty declaration
>../log.h:65: error: parse error before "volatile"
>../log.h:65: error: old-style parameter declarations in prototyped function 
>definition
>../log.h:56: error: parameter name omitted
>bsd-arc4random.c:20: error: `rcsid' undeclared (first use in this function)
>bsd-arc4random.c:20: error: (Each undeclared identifier is reported only once
>bsd-arc4random.c:20: error: for each function it appears in.)
>bsd-arc4random.c:20: warning: left-hand operand of comma expression has no 
>effect
>bsd-arc4random.c:20: error: parse error before '}' token
>gmake[1]: *** [bsd-arc4random.o] Error 1
>gmake[1]: Leaving directory `/var/tmp/openssh-4.1p1/openbsd-compat'
>gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2
>-=-
>
>Note that I am calling up the ssl bits from /opt/sfw where the version of 
>OpenSSH that comes w/ Solaris resides.  (attempts to compile OpenSSL from 
>source have been unsuccessful...)
>
>Has anyone successfully compiled 4.1p1 on a Solaris 10 system?
>
>-Peter
>  
>

I have compiled 4.0p1 on Solaris 10 (sparc). There was a problem with 
OpenSSL 0.9.7g at the time:
 
http://www.mail-archive.com/openssl-dev at openssl.org/msg18853.html

I ended up downloading openssl-0.9.7-stable-SNAP-20050317.tar.gz and 
building that instead.

-- 
*******************************************************
Quellyn L. Snead
UNIX Effort Team ( unixeffort at lanl.gov )
CCN-1 Central Services and Development Team
Los Alamos National Laboratory
(505) 667-4185
*******************************************************



From zibeli at yahoo.com  Thu Jun  9 00:22:54 2005
From: zibeli at yahoo.com (Zibeli Aton)
Date: Wed, 8 Jun 2005 07:22:54 -0700 (PDT)
Subject: hashing Hosts in ssh_config file
Message-ID: <20050608142254.48902.qmail@web42209.mail.yahoo.com>

Hello,

I hope this isn't a stupid question, but after editing
my sshd_config file to set HashKnownHosts to 'yes'
after this feature was recently added it occured to me
that many of those same hosts are listed in "Hosts"
lines in my ssh_config file.  (The servers I connect
to use different ports and require different
IdentityFiles, so I set the appropriate options for
each server in the ssh_config file to save me from
having to remember and type them when I connect to a
given server.)  Since this basically, I would think,
negates any usefulness of the HashKnownHosts option, I
wondered if there had been any thought given to
implementing a similar feature for the hosts listed in
"Hosts" lines of the ssh_config file.  I'm guessing
that since the "Hosts" directives allow wildcards,
this would be difficult or impossible, but curiosity
leads me to check with the developer's list.

Thanks in advance for any replies,
Zibeli.



		
__________________________________ 
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html



From dopheide at ncsa.uiuc.edu  Thu Jun  9 05:51:18 2005
From: dopheide at ncsa.uiuc.edu (Mike Dopheide)
Date: Wed, 8 Jun 2005 14:51:18 -0500 (CDT)
Subject: Possible security flaw in OpenSSH and/or pam_krb5
Message-ID: <Pine.LNX.4.44.0506081447410.2501-100000@osage.ncsa.uiuc.edu>


openssh-unix-dev at mindrot.org
kerberos at ncsa.uiuc.edu

We believe there is a security flaw in either OpenSSH and/or RedHat's pam_krb5
module.  When a Kerberos principal has the REQUIRES_PWCHANGE
(+needchange) flag set, OpenSSH+pam_krb5 will still successfully
authenticate the user.  Local 'su' and 'login' fail in this case which
leads us to believe it's at least partially a problem with OpenSSH's
PAM code.

We first noticed this flaw on SLES8 and verified the same problem on
RedHat 9 and RHEL 3.

RedHat 9                                pam_krb5-1.60-1
RedHat Enterprise Linux AS 3 Update 5   pam_krb5-1.75-1
SuSE SLES 8                             pam_krb5-1.0.3-199

Most of my work has been with RedHat 9 and I see the problem with
OpenSSH versions 3.7.1p2, 3.8.1p1, and 4.1p1.

Typically we try not to use pam_krb5, opting for native kerberos
authentication wherever possible. However, the ramification of this
problem is that accounts can still be used after we've 'expired' them
on the KDCs.

Last week (when we still thought it was solely a pam_krb5 issue) we
sent an email to some of the vendors.  The only one who responded was
Nicolas Williams from Sun who has been very helpful.  I'm not very
familiar with how PAM works or the OpenSSH codebase for that matter,
so I'm including some of his tips in case it helps in the
investigation of the problem:

------------------------------------------
 - If the application is not calling, or ignoring non-success return
   values of pam_acct_mgmt() yet still allowing access to the account,
   then the application has a gaping hole and is at fault.

 - A PAM module may defer authentication and authorization, in
   password-change-required situations, to pam_sm_chauthtok(3PAM), but
   if so it must: a) return PAM_SUCCESS from its
   pam_sm_authenticate(3PAM) _AND_ b) return PAM_NEW_AUTHTOK_REQD from
   its pam_sm_acct_mgmt(3PAM).

   Kerberos V and LDAP BIND type modules typically do this.

   If it does otherwise then it will either not support password aging
   or sport a gaping security hole.

    - Such modules' account modules must be configured as required or
      requisite or binding.

    - Care must be taken not to configure PAM account stacks in such a
      way that another sufficient or binding module may preempt calls to
      pam_sm_acct_mgmt(3PAM) entry points of modules such as pam_krb5.

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

We have not tested OpenSSH with PAM under Solaris.

If anyone has any questions regarding our setup I'll do my best to
answer them.  We're hoping someone can duplicate the problem and we're
willing to test any fixes/patches that come up.

Thanks,
Mike

---------------------------------------------------
Mike Dopheide                dopheide at ncsa.uiuc.edu
System Engineer                Phone:  217.244.0299
NCSA, University of Illinois     Fax:  217.244.1987



From djm at mindrot.org  Thu Jun  9 05:52:34 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 09 Jun 2005 05:52:34 +1000
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <42A56621.7090809@zip.com.au>
References: <200505210249.02881.Peter_Losher@isc.org>	<428F08E9.4060907@zip.com.au>	<428F0B80.20404@zip.com.au>	<200506062204.55768.Peter_Losher@isc.org>	<42A52DEE.9050302@zip.com.au>	<42A560E9.7030907@isc.org>
	<42A56621.7090809@zip.com.au>
Message-ID: <42A74C82.3000308@mindrot.org>

Darren Tucker wrote:
> Peter Losher wrote:
> 
>> Undefined                       first referenced
>>  symbol                             in file
>> EVP_aes_192_cbc                     ./libssh.a(cipher.o)
>> EVP_aes_256_cbc                     ./libssh.a(cipher.o)
>> ld: fatal: Symbol referencing errors. No output written to ssh
> 
> [...]
> 
>> Looks like more OpenSSL issues?
> 
> Yeah that's the missing strong ciphers in the Solaris OpenSSL.  If the 
> packages I mentioned earlier don't provide it (maybe it sticks the 
> libraries in a non-standard path?) then you ought to be able to build it 
> with the vanilla OpenSSL distribution, configure'ed --with-ssl-dir.

Here's a patch, please let me know if it helps.

-d

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssl-lobotomy.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050609/f157bdf6/attachment.ksh 

From dtucker at zip.com.au  Thu Jun  9 09:34:50 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 09 Jun 2005 09:34:50 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <Pine.LNX.4.44.0506081447410.2501-100000@osage.ncsa.uiuc.edu>
References: <Pine.LNX.4.44.0506081447410.2501-100000@osage.ncsa.uiuc.edu>
Message-ID: <42A7809A.8060908@zip.com.au>

I can't comment on the Kerberos aspects, but as far as sshd's PAM 
interface goes:

Mike Dopheide wrote:
[...]
>  - If the application is not calling, or ignoring non-success return
>    values of pam_acct_mgmt() yet still allowing access to the account,
>    then the application has a gaping hole and is at fault.

sshd calls pam_acct_mgmt (via auth{1,2}.c -> auth-pam.c:do_pam_account). 
  If it returns PAM_NEW_AUTHTOK_REQD, sshd forces a password change, 
either via keyboard-interactive or once the session starts.

You can check what the PAM stack is returning by running sshd in debug 
mode and checking for the line "PAM: do_pam_account pam_acct_mgmt = x".

>  - A PAM module may defer authentication and authorization, in
>    password-change-required situations, to pam_sm_chauthtok(3PAM), but
>    if so it must: a) return PAM_SUCCESS from its
>    pam_sm_authenticate(3PAM) _AND_ b) return PAM_NEW_AUTHTOK_REQD from
>    its pam_sm_acct_mgmt(3PAM).
[...]
> If anyone has any questions regarding our setup I'll do my best to
> answer them.  We're hoping someone can duplicate the problem and we're
> willing to test any fixes/patches that come up.

What do the PAM config files look like?  Can you provide sshd debug output?

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



From dtucker at zip.com.au  Thu Jun  9 09:58:38 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 09 Jun 2005 09:58:38 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42A7809A.8060908@zip.com.au>
References: <Pine.LNX.4.44.0506081447410.2501-100000@osage.ncsa.uiuc.edu>
	<42A7809A.8060908@zip.com.au>
Message-ID: <42A7862E.6080107@zip.com.au>

Darren Tucker wrote:
> I can't comment on the Kerberos aspects, but as far as sshd's PAM 
> interface goes:
> 
> Mike Dopheide wrote:
> [...]
> 
>>  - If the application is not calling, or ignoring non-success return
>>    values of pam_acct_mgmt() yet still allowing access to the account,
>>    then the application has a gaping hole and is at fault.
> 
> sshd calls pam_acct_mgmt (via auth{1,2}.c -> auth-pam.c:do_pam_account). 
>  If it returns PAM_NEW_AUTHTOK_REQD, sshd forces a password change, 
> either via keyboard-interactive or once the session starts.
> 
> You can check what the PAM stack is returning by running sshd in debug 
> mode and checking for the line "PAM: do_pam_account pam_acct_mgmt = x".

Further to this: I just did a quick test by overriding the return code 
of pam_acct_mgmt() with PAM_NEW_AUTHTOK_REQD, which resulted in the 
following behaviour or similar for at least v2+password, v2+pubkey and 
v1+tis authentications.

$ ssh -p 2022 localhost
Last login: Thu Jun  9 09:42:43 2005 from localhost
debug3: channel 0: close_fds r -1 w -1 e -1 c -1
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user dtucker.
Changing password for dtucker
(current) UNIX password:

(this is the output from "passwd", however for protocol 2 + 
keyboard-interactive, or privsep=no for any combination of protocol and 
authentication, the change will be done via pam_chauthtok().)

Could you please provide your sshd_config, PAM config and debug output 
from sshd -ddd ?  Which non-kerberos authentication are you using?

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



From dtucker at zip.com.au  Thu Jun  9 10:55:29 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 09 Jun 2005 10:55:29 +1000
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <42A74C82.3000308@mindrot.org>
References: <200505210249.02881.Peter_Losher@isc.org>	<428F08E9.4060907@zip.com.au>	<428F0B80.20404@zip.com.au>	<200506062204.55768.Peter_Losher@isc.org>	<42A52DEE.9050302@zip.com.au>	<42A560E9.7030907@isc.org>	<42A56621.7090809@zip.com.au>
	<42A74C82.3000308@mindrot.org>
Message-ID: <42A79381.5070409@zip.com.au>

Damien Miller wrote:
> I just noticed this on the Solaris 10 beta box that is lying around here:
> fix compilation on Sun's cripples SUNWopenssl package.
[...]
> +#ifndef OPENSSL_LOBOTOMISED_AES
>  	{ "aes192-cbc",		SSH_CIPHER_SSH2, 16, 24, EVP_aes_192_cbc },
>  	{ "aes256-cbc",		SSH_CIPHER_SSH2, 16, 32, EVP_aes_256_cbc },
>  	{ "rijndael-cbc at lysator.liu.se",
>  				SSH_CIPHER_SSH2, 16, 32, EVP_aes_256_cbc },
>  #endif

We've got the required code right there in rijndael.c, it would be easy 
to build non-crippled binaries even if the system openssl doesn't have 
those...

As for the configure test, why not just:
	AC_CHECK_FUNCS(EVP_aes_192_cbc EVP_aes_256_cbc)
?

-- 
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 dopheide at ncsa.uiuc.edu  Thu Jun  9 14:11:54 2005
From: dopheide at ncsa.uiuc.edu (Mike Dopheide)
Date: Wed, 8 Jun 2005 23:11:54 -0500 (CDT)
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42A7862E.6080107@zip.com.au>
Message-ID: <Pine.LNX.4.44.0506082127280.13727-101000@osage.ncsa.uiuc.edu>


Darren,

Thanks for taking the time to investigate this.  I've attached the 
requested debugging info, but I've also made a little bit of forward 
progress.

In the sshd PAM file you'll see the following line:
account     [default=bad success=ok user_unknown=ignore service_err=ignore 
system_err=ignore] /lib/security/$ISA/pam_krb5afs.so

By including this line I am asked to change my password.  As expected PAM 
first asks to change the Unix password and then for some reason it asks to 
change the Kerberos 5 password twice.  (As a side note, it ends up setting 
an /etc/shadow entry during one of these times it's changing my "Current 
Kerbero 5 Password".  That shouldn't have happened either and it confused 
me for about an hour.)

Without this line the debug output shows (attached sshd.debug):
debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success)

With this line, we see (attached sshd.debug2):
debug3: PAM: do_pam_account pam_acct_mgmt = 12 (Authentication token is no 
longer valid; new one required.)

In both of these cases pam_krb5 debug messages show:
Jun  8 22:42:54 quercus sshd[2510]: pam_krb5: get_int_tkt returned 
Password has expired

(Side note 2, I could never get pam_krb5 to write debug messages with it's 
'debug' option in the PAM config file.  I ended up hard coding the DEBUG 
#define.)

So I guess maybe all of this is just a misunderstanding of how to 
configure the PAM stack, but it seems broken to me that the default 
behavior for an expired principal is to succeed at authenticating.  

Confused,
Mike

PS.  You'll notice from the sshd_config and debug output that our sshd is 
patched to support native kerberos authentication with GSSAPI, but that 
shouldn't have any bearing on the PAM issues.

> > You can check what the PAM stack is returning by running sshd in debug 
> > mode and checking for the line "PAM: do_pam_account pam_acct_mgmt = x".
> 
> Further to this: I just did a quick test by overriding the return code 
> of pam_acct_mgmt() with PAM_NEW_AUTHTOK_REQD, which resulted in the 
> following behaviour or similar for at least v2+password, v2+pubkey and 
> v1+tis authentications.
> 
> $ ssh -p 2022 localhost
> Last login: Thu Jun  9 09:42:43 2005 from localhost
> debug3: channel 0: close_fds r -1 w -1 e -1 c -1
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for user dtucker.
> Changing password for dtucker
> (current) UNIX password:
> 
> (this is the output from "passwd", however for protocol 2 + 
> keyboard-interactive, or privsep=no for any combination of protocol and 
> authentication, the change will be done via pam_chauthtok().)
> 
> Could you please provide your sshd_config, PAM config and debug output 
> from sshd -ddd ?  Which non-kerberos authentication are you using?
> 
> 

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.tar.gz
Type: application/x-gzip
Size: 7875 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050608/6de6b789/attachment.bin 

From dtucker at zip.com.au  Thu Jun  9 14:50:23 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 09 Jun 2005 14:50:23 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <Pine.LNX.4.44.0506082127280.13727-101000@osage.ncsa.uiuc.edu>
References: <Pine.LNX.4.44.0506082127280.13727-101000@osage.ncsa.uiuc.edu>
Message-ID: <42A7CA8F.50503@zip.com.au>

Mike Dopheide wrote:
> Darren,
> 
> Thanks for taking the time to investigate this.

You're welcome.

> I've attached the requested debugging info, but I've also made a
> little bit of forward progress.
> 
> In the sshd PAM file you'll see the following line:
> account     [default=bad success=ok user_unknown=ignore service_err=ignore 
> system_err=ignore] /lib/security/$ISA/pam_krb5afs.so

I can guess why the line wasn't there: I'll bet that logins via ssh 
pubkey authentications won't work any more.

> By including this line I am asked to change my password.  As expected PAM 
> first asks to change the Unix password and then for some reason it asks to 
> change the Kerberos 5 password twice.

Regarding the double password request: I see you're using 
keyboard-interactive.  I suspect it's another manifestation of bug #688: 
the process where you authenticate exits, taking pam_krb5's private 
stash of data with it.  When sshd later calls pam_chauthtok() pam_krb5 
has to reestablish it.

Unfortunately there's no good, general solution for this right now. 
Patch #642 from bug #688 will help in the kerberos case as will building 
sshd with -DUNSUPPORTED_POSIX_THREADS_HACK (aka -DUSE_POSIX_THREADS for 
versions < 4.1p1).

You can also try "ssh -o PreferredAuthentications=password yourserver", 
but be aware that this will behave differently with and without privsep.

> So I guess maybe all of this is just a misunderstanding of how to 
> configure the PAM stack, but it seems broken to me that the default 
> behavior for an expired principal is to succeed at authenticating.  

That's just how PAM works: you don't get to know about things like 
password expiry until later.  A module could potentially force a change 
during pam_authenticate via the conversation mechanism before allowing 
the authentication to succeed, however that would break things 
(including sshd's PasswordAuthentication via PAM).

> PS.  You'll notice from the sshd_config and debug output that our sshd is 
> patched to support native kerberos authentication with GSSAPI, but that 
> shouldn't have any bearing on the PAM issues.

Probably not but you really ought to reproduce problems with unpatched 
versions before reporting them.

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



From djm at mindrot.org  Thu Jun  9 14:53:27 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 09 Jun 2005 14:53:27 +1000
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <42A79381.5070409@zip.com.au>
References: <200505210249.02881.Peter_Losher@isc.org>	<428F08E9.4060907@zip.com.au>	<428F0B80.20404@zip.com.au>	<200506062204.55768.Peter_Losher@isc.org>	<42A52DEE.9050302@zip.com.au>	<42A560E9.7030907@isc.org>	<42A56621.7090809@zip.com.au>	<42A74C82.3000308@mindrot.org>
	<42A79381.5070409@zip.com.au>
Message-ID: <42A7CB47.3000106@mindrot.org>

Darren Tucker wrote:
> Damien Miller wrote:
> 
>> I just noticed this on the Solaris 10 beta box that is lying around here:
>> fix compilation on Sun's cripples SUNWopenssl package.
> 
> [...]
> 
>> +#ifndef OPENSSL_LOBOTOMISED_AES
>>      { "aes192-cbc",        SSH_CIPHER_SSH2, 16, 24, EVP_aes_192_cbc },
>>      { "aes256-cbc",        SSH_CIPHER_SSH2, 16, 32, EVP_aes_256_cbc },
>>      { "rijndael-cbc at lysator.liu.se",
>>                  SSH_CIPHER_SSH2, 16, 32, EVP_aes_256_cbc },
>>  #endif
> 
> 
> We've got the required code right there in rijndael.c, it would be easy 
> to build non-crippled binaries even if the system openssl doesn't have 
> those...

That sounds like a good idea, but we must be careful to avoid symbol
clashes between the underlying AES implementations.

> As for the configure test, why not just:
>     AC_CHECK_FUNCS(EVP_aes_192_cbc EVP_aes_256_cbc)
> ?

OpenSSL has an unfortunate habit of hiding lots of public API functions
behind #defines. I wasn't sure which way the EVP_* functions were set up
(and I didn't want to check for all the versions of OpenSSL we support).

-d



From dtucker at zip.com.au  Thu Jun  9 15:25:25 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 09 Jun 2005 15:25:25 +1000
Subject: Compiling openssh-4.0p1 on Solaris 10.
In-Reply-To: <42A7CB47.3000106@mindrot.org>
References: <200505210249.02881.Peter_Losher@isc.org>	<428F08E9.4060907@zip.com.au>	<428F0B80.20404@zip.com.au>	<200506062204.55768.Peter_Losher@isc.org>	<42A52DEE.9050302@zip.com.au>	<42A560E9.7030907@isc.org>	<42A56621.7090809@zip.com.au>	<42A74C82.3000308@mindrot.org>	<42A79381.5070409@zip.com.au>
	<42A7CB47.3000106@mindrot.org>
Message-ID: <42A7D2C5.5060209@zip.com.au>

Damien Miller wrote:
> Darren Tucker wrote:
>> We've got the required code right there in rijndael.c, it would be 
>> easy to build non-crippled binaries even if the system openssl doesn't 
>> have those...
> 
> That sounds like a good idea, but we must be careful to avoid symbol
> clashes between the underlying AES implementations.

The rijndael code is already built unconditionally into libssh.a so it 
should be simply a matter of: "#define EVP_aes_192_cbc evp_rijndael".

> OpenSSL has an unfortunate habit of hiding lots of public API functions
> behind #defines. I wasn't sure which way the EVP_* functions were set up
> (and I didn't want to check for all the versions of OpenSSL we support).

They're real functions in the version I checked (0.9.7f) but I didn't 
check any others.

-- 
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 Jun  9 18:13:01 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 9 Jun 2005 18:13:01 +1000
Subject: Disconnects from Cisco router ssh sessions.
Message-ID: <20050609081301.GA5590@gate.dodgy.net.au>

Hi.

I don't do much with routers any more but recently I was configuring a
Cisco via SSH when my session disconnected while pasting large amounts
of text.  I'm told this is common.

I've had this patch for a while but I've not been able to test it. If
anyone is regularly experiencing this kind of issue could you please
tell me if the attached patch helps?

(The buffer size limit is from me, the IGNOREMSG flag is because PuTTY
thinks that particular version has it.)

Thanks.

Index: compat.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/compat.c,v
retrieving revision 1.71
diff -u -p -r1.71 compat.c
--- compat.c	1 Mar 2005 10:24:33 -0000	1.71
+++ compat.c	9 Jun 2005 07:54:45 -0000
@@ -151,6 +151,8 @@ compat_datafellows(const char *version)
 		  "OSU_1.5alpha3*",	SSH_BUG_PASSWORDPAD },
 		{ "*SSH_Version_Mapper*",
 					SSH_BUG_SCANNER },
+		{ "Cisco-1.25",
+					SSH_BUG_BIGV1PACKET|SSH_BUG_IGNOREMSG },
 		{ "Probe-*",
 					SSH_BUG_PROBE },
 		{ NULL,			0 }
Index: compat.h
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/compat.h,v
retrieving revision 1.37
diff -u -p -r1.37 compat.h
--- compat.h	1 Mar 2005 10:24:33 -0000	1.37
+++ compat.h	9 Jun 2005 07:55:01 -0000
@@ -56,6 +56,7 @@
 #define SSH_BUG_PROBE		0x00400000
 #define SSH_BUG_FIRSTKEX	0x00800000
 #define SSH_OLD_FORWARD_ADDR	0x01000000
+#define SSH_BUG_BIGV1PACKET	0x02000000
 
 void     enable_compat13(void);
 void     enable_compat20(void);
Index: sshconnect.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshconnect.c,v
retrieving revision 1.130
diff -u -p -r1.130 sshconnect.c
--- sshconnect.c	26 May 2005 02:23:44 -0000	1.130
+++ sshconnect.c	9 Jun 2005 07:55:14 -0000
@@ -514,6 +514,11 @@ ssh_exchange_identification(void)
 	chop(client_version_string);
 	chop(server_version_string);
 	debug("Local version string %.100s", client_version_string);
+
+	if (datafellows & SSH_BUG_BIGV1PACKET) {
+		debug("Found big SSHv1 packet bug, limiting packet size");
+		packet_set_maxsize(4 * 1024);
+	}
 }
 
 /* defaults to 'no' */

-- 
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 Nicolas.Williams at sun.com  Fri Jun 10 02:19:40 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 11:19:40 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42A7862E.6080107@zip.com.au>
Message-ID: <20050609161940.GA29902@binky.Central.Sun.COM>

On Thu Jun  9 09:58:11 2005, Darren Tucker wrote:
> Further to this: I just did a quick test by overriding the return code
> of pam_acct_mgmt() with PAM_NEW_AUTHTOK_REQD, which resulted in the
> following behaviour or similar for at least v2+password, v2+pubkey and
> v1+tis authentications.
> 
> $ ssh -p 2022 localhost
> Last login: Thu Jun  9 09:42:43 2005 from localhost
> debug3: channel 0: close_fds r -1 w -1 e -1 c -1
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for user dtucker.
> Changing password for dtucker
> (current) UNIX password:

While I can see how you can make this behaviour not be insecure, it is
clearly not ideal: it works only if the user was trying to open a pty
channel, otherwise the client's requests fail or, if the client wanted
only to do local port forwarding, then the client might wait a long time
to find out that something went wrong with user authentication.

The SSHv2 protocol provides for a much cleaner way to do this: force use
of keyboard-interactive userauth and let PAM drive keyboard-interactive
to change the user's expired password.

> (this is the output from "passwd", however for protocol 2 + 
> keyboard-interactive, or privsep=no for any combination of protocol and 
> authentication, the change will be done via pam_chauthtok().)

But will the call to pam_chauthtok() happen in the context of
keyboard-interactive userauth?  Or does it still require a pty channel?

Nico
-- 



From Nicolas.Williams at sun.com  Fri Jun 10 02:36:40 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 11:36:40 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42A7CA8F.50503@zip.com.au>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
Message-ID: <20050609163639.GB29902@binky.Central.Sun.COM>

On Thu Jun  9 14:49:57 2005, Darren Tucker wrote:
> Mike Dopheide wrote:
> > By including this line I am asked to change my password.  As expected PAM
> > first asks to change the Unix password and then for some reason it asks to
> > change the Kerberos 5 password twice.
> 
> Regarding the double password request: I see you're using
> keyboard-interactive.  I suspect it's another manifestation of bug #688:
> the process where you authenticate exits, taking pam_krb5's private
> stash of data with it.  When sshd later calls pam_chauthtok() pam_krb5
> has to reestablish it.

Pretty much all PAM calls for a given login attempt and session have to
be executed with the same PAM handle, in the same process, and with all
privileges.  That's just how PAM works.

I figure this answers my question in my other reply -- sshd must be
calling pam_chauthtok() in the context of a pty channel, in a child
process or something like that, rather than in the context of
keyboard-interactive userauth.

> That's just how PAM works: you don't get to know about things like 
> password expiry until later.  A module could potentially force a change 
> during pam_authenticate via the conversation mechanism before allowing 
> the authentication to succeed, however that would break things 
> (including sshd's PasswordAuthentication via PAM).

I agree that this is an obnoxious feature of PAM.  I'm thinking about
how we could make it better, but for the time being, that's how it is.

However, this does not excuse sshd, or any other application, not
handling PAM properly (see above).  When pam_acct_mgmt() returns
PAM_NEW_AUTHTOK_REQD while processing userauths other than
keyboard-interactive sshd should force failure of the current userauth
and then indicate that only keyboard-interactive userauth may continue.
When the client tries keyboard-interactive start PAM processing from
scratch, call pam_authenticate(), pam_acct_mgmt() and, if it
returns PAM_NEW_AUTHTOK_REQD, call pam_chauthtok(), then pam_setcred(),
then pam_open_session(), only then can SSH userauth be considered
complete.

Nico
-- 



From dtucker at zip.com.au  Fri Jun 10 10:10:05 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 10 Jun 2005 10:10:05 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050609163639.GB29902@binky.Central.Sun.COM>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
Message-ID: <42A8DA5D.5030905@zip.com.au>

Nicolas Williams wrote:
[...]
> Pretty much all PAM calls for a given login attempt and session have to
> be executed with the same PAM handle, in the same process, and with all
> privileges.  That's just how PAM works.

You forgot: and that process (or one of its decendants) must later 
become the user's shell.

> I figure this answers my question in my other reply -- sshd must be
> calling pam_chauthtok() in the context of a pty channel, in a child
> process or something like that, rather than in the context of
> keyboard-interactive userauth.

It depends.  For the current release:

For SSHv2 and keyboard-interactive it's done via kbdint, privsep or no.

For SSHv1 and SSHv2 passwordauthentication when privsep=yes, it uses 
passwd, because by the time the pty session is opened, sshd no longer 
has the privilege to call pam_chauthtok().   For privsep=no it uses 
pam_chauthtok(), because it can.

[...]
> I agree that this is an obnoxious feature of PAM.  I'm thinking about
> how we could make it better, but for the time being, that's how it is.

If you're looking for ways to improve PAM then I've got a long list, but 
the biggest single improvement you could make is to come up with a 
rentrant replacement for the blocking callback conversation function model.

A distant second would be some way to export and import the 
module-private data, or to provide shared-mmap'ped space to store it. 
(eg zlib provides a callback registration for allocating memory which 
sshd uses.)

If PAM had either of those things then we would not be having this 
discussion.  The blocking callback is the crux of the matter, though: it 
either causes the other problems or makes them harder to deal with.

> However, this does not excuse sshd, or any other application, not
> handling PAM properly (see above).   When pam_acct_mgmt() returns
> PAM_NEW_AUTHTOK_REQD while processing userauths other than
> keyboard-interactive sshd should force failure of the current userauth
> and then indicate that only keyboard-interactive userauth may continue.
> When the client tries keyboard-interactive start PAM processing from
> scratch, call pam_authenticate(), pam_acct_mgmt() and, if it
> returns PAM_NEW_AUTHTOK_REQD, call pam_chauthtok(), then pam_setcred(),
> then pam_open_session(),

The setcred/session order depends on whose documentation you believe, 
and it's the other way around according to yours (pam_setcred(3PAM)).

> only then can SSH userauth be considered
> complete.

PAM's architecture makes this difficult for sshd.  Any of those 
functions may block and attempt to interact with the user during which 
time sshd's event loop isn't running, and the event loop the only means 
sshd has to communicate with the user.  Snookered.

And before you say "threads": your PAM modules may be thread-safe (and I 
don't know if they are or not) but I'll guarantee that not every module 
is (and the LinuxPAM docs effectively give module writers a license to 
write thread-unsafe code).

-- 
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 Nicolas.Williams at sun.com  Fri Jun 10 11:36:16 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 20:36:16 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42A8DA5D.5030905@zip.com.au>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
Message-ID: <20050610013615.GT659@binky.Central.Sun.COM>

On Fri, Jun 10, 2005 at 10:10:05AM +1000, Darren Tucker wrote:
> Nicolas Williams wrote:
> [...]
> >Pretty much all PAM calls for a given login attempt and session have to
> >be executed with the same PAM handle, in the same process, and with all
> >privileges.  That's just how PAM works.
> 
> You forgot: and that process (or one of its decendants) must later 
> become the user's shell.

That's true, but I didn't forget it -- it wasn't relevant here yet :)

> >I figure this answers my question in my other reply -- sshd must be
> >calling pam_chauthtok() in the context of a pty channel, in a child
> >process or something like that, rather than in the context of
> >keyboard-interactive userauth.
> 
> It depends.  For the current release:
> 
> For SSHv2 and keyboard-interactive it's done via kbdint, privsep or no.
> 
> For SSHv1 and SSHv2 passwordauthentication when privsep=yes, it uses 
> passwd, because by the time the pty session is opened, sshd no longer 
> has the privilege to call pam_chauthtok().   For privsep=no it uses 
> pam_chauthtok(), because it can.

Basically, I would either support CHANGEREQ as best I could, or not
allow userauth to complete if the password can't be changed that way or
if the protocol is SSHv1.

> [...]
> >I agree that this is an obnoxious feature of PAM.  I'm thinking about
> >how we could make it better, but for the time being, that's how it is.
> 
> If you're looking for ways to improve PAM then I've got a long list, but 
> the biggest single improvement you could make is to come up with a 
> rentrant replacement for the blocking callback conversation function model.

I have a long list too.  As OpenSolaris comes online we'll have lots of
opportunity to go over these lists, design and implement improvements.

As for the conversation function issue you have, I've advised the
OpenSSH team before on how to handle the matter, namely: nest the
dispatch_run() event loop.  That is how Solaris 10's sshd does it, no
fork(), no threads.  There was one tricky issue: unwinding the stack on
keyboard-interactive userauth abandonment, but it was not that tricky.

> A distant second would be some way to export and import the 
> module-private data, or to provide shared-mmap'ped space to store it. 
> (eg zlib provides a callback registration for allocating memory which 
> sshd uses.)

Hadn't thought of that.  If the issue is that you want to move PAM
handles across processes I'd like to understand just why.

> If PAM had either of those things then we would not be having this 
> discussion.  The blocking callback is the crux of the matter, though: it 
> either causes the other problems or makes them harder to deal with.

Sun had to deal with the same problem and found a simple solution.  See
above.

> >However, this does not excuse sshd, or any other application, not
> >handling PAM properly (see above).   When pam_acct_mgmt() returns
> >PAM_NEW_AUTHTOK_REQD while processing userauths other than
> >keyboard-interactive sshd should force failure of the current userauth
> >and then indicate that only keyboard-interactive userauth may continue.
> >When the client tries keyboard-interactive start PAM processing from
> >scratch, call pam_authenticate(), pam_acct_mgmt() and, if it
> >returns PAM_NEW_AUTHTOK_REQD, call pam_chauthtok(), then pam_setcred(),
> >then pam_open_session(),
> 
> The setcred/session order depends on whose documentation you believe, 
> and it's the other way around according to yours (pam_setcred(3PAM)).

Indeed, my error.

> >only then can SSH userauth be considered
> >complete.
> 
> PAM's architecture makes this difficult for sshd.  Any of those 
> functions may block and attempt to interact with the user during which 
> time sshd's event loop isn't running, and the event loop the only means 
> sshd has to communicate with the user.  Snookered.

See above!

> And before you say "threads": your PAM modules may be thread-safe (and I 
> don't know if they are or not) but I'll guarantee that not every module 
> is (and the LinuxPAM docs effectively give module writers a license to 
> write thread-unsafe code).

See above!

Look ma, no threads!

Nico
-- 



From dtucker at zip.com.au  Fri Jun 10 12:58:36 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 10 Jun 2005 12:58:36 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050610013615.GT659@binky.Central.Sun.COM>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
Message-ID: <42A901DC.8060201@zip.com.au>

Nicolas Williams wrote:
> On Fri, Jun 10, 2005 at 10:10:05AM +1000, Darren Tucker wrote:
> 
>>Nicolas Williams wrote:
>>[...]
>>
>>>Pretty much all PAM calls for a given login attempt and session have to
>>>be executed with the same PAM handle, in the same process, and with all
>>>privileges.  That's just how PAM works.
>>
>>You forgot: and that process (or one of its decendants) must later 
>>become the user's shell.
> 
> That's true, but I didn't forget it -- it wasn't relevant here yet :)

It does matter for the topic that started this entire thread: otherwise 
the sshd process doing the PAM authentication could just call all of the 
pam functions (authenticate, acct_mgmt, maybe chauthtok, session, 
setcred) then exit.

The problem is one of the modules here is stashing some stuff using 
pam_set_data and that's vanishing.  If PAM didn't require/desire that 
the user's shell be a child of the process that called pam_authenticate 
then this would not be an issue.

>>For SSHv2 and keyboard-interactive it's done via kbdint, privsep or no.
>>
>>For SSHv1 and SSHv2 passwordauthentication when privsep=yes, it uses 
>>passwd, because by the time the pty session is opened, sshd no longer 
>>has the privilege to call pam_chauthtok().   For privsep=no it uses 
>>pam_chauthtok(), because it can.
> 
> Basically, I would either support CHANGEREQ as best I could, or not
> allow userauth to complete if the password can't be changed that way or
> if the protocol is SSHv1.

If you are referring to SSH2's USERAUTH_PASSWD_CHANGEREQ then that's a 
completely separate can of worms.  Implementing that reliably via PAM 
would likely be tricky because the conversation pam_chauthtok will have 
doesn't map exactly to the single "new password" field that CHANGEREQ 
will supply.  It's like the blind PasswordAuthentication case only worse.

(Examples: will it ask for the old password?  Will it ask for a 
confirmation of the new password?  Trusted-mode HP-UX will first ask you 
if you want to pick or generate a password, how does a blind 
conversation function answer that?  How does it even know what the PAM 
message means since the message types are opaque (other than string 
matching the text)?  And probably another gazillion platform-specific 
and module-specific variants I don't even know about.)

The passwd code is required to support password changing on platforms 
that don't have PAM, or are configured to not use PAM.  Using it for PAM 
in some case, while not ideal, is better than nothing and, as you point 
out, also works with SSHv1.

[...]
> As for the conversation function issue you have, I've advised the
> OpenSSH team before on how to handle the matter, namely: nest the
> dispatch_run() event loop.  That is how Solaris 10's sshd does it, no
> fork(), no threads.  There was one tricky issue: unwinding the stack on
> keyboard-interactive userauth abandonment, but it was not that tricky.

If you mean calling the event loop from within the conversation function 
then OpenSSH used to do something like that (as far back as 2.5x which I 
believe SunSSH was originally based on).  It predates my involvement 
though, so I can't comment on what issues it had.  I suspect that 
privsep makes it much tricker.  djm may wish to comment on this.

>>A distant second would be some way to export and import the 
>>module-private data, or to provide shared-mmap'ped space to store it. 
>>(eg zlib provides a callback registration for allocating memory which 
>>sshd uses.)
> 
> Hadn't thought of that.  If the issue is that you want to move PAM
> handles across processes I'd like to understand just why.

The handle is fine (it already exists in both processes I care about) 
it's what the module(s) store during authentication via pam_set_data 
that is the problem.  If the need for a separate process goes away then 
this problem goes away 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 Nicolas.Williams at sun.com  Fri Jun 10 13:58:06 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 22:58:06 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42A901DC.8060201@zip.com.au>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<42A901DC.8060201@zip.com.au>
Message-ID: <20050610035806.GX659@binky.Central.Sun.COM>

On Fri, Jun 10, 2005 at 12:58:36PM +1000, Darren Tucker wrote:
> Nicolas Williams wrote:
> >On Fri, Jun 10, 2005 at 10:10:05AM +1000, Darren Tucker wrote:
> >
> >>Nicolas Williams wrote:
> >>[...]
> >>
> >>>Pretty much all PAM calls for a given login attempt and session have to
> >>>be executed with the same PAM handle, in the same process, and with all
> >>>privileges.  That's just how PAM works.
> >>
> >>You forgot: and that process (or one of its decendants) must later 
> >>become the user's shell.
> >
> >That's true, but I didn't forget it -- it wasn't relevant here yet :)
> 
> It does matter for the topic that started this entire thread: otherwise 
> the sshd process doing the PAM authentication could just call all of the 
> pam functions (authenticate, acct_mgmt, maybe chauthtok, session, 
> setcred) then exit.
> 
> The problem is one of the modules here is stashing some stuff using 
> pam_set_data and that's vanishing.  If PAM didn't require/desire that 
> the user's shell be a child of the process that called pam_authenticate 
> then this would not be an issue.

The data is vanishing because the calls aren't being made with the same
PAM handle (or it might be that the module has fork-safety issues and
the PAM calls aren't being made in the same process).

> >>For SSHv2 and keyboard-interactive it's done via kbdint, privsep or no.
> >>
> >>For SSHv1 and SSHv2 passwordauthentication when privsep=yes, it uses 
> >>passwd, because by the time the pty session is opened, sshd no longer 
> >>has the privilege to call pam_chauthtok().   For privsep=no it uses 
> >>pam_chauthtok(), because it can.
> >
> >Basically, I would either support CHANGEREQ as best I could, or not
> >allow userauth to complete if the password can't be changed that way or
> >if the protocol is SSHv1.
> 
> If you are referring to SSH2's USERAUTH_PASSWD_CHANGEREQ then that's a 
> completely separate can of worms.  Implementing that reliably via PAM 
> would likely be tricky because the conversation pam_chauthtok will have 
> doesn't map exactly to the single "new password" field that CHANGEREQ 
> will supply.  It's like the blind PasswordAuthentication case only worse.

Set PAM_OLDAUTHOK and PAM_AUTHTOK and call pam_chauthtok() with the
PAM_SILENT flag and a conversation function that returns an error.

If pam_chauthtok() fails, then userauth fails and you're done.

> [...]
> >As for the conversation function issue you have, I've advised the
> >OpenSSH team before on how to handle the matter, namely: nest the
> >dispatch_run() event loop.  That is how Solaris 10's sshd does it, no
> >fork(), no threads.  There was one tricky issue: unwinding the stack on
> >keyboard-interactive userauth abandonment, but it was not that tricky.
> 
> If you mean calling the event loop from within the conversation function 
> then OpenSSH used to do something like that (as far back as 2.5x which I 
> believe SunSSH was originally based on).  It predates my involvement 
> though, so I can't comment on what issues it had.  I suspect that 
> privsep makes it much tricker.  djm may wish to comment on this.

Privsep makes it tickier, but not that much trickier -- you just have to
nest the event loop in the monitor instead.

> >>A distant second would be some way to export and import the 
> >>module-private data, or to provide shared-mmap'ped space to store it. 
> >>(eg zlib provides a callback registration for allocating memory which 
> >>sshd uses.)
> >
> >Hadn't thought of that.  If the issue is that you want to move PAM
> >handles across processes I'd like to understand just why.
> 
> The handle is fine (it already exists in both processes I care about) 
> it's what the module(s) store during authentication via pam_set_data 
> that is the problem.  If the need for a separate process goes away then 
> this problem goes away too.

What separate process?  Why is sshd doing the PAM calls in different
processes, instead of in the same one?

Nico
-- 



From Lehnert at Uni-Bremen.de  Fri Jun 10 17:38:21 2005
From: Lehnert at Uni-Bremen.de (G Lehnert)
Date: Fri, 10 Jun 2005 09:38:21 +0200
Subject: 4.1p1 on AIX5200-05
Message-ID: <42A9436D.9040407@Uni-Bremen.de>

sshd disconnects

openssh-4.1p1
on IBM p690 AIX 5200-05

using:
   openssl-0.9.7g
   zlib-1.2.2

   openssh-4.1p1
   CC="gcc  -O0 -maix64" ./configure       #- 64-Bit !!!

Compiles ok. ssh works fine.

sshd starts, accepts password, user authenticated
and then disconnects.

Debug log of both sshd and trying-to-connect client
(3.9p1-3.2 on Linux) are enclosed.
For test purposes por 3333 is used; however, same
behaviour when entirely installed and run on 22.

Kind regards
g lehnert


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: client_log.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050610/1e78b306/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sshd_log.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050610/1e78b306/attachment-0001.txt 

From Nicolas.Williams at sun.com  Sat Jun 11 00:39:01 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 10 Jun 2005 09:39:01 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050610035806.GX659@binky.Central.Sun.COM>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<42A901DC.8060201@zip.com.au>
	<20050610035806.GX659@binky.Central.Sun.COM>
Message-ID: <20050610143901.GB711@binky.Central.Sun.COM>

On Thu, Jun 09, 2005 at 10:58:06PM -0500, Nicolas Williams wrote:
> On Fri, Jun 10, 2005 at 12:58:36PM +1000, Darren Tucker wrote:
> > Nicolas Williams wrote:
> > [...]
> > >As for the conversation function issue you have, I've advised the
> > >OpenSSH team before on how to handle the matter, namely: nest the
> > >dispatch_run() event loop.  That is how Solaris 10's sshd does it, no
> > >fork(), no threads.  There was one tricky issue: unwinding the stack on
> > >keyboard-interactive userauth abandonment, but it was not that tricky.
> > 
> > If you mean calling the event loop from within the conversation function 
> > then OpenSSH used to do something like that (as far back as 2.5x which I 
> > believe SunSSH was originally based on).  It predates my involvement 
> > though, so I can't comment on what issues it had.  I suspect that 
> > privsep makes it much tricker.  djm may wish to comment on this.

BTW, Solaris 10's SUNWssh is based on OpenSSH 3.5*, Solaris 9's is based
on OpenSSH 2.5*.  And the dispatch_run() loop nesting idea did originate
with OpenSSH.

Nico
-- 



From openssh-unix-dev-mindrot at vbgunz.com  Sun Jun 12 02:28:41 2005
From: openssh-unix-dev-mindrot at vbgunz.com (Victor B. Gonzalez)
Date: Sat, 11 Jun 2005 12:28:41 -0400
Subject: Building NT installer. Need Advice RE: File Structure.
Message-ID: <285190883.20050611122841@vbgunz.com>

Hello OpenSSH,

 I am working on building an installer for a stand alone OpenSSH
 4.1p1-1 build for NT systems. Since it is built with Cygwin, it seems
 Cygwin bombed the OpenSSH directory with a ton of erroneous files.

 The installer is so far perfect and I am seeking advice. Which of the
 following files from the following structure are totally
 unnecessary? I wish to know so I can clean up the build.

 Some references are made to "SSHWindows 3.8.1p1" which was used
 *ONLY* as a reference tool.

 Thank you!

 PS. Following is a quick legend. Feel free to modify this list in
 any way as long as it makes sense in the end. Thanks again!

     >> These files are in question. Are these files necessary in any way on NT?
     ?? These files are found in SSHWindows 3.8.1p1 BUT are NOT found in Cygwin 2.457.2.2
     !! These files are important "mainly documentation". Only found in SSHWindows 3.8.1p1
     @! PERSONAL REFERENCE

@! 147 files match exactly
-----------------------
     >> bin\c_rehash
        bin\chmod.exe
        bin\chown.exe
        bin\crypt.exe
        bin\cygcrypt-0.dll
        bin\cygcrypto-0.9.7.dll
        bin\cygiconv-2.dll
        bin\cygminires.dll
        bin\cygrunsrv.exe
        bin\cygssl-0.9.7.dll
        bin\cygwin1.dll
        bin\cygz.dll
        bin\false.exe
        bin\ls.exe
        bin\mkdir.exe
        bin\mkgroup.exe
        bin\mkpasswd.exe
        bin\openssl.exe
     >> bin\openssl_fips_fingerprint
        bin\rm.exe
        bin\scp.exe
        bin\sftp.exe
        bin\sh.exe
     >> bin\slogin
        bin\ssh.exe
        bin\ssh-add.exe
        bin\ssh-agent.exe
     >> bin\ssh-host-config
        bin\ssh-keygen.exe
        bin\ssh-keyscan.exe
     >> bin\ssh-user-config
     >> etc\profile.d\openssl.csh
     >> etc\profile.d\openssl.sh
     >> etc\setup\crypt.lst.gz
     >> etc\setup\cygrunsrv.lst.gz
     >> etc\setup\installed.db
     >> etc\setup\last-action
     >> etc\setup\last-cache
     >> etc\setup\minires.lst.gz
     >> etc\setup\openssh.lst.gz
     >> etc\setup\openssl.lst.gz
     >> etc\setup\timestamp
        etc\ssh_config
        etc\ssh_host_dsa_key
        etc\ssh_host_dsa_key.pub
        etc\ssh_host_key
        etc\ssh_host_key.pub
        etc\ssh_host_rsa_key
        etc\ssh_host_rsa_key.pub
        etc\sshd_config
        etc\moduli
     >> lib\libcrypt.a
     >> lib\libcrypt.dll.a
     >> usr\include\crypt.h
        usr\sbin\sftp-server.exe
        usr\sbin\sshd.exe
        usr\sbin\ssh-keysign.exe
        usr\share\doc\Cygwin\crypt.README
        usr\share\doc\Cygwin\cygrunsrv.README
        usr\share\doc\Cygwin\minires-1.00-1.README
        usr\share\doc\Cygwin\openssh.README
        usr\share\doc\Cygwin\openssl-0.9.7g.README
        usr\share\doc\minires-1.00\LICENSE
        usr\share\doc\openssh\ChangeLog
        usr\share\doc\openssh\CREDITS
        usr\share\doc\openssh\LICENCE
        usr\share\doc\openssh\OVERVIEW
        usr\share\doc\openssh\README
        usr\share\doc\openssh\README.dns
        usr\share\doc\openssh\README.privsep
        usr\share\doc\openssh\README.smartcard
        usr\share\doc\openssh\RFC.nroff
        usr\share\doc\openssh\TODO
        usr\share\doc\openssh\WARNING.RNG
        usr\share\doc\openssl\CHANGES
        usr\share\doc\openssl\CHANGES.SSLeay
        usr\share\doc\openssl\INSTALL
        usr\share\doc\openssl\LICENSE
        usr\share\doc\openssl\NEWS
        usr\share\doc\openssl\README
     >> usr\share\man\man1\scp.1
     >> usr\share\man\man1\sftp.1
     >> usr\share\man\man1\slogin.1
     >> usr\share\man\man1\ssh.1
     >> usr\share\man\man1\ssh-add.1
     >> usr\share\man\man1\ssh-agent.1
     >> usr\share\man\man1\ssh-keygen.1
     >> usr\share\man\man1\ssh-keyscan.1
     >> usr\share\man\man5\ssh_config.5
     >> usr\share\man\man5\sshd_config.5
     >> usr\share\man\man8\sftp-server.8
     >> usr\share\man\man8\sshd.8
     >> usr\share\man\man8\ssh-keysign.8
     >> usr\share\terminfo\c\cygwin
        usr\share\Ssh.bin
     >> usr\ssl\man\man1\asn1parse.1
     >> usr\ssl\man\man1\ca.1
     >> usr\ssl\man\man1\CA.pl.1
     >> usr\ssl\man\man1\ciphers.1
     >> usr\ssl\man\man1\crl.1
     >> usr\ssl\man\man1\crl2pkcs7.1
     >> usr\ssl\man\man1\dgst.1
     >> usr\ssl\man\man1\dhparam.1
     >> usr\ssl\man\man1\dsa.1
     >> usr\ssl\man\man1\dsaparam.1
     >> usr\ssl\man\man1\enc.1
     >> usr\ssl\man\man1\errstr.1
     >> usr\ssl\man\man1\gendsa.1
     >> usr\ssl\man\man1\genrsa.1
     >> usr\ssl\man\man1\md2.1
     >> usr\ssl\man\man1\md4.1
     >> usr\ssl\man\man1\md5.1
     >> usr\ssl\man\man1\mdc2.1
     >> usr\ssl\man\man1\nseq.1
     >> usr\ssl\man\man1\ocsp.1
     >> usr\ssl\man\man1\openssl.1
     >> usr\ssl\man\man1\passwd.1
     >> usr\ssl\man\man1\pkcs12.1
     >> usr\ssl\man\man1\pkcs7.1
     >> usr\ssl\man\man1\pkcs8.1
     >> usr\ssl\man\man1\rand.1
     >> usr\ssl\man\man1\req.1
     >> usr\ssl\man\man1\ripemd160.1
     >> usr\ssl\man\man1\rsa.1
     >> usr\ssl\man\man1\rsautl.1
     >> usr\ssl\man\man1\s_client.1
     >> usr\ssl\man\man1\s_server.1
     >> usr\ssl\man\man1\s_time.1
     >> usr\ssl\man\man1\sess_id.1
     >> usr\ssl\man\man1\sha.1
     >> usr\ssl\man\man1\sha1.1
     >> usr\ssl\man\man1\smime.1
     >> usr\ssl\man\man1\speed.1
     >> usr\ssl\man\man1\spkac.1
     >> usr\ssl\man\man1\verify.1
     >> usr\ssl\man\man1\version.1
     >> usr\ssl\man\man1\x509.1
     >> usr\ssl\man\man5\config.5
     >> usr\ssl\man\man7\des_modes.7
     >> usr\ssl\man\man7\Modes_of_DES.7
     >> usr\ssl\misc\c_hash
     >> usr\ssl\misc\c_info
     >> usr\ssl\misc\c_issuer
     >> usr\ssl\misc\c_name
     >> usr\ssl\misc\CA.pl
     >> usr\ssl\misc\CA.sh
        usr\ssl\openssl.cnf

@! 3 files don't match
-------------------
     >> etc\setup\last-connection
     >> etc\setup\last-mirror
     >> var\run\utmp

@! 8 folders and files unique
--------------------------
     ?? bin\last.exe
     ?? bin\mkpasswd.c
     ?? bin\quietcmd.bat
     ?? bin\switch.c
     ?? bin\switch.exe
     ?? etc\banner.txt
     ?? usr\sbin\custom-sshd.bat
     !! usr\share\doc\SSHWindows 3.8.1p1\

-- 
 Best regards,
 Victor B. Gonzalez
                          
 OpenSSH-4.1p1-1
 Cygwin 2.457.2.2
 Windows XP  5.1 Build  2600 Service Pack 2



From openssh-unix-dev-mindrot at vbgunz.com  Sun Jun 12 13:07:46 2005
From: openssh-unix-dev-mindrot at vbgunz.com (Victor B. Gonzalez)
Date: Sat, 11 Jun 2005 23:07:46 -0400
Subject: Building NT installer. Need Advice RE: File Structure.
Message-ID: <92721059.20050611230746@vbgunz.com>

Hello OpenSSH,

 I am working on building an installer for a stand alone OpenSSH
 4.1p1-1 build for NT systems. Since it is built with Cygwin, it seems
 Cygwin bombed the OpenSSH directory with a ton of erroneous files.

 The installer is so far perfect and I am seeking advice. Which of the
 following files from the following structure are totally
 unnecessary? I wish to know so I can clean up the build.

 Some references are made to "SSHWindows 3.8.1p1" which was used
 *ONLY* as a reference tool.

 Thank you!

 PS. Following is a quick legend. Feel free to modify this list in
 any way as long as it makes sense in the end. Thanks again!

     >> These files are in question. Are these files necessary in any way on NT?
     ?? These files are found in SSHWindows 3.8.1p1 BUT are NOT found in Cygwin 2.457.2.2
     !! These files are important "mainly documentation". Only found in SSHWindows 3.8.1p1
     @! PERSONAL REFERENCE

@! 147 files match exactly
-----------------------
     >> bin\c_rehash
        bin\chmod.exe
        bin\chown.exe
        bin\crypt.exe
        bin\cygcrypt-0.dll
        bin\cygcrypto-0.9.7.dll
        bin\cygiconv-2.dll
        bin\cygminires.dll
        bin\cygrunsrv.exe
        bin\cygssl-0.9.7.dll
        bin\cygwin1.dll
        bin\cygz.dll
        bin\false.exe
        bin\ls.exe
        bin\mkdir.exe
        bin\mkgroup.exe
        bin\mkpasswd.exe
        bin\openssl.exe
     >> bin\openssl_fips_fingerprint
        bin\rm.exe
        bin\scp.exe
        bin\sftp.exe
        bin\sh.exe
     >> bin\slogin
        bin\ssh.exe
        bin\ssh-add.exe
        bin\ssh-agent.exe
     >> bin\ssh-host-config
        bin\ssh-keygen.exe
        bin\ssh-keyscan.exe
     >> bin\ssh-user-config
     >> etc\profile.d\openssl.csh
     >> etc\profile.d\openssl.sh
     >> etc\setup\crypt.lst.gz
     >> etc\setup\cygrunsrv.lst.gz
     >> etc\setup\installed.db
     >> etc\setup\last-action
     >> etc\setup\last-cache
     >> etc\setup\minires.lst.gz
     >> etc\setup\openssh.lst.gz
     >> etc\setup\openssl.lst.gz
     >> etc\setup\timestamp
        etc\ssh_config
        etc\ssh_host_dsa_key
        etc\ssh_host_dsa_key.pub
        etc\ssh_host_key
        etc\ssh_host_key.pub
        etc\ssh_host_rsa_key
        etc\ssh_host_rsa_key.pub
        etc\sshd_config
        etc\moduli
     >> lib\libcrypt.a
     >> lib\libcrypt.dll.a
     >> usr\include\crypt.h
        usr\sbin\sftp-server.exe
        usr\sbin\sshd.exe
        usr\sbin\ssh-keysign.exe
        usr\share\doc\Cygwin\crypt.README
        usr\share\doc\Cygwin\cygrunsrv.README
        usr\share\doc\Cygwin\minires-1.00-1.README
        usr\share\doc\Cygwin\openssh.README
        usr\share\doc\Cygwin\openssl-0.9.7g.README
        usr\share\doc\minires-1.00\LICENSE
        usr\share\doc\openssh\ChangeLog
        usr\share\doc\openssh\CREDITS
        usr\share\doc\openssh\LICENCE
        usr\share\doc\openssh\OVERVIEW
        usr\share\doc\openssh\README
        usr\share\doc\openssh\README.dns
        usr\share\doc\openssh\README.privsep
        usr\share\doc\openssh\README.smartcard
        usr\share\doc\openssh\RFC.nroff
        usr\share\doc\openssh\TODO
        usr\share\doc\openssh\WARNING.RNG
        usr\share\doc\openssl\CHANGES
        usr\share\doc\openssl\CHANGES.SSLeay
        usr\share\doc\openssl\INSTALL
        usr\share\doc\openssl\LICENSE
        usr\share\doc\openssl\NEWS
        usr\share\doc\openssl\README
     >> usr\share\man\man1\scp.1
     >> usr\share\man\man1\sftp.1
     >> usr\share\man\man1\slogin.1
     >> usr\share\man\man1\ssh.1
     >> usr\share\man\man1\ssh-add.1
     >> usr\share\man\man1\ssh-agent.1
     >> usr\share\man\man1\ssh-keygen.1
     >> usr\share\man\man1\ssh-keyscan.1
     >> usr\share\man\man5\ssh_config.5
     >> usr\share\man\man5\sshd_config.5
     >> usr\share\man\man8\sftp-server.8
     >> usr\share\man\man8\sshd.8
     >> usr\share\man\man8\ssh-keysign.8
     >> usr\share\terminfo\c\cygwin
        usr\share\Ssh.bin
     >> usr\ssl\man\man1\asn1parse.1
     >> usr\ssl\man\man1\ca.1
     >> usr\ssl\man\man1\CA.pl.1
     >> usr\ssl\man\man1\ciphers.1
     >> usr\ssl\man\man1\crl.1
     >> usr\ssl\man\man1\crl2pkcs7.1
     >> usr\ssl\man\man1\dgst.1
     >> usr\ssl\man\man1\dhparam.1
     >> usr\ssl\man\man1\dsa.1
     >> usr\ssl\man\man1\dsaparam.1
     >> usr\ssl\man\man1\enc.1
     >> usr\ssl\man\man1\errstr.1
     >> usr\ssl\man\man1\gendsa.1
     >> usr\ssl\man\man1\genrsa.1
     >> usr\ssl\man\man1\md2.1
     >> usr\ssl\man\man1\md4.1
     >> usr\ssl\man\man1\md5.1
     >> usr\ssl\man\man1\mdc2.1
     >> usr\ssl\man\man1\nseq.1
     >> usr\ssl\man\man1\ocsp.1
     >> usr\ssl\man\man1\openssl.1
     >> usr\ssl\man\man1\passwd.1
     >> usr\ssl\man\man1\pkcs12.1
     >> usr\ssl\man\man1\pkcs7.1
     >> usr\ssl\man\man1\pkcs8.1
     >> usr\ssl\man\man1\rand.1
     >> usr\ssl\man\man1\req.1
     >> usr\ssl\man\man1\ripemd160.1
     >> usr\ssl\man\man1\rsa.1
     >> usr\ssl\man\man1\rsautl.1
     >> usr\ssl\man\man1\s_client.1
     >> usr\ssl\man\man1\s_server.1
     >> usr\ssl\man\man1\s_time.1
     >> usr\ssl\man\man1\sess_id.1
     >> usr\ssl\man\man1\sha.1
     >> usr\ssl\man\man1\sha1.1
     >> usr\ssl\man\man1\smime.1
     >> usr\ssl\man\man1\speed.1
     >> usr\ssl\man\man1\spkac.1
     >> usr\ssl\man\man1\verify.1
     >> usr\ssl\man\man1\version.1
     >> usr\ssl\man\man1\x509.1
     >> usr\ssl\man\man5\config.5
     >> usr\ssl\man\man7\des_modes.7
     >> usr\ssl\man\man7\Modes_of_DES.7
     >> usr\ssl\misc\c_hash
     >> usr\ssl\misc\c_info
     >> usr\ssl\misc\c_issuer
     >> usr\ssl\misc\c_name
     >> usr\ssl\misc\CA.pl
     >> usr\ssl\misc\CA.sh
        usr\ssl\openssl.cnf

@! 3 files don't match
-------------------
     >> etc\setup\last-connection
     >> etc\setup\last-mirror
     >> var\run\utmp

@! 8 folders and files unique
--------------------------
     ?? bin\last.exe
     ?? bin\mkpasswd.c
     ?? bin\quietcmd.bat
     ?? bin\switch.c
     ?? bin\switch.exe
     ?? etc\banner.txt
     ?? usr\sbin\custom-sshd.bat
     !! usr\share\doc\SSHWindows 3.8.1p1\

-- 
 Best regards,
 Victor B. Gonzalez
                          
 OpenSSH-4.1p1-1
 Cygwin 2.457.2.2
 Windows XP  5.1 Build  2600 Service Pack 2
 end



From openssh-unix-dev-mindrot at vbgunz.com  Sun Jun 12 14:47:47 2005
From: openssh-unix-dev-mindrot at vbgunz.com (Victor B. Gonzalez)
Date: Sun, 12 Jun 2005 00:47:47 -0400
Subject: This is only a test...
Message-ID: <861866001.20050612004747@vbgunz.com>

--
Hello OpenSSH,

  Sorry, new to majordomo. I keep getting my messages rejected and
  then get a flood of error messages. I am just testing to see if this
  goes through successfully.

  Thank you for understanding.

-- 
 Best regards,
 Victor B. Gonzalez
                          
 OpenSSH-4.1p1-1
 Cygwin 2.457.2.2
 Windows XP  5.1 Build  2600 Service Pack 2



From openssh-unix-dev-mindrot at vbgunz.com  Sun Jun 12 15:29:23 2005
From: openssh-unix-dev-mindrot at vbgunz.com (Victor B. Gonzalez)
Date: Sun, 12 Jun 2005 01:29:23 -0400
Subject: Building Stand-Alone NT Installer. Need Advice on File Structure.
	Thank you!
Message-ID: <1436703537.20050612012923@vbgunz.com>

--
Hello Everyone,

 I am trying to build a stand-alone installation application of
 OpenSSH 4.1p1-1. The target of this project is the NT platform
 (NT/00/XP/03). I've met with success and am happy so far with the
 progress. I cross-checked all executables and DLL's for dependencies.
 All executables and DLL's should truly stand-alone (dependent on
 nothing outside the enclosed tree). Once this project is finished I
 plan on submitting a link to the final version here for peer review.
 I am using the following software on XP to help with the project.

>  OpenSSH-4.1p1-1
>  Cygwin 2.457.2.2
>  SSHWindows 3.8.1p1
>  Windows XP  5.1 Build  2600 Service Pack 2
 
This message is aimed at one purpose. To seek advice on the correct
file structure for OpenSSH. To get to the point is simple. It seems
Cygwin 2.457.2.2 bombed the OpenSSH build with a whole bunch of
erroneous files (I may be wrong). I wish to ask the community to take
a look at the following enclosed tree and correct any possible flaws,
mistakes and point out any unnecessary files & folders. Also, I've
diffed against SSHWindows 3.8.1p1 so to include applications such as
"mkdir.exe", "mkgroup.exe" & "mkpasswd.exe".

PLEASE NOTE: Unnecessary files and folders should be ERASED!

PLEASE NOTE: To make sense and to help the community please replace >>
OR ?? with !! IF the file or folder should be deleted. Please replace
>> OR ?? with << IF it should be kept. All files NOT marked should be
left alone IF they're to be included into the final build. Ahead of
time, I would like to thank you and the community for your time. Thank
you again!

==========================================================================================
     LEGEND:
     >> These files are in question. Are these files necessary in any way on NT?
     ?? These files are found in SSHWindows 3.8.1p1 BUT are NOT found in Cygwin 2.457.2.2
==========================================================================================
     >> bin\c_rehash
     ?? bin\chmod.exe
     ?? bin\chown.exe
        bin\crypt.exe
        bin\cygcrypt-0.dll
        bin\cygcrypto-0.9.7.dll
        bin\cygiconv-2.dll
        bin\cygintl-2.dll
        bin\cygintl-3.dll
        bin\cygminires.dll
        bin\cygrunsrv.exe
        bin\cygssl-0.9.7.dll
        bin\cygwin1.dll
        bin\cygz.dll
     ?? bin\false.exe
     ?? bin\last.exe
     ?? bin\ls.exe
     ?? bin\mkdir.exe
     ?? bin\mkgroup.exe
     ?? bin\mkpasswd.c
     ?? bin\mkpasswd.exe
        bin\openssl.exe
     >> bin\openssl_fips_fingerprint
     ?? bin\rm.exe
        bin\scp.exe
        bin\sftp.exe
     ?? bin\sh.exe
     >> bin\slogin
        bin\ssh.exe
        bin\ssh-add.exe
        bin\ssh-agent.exe
     >> bin\ssh-host-config
        bin\ssh-keygen.exe
        bin\ssh-keyscan.exe
     >> bin\ssh-user-config
     ?? bin\switch.c
     ?? bin\switch.exe
     ?? etc\banner.txt
     >> etc\profile.d\openssl.csh
     >> etc\profile.d\openssl.sh
     >> etc\setup\crypt.lst.gz
     >> etc\setup\cygrunsrv.lst.gz
     >> etc\setup\installed.db
     >> etc\setup\last-action
     >> etc\setup\last-cache
     >> etc\setup\last-connection
     >> etc\setup\last-mirror
     >> etc\setup\minires.lst.gz
     >> etc\setup\openssh.lst.gz
     >> etc\setup\openssl.lst.gz
     >> etc\setup\timestamp
        etc\ssh_config
        etc\ssh_host_dsa_key
        etc\ssh_host_dsa_key.pub
        etc\ssh_host_key
        etc\ssh_host_key.pub
        etc\ssh_host_rsa_key
        etc\ssh_host_rsa_key.pub
        etc\sshd_config
        etc\moduli
     >> lib\libcrypt.a
     >> lib\libcrypt.dll.a
     >> usr\include\crypt.h
        usr\sbin\sftp-server.exe
        usr\sbin\sshd.exe
        usr\sbin\ssh-keysign.exe
        usr\share\doc\Cygwin\crypt.README
        usr\share\doc\Cygwin\cygrunsrv.README
        usr\share\doc\Cygwin\minires-1.00-1.README
        usr\share\doc\Cygwin\openssh.README
        usr\share\doc\Cygwin\openssl-0.9.7g.README
        usr\share\doc\minires-1.00\LICENSE
        usr\share\doc\openssh\ChangeLog
        usr\share\doc\openssh\CREDITS
        usr\share\doc\openssh\LICENCE
        usr\share\doc\openssh\OVERVIEW
        usr\share\doc\openssh\README
        usr\share\doc\openssh\README.dns
        usr\share\doc\openssh\README.privsep
        usr\share\doc\openssh\README.smartcard
        usr\share\doc\openssh\RFC.nroff
        usr\share\doc\openssh\TODO
        usr\share\doc\openssh\WARNING.RNG
        usr\share\doc\openssl\CHANGES
        usr\share\doc\openssl\CHANGES.SSLeay
        usr\share\doc\openssl\INSTALL
        usr\share\doc\openssl\LICENSE
        usr\share\doc\openssl\NEWS
        usr\share\doc\openssl\README
     >> usr\share\man\man1\scp.1
     >> usr\share\man\man1\sftp.1
     >> usr\share\man\man1\slogin.1
     >> usr\share\man\man1\ssh.1
     >> usr\share\man\man1\ssh-add.1
     >> usr\share\man\man1\ssh-agent.1
     >> usr\share\man\man1\ssh-keygen.1
     >> usr\share\man\man1\ssh-keyscan.1
     >> usr\share\man\man5\ssh_config.5
     >> usr\share\man\man5\sshd_config.5
     >> usr\share\man\man8\sftp-server.8
     >> usr\share\man\man8\sshd.8
     >> usr\share\man\man8\ssh-keysign.8
     >> usr\share\terminfo\c\cygwin
        usr\share\Ssh.bin
     >> usr\ssl\man\man1\asn1parse.1
     >> usr\ssl\man\man1\ca.1
     >> usr\ssl\man\man1\CA.pl.1
     >> usr\ssl\man\man1\ciphers.1
     >> usr\ssl\man\man1\crl.1
     >> usr\ssl\man\man1\crl2pkcs7.1
     >> usr\ssl\man\man1\dgst.1
     >> usr\ssl\man\man1\dhparam.1
     >> usr\ssl\man\man1\dsa.1
     >> usr\ssl\man\man1\dsaparam.1
     >> usr\ssl\man\man1\enc.1
     >> usr\ssl\man\man1\errstr.1
     >> usr\ssl\man\man1\gendsa.1
     >> usr\ssl\man\man1\genrsa.1
     >> usr\ssl\man\man1\md2.1
     >> usr\ssl\man\man1\md4.1
     >> usr\ssl\man\man1\md5.1
     >> usr\ssl\man\man1\mdc2.1
     >> usr\ssl\man\man1\nseq.1
     >> usr\ssl\man\man1\ocsp.1
     >> usr\ssl\man\man1\openssl.1
     >> usr\ssl\man\man1\passwd.1
     >> usr\ssl\man\man1\pkcs12.1
     >> usr\ssl\man\man1\pkcs7.1
     >> usr\ssl\man\man1\pkcs8.1
     >> usr\ssl\man\man1\rand.1
     >> usr\ssl\man\man1\req.1
     >> usr\ssl\man\man1\ripemd160.1
     >> usr\ssl\man\man1\rsa.1
     >> usr\ssl\man\man1\rsautl.1
     >> usr\ssl\man\man1\s_client.1
     >> usr\ssl\man\man1\s_server.1
     >> usr\ssl\man\man1\s_time.1
     >> usr\ssl\man\man1\sess_id.1
     >> usr\ssl\man\man1\sha.1
     >> usr\ssl\man\man1\sha1.1
     >> usr\ssl\man\man1\smime.1
     >> usr\ssl\man\man1\speed.1
     >> usr\ssl\man\man1\spkac.1
     >> usr\ssl\man\man1\verify.1
     >> usr\ssl\man\man1\version.1
     >> usr\ssl\man\man1\x509.1
     >> usr\ssl\man\man5\config.5
     >> usr\ssl\man\man7\des_modes.7
     >> usr\ssl\man\man7\Modes_of_DES.7
     >> usr\ssl\misc\c_hash
     >> usr\ssl\misc\c_info
     >> usr\ssl\misc\c_issuer
     >> usr\ssl\misc\c_name
     >> usr\ssl\misc\CA.pl
     >> usr\ssl\misc\CA.sh
        usr\ssl\openssl.cnf
     >> var\run\utmp
==========================================================================================
-- 
 Best regards,
 Victor B. Gonzalez
                          
 OpenSSH-4.1p1-1
 Cygwin 2.457.2.2
 Windows XP  5.1 Build  2600 Service Pack 2



From dwmw2 at infradead.org  Sun Jun 12 18:59:22 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Jun 2005 09:59:22 +0100
Subject: %h,%p,%u expansion for ControlPath
Message-ID: <1118566763.4823.97.camel@localhost.localdomain>

This allows me to set 'ControlPath ~/.ssh/sockets/%h.%p.%u' for example.

Have I missed a good reason why ssh_connect finds the default port
number for itself instead of just having it in options.port (like we do
for the the default in options.user)?

--- openssh-4.1p1/ssh.c~	2005-06-12 09:47:18.000000000 +0100
+++ openssh-4.1p1/ssh.c	2005-06-12 09:40:53.000000000 +0100
@@ -604,6 +604,17 @@ again:
 				*p = tolower(*p);
 	}
 
+	/* Get default port if port has not been set. */
+	if (options.port == 0) {
+		struct servent *sp;
+
+		sp = getservbyname(SSH_SERVICE_NAME, "tcp");
+		if (sp)
+			options.port = ntohs(sp->s_port);
+		else
+			options.port = SSH_DEFAULT_PORT;
+	}
+
 	if (options.proxy_command != NULL &&
 	    strcmp(options.proxy_command, "none") == 0)
 		options.proxy_command = NULL;
@@ -611,6 +622,42 @@ again:
 	if (options.control_path != NULL) {
 		options.control_path = tilde_expand_filename(
 		   options.control_path, original_real_uid);
+
+		if (strchr(options.control_path, '%')) {
+			Buffer path;
+			const char *cp;
+			char strport[NI_MAXSERV];
+
+			/* Convert the port number into a string. */
+			snprintf(strport, sizeof strport, "%hu", options.port);	
+
+			buffer_init(&path);
+			for (cp = options.control_path; *cp; cp++) {
+				if (cp[0] == '%' && cp[1] == '%') {
+					buffer_append(&path, "%", 1);
+					cp++;
+					continue;
+				}
+				if (cp[0] == '%' && cp[1] == 'h') {
+					buffer_append(&path, host, strlen(host));
+					cp++;
+					continue;
+				}
+				if (cp[0] == '%' && cp[1] == 'p') {
+					buffer_append(&path, strport, strlen(strport));
+					cp++;
+					continue;
+				}
+				if (cp[0] == '%' && cp[1] == 'u') {
+					buffer_append(&path, options.user, strlen(options.user));
+					cp++;
+					continue;
+				}
+				buffer_append(&path, cp, 1);
+			}
+			buffer_append(&path, "\0", 1);
+			options.control_path = xstrdup(buffer_ptr(&path));
+		}
 	}
 	if (options.control_path != NULL && options.control_master == 0)
 		control_client(options.control_path); /* This doesn't return */
--- openssh-4.1p1/sshconnect.c~	2005-03-14 12:08:12.000000000 +0000
+++ openssh-4.1p1/sshconnect.c	2005-06-12 09:36:33.000000000 +0100
@@ -308,18 +308,9 @@ ssh_connect(const char *host, struct soc
 	int sock = -1, attempt;
 	char ntop[NI_MAXHOST], strport[NI_MAXSERV];
 	struct addrinfo hints, *ai, *aitop;
-	struct servent *sp;
 
 	debug2("ssh_connect: needpriv %d", needpriv);
 
-	/* Get default port if port has not been set. */
-	if (port == 0) {
-		sp = getservbyname(SSH_SERVICE_NAME, "tcp");
-		if (sp)
-			port = ntohs(sp->s_port);
-		else
-			port = SSH_DEFAULT_PORT;
-	}
 	/* If a proxy command is given, connect using it. */
 	if (proxy_command != NULL)
 		return ssh_proxy_connect(host, port, proxy_command);

-- 
dwmw2



From dwmw2 at infradead.org  Sun Jun 12 19:18:39 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Jun 2005 10:18:39 +0100
Subject: This is only a test...
In-Reply-To: <861866001.20050612004747@vbgunz.com>
References: <861866001.20050612004747@vbgunz.com>
Message-ID: <1118567920.4823.105.camel@localhost.localdomain>

On Sun, 2005-06-12 at 00:47 -0400, Victor B. Gonzalez wrote:
>   Sorry, new to majordomo. I keep getting my messages rejected and
>   then get a flood of error messages. I am just testing to see if this
>   goes through successfully.

What you see is probably just one of the misguided challenge-response
systems which are actually contributing to the spam problem rather than
helping to improve matters. These systems will generally spam an
innocent third party with 'challenges' in response to messages which
they did not send.

If you ever receive such a challenge in response to a message you did
not send, I recommend that you report it as mail abuse to the upstream
network provider of the sending host. Challenge-response isn't part of
the answer; it's part of the problem.

-- 
dwmw2



From dwmw2 at infradead.org  Sun Jun 12 23:18:11 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Jun 2005 14:18:11 +0100
Subject: 'ControlMaster auto'
In-Reply-To: <1118566763.4823.97.camel@localhost.localdomain>
References: <1118566763.4823.97.camel@localhost.localdomain>
Message-ID: <1118582292.4823.118.camel@localhost.localdomain>

On Sun, 2005-06-12 at 09:59 +0100, David Woodhouse wrote:
> This allows me to set 'ControlPath ~/.ssh/sockets/%h.%p.%u' for example.

... and this one complements it by adding 'ControlMaster auto'. I should
probably use #defines for the ControlMaster settings now that they're
more complicated than just 0, 1 or 2, -- but I'll do that in the next
patch, which will add 'persist' and 'autopersist' to the available
options.

--- openssh-4.1p1/readconf.c	2005-03-14 12:08:12.000000000 +0000
+++ openssh-4.1p1-auto/readconf.c	2005-06-12 11:18:05.000000000 +0100
@@ -793,7 +793,26 @@ parse_int:
 
 	case oControlMaster:
 		intptr = &options->control_master;
-		goto parse_yesnoask;
+		arg = strdelim(&s);
+		if (!arg || *arg == '\0')
+			fatal("%.200s line %d: Missing ControlMaster argument.",
+			    filename, linenum);
+		value = 0;	/* To avoid compiler warning... */
+		if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0)
+			value = 1;
+		else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0)
+			value = 0;
+		else if (strcmp(arg, "ask") == 0)
+			value = 2;
+		else if (strcmp(arg, "auto") == 0)
+			value = 3;
+		else if (strcmp(arg, "autoask") == 0)
+			value = 4;
+		else
+			fatal("%.200s line %d: Bad ControlMaster argument.", filename, linenum);
+		if (*activep && *intptr == -1)
+			*intptr = value;
+		break;
 
 	case oHashKnownHosts:
 		intptr = &options->hash_known_hosts;
--- openssh-4.1p1/ssh.c	2005-06-12 13:56:53.000000000 +0100
+++ openssh-4.1p1-auto/ssh.c	2005-06-12 13:55:32.000000000 +0100
@@ -659,8 +659,13 @@ again:
 			options.control_path = xstrdup(buffer_ptr(&path));
 		}
 	}
-	if (options.control_path != NULL && options.control_master == 0)
-		control_client(options.control_path); /* This doesn't return */
+	if (options.control_path != NULL && 
+	    (options.control_master == 0 || options.control_master == 3 ||
+	     options.control_master == 4)) {
+		/* This only returns in the 'ask' cases, if we should
+		   become a master */
+		control_client(options.control_path);
+	}
 
 	/* Open a connection to the remote host. */
 	if (ssh_connect(host, &hostaddr, options.port,
@@ -1337,15 +1342,6 @@ control_client(const char *path)
 	extern char **environ;
 	u_int  flags;
 
-	if (stdin_null_flag) {
-		if ((fd = open(_PATH_DEVNULL, O_RDONLY)) == -1)
-			fatal("open(/dev/null): %s", strerror(errno));
-		if (dup2(fd, STDIN_FILENO) == -1)
-			fatal("dup2: %s", strerror(errno));
-		if (fd > STDERR_FILENO)
-			close(fd);
-	}
-
 	memset(&addr, '\0', sizeof(addr));
 	addr.sun_family = AF_UNIX;
 	addr_len = offsetof(struct sockaddr_un, sun_path) +
@@ -1358,8 +1354,25 @@ control_client(const char *path)
 	if ((sock = socket(PF_UNIX, SOCK_STREAM, 0)) < 0)
 		fatal("%s socket(): %s", __func__, strerror(errno));
 
-	if (connect(sock, (struct sockaddr*)&addr, addr_len) == -1)
+	if (connect(sock, (struct sockaddr*)&addr, addr_len) == -1) {
+		if (options.control_master >= 2) {
+			debug("Couldn't connect to %s: %s", path, strerror(errno));
+			/* Automatic mode; return and become a master */
+			options.control_master -= 2;
+			close(sock);
+			return;
+		}
 		fatal("Couldn't connect to %s: %s", path, strerror(errno));
+	}
+
+	if (stdin_null_flag) {
+		if ((fd = open(_PATH_DEVNULL, O_RDONLY)) == -1)
+			fatal("open(/dev/null): %s", strerror(errno));
+		if (dup2(fd, STDIN_FILENO) == -1)
+			fatal("dup2: %s", strerror(errno));
+		if (fd > STDERR_FILENO)
+			close(fd);
+	}
 
 	if ((term = getenv("TERM")) == NULL)
 		term = "";

-- 
dwmw2



From dwmw2 at infradead.org  Mon Jun 13 00:16:47 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Jun 2005 15:16:47 +0100
Subject: 'ControlMaster persist'
In-Reply-To: <1118582292.4823.118.camel@localhost.localdomain>
References: <1118566763.4823.97.camel@localhost.localdomain>
	<1118582292.4823.118.camel@localhost.localdomain>
Message-ID: <1118585808.4823.125.camel@localhost.localdomain>

On Sun, 2005-06-12 at 14:18 +0100, David Woodhouse wrote:
> I'll do that in the next patch, which will add 'persist' and
> 'autopersist' to the available options.

... which start a master and leave it running even after the ssh command
which triggers its creation has gone. Looks like the simplest way to
achieve this is to fork a new ssh client process to become the master,
then wait for it to complete and use it in slave mode.

Should I make 'ask' and 'auto' into separate flags rather than
variations of the 'ControlMaster' option?

--- openssh-4.1p1/readconf.c~	2005-06-12 11:18:05.000000000 +0100
+++ openssh-4.1p1/readconf.c	2005-06-12 14:34:26.000000000 +0100
@@ -799,15 +799,19 @@
 			    filename, linenum);
 		value = 0;	/* To avoid compiler warning... */
 		if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0)
-			value = 1;
+			value = CONTROL_MASTER;
 		else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0)
-			value = 0;
+			value = CONTROL_SLAVE;
 		else if (strcmp(arg, "ask") == 0)
-			value = 2;
+			value = CONTROL_ASK;
+		else if (strcmp(arg, "persist") == 0)
+			value = CONTROL_PERSIST;
 		else if (strcmp(arg, "auto") == 0)
-			value = 3;
+			value = CONTROL_AUTO;
 		else if (strcmp(arg, "autoask") == 0)
-			value = 4;
+			value = CONTROL_AUTOASK;
+		else if (strcmp(arg, "autopersist") == 0)
+			value = CONTROL_AUTOPERSIST;
 		else
 			fatal("%.200s line %d: Bad ControlMaster argument.", filename, linenum);
 		if (*activep && *intptr == -1)
--- openssh-4.1p1/readconf.h~	2005-03-01 10:47:37.000000000 +0000
+++ openssh-4.1p1/readconf.h	2005-06-12 14:34:15.000000000 +0100
@@ -116,6 +116,13 @@
 	int	hash_known_hosts;
 }       Options;
 
+#define CONTROL_SLAVE		0
+#define CONTROL_MASTER		1
+#define CONTROL_ASK		2
+#define CONTROL_PERSIST		3
+#define CONTROL_AUTO		4
+#define CONTROL_AUTOASK		5
+#define CONTROL_AUTOPERSIST	6
 
 void     initialize_options(Options *);
 void     fill_default_options(Options *);
--- openssh-4.1p1/ssh.c~	2005-06-12 13:55:32.000000000 +0100
+++ openssh-4.1p1/ssh.c	2005-06-12 15:02:09.000000000 +0100
@@ -659,12 +659,52 @@
 			options.control_path = xstrdup(buffer_ptr(&path));
 		}
 	}
+ startpersist:
+	if (options.control_master == CONTROL_PERSIST) {
+		pid_t masterpid = fork();
+
+		if (masterpid < 0)
+			fatal("fork: %s", strerror(errno));
+
+		if (masterpid) {
+			/* We are the parent. Wait for the child to
+			   set itself up as master, then use its
+			   control socket */
+			int status;
+			if (waitpid(masterpid, &status, 0) < 0)
+				fatal("waitpid: %s", strerror(errno));
+
+			if (WIFEXITED(status)) {
+				if (WEXITSTATUS(status))
+					fatal("Master connection failed, returned %d", WEXITSTATUS(status));
+			} else if (WIFSIGNALED(status)) {
+				fatal("Master connection failed, died with signal %d", WTERMSIG(status));
+			} else {
+				fatal("Master connection failed. status %d\n", status);
+			}
+			/* The master exited with zero status, so the socket
+			   should be ready for us now */
+			options.control_master = CONTROL_SLAVE;
+		} else {
+			/* We are the child. Set ourselves up as master */
+			no_shell_flag = 1;
+			no_tty_flag = 1;
+			tty_flag = 0;
+			fork_after_authentication_flag = 1;
+			stdin_null_flag = 1;
+			options.control_master = CONTROL_MASTER;
+		}
+	}
+
 	if (options.control_path != NULL && 
-	    (options.control_master == 0 || options.control_master == 3 ||
-	     options.control_master == 4)) {
+	    (options.control_master == CONTROL_SLAVE || 
+	     options.control_master >= CONTROL_AUTO)) {
 		/* This only returns in the 'ask' cases, if we should
 		   become a master */
 		control_client(options.control_path);
+
+		if (options.control_master == CONTROL_PERSIST)
+			goto startpersist;
 	}
 
 	/* Open a connection to the remote host. */
@@ -1355,10 +1395,10 @@
 		fatal("%s socket(): %s", __func__, strerror(errno));
 
 	if (connect(sock, (struct sockaddr*)&addr, addr_len) == -1) {
-		if (options.control_master >= 2) {
+		if (options.control_master >= CONTROL_AUTO) {
 			debug("Couldn't connect to %s: %s", path, strerror(errno));
 			/* Automatic mode; return and become a master */
-			options.control_master -= 2;
+			options.control_master -= CONTROL_AUTO-1;
 			close(sock);
 			return;
 		}


-- 
dwmw2



From dwmw2 at infradead.org  Mon Jun 13 00:20:58 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Jun 2005 15:20:58 +0100
Subject: 'ControlPath none'
In-Reply-To: <1118585808.4823.125.camel@localhost.localdomain>
References: <1118566763.4823.97.camel@localhost.localdomain>
	<1118582292.4823.118.camel@localhost.localdomain>
	<1118585808.4823.125.camel@localhost.localdomain>
Message-ID: <1118586059.4823.129.camel@localhost.localdomain>

With the last three patches I can now do something like this...

 Host *
    ControlPath ~/.ssh/sockets/%h-%p-%u
    ControlMaster autopersist

If I want to be able to turn that _off_ for specific hosts, I'll want
this patch so that I can override the ControlPath setting....

--- openssh-4.1p1/ssh.c~	2005-06-12 13:55:32.000000000 +0100
+++ openssh-4.1p1/ssh.c	2005-06-12 15:14:43.000000000 +0100
@@ -619,6 +619,10 @@ again:
 	    strcmp(options.proxy_command, "none") == 0)
 		options.proxy_command = NULL;
 
+	if (options.control_path != NULL &&
+	    strcmp(options.control_path, "none") == 0)
+		options.control_path = NULL;
+
 	if (options.control_path != NULL) {
 		options.control_path = tilde_expand_filename(
 		   options.control_path, original_real_uid);

-- 
dwmw2



From vinschen at redhat.com  Sun Jun 12 18:40:51 2005
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sun, 12 Jun 2005 10:40:51 +0200
Subject: Building Stand-Alone NT Installer. Need Advice on File
	Structure. Thank you!
In-Reply-To: <1436703537.20050612012923@vbgunz.com>
References: <1436703537.20050612012923@vbgunz.com>
Message-ID: <20050612084051.GA6909@calimero.vinschen.de>

On Jun 12 01:29, Victor B. Gonzalez wrote:
> >  OpenSSH-4.1p1-1
> >  Cygwin 2.457.2.2

There's no such thing as a Cygwin version 2.457.2.2.

There's no gain for the community in packaging up a package which contains
a binary Cygwin DLL.  The only result is that somebody, who has already a
Cygwin installation will get another DLL with likely another version in
$PATH which results in serious trouble.  So this isn't something we want
to see and support.

Even then, I hope you're also packaging up all the source code at the
same spot you're providing binaries, otherwise you'll at least infringing
the Cygwin license.

This is very off-topic for this list, AFAICS, especially when sent three times.


Corinna

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



From openssh-unix-dev-mindrot at vbgunz.com  Mon Jun 13 09:18:11 2005
From: openssh-unix-dev-mindrot at vbgunz.com (Victor B. Gonzalez)
Date: Sun, 12 Jun 2005 19:18:11 -0400
Subject: I have a quick question regarding this list.
Message-ID: <791956922.20050612191811@vbgunz.com>

--
Hello OpenSSH,

  How do I know if my message has been posted correctly if at all?
  Unlike other list, I do not get my original message. Is there anyway
  to check and see if my message was posted correctly (outside of
  creating another account)?.

  Thanks!  

-- 
 Best regards,
 Victor B. Gonzalez
                          
 OpenSSH-4.1p1-1
 Cygwin 2.457.2.2
 Windows XP  5.1 Build  2600 Service Pack 2



From bob at proulx.com  Mon Jun 13 11:19:24 2005
From: bob at proulx.com (Bob Proulx)
Date: Sun, 12 Jun 2005 19:19:24 -0600
Subject: I have a quick question regarding this list.
In-Reply-To: <791956922.20050612191811@vbgunz.com>
References: <791956922.20050612191811@vbgunz.com>
Message-ID: <20050613011924.GA26008@dementia.proulx.com>

Victor B. Gonzalez wrote:
>   How do I know if my message has been posted correctly if at all?

You will see your message mailed to you from the list.  Or you can
look in the mailing list archives.

  http://www.mindrot.org/pipermail/openssh-unix-dev/2005-June/thread.html

Your message is here:

  http://www.mindrot.org/pipermail/openssh-unix-dev/2005-June/023345.html

>   Unlike other list, I do not get my original message. Is there anyway
>   to check and see if my message was posted correctly (outside of
>   creating another account)?.

The normal configuration for the list is to send you your own
messages.  If you are not getting any list messages then this is a
problem to be worked out between your end and the mailing list end.
As you can see in the archive there have been several recent postings
from different people.  If you are not getting any of them then you
have a problem receiving mail and not just your own messages.

If you are getting other postings but not getting your own messages
then this is a personal configuraiton for your mail address with
mailman.  Log into the site and adjust your settings.  Or you can
unsubscribe and subscribe again later to reset to default settings.

  http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

At the bottom is a form to log into the site to change your personal
mailing list options.  Log in then look for this question:

    Receive your own posts to the list?

    Ordinarily, you will get a copy of every message you post to the
    list. If you don't want to receive this copy, set this option to No.

Set that to Yes.

Bob



From openssh at roumenpetrov.info  Mon Jun 13 16:22:21 2005
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Mon, 13 Jun 2005 09:22:21 +0300
Subject: Announce: X.509 certificates support in OpenSSH (version 5.2 from
 "Validator" series)
Message-ID: <42AD261D.70902@roumenpetrov.info>

Hi All,

The version 5.2 of "X.509 certificates support in OpenSSH" is ready for download.
Available diffs are for OpenSSH versions 3.9p1, 4.0p1 and 4.1p1.

What's new:
* print CERT RR (resource record)
* verify remote key using DNS and CERT RR
* include not-pipeline patch
* work with OpenSSL 0.9.8betaX

Please visit "http://roumenpetrov.info/openssh/" for more information.


Regards,
Roumen Petrov


P.S.: Note on system with "/dev/{u||s}random" OpenSSH will report "checking whether OpenSSL's PRNG is internally seeded... no" for OpenSSL versions 0.9.8-beta{3|4|5}.
Work around is to remove quotes around DEVRANDOM in OpenSSL file "crypto/rand/rand_unix.c" or to install ssh-rand-helper.



From openssh-unix-dev-mindrot at vbgunz.com  Mon Jun 13 16:51:12 2005
From: openssh-unix-dev-mindrot at vbgunz.com (Victor B. Gonzalez)
Date: Mon, 13 Jun 2005 02:51:12 -0400
Subject: Building Stand-Alone NT Installer. Need Advice on
	FileStructure. Thank you!
References: 1436703537.20050612012923@vbgunz.com
Message-ID: <1491140517.20050613025112@vbgunz.com>

--
Hello Corinna,

>There's no such thing as a Cygwin version 2.457.2.2.
I apologize. I was referring to the version of setup. I've built with
the DLL version 1.5.17-1 and made a final stand alone build on June,
06, 2005.

>There's no gain for the community in packaging up a package which contains
>a binary Cygwin DLL.  The only result is that somebody, who has already a
>Cygwin installation will get another DLL with likely another version in
>$PATH which results in serious trouble.  So this isn't something we want
>to see and support.

Sounds interesting. Would it be of interest to you if I put in logic
that will refuse to install itself IF any of the following returns
true?

> Registry entries for "Cygnus Solutions"
> Environment variable of "CYGWIN"

I will do this so no trouble can surface. The installer can read the
registry and environment so to take the proper action. If incase
you're curious about someone wishing to install Cygwin AFTER they
installed OpenSSH standalone, well I can perform that check on every
system startup. IF an installation of Cygwin is found I can disable
the stand alone version completely from paths and registry. Or
whatever you might wish to recommend.

>Even then, I hope you're also packaging up all the source code at the
>same spot you're providing binaries, otherwise you'll at least infringing
>the Cygwin license.

In a sense, I was hoping users would advise on which files are safe to
remove and which one's aren't. For example are all man files required
on NT? Should I include all .README's from Cygwin OR just the main
README's which pertain to the actual used applications? IF I must
include the source rather than linking to it I might need some help.
BUT I am willing to do anything to comply with any and all legalities.

I am only really hoping to lay-down the groundwork with notes of my
progress about building a standalone installation. I would really
appreciate if someone much smarter than I in regards to Cygwin and
OpenSSH actually take it further and make it more solid and secure. I
don't proclaim to be a professional BUT I do proclaim that I am
willing to at least try and get OpenSSH to stand as alone as possible.

While at the same time doing anything to comply...

>This is very off-topic for this list, AFAICS, especially when sent
>three times.

I apologize for this inconvenience and feel bad about it. Thanks to
"Bob Proulx" from the list I've discovered I've got a serious problem.
It seems the either the list, my mail server or my client is not in
agreement at some point. My first two messages returned errors stating
it was never posted "bad command" and my last message "the one you
replied to" never sent me the actual reply. I had to find it on the
following webpage
http://www.mindrot.org/pipermail/openssh-unix-dev/2005-June/thread.html
thanks again to "Bob Proulx".

If this list isn't made for discussions about furthering OpenSSH into
projects like "standalone installations" then where do I find such a
list? Also, what is this list for if not for development?

-- 
 Best regards,
 Victor B. Gonzalez
                          
 OpenSSH-4.1p1-1
 Cygwin DLL 1.5.17-1
 Windows XP  5.1 Build  2600 Service Pack 2



From djm at mindrot.org  Mon Jun 13 19:01:18 2005
From: djm at mindrot.org (Damien Miller)
Date: Mon, 13 Jun 2005 19:01:18 +1000
Subject: %h,%p,%u expansion for ControlPath
In-Reply-To: <1118566763.4823.97.camel@localhost.localdomain>
References: <1118566763.4823.97.camel@localhost.localdomain>
Message-ID: <42AD4B5E.9020300@mindrot.org>

David Woodhouse wrote:
> This allows me to set 'ControlPath ~/.ssh/sockets/%h.%p.%u' for example.

this is already in -current.

-d



From dwmw2 at infradead.org  Mon Jun 13 19:15:09 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 13 Jun 2005 10:15:09 +0100
Subject: %h,%p,%u expansion for ControlPath
In-Reply-To: <42AD4B5E.9020300@mindrot.org>
References: <1118566763.4823.97.camel@localhost.localdomain>
	<42AD4B5E.9020300@mindrot.org>
Message-ID: <1118654110.2840.8.camel@localhost.localdomain>

On Mon, 2005-06-13 at 19:01 +1000, Damien Miller wrote:
> David Woodhouse wrote:
> > This allows me to set 'ControlPath ~/.ssh/sockets/%h.%p.%u' for example.
> 
> this is already in -current.

But not yet the portable version?

-- 
dwmw2



From dwmw2 at infradead.org  Mon Jun 13 19:32:20 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 13 Jun 2005 10:32:20 +0100
Subject: %h,%p,%u expansion for ControlPath
In-Reply-To: <42AD4B5E.9020300@mindrot.org>
References: <1118566763.4823.97.camel@localhost.localdomain>
	<42AD4B5E.9020300@mindrot.org>
Message-ID: <1118655140.2840.19.camel@localhost.localdomain>

On Mon, 2005-06-13 at 19:01 +1000, Damien Miller wrote:
> this is already in -current.

OK, I've checked out the OpenBSD version and I see it now. In that
version it looks like '%p' is going to expand to '0' when the default
port is used, instead of to '22' as it should.

Do you want me to try to redo the 'persist' patch against that code? I
can't (easily) test it until it's in the portable version.

Btw, I got another of your misguided TMDA challenges today, because I
use a new reverse-path each day. If you must persist with this, please
could you whitelist *.srs.infradead.org? Since all messages from those
domains are timestamped and hash-signed?, SMTP callouts are perfectly
sufficient to confirm the authenticity of a mail -- you don't have to
actually send the challenge and wait for a reply. TMDA is just making
the spam problem worse by sending _more_ junk mail to innocent third
parties.

-- 
dwmw2

? http://www.infradead.org/rpr.html



From jan.iven at cern.ch  Mon Jun 13 20:47:55 2005
From: jan.iven at cern.ch (Jan Iven)
Date: Mon, 13 Jun 2005 12:47:55 +0200
Subject: rekeying in SSH-2 and session setup?
Message-ID: <1118659675.3865.51.camel@laptop.mydomain>

Dear all,
while playing around with openssh-4.1p1 (trying to add AFS token
forwarding in SSH-2), I noticed that agressive rekeying (as e.g.
employed by regress/rekey.sh, rekeying every 16bytes) seems to disturb
the various forwardings (X11, agent) set up at the beginning of the
session. These do not trigger regression test errors, since the client
does not ask for confirmation from the server for these commands (except
for remote port forwarding, and that one isn't set up by default).

Setting the minimum rekey limit to a higher value that covers all of the
session setup would be easy, but at least the port forwarding can get
added also later during the session. I guess that a rekey event at this
stage would kill the connection (explicit 'packet_disconnect()' if we
receive neither SUCCESS nor FAILURE from the server).

Could somebody perhaps check whether I am completely off-track with
this? I'd also be grateful on advice how to handle or prevent rekeying
events during session setup, e.g. in ssh_session2_setup().

Thanks
Jan





From rschubnell at paninfo.com  Tue Jun 14 00:00:32 2005
From: rschubnell at paninfo.com (rschubnell at paninfo.com)
Date: Mon, 13 Jun 2005 16:00:32 +0200
Subject: Reto Schubnell/Paninfo AG ist abwesend.
Message-ID: <OF80981545.5891DF03-ONC125701F.004CF43F-C125701F.004CF43F@paninfo.com>

Ich werde ab  13.06.2005 nicht im B?ro sein. Ich kehre zur?ck am
17.06.2005.


Meine Stellvertretung ist durch Herrn Roger Zimmermann geregelt.
In Dringenden F?llen wenden Sie sich bitte an unsere Hotline

Hotline Paninfo: 01 / 805 14 99

Mails werden nicht weitergeleitet !


#####
Diese Email wurde durch verschiedene Security Mechanismen geprueft
und fuer sauber befunden.
Wenn Sie Interesse an diesen Security Checks haben,
nehmen Sie mit uns Kontakt auf. http://www.paninfo.com
#####



From dtucker at zip.com.au  Wed Jun 15 18:40:10 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 15 Jun 2005 18:40:10 +1000
Subject: 4.1p1 on AIX5200-05
In-Reply-To: <42A9436D.9040407@Uni-Bremen.de>
References: <42A9436D.9040407@Uni-Bremen.de>
Message-ID: <42AFE96A.1040108@zip.com.au>

G Lehnert wrote:
> sshd disconnects
> 
> openssh-4.1p1
> on IBM p690 AIX 5200-05
> 
> using:
>   openssl-0.9.7g
>   zlib-1.2.2

You built OpenSSL and zlib with the same 64bit flags?  If so did 
openssl's "make tests" past?

>   openssh-4.1p1
>   CC="gcc  -O0 -maix64" ./configure       #- 64-Bit !!!
> 
> Compiles ok. ssh works fine.

Any particular reason you're compiling it 64 bit?

Anyway, looks like sshd is dying at this point:

> debug2: User child is on pid 725152
> debug3: mm_request_receive entering
> debug1: do_cleanup

Does the error occur with "UsePrivilegeSeparation no" in sshd_config?

-- 
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  Thu Jun 16 01:53:11 2005
From: f_mohr at yahoo.de (Frank Mohr)
Date: Wed, 15 Jun 2005 17:53:11 +0200
Subject: sftp-logging patch and make tests problem
Message-ID: <42B04EE7.3070900@yahoo.de>

i tried the sftp-logging patch (v 1.3 from
http://sftplogging.sourceforge.net/download/v1.3/)
with OpenSSH 4.1p1 (and 4.0p1)

with the patch applied, all sftp tests
in "make tests" fail
(sfp exits with 255)
strace shows that there is a SIGCHLD immediately after
fork() in connect_to_server()
and sftp gets then killed by "SIGPIPE (Broken pipe)"

using the same sftp/sftp-server combination over sshd/network
shows no problems

has anyone else noticed this behavior?

Frank

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



From djm at mindrot.org  Thu Jun 16 13:29:31 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 16 Jun 2005 13:29:31 +1000
Subject: %h,%p,%u expansion for ControlPath
In-Reply-To: <1118655140.2840.19.camel@localhost.localdomain>
References: <1118566763.4823.97.camel@localhost.localdomain>	<42AD4B5E.9020300@mindrot.org>
	<1118655140.2840.19.camel@localhost.localdomain>
Message-ID: <42B0F21B.2090405@mindrot.org>

David Woodhouse wrote:
> On Mon, 2005-06-13 at 19:01 +1000, Damien Miller wrote:
> OK, I've checked out the OpenBSD version and I see it now. In that
> version it looks like '%p' is going to expand to '0' when the default
> port is used, instead of to '22' as it should.

Yes, I noticed that too - i'll fix it shortly.

> Do you want me to try to redo the 'persist' patch against that code? I
> can't (easily) test it until it's in the portable version.

Portable OpenSSH has been updated with the latest OpenBSD changes and
they should all be in tonight's snapshot (20050616).

I'm not sure about the persist option; it would be useful, but probably
confusing (especially amongst all the other ControlMaster options).
Maybe users should just do "ssh -nNf host" instead...

> Btw, I got another of your misguided TMDA challenges today, because I
> use a new reverse-path each day. If you must persist with this, please
> could you whitelist *.srs.infradead.org? Since all messages from those
> domains are timestamped and hash-signed?, SMTP callouts are perfectly
> sufficient to confirm the authenticity of a mail -- you don't have to
> actually send the challenge and wait for a reply. TMDA is just making
> the spam problem worse by sending _more_ junk mail to innocent third
> parties.

TMDA in this context is no worse than "approve" messages sent from a
listbot, but they are far easier for everyone involved. If you want to
avoid them altogther then you could just subscribe to the list
(challenges aren't sent to members).

Since this is somewhat offtopic, if you want to discuss the list
configuration further, please contact me directly.

-d



From djm at mindrot.org  Thu Jun 16 13:33:28 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 16 Jun 2005 13:33:28 +1000
Subject: rekeying in SSH-2 and session setup?
In-Reply-To: <1118659675.3865.51.camel@laptop.mydomain>
References: <1118659675.3865.51.camel@laptop.mydomain>
Message-ID: <42B0F308.6070809@mindrot.org>

Jan Iven wrote:
> Dear all,
> while playing around with openssh-4.1p1 (trying to add AFS token
> forwarding in SSH-2), I noticed that agressive rekeying (as e.g.
> employed by regress/rekey.sh, rekeying every 16bytes) seems to disturb
> the various forwardings (X11, agent) set up at the beginning of the
> session. These do not trigger regression test errors, since the client
> does not ask for confirmation from the server for these commands (except
> for remote port forwarding, and that one isn't set up by default).

Yes, we should probably set want_reply for forwarding setups and (at
least) warn when they are refused.

This would be a fairly easy project for someone who wants to start
hacking OpenSSH (hint, hint).

That rekeying causes problems is more concerning (I'll look at this),
but 16 bytes is an absurdly low limit - it isn't even enough to fit a
protocol v.2 packet.

-d



From daveroth at acm.org  Thu Jun 16 13:54:13 2005
From: daveroth at acm.org (David Rothenberger)
Date: Wed, 15 Jun 2005 20:54:13 -0700
Subject: SSH 2.4.0 remote forward patch in next release?
Message-ID: <42B0F7E5.6030607@acm.org>

I [1]reported a problem on 5-April-2005 about a problem with the 4.0p1 
version and remote port forwarding to SSH 2.4.0 servers. I provided a 
patch for the problem but [2]was told that no more patches were being 
considered until 4.1 was released and that I should attach my patch to a 
new Bugzilla bug. This [3]I did.

Is there any chance it will be included in the next release?

1. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111266548525108&w=2
2. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111287737706979&w=2
3. http://bugzilla.mindrot.org/show_bug.cgi?id=1012

-- 
David Rothenberger                spammer? -> spam at daveroth.dyndns.org
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734

Events are not affected, they develop.
		-- Sri Aurobindo



From djm at mindrot.org  Thu Jun 16 16:31:46 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 16 Jun 2005 16:31:46 +1000
Subject: SSH 2.4.0 remote forward patch in next release?
In-Reply-To: <42B0F7E5.6030607@acm.org>
References: <42B0F7E5.6030607@acm.org>
Message-ID: <42B11CD2.3060300@mindrot.org>

David Rothenberger wrote:
> I [1]reported a problem on 5-April-2005 about a problem with the 4.0p1 
> version and remote port forwarding to SSH 2.4.0 servers. I provided a 
> patch for the problem but [2]was told that no more patches were being 
> considered until 4.1 was released and that I should attach my patch to a 
> new Bugzilla bug. This [3]I did.
> 
> Is there any chance it will be included in the next release?
> 
> 1. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111266548525108&w=2
> 2. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111287737706979&w=2
> 3. http://bugzilla.mindrot.org/show_bug.cgi?id=1012

Probably, I intend to look at it soon (maybe this weekend).

Please stay tuned for messages from Bugzilla. If the patch needs
tweaking, then you (or someone else with ssh.com sshd) will need to
retest.

-d



From r.a.peters at student.tue.nl  Fri Jun 17 05:39:12 2005
From: r.a.peters at student.tue.nl (Richard Peters)
Date: Thu, 16 Jun 2005 21:39:12 +0200
Subject: Bug report: first_kex_packet_follows behaviour seems wrong
Message-ID: <059201c572ab$13aa2920$0a01a8c0@campus.tue.nl>

Hello,

It seems to me the algorithm negotiation of the transport layer has a bug,
it does not follow the specification of draft-ietf-secsh-transport-24, page
19, where the behaviour of first_kex_packet_follows is specified.

I've got an ssh client that sends an SSH_MSG_KEXINIT message and specifies
only 'diffie-hellman-group1-sha1' as key exchange algorithm. It sets
first_kex_packet_follows to true, and immediately sends the
SSH_MSG_KEXDH_INIT message. The ssh server (openssh-3.9p1) specifies three
key exchange algorithms in its SSH_MSG_KEXINIT message:
'diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellm
an-group1-sha1'. This results in diffie-hellman-group1-sha1 being the
algorithm used. So, I would think my client's guess is right, and its next
message is not ignored by the server. However, the ssh server gives me the
following debug output:

    debug2: proposal mismatch: my diffie-hellman-group-exchange-sha1 peer
diffie-hellman-group1-sha1
    debug2: skipping next packet (type 30)

The server indeed put its diffie-hellman-group-exchange-sha1 first in its
list, but that does not mean my client's guess was wrong. My client guessed
that diffie-hellman-group1-sha1 would be the algorithm chosen, and
anticipated by sending a SSH_MSG_KEXINIT message. That guess was right, so
its next message should not be ignored.

I'll include the description of the 'first_kex_packet_follows' field as
specified in draft-ietf-secsh-transport-24:

      first_kex_packet_follows
         Indicates whether a guessed key exchange packet follows.  If a
         guessed packet will be sent, this MUST be TRUE.  If no guessed
         packet will be sent, this MUST be FALSE.

         After receiving the SSH_MSG_KEXINIT packet from the other side,
         each party will know whether their guess was right.  If the
         other party's guess was wrong, and this field was TRUE, the
         next packet MUST be silently ignored, and both sides MUST then
         act as determined by the negotiated key exchange method.  If
         the guess was right, key exchange MUST continue using the
         guessed packet.

The server should not look at its own list of key exchange algorithms when
determining whether to ignore my client's next message, but it should
compare the chosen algorithm to the first algorithm specified in my client's
list. If those two do not match, then the client's guess was wrong,
otherwise, the server should not ignore my client's SSH_MSG_KEXDH_INIT
message.

best regards,

Richard Peters



From fcusack at fcusack.com  Fri Jun 17 09:40:08 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Thu, 16 Jun 2005 16:40:08 -0700
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050610013615.GT659@binky.Central.Sun.COM>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
Message-ID: <4094F650162B7F75391A073E@manatee.local>

On June 9, 2005 8:36:16 PM -0500 Nicolas Williams <Nicolas.Williams at sun.com> wrote:

> On Fri, Jun 10, 2005 at 10:10:05AM +1000, Darren Tucker wrote:
>> Nicolas Williams wrote:
>> If you're looking for ways to improve PAM then I've got a long list, but
>> the biggest single improvement you could make is to come up with a
>> rentrant replacement for the blocking callback conversation function model.
>
> I have a long list too.  As OpenSolaris comes online we'll have lots of
> opportunity to go over these lists, design and implement improvements.
>
> As for the conversation function issue you have, I've advised the
> OpenSSH team before on how to handle the matter,

As have I.  It's not difficult.  The portable openssh team just doesn't
get PAM, and apparently doesn't WANT to (I say this because it's not
that hard).

Frank



From djm at mindrot.org  Fri Jun 17 15:49:11 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jun 2005 15:49:11 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <4094F650162B7F75391A073E@manatee.local>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
Message-ID: <42B26457.1020308@mindrot.org>

Frank Cusack wrote:
>> I have a long list too.  As OpenSolaris comes online we'll have lots of
>> opportunity to go over these lists, design and implement improvements.
>>
>> As for the conversation function issue you have, I've advised the
>> OpenSSH team before on how to handle the matter,
> 
> As have I.  It's not difficult.  The portable openssh team just doesn't
> get PAM, and apparently doesn't WANT to (I say this because it's not
> that hard).

We do get PAM, we just don't feel the need to rewrite our application to
cope with its terrible interface. What we have works with the vast
majority of PAM modules and the module that does regularly cause
problems (pam_krb5) replicates functionality largely integrated into
OpenSSH anyway.

But, if you really care, then you can help lobby for a modern, saner PAM
API and obviate this whole mess. We have tried before, the Sun people
don't seem to care and the Linux-PAM people are asleep at the switch
(they don't even seem to respond to serious bug reports these days).

Or, you can submit patches - many of yours have been gratefully accepted
in the past and, as you say, "it's not that hard".

Or, you can continue to whinge from the sidelines and keep the status
quo.

-d



From sfrost at snowman.net  Fri Jun 17 22:27:40 2005
From: sfrost at snowman.net (Stephen Frost)
Date: Fri, 17 Jun 2005 08:27:40 -0400
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42B26457.1020308@mindrot.org>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
Message-ID: <20050617122740.GB30011@ns.snowman.net>

* Damien Miller (djm at mindrot.org) wrote:
> We do get PAM, we just don't feel the need to rewrite our application to
> cope with its terrible interface. What we have works with the vast
> majority of PAM modules and the module that does regularly cause
> problems (pam_krb5) replicates functionality largely integrated into
> OpenSSH anyway.

This caught me slightly off-guard so I'd like to just double-check...
As far as I'm aware it's not possible to duplicate what pam_krb5 does
(takes a password, gets a TGT and a host/<fqdn> for the user and dumps
it into their KRB5CCACHE) with OpenSSH today.

Thinking about it, I don't see any particular reason why that *couldn't*
be coded into sshd, and it would nicely get around the problems pam_krb5
and ssh have today.  I expect there would need to be an option to
enable/disable it since I'm sure some people have setups similar to me
(one machine allows passworded logins, everything else demands
Kerberos).

Am I wrong in my assumption that OpenSSH hasn't got such an option
today, and if not, is this an indication that the OpenSSH team would be
willing to consider a patch to add that functionality directly to
OpenSSH?  Anyone else interested in this besides me?  Personally I'm not
exactly a big fan of the seemingly often interaction problems between
OpenSSH and pam_krb5 and this might resolve the problems once and for
all...

	Many thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050617/7b5543f5/attachment.bin 

From dtucker at zip.com.au  Fri Jun 17 23:43:16 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Jun 2005 23:43:16 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050617122740.GB30011@ns.snowman.net>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>	<20050610013615.GT659@binky.Central.Sun.COM>	<4094F650162B7F75391A073E@manatee.local>	<42B26457.1020308@mindrot.org>
	<20050617122740.GB30011@ns.snowman.net>
Message-ID: <42B2D374.8070000@zip.com.au>

Stephen Frost wrote:
> This caught me slightly off-guard so I'd like to just double-check...
> As far as I'm aware it's not possible to duplicate what pam_krb5 does
> (takes a password, gets a TGT and a host/<fqdn> for the user and dumps
> it into their KRB5CCACHE) with OpenSSH today.

Does KerberosAuthentication=yes + PasswordAuthentication do what you 
want?  Since some time last year, auth_krb5_password() will put 
KRB5CCNAME where PAM can find it:

#ifdef USE_PAM
         if (options.use_pam)
                 do_pam_putenv("KRB5CCNAME", authctxt->krb5_ccname);
#endif

That's in 4.0p1 and 4.1p1 (from Doug Engert).

-- 
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 Nicolas.Williams at sun.com  Sat Jun 18 04:28:55 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 17 Jun 2005 13:28:55 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42B26457.1020308@mindrot.org>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
Message-ID: <20050617182855.GW16670@binky.Central.Sun.COM>

On Fri, Jun 17, 2005 at 03:49:11PM +1000, Damien Miller wrote:
> Frank Cusack wrote:
> >As have I.  It's not difficult.  The portable openssh team just doesn't
> >get PAM, and apparently doesn't WANT to (I say this because it's not
> >that hard).
> 
> We do get PAM, we just don't feel the need to rewrite our application to
> cope with its terrible interface. What we have works with the vast
> majority of PAM modules and the module that does regularly cause
> problems (pam_krb5) replicates functionality largely integrated into
> OpenSSH anyway.
> 
> But, if you really care, then you can help lobby for a modern, saner PAM
> API and obviate this whole mess. We have tried before, the Sun people
> don't seem to care and the Linux-PAM people are asleep at the switch
> (they don't even seem to respond to serious bug reports these days).

PAM can and will get better, but don't expect the interaction-through-
callback functions aspect of it to change anytime soon -- it can't, not
in a way that is backwards compatible with existing PAM applications and
modules.  If you want a fix for that then you must either lobby for a
shim that uses threading to provide an iterative interface or for a
replacement for PAM altogether.

I don't think PAM is going away though, and since PAM application
developers _can_ cope with those callbacks I don't see much incentive
for PAM implementors to provide an iterative shim atop PAM.  Since you
say you'll take patches I assume that getting OpenSSH to handle PAM
properly is really just a matter of resources and therefore really a
matter of time.

No, I don't have time to write patches for the lates portable OpenSSH,
so don't expect any patches from me anytime soon...

Cheers,

Nico
-- 



From rapier at psc.edu  Sat Jun 18 05:50:33 2005
From: rapier at psc.edu (Chris Rapier)
Date: Fri, 17 Jun 2005 15:50:33 -0400
Subject: New Set of High Performance Networking Patches Available
Message-ID: <42B32989.2080106@psc.edu>


http://www.psc.edu/networking/projects/hpn-ssh/

Mike Stevens and I just released a new set of high performance 
networking patches for OpenSSH 3.9p1, 4.0p1, and 4.1p1. These patches 
will provide the same set of functionality across all 3 revisions. New 
functionality includes

1) HPN performance even without both sides of the connection being HPN 
enabled. As long as the bulk data flow is in the direction of the HPN 
side you should see improved performance. I've measure 200Mb/s to an HPN 
server from a non HPN client and vice versa.

2) HPN client can now set the local tcp receive buffer on a per 
connection basis. Using the -w option allows the client to override the 
local tcp receive window settings up to the maximum tcp buffer size. 
This is just a setsockopt() call really.

3) NONE cipher switching now available for all revisions. This *is* a 
separate set of patches so it doesn't have to be part of your HPN 
install if you don't want the additional risk associated with NONE. It 
is important to note that the NONE cipher is only used *after* 
authentication takes place. During authentication the default or user 
specified cipher will be used. It should not be very easy to accidental 
switch over to NONE in an interactive session. Of course, the user has 
to accept that there are additional risks.

We're seeing very good throughput - up to 280Mb/s with the arcfour 
cipher. We're actually being limited by the disk speed in this case as 
cpu load is still under 60% on our test machines.

You can find the patches here
http://www.psc.edu/networking/projects/hpn-ssh/

Note: All we are doing is allowing SSH to make better use of the network 
available to it. People on networking paths with a bandwidth delay 
product lower that 64KB won't see an improvement in throughput. You 
should also make sure that the TCP stack on both sides are properly 
tuned for high performance networking.

Comments, questions, observations, bug reports, and the like are 
welcome. We'll have some more stuff out in the next month or so 
hopefully (not patches).

Chris Rapier, PSC
Mike Stevens, CMU



From deengert at anl.gov  Sat Jun 18 07:13:25 2005
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 17 Jun 2005 16:13:25 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050617122740.GB30011@ns.snowman.net>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>	<20050610013615.GT659@binky.Central.Sun.COM>	<4094F650162B7F75391A073E@manatee.local>	<42B26457.1020308@mindrot.org>
	<20050617122740.GB30011@ns.snowman.net>
Message-ID: <42B33CF5.9060703@anl.gov>



Stephen Frost wrote:

> * Damien Miller (djm at mindrot.org) wrote:
> 
>>We do get PAM, we just don't feel the need to rewrite our application to
>>cope with its terrible interface. What we have works with the vast
>>majority of PAM modules and the module that does regularly cause
>>problems (pam_krb5) replicates functionality largely integrated into
>>OpenSSH anyway.
> 
> 
> This caught me slightly off-guard so I'd like to just double-check...
> As far as I'm aware it's not possible to duplicate what pam_krb5 does
> (takes a password, gets a TGT and a host/<fqdn> for the user and dumps
> it into their KRB5CCACHE) with OpenSSH today.

OpenSSH had direct Kerberos support, if you add --with-kerberos5=path
to configure and can compile against MIT or Heimdal. But the nice thing
about using it via PAM is that you can use a vendor's version of OpenSSH
that may not have been compiled with the --with-kerberos5, and add Kerberos
later via PAM.

(OpenSSH also had GSSAPI for Kerberos.)

> 
> Thinking about it, I don't see any particular reason why that *couldn't*
> be coded into sshd, and it would nicely get around the problems pam_krb5
> and ssh have today.  I expect there would need to be an option to
> enable/disable it since I'm sure some people have setups similar to me
> (one machine allows passworded logins, everything else demands
> Kerberos).

Has the KerberosOrLocalPasswd yes|no options too.

> 
> Am I wrong in my assumption that OpenSSH hasn't got such an option
> today, and if not, is this an indication that the OpenSSH team would be
> willing to consider a patch to add that functionality directly to
> OpenSSH?  Anyone else interested in this besides me?  Personally I'm not
> exactly a big fan of the seemingly often interaction problems between
> OpenSSH and pam_krb5 and this might resolve the problems once and for
> all...

The code is there, and works, but I would be in favor of not using it
but using PAM instead as it uses Kerberos non standard API code out of
sshd, and in to seperate modules like pam_krb5 (or gssapi). The PAM code
is getting better, and as pam_krb5 is used by other login functions, like
login, or gdm, or dtlogin, xlock, xscreensaver, pam_krb5 will still be around.




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

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



From dwmw2 at infradead.org  Sat Jun 18 08:04:28 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 17 Jun 2005 23:04:28 +0100
Subject: %h,%p,%u expansion for ControlPath
In-Reply-To: <42B0F21B.2090405@mindrot.org>
References: <1118566763.4823.97.camel@localhost.localdomain>
	<42AD4B5E.9020300@mindrot.org>
	<1118655140.2840.19.camel@localhost.localdomain>
	<42B0F21B.2090405@mindrot.org>
Message-ID: <1119045868.24842.12.camel@localhost.localdomain>

On Thu, 2005-06-16 at 13:29 +1000, Damien Miller wrote:
> I'm not sure about the persist option; it would be useful, but probably
> confusing (especially amongst all the other ControlMaster options).
> Maybe users should just do "ssh -nNf host" instead...

That's not really a good enough solution -- it needs to be automatic,
really. I'm inclined to agree about 'all the other ControlMaster
options', which is why I wonder if we should make it (and maybe also
'ask') a separate option.

My first cut isn't good enough either though -- it doesn't work with
protocol 1, because it forks and waits for the '-nNf' child which then
obviously doesn't actually hold a control socket open for it.

I think we need to get as far as making the connection and
authenticating before we fork -- either that or we fork into the
background after the client which starts it has finished its session.
I'll take another look when I can next snatch a few minutes.

-- 
dwmw2



From djm at mindrot.org  Sat Jun 18 08:47:41 2005
From: djm at mindrot.org (Damien Miller)
Date: Sat, 18 Jun 2005 08:47:41 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <20050617182855.GW16670@binky.Central.Sun.COM>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
	<20050617182855.GW16670@binky.Central.Sun.COM>
Message-ID: <42B3530D.4090609@mindrot.org>

Nicolas Williams wrote:
> 
> I don't think PAM is going away though, and since PAM application
> developers _can_ cope with those callbacks I don't see much incentive
> for PAM implementors to provide an iterative shim atop PAM.  Since you
> say you'll take patches I assume that getting OpenSSH to handle PAM
> properly is really just a matter of resources and therefore really a
> matter of time.

No, it is just an preference to discuss something concrete (patches)
over pointless "OpenSSH should/shouldn't do this, OpenSSH developers are
misguided/dumb/eat babies because ..." arguments.

I never guaranteed that any patches would be accepted, but at least they
could advance this discussion to the point where it has the potential to
be productive.

-d



From r.a.peters at student.tue.nl  Mon Jun 20 05:29:47 2005
From: r.a.peters at student.tue.nl (Richard Peters)
Date: Sun, 19 Jun 2005 21:29:47 +0200
Subject: Bug report: first_kex_packet_follows behaviour seems wrong
Message-ID: <078501c57505$52283460$0a01a8c0@campus.tue.nl>

Original Message From: Richard Peters

> It seems to me the algorithm negotiation of the transport layer has a bug,
> it does not follow the specification of draft-ietf-secsh-transport-24,
page
> 19, where the behaviour of first_kex_packet_follows is specified.

Upon re-reading the beginning of section 7, page 16, I must conclude that
OpenSSH does correctly follow the specification. It just seemed wrong that
when a client sent a key exchange packet for the algorithms that are chosen
anyway, the guess could still be considered wrong.
You may ignore my previous bug report.

best regards,

Richard Peters



From fcusack at fcusack.com  Tue Jun 21 10:19:07 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Mon, 20 Jun 2005 17:19:07 -0700
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42B26457.1020308@mindrot.org>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
Message-ID: <C34C72118F1117F167F8E789@manatee.local>

On June 17, 2005 3:49:11 PM +1000 Damien Miller <djm at mindrot.org> wrote:
> Frank Cusack wrote:
>>> I have a long list too.  As OpenSolaris comes online we'll have lots of
>>> opportunity to go over these lists, design and implement improvements.
>>>
>>> As for the conversation function issue you have, I've advised the
>>> OpenSSH team before on how to handle the matter,
>>
>> As have I.  It's not difficult.  The portable openssh team just doesn't
>> get PAM, and apparently doesn't WANT to (I say this because it's not
>> that hard).
>
> We do get PAM, we just don't feel the need to rewrite our application to
> cope with its terrible interface. What we have works with the vast
> majority of PAM modules

But it does not follow the API correctly.  Isn't correctness a priority
for the openssh folks?  It's not just the conversation function handling
that's broken in openssh.

One of the large benefits of PAM is that organizations can write their
own authentication functionality without having to rewrite every application.
You are (to an admittedly small degree) reducing the effectiveness of PAM;
rather, for organizations that need such correctness, you are increasing
their exposure by forcing them to maintain their own openssh.  Yes, that
must be a conscious decision on the part of such organizations, but their
hand is forced nonetheless.

> and the module that does regularly cause
> problems (pam_krb5) replicates functionality largely integrated into
> OpenSSH anyway.

Publicly available module, you mean.

> But, if you really care, then you can help lobby for a modern, saner PAM
> API and obviate this whole mess. We have tried before, the Sun people
> don't seem to care and the Linux-PAM people are asleep at the switch
> (they don't even seem to respond to serious bug reports these days).
>
> Or, you can submit patches - many of yours have been gratefully accepted
> in the past and, as you say, "it's not that hard".
>
> Or, you can continue to whinge from the sidelines and keep the status
> quo.

That's laughable.

Anyway, I withdraw my comment as I see (now that I examine recent sources)
that PAM support is steadily improving.  Documenting threads as an ugly hack
is one of those nice improvements, IMHO.  Why you added it in the first place
is beyond my understanding.  As is why you refuse fairly trivial patches to
correctly handle PAM conversations.  Yet you have ugly code in there which
supports much more obscure systems.  (Although I hate to say that, because
I myself always reject arguments for brokenness that are based on existing
brokenness; just because something is already broken doesn't mean you make
it more broken.  But we're not talking about breaking openssh, we're talking
about improving it, from a system compatibility POV.)

Frank



From redelm at sbcglobal.net  Tue Jun 21 22:14:04 2005
From: redelm at sbcglobal.net (Robert Redelmeier)
Date: Tue, 21 Jun 2005 07:14:04 -0500
Subject: Keypress delay & grouping
Message-ID: <20050621121404.GA26794@adsl-70-240-240-206.dsl.hstntx.swbell.net>

Forgive this intrusion, but I couldn't
find much mention of this in the archives.

To reduce vulnerability to "Keystroke Timing Attack"
and reduce keystroke packet overhead, why not insert
a small configurable delay (10-1000ms) before sending
keystroke packets?`ssh -d NNN`

Yes, this costs latency.  But many netlinks are
already 200+ms and latency isn't always objectionable
in a CLI where people frequently type-ahead.  The
longer delays (20+ms) also give a good chance to
combine multiple keystrokes into a single packet,
reducing overhead and confusing listeners.

Practically, XX chars or a wait of `delay` would
release the send buffer.  That short wait would be
like pressing "RETURN" in LINEMODE telnet.  Fancier
implimentations might use smart delays based on
previous keystroke interval.

nanosleep() and similar delay functions should be
very useful so long as they're not so short as to
busywait but instead wait for the system clock.  This
introduces a variable delay that greatly reduces the
information from timing analysis.

I believe sshd already can handle multiple keypresses
per packet, but I did get one to choke around 1500
after pasting in 10KB.

I inserted a usleep() in channel_output_poll() [not the
best place but I couldn't get it to work in clientloop.c]
and it runs fine for me, but I may need to make the delay a
bit smarter.


-- Robert







From mar_mog at o2.pl  Wed Jun 22 01:55:05 2005
From: mar_mog at o2.pl (Marcin Mogielnicki)
Date: Tue, 21 Jun 2005 17:55:05 +0200
Subject: problem with pam_converse with openssh protocol version 1
Message-ID: <42B83859.60400@o2.pl>

Hi,

My company decided to implement security restrictions lately and I was 
to write more strict authorization modules for pam. One of it works 
asking for some kind of additional security string (for example pin from 
some kind of token). It is done by pam module, which asks calling 
application to do conversation for him:

         prompt_msg.msg_style = PAM_PROMPT_ECHO_OFF;
         prompt_msg.msg=strdup("Enter PIN:");
         pmsg[i++] = &prompt_msg;
         retval = pam_get_item(pamh, PAM_CONV,(void *) &conv);
         if (retval != PAM_SUCCESS)
          return PAM_SYSTEM_ERR;
         retval = conv->conv (i,(CONST struct pam_message 
**)&pmsg,&resp, conv->appdata_ptr);
         if (retval != PAM_SUCCESS || resp == NULL)
          return PAM_SYSTEM_ERR;
         pin=strdup(resp->resp);
         free (resp);

It works. For example rlogin shows string "Enter PIN:" and returns 
answer in resp->resp. Openssh works exactly the same, right way, if 
'ChallengeResponseAuthentication yes' is set and v2 protocol is used. 
With v1 PAM_CONV_ERR is always returned, which means that error occured 
during conversation with user. However no conversation takes place - 
"Enter PIN:" is not shown, user is asked for nothing. Logging in with v1 
looks this way:

# ssh -1 -p machine
Password:
Response:
user at machine's password:
(...)
It depends of pam cofiguration, if user is allowed in - PAM_CONV_ERR is 
returned and conversation took no place at all.

v2:
# ssh -2 machine
Password:
Enter PIN:
(...)
Everything works like it should.

I suspect that I will receive very simple answer - "use v2 only". It is 
the simplest and the most secure and effective, but inacceptable. Some 
of machines (Cray SV1 for example) have v1 only implemented. Besides 
hundreds of users connect to my site every day - try to persuade all of 
them to use v2 only.

So one more time:

1) if ChallengeResponseAuthentication is set to yes, pam conversation 
works right with v2, but v1 returns PAM_CONV_ERR. Moreover, it asks user 
for weird things, which make user to call me.
2) if ChallengeResponseAuthentication is set to no, pam conversation 
takes no place in v1 and v2 - PAM_CONV_ERR is returned by sshd to pam 
module.

Is there any way to implement pam conversation into v1 protocol? If not, 
it could be nice for v1 to converse with user in more comprehensible way.

All the tests took place on Solaris 9 and Linux - both behave exactly 
the same (i.e. wrong) way.

Thanks in advance,

	Marcin Mogielnicki, ICM, Poland



From Nicolas.Williams at sun.com  Wed Jun 22 03:26:10 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 21 Jun 2005 12:26:10 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42B3530D.4090609@mindrot.org>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
	<20050617182855.GW16670@binky.Central.Sun.COM>
	<42B3530D.4090609@mindrot.org>
Message-ID: <20050621172610.GC16670@binky.Central.Sun.COM>

On Sat, Jun 18, 2005 at 08:47:41AM +1000, Damien Miller wrote:
> No, it is just an preference to discuss something concrete (patches)
> over pointless "OpenSSH should/shouldn't do this, OpenSSH developers are
> misguided/dumb/eat babies because ..." arguments.
> 
> I never guaranteed that any patches would be accepted, but at least they
> could advance this discussion to the point where it has the potential to
> be productive.

Oh, I understand that you can't guarantee that you'd accept a patch.

But you'd have to agree to consider a given approach if you want someone
else to do the work, no?

So, do you have any reason to consider event loop nesting out of the
question?

As I see it there's only one reasonable, portable, solution: nest the
event loop.  In the privsep case only the monitor need nest its event
loop.

Nico
-- 



From prakash.velupula at hp.com  Wed Jun 22 05:09:27 2005
From: prakash.velupula at hp.com (Velupula, Prakash)
Date: Tue, 21 Jun 2005 14:09:27 -0500
Subject: Open SSH Specifications
Message-ID: <717252EC3E37AE4392E2614EA24E9F2B0CF5051D@txnexc01.americas.cpqcorp.net>

Hi all,
 
We have Open SSH 3.4p1 available on our HPTE (HP Telco Extensions)
Linux. We have a need to comply with the following requirements for our
customers:

*	The SSH product shall support Version 2 of SSH as defined by the
standards 
*	The SSH product shall support both client and server versions 
*	The SSH product shall support the following authentication
methods
-          Password Authentication 
-          Public-Key Authentication 
-          Host-Based Authentication 
-          Certificate Authentication
-          Kerberos Authentication 
-          Pluggable Authentication Module (PAM) 
-          SecurID

*	The SSH shall support a packet filtering firewall.  This
requirement allows for secure telnet only from some physical ports and
regular telnet from other physical ports 
*	The SSH product shall support secure Public Key encryption 
*	The SSH product shall be capable of being exported to all
countries in accordance with US governmental trade policies (i.e. Denied
or Restricted Parties) 
*	The SSH product shall support real time applications.  Run time
speed, footprint, etc are important parameters that should be optimized 
*	SSH agent should be included in the product 
*	Use force command configuration of the SSH - it limits what
clients can do in a session

Is there any Specifications document for Open SSH which describes as to
what all features are supported in a particular version? Otherwise,
should we perform the validation for ourselves using some test library?
 
Your co-operation is very much appreciated.
 
 
Thanks,
Prakash



From fcusack at fcusack.com  Wed Jun 22 06:27:50 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 21 Jun 2005 13:27:50 -0700
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <42B83859.60400@o2.pl>
References: <42B83859.60400@o2.pl>
Message-ID: <09C14BC7DD2045FED65AAAA2@manatee.local>

On June 21, 2005 5:55:05 PM +0200 Marcin Mogielnicki <mar_mog at o2.pl> wrote:
> I suspect that I will receive very simple answer - "use v2 only". It is the simplest and the most
> secure and effective, but inacceptable. Some of machines (Cray SV1 for example) have v1 only
> implemented. Besides hundreds of users connect to my site every day - try to persuade all of them
> to use v2 only.
>
> So one more time:
>
> 1) if ChallengeResponseAuthentication is set to yes, pam conversation works right with v2, but v1
> returns PAM_CONV_ERR. Moreover, it asks user for weird things, which make user to call me.
> 2) if ChallengeResponseAuthentication is set to no, pam conversation takes no place in v1 and v2
> - PAM_CONV_ERR is returned by sshd to pam module.
>
> Is there any way to implement pam conversation into v1 protocol? If not, it could be nice for v1
> to converse with user in more comprehensible way.

In v1, you'd have to use TIS authentication.  You have to make sure your client
doesn't echo the password, though.  (I think all modern clients are conservative
and don't echo.)  You might end up having to make some small sshd changes to make
this work.

Frank



From dtucker at zip.com.au  Wed Jun 22 08:52:31 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 22 Jun 2005 08:52:31 +1000
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <09C14BC7DD2045FED65AAAA2@manatee.local>
References: <42B83859.60400@o2.pl> <09C14BC7DD2045FED65AAAA2@manatee.local>
Message-ID: <42B89A2F.1090108@zip.com.au>

Frank Cusack wrote:
> On June 21, 2005 5:55:05 PM +0200 Marcin Mogielnicki <mar_mog at o2.pl> wrote:
> 
>> I suspect that I will receive very simple answer - "use v2 only".
>> It is the simplest and the most secure and effective, but
>> inacceptable. Some of machines (Cray SV1 for example) have v1 only 
>> implemented. Besides hundreds of users connect to my site every day
>> - try to persuade all of them to use v2 only.
>>
>> So one more time:
>>
>> 1) if ChallengeResponseAuthentication is set to yes, pam conversation 
>> works right with v2, but v1
>> returns PAM_CONV_ERR. Moreover, it asks user for weird things, which 
>> make user to call me.
>> 2) if ChallengeResponseAuthentication is set to no, pam conversation 
>> takes no place in v1 and v2
>> - PAM_CONV_ERR is returned by sshd to pam module.
>>
>> Is there any way to implement pam conversation into v1 protocol? If
>> not, it could be nice for v1 to converse with user in more
>> comprehensible way.

If already is however it is limited by the protocol, see below.

> In v1, you'd have to use TIS authentication. You have to make sure
> your client doesn't echo the password, though. (I think all modern
> clients are conservative and don't echo.) You might end up having to
> make some small sshd changes to make this work.

That's what was being attempted first but it failing.

Note that in this particular PAM configuration there are 2 calls to the 
conversation function, once for PIN and once for password,.  When that 
fails, it's falling back to plain password authentication (you can 
prevent that by disabling PasswordAuthentication in sshd_config since 
it's probably not going to work with that PAM config anyway).

My read of the original SSH1 protocol spec is that there is only one 
challenge/response pair permitted by the protocol.  For the TIS 
response, it says:

    41 SSH_CMSG_AUTH_TIS_RESPONSE

         string   user response to tis challenge

         When client receives SSH_SMSG_AUTH_TIS_CHALLENGE and ask users
         response to challenge it sends it back this message. The server
         answers with SSH_SMSG_FAILURE or SSH_SMSG_SUCCESS.

so the server can only reply with success or failure immediately after 
the first response, there's no partial-success flag.

If you can compact your requirements to a single challenge and response 
(eg "Enter password followed by PIN:") it'll probably work, but other 
than that I think you're limited to Protocol 2 only.

[1] http://www.zip.com.au/~dtucker/openssh/ssh-rfc-v1.txt among other 
places.

-- 
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 Jun 22 09:07:46 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 22 Jun 2005 09:07:46 +1000
Subject: Open SSH Specifications
In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B0CF5051D@txnexc01.americas.cpqcorp.net>
References: <717252EC3E37AE4392E2614EA24E9F2B0CF5051D@txnexc01.americas.cpqcorp.net>
Message-ID: <42B89DC2.2080607@zip.com.au>

Velupula, Prakash wrote:
> We have Open SSH 3.4p1 available on our HPTE (HP Telco Extensions)
> Linux. We have a need to comply with the following requirements for our
> customers:
> 
> *	The SSH product shall support Version 2 of SSH as defined by the
> standards

There are no standards for SSH version 2.  There are only draft protocol 
specifications and they're still changing.

> *	The SSH product shall support both client and server versions 
> *	The SSH product shall support the following authentication
> methods
> -          Password Authentication 
> -          Public-Key Authentication 
> -          Host-Based Authentication 
> -          Certificate Authentication

Vanilla OpenSSH doesn't support (x.509) certificates you would need a 
third-party patch such as Roumen Petrov's.

> -          Kerberos Authentication 
> -          Pluggable Authentication Module (PAM) 
> -          SecurID

OpenSSH supports PAM via keyboard-interactive authentication.  There's 
no direct support for SecurID however it ought to work via PAM if a 
suitable module is available.  There are also third-party patches but 
I'm not sure if they're currently maintained.

> *	The SSH shall support a packet filtering firewall.  This
> requirement allows for secure telnet only from some physical ports and
> regular telnet from other physical ports

Packet filtering is a kernel function not an application function.

> *	The SSH product shall support secure Public Key encryption 
> *	The SSH product shall be capable of being exported to all
> countries in accordance with US governmental trade policies (i.e. Denied
> or Restricted Parties)

That's a question for your legal team.

> *	The SSH product shall support real time applications.  Run time
> speed, footprint, etc are important parameters that should be optimized 

I'm not sure what an SSH application would do differently to "support 
real time applications".

> *	SSH agent should be included in the product 
> *	Use force command configuration of the SSH - it limits what
> clients can do in a session
> 
> Is there any Specifications document for Open SSH which describes as to
> what all features are supported in a particular version?

The best bet is the ssh_config(5) and sshd_config(5) man pages for the 
version you're interested in.

-- 
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 Jun 22 09:35:06 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 22 Jun 2005 09:35:06 +1000
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <A0AAC4F8008E0C0866CEADA0@manatee.local>
References: <42B83859.60400@o2.pl> <09C14BC7DD2045FED65AAAA2@manatee.local>
	<42B89A2F.1090108@zip.com.au>
	<A0AAC4F8008E0C0866CEADA0@manatee.local>
Message-ID: <42B8A42A.9030609@zip.com.au>

Frank Cusack wrote:
> On June 22, 2005 8:52:31 AM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
>> My read of the original SSH1 protocol spec is that there is only one 
>> challenge/response pair
>> permitted by the protocol.  For the TIS response, it says:
> 
> Ah. I must have made some client-side code changes to make this work,
> then. (In my original response I already said some sshd changes
> might be necessary.) They're rather easy.

I guess you could do it on the server side only by maintaining the PAM 
context between auth attempts and disabling all other auth types.  From 
a protocol perspective this would be 2 separate TIS attempts, the first 
failing and the second succeeding but to the user it would look kinda right.

It's awfully hacky, though.  Isn't correctness a priority for you?  :-)

-- 
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 Jun 22 10:19:21 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 22 Jun 2005 10:19:21 +1000
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <C34C72118F1117F167F8E789@manatee.local>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
	<C34C72118F1117F167F8E789@manatee.local>
Message-ID: <42B8AE89.3090004@zip.com.au>

Let me preface this with some things I think we can agree on:

1) sshd's PAM interface isn't perfect.

2) PAM itself isn't perfect either.

I'd like to think sshd's PAM interface is improving.  We've certainly 
been working to that end.  There is still room for improvement, no 
question.  (If you look at the open sshd PAM bugs you will see that some 
of them have been raised by me.)

It's never going to be perfect.  Given the SSHv1 and v2 protocol specs 
and PAM as it stands I don't think it's possible.

Now some of my opinions on PAM from working with it in the context of 
sshd.  (I'm not going to justify them although I will if people wish):

3) PAM's blocking callback conversation interface makes using it from 
sshd harder than it has to be.  Similarly functional authentication 
systems with reentrant interfaces can be used with much less code (like 
an order of magnitude less).

4) Several other of its characteristics make PAM as a whole harder for 
sshd to use.

5) The differences between PAM implementations (and in some cases bugs 
in them) make it harder for sshd to work with all of them.

6) The multiple-messages part of the PAM conversation protocol (ie 
allowing more than one message per call to the conversation function) is 
more complex than necessary and this has been a source of bugs.

Frank Cusack wrote:
> On June 17, 2005 3:49:11 PM +1000 Damien Miller <djm at mindrot.org> wrote:
[...]
> But it does not follow the API correctly.  Isn't correctness a priority
> for the openssh folks?  It's not just the conversation function handling
> that's broken in openssh.

Would you please describe this (or provide a pointer to what you're 
referring to)?

> One of the large benefits of PAM is that organizations can write their
> own authentication functionality without having to rewrite every 
> application.

Sure, and that's a worthwhile goal.  Some of the ways it does it are 
problematic, though.

[...]

> Anyway, I withdraw my comment as I see (now that I examine recent
> sources) that PAM support is steadily improving. Documenting threads
> as an ugly hack is one of those nice improvements, IMHO. Why you
> added it in the first place is beyond my understanding.

It was in the FreeBSD code on which the current PAM code is based, and 
since then it's been the only general solution to modules that rely on 
pam_set_data/pam_get_data (in the main distribution, anyway).

Right now, it's a necessary (but unsupported) evil.  Once we have a 
better solution, it becomes an *un*necessary evil and it's history.

> As is why you
> refuse fairly trivial patches to correctly handle PAM conversations.

Again, would you please describe this or provide a pointer to the patch 
in question?

> Yet you have ugly code in there which supports much more obscure
> systems. (Although I hate to say that, because I myself always reject
> arguments for brokenness that are based on existing brokenness; just
> because something is already broken doesn't mean you make it more
> broken. But we're not talking about breaking openssh, we're talking 
> about improving it, from a system compatibility POV.)

Great, but let's talk about specific improvements rather than in 
generalities.

-- 
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 Jun 22 10:49:14 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 22 Jun 2005 10:49:14 +1000
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <4528BA1AB1C50B0BA15984CC@manatee.local>
References: <42B83859.60400@o2.pl> <09C14BC7DD2045FED65AAAA2@manatee.local>
	<42B89A2F.1090108@zip.com.au>
	<A0AAC4F8008E0C0866CEADA0@manatee.local>
	<42B8A42A.9030609@zip.com.au>
	<4528BA1AB1C50B0BA15984CC@manatee.local>
Message-ID: <42B8B58A.1090309@zip.com.au>

Frank Cusack wrote:
[about hacking SSHv1 TIS auth for multiple challenges]
> Actually, what I did was to allow any number of challenge messages.
> So a failure message is indeed a failure.  I collected all the prompts
> in the conversation function and sent them one at a time as individual
> challenges to the client.

I don't think that's guaranteed to work with a compliant SSHv1 client. 
The client is well within its rights to try some other auth type after 
the first TIS failure then abort when the server violates the protocol 
by sending a second TIS challenge without the client first sending a 
SSH_CMSG_AUTH_TIS.

It may work with an unmodified client but purely by accident.

If they're going to have to modify clients they may as well deploy a v2 
client which can support it properly.

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



From fcusack at fcusack.com  Wed Jun 22 09:59:02 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 21 Jun 2005 16:59:02 -0700
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <42B8A42A.9030609@zip.com.au>
References: <42B83859.60400@o2.pl> <09C14BC7DD2045FED65AAAA2@manatee.local>
	<42B89A2F.1090108@zip.com.au> <A0AAC4F8008E0C0866CEADA0@manatee.local>
	<42B8A42A.9030609@zip.com.au>
Message-ID: <4528BA1AB1C50B0BA15984CC@manatee.local>

On June 22, 2005 9:35:06 AM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
> Frank Cusack wrote:
>> On June 22, 2005 8:52:31 AM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
>>> My read of the original SSH1 protocol spec is that there is only one
>>> challenge/response pair
>>> permitted by the protocol.  For the TIS response, it says:
>>
>> Ah. I must have made some client-side code changes to make this work,
>> then. (In my original response I already said some sshd changes
>> might be necessary.) They're rather easy.
>
> I guess you could do it on the server side only by maintaining the PAM context between auth
> attempts and disabling all other auth types.  From a protocol perspective this would be 2
> separate TIS attempts, the first failing and the second succeeding but to the user it would look
> kinda right.
>
> It's awfully hacky, though.  Isn't correctness a priority for you?  :-)

:-)

Actually, what I did was to allow any number of challenge messages.
So a failure message is indeed a failure.  I collected all the prompts
in the conversation function and sent them one at a time as individual
challenges to the client.

That's just from memory; I don't have the code anymore.

Frank



From djm at mindrot.org  Thu Jun 23 14:26:13 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 23 Jun 2005 14:26:13 +1000 (EST)
Subject: test, please ignore
Message-ID: <20050623042613.A7D1517E62F@mail.mindrot.org>

This is a test of the mailing list, please ignore.



From Nicolas.Williams at sun.com  Thu Jun 23 06:27:49 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 22 Jun 2005 15:27:49 -0500
Subject: Possible security flaw in OpenSSH and/or pam_krb5
In-Reply-To: <42B8AE89.3090004@zip.com.au>
References: <42A7862E.6080107@zip.com.au>
	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
	<C34C72118F1117F167F8E789@manatee.local>
	<42B8AE89.3090004@zip.com.au>
Message-ID: <20050622202749.GX16670@binky.Central.Sun.COM>

On Wed, Jun 22, 2005 at 10:19:21AM +1000, Darren Tucker wrote:
> 3) PAM's blocking callback conversation interface makes using it from 
> sshd harder than it has to be.  Similarly functional authentication 
> systems with reentrant interfaces can be used with much less code (like 
> an order of magnitude less).

This won't go away.  It's not that we disagree about this aspect of PAM
-- whether we do is irrelevant as we can't actually change this now.

> 6) The multiple-messages part of the PAM conversation protocol (ie 
> allowing more than one message per call to the conversation function) is 
> more complex than necessary and this has been a source of bugs.

Same thing.

[...]
> It was in the FreeBSD code on which the current PAM code is based, and 
> since then it's been the only general solution to modules that rely on 
> pam_set_data/pam_get_data (in the main distribution, anyway).

I'm not sure what you mean -- I've given you a general solution that
works for such modules (it works, I know, because Solaris 10's sshd
implements it) and which does not require threading.

It's not a patch, but, here's some pared down, annotated output from
DTrace that shows the event loop nesting in Solaris 10's sshd (note:
Solaris 10's sshd does not privsep before completion of userauth):

# /tmp/sshd.d 8309
dtrace: script '/tmp/sshd.d' matched 1437 probes
CPU FUNCTION
  1  -> do_authentication2                                    0
  1    -> dispatch_run                                    13856
  1     | dispatch_run:entry                              13856

	    <much of userauth "none" processing cut>
  1              -> auth2_read_banner                    379472
  1              <- auth2_read_banner                    386369
  1              -> auth_password                        387699
  1              <- auth_password                        402011
  1              -> userauth_finish                      403775
  1                -> userauth_check_partial_failure            405446
  1                <- userauth_check_partial_failure            406731

	    <userauth "none" failed>
  1                -> auth_log                           408421
  1                  -> get_remote_ipaddr                410243
  1                  <- get_remote_ipaddr                411812
  1                  -> get_remote_port                  413205
  1                  <- get_remote_port                  428302
  1                  -> verbose                          429356
  1                    -> do_log                         429892
  1                    <- verbose                        450636
  1                  <- auth_log                         451936
  1                  -> packet_start                     452725
  1                  <- packet_start                     457191
  1                  -> packet_put_cstring               500193
  1                  <- packet_put_cstring               508796
  1                  -> packet_put_char                  509939
  1                  <- packet_put_char                  513020
  1                  -> packet_send                      514925
  1                  <- packet_send                      547312
  1                  -> packet_write_wait                547903
  1                  <- packet_write_wait                566347
  1                <- userauth_finish                    567698

	    <beginning of next userauth processing>
  1                -> packet_read_seqnr                  572016
  1                <- packet_read_seqnr                  631496
  1                -> packet_get_string                  632414
  1                <- packet_get_string                  638528
  1                -> packet_get_string                  638987
  1                <- packet_get_string                  644063
  1                -> packet_get_string                  644523
  1                <- packet_get_string                  649537
  1                    -> userauth_user_svc_change            674585
  1                    <- userauth_user_svc_change            691131
  1                      -> packet_get_string            700603
  1                      <- packet_get_string            706340
  1                      -> packet_get_string            706856
  1                      <- packet_get_string            712194
  1                      -> packet_remaining             712781
  1                      <- packet_remaining             714279

	    <it's keyboard-interactive, so call auth2_pam()>
  1                        -> auth2_pam                  724581
  1                          -> new_start_pam            726072
  1                            -> derive_pam_svc_name            727367
  1                            <- derive_pam_svc_name            755245
  1                              -> fatal_add_cleanup           1032515
  1                              <- fatal_add_cleanup           1035132
  1                              -> get_remote_name_or_ip           1036371
  1                                -> get_canonical_hostname           1037855
  1                                  <- get_canonical_hostname           1101406
  1                                <- get_remote_name_or_ip           1102800
  1                              <- new_start_pam           1107792

	    <set handlers for kbd-int packets>
  1                              -> dispatch_set           1108655
  1                              <- dispatch_set           1113516

	    <call pam_authenticate()>
  1                                -> pam_authenticate           1130453

	    <a Solaris PAM module calls a [private] utility function,
	    __pam_get_authtok() which calls sshd's conversation
	    function>
  1                                  -> __pam_get_authtok           6498087

	    <sshd's conversation sends a kbd-int info request>
  1                                      -> packet_start           6552542
  1                                      <- packet_start           6563018
  1                                      -> packet_put_cstring           6564168
  1                                      <- packet_put_cstring           6577362
  1                                      -> packet_put_cstring           6577891
  1                                      <- packet_put_cstring           6584951
  1                                      -> packet_put_cstring           6585452
  1                                      <- packet_put_cstring           6592388
  1                                      -> packet_put_int           6593677
  1                                      <- packet_put_int           6597691
  1                                      -> packet_put_cstring           6598208
  1                                      <- packet_put_cstring           6605226
  1                                      -> packet_put_char           6606352
  1                                      <- packet_put_char           6609471
  1                                      -> packet_send           6610941
  1                                      <- packet_send           6664941
  1                                      -> packet_write_wait           6666370
  1                                      <- packet_write_wait           6705383

	    <re-enter dispatch_run(), wait for reply>
  1                                        -> dispatch_run           6720321
  1                                         | dispatch_run:entry           6720321
	    <kbd-int info reply arrives>
  1                                          -> packet_read_seqnr           6722072
  1                                            -> packet_write_wait           6724104
  1                                            <- packet_write_wait           6730510
  1                                            -> packet_read_poll_seqnr           6731721
  1                                            <- packet_read_poll_seqnr           6734729
  1  -> packet_process_incoming                         6760386
  1  <- packet_process_incoming                         6770437
  1  -> packet_read_poll_seqnr                          6772402
  1  <- packet_read_poll_seqnr                          6872951
  1  <- packet_read_seqnr                               6879365

	    <process reply, convert to PAM response>
  1  -> packet_get_int                                  6881555
  1  <- packet_get_int                                  6887511
  1    -> packet_get_string                             6916314
  1    <- packet_get_string                             6928744
  1    -> packet_remaining                              6935389
  1    <- packet_remaining                              6939064

	    <reply was processed -- return from dispatch_run() to
	    conversation function>
  1  <- dispatch_run                                    6940502

	    <conversation function returns to PAM module>
  1    <- __pam_get_authtok                             7035803

	    <pam_authenticate() finishes>
  1  <- pam_authenticate                                7605627
  1        -> finish_userauth_do_pam                    8821420

	    <not shown: calls to other PAM functions>
  1        <- finish_userauth_do_pam                   10510750

	    <clear callbacks for kbd-int>
  1          -> dispatch_set                           10547432
  1          <- dispatch_set                           10548814
  1        <- auth2_pam                                10550165

	    <finish up>
  1        -> userauth_finish                          10556711
  1          -> userauth_check_partial_failure          10558469
  1          <- userauth_check_partial_failure          10560198
  1          -> auth_log                               10562387
  1            -> userauth_check_partial_failure          10563212
  1            <- userauth_check_partial_failure          10563714
  1            -> get_remote_ipaddr                    10565341
  1            <- get_remote_ipaddr                    10567068
  1            -> get_remote_port                      10568399
  1            <- get_remote_port                      10586765
  1            -> log                                  10588052
  1              -> do_log                             10588591
  1              <- log                                10608479
  1            <- auth_log                             10609878
  1            -> dispatch_set                         10610566
  1            <- dispatch_set                         10611042
  1            -> packet_start                         10612593
  1            <- packet_start                         10622025
  1            -> packet_send                          10623533
  1            <- packet_send                          10674599
  1            -> packet_write_wait                    10676102
  1              -> packet_write_poll                  10679960
  1              <- packet_write_poll                  10702504
  1              -> packet_have_data_to_write          10703694
  1              <- packet_have_data_to_write          10705721
  1            <- packet_write_wait                    10707897
  1          <- userauth_finish                        10709301

	    <exit outer even loop>
  1        <- dispatch_run                             10713892
  1      <- do_authentication2                         63914715



Nico
-- 



From dwmw2 at infradead.org  Thu Jun 23 21:30:45 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Jun 2005 12:30:45 +0100
Subject: ControlPersist.
Message-ID: <1119526245.22181.255.camel@hades.cambridge.redhat.com>

This is a better approach to persistent control masters than my previous
attempt. Instead of forking before we make the connection, do so only
when the original session has closed -- much like the code for '~&'
backgrounding already does. 

My earlier patch for 'ControlPath none' still applies and is required, btw.

--- openssh/clientloop.c~	2005-06-17 03:59:35.000000000 +0100
+++ openssh/clientloop.c	2005-06-23 11:05:11.000000000 +0100
@@ -1271,8 +1271,28 @@ static void
 client_channel_closed(int id, void *arg)
 {
 	channel_cancel_cleanup(id);
-	session_closed = 1;
 	leave_raw_mode();
+	if (options.control_persist && options.control_path != NULL && control_fd != -1) {
+		int pid = fork();
+
+		if (pid < 0) {
+			error("fork: %.100s", strerror(errno));
+			/* Just exit */
+			session_closed = 1;
+			return;
+		}
+		if (pid != 0) {
+			/* We are the parent. Exit, leaving the child to continue serving */
+			exit(exit_status);
+		}
+		session_ident = -1;
+		/* We _must_ lose our controlling tty, else subsequent control_client
+		   invocations from the same tty will cause us to get -EIO when reading
+		   from the tty */
+		setsid();
+		return;
+	}
+	session_closed = 1;
 }
 
 /*
--- openssh/readconf.c~	2005-06-16 04:19:42.000000000 +0100
+++ openssh/readconf.c	2005-06-23 11:05:11.000000000 +0100
@@ -106,7 +106,7 @@ typedef enum {
 	oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout,
 	oAddressFamily, oGssAuthentication, oGssDelegateCreds,
 	oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
-	oSendEnv, oControlPath, oControlMaster, oHashKnownHosts,
+	oSendEnv, oControlPath, oControlMaster, oControlPersist, oHashKnownHosts,
 	oDeprecated, oUnsupported
 } OpCodes;
 
@@ -197,6 +197,7 @@ static struct {
 	{ "sendenv", oSendEnv },
 	{ "controlpath", oControlPath },
 	{ "controlmaster", oControlMaster },
+	{ "controlpersist", oControlPersist },
 	{ "hashknownhosts", oHashKnownHosts },
 	{ NULL, oBadOption }
 };
@@ -818,6 +819,10 @@ parse_int:
 			*intptr = value;
 		break;
 
+	case oControlPersist:
+		intptr = &options->control_persist;
+		goto parse_flag;
+
 	case oHashKnownHosts:
 		intptr = &options->hash_known_hosts;
 		goto parse_flag;
--- openssh/readconf.h~	2005-06-16 04:19:42.000000000 +0100
+++ openssh/readconf.h	2005-06-23 11:02:01.000000000 +0100
@@ -112,6 +112,7 @@ typedef struct {
 
 	char	*control_path;
 	int	control_master;
+	int	control_persist;
 
 	int	hash_known_hosts;
 }       Options;


-- 
dwmw2



From dwmw2 at infradead.org  Thu Jun 23 22:17:24 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Jun 2005 13:17:24 +0100
Subject: %h,%p,%u expansion for ControlPath
In-Reply-To: <42B0F21B.2090405@mindrot.org>
References: <1118566763.4823.97.camel@localhost.localdomain>
	<42AD4B5E.9020300@mindrot.org>
	<1118655140.2840.19.camel@localhost.localdomain>
	<42B0F21B.2090405@mindrot.org>
Message-ID: <1119529044.22181.261.camel@hades.cambridge.redhat.com>

On Thu, 2005-06-16 at 13:29 +1000, Damien Miller wrote:
> > OK, I've checked out the OpenBSD version and I see it now. In that
> > version it looks like '%p' is going to expand to '0' when the default
> > port is used, instead of to '22' as it should.
> 
> Yes, I noticed that too - i'll fix it shortly.

Still looks unfixed to me -- or has that just not propagated to the
portable tree yet?

--- openssh/readconf.c~	2005-06-23 12:20:15.000000000 +0100
+++ openssh/readconf.c	2005-06-23 13:06:59.000000000 +0100
@@ -1025,8 +1025,13 @@ fill_default_options(Options * options)
 		options->tcp_keep_alive = 1;
 	if (options->compression_level == -1)
 		options->compression_level = 6;
-	if (options->port == -1)
-		options->port = 0;	/* Filled in ssh_connect. */
+	if (options->port == -1) {
+		struct servent *sp = getservbyname(SSH_SERVICE_NAME, "tcp");
+		if (sp)
+			options->port = ntohs(sp->s_port);
+		else
+			options->port = SSH_DEFAULT_PORT;
+	}
 	if (options->address_family == -1)
 		options->address_family = AF_UNSPEC;
 	if (options->connection_attempts == -1)
--- openssh/sshconnect.c~	2005-06-17 03:59:35.000000000 +0100
+++ openssh/sshconnect.c	2005-06-23 13:06:59.000000000 +0100
@@ -289,18 +289,9 @@ ssh_connect(const char *host, struct soc
 	int sock = -1, attempt;
 	char ntop[NI_MAXHOST], strport[NI_MAXSERV];
 	struct addrinfo hints, *ai, *aitop;
-	struct servent *sp;
 
 	debug2("ssh_connect: needpriv %d", needpriv);
 
-	/* Get default port if port has not been set. */
-	if (port == 0) {
-		sp = getservbyname(SSH_SERVICE_NAME, "tcp");
-		if (sp)
-			port = ntohs(sp->s_port);
-		else
-			port = SSH_DEFAULT_PORT;
-	}
 	/* If a proxy command is given, connect using it. */
 	if (proxy_command != NULL)
 		return ssh_proxy_connect(host, port, proxy_command);



-- 
dwmw2



From misc at dstoecker.de  Wed Jun 22 17:59:59 2005
From: misc at dstoecker.de (Dirk Stoecker)
Date: Wed, 22 Jun 2005 09:59:59 +0200 (CEST)
Subject: known_hosts file and server keys
Message-ID: <Pine.LNX.4.61.0506220954470.4979@dirkwork.site>

Hello,

for some time now I wonder about the way the known_hosts file contains the 
server keys. Let's look at a part of my known_hosts file:

shell.sf.net,66.35.250.208 ssh-dss AAAAB3NzaC1kc3MAAACBA...
shell.sourceforge.net ssh-dss AAAAB3NzaC1kc3MAAACBA...

As you can see, there are two entries, which describe the same host. When 
the file is empty and I do each connect after another, I always get the 
question
"The authenticity of host 'foo (bar)' can't be established."

This is even true for alias names which I can create on my local system.

Suggestion:
a) Join all equal hosts in one line.
b) When a new name is entered, which matches the IP of one of the old
   server certificates bring a different warning, which tells something
   like
   "Host foo unknown, but seems to be bar1, bar2, ... Is this correct?
   Possibly make a switch to skip this message and set it true always.
c) When the IP does not match any of the knwon ones, but the server
   certificate does (server with different IP's and different names)
   do a question like:
   "Host foo unknwon, but certificate is equal to bar1, bar2, ..."

The changed messages would help to increase understanding. When connecting 
a second or third time to a server and get asked everytime that the 
certificate is not known (because you used another alias), then you tend
to answer yes all the time.

The joined lines in the known_hosts file would make maintaining such files 
easier.

Ciao
-- 
 ____  _ _  ____  _ _    _ _  ____
|    |  |  |    |  | \  / |  |    | the cool Gremlin from Bischofswerda
|  __   |   ____|  |  \/  |  |    | WWW: http://www.dstoecker.de/
|    |  |  |       |      |  |    | PGP key available on www page.
|____| _|_ |____| _|_    _|_ |____| I hope AMIGA never stops making fun!



From darryl at netbauds.net  Fri Jun 24 02:14:25 2005
From: darryl at netbauds.net (Darryl L. Miles)
Date: Thu, 23 Jun 2005 17:14:25 +0100
Subject: Rate Limit Unauthenticated connections ?
Message-ID: <42BADFE1.8000203@netbauds.net>


I am seeing a recent increase in SSH harvesting attempts and brute 
forcing in the log of my system.


I'm interested in opening up some discussion around what OpenSSH can do 
itself to counter measure against:

* DoS attack where too many unauthenticated connections are open.  I'm 
not interested in stopping the professional saboteur but the casual 
script kiddie (to use IRC terms) from downloading the latest SSH 
harvesting program and running it from their limited internet connection.

* The reason why OpenSSH should actively have internal support (or call 
on the assistance where possible of other installed apps like tcpd) is 
that the SSH protocol is universally installed in thats it is simply not 
possible to put all my SSH servers behind a firewall or intrusion 
detection system since I also wish to provide the same protection of SSH 
service to my firewall too (which is also a Unix box running SSH).

* Any proposal in counter measures must administer themselves.



A simple algorithm:

* Restriction of maximum unauthenticated connections in the process of 
authenticating from the same IP address, like a scoreboard file ?  This 
is fast and simple to implement.  The action is to drop the connection 
(maybe with a last blert message before shutdown if the protocol allows 
that).  The whole scoreboard is reset to zero at SSH startup.

* Once the connection has successfully authenticated its score is taken 
off the score board.

* Ability to set the maximum connection level in the sshd_config.

* Ability to provide inclusion or exclusion IPv4/IPv6 prefixes subject 
to scoreboard in the sshd_config.  Enterprise users can disable the 
mechanism for their internal/trusted network.



A more complex algorithm:

* Temporary (time based) locking restrictions, this is based on actual 
login failure information, where each failed attempt racks up counter.  
Then over a set level counter measures are enabled.

* Counter decay cycle based on last failed attempt time and the counter 
value.

* The same configuration options possible here too as simple algorithm, 
IP address inclusion/exclusion.

* Possible counter measure can be configured in sshd_config.

* Counter measure 1: close the connection

* Counter measure 2 (where I'm trying to go with it all): if we have a 
history of too many failed logins then throw the dice.  If the dice say 
no, then let the IP try to login but even if he gives us a real and 
correct password we still dont let him in.  The probability of the die 
saying no increases with the failed login count.  This situation MUST be 
logged clearly.  If this was not found to cause any hardship to 
legitimate users and was considered safe enough to become the default 
SSH configuration then it would have the  far more important social 
effect of just stopping the script kiddies from even bothering to brute 
force SSH.  I do not know what the parameter levels should be set to so 
am really asking the community if as a whole its possible to achieve a 
social deterrent by technical means to this problem.  Which is a far 
better counter measure in itself.


Does what I propose simply move the problem somewhere else ?

Your feedback and slating are both welcome.

-- 
Darryl L. Miles




From fcusack at fcusack.com  Wed Jun 22 18:22:53 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Wed, 22 Jun 2005 01:22:53 -0700
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <42B8B58A.1090309@zip.com.au>
References: <42B83859.60400@o2.pl> <09C14BC7DD2045FED65AAAA2@manatee.local>
	<42B89A2F.1090108@zip.com.au> <A0AAC4F8008E0C0866CEADA0@manatee.local>
	<42B8A42A.9030609@zip.com.au>
	<4528BA1AB1C50B0BA15984CC@manatee.local> <42B8B58A.1090309@zip.com.au>
Message-ID: <424440D93DC020989B83072A@manatee.local>

On June 22, 2005 10:49:14 AM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
> Frank Cusack wrote:
> [about hacking SSHv1 TIS auth for multiple challenges]
>> Actually, what I did was to allow any number of challenge messages.
>> So a failure message is indeed a failure.  I collected all the prompts
>> in the conversation function and sent them one at a time as individual
>> challenges to the client.
>
> I don't think that's guaranteed to work with a compliant SSHv1 client.

You're right, it won't.

> If they're going to have to modify clients they may as well deploy a v2 client which can support
> it properly.

Oops, I overlooked the [stated] problem of deploying new clients.

I guess your suggestion of sending failures might work, even though (as you say) it is ugly.

Frank



From fcusack at fcusack.com  Wed Jun 22 09:07:29 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Tue, 21 Jun 2005 16:07:29 -0700
Subject: problem with pam_converse with openssh protocol version 1
In-Reply-To: <42B89A2F.1090108@zip.com.au>
References: <42B83859.60400@o2.pl> <09C14BC7DD2045FED65AAAA2@manatee.local>
	<42B89A2F.1090108@zip.com.au>
Message-ID: <A0AAC4F8008E0C0866CEADA0@manatee.local>

On June 22, 2005 8:52:31 AM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
> Frank Cusack wrote:
>> On June 21, 2005 5:55:05 PM +0200 Marcin Mogielnicki <mar_mog at o2.pl> wrote:
>
>> In v1, you'd have to use TIS authentication. You have to make sure
>> your client doesn't echo the password, though. (I think all modern
>> clients are conservative and don't echo.) You might end up having to
>> make some small sshd changes to make this work.
>
> That's what was being attempted first but it failing.
>
> Note that in this particular PAM configuration there are 2 calls to the conversation function,
> once for PIN and once for password,.  When that fails, it's falling back to plain password
> authentication (you can prevent that by disabling PasswordAuthentication in sshd_config since
> it's probably not going to work with that PAM config anyway).
>
> My read of the original SSH1 protocol spec is that there is only one challenge/response pair
> permitted by the protocol.  For the TIS response, it says:

Ah.  I must have made some client-side code changes to make this work, then.
(In my original response I already said some sshd changes might be necessary.)
They're rather easy.

Frank



From fcusack at fcusack.com  Fri Jun 24 12:01:34 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Thu, 23 Jun 2005 19:01:34 -0700
Subject: openssh vs pam (was: Possible security flaw in OpenSSH and/or
	pam_krb5)
In-Reply-To: <42B8AE89.3090004@zip.com.au>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org> <C34C72118F1117F167F8E789@manatee.local>
	<42B8AE89.3090004@zip.com.au>
Message-ID: <E8474836FF90D3D50C8059EE@manatee.local>

Darren (et al.),

Thanks for taking so much time here!  I wish I had more time to devote to it.

On June 22, 2005 10:19:21 AM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
> Let me preface this with some things I think we can agree on:
>
> 1) sshd's PAM interface isn't perfect.
>
> 2) PAM itself isn't perfect either.
>
> I'd like to think sshd's PAM interface is improving.  We've certainly been working to that end.
> There is still room for improvement, no question.  (If you look at the open sshd PAM bugs you
> will see that some of them have been raised by me.)

Agreed up to here.

> It's never going to be perfect.  Given the SSHv1 and v2 protocol specs and PAM as it stands I
> don't think it's possible.

Disagree.  It is quite possible for ssh v2 to work properly with PAM.  I have it working.
Sun has it working.

> Now some of my opinions on PAM from working with it in the context of sshd.  (I'm not going to
> justify them although I will if people wish):
>
> 3) PAM's blocking callback conversation interface makes using it from sshd harder than it has to
> be.  Similarly functional authentication systems with reentrant interfaces can be used with much
> less code (like an order of magnitude less).

Agreed.

> 4) Several other of its characteristics make PAM as a whole harder for sshd to use.

OK.  (Don't know if I agree, but I'll give you this one.)

> 5) The differences between PAM implementations (and in some cases bugs in them) make it harder
> for sshd to work with all of them.

Sigh.  Yes.

> 6) The multiple-messages part of the PAM conversation protocol (ie allowing more than one message
> per call to the conversation function) is more complex than necessary and this has been a source
> of bugs.

A big no here.

This is a great example of both not understanding PAM and not wanting to.  One, you're wrong,
two, you can't imagine that the PAM interface might be the way it is for a reason, rather you
insist that it's broken and refuse to accommodate it.

Multiple messages are required because a) authentication exchanges are not limited to single
request/reply type of messages, and b) clients cannot derive any semantic meaning from
server-generated messages.

Gobbledygook, I know, but we need only look at password expiry, something you are quite
familiar, dare I say, expert, in for a concrete example.

pam_authenticate():
  info_request:  0: [enter password], type prompt
  info_response: 0: 1234
pam_acct_mgmt(): PAM_NEW_AUTHTOK_REQD
pam_chauthtok():
  info_request:  0: [your password has expired], type message
                 1: [old password], type prompt
                 2: [new password], type prompt
                 3: [verify], type prompt
  info_response: ...

1) Look at how difficult it is to do this (in ssh) without PAM, then get back to me
   about how PAM is broken.
2) Openssh tends to assume a CLI client, and even then handles this exchange incorrectly.
3) With a GUI client, openssh is especially broken here (multiple dialogs instead of
   one dialog).
4) This is a simple example.

I'm picking on password expiry because it is probably the most common issue, also since
that is/was one of your focuses (foci?) I figure you can appreciate the problem.  But
the same problem exists purely in the pam_authenticate() phase.

I threw in the comment about semantic meaning to head off any arguments that the client
might possibly understand that this is a password expiry and somehow coalesce messages.
The server can communicate in any language, not just ASCII english.  The client cannot
be expected to understand what is going on, nor should it.  Nor are multiple message
exchanges limited to password expiry.  So, PAM clients need to handle the general case.

Now, previously, in one sense I did overstate the case when I said "it's easy".  The
issue just described is a subtle one, and is probably not even understood by many of the
current PAM stack implementers and maintainers.  Even the authors of PAM don't describe
this in the PAM specification, and in fact they get a few things wrong!  (viz, they
claim kerberos and smartcard support, which isn't possible strictly within the PAM
framework as specified.)  OTOH, I give an explicit example of the need for multiple
messages in a single exchange in the kbdint draft, so this shouldn't be some new
or novel requirement for ssh implementers.  (I will say, though, that I took heat from
some WG folks for including such examples, but I insist on keeping them for what may now
be obvious reasons.)

So, sure, understanding the PAM API isn't exactly "easy", but it's certainly not "hard".
>From an implementation perspective, it IS easy though.  Perhaps not palatable, but still
easy.

You can either use a nested event loop, as Nico shows, or read incoming data from an
internal queue rather than the kernel packet buffer, as I have done (and I'm sure
I've submitted patches for).  Getting new ssh messages from a managed queue instead
of from the kernel read() interface allows you to "putback" messages, thus you can
escape the conversation function without nesting the event loop.  I didn't actually
implement a queue, I just buffered one message and added a hack to go back one
message, because the pam conversation is the only place it was necessary, so a general
purpose interface seemed unnecessarily complex.

The Sun patches are readily available.  Mine are not, and I'm sorry but I don't have
time to generate them, but it's easy enough to implement from scratch.

> Frank Cusack wrote:
>> On June 17, 2005 3:49:11 PM +1000 Damien Miller <djm at mindrot.org> wrote:
> [...]
>> But it does not follow the API correctly.  Isn't correctness a priority
>> for the openssh folks?  It's not just the conversation function handling
>> that's broken in openssh.
>
> Would you please describe this (or provide a pointer to what you're referring to)?

TEXT_INFO and ERROR_MSG buffering is broken (see password expiry example above for
one specific case).

pam_start() with "NOUSER" is broken (described verbosely on the list in the past).

pam_getenvlist() is broken (you already know this).

I think there's something specifically wrong with privsep and PAM but I'll be damned
if I can think of it now.  (I've never used privsep because it was historically
broken for PAM, nowadays some issues are fixed but there's no privsep value for me.)

>> Anyway, I withdraw my comment as I see (now that I examine recent
>> sources) that PAM support is steadily improving. Documenting threads
>> as an ugly hack is one of those nice improvements, IMHO. Why you
>> added it in the first place is beyond my understanding.
>
> It was in the FreeBSD code on which the current PAM code is based, and since then it's been the
> only general solution to modules that rely on pam_set_data/pam_get_data (in the main
> distribution, anyway).

OK, add that pam_set_data() and pam_get_data() is broken.  Although, I don't get it since
these should work.  Maybe the problem is that you fork a child (in addition to the privsep
fork) to do PAM; that's broken unless you start PAM in the forked child.  Just guessing;
I'm not familiar with the current implementation.  I remember when it was added though,
and I felt that the previous implementation was superior (for reasons that I've now
forgotten).

Frank



From djm at mindrot.org  Fri Jun 24 15:47:26 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 24 Jun 2005 15:47:26 +1000
Subject: Rate Limit Unauthenticated connections ?
In-Reply-To: <42BADFE1.8000203@netbauds.net>
References: <42BADFE1.8000203@netbauds.net>
Message-ID: <42BB9E6E.4010203@mindrot.org>

Darryl L. Miles wrote:
> I am seeing a recent increase in SSH harvesting attempts and brute 
> forcing in the log of my system.

Please look at the archives for past discussion on this, and also at
sshd_config's MaxStartups directive (which probably does what you want
already).

-d



From darryl at netbauds.net  Sat Jun 25 03:22:50 2005
From: darryl at netbauds.net (Darryl L. Miles)
Date: Fri, 24 Jun 2005 18:22:50 +0100
Subject: Rate Limit Unauthenticated connections ?
In-Reply-To: <42BB9E6E.4010203@mindrot.org>
References: <42BADFE1.8000203@netbauds.net> <42BB9E6E.4010203@mindrot.org>
Message-ID: <42BC416A.1070300@netbauds.net>

Damien Miller wrote:

> Darryl L. Miles wrote:
>
>> I am seeing a recent increase in SSH harvesting attempts and brute 
>> forcing in the log of my system.
>
> Please look at the archives for past discussion on this, and also at
> sshd_config's MaxStartups directive (which probably does what you want
> already).


This option is great and necessary but has a different purpose.  It 
serves to stop an attacker from bringing down the host by way of DoS.  
It does nothing to assist legitimate users from using the service when 
its under trivial attack, it does nothing to deter the attacker from 
using that method of harvesting crackable hosts in the first place.

MaxStartups - Hard ceiling limit (for all users alike, to protect the host)

Personally I run SSH on two ports, from two instances on many of my 
hosts.  All critical use of SSH (backups, data-tunneling) takes place on 
this alternative port number.  On many hosts this alternative port 
number also has a firewall rule in place (iptables) that returns 
Connection Refused for unknown IPs, so its not DoSable.  This two port 
approach has also helped during SSH server upgrades of remote hosts.

I want to protect legitimate users but obstruct abusive users and at the 
same time completely destroy ssh login brute forcing as a useful method 
of gaining entry by returning false negatives during authentication.

MaxStartups allows a single abusive user from dial-up to obstruct 
legitimate users.


I shall as you suggest check out the previous discussions on the list to 
see what was aired.   A starting URL or subject would be handy.

Thanks

Darryl



From email at steve-meier.de  Sat Jun 25 20:59:16 2005
From: email at steve-meier.de (Steve Meier)
Date: Sat, 25 Jun 2005 12:59:16 +0200
Subject: OpenSSH Feature Requests
Message-ID: <1119697156.21449.54.camel@localhost>

Dear OpenSSH-Team,

after looking through your website (Bug Reports, FAQ, etc.) this is the
best email-address I could find for submitting a feature idea/request.

Please excuse if this is not the correct address and kindly forward.

When working with OpenSSH in larger networks I often had to use
different keys for different hosts (with or without passphrases) to gain
proper access. The major difference was between keys used for "real
users" and keys used for scriting (scp, rsync).

I would therefore like to propose a "server related key" feature.

Let me explain this feature on a small example:

I have two host
1.) backup.mynet.local
2.) devel.mynet.local

For the first host I have a keyset with no password for automated use by
rsync to backup files.
For the second host I have a keyset with a strong password to login
manually.

With the "server related key" I would save the according keys as
~/.ssh/id_dsa.backup.mynet.local
~/.ssh/id_dsa.pub.backup.mynet.local
~/.ssh/id_dsa.devel.mynet.local
~/.ssh/id_dsa.pub.devel.mynet.local

The ssh client would then first try the key including the hostname
provided before trying the default key (id_dsa).

Of course I know, that you can specify the key to use on the command
line but I think that this would more convenient then to have everybody
write their own wrappers to accomplish this.

Let me know what you think about this and thanks for reading :-)

Best regards,
Steve



From djm at mindrot.org  Sat Jun 25 21:49:59 2005
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jun 2005 21:49:59 +1000
Subject: OpenSSH Feature Requests
In-Reply-To: <1119697156.21449.54.camel@localhost>
References: <1119697156.21449.54.camel@localhost>
Message-ID: <42BD44E7.70405@mindrot.org>

Steve Meier wrote:
> When working with OpenSSH in larger networks I often had to use
> different keys for different hosts (with or without passphrases) to gain
> proper access. The major difference was between keys used for "real

You can specify these in .ssh/config using the IdentityFile option. ssh
will try keys in the order in which they are listed there (even if the
keys reside in the agent). E.g.

Host foo
	IdentityFile ~/.ssh/id_rsa_foo

Host bar
	IdentityFile ~/.ssh/id_rsa_bar

It might be worthwhile to add %h expansion IdentityFile so you could
template this in the config file, see:

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

-d



From dtucker at zip.com.au  Sat Jun 25 23:38:46 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 25 Jun 2005 23:38:46 +1000
Subject: openssh vs pam
In-Reply-To: <E8474836FF90D3D50C8059EE@manatee.local>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
	<C34C72118F1117F167F8E789@manatee.local>
	<42B8AE89.3090004@zip.com.au>
	<E8474836FF90D3D50C8059EE@manatee.local>
Message-ID: <42BD5E66.4080500@zip.com.au>

Frank Cusack wrote:
 > Darren (et al.),
 > Thanks for taking so much time here!  I wish I had more time to
 > devote to it.

That's OK.

I had a goal about a year ago to stop sshd's PAM interface being a 
source of complaint.  It's maybe halfway there, but to be honest I'm 
running out of enthusiasm for the job.

I tried to like PAM, really I did, but every time I started to like it 
just a little bit it would shaft me in one of the many ways I enumerated 
earlier.

Anyway, on with the show...

[about sshd's PAM interface]
[...]
>> It's never going to be perfect. Given the SSHv1 and v2 protocol
>> specs and PAM as it stands I don't think it's possible.
> 
> Disagree. It is quite possible for ssh v2 to work properly with PAM.
> I have it working. Sun has it working.

I specified SSHv1 and SSHv2, but sticking to just SSHv2, could you 
please explain how you do the following within the existing SSHv2 
protocol and PAM interfaces:

a) Perform the "none" auth test specified by SSHv2 via PAM without 
causing either unnecessary delays or spurious failure messages from PAM 
in the logs.  Currently sshd doesn't try PAM for "none" if 
PermitEmptyPasswords=no but strictly speaking that's a hack.

b) Perform vanilla "password" USERAUTH_REQUEST via PAM in a way that 
works for the general case.

Now a) you can configure around, and I imagine your response to b) will 
be "use kbdint, that's what it's for!" :-)

My point is there are parts of the spec that you can't implement 
perfectly via PAM, given the current protocol and PAM implementations. 
It's not that OpenSSH can't improve (I've already said that it can).

Originally I had another thing in the list, which I now think is 
possible but tricky, and wanted to know if you implemented it and if so, 
how:

c) Handle the case where pam_acct_mgmt() wants to interact after a 
public-key authentication.

>> 6) The multiple-messages part of the PAM conversation protocol (ie 
>> allowing more than one message per call to the conversation
>> function) is more complex than necessary and this has been a source
>> of bugs.
> 
> A big no here.
[...]
> Multiple messages are required because a) authentication exchanges
> are not limited to single request/reply type of messages, and b)
> clients cannot derive any semantic meaning from server-generated
> messages.

It's not that there are multiple messages in the authentication 
exchange, but that there's multiple authentication messages *per API 
call*, in a format that can be silently gotten wrong in a way that's a 
security problem (and, historically, has been).

Exhibit A: LinuxPAM got it wrong and nobody noticed until it was to late 
to fix it.  It's still broken to this day.

(For anyone following the thread that doesn't realise: the PAM spec 
(XSSO, pp 89) specifies that the message parameter passed to the 
conversation function is "a pointer to an array", but LinuxPAM treats it 
as an array of pointers.  These are equivalent for the case where 
there's exactly one message but will blow up horribly for more.)

Exhibit B: des at freebsd, who wrote one of the PAM implementations 
(OpenPAM) from scratch, got it wrong in the FreeBSD sshd PAM code:
http://mail-index.netbsd.org/current-users/2003/10/02/0005.html

So the authors of two of the three PAM implementations I'm aware of have 
got it wrong at one time or another, in at least two cases undetected 
long enough to make it to released code.

(and I'm not trying to pick on either des or amorgan here, but with a 
history of misuse of the interface even by folks that know it well, you 
have to ask if maybe the interface is at fault here)

A separate but related issue to the fact this complex interface is 
supplied via a callback.  It's the callback that's the primary problem 
in sshd's case, though.  Give me a reentrant equivalent to the 
conversation function and I can live with the rest.  It could probably 
even fit withing the existing API with a few new flags.

> This is a great example of both not understanding PAM and not wanting
> to. One, you're wrong, two, you can't imagine that the PAM interface
> might be the way it is for a reason, rather you insist that it's
> broken and refuse to accommodate it.

You seem to be confusing understanding it with having a high opinion of 
it.  Do you believe that PAM is so fundamentally clean, elegant and 
beautiful that if someone understood it they could not fail to like it?

As to why it is the way it is: it seemed me to be that way to make it 
easier to do X-based dialogs (the callback is a strong hint in that 
direction).  Whatever the reason, it doesn't alter the fact that it's a 
pain for me to deal with.

[...]
> Gobbledygook, I know, but we need only look at password expiry, 
> something you are quite familiar, dare I say, expert, in for a
> concrete example.
> 
> pam_authenticate():
>  info_request:  0: [enter password], type prompt
>  info_response: 0: 1234
> pam_acct_mgmt(): PAM_NEW_AUTHTOK_REQD
> pam_chauthtok():
>  info_request:  0: [your password has expired], type message
>                 1: [old password], type prompt
>                 2: [new password], type prompt
>                 3: [verify], type prompt
>  info_response: ...
> 
> 1) Look at how difficult it is to do this (in ssh) without PAM, then get 
> back to me about how PAM is broken.

That's more a function of whether or not the underlying OS has any kind 
of change-password API at all.  I could implement an eqivalent on AIX 
using chpass(), for example.

> 2) Openssh tends to assume a CLI client, and even then handles this 
> exchange incorrectly.

If you're referring to the accumulation of messages then see below.  If 
you're referring to something else then please elaborate.

> 3) With a GUI client, openssh is especially broken here (multiple 
> dialogs instead of one dialog).

OK, now that might be easily fixable (for Protocol 2, anyway).  I'll 
look at that when I have time.

> 4) This is a simple example.
> 
> I'm picking on password expiry because it is probably the most common
> issue, also since that is/was one of your focuses (foci?) I figure
> you can appreciate the problem. But the same problem exists purely in
> the pam_authenticate() phase.
> 
> I threw in the comment about semantic meaning to head off any
> arguments that the client might possibly understand that this is a
> password expiry and somehow coalesce messages. The server can
> communicate in any language, not just ASCII english. The client
> cannot be expected to understand what is going on, nor should it. Nor
> are multiple message exchanges limited to password expiry. So, PAM
> clients need to handle the general case.
> 
> Now, previously, in one sense I did overstate the case when I said
> "it's easy". The issue just described is a subtle one, and is
> probably not even understood by many of the current PAM stack
> implementers and maintainers. Even the authors of PAM don't describe 
> this in the PAM specification, and in fact they get a few things
> wrong! (viz, they claim kerberos and smartcard support, which isn't
> possible strictly within the PAM framework as specified.)

The authors of the standard and some of the implementations don't 
understand the interface?  Does this not indicate that the interface is 
too complex and thus prone to misuse?

> OTOH, I
> give an explicit example of the need for multiple messages in a
> single exchange in the kbdint draft, so this shouldn't be some new or
> novel requirement for ssh implementers. (I will say, though, that I 
> took heat from some WG folks for including such examples, but I
> insist on keeping them for what may now be obvious reasons.)
> 
> So, sure, understanding the PAM API isn't exactly "easy", but it's 
> certainly not "hard".
> 
> From an implementation perspective, it IS easy though.

Yet witness the continuing lack of "easy" patches demonstrating it.

> Perhaps not palatable, but still easy.

The only ways the conversation (callback) interface can be used by sshd 
are all ugly.  To me that means it's a broken API for this purpose 
regardless of the historic reasons for it.  But then, I tend to reject 
arguments for current brokenness based on historic brokenness :-)

> You can either use a nested event loop, as Nico shows, or read
> incoming data from an internal queue rather than the kernel packet
> buffer, as I have done (and I'm sure I've submitted patches for).
> Getting new ssh messages from a managed queue instead of from the
> kernel read() interface allows you to "putback" messages, thus you
> can escape the conversation function without nesting the event loop.
> I didn't actually implement a queue, I just buffered one message and
> added a hack to go back one message, because the pam conversation is
> the only place it was necessary, so a general purpose interface
> seemed unnecessarily complex.

The closest thing I could find to that description is this:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101073742305758
which seems to be only for abandoning a keyboard-interactive attempt, it 
doesn't seem to help the general case of handling conversation callbacks.

> The Sun patches are readily available.

Really?  Where?  If you're referring to OpenSolaris the when I looked, 
ssh was one of the components that is not part of the release.  (Nico: 
any particular reason for this, and is it expected to change?)

> Mine are not, and I'm sorry but I don't have time to generate them,
> but it's easy enough to implement from scratch.
[...]
> TEXT_INFO and ERROR_MSG buffering is broken (see password expiry
> example above for one specific case).

If you're referring to sshpam_query(), then remember that it is used for 
TIS C/R in SSHv1 as well as kbdint.

For the SSHv2/kbdint case I guess it could pass the messages through to 
the client directly rather than accumulating which should be an 
improvement, right?

For the other cases (eg password, or where sshpam_store_conv is used to 
accumulate messages from, eg, pam_acct_mgmt) there's no way to send the 
messages to the client before the session starts in SSHv1 (other than a 
disconnect message), and in SSHv2 sshd already copies the messages to 
the privsep slave and sends them the the client as SSH2 userauth banner 
messages.

> pam_start() with "NOUSER" is broken (described verbosely on the list in 
> the past).

Sure, but sshd hasn't done that for over two years.  See auth1.c rev 
1.84 and auth2.c rev 1.116.

> pam_getenvlist() is broken (you already know this).

sshd's use of pam_getenvlist is in the same category as threads: a 
necessary evil right now but to be removed when possible.

> I think there's something specifically wrong with privsep and PAM but
> I'll be damned if I can think of it now. (I've never used privsep
> because it was historically broken for PAM, nowadays some issues are
> fixed but there's no privsep value for me.)

I'll stipulate that privsep makes dealing with PAM harder.

That said, I thought I had a nice way of dealing with one of the 
outstanding problems relating to privsep and ran afoul of one of the 
many differences between PAM implementations (which is a regular occurance):
http://bugzilla.mindrot.org/show_bug.cgi?id=926

[...]
> OK, add that pam_set_data() and pam_get_data() is broken. Although, I
> don't get it since these should work.   Maybe the problem is that you
> fork a child (in addition to the privsep fork) to do PAM; that's
> broken unless you start PAM in the forked child.

The pam_set_data() thing is a symptom of the separate process thing.

This is an example of my "other of its characteristics make PAM as a 
whole harder" statement earlier: the combination of the blocking API 
calls combined with the fact that pam_set_data does such a good job of 
hiding the data is harder to deal with that either alone.

> Just guessing; I'm
> not familiar with the current implementation. I remember when it was
> added though, and I felt that the previous implementation was
> superior (for reasons that I've now forgotten).

You also said this about the new code:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104627748509519

"The code as a whole /is/ far cleaner than what exists currently, so 
that is a big plus."

Anyway, I do appreciate your time (and Nico's) even when I'm not 
agreeing with you.

-- 
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 Nicolas.Williams at sun.com  Sun Jun 26 07:20:29 2005
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sat, 25 Jun 2005 16:20:29 -0500
Subject: openssh vs pam
In-Reply-To: <42BD5E66.4080500@zip.com.au>
References: <20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>
	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org>
	<C34C72118F1117F167F8E789@manatee.local>
	<42B8AE89.3090004@zip.com.au>
	<E8474836FF90D3D50C8059EE@manatee.local>
	<42BD5E66.4080500@zip.com.au>
Message-ID: <20050625212029.GJ16670@binky.Central.Sun.COM>

On Sat, Jun 25, 2005 at 11:38:46PM +1000, Darren Tucker wrote:
> >Disagree. It is quite possible for ssh v2 to work properly with PAM.
> >I have it working. Sun has it working.
> 
> I specified SSHv1 and SSHv2, but sticking to just SSHv2, could you 
> please explain how you do the following within the existing SSHv2 
> protocol and PAM interfaces:
> 
> a) Perform the "none" auth test specified by SSHv2 via PAM without 
> causing either unnecessary delays or spurious failure messages from PAM 
> in the logs.  Currently sshd doesn't try PAM for "none" if 
> PermitEmptyPasswords=no but strictly speaking that's a hack.

Solaris 10's sshd uses a different PAM handle and PAM_SERVICE for each
SSHv2 userauth.  This allows sysadmins to configure the "sshd-none"
service to only have, say, pam_deny.so.1 in its stack.  This lets you
avoid the delays and spurious failure log entries (and failure counting
towards account locking).

> b) Perform vanilla "password" USERAUTH_REQUEST via PAM in a way that 
> works for the general case.

General case?  As in when a PAM module wants to prompt for something
other than PAM_AUTHTOK?  Can't be done.  That's why we have
"keyboard-interactive" userauth.

> Now a) you can configure around, and I imagine your response to b) will 
> be "use kbdint, that's what it's for!" :-)

Indeed.  Every client I've used in recent memory supports it.

> My point is there are parts of the spec that you can't implement 
> perfectly via PAM, given the current protocol and PAM implementations. 

"keyboard-interactive" works fine.

Conversations during other userauths are more troublesome; as long as
they are text info messages they can just be saved for display later on
a tty channel.  Not that I can think of any PAM modules that converse
prompts during pam_open_session(), or pam_setcred(), or pam_acct_mgmt().

Password aging should trigger userauth failure, for userauths other than
"keyboard-interactive," with kbd-int being the only userauth that can
continue.

> It's not that OpenSSH can't improve (I've already said that it can).

Again, "keyboad-interactive" interfaces with PAM just fine.

> Originally I had another thing in the list, which I now think is 
> possible but tricky, and wanted to know if you implemented it and if so, 
> how:
> 
> c) Handle the case where pam_acct_mgmt() wants to interact after a 
> public-key authentication.

See above.  Prompts can't be handled in that case.  But, by using
"sshd-pubkey" as the PAM_SERVICE you give the sysadmin a chance to
configure PAM so that this doesn't happen during pubkey userauth.


> A separate but related issue to the fact this complex interface is 
> supplied via a callback.  It's the callback that's the primary problem 
> in sshd's case, though.  Give me a reentrant equivalent to the 
> conversation function and I can live with the rest.  It could probably 
> even fit withing the existing API with a few new flags.

So, shall I repeat myself and point out a good way to handle this?

> >This is a great example of both not understanding PAM and not wanting
> >to. One, you're wrong, two, you can't imagine that the PAM interface
> >might be the way it is for a reason, rather you insist that it's
> >broken and refuse to accommodate it.
> 
> You seem to be confusing understanding it with having a high opinion of 
> it.  Do you believe that PAM is so fundamentally clean, elegant and 
> beautiful that if someone understood it they could not fail to like it?

Does it matter?  Do you want to support it or don't you?  What you
dislike about it the most cannot be fixed.

> >The Sun patches are readily available.
> 
> Really?  Where?  If you're referring to OpenSolaris the when I looked, 
> ssh was one of the components that is not part of the release.  (Nico: 
> any particular reason for this, and is it expected to change?)

Ssh will be there soonish.  That it isn't there now is kinda my fault;
details next week :)

> For the SSHv2/kbdint case I guess it could pass the messages through to 
> the client directly rather than accumulating which should be an 
> improvement, right?

Yes.

> >I think there's something specifically wrong with privsep and PAM but
> >I'll be damned if I can think of it now. (I've never used privsep
> >because it was historically broken for PAM, nowadays some issues are
> >fixed but there's no privsep value for me.)
> 
> I'll stipulate that privsep makes dealing with PAM harder.

I don't think it does -- the monitor has to nest its event loop, and
this is no harder in the monitor than in the non-privsep case.

> Anyway, I do appreciate your time (and Nico's) even when I'm not 
> agreeing with you.

Cool.

Nico
-- 



From djm at mindrot.org  Sun Jun 26 08:44:13 2005
From: djm at mindrot.org (Damien Miller)
Date: Sun, 26 Jun 2005 08:44:13 +1000
Subject: openssh vs pam
In-Reply-To: <42BD5E66.4080500@zip.com.au>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>	<20050610013615.GT659@binky.Central.Sun.COM>	<4094F650162B7F75391A073E@manatee.local>	<42B26457.1020308@mindrot.org>	<C34C72118F1117F167F8E789@manatee.local>	<42B8AE89.3090004@zip.com.au>	<E8474836FF90D3D50C8059EE@manatee.local>
	<42BD5E66.4080500@zip.com.au>
Message-ID: <42BDDE3D.8090609@mindrot.org>

Darren Tucker wrote:
>>The Sun patches are readily available.
> 
> Really?  Where?  If you're referring to OpenSolaris the when I looked, 
> ssh was one of the components that is not part of the release.  (Nico: 
> any particular reason for this, and is it expected to change?)

A bit of history here: when Sun first forked OpenSSH to make Sun_SSH,
they offered us back their patchset, but steadfastly refused to state
or clarify the license that it was under, thereby making direct
cooperation impossible. Quite a pity really...

-d



From dtucker at zip.com.au  Sun Jun 26 09:38:11 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 26 Jun 2005 09:38:11 +1000
Subject: openssh vs pam
In-Reply-To: <42BDDE3D.8090609@mindrot.org>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>	<20050610013615.GT659@binky.Central.Sun.COM>	<4094F650162B7F75391A073E@manatee.local>	<42B26457.1020308@mindrot.org>	<C34C72118F1117F167F8E789@manatee.local>	<42B8AE89.3090004@zip.com.au>	<E8474836FF90D3D50C8059EE@manatee.local>	<42BD5E66.4080500@zip.com.au>
	<42BDDE3D.8090609@mindrot.org>
Message-ID: <42BDEAE3.50503@zip.com.au>

Damien Miller wrote:
> A bit of history here: when Sun first forked OpenSSH to make Sun_SSH,
> they offered us back their patchset, but steadfastly refused to state
> or clarify the license that it was under, thereby making direct
> cooperation impossible. Quite a pity really...

Some slightly more recent history: where code has been supplied by Sun 
(or anyone else for that matter) under a compatible license (ISC, 2 or 3 
term BSD) and there is a need for it, we are happy to use it.

For example, BSM audit support has been in the last couple of OpenSSH 
releases (audit-bsm.c), based on code supplied by Sun under a 2-term BSD 
license.

Now whether or not anyone actually uses it is another question.  I've 
seen no comments about it post-release.  Hopefully no news is good news...

-- 
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 esp5 at mdssdev05.comp.pge.com  Tue Jun 28 06:57:57 2005
From: esp5 at mdssdev05.comp.pge.com (Ed Peschko)
Date: Mon, 27 Jun 2005 13:57:57 -0700
Subject: openssh for pocket PC
Message-ID: <20050627205757.GA13459@mdssdev05.comp.pge.com>

hey all,

I was looking for an openssh version that ran on Pocket PC - I need to be able to connect
to a server from a Pocket PC in a secure fashion - and I was hoping that it was available
in a form that would be usable by CF .Net.

Any ideas on where I could get something like this? Is there a port of OpenSSH to 
pocketPC?

Ed



From stuge-openssh-unix-dev at cdy.org  Tue Jun 28 08:50:04 2005
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 28 Jun 2005 00:50:04 +0200
Subject: openssh for pocket PC
In-Reply-To: <20050627205757.GA13459@mdssdev05.comp.pge.com>
References: <20050627205757.GA13459@mdssdev05.comp.pge.com>
Message-ID: <20050627225004.GA7843@foo.birdnet.se>

On Mon, Jun 27, 2005 at 01:57:57PM -0700, Ed Peschko wrote:
> Is there a port of OpenSSH to pocketPC?

No, but I've seen a PuTTY port. Use google.


//Peter



From drogers at ncmir.ucsd.edu  Wed Jun 29 03:42:19 2005
From: drogers at ncmir.ucsd.edu (Daniel Rogers)
Date: Tue, 28 Jun 2005 10:42:19 -0700
Subject: more flexible AllowUsers/DenyUsers syntax
Message-ID: <FD82EB1E-45B5-4A0A-97A9-4556E9373E91@ncmir.ucsd.edu>

Hi,

I hope this is the right place for a feature request.
I'd like to have more flexible AllowUsers/DenyUsers synax.

I am in a situation, where I have machines connected to three  
networks (a private, high speed, a public, and a private vpn) and I'd  
like to enable root logins only on the private networks.  Currently I  
see no way of doing this, because there is no way to specify a class  
that doesn't match.  Something like:
AllowUsers ~root@*
AllowUsers root at 10.0.2.0/24
AllowUsers root at 172.31.0.0/24
Would be really really friggin' nice.
Even nicer would be to have acl statements with sophistication akin  
to squids configuration.

Futher, it would be really nice to be able to understand when openssh  
treats a pattern match like an ip or network and when openssh treats  
a pattern match like a host or domain name.

Are any features like this planned?  Is what I am asking for reasonable?

--
Daniel
-------------- 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/20050628/d4dd1a54/attachment.bin 

From mstevens at cmu.edu  Wed Jun 29 03:59:19 2005
From: mstevens at cmu.edu (Michael A Stevens)
Date: Tue, 28 Jun 2005 13:59:19 -0400 (EDT)
Subject: more flexible AllowUsers/DenyUsers syntax
In-Reply-To: <FD82EB1E-45B5-4A0A-97A9-4556E9373E91@ncmir.ucsd.edu>
References: <FD82EB1E-45B5-4A0A-97A9-4556E9373E91@ncmir.ucsd.edu>
Message-ID: <Pine.GSO.4.60-041.0506281356300.1424@unix2.andrew.cmu.edu>

The easiest way to do this would be to have three sshd's running, but 
listening on different IP addresses. You could give each its own config 
file with the -f option and have only one of them allow root logins.


Mike

On Tue, 28 Jun 2005, Daniel Rogers wrote:

> Hi,
>
> I hope this is the right place for a feature request.
> I'd like to have more flexible AllowUsers/DenyUsers synax.
>
> I am in a situation, where I have machines connected to three networks (a 
> private, high speed, a public, and a private vpn) and I'd like to enable root 
> logins only on the private networks.  Currently I see no way of doing this, 
> because there is no way to specify a class that doesn't match.  Something 
> like:
> AllowUsers ~root@*
> AllowUsers root at 10.0.2.0/24
> AllowUsers root at 172.31.0.0/24
> Would be really really friggin' nice.
> Even nicer would be to have acl statements with sophistication akin to squids 
> configuration.
>
> Futher, it would be really nice to be able to understand when openssh treats 
> a pattern match like an ip or network and when openssh treats a pattern match 
> like a host or domain name.
>
> Are any features like this planned?  Is what I am asking for reasonable?
>
> --
> Daniel
>



From dtucker at zip.com.au  Wed Jun 29 10:43:25 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 29 Jun 2005 10:43:25 +1000
Subject: more flexible AllowUsers/DenyUsers syntax
In-Reply-To: <FD82EB1E-45B5-4A0A-97A9-4556E9373E91@ncmir.ucsd.edu>
References: <FD82EB1E-45B5-4A0A-97A9-4556E9373E91@ncmir.ucsd.edu>
Message-ID: <42C1EEAD.1010608@zip.com.au>

Daniel Rogers wrote:
> I hope this is the right place for a feature request.

It is.

> I'd like to have more flexible AllowUsers/DenyUsers synax.
> 
> I am in a situation, where I have machines connected to three  networks 
> (a private, high speed, a public, and a private vpn) and I'd  like to 
> enable root logins only on the private networks.  Currently I  see no 
> way of doing this, because there is no way to specify a class  that 
> doesn't match.  Something like:
> AllowUsers ~root@*
> AllowUsers root at 10.0.2.0/24
> AllowUsers root at 172.31.0.0/24

You can already negate a "subpattern" with "!" (hmm, this fact appears 
to be missing from the man page), so you can probably do what you want 
with something like (untested):

DenyUsers root@!10.0.2.*
DenyUsers root@!172.31.0.*

There are several components that could benefit from understanding CIDR 
notation, see http://bugzilla.mindrot.org/show_bug.cgi?id=976

> Would be really really friggin' nice.
> Even nicer would be to have acl statements with sophistication akin  to 
> squids configuration.
> 
> Futher, it would be really nice to be able to understand when openssh  
> treats a pattern match like an ip or network and when openssh treats  a 
> pattern match like a host or domain name.

Right now it always checks both, IP address first.

> Are any features like this planned?  Is what I am asking for reasonable?

Yes but not a high priority.

I'd like to see it incorporated into RequiredAuthentications (see 
http://bugzilla.mindrot.org/show_bug.cgi?id=983 and previous discussion 
on openssh-unix-dev) as an optional extension, ie

RequiredAuthentications method[,method] [user at host]

eg

RequiredAuthentications password,rsa,hostbased	root at 10.0.0.0/8
RequiredAuthentications rsa	root@*

PermitRootLogin would then become an alias for "RequiredAuthentications 
[methods] root".

(The CIDR thing would probably be a simple project if someone wanted to 
code it.)

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



From logsnaath at gmail.com  Wed Jun 29 15:41:34 2005
From: logsnaath at gmail.com (Logu)
Date: Wed, 29 Jun 2005 11:11:34 +0530
Subject: inconsistent ut_id values in the utmp(x) file
Message-ID: <004401c57c6d$411100c0$140110ac@loguco>

Hi,

In loginrec.c,  the 'line' string utility function line_abbrevname() returns 
the last four characters of the terminal file path.  This returned value is 
assigned to the utmp structure member ut_id[4].

Some sample ut_id values are shown below:

/dev/pts/1   will have ut_id set to ts/1
/dev/pts/2   will have ut_id set to ts/2
.
.
/dev/pts/9   will have ut_id set to ts/9
/dev/pts/10 will have ut_id set to s/10
                                                 ^^^^
/dev/pts/11 will have ut_id set to s/11
                                                  ^^^^

Just by way of a contrast,  the corresponding rlogin (or telnet) records 
would show just the number part of the terminal device file path.  This 
inconsistency creates issues for HP-UX users, particularly in environments 
where specific tools are being used to read and analyze utmp information.

I am wondering what the reason was for choosing that approach. Wouldn't it 
have been better to assign just the number part to ut_id?

thanks
-logu 



From senthilkumar_sen at hotpop.com  Wed Jun 29 18:43:06 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Wed, 29 Jun 2005 14:13:06 +0530
Subject: sshd deletes the GSSAPI ticket on exit
Message-ID: <63fe01c57c86$a4e0e070$220110ac@sekco>

Hello All,

I have run into a situation where a user exiting from a 
PAM_KERBEROS-authenticated session runs the risk of deleting a 
kinit-generated credentials file that was already sitting on the server.  I 
will explain the problem in detail, but let me begin with my question.  It 
has a specific reference to PAM_KERBEROS, but it can also be a general 
question.

If a user (ssh) session was such that it skipped pam_authenticate() during 
login (probably because it used a Key-based auth method),  then is it all 
right for sshd to correspondingly skip pam_setcred() during session exit? 
What will happen if we take that approach?

As I understand it,  pam_setcred() is called as part of the authentication 
phase as well as part of the session exit phase.  When called during 
authentication,  pam_setcred() sets the KRB5CCNAME environment variable to 
the credentials file name,  and when called during session exit, 
pam_setcred() is called to delete that credentials file.

The problem:
Consider a server with pam.conf set up for PAM_KERBEROS all the way 
(authentication, acct management, session management, the works).   This is 
done, presumably, because most all users connecting to the sshd instance on 
this machine are to be PAM_KERBEROS authenticated, with some exceptions.

1.  And now a telnet user U1 comes along, logs into the server machine, and 
does a kinit (on the server).  There may be very good reasons for doing so, 
and I will not go into those reasons here.  We do not control those reasons 
anyway. As a result of the kinit,  a ticket file /tmp/krb5cc_U1uid is 
created on the server (where U1uid is the UID of this telnet user).

2.  Now user U1 logs in via SSH into this machine, this time with a 
PublicKey.  This will cause sshd to skip pam_authenticate(),  and therefore 
also skip the pam_setcred() call.  As a result, the KRB5CCNAME variable will 
remain unset.  No harm so far.

3.  Now, this user (U1, with PublicKey auth) exits. Since session management 
is also set to PAM_KERBEROS, sshd will call pam_setcred(), but this time to 
delete the credentials file.  Note that the credentials file was never 
created, but sshd still calls pam_setcred().  And even that should not have 
been a problem.  But it is, for a few PAM_KERBEROS implementations.

Typical pam_setcred() implementations for the deletion of credentials work 
in the following way:

* Either directly or indirectly, they call the  standard kerberos5 function 
krb5_cc_default_name(), to first determine the credentials file name.  This 
function does not know whether it is being called from PAM_KERBEROS or from 
a GSSAPI environment.  It first checks to see if KRB5CCNAME is set.  If set, 
it returns the file name that the variable is set to.  If not set, then this 
function assumes it is being called from a regular GSSAPI environment, and 
returns a filename that matches what a kinit would have generated. So for 
instance, for user U1, it will return a file name /tmp/krb5cc_U1uid.

* Remove the file whose name is returned by krb5_cc_default_name() !!

Not good.

Of course, the file generated by PAM_KERBEROS itself has a different naming 
convention, intentionally so, in order not to cause overlap between 
kinit-generated ticket filenames and PAM_KERBEROS generated file names. So 
if authentication had indeed been done via PAM, then sshd would have called 
pam_setcred () to establish the credentials file.  Generally speaking, 
pam_setcred() would create the credentials file, and then make the 
appropriate kerberos function calls to set the  name of the cred cache file 
and the KRB5CCNAME environment variable.  It is important to note here that 
the file name generated by pam_setcred() for the credentials file is 
different from that of a kinit-generated file for the same user.

However, a combination of the following events makes a valid server-resident 
kinit-generated ticket disappear:
A kinit-generated ticket exists on the server for user U1 (how it got there 
is not relevant.  Let us assume it is there)
pam.conf is set to have authentication and session management both done via 
PAM_KERBEROS
User U1 logs in via SSH, using a non-PAM method (e.g. Public Key), thereby 
causing KRB5CCNAME to be not set.
User U1 exits
When the user (U1) 's session terminates, the kinit-generated ticket will be 
deleted.


Fixing the problem:
I see at least two ways of fixing the problem.  The first of course, would 
be for PAM_KERBEROS to first check if KRB5CCNAME is set.  If not, it should 
probably just skip the file delete.  That would be ideal for us.

Alternatively, we could do something in sshd.  If pam_setcred() was not 
called during authentication, then don't call pam_setcred() during session 
exit either.

Could there be any problems with this approach?

thanks
Senthil 




From dtucker at zip.com.au  Wed Jun 29 19:12:08 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 29 Jun 2005 19:12:08 +1000
Subject: sshd deletes the GSSAPI ticket on exit
In-Reply-To: <63fe01c57c86$a4e0e070$220110ac@sekco>
References: <63fe01c57c86$a4e0e070$220110ac@sekco>
Message-ID: <42C265E8.5040307@zip.com.au>

Senthil Kumar wrote:
[...]
> If a user (ssh) session was such that it skipped pam_authenticate() during 
> login (probably because it used a Key-based auth method),  then is it all 
> right for sshd to correspondingly skip pam_setcred() during session exit? 

No. setcred should be called before and after.

> What will happen if we take that approach?

Depends on what everybody's modules do.  Could be anything.

> As I understand it,  pam_setcred() is called as part of the authentication 
> phase as well as part of the session exit phase.  When called during 
> authentication,  pam_setcred() sets the KRB5CCNAME environment variable to 
> the credentials file name,  and when called during session exit, 
> pam_setcred() is called to delete that credentials file.

setcred isn't called as part of authentication, at least not directly. 
It's called as part of session establishment (with privsep it's called 
quite early, though).

[snip description]

> Alternatively, we could do something in sshd.  If pam_setcred() was not 
> called during authentication, then don't call pam_setcred() during session 
> exit either.

pam_setcred() is (should be) always called during session initiation.

> Could there be any problems with this approach?

Yes.  You're assuming that kerberos is the only user of pam_setcred and 
that's not necessarily so.

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



From dtucker at zip.com.au  Wed Jun 29 19:18:08 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 29 Jun 2005 19:18:08 +1000
Subject: sshd deletes the GSSAPI ticket on exit
In-Reply-To: <63fe01c57c86$a4e0e070$220110ac@sekco>
References: <63fe01c57c86$a4e0e070$220110ac@sekco>
Message-ID: <42C26750.2010606@zip.com.au>

Senthil Kumar wrote:
[...]
> 2.  Now user U1 logs in via SSH into this machine, this time with a 
> PublicKey.  This will cause sshd to skip pam_authenticate(),  and therefore 
> also skip the pam_setcred() call.  As a result, the KRB5CCNAME variable will 
> remain unset.  No harm so far.

I think what's happening here is that pam_setcred *is* being called, but 
since there's no kerberos ticket (because of the pubkey auth) no 
credential cache is created.

Sounds like the underlying problem is that you PAM module is zapping 
credential caches that it didn't create.  I don't see how sshd can work 
around this without breaking something else.

Standard disclaimer: I don't use Kerberos...

-- 
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 sxw at inf.ed.ac.uk  Wed Jun 29 19:23:31 2005
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Wed, 29 Jun 2005 10:23:31 +0100 (BST)
Subject: sshd deletes the GSSAPI ticket on exit
In-Reply-To: <63fe01c57c86$a4e0e070$220110ac@sekco>
Message-ID: <Pine.LNX.4.44.0506291012530.30073-100000@hadrian.inf.ed.ac.uk>

On Wed, 29 Jun 2005, Senthil Kumar wrote:

> I have run into a situation where a user exiting from a 
> PAM_KERBEROS-authenticated session runs the risk of deleting a 
> kinit-generated credentials file that was already sitting on the server. 

There seem to be a number of misconceptions in your email.

Firstly, what you're describing has nothing at all to do with GSSAPI, or 
the support for GSSAPI in OpenSSH. GSSAPI is an API which provides a means 
of performing authentication options - it doesn't provide ticket formats 
or storage - both are properties of the underlying authentication 
mechanism.

Secondly, whilst OpenSSH does call pam_setcred(DELETE_CRED) on session 
exit, it only does so if an earlier call successfully established 
credentials. The danger is that many PAM modules also call their setcred() 
function when close_session() is called.

Finally, if a PAM module deletes a ccache that it didn't create, then that 
module is broken. Certainly, if it works in the way that you describe 
and trusts the KRB5CCNAME varibale, its fundamentaly flawed.

So, it's not really OpenSSH's problem. I'd suggest speaking to the vendor
of your PAM module.

Cheers,

Simon.




From logsnaath at gmail.com  Wed Jun 29 23:52:01 2005
From: logsnaath at gmail.com (Logu)
Date: Wed, 29 Jun 2005 19:22:01 +0530
Subject: inconsistent ut_id values in the utmp(x) file
Message-ID: <008301c57cb1$cb971920$140110ac@loguco>

Hi,

In loginrec.c,  the 'line' string utility function line_abbrevname() returns 
the last four characters of the terminal file path.  This returned value is 
assigned to the utmp structure member ut_id[4].

Some sample ut_id values are shown below:

/dev/pts/1   will have ut_id set to ts/1
/dev/pts/2   will have ut_id set to ts/2
.
.
/dev/pts/9   will have ut_id set to ts/9
/dev/pts/10 will have ut_id set to s/10
                                                 ^^^^
/dev/pts/11 will have ut_id set to s/11
                                                  ^^^^

Just by way of a contrast,  the corresponding rlogin (or telnet) records 
would show just the number part of the terminal device file path.  This 
inconsistency creates issues for HP-UX users, particularly in environments 
where specific tools are being used to read and analyze utmp information.

I am wondering what the reason was for choosing that approach. Wouldn't it 
have been better to assign just the number part to ut_id?

thanks
-logu



From uhap023 at alpha9.rhul.ac.uk  Thu Jun 30 07:10:53 2005
From: uhap023 at alpha9.rhul.ac.uk (Tom Crane)
Date: Wed, 29 Jun 2005 21:10:53 +0000 (GMT)
Subject: sshd_config parameter to deal with multiple failed logins
Message-ID: <05062920105250@alpha9.rhul.ac.uk>

Does anyone know if there are plans to give sshd the ability to block
further login attempts from a particular IP address/block after a set
number of failed logins?  I'm sure lots of other admins have seen their
system logs full of attempts by hackers probing with lists of sample
usernames.  I know there is a Python script which uses TCP wappers to
achieve this by editing /etc/hosts.{allow,deny}.  This seems a little
ugly.  Please could responders CC me since I'm not on the mailing list. 

Thanks
Tom Crane.



From rapier at psc.edu  Thu Jun 30 05:39:55 2005
From: rapier at psc.edu (Chris Rapier)
Date: Wed, 29 Jun 2005 15:39:55 -0400
Subject: CIphers and Channels
Message-ID: <42C2F90B.5040402@psc.edu>

In OpenSSH can you specify a different cipher for each channel? Is there 
any cross channel dependency with regards to the cipher? We're just 
looking at this in terms of using OpenSSH over SCTP.




From mstevens at cmu.edu  Thu Jun 30 05:48:38 2005
From: mstevens at cmu.edu (Michael A Stevens)
Date: Wed, 29 Jun 2005 15:48:38 -0400 (EDT)
Subject: CIphers and Channels
In-Reply-To: <42C2F90B.5040402@psc.edu>
References: <42C2F90B.5040402@psc.edu>
Message-ID: <Pine.LNX.4.60-041.0506291547490.5719@unix48.andrew.cmu.edu>

No ciphers are for the transport level, channels are one level above the 
transport.

Mike

On Wed, 29 Jun 2005, Chris Rapier wrote:

> In OpenSSH can you specify a different cipher for each channel? Is there
> any cross channel dependency with regards to the cipher? We're just
> looking at this in terms of using OpenSSH over SCTP.
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>



From senthilkumar_sen at hotpop.com  Thu Jun 30 17:35:47 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Thu, 30 Jun 2005 13:05:47 +0530
Subject: inconsistent ut_id values in the utmp(x) file
References: <008301c57cb1$cb971920$140110ac@loguco>
Message-ID: <65ee01c57d46$5aea1480$220110ac@sekco>

I think the inconsistency can be avoided by choosing only the number part of 
the terminal file path, something like below in line_abbrevname() of 
loginrec.c

* Always skip prefix if present */
        if (strncmp(src, "/dev/pts/", 9) == 0)
                src += 9;

and then logging only the number part residing in src.

But I also wonder the reason that makes OpenSSH to log terminal type too in 
ut_id[4]?

Thanks,
Senthil Kumar.


----- Original Message ----- 
From: "Logu" <logsnaath at gmail.com>
To: <openssh-unix-dev at mindrot.org>
Sent: Wednesday, June 29, 2005 7:22 PM
Subject: inconsistent ut_id values in the utmp(x) file


> Hi,
>
> In loginrec.c,  the 'line' string utility function line_abbrevname() 
> returns
> the last four characters of the terminal file path.  This returned value 
> is
> assigned to the utmp structure member ut_id[4].
>
> Some sample ut_id values are shown below:
>
> /dev/pts/1   will have ut_id set to ts/1
> /dev/pts/2   will have ut_id set to ts/2
> .
> .
> /dev/pts/9   will have ut_id set to ts/9
> /dev/pts/10 will have ut_id set to s/10
>                                                 ^^^^
> /dev/pts/11 will have ut_id set to s/11
>                                                  ^^^^
>
> Just by way of a contrast,  the corresponding rlogin (or telnet) records
> would show just the number part of the terminal device file path.  This
> inconsistency creates issues for HP-UX users, particularly in environments
> where specific tools are being used to read and analyze utmp information.
>
> I am wondering what the reason was for choosing that approach. Wouldn't it
> have been better to assign just the number part to ut_id?
>
> thanks
> -logu
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 




From djm at mindrot.org  Thu Jun 30 19:19:56 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 30 Jun 2005 19:19:56 +1000
Subject: inconsistent ut_id values in the utmp(x) file
In-Reply-To: <65ee01c57d46$5aea1480$220110ac@sekco>
References: <008301c57cb1$cb971920$140110ac@loguco>
	<65ee01c57d46$5aea1480$220110ac@sekco>
Message-ID: <42C3B93C.4050207@mindrot.org>

Senthil Kumar wrote:
> I think the inconsistency can be avoided by choosing only the number part of 
> the terminal file path, something like below in line_abbrevname() of 
> loginrec.c
> 
> * Always skip prefix if present */
>         if (strncmp(src, "/dev/pts/", 9) == 0)
>                 src += 9;
> 
> and then logging only the number part residing in src.
> 
> But I also wonder the reason that makes OpenSSH to log terminal type too in 
> ut_id[4]?

If you are asking "why do we log (part of) the pty name in ut_id in
addition to ut_line?" then the answer is that some platforms expect it
(e.g. Linux).

If instead you are asking "why do we log the 'pts' part and not just the
numeric line number?", I suppose the answer is because we aren't aware
of any documented rules on the relevant platform.

Generally speaking, the [uwb]tmp/lastlog code is probably the most
agonisingly platform-dependant part of OpenSSH (yes, worse than PAM) and
there are lots of poorly-documented subtleties, like pty name mangling
above. Therefore it is most likely to be the buggy on platforms we don't
have regular access to.

I.e. this code really depends on users testing it and reporting bugs on
their platforms.

-d