From rapier at psc.edu  Wed Aug  1 02:41:54 2007
From: rapier at psc.edu (Chris Rapier)
Date: Tue, 31 Jul 2007 12:41:54 -0400
Subject: VPN in Windows?
In-Reply-To: <1F37F03F67DB4B5FBFA6B2495B9E0D7F@dabney.caltech.edu>
References: <1F37F03F67DB4B5FBFA6B2495B9E0D7F@dabney.caltech.edu>
Message-ID: <46AF6652.9030808@psc.edu>

> Is there any chance that the VPN feature of the client can be ported to 
> Windows (such that even non-Cygwin Windows programs would be able to use it) 
> any time in the near future? It seems like many people would find this 
> feature useful on Windows. If not, is there any other way to accomplish the 
> OpenSSH VPN thing with other free tools?

You can kind of fake it using PuTTY with the judicious use of tunnels. 
http://souptonuts.sourceforge.net/sshtips.htm

From Jefferson.Ogata at noaa.gov  Wed Aug  1 07:42:52 2007
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Tue, 31 Jul 2007 21:42:52 +0000
Subject: chroot'd SFTP
In-Reply-To: <6ac10b630707310500q6a1fee9cj45e77ac8f95d47f8@mail.gmail.com>
References: <46AB9379.7030904@minstrel.org.uk>
	<6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com>
	<Pine.BSO.4.64.0707302045510.28046@fuyu.mindrot.org>
	<46ADC6EE.40503@minstrel.org.uk>
	<6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com>
	<Pine.BSO.4.64.0707310757550.26933@fuyu.mindrot.org>
	<6ac10b630707310500q6a1fee9cj45e77ac8f95d47f8@mail.gmail.com>
Message-ID: <46AFACDC.70108@noaa.gov>

On 2007-07-31 12:00, Richard Storm wrote:
> Thanks, I got now. Local/remote users with shell access can chroot in
> any dir they want. However, is this security problem, since after that
> privs are dropped and unix permissions are in effect...

Yes, generally, allowing users to chroot to a directory of their choice
is a very serious security problem.

If you can chroot to a directory you construct, you can get root privs
by fooling setuid programs using forged shared libraries or library
preloading, explicit reconfiguration (e.g. /etc/passwd, /etc/sudoers),
or various other tactics. Note that if you can construct a directory on
a filesystem that has existing setuid binaries, you can incorporate such
a binary into your chroot area using a hard link.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service

From rapier at psc.edu  Sat Aug  4 05:01:00 2007
From: rapier at psc.edu (Chris Rapier)
Date: Fri, 03 Aug 2007 15:01:00 -0400
Subject: Channel Patch
Message-ID: <46B37B6C.4040901@psc.edu>

I've updated the channel patch including some suggestions. The main 
difference is that I eliminated the channels[] array entirely (and the 
attendant code to create the array). I did not, however, include linked 
list pointers in the Channel struct. Mostly because its easier for me to 
work with at this time. I expect I'll do it in the next iteration though.

Removing the channels array does mean that channel_by_id must iterate 
through a linked list rather than doing an index lookup. I don't think 
this will have much impact on performance in the majority of cases. On 
the plus side, I think I can eliminate a lot of the NULL conditionals. I 
haven't yet though.

Anyway, if anyone is interested the patches are attached. Any comments, 
observations, or such not is greatly appreciated.

At this time this should still be viewed as development code. 
Preliminary tests indicated that there were no performance hits and 
there were some hints that in some situations it will provide a 
performance improvement.

Chris Rapier

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: channels.h.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070803/1628a9e3/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: channels.c.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070803/1628a9e3/attachment-0001.ksh 

From dot at dotat.at  Sat Aug  4 06:09:17 2007
From: dot at dotat.at (Tony Finch)
Date: Fri, 3 Aug 2007 21:09:17 +0100
Subject: race condition with ControlMaster=auto
Message-ID: <Pine.LNX.4.64.0708032101010.21965@hermes-1.csi.cam.ac.uk>

There is a race in the setup of the ControlMaster socket in auto mode, as
illustrated by the following command line:

ssh -oControlMaster=auto -oControlPath=sock localhost 'sleep 1; echo 1' &
ssh -oControlMaster=auto -oControlPath=sock localhost 'sleep 2; echo 2' &

Both of the commands will try to start up as a control client, find that
sock does not exist, and switch into control master mode. One will succeed
in creating the control master socket and the other will fail and bomb.

The attached patch eliminates this race by trying to create a control
master socket first, and falling back to control client mode if master
mode fails.

Tony.
-- 
f.a.n.finch  <dot at dotat.at>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
-------------- next part --------------
--- ssh.c~	Fri Jan  5 05:30:17 2007
+++ ssh.c	Fri Aug  3 19:21:18 2007
@@ -1045,18 +1045,19 @@
 	}
 }
 
-static void
-ssh_control_listener(void)
+static int
+ssh_control_listener(int test)
 {
 	struct sockaddr_un addr;
 	mode_t old_umask;
 	int addr_len;
 
 	if (options.control_path == NULL ||
-	    options.control_master == SSHCTL_MASTER_NO)
-		return;
+	    options.control_master == SSHCTL_MASTER_NO ||
+	    control_fd != -1)
+		return 1;
 
-	debug("setting up multiplex master socket");
+	debug("trying to set up multiplex master socket");
 
 	memset(&addr, '\0', sizeof(addr));
 	addr.sun_family = AF_UNIX;
@@ -1073,11 +1074,9 @@
 	old_umask = umask(0177);
 	if (bind(control_fd, (struct sockaddr *)&addr, addr_len) == -1) {
 		control_fd = -1;
-		if (errno == EINVAL || errno == EADDRINUSE)
-			fatal("ControlSocket %s already exists",
-			    options.control_path);
-		else
+		if (errno != EINVAL && errno != EADDRINUSE)
 			fatal("%s bind(): %s", __func__, strerror(errno));
+		return 0;
 	}
 	umask(old_umask);
 
@@ -1085,6 +1084,9 @@
 		fatal("%s listen(): %s", __func__, strerror(errno));
 
 	set_nonblock(control_fd);
+
+	debug("control master listening on %s", options.control_path);
+	return 1;
 }
 
 /* request pty/x11/agent/tcpfwd/shell for channel */
@@ -1201,7 +1203,9 @@
 
 	/* XXX should be pre-session */
 	ssh_init_forwarding();
-	ssh_control_listener();
+	if (!ssh_control_listener(0))
+		fatal("control master socket %s already exists",
+		    options.control_path);
 
 	if (!no_shell_flag || (datafellows & SSH_BUG_DUMMYCHAN))
 		id = ssh_session2_open();
@@ -1319,7 +1323,13 @@
 	switch (options.control_master) {
 	case SSHCTL_MASTER_AUTO:
 	case SSHCTL_MASTER_AUTO_ASK:
-		debug("auto-mux: Trying existing master");
+		/* see if we can create a control master socket
+		   to avoid a race between two auto clients */
+		if (mux_command == SSHMUX_COMMAND_OPEN &&
+		    ssh_control_listener(1))
+			return;
+		debug("trying to connect to control master socket %s",
+		    options.control_path);
 		/* FALLTHROUGH */
 	case SSHCTL_MASTER_NO:
 		break;
@@ -1452,6 +1462,8 @@
 	signal(SIGINT, control_client_sighandler);
 	signal(SIGTERM, control_client_sighandler);
 	signal(SIGWINCH, control_client_sigrelay);
+
+	debug("connected to control master; waiting for exit");
 
 	if (tty_flag)
 		enter_raw_mode();

From djm at mindrot.org  Sat Aug  4 11:22:48 2007
From: djm at mindrot.org (Damien Miller)
Date: Sat, 4 Aug 2007 11:22:48 +1000 (EST)
Subject: Channel Patch
In-Reply-To: <46B37B6C.4040901@psc.edu>
References: <46B37B6C.4040901@psc.edu>
Message-ID: <Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>


On Fri, 3 Aug 2007, Chris Rapier wrote:

> I've updated the channel patch including some suggestions. The main
> difference is that I eliminated the channels[] array entirely (and
> the attendant code to create the array). I did not, however, include
> linked list pointers in the Channel struct. Mostly because its easier
> for me to work with at this time. I expect I'll do it in the next
> iteration though.
>
> Removing the channels array does mean that channel_by_id must iterate
> through a linked list rather than doing an index lookup. I don't think
> this will have much impact on performance in the majority of cases. On
> the plus side, I think I can eliminate a lot of the NULL conditionals.
> I haven't yet though.
>
> Anyway, if anyone is interested the patches are attached. Any
> comments, observations, or such not is greatly appreciated.
>
> At this time this should still be viewed as development code.
> Preliminary tests indicated that there were no performance hits and
> there were some hints that in some situations it will provide a
> performance improvement.

Before you go any further with this diff, please understand that it 
almost no chance of being incorporated unless it follows the 
style of the existing code[1].

We also prefer to use the queue[2] macros instead of hand-rolled
linked list implementations, though I'm not sure that a linked list is
the right data structure (remember you need to support by-id lookups
too), whether you need to change the data structure at all or whether
traversing an array of a few dozen elements is worth optimising.

It seems you could avoid most of the channel array scans by simply
tracking the number of channels actually used and stopping the loop
after seeing that many open channels (this would work very well unless
the entries were fragmented across the array). If you wanted to be
tricky, you could add a precomputed skip step to the channels array that
would point to the next allocated channel, allowing the loop to skip
past unused channels.

-d

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9
[2] http://www.openbsd.org/cgi-bin/man.cgi?query=queue&sektion=3

From djm at mindrot.org  Sat Aug  4 11:26:26 2007
From: djm at mindrot.org (Damien Miller)
Date: Sat, 4 Aug 2007 11:26:26 +1000 (EST)
Subject: race condition with ControlMaster=auto
In-Reply-To: <Pine.LNX.4.64.0708032101010.21965@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0708032101010.21965@hermes-1.csi.cam.ac.uk>
Message-ID: <Pine.BSO.4.64.0708041123520.10393@fuyu.mindrot.org>

On Fri, 3 Aug 2007, Tony Finch wrote:

> There is a race in the setup of the ControlMaster socket in auto mode, as
> illustrated by the following command line:
> 
> ssh -oControlMaster=auto -oControlPath=sock localhost 'sleep 1; echo 1' &
> ssh -oControlMaster=auto -oControlPath=sock localhost 'sleep 2; echo 2' &
> 
> Both of the commands will try to start up as a control client, find that
> sock does not exist, and switch into control master mode. One will succeed
> in creating the control master socket and the other will fail and bomb.

Yes, this is annoying. The other approach to fixing it that I thought of
but didn't yet implement was to create the sockets with mkstemp (i.e.
with a random suffix) and try to rename them into place when ready. If
the rename fails then the ssh client can just turn off master mode,
unlink its temporarily named socket and act as a regular client.

> The attached patch eliminates this race by trying to create a control
> master socket first, and falling back to control client mode if master
> mode fails.

Please file a bug at http://bugzilla.mindrot.org with your patch.

-d

From dot at dotat.at  Sun Aug  5 04:12:50 2007
From: dot at dotat.at (Tony Finch)
Date: Sat, 4 Aug 2007 19:12:50 +0100
Subject: race condition with ControlMaster=auto
In-Reply-To: <Pine.BSO.4.64.0708041123520.10393@fuyu.mindrot.org>
References: <Pine.LNX.4.64.0708032101010.21965@hermes-1.csi.cam.ac.uk>
	<Pine.BSO.4.64.0708041123520.10393@fuyu.mindrot.org>
Message-ID: <Pine.LNX.4.64.0708041906140.3003@hermes-1.csi.cam.ac.uk>

On Sat, 4 Aug 2007, Damien Miller wrote:
>
> Yes, this is annoying. The other approach to fixing it that I thought of
> but didn't yet implement was to create the sockets with mkstemp (i.e.
> with a random suffix) and try to rename them into place when ready. If
> the rename fails then the ssh client can just turn off master mode,
> unlink its temporarily named socket and act as a regular client.

I don't think this is necessary, because the bind() already gives you
race-free socket creation. You could get the same effect by just ignoring
EADDRINUSE failures. My patch does this, but also fixes the ordering so
that if there's a race only one client will have to do a full login.

> Please file a bug at http://bugzilla.mindrot.org with your patch.

Will do.

Tony.
-- 
f.a.n.finch  <dot at dotat.at>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From dan at ns15.lightwave.net.ru  Mon Aug  6 21:28:45 2007
From: dan at ns15.lightwave.net.ru (Dan Yefimov)
Date: Mon, 6 Aug 2007 15:28:45 +0400 (MSD)
Subject: Channel Patch
In-Reply-To: <Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
Message-ID: <Pine.LNX.4.44.0708061517460.12378-100000@D00M.lightwave.net.ru>

On Sat, 4 Aug 2007, Damien Miller wrote:

> We also prefer to use the queue[2] macros instead of hand-rolled
> linked list implementations, though I'm not sure that a linked list is
> the right data structure (remember you need to support by-id lookups
> too), whether you need to change the data structure at all or whether
> traversing an array of a few dozen elements is worth optimising.
> 
By-id lookups can be facilitated with a hash table.

> It seems you could avoid most of the channel array scans by simply
> tracking the number of channels actually used and stopping the loop
> after seeing that many open channels (this would work very well unless
> the entries were fragmented across the array). If you wanted to be
> tricky, you could add a precomputed skip step to the channels array that
> would point to the next allocated channel, allowing the loop to skip
> past unused channels.
> 
The array of channels has undesireable effect of imposing a restriction on the 
number of channels which can be simultaneously open.
-- 

    Sincerely Your, Dan.


From dan at ns15.lightwave.net.ru  Mon Aug  6 23:14:07 2007
From: dan at ns15.lightwave.net.ru (Dan Yefimov)
Date: Mon, 6 Aug 2007 17:14:07 +0400 (MSD)
Subject: Channel Patch
In-Reply-To: <Pine.LNX.4.44.0708061517460.12378-100000@D00M.lightwave.net.ru>
Message-ID: <Pine.LNX.4.44.0708061711380.7419-100000@D00M.lightwave.net.ru>

On Mon, 6 Aug 2007, Dan Yefimov wrote:

> The array of channels has undesireable effect of imposing a restriction on the 
> number of channels which can be simultaneously open.
> 
My sincere apologies for that notice. After careful looking at the source I 
found that array of channel pointers is dynamically extended.
-- 

    Sincerely Your, Dan.


From rapier at psc.edu  Wed Aug  8 02:51:46 2007
From: rapier at psc.edu (Chris Rapier)
Date: Tue, 07 Aug 2007 12:51:46 -0400
Subject: Channel Patch
In-Reply-To: <Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
References: <46B37B6C.4040901@psc.edu>
	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
Message-ID: <46B8A322.7090103@psc.edu>

Damien Miller wrote:

> Before you go any further with this diff, please understand that it 
> almost no chance of being incorporated unless it follows the 
> style of the existing code[1].

That is understood. These aren't being put forward as actual patches for 
consideration for inclusion at this time. Its really just research at 
this point as I'm not sure it actually has any real merit to it in terms 
of performance. As such, I didn't want to develop this in a vacuum and 
wanted to get community insight on it.

Basically, in the course of other work I ran ssh/sshd against a profiler 
(oprofiler) and found that in some operations a lot of time was being 
spent in the channel_handling code. My hope was that by reducing the 
amount of time spent there more resources would be freed up for other 
operations.

> We also prefer to use the queue[2] macros instead of hand-rolled
> linked list implementations, though I'm not sure that a linked list is
> the right data structure (remember you need to support by-id lookups
> too), whether you need to change the data structure at all or whether
> traversing an array of a few dozen elements is worth optimising.

Which is, for the most part, the question I'm trying to answer with 
this. After some playing around with things I'm not sure if its that 
there is no merit to the idea of limiting the looping or if my code just 
sucks :)

> It seems you could avoid most of the channel array scans by simply
> tracking the number of channels actually used and stopping the loop
> after seeing that many open channels (this would work very well unless
> the entries were fragmented across the array).

Thats the problem that I was trying to avoid with the linked lists. From 
the code it seems that channels can be added to or removed from the 
channels array arbitrarily. In the first iteration of the patch I simply 
  compacted the array and broke the loop at the first null. This worked 
but it seemed to be somewhat limiting - I still needed all of the test 
statements and I had to make changes to the data in the channel struct - 
which is something I wanted to avoid doing. By moving to a linked list I 
was able to avoid that but I lost the ability to do an index lookup on 
the array (as you mentioned). I was able to addresses that but it does 
necessitate looping through the linked list. So I'm not sure how much a 
win it would be. Depends on how frequently the function is called. I'll 
look at the queue macros. Thank you for the pointers.

Actually, thinking a bit more about it I do think I'll try your 
suggestion. It won't help in every situation but I think it will in a 
significant percentage of them. In the remaining situations it shouldn't 
impose a penalty.

> If you wanted to be
> tricky, you could add a precomputed skip step to the channels array that
> would point to the next allocated channel, allowing the loop to skip
> past unused channels.

One thing I'm not is tricky. I always end up confusing myself. Mostly I 
just write this stuff as research projects in the hope that it interests 
someone else enough to actual code things properly :)

> -d
> 
> [1] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9
> [2] http://www.openbsd.org/cgi-bin/man.cgi?query=queue&sektion=3

From stuge-openssh-unix-dev at cdy.org  Wed Aug  8 04:33:48 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 7 Aug 2007 20:33:48 +0200
Subject: Channel Patch
In-Reply-To: <46B8A322.7090103@psc.edu>
References: <46B37B6C.4040901@psc.edu>
	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
	<46B8A322.7090103@psc.edu>
Message-ID: <20070807183348.24686.qmail@cdy.org>

On Tue, Aug 07, 2007 at 12:51:46PM -0400, Chris Rapier wrote:
> > If you wanted to be tricky, you could add a precomputed skip step
> > to the channels array that would point to the next allocated
> > channel, allowing the loop to skip past unused channels.
> 
> One thing I'm not is tricky. I always end up confusing myself.
> Mostly I  just write this stuff as research projects in the hope
> that it interests someone else enough to actual code things
> properly :)

The step optimization is really simple and still allows index
lookups. The step works just like a pointer in the linked list.

As long as individual channel entries do not need to be atomically
inserted or removed it'll work great!


//Peter

From rapier at psc.edu  Wed Aug  8 05:29:06 2007
From: rapier at psc.edu (Chris Rapier)
Date: Tue, 07 Aug 2007 15:29:06 -0400
Subject: Channel Patch
In-Reply-To: <20070807183348.24686.qmail@cdy.org>
References: <46B37B6C.4040901@psc.edu>	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>	<46B8A322.7090103@psc.edu>
	<20070807183348.24686.qmail@cdy.org>
Message-ID: <46B8C802.3050102@psc.edu>



Peter Stuge wrote:
> On Tue, Aug 07, 2007 at 12:51:46PM -0400, Chris Rapier wrote:
>>> If you wanted to be tricky, you could add a precomputed skip step
>>> to the channels array that would point to the next allocated
>>> channel, allowing the loop to skip past unused channels.
>> One thing I'm not is tricky. I always end up confusing myself.
>> Mostly I  just write this stuff as research projects in the hope
>> that it interests someone else enough to actual code things
>> properly :)
> 
> The step optimization is really simple and still allows index
> lookups. The step works just like a pointer in the linked list.
> 
> As long as individual channel entries do not need to be atomically
> inserted or removed it'll work great!

I'm going to betray my ignorance here and ask for a bit of 
clarification. This isn't like a skip list but basically just a data 
element that points to the next active channel. So instead of iterating 
through every element of the array I'd only go to active elements by 
doing something like

for (c = channels; c != NULL;  c = c->skip)
{}

When a channel is added or removed I would have to iterate through the 
entire array and update c->skip but that operation shouldn't happen all 
that often. Is this correct?

If so, this would preserve the index lookup and eliminate unnecessary 
looping, wouldn't it? In fact, its basically a linked list but 
superimposed on an array, right?

Chris

From stuge-openssh-unix-dev at cdy.org  Wed Aug  8 05:49:41 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 7 Aug 2007 21:49:41 +0200
Subject: Channel Patch
In-Reply-To: <46B8C802.3050102@psc.edu>
References: <46B37B6C.4040901@psc.edu>
	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
	<46B8A322.7090103@psc.edu> <20070807183348.24686.qmail@cdy.org>
	<46B8C802.3050102@psc.edu>
Message-ID: <20070807194941.4114.qmail@cdy.org>

On Tue, Aug 07, 2007 at 03:29:06PM -0400, Chris Rapier wrote:
> > The step optimization is really simple and still allows index
> > lookups. The step works just like a pointer in the linked list.
> 
> I'm going to betray my ignorance here and ask for a bit of
> clarification.

Sure!


> This isn't like a skip list but basically just a data element that
> points to the next active channel.

Well I interpreted it as a skip int that would be in the array.


> So instead of iterating through every element of the array I'd only
> go to active elements by doing something like
> 
> for (c = channels; c != NULL;  c = c->skip)
> {}

int i=0;
for(c=channels[i];c;i+=c->skip) {}


> When a channel is added or removed I would have to iterate through
> the entire array and update c->skip but that operation shouldn't
> happen all that often. Is this correct?

On add you need to find a free slot. How is not important. One way is
just iterating over the array from start until c->skip>1 and then
channels[i+1] will be free. Fill channels[i+1], then set
channels[i+1].skip=c->skip-1 and finally set c->skip=1.

Remove is cheaper, just do ++channels[i-1].skip;


> If so, this would preserve the index lookup and eliminate
> unnecessary looping, wouldn't it? In fact, its basically a
> linked list but superimposed on an array, right?

Yep. I envisioned using an index for skipping rather than a pointer
but the effect is exactly the same.


//Peter

From rapier at psc.edu  Wed Aug  8 06:08:28 2007
From: rapier at psc.edu (Chris Rapier)
Date: Tue, 07 Aug 2007 16:08:28 -0400
Subject: Channel Patch
In-Reply-To: <20070807194941.4114.qmail@cdy.org>
References: <46B37B6C.4040901@psc.edu>	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>	<46B8A322.7090103@psc.edu>
	<20070807183348.24686.qmail@cdy.org>	<46B8C802.3050102@psc.edu>
	<20070807194941.4114.qmail@cdy.org>
Message-ID: <46B8D13C.9040200@psc.edu>

Peter Stuge wrote:
> On Tue, Aug 07, 2007 at 03:29:06PM -0400, Chris Rapier wrote:
>>> The step optimization is really simple and still allows index
>>> lookups. The step works just like a pointer in the linked list.
>> I'm going to betray my ignorance here and ask for a bit of
>> clarification.
> 
> Sure!

Sometimes its tough having been a history major :)

>> This isn't like a skip list but basically just a data element that
>> points to the next active channel.
> 
> Well I interpreted it as a skip int that would be in the array.

Of course (slap forehead). I've been so focused on pointers lately 
*everything* looks like a pointer.

I'll give this a shot and see how it works out. At this point, to be 
completely honest, I don't expect it to make much of a difference. I've 
got some 10Gb machines set back to back that I'm going to try this with 
though. Even a marginal improvement there can add up over a terabyte 
data transfer though.

From openssh at roumenpetrov.info  Wed Aug  8 06:00:49 2007
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Tue, 07 Aug 2007 23:00:49 +0300
Subject: Announce: X.509 certificates support in OpenSSH (version
	6.0-International)
Message-ID: <46B8CF71.9090408@roumenpetrov.info>

Today, I released a new version of "X.509 certificates support in 
OpenSSH" ( http://roumenpetrov.info/openssh/ ).


Version 6.0 add following enhancements:

- Printable X.509 name attributes compared in UTF-8
Printable attributes are converted to utf-8 before to compare. This 
allow distinguished name in "authorized keys" file to be in UTF-8.

- "Distinguished Name" with escaped symbols or in UTF-8 codeset(charset)
File "authorized keys" can contain "distinguished Name" (subject) with 
escaped symbols or in UTF-8 charset. If unescaped certificate subject 
contain characters with code above 127(us-ascii) it is handled always as 
UTF-8 string.

- LDAP queries in conformance to [RFC2254]
In validation process "X.509 store" lookup for certificates and CRLs in 
files stored on file system. If is enabled (at configure time) this 
lookup can query LDAP server too. Attributes in query should be escaped 
and the versions before current escape attributes as is described in 
[RFC2253]. Now attributes are escaped in addition as is recommended in 
[RFC2254].

- Restored support for openssl 0.9.6
OpenSSL EVP_MD structure that handle so called "dss-raw" signatures can 
be compiled with openssl 0.9.6.

- Resolved cross-compilation issue
Test for "Email" in "Distinguished Name" (openssl 0.9.6 and earlier) in 
file configure.ac is modified to handle cross-compilation.

- Certificates for RSA keys size greater than 2048
Limitation for big RSA keys is resolved.

- Regression tests with multi-language "distinguished name" in utf-8
To enable uncomment #SSH_DN_UTF8_FLAG='-utf8' in 
"[SOURECDIR]/tests/CA/config", go in "[BUILDIR]/" and run tests. If test 
certificates are created, before to run tests again with flag enabled, 
go in "[BUILDIR]/tests/CA/", run make clean (this will remove created 
test certificates), return to "[BUILDIR]/" and run tests again.


On download page http://roumenpetrov.info/openssh/download.html
you can found diff for OpenSSH versions 4.5p1 and 4.6p1.


Roumen


From djm at mindrot.org  Wed Aug  8 14:04:32 2007
From: djm at mindrot.org (Damien Miller)
Date: Wed, 8 Aug 2007 14:04:32 +1000 (EST)
Subject: Channel Patch
In-Reply-To: <20070807183348.24686.qmail@cdy.org>
References: <46B37B6C.4040901@psc.edu>
	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
	<46B8A322.7090103@psc.edu> <20070807183348.24686.qmail@cdy.org>
Message-ID: <Pine.BSO.4.64.0708081403220.15098@fuyu.mindrot.org>

On Tue, 7 Aug 2007, Peter Stuge wrote:

> On Tue, Aug 07, 2007 at 12:51:46PM -0400, Chris Rapier wrote:
> > > If you wanted to be tricky, you could add a precomputed skip step
> > > to the channels array that would point to the next allocated
> > > channel, allowing the loop to skip past unused channels.
> > 
> > One thing I'm not is tricky. I always end up confusing myself.
> > Mostly I  just write this stuff as research projects in the hope
> > that it interests someone else enough to actual code things
> > properly :)
> 
> The step optimization is really simple and still allows index
> lookups. The step works just like a pointer in the linked list.
> 
> As long as individual channel entries do not need to be atomically
> inserted or removed it'll work great!

Since OpenSSH is single-threaded, there is no need to worry about
concurrent modifications to the channel array.

-d

From djm at mindrot.org  Wed Aug  8 14:21:20 2007
From: djm at mindrot.org (Damien Miller)
Date: Wed, 8 Aug 2007 14:21:20 +1000 (EST)
Subject: Channel Patch
In-Reply-To: <46B8C802.3050102@psc.edu>
References: <46B37B6C.4040901@psc.edu>
	<Pine.BSO.4.64.0708041100080.10393@fuyu.mindrot.org>
	<46B8A322.7090103@psc.edu> <20070807183348.24686.qmail@cdy.org>
	<46B8C802.3050102@psc.edu>
Message-ID: <Pine.BSO.4.64.0708081404560.15098@fuyu.mindrot.org>

On Tue, 7 Aug 2007, Chris Rapier wrote:

> Peter Stuge wrote:
> > On Tue, Aug 07, 2007 at 12:51:46PM -0400, Chris Rapier wrote:
> >>> If you wanted to be tricky, you could add a precomputed skip step
> >>> to the channels array that would point to the next allocated
> >>> channel, allowing the loop to skip past unused channels.
> >> One thing I'm not is tricky. I always end up confusing myself.
> >> Mostly I  just write this stuff as research projects in the hope
> >> that it interests someone else enough to actual code things
> >> properly :)
> > 
> > The step optimization is really simple and still allows index
> > lookups. The step works just like a pointer in the linked list.
> > 
> > As long as individual channel entries do not need to be atomically
> > inserted or removed it'll work great!
> 
> I'm going to betray my ignorance here and ask for a bit of 
> clarification. This isn't like a skip list but basically just a data 
> element that points to the next active channel. So instead of iterating 
> through every element of the array I'd only go to active elements by 
> doing something like
> 
> for (c = channels; c != NULL;  c = c->skip)
> {}

I think it would be more like:

for (i = channel_firstused; i < channels_alloc; i = c->skip)
	...

You would need to track the lowest allocated channel number, or
skip past any initial NULLs. It would be rare that channel 0 would
not be in use, but it is possible when connection multiplexing is in use.

> When a channel is added or removed I would have to iterate through the 
> entire array and update c->skip but that operation shouldn't happen all 
> that often. Is this correct?

You would need to update the next lowest channel's c->skip to point to
the new channel you allocated, or to the next highest allocated allocated
channel on deletion. Something like this:

/* adding channel */

if (channel_first > 0) {
	/* Space exists at the beginning of the array */;
	id = 0
	next_channel = channel_firstused;
	channel_firstused = 0;
} else {
	for (i = channel_first; i < channels_alloc; i = channels[id]->skip) {
		if (channels[i]->skip == i + 1)
			continue;
		/* Found a gap in the array */
		id = i + 1;
		next_channel = channels[i]->skip;
		channels[i]->skip = id;
		break;
	}
	/* No space in array, grow it, etc. */
	...
}

channels[id] = xcalloc(1, sizeof(**channels));
channels[id]->skip = next_channel;

I guess you could optimise this further by keeping a channel_minfree
that is updated when the channels array is grown or when entries are
deleted, but I'm not sure that channel addition/deletion is worth
optimising so much because these operations are relatively infrequent.

> If so, this would preserve the index lookup and eliminate unnecessary 
> looping, wouldn't it? In fact, its basically a linked list but 
> superimposed on an array, right?

That's a reasonable analogy.

-d

From apb at cequrux.com  Sat Aug 11 07:39:09 2007
From: apb at cequrux.com (Alan Barrett)
Date: Fri, 10 Aug 2007 23:39:09 +0200
Subject: RFE: idle timeout/auto-daemonize combo
In-Reply-To: <20070705111205.GN9160@apb-laptoy.apb.alt.za>
References: <C04EF57D-935F-4692-9F3D-E1F430FB9277@cisco.com>
	<1183583479.29081.113.camel@shinybook.infradead.org>
	<20070705111205.GN9160@apb-laptoy.apb.alt.za>
Message-ID: <20070810213909.GD6902@apb-laptoy.apb.alt.za>

On Thu, 05 Jul 2007, Alan Barrett wrote:
> On Wed, 04 Jul 2007, David Woodhouse wrote:
> > > option to automatically create a daemonized master on first
> > > connect.
> 
> That looks very useful, but I'd like the background master to exit after
> remaining unused for a configurable time.

OK, I implemented that the way I wanted it to work, which is a little
different from the way David Woodhouse and Wout Mertens had implemented
it.  See <https://bugzilla.mindrot.org/attachment.cgi?id=1338>, which is
linked from <https://bugzilla.mindrot.org/show_bug.cgi?id=1330#c8>.

--apb (Alan Barrett)

From babic.domagoj at gmail.com  Sun Aug 12 10:13:54 2007
From: babic.domagoj at gmail.com (Domagoj Babic)
Date: Sat, 11 Aug 2007 17:13:54 -0700
Subject: Calysto v1.5 reports on ssh v4.6p1
Message-ID: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>

New version of Calysto reports a warning that looks like a bug to me:

------------------------------------------
Possible NULL-ptr deref (vc27053):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1823
Bug: ??
Explanation:

choose_dh (dh.c:111) calls fopen twice (@120). If the first call to
fopen fails (returns NULL), but the second one succeeds, fgets (@129) is
called with f==NULL.
------------------------------------------

Can anyone confirm that this is a potential issue?

Thx,

-- 
        Domagoj Babic

        http://www.domagoj.info/
        http://www.calysto.org/

From dtucker at zip.com.au  Sun Aug 12 11:19:56 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 12 Aug 2007 11:19:56 +1000
Subject: Calysto v1.5 reports on ssh v4.6p1
In-Reply-To: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>
References: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>
Message-ID: <46BE603C.8070405@zip.com.au>

Domagoj Babic wrote:
> New version of Calysto reports a warning that looks like a bug to me:
> 
> ------------------------------------------
> Possible NULL-ptr deref (vc27053):
> @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1823
> Bug: ??
> Explanation:
> 
> choose_dh (dh.c:111) calls fopen twice (@120). If the first call to
> fopen fails (returns NULL), but the second one succeeds, fgets (@129) is
> called with f==NULL.

I don't follow.  If the second call to fopen succeeds, f is a valid FILE 
pointer returned by the second fopen call, not NULL.  If both fail, the 
function logs a warning,returns DH group 14 and never reaches the fgets.

120  if ((f = fopen(_PATH_DH_MODULI, "r")) == NULL &&
121      (f = fopen(_PATH_DH_PRIMES, "r")) == NULL) {
122          logit("WARNING: %s does not exist, using fixed modulus",
123               _PATH_DH_MODULI);
124                  return (dh_new_group14());
125   }
126
127   linenum = 0;
128   best = bestcount = 0;
129   while (fgets(line, sizeof(line), f)) {

-- 
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 stuge-openssh-unix-dev at cdy.org  Sun Aug 12 14:13:09 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sun, 12 Aug 2007 06:13:09 +0200
Subject: Calysto v1.5 reports on ssh v4.6p1
In-Reply-To: <46BE603C.8070405@zip.com.au>
References: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>
	<46BE603C.8070405@zip.com.au>
Message-ID: <20070812041309.11164.qmail@cdy.org>

On Sun, Aug 12, 2007 at 11:19:56AM +1000, Darren Tucker wrote:
> > choose_dh (dh.c:111) calls fopen twice (@120). If the first call
> > to fopen fails (returns NULL), but the second one succeeds, fgets
> > (@129) is called with f==NULL.
> 
> I don't follow. If the second call to fopen succeeds, f is a valid
> FILE pointer returned by the second fopen call, not NULL.  If both
> fail, the function logs a warning,returns DH group 14 and never
> reaches the fgets.
> 
> 120  if ((f = fopen(_PATH_DH_MODULI, "r")) == NULL &&
> 121      (f = fopen(_PATH_DH_PRIMES, "r")) == NULL) {
> 122          logit("WARNING: %s does not exist, using fixed modulus",

I guess the analyzer is concerned with compilers that generate code
to evaluate both statements even though the first one fails. If the
second statement succeeds then it seems to be at least an fd leak.

I don't know what the rules are for C - apparently GCC stops
evaluating once the complete statement is impossible, but is it
good form to rely on that behavior?


//Peter

From dtucker at zip.com.au  Sun Aug 12 14:51:29 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 12 Aug 2007 14:51:29 +1000
Subject: Calysto v1.5 reports on ssh v4.6p1
In-Reply-To: <20070812041309.11164.qmail@cdy.org>
References: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>	<46BE603C.8070405@zip.com.au>
	<20070812041309.11164.qmail@cdy.org>
Message-ID: <46BE91D1.4000403@zip.com.au>

Peter Stuge wrote:
[...]
> I guess the analyzer is concerned with compilers that generate code
> to evaluate both statements even though the first one fails. If the
> second statement succeeds then it seems to be at least an fd leak.
> 
> I don't know what the rules are for C - apparently GCC stops
> evaluating once the complete statement is impossible, but is it
> good form to rely on that behavior?

That "short circuit" or "lazy evaluation" behaviour is specified by the 
C standards (and I'm pretty sure it's in the K&R book too although I 
don't have a copy to confirm that).

 From section 6.5.13 of what I think this is the most recent C99 spec[1]:

[quote]
        [#4]  Unlike  the bitwise binary & operator, the && operator
        guarantees left-to-right evaluation;  there  is  a  sequence
        point  after  the  evaluation  of the first operand.  If the
        first operand compares equal to 0, the second operand is not
        evaluated.
[/quote]

I would assume that there's similar language in the original ANSI C spec.

[1] http://std.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt

-- 
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 babic.domagoj at gmail.com  Sun Aug 12 18:30:42 2007
From: babic.domagoj at gmail.com (Domagoj Babic)
Date: Sun, 12 Aug 2007 01:30:42 -0700
Subject: Calysto v1.5 reports on ssh v4.6p1
In-Reply-To: <46BE603C.8070405@zip.com.au>
References: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>
	<46BE603C.8070405@zip.com.au>
Message-ID: <e3684ba30708120130p31978f68h4cce22fa93d01266@mail.gmail.com>

On 8/11/07, Darren Tucker <dtucker at zip.com.au> wrote:
> Domagoj Babic wrote:
> > New version of Calysto reports a warning that looks like a bug to me:
> >
> > ------------------------------------------
> > Possible NULL-ptr deref (vc27053):
> > @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1823
> > Bug: ??
> > Explanation:
> >
> > choose_dh (dh.c:111) calls fopen twice (@120). If the first call to
> > fopen fails (returns NULL), but the second one succeeds, fgets (@129) is
> > called with f==NULL.
>
> I don't follow.  If the second call to fopen succeeds, f is a valid FILE
> pointer returned by the second fopen call, not NULL.  If both fail, the
> function logs a warning,returns DH group 14 and never reaches the fgets.

You're right. That's a false positive.

Thx,

-- 
        Domagoj Babic

        http://www.domagoj.info/
        http://www.calysto.org/

From babic.domagoj at gmail.com  Mon Aug 13 05:47:13 2007
From: babic.domagoj at gmail.com (Domagoj Babic)
Date: Sun, 12 Aug 2007 12:47:13 -0700
Subject: Calysto v1.5 reports on ssh v4.6p1
In-Reply-To: <46BE603C.8070405@zip.com.au>
References: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>
	<46BE603C.8070405@zip.com.au>
Message-ID: <e3684ba30708121247l73256d4fp34763493053607f7@mail.gmail.com>

Hi,

I'm experimenting with another static checker, Saturn, and I got a
report that neither Darren nor I can figure out:

[openssh v4.6p1]

> > @orange
> > @58 orange (INCONSISTENT USE) Possible null dereference of variable
> > gparent. This variable is checked for Null at lines: 58
> > @monitor_mm.c
> > @Inconsistency error

Could anyone confirm that this is either a bug or a false positive?

Thank you,

-- 
        Domagoj Babic

        http://www.domagoj.info/
        http://www.calysto.org/

From stuge-openssh-unix-dev at cdy.org  Mon Aug 13 07:35:13 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sun, 12 Aug 2007 23:35:13 +0200
Subject: Calysto v1.5 reports on ssh v4.6p1
In-Reply-To: <e3684ba30708121247l73256d4fp34763493053607f7@mail.gmail.com>
References: <e3684ba30708111713r679ea24elac7421e24e5ffb6b@mail.gmail.com>
	<46BE603C.8070405@zip.com.au>
	<e3684ba30708121247l73256d4fp34763493053607f7@mail.gmail.com>
Message-ID: <20070812213514.13757.qmail@cdy.org>

On Sun, Aug 12, 2007 at 12:47:13PM -0700, Domagoj Babic wrote:
> > > @58 orange (INCONSISTENT USE) Possible null dereference of
> > > variable gparent. This variable is checked for Null at lines:
> > > 58 @monitor_mm.c
> > > @Inconsistency error
> 
> Could anyone confirm that this is either a bug or a false positive?

Wow, this is a bit messy.

monitor_mm.c:58 has the RB_GENERATE() macro which expands to a 270
line long define in openbsd-compat/sys-tree.h, which in turn uses
macros that expand to even more lines. All this is however treated as
one line of source code to not affect the line numbers of the
original source file. (for debugging)

It would take a bit of work - turn those macros into code
(manually(!) or with gcc -E or cpp) and then re-run the static
checker, so that it actually gives some useful information.

Trying to proof 270 lines of code on a single line is not time well
spent for a human.

I could have a look at the code if those macros were made into C
source and the checker reported more meaningful line numbers. Please
include the C source you checked as well then.


//Peter

From listen at alexander.skwar.name  Tue Aug 14 18:54:18 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Tue, 14 Aug 2007 10:54:18 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
Message-ID: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>

Hello.

I've got a problem logging in to a Sparc Solaris 10 machine with 
public key authentication. I searched, and found a similar problem
report at <http://thread.gmane.org/gmane.network.openssh.devel/12694>.
For that guy, the problem had to do with LDAP.

My user accounts are also stored in LDAP, an OpenLDAP server, to be
exact. That server runs on the same machine as the machine I'm trying
to login to. I'm using the Sun pam_ldap stuff.

Strange thing is, that I *am* able to login to this machine with
pubkey authentication as /some/ users. But it does not work for /all/
the users; also not for (test) accounts I just created.

What did I do? In LDAP, I added a test account:

version: 1

# LDIF Export for: uid=testme,ou=People,ou=RACE,o=cmp
# Generated by phpLDAPadmin ( http://phpldapadmin.sourceforge.net/ ) on August 14, 2007 10:43 am
# Server: RACE LDAP Server (winds06)
# Search Scope: base
# Search Filter: (objectClass=*)
# Total Entries: 1

dn: uid=testme,ou=People,ou=RACE,o=cmp
cn: Test User
gidNumber: 10
homeDirectory: /tmp/testme
sn: User
uid: testme
uidNumber: 12345
loginShell: /opt/csw/bin/bash
objectClass: inetLocalMailRecipient
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
objectClass: hostObject
userPassword: {CRYPT}YN5cP0Ms6G.C2
roomNumber: tesetme at cmp.ch
mail: testme at cmp.com
mailRoutingAddress: testme at rieter.ch
mailHost: mail1.cmp.com
shadowLastChange: 13503
gecos: Test Me User,testme at cmp.ch
host: winds06
host: winds06.win.ch.da.rtr
host: winnb000488.win.ch.da.rtr
host: winnb000488
givenName: Test

(I don't care that you now might now the password.)

Next I "mkdir /tmp/testme && chown 12345:10 /tmp/testme". After
that, I'm able to ssh into that account using the password.
Fine. On my Gentoo Linux "client" (I'm sitting in front of it
and use it to do everything), I then ran:

ssh-copy-id testme at winds06

It prompted me for the password and then copied the public key
to the remote host:

root at winds06 $ ls -laR ~testme
/tmp/testme:
total 48
drwxr-xr-x   3 testme   staff        178 Aug 14 10:01 .
drwxrwxrwt  18 root     sys         2469 Aug 14 10:30 ..
drwx------   2 testme   staff        189 Aug 14 10:01 .ssh

/tmp/testme/.ssh:
total 48
drwx------   2 testme   staff        189 Aug 14 10:01 .
drwxr-xr-x   3 testme   staff        178 Aug 14 10:01 ..
-rw-------   1 testme   staff        406 Aug 14 10:01 authorized_keys

root at winds06 $ cat /tmp/testme/.ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAz3yb3Ey6eoDCViXpPNgNQ6gtB92tmEdzvn6R9rHDolPxA3iCOqtkGnMlOAhcg8E5NuGRWeJZueN8E3VpicJsY6xTGl8j8i9+PaCeraNCjJzwrEPXzeeTSKWNnS/uwO8j8NEGec6ZuYI2s4YmCzKGlG8xRS2D6fZalgbcjn4/ZkMGZiYeKm1RSY9Kg0pfLXnXu8u9kQczhKSFYEjvLi+IEhirnAcGPKTYAbNmvnWK8xvtNM+Gp3MQqmqfNC38XUXdah1fYZJaCH3i0slT/8bu3KxjT7UigE4NJ3AguByNfag6s4nglR8EVb0eqeVxdRWaSJrbeoXeZkuRfYM1d/DmnQ== /home/askwar/.ssh/id_rsa

Looks fine, doesn't it? I'm also able to login to other
accounts using this exact key.

Well, but watch this :(

root at winds06 $ /opt/csw/sbin/sshd -p 9991 -Dddd
debug2: load_server_config: filename /opt/csw/etc/sshd_config
debug2: load_server_config: done config len = 198
debug2: parse_server_config: config /opt/csw/etc/sshd_config len 198
debug3: /opt/csw/etc/sshd_config:15 setting Protocol 2
debug3: /opt/csw/etc/sshd_config:79 setting UsePAM yes
debug3: /opt/csw/etc/sshd_config:84 setting X11Forwarding yes
debug3: /opt/csw/etc/sshd_config:88 setting PrintMotd no
debug3: /opt/csw/etc/sshd_config:105 setting Subsystem sftp     /opt/csw/libexec/sftp-server
debug1: sshd version OpenSSH_4.5p1
debug3: Not a RSA1 key file /opt/csw/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /opt/csw/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/opt/csw/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='9991'
debug1: rexec_argv[3]='-Dddd'
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 9991 on ::.
Server listening on :: port 9991.
debug2: fd 5 setting O_NONBLOCK
debug1: Bind to port 9991 on 0.0.0.0.
Server listening on 0.0.0.0 port 9991.
debug1: fd 6 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 11 config len 198
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 11
debug1: inetd sockets after dupping: 4, 4
Connection from 10.0.3.115 port 57348
debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1-hpn12v17
debug1: match: OpenSSH_4.6p1-hpn12v17 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug2: fd 4 setting O_NONBLOCK
debug2: Network child is on pid 17491
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: privsep user:group 113:1
debug1: permanently_set_uid: 113/1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib at openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib at openssh.com,zlib,none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 zlib at openssh.com
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 zlib at openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 1024 8192
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 504/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 501/1024
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature a0f28(143)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user testme service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address 10.0.3.115.
debug2: parse_server_config: config reprocess config len 198
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for testme
debug3: mm_start_pam entering
debug3: mm_request_send entering: type 47
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug2: input_userauth_request: try method none
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 47
debug1: PAM: initializing for "testme"
debug1: PAM: setting PAM_RHOST to "winnb000488.win.ch.da.rtr"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: monitor_read: 47 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for testme from 10.0.3.115 port 57348 ssh2
debug3: mm_request_receive entering
debug3: mm_auth_password: user not authenticated
debug1: userauth-request for user testme service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 99468
debug1: temporarily_use_uid: 12345/10 (e=0/0)
debug1: trying public key file /tmp/testme/.ssh/authorized_keys
debug3: secure_filename: checking '/tmp/testme/.ssh'
debug3: secure_filename: checking '/tmp/testme'
debug3: secure_filename: terminating check at '/tmp/testme'
debug1: matching key found: file /tmp/testme/.ssh/authorized_keys, line 1
Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 99468 is allowed
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for testme from 10.0.3.115 port 57348 ssh2
debug1: userauth-request for user testme service ssh-connection method publickey
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method publickey
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 996a8
debug1: temporarily_use_uid: 12345/10 (e=0/0)
debug1: trying public key file /tmp/testme/.ssh/authorized_keys
debug3: secure_filename: checking '/tmp/testme/.ssh'
debug3: secure_filename: checking '/tmp/testme'
debug3: secure_filename: terminating check at '/tmp/testme'
debug1: matching key found: file /tmp/testme/.ssh/authorized_keys, line 1
Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 996a8 is allowed
debug3: mm_request_send entering: type 21
debug3: mm_key_verify entering
debug3: mm_request_send entering: type 22
debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY
debug3: mm_request_receive_expect entering: type 23
debug3: mm_request_receive entering
debug3: mm_request_receive entering
debug3: monitor_read: checking request 22
debug1: ssh_rsa_verify: signature correct
debug3: mm_answer_keyverify: key 99468 signature verified
debug3: mm_request_send entering: type 23
debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa
debug3: mm_do_pam_account entering
debug3: mm_request_send entering: type 48
debug3: mm_request_receive_expect entering: type 49
debug3: mm_request_receive entering
debug3: mm_request_receive_expect entering: type 48
debug3: mm_request_receive entering
debug1: do_pam_account: called
debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication failed)
debug3: mm_request_send entering: type 49
debug3: mm_do_pam_account returning 0
Access denied for user testme by PAM account configuration
debug1: do_cleanup
Failed publickey for testme from 10.0.3.115 port 57348 ssh2
debug3: mm_request_receive entering
debug1: do_cleanup

I guess the most important lines are these:

debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication failed)
[...]
Access denied for user testme by PAM account configuration

Why is PAM denying access?

root at winds06 $ grep -v \# /etc/pam.conf
login   auth requisite        pam_authtok_get.so.1
login   auth required         pam_dhkeys.so.1
login   auth required         pam_unix_cred.so.1
login   auth required         pam_dial_auth.so.1
login   auth binding          pam_unix_auth.so.1 server_policy
login   auth required         pam_ldap.so.1
rlogin  auth sufficient       pam_rhosts_auth.so.1
rlogin  auth requisite        pam_authtok_get.so.1
rlogin  auth required         pam_dhkeys.so.1
rlogin  auth required         pam_unix_cred.so.1
rlogin  auth binding          pam_unix_auth.so.1 server_policy
rlogin  auth required         pam_ldap.so.1
rsh     auth sufficient       pam_rhosts_auth.so.1
rsh     auth required         pam_unix_cred.so.1
rsh     auth binding          pam_unix_auth.so.1 server_policy
rsh     auth required         pam_ldap.so.1
ppp     auth requisite        pam_authtok_get.so.1
ppp     auth required         pam_dhkeys.so.1
ppp     auth required         pam_dial_auth.so.1
ppp     auth binding          pam_unix_auth.so.1 server_policy
ppp     auth required         pam_ldap.so.1
other   auth requisite        pam_authtok_get.so.1
other   auth required         pam_dhkeys.so.1
other   auth required         pam_unix_cred.so.1
other   auth binding          pam_unix_auth.so.1 server_policy
other   auth required         pam_ldap.so.1
passwd  auth binding          pam_passwd_auth.so.1 server_policy
passwd  auth required         pam_ldap.so.1
cron    account required      pam_unix_account.so.1
other   account requisite     pam_roles.so.1
other   account binding       pam_unix_account.so.1 server_policy
other   account required      pam_ldap.so.1
other   session required      pam_unix_session.so.1
other   password required     pam_dhkeys.so.1
other   password requisite    pam_authtok_get.so.1
other   password requisite    pam_authtok_check.so.1
other   password required     pam_authtok_store.so.1 server_policy

What I absolutely don't get, is why PAM denies access to this
user with pubkey auth. To create the user in LDAP, I copied an 
existing and working entry and then modified stuff like uidNumber,
uid, userPassword etc.

Versions:

Server: OpenSSH_4.5p1, OpenSSL 0.9.8e 23 Feb 2007, Sparc Solaris 10
Client: OpenSSH_4.6p1-hpn12v17, OpenSSL 0.9.8e 23 Feb 2007, x86 Gentoo Linux

Thanks a lot for any hints,

Alexander Skwar


From d at adaptive-enterprises.com.au  Tue Aug 14 21:28:52 2007
From: d at adaptive-enterprises.com.au (David Leonard)
Date: Tue, 14 Aug 2007 21:28:52 +1000
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
Message-ID: <46C191F4.5040104@adaptive-enterprises.com.au>

Alexander Skwar wrote:
> I've got a problem logging in to a Sparc Solaris 10 machine

> I guess the most important lines are these:
>
> debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication failed)
> [...]
> Access denied for user testme by PAM account configuration
>
> Why is PAM denying access?
>   

Hi, Alexander
See this post for information on enabling debug output from the pam 
stack on Solaris: 
http://mail.opensolaris.org/pipermail/ug-bosug/2006-July/000746.html

d

-- 
David Leonard


From listen at alexander.skwar.name  Tue Aug 14 22:10:07 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Tue, 14 Aug 2007 14:10:07 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
Message-ID: <35996548.VLSRdUcR7A@kn.gn.rtr.message-center.info>

David Leonard <d at adaptive-enterprises.com.au> wrote:

> Alexander Skwar wrote:
>> I've got a problem logging in to a Sparc Solaris 10 machine
> 
>> I guess the most important lines are these:
>>
>> debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication failed)
>> [...]
>> Access denied for user testme by PAM account configuration
>>
>> Why is PAM denying access?
>>   
> 
> Hi, Alexander
> See this post for information on enabling debug output from the pam
> stack on Solaris:
> http://mail.opensolaris.org/pipermail/ug-bosug/2006-July/000746.html

Hm. I get the following (starting from when I get the login prompt
after "telnet  host", ending after I entered username+password and then
^D):

,----[ PAM Debug Log Messages ]
| Aug 14 14:03:32 winds05 login[3155]: [ID 397050 auth.debug] PAM[3155]: pam_start(telnet,,26a84:29430) - debug = 1
| Aug 14 14:03:32 winds05 login[3155]: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:service)
| Aug 14 14:03:32 winds05 login[3155]: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:user)
| Aug 14 14:03:32 winds05 login[3155]: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:conv)
| Aug 14 14:03:32 winds05 login[3155]: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:tty)
| Aug 14 14:03:32 winds05 login[3155]: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:rhost)
| Aug 14 14:03:32 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:user_prompt)
| Aug 14 14:03:32 winds05 login: [ID 304686 auth.debug] PAM[3155]: pam_authenticate(29430, 0)
| Aug 14 14:03:32 winds05 login: [ID 387781 auth.debug] PAM[3155]: load_modules(29430, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1
| Aug 14 14:03:32 winds05 login: [ID 278207 auth.debug] PAM[3155]: load_function: successful load of pam_sm_authenticate
| Aug 14 14:03:32 winds05 login: [ID 387781 auth.debug] PAM[3155]: load_modules(29430, pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1
| Aug 14 14:03:32 winds05 login: [ID 278207 auth.debug] PAM[3155]: load_function: successful load of pam_sm_authenticate
| Aug 14 14:03:32 winds05 login: [ID 387781 auth.debug] PAM[3155]: load_modules(29430, pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1
| Aug 14 14:03:32 winds05 login: [ID 278207 auth.debug] PAM[3155]: load_function: successful load of pam_sm_authenticate
| Aug 14 14:03:32 winds05 login: [ID 744822 auth.debug] PAM[3155]: pam_get_user(29430, 61746500, NULL)
| 
| ==> ./remote/winds06/local4/debug <==
| Aug 14 14:01:14 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (ipHostNumber) index_param failed (18)
| Aug 14 14:01:14 winds06 slapd[24115]: [ID 580335 local4.debug] conn=968 op=0 ENTRY dn="cn=winnb000353.win.ch.da.rtr,ou=hosts,ou=race,o=Example"
| Aug 14 14:01:14 winds06 slapd[24115]: [ID 368799 local4.debug] get_filter: conn 969 unknown attribute type=nisdomain (17)
| Aug 14 14:01:14 winds06 slapd[24115]: [ID 368799 local4.debug] get_filter: conn 970 unknown attribute type=nisdomain (17)
| Aug 14 14:01:14 winds06 slapd[24115]: [ID 368799 local4.debug] get_filter: conn 971 unknown attribute type=nisdomain (17)
| 
| ==> ./remote/10.0.1.25/auth/debug <==
| Aug 14 14:03:36 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:user)
| 
| ==> ./remote/winds06/local4/debug <==
| Aug 14 14:01:15 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
| Aug 14 14:01:15 winds06 slapd[24115]: [ID 580335 local4.debug] conn=972 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
| 
| ==> ./remote/10.0.1.25/auth/debug <==
| Aug 14 14:03:40 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:authtok)
| Aug 14 14:03:40 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:authtok)
| Aug 14 14:03:40 winds05 login: [ID 993814 auth.debug] PAM[3155]: pam_authenticate(29430, 0): error Authentication failed
| Aug 14 14:03:40 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:authtok)
| 
| ==> ./remote/winds06/local4/debug <==
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 580335 local4.debug] conn=973 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 580335 local4.debug] conn=974 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 580335 local4.debug] conn=975 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
| Aug 14 14:01:20 winds06 slapd[24115]: [ID 580335 local4.debug] conn=976 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
| 
| ==> ./remote/10.0.1.25/auth/debug <==
| Aug 14 14:03:44 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:user)
| Aug 14 14:03:44 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:ruser)
| Aug 14 14:03:44 winds05 login: [ID 360225 auth.debug] PAM[3155]: pam_set_item(29430:user_prompt)
| Aug 14 14:03:44 winds05 login: [ID 304686 auth.debug] PAM[3155]: pam_authenticate(29430, 0)
| Aug 14 14:03:44 winds05 login: [ID 387781 auth.debug] PAM[3155]: load_modules(29430, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1
| Aug 14 14:03:44 winds05 login: [ID 744822 auth.debug] PAM[3155]: pam_get_user(29430, ff0000, NULL)
| Aug 14 14:03:46 winds05 login: [ID 503841 auth.debug] PAM[3155]: pam_end(29430): status = General PAM failure 
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 397042 auth.debug] PAM[3153]: pam_start(telnet,.telnet,0:28fe0) - debug = 1
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 735918 auth.debug] PAM[3153]: pam_set_item(28fe0:service)
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 735918 auth.debug] PAM[3153]: pam_set_item(28fe0:user)
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 735918 auth.debug] PAM[3153]: pam_set_item(28fe0:conv)
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 735918 auth.debug] PAM[3153]: pam_set_item(28fe0:tty)
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 735918 auth.debug] PAM[3153]: pam_set_item(28fe0:rhost)
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 304685 auth.debug] PAM[3153]: pam_close_session(28fe0, 0)
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 258799 auth.debug] PAM[3153]: load_modules(28fe0, pam_sm_close_session)=/usr/lib/security/pam_unix_session.so.1
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 213716 auth.debug] PAM[3153]: load_function: successful load of pam_sm_close_session
| Aug 14 14:03:46 winds05 telnetd[3153]: [ID 893552 auth.debug] PAM[3153]: pam_end(28fe0): status = Success
`----

Doesn't tell me much... I saw

Aug 14 14:03:40 winds05 login: [ID 993814 auth.debug] PAM[3155]: pam_authenticate(29430, 0): error Authentication failed

But why?

Anyway. Seems to be a PAM issue, not (much) related to OpenSSH.

Thanks a lot for the (not yet, but nonetheless *G*) helpful hint on how
to enable PAM debugging!

Best regards,

Alexander Skwar


From listen at alexander.skwar.name  Tue Aug 14 22:29:17 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Tue, 14 Aug 2007 14:29:17 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
Message-ID: <1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>

David Leonard <d at adaptive-enterprises.com.au> wrote:

> Alexander Skwar wrote:
>> I've got a problem logging in to a Sparc Solaris 10 machine
> 
>> I guess the most important lines are these:
>>
>> debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication failed)
>> [...]
>> Access denied for user testme by PAM account configuration
>>
>> Why is PAM denying access?
>>   
> 
> Hi, Alexander
> See this post for information on enabling debug output from the pam
> stack on Solaris:
> http://mail.opensolaris.org/pipermail/ug-bosug/2006-July/000746.html

Whoops. My previous reply to your mail related to a different server.
This time, I added

debug_flags = 0x17
log_facility = 22
log_priority = 7

to the /etc/pam_debug file on the correct server - still doesn't tell
me much, though...

,----[ PAM Debug Messages on correct server ]
| ==> ./remote/winds06/auth/debug <==
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 783976 auth.debug] PAM[3078]: pam_start(sshd,testme,8c204:98e30) - debug = 1
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:service)
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:user)
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:conv)
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:rhost)
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:tty)
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 899056 auth.debug] PAM[3078]: pam_acct_mgmt(98e30, 0)
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 684966 auth.debug] PAM[3078]: load_modules(98e30, pam_sm_acct_mgmt)=/usr/lib/security/pam_roles.so.1
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 555781 auth.debug] PAM[3078]: load_function: successful load of pam_sm_acct_mgmt
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 684966 auth.debug] PAM[3078]: load_modules(98e30, pam_sm_acct_mgmt)=/usr/lib/security/pam_unix_account.so.1
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 555781 auth.debug] PAM[3078]: load_function: successful load of pam_sm_acct_mgmt
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 684966 auth.debug] PAM[3078]: load_modules(98e30, pam_sm_acct_mgmt)=/usr/lib/security/pam_ldap.so.1
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 555781 auth.debug] PAM[3078]: load_function: successful load of pam_sm_acct_mgmt
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 835736 auth.debug] __ns_ldap_getAcctMgmt() failed for testme with error 7
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 118913 auth.debug] PAM[3078]: pam_acct_mgmt(98e30, 0): error Authentication failed
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:authtok)
| 
| ==> ./remote/winds06/auth/warning <==
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 778364 auth.warning] libsldap: server 127.0.0.1 does not provide account information without password
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 778364 auth.warning] libsldap: server 127.0.0.1 does not provide account information without password
| Aug 14 14:22:12 winds06 sshd[3078]: [ID 293258 auth.warning] libsldap: Status: 7  Mesg: Session error no available conn.
| 
| ==> ./remote/winds06/local4/debug <==
| Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (memberUid) index_param failed (18)
| Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
| Aug 14 14:22:12 winds06 slapd[24115]: [ID 580335 local4.debug] conn=1380 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
`----

Hmm:

Aug 14 14:22:12 winds06 sshd[3078]: [ID 835736 auth.debug] __ns_ldap_getAcctMgmt() failed for testme with error 7

"error 7"? What's that?

Anyway. Still looks like PAM / LDAP issue. But what I don't get is, why
I *am* able to login as some users with a pubkey. Any ideas about why
that might be?

Strange.

Alexander Skwar


From stuge-openssh-unix-dev at cdy.org  Tue Aug 14 23:17:27 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 14 Aug 2007 15:17:27 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
Message-ID: <20070814131728.12252.qmail@cdy.org>

On Tue, Aug 14, 2007 at 02:29:17PM +0200, Alexander Skwar wrote:
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 835736 auth.debug] __ns_ldap_getAcctMgmt() failed for testme with error 7
> | 
> | ==> ./remote/winds06/auth/warning <==
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 778364 auth.warning] libsldap: server 127.0.0.1 does not provide account information without password

Maybe this is a hint.


> | ==> ./remote/winds06/local4/debug <==
> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (memberUid) index_param failed (18)
> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)

Or this.


> "error 7"? What's that?

$ qlist openldap|grep include|xargs grep ERR|grep 7

gave these candidates:

/usr/include/ldap.h:#define LDAP_FILTER_ERROR (-7)
/usr/include/ldap.h:#define LDAP_URL_ERR_BADATTRS 0x07 /* bad (or
missing) attributes */
/usr/include/ldap_schema.h:#define LDAP_SCHERR_BADDESC 7


> Anyway. Still looks like PAM / LDAP issue.

Yes, it is.


> But what I don't get is, why I *am* able to login as some users
> with a pubkey. Any ideas about why that might be?

Something is different in the LDAP data stored for the users,
probably because of how they were created. I hope you can find what
it is.


//Peter

From listen at alexander.skwar.name  Tue Aug 14 23:43:04 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Tue, 14 Aug 2007 15:43:04 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
Message-ID: <3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>

Peter Stuge <stuge-openssh-unix-dev at cdy.org> wrote:

> On Tue, Aug 14, 2007 at 02:29:17PM +0200, Alexander Skwar wrote:
>> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 835736 auth.debug]
>> | __ns_ldap_getAcctMgmt() failed for testme with error 7
>> | 
>> | ==> ./remote/winds06/auth/warning <==
>> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 778364 auth.warning] libsldap:
>> | server 127.0.0.1 does not provide account information without password
> 
> Maybe this is a hint.

Yep. Public Key auth is certainly auth without a password :) But why
don't I get this message, when I login with a good user?

>> | ==> ./remote/winds06/local4/debug <==
>> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <=
>> | bdb_equality_candidates: (memberUid) index_param failed (18) Aug 14
>> | 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <=
>> | bdb_equality_candidates: (uid) index_param failed (18)
> 
> Or this.

That's just about a missing index. Important if you're interested
in performance.

And I also get this for good users.

>> "error 7"? What's that?
> 
> $ qlist openldap|grep include|xargs grep ERR|grep 7
> 
> gave these candidates:
> 
> /usr/include/ldap.h:#define LDAP_FILTER_ERROR (-7)
> /usr/include/ldap.h:#define LDAP_URL_ERR_BADATTRS 0x07 /* bad (or
> missing) attributes */
> /usr/include/ldap_schema.h:#define LDAP_SCHERR_BADDESC 7

Thanks.

>> Anyway. Still looks like PAM / LDAP issue.
> 
> Yes, it is.

With a strange coincidence with SSH.

>> But what I don't get is, why I *am* able to login as some users
>> with a pubkey. Any ideas about why that might be?
> 
> Something is different in the LDAP data stored for the users,
> probably because of how they were created. I hope you can find what
> it is.

That's the thing - I cannot... :( I copied the new user, using the
data from a working user. I also tried to create a new user "from
scratch". Having a look at the LDIF exports, I cannot see any differences.

Anyway. Probably really a LDAP thing. Sadly we're using Solaris
and not Linux - in Solaris, everything is just soo much more
complicated...

Oh, well.

Alexander Skwar


From deengert at anl.gov  Tue Aug 14 23:10:40 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 14 Aug 2007 08:10:40 -0500
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
Message-ID: <46C1A9D0.7000203@anl.gov>


Does the Solaris 10 sshd work or fail the same way?


Alexander Skwar wrote:
> David Leonard <d at adaptive-enterprises.com.au> wrote:
> 
>> Alexander Skwar wrote:
>>> I've got a problem logging in to a Sparc Solaris 10 machine
>>> I guess the most important lines are these:
>>>
>>> debug3: PAM: do_pam_account pam_acct_mgmt = 9 (Authentication failed)
>>> [...]
>>> Access denied for user testme by PAM account configuration
>>>
>>> Why is PAM denying access?
>>>   
>> Hi, Alexander
>> See this post for information on enabling debug output from the pam
>> stack on Solaris:
>> http://mail.opensolaris.org/pipermail/ug-bosug/2006-July/000746.html
> 
> Whoops. My previous reply to your mail related to a different server.
> This time, I added
> 
> debug_flags = 0x17
> log_facility = 22
> log_priority = 7
> 
> to the /etc/pam_debug file on the correct server - still doesn't tell
> me much, though...
> 
> ,----[ PAM Debug Messages on correct server ]
> | ==> ./remote/winds06/auth/debug <==
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 783976 auth.debug] PAM[3078]: pam_start(sshd,testme,8c204:98e30) - debug = 1
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:service)
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:user)
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:conv)
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:rhost)
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:tty)
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 899056 auth.debug] PAM[3078]: pam_acct_mgmt(98e30, 0)
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 684966 auth.debug] PAM[3078]: load_modules(98e30, pam_sm_acct_mgmt)=/usr/lib/security/pam_roles.so.1
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 555781 auth.debug] PAM[3078]: load_function: successful load of pam_sm_acct_mgmt
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 684966 auth.debug] PAM[3078]: load_modules(98e30, pam_sm_acct_mgmt)=/usr/lib/security/pam_unix_account.so.1
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 555781 auth.debug] PAM[3078]: load_function: successful load of pam_sm_acct_mgmt
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 684966 auth.debug] PAM[3078]: load_modules(98e30, pam_sm_acct_mgmt)=/usr/lib/security/pam_ldap.so.1
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 555781 auth.debug] PAM[3078]: load_function: successful load of pam_sm_acct_mgmt
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 835736 auth.debug] __ns_ldap_getAcctMgmt() failed for testme with error 7
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 118913 auth.debug] PAM[3078]: pam_acct_mgmt(98e30, 0): error Authentication failed
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 262804 auth.debug] PAM[3078]: pam_set_item(98e30:authtok)
> | 
> | ==> ./remote/winds06/auth/warning <==
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 778364 auth.warning] libsldap: server 127.0.0.1 does not provide account information without password
> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 778364 auth.warning] libsldap: server 127.0.0.1 does not provide account information without password

These look strange. It might be the access rules in LDAP that is preventing an anonymous user from reading the account.
Is nscd running? It should be. Did you use the the Solaris ldapclient tool to configure LDAp on the client?
It should have started it. It will access LDAP using the proxy user and password.

> | Aug 14 14:22:12 winds06 sshd[3078]: [ID 293258 auth.warning] libsldap: Status: 7  Mesg: Session error no available conn.
> | 
> | ==> ./remote/winds06/local4/debug <==
> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (memberUid) index_param failed (18)
> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <= bdb_equality_candidates: (uid) index_param failed (18)
> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 580335 local4.debug] conn=1380 op=0 ENTRY dn="uid=testme,ou=people,ou=race,o=Example"
> `----
> 
> Hmm:
> 
> Aug 14 14:22:12 winds06 sshd[3078]: [ID 835736 auth.debug] __ns_ldap_getAcctMgmt() failed for testme with error 7
> 
> "error 7"? What's that?
> 
> Anyway. Still looks like PAM / LDAP issue. But what I don't get is, why
> I *am* able to login as some users with a pubkey. Any ideas about why
> that might be?
> 
> Strange.
> 
> Alexander Skwar
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.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 stuge-openssh-unix-dev at cdy.org  Wed Aug 15 02:33:38 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 14 Aug 2007 18:33:38 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
Message-ID: <20070814163338.16925.qmail@cdy.org>

On Tue, Aug 14, 2007 at 03:43:04PM +0200, Alexander Skwar wrote:
> Yep. Public Key auth is certainly auth without a password :) But
> why don't I get this message, when I login with a good user?

Again - something is different for those users, somewhere.


> >> | ==> ./remote/winds06/local4/debug <==
> >> | Aug 14 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <=
> >> | bdb_equality_candidates: (memberUid) index_param failed (18) Aug 14
> >> | 14:22:12 winds06 slapd[24115]: [ID 925615 local4.debug] <=
> >> | bdb_equality_candidates: (uid) index_param failed (18)
> > 
> > Or this.
> 
> That's just about a missing index. Important if you're interested
> in performance.
> 
> And I also get this for good users.

Ok, so that can be ruled out.


> >> Anyway. Still looks like PAM / LDAP issue.
> > 
> > Yes, it is.
> 
> With a strange coincidence with SSH.

OpenSSH introduces a lot of third-party PAM code to a system so it's
not all that strange.


> > Something is different in the LDAP data stored for the users,
> > probably because of how they were created.

> I copied the new user, using the data from a working user.

So that's one way.


> I also tried to create a new user "from scratch".

That's two.

Possibly the working users were created in bulk (three) or just using
different versions of some software (four). Creating new users the
exact same way as the working users were created should still
succeed though. If you get that far, you get to reverse engineer what
is actually going on to find the difference.


> Having a look at the LDIF exports, I cannot see any differences.

But this is not the whole truth. There's a lot of software involved
in writing and reading that data, some of it may implement a policy
according to something else than the data in the LDIF export.


> Anyway. Probably really a LDAP thing.

Can you test if these users are allowed through when someone else
than OpenSSH uses PAM to do passwordless logins? Any server is good.

If that works, then there's probably a problem in OpenSSH with how
PAM is worked on the system. I recall there being a PAM test harness
which mimics what OpenSSH does - but I don't remember if it's
included in the distribution or available separately?

My guess is that the problem is with writing to LDAP, rather than
reading from it.


//Peter

From dtucker at zip.com.au  Wed Aug 15 07:23:32 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 15 Aug 2007 07:23:32 +1000
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <20070814163338.16925.qmail@cdy.org>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org>
Message-ID: <46C21D54.8050605@zip.com.au>

Peter Stuge wrote:
> I recall there being a PAM test harness
> which mimics what OpenSSH does - but I don't remember if it's
> included in the distribution or available separately?

http://www.zip.com.au/~dtucker/patches/#pamtest

The "-a" option skips the pam_authenticate call which simulates what 
happens during a public-key authentication.

-- 
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 listen at alexander.skwar.name  Wed Aug 15 16:52:42 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Wed, 15 Aug 2007 08:52:42 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org>
Message-ID: <1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>

Peter Stuge <stuge-openssh-unix-dev at cdy.org> wrote:

> On Tue, Aug 14, 2007 at 03:43:04PM +0200, Alexander Skwar wrote:
>> Yep. Public Key auth is certainly auth without a password :) But
>> why don't I get this message, when I login with a good user?
> 
> Again - something is different for those users, somewhere.

Of course! I'm not denying this ;) One set of users is able
to use passwordless entry, while the other set of users is
not able to do this. That's of course quite a difference *g*

>> >> Anyway. Still looks like PAM / LDAP issue.
>> > 
>> > Yes, it is.
>> 
>> With a strange coincidence with SSH.
> 
> OpenSSH introduces a lot of third-party PAM code to a system so it's
> not all that strange.
> 
> 
>> > Something is different in the LDAP data stored for the users,
>> > probably because of how they were created.
> 
>> I copied the new user, using the data from a working user.
> 
> So that's one way.
> 
> 
>> I also tried to create a new user "from scratch".
> 
> That's two.
> 
> Possibly the working users were created in bulk (three) or just using
> different versions of some software (four).

Well, as long as the LDAP database has the same contents, it doesn't
make a difference on how the data was "poured" into it, I'd think. But
I don't know that.

It's like if there were a difference, when you create a user by
doing "vi /etc/passwd" compared to "echo blah:blah:blah >> /etc/passwd".
The result is the same. Confusing.

> Creating new users the 
> exact same way as the working users were created should still
> succeed though.

Will try that. But I very highly doubt, that this makes a difference
at all. After all, it's just a different way to fill that database.

...

Okay. Done. Original way was, that I used the PADL Migration Tools,
which convert /etc/passwd et.al. to LDIF files which then have to
be ldapadd'ed to the LDAP database. I just did that, and as was
to be expected, there was no difference whatsoever. Result:
With yet another newly created test user, I'm able to SSH login 
using a password. Passwordless entry using pubkey doesn't work.

> If you get that far, you get to reverse engineer what 
> is actually going on to find the difference.

Yep. If I'd only be able to get that far... :\

>> Having a look at the LDIF exports, I cannot see any differences.
> 
> But this is not the whole truth. There's a lot of software involved
> in writing and reading that data, some of it may implement a policy
> according to something else than the data in the LDIF export.

But the LDAP database is the sole source of information. There
is nothing else (well, there's of course still a mostly empty
/etc/passwd and /etc/group, but there's nothing in those files
for the new users and there's also nothing in there for the
old and working users).

>> Anyway. Probably really a LDAP thing.
> 
> Can you test if these users are allowed through when someone else
> than OpenSSH uses PAM to do passwordless logins? Any server is good.

What server should I try?

> My guess is that the problem is with writing to LDAP, rather than
> reading from it.

I doubt that. In LDAP, there's no difference between the non-working
users and the working users. At least not, as far as I can tell.

Thanks a lot though,
Alexander Skwar


From listen at alexander.skwar.name  Wed Aug 15 17:45:08 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Wed, 15 Aug 2007 09:45:08 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<46C1A9D0.7000203@anl.gov>
Message-ID: <1377339.2gWihzfIaM@kn.gn.rtr.message-center.info>

Douglas E. Engert <deengert at anl.gov> wrote:

> Does the Solaris 10 sshd work or fail the same way?

It behaves differently. Without a key, I'm able to login to
the server (same behaviour as with OpenSSHd). But when I try
to login after I copied a key to the system, I'm still prompted
for a password. This does not happen with OpenSSHd! With
OpenSSH, I'm never prompted, as I'm using the ssh key agent.

Watch this:

,----[ ssh -Cv -l testing -p 65022 winds06, on the client ]
| debug1: matching key found: file /tmp/testing/.ssh/authorized_keys, line 1
| Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
| debug1: restore_uid: 0/0
| debug1: ssh_rsa_verify: signature correct
| debug2: Starting PAM service sshd-pubkey for method publickey
| debug3: Trying to reverse map address 10.0.3.115.
| debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
| Failed publickey for testing from 10.0.3.115 port 56651 ssh2
| debug1: userauth-request for user testing service ssh-connection method keyboard-interactive
| debug1: attempt 3 initial attempt 0 failures 3 initial failures 0
| debug2: input_userauth_request: try method keyboard-interactive
| debug1: keyboard-interactive devs 
| debug2: Starting PAM service sshd-kbdint for method keyboard-interactive
| debug2: Calling pam_authenticate()
| debug2: PAM echo off prompt: Password: 
| debug2: Nesting dispatch_run loop
`----

So it found a matching key in ~/.ssh, but for some reason that 
was not good enough, or something like that.

Complete sessions, also including one of a working user:

,----[ ssh -Cv -l testing -p 65022 winds06, on the client ]
| OpenSSH_4.6p1-hpn12v17, OpenSSL 0.9.8e 23 Feb 2007
| debug1: Reading configuration data /home/askwar/.ssh/config
| debug1: Reading configuration data /etc/ssh/ssh_config
| debug1: Connecting to winds06 [10.0.1.26] port 65022.
| debug1: Connection established.
| debug1: identity file /home/askwar/.ssh/identity type -1
| debug1: identity file /home/askwar/.ssh/id_rsa type 1
| debug1: identity file /home/askwar/.ssh/id_dsa type -1
| debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
| debug1: no match: Sun_SSH_1.1
| debug1: Enabling compatibility mode for protocol 2.0
| debug1: Local version string SSH-2.0-OpenSSH_4.6p1-hpn12v17
| debug1: SSH2_MSG_KEXINIT sent
| debug1: SSH2_MSG_KEXINIT received
| debug1: kex: server->client aes128-cbc hmac-md5 zlib
| debug1: kex: client->server aes128-cbc hmac-md5 zlib
| 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 '[winds06]:65022' is known and matches the RSA host key.
| debug1: Found key in /home/askwar/.ssh/known_hosts:25
| debug1: ssh_rsa_verify: signature correct
| debug1: Enabling compression at level 6.
| 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: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
| debug1: Next authentication method: publickey
| debug1: Offering public key: /home/askwar/.ssh/id_rsa
| debug1: Server accepts key: pkalg ssh-rsa blen 277
| debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
| debug1: Trying private key: /home/askwar/.ssh/identity
| debug1: Trying private key: /home/askwar/.ssh/id_dsa
| debug1: Next authentication method: keyboard-interactive
| Password: 
`----

And at the same time on the server side:

,----[ sudo /usr/lib/ssh/sshd -Dddd -f /etc/ssh/sshd_config, on the server ]
| debug1: sshd version Sun_SSH_1.1
| debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
| debug1: read PEM private key done: type RSA
| debug1: private host key: #0 type 1 RSA
| debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
| debug1: read PEM private key done: type DSA
| debug1: private host key: #1 type 2 DSA
| debug1: Bind to port 65022 on ::.
| Server listening on :: port 65022.
| debug1: Server will not fork when running in debugging mode.
| Connection from 10.0.3.115 port 56651
| debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1-hpn12v17
| debug1: match: OpenSSH_4.6p1-hpn12v17 pat OpenSSH*
| debug1: Enabling compatibility mode for protocol 2.0
| debug1: Local version string SSH-2.0-Sun_SSH_1.1
| debug1: list_hostkey_types: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
| debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: first_kex_follows 0 
| debug2: kex_parse_kexinit: reserved 0 
| debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
| Unknown code 0
| )
| debug1: SSH2_MSG_KEXINIT sent
| debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
| debug1: SSH2_MSG_KEXINIT received
| debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
| debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: first_kex_follows 0 
| debug2: kex_parse_kexinit: reserved 0 
| debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
| debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
| debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: zlib at openssh.com,zlib,none
| debug2: kex_parse_kexinit: zlib at openssh.com,zlib,none
| debug2: kex_parse_kexinit: 
| debug2: kex_parse_kexinit: 
| debug2: kex_parse_kexinit: first_kex_follows 0 
| debug2: kex_parse_kexinit: reserved 0 
| debug2: mac_init: found hmac-md5
| debug1: kex: client->server aes128-cbc hmac-md5 zlib
| debug2: mac_init: found hmac-md5
| debug1: kex: server->client aes128-cbc hmac-md5 zlib
| debug1: Peer sent proposed langtags, ctos: 
| debug1: Peer sent proposed langtags, stoc: 
| debug1: We proposed langtags, ctos: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug1: We proposed langtags, stoc: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
| debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
| debug1: dh_gen_key: priv key bits set: 132/256
| debug1: bits set: 516/1024
| debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
| debug1: bits set: 498/1024
| debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
| debug2: kex_derive_keys
| debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
| debug1: newkeys: mode 1
| debug1: Enabling compression at level 6.
| debug1: SSH2_MSG_NEWKEYS sent
| debug1: expecting SSH2_MSG_NEWKEYS
| debug1: newkeys: mode 0
| debug1: SSH2_MSG_NEWKEYS received
| debug1: KEX done
| debug1: userauth-request for user testing service ssh-connection method none
| debug1: attempt 0 initial attempt 0 failures 0 initial failures 0
| debug2: input_userauth_request: setting up authctxt for testing
| debug2: input_userauth_request: try method none
| Failed none for testing from 10.0.3.115 port 56651 ssh2
| debug1: userauth-request for user testing service ssh-connection method publickey
| debug1: attempt 1 initial attempt 0 failures 1 initial failures 0
| debug2: input_userauth_request: try method publickey
| debug1: test whether pkalg/pkblob are acceptable
| debug1: temporarily_use_uid: 54321/10 (e=0/0)
| debug1: trying public key file /tmp/testing/.ssh/authorized_keys
| debug3: secure_filename: checking '/tmp/testing/.ssh'
| debug3: secure_filename: checking '/tmp/testing'
| debug3: secure_filename: terminating check at '/tmp/testing'
| debug1: matching key found: file /tmp/testing/.ssh/authorized_keys, line 1
| Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
| debug1: restore_uid: 0/0
| debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
| debug1: userauth-request for user testing service ssh-connection method publickey
| debug1: attempt 2 initial attempt 0 failures 1 initial failures 0
| debug2: input_userauth_request: try method publickey
| debug1: temporarily_use_uid: 54321/10 (e=0/0)
| debug1: trying public key file /tmp/testing/.ssh/authorized_keys
| debug3: secure_filename: checking '/tmp/testing/.ssh'
| debug3: secure_filename: checking '/tmp/testing'
| debug3: secure_filename: terminating check at '/tmp/testing'
| debug1: matching key found: file /tmp/testing/.ssh/authorized_keys, line 1
| Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
| debug1: restore_uid: 0/0
| debug1: ssh_rsa_verify: signature correct
| debug2: Starting PAM service sshd-pubkey for method publickey
| debug3: Trying to reverse map address 10.0.3.115.
| debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
| Failed publickey for testing from 10.0.3.115 port 56651 ssh2
| debug1: userauth-request for user testing service ssh-connection method keyboard-interactive
| debug1: attempt 3 initial attempt 0 failures 3 initial failures 0
| debug2: input_userauth_request: try method keyboard-interactive
| debug1: keyboard-interactive devs 
| debug2: Starting PAM service sshd-kbdint for method keyboard-interactive
| debug2: Calling pam_authenticate()
| debug2: PAM echo off prompt: Password: 
| debug2: Nesting dispatch_run loop
`----

Now the session for a working user:

,----[ ssh -Cv -l askwar -p 65022 winds06, working user ]
| OpenSSH_4.6p1-hpn12v17, OpenSSL 0.9.8e 23 Feb 2007
| debug1: Reading configuration data /home/askwar/.ssh/config
| debug1: Reading configuration data /etc/ssh/ssh_config
| debug1: Connecting to winds06 [10.0.1.26] port 65022.
| debug1: Connection established.
| debug1: identity file /home/askwar/.ssh/identity type -1
| debug1: identity file /home/askwar/.ssh/id_rsa type 1
| debug1: identity file /home/askwar/.ssh/id_dsa type -1
| debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
| debug1: no match: Sun_SSH_1.1
| debug1: Enabling compatibility mode for protocol 2.0
| debug1: Local version string SSH-2.0-OpenSSH_4.6p1-hpn12v17
| debug1: SSH2_MSG_KEXINIT sent
| debug1: SSH2_MSG_KEXINIT received
| debug1: kex: server->client aes128-cbc hmac-md5 zlib
| debug1: kex: client->server aes128-cbc hmac-md5 zlib
| 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 '[winds06]:65022' is known and matches the RSA host key.
| debug1: Found key in /home/askwar/.ssh/known_hosts:25
| debug1: ssh_rsa_verify: signature correct
| debug1: Enabling compression at level 6.
| 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: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
| debug1: Next authentication method: publickey
| debug1: Offering public key: /home/askwar/.ssh/id_rsa
| debug1: Server accepts key: pkalg ssh-rsa blen 277
| debug1: Authentication succeeded (publickey).
| debug1: socksize 262142
| debug1: MIN of TCP RWIN and HPNBufferSize: 262142
| debug1: Final hpn_buffer_size = 262142
| debug1: channel 0: new [client-session]
| debug1: Entering interactive session.
| debug1: Requesting X11 forwarding with authentication spoofing.
| debug1: Requesting authentication agent forwarding.
| debug3: Recording SSHv2 channel login in utmpx/wtmpx
| Last login: Wed Aug 15 09:30:18 2007 from winnb000488.win
| debug3: child_set_env(USER, askwar)
| debug3: child_set_env(LOGNAME, askwar)
| debug3: child_set_env(HOME, /export/home/askwar)
| debug3: child_set_env(PATH, /usr/bin)
| debug3: child_set_env(MAIL, /var/mail//askwar)
| debug3: child_set_env(SHELL, /opt/csw/bin/bash)
| debug3: child_set_env(PATH, /opt/csw/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin)
| debug3: child_set_env(SHELL, /opt/csw/bin/bash)
| debug3: child_set_env(TZ, Europe/Zurich)
| debug3: child_set_env(LANG, de_CH)
| debug3: child_set_env(SSH_CLIENT, 10.0.3.115 43561 65022)
| debug3: child_set_env(SSH_CONNECTION, 10.0.3.115 43561 10.0.1.26 65022)
| debug3: child_set_env(SSH_TTY, /dev/pts/15)
| debug3: child_set_env(TERM, xterm)
| debug3: child_set_env(DISPLAY, localhost:14.0)
| debug3: child_set_env(SSH_AUTH_SOCK, /tmp/ssh-GZH20790/agent.20790)
| Environment:
|   USER=askwar
|   LOGNAME=askwar
|   HOME=/export/home/askwar
|   PATH=/opt/csw/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin
|   MAIL=/var/mail//askwar
|   SHELL=/opt/csw/bin/bash
|   TZ=Europe/Zurich
|   LANG=de_CH
|   SSH_CLIENT=10.0.3.115 43561 65022
|   SSH_CONNECTION=10.0.3.115 43561 10.0.1.26 65022
|   SSH_TTY=/dev/pts/15
|   TERM=xterm
|   DISPLAY=localhost:14.0
|   SSH_AUTH_SOCK=/tmp/ssh-GZH20790/agent.20790
| debug3: channel_close_fds: channel 0: r -1 w -1 e -1
| debug3: channel_close_fds: channel 1: r 12 w 12 e -1
| debug3: channel_close_fds: channel 2: r 13 w 13 e -1
| Running /usr/openwin/bin/xauth add unix:14.0 MIT-MAGIC-COOKIE-1 b89f5cdfc83208643d2b074edda2166f
| debug1: Received SIGCHLD.
| #----------------------------#
| #  RACE Developement Server  #
| #----------------------------#
| --(askwar at winds06)-(1/pts/15)-(09:39:41/2007-08-15)--
| --($:~)-- 
`----


,----[ sudo /usr/lib/ssh/sshd -Dddd -f /etc/ssh/sshd_config, working user ]
| debug1: sshd version Sun_SSH_1.1
| debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
| debug1: read PEM private key done: type RSA
| debug1: private host key: #0 type 1 RSA
| debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
| debug1: read PEM private key done: type DSA
| debug1: private host key: #1 type 2 DSA
| debug1: Bind to port 65022 on ::.
| Server listening on :: port 65022.
| debug1: Server will not fork when running in debugging mode.
| Connection from 10.0.3.115 port 43561
| debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1-hpn12v17
| debug1: match: OpenSSH_4.6p1-hpn12v17 pat OpenSSH*
| debug1: Enabling compatibility mode for protocol 2.0
| debug1: Local version string SSH-2.0-Sun_SSH_1.1
| debug1: list_hostkey_types: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
| debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: first_kex_follows 0 
| debug2: kex_parse_kexinit: reserved 0 
| debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
| Unknown code 0
| )
| debug1: SSH2_MSG_KEXINIT sent
| debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
| debug1: SSH2_MSG_KEXINIT received
| debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
| debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: none,zlib
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug2: kex_parse_kexinit: first_kex_follows 0 
| debug2: kex_parse_kexinit: reserved 0 
| debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
| debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
| debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
| debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
| debug2: kex_parse_kexinit: zlib at openssh.com,zlib,none
| debug2: kex_parse_kexinit: zlib at openssh.com,zlib,none
| debug2: kex_parse_kexinit: 
| debug2: kex_parse_kexinit: 
| debug2: kex_parse_kexinit: first_kex_follows 0 
| debug2: kex_parse_kexinit: reserved 0 
| debug2: mac_init: found hmac-md5
| debug1: kex: client->server aes128-cbc hmac-md5 zlib
| debug2: mac_init: found hmac-md5
| debug1: kex: server->client aes128-cbc hmac-md5 zlib
| debug1: Peer sent proposed langtags, ctos: 
| debug1: Peer sent proposed langtags, stoc: 
| debug1: We proposed langtags, ctos: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug1: We proposed langtags, stoc: ar-EG,ar-SA,cs-CZ,de,de-DE,en-US,es,es-ES,fi-FI,fr,fr-BE,fr-FR,he-IL,hi-IN,hu-HU,it,it-IT,ja-JP,ko,ko-KR,pl,pl-PL,pt-BR,ru,ru-RU,sv,sv-SE,th-TH,tr-TR,zh,zh-CN,zh-HK,zh-TW,ar,bg-BG,ca,ca-ES,cz,da,da-DK,de-AT,de-CH,el,el-GR,en-AU,en-CA,en-GB,en-IE,en-NZ,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et,et-EE,fi,fr-CA,fr-CH,he,hr-HR,hu,is-IS,ja,lt,lt-LT,lv,lv-LV,mk-MK,nl,nl-BE,nl-NL,no,no-NO,no-NY,nr,pt,pt-PT,ro-RO,sh-BA,sk-SK,sl-SI,sq-AL,sr-SP,sr-YU,th,tr,i-default
| debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
| debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
| debug1: dh_gen_key: priv key bits set: 124/256
| debug1: bits set: 484/1024
| debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
| debug1: bits set: 526/1024
| debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
| debug2: kex_derive_keys
| debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
| debug1: newkeys: mode 1
| debug1: Enabling compression at level 6.
| debug1: SSH2_MSG_NEWKEYS sent
| debug1: expecting SSH2_MSG_NEWKEYS
| debug1: newkeys: mode 0
| debug1: SSH2_MSG_NEWKEYS received
| debug1: KEX done
| debug1: userauth-request for user askwar service ssh-connection method none
| debug1: attempt 0 initial attempt 0 failures 0 initial failures 0
| debug2: input_userauth_request: setting up authctxt for askwar
| debug2: input_userauth_request: try method none
| Failed none for askwar from 10.0.3.115 port 43561 ssh2
| debug1: userauth-request for user askwar service ssh-connection method publickey
| debug1: attempt 1 initial attempt 0 failures 1 initial failures 0
| debug2: input_userauth_request: try method publickey
| debug1: test whether pkalg/pkblob are acceptable
| debug1: temporarily_use_uid: 10001/10 (e=0/0)
| debug1: trying public key file /export/home/askwar/.ssh/authorized_keys
| debug3: secure_filename: checking '/u04/home/askwar/.ssh'
| debug3: secure_filename: checking '/u04/home/askwar'
| debug3: secure_filename: terminating check at '/u04/home/askwar'
| debug1: matching key found: file /export/home/askwar/.ssh/authorized_keys, line 2
| Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
| debug1: restore_uid: 0/0
| debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
| debug1: userauth-request for user askwar service ssh-connection method publickey
| debug1: attempt 2 initial attempt 0 failures 1 initial failures 0
| debug2: input_userauth_request: try method publickey
| debug1: temporarily_use_uid: 10001/10 (e=0/0)
| debug1: trying public key file /export/home/askwar/.ssh/authorized_keys
| debug3: secure_filename: checking '/u04/home/askwar/.ssh'
| debug3: secure_filename: checking '/u04/home/askwar'
| debug3: secure_filename: terminating check at '/u04/home/askwar'
| debug1: matching key found: file /export/home/askwar/.ssh/authorized_keys, line 2
| Found matching RSA key: 42:1b:5b:46:12:a2:78:4d:7c:fc:b8:5a:a5:49:b9:e1
| debug1: restore_uid: 0/0
| debug1: ssh_rsa_verify: signature correct
| debug2: Starting PAM service sshd-pubkey for method publickey
| debug3: Trying to reverse map address 10.0.3.115.
| debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa
| Accepted publickey for askwar from 10.0.3.115 port 43561 ssh2
| debug2: Monitor pid 20763, unprivileged child pid 20790
| debug2: Monitor started
| monitor debug3: Recording SSHv2 session login in wtmpx
| monitor debug3: not writing utmpx entry
| monitor debug1: Entering monitor loop.
| monitor debug1: compress outgoing: raw data 385, compressed 384, factor 1,00
| monitor debug1: compress incoming: raw data 999, compressed 648, factor 0,65
| monitor debug1: fd 4 setting O_NONBLOCK
| monitor debug1: fd 12 setting O_NONBLOCK
| debug2: Waiting for monitor
| debug2: Monitor signalled readiness
| debug3: Setting handler to forward re-key packets to monitor
| debug2: Unprivileged server process dropping privileges
| debug1: permanently_set_uid: 10001/10
| debug1: Entering interactive session for SSH2.
| debug1: fd 9 setting O_NONBLOCK
| debug1: fd 11 setting O_NONBLOCK
| debug1: server_init_dispatch_20
| debug3: server_init_dispatch_20 -- should we dispatch_set(KEXINIT) here? 1 && !0
| debug3: server_init_dispatch_20 -- skipping dispatch_set(KEXINIT) in unpriv proc
| debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
| debug1: input_session_request
| debug1: channel 0: new [server-session]
| debug1: session_new: init
| debug1: session_new: session 0
| debug1: session_open: channel 0
| debug1: session_open: session 0: link with channel 0
| debug1: server_input_channel_open: confirm session
| debug1: server_input_channel_req: channel 0 request x11-req reply 0
| debug1: session_by_channel: session 0 channel 0
| debug1: session_input_channel_req: session 0 req x11-req
| debug1: bind port 6010: Cannot assign requested address
| debug1: bind port 6010: Address already in use
| debug1: bind port 6011: Cannot assign requested address
| debug1: bind port 6011: Address already in use
| debug1: bind port 6012: Cannot assign requested address
| debug1: bind port 6012: Address already in use
| debug1: bind port 6013: Cannot assign requested address
| debug1: bind port 6013: Address already in use
| debug1: bind port 6014: Cannot assign requested address
| debug1: fd 12 setting O_NONBLOCK
| debug2: fd 12 is O_NONBLOCK
| debug1: channel 1: new [X11 inet listener]
| debug1: server_input_channel_req: channel 0 request auth-agent-req at openssh.com reply 0
| debug1: session_by_channel: session 0 channel 0
| debug1: session_input_channel_req: session 0 req auth-agent-req at openssh.com
| debug1: temporarily_use_uid: 10001/10 (e=10001/10)
| debug1: restore_uid: (unprivileged)
| debug1: fd 13 setting O_NONBLOCK
| debug2: fd 13 is O_NONBLOCK
| debug1: channel 2: new [auth socket]
| debug1: server_input_channel_req: channel 0 request pty-req reply 0
| debug1: session_by_channel: session 0 channel 0
| debug1: session_input_channel_req: session 0 req pty-req
| debug1: Allocating pty.
| debug1: session_pty_req: session 0 alloc /dev/pts/15
| debug3: tty_parse_modes: SSH2 n_bytes 256
| debug3: tty_parse_modes: ospeed 38400
| debug3: tty_parse_modes: ispeed 38400
| debug3: tty_parse_modes: 1 3
| debug3: tty_parse_modes: 2 28
| debug3: tty_parse_modes: 3 127
| debug3: tty_parse_modes: 4 21
| debug3: tty_parse_modes: 5 4
| debug3: tty_parse_modes: 6 255
| debug3: tty_parse_modes: 7 255
| debug3: tty_parse_modes: 8 17
| debug3: tty_parse_modes: 9 19
| debug3: tty_parse_modes: 10 26
| debug3: tty_parse_modes: 12 18
| debug3: tty_parse_modes: 13 23
| debug3: tty_parse_modes: 14 22
| debug3: tty_parse_modes: 18 15
| debug3: tty_parse_modes: 30 0
| debug3: tty_parse_modes: 31 0
| debug3: tty_parse_modes: 32 0
| debug3: tty_parse_modes: 33 0
| debug3: tty_parse_modes: 34 0
| debug3: tty_parse_modes: 35 0
| debug3: tty_parse_modes: 36 1
| debug3: tty_parse_modes: 37 0
| debug3: tty_parse_modes: 38 1
| debug3: tty_parse_modes: 39 1
| debug3: tty_parse_modes: 40 0
| debug3: tty_parse_modes: 41 1
| debug3: tty_parse_modes: 50 1
| debug3: tty_parse_modes: 51 1
| debug3: tty_parse_modes: 52 0
| debug3: tty_parse_modes: 53 1
| debug3: tty_parse_modes: 54 1
| debug3: tty_parse_modes: 55 1
| debug3: tty_parse_modes: 56 0
| debug3: tty_parse_modes: 57 0
| debug3: tty_parse_modes: 58 0
| debug3: tty_parse_modes: 59 1
| debug3: tty_parse_modes: 60 1
| debug3: tty_parse_modes: 61 1
| debug3: tty_parse_modes: 62 0
| debug3: tty_parse_modes: 70 1
| debug3: tty_parse_modes: 71 0
| debug3: tty_parse_modes: 72 1
| debug3: tty_parse_modes: 73 0
| debug3: tty_parse_modes: 74 0
| debug3: tty_parse_modes: 75 0
| debug3: tty_parse_modes: 90 1
| debug3: tty_parse_modes: 91 1
| debug3: tty_parse_modes: 92 0
| debug3: tty_parse_modes: 93 0
| debug1: server_input_channel_req: channel 0 request shell reply 0
| debug1: session_by_channel: session 0 channel 0
| debug1: session_input_channel_req: session 0 req shell
| monitor debug3: writing utmpx entry
| debug1: fd 4 setting TCP_NODELAY
| debug1: fd 15 setting O_NONBLOCK
| debug2: fd 14 is O_NONBLOCK
| debug3: channel_set_wait_for_exit 0, 1 (type: 4)
`----


Confused.

Alexander Skwar


From Jefferson.Ogata at noaa.gov  Wed Aug 15 17:53:40 2007
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Wed, 15 Aug 2007 07:53:40 +0000
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org>
	<1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>
Message-ID: <46C2B104.6010307@noaa.gov>

On 2007-08-15 06:52, Alexander Skwar wrote:
> I doubt that. In LDAP, there's no difference between the non-working
> users and the working users. At least not, as far as I can tell.

Are you sure you're dumping all the attributes? Many LDAP servers don't
dump certain attributes by default. Safest bet is to compare an actual
dump export from the LDAP server, rather than the result of running
ldapsearch. Failing that, specify '*' and '+' as attributes to dump, and
be sure you're authenticating as a directory manager when you do your
ldapearch.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service

From listen at alexander.skwar.name  Wed Aug 15 18:24:29 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Wed, 15 Aug 2007 10:24:29 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org>
	<1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>
	<46C2B104.6010307@noaa.gov>
Message-ID: <2314816.F1exLrlWZM@kn.gn.rtr.message-center.info>

Jefferson Ogata <Jefferson.Ogata at noaa.gov> wrote:

> On 2007-08-15 06:52, Alexander Skwar wrote:
>> I doubt that. In LDAP, there's no difference between the non-working
>> users and the working users. At least not, as far as I can tell.
> 
> Are you sure you're dumping all the attributes?

No. But I'm sure that I'm importing all the attributes :) As
written elsewhere in this thread - initially, I filled the
database with the help of PADL MigrationTools. This converted
/etc/passwd to ldif format. I then ran ldapadd to add the ldif
file to the LDAP database.

That's what I did this time as well for the testing user.

> Many LDAP servers don't 
> dump certain attributes by default. Safest bet is to compare an actual
> dump export from the LDAP server, rather than the result of running
> ldapsearch.

You mean, that I should compare the output of slapcat? You're
right. And I did that. No difference.

,----[ differences between user entries, diff -u ]
| --- askwar.ldif Mit Aug 15 10:17:54 2007
| +++ testing.ldif        Mit Aug 15 10:18:09 2007
| @@ -1,9 +1,9 @@
| -dn: uid=askwar,ou=People,ou=RACE,o=Example
| -uid: askwar
| -cn: Alexander Skwar
| +dn: uid=testing,ou=People,ou=RACE,o=Example
| +uid: testing
| +cn: Testing User
|  roomNumber: alexander.skwar at Exampleauto.com
| -givenName: Alexander
| -sn: Skwar
| +givenName: Testing
| +sn: User
|  mail: askwar at win.ch.da.rtr
|  mailRoutingAddress: askwar at mail1.Exampleauto.com
|  mailHost: mail1.Exampleauto.com
| @@ -19,17 +19,17 @@
|  shadowLastChange: 13503
|  loginShell: /opt/csw/bin/bash
|  gidNumber: 10
| -homeDirectory: /export/home/askwar
| +homeDirectory: /tmp/testing
|  gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
| -structuralObjectClass: inetOrgPerson
| -entryUUID: 731c4ae2-76e2-102b-929e-898e4be004d5
| -creatorsName: cn=Admin,ou=RACE,o=Example
| -createTimestamp: 20070404102443Z
|  host: winnb000488
|  host: winnb000488.win.ch.da.rtr
|  host: winds06
|  host: winds06.win.ch.da.rtr
| -uidNumber: 10001
| -entryCSN: 20070412121522Z#000000#00#000000
| +uidNumber: 54321
| +structuralObjectClass: inetOrgPerson
| +entryUUID: 7634ba72-df45-102b-981d-216a382f8806
| +creatorsName: cn=Admin,ou=RACE,o=Example
| +createTimestamp: 20070815063530Z
| +entryCSN: 20070815063530Z#000000#00#000000
|  modifiersName: cn=Admin,ou=RACE,o=Example
| -modifyTimestamp: 20070412121522Z
| +modifyTimestamp: 20070815063530Z
`----

No relevant differences :/ "askwar" is the working user, "testing"
is the non-working user.

Thanks again,
Alexander Skwar


From dtucker at zip.com.au  Thu Aug 16 00:28:32 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 16 Aug 2007 00:28:32 +1000
Subject: OpenSSH 4.7: call for testing.
Message-ID: <46C30D90.3000306@zip.com.au>

Hi All.

OpenSSH 4.7 is preparing for release so we are asking for any interested 
folks to please test a snapshot. The main changes are:

  * sshd(8) in new installations defaults to SSH Protocol 2 only.
    Existing installations are unchanged.

  * The SSH channel window size has been increased, which improves
    performance on high-BDP networks.

  * ssh(1) and sshd(8) now preserve MAC contexts between packets, which
    saves 2 hash calls per packet and results in 12-16% speedup for
    arcfour256/hmac-md5.

  * A new MAC algorithm has been added, UMAC-64 (RFC4418) which is
    approximately 20% faster than HMAC-MD5.

  * A -K flag was added to ssh(1) to set GSSAPIAuthentication=Yes

#616: proxycommand breaks hostbased authentication.
#856: scp hangs on FIFOs rather than erroring
#891: possible problem with non-printing characters during scp copy
#1196: SIGINT is ignored by SSHD in case of privilegeseparation yes
#1220: Fix error messages for multiple mechanism GSSAPI libraries
#1224: ssh-add man page does not fully describe -d
#1225: Tidy up GSSAPI code
#1232: "LocalCommand" is executed before session is set up
#1236: SCP inappropriate truncate error when copying to FIFO file
#1261: Timed out command through ControlMaster yields 0 return value.
#1286: SFTP keeps reading input until it runs out of buffer space

#1243: Multiple including of paths.h on AIX 5.1 systems.
#1262: ssh disconnect message from master control is confusing
#1287: Use getpeerucred on Solaris
#1294: includes.h should pull in string.h based on HAVE_STRING_H
#1299: Remove redefinition of _res in getrrsetbyname.c
#1306: Spurious : "chan_read_failed for istate 3" errors from sshd
#1325: SELinux support broken when SELinux is in permissive mode
#1339: pam_dhkeys doesn't work
#1343: Privilege separation does not work on QNX

There is also #1322 (pam_abl) which has not been applied, but I'm not 
sure about that one (so if you use PAM, please try the latest patch from 
that bug, even if you don't use pam_abl or equivalent).

Thanks to all who contributed.

More detail may be found in the ChangeLog in the portable OpenSSH
tarballs.

The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html

Portable snapshots are available at:
http://www.mindrot.org/openssh_snap/

Running the regression tests supplied with Portable does not require
installation and is a simply:

$ ./configure && make tests

Testing on suitable non-production systems is also appreciated.
Please send reports of success or failure to
openssh-unix-dev at mindrot.org.

Thanks.

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

From deengert at anl.gov  Thu Aug 16 01:47:59 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Wed, 15 Aug 2007 10:47:59 -0500
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <2314816.F1exLrlWZM@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>	<46C2B104.6010307@noaa.gov>
	<2314816.F1exLrlWZM@kn.gn.rtr.message-center.info>
Message-ID: <46C3202F.60902@anl.gov>

Solaris 10 has a ldaplist command, that will use all the same
Solaris libs and files to access ldap as the Solaris pam does.

Try running as a user and then as root these commands:

  ldaplist -l passwd askwar
  ldaplist -l passwd testing

It might show something, like the account is locked...


Alexander Skwar wrote:
> Jefferson Ogata <Jefferson.Ogata at noaa.gov> wrote:
> 
>> On 2007-08-15 06:52, Alexander Skwar wrote:
>>> I doubt that. In LDAP, there's no difference between the non-working
>>> users and the working users. At least not, as far as I can tell.
>> Are you sure you're dumping all the attributes?
> 
> No. But I'm sure that I'm importing all the attributes :) As
> written elsewhere in this thread - initially, I filled the
> database with the help of PADL MigrationTools. This converted
> /etc/passwd to ldif format. I then ran ldapadd to add the ldif
> file to the LDAP database.
> 
> That's what I did this time as well for the testing user.
> 
>> Many LDAP servers don't 
>> dump certain attributes by default. Safest bet is to compare an actual
>> dump export from the LDAP server, rather than the result of running
>> ldapsearch.
> 
> You mean, that I should compare the output of slapcat? You're
> right. And I did that. No difference.
> 
> ,----[ differences between user entries, diff -u ]
> | --- askwar.ldif Mit Aug 15 10:17:54 2007
> | +++ testing.ldif        Mit Aug 15 10:18:09 2007
> | @@ -1,9 +1,9 @@
> | -dn: uid=askwar,ou=People,ou=RACE,o=Example
> | -uid: askwar
> | -cn: Alexander Skwar
> | +dn: uid=testing,ou=People,ou=RACE,o=Example
> | +uid: testing
> | +cn: Testing User
> |  roomNumber: alexander.skwar at Exampleauto.com
> | -givenName: Alexander
> | -sn: Skwar
> | +givenName: Testing
> | +sn: User
> |  mail: askwar at win.ch.da.rtr
> |  mailRoutingAddress: askwar at mail1.Exampleauto.com
> |  mailHost: mail1.Exampleauto.com
> | @@ -19,17 +19,17 @@
> |  shadowLastChange: 13503
> |  loginShell: /opt/csw/bin/bash
> |  gidNumber: 10
> | -homeDirectory: /export/home/askwar
> | +homeDirectory: /tmp/testing
> |  gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
> | -structuralObjectClass: inetOrgPerson
> | -entryUUID: 731c4ae2-76e2-102b-929e-898e4be004d5
> | -creatorsName: cn=Admin,ou=RACE,o=Example
> | -createTimestamp: 20070404102443Z
> |  host: winnb000488
> |  host: winnb000488.win.ch.da.rtr
> |  host: winds06
> |  host: winds06.win.ch.da.rtr
> | -uidNumber: 10001
> | -entryCSN: 20070412121522Z#000000#00#000000
> | +uidNumber: 54321
> | +structuralObjectClass: inetOrgPerson
> | +entryUUID: 7634ba72-df45-102b-981d-216a382f8806
> | +creatorsName: cn=Admin,ou=RACE,o=Example
> | +createTimestamp: 20070815063530Z
> | +entryCSN: 20070815063530Z#000000#00#000000
> |  modifiersName: cn=Admin,ou=RACE,o=Example
> | -modifyTimestamp: 20070412121522Z
> | +modifyTimestamp: 20070815063530Z
> `----
> 
> No relevant differences :/ "askwar" is the working user, "testing"
> is the non-working user.
> 
> Thanks again,
> Alexander Skwar
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.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 vinschen at redhat.com  Thu Aug 16 01:38:54 2007
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 15 Aug 2007 17:38:54 +0200
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <20070815153854.GC28407@calimero.vinschen.de>

On Aug 16 00:28, Darren Tucker wrote:
> Hi All.
> 
> OpenSSH 4.7 is preparing for release so we are asking for any interested 
> folks to please test a snapshot. The main changes are:

Builds OOTB on Cygwin.  Testsuite runs fine.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From listen at alexander.skwar.name  Thu Aug 16 03:05:51 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Wed, 15 Aug 2007 19:05:51 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>	<46C2B104.6010307@noaa.gov>
	<2314816.F1exLrlWZM@kn.gn.rtr.message-center.info>
	<46C3202F.60902@anl.gov>
Message-ID: <1204003.mUVGSWiZzo@kn.gn.rtr.message-center.info>

Douglas E. Engert <deengert at anl.gov> wrote:

> Solaris 10 has a ldaplist command, that will use all the same
> Solaris libs and files to access ldap as the Solaris pam does.
> 
> Try running as a user and then as root these commands:
> 
>   ldaplist -l passwd askwar
>   ldaplist -l passwd testing
> 
> It might show something, like the account is locked...

Thanks, I forgot about the ldaplist command!

But it also doesn't show anything interesting :(

--($:~)-- diff -u ldaplist.*
--- ldaplist.askwar     Mit Aug 15 19:01:45 2007
+++ ldaplist.testing    Mit Aug 15 19:01:50 2007
@@ -1,9 +1,9 @@
-dn: uid=askwar,ou=People,ou=RACE,o=Example
-       uid: askwar
-       cn: Alexander Skwar
+dn: uid=testing,ou=People,ou=RACE,o=Example
+       uid: testing
+       cn: Testing User
        roomNumber: alexander.skwar at Exampleauto.com
-       givenName: Alexander
-       sn: Skwar
+       givenName: Testing
+       sn: User
        mail: askwar at win.ch.da.rtr
        mailRoutingAddress: askwar at mail1.Exampleauto.com
        mailHost: mail1.Exampleauto.com
@@ -18,10 +18,10 @@
        shadowLastChange: 13503
        loginShell: /opt/csw/bin/bash
        gidNumber: 10
-       homeDirectory: /export/home/askwar
+       homeDirectory: /tmp/testing
        gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
        host: winnb000488
        host: winnb000488.win.ch.da.rtr
        host: winds06
        host: winds06.win.ch.da.rtr
-       uidNumber: 10001
+       uidNumber: 54321


:(

Alexander Skwar


From rapier at psc.edu  Thu Aug 16 03:11:21 2007
From: rapier at psc.edu (Chris Rapier)
Date: Wed, 15 Aug 2007 13:11:21 -0400
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <46C333B9.4030705@psc.edu>



Darren Tucker wrote:

>   * The SSH channel window size has been increased, which improves
>     performance on high-BDP networks.


While I'm a fan of larger buffers I'm also leery of arbitrarily 
increasing buffer sizes statically. While a larger buffer will help in 
bulk data transfers it can be a hindrance in other situations. In this 
case I'm mostly concerned about issues relating to overbuffering in 
interactive sessions. Has the dev team looked at this?

BTW:

builds and tests fine under OS X 10.4.10
(Darwin 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 
2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh unknown 
PowerBook6,4 Darwin)

And linux 2.6.16
Linux 2.6.16-web100 #1 SMP Wed Feb 7 09:59:18 EST 2007 i686 i686 i386 
GNU/Linux


From gert at greenie.muc.de  Thu Aug 16 06:23:13 2007
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 15 Aug 2007 22:23:13 +0200
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <20070815202313.GD1045@greenie.muc.de>

Hi,

On Thu, Aug 16, 2007 at 12:28:32AM +1000, Darren Tucker wrote:
> OpenSSH 4.7 is preparing for release so we are asking for any interested 
> folks to please test a snapshot. 

Tested on NetBSD 2.0.3_STABLE on Sparc64.

Configures, compiles, and runs "make tests" without complaints.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From lcashdol at gmail.com  Thu Aug 16 06:02:16 2007
From: lcashdol at gmail.com (Larry Cashdollar)
Date: Wed, 15 Aug 2007 16:02:16 -0400
Subject: testing openssh 4.7
Message-ID: <c2134ab30708151302y6715cc97rb7459586b94a23a2@mail.gmail.com>

Compiled and tested on MacOSX  10.4.10.

Darwin vapid.dhs.org 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23
16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386

All appears to work just fine.

From maniac.nl at gmail.com  Thu Aug 16 07:16:31 2007
From: maniac.nl at gmail.com (Mark Janssen)
Date: Wed, 15 Aug 2007 23:16:31 +0200
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <531e3e4c0708151416w5700a46fq76d4a36333edcf82@mail.gmail.com>

On 8/15/07, Darren Tucker <dtucker at zip.com.au> wrote:
> Hi All.
>
> OpenSSH 4.7 is preparing for release so we are asking for any interested
> folks to please test a snapshot. The main changes are:
> Running the regression tests supplied with Portable does not require
> installation and is a simply:
>
> $ ./configure && make tests

All tests succesful on x86_64-unknown-linux-gnu (debian etch)

Well done, and keep up the good work. I'll test on solaris 8/10 in the morning

-- 
Mark Janssen  --  maniac(at)maniac.nl  --  pgp: 0x357D2178 |   ,''`.  |
Unix / Linux Open-Source and Internet Consultant @ Snow.nl |  : :' :  |
Maniac.nl      MarkJanssen.nl      NerdNet.nl      Unix.nl |  `. `'   |
Skype: markmjanssen ICQ: 129696007 irc: FooBar on undernet |    `-    |

From pekkas at netcore.fi  Thu Aug 16 07:37:18 2007
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 16 Aug 2007 00:37:18 +0300 (EEST)
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <Pine.LNX.4.64.0708160035130.12095@netcore.fi>

On Thu, 16 Aug 2007, Darren Tucker wrote:
> Running the regression tests supplied with Portable does not require
> installation and is a simply:
>
> $ ./configure && make tests

On CentOS 5 on i386, I see the following warnings:

mac.c: In function 'mac_compute':
mac.c:131: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
ssh.c: In function 'control_client':
ssh.c:1475: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
readconf.c: In function 'process_config_line':
readconf.c:695: warning: dereferencing type-punned pointer will break strict-aliasing rules
servconf.c: In function 'process_server_config_line':
servconf.c:979: warning: dereferencing type-punned pointer will break strict-aliasing rules
servconf.c:990: warning: dereferencing type-punned pointer will break strict-aliasing rules
sftp.c: In function 'parse_dispatch_command':
sftp.c:1031: warning: 'n_arg' may be used uninitialized in this function
sftp.c:1030: warning: 'iflag' may be used uninitialized in this function
sftp.c:1030: warning: 'lflag' may be used uninitialized in this function
sftp.c:1030: warning: 'pflag' may be used uninitialized in this function

Make tests fails with the following:

...
run test login-timeout.sh ...
ssh: connect to host 127.0.0.1 port 4242: Connection refused
ssh connect after login grace timeout failed without privsep
failed connect after login grace timeout
make[1]: *** [t-exec] Error 1

I ran this as a regular user.  My configure flags were 
--with-tcp-wrappers --with-md5-passwords 
--with-privsep-path=/var/empty/sshd.

HTH..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From dtucker at zip.com.au  Thu Aug 16 08:05:21 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 16 Aug 2007 08:05:21 +1000
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <Pine.LNX.4.64.0708160035130.12095@netcore.fi>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
Message-ID: <46C378A1.3020704@zip.com.au>

Pekka Savola wrote:
> On Thu, 16 Aug 2007, Darren Tucker wrote:
>> Running the regression tests supplied with Portable does not require
>> installation and is a simply:
>>
>> $ ./configure && make tests
> 
> On CentOS 5 on i386, I see the following warnings:
> 
> mac.c: In function 'mac_compute':
> mac.c:131: warning: format '%lu' expects type 'long unsigned int', but 
> argument 3 has type 'unsigned int'
> ssh.c: In function 'control_client':
> ssh.c:1475: warning: format '%lu' expects type 'long unsigned int', but 
> argument 4 has type 'unsigned int'
> readconf.c: In function 'process_config_line':
> readconf.c:695: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> servconf.c: In function 'process_server_config_line':
> servconf.c:979: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> servconf.c:990: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> sftp.c: In function 'parse_dispatch_command':
> sftp.c:1031: warning: 'n_arg' may be used uninitialized in this function
> sftp.c:1030: warning: 'iflag' may be used uninitialized in this function
> sftp.c:1030: warning: 'lflag' may be used uninitialized in this function
> sftp.c:1030: warning: 'pflag' may be used uninitialized in this function

OK there's some warnings in there that we should look at after the 
release.  (Actually someone sent in a fix for those "type-punned 
pointer" warnings but it looks like that slipped through the cracks.)

> Make tests fails with the following:
> ...
> run test login-timeout.sh ...
> ssh: connect to host 127.0.0.1 port 4242: Connection refused
> ssh connect after login grace timeout failed without privsep
> failed connect after login grace timeout
> make[1]: *** [t-exec] Error 1

Does this error happen consistently?  Some of the tests are inherently 
racy, and this is one of them.  There are "sleep" commands sprinkled in 
strategic places but sometimes they're not enough.

Fortunately this is a relatively easy test to simulate:

run "/path/to/sshd -oLoginGraceTime=10s -oLogLevel=debug3-De -p 4242"

from another shell, connect to localhost port 4242 and type 
"SSH-2.0-fake" followed by a newline.

Wait and see if the connection drops after 10 seconds or so, which it 
should.

If/when it does, try logging in with ssh: "ssh -p 4242 localhost" and 
see what happens.

Thanks.

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

From pekkas at netcore.fi  Thu Aug 16 08:50:21 2007
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 16 Aug 2007 01:50:21 +0300 (EEST)
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C378A1.3020704@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
	<46C378A1.3020704@zip.com.au>
Message-ID: <Pine.LNX.4.64.0708160145530.12978@netcore.fi>

On Thu, 16 Aug 2007, Darren Tucker wrote:
>>  run test login-timeout.sh ...
>>  ssh: connect to host 127.0.0.1 port 4242: Connection refused
>>  ssh connect after login grace timeout failed without privsep
>>  failed connect after login grace timeout
>>  make[1]: *** [t-exec] Error 1
>
> Does this error happen consistently?  Some of the tests are inherently racy, 
> and this is one of them.  There are "sleep" commands sprinkled in strategic 
> places but sometimes they're not enough.

Yes, this seems to work when I retry it, as well as manually.

There is also later an issue with terminating forwarding connections, 
but I recall you debugged this already 6-12 months ago (then the 
system was RHL73 though) and couldn't reproduce it.  So this certainly 
shouldn't be a recent problem.  With tracing enabled, the output is:

start dynamic forwarding, fork to background
testing ssh protocol 1 socks version 4 host 127.0.0.1
testing ssh protocol 1 socks version 4 host localhost
testing ssh protocol 1 socks version 5 host 127.0.0.1
testing ssh protocol 1 socks version 5 host localhost
terminate remote shell, pid 23878
Waiting for forwarded connections to terminate...
The following connections are open:
   #1 direct-tcpip: listening port 4243 for localhost port 4242, connect from 127.0.0.1 port 36834 (t4 r3 i0/0 o0/0 fd 10/10 cfd -1)
start dynamic forwarding, fork to background
testing ssh protocol 2 socks version 4 host 127.0.0.1
testing ssh protocol 2 socks version 4 host localhost
testing ssh protocol 2 socks version 5 host 127.0.0.1
testing ssh protocol 2 socks version 5 host localhost
terminate remote shell, pid 23999
ok dynamic forwarding
run test forwarding.sh ...
generate keys
wait for sshd
start forwarding, fork to background
transfer over forwarded channels and check result
Waiting for forwarded connections to terminate...
The following connections are open:
   #9 direct-tcpip: listening port 3322 for 127.0.0.1 port 3372, connect from 127.0.0.1 port 35217 (t4 r17 i0/0 o0/0 fd 18/18 cfd -1)
   #10 direct-tcpip: listening port 3372 for 127.0.0.1 port 3321, connect from 127.0.0.1 port 53576 (t4 r18 i0/0 o0/0 fd 19/19 cfd -1)
   #11 direct-tcpip: listening port 3321 for 127.0.0.1 port 3371, connect from 127.0.0.1 port 48490 (t4 r19 i0/0 o0/0 fd 20/20 cfd -1)
   #12 direct-tcpip: listening port 3371 for 127.0.0.1 port 3320, connect from 127.0.0.1 port 37830 (t4 r20 i0/0 o0/0 fd 21/21 cfd -1)
   #13 direct-tcpip: listening port 3320 for 127.0.0.1 port 3370, connect from 127.0.0.1 port 36249 (t4 r21 i0/0 o0/0 fd 22/22 cfd -1)
   #14 direct-tcpip: listening port 3370 for 127.0.0.1 port 3312, connect from 127.0.0.1 port 60096 (t4 r22 i0/0 o0/0 fd 23/23 cfd -1)
   #15 direct-tcpip: listening port 3312 for 127.0.0.1 port 3362, connect from 127.0.0.1 port 60657 (t4 r23 i0/0 o0/0 fd 24/24 cfd -1)
   #16 direct-tcpip: listening port 3362 for 127.0.0.1 port 3311, connect from 127.0.0.1 port 55516 (t4 r24 i0/0 o0/0 fd 25/25 cfd -1)
   #17 direct-tcpip: listening port 3311 for 127.0.0.1 port 3361, connect from 127.0.0.1 port 50091 (t4 r25 i0/0 o0/0 fd 26/26 cfd -1)
   #18 direct-tcpip: listening port 3361 for 127.0.0.1 port 3310, connect from 127.0.0.1 port 33918 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1)
[[ very long wait here, and indeed netstat -an shows all these sessions as ESTABLISHED ]]
ssh_exchange_identification: Connection closed by remote host
cmp: EOF on /home/pekkas/tt/openssh/regress/ls.copy
corrupted copy of /bin/ls
start forwarding, fork to background
transfer over forwarded channels and check result
[[ pretty long wait here ]]
ssh_exchange_identification: Connection closed by remote host
cmp: EOF on /home/pekkas/tt/openssh/regress/ls.copy
corrupted copy of /bin/ls
exit on -L forward failure, proto 1
exit on -R forward failure, proto 1
exit on -L forward failure, proto 2
exit on -R forward failure, proto 2
simple clear forwarding proto 1
clear local forward proto 1
clear remote forward proto 1
simple clear forwarding proto 2
clear local forward proto 2
clear remote forward proto 2
failed local and remote forwarding
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/home/pekkas/tt/openssh/regress'
make: *** [tests] Error 2

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From imorgan at nas.nasa.gov  Thu Aug 16 08:21:48 2007
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 15 Aug 2007 15:21:48 -0700
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C333B9.4030705@psc.edu>
References: <46C30D90.3000306@zip.com.au> <46C333B9.4030705@psc.edu>
Message-ID: <20070815222148.GA28906@linux55.nas.nasa.gov>

On Wed, Aug 15, 2007 at 13:11:21 -0400, Chris Rapier wrote:
> 
> 
> Darren Tucker wrote:
> 
> >   * The SSH channel window size has been increased, which improves
> >     performance on high-BDP networks.
> 
> 
> While I'm a fan of larger buffers I'm also leery of arbitrarily 
> increasing buffer sizes statically. While a larger buffer will help in 
> bulk data transfers it can be a hindrance in other situations. In this 
> case I'm mostly concerned about issues relating to overbuffering in 
> interactive sessions. Has the dev team looked at this?
> 

We've been using the patch that Markus originally posted on this
list back in 2005 on a number of systems for over a year and have
not observed any issues with interactive sessions. Admittedly,
that patch set the channel buffer to 1.25 MB rather than 2MB.

-- 
Iain Morgan

From dtucker at zip.com.au  Thu Aug 16 09:17:08 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 16 Aug 2007 09:17:08 +1000
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <Pine.LNX.4.64.0708160145530.12978@netcore.fi>
References: <46C30D90.3000306@zip.com.au>	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>	<46C378A1.3020704@zip.com.au>
	<Pine.LNX.4.64.0708160145530.12978@netcore.fi>
Message-ID: <46C38974.9020607@zip.com.au>

Pekka Savola wrote:
> On Thu, 16 Aug 2007, Darren Tucker wrote:
>>>  run test login-timeout.sh ...
>>>  ssh: connect to host 127.0.0.1 port 4242: Connection refused
>>>  ssh connect after login grace timeout failed without privsep
>>>  failed connect after login grace timeout
>>>  make[1]: *** [t-exec] Error 1
>> Does this error happen consistently?  Some of the tests are inherently racy, 
>> and this is one of them.  There are "sleep" commands sprinkled in strategic 
>> places but sometimes they're not enough.
> 
> Yes, this seems to work when I retry it, as well as manually.
> 
> There is also later an issue with terminating forwarding connections, 
> but I recall you debugged this already 6-12 months ago (then the 
> system was RHL73 though) and couldn't reproduce it.  So this certainly 
> shouldn't be a recent problem.  With tracing enabled, the output is:

This can happen if you have something that uses the port ranges that the 
regress tests assume will be free (33xx).  I have had problems with 
ClamAV's clamd which by default uses a port in that range.

-- 
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 ldv at altlinux.org  Thu Aug 16 08:26:49 2007
From: ldv at altlinux.org (Dmitry V. Levin)
Date: Thu, 16 Aug 2007 02:26:49 +0400
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C378A1.3020704@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
	<46C378A1.3020704@zip.com.au>
Message-ID: <20070815222649.GA27860@basalt.office.altlinux.org>

On Thu, Aug 16, 2007 at 08:05:21AM +1000, Darren Tucker wrote:
[...]
> OK there's some warnings in there that we should look at after the 
> release.  (Actually someone sent in a fix for those "type-punned 
> pointer" warnings but it looks like that slipped through the cracks.)

http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-April/025274.html


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

From dtucker at zip.com.au  Thu Aug 16 09:49:45 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 16 Aug 2007 09:49:45 +1000
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <20070815222649.GA27860@basalt.office.altlinux.org>
References: <46C30D90.3000306@zip.com.au>	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>	<46C378A1.3020704@zip.com.au>
	<20070815222649.GA27860@basalt.office.altlinux.org>
Message-ID: <46C39119.2050308@zip.com.au>

Dmitry V. Levin wrote:
> On Thu, Aug 16, 2007 at 08:05:21AM +1000, Darren Tucker wrote:
> [...]
>> OK there's some warnings in there that we should look at after the 
>> release.  (Actually someone sent in a fix for those "type-punned 
>> pointer" warnings but it looks like that slipped through the cracks.)
> 
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-April/025274.html

That would be them.  I think the rest of the patches in that series were 
applied so thanks for those.

I've created a bug (#1355) for the type-punned pointer warnings 
targeting 4.8.

-- 
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 stuge-openssh-unix-dev at cdy.org  Thu Aug 16 11:30:19 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Thu, 16 Aug 2007 03:30:19 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <2314816.F1exLrlWZM@kn.gn.rtr.message-center.info>
	<1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>
References: <1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>
	<46C2B104.6010307@noaa.gov>
	<2314816.F1exLrlWZM@kn.gn.rtr.message-center.info>
	<1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org>
	<1588308.kqNCecX6D0@kn.gn.rtr.message-center.info>
Message-ID: <20070816013019.27394.qmail@cdy.org>

On Wed, Aug 15, 2007 at 08:52:42AM +0200, Alexander Skwar wrote:
> > Again - something is different for those users, somewhere.
> 
> Of course! I'm not denying this ;) One set of users is able
> to use passwordless entry, while the other set of users is
> not able to do this. That's of course quite a difference *g*

I meant whatever causes the difference in behavior.


> > Possibly the working users were created in bulk (three) or just
> > using different versions of some software (four).
> 
> Well, as long as the LDAP database has the same contents, it
> doesn't make a difference on how the data was "poured" into it,
> I'd think.

You'd think so, but apparently that's not the case. :\


> It's like if there were a difference, when you create a user by
> doing "vi /etc/passwd" compared to "echo blah:blah:blah >>
> /etc/passwd". The result is the same. Confusing.

Except the code paths for accessing those databases are better known.


> > Creating new users the exact same way as the working users were
> > created should still succeed though.
> 
> Will try that.

> With yet another newly created test user, I'm able to SSH login
> using a password. Passwordless entry using pubkey doesn't work.

So either the tools have changed, or the way they are used has
changed. What upgrades/updates have been done in the system since
creating the working users? See if you can trace it back.


> > If you get that far, you get to reverse engineer what 
> > is actually going on to find the difference.
> 
> Yep. If I'd only be able to get that far... :\

Ok, if you want, you can still investigate what is done for new
users, and then you can look into what PAM expects.


> >> Having a look at the LDIF exports, I cannot see any differences.
> > 
> > But this is not the whole truth. There's a lot of software
> > involved in writing and reading that data,
> 
> But the LDAP database is the sole source of information.

My point is that there are several programs between OpenSSH and the
database. There's at least PAM and the PAM LDAP library, but maybe
more. You can look into which if any requirements and policies are
enforced by those components too.


> >> Anyway. Probably really a LDAP thing.
> > 
> > Can you test if these users are allowed through when someone else
> > than OpenSSH uses PAM to do passwordless logins? Any server is
> > good.
> 
> What server should I try?

Anything that can use PAM to log in users without a password. Apache
with client certs, OpenSC with pubkey on smartcard and .eid file,
even Samba and pam_winbind(sp?) if you have a Windows domain.

Another good tool is Darren's PAM test harness.


> > My guess is that the problem is with writing to LDAP, rather than
> > reading from it.
> 
> I doubt that. In LDAP, there's no difference between the
> non-working users and the working users. At least not, as far as I
> can tell.

What I meant to write was "creating users" instead of "writing to
LDAP" and "logging them in" instead of "reading from it."

Certain users are allowed to log in with key and no password, thanks
to some bit in some database.

Sun's PAM notices this bit is wrong for your new users and requires
them to specify a password even when there's a good key.

You could truss Sun sshd -ddd for working and non-working user and
compare the output, maybe that provides some hints.


On Wed, Aug 15, 2007 at 10:24:29AM +0200, Alexander Skwar wrote:
> written elsewhere in this thread - initially, I filled the
> database with the help of PADL MigrationTools. This converted
> /etc/passwd to ldif format. I then ran ldapadd to add the ldif
> file to the LDAP database.
> 
> That's what I did this time as well for the testing user.

Same versions of all involved components?


> You mean, that I should compare the output of slapcat? You're
> right. And I did that. No difference.

> No relevant differences :/

So the magic bit is not in LDAP.


//Peter

From pekkas at netcore.fi  Thu Aug 16 16:35:08 2007
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 16 Aug 2007 09:35:08 +0300 (EEST)
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C38974.9020607@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
	<46C378A1.3020704@zip.com.au>
	<Pine.LNX.4.64.0708160145530.12978@netcore.fi>
	<46C38974.9020607@zip.com.au>
Message-ID: <Pine.LNX.4.64.0708160934010.2303@netcore.fi>

On Thu, 16 Aug 2007, Darren Tucker wrote:
>> There is also later an issue with terminating forwarding connections,
>> but I recall you debugged this already 6-12 months ago (then the
>> system was RHL73 though) and couldn't reproduce it.  So this certainly
>> shouldn't be a recent problem.  With tracing enabled, the output is:
>
> This can happen if you have something that uses the port ranges that the
> regress tests assume will be free (33xx).  I have had problems with
> ClamAV's clamd which by default uses a port in that range.

Yes, there's clamd listening to 3310 on localhost.  I wonder if the 
regress tests should use something higher (e.g., in 10000-20000 range) 
which might have a higher chance of being free?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From listen at alexander.skwar.name  Thu Aug 16 16:51:53 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Thu, 16 Aug 2007 08:51:53 +0200
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org> <46C21D54.8050605@zip.com.au>
Message-ID: <2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>

Darren Tucker <dtucker at zip.com.au> wrote:

> Peter Stuge wrote:
>> I recall there being a PAM test harness
>> which mimics what OpenSSH does - but I don't remember if it's
>> included in the distribution or available separately?
> 
> http://www.zip.com.au/~dtucker/patches/#pamtest
> 
> The "-a" option skips the pam_authenticate call which simulates what
> happens during a public-key authentication.

Hm. No difference between non-working and working user:

,----[ working user ]
| --($:~/Source/pamtest)-- ./pam-test-harness -a -u askwar
| $Id: pam-test-harness.c,v 1.30 2005/09/28 23:38:31 dtucker Exp $
| conversation struct {conv=0x112c8, appdata_ptr=0x23174}
| pam_start(login, askwar, &conv, &pamh) = 0 (Success)
| pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success)
|     PAM_SERVICE = login (unchanged)
| pam_set_item(pamh, PAM_TTY, "/dev/pts/17") = 0 (Success)
| pam_set_item(pamh, PAM_RHOST, "winds06") = 0 (Success)
| pam_set_item(pamh, PAM_RUSER, "askwar") = 0 (Success)
| pam_acct_mgmt(pamh, 0x0) = 9 (Authentication failed)
| pam_end(pamh, 0) = 0 (Success)
`----

,----[ non-working user ]
| --($:~/Source/pamtest)-- ./pam-test-harness -a -u testing
| $Id: pam-test-harness.c,v 1.30 2005/09/28 23:38:31 dtucker Exp $
| conversation struct {conv=0x112c8, appdata_ptr=0x23174}
| pam_start(login, testing, &conv, &pamh) = 0 (Success)
| pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success)
|     PAM_SERVICE = login (unchanged)
| pam_set_item(pamh, PAM_TTY, "/dev/pts/17") = 0 (Success)
| pam_set_item(pamh, PAM_RHOST, "winds06") = 0 (Success)
| pam_set_item(pamh, PAM_RUSER, "askwar") = 0 (Success)
| pam_acct_mgmt(pamh, 0x0) = 9 (Authentication failed)
| pam_end(pamh, 0) = 0 (Success)
`----

Both times, I get a "Authentication failed" message. Or am I using
the tool wrong?

Alexander Skwar


From dtucker at zip.com.au  Thu Aug 16 18:10:15 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 16 Aug 2007 18:10:15 +1000
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>
	<46C21D54.8050605@zip.com.au>
	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
Message-ID: <46C40667.1070508@zip.com.au>

Alexander Skwar wrote:
> Darren Tucker <dtucker at zip.com.au> wrote:
[...]
>> http://www.zip.com.au/~dtucker/patches/#pamtest
>>
>> The "-a" option skips the pam_authenticate call which simulates what
>> happens during a public-key authentication.
> 
> Hm. No difference between non-working and working user:
> ./pam-test-harness -a -u askwar
[...]
> Both times, I get a "Authentication failed" message. Or am I using
> the tool wrong?

You might want to use "-s sshd" to get the PAM sshd service.  By default 
it uses "login".

-- 
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 stuge-openssh-unix-dev at cdy.org  Thu Aug 16 21:33:36 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Thu, 16 Aug 2007 13:33:36 +0200
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <Pine.LNX.4.64.0708160934010.2303@netcore.fi>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
	<46C378A1.3020704@zip.com.au>
	<Pine.LNX.4.64.0708160145530.12978@netcore.fi>
	<46C38974.9020607@zip.com.au>
	<Pine.LNX.4.64.0708160934010.2303@netcore.fi>
Message-ID: <20070816113336.16412.qmail@cdy.org>

On Thu, Aug 16, 2007 at 09:35:08AM +0300, Pekka Savola wrote:
> Yes, there's clamd listening to 3310 on localhost.  I wonder if the
> regress tests should use something higher (e.g., in 10000-20000
> range) which might have a higher chance of being free?

Or >49152 which is explicitly free for all.


//Peter

From deengert at anl.gov  Fri Aug 17 00:15:58 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 16 Aug 2007 09:15:58 -0500
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>
	<46C21D54.8050605@zip.com.au>
	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
Message-ID: <46C45C1E.8010803@anl.gov>

Since you are using Solaris, and the problem is with old users, added with
the PADL MigrationTools, vs new users, this might be a userPassword
attribute issue in LDAP.

The PADL will add the old password to LDAP using the string: {crypt}crypted-password
where crypted-password was copied from /etc/shadow or NIS.

If you used some other tool to add new users to ldap with a userPassword
(or no userPasswrod) it might be adding a value which the Solaris pam
considers to be a locked account. So look at how you added the
new users to ldap.

Test as *root* with:

  ldaplist -l username

It should have a line with
  userPassword: {crypt}crypted-password

If its not{crypt}something
then try changing it to use {crypt}

the getpw.c program I sent yesterday should return (assuming the username
is not also in the local /etc/passwd file):
useranme:x:...
username:crypted-password:...


-- 

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

From deengert at anl.gov  Fri Aug 17 00:44:38 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 16 Aug 2007 09:44:38 -0500
Subject: OpenSSH public key problem with Solaris 10 and LDAP users?
In-Reply-To: <46C45C1E.8010803@anl.gov>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<46C21D54.8050605@zip.com.au>	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
	<46C45C1E.8010803@anl.gov>
Message-ID: <46C462D6.9060909@anl.gov>



Douglas E. Engert wrote:
> Since you are using Solaris, and the problem is with old users, added with
> the PADL MigrationTools, vs new users, this might be a userPassword
> attribute issue in LDAP.
> 
> The PADL will add the old password to LDAP using the string: {crypt}crypted-password
> where crypted-password was copied from /etc/shadow or NIS.
> 
> If you used some other tool to add new users to ldap with a userPassword
> (or no userPasswrod) it might be adding a value which the Solaris pam
> considers to be a locked account. So look at how you added the
> new users to ldap.
> 
> Test as *root* with:
> 
>   ldaplist -l username

Opps...

ldaplist -l passwd username


> 
> It should have a line with
>   userPassword: {crypt}crypted-password
> 
> If its not{crypt}something
> then try changing it to use {crypt}
> 
> the getpw.c program I sent yesterday should return (assuming the username
> is not also in the local /etc/passwd file):
> useranme:x:...
> username:crypted-password:...
> 
> 

-- 

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

From rapier at psc.edu  Thu Aug 16 23:04:58 2007
From: rapier at psc.edu (chris rapier)
Date: Thu, 16 Aug 2007 09:04:58 -0400
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <20070815222148.GA28906@linux55.nas.nasa.gov>
References: <46C30D90.3000306@zip.com.au> <46C333B9.4030705@psc.edu>
	<20070815222148.GA28906@linux55.nas.nasa.gov>
Message-ID: <46C44B7A.6070105@psc.edu>



Iain Morgan wrote:

> We've been using the patch that Markus originally posted on this
> list back in 2005 on a number of systems for over a year and have
> not observed any issues with interactive sessions. Admittedly,
> that patch set the channel buffer to 1.25 MB rather than 2MB.

Well, I don't think it will be a problem for most people but the problem 
may impact reponsiveness for some people on dial up or other slow 
connection types. That and increased host memory usage. Overall I think 
its a positive development for bulk data transfers on mid range 
commodity networks.


From listen at alexander.skwar.name  Fri Aug 17 01:02:13 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Thu, 16 Aug 2007 17:02:13 +0200
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>
	<46C21D54.8050605@zip.com.au>
	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
	<46C45C1E.8010803@anl.gov>
Message-ID: <2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>

Douglas E. Engert <deengert at anl.gov> wrote:

> Since you are using Solaris, and the problem is with old users, added with
> the PADL MigrationTools, vs new users, this might be a userPassword
> attribute issue in LDAP.
> 
> The PADL will add the old password to LDAP using the string:
> {crypt}crypted-password where crypted-password was copied from /etc/shadow
> or NIS.

Correct assessment. BUT: I did a slapcat to dump the database. Then
I copied my working user from this dump, modified it a bit (uid, etc.pp.)
and ldapadd'ed that back to the LDAP database. I did not modify the 
password field.

Result: Login not possible without a password.

Another BUT: I'm beginning to wonder, why passwordless entry works
in the first place. According to the documentation at 
<http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=view>, passwordless
entry should not work. And seeing that it does not work for new users,
I should be "happy", as it works as described - for new users. Question
is, why does it work for the old user?

> If you used some other tool to add new users to ldap with a userPassword
> (or no userPasswrod) it might be adding a value which the Solaris pam
> considers to be a locked account. So look at how you added the
> new users to ldap.

Described above. I also chose this route to make sure that the newly
created account is as identical to the old account as possible.

> 
> Test as *root* with:
> 
>   ldaplist -l username
>
> It should have a line with
>   userPassword: {crypt}crypted-password

It doesn't.

,----[ LC_ALL=C sudo -H -u root ldaplist -l passwd askwar  ]
| dn: uid=askwar,ou=People,ou=RACE,o=Example
|         uid: askwar
|         cn: Alexander Skwar
|         roomNumber: alexander.skwar at Exampleauto.com
|         givenName: Alexander
|         sn: Skwar
|         mail: askwar at win.ch.da.rtr
|         mailRoutingAddress: askwar at mail1.Exampleauto.com
|         mailHost: mail1.Exampleauto.com
|         objectClass: inetLocalMailRecipient
|         objectClass: person
|         objectClass: organizationalPerson
|         objectClass: inetOrgPerson
|         objectClass: posixAccount
|         objectClass: top
|         objectClass: shadowAccount
|         objectClass: hostObject
|         shadowLastChange: 13503
|         loginShell: /opt/csw/bin/bash
|         gidNumber: 10
|         homeDirectory: /export/home/askwar
|         gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
|         host: winnb000488
|         host: winnb000488.win.ch.da.rtr
|         host: winds06
|         host: winds06.win.ch.da.rtr
|         uidNumber: 10001
`----

I use phpLdapAdmin to manage the LDAP database. In there, I can
easily dump an entry. Doing so, I see that the password is indeed
{crypt} encoded.

,----[ ldif dump of a non-working user ]
| version: 1
| 
| dn: uid=testing,ou=People,ou=RACE,o=Example
| uid: testing
| cn: Testing User
| roomNumber: alexander.skwar at Exampleauto.com
| givenName: Testing
| sn: User
| mail: askwar at win.ch.da.rtr
| mailRoutingAddress: askwar at mail1.Exampleauto.com
| mailHost: mail1.Exampleauto.com
| objectClass: inetLocalMailRecipient
| objectClass: person
| objectClass: organizationalPerson
| objectClass: inetOrgPerson
| objectClass: posixAccount
| objectClass: top
| objectClass: shadowAccount
| objectClass: hostObject
| userPassword: {crypt}cd.......
| shadowLastChange: 13503
| loginShell: /opt/csw/bin/bash
| gidNumber: 10
| gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
| host: winnb000488
| host: winnb000488.win.ch.da.rtr
| host: winds06
| host: winds06.win.ch.da.rtr
| uidNumber: 54321
| homeDirectory: /export/home/testing
`----

(I modified the userPassword in this mail.)


> If its not{crypt}something
> then try changing it to use {crypt}

It is crypt. :(

> the getpw.c program I sent yesterday should return (assuming the username
> is not also in the local /etc/passwd file):
> useranme:x:...
> username:crypted-password:...

Ah!

--($:~/Source/pamtest)-- sudo ./getpw askwar 
STDC = __STDC__
askwar:x:10001:10:Alexander Skwar,alexander.skwar at Exampleauto.com:/export/home/askwar:/opt/csw/bin/bash
askwar:cd9--------psA:13503:-1:-1-1:-1:-1:0

--($:~/Source/pamtest)-- sudo ./getpw testing 
STDC = __STDC__
testing:x:54321:10:Alexander Skwar,alexander.skwar at Exampleauto.com:/export/home/testing:/opt/csw/bin/bash
testing:*NP*:-1:-1:-1-1:-1:-1:0

*NP* for testing? Why's that? Why's there a difference?

Hmm....

--($:~/Source/pamtest)-- sudo grep test /etc/shadow

--($:~/Source/pamtest)-- sudo grep askwar /etc/shadow
askwar:cd,,,,,,QkpsA:13503::::::

Ah. askwar is in shadow. 

Now I removed askwar from /etc/shadow. And, lo and behold, I'm no longer
able to do a password-less login to the system. Great! Just the way it
is documented! Excellent! Also good to see, that it really didn't have
anything to do with LDAP. :)

Now I just got to curse at Sun for requiring a password. I guess I need
to have a look at lpk, OpenSSH LDAP Public Key.

Douglas, and others, thanks a million for bearing with me and helping
me to finally find the difference! I very much appreciate it!

Alexander Skwar


From deengert at anl.gov  Fri Aug 17 01:45:40 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 16 Aug 2007 10:45:40 -0500
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
In-Reply-To: <2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<46C21D54.8050605@zip.com.au>	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>	<46C45C1E.8010803@anl.gov>
	<2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>
Message-ID: <46C47124.7070501@anl.gov>



Alexander Skwar wrote:
> Douglas E. Engert <deengert at anl.gov> wrote:
> 

> 
>> the getpw.c program I sent yesterday should return (assuming the username
>> is not also in the local /etc/passwd file):
>> useranme:x:...
>> username:crypted-password:...
> 
> Ah!
> 
> --($:~/Source/pamtest)-- sudo ./getpw askwar 
> STDC = __STDC__
> askwar:x:10001:10:Alexander Skwar,alexander.skwar at Exampleauto.com:/export/home/askwar:/opt/csw/bin/bash
> askwar:cd9--------psA:13503:-1:-1-1:-1:-1:0
> 
> --($:~/Source/pamtest)-- sudo ./getpw testing 
> STDC = __STDC__
> testing:x:54321:10:Alexander Skwar,alexander.skwar at Exampleauto.com:/export/home/testing:/opt/csw/bin/bash
> testing:*NP*:-1:-1:-1-1:-1:-1:0
> 
> *NP* for testing? Why's that? Why's there a difference?


This could be the problem. NP is used for OK to login if you can
authenticate some other way. *NP* may be considered locked,
as * is not a valid crypt character.

Try using ldapmodify to change the password to {crypt}NP

See of you can get the  phpLdapAdmin to add NP rather then *NP*
Or set some valid password.



> 
> Hmm....
> 
> --($:~/Source/pamtest)-- sudo grep test /etc/shadow
> 
> --($:~/Source/pamtest)-- sudo grep askwar /etc/shadow
> askwar:cd,,,,,,QkpsA:13503::::::
> 
> Ah. askwar is in shadow. 
> 
> Now I removed askwar from /etc/shadow. And, lo and behold, I'm no longer
> able to do a password-less login to the system. Great! Just the way it
> is documented! Excellent! Also good to see, that it really didn't have
> anything to do with LDAP. :)
> 
> Now I just got to curse at Sun for requiring a password. I guess I need
> to have a look at lpk, OpenSSH LDAP Public Key.
> 
> Douglas, and others, thanks a million for bearing with me and helping
> me to finally find the difference! I very much appreciate it!
> 
> Alexander Skwar
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.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 listen at alexander.skwar.name  Fri Aug 17 02:00:38 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Thu, 16 Aug 2007 18:00:38 +0200
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<46C21D54.8050605@zip.com.au>	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>	<46C45C1E.8010803@anl.gov>
	<2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>
	<46C47124.7070501@anl.gov>
Message-ID: <2086961.cVTA4CmhGb@kn.gn.rtr.message-center.info>

Douglas E. Engert <deengert at anl.gov> wrote:
> Alexander Skwar wrote:
>> Douglas E. Engert <deengert at anl.gov> wrote:

>>> the getpw.c program I sent yesterday should return (assuming the
>>> username is not also in the local /etc/passwd file):
>>> useranme:x:...
>>> username:crypted-password:...
>> 
>> Ah!
>> 
>> --($:~/Source/pamtest)-- sudo ./getpw askwar
>> STDC = __STDC__
>> askwar:x:10001:10:Alexander
>> Skwar,alexander.skwar at Exampleauto.com:/export/home/askwar:/opt/csw/bin/bash
>> askwar:cd9--------psA:13503:-1:-1-1:-1:-1:0
>> 
>> --($:~/Source/pamtest)-- sudo ./getpw testing
>> STDC = __STDC__
>> testing:x:54321:10:Alexander
>> Skwar,alexander.skwar at Exampleauto.com:/export/home/testing:/opt/csw/bin/bash
>> testing:*NP*:-1:-1:-1-1:-1:-1:0
>> 
>> *NP* for testing? Why's that? Why's there a difference?
> 
> 
> This could be the problem. NP is used for OK to login if you can
> authenticate some other way. *NP* may be considered locked,
> as * is not a valid crypt character.
> 
> Try using ldapmodify to change the password to {crypt}NP
> 
> See of you can get the  phpLdapAdmin to add NP rather then *NP*
> Or set some valid password.

Uhm - I DO have a valid password for the "testing" user. And
as soon as I remove "askwar" from /etc/shadow, I also get *NP* (no
password, I guess?) when I run getpw. Is that not the way you
expect it to be?

Alexander Skwar


From cmadams at hiwaay.net  Fri Aug 17 02:04:52 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 16 Aug 2007 11:04:52 -0500
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <20070816160452.GB1100177@hiwaay.net>

Once upon a time, Darren Tucker <dtucker at zip.com.au> said:
> OpenSSH 4.7 is preparing for release so we are asking for any interested 
> folks to please test a snapshot. The main changes are:

openssh-SNAP-20070816.tar.gz passes testing on Tru64 5.1B.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

From deengert at anl.gov  Fri Aug 17 02:51:01 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 16 Aug 2007 11:51:01 -0500
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
In-Reply-To: <2086961.cVTA4CmhGb@kn.gn.rtr.message-center.info>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<46C21D54.8050605@zip.com.au>	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>	<46C45C1E.8010803@anl.gov>	<2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>	<46C47124.7070501@anl.gov>
	<2086961.cVTA4CmhGb@kn.gn.rtr.message-center.info>
Message-ID: <46C48075.3050806@anl.gov>



Alexander Skwar wrote:
> Douglas E. Engert <deengert at anl.gov> wrote:
>> Alexander Skwar wrote:
>>> Douglas E. Engert <deengert at anl.gov> wrote:
> 
>>>> the getpw.c program I sent yesterday should return (assuming the
>>>> username is not also in the local /etc/passwd file):
>>>> useranme:x:...
>>>> username:crypted-password:...
>>> Ah!
>>>
>>> --($:~/Source/pamtest)-- sudo ./getpw askwar
>>> STDC = __STDC__
>>> askwar:x:10001:10:Alexander
>>> Skwar,alexander.skwar at Exampleauto.com:/export/home/askwar:/opt/csw/bin/bash
>>> askwar:cd9--------psA:13503:-1:-1-1:-1:-1:0
>>>
>>> --($:~/Source/pamtest)-- sudo ./getpw testing
>>> STDC = __STDC__
>>> testing:x:54321:10:Alexander
>>> Skwar,alexander.skwar at Exampleauto.com:/export/home/testing:/opt/csw/bin/bash
>>> testing:*NP*:-1:-1:-1-1:-1:-1:0
>>>
>>> *NP* for testing? Why's that? Why's there a difference?
>>
>> This could be the problem. NP is used for OK to login if you can
>> authenticate some other way. *NP* may be considered locked,
>> as * is not a valid crypt character.
>>
>> Try using ldapmodify to change the password to {crypt}NP
>>
>> See of you can get the  phpLdapAdmin to add NP rather then *NP*
>> Or set some valid password.
> 
> Uhm - I DO have a valid password for the "testing" user. And
> as soon as I remove "askwar" from /etc/shadow, I also get *NP* (no
> password, I guess?) when I run getpw. Is that not the way you
> expect it to be?

No, I expect it to be NP not *NP*.

We use SSH with GSSAPI and the LDAP accounts use {crypt}NP
This works on Linux, Solaris 10 using the Solaris sshd, and older
Solaris systems using OpenSSH sshd.

The OpenSSH 4.5 src/sshd.0 talks about using locked accounts and NP or *NP*.

See the OpenSolaris source for pam says it can use *NP*:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/pam_modules/

But many of the sun blogs talk about NP. So OpenSolaris may have added *NP*
as well.

NP works for us from LDAP.



> 
> Alexander Skwar
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.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 Jefferson.Ogata at noaa.gov  Fri Aug 17 03:03:11 2007
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 16 Aug 2007 17:03:11 +0000
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
In-Reply-To: <46C48075.3050806@anl.gov>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>
	<46C191F4.5040104@adaptive-enterprises.com.au>
	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>
	<20070814131728.12252.qmail@cdy.org>
	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>
	<20070814163338.16925.qmail@cdy.org> <46C21D54.8050605@zip.com.au>
	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>
	<46C45C1E.8010803@anl.gov>
	<2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>
	<46C47124.7070501@anl.gov>
	<2086961.cVTA4CmhGb@kn.gn.rtr.message-center.info>
	<46C48075.3050806@anl.gov>
Message-ID: <46C4834F.903@noaa.gov>

On 08/16/07 16:51, Douglas E. Engert wrote:
> No, I expect it to be NP not *NP*.

If you don't want a user to have a valid crypt password, you should
always include a character that cannot occur in a crypt password; this
assures that there is no possible string that could hash to the target
value, without relying on any specifics about the crypt algorithm other
than its target charset. The standard character for this is *, although
! is used as well. The traditional old-timer way to make a user with no
password is to use * alone in the password field. Solaris likes *NP* for
this, and also uses *LK*, if I recall correctly, to designate a locked user.

This is sysadmin 101, people.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service

From tim at multitalents.net  Fri Aug 17 02:47:10 2007
From: tim at multitalents.net (Tim Rice)
Date: Thu, 16 Aug 2007 09:47:10 -0700 (PDT)
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <Pine.LNX.4.64.0708160934010.2303@netcore.fi>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
	<46C378A1.3020704@zip.com.au>
	<Pine.LNX.4.64.0708160145530.12978@netcore.fi>
	<46C38974.9020607@zip.com.au>
	<Pine.LNX.4.64.0708160934010.2303@netcore.fi>
Message-ID: <Pine.UW2.4.64.0708160942520.27869@server01.int.multitalents.net>

On Thu, 16 Aug 2007, Pekka Savola wrote:

> On Thu, 16 Aug 2007, Darren Tucker wrote:
> > This can happen if you have something that uses the port ranges that the
> > regress tests assume will be free (33xx).  I have had problems with
> > ClamAV's clamd which by default uses a port in that range.
> 
> Yes, there's clamd listening to 3310 on localhost.  I wonder if the 
> regress tests should use something higher (e.g., in 10000-20000 range) 
> which might have a higher chance of being free?

After looking over http://www.iana.org/assignments/port-numbers
it looks like we should use something in the 49152 through 65535 range.
<quote>
The Dynamic and/or Private Ports are those from 49152 through 65535
</quote>

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



From openssh at roumenpetrov.info  Fri Aug 17 05:35:18 2007
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 16 Aug 2007 22:35:18 +0300
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <Pine.LNX.4.64.0708160035130.12095@netcore.fi>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
Message-ID: <46C4A6F6.9020602@roumenpetrov.info>

Pekka Savola wrote:
> On Thu, 16 Aug 2007, Darren Tucker wrote:
>   
>> Running the regression tests supplied with Portable does not require
>> installation and is a simply:
>>
>> $ ./configure && make tests
>>     
>
> On CentOS 5 on i386, I see the following warnings:
>
> mac.c: In function 'mac_compute':
> mac.c:131: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
> ssh.c: In function 'control_client':
> ssh.c:1475: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
> readconf.c: In function 'process_config_line':
> readconf.c:695: warning: dereferencing type-punned pointer will break strict-aliasing rules
>   
may be CFLAGS="-fno-strict-aliasing" ./configure will solve this.

Roumen

> [SNIP]


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


From listen at alexander.skwar.name  Fri Aug 17 05:40:17 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Thu, 16 Aug 2007 21:40:17 +0200
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>	<46C21D54.8050605@zip.com.au>	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>	<46C45C1E.8010803@anl.gov>	<2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>	<46C47124.7070501@anl.gov>
	<2086961.cVTA4CmhGb@kn.gn.rtr.message-center.info>
	<46C48075.3050806@anl.gov>
Message-ID: <3560820.G3caQ79O9G@m-id.message-center.info>

? Douglas E. Engert <deengert at anl.gov>:

> 
> 
> Alexander Skwar wrote:
>> Douglas E. Engert <deengert at anl.gov> wrote:
>>> Alexander Skwar wrote:
>>>> Douglas E. Engert <deengert at anl.gov> wrote:
>> 
>>>>> the getpw.c program I sent yesterday should return (assuming the
>>>>> username is not also in the local /etc/passwd file):
>>>>> useranme:x:...
>>>>> username:crypted-password:...
>>>> Ah!
>>>>
>>>> --($:~/Source/pamtest)-- sudo ./getpw askwar
>>>> STDC = __STDC__
>>>> askwar:x:10001:10:Alexander
>>>> Skwar,alexander.skwar at Exampleauto.com:/export/home/askwar:/opt/csw/bin/bash
>>>> askwar:cd9--------psA:13503:-1:-1-1:-1:-1:0
>>>>
>>>> --($:~/Source/pamtest)-- sudo ./getpw testing
>>>> STDC = __STDC__
>>>> testing:x:54321:10:Alexander
>>>> Skwar,alexander.skwar at Exampleauto.com:/export/home/testing:/opt/csw/bin/bash
>>>> testing:*NP*:-1:-1:-1-1:-1:-1:0
>>>>
>>>> *NP* for testing? Why's that? Why's there a difference?
>>>
>>> This could be the problem. NP is used for OK to login if you can
>>> authenticate some other way. *NP* may be considered locked,
>>> as * is not a valid crypt character.
>>>
>>> Try using ldapmodify to change the password to {crypt}NP
>>>
>>> See of you can get the  phpLdapAdmin to add NP rather then *NP*
>>> Or set some valid password.
>> 
>> Uhm - I DO have a valid password for the "testing" user. And
>> as soon as I remove "askwar" from /etc/shadow, I also get *NP* (no
>> password, I guess?) when I run getpw. Is that not the way you
>> expect it to be?
> 
> No, I expect it to be NP not *NP*.
> 
> We use SSH with GSSAPI and the LDAP accounts use {crypt}NP
> This works on Linux, Solaris 10 using the Solaris sshd, and older
> Solaris systems using OpenSSH sshd.

Hm. Interesting. I don't know what to do to get it display
{crypt}NP or {crypt}*NP*. pam is configured exactly as the
Sun documentation has it. Could you be so kind and send
your /etc/pam.conf from your S10 machine?

Thanks,

Alexander Skwar
-- 
Plastic...  Aluminum...  These are the inheritors of the Universe!
Flesh and Blood have had their day... and that day is past!
                -- Green Lantern Comics



From deengert at anl.gov  Fri Aug 17 06:47:21 2007
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 16 Aug 2007 15:47:21 -0500
Subject: [SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP
	users?
In-Reply-To: <46C4834F.903@noaa.gov>
References: <1369491.hhr5NejTU8@kn.gn.rtr.message-center.info>	<46C191F4.5040104@adaptive-enterprises.com.au>	<1506044.SFAFydEWOl@kn.gn.rtr.message-center.info>	<20070814131728.12252.qmail@cdy.org>	<3745341.3EIFh2V9cf@kn.gn.rtr.message-center.info>	<20070814163338.16925.qmail@cdy.org>
	<46C21D54.8050605@zip.com.au>	<2585013.alcK1t3JQE@kn.gn.rtr.message-center.info>	<46C45C1E.8010803@anl.gov>	<2065330.a4gMWVKEAW@kn.gn.rtr.message-center.info>	<46C47124.7070501@anl.gov>	<2086961.cVTA4CmhGb@kn.gn.rtr.message-center.info>	<46C48075.3050806@anl.gov>
	<46C4834F.903@noaa.gov>
Message-ID: <46C4B7D9.6000203@anl.gov>



Jefferson Ogata wrote:
> On 08/16/07 16:51, Douglas E. Engert wrote:
>> No, I expect it to be NP not *NP*.
> 
> If you don't want a user to have a valid crypt password, you should
> always include a character that cannot occur in a crypt password; this
> assures that there is no possible string that could hash to the target
> value, without relying on any specifics about the crypt algorithm other
> than its target charset. The standard character for this is *, although
> ! is used as well. The traditional old-timer way to make a user with no
> password is to use * alone in the password field. Solaris likes *NP* for
> this, and also uses *LK*, if I recall correctly, to designate a locked user.

Well NP is not a valid crypt string either as it is only 2 characters long,
and crypt always returns 13 characters.

> 
> This is sysadmin 101, people.

Its more like a sysadmin 401. This has changed over the years with different
OSs using different conventions. Including no use of the account at all if it
starts with a "*".  NP has always worked...

The OpenSSH src/sshd.0 has:

>      Regardless of the authentication type, the account is checked to ensure
>      that it is accessible.  An account is not accessible if it is locked,
>      listed in DenyUsers or its group is listed in DenyGroups .  The defini-
>      tion of a locked account is system dependant. Some platforms have their
>      own account database (eg AIX) and some modify the passwd field ( `*LK*'
>      on Solaris and UnixWare, `*' on HP-UX, containing `Nologin' on Tru64, a
>      leading `*LOCKED*' on FreeBSD and a leading `!!' on Linux).  If there is
>      a requirement to disable password authentication for the account while
>      allowing still public-key, then the passwd field should be set to some-
>      thing other than these values (eg `NP' or `*NP*' ).
> 

-- 

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

From lindysandiego at yahoo.com  Fri Aug 17 07:37:11 2007
From: lindysandiego at yahoo.com (Thomas Baden)
Date: Thu, 16 Aug 2007 14:37:11 -0700 (PDT)
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
Message-ID: <837744.11586.qm@web51707.mail.re2.yahoo.com>

--- Darren Tucker <dtucker at zip.com.au> wrote:
> $ ./configure && make tests

openssh-SNAP-20070816 on Solaris 8, Sun Forte 7 C 5.4,
64-bit, YASSP, OpenSSL 0.9.8e, /dev/random:

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

              Host: sparc-sun-solaris2.8
          Compiler: cc
    Compiler flags: -xtarget=ultra -xarch=v9
Preprocessor flags: -I/opt/local/ssl/include
-D_XOPEN_SOURCE=500 -D__EXTENSIONS__
      Linker flags: -L/opt/local/ssl/lib
-R/opt/local/ssl/lib -xtarget=ultra -xarch=v9
-L/opt/local/ssl/lib/64
         Libraries:  -lpam -ldl -lresolv -lcrypto -lrt
-lz -lsocket -lnsl

No errors reported.

openssh-SNAP-20070816 on Solaris 10, Sun Forte 7 C
5.7,
64-bit, OpenSSL 0.9.8e, /dev/random:

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

              Host: sparc-sun-solaris2.10
          Compiler: cc
    Compiler flags: -xtarget=ultra -xarch=v9
Preprocessor flags: -I/opt/local/ssl/include
-D_XOPEN_SOURCE=500 -D__EXTENSIONS__
      Linker flags: -L/opt/local/ssl/lib
-R/opt/local/ssl/lib -xtarget=ultra -xarch=v9
-L/opt/local/ssl/lib/64
         Libraries:  -lpam -ldl -lresolv -lcrypto -lrt
-lz -lsocket -lnsl

No errors reported.

Cheers,
-Thomas


       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

From doctor at doctor.nl2k.ab.ca  Fri Aug 17 09:15:55 2007
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Thu, 16 Aug 2007 17:15:55 -0600
Subject: {Spam?} Re: OpenSSH 4.7: call for testing.
In-Reply-To: <46C4A6F6.9020602@roumenpetrov.info>
References: <46C30D90.3000306@zip.com.au>
	<Pine.LNX.4.64.0708160035130.12095@netcore.fi>
	<46C4A6F6.9020602@roumenpetrov.info>
Message-ID: <20070816231555.GA9741@doctor.nl2k.ab.ca>


So far so good on BSD/OS 4.3.X .

-- 
Member - Liberal International	
This is doctor at nl2k.ab.ca	Ici doctor at nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
PAtriots! MAke your declaration of loyalty!

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From apb at cequrux.com  Fri Aug 17 20:10:06 2007
From: apb at cequrux.com (Alan Barrett)
Date: Fri, 17 Aug 2007 12:10:06 +0200
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au>
References: <46C30D90.3000306@zip.com.au>
Message-ID: <20070817101005.GU27645@apb-laptoy.apb.alt.za>

On Thu, 16 Aug 2007, Darren Tucker wrote:
> Running the regression tests supplied with Portable does not require
> installation and is a simply:
> 
> $ ./configure && make tests

I tested on NetBSD-current/i386 (version 4.99.27).

There was no configure script in the code that I obtained from
"cvs -d anoncvs at anoncvs.mindrot.org:/cvs checkout openssh".

I managed to generate a configure script via "autoreconf",
and the configure script appeared to work.

make tests failed with the following error:

run test connect.sh ...
Missing privilege separation directory: /var/empty
FATAL: sshd_proxy broken
*** Error code 1

I created /var/empty (as root) and then ran "make tests" again (as an
unprivileged user).

This time, "make tests" complained about some unrecognised syntax in my
.ssh/config file.  OK, the file did contain syntax that I didn't expect
an unpatched vesion of openssh to understand, but it seems liek an error
for the tests to use whatever random contant I happen to have in my
configuration file.  Surely the tests should use "-F /dev/null", or "-F
${special_configuration_file}"?

I moved by .ssh directory aside and tried "make tests" again.

This time, "make tests" succeeded.  However, it created an empty
$HOME/.ssh directory.  I think it's rude for a test suite to create any
non-temporary files or directories.

--apb (Alan Barrett)

From dtucker at zip.com.au  Fri Aug 17 21:31:05 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Aug 2007 21:31:05 +1000
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <20070817101005.GU27645@apb-laptoy.apb.alt.za>
References: <46C30D90.3000306@zip.com.au>
	<20070817101005.GU27645@apb-laptoy.apb.alt.za>
Message-ID: <20070817113104.GA11753@gate.dtucker.net>

On Fri, Aug 17, 2007 at 12:10:06PM +0200, Alan Barrett wrote:
> On Thu, 16 Aug 2007, Darren Tucker wrote:
> > Running the regression tests supplied with Portable does not require
> > installation and is a simply:
> > 
> > $ ./configure && make tests
> 
> I tested on NetBSD-current/i386 (version 4.99.27).
> 
> There was no configure script in the code that I obtained from
> "cvs -d anoncvs at anoncvs.mindrot.org:/cvs checkout openssh".
> 
> I managed to generate a configure script via "autoreconf",
> and the configure script appeared to work.

That's expected, and covered in the INSTALL file (which is a little
misnamed given that it covers both building and installing):

[quote]
Autoconf:

If you modify configure.ac or configure doesn't exist (eg if you checked
the code out of CVS yourself) then you will need autoconf-2.61 to rebuild
the automatically generated files by running "autoreconf".  Earlier
version may also work but this is not guaranteed.

http://www.gnu.org/software/autoconf/
[/quote]

(and yeah, I noticed the missing "s" on "version")

> make tests failed with the following error:
> 
> run test connect.sh ...
> Missing privilege separation directory: /var/empty
> FATAL: sshd_proxy broken
> *** Error code 1
> 
> I created /var/empty (as root) and then ran "make tests" again (as an
> unprivileged user).

sshd only checks that directory if use_privsep is enabled, but it
still does so when sshd is running as a regular user.  Perhaps it
should unset use_privsep in that case.

> This time, "make tests" complained about some unrecognised syntax in my
> .ssh/config file.  OK, the file did contain syntax that I didn't expect
> an unpatched vesion of openssh to understand, but it seems liek an error
> for the tests to use whatever random contant I happen to have in my
> configuration file.  Surely the tests should use "-F /dev/null", or "-F
> ${special_configuration_file}"?

For the most part, it does use its own config files which it creates in
a working directory during the test and removes afterward (see, eg,
regress/connect.sh).

It appears that just the multiplex tests in particular don't, but that's
easily fixable, although that won't be until after the release.

> I moved by .ssh directory aside and tried "make tests" again.
> 
> This time, "make tests" succeeded.  However, it created an empty
> $HOME/.ssh directory.  I think it's rude for a test suite to create any
> non-temporary files or directories.

That's a reasonable point, however offhand I can't think of a way to stop
it.

Thanks for the testing and report.

-- 
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 apb at cequrux.com  Fri Aug 17 21:48:53 2007
From: apb at cequrux.com (Alan Barrett)
Date: Fri, 17 Aug 2007 13:48:53 +0200
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <20070817113104.GA11753@gate.dtucker.net>
References: <46C30D90.3000306@zip.com.au>
	<20070817101005.GU27645@apb-laptoy.apb.alt.za>
	<20070817113104.GA11753@gate.dtucker.net>
Message-ID: <20070817114853.GV27645@apb-laptoy.apb.alt.za>

On Fri, 17 Aug 2007, Darren Tucker wrote:
> > There was no configure script in the code that I obtained from
> > "cvs -d anoncvs at anoncvs.mindrot.org:/cvs checkout openssh".
> > 
> > I managed to generate a configure script via "autoreconf",
> > and the configure script appeared to work.
> 
> That's expected, and covered in the INSTALL file

OK.  I misread your message, which I had thought said to check out from
CVS HEAD, but I now see that that part of the instructions was for the
OpenBSD version of openssh, not for the portable version of openssh.

> > Surely the tests should use "-F /dev/null", or "-F
> > ${special_configuration_file}"?
> 
> For the most part, it does use its own config files which it creates in
> a working directory during the test and removes afterward (see, eg,
> regress/connect.sh).
> 
> It appears that just the multiplex tests in particular don't, but that's
> easily fixable, although that won't be until after the release.

OK.

> > This time, "make tests" succeeded.  However, it created an empty
> > $HOME/.ssh directory.  I think it's rude for a test suite to create
> > any non-temporary files or directories.
>
> That's a reasonable point, however offhand I can't think of a way to
> stop it.

Perhaps HOME=${path_to_temporary_directory} ?

--apb (Alan Barrett)

From dtucker at zip.com.au  Fri Aug 17 21:58:29 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Aug 2007 21:58:29 +1000
Subject: OpenSSH 4.7: call for testing.
In-Reply-To: <20070817114853.GV27645@apb-laptoy.apb.alt.za>
References: <46C30D90.3000306@zip.com.au>
	<20070817101005.GU27645@apb-laptoy.apb.alt.za>
	<20070817113104.GA11753@gate.dtucker.net>
	<20070817114853.GV27645@apb-laptoy.apb.alt.za>
Message-ID: <20070817115829.GA9753@gate.dtucker.net>

On Fri, Aug 17, 2007 at 01:48:53PM +0200, Alan Barrett wrote:
> On Fri, 17 Aug 2007, Darren Tucker wrote:
> > > This time, "make tests" succeeded.  However, it created an empty
> > > $HOME/.ssh directory.  I think it's rude for a test suite to create
> > > any non-temporary files or directories.
> >
> > That's a reasonable point, however offhand I can't think of a way to
> > stop it.
> 
> Perhaps HOME=${path_to_temporary_directory} ?

Unfortunately that won't help.  ssh uses pw_dir from getpwnam() to
determine the home directory which is not so easily fooled.

-- 
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 lgriswold at ccsnh.edu  Sat Aug 18 03:30:48 2007
From: lgriswold at ccsnh.edu (Larry Griswold)
Date: Fri, 17 Aug 2007 13:30:48 -0400
Subject: SSH/SFTP from HP-UX to a Windows 2003 OpenSSH 3.8 -1p1
Message-ID: <BF5163CAC8D31B47B51E17A7B1CCAE647537F7@EX3.tec.nh.us>

We have used OpenSSH version 3.8-1p1 on our Windows 2003 servers for the
last several years for SFTP connection to our HP-UX Open SSH version 3.9
servers.  This is the first time having connections problems.  The new
Window 2003 server is in a DMZ zone and our security policy software has
been set to allow port 22 to pass in/out for our HP-UX servers.    I
have the sshd_config file the same as the non-DMZ Windows servers.

What is strange is if I stop the OpenSSH service on the Windows server
and execute \usr\sbin\sshd -d -d -d and try the SFTP connection from the
HP-UX server; it works.

If I start the OpenSSH service on the Windows server the logs show that
the keys are accepted, but the connection is closed immediately.  I have
provided the debug log from the HP-UX connection side.

Larry Griswold
OpenVMS / HP-UX System Manager
Comm. College of NH / System Office / IT
Concord, NH
603-271-3998


 <<cannon_sftp_close_connection.txt>> 
___________________________________________

This electronic mail (including any attachments) may contain information
that is privileged, confidential, and/or otherwise protected from
disclosure to anyone other than its intended recipient(s). Any
dissemination or use of this electronic email or its contents (including
any attachments) by persons other than the intended recipient(s) is
strictly prohibited. If you have received this message in error, please
notify us immediately by reply email so that we may correct our internal
records. Please then delete the original message (including any
attachments) in its entirety. Thank you. 


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cannon_sftp_close_connection.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070817/18481b76/attachment.txt 

From david-bronder at uiowa.edu  Sat Aug 18 13:36:05 2007
From: david-bronder at uiowa.edu (David Bronder)
Date: Fri, 17 Aug 2007 22:36:05 -0500 (CDT)
Subject: [openssh-unix-dev] OpenSSH 4.7: call for testing.
In-Reply-To: <46C30D90.3000306@zip.com.au> from "Darren Tucker" at Aug 16,
	2007 12:28:32 AM
Message-ID: <200708180336.l7I3a5Qt039470@fire.its.uiowa.edu>

Darren Tucker wrote:
>
> OpenSSH 4.7 is preparing for release so we are asking for any interested
> folks to please test a snapshot.

Running "make tests" with openssh-SNAP-20070817 on AIX 5.1 ML9,
AIX 5.2 TL9 and AIX 5.3 TL6 SP3 all looked good (minus the few
expected skipped tests).

I noticed a few informational and warning messages on the AIX 5.3
system (I didn't pay attention on the older systems).

In port-aix.c:

  "/usr/include/syms.h", line 288.9: 1506-236 (W) Macro name T_NULL has been redefined.
  "/usr/include/syms.h", line 288.9: 1506-358 (I) "T_NULL" is defined on line 150 of /usr/include/arpa/onameser_compat.h.


In serverloop.c:

  "serverloop.c", line 845.21: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed.


In sftp-client.c:

  "sftp-client.c", line 1066.62: 1506-280 (W) Function argument assignment between types "long long*" and "unsigned long long*" is not allowed.


-- 
Hello World.                                    David Bronder - Systems Admin
Segmentation Fault                                     ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder at uiowa.edu

From listen at alexander.skwar.name  Sat Aug 18 16:01:42 2007
From: listen at alexander.skwar.name (Alexander Skwar)
Date: Sat, 18 Aug 2007 08:01:42 +0200
Subject: PAM service used by OpenSSH on Solaris?
Message-ID: <3323387.1fmampYW7V@m-id.message-center.info>

Hello.

Which pam service is sshd using on Solaris? Is it sshd?

Thanks,

Alexander Skwar
-- 
Message from Our Sponsor on ttyTV at 13:58 ...



From dtucker at zip.com.au  Sat Aug 18 16:36:36 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Aug 2007 16:36:36 +1000
Subject: PAM service used by OpenSSH on Solaris?
In-Reply-To: <3323387.1fmampYW7V@m-id.message-center.info>
References: <3323387.1fmampYW7V@m-id.message-center.info>
Message-ID: <46C69374.4010008@zip.com.au>

Alexander Skwar wrote:
> Which pam service is sshd using on Solaris? Is it sshd?

For OpenSSH, by default it's the name of the server binary which is 
"sshd" in a normal installation.  You can override this at build time by 
specifying a custom "SSHD_PAM_SERVICE" #define.

Quoth the INSTALL file:

"If you are using PAM, you may need to manually install a PAM control
file as "/etc/pam.d/sshd" (or wherever your system prefers to keep
them).  Note that the service name used to start PAM is __progname,
which is the basename of the path of your sshd (e.g., the service name
for /usr/sbin/osshd will be osshd).  If you have renamed your sshd
executable, your PAM configuration may need to be modified."

-- 
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 mstevens at cmu.edu  Tue Aug 21 10:23:35 2007
From: mstevens at cmu.edu (Michael A Stevens)
Date: Mon, 20 Aug 2007 20:23:35 -0400 (EDT)
Subject: ssh-agent security
Message-ID: <Pine.LNX.4.64-044.0708201956120.30548@unix32.andrew.cmu.edu>

ssh-agent is a great tool that is often misconfigured with respect to 
agent forwarding. How many people running ssh-agent and doing a ssh 
-A have the very same public keys in ~/.ssh/authorized_keys of the machine 
they are coming from? ssh(1) is very clear in its warning about enabling 
agent forwarding. The simple act of prompting the user before using the 
key would enable them to determine when they key was potentially being 
used without their knowledge. It won't stop an attacker from riding on 
ssh sessions that a user legitimately forms, but it will help deter 
them from using the agent socket to make new ones either to other 
machines or back to the source machine. This patch is by no means 
ready to roll out to users, but any comments on it would be appreciated.

Usage:

patch -p0 < openssh-4.6p1-agentmod2.diff
cd openssh-4.6p1
./configure && make
./ssh-agent -di "xmessage -buttons Yes:0,No:1 Authorize key use by process with PID ="

(In other shell...)
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXX/agent.XXXX; export SSH_AUTH_SOCK;
echo Agent pid XXXX;
ssh-add ~/.ssh/id_dsa
ssh -A user at host
ssh user at source


Mike Stevens
-------------- next part --------------
--- openssh-4.6p1/ssh-agent.c	2007-02-28 05:19:58.000000000 -0500
+++ openssh-4.6p1-agentmod2/ssh-agent.c	2007-08-20 19:56:38.000000000 -0400
@@ -134,6 +134,9 @@
 /* Default lifetime (0 == forever) */
 static int lifetime = 0;
 
+static int run_inform = 0;
+char inform_cmd[MAXPATHLEN];
+
 static void
 close_socket(SocketEntry *e)
 {
@@ -247,6 +250,28 @@
 	MD5_CTX md;
 	Key *key;
 
+#if defined(SO_PEERCRED)
+	if (AUTH_CONNECTION == e->type) {
+		struct ucred cred;
+		socklen_t len = sizeof(cred);
+		char inform_cmdline[MAXPATHLEN];
+
+		if (run_inform && getsockopt(e->fd, SOL_SOCKET, SO_PEERCRED, &cred, &len) >= 0) {
+			int ret;
+
+			snprintf(inform_cmdline, sizeof inform_cmdline, "%s %d",
+					inform_cmd, cred.pid);
+			ret = system(inform_cmdline);
+			if (ret != 0) {
+				close_socket(e);
+				return;
+			}
+		}
+	}
+#endif
+	
+
+
 	buffer_init(&msg);
 	key = key_new(KEY_RSA1);
 	if ((challenge = BN_new()) == NULL)
@@ -314,6 +339,26 @@
 	Buffer msg;
 	Key *key;
 
+#if defined(SO_PEERCRED)
+	if (AUTH_CONNECTION == e->type) {
+		struct ucred cred;
+		socklen_t len = sizeof(cred);
+		char inform_cmdline[MAXPATHLEN];
+
+		if (run_inform && getsockopt(e->fd, SOL_SOCKET, SO_PEERCRED, &cred, &len) >= 0) {
+			int ret;
+
+			snprintf(inform_cmdline, sizeof inform_cmdline, "%s %d",
+					inform_cmd, cred.pid);
+			ret = system(inform_cmdline);
+			if (ret != 0) {
+				close_socket(e);
+				return;
+			}
+		}
+	}
+#endif
+	
 	datafellows = 0;
 
 	blob = buffer_get_string(&e->request, &blen);
@@ -1007,6 +1052,7 @@
 	fprintf(stderr, "  -d          Debug mode.\n");
 	fprintf(stderr, "  -a socket   Bind agent socket to given name.\n");
 	fprintf(stderr, "  -t life     Default identity lifetime (seconds).\n");
+	fprintf(stderr, "  -i cmd      Command to run on new connection.\n");
 	exit(1);
 }
 
@@ -1047,7 +1093,7 @@
 	init_rng();
 	seed_rng();
 
-	while ((ch = getopt(ac, av, "cdksa:t:")) != -1) {
+	while ((ch = getopt(ac, av, "cdksa:i:t:")) != -1) {
 		switch (ch) {
 		case 'c':
 			if (s_flag)
@@ -1070,6 +1116,10 @@
 		case 'a':
 			agentsocket = optarg;
 			break;
+		case 'i':
+			run_inform = 1;
+			snprintf(inform_cmd, sizeof inform_cmd, "%s", optarg);
+			break;
 		case 't':
 			if ((lifetime = convtime(optarg)) == -1) {
 				fprintf(stderr, "Invalid lifetime\n");

From djm at mindrot.org  Tue Aug 21 11:57:40 2007
From: djm at mindrot.org (Damien Miller)
Date: Tue, 21 Aug 2007 11:57:40 +1000 (EST)
Subject: ssh-agent security
In-Reply-To: <Pine.LNX.4.64-044.0708201956120.30548@unix32.andrew.cmu.edu>
References: <Pine.LNX.4.64-044.0708201956120.30548@unix32.andrew.cmu.edu>
Message-ID: <Pine.BSO.4.64.0708211156200.3512@fuyu.mindrot.org>

On Mon, 20 Aug 2007, Michael A Stevens wrote:

> ssh-agent is a great tool that is often misconfigured with respect to agent
> forwarding. How many people running ssh-agent and doing a ssh -A have the very
> same public keys in ~/.ssh/authorized_keys of the machine they are coming
> from? ssh(1) is very clear in its warning about enabling agent forwarding. The
> simple act of prompting the user before using the key would enable them to
> determine when they key was potentially being used without their knowledge. It
> won't stop an attacker from riding on ssh sessions that a user legitimately
> forms, but it will help deter them from using the agent socket to make new
> ones either to other machines or back to the source machine. This patch is by
> no means ready to roll out to users, but any comments on it would be
> appreciated.

Alternately, you could just add your key with "ssh-add -c". The agent
will then require confirmation (via ssh-askpass) for each use of the
key.

-d

From lcashdol at gmail.com  Wed Aug 22 22:59:06 2007
From: lcashdol at gmail.com (Larry Cashdollar)
Date: Wed, 22 Aug 2007 08:59:06 -0400
Subject: Patch to allow checking of v1 keys on remote host.
Message-ID: <c2134ab30708220559u36fe16a9s60c51a5073e4c3b7@mail.gmail.com>

The attached patch for 4.6p1 adds a feature (-u) that will check to
see if a key exists on a remote host.  I use this for auditing my
users transition to v2 keys very useful.  If there is any interest
I'll provide a patch for v2 ssh keys also.

http://vapid.dhs.org/dokuwiki/doku.php?id=vapidlabs:openssh_check_key_patch

-- Thanks

Larry

--- orig/openssh-4.6p1/sshconnect1.c	2006-11-07 07:14:42.000000000 -0500
+++ openssh-4.6p1/sshconnect1.c	2007-05-15 03:31:06.740012440 -0400
@@ -69,10 +69,11 @@
 	u_int i;
 	Key *key;
 	BIGNUM *challenge;
+	u_char buf[300];

 	/* Get connection to the agent. */
 	auth = ssh_get_authentication_connection();
-	if (!auth)
+if (!auth)
 		return 0;

 	if ((challenge = BN_new()) == NULL)
@@ -84,7 +85,7 @@

 		/* Try this identity. */
 		debug("Trying RSA authentication via agent with '%.100s'", comment);
-		xfree(comment);
+		if (!options.checkey) xfree(comment);

 		/* Tell the server that we are willing to authenticate using this key. */
 		packet_start(SSH_CMSG_AUTH_RSA);
@@ -107,9 +108,17 @@
 			packet_disconnect("Protocol error during RSA authentication: %d",
 					  type);

+                /*if -u is enabled print a message and then exit*/
+		 if (options.checkey) {
+       			snprintf(buf, sizeof(buf), "RSA key '%.100s' is Valid",comment);
+       			xfree(comment);
+         		packet_disconnect("%s",buf);
+        	}
+
 		packet_get_bignum(challenge);
 		packet_check_eom();

+		
 		debug("Received RSA challenge from server.");

 		/* Ask the agent to decrypt the challenge. */
@@ -136,12 +145,16 @@
 		type = packet_read();

 		/* The server returns success if it accepted the authentication. */
+
 		if (type == SSH_SMSG_SUCCESS) {
 			ssh_close_authentication_connection(auth);
 			BN_clear_free(challenge);
 			debug("RSA authentication accepted by server.");
 			return 1;
 		}
+
+
+
 		/* Otherwise it should return failure. */
 		if (type != SSH_SMSG_FAILURE)
 			packet_disconnect("Protocol error waiting RSA auth response: %d",
@@ -234,7 +247,8 @@
 		xfree(comment);
 		return 0;
 	}
-	/* Otherwise, the server should respond with a challenge. */
+	
+       /* Otherwise, the server should respond with a challenge. */
 	if (type != SSH_SMSG_AUTH_RSA_CHALLENGE)
 		packet_disconnect("Protocol error during RSA authentication: %d", type);

@@ -256,7 +270,15 @@
 	else
 		private = key_load_private_type(KEY_RSA1, authfile, "", NULL,
 		    &perm_ok);
-	if (private == NULL && !options.batch_mode && perm_ok) {
+
+	/*if -u flag is set just check to see if key is valid and exit.*/
+	if (options.checkey && perm_ok) {
+		snprintf(buf, sizeof(buf), "RSA key '%.100s' is Valid",comment);
+       		xfree(comment);
+         	packet_disconnect("%s",buf);
+        }
+
+	if (private == NULL && !options.batch_mode && perm_ok && !options.checkey) {
 		snprintf(buf, sizeof(buf),
 		    "Enter passphrase for RSA key '%.100s': ", comment);
 		for (i = 0; i < options.number_of_password_prompts; i++) {
--- orig/openssh-4.6p1/ssh.c	2007-01-05 00:30:17.000000000 -0500
+++ openssh-4.6p1/ssh.c	2007-05-10 11:40:06.279706888 -0400
@@ -185,7 +185,7 @@
 usage(void)
 {
 	fprintf(stderr,
-"usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]\n"
+"usage: ssh [-1246AaCfgkMNnqsTtuVvXxY] [-b bind_address] [-c cipher_spec]\n"
 "           [-D [bind_address:]port] [-e escape_char] [-F configfile]\n"
 "           [-i identity_file] [-L [bind_address:]port:host:hostport]\n"
 "           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]\n"
@@ -272,7 +272,7 @@

  again:
 	while ((opt = getopt(ac, av,
-	    "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:MNO:PR:S:TVw:XY")) != -1) {
+	    "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:MNO:PR:S:TuVw:XY")) != -1) {
 		switch (opt) {
 		case '1':
 			options.protocol = SSH_PROTO_1;
@@ -523,6 +523,9 @@
 		case 'F':
 			config = optarg;
 			break;
+		case 'u':
+			options.checkey = 1;
+			break;
 		default:
 			usage();
 		}
--- orig/openssh-4.6p1/readconf.c	2007-02-19 06:12:54.000000000 -0500
+++ openssh-4.6p1/readconf.c	2007-05-10 11:31:54.924404248 -0400
@@ -1065,6 +1065,7 @@
 	options->tun_remote = -1;
 	options->local_command = NULL;
 	options->permit_local_command = -1;
+	options->checkey = 0;
 }

 /*
--- orig/openssh-4.6p1/readconf.h	2006-08-04 22:39:40.000000000 -0400
+++ openssh-4.6p1/readconf.h	2007-05-10 11:29:55.636538760 -0400
@@ -120,6 +120,7 @@

 	char	*local_command;
 	int	permit_local_command;
+	int 	checkey;

 }       Options;

From postmaster at mx.aduana.argo.com.br  Thu Aug 23 08:24:41 2007
From: postmaster at mx.aduana.argo.com.br (MailScanner)
Date: Wed, 22 Aug 2007 18:24:41 -0400
Subject: {Spam?} Aviso: Detectado vírus no e-mail
Message-ID: <200708222224.l7MMOfAN013043@mx.aduana.argo.com.br>

Nosso sistema de detec??o de v?rus foi ativado por uma mensagem
que voc? enviou para:-
  To: ksantiago at aduana-dsp.com.br
  Subject: Re: Fotos!!
  Date: Wed Aug 22 18:24:39 2007

Um ou mais dos anexos encontra-se na lista de tipos de arquivo
pro?bidos pelo sistema e n?o poder? ser entregue.

Considere renomear o(s) arquivo(s) anexos ou coloque-os em formato
comprimido ("ZIP") para evitar este tipo de problema.

Nosso sistema de anti-virus relatou o seguinte a respeito da sua mensagem:
Relat?rio: Reporte: MailScanner: Shortcuts to MS-Dos programs are very dangerous in email (Fotos21.pif)
Reporte: Blocked Filetype Detected (Fotos21.pif)


-- 
Postmaster
Aduana Despachos e Assessoria de Com. Exterior
www.aduana-dsp.com.br

From a.michelizza at gmail.com  Thu Aug 23 19:18:15 2007
From: a.michelizza at gmail.com (Michelizza Arnauld)
Date: Thu, 23 Aug 2007 11:18:15 +0200
Subject: PAM_RUSER questions
Message-ID: <46c34de0708230218l7db8ba0cj3aa7ad04b3e50681@mail.gmail.com>

By looking at the code, I saw that PAM_RUSER is not set by sshd.
Is there a reason why ?
If I write a patch to add that feature, is there a chance for it to be
included in the main distrib ?

Best regards,

Arnauld

From Jan.Pechanec at Sun.COM  Fri Aug 24 05:36:48 2007
From: Jan.Pechanec at Sun.COM (Jan Pechanec)
Date: Thu, 23 Aug 2007 21:36:48 +0200 (CEST)
Subject: PAM_RUSER questions
In-Reply-To: <46c34de0708230218l7db8ba0cj3aa7ad04b3e50681@mail.gmail.com>
References: <46c34de0708230218l7db8ba0cj3aa7ad04b3e50681@mail.gmail.com>
Message-ID: <Pine.GSO.4.61.0708231229240.428282@fossa.czech.sun.com>

On Thu, 23 Aug 2007, Michelizza Arnauld wrote:

>By looking at the code, I saw that PAM_RUSER is not set by sshd.
>Is there a reason why ?
>If I write a patch to add that feature, is there a chance for it to be
>included in the main distrib ?

	speaking for myself - PAM_RUSER is rsh/rlogin stuff and should not 
be used for other apps since its value is not trusted; it's useless for 
audit logs, for example. Aside from hostbased auth (and gss-api maybe, I'm 
not sure now), you can use anything as a value for the remote user client 
field and it can't be verified. For example, Solaris uses PAM_AUSER (audited 
user) for hostbased and for this one auth method a remote user can log in 
directly to a role because as far as the remote host is trusted, the 
information on remote client username is trusted. J.

-- 
Jan Pechanec

From ritamcm at earthlink.net  Fri Aug 24 13:44:53 2007
From: ritamcm at earthlink.net (ritamcm at earthlink.net)
Date: Thu, 23 Aug 2007 23:44:53 -0400 (GMT-04:00)
Subject: Unable to use the Banner keyword in a Match Block in OpenSSH 4.4p1
Message-ID: <29788974.1187927093571.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>

I am running Openssh 4.4p1 on a Solaris 9 server.  I would like the accting service account to be able to run accounting scripts from a central server without the standard pre-login banner. At the end of the sshd_config file I have the following, where /etc/nobanner is an empty file:

Banner /etc/issue
Match User accting
       Banner /etc/nobanner

When an attempt is made to restart sshd, the error is:
/usr/local/etc/sshd_config line 127:  Directive 'Banner' is not allowed within a Match block


However, when I look at the manual page for sshd_config at openssh.org, Banner is listed as an keyword under Match.  What is the correct way to use the Banner keyword in a Match block in openssh 4.4p1?  

Thanks for your help,

Rita



From stuge-openssh-unix-dev at cdy.org  Sat Aug 25 01:35:52 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 24 Aug 2007 17:35:52 +0200
Subject: Unable to use the Banner keyword in a Match Block in OpenSSH 4.4p1
In-Reply-To: <29788974.1187927093571.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
References: <29788974.1187927093571.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Message-ID: <20070824153552.14028.qmail@cdy.org>

Hi Rita,

On Thu, Aug 23, 2007 at 11:44:53PM -0400, ritamcm at earthlink.net wrote:
> However, when I look at the manual page for sshd_config at
> openssh.org, Banner is listed as an keyword under Match.  What is
> the correct way to use the Banner keyword in a Match block in
> openssh 4.4p1?  

I'm not sure that is possible. The man page probably refers to the
very latest release of OpenSSH. 4.4p1 is a bit old. Match support has
been added for several directives lately and Banner may be one of
them.

Please try the latest version.


//Peter

From dtucker at zip.com.au  Sat Aug 25 08:26:55 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 25 Aug 2007 08:26:55 +1000
Subject: Unable to use the Banner keyword in a Match Block in OpenSSH 4.4p1
In-Reply-To: <20070824153552.14028.qmail@cdy.org>
References: <29788974.1187927093571.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
	<20070824153552.14028.qmail@cdy.org>
Message-ID: <46CF5B2F.8090009@zip.com.au>

Peter Stuge wrote:
> Hi Rita,
> 
> On Thu, Aug 23, 2007 at 11:44:53PM -0400, ritamcm at earthlink.net wrote:
>> However, when I look at the manual page for sshd_config at
>> openssh.org, Banner is listed as an keyword under Match.  What is
>> the correct way to use the Banner keyword in a Match block in
>> openssh 4.4p1?  
> 
> I'm not sure that is possible. The man page probably refers to the
> very latest release of OpenSSH.

Actually by default the man page links show the development version, ie 
CVS HEAD.  You can use the little drop-down to select OpenBSD 4.1 
(OpenSSH 4.6) or OpenBSD 4.0 (OpenSSH 4.4) and compare.

Where possible, you should always refer to the man pages that shipped 
with the binaries that you're using as they are authoritative for those 
binaries.

> 4.4p1 is a bit old. Match support has
> been added for several directives lately and Banner may be one of
> them.

Exactly so.  Support for keywords used before authentication, including 
Banner, was added in OpenSSH 4.6.

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

From pekkas at netcore.fi  Wed Aug 29 19:04:33 2007
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 29 Aug 2007 12:04:33 +0300 (EEST)
Subject: reverse mapping check; authentication methods
Message-ID: <Pine.LNX.4.64.0708290844580.29882@netcore.fi>

Hello all,

My logs get filled with bogus SSH connection attemps which I'd expect 
should have been denied without logging, so a couple of observations. 
Syslog has lots of entries like:

Aug 29 02:23:31 otso sshd[21000]: reverse mapping checking getaddrinfo for
powered.by.e-leven.be [78.110.207.104] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 29 02:23:31 otso sshd[21000]: Invalid user upload from 78.110.207.104

and these also show as multiple 'lastb' entries in btmp:

upload   ssh:notty    78.110.207.104   Wed Aug 29 02:23 - 02:23  (00:00)
upload   ssh:notty    78.110.207.104   Wed Aug 29 02:23 - 02:23  (00:00)
upload   ssh:notty    78.110.207.104   Wed Aug 29 02:23 - 02:23  (00:00)
upload   ssh:notty    78.110.207.104   Wed Aug 29 02:23 - 02:23  (00:00)
upload   ssh:notty    78.110.207.104   Wed Aug 29 02:23 - 02:23  (00:00)
upload   ssh:notty    78.110.207.104   Wed Aug 29 02:23 - 02:23  (00:00)
...

This is a bit unexpected for two reasons: AllowUsers directive exists 
and these users aren't listed there, and PasswordAuthentication is 
disabled for them [1].  Yet they clutter the logs.

Looking at the code, it seems that the getaddrinfo failures don't seem 
to result in the connection being rejected, even though the man page 
would seem to indicate so[2] though is not explicit about it.  It also 
seems that the possible authentication methods are only checked 
(do_authloop in SSH1) after it has been verified whether the user 
exists (causing these log messages).  Likewise, in auth.c getpwnam() 
is executed for the attempted user even if the user is not listed in 
AllowUsers.

Would it make sense to check the usernames and hosts later, avoiding 
unnecessary log clutter?  Or is all of this intentional and due to 
trying to avoid being able to use SSH to divulge whether a user is 
allowed to log in or not?

[1] config is substantially as follows:
==8<===
Protocol 2,1

AllowUsers foo bar
PasswordAuthentication no

Match Host *.fi
         PasswordAuthentication yes
Match Host 2002:*
         PasswordAuthentication yes
==8<===

[2]
UseDNS Specifies whether sshd(8) should look up the remote host name 
and check that the resolved host name for the remote IP address maps 
back to the very same IP address.  The default is "yes".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From jdthebigj at yahoo.com  Fri Aug 31 07:02:22 2007
From: jdthebigj at yahoo.com (Jaideep Padhye)
Date: Thu, 30 Aug 2007 14:02:22 -0700 (PDT)
Subject: Modifying OpenSSH
Message-ID: <938964.46595.qm@web50908.mail.re2.yahoo.com>

I'm a research student and I need to modify openSSH in
a way that I can implement my algorithm in it. My
algorithm mostly involves buffering the packets which
are received by the user using some formula to remove
the timing information in packets. Also the second
part is to encapsulate SSH packets into RTP packets
while communicating with a modified SSH server. The
client embeds SSH packets as RTP payload and on the
other end the server decodes it and does the process
vice-versa. I need guidance regarding following
issues:

1] Which is they best way to try and understand the
openSSH source code for implementing the buffering? My
idea is to use the same buffers which SSH uses by
controlling when I enqueue and dequeue packets. 

2] Can anybody point out to a set of files which I
should be first looking at for implementing these
features?

3] I have already read the RFC but i'm interested in
finding out if there is any other way to figure out
how a certain application works? I tried using the
sshd logs to understand the program flow but it is not
helping much. I'm not a experienced programmer and I'm
still trying figure out my way in the open source
world.

Thanks,

JD 


       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/