From nico at cryptonector.com  Thu Aug  1 03:38:00 2013
From: nico at cryptonector.com (Nico Williams)
Date: Wed, 31 Jul 2013 12:38:00 -0500
Subject: Bug #866
In-Reply-To: <alpine.BSO.2.03.1307311051040.8696@mindrot.org>
References: <CAK3OfOivv+p=Z_GyFM8JcvsoqPs0FS2AUvh+GXwNzPdfCRDXuQ@mail.gmail.com>
 <alpine.BSO.2.03.1307311051040.8696@mindrot.org>
Message-ID: <CAK3OfOghPoWuZKr1xkqvgpshn=wUhM7GQUW8eT=rc3+fyOW=YQ@mail.gmail.com>

On Tue, Jul 30, 2013 at 7:54 PM, Damien Miller <djm at mindrot.org> wrote:
> Why now? The proliferation of vendor packages that patch in things like
> GSSAPI-KEX and have default configurations that enable them explicitly.
> It makes it quite difficult to use custom-compiled packages of OpenSSH
> on these systems.

OK, thanks.  Good to know.

> For the record, I think turning on the attack surface of GSSAPI by
> default is a Very Bad Decision all by itself.

Noted.

From imorgan at nas.nasa.gov  Thu Aug  1 03:57:11 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 31 Jul 2013 10:57:11 -0700
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <20130730194649.GC18047@linux124.nas.nasa.gov>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <20130730194649.GC18047@linux124.nas.nasa.gov>
Message-ID: <20130731175711.GD18047@linux124.nas.nasa.gov>

On Tue, Jul 30, 2013 at 14:46:50 -0500, Iain Morgan wrote:
> On Wed, Jul 24, 2013 at 22:35:25 -0500, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 6.3 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bugfixes.
> > 
> [snip]
> > 
> >  * sftp(1): add support for resuming partial downloads using the "reget"
> >    command and on the sftp commandline or on the "get" commandline using
> >    the "-a" (append) option.
> > 
> 
> Some initial testing of the reget functionality shows that its
> interaction with the progress meter code is a bit buggy. In one test, it
> reported an inordinately high initial rate. In another test, it reported
> a negative rate.
> 
> A simple test is to reget a file which was already transferred
> successfully:
> 
> sftp> reget testfile.10gb
> Resuming /nobackupp1/imorgan/testfile.10gb to testfile.10gb
> /nobackupp1/imorgan/testfile.10gb               100%   10GB -2097151.-9KB/s   00:
> sftp>
> 

Another exemplar, which I should have included in my previous post is
found by interrupting the 10GB transfer after 10% and then doing a
reget. The reported rate and ETA right after the reget are rather
impressive, but unfortunately unrealistic. ;-)

sftp> reget testfile.10gb
Resuming /nobackupp1/imorgan/testfile.10gb to testfile.10gb
/nobackupp1/imorgan/testfile.10gb                 11% 1214MB 715.7MB/s   00:12 ETA^Interrupt


-- 
Iain Morgan

From loganaden at gmail.com  Thu Aug  1 07:34:49 2013
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Thu, 1 Aug 2013 01:34:49 +0400
Subject: openssh-unix-dev Digest, Vol 123, Issue 13
In-Reply-To: <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
References: <mailman.1727.1375213921.29288.openssh-unix-dev@mindrot.org>
 <CAOp4FwRjPK+0RgVD5wEQUmgEp0Ok7EYwyBkJWwEVVFPtZ2eM6w@mail.gmail.com>
 <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
 <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
Message-ID: <CAOp4FwSV0ZcY7vH7=u4-5ZuSKXPfAH0sP2UDxMjJKcn60sdCnQ@mail.gmail.com>

My test:

reget'ing an existing file:

sftp> reget 1000M
Resuming /root/1000M to 1000M
/root/1000M                                   100% 1000MB   0.0KB/s   00:00

Interrupting a download and trying again:
sftp> reget 1000M
Resuming /root/1000M to 1000M
/root/1000M                                     3%   40MB  10.0MB/s   01:36
ETA^Interrupt
/root/1000M                                     4%   46MB   9.7MB/s   01:38
ETA
Resuming /root/1000M to 1000M
/root/1000M                                    10%  106MB   9.8MB/s   01:31
ETA^Interrupt
sftp> reget 1000M
Resuming /root/1000M to 1000M
/root/1000M                                    13%  138MB   9.8MB/s   01:28
ETA^Interrupt

sftp> reget 1000M
Resuming /root/1000M to 1000M
/root/1000M                                   100% 1000MB  11.5MB/s   01:27




On Thu, Aug 1, 2013 at 1:30 AM, Loganaden Velvindron <loganaden at gmail.com>wrote:

> Hi Iain,
>
> Can you please try this patch ?
>
> Index: progressmeter.c
> ===================================================================
> RCS file: /cvs/openssh/progressmeter.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 progressmeter.c
> --- progressmeter.c	2 Jun 2013 13:46:24 -0000	1.40
> +++ progressmeter.c	31 Jul 2013 21:27:25 -0000
> @@ -147,7 +147,7 @@ refresh_progress_meter(void)
>  	if (elapsed != 0)
>  		cur_speed = (transferred / elapsed);
>  	else
> -		cur_speed = transferred;
> +		cur_speed = transferred - *counter;
>
>  #define AGE_FACTOR 0.9
>  	if (bytes_per_second != 0) {
>
>
> In case the diff gets garbled, it's available here:
>
> http://elandsys.com/~logan/progressmeter.diff
>
>
>
>
> On Wed, Jul 31, 2013 at 10:31 AM, Loganaden Velvindron <
> loganaden at gmail.com> wrote:
>
>>
>>
>>
>> On Wed, Jul 31, 2013 at 9:04 AM, Loganaden Velvindron <
>> loganaden at gmail.com> wrote:
>>
>>>
>>>
>>>> Message: 8
>>>> Date: Tue, 30 Jul 2013 12:46:50 -0700
>>>> From: Iain Morgan <imorgan at nas.nasa.gov>
>>>> To: Damien Miller <djm at mindrot.org>
>>>> Cc: "openssh-unix-dev at mindrot.org" <openssh-unix-dev at mindrot.org>
>>>> Subject: Re: Call for testing: OpenSSH-6.3
>>>> Message-ID: <20130730194649.GC18047 at linux124.nas.nasa.gov>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> On Wed, Jul 24, 2013 at 22:35:25 -0500, Damien Miller wrote:
>>>> > Hi,
>>>> >
>>>> > OpenSSH 6.3 is almost ready for release, so we would appreciate
>>>> testing
>>>> > on as many platforms and systems as possible. This release contains
>>>> > some substantial new features and a number of bugfixes.
>>>> >
>>>> [snip]
>>>> >
>>>> >  * sftp(1): add support for resuming partial downloads using the
>>>> "reget"
>>>> >    command and on the sftp commandline or on the "get" commandline
>>>> using
>>>> >    the "-a" (append) option.
>>>> >
>>>>
>>>> Some initial testing of the reget functionality shows that its
>>>> interaction with the progress meter code is a bit buggy. In one test, it
>>>> reported an inordinately high initial rate. In another test, it reported
>>>> a negative rate.
>>>>
>>>> A simple test is to reget a file which was already transferred
>>>> successfully:
>>>>
>>>> sftp> reget testfile.10gb
>>>> Resuming /nobackupp1/imorgan/testfile.10gb to testfile.10gb
>>>> /nobackupp1/imorgan/testfile.10gb               100%   10GB
>>>> -2097151.-9KB/s   00:
>>>> sftp>
>>>>
>>>> I think I hit a similar case:
>>
>> sftp> reget foo2
>> Resuming /home/loganaden/foo2 to foo2
>> /home/loganaden/foo2                          100% 2048KB  48.8KB/s
>> 00:42
>> sftp> reget foo2
>> Resuming /home/loganaden/foo2 to foo2
>> /home/loganaden/foo2                          100% 2048KB   2.0MB/s
>> 00:00
>>
>> I'm currently looking into this.
>>
>>
>>
>>>  --
>>>> Iain Morgan
>>>>
>>>>
>>>> I didn't encounter such problems during my testing. I'll try again @
>>> work with huge files
>>> and see if I can reproduce this.
>>>
>>>
>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> openssh-unix-dev mailing list
>>>> openssh-unix-dev at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>>
>>>>
>>>> End of openssh-unix-dev Digest, Vol 123, Issue 13
>>>> *************************************************
>>>>
>>>
>>>
>>>
>>> --
>>> This message is strictly personal and the opinions expressed do not
>>> represent those of my employers, either past or present.
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> This message is strictly personal and the opinions expressed do not
>> represent those of my employers, either past or present.
>>
>>
>>
>>
>>
>
>
> --
> This message is strictly personal and the opinions expressed do not
> represent those of my employers, either past or present.
>
>
>
>
>


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

From loganaden at gmail.com  Thu Aug  1 07:30:37 2013
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Thu, 1 Aug 2013 01:30:37 +0400
Subject: openssh-unix-dev Digest, Vol 123, Issue 13
In-Reply-To: <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
References: <mailman.1727.1375213921.29288.openssh-unix-dev@mindrot.org>
 <CAOp4FwRjPK+0RgVD5wEQUmgEp0Ok7EYwyBkJWwEVVFPtZ2eM6w@mail.gmail.com>
 <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
Message-ID: <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>

Hi Iain,

Can you please try this patch ?

Index: progressmeter.c
===================================================================
RCS file: /cvs/openssh/progressmeter.c,v
retrieving revision 1.40
diff -u -p -r1.40 progressmeter.c
--- progressmeter.c	2 Jun 2013 13:46:24 -0000	1.40
+++ progressmeter.c	31 Jul 2013 21:27:25 -0000
@@ -147,7 +147,7 @@ refresh_progress_meter(void)
 	if (elapsed != 0)
 		cur_speed = (transferred / elapsed);
 	else
-		cur_speed = transferred;
+		cur_speed = transferred - *counter;

 #define AGE_FACTOR 0.9
 	if (bytes_per_second != 0) {


In case the diff gets garbled, it's available here:

http://elandsys.com/~logan/progressmeter.diff




On Wed, Jul 31, 2013 at 10:31 AM, Loganaden Velvindron
<loganaden at gmail.com>wrote:

>
>
>
> On Wed, Jul 31, 2013 at 9:04 AM, Loganaden Velvindron <loganaden at gmail.com
> > wrote:
>
>>
>>
>>> Message: 8
>>> Date: Tue, 30 Jul 2013 12:46:50 -0700
>>> From: Iain Morgan <imorgan at nas.nasa.gov>
>>> To: Damien Miller <djm at mindrot.org>
>>> Cc: "openssh-unix-dev at mindrot.org" <openssh-unix-dev at mindrot.org>
>>> Subject: Re: Call for testing: OpenSSH-6.3
>>> Message-ID: <20130730194649.GC18047 at linux124.nas.nasa.gov>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> On Wed, Jul 24, 2013 at 22:35:25 -0500, Damien Miller wrote:
>>> > Hi,
>>> >
>>> > OpenSSH 6.3 is almost ready for release, so we would appreciate testing
>>> > on as many platforms and systems as possible. This release contains
>>> > some substantial new features and a number of bugfixes.
>>> >
>>> [snip]
>>> >
>>> >  * sftp(1): add support for resuming partial downloads using the
>>> "reget"
>>> >    command and on the sftp commandline or on the "get" commandline
>>> using
>>> >    the "-a" (append) option.
>>> >
>>>
>>> Some initial testing of the reget functionality shows that its
>>> interaction with the progress meter code is a bit buggy. In one test, it
>>> reported an inordinately high initial rate. In another test, it reported
>>> a negative rate.
>>>
>>> A simple test is to reget a file which was already transferred
>>> successfully:
>>>
>>> sftp> reget testfile.10gb
>>> Resuming /nobackupp1/imorgan/testfile.10gb to testfile.10gb
>>> /nobackupp1/imorgan/testfile.10gb               100%   10GB
>>> -2097151.-9KB/s   00:
>>> sftp>
>>>
>>> I think I hit a similar case:
>
> sftp> reget foo2
> Resuming /home/loganaden/foo2 to foo2
> /home/loganaden/foo2                          100% 2048KB  48.8KB/s
> 00:42
> sftp> reget foo2
> Resuming /home/loganaden/foo2 to foo2
> /home/loganaden/foo2                          100% 2048KB   2.0MB/s
> 00:00
>
> I'm currently looking into this.
>
>
>
>>  --
>>> Iain Morgan
>>>
>>>
>>> I didn't encounter such problems during my testing. I'll try again @
>> work with huge files
>> and see if I can reproduce this.
>>
>>
>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>>>
>>> End of openssh-unix-dev Digest, Vol 123, Issue 13
>>> *************************************************
>>>
>>
>>
>>
>> --
>> This message is strictly personal and the opinions expressed do not
>> represent those of my employers, either past or present.
>>
>>
>>
>>
>>
>
>
> --
> This message is strictly personal and the opinions expressed do not
> represent those of my employers, either past or present.
>
>
>
>
>


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

From loganaden at gmail.com  Thu Aug  1 07:52:27 2013
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Thu, 1 Aug 2013 01:52:27 +0400
Subject: openssh-unix-dev Digest, Vol 123, Issue 13
In-Reply-To: <CAOp4FwSV0ZcY7vH7=u4-5ZuSKXPfAH0sP2UDxMjJKcn60sdCnQ@mail.gmail.com>
References: <mailman.1727.1375213921.29288.openssh-unix-dev@mindrot.org>
 <CAOp4FwRjPK+0RgVD5wEQUmgEp0Ok7EYwyBkJWwEVVFPtZ2eM6w@mail.gmail.com>
 <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
 <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
 <CAOp4FwSV0ZcY7vH7=u4-5ZuSKXPfAH0sP2UDxMjJKcn60sdCnQ@mail.gmail.com>
Message-ID: <CAOp4FwQLNDNxfcqt=XbubR1xbY5HAh+jwU6uR9Vtt93rBqUh4w@mail.gmail.com>

usage() lacks the a flag:

Index: sftp.c
===================================================================
RCS file: /cvs/openssh/sftp.c,v
retrieving revision 1.161
diff -u -p -r1.161 sftp.c
--- sftp.c	25 Jul 2013 01:56:52 -0000	1.161
+++ sftp.c	31 Jul 2013 21:49:57 -0000
@@ -2116,7 +2116,7 @@ usage(void)
 	extern char *__progname;

 	fprintf(stderr,
-	    "usage: %s [-1246Cpqrv] [-B buffer_size] [-b batchfile] [-c cipher]\n"
+	    "usage: %s [-1246aCpqrv] [-B buffer_size] [-b batchfile] [-c cipher]\n"
 	    "          [-D sftp_server_path] [-F ssh_config] "
 	    "[-i identity_file] [-l limit]\n"
 	    "          [-o ssh_option] [-P port] [-R num_requests] "


http://elandsys.com/~logan/sftp.c.diff



On Thu, Aug 1, 2013 at 1:34 AM, Loganaden Velvindron <loganaden at gmail.com>wrote:

> My test:
>
> reget'ing an existing file:
>
> sftp> reget 1000M
> Resuming /root/1000M to 1000M
> /root/1000M                                   100% 1000MB   0.0KB/s   00:00
>
> Interrupting a download and trying again:
> sftp> reget 1000M
> Resuming /root/1000M to 1000M
> /root/1000M                                     3%   40MB  10.0MB/s
> 01:36 ETA^Interrupt
> /root/1000M                                     4%   46MB   9.7MB/s
> 01:38 ETA
> Resuming /root/1000M to 1000M
> /root/1000M                                    10%  106MB   9.8MB/s
> 01:31 ETA^Interrupt
> sftp> reget 1000M
> Resuming /root/1000M to 1000M
> /root/1000M                                    13%  138MB   9.8MB/s
> 01:28 ETA^Interrupt
>
> sftp> reget 1000M
> Resuming /root/1000M to 1000M
> /root/1000M                                   100% 1000MB  11.5MB/s   01:27
>
>
>
>
> On Thu, Aug 1, 2013 at 1:30 AM, Loganaden Velvindron <loganaden at gmail.com>wrote:
>
>> Hi Iain,
>>
>> Can you please try this patch ?
>>
>> Index: progressmeter.c
>> ===================================================================
>> RCS file: /cvs/openssh/progressmeter.c,v
>> retrieving revision 1.40
>> diff -u -p -r1.40 progressmeter.c
>> --- progressmeter.c	2 Jun 2013 13:46:24 -0000	1.40
>> +++ progressmeter.c	31 Jul 2013 21:27:25 -0000
>> @@ -147,7 +147,7 @@ refresh_progress_meter(void)
>>  	if (elapsed != 0)
>>  		cur_speed = (transferred / elapsed);
>>  	else
>> -		cur_speed = transferred;
>> +		cur_speed = transferred - *counter;
>>
>>  #define AGE_FACTOR 0.9
>>  	if (bytes_per_second != 0) {
>>
>>
>> In case the diff gets garbled, it's available here:
>>
>> http://elandsys.com/~logan/progressmeter.diff
>>
>>
>>
>>
>> On Wed, Jul 31, 2013 at 10:31 AM, Loganaden Velvindron <
>> loganaden at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Jul 31, 2013 at 9:04 AM, Loganaden Velvindron <
>>> loganaden at gmail.com> wrote:
>>>
>>>>
>>>>
>>>>> Message: 8
>>>>> Date: Tue, 30 Jul 2013 12:46:50 -0700
>>>>> From: Iain Morgan <imorgan at nas.nasa.gov>
>>>>> To: Damien Miller <djm at mindrot.org>
>>>>> Cc: "openssh-unix-dev at mindrot.org" <openssh-unix-dev at mindrot.org>
>>>>> Subject: Re: Call for testing: OpenSSH-6.3
>>>>> Message-ID: <20130730194649.GC18047 at linux124.nas.nasa.gov>
>>>>> Content-Type: text/plain; charset=us-ascii
>>>>>
>>>>> On Wed, Jul 24, 2013 at 22:35:25 -0500, Damien Miller wrote:
>>>>> > Hi,
>>>>> >
>>>>> > OpenSSH 6.3 is almost ready for release, so we would appreciate
>>>>> testing
>>>>> > on as many platforms and systems as possible. This release contains
>>>>> > some substantial new features and a number of bugfixes.
>>>>> >
>>>>> [snip]
>>>>> >
>>>>> >  * sftp(1): add support for resuming partial downloads using the
>>>>> "reget"
>>>>> >    command and on the sftp commandline or on the "get" commandline
>>>>> using
>>>>> >    the "-a" (append) option.
>>>>> >
>>>>>
>>>>> Some initial testing of the reget functionality shows that its
>>>>> interaction with the progress meter code is a bit buggy. In one test,
>>>>> it
>>>>> reported an inordinately high initial rate. In another test, it
>>>>> reported
>>>>> a negative rate.
>>>>>
>>>>> A simple test is to reget a file which was already transferred
>>>>> successfully:
>>>>>
>>>>> sftp> reget testfile.10gb
>>>>> Resuming /nobackupp1/imorgan/testfile.10gb to testfile.10gb
>>>>> /nobackupp1/imorgan/testfile.10gb               100%   10GB
>>>>> -2097151.-9KB/s   00:
>>>>> sftp>
>>>>>
>>>>> I think I hit a similar case:
>>>
>>> sftp> reget foo2
>>> Resuming /home/loganaden/foo2 to foo2
>>> /home/loganaden/foo2                          100% 2048KB  48.8KB/s
>>> 00:42
>>> sftp> reget foo2
>>> Resuming /home/loganaden/foo2 to foo2
>>> /home/loganaden/foo2                          100% 2048KB   2.0MB/s
>>> 00:00
>>>
>>> I'm currently looking into this.
>>>
>>>
>>>
>>>>  --
>>>>> Iain Morgan
>>>>>
>>>>>
>>>>> I didn't encounter such problems during my testing. I'll try again @
>>>> work with huge files
>>>> and see if I can reproduce this.
>>>>
>>>>
>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> openssh-unix-dev mailing list
>>>>> openssh-unix-dev at mindrot.org
>>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>>>
>>>>>
>>>>> End of openssh-unix-dev Digest, Vol 123, Issue 13
>>>>> *************************************************
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> This message is strictly personal and the opinions expressed do not
>>>> represent those of my employers, either past or present.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> This message is strictly personal and the opinions expressed do not
>>> represent those of my employers, either past or present.
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> This message is strictly personal and the opinions expressed do not
>> represent those of my employers, either past or present.
>>
>>
>>
>>
>>
>
>
> --
> This message is strictly personal and the opinions expressed do not
> represent those of my employers, either past or present.
>
>
>
>
>


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

From imorgan at nas.nasa.gov  Thu Aug  1 09:18:05 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 31 Jul 2013 16:18:05 -0700
Subject: openssh-unix-dev Digest, Vol 123, Issue 13
In-Reply-To: <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
References: <mailman.1727.1375213921.29288.openssh-unix-dev@mindrot.org>
 <CAOp4FwRjPK+0RgVD5wEQUmgEp0Ok7EYwyBkJWwEVVFPtZ2eM6w@mail.gmail.com>
 <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
 <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
Message-ID: <20130731231805.GE18047@linux124.nas.nasa.gov>

This seems to have helped. The unmbers look reasonable when the transfer
is resumed, but now there is similar strangeness when the transfer is
interrupted.

After the interrupt, a second status line now appears, which sometimes
reports unrealistically large or negative rates.

sftp> reget quuxfoo
Resuming /u1/imorgan/quuxfoo to quuxfoo
/u1/imorgan/quuxfoo                                                   80% 9949MB 109.0MB/s   00:21 ETA^Interrupt
/u1/imorgan/quuxfoo                                                   81% 9978MB -79437.-2KB/s   00:-2
sftp>

(This was using a 12GB testfile created with dd if=/dev/urandom.)

On Wed, Jul 31, 2013 at 16:30:37 -0500, Loganaden Velvindron wrote:
> Hi Iain,
> 
> Can you please try this patch ?
> 
> Index: progressmeter.c
> ===================================================================
> RCS file: /cvs/openssh/progressmeter.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 progressmeter.c
> --- progressmeter.c	2 Jun 2013 13:46:24 -0000	1.40
> +++ progressmeter.c	31 Jul 2013 21:27:25 -0000
> @@ -147,7 +147,7 @@ refresh_progress_meter(void)
>  	if (elapsed != 0)
>  		cur_speed = (transferred / elapsed);
>  	else
> -		cur_speed = transferred;
> +		cur_speed = transferred - *counter;
> 
>  #define AGE_FACTOR 0.9
>  	if (bytes_per_second != 0) {
> 

-- 
Iain Morgan

From imorgan at nas.nasa.gov  Thu Aug  1 09:28:03 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 31 Jul 2013 16:28:03 -0700
Subject: openssh-unix-dev Digest, Vol 123, Issue 13
In-Reply-To: <CAOp4FwQLNDNxfcqt=XbubR1xbY5HAh+jwU6uR9Vtt93rBqUh4w@mail.gmail.com>
References: <mailman.1727.1375213921.29288.openssh-unix-dev@mindrot.org>
 <CAOp4FwRjPK+0RgVD5wEQUmgEp0Ok7EYwyBkJWwEVVFPtZ2eM6w@mail.gmail.com>
 <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
 <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
 <CAOp4FwSV0ZcY7vH7=u4-5ZuSKXPfAH0sP2UDxMjJKcn60sdCnQ@mail.gmail.com>
 <CAOp4FwQLNDNxfcqt=XbubR1xbY5HAh+jwU6uR9Vtt93rBqUh4w@mail.gmail.com>
Message-ID: <20130731232802.GF18047@linux124.nas.nasa.gov>

A description of the -a command-line option is also missing from sftp.1.

On Wed, Jul 31, 2013 at 16:52:27 -0500, Loganaden Velvindron wrote:
> usage() lacks the a flag:
> 
> Index: sftp.c
> ===================================================================
> RCS file: /cvs/openssh/sftp.c,v
> retrieving revision 1.161
> diff -u -p -r1.161 sftp.c
> --- sftp.c	25 Jul 2013 01:56:52 -0000	1.161
> +++ sftp.c	31 Jul 2013 21:49:57 -0000
> @@ -2116,7 +2116,7 @@ usage(void)
>  	extern char *__progname;
> 
>  	fprintf(stderr,
> -	    "usage: %s [-1246Cpqrv] [-B buffer_size] [-b batchfile] [-c cipher]\n"
> +	    "usage: %s [-1246aCpqrv] [-B buffer_size] [-b batchfile] [-c cipher]\n"
>  	    "          [-D sftp_server_path] [-F ssh_config] "
>  	    "[-i identity_file] [-l limit]\n"
>  	    "          [-o ssh_option] [-P port] [-R num_requests] "
> 
> 
> http://elandsys.com/~logan/sftp.c.diff
> 
> 
> 

-- 
Iain Morgan

From djm at mindrot.org  Thu Aug  1 14:49:00 2013
From: djm at mindrot.org (Damien Miller)
Date: Thu, 1 Aug 2013 14:49:00 +1000 (EST)
Subject: openssh-unix-dev Digest, Vol 123, Issue 13
In-Reply-To: <CAOp4FwQLNDNxfcqt=XbubR1xbY5HAh+jwU6uR9Vtt93rBqUh4w@mail.gmail.com>
References: <mailman.1727.1375213921.29288.openssh-unix-dev@mindrot.org>
 <CAOp4FwRjPK+0RgVD5wEQUmgEp0Ok7EYwyBkJWwEVVFPtZ2eM6w@mail.gmail.com>
 <CAOp4FwSaPfLLeuR7LR8LMNstMvHT=268_civNShd4U4AfYf0uA@mail.gmail.com>
 <CAOp4FwSLZRrdPpU1px2r76aEdARQkP_50pP6Nkh9N0rf-fS0dA@mail.gmail.com>
 <CAOp4FwSV0ZcY7vH7=u4-5ZuSKXPfAH0sP2UDxMjJKcn60sdCnQ@mail.gmail.com>
 <CAOp4FwQLNDNxfcqt=XbubR1xbY5HAh+jwU6uR9Vtt93rBqUh4w@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1308011447380.8696@mindrot.org>

On Thu, 1 Aug 2013, Loganaden Velvindron wrote:

> usage() lacks the a flag:

Thanks, I'll commit this and adding -a to sftp.1 once the tree reopens
after the 6.3 release.

We're only taking patches for platform-specific or serious bugs at this
point.

-d

From binny.joseph at hp.com  Thu Aug  1 15:38:18 2013
From: binny.joseph at hp.com (Joseph, Binny Kallarackal (MCOU))
Date: Thu, 1 Aug 2013 05:38:18 +0000
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
Message-ID: <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>

Hi,
    Please find the snapshot test results on HP-UX platform.

    Used http://www.mindrot.org/openssh_snap/openssh-SNAP-20130730.tar.gz
    
Results :
    
OS              Build_Target            CC									OpenSSL	BUILD	TEST
==============  =====================   ================================================  	======= 	=====	================
HP-UX 11.31     ia64-hp-hpux11.31       HP C (bundled) for Integrity Servers B3910B A.06.12 	0.9.8t	OK	all tests passed
HP-UX 11.31     PA-RISC-hp-hpux11.31    HP92453-01 B.11.11.24 HP C Compiler				0.9.8y	OK	all tests passed
HP-UX 11.23     ia64-hp-hpux11.23       HP C/aC++ for Integrity Servers B3910B A.06.25   		0.9.8y	OK	all tests passed
HP-UX 11.23     PA-RISC -hp-hpux11.23   HP92453-01 B.11.11.22 HP C Compiler  				0.9.8y	OK	all tests passed
HP-UX 11.11     PA-RISC -hp-hpux11.11   HP92453-01 B.11.11.16 HP C Compiler  				0.9.7i	OK	all tests passed	

Thanks and Regards,
Binny.


-----Original Message-----
From: openssh-unix-dev-bounces+kulkarniamit=hp.com at mindrot.org [mailto:openssh-unix-dev-bounces+kulkarniamit=hp.com at mindrot.org] On Behalf Of Damien Miller
Sent: Thursday, July 25, 2013 9:05 AM
To: openssh-unix-dev at mindrot.org
Subject: Call for testing: OpenSSH-6.3

Hi,

OpenSSH 6.3 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes.

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 or via Mercurial at http://hg.mindrot.org/openssh

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.

Changes since OpenSSH 6.2
=========================

This release is predominantly a bugfix release:

Features:

 * sshd(8): add ssh-agent(1) support to sshd(8); allows encrypted hostkeys,
   or hostkeys on smartcards.

 * ssh(1)/sshd(8): allow optional time-based rekeying via a second argument
   to the existing RekeyLimit option. RekeyLimit is now supported in
   sshd_config as well as on the client.

 * sshd(8): standardise logging of information during user authentication.

   The presented key/cert and the remote username (if available) is now
   logged in the authentication success/failure message on the same log
   line as the local username, remote host/port and protocol in use.
   Certificates contents and the key fingerprint of the signing CA are
   logged too.

   Including all relevant information on a single line simplifies log
   analysis as it is no longer necessary to relate information scattered
   across multiple log entries.

 * ssh(1): add the ability to query supported ciphers, MAC algorithms, key
   types and key exchange methods. 

 * ssh(1): support ProxyCommand=- to allow support cases where stdin and
   stdout already point to the proxy.

 * ssh(1): allow IdenityFile=none

 * ssh(1)/sshd(8): add -E option to ssh and sshd to append debugging logs
   to a specified file instead of stderr or syslog.

 * sftp(1): add support for resuming partial downloads using the "reget"
   command and on the sftp commandline or on the "get" commandline using
   the "-a" (append) option.

 * ssh(1): add an "IgnoreUnknown" configuration option to selectively
   suppress errors arising from unknown configuration directives.

 * sshd(8): add support for submethods to be appended to required
   authentication methods listed via AuthenticationMethods.

Bugfixes:

 * sshd(8): fix refusal to accept certificate if a key of a different type
   to the CA key appeared in authorized_keys before the CA key.

 * ssh(1)/ssh-agent(1)/sshd(8): Use a monotonic time source for timers so
   that things like keepalives and rekeying will work properly over clock
   steps.

 * sftp(1): update progressmeter when data is acknowledged, not when it's
   sent. bz#2108

 * ssh(1)/ssh-keygen(1): improve error messages when the current user does
   not exist in /etc/passwd; bz#2125

 * ssh(1): reset the order in which public keys are tried after partial
   authentication success.

 * ssh-agent(1): clean up socket files after SIGINT when in debug mode;
   bz#2120

 * ssh(1) and others: avoid confusing error messages in the case of broken
   system resolver configurations; bz#2122

 * ssh(1): set TCP nodelay for connections started with -N; bz#2124

 * ssh(1): correct manual for permission requirements on ~/.ssh/config;
   bz#2078

 * ssh(1): fix ControlPersist timeout not triggering in cases where TCP
   connections have hung. bz#1917

 * ssh(1): properly deatch a ControlPersist master from its controlling
   terminal.

 * sftp(1): avoid crashes in libedit when it has been compiled with multi-
   byte character support. bz#1990

 * sshd(8): when running sshd -D, close stderr unless we have explicitly
   requested logging to stderr. bz#1976,

 * ssh(1): fix incomplete bzero; bz#2100

 * sshd(8): log and error and exit if ChrootDirectory is specified and
   running without root privileges.

 * Many improvements to the regression test suite. In particular log files
   are now saved from ssh and sshd after failures.

 * Fix a number of memory leaks. bz#1967 bz#2096 and others

 * sshd(8): fix public key authentication when a :style is appended to
   the requested username.

 * ssh(1): do not fatally exit when attempting to cleanup multiplexing-
   created channels that are incompletely opened. bz#2079

Portable OpenSSH:

 * Major overhaul of contrib/cygwin/README

 * Fix unaligned accesses in umac.c for strict-alignment architectures.
   bz#2101

 * Enable -Wsizeof-pointer-memaccess if the compiler supports it. bz#2100

 * Fix broken incorrect commandline reporting errors. bz#1448

 * Only include SHA256 and ECC-based key exchange methods if libcrypto has
   the required support.

 * A number of portability fixes for Android:
   * Don't try to use lastlog on Android; bz#2111
   * Fall back to using openssl's DES_crypt function on platorms that don't
     have a native crypt() function; bz#2112
   * Test for fd_mask, howmany and NFDBITS rather than trying to enumerate
     the plaforms that don't have them. bz#2085
   * Replace S_IWRITE, which isn't standardized, with S_IWUSR, which is.
     bz#2085
   * Add a null implementation of endgrent for platforms that don't have
     it (eg Android) bz#2087
   * Support platforms, such as Android, that lack struct passwd.pw_gecos.
     bz#2086

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From kevin.brott at gmail.com  Sat Aug  3 06:46:37 2013
From: kevin.brott at gmail.com (Kevin Brott)
Date: Fri, 2 Aug 2013 13:46:37 -0700
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
Message-ID: <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>

Mostly successful - couple of build issues. Also had to drop the hp-ux
11.11 builds - no working build environment for that platform here any
more. But I see herr Joseph has that covered. :)

 Using http://www.mindrot.org/openssh_snap/openssh-SNAP-20130803.tar.gz

 OS              Build_Target                CC
OpenSSL      BUILD TEST
 ==============  =========================== ================
============ ===== =================
 RHEL 2.1        i686-pc-linux-gnu           gcc 2.96-129.7.2
0.9.6b-eng   OK    all tests passed
 RHL 8.0         i686-pc-linux-gnu           gcc 3.2.2-5
0.9.7a       OK    FAIL**T1
 RHEL 3.0        i686-pc-linux-gnu           gcc 3.2.3-20
0.9.7a       OK    FAIL**T1
 Fedora Core r2  i686-pc-linux-gnu           gcc 3.3.3-7
0.9.7a       OK*1  all tests passed
 RHEL 4.0 nu6    i686-pc-linux-gnu           gcc 3.4.6
0.9.7a       OK*1  all tests passed
 RHEL 4.0 nu8    x86_64-unknown-linux-gnu    gcc 3.4.6-8
0.9.7a       OK*1  all tests passed
 RHEL 5.4        i686-pc-linux-gnu           gcc 4.1.2-46
0.9.8e-fips  OK    all tests passed
 RHEL 5.5        i686-pc-linux-gnu           gcc 4.1.2-48
0.9.8x       OK*4  all tests passed
 RHEL 5.5        x86_64-redhat-linux         gcc 4.1.2-48
0.9.8e-fips  OK    all tests passed
 RHEL 5.6        i686-pc-linux-gnu           gcc 4.1.2-50
0.9.8e-fips  OK    all tests passed
 RHEL 5.6        x86_64-redhat-linux         gcc 4.1.2-50
0.9.8x       OK*4  all tests passed
 RHEL 5.7        i686-redhat-linux           gcc 4.1.2-51
0.9.8e-fips  OK    all tests passed
 RHEL 5.7        x86_64-redhat-linux         gcc 4.1.2-51
0.9.8x       OK*3  all tests passed
 RHEL 5.8        i686-redhat-linux           gcc 4.1.2-52
0.9.8e-fips  OK    all tests passed
 RHEL 5.8        x86_64-redhat-linux         gcc 4.1.2-52
0.9.8x       OK*4  all tests passed
 RHEL 5.9        x86_64-redhat-linux         gcc 4.1.2-54
0.9.8x       OK*4  all tests passed
 RHEL 6.2        i686-redhat-linux           gcc 4.4.6-3
0.9.8x       OK*4  all tests passed**T2
 RHEL 6.2        x86_64-redhat-linux         gcc 4.4.6-3
1.0.0-fips   OK    all tests passed
 RHEL 6.3        x86_64-redhat-linux         gcc 4.4.7-3
1.0.0-fips   OK    all tests passed
 RHEL 6.4        i686-redhat-linux           gcc 4.4.7-3
1.0.0-fips   OK*4  all tests passed
 RHEL 6.4        x86_64-redhat-linux         gcc 4.4.7-3
1.0.0-fips   OK    all tests passed
 Ubuntu 8.04.04  i686-pc-linux-gnu           gcc 4.2.4-1ubuntu4
0.9.8g       OK    all tests passed
 Ubuntu 11.10    x86_64-linux-gnu            gcc 4.6.1-2ubuntu5
1.0.0e       OK    all tests passed**T3
 AIX 5300-12-04  powerpc-ibm-aix5.3.0.0      gcc 4.2.0
0.9.8k       OK    all tests passed
 AIX 5300-12-02  powerpc-ibm-aix5.3.0.0      xlc 08.00.0000.0016
0.9.8k       OK*2  all tests passed**T2
 AIX 6100-07-06  powerpc-ibm-aix6.1.0.0      gcc 4.2.0
0.9.8x       OK    all tests passed
 AIX 6100-07-06  powerpc-ibm-aix6.1.0.0      xlc 11.01.0000.0012
0.9.8x       OK    all tests passed
 AIX 7100-02-01  powerpc-ibm-aix7.1.0.0      gcc 4.2.0
0.9.8x       OK    all tests passed
 AIX 7100-02-01  powerpc-ibm-aix7.1.0.0      xlc 11.01.0000.0012
0.9.8x       OK    all tests passed
 HP-UX 11.23     ia64-hp-hpux11.23           gcc 4.1.1
0.9.8w       OK    all tests passed
 HP-UX 11.23     ia64-hp-hpux11.23           C/aC++ C.11.23.12
0.9.8w       OK    all tests passed
 HP-UX 11.31     ia64-hp-hpux11.31           gcc 4.6.2
0.9.8t       OK    all tests passed
 HP-UX 11.31     ia64-hp-hpux11.31           C/aC++ C.11.31.05
0.9.8t       OK    all tests passed

 # RHL     Red Hat Linux
 # RHEL    Red Hat Enterprise Linux

 # *1 --without-zlib-version-check
 # *2 missing zlib.h - so zlib 1.2.7 /var/tmp/ssh/
 # *3 missing openssl.h - so openssl 0.9.8x in /var/tmp/ssh/
 # *4 missing headers - so zlib 1.2.7 and openssl 0.9.8x in /var/tmp/ssh/

 **T1 run test connect.sh ...
      ssh connect with protocol 1 failed
      ssh connect with protocol 2 failed
      failed simple connect
      make[1]: *** [t-exec] Error 1
      make[1]: Leaving directory `/var/tmp/ssh/openssh/regress'
      make: *** [tests] Error 2
      --
      Looking at failure logs - this is what's killing it:
      clock_gettime: Invalid argument
      FAIL: ssh connect with protocol x failed

 **T2 test integrity: umac-64-etm at openssh.com @2902
      this test hangs hard (30-60 minutes runtime+) and has to be
      killed.  Happened on 1st 'make tests' not on subsequent.

 **T3 must 'service xrdp stop' for make tests to not hang

From djm at mindrot.org  Sat Aug  3 17:58:58 2013
From: djm at mindrot.org (Damien Miller)
Date: Sat, 3 Aug 2013 17:58:58 +1000 (EST)
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1308031757180.13530@mindrot.org>

On Fri, 2 Aug 2013, Kevin Brott wrote:

> Mostly successful - couple of build issues. Also had to drop the hp-ux
> 11.11 builds - no working build environment for that platform here any
> more. But I see herr Joseph has that covered. :)
> 
>  Using http://www.mindrot.org/openssh_snap/openssh-SNAP-20130803.tar.gz

First, thanks again for the very extensive set of tests.

>  OS              Build_Target                CC
> OpenSSL      BUILD TEST
>  ==============  =========================== ================
> ============ ===== =================
>  RHEL 2.1        i686-pc-linux-gnu           gcc 2.96-129.7.2
> 0.9.6b-eng   OK    all tests passed
>  RHL 8.0         i686-pc-linux-gnu           gcc 3.2.2-5
> 0.9.7a       OK    FAIL**T1
>  RHEL 3.0        i686-pc-linux-gnu           gcc 3.2.3-20
> 0.9.7a       OK    FAIL**T1

...

>  **T1 run test connect.sh ...
>       ssh connect with protocol 1 failed
>       ssh connect with protocol 2 failed
>       failed simple connect
>       make[1]: *** [t-exec] Error 1
>       make[1]: Leaving directory `/var/tmp/ssh/openssh/regress'
>       make: *** [tests] Error 2
>       --
>       Looking at failure logs - this is what's killing it:
>       clock_gettime: Invalid argument
>       FAIL: ssh connect with protocol x failed

Maybe these platforms lack CLOCK_MONOTONIC? Darren, perhaps we should
wrap clock_gettime and have a fallback for platforms that lack this?

-d

From dtucker at zip.com.au  Sat Aug  3 18:41:58 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 3 Aug 2013 18:41:58 +1000
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
Message-ID: <CALDDTe0+0OQjOS=MrtFYrfK6DXYEBTw5gMaZs4J+pP4btDus+w@mail.gmail.com>

On Sat, Aug 3, 2013 at 5:58 PM, Damien Miller <djm at mindrot.org> wrote:
>>       Looking at failure logs - this is what's killing it:
>>       clock_gettime: Invalid argument
[...]
> Maybe these platforms lack CLOCK_MONOTONIC? Darren, perhaps we should
> wrap clock_gettime and have a fallback for platforms that lack this?

I thought we did.  We check for clock_gettime in configure, and misc.c has:

#if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
        [...] clock_getttime [...]
#else
        return time(NULL);
#endif

So the fact that it compiled means that CLOCK_MONOTONIC is in the
headers, but the fact that it failed at runtime indicates that it's
not actually implemented.

Kevin, could you please try this test program on the problem system?
You'll probably need to compile it with -lrt.

#include <errno.h>
#include <stdio.h>
#include <time.h>
int main(void)
{
	struct timespec ts;
	int r = clock_gettime(CLOCK_MONOTONIC, &ts);
	printf("%d %d %ld\n", r, errno, (long)ts.tv_sec);
}

We could add a runtime fallback in misc.c:monotime() but it'd be kinda ugly.

-- 
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  Sat Aug  3 18:51:13 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 3 Aug 2013 18:51:13 +1000
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
Message-ID: <20130803085113.GA25525@gate.dtucker.net>

> We could add a runtime fallback in misc.c:monotime() but it'd be kinda
> ugly.

Like this?

Index: misc.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/misc.c,v
retrieving revision 1.118
diff -u -p -r1.118 misc.c
--- misc.c	18 Jul 2013 06:13:19 -0000	1.118
+++ misc.c	3 Aug 2013 08:41:31 -0000
@@ -859,14 +859,17 @@ monotime(void)
 {
 #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
 	struct timespec ts;
+	static int gettime_failed = 0;
 
-	if (clock_gettime(CLOCK_MONOTONIC, &ts) != 0)
-		fatal("clock_gettime: %s", strerror(errno));
+	if (!gettime_failed) {
+		if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0)
+			return (ts.tv_sec);
+		debug3("clock_gettime: %s", strerror(errno));
+		gettime_failed = 1;
+	}
+#endif
 
-	return (ts.tv_sec);
-#else
 	return time(NULL);
-#endif
 }
 
 void

-- 
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 keisial at gmail.com  Sat Aug  3 22:05:39 2013
From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 03 Aug 2013 14:05:39 +0200
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
Message-ID: <51FCF213.1000805@gmail.com>

I only saw a few compiler warnings:


regress/modpipe.c:83:6: ?parse_modification? function: format ?%lli? 
(?long long int *?) but argument 4 is ?u_int64_t *?

servconf.c:2066:2: ?dump_config? function: format ?%lld? (?long long 
int?) but argument 2 is ?int64_t?
printf("rekeylimit %lld %d\n", o->rekey_limit, o->rekey_interval);


md5crypt.c:53:42: ?md5_crypt? function variable ?p? set but not used 
[-Wunused-but-set-variable]
(the ?p = passwd + strlen(passwd);? line is dead code, the strlcat()s 
below were probably using p instead of passwd earlier)



From kevin.brott at gmail.com  Sun Aug  4 05:44:30 2013
From: kevin.brott at gmail.com (Kevin Brott)
Date: Sat, 03 Aug 2013 12:44:30 -0700
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <CALDDTe0+0OQjOS=MrtFYrfK6DXYEBTw5gMaZs4J+pP4btDus+w@mail.gmail.com>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <CALDDTe0+0OQjOS=MrtFYrfK6DXYEBTw5gMaZs4J+pP4btDus+w@mail.gmail.com>
Message-ID: <51FD5D9E.2070702@gmail.com>

On 2013-08-03 01:41, Darren Tucker wrote:
> On Sat, Aug 3, 2013 at 5:58 PM, Damien Miller <djm at mindrot.org> wrote:
>>>        Looking at failure logs - this is what's killing it:
>>>        clock_gettime: Invalid argument
> [...]
>> Maybe these platforms lack CLOCK_MONOTONIC? Darren, perhaps we should
>> wrap clock_gettime and have a fallback for platforms that lack this?
> I thought we did.  We check for clock_gettime in configure, and misc.c has:
>
> #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
>          [...] clock_getttime [...]
> #else
>          return time(NULL);
> #endif
>
> So the fact that it compiled means that CLOCK_MONOTONIC is in the
> headers, but the fact that it failed at runtime indicates that it's
> not actually implemented.
>
> Kevin, could you please try this test program on the problem system?
> You'll probably need to compile it with -lrt.
>
> #include <errno.h>
> #include <stdio.h>
> #include <time.h>
> int main(void)
> {
> 	struct timespec ts;
> 	int r = clock_gettime(CLOCK_MONOTONIC, &ts);
> 	printf("%d %d %ld\n", r, errno, (long)ts.tv_sec);
> }
>
> We could add a runtime fallback in misc.c:monotime() but it'd be kinda ugly.
>

*Similar results on both systems affected ... *

$ cat > test.c
#include <errno.h>
#include <stdio.h>
#include <time.h>
int main(void)
{
         struct timespec ts;
         int r = clock_gettime(CLOCK_MONOTONIC, &ts);
         printf("%d %d %ld\n", r, errno, (long)ts.tv_sec);
}

$ gcc -o test test.c
/tmp/ccoXSQXe.o(.text+0x1a): In function `main':
: undefined reference to `clock_gettime'
collect2: ld returned 1 exit status

$ gcc -lrt -o test test.c

$ file test
test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

$ ldd test
         librt.so.1 => /lib/librt.so.1 (0xb7fce000)
         libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
         libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7f7d000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fed000)

RHL8$ ./test
-1 22 1108578828

RHEL3$ ./test
-1 22 -1218445280

*For comparison on unaffected Fedora Core 2 system:*
$FC2$ ./test
0 0 2078415

*On the older RHEL 2.1 system - ssh builds and tests fine, yet the test program won't.
*$ gcc -lrt -o test test.c
test.c: In function `main':
test.c:7: `CLOCK_MONOTONIC' undeclared (first use in this function)
test.c:7: (Each undeclared identifier is reported only once
test.c:7: for each function it appears in.)



From djm at mindrot.org  Sun Aug  4 07:57:41 2013
From: djm at mindrot.org (Damien Miller)
Date: Sun, 4 Aug 2013 07:57:41 +1000 (EST)
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <51FD5D9E.2070702@gmail.com>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <CALDDTe0+0OQjOS=MrtFYrfK6DXYEBTw5gMaZs4J+pP4btDus+w@mail.gmail.com>
 <51FD5D9E.2070702@gmail.com>
Message-ID: <alpine.BSO.2.03.1308040733510.13530@mindrot.org>

On Sat, 3 Aug 2013, Kevin Brott wrote:

> RHL8$ ./test
> -1 22 1108578828
> 
> RHEL3$ ./test
> -1 22 -1218445280
> 
> For comparison on unaffected Fedora Core 2 system:
> $FC2$ ./test
> 0 0 2078415
> 
> On the older RHEL 2.1 system - ssh builds and tests fine, yet the test
> program won't.
> $ gcc -lrt -o test test.c
> test.c: In function `main':
> test.c:7: `CLOCK_MONOTONIC' undeclared (first use in this function)
> test.c:7: (Each undeclared identifier is reported only once
> test.c:7: for each function it appears in.)

I guess the CLOCK_MONOTONIC define was added before ther kernel support was.

From djm at mindrot.org  Sun Aug  4 11:20:10 2013
From: djm at mindrot.org (Damien Miller)
Date: Sun, 4 Aug 2013 11:20:10 +1000 (EST)
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <20130803085113.GA25525@gate.dtucker.net>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <20130803085113.GA25525@gate.dtucker.net>
Message-ID: <alpine.BSO.2.03.1308041119250.13530@mindrot.org>

On Sat, 3 Aug 2013, Darren Tucker wrote:

> > We could add a runtime fallback in misc.c:monotime() but it'd be kinda
> > ugly.
> 
> Like this?

ok djm if it fixes Kevin's problem. Kevin, could you please try this patch?

> Index: misc.c
> ===================================================================
> RCS file: /home/dtucker/openssh/cvs/openssh/misc.c,v
> retrieving revision 1.118
> diff -u -p -r1.118 misc.c
> --- misc.c	18 Jul 2013 06:13:19 -0000	1.118
> +++ misc.c	3 Aug 2013 08:41:31 -0000
> @@ -859,14 +859,17 @@ monotime(void)
>  {
>  #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
>  	struct timespec ts;
> +	static int gettime_failed = 0;
>  
> -	if (clock_gettime(CLOCK_MONOTONIC, &ts) != 0)
> -		fatal("clock_gettime: %s", strerror(errno));
> +	if (!gettime_failed) {
> +		if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0)
> +			return (ts.tv_sec);
> +		debug3("clock_gettime: %s", strerror(errno));
> +		gettime_failed = 1;
> +	}
> +#endif
>  
> -	return (ts.tv_sec);
> -#else
>  	return time(NULL);
> -#endif
>  }
>  
>  void
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From dtucker at zip.com.au  Sun Aug  4 16:38:30 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 4 Aug 2013 16:38:30 +1000
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <51FD5D9E.2070702@gmail.com>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <CALDDTe0+0OQjOS=MrtFYrfK6DXYEBTw5gMaZs4J+pP4btDus+w@mail.gmail.com>
 <51FD5D9E.2070702@gmail.com>
Message-ID: <CALDDTe030=SeDmm6YuiaxoW5NzT5pqqOu_WBx8v5VU8R-ZbpdQ@mail.gmail.com>

On Sun, Aug 4, 2013 at 5:44 AM, Kevin Brott <kevin.brott at gmail.com> wrote:
> Similar results on both systems affected ...
[...]
> RHL8$ ./test
> -1 22 1108578828
>
> RHEL3$ ./test
> -1 22 -1218445280
[...]
> On the older RHEL 2.1 system - ssh builds and tests fine, yet the test
> program won't.
[...]
> test.c:7: `CLOCK_MONOTONIC' undeclared (first use in this function)

The older system works because of the code that enables the use of
clock_gettime also checks that CLOCK_MONOTONIC is defined.  On the
older system it isn't, and the code correctly falls back to use plain
old time(2).

The problem seems to be the systems where CLOCK_MONOTONIC is in the
headers but not the kernel (or maybe librt).  Note that it's possible
for this to change post build time, eg after a kernel or library
update.

Based on the output of the test program I'm reasonably confident the
patch is the right thing to do.  I just tested with "#define
clock_gettime(a,b) -1" and got a binary that passed regress tests but
has no clock_gettime symbol in it, but if you could confirm it works
on the problematic system I'd appreciate it.

Thanks!

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

From fredports at mufley.com  Mon Aug  5 09:11:41 2013
From: fredports at mufley.com (Frederico Costa)
Date: Mon, 05 Aug 2013 00:11:41 +0100
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
Message-ID: <950f7e627009f74f1b1dda50be349e71@www.mufley.com>

Hi...

done the testing using openssh-SNAP-20130805.tar.gz.

Running on FreeBSD:

FreeBSD 9.1-RELEASE-p5 FreeBSD 9.1-RELEASE-p5 #0 r253835: Wed Jul 31 
15:53:35 BST 2013

And i got the nice:

--
ok key revocation lists
all tests passed
--

Fred



From ondrej.caletka at gmail.com  Mon Aug  5 20:44:45 2013
From: ondrej.caletka at gmail.com (=?windows-1250?Q?Ond=F8ej_Caletka?=)
Date: Mon, 05 Aug 2013 12:44:45 +0200
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
Message-ID: <51FF821D.5040004@gmail.com>

Hi,

Dne 25.7.2013 05:35, Damien Miller napsal(a):
> Hi,
> 
> OpenSSH 6.3 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.

Is there any chance that bugs bz#2040 and bz#2041 would be fixed in some
future release? Is there anything I can do about it?

Regards,

Ond?ej Caletka

From vinschen at redhat.com  Mon Aug  5 22:01:27 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 5 Aug 2013 14:01:27 +0200
Subject: [patch/Cygwin]: Simplify host key generation in ssh-host-config script
Message-ID: <20130805120127.GO23060@calimero.vinschen.de>

Hi,

as the subject says, the below patch just simplifies the host
key generation in the Cygwin-specific ssh-host-config script.
Rather than testing and generating each key, call ssh-keygen -A.

Could somebody with checkin rights please apply?


Thanks,
Corinna


Index: contrib/cygwin/ssh-host-config
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
retrieving revision 1.33
diff -u -p -r1.33 ssh-host-config
--- contrib/cygwin/ssh-host-config	2 Jul 2013 10:06:47 -0000	1.33
+++ contrib/cygwin/ssh-host-config	5 Aug 2013 12:00:39 -0000
@@ -68,54 +68,6 @@ password_value=
 opt_force=no
 
 # ======================================================================
-# Routine: create_host_keys
-# ======================================================================
-create_host_keys() {
-  local ret=0
-
-  if [ ! -f "${SYSCONFDIR}/ssh_host_key" ]
-  then
-    csih_inform "Generating ${SYSCONFDIR}/ssh_host_key"
-    if ! /usr/bin/ssh-keygen -t rsa1 -f ${SYSCONFDIR}/ssh_host_key -N '' > /dev/null
-    then
-    	csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!"
-	let ++ret
-    fi
-  fi
-
-  if [ ! -f "${SYSCONFDIR}/ssh_host_rsa_key" ]
-  then
-    csih_inform "Generating ${SYSCONFDIR}/ssh_host_rsa_key"
-    if ! /usr/bin/ssh-keygen -t rsa -f ${SYSCONFDIR}/ssh_host_rsa_key -N '' > /dev/null
-    then
-    	csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!"
-	let ++ret
-    fi
-  fi
-
-  if [ ! -f "${SYSCONFDIR}/ssh_host_dsa_key" ]
-  then
-    csih_inform "Generating ${SYSCONFDIR}/ssh_host_dsa_key"
-    if ! /usr/bin/ssh-keygen -t dsa -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' > /dev/null
-    then
-    	csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!"
-	let ++ret
-    fi
-  fi
-
-  if [ ! -f "${SYSCONFDIR}/ssh_host_ecdsa_key" ]
-  then
-    csih_inform "Generating ${SYSCONFDIR}/ssh_host_ecdsa_key"
-    if ! /usr/bin/ssh-keygen -t ecdsa -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' > /dev/null
-    then
-    	csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!"
-	let ++ret
-    fi
-  fi
-  return $ret
-} # --- End of create_host_keys --- #
-
-# ======================================================================
 # Routine: update_services_file
 # ======================================================================
 update_services_file() {
@@ -719,8 +671,8 @@ then
   let ++warning_cnt
 fi
 
-# host keys
-create_host_keys || let warning_cnt+=$?
+# generate missing host keys
+/usr/bin/ssh-keygen -A || let warning_cnt+=$?
 
 # handle ssh_config
 csih_install_config "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt


-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From dtucker at zip.com.au  Tue Aug  6 00:47:53 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 6 Aug 2013 00:47:53 +1000
Subject: [patch/Cygwin]: Simplify host key generation in ssh-host-config
 script
In-Reply-To: <20130805120127.GO23060@calimero.vinschen.de>
References: <20130805120127.GO23060@calimero.vinschen.de>
Message-ID: <CALDDTe11tzXPnhj0-LFrH_yx81PPHn0g_GpJ7mZ_bwFf1_cJ7Q@mail.gmail.com>

On Mon, Aug 5, 2013 at 10:01 PM, Corinna Vinschen <vinschen at redhat.com> wrote:
> as the subject says, the below patch just simplifies the host
> key generation in the Cygwin-specific ssh-host-config script.
> Rather than testing and generating each key, call ssh-keygen -A.
>
> Could somebody with checkin rights please apply?

is it urgent enough to apply before the 6.3 release?  if not I'll
apply it afterward.

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

From vinschen at redhat.com  Tue Aug  6 01:31:57 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 5 Aug 2013 17:31:57 +0200
Subject: [patch/Cygwin]: Simplify host key generation in ssh-host-config
 script
In-Reply-To: <CALDDTe11tzXPnhj0-LFrH_yx81PPHn0g_GpJ7mZ_bwFf1_cJ7Q@mail.gmail.com>
References: <20130805120127.GO23060@calimero.vinschen.de>
 <CALDDTe11tzXPnhj0-LFrH_yx81PPHn0g_GpJ7mZ_bwFf1_cJ7Q@mail.gmail.com>
Message-ID: <20130805153157.GT23060@calimero.vinschen.de>

On Aug  6 00:47, Darren Tucker wrote:
> On Mon, Aug 5, 2013 at 10:01 PM, Corinna Vinschen <vinschen at redhat.com> wrote:
> > as the subject says, the below patch just simplifies the host
> > key generation in the Cygwin-specific ssh-host-config script.
> > Rather than testing and generating each key, call ssh-keygen -A.
> >
> > Could somebody with checkin rights please apply?
> 
> is it urgent enough to apply before the 6.3 release?  if not I'll
> apply it afterward.

It's not urgent.  The current method works, it's just inelegant.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From kevin.brott at gmail.com  Tue Aug  6 01:51:16 2013
From: kevin.brott at gmail.com (Kevin Brott)
Date: Mon, 5 Aug 2013 08:51:16 -0700
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1308041119250.13530@mindrot.org>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <20130803085113.GA25525@gate.dtucker.net>
 <alpine.BSO.2.03.1308041119250.13530@mindrot.org>
Message-ID: <CAMv58rZJrowQ7QzZcVtUKBwZp7bNB577eMjdjLC_tOQxU4MEsA@mail.gmail.com>

Applying patch to openssh-SNAP-20130806.tar.gz - and testing against oldest
four hosts gives ...

Using http://www.mindrot.org/openssh_snap/openssh-SNAP-20130806p1.tar.gz

OS              Build_Target                CC
OpenSSL      BUILD TEST
==============  =========================== ================
============ ===== =================
RHEL 2.1        i686-pc-linux-gnu           gcc 2.96-129.7.2
0.9.6b-eng   OK    all tests passed
RHL 8.0         i686-pc-linux-gnu           gcc 3.2.2-5
0.9.7a       OK    all tests passed
RHEL 3.0        i686-pc-linux-gnu           gcc 3.2.3-20
0.9.7a       OK    all tests passed
Fedora Core r2  i686-pc-linux-gnu           gcc 3.3.3-7
0.9.7a       OK*1  all tests passed

# RHL     Red Hat Linux
# RHEL    Red Hat Enterprise Linux

# *1 --without-zlib-version-check

So it looks like that patch works fine for the hosts with the previous
build issue - without breaking the ones that already worked.



On Sat, Aug 3, 2013 at 6:20 PM, Damien Miller <djm at mindrot.org> wrote:

> On Sat, 3 Aug 2013, Darren Tucker wrote:
>
> > > We could add a runtime fallback in misc.c:monotime() but it'd be kinda
> > > ugly.
> >
> > Like this?
>
> ok djm if it fixes Kevin's problem. Kevin, could you please try this patch?
>
> > Index: misc.c
> > ===================================================================
> > RCS file: /home/dtucker/openssh/cvs/openssh/misc.c,v
> > retrieving revision 1.118
> > diff -u -p -r1.118 misc.c
> > --- misc.c    18 Jul 2013 06:13:19 -0000      1.118
> > +++ misc.c    3 Aug 2013 08:41:31 -0000
> > @@ -859,14 +859,17 @@ monotime(void)
> >  {
> >  #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
> >       struct timespec ts;
> > +     static int gettime_failed = 0;
> >
> > -     if (clock_gettime(CLOCK_MONOTONIC, &ts) != 0)
> > -             fatal("clock_gettime: %s", strerror(errno));
> > +     if (!gettime_failed) {
> > +             if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0)
> > +                     return (ts.tv_sec);
> > +             debug3("clock_gettime: %s", strerror(errno));
> > +             gettime_failed = 1;
> > +     }
> > +#endif
> >
> > -     return (ts.tv_sec);
> > -#else
> >       return time(NULL);
> > -#endif
> >  }
> >
> >  void
> >
> > --
> > Darren Tucker (dtucker at zip.com.au)
> > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
> >     Good judgement comes with experience. Unfortunately, the experience
> > usually comes from bad judgement.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>



-- 
# include <stddisclaimer.h>
/* Kevin  Brott <Kevin.Brott at gmail.com> */

From djm at mindrot.org  Tue Aug  6 10:53:57 2013
From: djm at mindrot.org (Damien Miller)
Date: Tue, 6 Aug 2013 10:53:57 +1000 (EST)
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <CAMv58rZJrowQ7QzZcVtUKBwZp7bNB577eMjdjLC_tOQxU4MEsA@mail.gmail.com>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <20130803085113.GA25525@gate.dtucker.net>
 <alpine.BSO.2.03.1308041119250.13530@mindrot.org>
 <CAMv58rZJrowQ7QzZcVtUKBwZp7bNB577eMjdjLC_tOQxU4MEsA@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1308061053360.13530@mindrot.org>

excellent - thanks again for testing. Darren, could you please commit?

On Mon, 5 Aug 2013, Kevin Brott wrote:

> 
> Applying patch to openssh-SNAP-20130806.tar.gz - and testing against oldest
> four hosts gives ...
> 
> Using http://www.mindrot.org/openssh_snap/openssh-SNAP-20130806p1.tar.gz
> 
> OS              Build_Target                CC                  OpenSSL     
> BUILD TEST
> ==============  =========================== ================    ============
> ===== =================
> RHEL 2.1        i686-pc-linux-gnu           gcc 2.96-129.7.2    0.9.6b-eng  
> OK    all tests passed
> RHL 8.0         i686-pc-linux-gnu           gcc 3.2.2-5         0.9.7a      
> OK    all tests passed
> RHEL 3.0        i686-pc-linux-gnu           gcc 3.2.3-20        0.9.7a      
> OK    all tests passed   
> Fedora Core r2  i686-pc-linux-gnu           gcc 3.3.3-7         0.9.7a      
> OK*1  all tests passed
> 
> # RHL     Red Hat Linux
> # RHEL    Red Hat Enterprise Linux
> 
> # *1 --without-zlib-version-check
> 
> So it looks like that patch works fine for the hosts with the previous build
> issue - without breaking the ones that already worked.
> 
> 
> 
> On Sat, Aug 3, 2013 at 6:20 PM, Damien Miller <djm at mindrot.org> wrote:
>       On Sat, 3 Aug 2013, Darren Tucker wrote:
> 
>       > > We could add a runtime fallback in misc.c:monotime() but
>       it'd be kinda
>       > > ugly.
>       >
>       > Like this?
> 
> ok djm if it fixes Kevin's problem. Kevin, could you please try this
> patch?
> 
> > Index: misc.c
> > ===================================================================
> > RCS file: /home/dtucker/openssh/cvs/openssh/misc.c,v
> > retrieving revision 1.118
> > diff -u -p -r1.118 misc.c
> > --- misc.c    18 Jul 2013 06:13:19 -0000      1.118
> > +++ misc.c    3 Aug 2013 08:41:31 -0000
> > @@ -859,14 +859,17 @@ monotime(void)
> >  {
> >  #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC)
> >       struct timespec ts;
> > +     static int gettime_failed = 0;
> >
> > -     if (clock_gettime(CLOCK_MONOTONIC, &ts) != 0)
> > -             fatal("clock_gettime: %s", strerror(errno));
> > +     if (!gettime_failed) {
> > +             if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0)
> > +                     return (ts.tv_sec);
> > +             debug3("clock_gettime: %s", strerror(errno));
> > +             gettime_failed = 1;
> > +     }
> > +#endif
> >
> > -     return (ts.tv_sec);
> > -#else
> >       return time(NULL);
> > -#endif
> >  }
> >
> >  void
> >
> > --
> > Darren Tucker (dtucker at zip.com.au)
> > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4
> FA69
> >     Good judgement comes with experience. Unfortunately, the
> experience
> > usually comes from bad judgement.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> 
> 
> 
> 
> --
> # include <stddisclaimer.h>
> /* Kevin  Brott <Kevin.Brott at gmail.com> */
> 
> 
> 

From andrew at pimlott.net  Tue Aug  6 05:04:44 2013
From: andrew at pimlott.net (Andrew Pimlott)
Date: Mon, 05 Aug 2013 12:04:44 -0700
Subject: RemoteForward and dynamically allocated listen port
Message-ID: <1375723816-sup-4743@pimlott.net>

Specifying a RemoteForward of 0:example.com:1234 dynamically allocates
the listen port on the server, and then reports it to ... the client!
Where it is practically useless.  Was this someone's idea of a joke?

Presumably not--there are some technical obstacles to reporting it to
the remote process.  I'd like to help solve that problem.

The natural way to me would be to extend the syntax of RemoteForward to
allow ENV_VAR:example.com:1234.  This would set $ENV_VAR to the
dynamically alocated port in the remote process.  However, the protocol
passes the listen port as a u_int.  A hack might be to pack the env var
name into the listen address and set the listen port to a special value
to indicate this, but I don't know if this is playing too fast and
loose.  A cleaner solution would be to add a new request type.  I
imagine that ssh protocol changes are made conservatively, so I don't
know how viable these options are.

Without changing the protocol, we could at least set an environment
variable for each dynamically allocated port, numbered by the order of
the RemoteForward requests, eg. SSH_REMOTE_FORWARD_PORT_1,
SSH_REMOTE_FORWARD_PORT_2, ....  I was able to wedge a proof of concept
into session.c:do_setup_env (patch below).  It's a hack because there
doesn't seem to be an API to iterate channels outside of channels.c.
Would it be agreeable to export channels and channels_alloc?  Also,
struct Channel doesn't let you tell which forwards were dynamically
allocated, so an environment variable is set for all RemoteForwards.
This could be changed by extending struct Channel, though it isn't a
show-stopper for me.

Last thought: if a new protocol request type were added, it should make
it easy to add support for forwarding unix sockets, which I have missed
for a long time.

Would any of these approaches be acceptable?  Any other ideas?

Thanks,
Andrew

--- session.c.orig	2013-08-03 13:22:10.354171156 -0700
+++ session.c	2013-08-05 09:58:00.017397667 -0700
@@ -1307,6 +1307,17 @@
 		child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME,
 		    auth_sock_name);
 
+	char name[256];
+	u_int n = 0;
+	for (i = 0; i < 100; i++) {
+		Channel *c = channel_by_id(i);
+		if (c == NULL || c->type != SSH_CHANNEL_RPORT_LISTENER)
+			continue;
+		snprintf(name, sizeof name, "SSH_REMOTE_FORWARD_PORT_%d", n);
+		snprintf(buf, sizeof buf, "%d", c->listening_port);
+		child_set_env(&env, &envsize, name, buf);
+	}
+
 	/* read $HOME/.ssh/environment. */
 	if (options.permit_user_env && !options.use_login) {
 		snprintf(buf, sizeof buf, "%.200s/.ssh/environment",

From alex at alex.org.uk  Wed Aug  7 00:29:41 2013
From: alex at alex.org.uk (Alex Bligh)
Date: Tue, 6 Aug 2013 15:29:41 +0100
Subject: RemoteForward and dynamically allocated listen port
In-Reply-To: <1375723816-sup-4743@pimlott.net>
References: <1375723816-sup-4743@pimlott.net>
Message-ID: <74254AB9-2F06-40C5-87F4-E3B7D4FB0908@alex.org.uk>


On 5 Aug 2013, at 20:04, Andrew Pimlott wrote:

> Specifying a RemoteForward of 0:example.com:1234 dynamically allocates
> the listen port on the server, and then reports it to ... the client!
> Where it is practically useless.  Was this someone's idea of a joke?

Yes this is not great; I've wanted this too.

One problem with your approach is that the child may already be running
by the time the remote forward is processed; that could be ten minutes
after the session start.

-- 
Alex Bligh





From mfriedl at gmail.com  Wed Aug  7 07:13:31 2013
From: mfriedl at gmail.com (Markus Friedl)
Date: Tue, 6 Aug 2013 23:13:31 +0200
Subject: RemoteForward and dynamically allocated listen port
In-Reply-To: <1375723816-sup-4743@pimlott.net>
References: <1375723816-sup-4743@pimlott.net>
Message-ID: <9C327506-3890-4D0F-8CC6-73E6984E0438@gmail.com>

see http://www.openssh.com/txt/release-5.6

 * ssh(1) connection multiplexing now supports remote forwarding with
   dynamic port allocation and can report the allocated port back to
   the user:

     LPORT=`ssh -S muxsocket -R0:localhost:25 -O forward somehost`


-m


Am 05.08.2013 um 21:04 schrieb Andrew Pimlott <andrew at pimlott.net>:

> Specifying a RemoteForward of 0:example.com:1234 dynamically allocates
> the listen port on the server, and then reports it to ... the client!
> Where it is practically useless.  Was this someone's idea of a joke?
> 
> Presumably not--there are some technical obstacles to reporting it to
> the remote process.  I'd like to help solve that problem.
> 
> The natural way to me would be to extend the syntax of RemoteForward to
> allow ENV_VAR:example.com:1234.  This would set $ENV_VAR to the
> dynamically alocated port in the remote process.  However, the protocol
> passes the listen port as a u_int.  A hack might be to pack the env var
> name into the listen address and set the listen port to a special value
> to indicate this, but I don't know if this is playing too fast and
> loose.  A cleaner solution would be to add a new request type.  I
> imagine that ssh protocol changes are made conservatively, so I don't
> know how viable these options are.
> 
> Without changing the protocol, we could at least set an environment
> variable for each dynamically allocated port, numbered by the order of
> the RemoteForward requests, eg. SSH_REMOTE_FORWARD_PORT_1,
> SSH_REMOTE_FORWARD_PORT_2, ....  I was able to wedge a proof of concept
> into session.c:do_setup_env (patch below).  It's a hack because there
> doesn't seem to be an API to iterate channels outside of channels.c.
> Would it be agreeable to export channels and channels_alloc?  Also,
> struct Channel doesn't let you tell which forwards were dynamically
> allocated, so an environment variable is set for all RemoteForwards.
> This could be changed by extending struct Channel, though it isn't a
> show-stopper for me.
> 
> Last thought: if a new protocol request type were added, it should make
> it easy to add support for forwarding unix sockets, which I have missed
> for a long time.
> 
> Would any of these approaches be acceptable?  Any other ideas?
> 
> Thanks,
> Andrew
> 
> --- session.c.orig	2013-08-03 13:22:10.354171156 -0700
> +++ session.c	2013-08-05 09:58:00.017397667 -0700
> @@ -1307,6 +1307,17 @@
> 		child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME,
> 		    auth_sock_name);
> 
> +	char name[256];
> +	u_int n = 0;
> +	for (i = 0; i < 100; i++) {
> +		Channel *c = channel_by_id(i);
> +		if (c == NULL || c->type != SSH_CHANNEL_RPORT_LISTENER)
> +			continue;
> +		snprintf(name, sizeof name, "SSH_REMOTE_FORWARD_PORT_%d", n);
> +		snprintf(buf, sizeof buf, "%d", c->listening_port);
> +		child_set_env(&env, &envsize, name, buf);
> +	}
> +
> 	/* read $HOME/.ssh/environment. */
> 	if (options.permit_user_env && !options.use_login) {
> 		snprintf(buf, sizeof buf, "%.200s/.ssh/environment",
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From opensshdev at r.paypc.com  Wed Aug  7 13:39:07 2013
From: opensshdev at r.paypc.com (Morham)
Date: Tue, 06 Aug 2013 20:39:07 -0700
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
Message-ID: <5201C15B.1060901@r.paypc.com>

I'd thought to bring up the Frankenbox platform side of things, always a good stress tester of wild and crazy compatibility issues.

A-OK!

all tests passed

Used http://www.mindrot.org/openssh_snap/openssh-SNAP-20130806.tar.gz

Northwood core Pentium 4, system started life as Slackware 9.1 i486 (no PAM, shadow/md5, pre-UNICODE)

Compiler: gcc-3.4.6 w/SSP patches
glibc: ancient (2.3.x)
Kernel: ancient (2.4.30-ish with OpenWall patches)
OpenSSL: 0.9.8y

(Don't ask.)

Configure line:

CC=gcc-3.4 CFLAGS='-O2 -s -mtune=pentium4 -march=pentium4' \
./configure --prefix=/usr --sysconfdir=/etc/ssh \
  --with-tcp-wrappers --with-privsep-user=sshd \
  --with-mantype=man --with-md5-passwords --with-ssl-dir=/usr \
  --with-ldflags='-s'

Configure results:

OpenSSH has been configured with the following options:
                     User binaries: /usr/bin
                   System binaries: /usr/sbin
               Configuration files: /etc/ssh
                   Askpass program: /usr/libexec/ssh-askpass
                      Manual pages: /usr/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: man
                       PAM support: no
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: no
                 Smartcard support: 
                     S/KEY support: no
              TCP Wrappers support: yes
              MD5 password support: yes
                   libedit support: no
  Solaris process contract support: no
           Solaris project support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY
             Privsep sandbox style: rlimit

              Host: i686-pc-linux-gnu
          Compiler: gcc-3.4
    Compiler flags: -O2 -s -mtune=pentium4 -march=pentium4 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fno-builtin-memset -fstack-protector-all -std=gnu99 
Preprocessor flags: -I/usr/include 
      Linker flags: -L/usr/lib  -fstack-protector-all -s
         Libraries: -lresolv -lcrypto -lrt -ldl -lutil -lz -lnsl  -lcrypt
         +for sshd:  -lwrap

Thanks for the hard work, guys.

=M=

From joe.carroll at sihti.fi  Wed Aug  7 16:16:25 2013
From: joe.carroll at sihti.fi (Joe Carroll)
Date: Wed, 7 Aug 2013 06:16:25 +0000
Subject: Documentation error: wrong permissions given in FAQ 
Message-ID: <CE27BF0D.12B84%joe.carroll@sihti.fi>

Hi,

I discovered yesterday that the instructions given at http://www.openssh.org/faq.html#3.14 regarding the correct permissions for the authorized_keys file mistakenly recommend chmod'ing the file to 600 when it should be 644. The requirement for public key authentication to work is in fact that ~/.ssh/authorized_keys is readable (but not writable) by group and other, not just owner. Someone should probably update the project's official FAQ accordingly to avoid future confusion. Unfortunately, I did not realise the error in this documentation before it caused me a great deal of frustration configuring chrooted key-only access to our server (Ubuntu 12.04 LTS).

Yst?v?llisin terveisin / Best regards,
Joe Carroll
IT-p??llikk? / IT Manager
joe at sihti.fi<mailto:joe at sihti.fi>
+358 50 444 4466
fi.linkedin.com/in/thejoecarroll<http://fi.linkedin.com/in/thejoecarroll>

Rekrytointipalvelu Sihti Oy
Tampellan esplanadi 2, 2. krs
33100 TAMPERE
www.sihti.fi<https://www.sihti.fi/>
p. 010 320 6500
Fax  010 320 6508

- Jos haluat osua, ota Sihti! -

From djm at mindrot.org  Wed Aug  7 18:55:40 2013
From: djm at mindrot.org (Damien Miller)
Date: Wed, 7 Aug 2013 18:55:40 +1000 (EST)
Subject: Documentation error: wrong permissions given in FAQ 
In-Reply-To: <CE27BF0D.12B84%joe.carroll@sihti.fi>
References: <CE27BF0D.12B84%joe.carroll@sihti.fi>
Message-ID: <alpine.BSO.2.03.1308071853450.25971@mindrot.org>

On Wed, 7 Aug 2013, Joe Carroll wrote:

> Hi,
>
> I discovered yesterday that the instructions given at
> http://www.openssh.org/faq.html#3.14 regarding the correct permissions
> for the authorized_keys file mistakenly recommend chmod'ing the
> file to 600 when it should be 644. The requirement for public key
> authentication to work is in fact that ~/.ssh/authorized_keys is
> readable (but not writable) by group and other, not just owner.
> Someone should probably update the project's official FAQ accordingly
> to avoid future confusion. Unfortunately, I did not realise the error
> in this documentation before it caused me a great deal of frustration
> configuring chrooted key-only access to our server (Ubuntu 12.04 LTS).

Mode 0600 works fine for authorized keys and, while ssh will still
accept this file with slightly looser permissions, it's best to keep
them as tight as possible unless there is a good reason otherwise.

-d

From joe.carroll at sihti.fi  Wed Aug  7 19:22:47 2013
From: joe.carroll at sihti.fi (Joe Carroll)
Date: Wed, 7 Aug 2013 09:22:47 +0000
Subject: Documentation error: wrong permissions given in FAQ 
In-Reply-To: <alpine.BSO.2.03.1308071853450.25971@mindrot.org>
Message-ID: <CE27E763.12BBB%joe.carroll@sihti.fi>

Hi,

I looked into this some more just now and realised my own error: the
reason 0644 worked for me but 0600 didn't was because the owner of the
file was root. I can confirm that 0600 works as you've said if the owner
is the same as the user (but this causes problems for multiple users
accessing the same SFTP jail). Despite this, Ubuntu's official wiki
recommends 0644: 
https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting

I need multiple chrooted users to use the same authorized_keys file so I
was able to get it working as desired by changing the group and using 0640
permissions, i.e. from

	-rw------- 1 root root 412 Aug 6 16:17
/var/chroot/home/.ssh/authorized_keys

to

	-rw-r----- 1 root jailedsftp 412 Aug 6 16:17
/var/chroot/home/.ssh/authorized_keys


Anyway, thanks for your response and sorry for bothering you with my
mistaken claims :-)

BR,
Joe


On 07/08/2013 11:55, "Damien Miller" <djm at mindrot.org> wrote:

>On Wed, 7 Aug 2013, Joe Carroll wrote:
>
>> Hi,
>>
>> I discovered yesterday that the instructions given at
>> http://www.openssh.org/faq.html#3.14 regarding the correct permissions
>> for the authorized_keys file mistakenly recommend chmod'ing the
>> file to 600 when it should be 644. The requirement for public key
>> authentication to work is in fact that ~/.ssh/authorized_keys is
>> readable (but not writable) by group and other, not just owner.
>> Someone should probably update the project's official FAQ accordingly
>> to avoid future confusion. Unfortunately, I did not realise the error
>> in this documentation before it caused me a great deal of frustration
>> configuring chrooted key-only access to our server (Ubuntu 12.04 LTS).
>
>Mode 0600 works fine for authorized keys and, while ssh will still
>accept this file with slightly looser permissions, it's best to keep
>them as tight as possible unless there is a good reason otherwise.
>
>-d
>



From des at des.no  Wed Aug  7 22:02:08 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 07 Aug 2013 14:02:08 +0200
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <alpine.BSO.2.03.1307251333420.29737@mindrot.org> (Damien
 Miller's message of "Thu, 25 Jul 2013 13:35:25 +1000 (EST)")
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
Message-ID: <86zjstyain.fsf@nine.des.no>

All tests pass on FreeBSD 9 and 10, configured with --with-pam
--with-tcp-wrappers --with-libedit --with-ssl-engine.

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

From des at des.no  Wed Aug  7 22:23:34 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 07 Aug 2013 14:23:34 +0200
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <86zjstyain.fsf@nine.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8r?=
 =?utf-8?Q?grav=22's?= message of
 "Wed, 07 Aug 2013 14:02:08 +0200")
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <86zjstyain.fsf@nine.des.no>
Message-ID: <86vc3hy9ix.fsf@nine.des.no>

Dag-Erling Sm?rgrav <des at des.no> writes:
> All tests pass on FreeBSD 9 and 10, configured with --with-pam
> --with-tcp-wrappers --with-libedit --with-ssl-engine.

All tests passed on FreeBSD 8 as well with same configure options
(20130805 in all three cases).

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

From nkadel at gmail.com  Wed Aug  7 23:14:33 2013
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 7 Aug 2013 09:14:33 -0400
Subject: Documentation error: wrong permissions given in FAQ
In-Reply-To: <CE27BF0D.12B84%joe.carroll@sihti.fi>
References: <CE27BF0D.12B84%joe.carroll@sihti.fi>
Message-ID: <C38A7477-88ED-4F2A-B6DD-CECF4CA580FF@gmail.com>

I'd frankly urge 0600 as a best practice. No one else needs casual read access to those public keys, especially when most such keys contain local usernames and hostnames in the "comments" segment.

Nico Kadel-Garcia
Email: nkadel at gmail.com
Sent from iPhone

On Aug 7, 2013, at 2:16, Joe Carroll <joe.carroll at sihti.fi> wrote:

> Hi,
> 
> I discovered yesterday that the instructions given at http://www.openssh.org/faq.html#3.14 regarding the correct permissions for the authorized_keys file mistakenly recommend chmod'ing the file to 600 when it should be 644. The requirement for public key authentication to work is in fact that ~/.ssh/authorized_keys is readable (but not writable) by group and other, not just owner. Someone should probably update the project's official FAQ accordingly to avoid future confusion. Unfortunately, I did not realise the error in this documentation before it caused me a great deal of frustration configuring chrooted key-only access to our server (Ubuntu 12.04 LTS).
> 
> Yst?v?llisin terveisin / Best regards,
> Joe Carroll
> IT-p??llikk? / IT Manager
> joe at sihti.fi<mailto:joe at sihti.fi>
> +358 50 444 4466
> fi.linkedin.com/in/thejoecarroll<http://fi.linkedin.com/in/thejoecarroll>
> 
> Rekrytointipalvelu Sihti Oy
> Tampellan esplanadi 2, 2. krs
> 33100 TAMPERE
> www.sihti.fi<https://www.sihti.fi/>
> p. 010 320 6500
> Fax  010 320 6508
> 
> - Jos haluat osua, ota Sihti! -
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From dtucker at zip.com.au  Thu Aug  8 11:53:18 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 8 Aug 2013 11:53:18 +1000
Subject: Call for testing: OpenSSH-6.3
In-Reply-To: <CAMv58rZJrowQ7QzZcVtUKBwZp7bNB577eMjdjLC_tOQxU4MEsA@mail.gmail.com>
References: <alpine.BSO.2.03.1307251333420.29737@mindrot.org>
 <D389E77E7E57DB46B85B0E8BE43836B0107B3522@G9W0747.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732AF9@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B45@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B55@G4W3292.americas.hpqcorp.net>
 <95F810D815A9AB449C311D797347145E51732B64@G4W3292.americas.hpqcorp.net>
 <CAMv58rbD4RpRLVNOydRcfeJFQsq0si5ckaTvEV=cS3kRSx1F5g@mail.gmail.com>
 <alpine.BSO.2.03.1308031757180.13530@mindrot.org>
 <20130803085113.GA25525@gate.dtucker.net>
 <alpine.BSO.2.03.1308041119250.13530@mindrot.org>
 <CAMv58rZJrowQ7QzZcVtUKBwZp7bNB577eMjdjLC_tOQxU4MEsA@mail.gmail.com>
Message-ID: <CALDDTe0S_U2qrQw2RES8d8AQq-7DJLEYbcbw7_VxNyeAx-MurA@mail.gmail.com>

On Tue, Aug 6, 2013 at 1:51 AM, Kevin Brott <kevin.brott at gmail.com> wrote:
> Applying patch to openssh-SNAP-20130806.tar.gz - and testing against oldest
> four hosts gives ...
[...]
> So it looks like that patch works fine for the hosts with the previous build
> issue - without breaking the ones that already worked.

Thanks!  I have  committed the patch and it will be in the release.

-- 
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 ronf at timeheart.net  Thu Aug  8 14:22:56 2013
From: ronf at timeheart.net (Ron Frederick)
Date: Wed, 7 Aug 2013 21:22:56 -0700
Subject: Issue with OpenSSH remote forwarding of dynamic ports
Message-ID: <9C0B2BEE-5997-4663-A70F-D21367643EB5@timeheart.net>

I recently ran across a problem with remote port forwarding in OpenSSH when trying to use dynamic ports. While it is possible to use OpenSSH to request a dynamic port and the OpenSSH sshd handles it just fine, the OpenSSH client gets confused when multiple ports are opened this way, due to the information passed in the "forwarded-tcpip" SSH_MSG_CHANNEL_OPEN message which is sent back to the client when connections are opened. To illustrate this problem, I tried the following with OpenSSH 6.2p1:

ssh -vvv -R 0:localhost:80 -R 0:localhost:81 localhost

In the debug output, I saw the lines:

debug1: remote forward success for: listen 0, connect localhost:80
Allocated port 60013 for remote forward to localhost:80
debug1: Updating allowed port 60013 for forwarding to host localhost port 80
debug1: remote forward success for: listen 0, connect localhost:81
Allocated port 60014 for remote forward to localhost:81
debug1: Updating allowed port 60014 for forwarding to host localhost port 81

So far, so good!

Connecting to port 60013 worked fine, causing the client to connect to localhost:80 as requested, with the following debug output:

quad:~>debug1: client_input_channel_open: ctype forwarded-tcpip rchan 5 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 0, originator ::1 port 60153
debug2: fd 9 setting O_NONBLOCK
debug1: connect_next: host localhost ([::1]:80) in progress, fd=9
debug2: fd 9 setting TCP_NODELAY
debug3: fd 9 is O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 1: new [::1]
debug1: confirm forwarded-tcpip
debug3: channel 1: waiting for connection
debug1: channel 1: connected to localhost port 80

However, connecting to port 60014 did not work as expected. In that case, I saw:

debug1: client_input_channel_open: ctype forwarded-tcpip rchan 5 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 0, originator ::1 port 60182
debug2: fd 9 setting O_NONBLOCK
debug1: connect_next: host localhost ([::1]:80) in progress, fd=9
debug2: fd 9 setting TCP_NODELAY
debug3: fd 9 is O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 1: new [::1]
debug1: confirm forwarded-tcpip
debug3: channel 1: waiting for connection
debug1: channel 1: connected to localhost port 80

Note that even though this was to the second listening port I set up, the connection was locally forwarded to port 80. The reason is that the SSH_MSG_CHANNEL_OPEN of type "forwarded-tcpip" from sshd reported the destination host & port as "localhost" port 0 for both the 60013 and 60014 connections, instead of reporting the actual listening port. The client seems to expect the 0 value here and does the right thing when you only have one dynamic listening port, but this breaks in the case where there are multiple, since there's nothing in the SSH_MSG_CHANNEL_OPEN which distinguishes between the two dynamic listeners. RFC 4254 is not completely clear on what is expected in the message. It says:

   When a connection comes to a port for which remote forwarding has
   been requested, a channel is opened to forward the port to the other
   side.

      byte      SSH_MSG_CHANNEL_OPEN
      string    "forwarded-tcpip"
      uint32    sender channel
      uint32    initial window size
      uint32    maximum packet size
      string    address that was connected
      uint32    port that was connected
      string    originator IP address
      uint32    originator port

I was expecting "port that was connected" in this message to be the dynamically allocated port so that it would always be a unique value, but this is not the case (at least with OpenSSH's sshd). Instead, it always seems to be the "port number to bind" value passed in the original SSH_MSG_GLOBAL_REQUEST "tcpip-forward" message (which is 0 since we're asking for a dynamic port).

Unfortunately, I would imagine changing this behavior on the server side might break existing clients out there which are expecting to get this 0 value back in channel open requests when they set up a dynamic listener, and I don't really see a good way to resolve this. Does anyone have any suggestions?
-- 
Ron Frederick
ronf at timeheart.net




From andrew at pimlott.net  Fri Aug  9 04:03:04 2013
From: andrew at pimlott.net (Andrew Pimlott)
Date: Thu, 08 Aug 2013 11:03:04 -0700
Subject: RemoteForward and dynamically allocated listen port
In-Reply-To: <9C327506-3890-4D0F-8CC6-73E6984E0438@gmail.com>
References: <1375723816-sup-4743@pimlott.net>
 <9C327506-3890-4D0F-8CC6-73E6984E0438@gmail.com>
Message-ID: <1375984386-sup-4417@pimlott.net>

Hi,

The port is still reported to the client.  I need it on the server.
Also, in my use case I want to forward the port immediately upon
connecting.  While this could be achieved with a few scripts, it is a
rather complicated bit of hacking for something that could be very
simple.

This is no different from SSH_AUTH_SOCK.

(For the use case of forwarding through the multiplexer, there's no
obvious way to report the port to the server, so reporting it to the
client only makes sense.)

Andrew

Excerpts from Markus Friedl's message of Tue Aug 06 14:13:31 -0700 2013:
> see http://www.openssh.com/txt/release-5.6
> 
>  * ssh(1) connection multiplexing now supports remote forwarding with
>    dynamic port allocation and can report the allocated port back to
>    the user:
> 
>      LPORT=`ssh -S muxsocket -R0:localhost:25 -O forward somehost`
> 
> 
> -m
> 
> Am 05.08.2013 um 21:04 schrieb Andrew Pimlott <andrew at pimlott.net>:
> 
> > Specifying a RemoteForward of 0:example.com:1234 dynamically allocates
> > the listen port on the server, and then reports it to ... the client!
> > Where it is practically useless.  Was this someone's idea of a joke?
> > 
> > Presumably not--there are some technical obstacles to reporting it to
> > the remote process.  I'd like to help solve that problem.
> > 
> > The natural way to me would be to extend the syntax of RemoteForward to
> > allow ENV_VAR:example.com:1234.  This would set $ENV_VAR to the
> > dynamically alocated port in the remote process.  However, the protocol
> > passes the listen port as a u_int.  A hack might be to pack the env var
> > name into the listen address and set the listen port to a special value
> > to indicate this, but I don't know if this is playing too fast and
> > loose.  A cleaner solution would be to add a new request type.  I
> > imagine that ssh protocol changes are made conservatively, so I don't
> > know how viable these options are.
> > 
> > Without changing the protocol, we could at least set an environment
> > variable for each dynamically allocated port, numbered by the order of
> > the RemoteForward requests, eg. SSH_REMOTE_FORWARD_PORT_1,
> > SSH_REMOTE_FORWARD_PORT_2, ....  I was able to wedge a proof of concept
> > into session.c:do_setup_env (patch below).  It's a hack because there
> > doesn't seem to be an API to iterate channels outside of channels.c.
> > Would it be agreeable to export channels and channels_alloc?  Also,
> > struct Channel doesn't let you tell which forwards were dynamically
> > allocated, so an environment variable is set for all RemoteForwards.
> > This could be changed by extending struct Channel, though it isn't a
> > show-stopper for me.
> > 
> > Last thought: if a new protocol request type were added, it should make
> > it easy to add support for forwarding unix sockets, which I have missed
> > for a long time.
> > 
> > Would any of these approaches be acceptable?  Any other ideas?
> > 
> > Thanks,
> > Andrew
> > 
> > --- session.c.orig    2013-08-03 13:22:10.354171156 -0700
> > +++ session.c    2013-08-05 09:58:00.017397667 -0700
> > @@ -1307,6 +1307,17 @@
> >         child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME,
> >             auth_sock_name);
> > 
> > +    char name[256];
> > +    u_int n = 0;
> > +    for (i = 0; i < 100; i++) {
> > +        Channel *c = channel_by_id(i);
> > +        if (c == NULL || c->type != SSH_CHANNEL_RPORT_LISTENER)
> > +            continue;
> > +        snprintf(name, sizeof name, "SSH_REMOTE_FORWARD_PORT_%d", n);
> > +        snprintf(buf, sizeof buf, "%d", c->listening_port);
> > +        child_set_env(&env, &envsize, name, buf);
> > +    }
> > +
> >     /* read $HOME/.ssh/environment. */
> >     if (options.permit_user_env && !options.use_login) {
> >         snprintf(buf, sizeof buf, "%.200s/.ssh/environment",
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From andrew at pimlott.net  Fri Aug  9 04:07:44 2013
From: andrew at pimlott.net (Andrew Pimlott)
Date: Thu, 08 Aug 2013 11:07:44 -0700
Subject: RemoteForward and dynamically allocated listen port
In-Reply-To: <74254AB9-2F06-40C5-87F4-E3B7D4FB0908@alex.org.uk>
References: <1375723816-sup-4743@pimlott.net>
 <74254AB9-2F06-40C5-87F4-E3B7D4FB0908@alex.org.uk>
Message-ID: <1375985048-sup-5736@pimlott.net>

Excerpts from Alex Bligh's message of Tue Aug 06 07:29:41 -0700 2013:
> One problem with your approach is that the child may already be running
> by the time the remote forward is processed; that could be ten minutes
> after the session start.

It's a limitation, not a problem. :-)  The code I ran in my example runs
in do_setup_env, which only happens on initial connection.  If the
forward is requested later through the multiplexer, this code doesn't
run and you have to find some other way.  There is really no natural
solution for that case.

Andrew

From plautrba at redhat.com  Mon Aug 12 18:27:09 2013
From: plautrba at redhat.com (Petr Lautrbach)
Date: Mon, 12 Aug 2013 10:27:09 +0200
Subject: add more ControlPath recommendations to ssh_config.5
Message-ID: <52089C5D.1080605@redhat.com>

Hello,

Right now, there is a recommendation about using special strings in ControlPatch in ssh_config.5,
but there's no specification of recommended directory. So users use random paths like
/home/misc/tmp/%r@%h:%p. Would it be worth to suggest the ~/.ssh/ directory for ControlPath
and to mention that used directory should not be publicly accessible?

It would help to better specify the SElinux policy based on these suggestions [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=987554

Thanks,


Petr

From ignathe at gmail.com  Tue Aug 13 02:48:33 2013
From: ignathe at gmail.com (Ignat Harczuk)
Date: Mon, 12 Aug 2013 16:48:33 +0000
Subject: subsribe
Message-ID: <CAC_oS=8k9qiA-GOzdAOT8p=cA86ixz7hOQ_WjtnhoxQK+rShQQ@mail.gmail.com>

i would like to subsrice to this mailing list!

ignathe at gmail.com

thank you

From marlon.davis at oracle.com  Tue Aug 13 03:30:05 2013
From: marlon.davis at oracle.com (Marlon Davis)
Date: Mon, 12 Aug 2013 12:30:05 -0500
Subject: openssh 6.2
Message-ID: <3C9405CB-A0F6-4851-8F0F-53B5815F323E@oracle.com>

To the openssh community;

I have installed openssh 6.2 on my mac book pro and tried to ssh to a server and the ssh session hangs. The host
server shows that a connection was established but I cannot return a prompt to indicate that I am connected
to the server. Can someone advise?

Thanks in advance

======>HOST SERVER
[ALLOC133 /export/home/tinker] netstat -a |grep msp9022.XX.XXX.COM.ssh
msp9022.XX.XXX.COM.ssh dhcp-uk-vpn-adc-anyconnect-10-154-141-30.XX.XXX.COM.49808 131024      0
128544      0 ESTABLISHED
[ALLOC133 /export/home/tinker] netstat -a |grep msp9022.XX.XXX.COM.ssh
msp9022.XX.XXX.COM.ssh dhcp-uk-vpn-adc-anyconnect-10-154-141-30.XX.XXX.COM.49808 131024      0
128544      0 ESTABLISHED
[ALLOC133 /export/home/tinker] 

=======> CLIENT MACHINE

bash-3.2$ ssh -v
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-W host:port] [-w local_tun[:remote_tun]]
           [user <at> ]hostname [command]

bash-3.2$ ssh -l tinker -vvv  msp9022
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to msp9022 [10.141.10.31] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/sherlock holmes/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/sherlock holmes/.ssh/id_rsa type 1
debug1: identity file /Users/sherlock holmes/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/sherlock holmes/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/sherlock holmes/.ssh/id_dsa type 2
debug1: identity file /Users/sherlock holmes/.ssh/id_dsa-cert type -1
debug1: identity file /Users/sherlock holmes/.ssh/id_ecdsa type -1
debug1: identity file /Users/sherlock holmes/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_2.0
debug1: no match: Sun_SSH_2.0
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "msp9022" from file "/Users/sherlock holmes/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/sherlock holmes/.ssh/known_hosts:52
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at ...,ssh-rsa-cert-v00 at ...,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at ...,ssh-rsa-cert-v00 at ...,ssh-rsa,ecdsa-sha2-nistp256-cert-v01 at ...,ecdsa-sha2-nistp384-cert-v01 at ...,ecdsa-sha2-nistp521-cert-v01 at ...,ssh-dss-cert-v01 at ...,ssh-dss-cert-v00 at ...,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm <at> openssh.com,aes256-gcm at ...,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at ...
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm <at> openssh.com,aes256-gcm at ...,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at ...
debug2: kex_parse_kexinit: hmac-md5-etm at ...,hmac-sha1-etm at ...,umac-64-etm at ...,umac-128-etm at ...,hmac-sha2-256-etm at ...,hmac-sha2-512-etm <at> openssh.com,hmac-ripemd160-etm at ...,hmac-sha1-96-etm at ...,hmac-md5-96-etm at ...,hmac-md5,hmac-sha1,umac-64 at ...,umac-128 <at> openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 <at> openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm at ...,hmac-sha1-etm at ...,umac-64-etm at ...,umac-128-etm at ...,hmac-sha2-256-etm at ...,hmac-sha2-512-etm <at> openssh.com,hmac-ripemd160-etm at ...,hmac-sha1-96-etm at ...,hmac-md5-96-etm at ...,hmac-md5,hmac-sha1,umac-64 at ...,umac-128 <at> openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 <at> openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at ...,zlib
debug2: kex_parse_kexinit: none,zlib at ...,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: af-ZA,ar-AE,ar-BH,ar-DZ,ar-EG,ar-IQ,ar-JO,ar-KW,ar-LY,ar-MA,ar-OM,ar-QA,ar-SA,ar-TN,ar-YE,as-IN,az-AZ,be-BY,bg-BG,bn-IN,bs-BA,ca-ES,cs-CZ,da-DK,de-AT,de-BE,de-CH,de-DE,de-LI,de-LU,el-CY,el-GR,en-AU,en-BW,en-CA,en-GB,en-HK,en-IE,en-IN,en-MT,en-NZ,en-PH,en-SG,en-US,en-ZW,es-AR,es-BO,es-CL,es-CO,es-CR,es-DO,es-EC,es-ES,es-GT,es-HN,es-MX,es-NI,es-PA,es-PE,es-PR,es-PY,es-SV,es-US,es-UY,es-VE,et-EE,fi-FI,fr-BE,fr-CA,fr-CH,fr-FR,fr-LU,gu-IN,he-IL,hi-IN,hr-HR,hu-HU,hy-AM,id-ID,is-IS,it-CH,it-IT,ja-JP,ka-GE,kk-KZ,kn-IN,ko-KR,ks-IN,ku-TR,ky-KG,lt-LT,lv-LV,mk-MK,ml-IN,mr-IN,ms-MY,mt-MT,nb-NO,nl-BE,nl-NL,nn-NO,or-IN,pa-IN,pl-PL,pt-BR,pt-PT,ro-RO,ru-RU,ru-UA,sa-IN,sk-SK,sl-SI,sq-AL,sr-ME,sr-RS,sv-SE,ta-IN,te-IN,th-TH,tr-TR,uk-UA,vi-VN,zh-CN,zh-HK,zh-SG,zh-TW,i-default
debug2: kex_parse_kexinit: af-ZA,ar-AE,ar-BH,ar-DZ,ar-EG,ar-IQ,ar-JO,ar-KW,ar-LY,ar-MA,ar-OM,ar-QA,ar-SA,ar-TN,ar-YE,as-IN,az-AZ,be-BY,bg-BG,bn-IN,bs-BA,ca-ES,cs-CZ,da-DK,de-AT,de-BE,de-CH,de-DE,de-LI,de-LU,el-CY,el-GR,en-AU,en-BW,en-CA,en-GB,en-HK,en-IE,en-IN,en-MT,en-NZ,en-PH,en-SG,en-US,en-ZW,es-AR,es-BO,es-CL,es-CO,es-CR,es-DO,es-EC,es-ES,es-GT,es-HN,es-MX,es-NI,es-PA,es-PE,es-PR,es-PY,es-SV,es-US,es-UY,es-VE,et-EE,fi-FI,fr-BE,fr-CA,fr-CH,fr-FR,fr-LU,gu-IN,he-IL,hi-IN,hr-HR,hu-HU,hy-AM,id-ID,is-IS,it-CH,it-IT,ja-JP,ka-GE,kk-KZ,kn-IN,ko-KR,ks-IN,ku-TR,ky-KG,lt-LT,lv-LV,mk-MK,ml-IN,mr-IN,ms-MY,mt-MT,nb-NO,nl-BE,nl-NL,nn-NO,or-IN,pa-IN,pl-PL,pt-BR,pt-PT,ro-RO,ru-RU,ru-UA,sa-IN,sk-SK,sl-SI,sq-AL,sr-ME,sr-RS,sv-SE,ta-IN,te-IN,th-TH,tr-TR,uk-UA,vi-VN,zh-CN,zh-HK,zh-SG,zh-TW,i-default
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 146/256
debug2: bits set: 488/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 18:8f:32:19:1f:c3:1d:ee:8c:61:c8:11:a0:59:77:5f
debug3: load_hostkeys: loading entries for host "msp9022" from file "/Users/sherlock holmes/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/sherlock holmes/.ssh/known_hosts:52
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "10.141.10.31" from file "/Users/sherlock holmes/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/sherlock holmes/.ssh/known_hosts:52
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'msp9022' is known and matches the RSA host key.
debug1: Found key in /Users/sherlock holmes/.ssh/known_hosts:52
debug2: bits set: 517/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received

======> hangs here until I control C==================


Cheers
Marlon Anthony Davis | Performance Engineering
Phone: 612.587.5025 | Mobile: 678.428.7704
Oracle 
900 Second Avenue South, Suite 10063 | Minneapolis, Minnesota 55402





From djm at mindrot.org  Wed Aug 14 11:00:47 2013
From: djm at mindrot.org (Damien Miller)
Date: Wed, 14 Aug 2013 11:00:47 +1000 (EST)
Subject: openssh 6.2
In-Reply-To: <3C9405CB-A0F6-4851-8F0F-53B5815F323E@oracle.com>
References: <3C9405CB-A0F6-4851-8F0F-53B5815F323E@oracle.com>
Message-ID: <alpine.BSO.2.03.1308141051270.14915@mindrot.org>


On Mon, 12 Aug 2013, Marlon Davis wrote:

> To the openssh community;
>
> I have installed openssh 6.2 on my mac book pro and tried to ssh to
> a server and the ssh session hangs. The host server shows that a
> connection was established but I cannot return a prompt to indicate
> that I am connected to the server. Can someone advise?

We can't really tell without seeing the server logs, though the server
(being "Sun_SSH_2.0") is not one we're so familiar with debugging.

If I had to guess based on where it was failing: the server is hanging
on getpwnam because of a broken nsswitch configuration. Right after
"debug1: SSH2_MSG_SERVICE_ACCEPT received" the client sends the first
user auth request, which will trigger the server to initialise its auth
code. One of the first things the server does here is look up the
username.

-d

From plautrba at redhat.com  Wed Aug 14 19:23:58 2013
From: plautrba at redhat.com (Petr Lautrbach)
Date: Wed, 14 Aug 2013 11:23:58 +0200
Subject: ssh.c - allocated wrong size for sensitive_data.keys?
Message-ID: <520B4CAE.6010008@redhat.com>

Hello,

There's a memory allocation for sensitive_data.keys in ssh.c:848 which uses size of Key instead of Key*.
This is probably harmless but seems to be wrong.

--- a/ssh.c
+++ b/ssh.c
@@ -846,7 +846,7 @@ main(int ac, char **av)
             options.hostbased_authentication) {
                 sensitive_data.nkeys = 7;
                 sensitive_data.keys = xcalloc(sensitive_data.nkeys,
-                   sizeof(Key));
+                   sizeof(Key *));
                 for (i = 0; i < sensitive_data.nkeys; i++)
                         sensitive_data.keys[i] = NULL;



Petr

From rapier at psc.edu  Thu Aug 15 07:36:31 2013
From: rapier at psc.edu (rapier)
Date: Wed, 14 Aug 2013 17:36:31 -0400
Subject: HPN-SSH for OpenSSH 6.2
Message-ID: <520BF85F.5060506@psc.edu>

Howdy,

It's been a while since I've made an announcement here but I wanted to 
mention that we've just released a set of HPN-SSH patches for 
OpenSSH6.2. The release marks the first time I've had the resources/help 
to actually do anything more than just forward port the patches in quite 
a while.

http://www.psc.edu/index.php/hpn-ssh

Items of note:

1) The multithreaded AES-CTR (MT-AES-CTR) cipher now works as expected 
in all situations. Previously MT-AES-CTR failed in dynamic forwarding 
tests because context with the threads were lost when daemon() was 
called. Starting with 6.1 it also failed on the server side with the 
introduction of sandboxing by default. Under the rlimit method NPROCS 
being set to zero precluded the possibility of threads being started in 
in privsep. This issue has been resolved by swapping the pointer for the 
AES CTR cipher from the nonthreaded AES-CTR cipher to MT-AES-CTR after 
authentication and then forcing a rekey. Throughput improvements of more 
than 50% were seen on test systems. MT-AES-CTR is cipherstream 
compatible with the default implementation.

2) In order to reduce the complexity of the patch sets I've finally 
stripped the postauth NONE cipher switching from the patchsets. It's now 
a standalone patch.

Thanks for your time!

Chris Rapier

From keisial at gmail.com  Fri Aug 16 10:09:45 2013
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 16 Aug 2013 02:09:45 +0200
Subject: ssh.c - allocated wrong size for sensitive_data.keys?
In-Reply-To: <520B4CAE.6010008@redhat.com>
References: <520B4CAE.6010008@redhat.com>
Message-ID: <520D6DC9.7070209@gmail.com>

On 14/08/13 11:23, Petr Lautrbach wrote:
> Hello,
>
> There's a memory allocation for sensitive_data.keys in ssh.c:848 which 
> uses size of Key instead of Key*.
> This is probably harmless but seems to be wrong.
>
> --- a/ssh.c
> +++ b/ssh.c
> @@ -846,7 +846,7 @@ main(int ac, char **av)
>             options.hostbased_authentication) {
>                 sensitive_data.nkeys = 7;
>                 sensitive_data.keys = xcalloc(sensitive_data.nkeys,
> -                   sizeof(Key));
> +                   sizeof(Key *));
>                 for (i = 0; i < sensitive_data.nkeys; i++)
>                         sensitive_data.keys[i] = NULL;
>
>
> Petr
I agree with you. Moreover, why is the loop below? The calloc should 
take care of it.
And if we are on one of those weird machines where NULL is not 
represented by zero bytes (are there still
boxes like this out there?), when the xcalloc can be a 
xmalloc(sensitive_data.nkeys * sizeof(Key*));

And if this wasn't enough, the next lines set them again* Those 7 slots 
are written thrice between line 819 and 842.
(plus a fourth time on 850-865, but that's conditional to the previous 
result)


* Ok... it would need a couple of #else for the case where 
OPENSSL_HAS_ECC is not defined.

From keisial at gmail.com  Fri Aug 16 10:14:52 2013
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 16 Aug 2013 02:14:52 +0200
Subject: Issue with OpenSSH remote forwarding of dynamic ports
In-Reply-To: <9C0B2BEE-5997-4663-A70F-D21367643EB5@timeheart.net>
References: <9C0B2BEE-5997-4663-A70F-D21367643EB5@timeheart.net>
Message-ID: <520D6EFC.1070301@gmail.com>

On 08/08/13 06:22, Ron Frederick wrote:
>     When a connection comes to a port for which remote forwarding has
>     been requested, a channel is opened to forward the port to the other
>     side.
>
>        byte      SSH_MSG_CHANNEL_OPEN
>        string    "forwarded-tcpip"
>        uint32    sender channel
>        uint32    initial window size
>        uint32    maximum packet size
>        string    address that was connected
>        uint32    port that was connected
>        string    originator IP address
>        uint32    originator port
>
> I was expecting "port that was connected" in this message to be the dynamically allocated port so that it would always be a unique value, but this is not the case (at least with OpenSSH's sshd). Instead, it always seems to be the "port number to bind" value passed in the original SSH_MSG_GLOBAL_REQUEST "tcpip-forward" message (which is 0 since we're asking for a dynamic port).
>
> Unfortunately, I would imagine changing this behavior on the server side might break existing clients out there which are expecting to get this 0 value back in channel open requests when they set up a dynamic listener, and I don't really see a good way to resolve this. Does anyone have any suggestions?
It could pass 0 for the first forward and the real port in the next ones 
(which are already open), but IMHO the right thing would be to always 
provide the real port.


From andrew at pimlott.net  Sat Aug 17 03:23:06 2013
From: andrew at pimlott.net (Andrew Pimlott)
Date: Fri, 16 Aug 2013 10:23:06 -0700
Subject: RemoteForward and dynamically allocated listen port
In-Reply-To: <1375984386-sup-4417@pimlott.net>
References: <1375723816-sup-4743@pimlott.net>
 <9C327506-3890-4D0F-8CC6-73E6984E0438@gmail.com>
 <1375984386-sup-4417@pimlott.net>
Message-ID: <1376673107-sup-5940@pimlott.net>

Markus et al,

Do you have any interest in my approach to this problem?  As I said, the
use case is really no different from SSH_AUTH_SOCK.  I want the port
allocated on initial connection, and I want it reported via an
environment variable on the server.  This seems like a reasonable
feature to me, and I would have many uses for it.

I am happy to work further on the implementation.  I could either extend
the protocol to let the user specify the environment variable name, or
refine the workable hack of setting SSH_REMOTE_FORWARD_PORT_NNN, where
NNN is incremented for each dynamically allocated port.

I will do whatever is most likely to get merged.

Andrew

Excerpts from Andrew Pimlott's message of Thu Aug 08 11:03:04 -0700 2013:
> Hi,
> 
> The port is still reported to the client.  I need it on the server.
> Also, in my use case I want to forward the port immediately upon
> connecting.  While this could be achieved with a few scripts, it is a
> rather complicated bit of hacking for something that could be very
> simple.
> 
> This is no different from SSH_AUTH_SOCK.
> 
> (For the use case of forwarding through the multiplexer, there's no
> obvious way to report the port to the server, so reporting it to the
> client only makes sense.)
> 
> Andrew
> 
> Excerpts from Markus Friedl's message of Tue Aug 06 14:13:31 -0700 2013:
> > see http://www.openssh.com/txt/release-5.6
> > 
> >  * ssh(1) connection multiplexing now supports remote forwarding with
> >    dynamic port allocation and can report the allocated port back to
> >    the user:
> > 
> >      LPORT=`ssh -S muxsocket -R0:localhost:25 -O forward somehost`
> > 
> > 
> > -m
> > 
> > Am 05.08.2013 um 21:04 schrieb Andrew Pimlott <andrew at pimlott.net>:
> > 
> > > Specifying a RemoteForward of 0:example.com:1234 dynamically allocates
> > > the listen port on the server, and then reports it to ... the client!
> > > Where it is practically useless.  Was this someone's idea of a joke?
> > > 
> > > Presumably not--there are some technical obstacles to reporting it to
> > > the remote process.  I'd like to help solve that problem.
> > > 
> > > The natural way to me would be to extend the syntax of RemoteForward to
> > > allow ENV_VAR:example.com:1234.  This would set $ENV_VAR to the
> > > dynamically alocated port in the remote process.  However, the protocol
> > > passes the listen port as a u_int.  A hack might be to pack the env var
> > > name into the listen address and set the listen port to a special value
> > > to indicate this, but I don't know if this is playing too fast and
> > > loose.  A cleaner solution would be to add a new request type.  I
> > > imagine that ssh protocol changes are made conservatively, so I don't
> > > know how viable these options are.
> > > 
> > > Without changing the protocol, we could at least set an environment
> > > variable for each dynamically allocated port, numbered by the order of
> > > the RemoteForward requests, eg. SSH_REMOTE_FORWARD_PORT_1,
> > > SSH_REMOTE_FORWARD_PORT_2, ....  I was able to wedge a proof of concept
> > > into session.c:do_setup_env (patch below).  It's a hack because there
> > > doesn't seem to be an API to iterate channels outside of channels.c.
> > > Would it be agreeable to export channels and channels_alloc?  Also,
> > > struct Channel doesn't let you tell which forwards were dynamically
> > > allocated, so an environment variable is set for all RemoteForwards.
> > > This could be changed by extending struct Channel, though it isn't a
> > > show-stopper for me.
> > > 
> > > Last thought: if a new protocol request type were added, it should make
> > > it easy to add support for forwarding unix sockets, which I have missed
> > > for a long time.
> > > 
> > > Would any of these approaches be acceptable?  Any other ideas?
> > > 
> > > Thanks,
> > > Andrew
> > > 
> > > --- session.c.orig    2013-08-03 13:22:10.354171156 -0700
> > > +++ session.c    2013-08-05 09:58:00.017397667 -0700
> > > @@ -1307,6 +1307,17 @@
> > >         child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME,
> > >             auth_sock_name);
> > > 
> > > +    char name[256];
> > > +    u_int n = 0;
> > > +    for (i = 0; i < 100; i++) {
> > > +        Channel *c = channel_by_id(i);
> > > +        if (c == NULL || c->type != SSH_CHANNEL_RPORT_LISTENER)
> > > +            continue;
> > > +        snprintf(name, sizeof name, "SSH_REMOTE_FORWARD_PORT_%d", n);
> > > +        snprintf(buf, sizeof buf, "%d", c->listening_port);
> > > +        child_set_env(&env, &envsize, name, buf);
> > > +    }
> > > +
> > >     /* read $HOME/.ssh/environment. */
> > >     if (options.permit_user_env && !options.use_login) {
> > >         snprintf(buf, sizeof buf, "%.200s/.ssh/environment",
> > > _______________________________________________
> > > openssh-unix-dev mailing list
> > > openssh-unix-dev at mindrot.org
> > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From ronf at timeheart.net  Sun Aug 18 02:35:10 2013
From: ronf at timeheart.net (Ron Frederick)
Date: Sat, 17 Aug 2013 09:35:10 -0700
Subject: Issue with OpenSSH remote forwarding of dynamic ports
In-Reply-To: <520D6EFC.1070301@gmail.com>
References: <9C0B2BEE-5997-4663-A70F-D21367643EB5@timeheart.net>
 <520D6EFC.1070301@gmail.com>
Message-ID: <BF4BCA3A-E965-4BCA-9B37-75933D35D7BD@timeheart.net>

On Aug 15, 2013, at 5:14 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
> 
> On 08/08/13 06:22, Ron Frederick wrote:
>>    When a connection comes to a port for which remote forwarding has
>>    been requested, a channel is opened to forward the port to the other
>>    side.
>> 
>>       byte      SSH_MSG_CHANNEL_OPEN
>>       string    "forwarded-tcpip"
>>       uint32    sender channel
>>       uint32    initial window size
>>       uint32    maximum packet size
>>       string    address that was connected
>>       uint32    port that was connected
>>       string    originator IP address
>>       uint32    originator port
>> 
>> I was expecting "port that was connected" in this message to be the dynamically allocated port so that it would always be a unique value, but this is not the case (at least with OpenSSH's sshd). Instead, it always seems to be the "port number to bind" value passed in the original SSH_MSG_GLOBAL_REQUEST "tcpip-forward" message (which is 0 since we're asking for a dynamic port).
>> 
>> Unfortunately, I would imagine changing this behavior on the server side might break existing clients out there which are expecting to get this 0 value back in channel open requests when they set up a dynamic listener, and I don't really see a good way to resolve this. Does anyone have any suggestions?
> 
> It could pass 0 for the first forward and the real port in the next ones (which are already open), but IMHO the right thing would be to always provide the real port.

I did an experiment today and was pleasantly surprised to find that the OpenSSH client does work correctly when the real port number is returned by the server. The "address that was connected" can also be a real address. So, for instance, a request could be made with a bind address of "localhost" and the address reported back could be "127.0.0.1" for IPv4 or "::1" for IPv6. Here's some debug output of it working:

debug1: remote forward success for: listen 0, connect localhost:80
Allocated port 12345 for remote forward to localhost:80
debug1: Updating allowed port 12345 for forwarding to host localhost port 80
...
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 1 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen 127.0.0.1 port 12345, originator 127.0.0.1 port 56789
debug1: connect_next: host localhost ([::1]:80) in progress, fd=9
debug1: channel 1: new [1.2.3.4]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to localhost port 80

I also tried having the server respond with a port number which didn't match the random port returned in the channel open response, and the client properly rejected that. In the debug output, I saw:

WARNING: Server requests forwarding for unknown listen_port 12346
debug1: failure forwarded-tcpip

So, it looks like it wouldn't cause a problem for OpenSSH clients if the OpenSSH server always returned the correct port number in the "tcpip-forward" response when requests were made to bind to port 0. The change looks fairly straightforward to do this. Here's a proposed patch against version 6.2p2:

--- channels.c.orig	2012-12-02 14:50:55.000000000 -0800
+++ channels.c	2013-08-17 09:18:41.000000000 -0700
@@ -1384,6 +1384,8 @@
 {
 	int direct;
 	char buf[1024];
+	char *local_ipaddr = get_local_ipaddr(c->sock);
+	int local_port = get_sock_port(c->sock, 1);
 	char *remote_ipaddr = get_peer_ipaddr(c->sock);
 	int remote_port = get_peer_port(c->sock);
 
@@ -1398,9 +1400,9 @@
 
 	snprintf(buf, sizeof buf,
 	    "%s: listening port %d for %.100s port %d, "
-	    "connect from %.200s port %d",
+	    "connect from %.200s port %d to %.100s port %d",
 	    rtype, c->listening_port, c->path, c->host_port,
-	    remote_ipaddr, remote_port);
+	    remote_ipaddr, remote_port, local_ipaddr, local_port);
 
 	xfree(c->remote_name);
 	c->remote_name = xstrdup(buf);
@@ -1416,9 +1418,9 @@
 			packet_put_cstring(c->path);
 			packet_put_int(c->host_port);
 		} else {
-			/* listen address, port */
-			packet_put_cstring(c->path);
-			packet_put_int(c->listening_port);
+			/* connected address, port */
+			packet_put_cstring(local_ipaddr);
+			packet_put_int(local_port);
 		}
 		/* originator host and port */
 		packet_put_cstring(remote_ipaddr);
@@ -1435,6 +1437,7 @@
 		packet_send();
 	}
 	xfree(remote_ipaddr);
+	xfree(local_ipaddr);
 }
 
 static void

One minor ugliness here is that I had to use "get_sock_port()" instead of get_local_port(), as get_local_port() doesn't take a socket as an argument the way get_local_ipaddr() does and there's no equivalent function under another name. Cleaning this up would impact other files, though, and I wanted to keep the diff as clean as possible for now.
-- 
Ron Frederick
ronf at timeheart.net




From john at keeping.me.uk  Mon Aug 19 03:07:08 2013
From: john at keeping.me.uk (John Keeping)
Date: Sun, 18 Aug 2013 18:07:08 +0100
Subject: Extracting client certificate information
Message-ID: <20130818170707.GS2337@serenity.lan>

When using client certificate authentication, is there any way to
extract the key ID from the certificate in a force command on the
server?

I would like to be able to configure Gitolite [1] with a certificate
authority key and then use the key ID as the Gitolite user ID when a
client connects.  Currently I can achieve the same effect by embedding
the username in a "force-command" certificate extension, but it seems
like it would be simpler if I could just configure the command once on
the server and use the key ID in it.

Am I missing some way of doing this, or is that a feature that you would
consider supporting?

[1] http://gitolite.com/gitolite/

From djm at mindrot.org  Tue Aug 20 08:47:23 2013
From: djm at mindrot.org (Damien Miller)
Date: Tue, 20 Aug 2013 08:47:23 +1000 (EST)
Subject: Extracting client certificate information
In-Reply-To: <20130818170707.GS2337@serenity.lan>
References: <20130818170707.GS2337@serenity.lan>
Message-ID: <alpine.BSO.2.03.1308200840030.576@mindrot.org>

On Sun, 18 Aug 2013, John Keeping wrote:

> When using client certificate authentication, is there any way to
> extract the key ID from the certificate in a force command on the
> server?
> 
> I would like to be able to configure Gitolite [1] with a certificate
> authority key and then use the key ID as the Gitolite user ID when a
> client connects.  Currently I can achieve the same effect by embedding
> the username in a "force-command" certificate extension, but it seems
> like it would be simpler if I could just configure the command once on
> the server and use the key ID in it.
> 
> Am I missing some way of doing this, or is that a feature that you would
> consider supporting?

Not at present. I had plans to implement a SSH_AUTH_KEY (patches even!)
that would expose the key used for authentication to the sessions started
after it but they were derailed by the multiple-authentication support
we added recently. The problem is that there now might be more than one
key used for authentication so I have to redesign them to support these
cases.

The intent is that you could do something like:

echo $SSH_AUTH_KEY | ssh-keygen -Lf - | grep ^"Key ID:"

but obviously that doesn't work right now.

Doing post-authentication authorisation like this can be risky though: you
have to ensure that users cannot set the SSH_AUTH_KEY environment variable
themselves otherwise they could impersonate anyone :/

If you are interested in this then there is a bug open for it, but I can't
find it right now - it must have had a confusing title. The only slightly-
tricky part in implementing it is to ensure that the the key used for authn
gets recorded in the privsep monitor rather than just the child process.

-d

From djm at mindrot.org  Wed Aug 21 02:49:29 2013
From: djm at mindrot.org (Damien Miller)
Date: Wed, 21 Aug 2013 02:49:29 +1000 (EST)
Subject: ProxyCommand that returns a socket
In-Reply-To: <CADd11yUUogLpCVuYsbBOR2xEBHqzsday3zdknLQMRrdoUbw4QQ@mail.gmail.com>
References: <CADd11yX592qj4KseRKr=UrMmEw3YpUZX+hdLEZ4RBSDXTADF=A@mail.gmail.com>
 <alpine.BSO.2.03.1306210927380.2953@mindrot.org>
 <CADd11yUUogLpCVuYsbBOR2xEBHqzsday3zdknLQMRrdoUbw4QQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1308210226480.576@mindrot.org>

... and it's committed - it will be in snapshots dated 20130821 and later,
and will be released in openssh-6.4 later this year.

-d

On Fri, 21 Jun 2013, Igor Bukanov wrote:

> Thanks, I think this is exactly what I was looking for!
> 
> On 21 June 2013 02:01, Damien Miller <djm at mindrot.org> wrote:
> > On Thu, 20 Jun 2013, Igor Bukanov wrote:
> >
> >> Hello,
> >>
> >> My usage of ProxyCommand just calls the nc utility with various
> >> parameters. That in turn after the initial setup just copies copies
> >> the data from the network socket to stdin/stdout. This useless coping
> >> can be avoided if ssh has an option to receive the socket from the
> >> proxy command. I suppose it can improve network error reporting as ssh
> >> would talk directly to the network socket rather than a proxy, right?
> >
> > I have a patch that adds a ProxyUseFdpass that might do what you want.
> >
> > When ProxyUseFdpass=yes, the ProxyCommand is expected to pass back a
> > connected socket and exit. ssh will then use this socket directly.
> >
> > This is somewhat more optional for cases where the proxy is only
> > needed at the beginning of the connection.
> >
> > Index: readconf.c
> > ===================================================================
> > RCS file: /var/cvs/openssh/readconf.c,v
> > retrieving revision 1.184
> > diff -u -p -r1.184 readconf.c
> > --- readconf.c  5 Jun 2013 22:22:47 -0000       1.184
> > +++ readconf.c  21 Jun 2013 00:00:29 -0000
> > @@ -137,7 +137,7 @@ typedef enum {
> >         oHashKnownHosts,
> >         oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
> >         oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication,
> > -       oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown,
> > +       oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, oProxyUseFdpass,
> >         oIgnoredUnknownOption, oDeprecated, oUnsupported
> >  } OpCodes;
> >
> > @@ -249,6 +249,7 @@ static struct {
> >         { "kexalgorithms", oKexAlgorithms },
> >         { "ipqos", oIPQoS },
> >         { "requesttty", oRequestTTY },
> > +       { "proxyusefdpass", oProxyUseFdpass },
> >         { "ignoreunknown", oIgnoreUnknown },
> >
> >         { NULL, oBadOption }
> > @@ -1074,6 +1075,10 @@ parse_int:
> >                 charptr = &options->ignored_unknown;
> >                 goto parse_string;
> >
> > +       case oProxyUseFdpass:
> > +               intptr = &options->proxy_use_fdpass;
> > +               goto parse_flag;
> > +
> >         case oDeprecated:
> >                 debug("%s line %d: Deprecated option \"%s\"",
> >                     filename, linenum, keyword);
> > @@ -1235,6 +1240,7 @@ initialize_options(Options * options)
> >         options->ip_qos_interactive = -1;
> >         options->ip_qos_bulk = -1;
> >         options->request_tty = -1;
> > +       options->proxy_use_fdpass = -1;
> >         options->ignored_unknown = NULL;
> >  }
> >
> > @@ -1387,6 +1393,8 @@ fill_default_options(Options * options)
> >                 options->ip_qos_bulk = IPTOS_THROUGHPUT;
> >         if (options->request_tty == -1)
> >                 options->request_tty = REQUEST_TTY_AUTO;
> > +       if (options->proxy_use_fdpass == -1)
> > +               options->proxy_use_fdpass = 0;
> >         /* options->local_command should not be set by default */
> >         /* options->proxy_command should not be set by default */
> >         /* options->user will be set in the main program if appropriate */
> > Index: readconf.h
> > ===================================================================
> > RCS file: /var/cvs/openssh/readconf.h,v
> > retrieving revision 1.87
> > diff -u -p -r1.87 readconf.h
> > --- readconf.h  16 May 2013 10:30:03 -0000      1.87
> > +++ readconf.h  21 Jun 2013 00:00:29 -0000
> > @@ -138,6 +138,8 @@ typedef struct {
> >
> >         int     request_tty;
> >
> > +       int     proxy_use_fdpass;
> > +
> >         char    *ignored_unknown; /* Pattern list of unknown tokens to ignore */
> >  }       Options;
> >
> > Index: ssh_config.5
> > ===================================================================
> > RCS file: /var/cvs/openssh/ssh_config.5,v
> > retrieving revision 1.164
> > diff -u -p -r1.164 ssh_config.5
> > --- ssh_config.5        16 May 2013 10:30:32 -0000      1.164
> > +++ ssh_config.5        21 Jun 2013 00:00:29 -0000
> > @@ -931,6 +931,14 @@ For example, the following directive wou
> >  .Bd -literal -offset 3n
> >  ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
> >  .Ed
> > +.It Cm ProxyUseFdpass
> > +Specifies that the a
> > +.Cm ProxyCommand
> > +will pass a connected file descriptor back to
> > +.Nm ssh
> > +instead of continuing to execute and pass data.
> > +The default is
> > +.Dq no .
> >  .It Cm PubkeyAuthentication
> >  Specifies whether to try public key authentication.
> >  The argument to this keyword must be
> > Index: sshconnect.c
> > ===================================================================
> > RCS file: /var/cvs/openssh/sshconnect.c,v
> > retrieving revision 1.211
> > diff -u -p -r1.211 sshconnect.c
> > --- sshconnect.c        1 Jun 2013 21:31:19 -0000       1.211
> > +++ sshconnect.c        21 Jun 2013 00:00:29 -0000
> > @@ -59,6 +59,7 @@
> >  #include "misc.h"
> >  #include "dns.h"
> >  #include "roaming.h"
> > +#include "monitor_fdpass.h"
> >  #include "ssh2.h"
> >  #include "version.h"
> >
> > @@ -78,16 +79,113 @@ extern uid_t original_effective_uid;
> >  static int show_other_keys(struct hostkeys *, Key *);
> >  static void warn_changed_key(Key *);
> >
> > +/* Expand a proxy command */
> > +static char *
> > +expand_proxy_command(const char *proxy_command, const char *user,
> > +    const char *host, int port)
> > +{
> > +       char *tmp, *ret, strport[NI_MAXSERV];
> > +
> > +       snprintf(strport, sizeof strport, "%hu", port);
> > +       xasprintf(&tmp, "exec %s", proxy_command);
> > +       ret = percent_expand(tmp, "h", host, "p", strport,
> > +           "r", options.user, (char *)NULL);
> > +       free(tmp);
> > +       return ret;
> > +}
> > +
> > +/*
> > + * Connect to the given ssh server using a proxy command that passes a
> > + * a connected fd back to us.
> > + */
> > +static int
> > +ssh_proxy_fdpass_connect(const char *host, u_short port,
> > +    const char *proxy_command)
> > +{
> > +       char *command_string;
> > +       int sp[2], sock;
> > +       pid_t pid;
> > +       char *shell;
> > +
> > +       if ((shell = getenv("SHELL")) == NULL)
> > +               shell = _PATH_BSHELL;
> > +
> > +       if (socketpair(AF_UNIX, SOCK_STREAM, 0, sp) < 0)
> > +               fatal("Could not create socketpair to communicate with "
> > +                   "proxy dialer: %.100s", strerror(errno));
> > +
> > +       command_string = expand_proxy_command(proxy_command, options.user,
> > +           host, port);
> > +       debug("Executing proxy dialer command: %.500s", command_string);
> > +
> > +       /* Fork and execute the proxy command. */
> > +       if ((pid = fork()) == 0) {
> > +               char *argv[10];
> > +
> > +               /* Child.  Permanently give up superuser privileges. */
> > +               permanently_drop_suid(original_real_uid);
> > +
> > +               close(sp[1]);
> > +               /* Redirect stdin and stdout. */
> > +               if (sp[0] != 0) {
> > +                       if (dup2(sp[0], 0) < 0)
> > +                               perror("dup2 stdin");
> > +               }
> > +               if (sp[0] != 1) {
> > +                       if (dup2(sp[0], 1) < 0)
> > +                               perror("dup2 stdout");
> > +               }
> > +               if (sp[0] >= 2)
> > +                       close(sp[0]);
> > +
> > +               /*
> > +                * Stderr is left as it is so that error messages get
> > +                * printed on the user's terminal.
> > +                */
> > +               argv[0] = shell;
> > +               argv[1] = "-c";
> > +               argv[2] = command_string;
> > +               argv[3] = NULL;
> > +
> > +               /*
> > +                * Execute the proxy command.
> > +                * Note that we gave up any extra privileges above.
> > +                */
> > +               execv(argv[0], argv);
> > +               perror(argv[0]);
> > +               exit(1);
> > +       }
> > +       /* Parent. */
> > +       if (pid < 0)
> > +               fatal("fork failed: %.100s", strerror(errno));
> > +       close(sp[0]);
> > +       free(command_string);
> > +
> > +       if ((sock = mm_receive_fd(sp[1])) == -1)
> > +               fatal("proxy dialer did not pass back a connection");
> > +
> > +       while (waitpid(pid, NULL, 0) == -1)
> > +               if (errno != EINTR)
> > +                       fatal("Couldn't wait for child: %s", strerror(errno));
> > +
> > +       /* Set the connection file descriptors. */
> > +       packet_set_connection(sock, sock);
> > +       packet_set_timeout(options.server_alive_interval,
> > +           options.server_alive_count_max);
> > +
> > +       return 0;
> > +}
> > +
> >  /*
> >   * Connect to the given ssh server using a proxy command.
> >   */
> >  static int
> >  ssh_proxy_connect(const char *host, u_short port, const char *proxy_command)
> >  {
> > -       char *command_string, *tmp;
> > +       char *command_string;
> >         int pin[2], pout[2];
> >         pid_t pid;
> > -       char *shell, strport[NI_MAXSERV];
> > +       char *shell;
> >
> >         if (!strcmp(proxy_command, "-")) {
> >                 packet_set_connection(STDIN_FILENO, STDOUT_FILENO);
> > @@ -96,29 +194,19 @@ ssh_proxy_connect(const char *host, u_sh
> >                 return 0;
> >         }
> >
> > +       if (options.proxy_use_fdpass)
> > +               return ssh_proxy_fdpass_connect(host, port, proxy_command);
> > +
> >         if ((shell = getenv("SHELL")) == NULL || *shell == '\0')
> >                 shell = _PATH_BSHELL;
> >
> > -       /* Convert the port number into a string. */
> > -       snprintf(strport, sizeof strport, "%hu", port);
> > -
> > -       /*
> > -        * Build the final command string in the buffer by making the
> > -        * appropriate substitutions to the given proxy command.
> > -        *
> > -        * Use "exec" to avoid "sh -c" processes on some platforms
> > -        * (e.g. Solaris)
> > -        */
> > -       xasprintf(&tmp, "exec %s", proxy_command);
> > -       command_string = percent_expand(tmp, "h", host, "p", strport,
> > -           "r", options.user, (char *)NULL);
> > -       free(tmp);
> > -
> >         /* Create pipes for communicating with the proxy. */
> >         if (pipe(pin) < 0 || pipe(pout) < 0)
> >                 fatal("Could not create pipes to communicate with the proxy: %.100s",
> >                     strerror(errno));
> >
> > +       command_string = expand_proxy_command(proxy_command, options.user,
> > +           host, port);
> >         debug("Executing proxy command: %.500s", command_string);
> >
> >         /* Fork and execute the proxy command. */
> _______________________________________________
> 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  Wed Aug 21 02:55:57 2013
From: djm at mindrot.org (Damien Miller)
Date: Wed, 21 Aug 2013 02:55:57 +1000 (EST)
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1308210250550.576@mindrot.org>

On Wed, 11 Jan 2012, Richard Hartmann wrote:

> Thanks, but I am not sure I want either a Windows-centric base product
> or something that tries to intercept stuff.
> 
> FWIW, I am attaching the patchset I found in my backups. Maybe someone
> is interested in this and willing to take it from here?

Hi,

Thanks for sending this. I'm not 100% sure we want this in the base sshd
but quite a few people have asked for it over the years (particularly
people with system under financial audit requirements) so it might be
worthwhile. 

Could I ask you to create a bug on https://bugzilla.mindrot.org/ and attach
this patch? 

Also, there are no copyright/licence blocks on the new files. Are these code
that you wrote? If so, could you please add a licence block (ideally 
using this template http://goo.gl/BQ5a4v ) to each of the new files?

Thanks,
Damien

From pi at nepustil.net  Thu Aug 22 01:21:13 2013
From: pi at nepustil.net (Kurt Jaeger)
Date: Wed, 21 Aug 2013 17:21:13 +0200
Subject: sftp logging, filenames with strange characters and parsing the
 logfile
Message-ID: <20130821152113.GA60410@complx.nepustil.net>

Hi!

The OpenSSH sshd sftp function can be configured to send logging to syslog.

When a file is open'ed or closed with unexpected characters, those
characters are send directly to syslog, e.g. a file with a '"' in it:

Aug 21 17:09:11 test internal-sftp[10128]: open "/usr/home/test/te"st" flags WRITE,CREATE,TRUNCATE mode 0664

This makes is difficult and error-prone to parse the logfile. Would it
be possible to mask those characters in filenames, e.g. like the quotemeta
function in perl does or the %xx escapes used in apache ?

Alternativly, if the logging is changed so that the filename comes at
the end, then the parser can just read until end-of-line (if the filename
does not contain a newline...)

Something like this:

Aug 21 17:09:11 test internal-sftp[10128]: open flags WRITE,CREATE,TRUNCATE mode 0664 name /usr/home/test/te"st

-- 
MfG/Best regards, Kurt Jaeger                                   7 years to go !
Dr.-Ing. Nepustil & Co. GmbH  fon +49 7123 93006-0  pi at nepustil.net
Rathausstr. 3                 fax +49 7123 93006-99
72658 Bempflingen             mob +49 171 3101372

From richih.mailinglist at gmail.com  Thu Aug 22 20:55:18 2013
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Thu, 22 Aug 2013 12:55:18 +0200
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <alpine.BSO.2.03.1308210250550.576@mindrot.org>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <alpine.BSO.2.03.1308210250550.576@mindrot.org>
Message-ID: <CAD77+gTihpznYjYODJJYfgBjDx-znPf0v5hHNrgg76UEf2foew@mail.gmail.com>

On Tue, Aug 20, 2013 at 6:55 PM, Damien Miller <djm at mindrot.org> wrote:

> Thanks for sending this. I'm not 100% sure we want this in the base sshd
> but quite a few people have asked for it over the years (particularly
> people with system under financial audit requirements) so it might be
> worthwhile.

We are in a similar situation.


> Could I ask you to create a bug on https://bugzilla.mindrot.org/ and attach
> this patch?

Will do in a few days.


> Also, there are no copyright/licence blocks on the new files. Are these code
> that you wrote? If so, could you please add a licence block (ideally
> using this template http://goo.gl/BQ5a4v ) to each of the new files?

This patch has been floating around in various incarnations over the
years within our company. I will need to see where we got it
initially, in-house or otherwise...


Richard

From dragos.ilie at bth.se  Mon Aug 26 20:12:29 2013
From: dragos.ilie at bth.se (Dragos Ilie)
Date: Mon, 26 Aug 2013 12:12:29 +0200
Subject: Hex string following key path
Message-ID: <521B2A0D.8030501@bth.se>

Hi,


Can somebody explain what is the hex string following the path to the
RSA key used for authentication? For an example, see last line in the
debug snippet shown below.

debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/blah/.ssh/id_rsa (0x6fef81c1d114)


How is that value generated? Is it something I can also do from the
command line? First, I thought it is the fingerprint of the public key
(as in ssh-keygen -l), but that's not it.


Regards,
Dragos

From medsalim.bouhlel at enis.rnu.tn  Tue Aug 27 04:48:06 2013
From: medsalim.bouhlel at enis.rnu.tn (Global Premier International Conference on Cryptography and Security
 2014)
Date: Mon, 26 Aug 2013 20:48:06 +0200
Subject: Call For Papers : International Conference on Cryptography and
 Security / July 2014 - Bangkok/ 
Message-ID: <6240408905683081320786@SETIT-PC>

Appologies if you received multiple copies.
Please consider to contribute and encourage your team members and fellow scientists to contribute to the following events.
Thanks for forwarding the information on this Call for Submissions to those potentially interested to submit.


Call for papers
International Conference on Cryptography and Security 2014
18-20 July 2014
Holiday Inn Silom, Bangkok, Kingdom of Thailand 

 

In association with SETIT, Sfax University, Tunisia. and ASDF (Association of Scientists, Developers and Faculties) Chennai Chapter,

International Conference on Cryptography and Security 2014, is a main annual research conference aimed at presenting current research being carried out. The idea of the conference is for the scientists, scholars, engineers and students from the Universities all around the world and the industry to present ongoing research activities, and hence to foster research relations between the Universities and the industry.
ICCS2014 is co-sponsored by the Association of Scientists, Developers and Faculties, India and SETIT, Sfax University, Tunisia and technical co-sponsored by many other universities and institutes.
The purpose of ICCS 2014, the International Conference on Cryptography and Security, is to bring together researchers, mathematicians, engineers and practitioners interested on security aspects related to information and communication. Theoretical and practical advances in the fields of cryptography and coding are a key factor in the growth of data communications, data networks and distributed computing. In addition to the mathematical theory and practice of cryptography and coding, ICCS also focuses on other aspects of information systems and network security, including applications in the scope of the knowledge society in general and information systems development in particular, especially in the context of e-business, internet and global enterprises.Areas of Conference

Cryptography
Data Security
Network Security
Encryption Technologies
Watermarking

 

For more information visit : http://www.iccs.asdf.org.in/

or join us on Facebook : http://www.facebook.com/pages/International-Conference-on-Cryptography-and-Security/450970385009899/

Best regards

Mohamed Salim BOUHLEL
General Co-Chair, ICCS2014
Head of Research Unit: Sciences & Technologies of Image and Telecommunications (Sfax University)
GSM +216 20 20 00 05



========================================================================================
This email is sent out to all those on the SETIT database. If you want to be removed from this database, please send an email
to unsubscribe.setit at gmail.com with subject Unsubscribe
========================================================================================




From djm at mindrot.org  Tue Aug 27 08:02:50 2013
From: djm at mindrot.org (Damien Miller)
Date: Tue, 27 Aug 2013 08:02:50 +1000 (EST)
Subject: Hex string following key path
In-Reply-To: <521B2A0D.8030501@bth.se>
References: <521B2A0D.8030501@bth.se>
Message-ID: <alpine.BSO.2.03.1308270802190.17663@mindrot.org>

It's a pointer to the key in memory. You can't use it for anything except
debugging.

On Mon, 26 Aug 2013, Dragos Ilie wrote:

> Hi,
> 
> 
> Can somebody explain what is the hex string following the path to the
> RSA key used for authentication? For an example, see last line in the
> debug snippet shown below.
> 
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: /Users/blah/.ssh/id_rsa (0x6fef81c1d114)
> 
> 
> How is that value generated? Is it something I can also do from the
> command line? First, I thought it is the fingerprint of the public key
> (as in ssh-keygen -l), but that's not it.
> 
> 
> Regards,
> Dragos
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>