From bruce.korb at gmail.com  Tue Jul  1 02:01:12 2008
From: bruce.korb at gmail.com (Bruce Korb)
Date: Mon, 30 Jun 2008 09:01:12 -0700
Subject: Build bug and execution bug
Message-ID: <668c430c0806300901w7011175fq53d05efcc4740c9c@mail.gmail.com>

The build bug:  DESTDIR=$SOMEDIR does not work:

mkdir ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc
${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/sbin/sshd -t -f
${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc/sshd_config
Could not load host key: /usr/local/etc/ssh_host_rsa_key
Could not load host key: /usr/local/etc/ssh_host_dsa_key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.
make: [check-config] Error 1 (ignored)

(the current version is rooted in /usr, not /usr/local, and these
files live in /etc/ssh.)

==============

Anyway, the problem that starts it all:

http://www.linuxquestions.org/questions/linux-networking-3/connection-refused-on-remoteforward-ed-port-652472/#post3198878

basically, the "RemoteForward" is not working as expected.
It works with my client side daemon running 0.9.8c and 0.9.8e
(as reported by "ssh", not "sshd"), but not with 0.9.8g.  On the
server side, I invoke:

/usr/bin/ssh -v -q -g -R ${PORT}:localhost:22 -n \
 -o BatchMode=yes -o StrictHostKeyChecking=no <home-mach>

The only user allowed to ssh in has a shell that does nothing except
keep the connection open.

On my home machine, I then attempt:

 ssh -X -p ${PORT} <work-uname>@localhost

The result (with "-vv'):
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data ${HOME}/.ssh/config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port ${PORT}.
debug1: connect to address 127.0.0.1 port ${PORT}: Connection refused
debug1: Connecting to localhost [::1] port ${PORT}.
debug1: connect to address ::1 port ${PORT}: Connection refused
ssh: connect to host localhost port ${PORT}: Connection refused


============

Help, please?  :)

From mouring at eviladmin.org  Tue Jul  1 06:33:45 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Mon, 30 Jun 2008 15:33:45 -0500 (CDT)
Subject: Build bug and execution bug
In-Reply-To: <668c430c0806300901w7011175fq53d05efcc4740c9c@mail.gmail.com>
References: <668c430c0806300901w7011175fq53d05efcc4740c9c@mail.gmail.com>
Message-ID: <alpine.BSO.1.00.0806301532580.30973@miyako.eviladmin.org>


DESTDIR doesn't replace doing a ./configure --prefix=/path/you/want/

DESTDIR just allows you to do a "make install" into a different place than 
what the --prefix has defined.

- Ben

On Mon, 30 Jun 2008, Bruce Korb wrote:

> The build bug:  DESTDIR=$SOMEDIR does not work:
>
> mkdir ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc
> ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/sbin/sshd -t -f
> ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc/sshd_config
> Could not load host key: /usr/local/etc/ssh_host_rsa_key
> Could not load host key: /usr/local/etc/ssh_host_dsa_key
> Disabling protocol version 2. Could not load host key
> sshd: no hostkeys available -- exiting.
> make: [check-config] Error 1 (ignored)
>
> (the current version is rooted in /usr, not /usr/local, and these
> files live in /etc/ssh.)
>
> ==============
>
> Anyway, the problem that starts it all:
>
> http://www.linuxquestions.org/questions/linux-networking-3/connection-refused-on-remoteforward-ed-port-652472/#post3198878
>
> basically, the "RemoteForward" is not working as expected.
> It works with my client side daemon running 0.9.8c and 0.9.8e
> (as reported by "ssh", not "sshd"), but not with 0.9.8g.  On the
> server side, I invoke:
>
> /usr/bin/ssh -v -q -g -R ${PORT}:localhost:22 -n \
> -o BatchMode=yes -o StrictHostKeyChecking=no <home-mach>
>
> The only user allowed to ssh in has a shell that does nothing except
> keep the connection open.
>
> On my home machine, I then attempt:
>
> ssh -X -p ${PORT} <work-uname>@localhost
>
> The result (with "-vv'):
> OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
> debug1: Reading configuration data ${HOME}/.ssh/config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to localhost [127.0.0.1] port ${PORT}.
> debug1: connect to address 127.0.0.1 port ${PORT}: Connection refused
> debug1: Connecting to localhost [::1] port ${PORT}.
> debug1: connect to address ::1 port ${PORT}: Connection refused
> ssh: connect to host localhost port ${PORT}: Connection refused
>
>
> ============
>
> Help, please?  :)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From bruce.korb at gmail.com  Tue Jul  1 06:43:30 2008
From: bruce.korb at gmail.com (Bruce Korb)
Date: Mon, 30 Jun 2008 13:43:30 -0700
Subject: Build bug and execution bug
In-Reply-To: <alpine.BSO.1.00.0806301532580.30973@miyako.eviladmin.org>
References: <668c430c0806300901w7011175fq53d05efcc4740c9c@mail.gmail.com>
	<alpine.BSO.1.00.0806301532580.30973@miyako.eviladmin.org>
Message-ID: <668c430c0806301343v71dc3718yf28d4141fd3a25e2@mail.gmail.com>

Hi Ben,

> DESTDIR just allows you to do a "make install" into a different place than
> what the --prefix has defined.

Yes, I know that.  The reason you do that is so you can stage an install
and roll it up for multiple installs.  So, "make install DESTDIR=$stagedir"
should work.  It does not.  Anyhow, that is a minor issue.  The major,
incapacitating issue is that I simply cannot get RemoteForward to work.
I cannot figure out how to debug the problem, either.  *ANY* hints would
be extremely welcome.  I am currently completely unable to work.

Thank you. - Bruce

On Mon, Jun 30, 2008 at 1:33 PM, Ben Lindstrom <mouring at eviladmin.org> wrote:
>> Anyway, the problem that starts it all:
>>
>> http://www.linuxquestions.org/questions/linux-networking-3/connection-refused-on-remoteforward-ed-port-652472/#post3198878
>>
>> basically, the "RemoteForward" is not working as expected.
>> It works with my client side daemon running 0.9.8c and 0.9.8e
>> (as reported by "ssh", not "sshd"), but not with 0.9.8g.  On the
>> server side, I invoke:
>>
>> /usr/bin/ssh -v -q -g -R ${PORT}:localhost:22 -n \
>> -o BatchMode=yes -o StrictHostKeyChecking=no <home-mach>
>>
>> The only user allowed to ssh in has a shell that does nothing except
>> keep the connection open.
>>
>> On my home machine, I then attempt:
>>
>> ssh -X -p ${PORT} <work-uname>@localhost
>>
>> The result (with "-vv'):
>> OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
>> debug1: Reading configuration data ${HOME}/.ssh/config
>> debug2: ssh_connect: needpriv 0
>> debug1: Connecting to localhost [127.0.0.1] port ${PORT}.
>> debug1: connect to address 127.0.0.1 port ${PORT}: Connection refused
>> debug1: Connecting to localhost [::1] port ${PORT}.
>> debug1: connect to address ::1 port ${PORT}: Connection refused
>> ssh: connect to host localhost port ${PORT}: Connection refused
>>
>> ============
>>
>> Help, please?  :)

From dtucker at zip.com.au  Tue Jul  1 07:45:43 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 1 Jul 2008 07:45:43 +1000
Subject: Build bug and execution bug
In-Reply-To: <668c430c0806300901w7011175fq53d05efcc4740c9c@mail.gmail.com>
References: <668c430c0806300901w7011175fq53d05efcc4740c9c@mail.gmail.com>
Message-ID: <e8958b630806301445u74fed8a5l5e71c36f29c1a52e@mail.gmail.com>

On Tue, Jul 1, 2008 at 2:01 AM, Bruce Korb <bruce.korb at gmail.com> wrote:
> The build bug:  DESTDIR=$SOMEDIR does not work:
>
> mkdir ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc
> ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/sbin/sshd -t -f
> ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc/sshd_config
> Could not load host key: /usr/local/etc/ssh_host_rsa_key
> Could not load host key: /usr/local/etc/ssh_host_dsa_key
> Disabling protocol version 2. Could not load host key
> sshd: no hostkeys available -- exiting.
> make: [check-config] Error 1 (ignored)

That looks like the install worked but the "sshd -t" test failed
because sshd did not have permission to read the keys that it's
configured to use (via --prefix or --sysconfdir as Ben mentioned).
Try "make install-nokeys DESTDIR=foo" instead.

[...]
> It works with my client side daemon running 0.9.8c and 0.9.8e
> (as reported by "ssh", not "sshd"), but not with 0.9.8g.

Those are versions of the OpenSSL library that OpenSSH uses.  What are
the versions of ssh and sshd?

> On the server side, I invoke:
>
> /usr/bin/ssh -v -q -g -R ${PORT}:localhost:22 -n \
>  -o BatchMode=yes -o StrictHostKeyChecking=no <home-mach>

The output of this command would be interesting (particularly with
"-vvv") to see if the remote forwarding request was actually accepted
by the server.  You could also add "-o ExitOnForwardFailure=yes" to
make sure that the tunnel is established.

> The only user allowed to ssh in has a shell that does nothing except
> keep the connection open.
[...]

My guess is that the server (ie the thing running sshd) has
"AllowTcpForwarding no" in its sshd_config.

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

From dwmw2 at infradead.org  Tue Jul  1 18:36:34 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 01 Jul 2008 09:36:34 +0100
Subject: [PATCH] SOCKS4A support
Message-ID: <1214901394.10393.382.camel@pmac.infradead.org>

This provides SOCKS4A support, which allows a SOCKS4 client to provide a
host name instead of an IP address. It indicates that it's doing so by
using a known-invalid IP address 0.0.0.x (where x != 0), and then
appending the NUL-terminated hostname to the connection request.

Although we check for the terminating NUL manually and the
'fatal(len %d > have %d)' should never happen, the condition for it (in
the existing processing of the username) seems to have been off-by-one;
not accounting for the terminating NUL. I've fixed that while I'm at it.

--- openssh-5.0p1/channels.c~	2008-04-09 17:06:20.000000000 +0100
+++ openssh-5.0p1/channels.c	2008-07-01 09:34:51.000000000 +0100
@@ -1028,7 +1028,7 @@ static int
 channel_decode_socks4(Channel *c, fd_set *readset, fd_set *writeset)
 {
 	char *p, *host;
-	u_int len, have, i, found;
+	u_int len, have, i, found, need;
 	char username[256];
 	struct {
 		u_int8_t version;
@@ -1044,10 +1044,20 @@ channel_decode_socks4(Channel *c, fd_set
 	if (have < len)
 		return 0;
 	p = buffer_ptr(&c->input);
+
+	need = 1;
+	/* SOCKS4A uses an invalid IP address 0.0.0.x */
+	if (!p[4] && !p[5] && !p[6] && p[7]) {
+		debug2("channel %d: socks4a request", c->self);
+		/* ... and needs an extra string (the hostname) */
+		need = 2;
+	}
+	/* Check for terminating NUL on the string(s) */
 	for (found = 0, i = len; i < have; i++) {
 		if (p[i] == '\0') {
-			found = 1;
-			break;
+			found++;
+			if (found == need)
+				break;
 		}
 		if (i > 1024) {
 			/* the peer is probably sending garbage */
@@ -1056,7 +1066,7 @@ channel_decode_socks4(Channel *c, fd_set
 			return -1;
 		}
 	}
-	if (!found)
+	if (found < need)
 		return 0;
 	buffer_get(&c->input, (char *)&s4_req.version, 1);
 	buffer_get(&c->input, (char *)&s4_req.command, 1);
@@ -1066,19 +1076,33 @@ channel_decode_socks4(Channel *c, fd_set
 	p = buffer_ptr(&c->input);
 	len = strlen(p);
 	debug2("channel %d: decode socks4: user %s/%d", c->self, p, len);
+	len++;					/* trailing '\0' */
 	if (len > have)
 		fatal("channel %d: decode socks4: len %d > have %d",
 		    c->self, len, have);
 	strlcpy(username, p, sizeof(username));
 	buffer_consume(&c->input, len);
-	buffer_consume(&c->input, 1);		/* trailing '\0' */
 
-	host = inet_ntoa(s4_req.dest_addr);
-	strlcpy(c->path, host, sizeof(c->path));
+	if (need == 1) {			/* SOCKS4: one string */
+		host = inet_ntoa(s4_req.dest_addr);
+		strlcpy(c->path, host, sizeof(c->path));
+	} else {				/* SOCKS4A: two strings */
+		have = buffer_len(&c->input);
+		p = buffer_ptr(&c->input);
+		len = strlen(p);
+		debug2("channel %d: decode socks4a: host %s/%d", c->self, p,
+		       len);
+		len++;				/* trailing '\0' */
+		if (len > have)
+			fatal("channel %d: decode socks4a: len %d > have %d",
+			      c->self, len, have);
+		strlcpy(c->path, p, sizeof(c->path));
+		buffer_consume(&c->input, len);
+	}
 	c->host_port = ntohs(s4_req.dest_port);
 
 	debug2("channel %d: dynamic request: socks4 host %s port %u command %u",
-	    c->self, host, c->host_port, s4_req.command);
+	    c->self, c->path, c->host_port, s4_req.command);
 
 	if (s4_req.command != 1) {
 		debug("channel %d: cannot handle: socks4 cn %d",



-- 
dwmw2


From djm at mindrot.org  Tue Jul  1 20:39:58 2008
From: djm at mindrot.org (Damien Miller)
Date: Tue, 1 Jul 2008 20:39:58 +1000 (EST)
Subject: [PATCH] SOCKS4A support
In-Reply-To: <1214901394.10393.382.camel@pmac.infradead.org>
References: <1214901394.10393.382.camel@pmac.infradead.org>
Message-ID: <alpine.BSO.1.10.0807012038440.30182@fuyu.mindrot.org>

On Tue, 1 Jul 2008, David Woodhouse wrote:

> This provides SOCKS4A support, which allows a SOCKS4 client to provide a
> host name instead of an IP address. It indicates that it's doing so by
> using a known-invalid IP address 0.0.0.x (where x != 0), and then
> appending the NUL-terminated hostname to the connection request.

How many programs speak SOCKS4A and not SOCKS5?

-d


From dwmw2 at infradead.org  Tue Jul  1 23:09:38 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 01 Jul 2008 14:09:38 +0100
Subject: [PATCH] SOCKS4A support
In-Reply-To: <alpine.BSO.1.10.0807012038440.30182@fuyu.mindrot.org>
References: <1214901394.10393.382.camel@pmac.infradead.org>
	<alpine.BSO.1.10.0807012038440.30182@fuyu.mindrot.org>
Message-ID: <1214917778.10393.394.camel@pmac.infradead.org>

On Tue, 2008-07-01 at 20:39 +1000, Damien Miller wrote:
> On Tue, 1 Jul 2008, David Woodhouse wrote:
> 
> > This provides SOCKS4A support, which allows a SOCKS4 client to provide a
> > host name instead of an IP address. It indicates that it's doing so by
> > using a known-invalid IP address 0.0.0.x (where x != 0), and then
> > appending the NUL-terminated hostname to the connection request.
> 
> How many programs speak SOCKS4A and not SOCKS5?

socat, for a start, which was the first thing I tried when I started
trying to use SOCKS. Not sure what else.

-- 
dwmw2


From wong_stan at yahoo.com  Tue Jul  1 03:53:26 2008
From: wong_stan at yahoo.com (Stan Wong)
Date: Mon, 30 Jun 2008 10:53:26 -0700 (PDT)
Subject: SFTP v4.9/v5.0 Protocol Differences
Message-ID: <747425.46518.qm@web51609.mail.re2.yahoo.com>

I have a problem with an embedded system which is acting as a SFTP client.? I get different repsonses from the SFTP server depending on if it is OpenSSH version 5.0 or versions 4.x.? The SFTP client speaks SFTP protocol version 3.

With OpenSSH version 5.0, the embedded SFTP client panics because it receives something it thinks it shouldn't get at the start of a data transfer from the server.? I have traced it to a section of code where it is processing incoming packets and it doesn't know what to do with what it has received.? The code comment at this section is "Message an sftp client should never receive".? I haven't been able to do a data dump at this point, yet, to find out exactly what it is receiving.

I do not have a problem if I use OpenSSH 4.9 or earlier.? Can anyone tell me what might have changed in the SFTP protocol section from v4.9 to v5.0?

I have tested with the following SFTP servers:

COPSSH (Windows, Cygwin, OpenSSH)
? OpenSSH 5.0p1-1? (doesn't work)
? OpenSSH 4.7p1
? OpenSSH 4.5p1
? 
Fedora 7
? OpenSSH 4.5p1-6
? 
I have searched the archives and Bugzilla but don't find any reports similar to my problem.? If this has been reported, can anyone can point me to the post or Bugzilla entry?? If anyone has information or ideas I'd appreciate those, too.? Thanks.





      

From dan at doxpara.com  Wed Jul  2 02:28:28 2008
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 01 Jul 2008 09:28:28 -0700
Subject: [PATCH] SOCKS4A support
In-Reply-To: <alpine.BSO.1.10.0807012038440.30182@fuyu.mindrot.org>
References: <1214901394.10393.382.camel@pmac.infradead.org>
	<alpine.BSO.1.10.0807012038440.30182@fuyu.mindrot.org>
Message-ID: <486A5B2C.8080909@doxpara.com>

Damien Miller wrote:
> On Tue, 1 Jul 2008, David Woodhouse wrote:
>
>   
>> This provides SOCKS4A support, which allows a SOCKS4 client to provide a
>> host name instead of an IP address. It indicates that it's doing so by
>> using a known-invalid IP address 0.0.0.x (where x != 0), and then
>> appending the NUL-terminated hostname to the connection request.
>>     
>
> How many programs speak SOCKS4A and not SOCKS5?
>   
There are a few -- and if I remember, they just always do SOCKS4A.  
Basically people assume that it's part of the SOCKS4 standard, given how 
absurdly trivial SOCKS4 itself is.

--Dan


From g.chulkov at jacobs-university.de  Wed Jul  2 04:42:45 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Tue, 1 Jul 2008 20:42:45 +0200
Subject: Processes and mmap
Message-ID: <200807012042.49024.g.chulkov@jacobs-university.de>

Hello,

For a key exchange algorithm I'm working on, I would like to keep a little bit 
of shared state between the main server process and the processes that 
clients connect to. So far, I'm considering mmap for the purpose.

But I cannot figure out where I need to put the mmap initialization call, 
where it would be called at server startup (before any fork()s/exec()s), and 
never again.

Could someone please briefly explain how OpenSSH manages its various 
processes - such as when processes are created and where in the code that 
happens?

Thanks in advance!

Georgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080701/ec34b470/attachment.bin 

From dtucker at zip.com.au  Wed Jul  2 06:31:40 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 02 Jul 2008 06:31:40 +1000
Subject: Processes and mmap
In-Reply-To: <200807012042.49024.g.chulkov@jacobs-university.de>
References: <200807012042.49024.g.chulkov@jacobs-university.de>
Message-ID: <486A942C.4090903@zip.com.au>

Georgi Chulkov wrote:
> Hello,
> 
> For a key exchange algorithm I'm working on, I would like to keep a little bit 
> of shared state between the main server process and the processes that 
> clients connect to. So far, I'm considering mmap for the purpose.
> 
> But I cannot figure out where I need to put the mmap initialization call, 
> where it would be called at server startup (before any fork()s/exec()s), and 
> never again.
> 
> Could someone please briefly explain how OpenSSH manages its various 
> processes - such as when processes are created and where in the code that 
> happens?

Try Neils Provos' paper on privsep:
http://www.citi.umich.edu/u/provos/ssh/privsep.html

If you still have questions after reading that, then please feel free to 
ask here.

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

From g.chulkov at jacobs-university.de  Fri Jul  4 07:58:24 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Thu, 3 Jul 2008 23:58:24 +0200
Subject: Processes and mmap
In-Reply-To: <486A942C.4090903@zip.com.au>
References: <200807012042.49024.g.chulkov@jacobs-university.de>
	<486A942C.4090903@zip.com.au>
Message-ID: <200807032358.26824.g.chulkov@jacobs-university.de>

> Try Neils Provos' paper on privsep:
> http://www.citi.umich.edu/u/provos/ssh/privsep.html
>
> If you still have questions after reading that, then please feel free to
> ask here.

Thanks for the reference, that was a very good read. Unfortunately I cannot 
quite understand the paragraph that stars at the end of page 4 ("Figure 3 
shows an overview..."). In particular, I do not understand:

1) Why is the shared address space "back" necessary?
2) What does mm_share_sync do?
3) What is the difference between mm using libc's malloc, as opposed to mm 
using back which itself uses libc's malloc?

I will now try to figure out the source code that implements privilage 
separation, and I will post any other questions I might have.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080703/81c6ae0d/attachment.bin 

From dtucker at zip.com.au  Fri Jul  4 08:42:14 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 04 Jul 2008 08:42:14 +1000
Subject: Processes and mmap
In-Reply-To: <200807032358.26824.g.chulkov@jacobs-university.de>
References: <200807012042.49024.g.chulkov@jacobs-university.de>	<486A942C.4090903@zip.com.au>
	<200807032358.26824.g.chulkov@jacobs-university.de>
Message-ID: <486D55C6.3090901@zip.com.au>

Georgi Chulkov wrote:
>> Try Neils Provos' paper on privsep:
>> http://www.citi.umich.edu/u/provos/ssh/privsep.html
>>
>> If you still have questions after reading that, then please feel free to
>> ask here.
> 
> Thanks for the reference, that was a very good read. Unfortunately I cannot 
> quite understand the paragraph that stars at the end of page 4 ("Figure 3 
> shows an overview..."). In particular, I do not understand:
> 
> 1) Why is the shared address space "back" necessary?

For handling things like the zlib compression state.  This state 
includes things like compression dictionaries that are needed to 
decompress the data from the client, and their content changes over time.

Since zlib compression can be negotiated before the connection is 
authenticated, it means that the compression state has to be available 
to both the preauth and post-auth privsep slaves.

> 2) What does mm_share_sync do?

The shared memory allocator keeps accounting records of its allocations. 
  For the most part these are held in normal dynamically allocated memory.

When the first privsep process exits, it copies these accounting records 
to the shared memory area in a format that the new (post-auth) privsep 
process can unpack and use to continue managing the shared memory area.

> 3) What is the difference between mm using libc's malloc, as opposed to mm 
> using back which itself uses libc's malloc?

I'm not sure I follow this question.  If you allocate memory from "back" 
the memory you allocated is in the shared memory area.  The information 
about the allocation (the metadata) is in non-shared memory, and this 
metadata is what is copied by mm_share_sync.

> I will now try to figure out the source code that implements privilage 
> separation, and I will post any other questions I might have.

-- 
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 g.chulkov at jacobs-university.de  Fri Jul  4 09:02:00 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Fri, 4 Jul 2008 01:02:00 +0200
Subject: Processes and mmap
In-Reply-To: <486D55C6.3090901@zip.com.au>
References: <200807012042.49024.g.chulkov@jacobs-university.de>
	<200807032358.26824.g.chulkov@jacobs-university.de>
	<486D55C6.3090901@zip.com.au>
Message-ID: <200807040102.02684.g.chulkov@jacobs-university.de>

> > 1) Why is the shared address space "back" necessary?
>
> For handling things like the zlib compression state.  This state
> includes things like compression dictionaries that are needed to
> decompress the data from the client, and their content changes over time.
>
> Since zlib compression can be negotiated before the connection is
> authenticated, it means that the compression state has to be available
> to both the preauth and post-auth privsep slaves.

I understand that there are things that need to remain between the slaves. I 
do not understand why mm is not sufficient by itself. 

> > 2) What does mm_share_sync do?
>
> The shared memory allocator keeps accounting records of its allocations.
>   For the most part these are held in normal dynamically allocated memory.
>
> When the first privsep process exits, it copies these accounting records
> to the shared memory area in a format that the new (post-auth) privsep
> process can unpack and use to continue managing the shared memory area.

I'm sorry, I still don't get it. So shared memory is kept in mm. mm itself was 
created by the monitor process, so nothing in there goes away when the first 
privsep slave exits. Why can't the monitor just pass mm back to the second 
slave?

Also, if mm_share_sync copies shared memory allocator metadata, where does it 
copy it to?

> > 3) What is the difference between mm using libc's malloc, as opposed to
> > mm using back which itself uses libc's malloc?
>
> I'm not sure I follow this question.  If you allocate memory from "back"
> the memory you allocated is in the shared memory area.  The information
> about the allocation (the metadata) is in non-shared memory, and this
> metadata is what is copied by mm_share_sync.

This question directly addresses the paragraph I pointed to in my last e-mail. 
You say "If you allocate memory from 'back' the memory you allocated is in 
the shared memory area." Is this not true of 'mm' too?

To paraphrase my question, why do we use mm_share_sync to save back's metadata 
(which holds mm's metadata), as opposed to using mm_share_sync to save mm's 
metadata directly and not having back at all?

Thanks again.

Georgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080704/6b559202/attachment.bin 

From g.chulkov at jacobs-university.de  Fri Jul  4 10:26:17 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Fri, 4 Jul 2008 02:26:17 +0200
Subject: Processes and mmap
In-Reply-To: <200807012042.49024.g.chulkov@jacobs-university.de>
References: <200807012042.49024.g.chulkov@jacobs-university.de>
Message-ID: <200807040226.20247.g.chulkov@jacobs-university.de>

Hello again,

I have noticed that when a connection is made to the main sshd process, it 
first forks, and then execv()s itself, thur restarting itself completely. 
What is the reason for the execv()?

My other concern is that I would like to have some global state inherited from 
the main sshd process to all forked processes, which is however sensitive 
data. Is it safe to pass it as a command-line argument during the execv() 
call?

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080704/9b439588/attachment.bin 

From dtucker at zip.com.au  Fri Jul  4 10:39:33 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 04 Jul 2008 10:39:33 +1000
Subject: Processes and mmap
In-Reply-To: <200807040226.20247.g.chulkov@jacobs-university.de>
References: <200807012042.49024.g.chulkov@jacobs-university.de>
	<200807040226.20247.g.chulkov@jacobs-university.de>
Message-ID: <486D7145.4060604@zip.com.au>

Georgi Chulkov wrote:
> Hello again,
> 
> I have noticed that when a connection is made to the main sshd process, it 
> first forks, and then execv()s itself, thur restarting itself completely. 
> What is the reason for the execv()?

Some security measures, in particular address space layout 
randomization, are only applied at exec time.  Doing this means that 
each connection gets a unique layout rather than a clone of the original 
sshd.  See:

http://www.openbsd.org/papers/openssh-measures-asiabsdcon2007.pdf
http://www.openbsd.org/papers/ven05-deraadt/index.html

> My other concern is that I would like to have some global state inherited from 
> the main sshd process to all forked processes, which is however sensitive 
> data. Is it safe to pass it as a command-line argument during the execv() 
> call?

No, command line arguments are visible to all users on many systems. 
See sshd.c:send_rexec_state() for how sshd sends some state to the new 
copy (via a pipe).

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

From djm at mindrot.org  Mon Jul  7 09:30:55 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 7 Jul 2008 09:30:55 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
Message-ID: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>

Hi,

OpenSSH 5.1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This release is one of
the biggest in recent years, with two hackathons' worth of improvements
and fixes for some of our most recalcitrant bugs.

Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/ 

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

Portable OpenSSH is also available via anonymous CVS using the
instructions at http://www.openssh.com/portable.html#cvs

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

$ ./configure && make tests

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

Below is a summary of changes. More detail may be found in the
ChangeLog in the portable OpenSSH tarballs.

Thanks to the many people who contributed to this release.


New features:

 * Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1)
   and ssh-keygen(1). Visual fingerprinnt display is controlled by a new
   ssh_config(5) option "VisualHostKey". The intent is to render
   SSH host keys in a visual form that is amenable to easy recall and
   rejection of changed host keys. This technique inspired by the
   graphical hash visualisation schemes known as "random art[*]", and
   by Dan Kaminsky's musings at 23C3 in Berlin.
   Fingerprint visualisation in is currently disabled by default, as the
   algorithm used to generate the random art is still subject to change.
   [*] "Hash Visualization: a New Technique to improve Real-World
       Security", Perrig A. and Song D., 1999, International Workshop on
       Cryptographic Techniques and E-Commerce (CrypTEC '99)
   http://sparrow.ece.cmu.edu/~adrian/projects/validation/validation.pdf

 * sshd_config(5) now supports CIDR address/masklen matching in "Match
   address" blocks, with a fallback to classic wildcard matching. For 
   example:
     Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*
         PasswordAuthentication yes

 * sshd(8) now supports CIDR matching in ~/.ssh/authorized_keys
   from="..." restrictions, also with a fallback to classic wildcard
   matching.

 * Added an extended test mode (-T) to sshd(8) to request that it write
   its effective configuration to stdout and exit. Extended test mode
   also supports the specification of connection parameters (username,
   source address and hostname) to test the application of
   sshd_config(5) Match rules. 

 * sftp-server(8) now supports extension methods statvfs at openssh.com and
   fstatvfs at openssh.com that implement statvfs(2)-like operations.

 * sftp(1) now has a "df" command to the sftp client that uses the
   statvfs at openssh.com to produce a df(1)-like display of filesystem
   space and inode utilisation (requires statvfs at openssh.com support on
   the server)

 * Added a MaxSessions option to sshd_config(5) to allow control of the
   number of multiplexed sessions supported over a single TCP connection.
   This allows increasing the number of allowed sessions above the
   previous default of 10, disabling connection multiplexing 
   (MaxSessions=1) or disallowing login/shell/subsystem sessions
   entirely (MaxSessions=0).

 * Added a no-more-sessions at openssh.com global request extension that is
   sent from ssh(1) to sshd(8) when the client knows that it will never
   request another session (i.e. when session multiplexing is disabled). 
   This allows a server to disallow further session requests and
   terminate the session in cases where the client has been hijacked.

 * ssh-keygen(1) now supports the use of the -l option in combination
   with -F to search for a host in ~/.ssh/known_hosts and display its 
   fingerprint.

 * ssh-keyscan(1) now defaults to "rsa" (protocol 2) keys, instead of
   "rsa1".

 * Added an AllowAgentForwarding option to sshd_config(8) to control
   whether authentication agent forwarding is permitted. Note that this
   is a loose control, as a client may install their own unofficial
   forwarder.

 * Avoid unnecessary malloc/copy/free when receiving network data,
   resulting in a ~10% speedup

 * ssh(1) and sshd(8) will now try additional addresses when connecting
   to a port forward destination whose DNS name resolves to more than
   one address. The previous behaviour was to try the only first address
   and give up if that failed.

 * ssh(1) and sshd(8) now support signalling that channels are
   half-closed for writing, through a channel protocol extension
   notification "eow at openssh.com". This allows propagation of closed
   file descriptors, so that commands such as:
       "ssh -2 localhost od /bin/ls | true"
   do not send unnecessary data over the wire. (bz#85)

 * sshd(8): increased the default size of ssh protocol 1 ephemeral keys 
   from 768 to 1024 bits.

 * When ssh(1) has been requested to fork after authentication
   ("ssh -f") with ExitOnForwardFailure enabled, delay the fork until
   after replies for any -R forwards have been seen. Allows for robust
   detection of -R forward failure when using -f.

 * "Match group" blocks in sshd_config(5) now support negation of
   groups. E.g. "Match group staff,!guests"

 * sftp(1) and sftp-server(8) now allow chmod-like operations to set 
   set[ug]id/sticky bits.

 * The MaxAuthTries option is now permitted in sshd_config(5) match
   blocks.

 * Multiplexed ssh(1) sessions now support a subset of the ~ escapes
   that are available to a primary connection.

 * ssh(1) connection multiplexing will now fall back to creating a new
   connection in most error cases.

 * Added some basic interoperability tests against Twisted Conch.

 * Documented OpenSSH's extensions to and deviations from the published
   SSH protocols (the PROTOCOL file in the distribution)

 * Documented OpenSSH's ssh-agent protocol (PROTOCOL.agent).

Bugfixes

 * Make ssh(1) deal more gracefully with channel requests that fail.
   Previously it would optimistically assume that requests would always 
   succeed, which could cause hangs if they did not (e.g. when the
   server runs out of file descriptors).

 * ssh(1) now reports multiplexing errors via the multiplex slave's
   stderr where possible (subject to LogLevel in the mux master).

 * ssh(1) and sshd(8) now send terminate protocol banners with CR+LF for
   protocol 2 to comply with RFC 4253. Previously they were terminated
   with CR alone. Protocol 1 banners remain CR terminated.

 * Merged duplicate authentication file checks in sshd(8) and refuse to
   read authorised_keys and .shosts from non-regular files.

 * Ensure that sshd(8)'s umask disallows at least group and world write,
   even if a more permissive one has been inherited.

 * Suppress the warning message from sshd(8) when changing to a
   non-existent user home directory after chrooting.

 * Mention that scp(1) follows symlinks when performing recursive
   copies.

 * Prevent sshd(8) from erroneously applying public key restrictions
   leaned from ~/.ssh/authorized_keys to other authentication methods
   when public key authentication subsequently fails.

 * Fix protocol keepalive timeouts - in some cases, keepalive packets
   were being sent, but the connection was not being closed when the
   limit for missing replies was exceeded.

 * Fix ssh(1) sending invalid TTY modes when a TTY was forced (ssh -tt)
   but stdin was not a TTY.

 * ssh(1) will now exit with a non-zero exit status if
   ExitOnForwardFailure was set and forwardings were disabled due to a
   failed host key check.

 * Fix MaxAuthTries tests to disallow a free authentication try to
   clients that skipped the protocol 2 "none" authentication method.

 * bz#1363: Make keepalive timeouts apply while synchronously waiting
   for a packet, particularly during key renegotiation.

 * sshd(8) has been audited to eliminate fd leaks and calls to fatal()
   in conditions of file descriptor exhaustion.

Portable OpenSSH-specific bugfixes

 * Avoid a sshd(8) hang-on-exit on Solaris caused by depending on the 
   success of isatty() on a PTY master (undefined behaviour). Probably 
   affected other platforms too.

 * bz#1083: Fixed test for locked accounts on HP/UX with shadowed
   passwords disabled.

 * bz#1386: Disable poll() fallback in atomiciov for Tru64. readv
   doesn't seem to be a comparable object there, which lead to
   compilation errors.

 * bz#1447: Fall back to racy rename if link returns EXDEV.

 * bz#1467: Explicitly handle EWOULDBLOCK wherever we handle EAGAIN, on
   some platforms (HP nonstop) it is a distinct errno.

 * bz#1240: Avoid NULL dereferences in ancient sigaction replacement
   code.

 * bz#1276: Avoid linking against libgssapi, which despite its name
   doesn't seem to implement all of GSSAPI.

 * bz#1112: Use explicit noreturn attribute instead of __dead, fixing
   compilation problems on Interix.

 * bz#1241: Support password expiry on Tru64 SIA systems.

 * bz#1462: Fix an UMAC alignment problem that manifested on Itanium 
   platforms.


Damien Miller

From Zube at CS.ColoState.EDU  Mon Jul  7 11:48:17 2008
From: Zube at CS.ColoState.EDU (Zube)
Date: Sun, 6 Jul 2008 19:48:17 -0600
Subject: success: SNAP-20080707, Solaris 9 sparc, gcc 3.4.6
Message-ID: <20080707014817.GA11032@mozart.cs.colostate.edu>

All tests ok on SNAP-20080707, Solaris 9 sparc, gcc 3.4.6.

Zube

From martin at oneiros.de  Mon Jul  7 17:51:03 2008
From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=)
Date: Mon, 7 Jul 2008 09:51:03 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <68c491a60807070051o6aa1b6f8wf2f5e0287a55b59d@mail.gmail.com>

2008/7/7 Damien Miller <djm at mindrot.org>:
> Please send reports of success or failure to
> openssh-unix-dev at mindrot.org.

Success on SUSE 10.3 (x86_64, 2.6.22.18-0.2, gcc 4.2.1) and Ubuntu
(i386, 2.6.15-52, 4.0.3)

Best
   Martin

From chris at qwirx.com  Mon Jul  7 18:38:34 2008
From: chris at qwirx.com (Chris Wilson)
Date: Mon, 7 Jul 2008 09:38:34 +0100 (BST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <Pine.LNX.4.64.0807070937220.30756@top.qwarx.com>

On Mon, 7 Jul 2008, Damien Miller wrote:

> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs
> 
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
> 
> $ ./configure && make tests

Run on FC6 i386, I think it worked, the output is:

ok localcommand
run test forcecommand.sh ...
ok forced command
make[1]: Leaving directory `/tmp/openssh/regress'

Perhaps it would help if the test ended with a single line that said PASS 
or FAIL?

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | We are GNU : free your mind & your software |

From nsheridan at google.com  Mon Jul  7 19:49:41 2008
From: nsheridan at google.com (Niall Sheridan)
Date: Mon, 7 Jul 2008 10:49:41 +0100
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <ad87d7d40807070249l5e4b3c75rd88ec1ec01f7503b@mail.gmail.com>

On Mon, Jul 7, 2008 at 00:30, Damien Miller <djm at mindrot.org> wrote:
> Hi,
>
> OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release is one of
> the biggest in recent years, with two hackathons' worth of improvements
> and fixes for some of our most recalcitrant bugs.
>
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
>
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
>
> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs
>
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
>
> $ ./configure && make tests

Success on :
Fedora9 (x86_64, 2.6.25, gcc 4.3.0)
Ubuntu 8.04 (i386, 2.6.24, gcc 4.2.3)

On Ubuntu 6.06 (i386, 2.6.16-xen, gcc 4.0.3) I get 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
make[1]: Leaving directory `/tmp/openssh/regress'
make: *** [tests] Error 2


 - Niall

From wknox at mitre.org  Mon Jul  7 14:23:31 2008
From: wknox at mitre.org (Knox, Bill)
Date: Mon, 7 Jul 2008 00:23:31 -0400
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <3B660B4ACB06BE488E3938F95115E4DE02752965@IMCSRV4.MITRE.ORG>

Tested successfully on the following platforms:

Solaris 8 (sparc), gcc 3.4.2
Fedora 7 (x86), gcc 4.1.2
Ubuntu 8.04 (x86), gcc 4.2.3

                          Bill Knox
                          Lead Infosec Engineer/Scientist
                          The MITRE Corporation

-----Original Message-----
From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org
[mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf
Of Damien Miller
Sent: Sunday, July 06, 2008 7:31 PM
To: openssh-unix-dev at mindrot.org
Subject: OpenSSH 5.1: call for testing

Hi,

OpenSSH 5.1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This release is one of
the biggest in recent years, with two hackathons' worth of improvements
and fixes for some of our most recalcitrant bugs.

Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/ 

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

Portable OpenSSH is also available via anonymous CVS using the
instructions at http://www.openssh.com/portable.html#cvs

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

$ ./configure && make tests

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

Below is a summary of changes. More detail may be found in the
ChangeLog in the portable OpenSSH tarballs.

Thanks to the many people who contributed to this release.


New features:

 * Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1)
   and ssh-keygen(1). Visual fingerprinnt display is controlled by a
new
   ssh_config(5) option "VisualHostKey". The intent is to render
   SSH host keys in a visual form that is amenable to easy recall and
   rejection of changed host keys. This technique inspired by the
   graphical hash visualisation schemes known as "random art[*]", and
   by Dan Kaminsky's musings at 23C3 in Berlin.
   Fingerprint visualisation in is currently disabled by default, as
the
   algorithm used to generate the random art is still subject to
change.
   [*] "Hash Visualization: a New Technique to improve Real-World
       Security", Perrig A. and Song D., 1999, International Workshop
on
       Cryptographic Techniques and E-Commerce (CrypTEC '99)
 
http://sparrow.ece.cmu.edu/~adrian/projects/validation/validation.pdf

 * sshd_config(5) now supports CIDR address/masklen matching in "Match
   address" blocks, with a fallback to classic wildcard matching. For 
   example:
     Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*
         PasswordAuthentication yes

 * sshd(8) now supports CIDR matching in ~/.ssh/authorized_keys
   from="..." restrictions, also with a fallback to classic wildcard
   matching.

 * Added an extended test mode (-T) to sshd(8) to request that it write
   its effective configuration to stdout and exit. Extended test mode
   also supports the specification of connection parameters (username,
   source address and hostname) to test the application of
   sshd_config(5) Match rules. 

 * sftp-server(8) now supports extension methods statvfs at openssh.com
and
   fstatvfs at openssh.com that implement statvfs(2)-like operations.

 * sftp(1) now has a "df" command to the sftp client that uses the
   statvfs at openssh.com to produce a df(1)-like display of filesystem
   space and inode utilisation (requires statvfs at openssh.com support on
   the server)

 * Added a MaxSessions option to sshd_config(5) to allow control of the
   number of multiplexed sessions supported over a single TCP
connection.
   This allows increasing the number of allowed sessions above the
   previous default of 10, disabling connection multiplexing 
   (MaxSessions=1) or disallowing login/shell/subsystem sessions
   entirely (MaxSessions=0).

 * Added a no-more-sessions at openssh.com global request extension that
is
   sent from ssh(1) to sshd(8) when the client knows that it will never
   request another session (i.e. when session multiplexing is
disabled). 
   This allows a server to disallow further session requests and
   terminate the session in cases where the client has been hijacked.

 * ssh-keygen(1) now supports the use of the -l option in combination
   with -F to search for a host in ~/.ssh/known_hosts and display its 
   fingerprint.

 * ssh-keyscan(1) now defaults to "rsa" (protocol 2) keys, instead of
   "rsa1".

 * Added an AllowAgentForwarding option to sshd_config(8) to control
   whether authentication agent forwarding is permitted. Note that this
   is a loose control, as a client may install their own unofficial
   forwarder.

 * Avoid unnecessary malloc/copy/free when receiving network data,
   resulting in a ~10% speedup

 * ssh(1) and sshd(8) will now try additional addresses when connecting
   to a port forward destination whose DNS name resolves to more than
   one address. The previous behaviour was to try the only first
address
   and give up if that failed.

 * ssh(1) and sshd(8) now support signalling that channels are
   half-closed for writing, through a channel protocol extension
   notification "eow at openssh.com". This allows propagation of closed
   file descriptors, so that commands such as:
       "ssh -2 localhost od /bin/ls | true"
   do not send unnecessary data over the wire. (bz#85)

 * sshd(8): increased the default size of ssh protocol 1 ephemeral keys

   from 768 to 1024 bits.

 * When ssh(1) has been requested to fork after authentication
   ("ssh -f") with ExitOnForwardFailure enabled, delay the fork until
   after replies for any -R forwards have been seen. Allows for robust
   detection of -R forward failure when using -f.

 * "Match group" blocks in sshd_config(5) now support negation of
   groups. E.g. "Match group staff,!guests"

 * sftp(1) and sftp-server(8) now allow chmod-like operations to set 
   set[ug]id/sticky bits.

 * The MaxAuthTries option is now permitted in sshd_config(5) match
   blocks.

 * Multiplexed ssh(1) sessions now support a subset of the ~ escapes
   that are available to a primary connection.

 * ssh(1) connection multiplexing will now fall back to creating a new
   connection in most error cases.

 * Added some basic interoperability tests against Twisted Conch.

 * Documented OpenSSH's extensions to and deviations from the published
   SSH protocols (the PROTOCOL file in the distribution)

 * Documented OpenSSH's ssh-agent protocol (PROTOCOL.agent).

Bugfixes

 * Make ssh(1) deal more gracefully with channel requests that fail.
   Previously it would optimistically assume that requests would always

   succeed, which could cause hangs if they did not (e.g. when the
   server runs out of file descriptors).

 * ssh(1) now reports multiplexing errors via the multiplex slave's
   stderr where possible (subject to LogLevel in the mux master).

 * ssh(1) and sshd(8) now send terminate protocol banners with CR+LF
for
   protocol 2 to comply with RFC 4253. Previously they were terminated
   with CR alone. Protocol 1 banners remain CR terminated.

 * Merged duplicate authentication file checks in sshd(8) and refuse to
   read authorised_keys and .shosts from non-regular files.

 * Ensure that sshd(8)'s umask disallows at least group and world
write,
   even if a more permissive one has been inherited.

 * Suppress the warning message from sshd(8) when changing to a
   non-existent user home directory after chrooting.

 * Mention that scp(1) follows symlinks when performing recursive
   copies.

 * Prevent sshd(8) from erroneously applying public key restrictions
   leaned from ~/.ssh/authorized_keys to other authentication methods
   when public key authentication subsequently fails.

 * Fix protocol keepalive timeouts - in some cases, keepalive packets
   were being sent, but the connection was not being closed when the
   limit for missing replies was exceeded.

 * Fix ssh(1) sending invalid TTY modes when a TTY was forced (ssh -tt)
   but stdin was not a TTY.

 * ssh(1) will now exit with a non-zero exit status if
   ExitOnForwardFailure was set and forwardings were disabled due to a
   failed host key check.

 * Fix MaxAuthTries tests to disallow a free authentication try to
   clients that skipped the protocol 2 "none" authentication method.

 * bz#1363: Make keepalive timeouts apply while synchronously waiting
   for a packet, particularly during key renegotiation.

 * sshd(8) has been audited to eliminate fd leaks and calls to fatal()
   in conditions of file descriptor exhaustion.

Portable OpenSSH-specific bugfixes

 * Avoid a sshd(8) hang-on-exit on Solaris caused by depending on the 
   success of isatty() on a PTY master (undefined behaviour). Probably 
   affected other platforms too.

 * bz#1083: Fixed test for locked accounts on HP/UX with shadowed
   passwords disabled.

 * bz#1386: Disable poll() fallback in atomiciov for Tru64. readv
   doesn't seem to be a comparable object there, which lead to
   compilation errors.

 * bz#1447: Fall back to racy rename if link returns EXDEV.

 * bz#1467: Explicitly handle EWOULDBLOCK wherever we handle EAGAIN, on
   some platforms (HP nonstop) it is a distinct errno.

 * bz#1240: Avoid NULL dereferences in ancient sigaction replacement
   code.

 * bz#1276: Avoid linking against libgssapi, which despite its name
   doesn't seem to implement all of GSSAPI.

 * bz#1112: Use explicit noreturn attribute instead of __dead, fixing
   compilation problems on Interix.

 * bz#1241: Support password expiry on Tru64 SIA systems.

 * bz#1462: Fix an UMAC alignment problem that manifested on Itanium 
   platforms.


Damien Miller
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From martin at oneiros.de  Mon Jul  7 19:56:07 2008
From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=)
Date: Mon, 7 Jul 2008 11:56:07 +0200
Subject: ssh-vpn linux<->openbsd
Message-ID: <68c491a60807070256m23ba8f56l9b9ccf915b364770@mail.gmail.com>

Hi,
I'm trying a VPN via ssh between Linux (Suse 10.3, 5.0) and OpenBSD
(4.2, 4.7). But it doesn't work...

On Linux:
sudo ssh -v -f -w 0:1 $OPENBSD true
sudo /sbin/ifconfig tun0 10.1.1.1 10.1.1.2
sudo /sbin/route add -net 192.168.17.0 netmask 255.255.255.0 dev tun0

On OBSD:
sudo ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.0
sudo /sbin/route add 10.0.3.0/24 10.1.1.1
And add a "pass quick on tun1" to /etc/pf.conf

Then I have:
- Linux:
tun0      Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
         inet addr:10.1.1.2  P-t-P:10.1.1.2  Mask:255.255.255.255
         UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
         RX packets:18 errors:0 dropped:0 overruns:0 frame:0
         TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:500
         RX bytes:1512 (1.4 Kb)  TX bytes:1932 (1.8 Kb)
192.168.17.0    0.0.0.0         255.255.255.0   U     0      0        0 tun0
- OpenBSD:
tun1: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
       groups: tun
       inet 10.1.1.2 --> 10.1.1.1 netmask 0xffffff00
10.0.3/24          10.1.1.1           UGS         0        8      -   tun1
10.1.1.1           10.1.1.2           UH          1        0      -   tun1

But the systems can't ping each other. :-(

What's missing?

TIA
  Martin

From gert at greenie.muc.de  Tue Jul  8 01:27:29 2008
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 7 Jul 2008 17:27:29 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <20080707152728.GE1231@greenie.muc.de>

Hi,

On Mon, Jul 07, 2008 at 09:30:55AM +1000, Damien Miller wrote:
> OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release is one of
> the biggest in recent years, with two hackathons' worth of improvements
> and fixes for some of our most recalcitrant bugs.

NetBSD 3.1 on Sparc64, CVS snapshot from "earlier today", has some 
funnies in the test suite. 

This test was run as non-root, but root makes no difference, the errors
are the same.

Here's the output of "make test" from the point where the errors start:

(cd openbsd-compat && make)
...
run test forwarding.sh ...
ok local and remote forwarding
run test multiplex.sh ...
test connection multiplexing: envpass
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
environment not found
test connection multiplexing: transfer
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
cmp: EOF on /home/gert/src/openssh_cvs/regress/ls.copy
ssh -Sctl: corrupted copy of /bin/ls
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
cmp: EOF on /home/gert/src/openssh_cvs/regress/ls.copy
ssh -S ctl: corrupted copy of /bin/ls
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
sftp: failed copy /bin/ls
cmp: /home/gert/src/openssh_cvs/regress/ls.copy: No such file or directory
sftp: corrupted copy of /bin/ls
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
scp: failed copy /bin/ls
cmp: /home/gert/src/openssh_cvs/regress/ls.copy: No such file or directory
scp: corrupted copy of /bin/ls
test connection multiplexing: status 0
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code mismatch for protocol : 255 != 0
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code (with sleep) mismatch for protocol : 255 != 0
test connection multiplexing: status 1
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code mismatch for protocol : 255 != 1
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code (with sleep) mismatch for protocol : 255 != 1
test connection multiplexing: status 4
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code mismatch for protocol : 255 != 4
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code (with sleep) mismatch for protocol : 255 != 4
test connection multiplexing: status 5
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code mismatch for protocol : 255 != 5
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code (with sleep) mismatch for protocol : 255 != 5
test connection multiplexing: status 44
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code mismatch for protocol : 255 != 44
mm_send_fd: sendmsg(0): Invalid argument
muxclient: send fds failed
Falling back to non-multiplexed connection
mm_receive_fd: recvmsg: expected received 1 got 0
muxserver_accept_control: failed to receive fd 0 from slave
ssh: Could not resolve hostname otherhost: No address associated with hostname
exit code (with sleep) mismatch for protocol : 255 != 44
Master running (pid=16839)
Exit request sent.
failed connection multiplexing
*** Error code 1

Stop.
make: stopped in /home/gert/src/openssh_cvs/regress
*** Error code 1

Stop.
make: stopped in /home/gert/src/openssh_cvs


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 stuge-openssh-unix-dev at cdy.org  Tue Jul  8 02:35:17 2008
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Mon, 7 Jul 2008 18:35:17 +0200
Subject: ssh-vpn linux<->openbsd
In-Reply-To: <68c491a60807070256m23ba8f56l9b9ccf915b364770@mail.gmail.com>
References: <68c491a60807070256m23ba8f56l9b9ccf915b364770@mail.gmail.com>
Message-ID: <20080707163517.3654.qmail@cdy.org>

On Mon, Jul 07, 2008 at 11:56:07AM +0200, Martin Schr?der wrote:
> On Linux:
> sudo ssh -v -f -w 0:1 $OPENBSD true
> sudo /sbin/ifconfig tun0 10.1.1.1 10.1.1.2
> sudo /sbin/route add -net 192.168.17.0 netmask 255.255.255.0 dev tun0

ifconfig and route are out of style. :)

Try this instead:

ip a a 10.1.1.1 peer 10.1.1.2 dev tun0
ip r a 192.168.17.0/24 via 10.1.1.2


> On OBSD:
> sudo ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.0
> sudo /sbin/route add 10.0.3.0/24 10.1.1.1
> And add a "pass quick on tun1" to /etc/pf.conf
> 
> Then I have:
> - Linux:
> tun0      Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>          inet addr:10.1.1.2  P-t-P:10.1.1.2  Mask:255.255.255.255
                            ^
That's not right, that should be a 1 right there.


//Peter

From vinschen at redhat.com  Tue Jul  8 03:20:49 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 7 Jul 2008 19:20:49 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <20080707172049.GA24644@calimero.vinschen.de>

On Jul  7 09:30, Damien Miller wrote:
> Hi,
> 
> OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release is one of

Runs basically fine on Cygwin 1.5.25.  I have a bit of trouble under
Cygwin 1.7.0 related to IPv6 (which is new in 1.7.0) which requires some
debugging.  I can't connect to the 5.1 sshd using IPv6. With full
debugging on, the connection stops at

  debug1: Server will not fork when running in debugging mode.

on the server side and

  debug1: identity file /home/corinna/.ssh/id_rsa type 1

on the client side.  IPv6 connections works fine with ssh and sshd from
5.0p1.  Does anybody have an idea what could have changed so that the
identification string exchange just hangs with v6?  I'm not quite sure
yet how to debug this...

Other than that:

- session.c, line 427:

    #define USE_PIPES

  Is that planned or just left over fomr some test?

- The following testcases fail on Cygwin 1.5.25:

  - addrmatch.sh  tries to run IPv6 tests even though IPv6 is not
                  available.

  - sftp-glob.sh  tries to match filenames with characters not
                  allowed in filenames on Windows filesystems ("*", "\\").


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From djm at mindrot.org  Tue Jul  8 08:37:55 2008
From: djm at mindrot.org (Damien Miller)
Date: Tue, 8 Jul 2008 08:37:55 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080707152728.GE1231@greenie.muc.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707152728.GE1231@greenie.muc.de>
Message-ID: <alpine.BSO.1.10.0807080833170.7583@fuyu.mindrot.org>

On Mon, 7 Jul 2008, Gert Doering wrote:

> Hi,
> 
> On Mon, Jul 07, 2008 at 09:30:55AM +1000, Damien Miller wrote:
> > OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release is one of
> > the biggest in recent years, with two hackathons' worth of improvements
> > and fixes for some of our most recalcitrant bugs.
> 
> NetBSD 3.1 on Sparc64, CVS snapshot from "earlier today", has some 
> funnies in the test suite. 
> 
> This test was run as non-root, but root makes no difference, the errors
> are the same.
> 
> Here's the output of "make test" from the point where the errors start:
> 
> (cd openbsd-compat && make)
> ...
> run test forwarding.sh ...
> ok local and remote forwarding
> run test multiplex.sh ...
> test connection multiplexing: envpass
> mm_send_fd: sendmsg(0): Invalid argument
> muxclient: send fds failed
> Falling back to non-multiplexed connection
> mm_receive_fd: recvmsg: expected received 1 got 0
> muxserver_accept_control: failed to receive fd 0 from slave

OpenBSD suffered from a similar problem a while back, it turned out to be
a kernel bug related to CMSG alignment:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c.diff?r1=1.37&r2=1.38
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c.diff?r1=1.40&r2=1.41

Short story: OpenSSH's use of the CMSG_* macros used to incorrect, but
fixing it uncovered this kernel bug.

-d

From andyb1 at andy-t.org  Tue Jul  8 11:22:17 2008
From: andyb1 at andy-t.org (Andy Tsouladze)
Date: Mon, 7 Jul 2008 20:22:17 -0500 (CDT)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <alpine.LNX.1.10.0807072020260.20861@king.andy-t.org>

Compiled and tested successfully on
Slackware-12.0, GCC-4.1.2

Regards,

Andy

On Mon, 7 Jul 2008, Damien Miller wrote:

> Hi,
>
> OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release is one of
> the biggest in recent years, with two hackathons' worth of improvements
> and fixes for some of our most recalcitrant bugs.
>
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
>
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
>
> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs
>
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
>
> $ ./configure && make tests
>
> Live testing on suitable non-production systems is also appreciated.
> Please send reports of success or failure to
> openssh-unix-dev at mindrot.org.
>
> Below is a summary of changes. More detail may be found in the
> ChangeLog in the portable OpenSSH tarballs.
>
> Thanks to the many people who contributed to this release.
>
>
> New features:
>
> * Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1)
>   and ssh-keygen(1). Visual fingerprinnt display is controlled by a new
>   ssh_config(5) option "VisualHostKey". The intent is to render
>   SSH host keys in a visual form that is amenable to easy recall and
>   rejection of changed host keys. This technique inspired by the
>   graphical hash visualisation schemes known as "random art[*]", and
>   by Dan Kaminsky's musings at 23C3 in Berlin.
>   Fingerprint visualisation in is currently disabled by default, as the
>   algorithm used to generate the random art is still subject to change.
>   [*] "Hash Visualization: a New Technique to improve Real-World
>       Security", Perrig A. and Song D., 1999, International Workshop on
>       Cryptographic Techniques and E-Commerce (CrypTEC '99)
>   http://sparrow.ece.cmu.edu/~adrian/projects/validation/validation.pdf
>
> * sshd_config(5) now supports CIDR address/masklen matching in "Match
>   address" blocks, with a fallback to classic wildcard matching. For
>   example:
>     Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*
>         PasswordAuthentication yes
>
> * sshd(8) now supports CIDR matching in ~/.ssh/authorized_keys
>   from="..." restrictions, also with a fallback to classic wildcard
>   matching.
>
> * Added an extended test mode (-T) to sshd(8) to request that it write
>   its effective configuration to stdout and exit. Extended test mode
>   also supports the specification of connection parameters (username,
>   source address and hostname) to test the application of
>   sshd_config(5) Match rules.
>
> * sftp-server(8) now supports extension methods statvfs at openssh.com and
>   fstatvfs at openssh.com that implement statvfs(2)-like operations.
>
> * sftp(1) now has a "df" command to the sftp client that uses the
>   statvfs at openssh.com to produce a df(1)-like display of filesystem
>   space and inode utilisation (requires statvfs at openssh.com support on
>   the server)
>
> * Added a MaxSessions option to sshd_config(5) to allow control of the
>   number of multiplexed sessions supported over a single TCP connection.
>   This allows increasing the number of allowed sessions above the
>   previous default of 10, disabling connection multiplexing
>   (MaxSessions=1) or disallowing login/shell/subsystem sessions
>   entirely (MaxSessions=0).
>
> * Added a no-more-sessions at openssh.com global request extension that is
>   sent from ssh(1) to sshd(8) when the client knows that it will never
>   request another session (i.e. when session multiplexing is disabled).
>   This allows a server to disallow further session requests and
>   terminate the session in cases where the client has been hijacked.
>
> * ssh-keygen(1) now supports the use of the -l option in combination
>   with -F to search for a host in ~/.ssh/known_hosts and display its
>   fingerprint.
>
> * ssh-keyscan(1) now defaults to "rsa" (protocol 2) keys, instead of
>   "rsa1".
>
> * Added an AllowAgentForwarding option to sshd_config(8) to control
>   whether authentication agent forwarding is permitted. Note that this
>   is a loose control, as a client may install their own unofficial
>   forwarder.
>
> * Avoid unnecessary malloc/copy/free when receiving network data,
>   resulting in a ~10% speedup
>
> * ssh(1) and sshd(8) will now try additional addresses when connecting
>   to a port forward destination whose DNS name resolves to more than
>   one address. The previous behaviour was to try the only first address
>   and give up if that failed.
>
> * ssh(1) and sshd(8) now support signalling that channels are
>   half-closed for writing, through a channel protocol extension
>   notification "eow at openssh.com". This allows propagation of closed
>   file descriptors, so that commands such as:
>       "ssh -2 localhost od /bin/ls | true"
>   do not send unnecessary data over the wire. (bz#85)
>
> * sshd(8): increased the default size of ssh protocol 1 ephemeral keys
>   from 768 to 1024 bits.
>
> * When ssh(1) has been requested to fork after authentication
>   ("ssh -f") with ExitOnForwardFailure enabled, delay the fork until
>   after replies for any -R forwards have been seen. Allows for robust
>   detection of -R forward failure when using -f.
>
> * "Match group" blocks in sshd_config(5) now support negation of
>   groups. E.g. "Match group staff,!guests"
>
> * sftp(1) and sftp-server(8) now allow chmod-like operations to set
>   set[ug]id/sticky bits.
>
> * The MaxAuthTries option is now permitted in sshd_config(5) match
>   blocks.
>
> * Multiplexed ssh(1) sessions now support a subset of the ~ escapes
>   that are available to a primary connection.
>
> * ssh(1) connection multiplexing will now fall back to creating a new
>   connection in most error cases.
>
> * Added some basic interoperability tests against Twisted Conch.
>
> * Documented OpenSSH's extensions to and deviations from the published
>   SSH protocols (the PROTOCOL file in the distribution)
>
> * Documented OpenSSH's ssh-agent protocol (PROTOCOL.agent).
>
> Bugfixes
>
> * Make ssh(1) deal more gracefully with channel requests that fail.
>   Previously it would optimistically assume that requests would always
>   succeed, which could cause hangs if they did not (e.g. when the
>   server runs out of file descriptors).
>
> * ssh(1) now reports multiplexing errors via the multiplex slave's
>   stderr where possible (subject to LogLevel in the mux master).
>
> * ssh(1) and sshd(8) now send terminate protocol banners with CR+LF for
>   protocol 2 to comply with RFC 4253. Previously they were terminated
>   with CR alone. Protocol 1 banners remain CR terminated.
>
> * Merged duplicate authentication file checks in sshd(8) and refuse to
>   read authorised_keys and .shosts from non-regular files.
>
> * Ensure that sshd(8)'s umask disallows at least group and world write,
>   even if a more permissive one has been inherited.
>
> * Suppress the warning message from sshd(8) when changing to a
>   non-existent user home directory after chrooting.
>
> * Mention that scp(1) follows symlinks when performing recursive
>   copies.
>
> * Prevent sshd(8) from erroneously applying public key restrictions
>   leaned from ~/.ssh/authorized_keys to other authentication methods
>   when public key authentication subsequently fails.
>
> * Fix protocol keepalive timeouts - in some cases, keepalive packets
>   were being sent, but the connection was not being closed when the
>   limit for missing replies was exceeded.
>
> * Fix ssh(1) sending invalid TTY modes when a TTY was forced (ssh -tt)
>   but stdin was not a TTY.
>
> * ssh(1) will now exit with a non-zero exit status if
>   ExitOnForwardFailure was set and forwardings were disabled due to a
>   failed host key check.
>
> * Fix MaxAuthTries tests to disallow a free authentication try to
>   clients that skipped the protocol 2 "none" authentication method.
>
> * bz#1363: Make keepalive timeouts apply while synchronously waiting
>   for a packet, particularly during key renegotiation.
>
> * sshd(8) has been audited to eliminate fd leaks and calls to fatal()
>   in conditions of file descriptor exhaustion.
>
> Portable OpenSSH-specific bugfixes
>
> * Avoid a sshd(8) hang-on-exit on Solaris caused by depending on the
>   success of isatty() on a PTY master (undefined behaviour). Probably
>   affected other platforms too.
>
> * bz#1083: Fixed test for locked accounts on HP/UX with shadowed
>   passwords disabled.
>
> * bz#1386: Disable poll() fallback in atomiciov for Tru64. readv
>   doesn't seem to be a comparable object there, which lead to
>   compilation errors.
>
> * bz#1447: Fall back to racy rename if link returns EXDEV.
>
> * bz#1467: Explicitly handle EWOULDBLOCK wherever we handle EAGAIN, on
>   some platforms (HP nonstop) it is a distinct errno.
>
> * bz#1240: Avoid NULL dereferences in ancient sigaction replacement
>   code.
>
> * bz#1276: Avoid linking against libgssapi, which despite its name
>   doesn't seem to implement all of GSSAPI.
>
> * bz#1112: Use explicit noreturn attribute instead of __dead, fixing
>   compilation problems on Interix.
>
> * bz#1241: Support password expiry on Tru64 SIA systems.
>
> * bz#1462: Fix an UMAC alignment problem that manifested on Itanium
>   platforms.
>
>
> Damien Miller
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Dr Andy Tsouladze
Sr Unix SysAdmin/System Architect

From gert at greenie.muc.de  Tue Jul  8 19:30:43 2008
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 8 Jul 2008 11:30:43 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807080833170.7583@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707152728.GE1231@greenie.muc.de>
	<alpine.BSO.1.10.0807080833170.7583@fuyu.mindrot.org>
Message-ID: <20080708093042.GL1231@greenie.muc.de>

Hi,

On Tue, Jul 08, 2008 at 08:37:55AM +1000, Damien Miller wrote:
> > NetBSD 3.1 on Sparc64, CVS snapshot from "earlier today", has some 
> > funnies in the test suite. 
[..]
> 
> OpenBSD suffered from a similar problem a while back, it turned out to be
> a kernel bug related to CMSG alignment:
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c.diff?r1=1.37&r2=1.38
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c.diff?r1=1.40&r2=1.41
> 
> Short story: OpenSSH's use of the CMSG_* macros used to incorrect, but
> fixing it uncovered this kernel bug.

Hmmm.  OpenBSD's change log also mentions Sparc64 - this seems to be a
good platform for uncovering bugs...

Is the discussion preceding this OpenBSD kernel change online somewhere?  I'd
like to forward this to the NetBSD kernel list, but without a bit more
background, I can't really explain what's wrong.

gert

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

From nsheridan at google.com  Tue Jul  8 20:10:09 2008
From: nsheridan at google.com (Niall Sheridan)
Date: Tue, 8 Jul 2008 11:10:09 +0100
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <ad87d7d40807070249l5e4b3c75rd88ec1ec01f7503b@mail.gmail.com>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<ad87d7d40807070249l5e4b3c75rd88ec1ec01f7503b@mail.gmail.com>
Message-ID: <ad87d7d40807080310n535b0991sa4fcd03e0d13a5b9@mail.gmail.com>

On Mon, Jul 7, 2008 at 10:49, Niall Sheridan <nsheridan at google.com> wrote:
> On Ubuntu 6.06 (i386, 2.6.16-xen, gcc 4.0.3) I get 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
> make[1]: Leaving directory `/tmp/openssh/regress'
> make: *** [tests] Error 2

Tried on two different 6.06 machines - one xen, one real. On the real
machine, all tests passed. On the xen machine, the tests failed with
the above error.

 - Niall

From flavien-ssh at lebarbe.net  Tue Jul  8 22:18:04 2008
From: flavien-ssh at lebarbe.net (Flavien Lebarbe)
Date: Tue, 8 Jul 2008 14:18:04 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <ad87d7d40807080310n535b0991sa4fcd03e0d13a5b9@mail.gmail.com>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<ad87d7d40807070249l5e4b3c75rd88ec1ec01f7503b@mail.gmail.com>
	<ad87d7d40807080310n535b0991sa4fcd03e0d13a5b9@mail.gmail.com>
Message-ID: <20080708121804.GE6132@flavien.org>

Hi,


> Tried on two different 6.06 machines - one xen, one real. On the real
> machine, all tests passed. On the xen machine, the tests failed with
> the above error.

Assuming it's not a problem related to your networking setup inside
your virtual machine, and that you have the same packages installed
on the 2 systems, I guess you should report it to xen.

It could be a bug in the emulation. openssh-portable only tries to
make it possible to run openssh on as many systems as possible,
accomodating many different libraries/APIs. As opposed to getting
around bugs in emulation/virtualization software.

If the two systems are the same, you could compare the binaries, run
them on one another. Don't forget to also check openssl.


Flavien.

From vinschen at redhat.com  Tue Jul  8 22:41:39 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 8 Jul 2008 14:41:39 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080707172049.GA24644@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
Message-ID: <20080708124139.GD24644@calimero.vinschen.de>

On Jul  7 19:20, Corinna Vinschen wrote:
> On Jul  7 09:30, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release is one of
> 
> Runs basically fine on Cygwin 1.5.25.  I have a bit of trouble under
> Cygwin 1.7.0 related to IPv6 (which is new in 1.7.0) which requires some
> debugging.  I can't connect to the 5.1 sshd using IPv6. With full
> debugging on, the connection stops at
> 
>   debug1: Server will not fork when running in debugging mode.
> 
> on the server side and
> 
>   debug1: identity file /home/corinna/.ssh/id_rsa type 1
> 
> on the client side.  IPv6 connections works fine with ssh and sshd from
> 5.0p1.  Does anybody have an idea what could have changed so that the

Nothing to worry about.  As it turned out I used a not IPv6-enabled
version of tcp_wrappers.  Updating to the latest IPv6-enabled
tcp_wrappers fixed this issue.

Important side-effect:  This new OpenSSH release also uncovered two bugs
in my IPv6 implementation in Cygwin 1.7.  I'm about to fix them.

> Other than that:
> 
> - session.c, line 427:
> 
>     #define USE_PIPES
> 
>   Is that planned or just left over fomr some test?

s/fomr/from/

> - The following testcases fail on Cygwin 1.5.25:
> 
>   - addrmatch.sh  tries to run IPv6 tests even though IPv6 is not
>                   available.
> 
>   - sftp-glob.sh  tries to match filenames with characters not
>                   allowed in filenames on Windows filesystems ("*", "\\").


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From djm at mindrot.org  Wed Jul  9 00:18:18 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 00:18:18 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080707172049.GA24644@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
Message-ID: <alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>

On Mon, 7 Jul 2008, Corinna Vinschen wrote:

> Other than that:
> 
> - session.c, line 427:
> 
>     #define USE_PIPES
> 
>   Is that planned or just left over fomr some test?

No, that is planned. We now unconditionally use pipes for communicating
with the session subprocesses because they seem to give better semantics
for half-closed channels (cf. https://bugzilla.mindrot.org/b/85).

> - The following testcases fail on Cygwin 1.5.25:
> 
>   - addrmatch.sh  tries to run IPv6 tests even though IPv6 is not
>                   available.

I'm not sure of a good way to determine at runtime whether IPv6 is
available on a platform. Perhaps these tests should be disabled in
portable or made non-fatal.

>   - sftp-glob.sh  tries to match filenames with characters not
>                   allowed in filenames on Windows filesystems ("*", "\\").

These should be special-cased for Windows.

-d

From djm at mindrot.org  Wed Jul  9 00:21:45 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 00:21:45 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <Pine.LNX.4.64.0807070937220.30756@top.qwarx.com>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<Pine.LNX.4.64.0807070937220.30756@top.qwarx.com>
Message-ID: <alpine.BSO.1.10.0807090021140.22609@fuyu.mindrot.org>

On Mon, 7 Jul 2008, Chris Wilson wrote:

> On Mon, 7 Jul 2008, Damien Miller wrote:
> 
> > Portable OpenSSH is also available via anonymous CVS using the
> > instructions at http://www.openssh.com/portable.html#cvs
> > 
> > Running the regression tests supplied with Portable OpenSSH does not
> > require installation and is a simply:
> > 
> > $ ./configure && make tests
> 
> Run on FC6 i386, I think it worked, the output is:
> 
> ok localcommand
> run test forcecommand.sh ...
> ok forced command
> make[1]: Leaving directory `/tmp/openssh/regress'
> 
> Perhaps it would help if the test ended with a single line that said PASS 
> or FAIL?

Fair point, it now says "all tests passed" on success. On failure, you
should see something more obvious and verbose.

-d

From djm at mindrot.org  Wed Jul  9 00:26:21 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 00:26:21 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080708093042.GL1231@greenie.muc.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707152728.GE1231@greenie.muc.de>
	<alpine.BSO.1.10.0807080833170.7583@fuyu.mindrot.org>
	<20080708093042.GL1231@greenie.muc.de>
Message-ID: <alpine.BSO.1.10.0807090021490.22609@fuyu.mindrot.org>

On Tue, 8 Jul 2008, Gert Doering wrote:

> Hi,
> 
> On Tue, Jul 08, 2008 at 08:37:55AM +1000, Damien Miller wrote:
> > > NetBSD 3.1 on Sparc64, CVS snapshot from "earlier today", has some 
> > > funnies in the test suite. 
> [..]
> > 
> > OpenBSD suffered from a similar problem a while back, it turned out to be
> > a kernel bug related to CMSG alignment:
> > 
> > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c.diff?r1=1.37&r2=1.38
> > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c.diff?r1=1.40&r2=1.41
> > 
> > Short story: OpenSSH's use of the CMSG_* macros used to incorrect, but
> > fixing it uncovered this kernel bug.
> 
> Hmmm. OpenBSD's change log also mentions Sparc64 - this seems to be a
> good platform for uncovering bugs...

Big endian and strict alignment :)

> Is the discussion preceding this OpenBSD kernel change online
> somewhere? I'd like to forward this to the NetBSD kernel list, but
> without a bit more background, I can't really explain what's wrong.

I think most of the discussion happened in person, or at least not by
email. The comments added in the first diff explain it a bit, but I
think the bulk of the problems occur when using the CMSG macros to pack
multiple messages under one msghdr - our previous use was causing the
alignment to be slightly wrong which made robust recovery of subsequent
messages impossible.

-d

From djm at mindrot.org  Wed Jul  9 00:29:55 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 00:29:55 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <ad87d7d40807080310n535b0991sa4fcd03e0d13a5b9@mail.gmail.com>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<ad87d7d40807070249l5e4b3c75rd88ec1ec01f7503b@mail.gmail.com>
	<ad87d7d40807080310n535b0991sa4fcd03e0d13a5b9@mail.gmail.com>
Message-ID: <alpine.BSO.1.10.0807090027100.22609@fuyu.mindrot.org>

On Tue, 8 Jul 2008, Niall Sheridan wrote:

> On Mon, Jul 7, 2008 at 10:49, Niall Sheridan <nsheridan at google.com> wrote:
> > On Ubuntu 6.06 (i386, 2.6.16-xen, gcc 4.0.3) I get 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
> > make[1]: Leaving directory `/tmp/openssh/regress'
> > make: *** [tests] Error 2
> 
> Tried on two different 6.06 machines - one xen, one real. On the real
> machine, all tests passed. On the xen machine, the tests failed with
> the above error.

I really should write up a "debugging failing regress test" doc, because
somehow I manage to forget how to extract proper debugging immediately
after each time I do it. I think you do something like:

env TEST_SSH_LOGFILE=/path/to/log \
    TEST_SSH_SSHD_CONFOPTS=LogLevel=debug3 \
    TEST_SSH_SSH_CONFOPTS=LogLevel=debug3 make tests

Hopefully that will give some details on what broke.

-d

From vinschen at redhat.com  Wed Jul  9 00:41:05 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 8 Jul 2008 16:41:05 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
Message-ID: <20080708144105.GA6726@calimero.vinschen.de>

On Jul  9 00:18, Damien Miller wrote:
> On Mon, 7 Jul 2008, Corinna Vinschen wrote:
> 
> > Other than that:
> > 
> > - session.c, line 427:
> > 
> >     #define USE_PIPES
> > 
> >   Is that planned or just left over fomr some test?
> 
> No, that is planned. We now unconditionally use pipes for communicating
> with the session subprocesses because they seem to give better semantics
> for half-closed channels (cf. https://bugzilla.mindrot.org/b/85).

Ok.  Given that USE_PIPES is now only used in sftp.c, wouldn't it 
be easier now to always use pipes, even in sftp.c?  That would drop
the whole test and a bunch of conditional code.

> > - The following testcases fail on Cygwin 1.5.25:
> > 
> >   - addrmatch.sh  tries to run IPv6 tests even though IPv6 is not
> >                   available.
> 
> I'm not sure of a good way to determine at runtime whether IPv6 is
> available on a platform. Perhaps these tests should be disabled in
> portable or made non-fatal.

Ack.  Unfortunately `ssh -6' falls silently back to IPv4 instead of
complaining on platforms not supporting IPv6.  Complaining would allow
to use this as a test.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From vinschen at redhat.com  Wed Jul  9 01:44:21 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 8 Jul 2008 17:44:21 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080708144105.GA6726@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
Message-ID: <20080708154421.GF24644@calimero.vinschen.de>

On Jul  8 16:41, Corinna Vinschen wrote:
> On Jul  9 00:18, Damien Miller wrote:
> > On Mon, 7 Jul 2008, Corinna Vinschen wrote:
> > 
> > > Other than that:
> > > 
> > > - session.c, line 427:
> > > 
> > >     #define USE_PIPES
> > > 
> > >   Is that planned or just left over fomr some test?
> > 
> > No, that is planned. We now unconditionally use pipes for communicating
> > with the session subprocesses because they seem to give better semantics
> > for half-closed channels (cf. https://bugzilla.mindrot.org/b/85).
> 
> Ok.  Given that USE_PIPES is now only used in sftp.c, wouldn't it 
> be easier now to always use pipes, even in sftp.c?  That would drop
> the whole test and a bunch of conditional code.
> 
> > > - The following testcases fail on Cygwin 1.5.25:
> > > 
> > >   - addrmatch.sh  tries to run IPv6 tests even though IPv6 is not
> > >                   available.
> > 
> > I'm not sure of a good way to determine at runtime whether IPv6 is
> > available on a platform. Perhaps these tests should be disabled in
> > portable or made non-fatal.
> 
> Ack.  Unfortunately `ssh -6' falls silently back to IPv4 instead of
> complaining on platforms not supporting IPv6.  Complaining would allow
> to use this as a test.

Oh, btw.  Here's another testsuite problem.  Even after I fixed the IPv6
problems in Cygwin I mentioned in the other mail, there's nothing I can
do against this error on Windows up to and including Windows Server 2003:

forwarding.sh:

  exit on -L forward failure, proto 1
  connection not termintated, but should (0)
  [...]
  exit on -L forward failure, proto 2
  connection not termintated, but should (0)

This problem can only be fixed for Windows Vista and Server 2008.  The
underlying problem is a bug in SO_REUSEADDR handling in WinSock.
Usually it should be impossible to reuse a complete duplicate of a local
TCP address (same IP, same port), even if SO_REUSEADDR has been set.
That's unfortunately possible in WinSock and, instead of fixing this
bug, has been defined as "that's how it works here", despite a lot of
other changes in this area over the time.

I have a workaround for IPv4 for a while now, but working around this
for IPv6 requires the existance of a function which is only available
since Windows Vista/2008.  No chance on earlier Windows versions.

I don't know if that fact should really be taken into account in the
testsuite, but I thought I should mention it for the records.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From cristian.ionescu-idbohrn at axis.com  Wed Jul  9 00:53:33 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Tue, 8 Jul 2008 16:53:33 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <0807081546470.18603@somehost>

On Mon, 7 Jul 2008, Damien Miller wrote:
>
> Please send reports of success or failure to
> openssh-unix-dev at mindrot.org.

Cross-builds for cris arch.  Quickly tested sftp-server; successfuly.

OpenSSH has been configured with the following options:
                     User binaries: /usr/bin
                   System binaries: /usr/sbin
               Configuration files: /etc/ssh
                   Askpass program: /usr/libexec/ssh-askpass
                      Manual pages: .../target/cris-axis-linux-gnuuclibc/usr/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin
                    Manpage format: doc
                       PAM support: no
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: no
                 Smartcard support: no
                     S/KEY support: no
              TCP Wrappers support: no
              MD5 password support: yes
                   libedit support: no
  Solaris process contract support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: cris-axis-linux-gnuuclibc
          Compiler: gcc_cris -mlinux -mno-mul-bug-workaround
-muclibc=.../target/cris-axis-linux-gnuuclibc
    Compiler flags: -Wall -Wshadow -O2 -g  -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -fno-builtin-memset -std=gnu99
Preprocessor flags: -I.../target/cris-axis-linux-gnuuclibc/lib
      Linker flags: -L.../target/cris-axis-linux-gnuuclibc/lib
         Libraries: -lcrypto -lutil -lz  -lcrypt -lresolv -lresolv

Warnings:

xmalloc.h:26: warning: `__nonnull__' attribute directive ignored

bindresvport.c: In function `bindresvport_sa':
bindresvport.c:57: warning: declaration of `sin' shadows a global declaration
<built-in>:0: warning: shadowed declaration is here

rresvport.c: In function `rresvport_af':
rresvport.c:92: warning: implicit declaration of function `close'

umac.c:187: warning: declaration of `buffer_ptr' shadows a global declaration
buffer.h:31: warning: shadowed declaration is here

auth.c: In function `auth_openkeyfile':
auth.c:489: warning: implicit declaration of function `close'

I also get this warning from the linker:

/usr/local/cris/r64/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/../../../../cris-axis-linux-gnu/bin/ld: warning: type and size of dynamic symbol `AES_encrypt' are not defined

which goes away if I build with:

  CFLAGS += -DUSE_BUILTIN_RIJNDAEL


-- 
Cristian

From archer at eskimo.com  Wed Jul  9 01:53:23 2008
From: archer at eskimo.com (Curt, WE7U)
Date: Tue, 8 Jul 2008 08:53:23 -0700 (PDT)
Subject: Clear-Text Patch?  was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>

On Mon, 7 Jul 2008, Damien Miller wrote:

> OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release is one of
> the biggest in recent years, with two hackathons' worth of improvements
> and fixes for some of our most recalcitrant bugs.

Does this version have the clear-text-after-authentication patch in
it?  The amateur radio people still need this tweak in order to use
OpenSSH over ham radio data links.  The FCC does not allow
encryption of data on our frequencies, but does allow encryption for
authentication purposes.

We don't much care if it requires some new oddball command line
options, as long as it's supported in the base OpenSSH code and
generally compiled in.  We'd like it to eventually be available on
most Linux distributions ready-to-go for us.  In other words,
compiling in the patch from the HPN mods is beyond a lot of hams.

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

From jdvf at optonline.net  Wed Jul  9 07:46:41 2008
From: jdvf at optonline.net (John Devitofranceschi)
Date: Tue, 08 Jul 2008 17:46:41 -0400
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <9CEACBB1-0A7D-449F-940A-3B493AFDBE51@optonline.net>


All tests okay on Leopard 10.5.4

$ uname -a
Darwin syd.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9  
19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386

$ cc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

$ ./ssh -V
OpenSSH_5.0p1-snap20080709, OpenSSL 0.9.7l 28 Sep 2006


On Jul 6, 2008, at 7:30 PM, Damien Miller wrote:

> Hi,
>
> OpenSSH 5.1 is almost ready for release, so we would appreciate  
> testing
> on as many platforms and systems as possible. This release is one of
> the biggest in recent years, with two hackathons' worth of  
> improvements
> and fixes for some of our most recalcitrant bugs.
>
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
>
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
>
> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs
>
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
>
> $ ./configure && make tests
>
> Live testing on suitable non-production systems is also appreciated.
> Please send reports of success or failure to
> openssh-unix-dev at mindrot.org.
>
> Below is a summary of changes. More detail may be found in the
> ChangeLog in the portable OpenSSH tarballs.
>
> Thanks to the many people who contributed to this release.
>
>
> New features:
>
> * Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1)
>   and ssh-keygen(1). Visual fingerprinnt display is controlled by a  
> new
>   ssh_config(5) option "VisualHostKey". The intent is to render
>   SSH host keys in a visual form that is amenable to easy recall and
>   rejection of changed host keys. This technique inspired by the
>   graphical hash visualisation schemes known as "random art[*]", and
>   by Dan Kaminsky's musings at 23C3 in Berlin.
>   Fingerprint visualisation in is currently disabled by default, as  
> the
>   algorithm used to generate the random art is still subject to  
> change.
>   [*] "Hash Visualization: a New Technique to improve Real-World
>       Security", Perrig A. and Song D., 1999, International Workshop  
> on
>       Cryptographic Techniques and E-Commerce (CrypTEC '99)
>   http://sparrow.ece.cmu.edu/~adrian/projects/validation/ 
> validation.pdf
>
> * sshd_config(5) now supports CIDR address/masklen matching in "Match
>   address" blocks, with a fallback to classic wildcard matching. For
>   example:
>     Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*
>         PasswordAuthentication yes
>
> * sshd(8) now supports CIDR matching in ~/.ssh/authorized_keys
>   from="..." restrictions, also with a fallback to classic wildcard
>   matching.
>
> * Added an extended test mode (-T) to sshd(8) to request that it write
>   its effective configuration to stdout and exit. Extended test mode
>   also supports the specification of connection parameters (username,
>   source address and hostname) to test the application of
>   sshd_config(5) Match rules.
>
> * sftp-server(8) now supports extension methods statvfs at openssh.com  
> and
>   fstatvfs at openssh.com that implement statvfs(2)-like operations.
>
> * sftp(1) now has a "df" command to the sftp client that uses the
>   statvfs at openssh.com to produce a df(1)-like display of filesystem
>   space and inode utilisation (requires statvfs at openssh.com support on
>   the server)
>
> * Added a MaxSessions option to sshd_config(5) to allow control of the
>   number of multiplexed sessions supported over a single TCP  
> connection.
>   This allows increasing the number of allowed sessions above the
>   previous default of 10, disabling connection multiplexing
>   (MaxSessions=1) or disallowing login/shell/subsystem sessions
>   entirely (MaxSessions=0).
>
> * Added a no-more-sessions at openssh.com global request extension that  
> is
>   sent from ssh(1) to sshd(8) when the client knows that it will never
>   request another session (i.e. when session multiplexing is  
> disabled).
>   This allows a server to disallow further session requests and
>   terminate the session in cases where the client has been hijacked.
>
> * ssh-keygen(1) now supports the use of the -l option in combination
>   with -F to search for a host in ~/.ssh/known_hosts and display its
>   fingerprint.
>
> * ssh-keyscan(1) now defaults to "rsa" (protocol 2) keys, instead of
>   "rsa1".
>
> * Added an AllowAgentForwarding option to sshd_config(8) to control
>   whether authentication agent forwarding is permitted. Note that this
>   is a loose control, as a client may install their own unofficial
>   forwarder.
>
> * Avoid unnecessary malloc/copy/free when receiving network data,
>   resulting in a ~10% speedup
>
> * ssh(1) and sshd(8) will now try additional addresses when connecting
>   to a port forward destination whose DNS name resolves to more than
>   one address. The previous behaviour was to try the only first  
> address
>   and give up if that failed.
>
> * ssh(1) and sshd(8) now support signalling that channels are
>   half-closed for writing, through a channel protocol extension
>   notification "eow at openssh.com". This allows propagation of closed
>   file descriptors, so that commands such as:
>       "ssh -2 localhost od /bin/ls | true"
>   do not send unnecessary data over the wire. (bz#85)
>
> * sshd(8): increased the default size of ssh protocol 1 ephemeral keys
>   from 768 to 1024 bits.
>
> * When ssh(1) has been requested to fork after authentication
>   ("ssh -f") with ExitOnForwardFailure enabled, delay the fork until
>   after replies for any -R forwards have been seen. Allows for robust
>   detection of -R forward failure when using -f.
>
> * "Match group" blocks in sshd_config(5) now support negation of
>   groups. E.g. "Match group staff,!guests"
>
> * sftp(1) and sftp-server(8) now allow chmod-like operations to set
>   set[ug]id/sticky bits.
>
> * The MaxAuthTries option is now permitted in sshd_config(5) match
>   blocks.
>
> * Multiplexed ssh(1) sessions now support a subset of the ~ escapes
>   that are available to a primary connection.
>
> * ssh(1) connection multiplexing will now fall back to creating a new
>   connection in most error cases.
>
> * Added some basic interoperability tests against Twisted Conch.
>
> * Documented OpenSSH's extensions to and deviations from the published
>   SSH protocols (the PROTOCOL file in the distribution)
>
> * Documented OpenSSH's ssh-agent protocol (PROTOCOL.agent).
>
> Bugfixes
>
> * Make ssh(1) deal more gracefully with channel requests that fail.
>   Previously it would optimistically assume that requests would always
>   succeed, which could cause hangs if they did not (e.g. when the
>   server runs out of file descriptors).
>
> * ssh(1) now reports multiplexing errors via the multiplex slave's
>   stderr where possible (subject to LogLevel in the mux master).
>
> * ssh(1) and sshd(8) now send terminate protocol banners with CR+LF  
> for
>   protocol 2 to comply with RFC 4253. Previously they were terminated
>   with CR alone. Protocol 1 banners remain CR terminated.
>
> * Merged duplicate authentication file checks in sshd(8) and refuse to
>   read authorised_keys and .shosts from non-regular files.
>
> * Ensure that sshd(8)'s umask disallows at least group and world  
> write,
>   even if a more permissive one has been inherited.
>
> * Suppress the warning message from sshd(8) when changing to a
>   non-existent user home directory after chrooting.
>
> * Mention that scp(1) follows symlinks when performing recursive
>   copies.
>
> * Prevent sshd(8) from erroneously applying public key restrictions
>   leaned from ~/.ssh/authorized_keys to other authentication methods
>   when public key authentication subsequently fails.
>
> * Fix protocol keepalive timeouts - in some cases, keepalive packets
>   were being sent, but the connection was not being closed when the
>   limit for missing replies was exceeded.
>
> * Fix ssh(1) sending invalid TTY modes when a TTY was forced (ssh -tt)
>   but stdin was not a TTY.
>
> * ssh(1) will now exit with a non-zero exit status if
>   ExitOnForwardFailure was set and forwardings were disabled due to a
>   failed host key check.
>
> * Fix MaxAuthTries tests to disallow a free authentication try to
>   clients that skipped the protocol 2 "none" authentication method.
>
> * bz#1363: Make keepalive timeouts apply while synchronously waiting
>   for a packet, particularly during key renegotiation.
>
> * sshd(8) has been audited to eliminate fd leaks and calls to fatal()
>   in conditions of file descriptor exhaustion.
>
> Portable OpenSSH-specific bugfixes
>
> * Avoid a sshd(8) hang-on-exit on Solaris caused by depending on the
>   success of isatty() on a PTY master (undefined behaviour). Probably
>   affected other platforms too.
>
> * bz#1083: Fixed test for locked accounts on HP/UX with shadowed
>   passwords disabled.
>
> * bz#1386: Disable poll() fallback in atomiciov for Tru64. readv
>   doesn't seem to be a comparable object there, which lead to
>   compilation errors.
>
> * bz#1447: Fall back to racy rename if link returns EXDEV.
>
> * bz#1467: Explicitly handle EWOULDBLOCK wherever we handle EAGAIN, on
>   some platforms (HP nonstop) it is a distinct errno.
>
> * bz#1240: Avoid NULL dereferences in ancient sigaction replacement
>   code.
>
> * bz#1276: Avoid linking against libgssapi, which despite its name
>   doesn't seem to implement all of GSSAPI.
>
> * bz#1112: Use explicit noreturn attribute instead of __dead, fixing
>   compilation problems on Interix.
>
> * bz#1241: Support password expiry on Tru64 SIA systems.
>
> * bz#1462: Fix an UMAC alignment problem that manifested on Itanium
>   platforms.
>
>
> Damien Miller
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

From djm at mindrot.org  Wed Jul  9 10:54:39 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 10:54:39 +1000 (EST)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
Message-ID: <alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>

On Tue, 8 Jul 2008, Curt, WE7U wrote:

> On Mon, 7 Jul 2008, Damien Miller wrote:
> 
> > OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release is one of
> > the biggest in recent years, with two hackathons' worth of improvements
> > and fixes for some of our most recalcitrant bugs.
> 
> Does this version have the clear-text-after-authentication patch in
> it?

No - we have said repeatedly that we are not interested in adding support
for the "none" cipher.

> The amateur radio people still need this tweak in order to use
> OpenSSH over ham radio data links.  The FCC does not allow
> encryption of data on our frequencies, but does allow encryption for
> authentication purposes.

I'm sorry about your government's stupid laws, but I think that there
is much potential for users to harm themselves if we were to add the
null cipher.

-d


From cristian.ionescu-idbohrn at axis.com  Wed Jul  9 19:33:25 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Wed, 9 Jul 2008 11:33:25 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <0807081546470.18603@somehost>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
Message-ID: <0807091120570.18603@somehost>

On Tue, 8 Jul 2008, Cristian Ionescu-Idbohrn wrote:

> Warnings:
>
> bindresvport.c: In function `bindresvport_sa':
> bindresvport.c:57: warning: declaration of `sin' shadows a global declaration
>
> rresvport.c: In function `rresvport_af':
> rresvport.c:92: warning: implicit declaration of function `close'
>
> umac.c:187: warning: declaration of `buffer_ptr' shadows a global declaration
> buffer.h:31: warning: shadowed declaration is here
>
> auth.c: In function `auth_openkeyfile':
> auth.c:489: warning: implicit declaration of function `close'

I propose the attached trivial patches to kill the warnings listed
above.


Cheers,

-- 
Cristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01_shadows_global.patch
Type: text/x-diff
Size: 1486 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080709/a74f347c/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02_implicit_declaration_of_close.patch
Type: text/x-diff
Size: 568 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080709/a74f347c/attachment-0001.bin 

From des at des.no  Wed Jul  9 20:04:07 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 09 Jul 2008 12:04:07 +0200
Subject: loginmsg bug
Message-ID: <864p6z4bmw.fsf@ds4.des.no>

Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html

This Mrdkaaa character claims to have exploited this, but does not say
how.

The issue is that if do_pam_account() fails, do_authloop() will call
packet_disconnect() with loginmsg as the format string (classic
printf(foo) instead of printf("%s", foo) bug).

The stuff that do_authloop() appends to loginmsg is harmless (the user
name is safe, since at this point we know the account exists).  The
question is, what does loginmsg contain before do_authloop()?

Can loginmsg at this point contain the "Last login" text?  That one's
unsafe since it contains the result of a reverse DNS lookup.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From des at des.no  Wed Jul  9 20:08:17 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 09 Jul 2008 12:08:17 +0200
Subject: loginmsg bug
In-Reply-To: <864p6z4bmw.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?=
	=?utf-8?Q?rav=22's?= message of
	"Wed\, 09 Jul 2008 12\:04\:07 +0200")
References: <864p6z4bmw.fsf@ds4.des.no>
Message-ID: <86zlor2wvi.fsf@ds4.des.no>

Dag-Erling Sm?rgrav <des at des.no> writes:
> Can loginmsg at this point contain the "Last login" text?  That one's
> unsafe since it contains the result of a reverse DNS lookup.

a quick check suggests it can't, and AFAICT the offending code runs in
the unprivileged child, so I really can't see how he exploited it.

Does anybody know what's going on?

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From djm at mindrot.org  Wed Jul  9 20:21:29 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 20:21:29 +1000 (EST)
Subject: loginmsg bug
In-Reply-To: <864p6z4bmw.fsf@ds4.des.no>
References: <864p6z4bmw.fsf@ds4.des.no>
Message-ID: <alpine.BSO.1.10.0807092012570.8636@fuyu.mindrot.org>

On Wed, 9 Jul 2008, Dag-Erling Sm?rgrav wrote:

> Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html
> 
> This Mrdkaaa character claims to have exploited this, but does not say
> how.

hmm, loginmsg starts empty and is filled from three sources:

- The contents of a sshd_config:Banner file (if any)
- Password expiry messages generated by sshd
- Messages generated by PAM

Of these three, the PAM messages are the only ones that could
possibly be attacker-controlled (e.g. echoing back a deliberately
corrupted username), but I don't know off the top of my head whether
any PAM modules will actually do that. The actual bug happens in the path
that handles a failed PAM account check, so it will have accrued these
messages.

The second difficulty in exploiting this in the wild is that that
the packet_disconnect() call should only ever happen in the unprivileged
slave process. Maybe the reporter disabled privsep for his/her demo?

-d

From djm at mindrot.org  Wed Jul  9 20:36:22 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 20:36:22 +1000 (EST)
Subject: loginmsg bug
In-Reply-To: <alpine.BSO.1.10.0807092012570.8636@fuyu.mindrot.org>
References: <864p6z4bmw.fsf@ds4.des.no>
	<alpine.BSO.1.10.0807092012570.8636@fuyu.mindrot.org>
Message-ID: <alpine.BSO.1.10.0807092024380.8636@fuyu.mindrot.org>

On Wed, 9 Jul 2008, Damien Miller wrote:

> On Wed, 9 Jul 2008, Dag-Erling Sm?rgrav wrote:
> 
> > Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html
> > 
> > This Mrdkaaa character claims to have exploited this, but does not say
> > how.
> 
> hmm, loginmsg starts empty and is filled from three sources:
> 
> - The contents of a sshd_config:Banner file (if any)
> - Password expiry messages generated by sshd
> - Messages generated by PAM
> 
> Of these three, the PAM messages are the only ones that could
> possibly be attacker-controlled (e.g. echoing back a deliberately
> corrupted username), but I don't know off the top of my head whether
> any PAM modules will actually do that. The actual bug happens in the path
> that handles a failed PAM account check, so it will have accrued these
> messages.

Actually, it couldn't be the username that is the vector because we
sanitise that. It would have to be (as you suggested originally) DNS
or something else from the local environment.

Populating loginmsg with lastlog happens postauth (at the time the 
interactive session is established). An exception to this would be
hosts where an administrator has put pam_lastlog.so in the PAM account
stack.

-d

From djm at mindrot.org  Wed Jul  9 20:43:06 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 20:43:06 +1000 (EST)
Subject: loginmsg bug
In-Reply-To: <86zlor2wvi.fsf@ds4.des.no>
References: <864p6z4bmw.fsf@ds4.des.no> <86zlor2wvi.fsf@ds4.des.no>
Message-ID: <alpine.BSO.1.10.0807092040450.8636@fuyu.mindrot.org>

On Wed, 9 Jul 2008, Dag-Erling Sm?rgrav wrote:

> Dag-Erling Sm?rgrav <des at des.no> writes:
> > Can loginmsg at this point contain the "Last login" text?  That one's
> > unsafe since it contains the result of a reverse DNS lookup.
> 
> a quick check suggests it can't, and AFAICT the offending code runs in
> the unprivileged child, so I really can't see how he exploited it.
> 
> Does anybody know what's going on?

I'd say the reporter disabled privsep and rigged a PAM module to display
a custom message (if they worked up to an exploit at all).

The vulnerability criteria seem to be:

1. protocol 1 enabled
2. privsep disabled
3. successful authentication
4. PAM accounting module in stack that returns attacker-supplied data

-d

From des at des.no  Wed Jul  9 21:10:11 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 09 Jul 2008 13:10:11 +0200
Subject: loginmsg bug
In-Reply-To: <alpine.BSO.1.10.0807092040450.8636@fuyu.mindrot.org> (Damien
	Miller's message of "Wed\, 9 Jul 2008 20\:43\:06 +1000 \(EST\)")
References: <864p6z4bmw.fsf@ds4.des.no> <86zlor2wvi.fsf@ds4.des.no>
	<alpine.BSO.1.10.0807092040450.8636@fuyu.mindrot.org>
Message-ID: <86od572u0c.fsf@ds4.des.no>

Damien Miller <djm at mindrot.org> writes:
> I'd say the reporter disabled privsep and rigged a PAM module to display
> a custom message (if they worked up to an exploit at all).
>
> The vulnerability criteria seem to be:
>
> 1. protocol 1 enabled
> 2. privsep disabled
> 3. successful authentication
> 4. PAM accounting module in stack that returns attacker-supplied data

That's pretty much what I concluded as well.  He found something that
looked like a classic bug (printf() with no format string) and set up a
highly contrived scenario in which the bug is exploitable.

Anyway, the fix is trivial - add "%s" to the packet_disconnect() call in
do_authloop().

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From djm at mindrot.org  Wed Jul  9 21:32:05 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 9 Jul 2008 21:32:05 +1000 (EST)
Subject: loginmsg bug
In-Reply-To: <86od572u0c.fsf@ds4.des.no>
References: <864p6z4bmw.fsf@ds4.des.no> <86zlor2wvi.fsf@ds4.des.no>
	<alpine.BSO.1.10.0807092040450.8636@fuyu.mindrot.org>
	<86od572u0c.fsf@ds4.des.no>
Message-ID: <alpine.BSO.1.10.0807092129110.23799@fuyu.mindrot.org>

On Wed, 9 Jul 2008, Dag-Erling Sm?rgrav wrote:

> Damien Miller <djm at mindrot.org> writes:
> > I'd say the reporter disabled privsep and rigged a PAM module to display
> > a custom message (if they worked up to an exploit at all).
> >
> > The vulnerability criteria seem to be:
> >
> > 1. protocol 1 enabled
> > 2. privsep disabled
> > 3. successful authentication
> > 4. PAM accounting module in stack that returns attacker-supplied data
> 
> That's pretty much what I concluded as well.  He found something that
> looked like a classic bug (printf() with no format string) and set up a
> highly contrived scenario in which the bug is exploitable.
> 
> Anyway, the fix is trivial - add "%s" to the packet_disconnect() call in
> do_authloop().

Yes, I have already committed such a fix and have added -Wformat-security
to the default gcc 3.x and 4.x CFLAGS which would have caught this screwup.

I'm not going to rush out a release unless someone can point out a
commonly used PAM module that sends exploitable messages.

-d

From archer at eskimo.com  Thu Jul 10 00:45:40 2008
From: archer at eskimo.com (Curt, WE7U)
Date: Wed, 9 Jul 2008 07:45:40 -0700 (PDT)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
Message-ID: <alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>

On Wed, 9 Jul 2008, Damien Miller wrote:

> On Tue, 8 Jul 2008, Curt, WE7U wrote:
>
>> Does this version have the clear-text-after-authentication patch in
>> it?
>
> No - we have said repeatedly that we are not interested in adding support
> for the "none" cipher.

I subscribed to this list several years back.  I've not brought this
topic up often, but to my recollection have not received as clear an
answer as you indicate above during the time I've been subscribed.

Not knowing who all of the developers are (or who speaks for the
developers), it's hard to judge what the level of interest is among
them.  There has been interest both on and off the list but I have
no way of knowing whether that interest was among developers, users,
or both.


>> The amateur radio people still need this tweak in order to use
>> OpenSSH over ham radio data links.  The FCC does not allow
>> encryption of data on our frequencies, but does allow encryption for
>> authentication purposes.
>
> I'm sorry about your government's stupid laws, but I think that there
> is much potential for users to harm themselves if we were to add the
> null cipher.

It's likely that your government or other nearby governments have
similar "stupid" laws for amateur radio.  Many do.  Radio links know
no political boundaries, so encryption over radio links tends to
make the powers-that-be nervous and they legislate against it.
Either that or they borrowed bits from FCC regulations which is also
common.

Why would users be so stupid as to get in trouble with something
like:  "--NONE_CIPHER_PLEASE_DONT_USE" or
"--NO_CIPHER_HAM_RADIO_ONLY" or similar?  I generally assume my
users are intelligent and am not often disappointed.  There are
obvious ways to make a NULL cipher available from the command-line
without letting users get into trouble with it.

Are you aware that hams have a link-level protocol used for
over-the-air that is actually part of distributed Linux kernel
sources?  We send TCP/IP and other protocols over lower-level AX.25
protocol nicely.  With a NULL-Cipher patch we'd be able to use SSH
over AX.25 to authenticate.  At one time we were able to, but it was
years ago and I can't recall now which version of SSH supported it.
It was a feature we had gotten quite used to and was available on
any Linux box at the time.

Today with the large number of embedded Linux devices out there it
would be VERY handy to be able to remotely configure mountaintop
systems using OpenSSH.  Many repeater sites are snow-bound most of
the year making physical access impossible until late spring or
summer.  Data links over radio make it possible to maintain these
systems.

I was hoping that the OpenSSH project might eventually support such
operation:  I wouldn't bring the topic up every six months to a year
if I didn't think it was important and useful.  Hams do amazing work
in emergency services, providing radio links in/out of affected
areas, all for free.  How about making it easier for us to continue
to provide such services to your community and others?

Curt, proud member of Snohomish County Search and Rescue, ham for 29
years, admin on the Xastir open-source project, contributor to many
others.

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
   Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"

From mouring at eviladmin.org  Thu Jul 10 02:19:57 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Wed, 9 Jul 2008 11:19:57 -0500 (CDT)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
Message-ID: <alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>



On Wed, 9 Jul 2008, Curt, WE7U wrote:

[..]
> over AX.25 to authenticate.  At one time we were able to, but it was
> years ago and I can't recall now which version of SSH supported it.
> It was a feature we had gotten quite used to and was available on
> any Linux box at the time.
>

The old SSH Corp supported this, and maybe the OSSH version did.  However, 
IIRC "none" cipher was one of the first things removed from OpenSSH back 
when it was forked.

- Ben

From des at des.no  Thu Jul 10 06:27:22 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 09 Jul 2008 22:27:22 +0200
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org> (Ben
	Lindstrom's message of "Wed\, 9 Jul 2008 11\:19\:57 -0500 \(CDT\)")
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
Message-ID: <863amin6qd.fsf@ds4.des.no>

Ben Lindstrom <mouring at eviladmin.org> writes:
> [...]  IIRC "none" cipher was one of the first things removed from
> OpenSSH back when it was forked.

Last I checked, it's still there; you just need to add "none" to the
list of accepted ciphers in myproposal.h.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From rapier at psc.edu  Thu Jul 10 06:45:34 2008
From: rapier at psc.edu (rapier)
Date: Wed, 09 Jul 2008 16:45:34 -0400
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <863amin6qd.fsf@ds4.des.no>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no>
Message-ID: <4875236E.5020006@psc.edu>



Dag-Erling Sm?rgrav wrote:
> Ben Lindstrom <mouring at eviladmin.org> writes:
>> [...]  IIRC "none" cipher was one of the first things removed from
>> OpenSSH back when it was forked.
> 
> Last I checked, it's still there; you just need to add "none" to the
> list of accepted ciphers in myproposal.h.

The problem is that just adding 'none' back pushes all interaction into 
the clear which is, IMNSHO, a really bad idea. While I personally think 
the none-cipher switching is a reasonable compromise between security 
and performance I fully understand and support the OpenSSH decision to 
not include it (even if I don't completely agree with it). There is, one 
can argue, a certain expectation that all SSH communications will occur 
with full encryption and the none switch, without a doubt, opens the 
user to additional risks. I've done my best to minimize those risks but 
they're still there.

So I'll continue to make the none switch patch available to users who 
are willing to assume those risks. What would be interesting would be if 
OpenSSH would be willing to support the idea of cipher switching in 
general - so that a user could move from one cipher to another 
mid-stream. There would be no need to include the none cipher in that 
list of allowed ciphers (but obviously, I'd like to build on top of an 
approved mechanism).

Either way, this is OpenSSH so the dev team gets to make these decisions 
- and live with those decisions. This is a heavy responsibility and why 
I fully support the decisions they make regarding their own software.

The main question I have is if they've increase the number of 
outstanding requests in SFTP to match the increased receive window size 
introduced in 4.7.


From rapier at psc.edu  Thu Jul 10 06:50:43 2008
From: rapier at psc.edu (rapier)
Date: Wed, 09 Jul 2008 16:50:43 -0400
Subject: Clear-Text Patch?  was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
Message-ID: <487524A3.9020801@psc.edu>

Curt, WE7U wrote:

> We'd like it to eventually be available on
> most Linux distributions ready-to-go for us.  In other words,
> compiling in the patch from the HPN mods is beyond a lot of hams.

We're looking into providing pre-compiled binaries of various flavors of 
the hpn patch. I had meant to get this started early but I didn't get 
the intern I planned on getting for this summer. I've not done it in the 
past because I don't want anyone to think I'm forking the code. However, 
there has been a call for this from the community I'm trying to support 
and as such its been 'suggested' by my higher ups that I do this. Its 
also been 'suggested' that this be available by November
(for the SC'08 convention).

chris

From rapier at psc.edu  Thu Jul 10 07:43:56 2008
From: rapier at psc.edu (rapier)
Date: Wed, 09 Jul 2008 17:43:56 -0400
Subject: Changes in channel_connect_to
Message-ID: <4875311C.5040005@psc.edu>

I just want to make sure I'm interpreting this correctly.

In 5.0 channel_connect_to would only return the requested socket. You'd 
then need to use this socket to create the channel with with channel_new.

In 5.1 channel_connect_to doesn't return the socket but rolls in 
channel_new and now returns the channel directly. The usage of 
channel_new hasn't changed though, only channel_connect_to.

Is that about right? Are the any subtleties I'm missing?

From dan at nf15.lightwave.net.ru  Thu Jul 10 07:48:08 2008
From: dan at nf15.lightwave.net.ru (Dan Yefimov)
Date: Thu, 10 Jul 2008 01:48:08 +0400 (MSD)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
Message-ID: <Pine.LNX.4.44.0807100132040.5046-100000@D00M.lightwave.net.ru>

On Wed, 9 Jul 2008, Curt, WE7U wrote:

> >> The amateur radio people still need this tweak in order to use
> >> OpenSSH over ham radio data links.  The FCC does not allow
> >> encryption of data on our frequencies, but does allow encryption for
> >> authentication purposes.
> >
> > I'm sorry about your government's stupid laws, but I think that there
> > is much potential for users to harm themselves if we were to add the
> > null cipher.
> 
> It's likely that your government or other nearby governments have
> similar "stupid" laws for amateur radio.  Many do.  Radio links know
> no political boundaries, so encryption over radio links tends to
> make the powers-that-be nervous and they legislate against it.
> Either that or they borrowed bits from FCC regulations which is also
> common.
> 
Hmm. Strange point. Internet due to it's nature knows no political boundaries 
too, but AFAIK no country prohibits encrypted traffic over it. I don't in any 
way vote against including the none cipher in the OpenSSH distribution, but I 
think that the problem of such actually stupid regulations would be much better 
solved in a legislative way.
-- 

    Sincerely Your, Dan.


From bob at proulx.com  Thu Jul 10 08:14:30 2008
From: bob at proulx.com (Bob Proulx)
Date: Wed, 9 Jul 2008 16:14:30 -0600
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <Pine.LNX.4.44.0807100132040.5046-100000@D00M.lightwave.net.ru>
References: <alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<Pine.LNX.4.44.0807100132040.5046-100000@D00M.lightwave.net.ru>
Message-ID: <20080709221430.GA6796@dementia.proulx.com>

Dan Yefimov wrote:
> Curt, WE7U wrote:
> > It's likely that your government or other nearby governments have
> > similar "stupid" laws for amateur radio.  Many do.  Radio links know
> > no political boundaries, so encryption over radio links tends to
> > make the powers-that-be nervous and they legislate against it.
> > Either that or they borrowed bits from FCC regulations which is also
> > common.
>
> Hmm. Strange point. Internet due to it's nature knows no political
> boundaries too, but AFAIK no country prohibits encrypted traffic
> over it. I don't in any way vote against including the none cipher
> in the OpenSSH distribution, but I think that the problem of such
> actually stupid regulations would be much better solved in a
> legislative way.

The regulations for amateur radio have been derived from international
treaty which prohibited amateur radio communication from using codes
or ciphers to obscure the content.  In the US these regulations date
back to the Communications Act of 1934 which still governs
telecommunications today.  In 1934 encryption was still viewed as a
munition of war.  These regulations well predate the computer
revolution and the Internet.

Trying to change international treaty is not something that can be
done easily even when there isn't any controversy involved.
Unfortunately legislature isn't like a computer program which can be
modified and improved incrementally or all together.  It is the social
creation of people.  It isn't something to which you can apply logic.

Bob

From dan at nf15.lightwave.net.ru  Thu Jul 10 08:40:57 2008
From: dan at nf15.lightwave.net.ru (Dan Yefimov)
Date: Thu, 10 Jul 2008 02:40:57 +0400 (MSD)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <20080709221430.GA6796@dementia.proulx.com>
Message-ID: <Pine.LNX.4.44.0807100224250.5046-100000@D00M.lightwave.net.ru>

On Wed, 9 Jul 2008, Bob Proulx wrote:

> Trying to change international treaty is not something that can be
> done easily even when there isn't any controversy involved.

While international treaties aren't something to be easily changed, they can be 
left at will by legislation.

> Unfortunately legislature isn't like a computer program which can be
> modified and improved incrementally or all together.  It is the social
> creation of people.  It isn't something to which you can apply logic.
> 
Everything in the society has some logic that however unfortunately isn't 
obliged to be obvious and clear to everyone.
-- 

    Sincerely Your, Dan.


From openssh at roumenpetrov.info  Thu Jul 10 08:56:42 2008
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 10 Jul 2008 01:56:42 +0300
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <Pine.LNX.4.44.0807100132040.5046-100000@D00M.lightwave.net.ru>
References: <Pine.LNX.4.44.0807100132040.5046-100000@D00M.lightwave.net.ru>
Message-ID: <4875422A.3080009@roumenpetrov.info>

Dan Yefimov wrote:
> On Wed, 9 Jul 2008, Curt, WE7U wrote:
> 
>>>> The amateur radio people still need this tweak in order to use
>>>> OpenSSH over ham radio data links.  The FCC does not allow
>>>> encryption of data on our frequencies, but does allow encryption for
>>>> authentication purposes.
>>> I'm sorry about your government's stupid laws, but I think that there
>>> is much potential for users to harm themselves if we were to add the
>>> null cipher.
>> It's likely that your government or other nearby governments have
>> similar "stupid" laws for amateur radio.  Many do.  Radio links know
>> no political boundaries, so encryption over radio links tends to
>> make the powers-that-be nervous and they legislate against it.
>> Either that or they borrowed bits from FCC regulations which is also
>> common.
>>
> Hmm. Strange point. Internet due to it's nature knows no political boundaries 
> too, but AFAIK no country prohibits encrypted traffic over it. 

The rule is not same for encrypted radio communications.


> I don't in any 
> way vote against including the none cipher in the OpenSSH distribution, but I 
> think that the problem of such actually stupid regulations would be much better 
> solved in a legislative way.

May be encrypted radio communications pass under rules for dual-use 
technologies.


Roumen

From dan at nf15.lightwave.net.ru  Thu Jul 10 09:06:22 2008
From: dan at nf15.lightwave.net.ru (Dan Yefimov)
Date: Thu, 10 Jul 2008 03:06:22 +0400 (MSD)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <4875422A.3080009@roumenpetrov.info>
Message-ID: <Pine.LNX.4.44.0807100303130.17659-100000@D00M.lightwave.net.ru>

On Thu, 10 Jul 2008, Roumen Petrov wrote:

> > I don't in any 
> > way vote against including the none cipher in the OpenSSH distribution, but I 
> > think that the problem of such actually stupid regulations would be much better 
> > solved in a legislative way.
> 
> May be encrypted radio communications pass under rules for dual-use 
> technologies.
> 
Internet easily fits that category.
-- 

    Sincerely Your, Dan.


From djm at mindrot.org  Thu Jul 10 13:15:51 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 10 Jul 2008 13:15:51 +1000 (EST)
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
Message-ID: <alpine.BSO.1.10.0807101237100.19199@fuyu.mindrot.org>

On Wed, 9 Jul 2008, Curt, WE7U wrote:

> On Wed, 9 Jul 2008, Damien Miller wrote:
> 
> > On Tue, 8 Jul 2008, Curt, WE7U wrote:
> >
> >> Does this version have the clear-text-after-authentication patch in
> >> it?
> >
> > No - we have said repeatedly that we are not interested in adding support
> > for the "none" cipher.
> 
> I subscribed to this list several years back.  I've not brought this
> topic up often, but to my recollection have not received as clear an
> answer as you indicate above during the time I've been subscribed.
> 
> Not knowing who all of the developers are (or who speaks for the
> developers), it's hard to judge what the level of interest is among
> them.  There has been interest both on and off the list but I have
> no way of knowing whether that interest was among developers, users,
> or both.

There has certainly been some interest in users, but not any amongst
the other developers that I'm aware of (you can get an idea of who is
working on OpenSSH by looking at the ChangeLog file in the distribution
btw).

Let me explain our rationale a little more:

OpenSSH is a security tool used by lots of people of wildly varying
technical skill and cryptographic fluency, so we want to make it as
foolproof as possible. Part of this means that we are willing to
deliberately exclude dangerous options even if users want them.

Generally, the people who require esoteric or dangerous options also
happen to be the people who are technical enough to patch them in
themselves.

> It's likely that your government or other nearby governments have
> similar "stupid" laws for amateur radio.  Many do.  Radio links know
> no political boundaries, so encryption over radio links tends to
> make the powers-that-be nervous and they legislate against it.
> Either that or they borrowed bits from FCC regulations which is also
> common.

Please don't read too much into my throwaway line about laws - I'm not
opposed to adding the null cipher because of politics, it is really
about user safety.

> Why would users be so stupid as to get in trouble with something
> like:  "--NONE_CIPHER_PLEASE_DONT_USE" or
> "--NO_CIPHER_HAM_RADIO_ONLY" or similar?  I generally assume my
> users are intelligent and am not often disappointed.  There are
> obvious ways to make a NULL cipher available from the command-line
> without letting users get into trouble with it.

No. Unfortunately distributors of OpenSSH have a imperfect record of
changing defaults and turning on options that we recommend against.
Invariably, the support requests and blame when things go wrong come
back to us.

Also, once you are at the point of having to do a custom compile of
OpenSSH to get the options you want then adding a small patch is 
very low additional overhead anyway.

> Today with the large number of embedded Linux devices out there it
> would be VERY handy to be able to remotely configure mountaintop
> systems using OpenSSH.  Many repeater sites are snow-bound most of
> the year making physical access impossible until late spring or
> summer.  Data links over radio make it possible to maintain these
> systems.
> 
> I was hoping that the OpenSSH project might eventually support such
> operation:  I wouldn't bring the topic up every six months to a year
> if I didn't think it was important and useful.  Hams do amazing work
> in emergency services, providing radio links in/out of affected
> areas, all for free.  How about making it easier for us to continue
> to provide such services to your community and others?

We will help by doing our best to keep OpenSSH a high quality product,
but we are not willing to be "all things to all people".

-d

From jronan at tssg.org  Thu Jul 10 17:44:54 2008
From: jronan at tssg.org (John Ronan)
Date: Thu, 10 Jul 2008 08:44:54 +0100
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807101237100.19199@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807101237100.19199@fuyu.mindrot.org>
Message-ID: <83DDD611-3728-4432-9849-2F7FA78A0ECA@tssg.org>

Morning,
>
> There has certainly been some interest in users, but not any amongst
> the other developers that I'm aware of (you can get an idea of who is
> working on OpenSSH by looking at the ChangeLog file in the  
> distribution
> btw).
>
> Let me explain our rationale a little more:
>
> OpenSSH is a security tool used by lots of people of wildly varying
> technical skill and cryptographic fluency, so we want to make it as
> foolproof as possible. Part of this means that we are willing to
> deliberately exclude dangerous options even if users want them.
>
> Generally, the people who require esoteric or dangerous options also
> happen to be the people who are technical enough to patch them in
> themselves.
>
You say yourself that there has been some interest amongst users, I  
personally, since January have been using the HPN-SSH patch on three  
machines (Thanks to Michael Stevens for pointing me in the right  
direction) that I have no other access to except over radio or by  
visiting the site and visiting the site is impossible for several  
months of the year.

Obviously I use (unpatched) open-ssh every day during my normal work,  
and I'm thankful for it.

>> It's likely that your government or other nearby governments have
>> similar "stupid" laws for amateur radio.  Many do.  Radio links know
>> no political boundaries, so encryption over radio links tends to
>> make the powers-that-be nervous and they legislate against it.
>> Either that or they borrowed bits from FCC regulations which is also
>> common.
>
> Please don't read too much into my throwaway line about laws - I'm not
> opposed to adding the null cipher because of politics, it is really
> about user safety.
>
>> Why would users be so stupid as to get in trouble with something
>> like:  "--NONE_CIPHER_PLEASE_DONT_USE" or
>> "--NO_CIPHER_HAM_RADIO_ONLY" or similar?  I generally assume my
>> users are intelligent and am not often disappointed.  There are
>> obvious ways to make a NULL cipher available from the command-line
>> without letting users get into trouble with it.
>
> No. Unfortunately distributors of OpenSSH have a imperfect record of
> changing defaults and turning on options that we recommend against.
> Invariably, the support requests and blame when things go wrong come
> back to us.
>
> Also, once you are at the point of having to do a custom compile of
> OpenSSH to get the options you want then adding a small patch is
> very low additional overhead anyway.
>
Ok, I understand your concern. (Australia, I think, have recently  
relaxed this rule to allow the use of encrypted traffic on air btw)

How about printing a big ugly half page warning if the option is  
switched on and when it gets enabled at compile time?  So the user is  
under no illusion as to whats happening if the null cipher is enabled.

Don't forget that in order for it to work at all, in my case I would  
have to compile with whatever options that could be required to  
enable it on at least 4 machines.

If a distribution started enabling the none ciper by default (which I  
doubt would happen), I'll gladly chase them down and file bug reports  
with them until they desist. I reckon I'm good for another 30-50  
years ish, and I'm nothing if not persistent.

Even if someone managed to download the source and build it with  
'none-cipher' enabled on every machine they wanted to log into, AND  
use whatever command line option was required to engage it, they  
would have to go to a lot of trouble to use it.


>
[snip]
> We will help by doing our best to keep OpenSSH a high quality product,
Which, there can be no argument, that it is, and I thank you for it.
> but we are not willing to be "all things to all people".
>
Well we're not asking you to be that, just allow for the relatively  
easy enabling of a feature that allows us to stay legal.

Regards
de John
EI7IG
--
John Ronan <jronan at tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org




From g.chulkov at jacobs-university.de  Fri Jul 11 09:20:40 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Fri, 11 Jul 2008 02:20:40 +0300
Subject: Race condition in sshd
Message-ID: <200807110220.44542.g.chulkov@jacobs-university.de>

Hello,

This bug exists in 5.0p1. I apologize that I couldn't test against HEAD.

I _believe_ I have found a race condition in sshd. In the v2 protocol, after a 
connection, the accepting process forks in privsep_preauth(). The parent 
executes monitor_child_preauth() to allow certain privsep requests necessary 
for authentication. The unprivileged child runs do_ssh2_kex() followed by 
do_authentication2().

I am working on a new KEX algorithm whose primary feature is performance. It 
is fast enough that do_authentication2() runs _before_ the monitor has a 
chance to permit the necessary requests (MONITOR_REQ_PWNAM in particular), 
and therefore authentication fails on the server with:

monitor_read: unpermitted request 6

Could someone more experienced please look at this?

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080711/7a916072/attachment.bin 

From djm at mindrot.org  Fri Jul 11 09:55:44 2008
From: djm at mindrot.org (Damien Miller)
Date: Fri, 11 Jul 2008 09:55:44 +1000 (EST)
Subject: Race condition in sshd
In-Reply-To: <200807110220.44542.g.chulkov@jacobs-university.de>
References: <200807110220.44542.g.chulkov@jacobs-university.de>
Message-ID: <alpine.BSO.1.10.0807110952380.19199@fuyu.mindrot.org>

On Fri, 11 Jul 2008, Georgi Chulkov wrote:

> Hello,
> 
> This bug exists in 5.0p1. I apologize that I couldn't test against
> HEAD.
>
> I _believe_ I have found a race condition in sshd. In the v2 protocol,
> after a connection, the accepting process forks in privsep_preauth().
> The parent executes monitor_child_preauth() to allow certain privsep
> requests necessary for authentication. The unprivileged child runs
> do_ssh2_kex() followed by do_authentication2().
>
> I am working on a new KEX algorithm whose primary feature is
> performance. It is fast enough that do_authentication2() runs
> _before_ the monitor has a chance to permit the necessary requests
> (MONITOR_REQ_PWNAM in particular), and therefore authentication fails
> on the server with:
>
> monitor_read: unpermitted request 6
>
> Could someone more experienced please look at this?

It looks like there is a race there, but it would be nearly impossible
to hit with our current KEX methods. File a bug at
http://bugzilla.mindrot.org so it doesn't get lost.

You can fix the race by setting up a pipe shared between the monitor and
child, and making the child wait until the monitor end closes, which
it should do after permitting the monitor calls.

-d

From djm at mindrot.org  Fri Jul 11 17:51:41 2008
From: djm at mindrot.org (Damien Miller)
Date: Fri, 11 Jul 2008 17:51:41 +1000 (EST)
Subject: Changes in channel_connect_to
In-Reply-To: <4875311C.5040005@psc.edu>
References: <4875311C.5040005@psc.edu>
Message-ID: <alpine.BSO.1.10.0807111740020.24152@fuyu.mindrot.org>

On Wed, 9 Jul 2008, rapier wrote:

> I just want to make sure I'm interpreting this correctly.
> 
> In 5.0 channel_connect_to would only return the requested socket. You'd 
> then need to use this socket to create the channel with with channel_new.
> 
> In 5.1 channel_connect_to doesn't return the socket but rolls in 
> channel_new and now returns the channel directly. The usage of 
> channel_new hasn't changed though, only channel_connect_to.
> 
> Is that about right? Are the any subtleties I'm missing?

Most of the changes are in the connect_to(). Much of its logic has 
been remvoed to connect_next() to support fallback to trying additional
addresses when the initial connect fails. 

To support this, connect_to fills in the channel->connect_ctx with
the addresses of the host that it is trying to connect to. On a
connect error, channel_post_connecting() can call connect_next() with
this structure to pick the next address to try rather than just failing.

-d

From vinschen at redhat.com  Fri Jul 11 18:02:45 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 11 Jul 2008 10:02:45 +0200
Subject: [PATCH] contrib/cygwin/ssh-{host,user}-config
Message-ID: <20080711080245.GM24644@calimero.vinschen.de>

Hi,

attached a total revamp of the ssh-host-config and ssh-user-config
scripts.  The underlying idea is that one of our maintainers has
contributed a unified configuration script environment for Cygwin,
called csih.  This is now used by the below ssh config scripts as well.
There's also an additional file called sshd-inetd, which is a service
configuration file for inetutils.  The Makefile had to be changed
accordingly.

Could somebody please check this in?

And, is is possible to get this change into 5.1p1?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssh.diff
Type: text/x-patch
Size: 52946 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080711/4e245b7e/attachment-0001.bin 

From g.chulkov at jacobs-university.de  Fri Jul 11 19:00:34 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Fri, 11 Jul 2008 12:00:34 +0300
Subject: Race condition in sshd
In-Reply-To: <alpine.BSO.1.10.0807110952380.19199@fuyu.mindrot.org>
References: <200807110220.44542.g.chulkov@jacobs-university.de>
	<alpine.BSO.1.10.0807110952380.19199@fuyu.mindrot.org>
Message-ID: <200807111200.38048.g.chulkov@jacobs-university.de>

On Friday 11 July 2008 02:55:44 Damien Miller wrote:
> On Fri, 11 Jul 2008, Georgi Chulkov wrote:
> > Hello,
> >
> > This bug exists in 5.0p1. I apologize that I couldn't test against
> > HEAD.
> >
> > I _believe_ I have found a race condition in sshd. In the v2 protocol,
> > after a connection, the accepting process forks in privsep_preauth().
> > The parent executes monitor_child_preauth() to allow certain privsep
> > requests necessary for authentication. The unprivileged child runs
> > do_ssh2_kex() followed by do_authentication2().
> >
> > I am working on a new KEX algorithm whose primary feature is
> > performance. It is fast enough that do_authentication2() runs
> > _before_ the monitor has a chance to permit the necessary requests
> > (MONITOR_REQ_PWNAM in particular), and therefore authentication fails
> > on the server with:
> >
> > monitor_read: unpermitted request 6
> >
> > Could someone more experienced please look at this?
>
> It looks like there is a race there, but it would be nearly impossible
> to hit with our current KEX methods. File a bug at
> http://bugzilla.mindrot.org so it doesn't get lost.
>
> You can fix the race by setting up a pipe shared between the monitor and
> child, and making the child wait until the monitor end closes, which
> it should do after permitting the monitor calls.

I put the pipe close call at the end of monitor.c:mm_answer_sign(), right 
after the permission for MONITOR_REQ_PWNAM is set to true. But I can't figure 
out where exactly to put the blocking pipe read call. Everything I tried is 
either too early (->authentication doesn't get far enough to permit 
MONITOR_REQ_PWNAM) or too late (->unpermitted request).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080711/23a78cfd/attachment.bin 

From rebel at atrey.karlin.mff.cuni.cz  Wed Jul  9 02:00:26 2008
From: rebel at atrey.karlin.mff.cuni.cz (Michal Svec)
Date: Tue, 8 Jul 2008 18:00:26 +0200 (CEST)
Subject: SSH_RSA_MINIMUM_MODULUS_SIZE
Message-ID: <Pine.LNX.4.64.0807071535170.12973@atrey.karlin.mff.cuni.cz>


Hi,

is there any chance to make SSH_RSA_MINIMUM_MODULUS_SIZE configurable?
I keep receiving these messages:

   ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits
   key_verify failed for server_host_key

And it's quite a hassle to recompile each time I need to use it (there
are still devices where you can't fix it easily).

Thanks
Michal

From dbeecher at dmsgs.com  Sat Jul 12 02:58:05 2008
From: dbeecher at dmsgs.com (David Beecher)
Date: Fri, 11 Jul 2008 12:58:05 -0400
Subject: openssh / prngd unresolved bug since 2002, need help
Message-ID: <4877911D.5050508@dmsgs.com>

Hello,

I apologize if this is the wrong list. It was the list I was directed 
towards. I have reviewed the archives as well as everything I could 
google before posting. Any help is most appreciated:

We're seeing an error during sftp and ssh connections with consistent 
regularity. It's triggered by a high number of connections coming into 
sftp/ssh at the same time. It affects additional connections and leaves 
the failed connect attempts open for days in a TCP_WAIT state. We're 
seeing the error in the system logs:

openssh session hanging - prngd[671]: write() in socket_write() failed: 
Broken pipe

This appears to be an issue that has been an unresolved  problem with 
prngd since 2002.  Some have attributed the problem to prngd version 
0.9.26 (2004) but we are seeing it with version 0.9.25 (30 May 2002) as 
have others that we've seen on the web.

The problem appears to be (we are quoting here):

-- snip --
  When lots of processes query entropy at the same time, the "fairness"
  change introduced in 0.9.25 could lead to clients being only served with
  a delay.
  Reason: in serverloop.c the next client to serv is "i1" as determined from
    i1 = (prev_location + i) % max_query_old;
  The client that actually was served however was "i" instead of "i1".
  If the connection of "i" was not yet ready for "write" state set after
  getting the entropy, it might block.
  This problem has not been reported by any other user, though it might also
  have occured at other sites.
  Depending on the internal sorting of sockets by fd/slot (number increasing
  in the sequence of accepted connections, closed connections are
  removed from the list), connections might appear locked.
  The entropy served was not provided in the sequence intended. The
  entropy bytes returned via internal buffer however were consistent
  with the connection served (buffer[i]) was filled correctly for
  connection[i]. The problem therefore has no impact on the quality
  of seeding.
-- snap --

It appears that the latest version of prngd for sunos is 0.9.25 up 
through solaris 9.

The sourceforge for prngd (http://sourceforge.net/projects/prngd/) is 
alive but does not appear to be active. I'm going to contact them, has 
anybody else found a eliable solution or a newer version of prngd for 
sunos 5.8 that does not have this issue.

We have not received any response from the prngd group on sourceforge.

Thank you in advance for any/all help,
David


From mouring at eviladmin.org  Sat Jul 12 05:57:34 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Fri, 11 Jul 2008 14:57:34 -0500 (CDT)
Subject: openssh / prngd unresolved bug since 2002, need help
In-Reply-To: <4877911D.5050508@dmsgs.com>
References: <4877911D.5050508@dmsgs.com>
Message-ID: <alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org>


Under high number of connections if prngd is holding up the connection 
becoming authenticated you may be hitting your "MaxStartups" value.

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

As a work around (not suggesting this is an end-all solution) could be to 
bump that number to 20, and see if the problem becomes less frequent.

If this does improve your life then one has to figure out a better way to 
get entropy.  I suspect you are running too low to effectly pass good 
random data to sshd to use.

If you are on Solaris 9.. You should have a /dev/[u]random and you 
shouldn't need prngd (or am I thinking Solaris 10?).

- Ben

On Fri, 11 Jul 2008, David Beecher wrote:

> Hello,
>
> I apologize if this is the wrong list. It was the list I was directed
> towards. I have reviewed the archives as well as everything I could
> google before posting. Any help is most appreciated:
>
> We're seeing an error during sftp and ssh connections with consistent
> regularity. It's triggered by a high number of connections coming into
> sftp/ssh at the same time. It affects additional connections and leaves
> the failed connect attempts open for days in a TCP_WAIT state. We're
> seeing the error in the system logs:
>
> openssh session hanging - prngd[671]: write() in socket_write() failed:
> Broken pipe
>
> This appears to be an issue that has been an unresolved  problem with
> prngd since 2002.  Some have attributed the problem to prngd version
> 0.9.26 (2004) but we are seeing it with version 0.9.25 (30 May 2002) as
> have others that we've seen on the web.
>
> The problem appears to be (we are quoting here):
>
> -- snip --
>  When lots of processes query entropy at the same time, the "fairness"
>  change introduced in 0.9.25 could lead to clients being only served with
>  a delay.
>  Reason: in serverloop.c the next client to serv is "i1" as determined from
>    i1 = (prev_location + i) % max_query_old;
>  The client that actually was served however was "i" instead of "i1".
>  If the connection of "i" was not yet ready for "write" state set after
>  getting the entropy, it might block.
>  This problem has not been reported by any other user, though it might also
>  have occured at other sites.
>  Depending on the internal sorting of sockets by fd/slot (number increasing
>  in the sequence of accepted connections, closed connections are
>  removed from the list), connections might appear locked.
>  The entropy served was not provided in the sequence intended. The
>  entropy bytes returned via internal buffer however were consistent
>  with the connection served (buffer[i]) was filled correctly for
>  connection[i]. The problem therefore has no impact on the quality
>  of seeding.
> -- snap --
>
> It appears that the latest version of prngd for sunos is 0.9.25 up
> through solaris 9.
>
> The sourceforge for prngd (http://sourceforge.net/projects/prngd/) is
> alive but does not appear to be active. I'm going to contact them, has
> anybody else found a eliable solution or a newer version of prngd for
> sunos 5.8 that does not have this issue.
>
> We have not received any response from the prngd group on sourceforge.
>
> Thank you in advance for any/all help,
> David
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From dbeecher at dmsgs.com  Sat Jul 12 06:10:21 2008
From: dbeecher at dmsgs.com (David Beecher)
Date: Fri, 11 Jul 2008 16:10:21 -0400
Subject: openssh / prngd unresolved bug since 2002, need help
In-Reply-To: <alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org>
References: <4877911D.5050508@dmsgs.com>
	<alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org>
Message-ID: <4877BE2D.4060708@dmsgs.com>

Thankyou.

I already did that and any variation of that.  Does not help.  We found 
that if we connected more slowly to the sshd server daemon that the 
problem would not happen.  After a lot of digging, ruling out firewall, 
network, etc., we finally figured out the source of the bug -- prngd -- 
and how it does entropy.  Under high demand it fails.  This is a known 
specific bug with prngd that has never been resolved and those that have 
run into the problem never effectively troubleshot it.  They just 
figured a different way out or gave up.  Neither of those is an option 
here. 

This error was specifically introduced in prngd in the .25 version and 
has never been fixed. 

I contacted this list because I had no response from the 
sourceforge/prngd "project".

Very much appreciate your help.

Thank you,
David


Ben Lindstrom wrote:
>
> Under high number of connections if prngd is holding up the connection 
> becoming authenticated you may be hitting your "MaxStartups" value.
>
> $ man sshd_config
> [..]
>      MaxStartups
>              Specifies the maximum number of concurrent 
> unauthenticated con-
>              nections to the SSH daemon.  Additional connections will be
>              dropped until authentication succeeds or the 
> LoginGraceTime ex-
>              pires for a connection.  The default is 10.
> [..]
>
> As a work around (not suggesting this is an end-all solution) could be 
> to bump that number to 20, and see if the problem becomes less frequent.
>
> If this does improve your life then one has to figure out a better way 
> to get entropy.  I suspect you are running too low to effectly pass 
> good random data to sshd to use.
>
> If you are on Solaris 9.. You should have a /dev/[u]random and you 
> shouldn't need prngd (or am I thinking Solaris 10?).
>
> - Ben
>
> On Fri, 11 Jul 2008, David Beecher wrote:
>
>> Hello,
>>
>> I apologize if this is the wrong list. It was the list I was directed
>> towards. I have reviewed the archives as well as everything I could
>> google before posting. Any help is most appreciated:
>>
>> We're seeing an error during sftp and ssh connections with consistent
>> regularity. It's triggered by a high number of connections coming into
>> sftp/ssh at the same time. It affects additional connections and leaves
>> the failed connect attempts open for days in a TCP_WAIT state. We're
>> seeing the error in the system logs:
>>
>> openssh session hanging - prngd[671]: write() in socket_write() failed:
>> Broken pipe
>>
>> This appears to be an issue that has been an unresolved  problem with
>> prngd since 2002.  Some have attributed the problem to prngd version
>> 0.9.26 (2004) but we are seeing it with version 0.9.25 (30 May 2002) as
>> have others that we've seen on the web.
>>
>> The problem appears to be (we are quoting here):
>>
>> -- snip --
>>  When lots of processes query entropy at the same time, the "fairness"
>>  change introduced in 0.9.25 could lead to clients being only served 
>> with
>>  a delay.
>>  Reason: in serverloop.c the next client to serv is "i1" as 
>> determined from
>>    i1 = (prev_location + i) % max_query_old;
>>  The client that actually was served however was "i" instead of "i1".
>>  If the connection of "i" was not yet ready for "write" state set after
>>  getting the entropy, it might block.
>>  This problem has not been reported by any other user, though it 
>> might also
>>  have occured at other sites.
>>  Depending on the internal sorting of sockets by fd/slot (number 
>> increasing
>>  in the sequence of accepted connections, closed connections are
>>  removed from the list), connections might appear locked.
>>  The entropy served was not provided in the sequence intended. The
>>  entropy bytes returned via internal buffer however were consistent
>>  with the connection served (buffer[i]) was filled correctly for
>>  connection[i]. The problem therefore has no impact on the quality
>>  of seeding.
>> -- snap --
>>
>> It appears that the latest version of prngd for sunos is 0.9.25 up
>> through solaris 9.
>>
>> The sourceforge for prngd (http://sourceforge.net/projects/prngd/) is
>> alive but does not appear to be active. I'm going to contact them, has
>> anybody else found a eliable solution or a newer version of prngd for
>> sunos 5.8 that does not have this issue.
>>
>> We have not received any response from the prngd group on sourceforge.
>>
>> Thank you in advance for any/all help,
>> David
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>

-- 

David Beecher, Executive Vice President and Chief Technical Officer
Digital Messaging Solutions, Inc.
678.446.3050 voice   866.881.7081 fax
http://www.dmsgs.com
We appreciate your business!

This e-mail may contain data that is confidential, proprietary or
"non-public personal information," as that term is defined in the
Gramm-Leach-Bliley Act (collectively, "Confidential Information"). The
Confidential Information is disclosed conditioned upon your agreement that
you will treat it confidentially and in accordance with applicable law,
ensure that such data isn't used or disclosed except for the limited purpose
for which it's being provided and will notify and cooperate with us
regarding any requested or unauthorized disclosure or use of any
Confidential Information. By accepting and reviewing the Confidential
Information you agree to indemnify us against any losses or expenses,
including attorney's fees that we may incur as a result of any unauthorized
use or disclosure of this data due to your acts or omissions. If a party
other than the intended recipient receives this e-mail, you are requested to
instantly notify us of the erroneous delivery and return to us all data so
delivered.



From jmknoble at pobox.com  Sat Jul 12 08:59:08 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Fri, 11 Jul 2008 18:59:08 -0400
Subject: openssh / prngd unresolved bug since 2002, need help
In-Reply-To: <alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org>
References: <4877911D.5050508@dmsgs.com>
	<alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org>
Message-ID: <20080711225908.GH23650@crawfish.ais.com>

Circa 2008-07-11 15:57 dixit Ben Lindstrom:

: If you are on Solaris 9.. You should have a /dev/[u]random and you 
: shouldn't need prngd (or am I thinking Solaris 10?).

Solaris 9 should have /dev/random and /dev/urandom already.  Solaris 8
has patches which provide it.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From rapier at psc.edu  Sat Jul 12 09:54:36 2008
From: rapier at psc.edu (chris rapier)
Date: Fri, 11 Jul 2008 19:54:36 -0400
Subject: Changes in channel_connect_to
In-Reply-To: <alpine.BSO.1.10.0807111740020.24152@fuyu.mindrot.org>
References: <4875311C.5040005@psc.edu>
	<alpine.BSO.1.10.0807111740020.24152@fuyu.mindrot.org>
Message-ID: <4877F2BC.80508@psc.edu>

Damien Miller wrote:

> Most of the changes are in the connect_to(). Much of its logic has 
> been remvoed to connect_next() to support fallback to trying additional
> addresses when the initial connect fails. 
> 
> To support this, connect_to fills in the channel->connect_ctx with
> the addresses of the host that it is trying to connect to. On a
> connect error, channel_post_connecting() can call connect_next() with
> this structure to pick the next address to try rather than just failing.

Thanks for the insight! I noticed that channel_new got moved into 
connect_to. It does make sense for it to be there but man, you just made 
my job more difficult ;)




From dbeecher at dmsgs.com  Sat Jul 12 11:36:08 2008
From: dbeecher at dmsgs.com (David Beecher)
Date: Fri, 11 Jul 2008 19:36:08 -0600 (MDT)
Subject: openssh / prngd unresolved bug since 2002, need help
In-Reply-To: <20080711225908.GH23650@crawfish.ais.com>
References: <4877911D.5050508@dmsgs.com>
	<alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org>
	<20080711225908.GH23650@crawfish.ais.com>
Message-ID: <4101.10.253.10.102.1215826568.squirrel@corp.tekops.com>

Hello Jim,

Thank you very much.  I am aware of the random number generator on sunos
5.9.  Finally they included one.  Unfortunately this install is sunos 5.8
and not easily changeable at this point.

I was not aware that patches for sunos 5.8 existed that would add urandom
and when I saw the package on sunfreeware that used prngd I assumed none
existed and prngd was required.

I will look for them and report back here what I find.

Thanks a lot!
David



Jim Knoble wrote:
> Circa 2008-07-11 15:57 dixit Ben Lindstrom:
>
> : If you are on Solaris 9.. You should have a /dev/[u]random and you
> : shouldn't need prngd (or am I thinking Solaris 10?).
>
> Solaris 9 should have /dev/random and /dev/urandom already.  Solaris 8
> has patches which provide it.
>
> --
> jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
> (GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
> (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
> +----------------------------------------------------------------------+
> |[L]iberty, as we all know, cannot flourish in a country that is perma-|
> | nently on a war footing, or even a near-war footing.  --Aldous Huxley|
> +----------------------------------------------------------------------+
>


-- 
David Beecher, Executive Vice President and Chief Technical Officer
Digital Messaging Solutions, Inc.
678-446-3050 voice
http://www.dmsgs.com

This e-mail may contain data that is confidential, proprietary or "non-public
personal information," as that term is defined in the Gramm-Leach-Bliley Act
(collectively, "Confidential Information"). The Confidential Information is
disclosed conditioned upon your agreement that you will treat it
confidentially and in accordance with applicable law, ensure that such data
isn't used or disclosed except for the limited purpose for which it's being
provided and will notify and cooperate with us regarding any requested or
unauthorized disclosure or use of any Confidential Information. By accepting
and reviewing the Confidential Information you agree to indemnify us against
any losses or expenses, including attorney's fees that we may incur as a
result of any unauthorized use or disclosure of this data due to your acts or
omissions. If a party other than the intended recipient receives this e-mail,
you are requested to instantly notify us of the erroneous delivery and return
to us all data so delivered.

From wknox at mitre.org  Sat Jul 12 13:15:44 2008
From: wknox at mitre.org (Knox, Bill)
Date: Fri, 11 Jul 2008 23:15:44 -0400
Subject: openssh / prngd unresolved bug since 2002, need help
In-Reply-To: <4101.10.253.10.102.1215826568.squirrel@corp.tekops.com>
References: <4877911D.5050508@dmsgs.com><alpine.BSO.1.00.0807111451520.30973@miyako.eviladmin.org><20080711225908.GH23650@crawfish.ais.com>
	<4101.10.253.10.102.1215826568.squirrel@corp.tekops.com>
Message-ID: <3B660B4ACB06BE488E3938F95115E4DE027C77B9@IMCSRV4.MITRE.ORG>

The Solaris 8 patch is 112438 - I don't know what rev it is up to at
this point. The patch says it requires a reboot, but I came across the
following instructions years ago to do it without a reboot (sorry, no
attribution available - some person brighter than me):

In order to add patch 112438 to the systems without requiring a reboot,
perform the following steps:

# patchadd 112438-*
(The patch addition information should appear)
# rm /reconfigure
# rem_drv random
(Ignore any errors returned)
# add_drv -m '* 0644 root sys' random

Good luck, and sorry everyone else for the somewhat off topic post.

                          Bill Knox
                          Lead Infosec Engineer/Scientist
                          The MITRE Corporation

-----Original Message-----
From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org
[mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf
Of David Beecher
Sent: Friday, July 11, 2008 9:36 PM
To: Ben Lindstrom; David Beecher; openssh-unix-dev at mindrot.org
Subject: Re: openssh / prngd unresolved bug since 2002, need help

Hello Jim,

Thank you very much.  I am aware of the random number generator on
sunos
5.9.  Finally they included one.  Unfortunately this install is sunos
5.8
and not easily changeable at this point.

I was not aware that patches for sunos 5.8 existed that would add
urandom
and when I saw the package on sunfreeware that used prngd I assumed
none
existed and prngd was required.

I will look for them and report back here what I find.

Thanks a lot!
David



Jim Knoble wrote:
> Circa 2008-07-11 15:57 dixit Ben Lindstrom:
>
> : If you are on Solaris 9.. You should have a /dev/[u]random and you
> : shouldn't need prngd (or am I thinking Solaris 10?).
>
> Solaris 9 should have /dev/random and /dev/urandom already.  Solaris
8
> has patches which provide it.
>
> --
> jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
> (GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/
)
> (GnuPG fingerprint:
5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
>
+----------------------------------------------------------------------
+
> |[L]iberty, as we all know, cannot flourish in a country that is
perma-|
> | nently on a war footing, or even a near-war footing.  --Aldous
Huxley|
>
+----------------------------------------------------------------------
+
>


-- 
David Beecher, Executive Vice President and Chief Technical Officer
Digital Messaging Solutions, Inc.
678-446-3050 voice
http://www.dmsgs.com

This e-mail may contain data that is confidential, proprietary or
"non-public
personal information," as that term is defined in the
Gramm-Leach-Bliley Act
(collectively, "Confidential Information"). The Confidential
Information is
disclosed conditioned upon your agreement that you will treat it
confidentially and in accordance with applicable law, ensure that such
data
isn't used or disclosed except for the limited purpose for which it's
being
provided and will notify and cooperate with us regarding any requested
or
unauthorized disclosure or use of any Confidential Information. By
accepting
and reviewing the Confidential Information you agree to indemnify us
against
any losses or expenses, including attorney's fees that we may incur as
a
result of any unauthorized use or disclosure of this data due to your
acts or
omissions. If a party other than the intended recipient receives this
e-mail,
you are requested to instantly notify us of the erroneous delivery and
return
to us all data so delivered.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From djm at mindrot.org  Sat Jul 12 17:02:56 2008
From: djm at mindrot.org (Damien Miller)
Date: Sat, 12 Jul 2008 17:02:56 +1000 (EST)
Subject: [PATCH] contrib/cygwin/ssh-{host,user}-config
In-Reply-To: <20080711080245.GM24644@calimero.vinschen.de>
References: <20080711080245.GM24644@calimero.vinschen.de>
Message-ID: <alpine.BSO.1.10.0807121702080.16462@fuyu.mindrot.org>

On Fri, 11 Jul 2008, Corinna Vinschen wrote:

> Hi,
> 
> attached a total revamp of the ssh-host-config and ssh-user-config
> scripts.  The underlying idea is that one of our maintainers has
> contributed a unified configuration script environment for Cygwin,
> called csih.  This is now used by the below ssh config scripts as well.
> There's also an additional file called sshd-inetd, which is a service
> configuration file for inetutils.  The Makefile had to be changed
> accordingly.
> 
> Could somebody please check this in?
> 
> And, is is possible to get this change into 5.1p1?

Does this require a specific version of the cygwin tools or DLL? If so
we may want to document it, or explicitly test for it in configure.ac.

What do you think?

-d

From vinschen at redhat.com  Sat Jul 12 21:17:55 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sat, 12 Jul 2008 13:17:55 +0200
Subject: [PATCH] contrib/cygwin/ssh-{host,user}-config
In-Reply-To: <alpine.BSO.1.10.0807121702080.16462@fuyu.mindrot.org>
References: <20080711080245.GM24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807121702080.16462@fuyu.mindrot.org>
Message-ID: <20080712111755.GV24644@calimero.vinschen.de>

On Jul 12 17:02, Damien Miller wrote:
> On Fri, 11 Jul 2008, Corinna Vinschen wrote:
> 
> > Hi,
> > 
> > attached a total revamp of the ssh-host-config and ssh-user-config
> > scripts.  The underlying idea is that one of our maintainers has
> > contributed a unified configuration script environment for Cygwin,
> > called csih.  This is now used by the below ssh config scripts as well.
> > There's also an additional file called sshd-inetd, which is a service
> > configuration file for inetutils.  The Makefile had to be changed
> > accordingly.
> > 
> > Could somebody please check this in?
> > 
> > And, is is possible to get this change into 5.1p1?
> 
> Does this require a specific version of the cygwin tools or DLL? If so
> we may want to document it, or explicitly test for it in configure.ac.

It does not require a specific version of the Cygwin DLL and it does not
require any more tools than before, except for the addition dependency
of the csih package.  However, the csih package is now part of the Cygwin
distro base install.  Additionally, csih will be added to the OpenSSH
package dependencies in the Cygwin distro.  From the user perspective,
the change is rather gentle.

The big advantage of this new solution is that most of the really sticky
Windows stuff is now externalized into the csih packages.  This doesn't
only positively affect OpenSSH but evey other package which requires
Windows-specific configuration (creating a Windows user account with
special privileges, installing as a Windows service, etc.)
If changes are necessary, they will in future not so much affect the
OpenSSH package, but rather the csih package (apart from potential
script bugs, of course).

I don't see any need to document something or to do additional tests in
configure.

Oh, btw., here's a somewhat off-topic question:  The next major release
of Cygwin will drop Windows 95/98/Me support, it won't even run on 9x
anymore.  Shall we rip out 9x support from the cygwin-specific code in
OpenSSH as well, as soon as Cygwin 1.7 is officially released (hopefully
this year)?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From g.chulkov at jacobs-university.de  Sat Jul 12 21:54:55 2008
From: g.chulkov at jacobs-university.de (Georgi Chulkov)
Date: Sat, 12 Jul 2008 14:54:55 +0300
Subject: Race condition in sshd
In-Reply-To: <200807111200.38048.g.chulkov@jacobs-university.de>
References: <200807110220.44542.g.chulkov@jacobs-university.de>
	<alpine.BSO.1.10.0807110952380.19199@fuyu.mindrot.org>
	<200807111200.38048.g.chulkov@jacobs-university.de>
Message-ID: <200807121455.02752.g.chulkov@jacobs-university.de>

On Friday 11 July 2008 12:00:34 Georgi Chulkov wrote:
> On Friday 11 July 2008 02:55:44 Damien Miller wrote:
> > On Fri, 11 Jul 2008, Georgi Chulkov wrote:
> > > Hello,
> > >
> > > This bug exists in 5.0p1. I apologize that I couldn't test against
> > > HEAD.
> > >
> > > I _believe_ I have found a race condition in sshd. In the v2 protocol,
> > > after a connection, the accepting process forks in privsep_preauth().
> > > The parent executes monitor_child_preauth() to allow certain privsep
> > > requests necessary for authentication. The unprivileged child runs
> > > do_ssh2_kex() followed by do_authentication2().
> > >
> > > I am working on a new KEX algorithm whose primary feature is
> > > performance. It is fast enough that do_authentication2() runs
> > > _before_ the monitor has a chance to permit the necessary requests
> > > (MONITOR_REQ_PWNAM in particular), and therefore authentication fails
> > > on the server with:
> > >
> > > monitor_read: unpermitted request 6
> > >
> > > Could someone more experienced please look at this?
> >
> > It looks like there is a race there, but it would be nearly impossible
> > to hit with our current KEX methods. File a bug at
> > http://bugzilla.mindrot.org so it doesn't get lost.
> >
> > You can fix the race by setting up a pipe shared between the monitor and
> > child, and making the child wait until the monitor end closes, which
> > it should do after permitting the monitor calls.
>
> I put the pipe close call at the end of monitor.c:mm_answer_sign(), right
> after the permission for MONITOR_REQ_PWNAM is set to true. But I can't
> figure out where exactly to put the blocking pipe read call. Everything I
> tried is either too early (->authentication doesn't get far enough to
> permit MONITOR_REQ_PWNAM) or too late (->unpermitted request).

This is now in Bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=1487
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080712/b816c29d/attachment.bin 

From djm at mindrot.org  Mon Jul 14 08:16:55 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 14 Jul 2008 08:16:55 +1000 (EST)
Subject: sftp pipelined requests was: Re: Clear-Text Patch? was: Re: OpenSSH
	5.1: call for testing
In-Reply-To: <4875236E.5020006@psc.edu>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
Message-ID: <alpine.BSO.1.10.0807140816060.7114@fuyu.mindrot.org>

On Wed, 9 Jul 2008, rapier wrote:

> The main question I have is if they've increase the number of 
> outstanding requests in SFTP to match the increased receive window size 
> introduced in 4.7.

It has now:

 /* Number of concurrent outstanding requests */
-size_t num_requests = 16;
+size_t num_requests = 64;


-d

From djm at mindrot.org  Mon Jul 14 11:59:07 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 14 Jul 2008 11:59:07 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080708144105.GA6726@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
Message-ID: <alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>

On Tue, 8 Jul 2008, Corinna Vinschen wrote:

> On Jul  9 00:18, Damien Miller wrote:
> > On Mon, 7 Jul 2008, Corinna Vinschen wrote:
> > 
> > > Other than that:
> > > 
> > > - session.c, line 427:
> > > 
> > >     #define USE_PIPES
> > > 
> > >   Is that planned or just left over fomr some test?
> > 
> > No, that is planned. We now unconditionally use pipes for communicating
> > with the session subprocesses because they seem to give better semantics
> > for half-closed channels (cf. https://bugzilla.mindrot.org/b/85).
> 
> Ok.  Given that USE_PIPES is now only used in sftp.c, wouldn't it 
> be easier now to always use pipes, even in sftp.c?  That would drop
> the whole test and a bunch of conditional code.

USE_PIPES wastes an extra file descriptor where it isn't needed, so
we still prefer sockets where possible.

> > I'm not sure of a good way to determine at runtime whether IPv6 is
> > available on a platform. Perhaps these tests should be disabled in
> > portable or made non-fatal.
> 
> Ack.  Unfortunately `ssh -6' falls silently back to IPv4 instead of
> complaining on platforms not supporting IPv6.  Complaining would allow
> to use this as a test.

It shouldn't!

[djm at fuyu ssh]$ ssh -6 anoncvs.mindrot.org
ssh: Could not resolve hostname anoncvs.mindrot.org: no address associated with name
[djm at fuyu ssh]$ echo $?
255

(verified on OpenBSD and Linux)

-d

From djm at mindrot.org  Mon Jul 14 12:07:48 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 14 Jul 2008 12:07:48 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <0807081546470.18603@somehost>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
Message-ID: <alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>

On Tue, 8 Jul 2008, Cristian Ionescu-Idbohrn wrote:

Thanks for the detailed report!

> Warnings:
> 
> xmalloc.h:26: warning: `__nonnull__' attribute directive ignored

We'll have to ignore this, it is harmless though.

> bindresvport.c: In function `bindresvport_sa':
> bindresvport.c:57: warning: declaration of `sin' shadows a global declaration
> <built-in>:0: warning: shadowed declaration is here

Fixed.

> rresvport.c: In function `rresvport_af':
> rresvport.c:92: warning: implicit declaration of function `close'

Fixed.

> umac.c:187: warning: declaration of `buffer_ptr' shadows a global declaration
> buffer.h:31: warning: shadowed declaration is here

Fixed.

> auth.c: In function `auth_openkeyfile':
> auth.c:489: warning: implicit declaration of function `close'

Fixed.

> I also get this warning from the linker:
> 
> /usr/local/cris/r64/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/../../../../cris-axis-linux-gnu/bin/ld: warning: type and size of dynamic symbol `AES_encrypt' are not defined
> 
> which goes away if I build with:
> 
>   CFLAGS += -DUSE_BUILTIN_RIJNDAEL

That shouldn't be necessary unless you are using quite an old OpenSSL.
Is this the case?

-d

From djm at mindrot.org  Mon Jul 14 12:13:16 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 14 Jul 2008 12:13:16 +1000 (EST)
Subject: [PATCH] contrib/cygwin/ssh-{host,user}-config
In-Reply-To: <20080711080245.GM24644@calimero.vinschen.de>
References: <20080711080245.GM24644@calimero.vinschen.de>
Message-ID: <alpine.BSO.1.10.0807141212570.16462@fuyu.mindrot.org>

On Fri, 11 Jul 2008, Corinna Vinschen wrote:

> Hi,
> 
> attached a total revamp of the ssh-host-config and ssh-user-config
> scripts.  The underlying idea is that one of our maintainers has
> contributed a unified configuration script environment for Cygwin,
> called csih.  This is now used by the below ssh config scripts as well.
> There's also an additional file called sshd-inetd, which is a service
> configuration file for inetutils.  The Makefile had to be changed
> accordingly.
> 
> Could somebody please check this in?

Yes, done

> And, is is possible to get this change into 5.1p1?

Yes, done

-d

From rapier at psc.edu  Mon Jul 14 12:35:34 2008
From: rapier at psc.edu (rapier at psc.edu)
Date: Sun, 13 Jul 2008 22:35:34 -0400
Subject: sftp pipelined requests was: Re: Clear-Text Patch? was: Re:
	OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807140816060.7114@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
	<alpine.BSO.1.10.0807140816060.7114@fuyu.mindrot.org>
Message-ID: <1216002934.487abb767f6e1@webmail.psc.edu>

Quoting Damien Miller <djm at mindrot.org>:

> On Wed, 9 Jul 2008, rapier wrote:
> 
> > The main question I have is if they've increase the number of 
> > outstanding requests in SFTP to match the increased receive window
> size 
> > introduced in 4.7.
> 
> It has now:
> 
>  /* Number of concurrent outstanding requests */
> -size_t num_requests = 16;
> +size_t num_requests = 64;

Rock. :)

From cristian.ionescu-idbohrn at axis.com  Mon Jul 14 18:18:09 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Mon, 14 Jul 2008 10:18:09 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
Message-ID: <0807141007340.18603@somehost>

Thanks for those fixes.

On Mon, 14 Jul 2008, Damien Miller wrote:

> > I also get this warning from the linker:
> >
> > /usr/local/cris/r64/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/../../../../cris-axis-linux-gnu/bin/ld: warning: type and size of dynamic symbol `AES_encrypt' are not defined
> >
> > which goes away if I build with:
> >
> >   CFLAGS += -DUSE_BUILTIN_RIJNDAEL
>
> That shouldn't be necessary unless you are using quite an old OpenSSL.
> Is this the case?

Is 0.9.7m too old?


Cheers,

-- 
Cristian

From djm at mindrot.org  Mon Jul 14 19:32:41 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 14 Jul 2008 19:32:41 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <0807141007340.18603@somehost>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
	<0807141007340.18603@somehost>
Message-ID: <alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>

On Mon, 14 Jul 2008, Cristian Ionescu-Idbohrn wrote:

> > >   CFLAGS += -DUSE_BUILTIN_RIJNDAEL
> >
> > That shouldn't be necessary unless you are using quite an old OpenSSL.
> > Is this the case?
> 
> Is 0.9.7m too old?

Not at all - I think AES has been in OpenSSL since 0.9.5 or 0.9.6,
unless it has been disabled at build time.

Does the linked ssh/sshd link OK and pass the regress tests?

-d

From vinschen at redhat.com  Mon Jul 14 20:04:41 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 14 Jul 2008 12:04:41 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
Message-ID: <20080714100441.GA28868@calimero.vinschen.de>

On Jul 14 11:59, Damien Miller wrote:
> On Tue, 8 Jul 2008, Corinna Vinschen wrote:
> > On Jul  9 00:18, Damien Miller wrote:
> > > I'm not sure of a good way to determine at runtime whether IPv6 is
> > > available on a platform. Perhaps these tests should be disabled in
> > > portable or made non-fatal.
> > 
> > Ack.  Unfortunately `ssh -6' falls silently back to IPv4 instead of
> > complaining on platforms not supporting IPv6.  Complaining would allow
> > to use this as a test.
> 
> It shouldn't!
> 
> [djm at fuyu ssh]$ ssh -6 anoncvs.mindrot.org
> ssh: Could not resolve hostname anoncvs.mindrot.org: no address associated with name
> [djm at fuyu ssh]$ echo $?
> 255
> 
> (verified on OpenBSD and Linux)

Your example is not what I had in mind.

In your scenario ssh is running on an OS which supports IPv6, but the
target you're trying to connect to has no IPv6 address.

I'm talking about running ssh on a system which doesn't support IPv6 at
all and which doesn't even know the newer system calls getaddrinfo,
getnameinfo, freeaddrinfo, like the older Cygwin releases.  The main
difference to your scenario is that ssh uses the getaddrinfo implementation
in openbsd-compat/fake-rfc2553.c.

And here's the problem.  getaddrinfo in fake-rfc2553.c does not check
for the requested address family.  Actually it should only allow
hints->ai_family == AF_UNSPEC or == AF_INET, and it should return with
EAI_FAMILY if hints->ai_family is anything else.  Since it doesn't, `ssh
-6 foo' will happily use AF_INET and just work.

Below you'll find a patch which fixes that problem in fake-rfc2553.c.
Tested on Cygwin 1.5.25.

Before:

  cygwin$ ssh -6 foo
  [...]
  foo$ echo $SSH_CONNECTION
  192.168.129.14 1217 192.168.129.6 22

With the patch:

  cygwin$ ssh foo
  [...]
  foo$ echo $SSH_CONNECTION
  192.168.129.14 1217 192.168.129.6 22
  
  cygwin$ ssh -4 foo
  [...]
  foo$ echo $SSH_CONNECTION
  192.168.129.14 1217 192.168.129.6 22

  cygwin$ ssh -6 foo
  ssh: Could not resolve hostname calimero: ai_family not supported


Corinna


Index: openbsd-compat/fake-rfc2553.h
===================================================================
RCS file: /cvs/openssh/openbsd-compat/fake-rfc2553.h,v
retrieving revision 1.15
diff -u -p -r1.15 fake-rfc2553.h
--- openbsd-compat/fake-rfc2553.h	10 Jun 2008 13:52:51 -0000	1.15
+++ openbsd-compat/fake-rfc2553.h	14 Jul 2008 10:00:38 -0000
@@ -129,6 +129,9 @@ struct sockaddr_in6 {
 #ifndef EAI_SYSTEM
 # define EAI_SYSTEM	(INT_MAX - 4)
 #endif
+#ifndef EAI_FAMILY
+# define EAI_FAMILY	(INT_MAX - 5)
+#endif
 
 #ifndef HAVE_STRUCT_ADDRINFO
 struct addrinfo {
Index: openbsd-compat/fake-rfc2553.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/fake-rfc2553.c,v
retrieving revision 1.9
diff -u -p -r1.9 fake-rfc2553.c
--- openbsd-compat/fake-rfc2553.c	17 Aug 2006 08:55:28 -0000	1.9
+++ openbsd-compat/fake-rfc2553.c	14 Jul 2008 10:00:38 -0000
@@ -51,6 +51,8 @@ int getnameinfo(const struct sockaddr *s
 	struct hostent *hp;
 	char tmpserv[16];
 
+	if (sa->sa_family != AF_UNSPEC && sa->sa_family != AF_INET)
+		return (EAI_FAMILY);
 	if (serv != NULL) {
 		snprintf(tmpserv, sizeof(tmpserv), "%d", ntohs(sin->sin_port));
 		if (strlcpy(serv, tmpserv, servlen) >= servlen)
@@ -95,6 +97,8 @@ gai_strerror(int err)
 		return ("memory allocation failure.");
 	case EAI_NONAME:
 		return ("nodename nor servname provided, or not known");
+	case EAI_FAMILY:
+		return ("ai_family not supported");
 	default:
 		return ("unknown/invalid error.");
 	}
@@ -159,6 +163,9 @@ getaddrinfo(const char *hostname, const 
 	u_long addr;
 
 	port = 0;
+	if (hints && hints->ai_family != AF_UNSPEC &&
+	    hints->ai_family != AF_INET)
+		return (EAI_FAMILY);
 	if (servname != NULL) {
 		char *cp;
 

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From djm at mindrot.org  Mon Jul 14 21:38:40 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 14 Jul 2008 21:38:40 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080714100441.GA28868@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
Message-ID: <alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>

On Mon, 14 Jul 2008, Corinna Vinschen wrote:

> Your example is not what I had in mind.
> 
> In your scenario ssh is running on an OS which supports IPv6, but the
> target you're trying to connect to has no IPv6 address.

Yes, I forgot about the fallback code. Doesn't cygwin provide its
own getaddrinfo? I though winsock did...

> Below you'll find a patch which fixes that problem in fake-rfc2553.c.
> Tested on Cygwin 1.5.25.

Applied - thanks.

-d

From vinschen at redhat.com  Mon Jul 14 22:10:58 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 14 Jul 2008 14:10:58 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
Message-ID: <20080714121058.GB31215@calimero.vinschen.de>

On Jul 14 21:38, Damien Miller wrote:
> On Mon, 14 Jul 2008, Corinna Vinschen wrote:
> 
> > Your example is not what I had in mind.
> > 
> > In your scenario ssh is running on an OS which supports IPv6, but the
> > target you're trying to connect to has no IPv6 address.
> 
> Yes, I forgot about the fallback code. Doesn't cygwin provide its
> own getaddrinfo? I though winsock did...

Not in the still current 1.5.25.  The next major release 1.7 provides
fallback code for systems not supporting them (pre-XP).  That code
also checks for an AF_INET6 request and refuses it with EAI_FAMILY.
Hopefully the WinSock call starting with XP will do the same if the
IPv6 stack isn't activated.  Actually I never tried :}

> > Below you'll find a patch which fixes that problem in fake-rfc2553.c.
> > Tested on Cygwin 1.5.25.
> 
> Applied - thanks.

Thanks to you,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From cristian.ionescu-idbohrn at axis.com  Mon Jul 14 23:34:52 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Mon, 14 Jul 2008 15:34:52 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
	<0807141007340.18603@somehost>
	<alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>
Message-ID: <0807141138440.18603@somehost>

On Mon, 14 Jul 2008, Damien Miller wrote:

> On Mon, 14 Jul 2008, Cristian Ionescu-Idbohrn wrote:
>
> > > >   CFLAGS += -DUSE_BUILTIN_RIJNDAEL
> > >
> > > That shouldn't be necessary unless you are using quite an old OpenSSL.
> > > Is this the case?
> >
> > Is 0.9.7m too old?
>
> Not at all - I think AES has been in OpenSSL since 0.9.5 or 0.9.6,
> unless it has been disabled at build time.

Ok.

> Does the linked ssh/sshd link OK and pass the regress tests?

Any easy way to do that?

I'm cross building.
I build just some of the build targets.
Target system lacks development tools.


Cheers,

-- 
Cristian

From stanislaw.kaminski at gmail.com  Tue Jul 15 00:26:47 2008
From: stanislaw.kaminski at gmail.com (Stanislaw Kaminski)
Date: Mon, 14 Jul 2008 16:26:47 +0200
Subject: EOL in stderr of ssh - Linux
Message-ID: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>

Hello everyone,
recently I've found something I consider a bug.

Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
Imagine my surprise when I saw that all messages that are being output
on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
terminated with 0x0D, 0x0A.

Maybe that's standard behaviour of all stderr messages in all Linux
software, but I have to admin it's the first time I saw something like
this.

So, can anybody tell me if it's for a purpose, or is it just a plain bug?

yours sincerely,
Stanislaw Kaminski

From stuge-openssh-unix-dev at cdy.org  Tue Jul 15 01:31:16 2008
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Mon, 14 Jul 2008 17:31:16 +0200
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
References: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
Message-ID: <20080714153116.5191.qmail@cdy.org>

On Mon, Jul 14, 2008 at 04:26:47PM +0200, Stanislaw Kaminski wrote:
> Imagine my surprise when I saw that all messages that are being output
> on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
> terminated with 0x0D, 0x0A.

How are you testing this?


> So, can anybody tell me if it's for a purpose, or is it just a plain bug?

I doubt ssh has \r\n in any source files.


//Peter

From wknox at mitre.org  Tue Jul 15 02:06:24 2008
From: wknox at mitre.org (Knox, Bill)
Date: Mon, 14 Jul 2008 12:06:24 -0400
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
References: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
Message-ID: <3B660B4ACB06BE488E3938F95115E4DE027C787B@IMCSRV4.MITRE.ORG>

Not on my Fedora Core 7 or my CentOS 5.2 box - both of them terminate
with just 0x0A, as is shown below:

ssh -v 2>&1 | xxd
0000000: 4f70 656e 5353 485f 342e 3370 322c 204f  OpenSSH_4.3p2, O
0000010: 7065 6e53 534c 2030 2e39 2e38 6220 3034  penSSL 0.9.8b 04
0000020: 204d 6179 2032 3030 360a 7573 6167 653a   May 2006.usage:
0000030: 2073 7368 205b 2d31 3234 3641 6143 6667   ssh [-1246AaCfg
0000040: 6b4d 4e6e 7173 5474 5676 5878 595d 205b  kMNnqsTtVvXxY] [
0000050: 2d62 2062 696e 645f 6164 6472 6573 735d  -b bind_address]
0000060: 205b 2d63 2063 6970 6865 725f 7370 6563   [-c cipher_spec
0000070: 5d0a 2020 2020 2020 2020 2020 205b 2d44  ].           [-D
0000080: 205b 6269 6e64 5f61 6464 7265 7373 3a5d   [bind_address:]
0000090: 706f 7274 5d20 5b2d 6520 6573 6361 7065  port] [-e escape
00000a0: 5f63 6861 725d 205b 2d46 2063 6f6e 6669  _char] [-F confi
00000b0: 6766 696c 655d 0a20 2020 2020 2020 2020  gfile].
00000c0: 2020 5b2d 6920 6964 656e 7469 7479 5f66    [-i identity_f
00000d0: 696c 655d 205b 2d4c 205b 6269 6e64 5f61  ile] [-L [bind_a
00000e0: 6464 7265 7373 3a5d 706f 7274 3a68 6f73  ddress:]port:hos
00000f0: 743a 686f 7374 706f 7274 5d0a 2020 2020  t:hostport].
0000100: 2020 2020 2020 205b 2d6c 206c 6f67 696e         [-l login
0000110: 5f6e 616d 655d 205b 2d6d 206d 6163 5f73  _name] [-m mac_s
0000120: 7065 635d 205b 2d4f 2063 746c 5f63 6d64  pec] [-O ctl_cmd
0000130: 5d20 5b2d 6f20 6f70 7469 6f6e 5d20 5b2d  ] [-o option] [-
0000140: 7020 706f 7274 5d0a 2020 2020 2020 2020  p port].
0000150: 2020 205b 2d52 205b 6269 6e64 5f61 6464     [-R [bind_add
0000160: 7265 7373 3a5d 706f 7274 3a68 6f73 743a  ress:]port:host:
0000170: 686f 7374 706f 7274 5d20 5b2d 5320 6374  hostport] [-S ct
0000180: 6c5f 7061 7468 5d0a 2020 2020 2020 2020  l_path].
0000190: 2020 205b 2d77 2074 756e 6e65 6c3a 7475     [-w tunnel:tu
00001a0: 6e6e 656c 5d20 5b75 7365 7240 5d68 6f73  nnel] [user@]hos
00001b0: 746e 616d 6520 5b63 6f6d 6d61 6e64 5d0a  tname [command].

                          Bill Knox
                          Lead Infosec Engineer/Scientist
                          The MITRE Corporation


-----Original Message-----
From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org
[mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf
Of Stanislaw Kaminski
Sent: Monday, July 14, 2008 10:27 AM
To: openssh-unix-dev at mindrot.org
Subject: EOL in stderr of ssh - Linux

Hello everyone,
recently I've found something I consider a bug.

Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
Imagine my surprise when I saw that all messages that are being output
on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
terminated with 0x0D, 0x0A.

Maybe that's standard behaviour of all stderr messages in all Linux
software, but I have to admin it's the first time I saw something like
this.

So, can anybody tell me if it's for a purpose, or is it just a plain
bug?

yours sincerely,
Stanislaw Kaminski
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From bob at proulx.com  Tue Jul 15 07:19:26 2008
From: bob at proulx.com (Bob Proulx)
Date: Mon, 14 Jul 2008 15:19:26 -0600
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
References: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
Message-ID: <20080714211926.GA875@dementia.proulx.com>

Stanislaw Kaminski wrote:
> Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
> Imagine my surprise when I saw that all messages that are being output
> on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
> terminated with 0x0D, 0x0A.

What are your tty settings?  What is the output of this command?

  stty -a

What is the output of this command?

  echo ABC | od -tx1

Bob

From vinschen at redhat.com  Tue Jul 15 07:20:58 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 14 Jul 2008 23:20:58 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080714121058.GB31215@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
	<20080714121058.GB31215@calimero.vinschen.de>
Message-ID: <20080714212058.GH24644@calimero.vinschen.de>

On Jul 14 14:10, Corinna Vinschen wrote:
> On Jul 14 21:38, Damien Miller wrote:
> > > Below you'll find a patch which fixes that problem in fake-rfc2553.c.
> > > Tested on Cygwin 1.5.25.
> > 
> > Applied - thanks.

Below is another patch which simplifies the test for POSIX file security
in Cygwin.  The functionality implemented in check_ntsec() is already
present in the Cygwin DLL for about seven years and accessible through
pathconf(3).  In fact, in Cygwin 1.7, this will be the *only* valid
interface to check for POSIX file security, since the global
"CYGWIN=ntsec" environment option will be dropped in favor of a
per-mount option.

Another question is this:  The has_capability function requests Cygwin
version information to figure out if specific features are available.
The newest of the requested capabilities exists since Cygwin 1.5.0,
which has been release in 2003, five years ago.  Older versions of
Cygwin are long out of support.  That's why I would like to ask, if it
isn't time to drop the whole has_capability() function as well as the
check_nt_auth() function and to remove calling this Cygwin-specific
function throughout OpenSSH.  Right now it's called in auth1.c,
auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
That's a lot of #ifdef HAVE_CYGWIN which could go away :)


Corinna


Index: openbsd-compat/bsd-cygwin_util.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v
retrieving revision 1.19
diff -u -p -r1.19 bsd-cygwin_util.c
--- openbsd-compat/bsd-cygwin_util.c	1 Sep 2006 09:29:01 -0000	1.19
+++ openbsd-compat/bsd-cygwin_util.c	14 Jul 2008 21:01:36 -0000
@@ -175,45 +175,7 @@ check_nt_auth(int pwd_authenticated, str
 int
 check_ntsec(const char *filename)
 {
-	char *cygwin;
-	int allow_ntea = 0, allow_ntsec = 0;
-	struct statfs fsstat;
-
-	/* Windows 95/98/ME don't support file system security at all. */
-	if (!is_winnt)
-		return (0);
-
-	/* Evaluate current CYGWIN settings. */
-	cygwin = getenv("CYGWIN");
-	allow_ntea = ntea_on(cygwin);
-	allow_ntsec = ntsec_on(cygwin) ||
-	    (has_capability(HAS_NTSEC_BY_DEFAULT) && !ntsec_off(cygwin));
-
-	/*
-	 * `ntea' is an emulation of POSIX attributes. It doesn't support
-	 * real file level security as ntsec on NTFS file systems does
-	 * but it supports FAT filesystems. `ntea' is minimum requirement
-	 * for security checks.
-	 */
-	if (allow_ntea)
-		return (1);
-
-	/*
-	 * Retrieve file system flags. In Cygwin, file system flags are
-	 * copied to f_type which has no meaning in Win32 itself.
-	 */
-	if (statfs(filename, &fsstat))
-		return (1);
-
-	/*
-	 * Only file systems supporting ACLs are able to set permissions.
-	 * `ntsec' is the setting in Cygwin which switches using of NTFS
-	 * ACLs to support POSIX permissions on files.
-	 */
-	if (fsstat.f_type & FS_PERSISTENT_ACLS)
-		return (allow_ntsec);
-
-	return (0);
+	return (pathconf(filename, _PC_POSIX_PERMISSIONS));
 }
 
 void

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From Iain.Morgan at nasa.gov  Tue Jul 15 06:53:52 2008
From: Iain.Morgan at nasa.gov (Iain Morgan)
Date: Mon, 14 Jul 2008 13:53:52 -0700
Subject: sftp pipelined requests was: Re: Clear-Text Patch? was: Re:
	OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807140816060.7114@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
	<alpine.BSO.1.10.0807140816060.7114@fuyu.mindrot.org>
Message-ID: <20080714205352.GA5733@linux55.nas.nasa.gov>

On Mon, Jul 14, 2008 at 08:16:55 +1000, Damien Miller wrote:
> On Wed, 9 Jul 2008, rapier wrote:
> 
> > The main question I have is if they've increase the number of 
> > outstanding requests in SFTP to match the increased receive window size 
> > introduced in 4.7.
> 
> It has now:
> 
>  /* Number of concurrent outstanding requests */
> -size_t num_requests = 16;
> +size_t num_requests = 64;
> 
> 
> -d

Don't forget to update sftp(1). :-)

-- 
Iain Morgan

From djm at mindrot.org  Tue Jul 15 12:23:20 2008
From: djm at mindrot.org (Damien Miller)
Date: Tue, 15 Jul 2008 12:23:20 +1000 (EST)
Subject: sftp pipelined requests was: Re: Clear-Text Patch? was: Re:
	OpenSSH 5.1: call for testing
In-Reply-To: <20080714205352.GA5733@linux55.nas.nasa.gov>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
	<alpine.BSO.1.10.0807140816060.7114@fuyu.mindrot.org>
	<20080714205352.GA5733@linux55.nas.nasa.gov>
Message-ID: <alpine.BSO.1.10.0807151223160.14657@fuyu.mindrot.org>

oops, fixed

On Mon, 14 Jul 2008, Iain Morgan wrote:

> On Mon, Jul 14, 2008 at 08:16:55 +1000, Damien Miller wrote:
> > On Wed, 9 Jul 2008, rapier wrote:
> > 
> > > The main question I have is if they've increase the number of 
> > > outstanding requests in SFTP to match the increased receive window size 
> > > introduced in 4.7.
> > 
> > It has now:
> > 
> >  /* Number of concurrent outstanding requests */
> > -size_t num_requests = 16;
> > +size_t num_requests = 64;
> > 
> > 
> > -d
> 
> Don't forget to update sftp(1). :-)
> 
> -- 
> Iain Morgan
> 

From djm at mindrot.org  Tue Jul 15 12:31:10 2008
From: djm at mindrot.org (Damien Miller)
Date: Tue, 15 Jul 2008 12:31:10 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <0807141138440.18603@somehost>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
	<0807141007340.18603@somehost>
	<alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>
	<0807141138440.18603@somehost>
Message-ID: <alpine.BSO.1.10.0807151230220.14657@fuyu.mindrot.org>

On Mon, 14 Jul 2008, Cristian Ionescu-Idbohrn wrote:

> > Does the linked ssh/sshd link OK and pass the regress tests?
> 
> Any easy way to do that?
> 
> I'm cross building.
> I build just some of the build targets.
> Target system lacks development tools.

You would need at least "make" on the target, but you should be able
to copy over the build directory and run "make tests".

-d

From stanislaw.kaminski at gmail.com  Tue Jul 15 20:27:01 2008
From: stanislaw.kaminski at gmail.com (Stanislaw Kaminski)
Date: Tue, 15 Jul 2008 12:27:01 +0200
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <3B660B4ACB06BE488E3938F95115E4DE027C787B@IMCSRV4.MITRE.ORG>
References: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
	<3B660B4ACB06BE488E3938F95115E4DE027C787B@IMCSRV4.MITRE.ORG>
Message-ID: <52bc3fca0807150327m2def27efu85336b5a006bfed3@mail.gmail.com>

Hm, so it seems that this bug does not concern all error outputs.

I've stumbled upon it when connecting to host which had it's ssh key
changed or when it's not known to the client:

ssh -v afs-krw1 2>&1 | xxd
0000000: 4f70 656e 5353 485f 342e 3770 3120 4465  OpenSSH_4.7p1 De
0000010: 6269 616e 2d38 7562 756e 7475 312e 322c  bian-8ubuntu1.2,
0000020: 204f 7065 6e53 534c 2030 2e39 2e38 6720   OpenSSL 0.9.8g
0000030: 3139 204f 6374 2032 3030 370a 6465 6275  19 Oct 2007.debu
0000040: 6731 3a20 5265 6164 696e 6720 636f 6e66  g1: Reading conf
0000050: 6967 7572 6174 696f 6e20 6461 7461 202f  iguration data /
0000060: 6574 632f 7373 682f 7373 685f 636f 6e66  etc/ssh/ssh_conf
0000070: 6967 0d0a 6465 6275 6731 3a20 4170 706c  ig..debug1: Appl
0000080: 7969 6e67 206f 7074 696f 6e73 2066 6f72  ying options for
0000090: 202a 0d0a 6465 6275 6731 3a20 436f 6e6e   *..debug1: Conn
00000a0: 6563 7469 6e67 2074 6f20 6166 732d 6b72  ecting to afs-kr
00000b0: 7731 205b 3137 322e 3137 2e34 302e 3139  w1 [172.17.40.19
00000c0: 355d 2070 6f72 7420 3232 2e0d 0a64 6562  5] port 22...deb
00000d0: 7567 313a 2043 6f6e 6e65 6374 696f 6e20  ug1: Connection
00000e0: 6573 7461 626c 6973 6865 642e 0d0a 6465  established...de
00000f0: 6275 6731 3a20 6964 656e 7469 7479 2066  bug1: identity f
0000100: 696c 6520 2f68 6f6d 652f 7374 6b61 2f2e  ile /home/stka/.
0000110: 7373 682f 6964 656e 7469 7479 2074 7970  ssh/identity typ
0000120: 6520 2d31 0d0a 6465 6275 6731 3a20 6964  e -1..debug1: id
0000130: 656e 7469 7479 2066 696c 6520 2f68 6f6d  entity file /hom
0000140: 652f 7374 6b61 2f2e 7373 682f 6964 5f72  e/stka/.ssh/id_r
0000150: 7361 2074 7970 6520 2d31 0d0a 6465 6275  sa type -1..debu
0000160: 6731 3a20 6964 656e 7469 7479 2066 696c  g1: identity fil
0000170: 6520 2f68 6f6d 652f 7374 6b61 2f2e 7373  e /home/stka/.ss
0000180: 682f 6964 5f64 7361 2074 7970 6520 2d31  h/id_dsa type -1
0000190: 0d0a 6465 6275 6731 3a20 5265 6d6f 7465  ..debug1: Remote
00001a0: 2070 726f 746f 636f 6c20 7665 7273 696f   protocol versio
00001b0: 6e20 322e 302c 2072 656d 6f74 6520 736f  n 2.0, remote so
00001c0: 6674 7761 7265 2076 6572 7369 6f6e 204f  ftware version O
00001d0: 7065 6e53 5348 5f33 2e38 2e31 7031 2044  penSSH_3.8.1p1 D
00001e0: 6562 6961 6e2d 382e 7361 7267 652e 340d  ebian-8.sarge.4.
00001f0: 0a64 6562 7567 313a 206d 6174 6368 3a20  .debug1: match:
0000200: 4f70 656e 5353 485f 332e 382e 3170 3120  OpenSSH_3.8.1p1
0000210: 4465 6269 616e 2d38 2e73 6172 6765 2e34  Debian-8.sarge.4
0000220: 2070 6174 204f 7065 6e53 5348 5f33 2e2a   pat OpenSSH_3.*
0000230: 0d0a 6465 6275 6731 3a20 456e 6162 6c69  ..debug1: Enabli
0000240: 6e67 2063 6f6d 7061 7469 6269 6c69 7479  ng compatibility
0000250: 206d 6f64 6520 666f 7220 7072 6f74 6f63   mode for protoc
0000260: 6f6c 2032 2e30 0d0a 6465 6275 6731 3a20  ol 2.0..debug1:
0000270: 4c6f 6361 6c20 7665 7273 696f 6e20 7374  Local version st
0000280: 7269 6e67 2053 5348 2d32 2e30 2d4f 7065  ring SSH-2.0-Ope
0000290: 6e53 5348 5f34 2e37 7031 2044 6562 6961  nSSH_4.7p1 Debia
00002a0: 6e2d 3875 6275 6e74 7531 2e32 0d0a 6465  n-8ubuntu1.2..de
00002b0: 6275 6731 3a20 5353 4832 5f4d 5347 5f4b  bug1: SSH2_MSG_K
00002c0: 4558 494e 4954 2073 656e 740d 0a64 6562  EXINIT sent..deb
00002d0: 7567 313a 2053 5348 325f 4d53 475f 4b45  ug1: SSH2_MSG_KE
00002e0: 5849 4e49 5420 7265 6365 6976 6564 0d0a  XINIT received..
00002f0: 6465 6275 6731 3a20 6b65 783a 2073 6572  debug1: kex: ser
0000300: 7665 722d 3e63 6c69 656e 7420 6165 7331  ver->client aes1
0000310: 3238 2d63 6263 2068 6d61 632d 6d64 3520  28-cbc hmac-md5
0000320: 6e6f 6e65 0d0a 6465 6275 6731 3a20 6b65  none..debug1: ke
0000330: 783a 2063 6c69 656e 742d 3e73 6572 7665  x: client->serve
0000340: 7220 6165 7331 3238 2d63 6263 2068 6d61  r aes128-cbc hma
0000350: 632d 6d64 3520 6e6f 6e65 0d0a 6465 6275  c-md5 none..debu
0000360: 6731 3a20 5353 4832 5f4d 5347 5f4b 4558  g1: SSH2_MSG_KEX
0000370: 5f44 485f 4745 585f 5245 5155 4553 5428  _DH_GEX_REQUEST(
0000380: 3130 3234 3c31 3032 343c 3831 3932 2920  1024<1024<8192)
0000390: 7365 6e74 0d0a 6465 6275 6731 3a20 6578  sent..debug1: ex
00003a0: 7065 6374 696e 6720 5353 4832 5f4d 5347  pecting SSH2_MSG
00003b0: 5f4b 4558 5f44 485f 4745 585f 4752 4f55  _KEX_DH_GEX_GROU
00003c0: 500d 0a64 6562 7567 313a 2053 5348 325f  P..debug1: SSH2_
00003d0: 4d53 475f 4b45 585f 4448 5f47 4558 5f49  MSG_KEX_DH_GEX_I
00003e0: 4e49 5420 7365 6e74 0d0a 6465 6275 6731  NIT sent..debug1
00003f0: 3a20 6578 7065 6374 696e 6720 5353 4832  : expecting SSH2
0000400: 5f4d 5347 5f4b 4558 5f44 485f 4745 585f  _MSG_KEX_DH_GEX_
The authenticity of host 'afs-krw1 (172.17.40.195)' can't be established.
RSA key fingerprint is 89:ab:bb:88:4c:2a:99:be:00:53:a1:a1:4c:22:82:ba.
Are you sure you want to continue connecting (yes/no)? no
0000410: 5245 504c 590d 0a48 6f73 7420 6b65 7920  REPLY..Host key
0000420: 7665 7269 6669 6361 7469 6f6e 2066 6169  verification fai
0000430: 6c65 642e 0d0a                           led...

As you can see, EOLs are 0d0a.
ssh -v 2>&1 | xxd
0000000: 4f70 656e 5353 485f 342e 3770 3120 4465  OpenSSH_4.7p1 De
0000010: 6269 616e 2d38 7562 756e 7475 312e 322c  bian-8ubuntu1.2,
0000020: 204f 7065 6e53 534c 2030 2e39 2e38 6720   OpenSSL 0.9.8g
0000030: 3139 204f 6374 2032 3030 370a 7573 6167  19 Oct 2007.usag
0000040: 653a 2073 7368 205b 2d31 3234 3641 6143  e: ssh [-1246AaC
0000050: 6667 4b6b 4d4e 6e71 7354 7456 7658 7859  fgKkMNnqsTtVvXxY
0000060: 5d20 5b2d 6220 6269 6e64 5f61 6464 7265  ] [-b bind_addre
0000070: 7373 5d20 5b2d 6320 6369 7068 6572 5f73  ss] [-c cipher_s
0000080: 7065 635d 0a20 2020 2020 2020 2020 2020  pec].
0000090: 5b2d 4420 5b62 696e 645f 6164 6472 6573  [-D [bind_addres
00000a0: 733a 5d70 6f72 745d 205b 2d65 2065 7363  s:]port] [-e esc
00000b0: 6170 655f 6368 6172 5d20 5b2d 4620 636f  ape_char] [-F co
00000c0: 6e66 6967 6669 6c65 5d0a 2020 2020 2020  nfigfile].
00000d0: 2020 2020 205b 2d69 2069 6465 6e74 6974       [-i identit
00000e0: 795f 6669 6c65 5d20 5b2d 4c20 5b62 696e  y_file] [-L [bin
00000f0: 645f 6164 6472 6573 733a 5d70 6f72 743a  d_address:]port:
0000100: 686f 7374 3a68 6f73 7470 6f72 745d 0a20  host:hostport].
0000110: 2020 2020 2020 2020 2020 5b2d 6c20 6c6f            [-l lo
0000120: 6769 6e5f 6e61 6d65 5d20 5b2d 6d20 6d61  gin_name] [-m ma
0000130: 635f 7370 6563 5d20 5b2d 4f20 6374 6c5f  c_spec] [-O ctl_
0000140: 636d 645d 205b 2d6f 206f 7074 696f 6e5d  cmd] [-o option]
0000150: 205b 2d70 2070 6f72 745d 0a20 2020 2020   [-p port].
0000160: 2020 2020 2020 5b2d 5220 5b62 696e 645f        [-R [bind_
0000170: 6164 6472 6573 733a 5d70 6f72 743a 686f  address:]port:ho
0000180: 7374 3a68 6f73 7470 6f72 745d 205b 2d53  st:hostport] [-S
0000190: 2063 746c 5f70 6174 685d 0a20 2020 2020   ctl_path].
00001a0: 2020 2020 2020 5b2d 7720 6c6f 6361 6c5f        [-w local_
00001b0: 7475 6e5b 3a72 656d 6f74 655f 7475 6e5d  tun[:remote_tun]
00001c0: 5d20 5b75 7365 7240 5d68 6f73 746e 616d  ] [user@]hostnam
00001d0: 6520 5b63 6f6d 6d61 6e64 5d0a            e [command].

everything seems correct, and delimiters are just plain Linux 0a.

Try it yourself.

regards,
Stanislaw
but, using your example:



2008/7/14 Knox, Bill <wknox at mitre.org>:
> Not on my Fedora Core 7 or my CentOS 5.2 box - both of them terminate
> with just 0x0A, as is shown below:
>
> ssh -v 2>&1 | xxd
> 0000000: 4f70 656e 5353 485f 342e 3370 322c 204f  OpenSSH_4.3p2, O
> 0000010: 7065 6e53 534c 2030 2e39 2e38 6220 3034  penSSL 0.9.8b 04
> 0000020: 204d 6179 2032 3030 360a 7573 6167 653a   May 2006.usage:
> 0000030: 2073 7368 205b 2d31 3234 3641 6143 6667   ssh [-1246AaCfg
> 0000040: 6b4d 4e6e 7173 5474 5676 5878 595d 205b  kMNnqsTtVvXxY] [
> 0000050: 2d62 2062 696e 645f 6164 6472 6573 735d  -b bind_address]
> 0000060: 205b 2d63 2063 6970 6865 725f 7370 6563   [-c cipher_spec
> 0000070: 5d0a 2020 2020 2020 2020 2020 205b 2d44  ].           [-D
> 0000080: 205b 6269 6e64 5f61 6464 7265 7373 3a5d   [bind_address:]
> 0000090: 706f 7274 5d20 5b2d 6520 6573 6361 7065  port] [-e escape
> 00000a0: 5f63 6861 725d 205b 2d46 2063 6f6e 6669  _char] [-F confi
> 00000b0: 6766 696c 655d 0a20 2020 2020 2020 2020  gfile].
> 00000c0: 2020 5b2d 6920 6964 656e 7469 7479 5f66    [-i identity_f
> 00000d0: 696c 655d 205b 2d4c 205b 6269 6e64 5f61  ile] [-L [bind_a
> 00000e0: 6464 7265 7373 3a5d 706f 7274 3a68 6f73  ddress:]port:hos
> 00000f0: 743a 686f 7374 706f 7274 5d0a 2020 2020  t:hostport].
> 0000100: 2020 2020 2020 205b 2d6c 206c 6f67 696e         [-l login
> 0000110: 5f6e 616d 655d 205b 2d6d 206d 6163 5f73  _name] [-m mac_s
> 0000120: 7065 635d 205b 2d4f 2063 746c 5f63 6d64  pec] [-O ctl_cmd
> 0000130: 5d20 5b2d 6f20 6f70 7469 6f6e 5d20 5b2d  ] [-o option] [-
> 0000140: 7020 706f 7274 5d0a 2020 2020 2020 2020  p port].
> 0000150: 2020 205b 2d52 205b 6269 6e64 5f61 6464     [-R [bind_add
> 0000160: 7265 7373 3a5d 706f 7274 3a68 6f73 743a  ress:]port:host:
> 0000170: 686f 7374 706f 7274 5d20 5b2d 5320 6374  hostport] [-S ct
> 0000180: 6c5f 7061 7468 5d0a 2020 2020 2020 2020  l_path].
> 0000190: 2020 205b 2d77 2074 756e 6e65 6c3a 7475     [-w tunnel:tu
> 00001a0: 6e6e 656c 5d20 5b75 7365 7240 5d68 6f73  nnel] [user@]hos
> 00001b0: 746e 616d 6520 5b63 6f6d 6d61 6e64 5d0a  tname [command].
>
>                          Bill Knox
>                          Lead Infosec Engineer/Scientist
>                          The MITRE Corporation
>
>
> -----Original Message-----
> From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org
> [mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf
> Of Stanislaw Kaminski
> Sent: Monday, July 14, 2008 10:27 AM
> To: openssh-unix-dev at mindrot.org
> Subject: EOL in stderr of ssh - Linux
>
> Hello everyone,
> recently I've found something I consider a bug.
>
> Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
> Imagine my surprise when I saw that all messages that are being output
> on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
> terminated with 0x0D, 0x0A.
>
> Maybe that's standard behaviour of all stderr messages in all Linux
> software, but I have to admin it's the first time I saw something like
> this.
>
> So, can anybody tell me if it's for a purpose, or is it just a plain
> bug?
>
> yours sincerely,
> Stanislaw Kaminski
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From dxh at yahoo.com  Wed Jul 16 00:51:00 2008
From: dxh at yahoo.com (Don Hoover)
Date: Tue, 15 Jul 2008 07:51:00 -0700 (PDT)
Subject: Risk of StrictMode (but read only)
Message-ID: <187325.82491.qm@web65509.mail.ac4.yahoo.com>

Is there a risk associated with having authorized_keys files set to readable but "StrictMode no"?

I am thinking particularly in the case of having public keys all centralized in a directory in /etc or something.


Is it really a potential hack vector if someone can read a public key, or is the only real danger if they were writable?

---
Don Hoover
dxh at yahoo.com

From imorgan at nas.nasa.gov  Wed Jul 16 05:31:12 2008
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 15 Jul 2008 12:31:12 -0700
Subject: Risk of StrictMode (but read only)
In-Reply-To: <187325.82491.qm@web65509.mail.ac4.yahoo.com>
References: <187325.82491.qm@web65509.mail.ac4.yahoo.com>
Message-ID: <20080715193112.GA17692@linux55.nas.nasa.gov>

On Tue, Jul 15, 2008 at 07:51:00 -0700, Don Hoover wrote:
> Is there a risk associated with having authorized_keys files set to readable but "StrictMode no"?
> 
> I am thinking particularly in the case of having public keys all centralized in a directory in /etc or something.
> 
> 
> Is it really a potential hack vector if someone can read a public key, or is the only real danger if they were writable?
> 
> ---
> Don Hoover
> dxh at yahoo.com
>

If Your OS supports POSIX ACLs, you could set an acl on each
authorized_keys file to make it readable by the user without having to
turn off StrictModes. (On Linux, you may need to supply the acl mount
option to enable POSIX ACL support.)

-- 
Iain Morgan

From stanislaw.kaminski at gmail.com  Wed Jul 16 19:44:29 2008
From: stanislaw.kaminski at gmail.com (Stanislaw Kaminski)
Date: Wed, 16 Jul 2008 11:44:29 +0200
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <52bc3fca0807150613m5edf6fa1q9a90ef89abd8a5b9@mail.gmail.com>
References: <52bc3fca0807150613m5edf6fa1q9a90ef89abd8a5b9@mail.gmail.com>
Message-ID: <52bc3fca0807160244m29ebd45cxd0f35df714b011bc@mail.gmail.com>

Hi,

Bob wrote:
> Stanislaw Kaminski wrote:
>> Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
>> Imagine my surprise when I saw that all messages that are being output
>> on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
>> terminated with 0x0D, 0x0A.
>
> What are your tty settings?  What is the output of this command?
>
>  stty -a
>
> What is the output of this command?
>
>  echo ABC | od -tx1
>
>Bob

$ stty -aspeed 38400 baud; rows 44; columns 179; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
-ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

$ echo ABC | od -tx1
0000000 41 42 43 0a
0000004

I don't want to post this two times, so I'd like you to read my reply
to Bill's post to see where I see 0x0A 0x0D.

regards,
Stanislaw

From djm at mindrot.org  Wed Jul 16 20:09:57 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 16 Jul 2008 20:09:57 +1000 (EST)
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
References: <52bc3fca0807140726s5cdb7d6fqec2f09474bd3c5de@mail.gmail.com>
Message-ID: <alpine.BSO.1.10.0807162003110.11428@fuyu.mindrot.org>

On Mon, 14 Jul 2008, Stanislaw Kaminski wrote:

> Hello everyone,
> recently I've found something I consider a bug.
> 
> Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
> Imagine my surprise when I saw that all messages that are being output
> on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
> terminated with 0x0D, 0x0A.
> 
> Maybe that's standard behaviour of all stderr messages in all Linux
> software, but I have to admin it's the first time I saw something like
> this.
> 
> So, can anybody tell me if it's for a purpose, or is it just a plain bug?

stderr logging is terminated with \r\n in case (IIRC) the terminal is
in raw mode to prevent stair-stepping of text - e.g.

debug1: SSH2_MSG_KEXINIT sent
                             debug1: rekeying in progress
                                                         debug1: rekeying in progress

... and so forth. I'm not sure why it doesn't appear in the output earlier -
perhaps cooked terminal mode eats the \r's

The actual code is in log.c.

-d


From cristian.ionescu-idbohrn at axis.com  Wed Jul 16 21:10:38 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Wed, 16 Jul 2008 13:10:38 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807151230220.14657@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
	<0807141007340.18603@somehost>
	<alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>
	<0807141138440.18603@somehost>
	<alpine.BSO.1.10.0807151230220.14657@fuyu.mindrot.org>
Message-ID: <0807151132500.18603@somehost>

On Tue, 15 Jul 2008, Damien Miller wrote:

> On Mon, 14 Jul 2008, Cristian Ionescu-Idbohrn wrote:
>
> > > Does the linked ssh/sshd link OK and pass the regress tests?
> >
> > Any easy way to do that?
> >
> > I'm cross building.
> > I build just some of the build targets.
> > Target system lacks development tools.
>
> You would need at least "make" on the target,

I was afraid you would say that :)

> but you should be able to copy over the build directory and run
> "make tests".

I'll see if I can build and squeeze make on the target system.

Just found another warning (this is 5.0p1) you might want to look
into:

ssh.c: In function `control_client':
ssh.c:1507: warning: long unsigned int format, unsigned int arg (arg 4)



Cheers,

-- 
Cristian

From djm at mindrot.org  Wed Jul 16 21:15:05 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 16 Jul 2008 21:15:05 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <0807151132500.18603@somehost>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
	<0807141007340.18603@somehost>
	<alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>
	<0807141138440.18603@somehost>
	<alpine.BSO.1.10.0807151230220.14657@fuyu.mindrot.org>
	<0807151132500.18603@somehost>
Message-ID: <alpine.BSO.1.10.0807162113430.17593@fuyu.mindrot.org>

On Wed, 16 Jul 2008, Cristian Ionescu-Idbohrn wrote:

> On Tue, 15 Jul 2008, Damien Miller wrote:
> 
> > On Mon, 14 Jul 2008, Cristian Ionescu-Idbohrn wrote:
> >
> > > > Does the linked ssh/sshd link OK and pass the regress tests?
> > >
> > > Any easy way to do that?
> > >
> > > I'm cross building.
> > > I build just some of the build targets.
> > > Target system lacks development tools.
> >
> > You would need at least "make" on the target,
> 
> I was afraid you would say that :)
> 
> > but you should be able to copy over the build directory and run
> > "make tests".
> 
> I'll see if I can build and squeeze make on the target system.

Failing that, just running (i.e. connecting to/from) sshd and ssh on
the target should show whether the linker warning is harmless or not.

> Just found another warning (this is 5.0p1) you might want to look
> into:
> 
> ssh.c: In function `control_client':
> ssh.c:1507: warning: long unsigned int format, unsigned int arg (arg 4)

I think that code was moved entirely after 5.0p1 :)

-d

From vinschen at redhat.com  Wed Jul 16 23:32:16 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 16 Jul 2008 15:32:16 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080714212058.GH24644@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
	<20080714121058.GB31215@calimero.vinschen.de>
	<20080714212058.GH24644@calimero.vinschen.de>
Message-ID: <20080716133216.GP24644@calimero.vinschen.de>

Ping?

On Jul 14 23:20, Corinna Vinschen wrote:
> On Jul 14 14:10, Corinna Vinschen wrote:
> > On Jul 14 21:38, Damien Miller wrote:
> > > > Below you'll find a patch which fixes that problem in fake-rfc2553.c.
> > > > Tested on Cygwin 1.5.25.
> > > 
> > > Applied - thanks.
> 
> Below is another patch which simplifies the test for POSIX file security
> in Cygwin.  The functionality implemented in check_ntsec() is already
> present in the Cygwin DLL for about seven years and accessible through
> pathconf(3).  In fact, in Cygwin 1.7, this will be the *only* valid
> interface to check for POSIX file security, since the global
> "CYGWIN=ntsec" environment option will be dropped in favor of a
> per-mount option.
> 
> Another question is this:  The has_capability function requests Cygwin
> version information to figure out if specific features are available.
> The newest of the requested capabilities exists since Cygwin 1.5.0,
> which has been release in 2003, five years ago.  Older versions of
> Cygwin are long out of support.  That's why I would like to ask, if it
> isn't time to drop the whole has_capability() function as well as the
> check_nt_auth() function and to remove calling this Cygwin-specific
> function throughout OpenSSH.  Right now it's called in auth1.c,
> auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
> That's a lot of #ifdef HAVE_CYGWIN which could go away :)
> 
> 
> Corinna
> 
> 
> Index: openbsd-compat/bsd-cygwin_util.c
> ===================================================================
> RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 bsd-cygwin_util.c
> --- openbsd-compat/bsd-cygwin_util.c	1 Sep 2006 09:29:01 -0000	1.19
> +++ openbsd-compat/bsd-cygwin_util.c	14 Jul 2008 21:01:36 -0000
> @@ -175,45 +175,7 @@ check_nt_auth(int pwd_authenticated, str
>  int
>  check_ntsec(const char *filename)
>  {
> -	char *cygwin;
> -	int allow_ntea = 0, allow_ntsec = 0;
> -	struct statfs fsstat;
> -
> -	/* Windows 95/98/ME don't support file system security at all. */
> -	if (!is_winnt)
> -		return (0);
> -
> -	/* Evaluate current CYGWIN settings. */
> -	cygwin = getenv("CYGWIN");
> -	allow_ntea = ntea_on(cygwin);
> -	allow_ntsec = ntsec_on(cygwin) ||
> -	    (has_capability(HAS_NTSEC_BY_DEFAULT) && !ntsec_off(cygwin));
> -
> -	/*
> -	 * `ntea' is an emulation of POSIX attributes. It doesn't support
> -	 * real file level security as ntsec on NTFS file systems does
> -	 * but it supports FAT filesystems. `ntea' is minimum requirement
> -	 * for security checks.
> -	 */
> -	if (allow_ntea)
> -		return (1);
> -
> -	/*
> -	 * Retrieve file system flags. In Cygwin, file system flags are
> -	 * copied to f_type which has no meaning in Win32 itself.
> -	 */
> -	if (statfs(filename, &fsstat))
> -		return (1);
> -
> -	/*
> -	 * Only file systems supporting ACLs are able to set permissions.
> -	 * `ntsec' is the setting in Cygwin which switches using of NTFS
> -	 * ACLs to support POSIX permissions on files.
> -	 */
> -	if (fsstat.f_type & FS_PERSISTENT_ACLS)
> -		return (allow_ntsec);
> -
> -	return (0);
> +	return (pathconf(filename, _PC_POSIX_PERMISSIONS));
>  }
>  
>  void
> 
> -- 
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From cristian.ionescu-idbohrn at axis.com  Thu Jul 17 01:03:37 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Wed, 16 Jul 2008 17:03:37 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807162113430.17593@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
	<0807141007340.18603@somehost>
	<alpine.BSO.1.10.0807141931190.7114@fuyu.mindrot.org>
	<0807141138440.18603@somehost>
	<alpine.BSO.1.10.0807151230220.14657@fuyu.mindrot.org>
	<0807151132500.18603@somehost>
	<alpine.BSO.1.10.0807162113430.17593@fuyu.mindrot.org>
Message-ID: <0807161412510.18603@somehost>

On Wed, 16 Jul 2008, Damien Miller wrote:

> On Wed, 16 Jul 2008, Cristian Ionescu-Idbohrn wrote:
>
> > I'll see if I can build and squeeze make on the target system.
>
> Failing that, just running (i.e. connecting to/from) sshd and ssh on
> the target should show whether the linker warning is harmless or not.

Alright.  Done that now.  Quick test and no problems.
But I'd still want to know what that linker warning means.

> > Just found another warning (this is 5.0p1) you might want to look
> > into:
> >
> > ssh.c: In function `control_client':
> > ssh.c:1507: warning: long unsigned int format, unsigned int arg (arg 4)
>
> I think that code was moved entirely after 5.0p1 :)

Right.  And that gave me the opportunity to check latest snapshot :)
Today's snapshot shows no such warning.


Cheers,

-- 
Cristian

From jmknoble at pobox.com  Thu Jul 17 03:32:44 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 16 Jul 2008 13:32:44 -0400
Subject: Risk of StrictMode (but read only)
In-Reply-To: <20080715234718.GC1121@crawfish.ais.com>
Message-ID: <20080716173244.GF1121@crawfish.ais.com>

[Apparently i was on auto-pilot when i sent the message below and
neglected to send it to the mailing list and the original poster.
Here it is.] 

----- Forwarded message from Jim Knoble <jmknoble at pobox.com> -----

Date: Tue, 15 Jul 2008 19:47:18 -0400
From: Jim Knoble <jmknoble at pobox.com>
To: Iain Morgan <imorgan at nas.nasa.gov>
Subject: Re: Risk of StrictMode (but read only)

Circa 2008-07-15 15:31 dixit Iain Morgan:

: On Tue, Jul 15, 2008 at 07:51:00 -0700, Don Hoover wrote:
: > Is there a risk associated with having authorized_keys files set to
: > readable but "StrictMode no"?
: > 
: > I am thinking particularly in the case of having public keys all
: > centralized in a directory in /etc or something.
: > 
: > Is it really a potential hack vector if someone can read a public
: > key, or is the only real danger if they were writable?
: 
: If Your OS supports POSIX ACLs, you could set an acl on each
: authorized_keys file to make it readable by the user without having to
: turn off StrictModes. (On Linux, you may need to supply the acl mount
: option to enable POSIX ACL support.)

StrictModes keeps your ~/.ssh/authorized_keys file and its containing
directories from being writable by someone other than root or the owner.
This is what's crucial (so that no one else can add their own public key
to authorized_keys, for example).

If by "public keys centralized in a directory..." you are referring to
the authorized_keys files, then the only real danger is exposure of
information about who is allowed to log in using public keys and what
restrictions those logins may or may not have.

If this concerns you, consider keeping the authorized key files in
per-user directories; for example (in sshd_config):

    AuthorizedKeysFile /etc/ssh/auth/%u/authorized_keys

Then, make each user's directory under /etc/ssh/auth/ readable only by
that user.  For example, for users 'alice' and 'bob':

    mkdir -p /etc/ssh/auth/alice /etc/ssh/auth/bob
    chmod 0400 /etc/ssh/auth/alice
    chown alice:0 /etc/ssh/auth/alice
    chmod 0400 /etc/ssh/auth/bob
    chown bob:0 /etc/ssh/auth/bob

Now alice can read her own /etc/ssh/auth/alice/authorized_keys file, but
can't read bob's.

You could even use this to allow specific users to maintain their own
authorized_keys file, if you so desire.

Good luck,
Jim

----- End forwarded message -----

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From jmknoble at pobox.com  Thu Jul 17 04:03:07 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 16 Jul 2008 14:03:07 -0400
Subject: Risk of StrictMode (but read only)
In-Reply-To: <20080716173244.GF1121@crawfish.ais.com>
References: <20080715234718.GC1121@crawfish.ais.com>
	<20080716173244.GF1121@crawfish.ais.com>
Message-ID: <20080716180307.GG1121@crawfish.ais.com>

Circa 2008-07-16 13:32 dixit Jim Knoble:

:     mkdir -p /etc/ssh/auth/alice /etc/ssh/auth/bob
:     chmod 0400 /etc/ssh/auth/alice
:     chown alice:0 /etc/ssh/auth/alice
:     chmod 0400 /etc/ssh/auth/bob
:     chown bob:0 /etc/ssh/auth/bob

And, of course, i wasn't thinking clearly.  There are at least two
problems with the above:

    (1) For the purpose above, '0500' is the right mode (make directories
        searchable):

            chmod 0500 /etc/ssh/auth/alice
            chmod 0500 /etc/ssh/auth/bob

    (2) Making the users the owner of the directory enables them to
        change the permissions of the directory.  That, in turn, enables
        them to change any files contained in it.  If that's not what
        you want, you are better off adding each user to their own group
        (as is done by default on many modern Linux-based systems), then
        changing directory ownership to that group and setting
        permissions accordingly.  Example:

            groupadd alice
            GROUPS=`id -Gn alice |sed -e 's/  */,/g'`
            GROUPS=${GROUPS:+${GROUPS},}
            usermod -G ${GROUPS}alice alice
            mkdir -p /etc/ssh/auth/alice
            chmod 0750 /etc/ssh/auth/alice
            chown 0:alice /etc/ssh/auth/alice

        Your mileage may vary, depending on whether groupadd and usermod
        are available (you may need to manipulate /etc/groups directly).

: Now alice can read her own /etc/ssh/auth/alice/authorized_keys file, but
: can't read bob's.
: 
: You could even use this to allow specific users to maintain their own
: authorized_keys file, if you so desire.

Which is possible by:

    mkdir -p /etc/ssh/auth/alice
    chmod 0700 /etc/ssh/auth/alice
    chown alice:alice /etc/ssh/auth/alice

Best,
Jim

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From bob at proulx.com  Thu Jul 17 05:39:07 2008
From: bob at proulx.com (Bob Proulx)
Date: Wed, 16 Jul 2008 13:39:07 -0600
Subject: EOL in stderr of ssh - Linux
In-Reply-To: <52bc3fca0807160244m29ebd45cxd0f35df714b011bc@mail.gmail.com>
References: <52bc3fca0807150613m5edf6fa1q9a90ef89abd8a5b9@mail.gmail.com>
	<52bc3fca0807160244m29ebd45cxd0f35df714b011bc@mail.gmail.com>
Message-ID: <20080716193907.GA25613@dementia.proulx.com>

Stanislaw Kaminski wrote:
> Bob wrote:
> > What are your tty settings?  What is the output of this command?
> >  stty -a

> $ stty -aspeed 38400 baud; rows 44; columns 179; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
> rprnt = ^R; werase = ^W; lnext = ^V;
> flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
> -ixon -ixoff -iuclc -ixany -imaxbel iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
> -echoprt echoctl echoke

I was looking specifically at the output post processing settings
(opost) and it looks normal to me.  In particular onlcr says to
translate newlines to carriage return-newline pairs when processing
output to the terminal.  It is set normally.

However this was probably a silly question because this governs output
to the terminal and not I/O through to a pipe.  Therefore this really
wouldn't have anything to do with the characters actually output when
they are directed into a pipe.  Sorry for the distraction.

> > What is the output of this command?
> >
> >  echo ABC | od -tx1
> 
> $ echo ABC | od -tx1
> 0000000 41 42 43 0a
> 0000004

Again, this looks normal to me.  But again, the question was probably
just a distraction.  Oh well.

Bob

From bowman at math.utah.edu  Thu Jul 17 04:17:19 2008
From: bowman at math.utah.edu (Pieter Bowman)
Date: Wed, 16 Jul 2008 12:17:19 -0600 (MDT)
Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain X11
	display socket.
Message-ID: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>

On Solaris 10 (SPARC & x86), I'm seeing the following error:

error: Failed to allocate internet-domain X11 display socket.


I tracked this down to this code change between openssh 4.7p1 and
5.0p1:

*** openssh-4.7p1/channels.c	Mon Jun 25 03:04:47 2007
--- openssh-5.0p1/channels.c	Wed Apr  2 15:43:57 2008
***************
*** 1,4 ****
! /* $OpenBSD: channels.c,v 1.270 2007/06/25 08:20:03 dtucker Exp $ */
  /*
   * Author: Tatu Ylonen <ylo at cs.hut.fi>
   * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
--- 1,4 ----
! /* $OpenBSD: channels.c,v 1.273 2008/04/02 21:36:51 markus Exp $ */
  /*
   * Author: Tatu Ylonen <ylo at cs.hut.fi>
   * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
***************
*** 2905,2913 ****
  				debug2("bind port %d: %.100s", port, strerror(errno));
  				close(sock);
  
- 				if (ai->ai_next)
- 					continue;
- 
  				for (n = 0; n < num_socks; n++) {
  					close(socks[n]);
  				}
--- 2906,2911 ----


When those two lines are added back in, X11 forwarding is able to get
a port bound.

This is only the case on Solaris.  On Linux, *BSD, IRIX systems the
current code works.

Thanks for looking into this.

Pieter

From scott_n at xypro.com  Thu Jul 17 07:00:37 2008
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 16 Jul 2008 14:00:37 -0700
Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain
	X11display socket.
In-Reply-To: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>
References: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>
Message-ID: <78DD71C304F38B41885A242996B96F73018FFB8B@xyservd.XYPRO-23.LOCAL>



> -----Original Message-----
> From: openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On
> Behalf Of Pieter Bowman
> Sent: Wednesday, July 16, 2008 11:17 AM
> To: openssh-unix-dev at mindrot.org
> Cc: bowman at math.utah.edu
> Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain
> X11display socket.
> 
> On Solaris 10 (SPARC & x86), I'm seeing the following error:
> 
> error: Failed to allocate internet-domain X11 display socket.
> 
> 
> I tracked this down to this code change between openssh 4.7p1 and
> 5.0p1:
> 
> *** openssh-4.7p1/channels.c	Mon Jun 25 03:04:47 2007
> --- openssh-5.0p1/channels.c	Wed Apr  2 15:43:57 2008
> ***************
> *** 1,4 ****
> ! /* $OpenBSD: channels.c,v 1.270 2007/06/25 08:20:03 dtucker Exp $ */
>   /*
>    * Author: Tatu Ylonen <ylo at cs.hut.fi>
>    * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
> --- 1,4 ----
> ! /* $OpenBSD: channels.c,v 1.273 2008/04/02 21:36:51 markus Exp $ */
>   /*
>    * Author: Tatu Ylonen <ylo at cs.hut.fi>
>    * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
> ***************
> *** 2905,2913 ****
>   				debug2("bind port %d: %.100s", port,
> strerror(errno));
>   				close(sock);
> 
> - 				if (ai->ai_next)
> - 					continue;
> -
>   				for (n = 0; n < num_socks; n++) {
>   					close(socks[n]);
>   				}
> --- 2906,2911 ----
> 
> 
> When those two lines are added back in, X11 forwarding is able to get
> a port bound.
> 
> This is only the case on Solaris.  On Linux, *BSD, IRIX systems the
> current code works.
> 

Weren't those two lines related to the fix between 4.9p1 and 5.0p1
ix-dev

From djm at mindrot.org  Thu Jul 17 07:39:46 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 17 Jul 2008 07:39:46 +1000 (EST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080716133216.GP24644@calimero.vinschen.de>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
	<20080714121058.GB31215@calimero.vinschen.de>
	<20080714212058.GH24644@calimero.vinschen.de>
	<20080716133216.GP24644@calimero.vinschen.de>
Message-ID: <alpine.BSO.1.10.0807170739230.17593@fuyu.mindrot.org>

On Wed, 16 Jul 2008, Corinna Vinschen wrote:

> Ping?

This will be post-5.1. Could you file is as a bug so it doesn't get lost?

-d

> On Jul 14 23:20, Corinna Vinschen wrote:
> > On Jul 14 14:10, Corinna Vinschen wrote:
> > > On Jul 14 21:38, Damien Miller wrote:
> > > > > Below you'll find a patch which fixes that problem in fake-rfc2553.c.
> > > > > Tested on Cygwin 1.5.25.
> > > > 
> > > > Applied - thanks.
> > 
> > Below is another patch which simplifies the test for POSIX file security
> > in Cygwin.  The functionality implemented in check_ntsec() is already
> > present in the Cygwin DLL for about seven years and accessible through
> > pathconf(3).  In fact, in Cygwin 1.7, this will be the *only* valid
> > interface to check for POSIX file security, since the global
> > "CYGWIN=ntsec" environment option will be dropped in favor of a
> > per-mount option.
> > 
> > Another question is this:  The has_capability function requests Cygwin
> > version information to figure out if specific features are available.
> > The newest of the requested capabilities exists since Cygwin 1.5.0,
> > which has been release in 2003, five years ago.  Older versions of
> > Cygwin are long out of support.  That's why I would like to ask, if it
> > isn't time to drop the whole has_capability() function as well as the
> > check_nt_auth() function and to remove calling this Cygwin-specific
> > function throughout OpenSSH.  Right now it's called in auth1.c,
> > auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
> > That's a lot of #ifdef HAVE_CYGWIN which could go away :)
> > 
> > 
> > Corinna
> > 
> > 
> > Index: openbsd-compat/bsd-cygwin_util.c
> > ===================================================================
> > RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v
> > retrieving revision 1.19
> > diff -u -p -r1.19 bsd-cygwin_util.c
> > --- openbsd-compat/bsd-cygwin_util.c	1 Sep 2006 09:29:01 -0000	1.19
> > +++ openbsd-compat/bsd-cygwin_util.c	14 Jul 2008 21:01:36 -0000
> > @@ -175,45 +175,7 @@ check_nt_auth(int pwd_authenticated, str
> >  int
> >  check_ntsec(const char *filename)
> >  {
> > -	char *cygwin;
> > -	int allow_ntea = 0, allow_ntsec = 0;
> > -	struct statfs fsstat;
> > -
> > -	/* Windows 95/98/ME don't support file system security at all. */
> > -	if (!is_winnt)
> > -		return (0);
> > -
> > -	/* Evaluate current CYGWIN settings. */
> > -	cygwin = getenv("CYGWIN");
> > -	allow_ntea = ntea_on(cygwin);
> > -	allow_ntsec = ntsec_on(cygwin) ||
> > -	    (has_capability(HAS_NTSEC_BY_DEFAULT) && !ntsec_off(cygwin));
> > -
> > -	/*
> > -	 * `ntea' is an emulation of POSIX attributes. It doesn't support
> > -	 * real file level security as ntsec on NTFS file systems does
> > -	 * but it supports FAT filesystems. `ntea' is minimum requirement
> > -	 * for security checks.
> > -	 */
> > -	if (allow_ntea)
> > -		return (1);
> > -
> > -	/*
> > -	 * Retrieve file system flags. In Cygwin, file system flags are
> > -	 * copied to f_type which has no meaning in Win32 itself.
> > -	 */
> > -	if (statfs(filename, &fsstat))
> > -		return (1);
> > -
> > -	/*
> > -	 * Only file systems supporting ACLs are able to set permissions.
> > -	 * `ntsec' is the setting in Cygwin which switches using of NTFS
> > -	 * ACLs to support POSIX permissions on files.
> > -	 */
> > -	if (fsstat.f_type & FS_PERSISTENT_ACLS)
> > -		return (allow_ntsec);
> > -
> > -	return (0);
> > +	return (pathconf(filename, _PC_POSIX_PERMISSIONS));
> >  }
> >  
> >  void
> > 
> > -- 
> > Corinna Vinschen
> > Cygwin Project Co-Leader
> > Red Hat
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> -- 
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From imorgan at nas.nasa.gov  Thu Jul 17 09:46:09 2008
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 16 Jul 2008 16:46:09 -0700
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
Message-ID: <20080716234609.GA16486@linux55.nas.nasa.gov>

On Mon, Jul 07, 2008 at 09:30:55 +1000, Damien Miller wrote:
> OpenSSH 5.1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release is one of
> the biggest in recent years, with two hackathons' worth of improvements
> and fixes for some of our most recalcitrant bugs.
> 

The following platforms passwd all tests using the 20080715 snapshot:

	Red Hat Enterprise Linux 4 (amd64)
	Red Hat Enterprise Linux 5 (amd64)
	Solaris 9 (SPARC)
	Mac OS X 10.4 (PPC)
	SuSE Linux Enterprise Server 10 (x86_64)
	SuSE Linux Enterprise Server 10 (IA64)
	AIX 5.3

-- 
Iain Morgan

From mouring at eviladmin.org  Thu Jul 17 11:15:28 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Wed, 16 Jul 2008 20:15:28 -0500 (CDT)
Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain X11
	display socket.
In-Reply-To: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>
References: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>
Message-ID: <alpine.BSO.1.00.0807162014000.30973@miyako.eviladmin.org>


Ermm...

Revision 1.273 / (download) - annotate - [select for diffs] , Wed Apr 2 
21:36:51 2008 UTC (3 months, 1 week ago) by markus
Branch: MAIN
Changes since 1.272: +1 -4 lines
Diff to previous 1.272 (colored)

avoid possible hijacking of x11-forwarded connections (back out 1.183)
CVE-2008-1483; ok djm@

--

Revision 1.183 / (download) - annotate - [select for diffs] , Tue Sep 17 
07:47:02 2002 UTC (5 years, 10 months ago) by itojun
Branch: MAIN
CVS Tags: OPENBSD_3_2_BASE
Branch point for: OPENBSD_3_2
Changes since 1.182: +5 -1 lines
Diff to previous 1.182 (colored)

don't quit while creating X11 listening socket.

http://mail-index.netbsd.org/current-users/2002/09/16/0005.html
got from portable.  markus ok

Removing it is the wrong solution... Not sure what the correct one, but I 
figured I'd post why it was removed.

- Ben




On Wed, 16 Jul 2008, Pieter Bowman wrote:

> On Solaris 10 (SPARC & x86), I'm seeing the following error:
>
> error: Failed to allocate internet-domain X11 display socket.
>
>
> I tracked this down to this code change between openssh 4.7p1 and
> 5.0p1:
>
> *** openssh-4.7p1/channels.c	Mon Jun 25 03:04:47 2007
> --- openssh-5.0p1/channels.c	Wed Apr  2 15:43:57 2008
> ***************
> *** 1,4 ****
> ! /* $OpenBSD: channels.c,v 1.270 2007/06/25 08:20:03 dtucker Exp $ */
>  /*
>   * Author: Tatu Ylonen <ylo at cs.hut.fi>
>   * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
> --- 1,4 ----
> ! /* $OpenBSD: channels.c,v 1.273 2008/04/02 21:36:51 markus Exp $ */
>  /*
>   * Author: Tatu Ylonen <ylo at cs.hut.fi>
>   * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
> ***************
> *** 2905,2913 ****
>  				debug2("bind port %d: %.100s", port, strerror(errno));
>  				close(sock);
>
> - 				if (ai->ai_next)
> - 					continue;
> -
>  				for (n = 0; n < num_socks; n++) {
>  					close(socks[n]);
>  				}
> --- 2906,2911 ----
>
>
> When those two lines are added back in, X11 forwarding is able to get
> a port bound.
>
> This is only the case on Solaris.  On Linux, *BSD, IRIX systems the
> current code works.
>
> Thanks for looking into this.
>
> Pieter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From djm at mindrot.org  Thu Jul 17 13:26:42 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 17 Jul 2008 13:26:42 +1000 (EST)
Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain X11
	display socket.
In-Reply-To: <alpine.BSO.1.00.0807162014000.30973@miyako.eviladmin.org>
References: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>
	<alpine.BSO.1.00.0807162014000.30973@miyako.eviladmin.org>
Message-ID: <alpine.BSO.1.10.0807171324501.5669@fuyu.mindrot.org>

On Wed, 16 Jul 2008, Ben Lindstrom wrote:

> Removing it is the wrong solution... Not sure what the correct one, but I 
> figured I'd post why it was removed.

Removing it is the right solution, the problem is that Sun returns
unusable return codes from getaddrinfo(3) when IPv6 is installed on the
machine but no interfaces have IPv6 addresses configured.

Workaround: put "AddressFamily inet" in sshd_config.

-d

From vinschen at redhat.com  Thu Jul 17 17:48:52 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 17 Jul 2008 09:48:52 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807170739230.17593@fuyu.mindrot.org>
References: <20080707172049.GA24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>
	<20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
	<20080714121058.GB31215@calimero.vinschen.de>
	<20080714212058.GH24644@calimero.vinschen.de>
	<20080716133216.GP24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807170739230.17593@fuyu.mindrot.org>
Message-ID: <20080717074852.GA5633@calimero.vinschen.de>

On Jul 17 07:39, Damien Miller wrote:
> On Wed, 16 Jul 2008, Corinna Vinschen wrote:
> 
> > Ping?
> 
> This will be post-5.1.

Too bad.  That means that 5.1 will not run on Cygwin 1.7 without local
patch.

> This will be post-5.1. Could you file is as a bug so it doesn't get lost?

Ok, will do.

What about my question:

> > > Another question is this:  The has_capability function requests Cygwin
> > > version information to figure out if specific features are available.
> > > The newest of the requested capabilities exists since Cygwin 1.5.0,
> > > which has been release in 2003, five years ago.  Older versions of
> > > Cygwin are long out of support.  That's why I would like to ask, if it
> > > isn't time to drop the whole has_capability() function as well as the
> > > check_nt_auth() function and to remove calling this Cygwin-specific
> > > function throughout OpenSSH.  Right now it's called in auth1.c,
> > > auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
> > > That's a lot of #ifdef HAVE_CYGWIN which could go away :)

Is that also ok for post-5.1?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From djm at mindrot.org  Thu Jul 17 18:09:19 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 17 Jul 2008 18:09:19 +1000 (EST)
Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain X11
	display socket.
In-Reply-To: <alpine.BSO.1.10.0807171324501.5669@fuyu.mindrot.org>
References: <CMM.0.94.0.1216232239.bowman@tortola.math.utah.edu>
	<alpine.BSO.1.00.0807162014000.30973@miyako.eviladmin.org>
	<alpine.BSO.1.10.0807171324501.5669@fuyu.mindrot.org>
Message-ID: <alpine.BSO.1.10.0807171808550.5993@fuyu.mindrot.org>



On Thu, 17 Jul 2008, Damien Miller wrote:

> On Wed, 16 Jul 2008, Ben Lindstrom wrote:
> 
> > Removing it is the wrong solution... Not sure what the correct one, but I 
> > figured I'd post why it was removed.
> 
> Removing it is the right solution, the problem is that Sun returns

ugh, "not the right solution".

From dtucker at zip.com.au  Thu Jul 17 18:56:57 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 17 Jul 2008 18:56:57 +1000
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <20080717074852.GA5633@calimero.vinschen.de>
References: <20080707172049.GA24644@calimero.vinschen.de>	<alpine.BSO.1.10.0807090015430.22609@fuyu.mindrot.org>	<20080708144105.GA6726@calimero.vinschen.de>	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>	<20080714100441.GA28868@calimero.vinschen.de>	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>	<20080714121058.GB31215@calimero.vinschen.de>	<20080714212058.GH24644@calimero.vinschen.de>	<20080716133216.GP24644@calimero.vinschen.de>	<alpine.BSO.1.10.0807170739230.17593@fuyu.mindrot.org>
	<20080717074852.GA5633@calimero.vinschen.de>
Message-ID: <487F0959.3090100@zip.com.au>

Corinna Vinschen wrote:
> On Jul 17 07:39, Damien Miller wrote:
>> On Wed, 16 Jul 2008, Corinna Vinschen wrote:
>>
>>> Ping?
>> This will be post-5.1.
> 
> Too bad.  That means that 5.1 will not run on Cygwin 1.7 without local
> patch.

In that case I think we should put it in now.  It affects cygwin only 
and you're in the best position to know what the impact is.

>> This will be post-5.1. Could you file is as a bug so it doesn't get lost?
> 
> Ok, will do.
> 
> What about my question:
> 
>>>> Another question is this:  The has_capability function requests Cygwin
>>>> version information to figure out if specific features are available.
>>>> The newest of the requested capabilities exists since Cygwin 1.5.0,
>>>> which has been release in 2003, five years ago.  Older versions of
>>>> Cygwin are long out of support.  That's why I would like to ask, if it
>>>> isn't time to drop the whole has_capability() function as well as the
>>>> check_nt_auth() function and to remove calling this Cygwin-specific
>>>> function throughout OpenSSH.  Right now it's called in auth1.c,
>>>> auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
>>>> That's a lot of #ifdef HAVE_CYGWIN which could go away :)
> 
> Is that also ok for post-5.1?

If it removes ifdefs and doesn't break anything other than 
long-unsupported cygwin then it sounds good to me.

-- 
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 kme at term.at  Thu Jul 17 19:00:10 2008
From: kme at term.at (KMe)
Date: Thu, 17 Jul 2008 11:00:10 +0200 (CEST)
Subject: Failure to connect to mpSSH Server
Message-ID: <KuwtzXYm.1216285210.6333170.cs@localhost>


Hello everybody,

i found a problem when using OpenSSH (5.0 & 4.8 running on OpenBSD 4.3)
to connect to the management processor of a HP Superdome.

These MPs are running an ssh-server anouncing itself as
"SSH-2.0-mpSSH_0.1.0".

The problem is that you get the following error when connecting:
"Disconnecting: Bad packet length 218777966."

It looks like this mpSSH is based on some older version of OpenSSH which
had a bug with AES support on bigendian machines.

Entries in the check-array in compat.c have been added some time ago
(http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/compat.c.diff?r1=1.39&r2=1.40),
but since there are no entries for mpSSH in the check-array this fails.
Here is the link to the post in HPs support forum which led me to
compat.c:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1216285116769+28353475&threadId=98508

Could someone please add the following entry to the check-array in
compat.c:

{ "mpSSH_*",            SSH_BUG_BIGENDIANAES },

Is there a way to scan for these compatability-bugs to get a complete
list to include?

regards,
cs

From vinschen at redhat.com  Thu Jul 17 20:15:44 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 17 Jul 2008 12:15:44 +0200
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <487F0959.3090100@zip.com.au>
References: <20080708144105.GA6726@calimero.vinschen.de>
	<alpine.BSO.1.10.0807141156580.16462@fuyu.mindrot.org>
	<20080714100441.GA28868@calimero.vinschen.de>
	<alpine.BSO.1.10.0807142137480.7114@fuyu.mindrot.org>
	<20080714121058.GB31215@calimero.vinschen.de>
	<20080714212058.GH24644@calimero.vinschen.de>
	<20080716133216.GP24644@calimero.vinschen.de>
	<alpine.BSO.1.10.0807170739230.17593@fuyu.mindrot.org>
	<20080717074852.GA5633@calimero.vinschen.de>
	<487F0959.3090100@zip.com.au>
Message-ID: <20080717101544.GA6477@calimero.vinschen.de>

On Jul 17 18:56, Darren Tucker wrote:
> Corinna Vinschen wrote:
> > On Jul 17 07:39, Damien Miller wrote:
> >> On Wed, 16 Jul 2008, Corinna Vinschen wrote:
> >>
> >>> Ping?
> >> This will be post-5.1.
> > 
> > Too bad.  That means that 5.1 will not run on Cygwin 1.7 without local
> > patch.
> 
> In that case I think we should put it in now.  It affects cygwin only 
> and you're in the best position to know what the impact is.

Even better, I'm in the position to know how embarrassing it is that I
haven't provided this patch already years ago. 

pathconf(_PC_POSIX_PERMISSIONS) exists for seven years and has been
designed for exactly the same purpose as the check_ntsec() function
in OpenSSH.  Oh well...

> >> This will be post-5.1. Could you file is as a bug so it doesn't get lost?
> > 
> > Ok, will do.
> > 
> > What about my question:
> > 
> >>>> Another question is this:  The has_capability function requests Cygwin
> >>>> version information to figure out if specific features are available.
> >>>> The newest of the requested capabilities exists since Cygwin 1.5.0,
> >>>> which has been release in 2003, five years ago.  Older versions of
> >>>> Cygwin are long out of support.  That's why I would like to ask, if it
> >>>> isn't time to drop the whole has_capability() function as well as the
> >>>> check_nt_auth() function and to remove calling this Cygwin-specific
> >>>> function throughout OpenSSH.  Right now it's called in auth1.c,
> >>>> auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
> >>>> That's a lot of #ifdef HAVE_CYGWIN which could go away :)
> > 
> > Is that also ok for post-5.1?
> 
> If it removes ifdefs and doesn't break anything other than 
> long-unsupported cygwin then it sounds good to me.

That's the idea :)


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From bowman at math.utah.edu  Fri Jul 18 01:13:52 2008
From: bowman at math.utah.edu (Pieter Bowman)
Date: Thu, 17 Jul 2008 09:13:52 -0600 (MDT)
Subject: openssh 5.0p1: Solaris - Failed to allocate internet-domain X11
	display socket.
In-Reply-To: Your message of Thu, 17 Jul 2008 13:26:42 +1000 (EST)
Message-ID: <CMM.0.94.0.1216307631.bowman@tortola.math.utah.edu>


>> ...
>> Workaround: put "AddressFamily inet" in sshd_config.
>> ...

Thanks, that works for me (no IPV6 here, yet).  Maybe a line or two in
README.platform would be a good idea.

Pieter

From cristian.ionescu-idbohrn at axis.com  Fri Jul 18 20:35:28 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Fri, 18 Jul 2008 12:35:28 +0200 (CEST)
Subject: OpenSSH 5.1: call for testing
In-Reply-To: <alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<0807081546470.18603@somehost>
	<alpine.BSO.1.10.0807141205250.16462@fuyu.mindrot.org>
Message-ID: <0807181111210.18603@somehost>

I think I owe an explanation.

On Mon, 14 Jul 2008, Damien Miller wrote:

> On Tue, 8 Jul 2008, Cristian Ionescu-Idbohrn wrote:
>
> > I also get this warning from the linker:
> >
> > /usr/local/cris/r64/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/../../../../cris-axis-linux-gnu/bin/ld: warning: type and size of dynamic symbol `AES_encrypt' are not defined
> >
> > which goes away if I build with:
> >
> >   CFLAGS += -DUSE_BUILTIN_RIJNDAEL
>
> That shouldn't be necessary unless you are using quite an old OpenSSL.
> Is this the case?

Showed up the above warning was caused by ourselfs :(
We misbuilded openssl. Fixed now.

Crossbuilt (for cris v10) latest snapshot.  Builds and runs fine; no
(arch) patches required :)

I'm seeing these warnings when I build for host:

sftp.c: In function 'parse_dispatch_command':
sftp.c:1238: warning: 'n_arg' may be used uninitialized in this function
sftp.c:1237: warning: 'hflag' may be used uninitialized in this function
sftp.c:1237: warning: 'iflag' may be used uninitialized in this function
sftp.c:1237: warning: 'lflag' may be used uninitialized in this function
sftp.c:1237: warning: 'pflag' may be used uninitialized in this function

Shouldn't cost much to give them a sensible initial value.

All tests passed on a debian lenny box.


Cheers,

-- 
Cristian

From des at des.no  Mon Jul 21 03:40:19 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun, 20 Jul 2008 19:40:19 +0200
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <4875236E.5020006@psc.edu> (rapier@psc.edu's message of "Wed\, 09
	Jul 2008 16\:45\:34 -0400")
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
Message-ID: <864p6ksbcs.fsf@ds4.des.no>

rapier <rapier at psc.edu> writes:
> Dag-Erling Sm?rgrav <des at des.no> writes:
> > Last I checked, it's still there; you just need to add "none" to the
> > list of accepted ciphers in myproposal.h.
> The problem is that just adding 'none' back pushes all interaction into 
> the clear [...]

No, adding "none" to the list makes it available, but not the default -
unless you add it to the front of the list.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From bruce.korb at gmail.com  Mon Jul 21 04:21:20 2008
From: bruce.korb at gmail.com (Bruce Korb)
Date: Sun, 20 Jul 2008 11:21:20 -0700
Subject: Major documentation bug
Message-ID: <48838220.50708@gmail.com>



This information needs to be in the etc/ssh/sshd_config file.



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

As documented in the 3.8 release notes 
<http://www.openssh.com/txt/release-3.8>, |ssh| will now use untrusted 
X11 cookies by default. The previous behaviour can be restored by 
setting *ForwardX11Trusted yes* in /ssh_config/.

Possible symptoms include:
|BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)|



From Markus.Wuensch at idv-ag.de  Mon Jul 21 20:42:31 2008
From: Markus.Wuensch at idv-ag.de (Markus =?ISO-8859-1?Q?W=FCnsch?=)
Date: Mon, 21 Jul 2008 12:42:31 +0200
Subject: sftp needs a long time for sending a filelist
Message-ID: <OF2DFF9A2E.4FC8FC5D-ONC125748D.003AD32C-C125748D.003AD33E@idvnet.de>


   Hello all
   Im using sftp 1:4.7p1-8ubuntu1.2
   in a batchjob
   Ive noticed that sftp needs a long time for sending a filelist.
   The timespan increases exponential if many files are on the
   remoteserver.
   for example "ls -la *.txt" needs 10 seconds for 2000 files
   but needs 50 seconds for 4000 files.
   For 150.000 Files i have to wait 15 minutes for example
   but the Conecction is very fast. I think the sftp-server needs this
   time to
   build the list.
   What can i do to get the list in normal time. ?
   Whats could be the reason for this long delay ?
   Thanks to All
   --
   Markus Wuensch

   ________________________________________________________________

   IDV AG Individuelle Datenverarbeitungssysteme

   Vorstand : Robert Strassmeir
   Vors. des Aufsichtsrates : Dr. Brigitte Holler

   Sitz der Gesellschaft : M?nchen
   Amtsgericht M?nchen HRB 122 701

From djm at mindrot.org  Mon Jul 21 23:16:51 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 21 Jul 2008 23:16:51 +1000 (EST)
Subject: sftp needs a long time for sending a filelist
In-Reply-To: <OF2DFF9A2E.4FC8FC5D-ONC125748D.003AD32C-C125748D.003AD33E@idvnet.de>
References: <OF2DFF9A2E.4FC8FC5D-ONC125748D.003AD32C-C125748D.003AD33E@idvnet.de>
Message-ID: <alpine.BSO.1.10.0807212258160.22696@fuyu.mindrot.org>

On Mon, 21 Jul 2008, Markus W?nsch wrote:

> 
>    Hello all
>    Im using sftp 1:4.7p1-8ubuntu1.2
>    in a batchjob
>    Ive noticed that sftp needs a long time for sending a filelist.
>    The timespan increases exponential if many files are on the
>    remoteserver.
>    for example "ls -la *.txt" needs 10 seconds for 2000 files
>    but needs 50 seconds for 4000 files.
>    For 150.000 Files i have to wait 15 minutes for example
>    but the Conecction is very fast. I think the sftp-server needs this
>    time to
>    build the list.

There are two performance bugs in the sftp client related to directory
listings:

1. The sftp-client.c do_readdir() makes a server round trip per batch of
   filenames rather than doing pipelined reads like do_upload/do_download

2. The sftp.c code then does a server round trip per filename to refetch
   the attrib (stat) data for each file. This is especially wasteful,
   because this data was already sent via do_readdir()

>    What can i do to get the list in normal time. ?

Fixing this is on my (long) todo list. Here is a patch that I made some
time back to fix #2, but never fully tested (updated to -current). Fixing
#1 would probably be the work of an evening if someone is interested.

-d

Index: sftp-client.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v
retrieving revision 1.86
diff -u -p -r1.86 sftp-client.c
--- sftp-client.c	26 Jun 2008 06:10:09 -0000	1.86
+++ sftp-client.c	21 Jul 2008 13:11:46 -0000
@@ -465,6 +465,7 @@ do_lsreaddir(struct sftp_conn *conn, cha
 		if (count == 0)
 			break;
 		debug3("Received %d SSH2_FXP_NAME responses", count);
+		/* XXX - implement pipelined read here like do_download */
 		for (i = 0; i < count; i++) {
 			char *filename, *longname;
 			Attrib *a;
Index: sftp-glob.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sftp-glob.c,v
retrieving revision 1.22
diff -u -p -r1.22 sftp-glob.c
--- sftp-glob.c	3 Aug 2006 03:34:42 -0000	1.22
+++ sftp-glob.c	21 Jul 2008 13:11:46 -0000
@@ -19,35 +19,31 @@
 #include <sys/stat.h>
 
 #include <dirent.h>
-#include <glob.h>
 #include <string.h>
 
+#include "xglob.h"
 #include "xmalloc.h"
 #include "sftp.h"
 #include "buffer.h"
 #include "sftp-common.h"
 #include "sftp-client.h"
 
-int remote_glob(struct sftp_conn *, const char *, int,
-    int (*)(const char *, int), glob_t *);
+int remote_xglob(struct sftp_conn *, const char *, int,
+    int (*)(const char *, int), xglob_t *);
 
 struct SFTP_OPENDIR {
 	SFTP_DIRENT **dir;
 	int offset;
 };
 
-static struct {
-	struct sftp_conn *conn;
-} cur;
-
 static void *
-fudge_opendir(const char *path)
+remote_opendir(void *ctx, const char *path)
 {
 	struct SFTP_OPENDIR *r;
+	struct sftp_conn *conn = ctx;
 
 	r = xmalloc(sizeof(*r));
-
-	if (do_readdir(cur.conn, (char *)path, &r->dir)) {
+	if (do_readdir(conn, (char *)path, &r->dir)) {
 		xfree(r);
 		return(NULL);
 	}
@@ -58,33 +54,39 @@ fudge_opendir(const char *path)
 }
 
 static struct dirent *
-fudge_readdir(struct SFTP_OPENDIR *od)
+remote_readdir(void *ctx, void *od_)
 {
+	struct SFTP_OPENDIR *od = od_;
 	static struct dirent ret;
 
 	if (od->dir[od->offset] == NULL)
 		return(NULL);
 
 	memset(&ret, 0, sizeof(ret));
-	strlcpy(ret.d_name, od->dir[od->offset++]->filename,
+	strlcpy(ret.d_name, od->dir[od->offset]->filename,
 	    sizeof(ret.d_name));
+	od->offset++;
 
 	return(&ret);
 }
 
 static void
-fudge_closedir(struct SFTP_OPENDIR *od)
+remote_closedir(void *ctx, void *od_)
 {
+	struct SFTP_OPENDIR *od = od_;
+
 	free_sftp_dirents(od->dir);
 	xfree(od);
 }
 
 static int
-fudge_lstat(const char *path, struct stat *st)
+remote_lstat(void *ctx, const char *path, struct stat *st)
 {
 	Attrib *a;
+	struct sftp_conn *conn = ctx;
 
-	if (!(a = do_lstat(cur.conn, (char *)path, 0)))
+	a = do_lstat(conn, (char *)path, 0);
+	if (a == NULL)
 		return(-1);
 
 	attrib_to_stat(a, st);
@@ -93,11 +95,17 @@ fudge_lstat(const char *path, struct sta
 }
 
 static int
-fudge_stat(const char *path, struct stat *st)
+remote_stat(void *ctx, const char *path, struct stat *st)
 {
 	Attrib *a;
+	struct sftp_conn *conn = ctx;
 
-	if (!(a = do_stat(cur.conn, (char *)path, 0)))
+	/*
+	 * XXX it is possible to skip another roundtrip here in
+	 * some cases, where the Attrib information is in the results of
+	 * a recent opendir()
+	 */
+	if (!(a = do_stat(conn, (char *)path, 0)))
 		return(-1);
 
 	attrib_to_stat(a, st);
@@ -106,17 +114,15 @@ fudge_stat(const char *path, struct stat
 }
 
 int
-remote_glob(struct sftp_conn *conn, const char *pattern, int flags,
-    int (*errfunc)(const char *, int), glob_t *pglob)
+remote_xglob(struct sftp_conn *conn, const char *pattern, int flags,
+    int (*errfunc)(const char *, int), xglob_t *pglob)
 {
-	pglob->gl_opendir = fudge_opendir;
-	pglob->gl_readdir = (struct dirent *(*)(void *))fudge_readdir;
-	pglob->gl_closedir = (void (*)(void *))fudge_closedir;
-	pglob->gl_lstat = fudge_lstat;
-	pglob->gl_stat = fudge_stat;
-
-	memset(&cur, 0, sizeof(cur));
-	cur.conn = conn;
+	pglob->gl_opendir = remote_opendir;
+	pglob->gl_readdir = remote_readdir;
+	pglob->gl_closedir = remote_closedir;
+	pglob->gl_lstat = remote_lstat;
+	pglob->gl_stat = remote_stat;
+	pglob->gl_user_ctx = conn;
 
-	return(glob(pattern, flags | GLOB_ALTDIRFUNC, errfunc, pglob));
+	return(xglob(pattern, flags | XGLOB_ALTDIRFUNC, errfunc, pglob));
 }
Index: sftp.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.103
diff -u -p -r1.103 sftp.c
--- sftp.c	13 Jul 2008 22:16:03 -0000	1.103
+++ sftp.c	21 Jul 2008 13:11:46 -0000
@@ -25,7 +25,6 @@
 
 #include <ctype.h>
 #include <errno.h>
-#include <glob.h>
 #include <histedit.h>
 #include <paths.h>
 #include <signal.h>
@@ -41,6 +40,7 @@
 #include "pathnames.h"
 #include "misc.h"
 
+#include "xglob.h"
 #include "sftp.h"
 #include "buffer.h"
 #include "sftp-common.h"
@@ -70,8 +70,8 @@ volatile sig_atomic_t interrupted = 0;
 /* I wish qsort() took a separate ctx for the comparison function...*/
 int sort_flag;
 
-int remote_glob(struct sftp_conn *, const char *, int,
-    int (*)(const char *, int), glob_t *); /* proto for sftp-glob.c */
+int remote_xglob(struct sftp_conn *, const char *, int,
+    int (*)(const char *, int), xglob_t *); /* proto for sftp-glob.c */
 
 /* Separators for interactive commands */
 #define WHITESPACE " \t\r\n"
@@ -473,7 +473,7 @@ process_get(struct sftp_conn *conn, char
 	char *abs_src = NULL;
 	char *abs_dst = NULL;
 	char *tmp;
-	glob_t g;
+	xglob_t g;
 	int err = 0;
 	int i;
 
@@ -482,7 +482,7 @@ process_get(struct sftp_conn *conn, char
 
 	memset(&g, 0, sizeof(g));
 	debug3("Looking up %s", abs_src);
-	if (remote_glob(conn, abs_src, 0, NULL, &g)) {
+	if (remote_xglob(conn, abs_src, 0, NULL, &g)) {
 		error("File \"%s\" not found.", abs_src);
 		err = -1;
 		goto out;
@@ -496,8 +496,8 @@ process_get(struct sftp_conn *conn, char
 		goto out;
 	}
 
-	for (i = 0; g.gl_pathv[i] && !interrupted; i++) {
-		if (infer_path(g.gl_pathv[i], &tmp)) {
+	for (i = 0; g.gl_matchv[i].gl_path && !interrupted; i++) {
+		if (infer_path(g.gl_matchv[i].gl_path, &tmp)) {
 			err = -1;
 			goto out;
 		}
@@ -506,7 +506,7 @@ process_get(struct sftp_conn *conn, char
 			/* If directory specified, append filename */
 			xfree(tmp);
 			if (is_dir(dst)) {
-				if (infer_path(g.gl_pathv[0], &tmp)) {
+				if (infer_path(g.gl_matchv[0].gl_path, &tmp)) {
 					err = 1;
 					goto out;
 				}
@@ -520,8 +520,9 @@ process_get(struct sftp_conn *conn, char
 		} else
 			abs_dst = tmp;
 
-		printf("Fetching %s to %s\n", g.gl_pathv[i], abs_dst);
-		if (do_download(conn, g.gl_pathv[i], abs_dst, pflag) == -1)
+		printf("Fetching %s to %s\n", g.gl_matchv[i].gl_path, abs_dst);
+		if (do_download(conn, g.gl_matchv[i].gl_path, abs_dst,
+		    pflag) == -1)
 			err = -1;
 		xfree(abs_dst);
 		abs_dst = NULL;
@@ -529,7 +530,7 @@ process_get(struct sftp_conn *conn, char
 
 out:
 	xfree(abs_src);
-	globfree(&g);
+	xglobfree(&g);
 	return(err);
 }
 
@@ -539,7 +540,7 @@ process_put(struct sftp_conn *conn, char
 	char *tmp_dst = NULL;
 	char *abs_dst = NULL;
 	char *tmp;
-	glob_t g;
+	xglob_t g;
 	int err = 0;
 	int i;
 	struct stat sb;
@@ -551,7 +552,7 @@ process_put(struct sftp_conn *conn, char
 
 	memset(&g, 0, sizeof(g));
 	debug3("Looking up %s", src);
-	if (glob(src, GLOB_NOCHECK, NULL, &g)) {
+	if (xglob(src, XGLOB_NOCHECK, NULL, &g)) {
 		error("File \"%s\" not found.", src);
 		err = -1;
 		goto out;
@@ -565,19 +566,20 @@ process_put(struct sftp_conn *conn, char
 		goto out;
 	}
 
-	for (i = 0; g.gl_pathv[i] && !interrupted; i++) {
-		if (stat(g.gl_pathv[i], &sb) == -1) {
+	for (i = 0; g.gl_matchv[i].gl_path && !interrupted; i++) {
+		if (stat(g.gl_matchv[i].gl_path, &sb) == -1) {
 			err = -1;
-			error("stat %s: %s", g.gl_pathv[i], strerror(errno));
+			error("stat %s: %s", g.gl_matchv[i].gl_path,
+			    strerror(errno));
 			continue;
 		}
 
 		if (!S_ISREG(sb.st_mode)) {
 			error("skipping non-regular file %s",
-			    g.gl_pathv[i]);
+			    g.gl_matchv[i].gl_path);
 			continue;
 		}
-		if (infer_path(g.gl_pathv[i], &tmp)) {
+		if (infer_path(g.gl_matchv[i].gl_path, &tmp)) {
 			err = -1;
 			goto out;
 		}
@@ -585,7 +587,7 @@ process_put(struct sftp_conn *conn, char
 		if (g.gl_matchc == 1 && tmp_dst) {
 			/* If directory specified, append filename */
 			if (remote_is_dir(conn, tmp_dst)) {
-				if (infer_path(g.gl_pathv[0], &tmp)) {
+				if (infer_path(g.gl_matchv[0].gl_path, &tmp)) {
 					err = 1;
 					goto out;
 				}
@@ -600,8 +602,9 @@ process_put(struct sftp_conn *conn, char
 		} else
 			abs_dst = make_absolute(tmp, pwd);
 
-		printf("Uploading %s to %s\n", g.gl_pathv[i], abs_dst);
-		if (do_upload(conn, g.gl_pathv[i], abs_dst, pflag) == -1)
+		printf("Uploading %s to %s\n", g.gl_matchv[i].gl_path, abs_dst);
+		if (do_upload(conn, g.gl_matchv[i].gl_path, abs_dst,
+		    pflag) == -1)
 			err = -1;
 	}
 
@@ -610,7 +613,7 @@ out:
 		xfree(abs_dst);
 	if (tmp_dst)
 		xfree(tmp_dst);
-	globfree(&g);
+	xglobfree(&g);
 	return(err);
 }
 
@@ -716,21 +719,50 @@ do_ls_dir(struct sftp_conn *conn, char *
 	return (0);
 }
 
+static int
+xglobentry_comp(const void *aa, const void *bb)
+{
+	struct xglob_entry *a = (struct xglob_entry *)aa;
+	struct xglob_entry *b = (struct xglob_entry *)bb;
+	int rmul = sort_flag & LS_REVERSE_SORT ? -1 : 1;
+
+#define NCMP(a,b) (a == b ? 0 : (a < b ? 1 : -1))
+	if (sort_flag & LS_NAME_SORT)
+		return (rmul * strcmp(a->gl_path, b->gl_path));
+	else if (sort_flag & LS_TIME_SORT) {
+		if (timespeccmp(&a->gl_stat.st_mtimespec, 
+		    &b->gl_stat.st_mtimespec, >))
+			return rmul;
+		if (timespeccmp(&a->gl_stat.st_mtimespec, 
+		    &b->gl_stat.st_mtimespec, <))
+			return -rmul;
+		return 0;
+	} else if (sort_flag & LS_SIZE_SORT)
+		return (rmul * NCMP(a->gl_stat.st_size, b->gl_stat.st_size));
+
+	fatal("Unknown ls sort type");
+}
+
 /* sftp ls.1 replacement which handles path globs */
 static int
 do_globbed_ls(struct sftp_conn *conn, char *path, char *strip_path,
     int lflag)
 {
-	glob_t g;
+	xglob_t g;
 	u_int i, c = 1, colspace = 0, columns = 1;
 	Attrib *a = NULL;
+	int err;
 
 	memset(&g, 0, sizeof(g));
 
-	if (remote_glob(conn, path, GLOB_MARK|GLOB_NOCHECK|GLOB_BRACE,
+	g.gl_cmp = xglobentry_comp;
+	sort_flag = lflag & (SORT_FLAGS|LS_REVERSE_SORT);
+
+	if (remote_xglob(conn, path,
+	    XGLOB_MARK|XGLOB_NOCHECK|XGLOB_BRACE|XGLOB_ALTCMPFUNC,
 	    NULL, &g) || (g.gl_pathc && !g.gl_matchc)) {
 		if (g.gl_pathc)
-			globfree(&g);
+			xglobfree(&g);
 		error("Can't ls: \"%s\" not found", path);
 		return (-1);
 	}
@@ -739,20 +771,19 @@ do_globbed_ls(struct sftp_conn *conn, ch
 		goto out;
 
 	/*
-	 * If the glob returns a single match and it is a directory,
+	 * If the xglob returns a single match and it is a directory,
 	 * then just list its contents.
 	 */
 	if (g.gl_matchc == 1) {
-		if ((a = do_lstat(conn, g.gl_pathv[0], 1)) == NULL) {
-			globfree(&g);
+		if ((a = do_lstat(conn, g.gl_matchv[0].gl_path, 1)) == NULL) {
+			xglobfree(&g);
 			return (-1);
 		}
 		if ((a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) &&
 		    S_ISDIR(a->perm)) {
-			int err;
-
-			err = do_ls_dir(conn, g.gl_pathv[0], strip_path, lflag);
-			globfree(&g);
+			err = do_ls_dir(conn, g.gl_matchv[0].gl_path,
+			    strip_path, lflag);
+			xglobfree(&g);
 			return (err);
 		}
 	}
@@ -762,8 +793,8 @@ do_globbed_ls(struct sftp_conn *conn, ch
 		struct winsize ws;
 
 		/* Count entries for sort and find longest filename */
-		for (i = 0; g.gl_pathv[i]; i++)
-			m = MAX(m, strlen(g.gl_pathv[i]));
+		for (i = 0; g.gl_matchv[i].gl_path; i++)
+			m = MAX(m, strlen(g.gl_matchv[i].gl_path));
 
 		if (ioctl(fileno(stdin), TIOCGWINSZ, &ws) != -1)
 			width = ws.ws_col;
@@ -773,28 +804,12 @@ do_globbed_ls(struct sftp_conn *conn, ch
 		colspace = width / columns;
 	}
 
-	for (i = 0; g.gl_pathv[i] && !interrupted; i++, a = NULL) {
-		char *fname;
-
-		fname = path_strip(g.gl_pathv[i], strip_path);
+	for (i = 0; g.gl_matchv[i].gl_path && !interrupted; i++) {
+		char *fname, *lname;
 
+		fname = path_strip(g.gl_matchv[i].gl_path, strip_path);
 		if (lflag & LS_LONG_VIEW) {
-			char *lname;
-			struct stat sb;
-
-			/*
-			 * XXX: this is slow - 1 roundtrip per path
-			 * A solution to this is to fork glob() and
-			 * build a sftp specific version which keeps the
-			 * attribs (which currently get thrown away)
-			 * that the server returns as well as the filenames.
-			 */
-			memset(&sb, 0, sizeof(sb));
-			if (a == NULL)
-				a = do_lstat(conn, g.gl_pathv[i], 1);
-			if (a != NULL)
-				attrib_to_stat(a, &sb);
-			lname = ls_file(fname, &sb, 1);
+			lname = ls_file(fname, &g.gl_matchv[i].gl_stat, 1);
 			printf("%s\n", lname);
 			xfree(lname);
 		} else {
@@ -813,7 +828,7 @@ do_globbed_ls(struct sftp_conn *conn, ch
 
  out:
 	if (g.gl_pathc)
-		globfree(&g);
+		xglobfree(&g);
 
 	return (0);
 }
@@ -1218,7 +1233,7 @@ parse_dispatch_command(struct sftp_conn 
 	Attrib a, *aa;
 	char path_buf[MAXPATHLEN];
 	int err = 0;
-	glob_t g;
+	xglob_t g;
 
 	path1 = path2 = NULL;
 	cmdnum = parse_args(&cmd, &pflag, &lflag, &iflag, &hflag, &n_arg,
@@ -1255,10 +1270,10 @@ parse_dispatch_command(struct sftp_conn 
 		break;
 	case I_RM:
 		path1 = make_absolute(path1, *pwd);
-		remote_glob(conn, path1, GLOB_NOCHECK, NULL, &g);
-		for (i = 0; g.gl_pathv[i] && !interrupted; i++) {
-			printf("Removing %s\n", g.gl_pathv[i]);
-			err = do_rm(conn, g.gl_pathv[i]);
+		remote_xglob(conn, path1, XGLOB_NOCHECK, NULL, &g);
+		for (i = 0; g.gl_matchv[i].gl_path && !interrupted; i++) {
+			printf("Removing %s\n", g.gl_matchv[i].gl_path);
+			err = do_rm(conn, g.gl_matchv[i].gl_path);
 			if (err != 0 && err_abort)
 				break;
 		}
@@ -1351,10 +1366,10 @@ parse_dispatch_command(struct sftp_conn 
 		attrib_clear(&a);
 		a.flags |= SSH2_FILEXFER_ATTR_PERMISSIONS;
 		a.perm = n_arg;
-		remote_glob(conn, path1, GLOB_NOCHECK, NULL, &g);
-		for (i = 0; g.gl_pathv[i] && !interrupted; i++) {
-			printf("Changing mode on %s\n", g.gl_pathv[i]);
-			err = do_setstat(conn, g.gl_pathv[i], &a);
+		remote_xglob(conn, path1, XGLOB_NOCHECK, NULL, &g);
+		for (i = 0; g.gl_matchv[i].gl_path && !interrupted; i++) {
+			printf("Changing mode on %s\n", g.gl_matchv[i].gl_path);
+			err = do_setstat(conn, g.gl_matchv[i].gl_path, &a);
 			if (err != 0 && err_abort)
 				break;
 		}
@@ -1362,9 +1377,9 @@ parse_dispatch_command(struct sftp_conn 
 	case I_CHOWN:
 	case I_CHGRP:
 		path1 = make_absolute(path1, *pwd);
-		remote_glob(conn, path1, GLOB_NOCHECK, NULL, &g);
-		for (i = 0; g.gl_pathv[i] && !interrupted; i++) {
-			if (!(aa = do_stat(conn, g.gl_pathv[i], 0))) {
+		remote_xglob(conn, path1, XGLOB_NOCHECK, NULL, &g);
+		for (i = 0; g.gl_matchv[i].gl_path && !interrupted; i++) {
+			if (!(aa = do_stat(conn, g.gl_matchv[i].gl_path, 0))) {
 				if (err != 0 && err_abort)
 					break;
 				else
@@ -1372,7 +1387,8 @@ parse_dispatch_command(struct sftp_conn 
 			}
 			if (!(aa->flags & SSH2_FILEXFER_ATTR_UIDGID)) {
 				error("Can't get current ownership of "
-				    "remote file \"%s\"", g.gl_pathv[i]);
+				    "remote file \"%s\"", 
+				    g.gl_matchv[i].gl_path);
 				if (err != 0 && err_abort)
 					break;
 				else
@@ -1380,13 +1396,15 @@ parse_dispatch_command(struct sftp_conn 
 			}
 			aa->flags &= SSH2_FILEXFER_ATTR_UIDGID;
 			if (cmdnum == I_CHOWN) {
-				printf("Changing owner on %s\n", g.gl_pathv[i]);
+				printf("Changing owner on %s\n",
+				    g.gl_matchv[i].gl_path);
 				aa->uid = n_arg;
 			} else {
-				printf("Changing group on %s\n", g.gl_pathv[i]);
+				printf("Changing group on %s\n",
+				    g.gl_matchv[i].gl_path);
 				aa->gid = n_arg;
 			}
-			err = do_setstat(conn, g.gl_pathv[i], aa);
+			err = do_setstat(conn, g.gl_matchv[i].gl_path, aa);
 			if (err != 0 && err_abort)
 				break;
 		}
@@ -1423,7 +1441,7 @@ parse_dispatch_command(struct sftp_conn 
 	}
 
 	if (g.gl_pathc)
-		globfree(&g);
+		xglobfree(&g);
 	if (path1)
 		xfree(path1);
 	if (path2)
Index: xglob.c
===================================================================
RCS file: xglob.c
diff -N xglob.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ xglob.c	21 Jul 2008 13:11:46 -0000
@@ -0,0 +1,835 @@
+/*	$OpenBSD$ */
+/*
+ * Copyright 2007 Damien Miller <djm at mindrot.org>
+ * Copyright (c) 1989, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Guido van Rossum.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Modified version of BSD glob(3):
+ *  - ALTDIRFUNCs gain context arguments. sftp uses this to pass in a
+ *    structure representing the connection.
+ *  - Instead of returning just a vector of paths, xglob returns a struct
+ *    that contains the path and its stuct stat. This is useful for sftp, as
+ *    it saves a round-trip later.
+ *  - Added ALTCMPFUNC for caller-specified comparison functions to be passed
+ *    to the final qsort(3).
+ */
+
+#include <sys/param.h>
+#include <sys/stat.h>
+
+#include <ctype.h>
+#include <dirent.h>
+#include <errno.h>
+#include <pwd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "xglob.h"
+
+#define	DOLLAR		'$'
+#define	DOT		'.'
+#define	EOS		'\0'
+#define	LBRACKET	'['
+#define	NOT		'!'
+#define	QUESTION	'?'
+#define	QUOTE		'\\'
+#define	RANGE		'-'
+#define	RBRACKET	']'
+#define	SEP		'/'
+#define	STAR		'*'
+#define	TILDE		'~'
+#define	UNDERSCORE	'_'
+#define	LBRACE		'{'
+#define	RBRACE		'}'
+#define	SLASH		'/'
+#define	COMMA		','
+
+#ifndef DEBUG
+
+#define	M_QUOTE		0x8000
+#define	M_PROTECT	0x4000
+#define	M_MASK		0xffff
+#define	M_ASCII		0x00ff
+
+typedef u_short Char;
+
+#else
+
+#define	M_QUOTE		0x80
+#define	M_PROTECT	0x40
+#define	M_MASK		0xff
+#define	M_ASCII		0x7f
+
+typedef char Char;
+
+#endif
+
+
+#define	CHAR(c)		((Char)((c)&M_ASCII))
+#define	META(c)		((Char)((c)|M_QUOTE))
+#define	M_ALL		META('*')
+#define	M_END		META(']')
+#define	M_NOT		META('!')
+#define	M_ONE		META('?')
+#define	M_RNG		META('-')
+#define	M_SET		META('[')
+#define	ismeta(c)	(((c)&M_QUOTE) != 0)
+
+
+static int	 path_compare(const void *, const void *);
+static int	 g_Ctoc(const Char *, char *, u_int);
+static int	 g_lstat(Char *, struct stat *, xglob_t *);
+static DIR	*g_opendir(Char *, xglob_t *);
+static Char	*g_strchr(Char *, int);
+static int	 g_stat(Char *, struct stat *, xglob_t *);
+static int	 xglob0(const Char *, xglob_t *);
+static int	 xglob1(Char *, Char *, xglob_t *, size_t *);
+static int	 xglob2(Char *, Char *, Char *, Char *, Char *, Char *,
+		    xglob_t *, size_t *);
+static int	 xglob3(Char *, Char *, Char *, Char *, Char *,
+		    Char *, Char *, xglob_t *, size_t *);
+static int	 xglobextend(const Char *, struct stat *, xglob_t *, size_t *);
+static const Char *
+		 xglobtilde(const Char *, Char *, size_t, xglob_t *);
+static int	 xglobexp1(const Char *, xglob_t *);
+static int	 xglobexp2(const Char *, const Char *, xglob_t *, int *);
+static int	 match(Char *, Char *, Char *);
+#ifdef DEBUG
+static void	 qprintf(const char *, Char *);
+#endif
+
+int
+xglob(const char *pattern, int flags, int (*errfunc)(const char *, int),
+    xglob_t *pglob)
+{
+	const u_char *patnext;
+	int c;
+	Char *bufnext, *bufend, patbuf[MAXPATHLEN];
+
+	patnext = (u_char *) pattern;
+	if (!(flags & XGLOB_APPEND)) {
+		pglob->gl_pathc = 0;
+		pglob->gl_matchv = NULL;
+		if (!(flags & XGLOB_DOOFFS))
+			pglob->gl_offs = 0;
+	}
+	pglob->gl_flags = flags & ~XGLOB_MAGCHAR;
+	pglob->gl_errfunc = errfunc;
+	pglob->gl_matchc = 0;
+
+	bufnext = patbuf;
+	bufend = bufnext + MAXPATHLEN - 1;
+	if (flags & XGLOB_NOESCAPE)
+		while (bufnext < bufend && (c = *patnext++) != EOS)
+			*bufnext++ = c;
+	else {
+		/* Protect the quoted characters. */
+		while (bufnext < bufend && (c = *patnext++) != EOS)
+			if (c == QUOTE) {
+				if ((c = *patnext++) == EOS) {
+					c = QUOTE;
+					--patnext;
+				}
+				*bufnext++ = c | M_PROTECT;
+			} else
+				*bufnext++ = c;
+	}
+	*bufnext = EOS;
+
+	if (flags & XGLOB_BRACE)
+		return xglobexp1(patbuf, pglob);
+	else
+		return xglob0(patbuf, pglob);
+}
+
+/*
+ * Expand recursively a glob {} pattern. When there is no more expansion
+ * invoke the standard globbing routine to glob the rest of the magic
+ * characters
+ */
+static int
+xglobexp1(const Char *pattern, xglob_t *pglob)
+{
+	const Char* ptr = pattern;
+	int rv;
+
+	/* Protect a single {}, for find(1), like csh */
+	if (pattern[0] == LBRACE && pattern[1] == RBRACE && pattern[2] == EOS)
+		return xglob0(pattern, pglob);
+
+	while ((ptr = (const Char *) g_strchr((Char *) ptr, LBRACE)) != NULL)
+		if (!xglobexp2(ptr, pattern, pglob, &rv))
+			return rv;
+
+	return xglob0(pattern, pglob);
+}
+
+
+/*
+ * Recursive brace globbing helper. Tries to expand a single brace.
+ * If it succeeds then it invokes xglobexp1 with the new pattern.
+ * If it fails then it tries to glob the rest of the pattern and returns.
+ */
+static int
+xglobexp2(const Char *ptr, const Char *pattern, xglob_t *pglob, int *rv)
+{
+	int     i;
+	Char   *lm, *ls;
+	const Char *pe, *pm, *pl;
+	Char    patbuf[MAXPATHLEN];
+
+	/* copy part up to the brace */
+	for (lm = patbuf, pm = pattern; pm != ptr; *lm++ = *pm++)
+		;
+	*lm = EOS;
+	ls = lm;
+
+	/* Find the balanced brace */
+	for (i = 0, pe = ++ptr; *pe; pe++)
+		if (*pe == LBRACKET) {
+			/* Ignore everything between [] */
+			for (pm = pe++; *pe != RBRACKET && *pe != EOS; pe++)
+				;
+			if (*pe == EOS) {
+				/*
+				 * We could not find a matching RBRACKET.
+				 * Ignore and just look for RBRACE
+				 */
+				pe = pm;
+			}
+		} else if (*pe == LBRACE)
+			i++;
+		else if (*pe == RBRACE) {
+			if (i == 0)
+				break;
+			i--;
+		}
+
+	/* Non matching braces; just glob the pattern */
+	if (i != 0 || *pe == EOS) {
+		*rv = xglob0(patbuf, pglob);
+		return 0;
+	}
+
+	for (i = 0, pl = pm = ptr; pm <= pe; pm++) {
+		switch (*pm) {
+		case LBRACKET:
+			/* Ignore everything between [] */
+			for (pl = pm++; *pm != RBRACKET && *pm != EOS; pm++)
+				;
+			if (*pm == EOS) {
+				/*
+				 * We could not find a matching RBRACKET.
+				 * Ignore and just look for RBRACE
+				 */
+				pm = pl;
+			}
+			break;
+
+		case LBRACE:
+			i++;
+			break;
+
+		case RBRACE:
+			if (i) {
+				i--;
+				break;
+			}
+			/* FALLTHROUGH */
+		case COMMA:
+			if (i && *pm == COMMA)
+				break;
+			else {
+				/* Append the current string */
+				for (lm = ls; (pl < pm); *lm++ = *pl++)
+					;
+
+				/*
+				 * Append the rest of the pattern after the
+				 * closing brace
+				 */
+				for (pl = pe + 1; (*lm++ = *pl++) != EOS; )
+					;
+
+				/* Expand the current pattern */
+#ifdef DEBUG
+				qprintf("xglobexp2:", patbuf);
+#endif
+				*rv = xglobexp1(patbuf, pglob);
+
+				/* move after the comma, to the next string */
+				pl = pm + 1;
+			}
+			break;
+
+		default:
+			break;
+		}
+	}
+	*rv = 0;
+	return 0;
+}
+
+
+
+/*
+ * expand tilde from the passwd file.
+ */
+static const Char *
+xglobtilde(const Char *pattern, Char *patbuf, size_t patbuf_len, xglob_t *pglob)
+{
+	struct passwd *pwd;
+	char *h;
+	const Char *p;
+	Char *b, *eb;
+
+	if (*pattern != TILDE || !(pglob->gl_flags & XGLOB_TILDE))
+		return pattern;
+
+	/* Copy up to the end of the string or / */
+	eb = &patbuf[patbuf_len - 1];
+	for (p = pattern + 1, h = (char *) patbuf;
+	    h < (char *)eb && *p && *p != SLASH; *h++ = *p++)
+		;
+
+	*h = EOS;
+
+#if 0
+	if (h == (char *)eb)
+		return what;
+#endif
+
+	if (((char *) patbuf)[0] == EOS) {
+		/*
+		 * handle a plain ~ or ~/ by expanding $HOME
+		 * first and then trying the password file
+		 */
+		if (issetugid() != 0 || (h = getenv("HOME")) == NULL) {
+			if ((pwd = getpwuid(getuid())) == NULL)
+				return pattern;
+			else
+				h = pwd->pw_dir;
+		}
+	} else {
+		/*
+		 * Expand a ~user
+		 */
+		if ((pwd = getpwnam((char*) patbuf)) == NULL)
+			return pattern;
+		else
+			h = pwd->pw_dir;
+	}
+
+	/* Copy the home directory */
+	for (b = patbuf; b < eb && *h; *b++ = *h++)
+		;
+
+	/* Append the rest of the pattern */
+	while (b < eb && (*b++ = *p++) != EOS)
+		;
+	*b = EOS;
+
+	return patbuf;
+}
+
+
+/*
+ * The main xglob() routine: compiles the pattern (optionally processing
+ * quotes), calls xglob1() to do the real pattern matching, and finally
+ * sorts the list (unless unsorted operation is requested).  Returns 0
+ * if things went well, nonzero if errors occurred.  It is not an error
+ * to find no matches.
+ */
+static int
+xglob0(const Char *pattern, xglob_t *pglob)
+{
+	const Char *qpatnext;
+	int c, err, oldpathc;
+	Char *bufnext, patbuf[MAXPATHLEN];
+	size_t limit = 0;
+
+	qpatnext = xglobtilde(pattern, patbuf, MAXPATHLEN, pglob);
+	oldpathc = pglob->gl_pathc;
+	bufnext = patbuf;
+
+	/* We don't need to check for buffer overflow any more. */
+	while ((c = *qpatnext++) != EOS) {
+		switch (c) {
+		case LBRACKET:
+			c = *qpatnext;
+			if (c == NOT)
+				++qpatnext;
+			if (*qpatnext == EOS ||
+			    g_strchr((Char *) qpatnext+1, RBRACKET) == NULL) {
+				*bufnext++ = LBRACKET;
+				if (c == NOT)
+					--qpatnext;
+				break;
+			}
+			*bufnext++ = M_SET;
+			if (c == NOT)
+				*bufnext++ = M_NOT;
+			c = *qpatnext++;
+			do {
+				*bufnext++ = CHAR(c);
+				if (*qpatnext == RANGE &&
+				    (c = qpatnext[1]) != RBRACKET) {
+					*bufnext++ = M_RNG;
+					*bufnext++ = CHAR(c);
+					qpatnext += 2;
+				}
+			} while ((c = *qpatnext++) != RBRACKET);
+			pglob->gl_flags |= XGLOB_MAGCHAR;
+			*bufnext++ = M_END;
+			break;
+		case QUESTION:
+			pglob->gl_flags |= XGLOB_MAGCHAR;
+			*bufnext++ = M_ONE;
+			break;
+		case STAR:
+			pglob->gl_flags |= XGLOB_MAGCHAR;
+			/* collapse adjacent stars to one,
+			 * to avoid exponential behavior
+			 */
+			if (bufnext == patbuf || bufnext[-1] != M_ALL)
+				*bufnext++ = M_ALL;
+			break;
+		default:
+			*bufnext++ = CHAR(c);
+			break;
+		}
+	}
+	*bufnext = EOS;
+#ifdef DEBUG
+	qprintf("xglob0:", patbuf);
+#endif
+
+	if ((err = xglob1(patbuf, patbuf+MAXPATHLEN-1, pglob, &limit)) != 0)
+		return(err);
+
+	/*
+	 * If there was no match we are going to append the pattern
+	 * if XGLOB_NOCHECK was specified or if XGLOB_NOMAGIC was specified
+	 * and the pattern did not contain any magic characters
+	 * XGLOB_NOMAGIC is there just for compatibility with csh.
+	 */
+	if (pglob->gl_pathc == oldpathc) {
+		if ((pglob->gl_flags & XGLOB_NOCHECK) ||
+		    ((pglob->gl_flags & XGLOB_NOMAGIC) &&
+		    !(pglob->gl_flags & XGLOB_MAGCHAR)))
+			return(xglobextend(pattern, NULL, pglob, &limit));
+		else
+			return(XGLOB_NOMATCH);
+	}
+	if (!(pglob->gl_flags & XGLOB_NOSORT))
+		qsort(pglob->gl_matchv + pglob->gl_offs + oldpathc,
+		    pglob->gl_pathc - oldpathc, sizeof(*pglob->gl_matchv),
+		    (pglob->gl_flags & XGLOB_ALTCMPFUNC) ?
+		     pglob->gl_cmp : path_compare);
+	return(0);
+}
+
+static int
+path_compare(const void *a, const void *b)
+{
+	struct xglob_entry *aa = (struct xglob_entry *)a;
+	struct xglob_entry *bb = (struct xglob_entry *)b;
+
+	return(strcmp(aa->gl_path, bb->gl_path));
+}
+
+static int
+xglob1(Char *pattern, Char *pattern_last, xglob_t *pglob, size_t *limitp)
+{
+	Char pathbuf[MAXPATHLEN];
+
+	/* A null pathname is invalid -- POSIX 1003.1 sect. 2.4. */
+	if (*pattern == EOS)
+		return(0);
+	return(xglob2(pathbuf, pathbuf+MAXPATHLEN-1,
+	    pathbuf, pathbuf+MAXPATHLEN-1,
+	    pattern, pattern_last, pglob, limitp));
+}
+
+/*
+ * The functions xglob2 and xglob3 are mutually recursive; there is one level
+ * of recursion for each segment in the pattern that contains one or more
+ * meta characters.
+ */
+static int
+xglob2(Char *pathbuf, Char *pathbuf_last, Char *pathend, Char *pathend_last,
+    Char *pattern, Char *pattern_last, xglob_t *pglob, size_t *limitp)
+{
+	struct stat sb;
+	Char *p, *q;
+	int anymeta;
+
+	/*
+	 * Loop over pattern segments until end of pattern or until
+	 * segment with meta character found.
+	 */
+	for (anymeta = 0;;) {
+		if (*pattern == EOS) {		/* End of pattern? */
+			*pathend = EOS;
+			if (g_lstat(pathbuf, &sb, pglob))
+				return(0);
+
+			if (((pglob->gl_flags & XGLOB_MARK) &&
+			    pathend[-1] != SEP) && (S_ISDIR(sb.st_mode) ||
+			    (S_ISLNK(sb.st_mode) &&
+			    (g_stat(pathbuf, &sb, pglob) == 0) &&
+			    S_ISDIR(sb.st_mode)))) {
+				if (pathend+1 > pathend_last)
+					return (1);
+				*pathend++ = SEP;
+				*pathend = EOS;
+			}
+			++pglob->gl_matchc;
+			return(xglobextend(pathbuf, &sb, pglob, limitp));
+		}
+
+		/* Find end of next segment, copy tentatively to pathend. */
+		q = pathend;
+		p = pattern;
+		while (*p != EOS && *p != SEP) {
+			if (ismeta(*p))
+				anymeta = 1;
+			if (q+1 > pathend_last)
+				return (1);
+			*q++ = *p++;
+		}
+
+		if (!anymeta) {		/* No expansion, do next segment. */
+			pathend = q;
+			pattern = p;
+			while (*pattern == SEP) {
+				if (pathend+1 > pathend_last)
+					return (1);
+				*pathend++ = *pattern++;
+			}
+		} else
+			/* Need expansion, recurse. */
+			return(xglob3(pathbuf, pathbuf_last, pathend,
+			    pathend_last, pattern, p, pattern_last,
+			    pglob, limitp));
+	}
+	/* NOTREACHED */
+}
+
+static int
+xglob3(Char *pathbuf, Char *pathbuf_last, Char *pathend, Char *pathend_last,
+    Char *pattern, Char *restpattern, Char *restpattern_last, xglob_t *pglob,
+    size_t *limitp)
+{
+	struct dirent *dp;
+	DIR *dirp;
+	int err;
+	char buf[MAXPATHLEN];
+
+	if (pathend > pathend_last)
+		return (1);
+	*pathend = EOS;
+	errno = 0;
+
+	if ((dirp = g_opendir(pathbuf, pglob)) == NULL) {
+		/* TODO: don't call for ENOENT or ENOTDIR? */
+		if (pglob->gl_errfunc) {
+			if (g_Ctoc(pathbuf, buf, sizeof(buf)))
+				return(XGLOB_ABORTED);
+			if (pglob->gl_errfunc(buf, errno) ||
+			    pglob->gl_flags & XGLOB_ERR)
+				return(XGLOB_ABORTED);
+		}
+		return(0);
+	}
+
+	err = 0;
+
+	/* Search directory for matching names. */
+	while (1) {
+		if (pglob->gl_flags & XGLOB_ALTDIRFUNC)
+			dp = pglob->gl_readdir(pglob->gl_user_ctx, dirp);
+		else
+			dp = readdir(dirp);
+
+		if (dp == NULL)
+			break;
+
+		u_char *sc;
+		Char *dc;
+
+		/* Initial DOT must be matched literally. */
+		if (dp->d_name[0] == DOT && *pattern != DOT)
+			continue;
+		dc = pathend;
+		sc = (u_char *) dp->d_name;
+		while (dc < pathend_last && (*dc++ = *sc++) != EOS)
+			;
+		if (dc >= pathend_last) {
+			*dc = EOS;
+			err = 1;
+			break;
+		}
+
+		if (!match(pathend, pattern, restpattern)) {
+			*pathend = EOS;
+			continue;
+		}
+		err = xglob2(pathbuf, pathbuf_last, --dc, pathend_last,
+		    restpattern, restpattern_last, pglob, limitp);
+		if (err)
+			break;
+	}
+
+	if (pglob->gl_flags & XGLOB_ALTDIRFUNC)
+		(*pglob->gl_closedir)(pglob->gl_user_ctx, dirp);
+	else
+		closedir(dirp);
+	return(err);
+}
+
+
+/*
+ * Extend the gl_matchv member of a xglob_t structure to accommodate a new item,
+ * add the new item, and update gl_pathc.
+ *
+ * This assumes the BSD realloc, which only copies the block when its size
+ * crosses a power-of-two boundary; for v7 realloc, this would cause quadratic
+ * behavior.
+ *
+ * Return 0 if new item added, error code if memory couldn't be allocated.
+ *
+ * Invariant of the xglob_t structure:
+ *	Either gl_pathc is zero and gl_matchv is NULL; or gl_pathc > 0 and
+ *	gl_matchv points to (gl_offs + gl_pathc + 1) items.
+ */
+static int
+xglobextend(const Char *path, struct stat *st, xglob_t *pglob, size_t *limitp)
+{
+	struct xglob_entry *matchv;
+	size_t newsize, len, i;
+	char *copy;
+	const Char *p;
+
+	newsize = sizeof(*matchv) * (2 + pglob->gl_pathc + pglob->gl_offs);
+	matchv = realloc(pglob->gl_matchv, newsize);
+	if (matchv == NULL) {
+		if (pglob->gl_matchv) {
+			free(pglob->gl_matchv);
+			pglob->gl_matchv = NULL;
+		}
+		return(XGLOB_NOSPACE);
+	}
+
+	if (pglob->gl_matchv == NULL && pglob->gl_offs > 0)
+		memset(matchv, '\0', newsize);
+
+	pglob->gl_matchv = matchv;
+
+	for (p = path; *p++;)
+		;
+	len = (size_t)(p - path);
+	*limitp += len;
+	copy = malloc(len);
+	if (copy != NULL) {
+		if (g_Ctoc(path, copy, len)) {
+			free(copy);
+			copy = NULL;
+		}
+		i = pglob->gl_offs + pglob->gl_pathc++;
+		matchv[i].gl_path = copy;
+		if (st != NULL)
+			matchv[i].gl_stat = *st;
+	}
+	memset(&matchv[pglob->gl_offs + pglob->gl_pathc], '\0',
+	    sizeof(*matchv));
+
+	if ((pglob->gl_flags & XGLOB_LIMIT) &&
+	    newsize + *limitp >= ARG_MAX) {
+		errno = 0;
+		return(XGLOB_NOSPACE);
+	}
+
+	return(copy == NULL ? XGLOB_NOSPACE : 0);
+}
+
+
+/*
+ * pattern matching function for filenames.  Each occurrence of the *
+ * pattern causes a recursion level.
+ */
+static int
+match(Char *name, Char *pat, Char *patend)
+{
+	int ok, negate_range;
+	Char c, k;
+
+	while (pat < patend) {
+		c = *pat++;
+		switch (c & M_MASK) {
+		case M_ALL:
+			if (pat == patend)
+				return(1);
+			do {
+			    if (match(name, pat, patend))
+				    return(1);
+			} while (*name++ != EOS);
+			return(0);
+		case M_ONE:
+			if (*name++ == EOS)
+				return(0);
+			break;
+		case M_SET:
+			ok = 0;
+			if ((k = *name++) == EOS)
+				return(0);
+			if ((negate_range = ((*pat & M_MASK) == M_NOT)) != EOS)
+				++pat;
+			while (((c = *pat++) & M_MASK) != M_END)
+				if ((*pat & M_MASK) == M_RNG) {
+					if (c <= k && k <= pat[1])
+						ok = 1;
+					pat += 2;
+				} else if (c == k)
+					ok = 1;
+			if (ok == negate_range)
+				return(0);
+			break;
+		default:
+			if (*name++ != c)
+				return(0);
+			break;
+		}
+	}
+	return(*name == EOS);
+}
+
+/* Free allocated data belonging to a xglob_t structure. */
+void
+xglobfree(xglob_t *pglob)
+{
+	int i;
+	struct xglob_entry *pp;
+
+	if (pglob->gl_matchv != NULL) {
+		pp = pglob->gl_matchv + pglob->gl_offs;
+		for (i = pglob->gl_pathc; i--; ++pp)
+			if (pp->gl_path)
+				free(pp->gl_path);
+		free(pglob->gl_matchv);
+		pglob->gl_matchv = NULL;
+	}
+}
+
+static DIR *
+g_opendir(Char *str, xglob_t *pglob)
+{
+	char buf[MAXPATHLEN];
+
+	if (!*str)
+		strlcpy(buf, ".", sizeof buf);
+	else {
+		if (g_Ctoc(str, buf, sizeof(buf)))
+			return(NULL);
+	}
+
+	if (pglob->gl_flags & XGLOB_ALTDIRFUNC)
+		return((*pglob->gl_opendir)(pglob->gl_user_ctx, buf));
+
+	return(opendir(buf));
+}
+
+static int
+g_lstat(Char *fn, struct stat *sb, xglob_t *pglob)
+{
+	char buf[MAXPATHLEN];
+
+	if (g_Ctoc(fn, buf, sizeof(buf)))
+		return(-1);
+	if (pglob->gl_flags & XGLOB_ALTDIRFUNC)
+		return((*pglob->gl_lstat)(pglob->gl_user_ctx, buf, sb));
+	return(lstat(buf, sb));
+}
+
+static int
+g_stat(Char *fn, struct stat *sb, xglob_t *pglob)
+{
+	char buf[MAXPATHLEN];
+
+	if (g_Ctoc(fn, buf, sizeof(buf)))
+		return(-1);
+	if (pglob->gl_flags & XGLOB_ALTDIRFUNC)
+		return((*pglob->gl_stat)(pglob->gl_user_ctx, buf, sb));
+	return(stat(buf, sb));
+}
+
+static Char *
+g_strchr(Char *str, int ch)
+{
+	do {
+		if (*str == ch)
+			return (str);
+	} while (*str++);
+	return (NULL);
+}
+
+static int
+g_Ctoc(const Char *str, char *buf, u_int len)
+{
+
+	while (len--) {
+		if ((*buf++ = *str++) == EOS)
+			return (0);
+	}
+	return (1);
+}
+
+#ifdef DEBUG
+static void
+qprintf(const char *str, Char *s)
+{
+	Char *p;
+
+	(void)printf("%s:\n", str);
+	for (p = s; *p; p++)
+		(void)printf("%c", CHAR(*p));
+	(void)printf("\n");
+	for (p = s; *p; p++)
+		(void)printf("%c", *p & M_PROTECT ? '"' : ' ');
+	(void)printf("\n");
+	for (p = s; *p; p++)
+		(void)printf("%c", ismeta(*p) ? '_' : ' ');
+	(void)printf("\n");
+}
+#endif
Index: xglob.h
===================================================================
RCS file: xglob.h
diff -N xglob.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ xglob.h	21 Jul 2008 13:11:46 -0000
@@ -0,0 +1,108 @@
+/*	$OpenBSD: glob.h,v 1.10 2005/12/13 00:35:22 millert Exp $	*/
+/*	$NetBSD: glob.h,v 1.5 1994/10/26 00:55:56 cgd Exp $	*/
+
+/*
+ * Copyright (c) 1989, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Guido van Rossum.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *	@(#)glob.h	8.1 (Berkeley) 6/2/93
+ */
+
+#ifndef _XGLOB_H_
+#define	_XGLOB_H_
+
+#include <sys/cdefs.h>
+
+struct xglob_entry {
+	char *gl_path;		/* Path name */
+	struct stat gl_stat;	/* Corresponding struct stat */
+};
+
+struct stat;
+typedef struct {
+	int gl_pathc;		/* Count of total paths so far. */
+	int gl_matchc;		/* Count of paths matching pattern. */
+	int gl_offs;		/* Reserved at beginning of gl_matchv. */
+	int gl_flags;		/* Copy of flags parameter to glob. */
+
+	struct xglob_entry *gl_matchv;
+				/* List of entries matching */
+
+	void *gl_user_ctx;	/* User context, also passed to ALTDIRFUNCs */
+
+	int (*gl_errfunc)(const char *, int);
+
+	/*
+	 * Alternate filesystem access methods for glob; replacement
+	 * versions of closedir(3), readdir(3), opendir(3), stat(2)
+	 * and lstat(2). These versions are passed xglob_t->gl_user_ctx
+	 * as their first arguments.
+	 */
+	void (*gl_closedir)(void *, void *);
+	struct dirent *(*gl_readdir)(void *, void *);
+	void *(*gl_opendir)(void *, const char *);
+	int (*gl_lstat)(void *, const char *, struct stat *);
+	int (*gl_stat)(void *, const char *, struct stat *);
+
+	/*
+	 * Alternate comparison function, used to qsort(3) gl_matchv.
+	 * if the XGLOB_ALTCMPFUNC option has been specified.
+	 * Arguments to the comparison function are both struct glob_entry *
+	 */
+	int (*gl_cmp)(const void *, const void *);
+} xglob_t;
+
+#define	XGLOB_APPEND	0x0001	/* Append to output from previous call. */
+#define	XGLOB_DOOFFS	0x0002	/* Use gl_offs. */
+#define	XGLOB_ERR	0x0004	/* Return on error. */
+#define	XGLOB_MARK	0x0008	/* Append / to matching directories. */
+#define	XGLOB_NOCHECK	0x0010	/* Return pattern itself if nothing matches. */
+#define	XGLOB_NOSORT	0x0020	/* Don't sort. */
+#define	XGLOB_NOESCAPE	0x1000	/* Disable backslash escaping. */
+
+#define	XGLOB_NOSPACE	(-1)	/* Malloc call failed. */
+#define	XGLOB_ABORTED	(-2)	/* Unignored error. */
+#define	XGLOB_NOMATCH	(-3)	/* No match and GLOB_NOCHECK not set. */
+#define	XGLOB_NOSYS	(-4)	/* Function not supported. */
+
+#define	XGLOB_ALTDIRFUNC 0x0040	/* Use alternately specified directory funcs. */
+#define	XGLOB_BRACE	0x0080	/* Expand braces ala csh. */
+#define	XGLOB_MAGCHAR	0x0100	/* Pattern had globbing characters. */
+#define	XGLOB_NOMAGIC	0x0200	/* GLOB_NOCHECK without magic chars (csh). */
+#define	XGLOB_QUOTE	0x0400	/* Quote special chars with \. */
+#define	XGLOB_TILDE	0x0800	/* Expand tilde names from the passwd file. */
+#define XGLOB_LIMIT	0x2000	/* Limit pattern match output to ARG_MAX */
+#define XGLOB_ALTCMPFUNC 0x4000	/* Use alternately specified comparison func */
+#define XGLOB_ABEND	GLOB_ABORTED /* backward compatibility */
+
+int	xglob(const char *, int, int (*)(const char *, int), xglob_t *);
+void	xglobfree(xglob_t *);
+
+#endif /* !_XGLOB_H_ */
Index: sftp/Makefile
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sftp/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- sftp/Makefile	18 Apr 2008 12:32:11 -0000	1.11
+++ sftp/Makefile	21 Jul 2008 13:11:46 -0000
@@ -10,7 +10,7 @@ BINMODE?=555
 BINDIR=	/usr/bin
 MAN=	sftp.1
 
-SRCS=	sftp.c sftp-client.c sftp-common.c sftp-glob.c
+SRCS=	sftp.c sftp-client.c sftp-common.c xglob.c sftp-glob.c
 
 .include <bsd.prog.mk>
 

From djm at mindrot.org  Mon Jul 21 23:25:10 2008
From: djm at mindrot.org (Damien Miller)
Date: Mon, 21 Jul 2008 23:25:10 +1000 (EST)
Subject: sftp needs a long time for sending a filelist
In-Reply-To: <OF2DFF9A2E.4FC8FC5D-ONC125748D.003AD32C-C125748D.003AD33E@idvnet.de>
References: <OF2DFF9A2E.4FC8FC5D-ONC125748D.003AD32C-C125748D.003AD33E@idvnet.de>
Message-ID: <alpine.BSO.1.10.0807212323390.22696@fuyu.mindrot.org>

On Mon, 21 Jul 2008, Markus W?nsch wrote:

> 
>    Hello all
>    Im using sftp 1:4.7p1-8ubuntu1.2
>    in a batchjob
>    Ive noticed that sftp needs a long time for sending a filelist.
>    The timespan increases exponential if many files are on the
>    remoteserver.
>    for example "ls -la *.txt" needs 10 seconds for 2000 files
>    but needs 50 seconds for 4000 files.
>    For 150.000 Files i have to wait 15 minutes for example
>    but the Conecction is very fast. I think the sftp-server needs this
>    time to
>    build the list.

I should also mention that there is a workaround: using "ls -1f" will
avoid the rountrip per filename.

-d

From djm at cvs.openbsd.org  Tue Jul 22 10:11:48 2008
From: djm at cvs.openbsd.org (Damien Miller)
Date: Mon, 21 Jul 2008 18:11:48 -0600 (MDT)
Subject: Announce: OpenSSH 5.1 released
Message-ID: <200807220011.m6M0Bm3P031514@cvs.openbsd.org>

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

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We have also recently completed another Internet SSH usage scan, the 
results of which may be found at http://www.openssh.com/usage.html

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Changes since OpenSSH 5.0
=========================

Security:

 * sshd(8): Avoid X11 man-in-the-middle attack on HP/UX (and possibly
   other platforms) when X11UseLocalhost=no

   When attempting to bind(2) to a port that has previously been bound
   with SO_REUSEADDR set, most operating systems check that either the
   effective user-id matches the previous bind (common on BSD-derived
   systems) or that the bind addresses do not overlap (Linux and
   Solaris).

   Some operating systems, such as HP/UX, do not perform these checks
   and are vulnerable to an X11 man-in-the-middle attack when the
   sshd_config(5) option X11UseLocalhost has been set to "no" - an
   attacker may establish a more-specific bind, which will be used in
   preference to sshd's wildcard listener.

   Modern BSD operating systems, Linux, OS X and Solaris implement the
   above checks and are not vulnerable to this attack, nor are systems
   where the X11UseLocalhost has been left at the default value of
   "yes".

   Portable OpenSSH 5.1 avoids this problem for all operating systems
   by not setting SO_REUSEADDR when X11UseLocalhost is set to no.

   This vulnerability was reported by sway2004009 AT hotmail.com.

New features:

 * Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1)
   and ssh-keygen(1). Visual fingerprinnt display is controlled by a new
   ssh_config(5) option "VisualHostKey". The intent is to render
   SSH host keys in a visual form that is amenable to easy recall and
   rejection of changed host keys. This technique inspired by the
   graphical hash visualisation schemes known as "random art[*]", and
   by Dan Kaminsky's musings at 23C3 in Berlin.

   Fingerprint visualisation in is currently disabled by default, as the
   algorithm used to generate the random art is still subject to change.

   [*] "Hash Visualization: a New Technique to improve Real-World
       Security", Perrig A. and Song D., 1999, International Workshop on
       Cryptographic Techniques and E-Commerce (CrypTEC '99)
   http://sparrow.ece.cmu.edu/~adrian/projects/validation/validation.pdf

 * sshd_config(5) now supports CIDR address/masklen matching in "Match
   address" blocks, with a fallback to classic wildcard matching. For 
   example:
     Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*
         PasswordAuthentication yes

 * sshd(8) now supports CIDR matching in ~/.ssh/authorized_keys
   from="..." restrictions, also with a fallback to classic wildcard
   matching.

 * Added an extended test mode (-T) to sshd(8) to request that it write
   its effective configuration to stdout and exit. Extended test mode
   also supports the specification of connection parameters (username,
   source address and hostname) to test the application of
   sshd_config(5) Match rules. 

 * ssh(1) now prints the number of bytes transferred and the overall
   connection throughput for SSH protocol 2 sessions when in verbose
   mode (previously these statistics were displayed for protocol 1
   connections only).

 * sftp-server(8) now supports extension methods statvfs at openssh.com and
   fstatvfs at openssh.com that implement statvfs(2)-like operations.
   (bz#1399)

 * sftp(1) now has a "df" command to the sftp client that uses the
   statvfs at openssh.com to produce a df(1)-like display of filesystem
   space and inode utilisation (requires statvfs at openssh.com support on
   the server)

 * Added a MaxSessions option to sshd_config(5) to allow control of the
   number of multiplexed sessions supported over a single TCP connection.
   This allows increasing the number of allowed sessions above the
   previous default of 10, disabling connection multiplexing 
   (MaxSessions=1) or disallowing login/shell/subsystem sessions
   entirely (MaxSessions=0).

 * Added a no-more-sessions at openssh.com global request extension that is
   sent from ssh(1) to sshd(8) when the client knows that it will never
   request another session (i.e. when session multiplexing is disabled). 
   This allows a server to disallow further session requests and
   terminate the session in cases where the client has been hijacked.

 * ssh-keygen(1) now supports the use of the -l option in combination
   with -F to search for a host in ~/.ssh/known_hosts and display its 
   fingerprint.

 * ssh-keyscan(1) now defaults to "rsa" (protocol 2) keys, instead of
   "rsa1".

 * Added an AllowAgentForwarding option to sshd_config(8) to control
   whether authentication agent forwarding is permitted. Note that this
   is a loose control, as a client may install their own unofficial
   forwarder.

 * ssh(1) and sshd(8): avoid unnecessary malloc/copy/free when receiving
   network data, resulting in a ~10% speedup

 * ssh(1) and sshd(8) will now try additional addresses when connecting
   to a port forward destination whose DNS name resolves to more than
   one address. The previous behaviour was to try the only first address
   and give up if that failed. (bz#383)

 * ssh(1) and sshd(8) now support signalling that channels are
   half-closed for writing, through a channel protocol extension
   notification "eow at openssh.com". This allows propagation of closed
   file descriptors, so that commands such as:
       "ssh -2 localhost od /bin/ls | true"
   do not send unnecessary data over the wire. (bz#85)

 * sshd(8): increased the default size of ssh protocol 1 ephemeral keys 
   from 768 to 1024 bits.

 * When ssh(1) has been requested to fork after authentication
   ("ssh -f") with ExitOnForwardFailure enabled, delay the fork until
   after replies for any -R forwards have been seen. Allows for robust
   detection of -R forward failure when using -f. (bz#92)

 * "Match group" blocks in sshd_config(5) now support negation of
   groups. E.g. "Match group staff,!guests" (bz#1315)

 * sftp(1) and sftp-server(8) now allow chmod-like operations to set 
   set[ug]id/sticky bits. (bz#1310)

 * The MaxAuthTries option is now permitted in sshd_config(5) match
   blocks.

 * Multiplexed ssh(1) sessions now support a subset of the ~ escapes
   that are available to a primary connection. (bz#1331)

 * ssh(1) connection multiplexing will now fall back to creating a new
   connection in most error cases. (bz#1439 bz#1329)

 * Added some basic interoperability tests against Twisted Conch.

 * Documented OpenSSH's extensions to and deviations from the published
   SSH protocols (the PROTOCOL file in the distribution)

 * Documented OpenSSH's ssh-agent protocol (PROTOCOL.agent).

Bug and documentation fixes

 * Make ssh(1) deal more gracefully with channel requests that fail.
   Previously it would optimistically assume that requests would always 
   succeed, which could cause hangs if they did not (e.g. when the
   server runs out of file descriptors). (bz#1384)

 * ssh(1) now reports multiplexing errors via the multiplex slave's
   stderr where possible (subject to LogLevel in the mux master).

 * ssh(1) and sshd(8) now send terminate protocol banners with CR+LF for
   protocol 2 to comply with RFC 4253. Previously they were terminated
   with CR alone. Protocol 1 banners remain CR terminated. (bz#1443)

 * Merged duplicate authentication file checks in sshd(8) and refuse to
   read authorised_keys and .shosts from non-regular files. (bz#1438)

 * Ensure that sshd(8)'s umask disallows at least group and world write,
   even if a more permissive one has been inherited. (bz#1433)

 * Suppress the warning message from sshd(8) when changing to a
   non-existent user home directory after chrooting. (bz#1461)

 * Mention that scp(1) follows symlinks when performing recursive
   copies. (bz#1466)

 * Prevent sshd(8) from erroneously applying public key restrictions
   leaned from ~/.ssh/authorized_keys to other authentication methods
   when public key authentication subsequently fails. (bz#1472)

 * Fix protocol keepalive timeouts - in some cases, keepalive packets
   were being sent, but the connection was not being closed when the
   limit for missing replies was exceeded. (bz#1465)

 * Fix ssh(1) sending invalid TTY modes when a TTY was forced (ssh -tt)
   but stdin was not a TTY. (bz#1199)

 * ssh(1) will now exit with a non-zero exit status if
   ExitOnForwardFailure was set and forwardings were disabled due to a
   failed host key check.

 * Fix MaxAuthTries tests to disallow a free authentication try to
   clients that skipped the protocol 2 "none" authentication method.
   (part of bz#1432)

 * Make keepalive timeouts apply while synchronously waiting
   for a packet, particularly during key renegotiation. (bz#1363)

 * sshd(8) has been audited to eliminate fd leaks and calls to fatal()
   in conditions of file descriptor exhaustion.

Portable OpenSSH-specific bugfixes

 * Avoid a sshd(8) hang-on-exit on Solaris caused by depending on the 
   success of isatty() on a PTY master (undefined behaviour). Probably 
   affected other platforms too. (bz#1463)

 * Fixed test for locked accounts on HP/UX with shadowed
   passwords disabled. (bz#1083)

 * Disable poll() fallback in atomiciov for Tru64. readv
   doesn't seem to be a comparable object there, which lead to
   compilation errors. (bz#1386)

 * Fall back to racy rename if link returns EXDEV. (bz#1447)

 * Explicitly handle EWOULDBLOCK wherever we handle EAGAIN, on
   some platforms (HP nonstop) it is a distinct errno. (bz#1467)

 * Avoid NULL dereferences in ancient sigaction replacement
   code. (bz#1240)

 * Avoid linking against libgssapi, which despite its name
   doesn't seem to implement all of GSSAPI. (bz#1276)

 * Use explicit noreturn attribute instead of __dead, fixing
   compilation problems on Interix. (bz#1112)

 * Added support password expiry on Tru64 SIA systems. (bz#1241)

 * Fixed an UMAC alignment problem that manifested on Itanium 
   platforms. (bz#1462)

 * The sftp-server(8) manual now describes the requirements for
   transfer logging in chroot environments. (bz#1488)

 * Strip trailing dot from hostnames when the sshd_config(5)
   HostbasedUsesNameFromPacketOnly option is set. (bz#1200)
   
Checksums:
==========

 - SHA1 (openssh-5.1.tar.gz) = 1e5b43844ed015e4fbbbe25cfad6f5377c60e759
 - SHA1 (openssh-5.1p1.tar.gz) = 877ea5b283060fe0160e376ea645e8e168047ff5

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh at openssh.com

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


From rapier at psc.edu  Wed Jul 23 06:48:44 2008
From: rapier at psc.edu (rapier)
Date: Tue, 22 Jul 2008 16:48:44 -0400
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <864p6ksbcs.fsf@ds4.des.no>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>	<863amin6qd.fsf@ds4.des.no>
	<4875236E.5020006@psc.edu> <864p6ksbcs.fsf@ds4.des.no>
Message-ID: <488647AC.7060006@psc.edu>


Dag-Erling Sm?rgrav wrote:
> rapier <rapier at psc.edu> writes:
>> Dag-Erling Sm?rgrav <des at des.no> writes:
>>> Last I checked, it's still there; you just need to add "none" to the
>>> list of accepted ciphers in myproposal.h.
>> The problem is that just adding 'none' back pushes all interaction into 
>> the clear [...]
> 
> No, adding "none" to the list makes it available, but not the default -
> unless you add it to the front of the list.

My apologies for not being clear. Let me try again.

If you simply add 'none' to the list and both sides of the connection 
agree to use none then all transactions for that connection, including 
authentication, happen in the clear. This is obviously unacceptable. 
This is why we developed the cipher switching patch. This allows for 
cipher used to be change midstream - which allows for encrypted 
authentication and unencrypted bulk data transport.






From des at des.no  Wed Jul 23 18:51:53 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 23 Jul 2008 10:51:53 +0200
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <488647AC.7060006@psc.edu> (rapier@psc.edu's message of "Tue\, 22
	Jul 2008 16\:48\:44 -0400")
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
	<864p6ksbcs.fsf@ds4.des.no> <488647AC.7060006@psc.edu>
Message-ID: <86myk9t23a.fsf@ds4.des.no>

rapier <rapier at psc.edu> writes:
> If you simply add 'none' to the list and both sides of the connection
> agree to use none then all transactions for that connection, including
> authentication, happen in the clear. This is obviously
> unacceptable.

Depends on the context.  I rarely use the "none" cipher, and haven't in
a while, but it has always been on a trusted network, between two
servers connected to the same switch.  I would never use the "none"
cipher over an untrusted link, even if only for "bulk data transport".

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From dbeecher at dmsgs.com  Wed Jul 23 23:40:20 2008
From: dbeecher at dmsgs.com (David Beecher)
Date: Wed, 23 Jul 2008 09:40:20 -0400
Subject: remove
In-Reply-To: <20080723072248.4B8D069CC5@natsu.mindrot.org>
References: <bug-1490-705@http.bugzilla.mindrot.org/>
	<20080723072248.4B8D069CC5@natsu.mindrot.org>
Message-ID: <488734C4.1050802@dmsgs.com>

remove
unsubscribe

bugzilla-daemon at bugzilla.mindrot.org wrote:
> https://bugzilla.mindrot.org/show_bug.cgi?id=1490
>
>
> Darren Tucker <dtucker at zip.com.au> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          AssignedTo|unassigned-bugs at mindrot.org |dtucker at zip.com.au
>
>
>
>
> --- Comment #2 from Darren Tucker <dtucker at zip.com.au>  2008-07-23 17:22:44 ---
> Created an attachment (id=1549)
>  --> (http://bugzilla.mindrot.org/attachment.cgi?id=1549)
> #ifdef out config dump options based on build-time config
>
> Agreed, that's what it is.  Please try this patch.
>
> I should have had a regress test for this.
>
>   

-- 

David Beecher, Executive Vice President and Chief Technical Officer
Digital Messaging Solutions, Inc.
678.446.3050 voice   866.881.7081 fax
http://www.dmsgs.com
We appreciate your business!

This e-mail may contain data that is confidential, proprietary or
"non-public personal information," as that term is defined in the
Gramm-Leach-Bliley Act (collectively, "Confidential Information"). The
Confidential Information is disclosed conditioned upon your agreement that
you will treat it confidentially and in accordance with applicable law,
ensure that such data isn't used or disclosed except for the limited purpose
for which it's being provided and will notify and cooperate with us
regarding any requested or unauthorized disclosure or use of any
Confidential Information. By accepting and reviewing the Confidential
Information you agree to indemnify us against any losses or expenses,
including attorney's fees that we may incur as a result of any unauthorized
use or disclosure of this data due to your acts or omissions. If a party
other than the intended recipient receives this e-mail, you are requested to
instantly notify us of the erroneous delivery and return to us all data so
delivered.



From rapier at psc.edu  Thu Jul 24 02:10:58 2008
From: rapier at psc.edu (rapier)
Date: Wed, 23 Jul 2008 12:10:58 -0400
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <86myk9t23a.fsf@ds4.des.no>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>	<863amin6qd.fsf@ds4.des.no>
	<4875236E.5020006@psc.edu>	<864p6ksbcs.fsf@ds4.des.no>
	<488647AC.7060006@psc.edu> <86myk9t23a.fsf@ds4.des.no>
Message-ID: <48875812.1070006@psc.edu>



Dag-Erling Sm?rgrav wrote:

> Depends on the context.  I rarely use the "none" cipher, and haven't in
> a while, but it has always been on a trusted network, between two
> servers connected to the same switch.  I would never use the "none"
> cipher over an untrusted link, even if only for "bulk data transport".

There are times in which en clear authentication is acceptable but I 
find it probably better to treat every network as not being trust 
worthy. However, I do think there are many times in which is perfectly 
acceptable to transfer bulk data en clear - most data is not sensitive 
to the point where leaking it would prove to be problematic. For 
example, if you are transferring a hundred terabytes of weather station 
data to a supercomputing site for storm analysis (which is the class of 
user I write for) the data isn't sensitive at all. Primary concerns 
would be the speed of the transfer and meeting the required security 
aspects (authentication, data integrity). This is why the majority of 
the high performance bulk data transfer applications - like kftp, 
gridftp, bbftp, and so forth don't encrypt the data but use strong 
security on the authentication.

However, there are time when this is unacceptable - which is why we 
developed a multi-threaded aes-ctr cipher. We've been able to get 
900Mb/s transatlantic with aes256 that way.

Also, I'm thinking that you actually do unencrypted bulk data transfer 
over untrusted links. I know I just did it a few minutes ago when I got 
the 5.1 OpenSSH distribution from a mirror site.

From des at des.no  Thu Jul 24 02:17:08 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 23 Jul 2008 18:17:08 +0200
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <48875812.1070006@psc.edu> (rapier@psc.edu's message of "Wed\, 23
	Jul 2008 12\:10\:58 -0400")
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>
	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>
	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>
	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>
	<863amin6qd.fsf@ds4.des.no> <4875236E.5020006@psc.edu>
	<864p6ksbcs.fsf@ds4.des.no> <488647AC.7060006@psc.edu>
	<86myk9t23a.fsf@ds4.des.no> <48875812.1070006@psc.edu>
Message-ID: <8663qwshh7.fsf@ds4.des.no>

rapier <rapier at psc.edu> writes:
> Dag-Erling Sm?rgrav <des at des.no> writes:
> > Depends on the context.  I rarely use the "none" cipher, and haven't in
> > a while, but it has always been on a trusted network, between two
> > servers connected to the same switch.  I would never use the "none"
> > cipher over an untrusted link, even if only for "bulk data transport".
> [...]
> Also, I'm thinking that you actually do unencrypted bulk data transfer
> over untrusted links. I know I just did it a few minutes ago when I
> got the 5.1 OpenSSH distribution from a mirror site.

This is a strawman.  I did not claim that I never "do unencrypted bulk
data transfer over untrusted links", only that I never use ssh with the
"none" cipher over an untrusted link.

The authenticity and integrity of the tarball you downloaded can be
verified through other means; this is why the tarball is crypto-
graphically signed.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From rapier at psc.edu  Thu Jul 24 02:38:07 2008
From: rapier at psc.edu (rapier)
Date: Wed, 23 Jul 2008 12:38:07 -0400
Subject: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing
In-Reply-To: <8663qwshh7.fsf@ds4.des.no>
References: <alpine.BSO.1.10.0807070850180.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807080846480.27511@wapiti2.we7u.net>	<alpine.BSO.1.10.0807091044350.22609@fuyu.mindrot.org>	<alpine.LNX.1.10.0807090640420.16015@wapiti2.we7u.net>	<alpine.BSO.1.00.0807091112160.30973@miyako.eviladmin.org>	<863amin6qd.fsf@ds4.des.no>
	<4875236E.5020006@psc.edu>	<864p6ksbcs.fsf@ds4.des.no>
	<488647AC.7060006@psc.edu>	<86myk9t23a.fsf@ds4.des.no>
	<48875812.1070006@psc.edu> <8663qwshh7.fsf@ds4.des.no>
Message-ID: <48875E6F.5050700@psc.edu>



Dag-Erling Sm?rgrav wrote:
> rapier <rapier at psc.edu> writes:
>> Dag-Erling Sm?rgrav <des at des.no> writes:
>>> Depends on the context.  I rarely use the "none" cipher, and haven't in
>>> a while, but it has always been on a trusted network, between two
>>> servers connected to the same switch.  I would never use the "none"
>>> cipher over an untrusted link, even if only for "bulk data transport".
>> [...]
>> Also, I'm thinking that you actually do unencrypted bulk data transfer
>> over untrusted links. I know I just did it a few minutes ago when I
>> got the 5.1 OpenSSH distribution from a mirror site.
> 
> This is a strawman.  I did not claim that I never "do unencrypted bulk
> data transfer over untrusted links", only that I never use ssh with the
> "none" cipher over an untrusted link.

I'm sorry if it came across that way. It wasn't intentional and I'm 
really not trying to start an argument. I was actually trying to make 
the point that some data isn't seen as being important enough to 
transfer encrypted. I personally feel that if data isn't worth 
encrypting its not worth encrypting regardless of the transport 
mechanism being used. Personally, I'd prefer if all data was encrypted 
at all times as a matter of course. Unfortunately, thats just not 
feasible with the current paradigms/infrastructure available. It 
probably going to become less so over time to be honest.

From kkaur5 at csc.com  Thu Jul 24 23:29:24 2008
From: kkaur5 at csc.com (Kawaljeet Kaur)
Date: Thu, 24 Jul 2008 18:59:24 +0530
Subject: Openssh xauth on Solaris
Message-ID: <OF5B3E9922.287BC56A-ON65257490.0044C97D-65257490.0049A731@csc.com>

Hi All,

I have a query..

How to build the sshd_config file with all the possible parameters set to 
their default values.?

For eg:
When I compile any version of Openssh and run make install, the 
sshd_config file that gets copied to the directory specified by 
"--sysconfigdir=" flag does not contain the parameter "XAuthLocation" at 
all

Whereas the sshd_config.5 man file copied in the man/man5 directory does 
contain information about default value , but not in a very legible manner 
as given below:

 more /opt/soe/local/openssh-4.7p1/share/man/man5/sshd_config.5
\fBXAuthLocation\fP
Specifies the full pathname of the
\fBxauth\fP(1)
program.
The default is
\fI/usr/openwin/bin/xauth\fP.

Please guide me with  the procedure to prepare a sshd_config file 
automatically which contains all the possible parameters with their 
default values and please do correct me if i am wrong somewhere.




Thanks and Regards,
Kawaljeet Kaur
UnixSOE
GST

Computer Sciences Corporation India Private Limited
Registered Office: Electronics Complex, Software Technology Park, Indore, 
Madhya Pradesh, India
Registered in India No: 10-11210

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

From Frank_LaMon at CSX.com  Sat Jul 26 00:09:17 2008
From: Frank_LaMon at CSX.com (Lamon, Frank III)
Date: Fri, 25 Jul 2008 10:09:17 -0400
Subject: SSH authentication order on AIX
Message-ID: <AD69503BEBC6D1498DCABE5A82A9F0F11641BF51@TJAX2736EXCH.csxt.ad.csx.com>

I'm trying to get to the bottom of an issue with key authentication on
AIX and I'm not sure I believe IBM's answer so I thought I'd post here
to see what answer I'd get from the SSH side.

We have three different methods of authentication - local, VAS (AD),
NIS. On our Linux and Solaris servers it's very simple to set the
authentication order with nsswitch.conf and SSH follows that order on
those systems without any issues - even with key-authentication. On AIX
however if we use key-authentication it always hits NIS before VAS. IBM
is telling us that it is because that's how SSH works and we keep trying
to tell them that it doesn't work like that anywhere else - only on AIX.
It's my understanding that SHH will authenticate in the order
established by the OS and not vice-versa - is this thinking correct? 

We have workarounds for the issue, but we'd like to have IBM own up to
what we perceive as a flaw in their authentication model instead of
blaming it on how SSH works.

Here is the latest from their developers:

"Discussed about the SSH design.
As we are copying the public key in the /home/(user). So in this case
authentication is done by the SSH Server. But in case of password
authenticationNIS server or VAS server is doing the authentication.
Therefore in the password case it is able to differentiate between NIS
and VAS user.
But  in case of Public Key Authentication it is first taking the NIS
user and then server is doing the authentication.
So it is not able to differentiate  between the two users in case of
PUBLIC KEY AUTHENTICATION."

My belief is even with key-authentication SSH still has to have the user
account validated by the OS and that the order in which this validation
will occur is determined by the OS not the SSH server. At least this is
what happens on our other operating systems - we can switch the
authentication order and it will authenticate to which ever option is
first.

Thanks,
Frank LaMon 

-----------------------------------------
This email transmission and any accompanying attachments may
contain CSX privileged and confidential information intended only
for the use of the intended addressee.  Any dissemination,
distribution, copying or action taken in reliance on the contents
of this email by anyone other than the intended recipient is
strictly prohibited.  If you have received this email in error
please immediately delete it and  notify sender at the above CSX
email address.  Sender and CSX accept no liability for any damage
caused directly or indirectly by receipt of this email.

From Jason.C.Burns at wellsfargo.com  Sat Jul 26 06:11:23 2008
From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com)
Date: Fri, 25 Jul 2008 15:11:23 -0500
Subject: SSH authentication order on AIX
References: <AD69503BEBC6D1498DCABE5A82A9F0F11641BF51@TJAX2736EXCH.csxt.ad.csx.com>
Message-ID: <F5D8B3CDB523D94BAE9342E416E63BC8034F6416@msgswbiadsm25.wellsfargo.com>

Frank,

I don't know if this is the correct list for this question (you are correct,
it is an OS issue, not an ssh one), but just as a quick answer to your
question, you should be able to define the order in /etc/security/user in
the "default" stanza.  Look for the value of "SYSTEM".  If you are using
Quest's VAS product, it should say something like "VAS or compat".  This
will normally tell the OS to try the VAS module first, then the compat
module (which is shorthand for "NIS OR files" or "files OR NIS" I can't
remember the order off the top of my head).  You should be able to switch to
"compat OR VAS" if you want local and NIS users to be tried before VAS users
and vice versa.

Jason Burns
Information Security Technology
Cryptography Services -> Secure Communications and Data Encryption 

> -----Original Message-----
> 
> I'm trying to get to the bottom of an issue with key 
> authentication on AIX and I'm not sure I believe IBM's answer 
> so I thought I'd post here to see what answer I'd get from 
> the SSH side.
> 
> We have three different methods of authentication - local, 
> VAS (AD), NIS. On our Linux and Solaris servers it's very 
> simple to set the authentication order with nsswitch.conf and 
> SSH follows that order on those systems without any issues - 
> even with key-authentication. On AIX however if we use 
> key-authentication it always hits NIS before VAS. IBM is 
> telling us that it is because that's how SSH works and we 
> keep trying to tell them that it doesn't work like that 
> anywhere else - only on AIX.
> It's my understanding that SHH will authenticate in the order 
> established by the OS and not vice-versa - is this thinking correct? 
> 
> We have workarounds for the issue, but we'd like to have IBM 
> own up to what we perceive as a flaw in their authentication 
> model instead of blaming it on how SSH works.
> 
> Here is the latest from their developers:
> 
> "Discussed about the SSH design.
> As we are copying the public key in the /home/(user). So in 
> this case authentication is done by the SSH Server. But in 
> case of password authenticationNIS server or VAS server is 
> doing the authentication.
> Therefore in the password case it is able to differentiate 
> between NIS and VAS user.
> But  in case of Public Key Authentication it is first taking 
> the NIS user and then server is doing the authentication.
> So it is not able to differentiate  between the two users in 
> case of PUBLIC KEY AUTHENTICATION."
> 
> My belief is even with key-authentication SSH still has to 
> have the user account validated by the OS and that the order 
> in which this validation will occur is determined by the OS 
> not the SSH server. At least this is what happens on our 
> other operating systems - we can switch the authentication 
> order and it will authenticate to which ever option is first.
> 
> Thanks,
> Frank LaMon 
> 
> -----------------------------------------
> This email transmission and any accompanying attachments may 
> contain CSX privileged and confidential information intended 
> only for the use of the intended addressee.  Any 
> dissemination, distribution, copying or action taken in 
> reliance on the contents of this email by anyone other than 
> the intended recipient is strictly prohibited.  If you have 
> received this email in error please immediately delete it and 
>  notify sender at the above CSX email address.  Sender and 
> CSX accept no liability for any damage caused directly or 
> indirectly by receipt of this email.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5659 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080725/7a8a2900/attachment-0001.bin 

From bruce.korb at gmail.com  Sat Jul 26 10:08:50 2008
From: bruce.korb at gmail.com (Bruce Korb)
Date: Fri, 25 Jul 2008 17:08:50 -0700
Subject: Still no joy:  no X11 protocols
Message-ID: <488A6B12.3030704@gmail.com>

Hello,

I know this is likely to give me a brute force attack hit,
but the only thing anyone can accomplish by ssh-ing to my machine
is to provide me with a tunnel into your machine.  So don't bother.

Anyway, my server machine is running this:

/usr/bin/ssh -X -R ${port}:localhost:22 -o BatchMode=yes \
  -o StrictHostKeyChecking=no ${user}@${my_home_machine}

On my local machine:

ssh -vvv -X -p ${port} localhost

Attached is the output, below is the X11 stuff.  What's wrong?
Thank you in advance.  Regards, Bruce

====

Here is the typical symptom, running X app on the server through the tunnel:
> X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
>   Major opcode of failed request:  55 (X_CreateGC)
>   Resource id in failed request:  0x1a6
>   Serial number of failed request:  1
>   Current serial number in output stream:  4
or something similar.

Here is a new symptom ($DISPLAY is not set):
 > xterm -T "S043-1 via telnet bignts17 5010" -e telnet bignts17 5010
 > xterm Xt error: Can't open display:

And the config files, first from the server (work) machine:

> # for f in /etc/ssh/ssh*_config;do echo $f;egrep -v $'^[ \t]*(#|$)' $f ;done

> /etc/ssh/ssh_config
> Host *
> ForwardX11 no
> ForwardX11Trusted yes
>     Protocol 2
> SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> SendEnv LC_IDENTIFICATION LC_ALL

> /etc/ssh/sshd_config
> Protocol 2
> PasswordAuthentication no
> UsePAM yes
> X11Forwarding yes
> Subsystem       sftp    /usr/lib64/ssh/sftp-server
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL

And then from home:

> /etc/ssh/ssh_config
> Host *
> ForwardX11Trusted yes
>     Protocol 2
> SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> SendEnv LC_IDENTIFICATION LC_ALL

> /etc/ssh/sshd_config
> Protocol 2
> HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_dsa_key
> TCPKeepAlive yes
> ClientAliveInterval 30
> ClientAliveCountMax 99999
> PasswordAuthentication no
> ChallengeResponseAuthentication no
> UsePAM no
> X11Forwarding yes
> AllowUsers ${user}
> Subsystem       sftp    /usr/lib64/ssh/sftp-server
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL

And finally the debug output:

debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ZCkLTd4136/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ZCkLTd4136/xauthfile list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
....
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 55024
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd eof
....
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
   #0 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
   #1 x11 (t4 r2 i3/0 o3/0 fd 9/9 cfd -1)

debug3: channel 1: close_fds r 9 w 9 e -1 c -1
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 55025
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
.....
debug3: channel 1: will not send data after close
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 55026
debug2: fd 10 setting O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
....
debug1: channel 1: free: x11, nchannels 3
debug3: channel 1: status: The following connections are open:
   #0 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
   #1 x11 (t4 r2 i3/0 o3/0 fd 9/9 cfd -1)
   #2 x11 (t7 r3 i0/0 o0/0 fd 10/10 cfd -1)
....
debug1: channel 2: free: x11, nchannels 2
debug3: channel 2: status: The following connections are open:
   #0 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
   #2 x11 (t4 r3 i3/0 o3/0 fd 10/10 cfd -1)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssh-connect.txt
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080725/f998c15a/attachment.txt 

From Dippen.Patel at motorola.com  Mon Jul 28 12:53:04 2008
From: Dippen.Patel at motorola.com (Patel Dippen-CDP054)
Date: Sun, 27 Jul 2008 22:53:04 -0400
Subject: Openssh for Windows
Message-ID: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>

Is there a OpenSSH server version for Windows 2003 Server? The only
OpenSSH server for Windows I found is version v3.8.1p1-1. However, this
is ONLY supported on Windows NT.
Is there any other openware SSH Server for Windows 2003 Server?

From mouring at eviladmin.org  Mon Jul 28 23:54:16 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Mon, 28 Jul 2008 08:54:16 -0500 (CDT)
Subject: Openssh for Windows
In-Reply-To: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
Message-ID: <alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>


The only other OpenSSH based server would be part of Cygwin.  Otherwise 
VanDyke has a nice native commerical SSH server.

- Ben

On Sun, 27 Jul 2008, Patel Dippen-CDP054 wrote:

> Is there a OpenSSH server version for Windows 2003 Server? The only
> OpenSSH server for Windows I found is version v3.8.1p1-1. However, this
> is ONLY supported on Windows NT.
> Is there any other openware SSH Server for Windows 2003 Server?
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From Dippen.Patel at motorola.com  Tue Jul 29 00:01:51 2008
From: Dippen.Patel at motorola.com (Patel Dippen-CDP054)
Date: Mon, 28 Jul 2008 10:01:51 -0400
Subject: Openssh for Windows
In-Reply-To: <alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
Message-ID: <B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>

So basically, I have to download and install Cygwin from
http://cygwin.com/. Does this install the complete Cygwin or just a
small portion like the v3.8.1p1-1 below?

Are there security issues related to using Cygwin itself? The v3.8.1p1-1
version has a Readme that states that Cygwin uses shared memory to store
process information that is not protected.

How safe is the VanDyke version?

Could I use either of these on high security/ mission critical systems?

I have Windows Services running on different Windows machines and they
talk to each other. I need to protect the communication between these 2
services. One approach is using SSL. I am trying to investigate the
feasibility of using SSH tunnels so that I do NOT have to modify the
Applications.

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at eviladmin.org] 
Sent: Monday, July 28, 2008 8:54 AM
To: Patel Dippen-CDP054
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Openssh for Windows


The only other OpenSSH based server would be part of Cygwin.  Otherwise
VanDyke has a nice native commerical SSH server.

- Ben

On Sun, 27 Jul 2008, Patel Dippen-CDP054 wrote:

> Is there a OpenSSH server version for Windows 2003 Server? The only 
> OpenSSH server for Windows I found is version v3.8.1p1-1. However, 
> this is ONLY supported on Windows NT.
> Is there any other openware SSH Server for Windows 2003 Server?
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From harald.dunkel at aixigo.de  Tue Jul 29 00:33:05 2008
From: harald.dunkel at aixigo.de (Harald Dunkel)
Date: Mon, 28 Jul 2008 16:33:05 +0200
Subject: Openssh for Windows
In-Reply-To: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
Message-ID: <488DD8A1.90406@aixigo.de>

You might want to consider to use Microsoft's Services For Unix.
A nice OpenSSH implementation (client and server, including
public-key authentications!) is provided by Interopsystems. Some
links:

	http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
	http://www.interopsystems.com/community/default.htm
	http://debian-interix.net/

The Debian page provides a highly recommended list of patches
to install.


Good luck

Harri


From chris at qwirx.com  Tue Jul 29 00:52:33 2008
From: chris at qwirx.com (Chris Wilson)
Date: Mon, 28 Jul 2008 15:52:33 +0100 (BST)
Subject: Openssh for Windows
In-Reply-To: <B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
Message-ID: <Pine.LNX.4.64.0807281551250.5696@top.qwarx.com>

Hi Patel,

On Mon, 28 Jul 2008, Patel Dippen-CDP054 wrote:

> I have Windows Services running on different Windows machines and they
> talk to each other. I need to protect the communication between these 2
> services. One approach is using SSL. I am trying to investigate the
> feasibility of using SSH tunnels so that I do NOT have to modify the
> Applications.

IPSec is probably the best tool for this job. Adding SSH tunneling and
port forwarding to the mix will only complicate matters, probably not
perform as well, and subtly changes semantics of things like connect()
which could break your application in odd ways.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | We are GNU : free your mind & your software |

From Dippen.Patel at motorola.com  Tue Jul 29 01:08:08 2008
From: Dippen.Patel at motorola.com (Patel Dippen-CDP054)
Date: Mon, 28 Jul 2008 11:08:08 -0400
Subject: Openssh for Windows
In-Reply-To: <Pine.LNX.4.64.0807281551250.5696@top.qwarx.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
	<Pine.LNX.4.64.0807281551250.5696@top.qwarx.com>
Message-ID: <B064CD283C01A646BD35F603F2653EAF0279D216@de01exm66.ds.mot.com>

Chris,

Agree. Our proposal is to use SSL natively (IPSec creates other problems
for us). However, I have to provde some analysis on why SSH is not
suitable. Believe the lack of a openware, stable and secured SSH server
for Windows itself suffices.

-Dippen

-----Original Message-----
From: Chris Wilson [mailto:chris at qwirx.com] 
Sent: Monday, July 28, 2008 9:53 AM
To: Patel Dippen-CDP054
Cc: Ben Lindstrom; openssh-unix-dev at mindrot.org
Subject: RE: Openssh for Windows

Hi Patel,

On Mon, 28 Jul 2008, Patel Dippen-CDP054 wrote:

> I have Windows Services running on different Windows machines and they

> talk to each other. I need to protect the communication between these 
> 2 services. One approach is using SSL. I am trying to investigate the 
> feasibility of using SSH tunnels so that I do NOT have to modify the 
> Applications.

IPSec is probably the best tool for this job. Adding SSH tunneling and
port forwarding to the mix will only complicate matters, probably not
perform as well, and subtly changes semantics of things like connect()
which could break your application in odd ways.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/
,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \
_/_/_/_//_/___/ | We are GNU : free your mind & your software |

From stuge-openssh-unix-dev at cdy.org  Tue Jul 29 01:08:17 2008
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Mon, 28 Jul 2008 17:08:17 +0200
Subject: Openssh for Windows
In-Reply-To: <B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
Message-ID: <20080728150817.32509.qmail@cdy.org>

On Mon, Jul 28, 2008 at 10:01:51AM -0400, Patel Dippen-CDP054 wrote:
.. Cygwin / VanDyke
> 
> Could I use either of these on high security/ mission critical systems?

One advantage for the open source alternative is that you are able to
find the answer for this question out for yourself, rather than
having to rely on what a vendor tells you.


> I have Windows Services running on different Windows machines and
> they talk to each other. I need to protect the communication
> between these 2 services.

As others mentioned, an actual VPN product is much more suitable for
this task. I recommend the open source product OpenVPN which runs
very well also on Windows. Please see http://openvpn.net/


//Peter

From vinschen at redhat.com  Tue Jul 29 01:11:56 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 28 Jul 2008 17:11:56 +0200
Subject: Openssh for Windows
In-Reply-To: <488DD8A1.90406@aixigo.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
Message-ID: <20080728151156.GB23519@calimero.vinschen.de>

On Jul 28 16:33, Harald Dunkel wrote:
> You might want to consider to use Microsoft's Services For Unix.
> A nice OpenSSH implementation (client and server, including
> public-key authentications!) is provided by Interopsystems. Some

Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From mouring at eviladmin.org  Tue Jul 29 01:45:59 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Mon, 28 Jul 2008 10:45:59 -0500 (CDT)
Subject: Openssh for Windows
In-Reply-To: <B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
Message-ID: <alpine.BSO.1.00.0807281035520.30973@miyako.eviladmin.org>



On Mon, 28 Jul 2008, Patel Dippen-CDP054 wrote:

> So basically, I have to download and install Cygwin from
> http://cygwin.com/. Does this install the complete Cygwin or just a
> small portion like the v3.8.1p1-1 below?
>

By default you are given a choice as to how much of Cygwin you want to 
install.  It is really an attempt to do a full "UNIX-like" environment 
(command line, and library set) within the Windows enviroment.

> Are there security issues related to using Cygwin itself? The v3.8.1p1-1
> version has a Readme that states that Cygwin uses shared memory to store
> process information that is not protected.
>

I can't comment on this.  Others that have dealt with Cygwin more 
recently can speak for it.

> How safe is the VanDyke version?
>

I've had no problems with VanDyke products so far, and I've been rather 
pleased with their support.

> Could I use either of these on high security/ mission critical systems?
>

If it was me I'd look at the VanDyke solution.  One could prototype using 
Cygwin, but..  Well, I've been too close to the patches that flowed in for 
OpenSSH support and some of them still cause me nightmares (Sorry 
Corinna.. I know they are needed, but still doesn't make me comfortable 
=).

But we'ved drifted off the subject of OpenSSH.. so I'll wander off. =)

- Ben

From rapier at psc.edu  Tue Jul 29 01:38:54 2008
From: rapier at psc.edu (rapier)
Date: Mon, 28 Jul 2008 11:38:54 -0400
Subject: Openssh for Windows
In-Reply-To: <20080728151156.GB23519@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
Message-ID: <488DE80E.7000601@psc.edu>



Corinna Vinschen wrote:
> On Jul 28 16:33, Harald Dunkel wrote:
>> You might want to consider to use Microsoft's Services For Unix.
>> A nice OpenSSH implementation (client and server, including
>> public-key authentications!) is provided by Interopsystems. Some
> 
> Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.

Cygwin is probably your best solution for OpenSSH under Windows. 
However, if you want a more minimal solution then you may want to look 
at CopSSH http://www.itefix.no/i2/node/27. Its a port of OpenSSH which 
uses a minimal Cygwin environment in straightforward installer package.


From vinschen at redhat.com  Tue Jul 29 01:34:34 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 28 Jul 2008 17:34:34 +0200
Subject: Openssh for Windows
In-Reply-To: <B064CD283C01A646BD35F603F2653EAF0279D216@de01exm66.ds.mot.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
	<Pine.LNX.4.64.0807281551250.5696@top.qwarx.com>
	<B064CD283C01A646BD35F603F2653EAF0279D216@de01exm66.ds.mot.com>
Message-ID: <20080728153434.GO29031@calimero.vinschen.de>

On Jul 28 11:08, Patel Dippen-CDP054 wrote:
> Chris,
> 
> Agree. Our proposal is to use SSL natively (IPSec creates other problems
> for us). However, I have to provde some analysis on why SSH is not
> suitable. Believe the lack of a openware, stable and secured SSH server
> for Windows itself suffices.

Cygwin uses global shared memory for sharing not very security relevant
stuff.  Otherwise all datastructures are secured by security descriptors
which only the user, administrative accounts and the system itself can
access.

However, it looks like you're just looking for an excuse not to use
OpenSSH on Windows anyway, so, never mind.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From jmknoble at pobox.com  Tue Jul 29 15:35:41 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Tue, 29 Jul 2008 01:35:41 -0400
Subject: Openssh for Windows
In-Reply-To: <20080728150817.32509.qmail@cdy.org>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
	<20080728150817.32509.qmail@cdy.org>
Message-ID: <20080729053540.GA2184@crawfish.ais.com>

Circa 2008-07-28 11:08 dixit Peter Stuge:

: On Mon, Jul 28, 2008 at 10:01:51AM -0400, Patel Dippen-CDP054 wrote:
: .. Cygwin / VanDyke
: > 
: > Could I use either of these on high security/ mission critical systems?

  [...]

: > I have Windows Services running on different Windows machines and
: > they talk to each other. I need to protect the communication
: > between these 2 services.
: 
: As others mentioned, an actual VPN product is much more suitable for
: this task. I recommend the open source product OpenVPN which runs
: very well also on Windows. Please see http://openvpn.net/

As no one else has mentioned yet, if the services in question talk to
each other via TCP, then a number of solutions are available, including
OpenSSH with a minimal Cygwin environment (see Corinna Vinschen's
response in this thread for info about OpenSSH's security under Cygwin).
Stunnel is another potential solution <http://www.stunnel.org/>; it
appears to have a Microsoft-native installer (and can allegedly install
as a Microsoft Windows service).

However, if the services communicate via UDP, then you *must* use a
different solution, as neither OpenSSH nor stunnel will tunnel UDP
traffic.  OpenVPN, as Peter mentions, is a high-quality SSL-based VPN
solution that works natively on Microsoft OSes and handles UDP.  As
mentioned previously, IPsec is another candidate.

Of course, there are other ways to handle this as well, including
putting VPN appliances in between the Microsoft systems (this includes
using, say, a Linux or OpenBSD system as a VPN gateway).  That could
bring you more flexibility.

Also, depending on the physical proximity of the systems, you may be
able to simply use a physically separated network to connect them (for
example, dedicated network ports connected via a separate switch or a
crossover cable).

Good luck,
jim

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From harald.dunkel at aixigo.de  Tue Jul 29 17:12:12 2008
From: harald.dunkel at aixigo.de (Harald Dunkel)
Date: Tue, 29 Jul 2008 09:12:12 +0200
Subject: Openssh for Windows
In-Reply-To: <20080728151156.GB23519@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
Message-ID: <488EC2CC.9020808@aixigo.de>

Corinna Vinschen wrote:
> On Jul 28 16:33, Harald Dunkel wrote:
>> You might want to consider to use Microsoft's Services For Unix.
>> A nice OpenSSH implementation (client and server, including
>> public-key authentications!) is provided by Interopsystems. Some
> 
> Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.
> 

Surely I don't want to goof on Cygwin, but you mean you can
login via ssh on a remote Windows XP host without being asked
for a password? Within an LDAP environment, including your
home directory on a remote network drive?

Maybe I missed some trick hidden too deep in the documentation,
but I never made this work with Cygwin's ssh (in 2006). AFAICR
sshd was not running with the appropriate rights to read the
user's .ssh directory on a remote share, and there was no "regpwd"
tool as there is for Interix.


Regards

Harri

From vinschen at redhat.com  Tue Jul 29 18:17:16 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 29 Jul 2008 10:17:16 +0200
Subject: Openssh for Windows
In-Reply-To: <488EC2CC.9020808@aixigo.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
Message-ID: <20080729081716.GB29994@calimero.vinschen.de>

On Jul 29 09:12, Harald Dunkel wrote:
> Corinna Vinschen wrote:
> > On Jul 28 16:33, Harald Dunkel wrote:
> >> You might want to consider to use Microsoft's Services For Unix.
> >> A nice OpenSSH implementation (client and server, including
> >> public-key authentications!) is provided by Interopsystems. Some
> > 
> > Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.
> > 
> 
> Surely I don't want to goof on Cygwin, but you mean you can
> login via ssh on a remote Windows XP host without being asked
> for a password? Within an LDAP environment, including your
> home directory on a remote network drive?
> 
> Maybe I missed some trick hidden too deep in the documentation,
> but I never made this work with Cygwin's ssh (in 2006). AFAICR
> sshd was not running with the appropriate rights to read the
> user's .ssh directory on a remote share, and there was no "regpwd"
> tool as there is for Interix.

You can use password-less authentication and Cygwin will create
a user token for your user.  This user token has no credentials for
network access because you only get that when using password
authentication.  The result is that you only get your remote home dir
after logging in by using `net use share /user:domain\user password',
thus explicitely authenticating against the sharing server.

The method Interix uses is to store a copy of the user's password in the
registry in a two-way encrypted fashion, which is then used whenever
Interix needs to impersonate a user.  That means, the pubkey
authentication is used in OpenSSH, but the actual authentication against
the OS is using password authentication.  The result is that you get a
user token which includes the network credentials to access your home
dir automatically.

The advantage of the Interix method is that the user token is a password
authenticated token with network credentials.  The downside is that
there's a two-way encrypted copy of your password somewhere in an
undocumented place in the registry, using an undocumented two-way
encryption.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From ed at FreeBSD.org  Tue Jul 29 01:49:19 2008
From: ed at FreeBSD.org (Ed Schouten)
Date: Mon, 28 Jul 2008 17:49:19 +0200
Subject: PTY allocation without being root
Message-ID: <20080728154919.GC99951@hoeg.nl>

Hello everyone,

Some of you might already know what I've been doing lately, but I'd
better introduce myself properly: since February this year I've been
working on redesigning the TTY layer for the FreeBSD operating system. I
hope to get my work integrated next month (the 10th of August). The new
TTY layer will have some minor improvements with respect to performance,
but one of the nice features is that we'll finally create/destroy PTY's
on demand.

Creating PTY's on demand gave me an idea: what if we could perform
resource limiting on PTY's? PTY's aren't infinitely available on FreeBSD
(right now we can only allocate 1000, because of UT_LINESIZE). This
means a single user could block other users from logging in, by running:

	for (;;) posix_openpt(O_RDWR|O_NOCTTY);

A couple of weeks ago, I created an experimental patch to add a new
rlimit. Unfortunately, it seemed OpenSSH just ignored the limit, which
only meant one thing: OpenSSH allocates PTY's as root.

Only a few months ago, I visited a talk by Otto Moerbeek about privilege
separation. If I understand OpenSSH's design correctly, we've got two
processes:

- One process running as the user which will be logging in.

- One process running as root, which runs all the operations which
  cannot be performed by the first process.

Allocating PTY's is performed in the second process. It would be nice if
we allocated it in the first process, because we could then perform the
resource limiting. Right now I'm using this patch, which actually seems
to work on my system:

| --- crypto/openssh/session.c
| +++ crypto/openssh/session.c
| @@ -1867,7 +1867,7 @@
|  
|  	/* Allocate a pty and open it. */
|  	debug("Allocating pty.");
| -	if (!PRIVSEP(pty_allocate(&s->ptyfd, &s->ttyfd, s->tty, sizeof(s->tty)))) {
| +	if (!pty_allocate(&s->ptyfd, &s->ttyfd, s->tty, sizeof(s->tty))) {
|  		if (s->term)
|  			xfree(s->term);
|  		s->term = NULL;

I can imagine this is not the right way to do it. I predict this breaks
badly when the unprivileged process is chroot'ed.

I think a better approach would be to switch to the actual user
somewhere inside pty_allocate(). If we would call openpty() by the
proper user, we wouldn't need functions like pty_setowner(), because
openpty() already sets the proper permissions then.

There's no rush in implementing this, but I think it would be cool if
OpenSSH would honour this behaviour. Thanks!

-- 
 Ed Schouten <ed at FreeBSD.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080728/284e6833/attachment.bin 

From vinschen at redhat.com  Tue Jul 29 18:36:11 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 29 Jul 2008 10:36:11 +0200
Subject: Openssh for Windows
In-Reply-To: <alpine.BSO.1.00.0807281035520.30973@miyako.eviladmin.org>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807280853100.30973@miyako.eviladmin.org>
	<B064CD283C01A646BD35F603F2653EAF0279D179@de01exm66.ds.mot.com>
	<alpine.BSO.1.00.0807281035520.30973@miyako.eviladmin.org>
Message-ID: <20080729083611.GC29994@calimero.vinschen.de>

On Jul 28 10:45, Ben Lindstrom wrote:
> If it was me I'd look at the VanDyke solution.  One could prototype using 
> Cygwin, but..  Well, I've been too close to the patches that flowed in for 
> OpenSSH support and some of them still cause me nightmares (Sorry 
> Corinna.. I know they are needed, but still doesn't make me comfortable 
> =).

Which ones?

The file system related tests?  The default installation on an NTFS
drive will use all security it can get.  The extra code is just
necessary for users who install on FAT or FAT32 with no security at all,
or users who explicitely switched off all permission checking.  And then
there are still Windows 95/98/Me users out there, hard as it is to
imagine it...

The disabled root user tests?  There's no such thing as a single user
with uid 0 having the necessary rights to run OpenSSH and switch the
user context on Windows.  I already suggested more than once in the last
years to replace the `if (pw_uid == 0)'-like tests in OpenSSH with a OS
dependent function call.  On Cygwin (well, Windows) this would mean to
check for specific user rights as the right to act on behave of the
operating system, stuff like that.  On most POSIX systems that would be
a simple test for uid 0.  I even created a patch for this but
unfortunately it hasn't been accepted.

The disabled test for being able to revert a seteuid in
permanently_drop_suid?  That's something I have no control over.
Windows NT has a means to do that, but that function was never intended
to be called by a Win32 process to switch its own user token permanently
and it doesn't work as expected.  I tried to use it but I never got it
working on some OS versions.  Eventually Microsoft disabled this
function entirely when called from a Win32 process starting with Windows
Vista.  Interix OTOH may call this function because it's not a Win32
process like Cygwin but an entirely different subsystem.
However, that's really not a problem.  When the user process is started
by sshd, this *is* done by a function call which actually switches the
the user token permanently (CreateProcessAsUser).  There's no way for
the user process to re-gain root privileges anymore.

Anything else?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From vinschen at redhat.com  Tue Jul 29 18:40:19 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 29 Jul 2008 10:40:19 +0200
Subject: Openssh for Windows
In-Reply-To: <20080729081716.GB29994@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
Message-ID: <20080729084019.GD29994@calimero.vinschen.de>

On Jul 29 10:17, Corinna Vinschen wrote:
> On Jul 29 09:12, Harald Dunkel wrote:
> > Corinna Vinschen wrote:
> > > On Jul 28 16:33, Harald Dunkel wrote:
> > >> You might want to consider to use Microsoft's Services For Unix.
> > >> A nice OpenSSH implementation (client and server, including
> > >> public-key authentications!) is provided by Interopsystems. Some
> > > 
> > > Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.
> > > 
> > 
> > Surely I don't want to goof on Cygwin, but you mean you can
> > login via ssh on a remote Windows XP host without being asked
> > for a password? Within an LDAP environment, including your
> > home directory on a remote network drive?
> > 
> > Maybe I missed some trick hidden too deep in the documentation,
> > but I never made this work with Cygwin's ssh (in 2006). AFAICR
> > sshd was not running with the appropriate rights to read the
> > user's .ssh directory on a remote share, and there was no "regpwd"
> > tool as there is for Interix.
> 
> You can use password-less authentication and Cygwin will create
> a user token for your user.  This user token has no credentials for
> network access because you only get that when using password
> authentication.  The result is that you only get your remote home dir
> after logging in by using `net use share /user:domain\user password',
> thus explicitely authenticating against the sharing server.

Btw., if you only need pubkey authentication for a single account, you
can do that in Cygwin by running sshd under that account.  In this case,
there's no actual user context switch, just the authentication part.
This has an obvious advantage.  Since sshd is already running as that
user, the user token has all credentials for accessing the required
network drives.  And, you don't have to run sshd under a privileged
account if you don't feel confortable to do that on Windows.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From harald.dunkel at aixigo.de  Tue Jul 29 19:02:40 2008
From: harald.dunkel at aixigo.de (Harald Dunkel)
Date: Tue, 29 Jul 2008 11:02:40 +0200
Subject: Openssh for Windows
In-Reply-To: <20080729081716.GB29994@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>	<488DD8A1.90406@aixigo.de>	<20080728151156.GB23519@calimero.vinschen.de>	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
Message-ID: <488EDCB0.9020509@aixigo.de>

Corinna Vinschen wrote:
> 
> You can use password-less authentication and Cygwin will create
> a user token for your user.  This user token has no credentials for
> network access because you only get that when using password
> authentication.  The result is that you only get your remote home dir
> after logging in by using `net use share /user:domain\user password',
> thus explicitely authenticating against the sharing server.
> 

If I got you correctly then this means that Cygwin's sshd doesn't
have permission to access my .ssh for authentication, if it is on
a remote disk. Doesn't this mean that pubkey simply doesn't work
in this case?

> The method Interix uses is to store a copy of the user's password in the
> registry in a two-way encrypted fashion, which is then used whenever
> Interix needs to impersonate a user.  That means, the pubkey
> authentication is used in OpenSSH, but the actual authentication against
> the OS is using password authentication.  The result is that you get a
> user token which includes the network credentials to access your home
> dir automatically.
> 
> The advantage of the Interix method is that the user token is a password
> authenticated token with network credentials.  The downside is that
> there's a two-way encrypted copy of your password somewhere in an
> undocumented place in the registry, using an undocumented two-way
> encryption.
> 

I am surely not an advocate for Windows, but the Unix procedure is
pretty rude, too: sshd is running with root permission. Since the
NFS partition containing my $HOME might be mounted without giving
root the right to read all files it likes (no_root_squash), sshd has
to break into my account (via seteuid(1), I would guess) to read my
.ssh directory.

In other words, sshd on Unix doesn't need an encrypted copy of my
password to generate some network credentials (as Interix' sshd
does). It bypasses all security means by brute force.

I can live with both. But I have to say that Cygwin's sshd doesn't
match my needs.


Regards

Harri


From vinschen at redhat.com  Tue Jul 29 20:08:06 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 29 Jul 2008 12:08:06 +0200
Subject: Openssh for Windows
In-Reply-To: <488EDCB0.9020509@aixigo.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
	<488EDCB0.9020509@aixigo.de>
Message-ID: <20080729100806.GU29031@calimero.vinschen.de>

On Jul 29 11:02, Harald Dunkel wrote:
> Corinna Vinschen wrote:
> > 
> > You can use password-less authentication and Cygwin will create
> > a user token for your user.  This user token has no credentials for
> > network access because you only get that when using password
> > authentication.  The result is that you only get your remote home dir
> > after logging in by using `net use share /user:domain\user password',
> > thus explicitely authenticating against the sharing server.
> > 
> 
> If I got you correctly then this means that Cygwin's sshd doesn't
> have permission to access my .ssh for authentication, if it is on
> a remote disk. Doesn't this mean that pubkey simply doesn't work
> in this case?

Basically yes.  The usual workaround is to define a local home dir
which contains the .ssh dir and to attach to the network drive after
authentication.

However, if sshd is running from a domain account which has access
to the network drives, and if /etc/passwd has the homedirs mentioned
as UNC paths, you can get this working transparently.  It just requires
a bit of administration.  The user still has no network credentials, of
course, so the explicit `net use' is still required.

Btw., in the next major Cygwin release you can use NFS shares instead of
SMB shares for your home dir (together with Microsoft's NFS client).  As
long as you use UNC paths, rather than drive letters, you can access
them just fine from your user account without having to call `net use'.
Provided you installed the name mapping service correctly.

> > The advantage of the Interix method is that the user token is a password
> > authenticated token with network credentials.  The downside is that
> > there's a two-way encrypted copy of your password somewhere in an
> > undocumented place in the registry, using an undocumented two-way
> > encryption.
> 
> I am surely not an advocate for Windows, but the Unix procedure is
> pretty rude, too: sshd is running with root permission. Since the
> NFS partition containing my $HOME might be mounted without giving
> root the right to read all files it likes (no_root_squash), sshd has
> to break into my account (via seteuid(1), I would guess) to read my
> .ssh directory.
> 
> In other words, sshd on Unix doesn't need an encrypted copy of my
> password to generate some network credentials (as Interix' sshd
> does). It bypasses all security means by brute force.

As Interix does.  And IMHO even worse.  Interix has access to your
cleartext(!) password.  You entered it when calling regpwd, then it gets
encrypted, but Interix knows the key to fetch it back in cleartext
whenever it needs it to create a user token on your behalf.

Actually, if we wanted to, we could easily do the same.  But I'm still
feeling rather uncomfortable with the idea to have two-way encrypted
password stored somewhere in the system.

> I can live with both. But I have to say that Cygwin's sshd doesn't
> match my needs.

That's ok.  That doesn't mean that Cygwin isn't useful for other people :)


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From des at des.no  Wed Jul 30 00:53:38 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 29 Jul 2008 16:53:38 +0200
Subject: Question regarding alignment patch
Message-ID: <86iquo68st.fsf@ds4.des.no>

Contrast

http://cvsweb.mindrot.org/index.cgi/openssh/monitor_fdpass.c?r1=1.23;r2=1.24
with
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/monitor_fdpass.c.diff?r1=1.14&r2=1.15

The original replaces cmsgbuf.tmp with cmsgbuf.buf, while the -portable
version *adds* cmsgbuf.buf but retains cmsgbuf.tmp.

I assume this was an oversight, and cmsgbuf.tmp should be removed?

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From jmknoble at pobox.com  Wed Jul 30 04:00:20 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Tue, 29 Jul 2008 14:00:20 -0400
Subject: Openssh for Windows
In-Reply-To: <20080729100806.GU29031@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
	<488EDCB0.9020509@aixigo.de>
	<20080729100806.GU29031@calimero.vinschen.de>
Message-ID: <20080729180019.GB2184@crawfish.ais.com>

Circa 2008-07-29 06:08 dixit Corinna Vinschen:

: > > The advantage of the Interix method is that the user token is a password
: > > authenticated token with network credentials.  The downside is that
: > > there's a two-way encrypted copy of your password somewhere in an
: > > undocumented place in the registry, using an undocumented two-way
: > > encryption.

  [...]

: Actually, if we wanted to, we could easily do the same.  But I'm still
: feeling rather uncomfortable with the idea to have two-way encrypted
: password stored somewhere in the system.

You could encrypt the user's password using the user's SSH public key.
Then the private key could be used to both authenticate and decrypt the
password.  It's a bit cumbersome if there are more than a few keypairs
used to access the account, but ... just a thought.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From imorgan at nas.nasa.gov  Wed Jul 30 05:58:58 2008
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 29 Jul 2008 12:58:58 -0700
Subject: Chained X11 forwarding
Message-ID: <20080729195858.GA31824@linux55.nas.nasa.gov>

hI,

Recently, we encountered a problem with forwarded X11 sessions when the
user ssh's through multiple systems. This was first spotted with 5.0p1
but is also reproducible with 5.1p1. The problem does not occur with
4.2p1.

The scenario is this: ssh from HostA to HostB requesting X11 forwarding
and then likewise from HostB to HostC. If you request a trusted cookie
when connecting to HostC, then X11 forwarding works fine. However, if
you use an untrusted cookie, it fails.

X11 forwarding from HostB works fine regardless of the type of cookie
used. Also, the problem seems to be independent of the version of
OpenSSH running on HostC.

The ssh client on HostB appears to generate an untrusted cookie
successuflly. The -vv output confirms that it tries to generate an
untrusted cookie and there are no warnings indicating that ssh is
falling back to fake authentication.

The error encountered is a fairly generic one:

seven.imorgan> xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:29.0 broken (explicit kill or server
shutdown).

Has anyone else seen a similar problem or is it reproducible at other
sites?


Thanks

-- 
Iain Morgan

From rapier at psc.edu  Wed Jul 30 07:31:21 2008
From: rapier at psc.edu (rapier)
Date: Tue, 29 Jul 2008 17:31:21 -0400
Subject: HPN-SSH for OpenSSH 5.1 Available
Message-ID: <488F8C29.7020501@psc.edu>

Just as an FYI. HPN-SSH 13v5 is now available for OpenSSH 5.1. There are 
two minor changes in functionality. First, the progress meter will no 
longer spit out an extra line with the peak throughput. Instead the peak 
throughput will be displayed as the last update in the meter itself. 
Second, I've increased the number of outstanding requests in sftp to 
256. This will give users 8MB of outstanding data. I also made some 
changes that allowed me to clean up some of the code by reducing arg 
passing. 13v6 is on the horizon with improved threading for aes-ctr and 
more code cleanup.

I've done a bit of testing but, as always, the more people that poke at 
the code the better it will be. If you have the time and inclination to 
try the patch out and give me your comments I'll welcome them gladly.

Thanks,

Chris



From dtucker at zip.com.au  Wed Jul 30 10:34:06 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 30 Jul 2008 10:34:06 +1000
Subject: Question regarding alignment patch
In-Reply-To: <86iquo68st.fsf@ds4.des.no>
References: <86iquo68st.fsf@ds4.des.no>
Message-ID: <20080730003405.GA4129@gate.dtucker.net>

On Tue, Jul 29, 2008 at 04:53:38PM +0200, Dag-Erling Sm?rgrav wrote:
> Contrast
> 
> http://cvsweb.mindrot.org/index.cgi/openssh/monitor_fdpass.c?r1=1.23;r2=1.24
> with
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/monitor_fdpass.c.diff?r1=1.14&r2=1.15
> 
> The original replaces cmsgbuf.tmp with cmsgbuf.buf, while the -portable
> version *adds* cmsgbuf.buf but retains cmsgbuf.tmp.
> 
> I assume this was an oversight, and cmsgbuf.tmp should be removed?

Yes it certainly looks like an oversight.

On a somewhat related note, it seems that some platforms (NetBSD 1.6
at least) fail the recvmsg with EAGAIN making multiplexing fail with:

mm_receive_fd: recvmsg: Resource temporarily unavailable

Retrying on EAGAIN makes this work (well, pass the regress tests
anyway).

Index: monitor_fdpass.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor_fdpass.c,v
retrieving revision 1.26
diff -u -p -r1.26 monitor_fdpass.c
--- monitor_fdpass.c	27 Mar 2008 00:01:15 -0000	1.26
+++ monitor_fdpass.c	30 Jul 2008 00:31:16 -0000
@@ -51,7 +51,6 @@ mm_send_fd(int sock, int fd)
 #ifndef HAVE_ACCRIGHTS_IN_MSGHDR
 	union {
 		struct cmsghdr hdr;
-		char tmp[CMSG_SPACE(sizeof(int))];
 		char buf[CMSG_SPACE(sizeof(int))];
 	} cmsgbuf;
 	struct cmsghdr *cmsg;
@@ -76,7 +75,9 @@ mm_send_fd(int sock, int fd)
 	msg.msg_iov = &vec;
 	msg.msg_iovlen = 1;
 
-	if ((n = sendmsg(sock, &msg, 0)) == -1) {
+	while ((n = sendmsg(sock, &msg, 0)) == -1 && errno == EAGAIN)
+		;
+	if (n == -1) {
 		error("%s: sendmsg(%d): %s", __func__, fd,
 		    strerror(errno));
 		return -1;
@@ -124,7 +125,9 @@ mm_receive_fd(int sock)
 	msg.msg_controllen = sizeof(cmsgbuf.buf);
 #endif
 
-	if ((n = recvmsg(sock, &msg, 0)) == -1) {
+	while ((n = recvmsg(sock, &msg, 0)) == -1 && errno == EAGAIN)
+		;
+	if (n == -1) {
 		error("%s: recvmsg: %s", __func__, strerror(errno));
 		return -1;
 	}

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

From dtucker at zip.com.au  Wed Jul 30 11:00:45 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 30 Jul 2008 11:00:45 +1000
Subject: Question regarding alignment patch
In-Reply-To: <20080730003405.GA4129@gate.dtucker.net>
References: <86iquo68st.fsf@ds4.des.no>
	<20080730003405.GA4129@gate.dtucker.net>
Message-ID: <20080730010045.GA4454@gate.dtucker.net>

On Wed, Jul 30, 2008 at 10:34:06AM +1000, Darren Tucker wrote:
> On Tue, Jul 29, 2008 at 04:53:38PM +0200, Dag-Erling Sm?rgrav wrote:
> > Contrast
> > 
> > http://cvsweb.mindrot.org/index.cgi/openssh/monitor_fdpass.c?r1=1.23;r2=1.24
> > with
> > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/monitor_fdpass.c.diff?r1=1.14&r2=1.15
> > 
> > The original replaces cmsgbuf.tmp with cmsgbuf.buf, while the -portable
> > version *adds* cmsgbuf.buf but retains cmsgbuf.tmp.
> > 
> > I assume this was an oversight, and cmsgbuf.tmp should be removed?
> 
> Yes it certainly looks like an oversight.
> 
> On a somewhat related note, it seems that some platforms (NetBSD 1.6
> at least) fail the recvmsg with EAGAIN making multiplexing fail with:

On another related note, if we reshuffle some variable declarations and
fiddle spacing we can cut the diff against OpenBSD by quite a bit (55
lines to 38 lines) and make the remainder more readable (this conficts
with my previous patch).

I'm not sure if there's a reason for the existing order (can't see one
from the CVS history).  Damien?

Index: monitor_fdpass.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor_fdpass.c,v
retrieving revision 1.26
diff -u -p -r1.26 monitor_fdpass.c
--- monitor_fdpass.c	27 Mar 2008 00:01:15 -0000	1.26
+++ monitor_fdpass.c	30 Jul 2008 00:37:37 -0000
@@ -45,17 +45,16 @@ mm_send_fd(int sock, int fd)
 {
 #if defined(HAVE_SENDMSG) && (defined(HAVE_ACCRIGHTS_IN_MSGHDR) || defined(HAVE_CONTROL_IN_MSGHDR))
 	struct msghdr msg;
-	struct iovec vec;
-	char ch = '\0';
-	ssize_t n;
 #ifndef HAVE_ACCRIGHTS_IN_MSGHDR
 	union {
 		struct cmsghdr hdr;
-		char tmp[CMSG_SPACE(sizeof(int))];
 		char buf[CMSG_SPACE(sizeof(int))];
 	} cmsgbuf;
 	struct cmsghdr *cmsg;
 #endif
+	struct iovec vec;
+	char ch = '\0';
+	ssize_t n;
 
 	memset(&msg, 0, sizeof(msg));
 #ifdef HAVE_ACCRIGHTS_IN_MSGHDR
@@ -99,10 +98,6 @@ mm_receive_fd(int sock)
 {
 #if defined(HAVE_RECVMSG) && (defined(HAVE_ACCRIGHTS_IN_MSGHDR) || defined(HAVE_CONTROL_IN_MSGHDR))
 	struct msghdr msg;
-	struct iovec vec;
-	ssize_t n;
-	char ch;
-	int fd;
 #ifndef HAVE_ACCRIGHTS_IN_MSGHDR
 	union {
 		struct cmsghdr hdr;
@@ -110,6 +105,10 @@ mm_receive_fd(int sock)
 	} cmsgbuf;
 	struct cmsghdr *cmsg;
 #endif
+	struct iovec vec;
+	ssize_t n;
+	char ch;
+	int fd;
 
 	memset(&msg, 0, sizeof(msg));
 	vec.iov_base = &ch;
@@ -128,6 +127,7 @@ mm_receive_fd(int sock)
 		error("%s: recvmsg: %s", __func__, strerror(errno));
 		return -1;
 	}
+
 	if (n != 1) {
 		error("%s: recvmsg: expected received 1 got %ld",
 		    __func__, (long)n);
@@ -145,6 +145,7 @@ mm_receive_fd(int sock)
 		error("%s: no message header", __func__);
 		return -1;
 	}
+
 #ifndef BROKEN_CMSG_TYPE
 	if (cmsg->cmsg_type != SCM_RIGHTS) {
 		error("%s: expected type %d got %d", __func__,

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

From djm at mindrot.org  Wed Jul 30 16:08:21 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 30 Jul 2008 16:08:21 +1000 (EST)
Subject: Question regarding alignment patch
In-Reply-To: <20080730010045.GA4454@gate.dtucker.net>
References: <86iquo68st.fsf@ds4.des.no>
	<20080730003405.GA4129@gate.dtucker.net>
	<20080730010045.GA4454@gate.dtucker.net>
Message-ID: <alpine.BSO.1.10.0807301607110.2447@fuyu.mindrot.org>

On Wed, 30 Jul 2008, Darren Tucker wrote:

> On another related note, if we reshuffle some variable declarations and
> fiddle spacing we can cut the diff against OpenBSD by quite a bit (55
> lines to 38 lines) and make the remainder more readable (this conficts
> with my previous patch).
> 
> I'm not sure if there's a reason for the existing order (can't see one
> from the CVS history).  Damien?

No reason, feel free to commit your fixes.

-d

From vinschen at redhat.com  Wed Jul 30 18:58:59 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 30 Jul 2008 10:58:59 +0200
Subject: Openssh for Windows
In-Reply-To: <20080729180019.GB2184@crawfish.ais.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
	<488EDCB0.9020509@aixigo.de>
	<20080729100806.GU29031@calimero.vinschen.de>
	<20080729180019.GB2184@crawfish.ais.com>
Message-ID: <20080730085859.GA5808@calimero.vinschen.de>

On Jul 29 14:00, Jim Knoble wrote:
> Circa 2008-07-29 06:08 dixit Corinna Vinschen:
> : Actually, if we wanted to, we could easily do the same.  But I'm still
> : feeling rather uncomfortable with the idea to have two-way encrypted
> : password stored somewhere in the system.
> 
> You could encrypt the user's password using the user's SSH public key.
> Then the private key could be used to both authenticate and decrypt the
> password.  It's a bit cumbersome if there are more than a few keypairs
> used to access the account, but ... just a thought.

That's an interesting idea but the problem is that the user context
change is generic code buried within the seteuid call.  It has to work
with all sorts of applications changing the user context, not just with
sshd.  Therefore, a generic solution is required.

I'm not overly encryption savvy.  Is it at all possible to store a
two-way encrypted password in a safe way, using a known encryption
mechanism, storing it in a known location?  Even if another key is used
on every machine?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From dtucker at zip.com.au  Wed Jul 30 23:26:14 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 30 Jul 2008 23:26:14 +1000
Subject: Openssh for Windows
In-Reply-To: <20080730085859.GA5808@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>	<488DD8A1.90406@aixigo.de>	<20080728151156.GB23519@calimero.vinschen.de>	<488EC2CC.9020808@aixigo.de>	<20080729081716.GB29994@calimero.vinschen.de>	<488EDCB0.9020509@aixigo.de>	<20080729100806.GU29031@calimero.vinschen.de>	<20080729180019.GB2184@crawfish.ais.com>
	<20080730085859.GA5808@calimero.vinschen.de>
Message-ID: <48906BF6.10402@zip.com.au>

Corinna Vinschen wrote:
> On Jul 29 14:00, Jim Knoble wrote:
>> Circa 2008-07-29 06:08 dixit Corinna Vinschen:
>> : Actually, if we wanted to, we could easily do the same.  But I'm still
>> : feeling rather uncomfortable with the idea to have two-way encrypted
>> : password stored somewhere in the system.
>>
>> You could encrypt the user's password using the user's SSH public key.
>> Then the private key could be used to both authenticate and decrypt the
>> password.  It's a bit cumbersome if there are more than a few keypairs
>> used to access the account, but ... just a thought.
> 
> That's an interesting idea but the problem is that the user context
> change is generic code buried within the seteuid call.  It has to work
> with all sorts of applications changing the user context, not just with
> sshd.  Therefore, a generic solution is required.
> 
> I'm not overly encryption savvy.  Is it at all possible to store a
> two-way encrypted password in a safe way, using a known encryption
> mechanism, storing it in a known location?  Even if another key is used
> on every machine?

I don't think it's feasible from a protocol perspective; for ssh v2 the 
server never has access to the corresponding private key, only a chunk 
of data provided by the client that's signed with the private key (said 
chunk of data containing amongst other things a session id and the user 
name).

-- 
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 kravindra at gmail.com  Thu Jul 31 01:00:17 2008
From: kravindra at gmail.com (Ravindra)
Date: Wed, 30 Jul 2008 20:30:17 +0530
Subject: IPv6 support in OpenSSH
Message-ID: <ad3abf630807300800o283a2508oe06e087c2180aebe@mail.gmail.com>

Hi,

Please redirect me to the right mailing list if this is not the correct one.

I would like to know what stable version of OpenSSH added support for
IPv6 for the first time ?

Thanks in advance,
Ravindra

From markus.r.friedl at arcor.de  Thu Jul 31 02:11:56 2008
From: markus.r.friedl at arcor.de (Markus Friedl)
Date: Wed, 30 Jul 2008 18:11:56 +0200
Subject: IPv6 support in OpenSSH
In-Reply-To: <ad3abf630807300800o283a2508oe06e087c2180aebe@mail.gmail.com>
References: <ad3abf630807300800o283a2508oe06e087c2180aebe@mail.gmail.com>
Message-ID: <20080730161156.GA3461@folly>

i commited support in january 2001, so openssh-1.2.2
was the first release with ipv6



On Wed, Jul 30, 2008 at 08:30:17PM +0530, Ravindra wrote:
> Hi,
> 
> Please redirect me to the right mailing list if this is not the correct one.
> 
> I would like to know what stable version of OpenSSH added support for
> IPv6 for the first time ?
> 
> Thanks in advance,
> Ravindra
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From rac at tenzing.org  Thu Jul 31 03:58:28 2008
From: rac at tenzing.org (Roger Cornelius)
Date: Wed, 30 Jul 2008 13:58:28 -0400
Subject: 5.1p build problem on SCO OSR6
Message-ID: <20080730175828.GB29835@tenzing.org>

Build of 5.1p1 fails on SCO OSR6 with the error:

UX:acomp: ERROR: "addrmatch.c", line 100: undefined struct/union member: sin6_scope_id

configure checks for presence of struct sockaddr_in6 and uses the system
declaration if found (via #define HAVE_STRUCT_SOCKADDR_IN6 in config.h)
If not found, the struct is declared in openbsd-compat/fake-rfc2553.h.
OSR6 has struct sockaddr_in6 but it does not include the sin6_scope_id
member.  The declaration in fake-rfc2553.h does include this member,
which is referenced in addrmatch.c.

So the problem seems to be, openssh erroneously assumes the presence of
sin6_scope_id if struct sockaddr_in6 is present.  This isn't true on
OSR6 (and maybe others??).
-- 
Roger Cornelius        rac at tenzing.org

From jmknoble at pobox.com  Thu Jul 31 05:25:04 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 30 Jul 2008 15:25:04 -0400
Subject: Openssh for Windows
In-Reply-To: <20080730085859.GA5808@calimero.vinschen.de>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
	<488EDCB0.9020509@aixigo.de>
	<20080729100806.GU29031@calimero.vinschen.de>
	<20080729180019.GB2184@crawfish.ais.com>
	<20080730085859.GA5808@calimero.vinschen.de>
Message-ID: <20080730192503.GF2184@crawfish.ais.com>

Circa 2008-07-30 04:58 dixit Corinna Vinschen:

: On Jul 29 14:00, Jim Knoble wrote:
: > Circa 2008-07-29 06:08 dixit Corinna Vinschen:
: > : [...] But I'm still feeling rather uncomfortable with the idea to
: > : have two-way encrypted password stored somewhere in the system.
: > 
: > You could encrypt the user's password using the user's SSH public key.
: > Then the private key could be used to both authenticate and decrypt the
: > password.  It's a bit cumbersome if there are more than a few keypairs
: > used to access the account, but ... just a thought.
: 
: That's an interesting idea but the problem is that the user context
: change is generic code buried within the seteuid call.  It has to work
: with all sorts of applications changing the user context, not just with
: sshd.  Therefore, a generic solution is required.

Hmm.  That definitely sounds more complex than one would want it to be.
The generic solution really sounds like Kerberos.

: I'm not overly encryption savvy.  Is it at all possible to store a
: two-way encrypted password in a safe way, using a known encryption
: mechanism, storing it in a known location?  Even if another key is
: used on every machine?

It depends on what risks are acceptable to you.  Unless the user enters
the encryption key itself or a passphrase for the key, then the
encryption key must be stored in what is effectively plaintext, either
in permanent (disk) or volatile (RAM) storage.  Thus, an attacker who
gains sufficiently privileged access to disk or RAM (e.g., through a
rootkit) would effectively gain access to the plaintext password as
well.

That's why i suggested using the SSH private key, as it can be made to
depend on a private passphrase stored separately from the encrypted
password.  Darren Tucker's response that sshd doesn't really know the
private key makes that more difficult; sshd would have to ask the client
to decrypt the encrypted password and send the plaintext password back
to the server.  That sounds overly complex.

To make it simpler, the server could ask the user for the encryption key
or a passphrase for the encryption key, as part of a two-step
authentication method.  But that's effectively the same as just asking
the user for the actual password, which is what happens now with the
"net use" command....

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From scott_n at xypro.com  Thu Jul 31 06:37:41 2008
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 30 Jul 2008 13:37:41 -0700
Subject: 5.1p build problem on SCO OSR6
In-Reply-To: <20080730175828.GB29835@tenzing.org>
References: <20080730175828.GB29835@tenzing.org>
Message-ID: <78DD71C304F38B41885A242996B96F73019003F3@xyservd.XYPRO-23.LOCAL>



> -----Original Message-----
> From: openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On
> Behalf Of Roger Cornelius
> Sent: Wednesday, July 30, 2008 10:58 AM
> To: openssh-unix-dev at mindrot.org
> Subject: 5.1p build problem on SCO OSR6
> 
> Build of 5.1p1 fails on SCO OSR6 with the error:
> 
> UX:acomp: ERROR: "addrmatch.c", line 100: undefined struct/union
> member: sin6_scope_id
> 
> configure checks for presence of struct sockaddr_in6 and uses the
> system
> declaration if found (via #define HAVE_STRUCT_SOCKADDR_IN6 in
config.h)
> If not found, the struct is declared in openbsd-compat/fake-rfc2553.h.
> OSR6 has struct sockaddr_in6 but it does not include the sin6_scope_id
> member.  The declaration in fake-rfc2553.h does include this member,
> which is referenced in addrmatch.c.
> 
> So the problem seems to be, openssh erroneously assumes the presence
of
> sin6_scope_id if struct sockaddr_in6 is present.  This isn't true on
> OSR6 (and maybe others??).
> 

Perhaps you could set environment variables at config time to disable
HAVE_STRUCT_SOCKADDR_IN6, assuming you won't need IPv6.  It's an
ac_{something} variable.

I've done stuff like this to work around this sort of thing without
needing to tweak configure.


From vinschen at redhat.com  Thu Jul 31 21:59:39 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 31 Jul 2008 13:59:39 +0200
Subject: Openssh for Windows
In-Reply-To: <20080730192503.GF2184@crawfish.ais.com>
References: <B064CD283C01A646BD35F603F2653EAF0279D0C1@de01exm66.ds.mot.com>
	<488DD8A1.90406@aixigo.de>
	<20080728151156.GB23519@calimero.vinschen.de>
	<488EC2CC.9020808@aixigo.de>
	<20080729081716.GB29994@calimero.vinschen.de>
	<488EDCB0.9020509@aixigo.de>
	<20080729100806.GU29031@calimero.vinschen.de>
	<20080729180019.GB2184@crawfish.ais.com>
	<20080730085859.GA5808@calimero.vinschen.de>
	<20080730192503.GF2184@crawfish.ais.com>
Message-ID: <20080731115939.GE7319@calimero.vinschen.de>

On Jul 30 15:25, Jim Knoble wrote:
> Circa 2008-07-30 04:58 dixit Corinna Vinschen:
> 
> : On Jul 29 14:00, Jim Knoble wrote:
> : > Circa 2008-07-29 06:08 dixit Corinna Vinschen:
> : > : [...] But I'm still feeling rather uncomfortable with the idea to
> : > : have two-way encrypted password stored somewhere in the system.
> : > 
> : > You could encrypt the user's password using the user's SSH public key.
> : > Then the private key could be used to both authenticate and decrypt the
> : > password.  It's a bit cumbersome if there are more than a few keypairs
> : > used to access the account, but ... just a thought.
> : 
> : That's an interesting idea but the problem is that the user context
> : change is generic code buried within the seteuid call.  It has to work
> : with all sorts of applications changing the user context, not just with
> : sshd.  Therefore, a generic solution is required.
> 
> Hmm.  That definitely sounds more complex than one would want it to be.
> The generic solution really sounds like Kerberos.

Still needs a supported user authentication method, password or smart
card.  It's way over my head to write a Windows Kerberos authentication
plugin.

> : I'm not overly encryption savvy.  Is it at all possible to store a
> : two-way encrypted password in a safe way, using a known encryption
> : mechanism, storing it in a known location?  Even if another key is
> : used on every machine?
> 
> It depends on what risks are acceptable to you.  Unless the user enters
> the encryption key itself or a passphrase for the key, then the
> encryption key must be stored in what is effectively plaintext, either
> in permanent (disk) or volatile (RAM) storage.  Thus, an attacker who
> gains sufficiently privileged access to disk or RAM (e.g., through a
> rootkit) would effectively gain access to the plaintext password as
> well.

It would have to be in permanent storage, as Interix does (registry).
In contrast to Interix, everybody would know from source where the keys
are stored and how they are encrypted.  I have no idea how to make that
safe and as long as I don't know that, I won't do it.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat