From ebarreto at linux.vnet.ibm.com  Wed Mar  1 00:47:57 2017
From: ebarreto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Tue, 28 Feb 2017 10:47:57 -0300
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
Message-ID: <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>

On 13-02-2017 13:23, Eduardo Barretto wrote:
> This patch enables specific ioctl calls for ICA crypto card on s390
> platform. Without this patch, users using the IBMCA engine are not able
> to perform ssh login as the filter blocks the communication with the
> crypto card.
> 
> Signed-off-by: Harald Freudenberger <freude at linux.vnet.ibm.com>
> Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
> ---
>  sandbox-seccomp-filter.c | 24 +++++++++++++++++++++---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
> index 2e1ed2c..264e146 100644
> --- a/sandbox-seccomp-filter.c
> +++ b/sandbox-seccomp-filter.c
> @@ -59,6 +59,11 @@
>  #include <stdlib.h>
>  #include <string.h>
>  #include <unistd.h>
> +#include <endian.h>
> +
> +#ifdef __s390__
> +#include <asm/zcrypt.h>
> +#endif
> 
>  #include "log.h"
>  #include "ssh-sandbox.h"
> @@ -74,6 +79,13 @@
>  #endif /* SANDBOX_SECCOMP_FILTER_DEBUG */
> 
>  /* Simple helpers to avoid manual errors (but larger BPF programs). */
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> +#define LO_ARG(idx) offsetof(struct seccomp_data, args[(idx)])
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +#define LO_ARG(idx) offsetof(struct seccomp_data, args[(idx)]) + sizeof(_u32)
> +#else
> +#error "Unknown endianness"
> +#endif
>  #define SC_DENY(_nr, _errno) \
>  	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 1), \
>  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ERRNO|(_errno))
> @@ -82,9 +94,8 @@
>  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW)
>  #define SC_ALLOW_ARG(_nr, _arg_nr, _arg_val) \
>  	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 4), \
> -	/* load first syscall argument */ \
> -	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, \
> -	    offsetof(struct seccomp_data, args[(_arg_nr)])), \
> +	/* load the syscall argument to check into accumulator */ \
> +	BPF_STMT(BPF_LD+BPF_W+BPF_ABS, LO_ARG(_arg_nr)), \
>  	BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, (_arg_val), 0, 1), \
>  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW), \
>  	/* reload syscall number; all rules expect it in accumulator */ \
> @@ -207,6 +218,13 @@ static const struct sock_filter preauth_insns[] = {
>  #ifdef __NR_socketcall
>  	SC_ALLOW_ARG(socketcall, 0, SYS_SHUTDOWN),
>  #endif
> +#ifdef __NR_ioctl
> +#ifdef __s390__
> +	SC_ALLOW_ARG(ioctl, 1, Z90STAT_STATUS_MASK),
> +	SC_ALLOW_ARG(ioctl, 1, ICARSAMODEXPO),
> +	SC_ALLOW_ARG(ioctl, 1, ICARSACRT),
> +#endif
> +#endif
> 
>  	/* Default deny */
>  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),
> 

Hi there,

Do you have any feedback on this patch?

Thanks,

Eduardo


From adrian.wilkins at gmail.com  Thu Mar  2 00:41:38 2017
From: adrian.wilkins at gmail.com (Adrian Wilkins)
Date: Wed, 1 Mar 2017 13:41:38 +0000
Subject: Slow connects due to out-of-context DNS lookup
Message-ID: <43bcebdd-ddc4-e89c-0ed7-4c0d8e86f5ed@gmail.com>

Ok, so my situation :

Connecting to internal machines via a bastion server in AWS.

Because I'm raising and tearing down the infrastructure a lot at this 
stage with Terraform, the IP addresses change.

For the management subnet, I have a private DNS zone defined, and a 
public zone with a record for the bastion server.

What I wanted ; to just be able to define a config entry thus :

---

Host graylog
   Hostname graylog.management
   ProxyCommand ssh -q -W %h:%p user at jumpbox.my.aws.zone

---

This takes a long time (> 30s)to connect because the client is doing a 
DNS lookup on the Hostname, which apparently has to fail before it 
attempts to connect.

Add this to your /etc/hosts ...

---

127.0.0.1  graylog.management

---

... and connection is swift. This seems like a rather grody workaround, 
because one day I may have a VPN server inside this cloud and want DNS 
lookups to work properly.

Is there a way to suppress this DNS lookup happening locally, when using 
ProxyCommand?

Is this in the same set of things being discussed at

http://marc.info/?l=openssh-unix-dev&m=139556798100796&w=2

and https://bugzilla.mindrot.org/show_bug.cgi?id=2218

?

I don't have CanonicalizeHostName on, so what's doing the lookup?

From jonathan.windham at fostermoore.com  Wed Mar  1 04:09:38 2017
From: jonathan.windham at fostermoore.com (Jonathan Windham)
Date: Tue, 28 Feb 2017 17:09:38 +0000
Subject: How can one log keystokes being sent via ssh on the
 machine initiating the connection?
Message-ID: <SINPR03MB23207BA2DD23F7D5BBB53AAC91560@SINPR03MB2320.apcprd03.prod.outlook.com>

Greetings all,

         I am a systems administrator, and please forgive me if I have been obtuse, or if this question has been asked in the past, but I am looking for a method in which to collect every keystroke or every command sent from a jumphost in my environment to target machines on the distal end of the connection. The hosts on the distant end of the connection are hosts in which the users have administrative (root level) access, so its trivial to cover their tracks.  I've tried the auditd route, and it relies on pam-tty.so, and it looks based on the github, that this functionality as it relates to openssh was depreciated. No longer does facist mode exist, and LogLevel at debug level 3 does not reveal the information that I am looking for.

Is there any way that I can accomplish this, any help in this would be appreciated greatly.

Humbly yours,



Jonathan Windham

Sr. Systems Engineer



E jonathan.windham at fostermoore.com

Cary

fostermoore.com

This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.

From djm at mindrot.org  Thu Mar  2 08:33:42 2017
From: djm at mindrot.org (Damien Miller)
Date: Thu, 2 Mar 2017 08:33:42 +1100 (AEDT)
Subject: Slow connects due to out-of-context DNS lookup
In-Reply-To: <43bcebdd-ddc4-e89c-0ed7-4c0d8e86f5ed@gmail.com>
References: <43bcebdd-ddc4-e89c-0ed7-4c0d8e86f5ed@gmail.com>
Message-ID: <alpine.BSO.2.20.1703020833120.84535@natsu.mindrot.org>

Please send verbose output, i.e. "ssh -vvv ..."

On Wed, 1 Mar 2017, Adrian Wilkins wrote:

> Ok, so my situation :
> 
> Connecting to internal machines via a bastion server in AWS.
> 
> Because I'm raising and tearing down the infrastructure a lot at this stage
> with Terraform, the IP addresses change.
> 
> For the management subnet, I have a private DNS zone defined, and a public
> zone with a record for the bastion server.
> 
> What I wanted ; to just be able to define a config entry thus :
> 
> ---
> 
> Host graylog
>   Hostname graylog.management
>   ProxyCommand ssh -q -W %h:%p user at jumpbox.my.aws.zone
> 
> ---
> 
> This takes a long time (> 30s)to connect because the client is doing a DNS
> lookup on the Hostname, which apparently has to fail before it attempts to
> connect.
> 
> Add this to your /etc/hosts ...
> 
> ---
> 
> 127.0.0.1  graylog.management
> 
> ---
> 
> ... and connection is swift. This seems like a rather grody workaround,
> because one day I may have a VPN server inside this cloud and want DNS lookups
> to work properly.
> 
> Is there a way to suppress this DNS lookup happening locally, when using
> ProxyCommand?
> 
> Is this in the same set of things being discussed at
> 
> http://marc.info/?l=openssh-unix-dev&m=139556798100796&w=2
> 
> and https://bugzilla.mindrot.org/show_bug.cgi?id=2218
> 
> ?
> 
> I don't have CanonicalizeHostName on, so what's doing the lookup?
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From djm at mindrot.org  Thu Mar  2 15:32:05 2017
From: djm at mindrot.org (Damien Miller)
Date: Thu, 2 Mar 2017 15:32:05 +1100 (AEDT)
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
Message-ID: <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>

On Tue, 28 Feb 2017, Eduardo Barretto wrote:

> On 13-02-2017 13:23, Eduardo Barretto wrote:
> > This patch enables specific ioctl calls for ICA crypto card on s390
> > platform. Without this patch, users using the IBMCA engine are not able
> > to perform ssh login as the filter blocks the communication with the
> > crypto card.
> > 
> > Signed-off-by: Harald Freudenberger <freude at linux.vnet.ibm.com>
> > Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
> > ---
> >  sandbox-seccomp-filter.c | 24 +++++++++++++++++++++---
> >  1 file changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
> > index 2e1ed2c..264e146 100644
> > --- a/sandbox-seccomp-filter.c
> > +++ b/sandbox-seccomp-filter.c

[snip]

> Hi there,
> 
> Do you have any feedback on this patch?

It's hard to evaluate it without reference to some public documentation
for the crypto card and the syscalls needed to use it. Is it a standard
part of s390 machines or an option?

Does it provide substantial benefit for the crypto used in the pre-auth
stage of the protocol? (private key operations and DH/ECDH key agreement)

-d

From nkadel at gmail.com  Thu Mar  2 17:31:25 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 2 Mar 2017 01:31:25 -0500
Subject: How can one log keystokes being sent via ssh on the machine
 initiating the connection?
In-Reply-To: <SINPR03MB23207BA2DD23F7D5BBB53AAC91560@SINPR03MB2320.apcprd03.prod.outlook.com>
References: <SINPR03MB23207BA2DD23F7D5BBB53AAC91560@SINPR03MB2320.apcprd03.prod.outlook.com>
Message-ID: <CAOCN9ry3-RGp0cvEzGjzfF67n8TmZpQ8hAKaNTwV4pntbr4LLQ@mail.gmail.com>

On Tue, Feb 28, 2017 at 12:09 PM, Jonathan Windham
<jonathan.windham at fostermoore.com> wrote:
> Greetings all,
>
>          I am a systems administrator, and please forgive me if I have been obtuse, or if this question has been asked in the past, but I am looking for a method in which to collect every keystroke or every command sent from a jumphost in my environment to target machines on the distal end of the connection. The hosts on the distant end of the connection are hosts in which the users have administrative (root level) access, so its trivial to cover their tracks.  I've tried the auditd route, and it relies on pam-tty.so, and it looks based on the github, that this functionality as it relates to openssh was depreciated. No longer does facist mode exist, and LogLevel at debug level 3 does not reveal the information that I am looking for.

I'd urge you to consult with an actual attorney in our state before you do this.

The typical method is to replace the local "bash" or user shell  on
the jumphost with one that key strokes everything. If you have to
protect yourself from power users who might be able to make the
additional steps your jumphost, well, that's a whole second layer of
pain.

From spleefer90 at gmail.com  Thu Mar  2 22:46:07 2017
From: spleefer90 at gmail.com (Martin Rys)
Date: Thu, 2 Mar 2017 12:46:07 +0100
Subject: Domain name suffix woes
Message-ID: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>

Example problem -
We have a domain with following DNS records

330.domain.com CNAME 330.blah.domain.com
330.blah.domain.com A 10.0.1.2

foo.domain.com A 10.0.2.2

Now, when I set `search domain.com` in /etc/resolv.conf, I can use SSH to
connect to foo like this

`ssh user at foo`

and I can connect to the 330 A record like this

`ssh user at 330.blah`

However I cannot connect to the 330.domain.com via

`ssh user at 330` - That gets me an error:
ssh: connect to host 330 port 22: Invalid argument

I'm assuming that when the hostname is pure number, it ignores domain
suffix. As just a number cannot be an actual IP, could this behavior be
fixed in OpenSSH?

Thanks, Martin

From philipp.marek at linbit.com  Thu Mar  2 23:05:28 2017
From: philipp.marek at linbit.com (Philipp Marek)
Date: Thu, 2 Mar 2017 13:05:28 +0100
Subject: Domain name suffix woes
In-Reply-To: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>
References: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>
Message-ID: <20170302120527.6iz77nwuok36yxxc@cacao.linbit>


> I'm assuming that when the hostname is pure number, it ignores domain
> suffix. As just a number cannot be an actual IP, could this behavior be
> fixed in OpenSSH?
A number _is_ (or can be) a valid IPv4.

    $ perl -e 'print gethostbyname(shift)."\n"' 65.65.65.65
    AAAA
    $ perl -e 'print gethostbyname(shift)."\n"' 1094795585
    AAAA

You can leave out parts of the IP address:

    $ perl -e 'print gethostbyname(shift)."\n"' 65.65 | hd
    00000000  41 00 00 41 0a                                    |A..A.|

See also 
http://serverfault.com/questions/638260/is-it-valid-for-a-hostname-to-start-with-a-digit 
for some more discussion and links.


From dtucker at zip.com.au  Thu Mar  2 23:09:23 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 2 Mar 2017 23:09:23 +1100
Subject: Domain name suffix woes
In-Reply-To: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>
References: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>
Message-ID: <CALDDTe3DoYHc0VpWJ4Zic3fNC+Oodz7sDQ=wrqp8NEk1X5dwAg@mail.gmail.com>

On Thu, Mar 2, 2017 at 10:46 PM, Martin Rys <spleefer90 at gmail.com> wrote:
[...]
> `ssh user at 330` - That gets me an error:
> ssh: connect to host 330 port 22: Invalid argument
>
> I'm assuming that when the hostname is pure number, it ignores domain
> suffix. As just a number cannot be an actual IP, could this behavior be
> fixed in OpenSSH?

not really, the behaviour in question is in they system libraries,
which think it's an IP address (single numeric, number.number and
octal are all valid but uncommon representations of IP addresses).

$ gethostip localhost
localhost.localdomain 127.0.0.1 7F000001

$ gethostip 330
330 0.0.1.74 0000014A

$ telnet 330
Trying 0.0.1.74...
telnet: connect to address 0.0.1.74: Invalid argument

You can work around it with an entry in ~/.ssh/config:

Host 300
   Hostname 330.blah.domain.com

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From nkadel at gmail.com  Fri Mar  3 00:24:10 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 2 Mar 2017 08:24:10 -0500
Subject: Domain name suffix woes
In-Reply-To: <CALDDTe3DoYHc0VpWJ4Zic3fNC+Oodz7sDQ=wrqp8NEk1X5dwAg@mail.gmail.com>
References: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>
 <CALDDTe3DoYHc0VpWJ4Zic3fNC+Oodz7sDQ=wrqp8NEk1X5dwAg@mail.gmail.com>
Message-ID: <CAOCN9rzL4HcKFPnqs6c=FSRA3WXPdb8UnJC=hCNMkKOcBb5o2Q@mail.gmail.com>

On Thu, Mar 2, 2017 at 7:09 AM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Thu, Mar 2, 2017 at 10:46 PM, Martin Rys <spleefer90 at gmail.com> wrote:
> [...]
>> `ssh user at 330` - That gets me an error:
>> ssh: connect to host 330 port 22: Invalid argument
>>
>> I'm assuming that when the hostname is pure number, it ignores domain
>> suffix. As just a number cannot be an actual IP, could this behavior be
>> fixed in OpenSSH?
>
> not really, the behaviour in question is in they system libraries,
> which think it's an IP address (single numeric, number.number and
> octal are all valid but uncommon representations of IP addresses).
>
> $ gethostip localhost
> localhost.localdomain 127.0.0.1 7F000001
>
> $ gethostip 330
> 330 0.0.1.74 0000014A
>
> $ telnet 330
> Trying 0.0.1.74...
> telnet: connect to address 0.0.1.74: Invalid argument
>
> You can work around it with an entry in ~/.ssh/config:
>
> Host 300
>    Hostname 330.blah.domain.com

Note that SSH is hardly the only tool vulnerable to t his problem.
This is why most of us never use raw numbers as shortened hostnames,
even if it is convenient on occasion.

From spleefer90 at gmail.com  Fri Mar  3 00:29:11 2017
From: spleefer90 at gmail.com (Martin Rys)
Date: Thu, 2 Mar 2017 14:29:11 +0100
Subject: Domain name suffix woes
In-Reply-To: <CAOCN9rzL4HcKFPnqs6c=FSRA3WXPdb8UnJC=hCNMkKOcBb5o2Q@mail.gmail.com>
References: <CACbE=3oSwV1Euy=u8FN-kPT0fPSBJymNNNrw+MTQJaNuYoswrQ@mail.gmail.com>
 <CALDDTe3DoYHc0VpWJ4Zic3fNC+Oodz7sDQ=wrqp8NEk1X5dwAg@mail.gmail.com>
 <CAOCN9rzL4HcKFPnqs6c=FSRA3WXPdb8UnJC=hCNMkKOcBb5o2Q@mail.gmail.com>
Message-ID: <CACbE=3oHsty975+i257+gZY+TsDoieHdC=Kie1vmzg1y2Nqmsw@mail.gmail.com>

Thanks for the input and explanation, I changed the names so they start
with a letter.

Martin

On Thu, Mar 2, 2017 at 2:24 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Thu, Mar 2, 2017 at 7:09 AM, Darren Tucker <dtucker at zip.com.au> wrote:
> > On Thu, Mar 2, 2017 at 10:46 PM, Martin Rys <spleefer90 at gmail.com>
> wrote:
> > [...]
> >> `ssh user at 330` - That gets me an error:
> >> ssh: connect to host 330 port 22: Invalid argument
> >>
> >> I'm assuming that when the hostname is pure number, it ignores domain
> >> suffix. As just a number cannot be an actual IP, could this behavior be
> >> fixed in OpenSSH?
> >
> > not really, the behaviour in question is in they system libraries,
> > which think it's an IP address (single numeric, number.number and
> > octal are all valid but uncommon representations of IP addresses).
> >
> > $ gethostip localhost
> > localhost.localdomain 127.0.0.1 7F000001
> >
> > $ gethostip 330
> > 330 0.0.1.74 0000014A
> >
> > $ telnet 330
> > Trying 0.0.1.74...
> > telnet: connect to address 0.0.1.74: Invalid argument
> >
> > You can work around it with an entry in ~/.ssh/config:
> >
> > Host 300
> >    Hostname 330.blah.domain.com
>
> Note that SSH is hardly the only tool vulnerable to t his problem.
> This is why most of us never use raw numbers as shortened hostnames,
> even if it is convenient on occasion.
>

From dcavalcanticosta at gmail.com  Fri Mar  3 03:25:33 2017
From: dcavalcanticosta at gmail.com (Daniel Costa)
Date: Thu, 02 Mar 2017 16:25:33 +0000
Subject: Windows 10 instalation issue
Message-ID: <CAKE61t79+rujwtQM29pu-f+NLEeG4UvDKNRqrJUd=nxFN=xJhw@mail.gmail.com>

I've been struggling with the OpenSSH 3.8.1p1-1 installation on windows 10,
it does not finishes, gives no errors or messages, just stays like this:
[image: openssh-install.jpg]

Can someone help me with this please?
Thanks!
-- 
Atenciosamente,
Daniel Cavalcanti Costa.

From dtucker at zip.com.au  Fri Mar  3 10:57:08 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 3 Mar 2017 10:57:08 +1100
Subject: Windows 10 instalation issue
In-Reply-To: <CAKE61t79+rujwtQM29pu-f+NLEeG4UvDKNRqrJUd=nxFN=xJhw@mail.gmail.com>
References: <CAKE61t79+rujwtQM29pu-f+NLEeG4UvDKNRqrJUd=nxFN=xJhw@mail.gmail.com>
Message-ID: <CALDDTe3BsJ6BBhHvJbNvwowqvxszJ-RQ1jqcvGoj=rQFy1KhWA@mail.gmail.com>

On Fri, Mar 3, 2017 at 3:25 AM, Daniel Costa <dcavalcanticosta at gmail.com> wrote:
> I've been struggling with the OpenSSH 3.8.1p1-1 installation on windows 10,

That is an amazingly obsolete package of a _13_ year old version[1] of
OpenSSH and Cygwin packaged and abandoned by a third party.  The
version of OpenSSH has a number of known vulnerabilities and the
installer has been reported to trash Windows 10 installations.  To my
knowledge nobody on this list has anything to do with it and I
personally consider it an attractive nuisance that should be taken
down entirely.

[1] https://www.openssh.com/releasenotes.html#3.8p1

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dcavalcanticosta at gmail.com  Fri Mar  3 15:15:59 2017
From: dcavalcanticosta at gmail.com (Daniel Costa)
Date: Fri, 03 Mar 2017 04:15:59 +0000
Subject: Windows 10 instalation issue
In-Reply-To: <CALDDTe3BsJ6BBhHvJbNvwowqvxszJ-RQ1jqcvGoj=rQFy1KhWA@mail.gmail.com>
References: <CAKE61t79+rujwtQM29pu-f+NLEeG4UvDKNRqrJUd=nxFN=xJhw@mail.gmail.com>
 <CALDDTe3BsJ6BBhHvJbNvwowqvxszJ-RQ1jqcvGoj=rQFy1KhWA@mail.gmail.com>
Message-ID: <CAKE61t73Qgs0HyvAbFB+KNAG9pop618PdMmbp0wyB_7jJhEpxw@mail.gmail.com>

hum didn`t know that, got the installator on a tutorial. thanks anyway

Em qui, 2 de mar de 2017 ?s 20:57, Darren Tucker <dtucker at zip.com.au>
escreveu:

> On Fri, Mar 3, 2017 at 3:25 AM, Daniel Costa <dcavalcanticosta at gmail.com>
> wrote:
> > I've been struggling with the OpenSSH 3.8.1p1-1 installation on windows
> 10,
>
> That is an amazingly obsolete package of a _13_ year old version[1] of
> OpenSSH and Cygwin packaged and abandoned by a third party.  The
> version of OpenSSH has a number of known vulnerabilities and the
> installer has been reported to trash Windows 10 installations.  To my
> knowledge nobody on this list has anything to do with it and I
> personally consider it an attractive nuisance that should be taken
> down entirely.
>
> [1] https://www.openssh.com/releasenotes.html#3.8p1
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>
-- 
Atenciosamente,
Daniel Cavalcanti Costa.

From pcerny at suse.cz  Fri Mar  3 23:54:06 2017
From: pcerny at suse.cz (Petr Cerny)
Date: Fri, 3 Mar 2017 13:54:06 +0100
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
Message-ID: <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>

Damien Miller wrote:
> On Tue, 28 Feb 2017, Eduardo Barretto wrote:
>
>> On 13-02-2017 13:23, Eduardo Barretto wrote:
>> > This patch enables specific ioctl calls for ICA crypto card on s390
>> > platform. Without this patch, users using the IBMCA engine are not able
>> > to perform ssh login as the filter blocks the communication with the
>> > crypto card.
>> >
>> > Signed-off-by: Harald Freudenberger <freude at linux.vnet.ibm.com>
>> > Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
>> > ---
>> >  sandbox-seccomp-filter.c | 24 +++++++++++++++++++++---
>> >  1 file changed, 21 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
>> > index 2e1ed2c..264e146 100644
>> > --- a/sandbox-seccomp-filter.c
>> > +++ b/sandbox-seccomp-filter.c
>
> [snip]
>
>> Hi there,
>>
>> Do you have any feedback on this patch?
>
> It's hard to evaluate it without reference to some public documentation
> for the crypto card and the syscalls needed to use it. Is it a standard
> part of s390 machines or an option?

Hi,

let me step in for Eduardo so that the thread doesn't hibernate.

As far as I know it is an optional piece of hardware, that may or may 
not be present in the system. OpenSSL is typically configured to load 
the libica engine (alongside any other possibly available ones).

As for the syscalls, would 
https://sourceforge.net/p/opencryptoki/libica/ci/master/tree/src/ica_api.c 
and 
http://lxr.free-electrons.com/source/arch/s390/include/uapi/asm/zcrypt.h#L259 
be enough?

> Does it provide substantial benefit for the crypto used in the pre-auth
> stage of the protocol? (private key operations and DH/ECDH key agreement)

It should speed up some these:
https://sourceforge.net/p/opencryptoki/libica/ci/master/tree/doc/icainfo.1

Thanks
Kind regards
	Petr
-- 
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux


From pcerny at suse.cz  Sat Mar  4 00:06:35 2017
From: pcerny at suse.cz (Petr Cerny)
Date: Fri, 3 Mar 2017 14:06:35 +0100
Subject: case sensitive hostname matching
Message-ID: <ac444d9c-4fe8-8248-5301-bb07853e3709@suse.cz>

Hi,

as recently noticed by one of our customers, ssh tends to perform 
hostname matching in a case sensitive manner since the lowercasing has 
been delayed till after configuration parsing (by commits 
d56b44d2dfa093883a5c4e91be3f72d99946b170 and 
eb6d870a0ea8661299bb2ea8f013d3ace04e2024).

Given that hostnames are ususally interpreted in a case insensitive way 
(and the code actually expects the input to be lowercased anyway) it 
might be good to perform the comparisons as such. We can either make 
sure match_hostname() receives a lowercased string indeed or perform the 
lowercasing there (carefully as not to introduce side effects).

One question is, whether *any* hostname matching should be case 
insensitive or whether originalhost is better left alone (I can think of 
reasons for case sensitive matching there, yet they seem to be bordering 
on misuse of the code).

I've also opened https://bugzilla.mindrot.org/show_bug.cgi?id=2685 
(patch is attached there as well).

Thanks
Kind regards
	Petr
-- 
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-ssh_case_insensitive_host_matching.patch
Type: text/x-patch
Size: 1565 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170303/18824394/attachment.bin>

From ebarreto at linux.vnet.ibm.com  Sat Mar  4 01:23:35 2017
From: ebarreto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Fri, 3 Mar 2017 11:23:35 -0300
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
 <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>
Message-ID: <ab1b2c3c-965a-ac0d-afd2-089dbeed3e66@linux.vnet.ibm.com>

On 03-03-2017 09:54, Petr Cerny wrote:
> Damien Miller wrote:
>> On Tue, 28 Feb 2017, Eduardo Barretto wrote:
>>
>>> On 13-02-2017 13:23, Eduardo Barretto wrote:
>>> > This patch enables specific ioctl calls for ICA crypto card on s390
>>> > platform. Without this patch, users using the IBMCA engine are not
>>> able
>>> > to perform ssh login as the filter blocks the communication with the
>>> > crypto card.
>>> >
>>> > Signed-off-by: Harald Freudenberger <freude at linux.vnet.ibm.com>
>>> > Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
>>> > ---
>>> >  sandbox-seccomp-filter.c | 24 +++++++++++++++++++++---
>>> >  1 file changed, 21 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
>>> > index 2e1ed2c..264e146 100644
>>> > --- a/sandbox-seccomp-filter.c
>>> > +++ b/sandbox-seccomp-filter.c
>>
>> [snip]
>>
>>> Hi there,
>>>
>>> Do you have any feedback on this patch?
>>
>> It's hard to evaluate it without reference to some public documentation
>> for the crypto card and the syscalls needed to use it. Is it a standard
>> part of s390 machines or an option?
> 
> Hi,
> 
> let me step in for Eduardo so that the thread doesn't hibernate.
> 
> As far as I know it is an optional piece of hardware, that may or may
> not be present in the system. OpenSSL is typically configured to load
> the libica engine (alongside any other possibly available ones).
> 
> As for the syscalls, would
> https://sourceforge.net/p/opencryptoki/libica/ci/master/tree/src/ica_api.c
> and
> http://lxr.free-electrons.com/source/arch/s390/include/uapi/asm/zcrypt.h#L259
> be enough?
> 
>> Does it provide substantial benefit for the crypto used in the pre-auth
>> stage of the protocol? (private key operations and DH/ECDH key agreement)
> 
> It should speed up some these:
> https://sourceforge.net/p/opencryptoki/libica/ci/master/tree/doc/icainfo.1

Just adding some more information on Petr answer (Thanks Petr for
stepping in!):

The ioctls for the s390 crypto card support are documented. The crypto
device driver is part of the linux kernel and thus open source. It can be
found in the kernel in drivers/s390/crypto. The ioctl stuff required to
interact with the crypto device driver is as usual provided in the
kernel header file arch/s390/include/uapi/asm/zcrypt.h
In particular the defines for the ioctl magics intended to not
get filtered can be found there.

As Petr mentioned, the relevant user space shared library which provides
a comfortable api for applications is libica. Libica is open
source and currently hosted on sourceforge as part of the
opencryptoki project (URLs above).

At the moment the zcrypt device driver provides access
to crypto cards which are able to accelerate RSA functions.
We are currently working on acceleration for ECC functions
and planing to release this in the near future. So one
benefit is performance, another is relief of CPU by
offloading crypto operations to this dedicated hardware.

The key exchange may use DH, ECCDH. The authentication
may use RSA or ECC. All the kind of stuff where the crypto
hardware may assist.

Thanks,
Eduardo
> 
> Thanks
> Kind regards
>     Petr


From rsbecker at nexbridge.com  Sat Mar  4 02:39:13 2017
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Fri, 3 Mar 2017 10:39:13 -0500
Subject: case sensitive hostname matching
In-Reply-To: <ac444d9c-4fe8-8248-5301-bb07853e3709@suse.cz>
References: <ac444d9c-4fe8-8248-5301-bb07853e3709@suse.cz>
Message-ID: <003401d29434$507c0140$f17403c0$@nexbridge.com>

> -----Original Message-----
> From: openssh-unix-dev [mailto:openssh-unix-dev-
> bounces+rsbecker=nexbridge.com at mindrot.org] On Behalf Of Petr Cerny
> Sent: March 3, 2017 8:07 AM
> To: openssh-unix-dev at mindrot.org
> Subject: case sensitive hostname matching
> 
> Hi,
> 
> as recently noticed by one of our customers, ssh tends to perform hostname
> matching in a case sensitive manner since the lowercasing has been delayed
> till after configuration parsing (by commits
> d56b44d2dfa093883a5c4e91be3f72d99946b170 and
> eb6d870a0ea8661299bb2ea8f013d3ace04e2024).
> 
> Given that hostnames are ususally interpreted in a case insensitive way (and
> the code actually expects the input to be lowercased anyway) it might be
> good to perform the comparisons as such. We can either make sure
> match_hostname() receives a lowercased string indeed or perform the
> lowercasing there (carefully as not to introduce side effects).
> 
> One question is, whether *any* hostname matching should be case
> insensitive or whether originalhost is better left alone (I can think of reasons
> for case sensitive matching there, yet they seem to be bordering on misuse
> of the code).
> 
> I've also opened https://bugzilla.mindrot.org/show_bug.cgi?id=2685
> (patch is attached there as well).

While it might be theoretically a good idea, some security implementations have issues with multiple key pairs specified for a single delegate user (say 'git') on the same host. I'm not saying that this is the correct way to do it, but some ~/.ssh/config files differentiate the same user on the same host with different keys using Abc.domain vs. AbC.domain, allowing multiple key-pair identities. Moving to case-insensitive comparisons inside ~/.ssh/config would break this legacy behaviour for which there does not appear to be good work-arounds in some setups.

Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.




From pcerny at suse.cz  Sat Mar  4 07:15:42 2017
From: pcerny at suse.cz (Petr Cerny)
Date: Fri, 3 Mar 2017 21:15:42 +0100
Subject: case sensitive hostname matching
In-Reply-To: <003401d29434$507c0140$f17403c0$@nexbridge.com>
References: <ac444d9c-4fe8-8248-5301-bb07853e3709@suse.cz>
 <003401d29434$507c0140$f17403c0$@nexbridge.com>
Message-ID: <6050255a-d384-29b6-62bf-09d5bb969a37@suse.cz>

Randall S. Becker wrote:
>> Given that hostnames are ususally interpreted in a case insensitive
>> way (and the code actually expects the input to be lowercased
>> anyway) it might be good to perform the comparisons as such. We can
>> either make sure match_hostname() receives a lowercased string
>> indeed or perform the lowercasing there (carefully as not to
>> introduce side effects).
>>
>> One question is, whether *any* hostname matching should be case
>> insensitive or whether originalhost is better left alone (I can
>> think of reasons for case sensitive matching there, yet they seem
>> to be bordering on misuse of the code).
>>
>> I've also opened https://bugzilla.mindrot.org/show_bug.cgi?id=2685
>> (patch is attached there as well).
>
> While it might be theoretically a good idea, some security
> implementations have issues with multiple key pairs specified for a
> single delegate user (say 'git') on the same host. I'm not saying
> that this is the correct way to do it, but some ~/.ssh/config files
> differentiate the same user on the same host with different keys
> using Abc.domain vs. AbC.domain, allowing multiple key-pair
> identities. Moving to case-insensitive comparisons inside
> ~/.ssh/config would break this legacy behaviour for which there does
> not appear to be good work-arounds in some setups.

Interesting. I suppose this kind of setup uses the `Host` sections - if 
used as `Match originalhost` then the attached patch, which doesn't 
touch original host. Or, possibly better way - make this an option.

Thanks
Kind regards
	Petr

From tseegerkrb at gmail.com  Sat Mar  4 08:17:13 2017
From: tseegerkrb at gmail.com (tseegerkrb)
Date: Fri, 3 Mar 2017 22:17:13 +0100
Subject: Use other default credential cache then FILE
Message-ID: <f45eaa2a-e846-3196-3036-70c19a2bd3b8@gmail.com>

/Hello, i m playing around with MIT kerberos at moment and got the 
problem that openssh do not honor the "default_ccache_name" variable in 
/etc/krb5.conf. It looks like the FILE based credential cache is 
hardcoded and openssh set KRB5CCNAME to it, but i would like to use the 
KEYRING cache. Is there any way to tell ssh to use the cache set in 
"default_ccache_name"? /Many thanks in advance and best regards

- Thorsten -
//


From jjelen at redhat.com  Mon Mar  6 18:41:22 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 6 Mar 2017 08:41:22 +0100
Subject: Use other default credential cache then FILE
In-Reply-To: <f45eaa2a-e846-3196-3036-70c19a2bd3b8@gmail.com>
References: <f45eaa2a-e846-3196-3036-70c19a2bd3b8@gmail.com>
Message-ID: <a77942fe-4876-bd69-b0d1-d6d78f954469@redhat.com>

On 03/03/2017 10:17 PM, tseegerkrb wrote:
> /Hello, i m playing around with MIT kerberos at moment and got the
> problem that openssh do not honor the "default_ccache_name" variable in
> /etc/krb5.conf. It looks like the FILE based credential cache is
> hardcoded and openssh set KRB5CCNAME to it, but i would like to use the
> KEYRING cache. Is there any way to tell ssh to use the cache set in
> "default_ccache_name"? /Many thanks in advance and best regards

Hello,
in Fedora and RHEL we have a patch that takes care of this:

http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-6.3p1-krb5-use-default_ccache_name.patch

I am not sure why it was not driven upstream yet, but in any case if 
that would solve your case, feel free to use it, if it would be 
acceptable upstream, feel free to merge it.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From tseegerkrb at gmail.com  Wed Mar  8 02:42:12 2017
From: tseegerkrb at gmail.com (tseegerkrb)
Date: Tue, 7 Mar 2017 16:42:12 +0100
Subject: Use other default credential cache then FILE
In-Reply-To: <a77942fe-4876-bd69-b0d1-d6d78f954469@redhat.com>
References: <f45eaa2a-e846-3196-3036-70c19a2bd3b8@gmail.com>
 <a77942fe-4876-bd69-b0d1-d6d78f954469@redhat.com>
Message-ID: <b05b8ac6-0f47-86a2-97c7-08f6d40859e3@gmail.com>

On 06.03.2017 08:41, Jakub Jelen wrote:
> On 03/03/2017 10:17 PM, tseegerkrb wrote:
>> /Hello, i m playing around with MIT kerberos at moment and got the
>> problem that openssh do not honor the "default_ccache_name" variable in
>> /etc/krb5.conf. It looks like the FILE based credential cache is
>> hardcoded and openssh set KRB5CCNAME to it, but i would like to use the
>> KEYRING cache. Is there any way to tell ssh to use the cache set in
>> "default_ccache_name"? /Many thanks in advance and best regards
>
> Hello,
> in Fedora and RHEL we have a patch that takes care of this:
>
> http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-6.3p1-krb5-use-default_ccache_name.patch 
>
>
> I am not sure why it was not driven upstream yet, but in any case if 
> that would solve your case, feel free to use it, if it would be 
> acceptable upstream, feel free to merge it.
>
> Regards,

Hello,

thx for your answer. I m using debian / ubuntu and would prefer to get 
the patch in the upstream package.
I m new to this, how and who do i need to ask to add the patch to the 
upstream?

thank you in advance

Best Regards,
Thorsten


From MaritzaStaceyMaSta at gmx.com  Wed Mar  8 02:37:37 2017
From: MaritzaStaceyMaSta at gmx.com (Jessica)
Date: Tue, 7 Mar 2017 16:37:37 +0100
Subject: Alnwick Ghjh ?
Message-ID: <trinity-c59b2986-6893-45fb-8039-c7c358b0a927-1488901057495@3capp-mailcom-bs05>


   Ghjh, Hola, do you live in Alnwick?


From oliver.graute at gmail.com  Wed Mar  8 21:01:12 2017
From: oliver.graute at gmail.com (Oliver Graute)
Date: Wed, 8 Mar 2017 11:01:12 +0100
Subject: Logging with ForceCommand and SCP
Message-ID: <20170308100112.GA5324@graute-opti>

Hello List,

I'am using the ForceCommand in my sshd configuration to log all the user
actions on my device.

ForceCommand /usr/bin/log-session.sh

The Log Session Script itself is working fine for logging.

But now I want also use SCP to copy files and this won't work together
with the ForceCommand above.

The copied file is created but its zero byte on the target.

scp file.tar.gz  ssh-user at 192.168.1.229:/home/ssh-user/
Enter passphrase for key '/home/user/.ssh/id_ecdsa':
C0664 28508 file.tar.gz

-rw-r--r--    1 ssh-user ssh-user         0 Mar  8 10:52 file.tar.gz

Some ideas whats the reason for this behavior?

Best regards,

Oliver


#!/bin/sh
#
# log-session
# John Simpson <jms1 at jms1.net> 2008-08-06
#
###############################################################################
#
# Copyright (C) 2008 John Simpson.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License, version 3, as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
###############################################################################
#
# configuration

# copy this value from the "Subsystem sftp" line in your sshd_config file
SFTP_SERVER=/usr/lib/openssh/sftp-server

###############################################################################
###############################################################################
###############################################################################

value=`cat /data/etc/ssh/umask.cfg`
umask "$value"

NOW=`date +%Y-%m-%d.%H%M%S`
IP=`echo $SSH_CLIENT | sed 's/ .*//'`
LOGFILE=/data/var/sshlog/sshlog.$NOW.$IP

# if you want to log the initial contents of the environment received from
# sshd, un-comment these lines.
#
# env | sort >> $LOGFILE
# echo "========================================" >> $LOGFILE

# the "internal-sftp" service is new as of openssh 5.0. it works like
# the sftp server logic is built into sshd, and as such it's capable of
# chroot'ing users into their home directories.
# there's no way to "redirect" execution back into it, so the best we
# can do is exec the old sftp-server instead, which will give the user a
# working sftp session, but won't chroot them into their home directory.

if [ "${SSH_ORIGINAL_COMMAND:-}" = "internal-sftp" ]
then
	echo "substituting $SFTP_SERVER for internal SFTP service" >> $LOGFILE
	echo "========================================" >> $LOGFILE
	exec $SFTP_SERVER

# if they're requesting the sftp server, this is an sftp command.
# logging the traffic wouldn't make much sense, it's a binary protocol...
# although if you really want to log the raw data, comment out this block
# and let execution fall through to the next block.

elif [ "${SSH_ORIGINAL_COMMAND:-}" = "$SFTP_SERVER" ]
then
	echo starting SFTP service >> $LOGFILE
	echo ======================================== >> $LOGFILE
	exec $SFTP_SERVER

# if the user asked for a specific command, run that command
# but log the traffic going into and out of it.

elif [ -n "${SSH_ORIGINAL_COMMAND:-}" ]
then
	echo executing $SSH_ORIGINAL_COMMAND >> $LOGFILE
	echo ======================================== >> $LOGFILE
	exec script -a -f -q -c "$SSH_ORIGINAL_COMMAND" $LOGFILE

# no command was requested, user wants an interactive shell.
# of course, log the traffic going in and out of it.

else
	echo starting interactive shell session >> $LOGFILE
	echo ======================================== >> $LOGFILE
	exec script -a -f -q $LOGFILE
fi

# if we get to this point, an "exec" failed somewhere.

echo exec failed, rv=$?
exit 1

From yaneurabeya at gmail.com  Thu Mar  9 08:28:15 2017
From: yaneurabeya at gmail.com (Ngie Cooper (yaneurabeya))
Date: Wed, 8 Mar 2017 13:28:15 -0800
Subject: FreeBSD Coverity scan issues in OpenSSH -> how to contribute back
 patches?
References: <C61DDAD9-2426-45CB-A6AA-1A68860CEE6C@gmail.com>
Message-ID: <7156CCD8-79AE-4600-BF08-FFC1E05C1856@gmail.com>

Hi,
	FreeBSD runs a Coverity static analysis scan on a weekly basis to determine whether or not there are issues within the software that we ship with FreeBSD. After the latest upgrade (to 7.4p1) I noticed that there are some new issues in SSH.
	We (FreeBSD) have some local modifications to OpenSSH that are maintained for features or behavior (I believe), so I?ll need to go through our patchset and determine whether or not the issues are in our modifications or in the upstream code.
	That being said, I was wondering how you prefer for patches to be submitted back upstream, in particular, is there a process that I should follow for signing off on patches, contributing, etc?
Thank you for your time,
-Ngie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170308/6ae94ac2/attachment.bin>

From dtucker at zip.com.au  Thu Mar  9 10:23:01 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 9 Mar 2017 10:23:01 +1100
Subject: FreeBSD Coverity scan issues in OpenSSH -> how to contribute back
 patches?
In-Reply-To: <7156CCD8-79AE-4600-BF08-FFC1E05C1856@gmail.com>
References: <C61DDAD9-2426-45CB-A6AA-1A68860CEE6C@gmail.com>
 <7156CCD8-79AE-4600-BF08-FFC1E05C1856@gmail.com>
Message-ID: <CALDDTe2-bCq=MRy708zaJV4R5xQ36c9v2gSFYwzy3bVXk_dYrw@mail.gmail.com>

On Thu, Mar 9, 2017 at 8:28 AM, Ngie Cooper (yaneurabeya)
<yaneurabeya at gmail.com> wrote:
> That being said, I was wondering how you prefer for patches to be submitted back
> upstream, in particular, is there a process that I should follow for signing off on patches, contributing, etc?

Trivial patches can be sent to this list (be aware that non-text
attachments will be dropped), for non trivial patches
https://bugzilla.mindrot.org/ is preferred.

Thanks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From yaneurabeya at gmail.com  Thu Mar  9 10:24:21 2017
From: yaneurabeya at gmail.com (Ngie Cooper (yaneurabeya))
Date: Wed, 8 Mar 2017 15:24:21 -0800
Subject: FreeBSD Coverity scan issues in OpenSSH -> how to contribute back
 patches?
In-Reply-To: <CALDDTe2-bCq=MRy708zaJV4R5xQ36c9v2gSFYwzy3bVXk_dYrw@mail.gmail.com>
References: <C61DDAD9-2426-45CB-A6AA-1A68860CEE6C@gmail.com>
 <7156CCD8-79AE-4600-BF08-FFC1E05C1856@gmail.com>
 <CALDDTe2-bCq=MRy708zaJV4R5xQ36c9v2gSFYwzy3bVXk_dYrw@mail.gmail.com>
Message-ID: <7A08D8C9-3A90-4048-86B9-41A7D2B48028@gmail.com>


> On Mar 8, 2017, at 15:23, Darren Tucker <dtucker at zip.com.au> wrote:
> 
> On Thu, Mar 9, 2017 at 8:28 AM, Ngie Cooper (yaneurabeya)
> <yaneurabeya at gmail.com> wrote:
>> That being said, I was wondering how you prefer for patches to be submitted back
>> upstream, in particular, is there a process that I should follow for signing off on patches, contributing, etc?
> 
> Trivial patches can be sent to this list (be aware that non-text
> attachments will be dropped), for non trivial patches
> https://bugzilla.mindrot.org/ is preferred.

Hi Darren,
	Perfect! Thanks so for the info :).
All the best,
-Ngie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170308/9ae8d905/attachment.bin>

From Zube at stat.colostate.edu  Thu Mar  9 13:58:08 2017
From: Zube at stat.colostate.edu (Zube)
Date: Wed, 8 Mar 2017 19:58:08 -0700
Subject: sshd 7.4p1 with ssl 1.0.2j seg faults, MacOSX 10.12.2/3,
 clang-800.0.42.1 (workaround)
Message-ID: <20170309025808.GA82513@quantum.stat.colostate.edu>

Just a follow-up from January:  after updating to the latest Xcode,
latest openssl and the latest openssh SNAP, ssh would build as before,
but still would not run and this still appeared in the logs:

assertion failed 16C67:  libsystem_trace.dynlib+76912
[5BD4ECD4-75CA-38EA-AF5C-B481C15955F8]: 0x0

I gave up, built gcc 6.3 and used that to compile.  Everything was
peachy as long as the OSX system files were there.  They come with
the command line tools, which can be installed with:

xcode-select --install

Cheers,
Zube

From pengyu.ut at gmail.com  Mon Mar 13 03:18:43 2017
From: pengyu.ut at gmail.com (Peng Yu)
Date: Sun, 12 Mar 2017 11:18:43 -0500
Subject: Why windows from 2nd server can not be shown when an intermediate ssh
 server is used?
Message-ID: <CABrM6wkcK7QMMWhbkKTvq2wfMQpyeXMJaYjKN=sXp4-ztj0XVw@mail.gmail.com>

Hi,

Suppose I have three linux servers A, B and C.

On A, I run `ssh -Y B` to login to B (programs using windows on B can
be shown on A). Then, I login to C from B using the command `ssh -Y
C`. But, programs in can not show windows on A.

Does anybody know how to let A show windows from C? Thanks.

-- 
Regards,
Peng

From tom at quarendon.net  Mon Mar 13 06:35:16 2017
From: tom at quarendon.net (tom at quarendon.net)
Date: Sun, 12 Mar 2017 19:35:16 +0000 (GMT)
Subject: SSH Window flow control operation in OpenSSH.
Message-ID: <1719791903.7834.1489347320510@webmail.123-reg.co.uk>

Apologies if this is not an appropriate question for this list, but I'm hoping to find some experts who might be able to give me a general answer to how this operates in openSSH (or SSH daemons generally).

I'm fairly familiar with the SSH connection protocol spec and the concept of the window and the SSH_MSG_CHANNEL_WINDOW_ADJUST message in order to implement channel flow control.

What I can't figure out, and I haven't really been able to glean from the OpenSSH source so far is how one (openSSH) actually makes use of this.

So client has an exec channel (similar for a tcpip channel). Lets say that the client is able to send data much faster than the program at the other end (or socket peer in the case of a tcpip channel) will read it from its stdin stream. The window mechanism exists to ensure that it is the ssh client channel that blocks and backs up, protecting the SSH daemon (the SSH daemon discarding data that is sent out of the window by a rogue client attempting to crash the daemon), and allowing other channels from the same client to continue operating.
The bit I can't get clear in my mind is how the SSH daemon actually manages sending the SSH_MSG_CHANNEL_WINDOW_ADJUST message to the client. I mean what you really want to know is how much of the data the program has actually read from its buffers -- the window you are really trying to describe is that pipe between the SSH daemon and the program itself. But the SSH daemon clearly (?) can't know that. 

Presumably all it can do is ensure that the file descriptors it is writing to are in non blocking mode and then notice the "EAGAIN" or "EWOULDBLOCK" and know what it has got some data left that it can't deliver immediately, and put a brake on the client by sending it a suitable SSH_MSG_CHANNEL_WINDOW_ADJUST. It then adds that data and file descriptor to a list that it retries periodically until it is successful and then releases the client with another WINDOW_ADJUST message?
Each channel can potentially end up in this state, but you are limited by the number of channels, so you will have one outstanding message per channel that you are waiting to try and deliver, and the buffer will be at most the packet size, so there doesn't seem to be any danger to the daemon in doing this, running out of memory, etc.

Is that the basic mechanism by which openSSH works in this regard?

Again, apologies if this is not an appropriate question for this list. 

Thanks.

From dtucker at zip.com.au  Mon Mar 13 11:19:09 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 13 Mar 2017 11:19:09 +1100
Subject: Why windows from 2nd server can not be shown when an intermediate
 ssh server is used?
In-Reply-To: <CABrM6wkcK7QMMWhbkKTvq2wfMQpyeXMJaYjKN=sXp4-ztj0XVw@mail.gmail.com>
References: <CABrM6wkcK7QMMWhbkKTvq2wfMQpyeXMJaYjKN=sXp4-ztj0XVw@mail.gmail.com>
Message-ID: <CALDDTe0Zbm4QVpf+tigpOgTPA6UQB-SZkZEy7-yEZ_bqfbvZTg@mail.gmail.com>

On Mon, Mar 13, 2017 at 3:18 AM, Peng Yu <pengyu.ut at gmail.com> wrote:
> Suppose I have three linux servers A, B and C.
>
> On A, I run `ssh -Y B` to login to B (programs using windows on B can
> be shown on A). Then, I login to C from B using the command `ssh -Y
> C`. But, programs in can not show windows on A.
>
> Does anybody know how to let A show windows from C? Thanks.

My guess is that C either has X11Forwarding disabled in its
sshd_config or it does not have the xauth binary (or it's not where
sshd expects and XAuthLocation is not set).

If those are not the case please post a debug log from the client on B
(ie ssh -Y into B then ssh -vvv C".

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From rslovers at yandex.com  Tue Mar 14 07:50:08 2017
From: rslovers at yandex.com (Xu Pu Ti)
Date: Mon, 13 Mar 2017 23:50:08 +0300
Subject: What's the point of using xauth when using X11 forwarding?
Message-ID: <20170313235008.o7EWomQp@smtp2j.mail.yandex.net>

I still don't understand the point of authenticating myself to my own local
X server when using X11 forwarding, I tried:

  ssh -R /tmp/.X11-unix/X0:/tmp/.X11-unix/X0 user at server
  # and then
  DISPLAY=:0 xterm

and everything is working fine without the mess with xauth, so why it is
required to use use xauth when doing X11 forwarding with ssh?

From dtucker at zip.com.au  Tue Mar 14 09:53:43 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 14 Mar 2017 09:53:43 +1100
Subject: What's the point of using xauth when using X11 forwarding?
In-Reply-To: <20170313235008.o7EWomQp@smtp2j.mail.yandex.net>
References: <20170313235008.o7EWomQp@smtp2j.mail.yandex.net>
Message-ID: <CALDDTe1cU4M1qmjZnTsKoTNGLR6fYxnfkG7yovt5K7zEz6_SPA@mail.gmail.com>

On Tue, Mar 14, 2017 at 7:50 AM, Xu Pu Ti <rslovers at yandex.com> wrote:
> I still don't understand the point of authenticating myself to my own local
> X server when using X11 forwarding,

X11Forwarding uses TCP, and xauth is what stops anyone else on the
server (or any machine, if X11UseLocalhost=no) from snooping on your
display and keyboard, injecting keystrokes and any of the the other
things you can do with an X server.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From djm at mindrot.org  Tue Mar 14 12:49:48 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 14 Mar 2017 12:49:48 +1100 (AEDT)
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <ab1b2c3c-965a-ac0d-afd2-089dbeed3e66@linux.vnet.ibm.com>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
 <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>
 <ab1b2c3c-965a-ac0d-afd2-089dbeed3e66@linux.vnet.ibm.com>
Message-ID: <alpine.BSO.2.20.1703141248370.220@natsu.mindrot.org>

On Fri, 3 Mar 2017, Eduardo Barretto wrote:

> Just adding some more information on Petr answer (Thanks Petr for
> stepping in!):
> 
> The ioctls for the s390 crypto card support are documented. The crypto
> device driver is part of the linux kernel and thus open source. It can be
> found in the kernel in drivers/s390/crypto. The ioctl stuff required to
> interact with the crypto device driver is as usual provided in the
> kernel header file arch/s390/include/uapi/asm/zcrypt.h
> In particular the defines for the ioctl magics intended to not
> get filtered can be found there.

ok, with the fixes for the seccomp-bpf sandbox that I just committed
the diff reduces to.

IMO this is scoped narrowly enough to go in.

-d

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index af5525ab..6ceee33f 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -223,6 +223,12 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_socketcall
 	SC_ALLOW_ARG(socketcall, 0, SYS_SHUTDOWN),
 #endif
+#if defined(__NR_ioctl) && defined(__s390__)
+	/* Allow ioctls for ICA crypto card on s390 */
+	SC_ALLOW_ARG(ioctl, 1, Z90STAT_STATUS_MASK),
+	SC_ALLOW_ARG(ioctl, 1, ICARSAMODEXPO),
+	SC_ALLOW_ARG(ioctl, 1, ICARSACRT),
+#endif /* defined(__NR_ioctl) && defined(__s390__) */
 
 	/* Default deny */
 	BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),

From djm at mindrot.org  Tue Mar 14 13:17:26 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 14 Mar 2017 13:17:26 +1100 (AEDT)
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <alpine.BSO.2.20.1703141248370.220@natsu.mindrot.org>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
 <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>
 <ab1b2c3c-965a-ac0d-afd2-089dbeed3e66@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703141248370.220@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.20.1703141316250.220@natsu.mindrot.org>

I've committed this diff. Please test and confirm that it works ok.
(If not, then I've botched the macro fixes in the previous commit)

Thanks,
Damien Miller

On Tue, 14 Mar 2017, Damien Miller wrote:

> ok, with the fixes for the seccomp-bpf sandbox that I just committed
> the diff reduces to.
> 
> IMO this is scoped narrowly enough to go in.
> 
> -d
> 
> diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
> index af5525ab..6ceee33f 100644
> --- a/sandbox-seccomp-filter.c
> +++ b/sandbox-seccomp-filter.c
> @@ -223,6 +223,12 @@ static const struct sock_filter preauth_insns[] = {
>  #ifdef __NR_socketcall
>  	SC_ALLOW_ARG(socketcall, 0, SYS_SHUTDOWN),
>  #endif
> +#if defined(__NR_ioctl) && defined(__s390__)
> +	/* Allow ioctls for ICA crypto card on s390 */
> +	SC_ALLOW_ARG(ioctl, 1, Z90STAT_STATUS_MASK),
> +	SC_ALLOW_ARG(ioctl, 1, ICARSAMODEXPO),
> +	SC_ALLOW_ARG(ioctl, 1, ICARSACRT),
> +#endif /* defined(__NR_ioctl) && defined(__s390__) */
>  
>  	/* Default deny */
>  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From rslovers at yandex.com  Tue Mar 14 18:22:46 2017
From: rslovers at yandex.com (Xu Pu Ti)
Date: Tue, 14 Mar 2017 10:22:46 +0300
Subject: What's the point of using xauth when using X11 forwarding?
In-Reply-To: <CALDDTe1cU4M1qmjZnTsKoTNGLR6fYxnfkG7yovt5K7zEz6_SPA@mail.gmail.com>
Message-ID: <20170314102246.MjDKwv8Q@smtp2h.mail.yandex.net>

Thanks, now I understand the problem. I rarely encounter the situation where
multiple people need to login to the same machine, and when I do they're usually
separated by different network namespaces, so I didn't think of that at first.

From guettliml at thomas-guettler.de  Tue Mar 14 20:02:33 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Tue, 14 Mar 2017 10:02:33 +0100
Subject: Relaiable ssh tunnel via systemd
Message-ID: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>

We try to run a reliable ssh tunnel vis systemd.

This is the unit configuration file:

{{{
[Unit]
Description=Tunnel For %i
After=network.target

[Service]
User=autossh
ExecStart=/usr/bin/ssh -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 60" -N -R 40443:installserver:40443 -R 
8080:installserver:8080
ExecStartPre=-/usr/bin/ssh tunnel@%i "for pid in  $$(ps -u tunnel | grep sshd| cut -d' ' -f1); do kill -9 $$pid; echo 
kill old ssh process p
Restart=always
RestartSec=5s
StartLimitInterval=0

[Install]
WantedBy=multi-user.target
}}}

Unfortunately on some hosts we see this warning again and again:

Mar 13 23:11:14 remotehost sshd[10938]: error: bind: Address already in use
Mar 13 23:11:14 remotehost sshd[10938]: error: channel_setup_fwd_listener: cannot listen to port: 40443
Mar 13 23:11:14 remotehost sshd[10938]: error: bind: Address already in use
Mar 13 23:11:14 remotehost sshd[10938]: error: channel_setup_fwd_listener: cannot listen to port: 8080

Since we kill the old tunnel before starting a new, I don't understand why this error message occurs.

Any hints?

-- 
Thomas Guettler http://www.thomas-guettler.de/

From djm at mindrot.org  Tue Mar 14 21:40:35 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 14 Mar 2017 21:40:35 +1100 (AEDT)
Subject: Call for testing: OpenSSH 7.5p1
Message-ID: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>

Hi,

OpenSSH 7.5p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a bugfix release.

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 git using the
instructions at http://www.openssh.com/portable.html#cvs
At https://anongit.mindrot.org/openssh.git/ or via a mirror at Github:
https://github.com/openssh/openssh-portable

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.

Future deprecation notice
=========================

We plan on retiring more legacy cryptography in future releases,
specifically:

 * In the next major release (expected June-August), removing remaining
   support for the SSH v.1 protocol (currently client-only and compile-
   time disabled).

 * In the same release, removing support for Blowfish and RC4 ciphers
   and the RIPE-MD160 HMAC. (These are currently run-time disabled).

 * In the same release, removing the remaining CBC ciphers from being
   offered by default in the client (These have not been offered in
   sshd by default for several years).

 * Refusing all RSA keys smaller than 1024 bits (the current minimum
   is 768 bits)

This list reflects our current intentions, but please check the final
release notes for future releases.

Potentially-incompatible changes
================================

This release includes a number of changes that may affect existing
configurations:

 * This release deprecates the sshd_config UsePrivilegeSeparation
   option, thereby making privilege separation mandatory. Privilege
   separation has been on by default for almost 15 years.

 * The format of several log messages emitted by the packet code has
   changed to include additional information about the user and
   their authentication state. Software that monitors ssh/sshd logs
   may need to account for these changes. For example:

   Connection closed by user x 1.1.1.1 port 1234 [preauth]
   Connection closed by authenticating user x 10.1.1.1 port 1234 [preauth]
   Connection closed by invalid user x 1.1.1.1 port 1234 [preauth]

   Affected messages include connection closure, timeout, remote
   disconnection, negotiation failure and some other fatal messages
   generated by the packet code.

Changes since OpenSSH 7.4
=========================

This is a bugfix release.

New Features
------------

 * ssh(1), sshd(8): Support "=-" syntax to easily remove methods from
   algorithm lists, e.g. Ciphers=-*cbc. bz#2671

Bugfixes
--------

 * ssh(1), sshd(8): Allow form-feed characters to appear in
   configuration files.
 
 * sshd(8): Fix regression in OpenSSH 7.4 support for the
   server-sig-algs extension, where SHA2 RSA signature methods were
   not being correctly advertised. bz#2680

 * ssh(1), ssh-keygen(1): Fix a number of case-sensitivity bugs in
   known_hosts processing. bz#2591 bz#2685

 * ssh(1): Allow ssh to use certificates accompanied by a private key
   file but no corresponding plain *.pub public key. bz#2617

 * ssh(1): When updating hostkeys using the UpdateHostKeys option,
   accept RSA keys if HostkeyAlgorithms contains any RSA keytype.
   Previously, ssh could ignore RSA keys when only the ssh-rsa-sha2-*
   methods were enabled in HostkeyAlgorithms and not the old ssh-rsa
   method. bz#2650
    
 * ssh(1): Detect and report excessively long configuration file
   lines. bz#2651

 * Merge a number of fixes found by Coverity and reported via Redhat
   and FreeBSD. Includes fixes for some memory and file descriptor
   leaks in error paths. bz#2687
    
 * ssh-keyscan(1): Correctly hash hosts with a port number. bz#2692

 * ssh(1), sshd(8): When logging long messages to stderr, don't truncate
   "\r\n" if the length of the message exceeds the buffer. bz#2688

 * ssh(1): Fully quote [host]:port in generated ProxyJump/-J command-
   line; avoid confusion over IPv6 addresses and shells that treat
   square bracket characters specially.
    
 * ssh-keygen(1): Fix corruption of known_hosts when running
   "ssh-keygen -H" on a known_hosts containing already-hashed entries.

 * Fix various fallout and sharp edges caused by removing SSH protocol
   1 support from the server, including the server banner string being
   incorrectly terminated with only \n (instead of \r\n), and
   confusing error messages from ssh-keyscan bz#2583.

 * ssh(1), sshd(8): Free fd_set on connection timeout. bz#2683

 * sshd(8): Fix Unix domain socket forwarding for root (regression in
   OpenSSH 7.4).
    
 * sftp(1): Fix division by zero crash in "df" output when server
   returns zero total filesystem blocks/inodes.
 
 * ssh(1), ssh-add(1), ssh-keygen(1), sshd(8): Translate OpenSSL errors
   encountered during key loading to more meaningful error codes.
   bz#2522 bz#2523

 * ssh-keygen(1): Sanitise escape sequences in key comments sent to
   printf but preserve valid UTF-8 when the locale supports it;
   bz#2520

 * ssh(1), sshd(8): Return reason for port forwarding failures where
   feasible rather than always "administratively prohibited". bz#2674

 * sshd(8): Fix deadlock when AuthorizedKeysCommand or
   AuthorizedPrincipalsCommand produces a lot of output and a key is
   matched early. bz#2655

 * Regression tests: several reliability fixes. bz#2654 bz#2658 bz#2659
    
 * ssh(1): Fix typo in ~C error message for bad port forward
   cancellation. bz#2672

 * ssh(1): Show a useful error message when included config files
   can't be opened; bz#2653

 * sshd(8): Make sshd set GSSAPIStrictAcceptorCheck=yes as the manual page
   (previously incorrectly) advertised. bz#2637

 * sshd_config(5): Repair accidentally-deleted mention of %k token
   in AuthorizedKeysCommand; bz#2656

 * sshd(8): Remove vestiges of previously removed LOGIN_PROGRAM; bzbz#2665

 * ssh-agent(1): Relax PKCS#11 whitelist to include libexec and
   common 32-bit compatibility library directories.

 * sftp-client(1): fix non-exploitable integer overflow in SSH2_FXP_NAME
   response handling.

Portability
-----------

 * sshd(8): Avoid sandbox errors for Linux S390 systems using an ICA
   crypto coprocessor.

 * sshd(8): Fix non-exploitable weakness in seccomp-bpf sandbox arg
   inspection.

 * ssh(1): Fix X11 forwarding on OSX where X11 was being started by
   launchd. bz#2341

 * ssh-keygen(1), ssh(1), sftp(1): Fix output truncation for various that
   contain non-printable characters where the codeset in use is ASCII.

 * build: Fix builds that attempt to link a kerberised libldns. bz#2603

 * build: Fix compilation problems caused by unconditionally defining
   _XOPEN_SOURCE in wide character detection.

 * sshd(8): Fix sandbox violations for clock_gettime VSDO syscall
   fallback on some Linux/X32 kernels. bz#2142

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


From jjelen at redhat.com  Tue Mar 14 22:45:55 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 14 Mar 2017 12:45:55 +0100
Subject: Call for testing: OpenSSH 7.5p1
In-Reply-To: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
References: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
Message-ID: <081aef2c-d8ca-d5e5-be71-b3333da649ab@redhat.com>

On 03/14/2017 11:40 AM, Damien Miller wrote:
> Hi,
>
> OpenSSH 7.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
>
> [...]
>
> This release includes a number of changes that may affect existing
> configurations:
>
>  * This release deprecates the sshd_config UsePrivilegeSeparation
>    option, thereby making privilege separation mandatory. Privilege
>    separation has been on by default for almost 15 years.

Hello,
I don't see this option deprecated in current portable master. Still in 
place. How are we going to be able to switch between Sandbox and just 
privilege separation?

As far as I remember, various people still use this use case to test 
other SSH implementation (privsep requires running a root, isn't it?).

>  * Fix various fallout and sharp edges caused by removing SSH protocol
>    1 support from the server, including the server banner string being
>    incorrectly terminated with only \n (instead of \r\n), and
>    confusing error messages from ssh-keyscan bz#2583.

I would vouch for this bug get fixed too in the relation to the SSH1 
removal:

https://bugzilla.mindrot.org/show_bug.cgi?id=2686

Also this one is a bit confusing:

https://bugzilla.mindrot.org/show_bug.cgi?id=2682

I took the package through the basic sanity testing and so far all tests 
passed.

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: typo.patch
Type: text/x-patch
Size: 663 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170314/af21333b/attachment.bin>

From nkadel at gmail.com  Wed Mar 15 01:10:11 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Tue, 14 Mar 2017 10:10:11 -0400
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
Message-ID: <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>

Look into the "autossh" program, which is very good to manage and
maintain such tunnels.

On Tue, Mar 14, 2017 at 5:02 AM, Thomas G?ttler
<guettliml at thomas-guettler.de> wrote:
> We try to run a reliable ssh tunnel vis systemd.
>
> This is the unit configuration file:
>
> {{{
> [Unit]
> Description=Tunnel For %i
> After=network.target
>
> [Service]
> User=autossh
> ExecStart=/usr/bin/ssh -o "ExitOnForwardFailure yes" -o "ServerAliveInterval
> 60" -N -R 40443:installserver:40443 -R 8080:installserver:8080
> ExecStartPre=-/usr/bin/ssh tunnel@%i "for pid in  $$(ps -u tunnel | grep
> sshd| cut -d' ' -f1); do kill -9 $$pid; echo kill old ssh process p
> Restart=always
> RestartSec=5s
> StartLimitInterval=0
>
> [Install]
> WantedBy=multi-user.target
> }}}
>
> Unfortunately on some hosts we see this warning again and again:
>
> Mar 13 23:11:14 remotehost sshd[10938]: error: bind: Address already in use
> Mar 13 23:11:14 remotehost sshd[10938]: error: channel_setup_fwd_listener:
> cannot listen to port: 40443
> Mar 13 23:11:14 remotehost sshd[10938]: error: bind: Address already in use
> Mar 13 23:11:14 remotehost sshd[10938]: error: channel_setup_fwd_listener:
> cannot listen to port: 8080
>
> Since we kill the old tunnel before starting a new, I don't understand why
> this error message occurs.
>
> Any hints?
>
> --
> Thomas Guettler http://www.thomas-guettler.de/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From guettliml at thomas-guettler.de  Wed Mar 15 07:20:34 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Tue, 14 Mar 2017 21:20:34 +0100
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
Message-ID: <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>




Am 14.03.2017 um 15:10 schrieb Nico Kadel-Garcia:
> Look into the "autossh" program, which is very good to manage and
> maintain such tunnels.
> 

Hi Nico and other ssh users,

Systemd restarts the ssh if it terminates. AFAIK this is all that is needed.

But maybe I am missing something. Is there a feature of autossh that I don't
get with systemd?


-- 
http://www.thomas-guettler.de/

From nkadel at gmail.com  Wed Mar 15 07:43:58 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Tue, 14 Mar 2017 16:43:58 -0400
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
Message-ID: <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>

On Tue, Mar 14, 2017 at 4:20 PM, Thomas G?ttler
<guettliml at thomas-guettler.de> wrote:
>
>
>
> Am 14.03.2017 um 15:10 schrieb Nico Kadel-Garcia:
>> Look into the "autossh" program, which is very good to manage and
>> maintain such tunnels.
>>
>
> Hi Nico and other ssh users,
>
> Systemd restarts the ssh if it terminates. AFAIK this is all that is needed.
>
> But maybe I am missing something. Is there a feature of autossh that I don't
> get with systemd?

Better logging, especially error reporting, and much more modular
configuration for multiple parallel autossh daemons without having to
hand edit and customize systemd init scripts. I've had some success
with using chef to manage it, along with deploying SSH configurations
to avoid the "known_hosts" mismatched hostkey issues as target hosts
change IP address, and to get management of the relevant public and
private SSH keys for the port forwarding.

From djm at mindrot.org  Wed Mar 15 11:47:20 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 15 Mar 2017 11:47:20 +1100 (AEDT)
Subject: Call for testing: OpenSSH 7.5p1
In-Reply-To: <081aef2c-d8ca-d5e5-be71-b3333da649ab@redhat.com>
References: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
 <081aef2c-d8ca-d5e5-be71-b3333da649ab@redhat.com>
Message-ID: <alpine.BSO.2.20.1703151117140.26367@natsu.mindrot.org>

On Tue, 14 Mar 2017, Jakub Jelen wrote:

> Hello,
> I don't see this option deprecated in current portable master. Still in place.
> How are we going to be able to switch between Sandbox and just privilege
> separation?

We might consider some way of disabling sandboxing (apart from editing
the source) if there is user demand, but I think developers/packagers
can figure out sandbox violations pretty easily from dmesg, etc.

> As far as I remember, various people still use this use case to test
> other SSH implementation (privsep requires running a root, isn't it?).

No, only setuid to an unprivileged user needs that; the rest of privsep
including sandboxing is still active if sshd is run as a regular user.

> >  * Fix various fallout and sharp edges caused by removing SSH protocol
> >    1 support from the server, including the server banner string being
> >    incorrectly terminated with only \n (instead of \r\n), and
> >    confusing error messages from ssh-keyscan bz#2583.
> 
> I would vouch for this bug get fixed too in the relation to the SSH1 removal:
> 
> https://bugzilla.mindrot.org/show_bug.cgi?id=2686
> 
> Also this one is a bit confusing:
> 
> https://bugzilla.mindrot.org/show_bug.cgi?id=2682

Will take a look.

-d

From Philipp.Neuser at fu-berlin.de  Wed Mar 15 07:45:18 2017
From: Philipp.Neuser at fu-berlin.de (Neuser, Philipp)
Date: Tue, 14 Mar 2017 21:45:18 +0100
Subject: ssh-client should always revoke ssh-dss keys not only when coming
 from the agent
Message-ID: <739456C1FBF32A4BB46413BA27991CA281C366E5@ex03a.campus.fu-berlin.de>

Hi!

when calling ssh-add on a dsa key i'm asked for passphrase and the key is perfectly accepted and listed by ssh-agent. A dsa key is also used by ssh-client when found in home directory and passphrase entered is correct. But a dsa key offered to ssh-client by ssh-agent is skipped as long as ssh-dss is not listed in PubkeyAcceptedKeyTypes.

debug1: Skipping ssh-dss key /home/XXXX/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/XXXX/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: Trying private key: /home/XXX/.ssh/id_dsa
Enter passphrase for key '/home/XXX/.ssh/id_dsa':
debug1: Authentication succeeded (publickey).

This results in a strange behavior to users.  You are asked for your passphrase by agent and again by ssh-client and nobody tells you that you should not use a dsa key anymore.
Shouldn't ssh client also reject dsa keys found in home as long as ssh-dss is not listed in PubkeyAccpetedKeyTypes or reject when trying to add keys to ssh-agent?

Regards,
Philipp Neuser



From guettliml at thomas-guettler.de  Wed Mar 15 20:13:32 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Wed, 15 Mar 2017 10:13:32 +0100
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
 <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>
Message-ID: <9573931f-1e62-6cb3-28c6-143c53bdbf95@thomas-guettler.de>



Am 14.03.2017 um 21:43 schrieb Nico Kadel-Garcia:
> On Tue, Mar 14, 2017 at 4:20 PM, Thomas G?ttler
> <guettliml at thomas-guettler.de> wrote:
>>
>>
>>
>> Am 14.03.2017 um 15:10 schrieb Nico Kadel-Garcia:
>>> Look into the "autossh" program, which is very good to manage and
>>> maintain such tunnels.
>>>
>>
>> Hi Nico and other ssh users,
>>
>> Systemd restarts the ssh if it terminates. AFAIK this is all that is needed.
>>
>> But maybe I am missing something. Is there a feature of autossh that I don't
>> get with systemd?
>
> Better logging, especially error reporting,

I am happy with the messages which gets passed from the ssh process to systemd.
Could you please provide an example, since I fail to see what autossh does better.


> and much more modular
> configuration for multiple parallel autossh daemons without having to
> hand edit and customize systemd init scripts.

We use configuration management to create and update systemd unit configuration files.
I don't see how autossh can help here. Do you have an example?

> I've had some success
> with using chef to manage it, along with deploying SSH configurations
> to avoid the "known_hosts" mismatched hostkey issues as target hosts
> change IP address, and to get management of the relevant public and
> private SSH keys for the port forwarding.

I can't follow. My brain is still focused on the question: Why autossh?

Regards,
   Thomas


-- 
Thomas Guettler http://www.thomas-guettler.de/

From jjelen at redhat.com  Wed Mar 15 20:36:40 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 15 Mar 2017 10:36:40 +0100
Subject: Call for testing: OpenSSH 7.5p1
In-Reply-To: <alpine.BSO.2.20.1703151117140.26367@natsu.mindrot.org>
References: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
 <081aef2c-d8ca-d5e5-be71-b3333da649ab@redhat.com>
 <alpine.BSO.2.20.1703151117140.26367@natsu.mindrot.org>
Message-ID: <a718d67c-d076-3d1a-96ad-0f63e8a7d05b@redhat.com>

On 03/15/2017 01:47 AM, Damien Miller wrote:
> On Tue, 14 Mar 2017, Jakub Jelen wrote:
>
>> Hello,
>> I don't see this option deprecated in current portable master. Still in place.
>> How are we going to be able to switch between Sandbox and just privilege
>> separation?
>
> We might consider some way of disabling sandboxing (apart from editing
> the source) if there is user demand, but I think developers/packagers
> can figure out sandbox violations pretty easily from dmesg, etc.

That would be very desirable.

The sandbox (at least rlimit if I remember well) had a problems with 
running under valgrind.

>> As far as I remember, various people still use this use case to test
>> other SSH implementation (privsep requires running a root, isn't it?).
>
> No, only setuid to an unprivileged user needs that; the rest of privsep
> including sandboxing is still active if sshd is run as a regular user.
>
>>>  * Fix various fallout and sharp edges caused by removing SSH protocol
>>>    1 support from the server, including the server banner string being
>>>    incorrectly terminated with only \n (instead of \r\n), and
>>>    confusing error messages from ssh-keyscan bz#2583.
>>
>> I would vouch for this bug get fixed too in the relation to the SSH1 removal:
>>
>> https://bugzilla.mindrot.org/show_bug.cgi?id=2686
>>
>> Also this one is a bit confusing:
>>
>> https://bugzilla.mindrot.org/show_bug.cgi?id=2682
>
> Will take a look.

Thanks. One more thing that I noticed:

Build against OpenSSL 1.1.0 fails, because there is no 
EVP_R_BN_DECODE_ERROR defined. The last usage was removed >10 years ago 
from OpenSSL sources [1].

I understand that OpenSSL 1.1.0 is not a priority, but I believe it is 
not used in other forks either so compatibility patch (attached) would 
probably make sense.

The other tests passed so I guess we are good to go from our side.

[1] https://github.com/openssl/openssl/commit/448be743


Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-1.1.0.patch
Type: text/x-patch
Size: 441 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170315/faf5d17f/attachment-0001.bin>

From oliver.graute at gmail.com  Wed Mar 15 21:39:13 2017
From: oliver.graute at gmail.com (Oliver Graute)
Date: Wed, 15 Mar 2017 11:39:13 +0100
Subject: Logging with ForceCommand and SCP
In-Reply-To: <20170308100112.GA5324@graute-opti>
References: <20170308100112.GA5324@graute-opti>
Message-ID: <CA+KjHfZ7=VgBp1N44B8GZiJ91XN73O36FgbL=MVw9EAfoLpWSw@mail.gmail.com>

On Wed, Mar 8, 2017 at 11:01 AM, Oliver Graute <oliver.graute at gmail.com> wrote:
> Hello List,
>
> I'am using the ForceCommand in my sshd configuration to log all the user
> actions on my device.
>
> ForceCommand /usr/bin/log-session.sh
>
> The Log Session Script itself is working fine for logging.
>
> But now I want also use SCP to copy files and this won't work together
> with the ForceCommand above.
>
> The copied file is created but its zero byte on the target.
>
> scp file.tar.gz  ssh-user at 192.168.1.229:/home/ssh-user/
> Enter passphrase for key '/home/user/.ssh/id_ecdsa':
> C0664 28508 file.tar.gz
>
> -rw-r--r--    1 ssh-user ssh-user         0 Mar  8 10:52 file.tar.gz
>
> Some ideas whats the reason for this behavior?
>

I solved the scp copy problem by adding this scp case to the
log-session.sh script

# if scp is requested we just forward this command

elif [ "$(echo ${SSH_ORIGINAL_COMMAND} | grep '^scp')" ]
then
        echo starting SCP service >> $LOGFILE
        echo ======================================== >> $LOGFILE
        ${SSH_ORIGINAL_COMMAND}


No the copy of files in both directions is fine. But I observe a
strange protocol error

Enter passphrase for key '/home/graute/.ssh/id_ecdsa':
test.log

                                 100%   39     0.0KB/s   00:00
protocol error: expected control record


Best regards,

Oliver

From dtucker at zip.com.au  Wed Mar 15 22:24:24 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 15 Mar 2017 22:24:24 +1100
Subject: Logging with ForceCommand and SCP
In-Reply-To: <CA+KjHfZ7=VgBp1N44B8GZiJ91XN73O36FgbL=MVw9EAfoLpWSw@mail.gmail.com>
References: <20170308100112.GA5324@graute-opti>
 <CA+KjHfZ7=VgBp1N44B8GZiJ91XN73O36FgbL=MVw9EAfoLpWSw@mail.gmail.com>
Message-ID: <CALDDTe2kphmD1Yi3=quCzjkSsYjhDtrr=594HvBxiTmf+Y0cuw@mail.gmail.com>

On Wed, Mar 15, 2017 at 9:39 PM, Oliver Graute <oliver.graute at gmail.com> wrote:
[...]
> protocol error: expected control record

Most likely your script is producing some output at the end which scp
tries and fails to interpret.

Try exec'ing scp rather than just calling it to make sure your script
doesn't do anything else.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From vinschen at redhat.com  Wed Mar 15 22:32:49 2017
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 15 Mar 2017 12:32:49 +0100
Subject: Call for testing: OpenSSH 7.5p1
In-Reply-To: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
References: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
Message-ID: <20170315113249.GA7062@calimero.vinschen.de>

On Mar 14 21:40, Damien Miller wrote:
> Hi,
> 
> OpenSSH 7.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
> [...]
> Potentially-incompatible changes
> ================================
> 
> This release includes a number of changes that may affect existing
> configurations:
> 
>  * This release deprecates the sshd_config UsePrivilegeSeparation
>    option, thereby making privilege separation mandatory. Privilege
>    separation has been on by default for almost 15 years.

Today's code from the git repo with UsePrivilegeSeparation option
removed tested on Cygwin.  It compiles OOTB and the testsuite runs
successfully.

However, the removal of UsePrivilegeSeparation requires a patch to
Cygwin's ssh-host-config script.  Patch attached.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
From beb8cf663a6a9183c82c7a78c62ee17512e02184 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <vinschen at redhat.com>
Date: Wed, 15 Mar 2017 11:10:23 +0100
Subject: [PATCH] Remove handling of deprecated UsePrivilegeSeparation from
 Cygwin install script

Signed-off-by: Corinna Vinschen <vinschen at redhat.com>
---
 contrib/cygwin/ssh-host-config | 43 +++++++++---------------------------------
 1 file changed, 9 insertions(+), 34 deletions(-)

diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config
index d934d09..db6aaa0 100644
--- a/contrib/cygwin/ssh-host-config
+++ b/contrib/cygwin/ssh-host-config
@@ -63,7 +63,6 @@ sshd_config_configured=no
 port_number=22
 service_name=sshd
 strictmodes=yes
-privsep_used=yes
 cygwin_value=""
 user_account=
 password_value=
@@ -140,33 +139,21 @@ sshd_strictmodes() {
 
 # ======================================================================
 # Routine: sshd_privsep
-#  MODIFIES: privsep_used
+# Try to create ssshd user account
 # ======================================================================
 sshd_privsep() {
   local ret=0
 
   if [ "${sshd_config_configured}" != "yes" ]
   then
-    echo
-    csih_inform "Privilege separation is set to 'sandbox' by default since"
-    csih_inform "OpenSSH 6.1.  This is unsupported by Cygwin and has to be set"
-    csih_inform "to 'yes' or 'no'."
-    csih_inform "However, using privilege separation requires a non-privileged account"
-    csih_inform "called 'sshd'."
-    csih_inform "For more info on privilege separation read /usr/share/doc/openssh/README.privsep."
-    if csih_request "Should privilege separation be used?"
+    if ! csih_create_unprivileged_user sshd
     then
-      privsep_used=yes
-      if ! csih_create_unprivileged_user sshd
-      then
-	csih_error_recoverable "Couldn't create user 'sshd'!"
-	csih_error_recoverable "Privilege separation set to 'no' again!"
-	csih_error_recoverable "Check your ${SYSCONFDIR}/sshd_config file!"
-	let ++ret
-	privsep_used=no
-      fi
-    else
-      privsep_used=no
+      csih_error_recoverable "Could not create user 'sshd'!"
+      csih_error_recoverable "You will not be able to run an sshd service"
+      csih_error_recoverable "under a privileged account successfully."
+      csih_error_recoverable "Make sure to create a non-privileged user 'sshd'"
+      csih_error_recoverable "manually before trying to run the service!"
+      let ++ret
     fi
   fi
   return $ret
@@ -202,18 +189,6 @@ sshd_config_tweak() {
       let ++ret
     fi
   fi
-  if [ "${sshd_config_configured}" != "yes" ]
-  then
-    /usr/bin/sed -i -e "
-      s/^#\?UsePrivilegeSeparation .*/UsePrivilegeSeparation ${privsep_used}/" \
-      ${SYSCONFDIR}/sshd_config
-    if [ $? -ne 0 ]
-    then
-      csih_warning "Setting privilege separation failed!"
-      csih_warning "Check your ${SYSCONFDIR}/sshd_config file!"
-      let ++ret
-    fi
-  fi
   return $ret
 } # --- End of sshd_config_tweak --- #
 
@@ -693,7 +668,7 @@ then
   fi
 fi
 
-# handle sshd_config (and privsep)
+# handle sshd_config
 csih_install_config "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt
 if ! /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1
 then
-- 
2.9.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170315/659745e9/attachment.bin>

From oliver.graute at gmail.com  Wed Mar 15 23:09:29 2017
From: oliver.graute at gmail.com (Oliver Graute)
Date: Wed, 15 Mar 2017 13:09:29 +0100
Subject: Logging with ForceCommand and SCP
In-Reply-To: <CALDDTe2kphmD1Yi3=quCzjkSsYjhDtrr=594HvBxiTmf+Y0cuw@mail.gmail.com>
References: <20170308100112.GA5324@graute-opti>
 <CA+KjHfZ7=VgBp1N44B8GZiJ91XN73O36FgbL=MVw9EAfoLpWSw@mail.gmail.com>
 <CALDDTe2kphmD1Yi3=quCzjkSsYjhDtrr=594HvBxiTmf+Y0cuw@mail.gmail.com>
Message-ID: <CA+KjHfbZhJQC5Vum9QXseo42pS137XJHJW_7L-dGzCWJBi7+FA@mail.gmail.com>

On Wed, Mar 15, 2017 at 12:24 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Wed, Mar 15, 2017 at 9:39 PM, Oliver Graute <oliver.graute at gmail.com> wrote:
> [...]
>> protocol error: expected control record
>
> Most likely your script is producing some output at the end which scp
> tries and fails to interpret.
>
> Try exec'ing scp rather than just calling it to make sure your script
> doesn't do anything else.

you are right

-        ${SSH_ORIGINAL_COMMAND}
+       exec ${SSH_ORIGINAL_COMMAND}

solved the issue. Thx

Oliver

From deengert at gmail.com  Thu Mar 16 00:16:53 2017
From: deengert at gmail.com (Douglas E Engert)
Date: Wed, 15 Mar 2017 08:16:53 -0500
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
Message-ID: <f7aaa264-fabd-3630-db44-6d5b51624fdd@gmail.com>



On 3/14/2017 9:10 AM, Nico Kadel-Garcia wrote:
> Look into the "autossh" program, which is very good to manage and
> maintain such tunnels.
>
> On Tue, Mar 14, 2017 at 5:02 AM, Thomas G?ttler
> <guettliml at thomas-guettler.de> wrote:
>> We try to run a reliable ssh tunnel vis systemd.
>>
>> This is the unit configuration file:
>>
>> {{{
>> [Unit]
>> Description=Tunnel For %i
>> After=network.target
>>
>> [Service]
>> User=autossh
>> ExecStart=/usr/bin/ssh -o "ExitOnForwardFailure yes" -o "ServerAliveInterval
>> 60" -N -R 40443:installserver:40443 -R 8080:installserver:8080
>> ExecStartPre=-/usr/bin/ssh tunnel@%i "for pid in  $$(ps -u tunnel | grep
>> sshd| cut -d' ' -f1); do kill -9 $$pid; echo kill old ssh process p
>> Restart=always
>> RestartSec=5s
>> StartLimitInterval=0
>>
>> [Install]
>> WantedBy=multi-user.target
>> }}}
>>
>> Unfortunately on some hosts we see this warning again and again:
>>
>> Mar 13 23:11:14 remotehost sshd[10938]: error: bind: Address already in use
>> Mar 13 23:11:14 remotehost sshd[10938]: error: channel_setup_fwd_listener:
>> cannot listen to port: 40443
>> Mar 13 23:11:14 remotehost sshd[10938]: error: bind: Address already in use
>> Mar 13 23:11:14 remotehost sshd[10938]: error: channel_setup_fwd_listener:
>> cannot listen to port: 8080
>>
>> Since we kill the old tunnel before starting a new, I don't understand why
>> this error message occurs.
>>
>> Any hints?

I remember from years ago, a problem like this. The TCP bind was not freed up
as quickly as one might expect. "kill -9" could be causing this not giving the
application time to shutdown.

Search for tcp bind address already in use

https://hea-www.harvard.edu/~fine/Tech/addrinuse.html

>>
>> --
>> Thomas Guettler http://www.thomas-guettler.de/
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>


From nkadel at gmail.com  Thu Mar 16 10:48:34 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 15 Mar 2017 19:48:34 -0400
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <9573931f-1e62-6cb3-28c6-143c53bdbf95@thomas-guettler.de>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
 <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>
 <9573931f-1e62-6cb3-28c6-143c53bdbf95@thomas-guettler.de>
Message-ID: <CAOCN9rx0_mYNM6G1942mouOT3ci_-firTAQ02gHLzvMux9k1og@mail.gmail.com>

On Wed, Mar 15, 2017 at 5:13 AM, Thomas G?ttler
<guettliml at thomas-guettler.de> wrote:

>> and much more modular
>> configuration for multiple parallel autossh daemons without having to
>> hand edit and customize systemd init scripts.
>
>
> We use configuration management to create and update systemd unit
> configuration files.
> I don't see how autossh can help here. Do you have an example?

I found the logging in /var/log/autossh{-instancename}, and the
management of multiple autossh configurations, to be much more
manageable and reportable through configuraiton managed
/etc/sysconfig/autossh{-intancename} files than  via the confusing and
Linux-kernel-only logging of systemd. I found authorship and
maintenance of those files, *outside* of the SELinux and default
systemd configurations, to be far more flexible and reliable for my
uses. And even debugging the "ssh client is getting restarted too fast
and port isn't released" was painful when I encountered it in similar
environments.

> I can't follow. My brain is still focused on the question: Why autossh?

You've taken the time to say that you have systemd configured through
a separate management tool. For me, this is one of many instances for
which I find sytemd's centralization and merging of all logging into a
single log repository awkward and unnecessary.

So please allow me to invert the question. What logging benefit or
maintenance benefit are you gaining from inserting autossh instance
specific configurations into systemd init files, and losing the
segregation of autossh logs into individually parseable and reviewable
log files?

From djm at mindrot.org  Thu Mar 16 11:23:58 2017
From: djm at mindrot.org (Damien Miller)
Date: Thu, 16 Mar 2017 11:23:58 +1100 (AEDT)
Subject: Call for testing: OpenSSH 7.5p1
In-Reply-To: <20170315113249.GA7062@calimero.vinschen.de>
References: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
 <20170315113249.GA7062@calimero.vinschen.de>
Message-ID: <alpine.BSO.2.20.1703161123460.89614@natsu.mindrot.org>


On Wed, 15 Mar 2017, Corinna Vinschen wrote:

> Today's code from the git repo with UsePrivilegeSeparation option
> removed tested on Cygwin.  It compiles OOTB and the testsuite runs
> successfully.
> 
> However, the removal of UsePrivilegeSeparation requires a patch to
> Cygwin's ssh-host-config script.  Patch attached.

Applied, thanks.

From guettliml at thomas-guettler.de  Fri Mar 17 01:26:26 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Thu, 16 Mar 2017 15:26:26 +0100
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <CAOCN9rx0_mYNM6G1942mouOT3ci_-firTAQ02gHLzvMux9k1og@mail.gmail.com>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
 <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>
 <9573931f-1e62-6cb3-28c6-143c53bdbf95@thomas-guettler.de>
 <CAOCN9rx0_mYNM6G1942mouOT3ci_-firTAQ02gHLzvMux9k1og@mail.gmail.com>
Message-ID: <d7c2d736-c015-c36f-34a9-29bb4c4d8fc0@thomas-guettler.de>



Am 16.03.2017 um 00:48 schrieb Nico Kadel-Garcia:
> On Wed, Mar 15, 2017 at 5:13 AM, Thomas G?ttler
> <guettliml at thomas-guettler.de> wrote:
>
>>> and much more modular
>>> configuration for multiple parallel autossh daemons without having to
>>> hand edit and customize systemd init scripts.
>>
>>
>> We use configuration management to create and update systemd unit
>> configuration files.
>> I don't see how autossh can help here. Do you have an example?
>
> I found the logging in /var/log/autossh{-instancename}, and the
> management of multiple autossh configurations, to be much more
> manageable and reportable through configuraiton managed
> /etc/sysconfig/autossh{-intancename} files than  via the confusing and
> Linux-kernel-only logging of systemd. I found authorship and
> maintenance of those files, *outside* of the SELinux and default
> systemd configurations, to be far more flexible and reliable for my
> uses. And even debugging the "ssh client is getting restarted too fast
> and port isn't released" was painful when I encountered it in similar
> environments.
>
>> I can't follow. My brain is still focused on the question: Why autossh?
>
> You've taken the time to say that you have systemd configured through
> a separate management tool. For me, this is one of many instances for
> which I find sytemd's centralization and merging of all logging into a
> single log repository awkward and unnecessary.
>
> So please allow me to invert the question. What logging benefit or
> maintenance benefit are you gaining from inserting autossh instance
> specific configurations into systemd init files, and losing the
> segregation of autossh logs into individually parseable and reviewable
> log files?

Of course, I like questions.

I like simple systems. If I can avoid a daemon, then I do it.

Systemd is the process-Supervisor on my operating system. If there
are no good reasons for an other process-Supervisor, then I use systemd.

Logging via systemd is no problem for me.

One reason to use autossh is the ugly ExecStartPre which I use to kill and old
tunnel.

Regards,
   Thomas G?ttler

-- 
Thomas Guettler http://www.thomas-guettler.de/

From guettliml at thomas-guettler.de  Fri Mar 17 01:28:09 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Thu, 16 Mar 2017 15:28:09 +0100
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <f7aaa264-fabd-3630-db44-6d5b51624fdd@gmail.com>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <f7aaa264-fabd-3630-db44-6d5b51624fdd@gmail.com>
Message-ID: <35b37358-b14c-9582-09b4-6fa7f40c0773@thomas-guettler.de>


Am 15.03.2017 um 14:16 schrieb Douglas E Engert:
>
> I remember from years ago, a problem like this. The TCP bind was not freed up
> as quickly as one might expect. "kill -9" could be causing this not giving the
> application time to shutdown.
>
> Search for tcp bind address already in use
>
> https://hea-www.harvard.edu/~fine/Tech/addrinuse.html

Thank you for providing this.

Regards,
   Thomas


-- 
Thomas Guettler http://www.thomas-guettler.de/

From guettliml at thomas-guettler.de  Fri Mar 17 01:35:21 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Thu, 16 Mar 2017 15:35:21 +0100
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <38CA524B-F6F5-48CA-B0A5-FB6C1B94C5C7@pobox.com>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
 <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>
 <9573931f-1e62-6cb3-28c6-143c53bdbf95@thomas-guettler.de>
 <38CA524B-F6F5-48CA-B0A5-FB6C1B94C5C7@pobox.com>
Message-ID: <649848ed-71f0-4b02-5aaf-1b4c76cf8c68@thomas-guettler.de>



Am 16.03.2017 um 02:33 schrieb Jim Knoble:
> (Response inline below).
>
>>> On Tue, Mar 14, 2017 at 4:20 PM, Thomas G?ttler
>>> <guettliml at thomas-guettler.de <mailto:guettliml at thomas-guettler.de>> wrote:
>>>>
>>>> Systemd restarts the ssh if it terminates. AFAIK this is all that is needed.
>>>>
>>>> But maybe I am missing something. Is there a feature of autossh that I don't
>>>> get with systemd?
>
> AutoSSH can restart a failed connection even if SSH has not terminated. It uses either a pair of tunneled ports or an
> alternate mechanism to detect tunnel failure.
 > See https://www.everythingcli.org/ssh-tunnelling-for-fun-and-profit-autossh/ for details, including a recipe for using
 > autossh with systemd.

AFAIK ssh has the ability to detect broken connection itself.

I use this options:

     -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 60"

But I guess these options are not perfect yet.


Maybe I am wrong, but I think the "monitoring port" magic of auto-ssh is not needed.

Please tell me if I am wrong.

These options make ssh detect broken connections on his own:


   http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#ServerAliveInterval

   http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#ServerAliveCountMax

BTW, thanks to Ingo Schwarze that you can link directly to ssh_config options now.

Regards,
   Thomas G?ttler


-- 
Thomas Guettler http://www.thomas-guettler.de/

From manojampalam at gmail.com  Fri Mar 17 04:42:47 2017
From: manojampalam at gmail.com (Manoj K. Ampalam)
Date: Thu, 16 Mar 2017 10:42:47 -0700
Subject: Feedback requested: OpenSSH changes to support Windows
Message-ID: <CAB5HWyV7X4aZV4Py0okp=-LHCKjQ7Biz+7Pd+UH-9ax1UqQ7nQ@mail.gmail.com>

https://github.com/openssh/openssh-portable/pull/63

I provided a high level summary of design and implementation details in PR.
Please let me know if you have any questions or need any clarifications.
The intent behind this request is to evaluate if we are going on the right
path for a possible integration upstream.

From mindrot at hda3.com  Sat Mar 18 03:42:37 2017
From: mindrot at hda3.com (Peter Moody)
Date: Fri, 17 Mar 2017 09:42:37 -0700
Subject: Call for testing: OpenSSH 7.5p1
In-Reply-To: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
References: <alpine.BSO.2.20.1703141833130.26367@natsu.mindrot.org>
Message-ID: <CADbMJxnprWvSCT8hGdiH3oVXaZVU9XHJQW9MouyWR6GAUqL+iw@mail.gmail.com>

special snowflake reporting in. looks good here too.

thanks for all your hardwork, folks!

On Tue, Mar 14, 2017 at 3:40 AM, Damien Miller <djm at mindrot.org> wrote:
> Hi,
>
> OpenSSH 7.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
>
> 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 git using the
> instructions at http://www.openssh.com/portable.html#cvs
> At https://anongit.mindrot.org/openssh.git/ or via a mirror at Github:
> https://github.com/openssh/openssh-portable
>
> 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.
>
> Future deprecation notice
> =========================
>
> We plan on retiring more legacy cryptography in future releases,
> specifically:
>
>  * In the next major release (expected June-August), removing remaining
>    support for the SSH v.1 protocol (currently client-only and compile-
>    time disabled).
>
>  * In the same release, removing support for Blowfish and RC4 ciphers
>    and the RIPE-MD160 HMAC. (These are currently run-time disabled).
>
>  * In the same release, removing the remaining CBC ciphers from being
>    offered by default in the client (These have not been offered in
>    sshd by default for several years).
>
>  * Refusing all RSA keys smaller than 1024 bits (the current minimum
>    is 768 bits)
>
> This list reflects our current intentions, but please check the final
> release notes for future releases.
>
> Potentially-incompatible changes
> ================================
>
> This release includes a number of changes that may affect existing
> configurations:
>
>  * This release deprecates the sshd_config UsePrivilegeSeparation
>    option, thereby making privilege separation mandatory. Privilege
>    separation has been on by default for almost 15 years.
>
>  * The format of several log messages emitted by the packet code has
>    changed to include additional information about the user and
>    their authentication state. Software that monitors ssh/sshd logs
>    may need to account for these changes. For example:
>
>    Connection closed by user x 1.1.1.1 port 1234 [preauth]
>    Connection closed by authenticating user x 10.1.1.1 port 1234 [preauth]
>    Connection closed by invalid user x 1.1.1.1 port 1234 [preauth]
>
>    Affected messages include connection closure, timeout, remote
>    disconnection, negotiation failure and some other fatal messages
>    generated by the packet code.
>
> Changes since OpenSSH 7.4
> =========================
>
> This is a bugfix release.
>
> New Features
> ------------
>
>  * ssh(1), sshd(8): Support "=-" syntax to easily remove methods from
>    algorithm lists, e.g. Ciphers=-*cbc. bz#2671
>
> Bugfixes
> --------
>
>  * ssh(1), sshd(8): Allow form-feed characters to appear in
>    configuration files.
>
>  * sshd(8): Fix regression in OpenSSH 7.4 support for the
>    server-sig-algs extension, where SHA2 RSA signature methods were
>    not being correctly advertised. bz#2680
>
>  * ssh(1), ssh-keygen(1): Fix a number of case-sensitivity bugs in
>    known_hosts processing. bz#2591 bz#2685
>
>  * ssh(1): Allow ssh to use certificates accompanied by a private key
>    file but no corresponding plain *.pub public key. bz#2617
>
>  * ssh(1): When updating hostkeys using the UpdateHostKeys option,
>    accept RSA keys if HostkeyAlgorithms contains any RSA keytype.
>    Previously, ssh could ignore RSA keys when only the ssh-rsa-sha2-*
>    methods were enabled in HostkeyAlgorithms and not the old ssh-rsa
>    method. bz#2650
>
>  * ssh(1): Detect and report excessively long configuration file
>    lines. bz#2651
>
>  * Merge a number of fixes found by Coverity and reported via Redhat
>    and FreeBSD. Includes fixes for some memory and file descriptor
>    leaks in error paths. bz#2687
>
>  * ssh-keyscan(1): Correctly hash hosts with a port number. bz#2692
>
>  * ssh(1), sshd(8): When logging long messages to stderr, don't truncate
>    "\r\n" if the length of the message exceeds the buffer. bz#2688
>
>  * ssh(1): Fully quote [host]:port in generated ProxyJump/-J command-
>    line; avoid confusion over IPv6 addresses and shells that treat
>    square bracket characters specially.
>
>  * ssh-keygen(1): Fix corruption of known_hosts when running
>    "ssh-keygen -H" on a known_hosts containing already-hashed entries.
>
>  * Fix various fallout and sharp edges caused by removing SSH protocol
>    1 support from the server, including the server banner string being
>    incorrectly terminated with only \n (instead of \r\n), and
>    confusing error messages from ssh-keyscan bz#2583.
>
>  * ssh(1), sshd(8): Free fd_set on connection timeout. bz#2683
>
>  * sshd(8): Fix Unix domain socket forwarding for root (regression in
>    OpenSSH 7.4).
>
>  * sftp(1): Fix division by zero crash in "df" output when server
>    returns zero total filesystem blocks/inodes.
>
>  * ssh(1), ssh-add(1), ssh-keygen(1), sshd(8): Translate OpenSSL errors
>    encountered during key loading to more meaningful error codes.
>    bz#2522 bz#2523
>
>  * ssh-keygen(1): Sanitise escape sequences in key comments sent to
>    printf but preserve valid UTF-8 when the locale supports it;
>    bz#2520
>
>  * ssh(1), sshd(8): Return reason for port forwarding failures where
>    feasible rather than always "administratively prohibited". bz#2674
>
>  * sshd(8): Fix deadlock when AuthorizedKeysCommand or
>    AuthorizedPrincipalsCommand produces a lot of output and a key is
>    matched early. bz#2655
>
>  * Regression tests: several reliability fixes. bz#2654 bz#2658 bz#2659
>
>  * ssh(1): Fix typo in ~C error message for bad port forward
>    cancellation. bz#2672
>
>  * ssh(1): Show a useful error message when included config files
>    can't be opened; bz#2653
>
>  * sshd(8): Make sshd set GSSAPIStrictAcceptorCheck=yes as the manual page
>    (previously incorrectly) advertised. bz#2637
>
>  * sshd_config(5): Repair accidentally-deleted mention of %k token
>    in AuthorizedKeysCommand; bz#2656
>
>  * sshd(8): Remove vestiges of previously removed LOGIN_PROGRAM; bzbz#2665
>
>  * ssh-agent(1): Relax PKCS#11 whitelist to include libexec and
>    common 32-bit compatibility library directories.
>
>  * sftp-client(1): fix non-exploitable integer overflow in SSH2_FXP_NAME
>    response handling.
>
> Portability
> -----------
>
>  * sshd(8): Avoid sandbox errors for Linux S390 systems using an ICA
>    crypto coprocessor.
>
>  * sshd(8): Fix non-exploitable weakness in seccomp-bpf sandbox arg
>    inspection.
>
>  * ssh(1): Fix X11 forwarding on OSX where X11 was being started by
>    launchd. bz#2341
>
>  * ssh-keygen(1), ssh(1), sftp(1): Fix output truncation for various that
>    contain non-printable characters where the codeset in use is ASCII.
>
>  * build: Fix builds that attempt to link a kerberised libldns. bz#2603
>
>  * build: Fix compilation problems caused by unconditionally defining
>    _XOPEN_SOURCE in wide character detection.
>
>  * sshd(8): Fix sandbox violations for clock_gettime VSDO syscall
>    fallback on some Linux/X32 kernels. bz#2142
>
> 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 venture37 at geeklan.co.uk  Sat Mar 18 11:08:04 2017
From: venture37 at geeklan.co.uk (Sevan Janiyan)
Date: Sat, 18 Mar 2017 00:08:04 +0000
Subject: Tested on various operating systems
Message-ID: <f88592a1-df31-519a-5804-5307ed9e01d9@geeklan.co.uk>

Tests conducted using
http://www.mindrot.org/openssh_snap/openssh-SNAP-20170318.tar.gz

FreeBSD 12.0-CURRENT #15 r314188: Fri Feb 24 07:24:50 GMT 2017
&
DragonFly v4.7.0.1382.g6ae02a-DEVELOPMENT #259: Sat Mar  4 05:52:03 PST 2017
"All" tests passed (SUDO not set)

OS X Tiger, PowerPC
all tests passed (SUDO not set)


NetBSD 7.1RC2 & 7.99.60 (slightly stale but not that much)
test_utf8: ........................
regress/unittests/utf8/tests.c:48 test #25 "c_esc"
ASSERT_INT_EQ(len, wantlen) failed:
         len = -1
     wantlen = 5
[1]   Abort trap (core dumped) ${V}


OmniOS r151021
test_utf8: ..................
regress/unittests/utf8/tests.c:27 test #19 "utf8_badarg"
ASSERT_INT_EQ(len, -1) failed:
         len = 1
          -1 = -1
*** Signal 6 - core dumped

OS X El Capitan
/Downloads/openssh/ssh-keygen -lf
/Downloads/openssh/regress//t12.out.pub | grep test-comment-1234 >/dev/null
run test connect.sh ...
Sometimes I think the surest sign that intelligent life exists elsewhere
in the Universe is that none of it has tried to contact us.  -Calvin
ok simple connect
run test proxy-connect.sh ...
plain username protocol 2 privsep=no comp=no
bad SSH_CONNECTION protocol 2 privsep=no comp=no:  There is a clear
relationship between the elastic modulus and the resistance to erosion.
Brauer-Kriegel Rule
UNKNOWN 65535 UNKNOWN 65535
plain username protocol 2 privsep=no comp=yes
bad SSH_CONNECTION protocol 2 privsep=no comp=yes:  The whole UNIX
operating system whose documentation fits in a chinese computer terminal!
UNKNOWN 65535 UNKNOWN 65535
plain username protocol 2 privsep=yes comp=no
bad SSH_CONNECTION protocol 2 privsep=yes comp=no:  We are unable to
complete the check-in process at this time. Please proceed to the
airport for assistance.
UNKNOWN 65535 UNKNOWN 65535
plain username protocol 2 privsep=yes comp=yes
bad SSH_CONNECTION protocol 2 privsep=yes comp=yes:  21st Century Cyborg
Returns To Kill Waitress.
UNKNOWN 65535 UNKNOWN 65535
username with style protocol 2
If you are asleep you can't eat dumplings.
failed proxy connect
make[1]: *** [t-exec] Error 1
make: *** [tests] Error 2


Debian 8.7 amd64
/openssh/ssh-keygen -lf /openssh/regress//t12.out.pub | grep
test-comment-1234 >/dev/null
run test connect.sh ...
Missing privilege separation directory: /var/empty
FATAL: sshd_proxy broken
Makefile:199: recipe for target 't-exec' failed
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory '/openssh/regress'


From venture37 at geeklan.co.uk  Sun Mar 19 02:05:03 2017
From: venture37 at geeklan.co.uk (Sevan Janiyan)
Date: Sat, 18 Mar 2017 15:05:03 +0000
Subject: Tested on various operating systems
In-Reply-To: <f88592a1-df31-519a-5804-5307ed9e01d9@geeklan.co.uk>
References: <f88592a1-df31-519a-5804-5307ed9e01d9@geeklan.co.uk>
Message-ID: <dc7d1ef3-4d37-948a-e60c-78eeb7756b5e@geeklan.co.uk>



On 18/03/2017 00:08, Sevan Janiyan wrote:
> NetBSD 7.1RC2 & 7.99.60 (slightly stale but not that much)
> test_utf8: ........................
> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
> ASSERT_INT_EQ(len, wantlen) failed:
>          len = -1
>      wantlen = 5
> [1]   Abort trap (core dumped) ${V}
> 

Solaris 10 8/11 SPARC
test_utf8: ........................
regress/unittests/utf8/tests.c:48 test #25 "c_esc"
ASSERT_INT_EQ(len, wantlen) failed:
         len = -1
     wantlen = 5
*** Error code 134
make: Fatal error: Command failed for target `unit'


From djm at mindrot.org  Mon Mar 20 13:42:26 2017
From: djm at mindrot.org (Damien Miller)
Date: Mon, 20 Mar 2017 13:42:26 +1100 (AEDT)
Subject: Tested on various operating systems
In-Reply-To: <f88592a1-df31-519a-5804-5307ed9e01d9@geeklan.co.uk>
References: <f88592a1-df31-519a-5804-5307ed9e01d9@geeklan.co.uk>
Message-ID: <alpine.BSO.2.20.1703201337550.74407@natsu.mindrot.org>

On Sat, 18 Mar 2017, Sevan Janiyan wrote:

> Tests conducted using
> http://www.mindrot.org/openssh_snap/openssh-SNAP-20170318.tar.gz

Thanks for running these tests.

> NetBSD 7.1RC2 & 7.99.60 (slightly stale but not that much)
> test_utf8: ........................
> regress/unittests/utf8/tests.c:48 test #25 "c_esc"
> ASSERT_INT_EQ(len, wantlen) failed:
>          len = -1
>      wantlen = 5
> [1]   Abort trap (core dumped) ${V}

This should be fixed in HEAD.

> OmniOS r151021
> test_utf8: ..................
> regress/unittests/utf8/tests.c:27 test #19 "utf8_badarg"
> ASSERT_INT_EQ(len, -1) failed:
>          len = 1
>           -1 = -1
> *** Signal 6 - core dumped

Not sure what this one is, it's possible it was fixed by the same commit
as the NetBSD one, but it's hard to tell. I'll have to try and install it
on a VM to replicate.

> OS X El Capitan
> /Downloads/openssh/ssh-keygen -lf
> /Downloads/openssh/regress//t12.out.pub | grep test-comment-1234 >/dev/null
> run test connect.sh ...
> Sometimes I think the surest sign that intelligent life exists elsewhere
> in the Universe is that none of it has tried to contact us.  -Calvin

It looks like some shell initialisation is producing extra output for
non-interactive shells. This could be something in .bashrc (or similar)
that would better live in .bash_profile (or similar). It will break all
sorts of tests :)

> Debian 8.7 amd64
> /openssh/ssh-keygen -lf /openssh/regress//t12.out.pub | grep
> test-comment-1234 >/dev/null
> run test connect.sh ...
> Missing privilege separation directory: /var/empty

We should probably do a better job of autoconfiguring the default privsep
directory. Until then it's best to pas an explicit --with-privsep-path
to configure. I think the right one for Debian is /var/run/sshd.

-d

From andrewponomarenko at yandex.ru  Mon Mar 20 17:52:11 2017
From: andrewponomarenko at yandex.ru (Andrey Ponomarenko)
Date: Mon, 20 Mar 2017 09:52:11 +0300
Subject: API/ABI changes review for OpenSSH
Message-ID: <3892971489992731@web4j.yandex.ru>

Hello,

Here is the review of API/ABI changes for OpenSSH since 5.4p1 version: https://abi-laboratory.pro/tracker/timeline/openssh/

The report is updated 3 times a week. Hope it will be helpful for users and maintainers of the library.

Created with the help of open-source abi-tracker tool: https://github.com/lvc/abi-tracker

Thank you.

From alexis.horgix.chotard at gmail.com  Tue Mar 21 00:03:41 2017
From: alexis.horgix.chotard at gmail.com (Alexis Horgix Chotard)
Date: Mon, 20 Mar 2017 14:03:41 +0100
Subject: [Doc] Extension of Included configuration files
In-Reply-To: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com>
References: <CAPwU=5WoKUtbgO7oS8EYn7CNF6b1uHQejYwwF5g5sLetkq-QoA@mail.gmail.com>
 <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com>
Message-ID: <CAPwU=5WOqK1AyETHkkaVBgACc0CTs3_fJAuMwiy9436KeZJGTg@mail.gmail.com>

Hello,

2017-02-15 9:50 GMT+01:00 Jakub Jelen <jjelen at redhat.com>:
> This is very strict condition. For the tools, I would rather have a look at
> the full path (if it is possible), because in most of the cases, the files
> should come under /etc/ssh/ssh_config.d/*

Well, if it's not  strict enough it will make it hard to differenciate
different kind of ssh configurations.
And this would only covers configuration in /etc, not the ones in
~/.ssh, so it would be necessary to add ~/.ssh/ssh_config.d/ to the
list.

> Having this path automatically included by default in shipped configuration
> files from OpenSSH upstream would be nice.

That's actually a good idea imho. Does anyone have something for/against that ?
It would simplify configurations inclusion, and it will set a base
"standard" so ~/.ssh/ssh_config.d would make sense too and could be
indicated in the man page.

I'm willing to write the patch for it if it were to be accepted, and
then submit it, but I'm not sure where I could submit this since there
was so little answer to my current proposal.

Regards,

-- 
Alexis 'Horgix' Chotard

From nkadel at gmail.com  Tue Mar 21 00:26:09 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Mon, 20 Mar 2017 09:26:09 -0400
Subject: [Doc] Extension of Included configuration files
In-Reply-To: <CAPwU=5WOqK1AyETHkkaVBgACc0CTs3_fJAuMwiy9436KeZJGTg@mail.gmail.com>
References: <CAPwU=5WoKUtbgO7oS8EYn7CNF6b1uHQejYwwF5g5sLetkq-QoA@mail.gmail.com>
 <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com>
 <CAPwU=5WOqK1AyETHkkaVBgACc0CTs3_fJAuMwiy9436KeZJGTg@mail.gmail.com>
Message-ID: <CAOCN9ryQxz_YHWPQ4-9aN=gCVmfnTdvO5UGcqeB44jCGT9Z19Q@mail.gmail.com>

On Mon, Mar 20, 2017 at 9:03 AM, Alexis Horgix Chotard
<alexis.horgix.chotard at gmail.com> wrote:
> Hello,
>
> 2017-02-15 9:50 GMT+01:00 Jakub Jelen <jjelen at redhat.com>:
>> This is very strict condition. For the tools, I would rather have a look at
>> the full path (if it is possible), because in most of the cases, the files
>> should come under /etc/ssh/ssh_config.d/*
>
> Well, if it's not  strict enough it will make it hard to differenciate
> different kind of ssh configurations.
> And this would only covers configuration in /etc, not the ones in
> ~/.ssh, so it would be necessary to add ~/.ssh/ssh_config.d/ to the
> list.
>
>> Having this path automatically included by default in shipped configuration
>> files from OpenSSH upstream would be nice.
>
> That's actually a good idea imho. Does anyone have something for/against that ?
> It would simplify configurations inclusion, and it will set a base
> "standard" so ~/.ssh/ssh_config.d would make sense too and could be
> indicated in the man page.
>
> I'm willing to write the patch for it if it were to be accepted, and
> then submit it, but I'm not sure where I could submit this since there
> was so little answer to my current proposal.
>
> Regards,

I'm against it being on by default. Not because "include" files are
not an interesting idea, but because it could be prone to incompatible
abuse by other add-on packages after OpenSSH is installed, and because
the sequential activation of included files can lead to erratic
behavior when an individual file is added alphabetically ahead of
another included file which is no longer being successfully parsed due
to the first file. (Been there, done that with /etc/sudoers.d and
/etc/profile.d.)

From djm at openbsd.org  Tue Mar 21 00:31:35 2017
From: djm at openbsd.org (Damien Miller)
Date: Mon, 20 Mar 2017 07:31:35 -0600 (MDT)
Subject: Announce: OpenSSH 7.5 released
Message-ID: <aca826c22adc3f94@openbsd.org>

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

OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support. OpenSSH also includes
transitional support for the legacy SSH 1.3 and 1.5 protocols
that may be enabled at compile-time.

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

Future deprecation notice
=========================

We plan on retiring more legacy cryptography in future releases,
specifically:

 * In the next major release (expected June-August), removing remaining
   support for the SSH v.1 protocol (currently client-only and compile-
   time disabled).

 * In the same release, removing support for Blowfish and RC4 ciphers
   and the RIPE-MD160 HMAC. (These are currently run-time disabled).

 * In the same release, removing the remaining CBC ciphers from being
   offered by default in the client (These have not been offered in
   sshd by default for several years).

 * Refusing all RSA keys smaller than 1024 bits (the current minimum
   is 768 bits)

This list reflects our current intentions, but please check the final
release notes for future releases.

Potentially-incompatible changes
================================

This release includes a number of changes that may affect existing
configurations:

 * This release deprecates the sshd_config UsePrivilegeSeparation
   option, thereby making privilege separation mandatory. Privilege
   separation has been on by default for almost 15 years and
   sandboxing has been on by default for almost the last five.

 * The format of several log messages emitted by the packet code has
   changed to include additional information about the user and
   their authentication state. Software that monitors ssh/sshd logs
   may need to account for these changes. For example:

   Connection closed by user x 1.1.1.1 port 1234 [preauth]
   Connection closed by authenticating user x 10.1.1.1 port 1234 [preauth]
   Connection closed by invalid user x 1.1.1.1 port 1234 [preauth]

   Affected messages include connection closure, timeout, remote
   disconnection, negotiation failure and some other fatal messages
   generated by the packet code.

 * [Portable OpenSSH only] This version removes support for building
   against OpenSSL versions prior to 1.0.1. OpenSSL stopped supporting
   versions prior to 1.0.1 over 12 months ago (i.e. they no longer
   receive fixes for security bugs).

Changes since OpenSSH 7.4
=========================

This is a bugfix release.

Security
--------

 * ssh(1), sshd(8): Fix weakness in CBC padding oracle countermeasures
   that allowed a variant of the attack fixed in OpenSSH 7.3 to proceed.
   Note that the OpenSSH client disables CBC ciphers by default, sshd
   offers them as lowest-preference options and will remove them by
   default entriely in the next release. Reported by Jean Paul
   Degabriele, Kenny Paterson, Martin Albrecht and Torben Hansen of
   Royal Holloway, University of London.

 * sftp-client(1): [portable OpenSSH only] On Cygwin, a client making
   a recursive file transfer could be maniuplated by a hostile server to
   perform a path-traversal attack. creating or modifying files outside
   of the intended target directory. Reported by Jann Horn of Google
   Project Zero.

New Features
------------

 * ssh(1), sshd(8): Support "=-" syntax to easily remove methods from
   algorithm lists, e.g. Ciphers=-*cbc. bz#2671

Bugfixes
--------

 * sshd(1): Fix NULL dereference crash when key exchange start
   messages are sent out of sequence.

 * ssh(1), sshd(8): Allow form-feed characters to appear in
   configuration files.
 
 * sshd(8): Fix regression in OpenSSH 7.4 support for the
   server-sig-algs extension, where SHA2 RSA signature methods were
   not being correctly advertised. bz#2680

 * ssh(1), ssh-keygen(1): Fix a number of case-sensitivity bugs in
   known_hosts processing. bz#2591 bz#2685

 * ssh(1): Allow ssh to use certificates accompanied by a private key
   file but no corresponding plain *.pub public key. bz#2617

 * ssh(1): When updating hostkeys using the UpdateHostKeys option,
   accept RSA keys if HostkeyAlgorithms contains any RSA keytype.
   Previously, ssh could ignore RSA keys when only the ssh-rsa-sha2-*
   methods were enabled in HostkeyAlgorithms and not the old ssh-rsa
   method. bz#2650
    
 * ssh(1): Detect and report excessively long configuration file
   lines. bz#2651

 * Merge a number of fixes found by Coverity and reported via Redhat
   and FreeBSD. Includes fixes for some memory and file descriptor
   leaks in error paths. bz#2687
    
 * ssh-keyscan(1): Correctly hash hosts with a port number. bz#2692

 * ssh(1), sshd(8): When logging long messages to stderr, don't truncate
   "\r\n" if the length of the message exceeds the buffer. bz#2688

 * ssh(1): Fully quote [host]:port in generated ProxyJump/-J command-
   line; avoid confusion over IPv6 addresses and shells that treat
   square bracket characters specially.
    
 * ssh-keygen(1): Fix corruption of known_hosts when running
   "ssh-keygen -H" on a known_hosts containing already-hashed entries.

 * Fix various fallout and sharp edges caused by removing SSH protocol
   1 support from the server, including the server banner string being
   incorrectly terminated with only \n (instead of \r\n), confusing
   error messages from ssh-keyscan bz#2583 and a segfault in sshd
   if protocol v.1 was enabled for the client and sshd_config
   contained references to legacy keys bz#2686.

 * ssh(1), sshd(8): Free fd_set on connection timeout. bz#2683

 * sshd(8): Fix Unix domain socket forwarding for root (regression in
   OpenSSH 7.4).
    
 * sftp(1): Fix division by zero crash in "df" output when server
   returns zero total filesystem blocks/inodes.
 
 * ssh(1), ssh-add(1), ssh-keygen(1), sshd(8): Translate OpenSSL errors
   encountered during key loading to more meaningful error codes.
   bz#2522 bz#2523

 * ssh-keygen(1): Sanitise escape sequences in key comments sent to
   printf but preserve valid UTF-8 when the locale supports it;
   bz#2520

 * ssh(1), sshd(8): Return reason for port forwarding failures where
   feasible rather than always "administratively prohibited". bz#2674

 * sshd(8): Fix deadlock when AuthorizedKeysCommand or
   AuthorizedPrincipalsCommand produces a lot of output and a key is
   matched early. bz#2655

 * Regression tests: several reliability fixes. bz#2654 bz#2658 bz#2659
    
 * ssh(1): Fix typo in ~C error message for bad port forward
   cancellation. bz#2672

 * ssh(1): Show a useful error message when included config files
   can't be opened; bz#2653

 * sshd(8): Make sshd set GSSAPIStrictAcceptorCheck=yes as the manual page
   (previously incorrectly) advertised. bz#2637

 * sshd_config(5): Repair accidentally-deleted mention of %k token
   in AuthorizedKeysCommand; bz#2656

 * sshd(8): Remove vestiges of previously removed LOGIN_PROGRAM; bz#2665

 * ssh-agent(1): Relax PKCS#11 whitelist to include libexec and
   common 32-bit compatibility library directories.

 * sftp-client(1): Fix non-exploitable integer overflow in SSH2_FXP_NAME
   response handling.

 * ssh-agent(1): Fix regression in 7.4 of deleting PKCS#11-hosted
   keys. It was not possible to delete them except by specifying
   their full physical path. bz#2682

Portability
-----------

 * sshd(8): Avoid sandbox errors for Linux S390 systems using an ICA
   crypto coprocessor.

 * sshd(8): Fix non-exploitable weakness in seccomp-bpf sandbox arg
   inspection.

 * ssh(1): Fix X11 forwarding on OSX where X11 was being started by
   launchd. bz#2341

 * ssh-keygen(1), ssh(1), sftp(1): Fix output truncation for various that
   contain non-printable characters where the codeset in use is ASCII.

 * build: Fix builds that attempt to link a kerberised libldns. bz#2603

 * build: Fix compilation problems caused by unconditionally defining
   _XOPEN_SOURCE in wide character detection.

 * sshd(8): Fix sandbox violations for clock_gettime VSDO syscall
   fallback on some Linux/X32 kernels. bz#2142

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

 - SHA1 (openssh-7.5.tar.gz) = 81384df377e38551f7659a4c250383d0bbd25341
 - SHA1 (openssh-7.5p1.tar.gz) = 5e8f185d00afb4f4f89801e9b0f8b9cee9d87ebd

 - SHA256 (openssh-7.5.tar.gz) = Gmk8jOdGdKa7NixUN5J+bTMfeum5Vx8Nv+leAdQNq3U=
 - SHA256 (openssh-7.5p1.tar.gz) = mEbjxfq58FR0ALTSwBeZL5FCIrP9H47ubH3GvF5Z+fA=

Please note that the SHA256 signatures are base64 encoded and not
hexadecimal (which is the default for most checksum tools). The PGP
key used to sign the releases is available as RELEASE_KEY.asc from
the mirror sites.

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh at openssh.com

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


From alexis.horgix.chotard at gmail.com  Tue Mar 21 00:39:48 2017
From: alexis.horgix.chotard at gmail.com (Alexis Horgix Chotard)
Date: Mon, 20 Mar 2017 14:39:48 +0100
Subject: [Doc] Extension of Included configuration files
In-Reply-To: <CAOCN9ryQxz_YHWPQ4-9aN=gCVmfnTdvO5UGcqeB44jCGT9Z19Q@mail.gmail.com>
References: <CAPwU=5WoKUtbgO7oS8EYn7CNF6b1uHQejYwwF5g5sLetkq-QoA@mail.gmail.com>
 <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com>
 <CAPwU=5WOqK1AyETHkkaVBgACc0CTs3_fJAuMwiy9436KeZJGTg@mail.gmail.com>
 <CAOCN9ryQxz_YHWPQ4-9aN=gCVmfnTdvO5UGcqeB44jCGT9Z19Q@mail.gmail.com>
Message-ID: <CAPwU=5V-KbF-Fe6CnrML8zk7o+v6i36NodcbfExwMdJWqz=L8A@mail.gmail.com>

Hello,

2017-03-20 14:26 GMT+01:00 Nico Kadel-Garcia <nkadel at gmail.com>:
> I'm against it being on by default. Not because "include" files are
> not an interesting idea, but because it could be prone to incompatible
> abuse by other add-on packages after OpenSSH is installed, and because
> the sequential activation of included files can lead to erratic
> behavior when an individual file is added alphabetically ahead of
> another included file which is no longer being successfully parsed due
> to the first file. (Been there, done that with /etc/sudoers.d and
> /etc/profile.d.)

That's for this reason that my original proposal was only to include a
SHOULD mention to the manpage, like "Included files should go to a
ssh_config.d directory in order to be detected as such by external
tools".

Would that make more sense to you ? If not, do you have any suggestion
regarding the original problem of detecting ssh configuration files
now that any file can be included ?

-- 
Alexis 'Horgix' Chotard

From vapier at gentoo.org  Tue Mar 21 04:46:40 2017
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 20 Mar 2017 13:46:40 -0400
Subject: [PATCH] keytype.sh: drop usage of `time`
Message-ID: <20170320174640.16126-1-vapier@gentoo.org>

This doesn't provide any useful info and just makes it harder to
diff the log outputs between diff test runs.
---
 regress/keytype.sh | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/regress/keytype.sh b/regress/keytype.sh
index 8f697788f865..644d77881e4f 100644
--- a/regress/keytype.sh
+++ b/regress/keytype.sh
@@ -3,11 +3,6 @@
 
 tid="login with different key types"
 
-TIME=`which time 2>/dev/null`
-if test ! -x "$TIME"; then
-	TIME=""
-fi
-
 cp $OBJ/sshd_proxy $OBJ/sshd_proxy_bak
 cp $OBJ/ssh_proxy $OBJ/ssh_proxy_bak
 
@@ -27,7 +22,7 @@ for kt in $ktypes; do
 	bits=`echo ${kt} | awk -F- '{print $2}'`
 	type=`echo ${kt}  | awk -F- '{print $1}'`
 	printf "keygen $type, $bits bits:\t"
-	${TIME} ${SSHKEYGEN} -b $bits -q -N '' -t $type  -f $OBJ/key.$kt ||\
+	${SSHKEYGEN} -b $bits -q -N '' -t $type  -f $OBJ/key.$kt ||\
 		fail "ssh-keygen for type $type, $bits bits failed"
 done
 
@@ -64,7 +59,7 @@ for ut in $ktypes; do
 		cat $OBJ/key.$ut.pub > $OBJ/authorized_keys_$USER
 		for i in $tries; do
 			printf "userkey $ut, hostkey ${ht}:\t"
-			${TIME} ${SSH} -F $OBJ/ssh_proxy 999.999.999.999 true
+			${SSH} -F $OBJ/ssh_proxy 999.999.999.999 true
 			if [ $? -ne 0 ]; then
 				fail "ssh userkey $ut, hostkey $ht failed"
 			fi
-- 
2.12.0


From vapier at gentoo.org  Tue Mar 21 05:59:07 2017
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 20 Mar 2017 14:59:07 -0400
Subject: [PATCH] seccomp sandbox: fix typo w/x32 check
Message-ID: <20170320185907.16288-1-vapier@gentoo.org>

---
 sandbox-seccomp-filter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index 3a1aedce72c2..a8d472a63ccb 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -235,7 +235,7 @@ static const struct sock_filter preauth_insns[] = {
 	 * x86-64 syscall under some circumstances, e.g.
 	 * https://bugs.debian.org/849923
 	 */
-	SC_ALLOW(__NR_clock_gettime & ~__X32_SYSCALL_BIT);
+	SC_ALLOW(__NR_clock_gettime & ~__X32_SYSCALL_BIT),
 #endif
 
 	/* Default deny */
-- 
2.12.0


From djm at mindrot.org  Tue Mar 21 08:51:21 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 21 Mar 2017 08:51:21 +1100 (AEDT)
Subject: [PATCH] seccomp sandbox: fix typo w/x32 check
In-Reply-To: <20170320185907.16288-1-vapier@gentoo.org>
References: <20170320185907.16288-1-vapier@gentoo.org>
Message-ID: <alpine.BSO.2.20.1703210847080.64361@natsu.mindrot.org>

damn. Thanks for the patch. I've applied to both HEAD and the V_7_5 branch.

On Mon, 20 Mar 2017, Mike Frysinger wrote:

> ---
>  sandbox-seccomp-filter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
> index 3a1aedce72c2..a8d472a63ccb 100644
> --- a/sandbox-seccomp-filter.c
> +++ b/sandbox-seccomp-filter.c
> @@ -235,7 +235,7 @@ static const struct sock_filter preauth_insns[] = {
>  	 * x86-64 syscall under some circumstances, e.g.
>  	 * https://bugs.debian.org/849923
>  	 */
> -	SC_ALLOW(__NR_clock_gettime & ~__X32_SYSCALL_BIT);
> +	SC_ALLOW(__NR_clock_gettime & ~__X32_SYSCALL_BIT),
>  #endif
>  
>  	/* Default deny */
> -- 
> 2.12.0
> 
> _______________________________________________
> 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  Tue Mar 21 09:07:19 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 21 Mar 2017 09:07:19 +1100 (AEDT)
Subject: [PATCH] keytype.sh: drop usage of `time`
In-Reply-To: <20170320174640.16126-1-vapier@gentoo.org>
References: <20170320174640.16126-1-vapier@gentoo.org>
Message-ID: <alpine.BSO.2.20.1703210906240.64361@natsu.mindrot.org>

On Mon, 20 Mar 2017, Mike Frysinger wrote:

> This doesn't provide any useful info and just makes it harder to
> diff the log outputs between diff test runs.

I committed a variant of this diff that changed the printf's for verbose's
since it was relying on time to provide newlines between test cases.

Thanks,
Damien

From nkadel at gmail.com  Tue Mar 21 15:08:09 2017
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Tue, 21 Mar 2017 00:08:09 -0400
Subject: [Doc] Extension of Included configuration files
In-Reply-To: <CAPwU=5V-KbF-Fe6CnrML8zk7o+v6i36NodcbfExwMdJWqz=L8A@mail.gmail.com>
References: <CAPwU=5WoKUtbgO7oS8EYn7CNF6b1uHQejYwwF5g5sLetkq-QoA@mail.gmail.com>
 <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com>
 <CAPwU=5WOqK1AyETHkkaVBgACc0CTs3_fJAuMwiy9436KeZJGTg@mail.gmail.com>
 <CAOCN9ryQxz_YHWPQ4-9aN=gCVmfnTdvO5UGcqeB44jCGT9Z19Q@mail.gmail.com>
 <CAPwU=5V-KbF-Fe6CnrML8zk7o+v6i36NodcbfExwMdJWqz=L8A@mail.gmail.com>
Message-ID: <CAOCN9rxHd3T999MV9CRDdcOHy+-H6-JY9r=sT5WLvtpA4HDMNA@mail.gmail.com>

On Mon, Mar 20, 2017 at 9:39 AM, Alexis Horgix Chotard
<alexis.horgix.chotard at gmail.com> wrote:
> Hello,
>
> 2017-03-20 14:26 GMT+01:00 Nico Kadel-Garcia <nkadel at gmail.com>:
>> I'm against it being on by default. Not because "include" files are
>> not an interesting idea, but because it could be prone to incompatible
>> abuse by other add-on packages after OpenSSH is installed, and because
>> the sequential activation of included files can lead to erratic
>> behavior when an individual file is added alphabetically ahead of
>> another included file which is no longer being successfully parsed due
>> to the first file. (Been there, done that with /etc/sudoers.d and
>> /etc/profile.d.)
>
> That's for this reason that my original proposal was only to include a
> SHOULD mention to the manpage, like "Included files should go to a
> ssh_config.d directory in order to be detected as such by external
> tools".

"Should" is better. "Should" protected from casual user replacement,
is even better, but that can be a religious issue.

> Would that make more sense to you ? If not, do you have any suggestion
> regarding the original problem of detecting ssh configuration files
> now that any file can be included ?

Not really. Pre-vetting them for parseability will slow down SSH
connections, perhaps not by much, but potentially significantly for a
system where disk access is having some difficulty.

From andrewponomarenko at yandex.ru  Tue Mar 21 16:53:12 2017
From: andrewponomarenko at yandex.ru (Andrey Ponomarenko)
Date: Tue, 21 Mar 2017 08:53:12 +0300
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <aca826c22adc3f94@openbsd.org>
References: <aca826c22adc3f94@openbsd.org>
Message-ID: <986551490075592@web14m.yandex.ru>

20.03.2017, 16:41, Damien Miller:
> OpenSSH 7.5 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.

API/ABI changes review for 7.5p1 vs 7.4p1: https://abi-laboratory.pro/tracker/compat_report/openssh/7.4p1/7.5p1/96f83/abi_compat_report.html

API/ABI changes timeline: https://abi-laboratory.pro/tracker/timeline/openssh/

Thank you.

From jjelen at redhat.com  Tue Mar 21 22:29:57 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 21 Mar 2017 12:29:57 +0100
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <alpine.BSO.2.20.1703141316250.220@natsu.mindrot.org>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
 <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>
 <ab1b2c3c-965a-ac0d-afd2-089dbeed3e66@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703141248370.220@natsu.mindrot.org>
 <alpine.BSO.2.20.1703141316250.220@natsu.mindrot.org>
Message-ID: <9ea793f4-e374-52de-4ae1-37c4553ee6b5@redhat.com>

On 03/14/2017 03:17 AM, Damien Miller wrote:
> I've committed this diff. Please test and confirm that it works ok.
> (If not, then I've botched the macro fixes in the previous commit)
>
> Thanks,
> Damien Miller
>
> On Tue, 14 Mar 2017, Damien Miller wrote:
>
>> ok, with the fixes for the seccomp-bpf sandbox that I just committed
>> the diff reduces to.
>>
>> IMO this is scoped narrowly enough to go in.
>>
>> -d
>>
>> diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
>> index af5525ab..6ceee33f 100644
>> --- a/sandbox-seccomp-filter.c
>> +++ b/sandbox-seccomp-filter.c
>> @@ -223,6 +223,12 @@ static const struct sock_filter preauth_insns[] = {
>>  #ifdef __NR_socketcall
>>  	SC_ALLOW_ARG(socketcall, 0, SYS_SHUTDOWN),
>>  #endif
>> +#if defined(__NR_ioctl) && defined(__s390__)
>> +	/* Allow ioctls for ICA crypto card on s390 */
>> +	SC_ALLOW_ARG(ioctl, 1, Z90STAT_STATUS_MASK),
>> +	SC_ALLOW_ARG(ioctl, 1, ICARSAMODEXPO),
>> +	SC_ALLOW_ARG(ioctl, 1, ICARSACRT),
>> +#endif /* defined(__NR_ioctl) && defined(__s390__) */
>>
>>  	/* Default deny */
>>  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),

Hello,
this patch requires also the header files included, which was dropped 
from the initial proposal and breaks the build on s390x [1].

The missing constants should be defined in asm/zcrypt.h as mentioned in 
the original patch:

#ifdef __s390__
#include <asm/zcrypt.h>
#endif

Please, add also this hunk.

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

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From ldv at altlinux.org  Tue Mar 21 23:10:18 2017
From: ldv at altlinux.org (Dmitry V. Levin)
Date: Tue, 21 Mar 2017 15:10:18 +0300
Subject: API/ABI changes review for OpenSSH
In-Reply-To: <3892971489992731@web4j.yandex.ru>
References: <3892971489992731@web4j.yandex.ru>
Message-ID: <20170321121018.GA5172@altlinux.org>

Hi,

On Mon, Mar 20, 2017 at 09:52:11AM +0300, Andrey Ponomarenko wrote:
> Hello,
> 
> Here is the review of API/ABI changes for OpenSSH since 5.4p1 version: https://abi-laboratory.pro/tracker/timeline/openssh/

Looks like it tracks libssh.so which is not a part of OpenSSH.
Where have you got that libssh.so from?


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170321/7dd006a8/attachment.bin>

From jjelen at redhat.com  Wed Mar 22 02:27:20 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 21 Mar 2017 16:27:20 +0100
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <aca826c22adc3f94@openbsd.org>
References: <aca826c22adc3f94@openbsd.org>
Message-ID: <f586dabb-b405-7e60-bf2e-883ab53c2c35@redhat.com>

On 03/20/2017 02:31 PM, Damien Miller wrote:
> OpenSSH 7.5 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.
>
>
> Security
> --------
>
>  * ssh(1), sshd(8): Fix weakness in CBC padding oracle countermeasures
>    that allowed a variant of the attack fixed in OpenSSH 7.3 to proceed.
>    Note that the OpenSSH client disables CBC ciphers by default, sshd
>    offers them as lowest-preference options and will remove them by
>    default entriely in the next release. Reported by Jean Paul
>    Degabriele, Kenny Paterson, Martin Albrecht and Torben Hansen of
>    Royal Holloway, University of London.

Can we get some clarification on this CBC weakness from you or from the 
reporters? There is no update in the security page according to this 
security issue.

So far I understood that the CBC modes are disabled because we have 
better ciphers to choose from. Also I still have understanding that any 
of the attacks presented so far were not feasible. Did it change?

If I see right, the change related to this record is below, but the real 
effects are not clear even from the commit message:

https://github.com/openssh/openssh-portable/commit/0fb1a617

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From djm at mindrot.org  Wed Mar 22 12:44:30 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 22 Mar 2017 12:44:30 +1100 (AEDT)
Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390)
In-Reply-To: <9ea793f4-e374-52de-4ae1-37c4553ee6b5@redhat.com>
References: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com>
 <020ec0a7-5ab5-071a-adf7-65d2ecc5d573@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703021528120.51202@natsu.mindrot.org>
 <88489abf-11fe-072d-3641-2d32d7644201@suse.cz>
 <ab1b2c3c-965a-ac0d-afd2-089dbeed3e66@linux.vnet.ibm.com>
 <alpine.BSO.2.20.1703141248370.220@natsu.mindrot.org>
 <alpine.BSO.2.20.1703141316250.220@natsu.mindrot.org>
 <9ea793f4-e374-52de-4ae1-37c4553ee6b5@redhat.com>
Message-ID: <alpine.BSO.2.20.1703221244080.13572@natsu.mindrot.org>

Committed to both master and the V_7_5 branch.

Thanks,
Damien

On Tue, 21 Mar 2017, Jakub Jelen wrote:

> On 03/14/2017 03:17 AM, Damien Miller wrote:
> > I've committed this diff. Please test and confirm that it works ok.
> > (If not, then I've botched the macro fixes in the previous commit)
> > 
> > Thanks,
> > Damien Miller
> > 
> > On Tue, 14 Mar 2017, Damien Miller wrote:
> > 
> > > ok, with the fixes for the seccomp-bpf sandbox that I just committed
> > > the diff reduces to.
> > > 
> > > IMO this is scoped narrowly enough to go in.
> > > 
> > > -d
> > > 
> > > diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
> > > index af5525ab..6ceee33f 100644
> > > --- a/sandbox-seccomp-filter.c
> > > +++ b/sandbox-seccomp-filter.c
> > > @@ -223,6 +223,12 @@ static const struct sock_filter preauth_insns[] = {
> > >  #ifdef __NR_socketcall
> > >  	SC_ALLOW_ARG(socketcall, 0, SYS_SHUTDOWN),
> > >  #endif
> > > +#if defined(__NR_ioctl) && defined(__s390__)
> > > +	/* Allow ioctls for ICA crypto card on s390 */
> > > +	SC_ALLOW_ARG(ioctl, 1, Z90STAT_STATUS_MASK),
> > > +	SC_ALLOW_ARG(ioctl, 1, ICARSAMODEXPO),
> > > +	SC_ALLOW_ARG(ioctl, 1, ICARSACRT),
> > > +#endif /* defined(__NR_ioctl) && defined(__s390__) */
> > > 
> > >  	/* Default deny */
> > >  	BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),
> 
> Hello,
> this patch requires also the header files included, which was dropped from the
> initial proposal and breaks the build on s390x [1].
> 
> The missing constants should be defined in asm/zcrypt.h as mentioned in the
> original patch:
> 
> #ifdef __s390__
> #include <asm/zcrypt.h>
> #endif
> 
> Please, add also this hunk.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1434341
> 
> Regards,
> -- 
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
> _______________________________________________
> 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 Mar 22 13:00:22 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 22 Mar 2017 13:00:22 +1100 (AEDT)
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <f586dabb-b405-7e60-bf2e-883ab53c2c35@redhat.com>
References: <aca826c22adc3f94@openbsd.org>
 <f586dabb-b405-7e60-bf2e-883ab53c2c35@redhat.com>
Message-ID: <alpine.BSO.2.20.1703221244350.13572@natsu.mindrot.org>

On Tue, 21 Mar 2017, Jakub Jelen wrote:

> On 03/20/2017 02:31 PM, Damien Miller wrote:
> > OpenSSH 7.5 has just been released. It will be available from the
> > mirrors listed at http://www.openssh.com/ shortly.
> > 
> > 
> > Security
> > --------
> > 
> >  * ssh(1), sshd(8): Fix weakness in CBC padding oracle countermeasures
> >    that allowed a variant of the attack fixed in OpenSSH 7.3 to proceed.
> >    Note that the OpenSSH client disables CBC ciphers by default, sshd
> >    offers them as lowest-preference options and will remove them by
> >    default entriely in the next release. Reported by Jean Paul
> >    Degabriele, Kenny Paterson, Martin Albrecht and Torben Hansen of
> >    Royal Holloway, University of London.
> 
> Can we get some clarification on this CBC weakness from you or from the
> reporters? There is no update in the security page according to this security
> issue.

I've asked Kenny Paterson if he has some details he can share. Otherwise
I'll write something up. The impact is similar to the original CBC padding
attack:

http://www.openssh.com/txt/cbc.adv
http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf

> So far I understood that the CBC modes are disabled because we have better
> ciphers to choose from. Also I still have understanding that any of the
> attacks presented so far were not feasible. Did it change?

They're borderline feasible in the case of client/server pairs that retry
endlessly and carry private data. IIRC the cost of mounting the attack is
in the order of hundreds of thousands of disrupted connections per word
pilfered.

The main thing that convinced us to un-default the remaining CBC
ciphers in the next release is that the countermeasures code has needed
repair multiple times. IMO this is a signal that we're wasting effort on
something that is 1) providing a false sense of security and 2) keeping
CBC on life-support in the wider SSH ecosystem when we should be pulling
the plug.

-d

From andrewponomarenko at yandex.ru  Wed Mar 22 18:07:10 2017
From: andrewponomarenko at yandex.ru (Andrey Ponomarenko)
Date: Wed, 22 Mar 2017 10:07:10 +0300
Subject: API/ABI changes review for OpenSSH
In-Reply-To: <20170321121018.GA5172@altlinux.org>
References: <3892971489992731@web4j.yandex.ru>
 <20170321121018.GA5172@altlinux.org>
Message-ID: <1335101490166430@web18j.yandex.ru>

21.03.2017, 15:15, Dmitry V. Levin:
> Hi,
>
> On Mon, Mar 20, 2017 at 09:52:11AM +0300, Andrey Ponomarenko wrote:
>> ?Hello,
>>
>> ?Here is the review of API/ABI changes for OpenSSH since 5.4p1 version: https://abi-laboratory.pro/tracker/timeline/openssh/
>
> Looks like it tracks libssh.so which is not a part of OpenSSH.
> Where have you got that libssh.so from?
>

Hi Dmitry,

It's built from libssh.a:

gcc -shared -o libssh.so -Wl,--whole-archive libssh.a

Thank you.

From guettliml at thomas-guettler.de  Thu Mar 23 03:55:54 2017
From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=)
Date: Wed, 22 Mar 2017 17:55:54 +0100
Subject: Relaiable ssh tunnel via systemd
In-Reply-To: <649848ed-71f0-4b02-5aaf-1b4c76cf8c68@thomas-guettler.de>
References: <5be93800-219c-7abe-997e-ae55085602e3@thomas-guettler.de>
 <CAOCN9rx6duDkF-SejRKNWPQA5+ast4DA948jGZoChYZ=4s16DQ@mail.gmail.com>
 <a762df55-691e-f554-394c-7f26466d8131@thomas-guettler.de>
 <CAOCN9ryLQqc66toMAfLnM++ryHj8foxc-b4i1Bw==vxaAMuxTQ@mail.gmail.com>
 <9573931f-1e62-6cb3-28c6-143c53bdbf95@thomas-guettler.de>
 <38CA524B-F6F5-48CA-B0A5-FB6C1B94C5C7@pobox.com>
 <649848ed-71f0-4b02-5aaf-1b4c76cf8c68@thomas-guettler.de>
Message-ID: <1bad4919-fc69-e47c-380e-93d7bf17b2b0@thomas-guettler.de>

Hi Jim and other ssh-users,

I received no reply on my last post.

Is there something autossh can do, which I don't get with systemd and ServerAliveInterval?

Regards,
   Thomas G?ttler

Am 16.03.2017 um 15:35 schrieb Thomas G?ttler:
>
>
> Am 16.03.2017 um 02:33 schrieb Jim Knoble:
>> (Response inline below).
>>
>>>> On Tue, Mar 14, 2017 at 4:20 PM, Thomas G?ttler
>>>> <guettliml at thomas-guettler.de <mailto:guettliml at thomas-guettler.de>> wrote:
>>>>>
>>>>> Systemd restarts the ssh if it terminates. AFAIK this is all that is needed.
>>>>>
>>>>> But maybe I am missing something. Is there a feature of autossh that I don't
>>>>> get with systemd?
>>
>> AutoSSH can restart a failed connection even if SSH has not terminated. It uses either a pair of tunneled ports or an
>> alternate mechanism to detect tunnel failure.
>> See https://www.everythingcli.org/ssh-tunnelling-for-fun-and-profit-autossh/ for details, including a recipe for using
>> autossh with systemd.
>
> AFAIK ssh has the ability to detect broken connection itself.
>
> I use this options:
>
>     -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 60"
>
> But I guess these options are not perfect yet.
>
>
> Maybe I am wrong, but I think the "monitoring port" magic of auto-ssh is not needed.
>
> Please tell me if I am wrong.
>
> These options make ssh detect broken connections on his own:
>
>
>   http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#ServerAliveInterval
>
>   http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#ServerAliveCountMax
>
> BTW, thanks to Ingo Schwarze that you can link directly to ssh_config options now.
>
> Regards,
>   Thomas G?ttler
>
>

-- 
Thomas Guettler http://www.thomas-guettler.de/

From stu at spacehopper.org  Thu Mar 23 21:19:13 2017
From: stu at spacehopper.org (Stuart Henderson)
Date: Thu, 23 Mar 2017 10:19:13 +0000 (UTC)
Subject: Announce: OpenSSH 7.5 released
References: <aca826c22adc3f94@openbsd.org> <986551490075592@web14m.yandex.ru>
Message-ID: <slrnod7897.103p.stu@naiad.spacehopper.org>

On 2017-03-21, Andrey Ponomarenko <andrewponomarenko at yandex.ru> wrote:
> 20.03.2017, 16:41, Damien Miller:
>> OpenSSH 7.5 has just been released. It will be available from the
>> mirrors listed at http://www.openssh.com/ shortly.
>
> API/ABI changes review for 7.5p1 vs 7.4p1: https://abi-laboratory.pro/tracker/compat_report/openssh/7.4p1/7.5p1/96f83/abi_compat_report.html
>
> API/ABI changes timeline: https://abi-laboratory.pro/tracker/timeline/openssh/
>
> Thank you.

This is an internal-only library, on OpenBSD only the static libssh.a is
built and it's not installed...

Is some OS providing this as a shared library?



From cat at vv.carleton.ca  Fri Mar 24 12:15:55 2017
From: cat at vv.carleton.ca (Catalin Patulea)
Date: Thu, 23 Mar 2017 21:15:55 -0400
Subject: ssh man page about 'tunnel' feature
Message-ID: <CAE2LqHK712N2qDkBC8j93x-pLFODF+pUJSBXN1=+j=Jd=vwATg@mail.gmail.com>

"Hi,

I was reading about the tunnel/VPN feature and found this section of
the ssh man page:
http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=ssh#8
under "SSH-BASED VIRTUAL PRIVATE NETWORKS"

--
Client access may be more finely tuned via the
/root/.ssh/authorized_keys file (see below) and the PermitRootLogin
server option. The following entry would permit connections on tun(4)
device 1 from user "jane" and on tun device 2 from user "john", if
PermitRootLogin is set to "forced-commands-only":

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
--

Is that true? Can /root authorized_keys set keys for other users? I
can't find a reference to this in other man pages, or the source code.

Catalin

From peter at stuge.se  Fri Mar 24 13:24:35 2017
From: peter at stuge.se (Peter Stuge)
Date: Fri, 24 Mar 2017 02:24:35 +0000
Subject: ssh man page about 'tunnel' feature
In-Reply-To: <CAE2LqHK712N2qDkBC8j93x-pLFODF+pUJSBXN1=+j=Jd=vwATg@mail.gmail.com>
References: <CAE2LqHK712N2qDkBC8j93x-pLFODF+pUJSBXN1=+j=Jd=vwATg@mail.gmail.com>
Message-ID: <20170324022435.GW25144@stuge.se>

Catalin Patulea wrote:
> The following entry would permit connections on tun(4)
> device 1 from user "jane" and on tun device 2 from user "john",
> if PermitRootLogin is set to "forced-commands-only":
> 
> tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
> tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
> --
> 
> Is that true?

Yes.

> Can /root authorized_keys set keys for other users?

jane and john are not neccessarily local users, they are usernames
in the comment fields of the two authorized public keys.

The comment by default reflects the current username on the system
where a key was generated.

If that happened to have been on the local system, then local users
jane and john are indeed authorized to create tunnels, but that use
case doesn't make much sense.


//Peter

From cjwatson at debian.org  Fri Mar 24 21:28:00 2017
From: cjwatson at debian.org (Colin Watson)
Date: Fri, 24 Mar 2017 10:28:00 +0000
Subject: API/ABI changes review for OpenSSH
In-Reply-To: <1335101490166430@web18j.yandex.ru>
References: <3892971489992731@web4j.yandex.ru>
 <20170321121018.GA5172@altlinux.org>
 <1335101490166430@web18j.yandex.ru>
Message-ID: <20170324102800.GA7273@riva.ucam.org>

On Wed, Mar 22, 2017 at 10:07:10AM +0300, Andrey Ponomarenko wrote:
> 21.03.2017, 15:15, Dmitry V. Levin:
> > On Mon, Mar 20, 2017 at 09:52:11AM +0300, Andrey Ponomarenko wrote:
> >> ?Here is the review of API/ABI changes for OpenSSH since 5.4p1 version: https://abi-laboratory.pro/tracker/timeline/openssh/
> >
> > Looks like it tracks libssh.so which is not a part of OpenSSH.
> > Where have you got that libssh.so from?
> 
> Hi Dmitry,
> 
> It's built from libssh.a:
> 
> gcc -shared -o libssh.so -Wl,--whole-archive libssh.a

This library is only used internally by OpenSSH and not installed, so
I'm not sure what the point of tracking its API/ABI changes is.

-- 
Colin Watson                                       [cjwatson at debian.org]

From cjwatson at debian.org  Fri Mar 24 21:29:30 2017
From: cjwatson at debian.org (Colin Watson)
Date: Fri, 24 Mar 2017 10:29:30 +0000
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <aca826c22adc3f94@openbsd.org>
References: <aca826c22adc3f94@openbsd.org>
Message-ID: <20170324102930.GB7273@riva.ucam.org>

On Mon, Mar 20, 2017 at 07:31:35AM -0600, Damien Miller wrote:
> OpenSSH 7.5 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.

I don't see the usual V_7_5_P1 tag in git.  Did somebody forget to push
that?

Thanks as ever,

-- 
Colin Watson                                       [cjwatson at debian.org]

From vinschen at redhat.com  Fri Mar 24 23:00:06 2017
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 24 Mar 2017 13:00:06 +0100
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <aca826c22adc3f94@openbsd.org>
Message-ID: <20170324120006.GA22109@calimero.vinschen.de>

Hi,

I got a report on the Cygwin mailing list in terms of deprecating the
privsep option.  It seems one consequence is that you can't run sshd
under a non-privileged account for personal use anymore:

----- Forwarded message from Lionel Fourquaux -----
> * This release deprecates the sshd_config UsePrivilegeSeparation
>   option, thereby making privilege separation mandatory.

This has (probably not wholly intended) consequences when running sshd in
single user (non root) mode:

$ /usr/sbin/sshd -D -f ~/.ssh/sshd_config
Privilege separation user sshd does not exist

The problem is not limited to Cygwin, but is unlikely to happen in a typical
Unix, since ssh is probably installed globally.

If Cygwin was installed without administrative privileges, creating a
dedicated sshd user would be impossible (and makes little sense if sshd runs
in single user mode, anyway).  I guess it would be possible to add a fake
user account in /etc/passwd.

Since user sshd and chroot /var/empty are not used in single user mode, it
might be better to remove the check in this case:

=== cut after ===
diff --git a/sshd.c b/sshd.c
index 010a2c3..4f9b2c8 100644
--- a/sshd.c
+++ b/sshd.c
@@ -1641,7 +1641,8 @@ main(int ac, char **av)

	/* Store privilege separation user for later use if required. */
	if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
-		if (use_privsep || options.kerberos_authentication)
+		if ((use_privsep || options.kerberos_authentication)
+		    && (getuid() == 0 || geteuid() == 0))
			fatal("Privilege separation user %s does not exist",
			    SSH_PRIVSEP_USER);
	} else {
@@ -1767,7 +1768,7 @@ main(int ac, char **av)
		    key_type(key));
	}

-	if (use_privsep) {
+	if (use_privsep && (getuid() == 0 || geteuid() == 0)) {
		struct stat st;

		if ((stat(_PATH_PRIVSEP_CHROOT_DIR, &st) == -1) ||
=== cut before ===

Best regards,

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

Is there a chance this could be reenabled again?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170324/09b912fb/attachment.bin>

From brmdamon at hushmail.com  Fri Mar 24 23:38:29 2017
From: brmdamon at hushmail.com (Jack Dodds)
Date: Fri, 24 Mar 2017 12:38:29 -0000
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <20170324120006.GA22109@calimero.vinschen.de>
References: <20170324120006.GA22109@calimero.vinschen.de>
Message-ID: <be3bbc3eba9d32a3d0ca3f30c61dcfd4@smtp.hushmail.com>

Hello,

You seem to be saying that in 7.5, sshd can no longer be run
under an ordinary user account. Is that accurate?

I use sshd running under a user account in Debian Jessie to allow
tunnels from remote devices. That capability is crucial to my
application.

Any comments would be appreciated.

Jack Dodds


Corinna Vinschen <vinschen at redhat.com> wrote:
> Hi,
> 
> I got a report on the Cygwin mailing list in terms of
> deprecating the privsep option. It seems one consequence is
> that you can't run sshd under a non-privileged account for
> personal use anymore:
> 
> ----- Forwarded message from Lionel Fourquaux -----
> > * This release deprecates the sshd_config UsePrivilegeSeparation
> >   option, thereby making privilege separation mandatory.
> 
> This has (probably not wholly intended) consequences when
> running sshd in single user (non root) mode:
> 
> $ /usr/sbin/sshd -D -f ~/.ssh/sshd_config
> Privilege separation user sshd does not exist
> 
> The problem is not limited to Cygwin, but is unlikely to happen
> in a typical Unix, since ssh is probably installed globally.
> 
> If Cygwin was installed without administrative privileges,
> creating a dedicated sshd user would be impossible (and makes
> little sense if sshd runs in single user mode, anyway). I guess
> it would be possible to add a fake user account in /etc/passwd.
> 
> Since user sshd and chroot /var/empty are not used in single
> user mode, it might be better to remove the check in this case:
> 
> === cut after ===
> diff --git a/sshd.c b/sshd.c
> index 010a2c3..4f9b2c8 100644
> --- a/sshd.c
> +++ b/sshd.c
> @@ -1641,7 +1641,8 @@ main(int ac, char **av)
> 
> 	/* Store privilege separation user for later use if required. */
> 	if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
> -		if (use_privsep || options.kerberos_authentication)
> +		if ((use_privsep || options.kerberos_authentication)
> +		    && (getuid() == 0 || geteuid() == 0))
> 			fatal("Privilege separation user %s does not exist",
> 			    SSH_PRIVSEP_USER);
> 	} else {
> @@ -1767,7 +1768,7 @@ main(int ac, char **av)
> 		    key_type(key));
> 	}
> 
> -	if (use_privsep) {
> +	if (use_privsep && (getuid() == 0 || geteuid() == 0)) {
> 		struct stat st;
> 
> 		if ((stat(_PATH_PRIVSEP_CHROOT_DIR, &st) == -1) ||
> === cut before ===
> 
> Best regards,
> 
> 		-- Lionel
> ----- End forwarded message -----
> 
> Is there a chance this could be reenabled again?
> 
> 
> Thanks,
> Corinna
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Encryption key for Jack Dodds.asc
Type: application/pgp-keys
Size: 1702 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170324/2441bf19/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170324/2441bf19/attachment-0001.bin>

From ggarner_online at gmgsystemsinc.com  Sat Mar 25 02:05:06 2017
From: ggarner_online at gmgsystemsinc.com (George M. Garner Jr.)
Date: Fri, 24 Mar 2017 11:05:06 -0400
Subject: Windows module-definition file for libssh
Message-ID: <82fef63f-39c7-825a-84c2-d49107dec1bc@gmgsystemsinc.com>

Does anyone have module-definition file (.def) for libssh, or even 
better, a script to automatically generate one?  The OpenSSL project has 
a mkdef.pl script, but that is specific to OpenSSL.

Regards,

George M. Garner Jr.

From hecht at hlrs.de  Mon Mar 27 21:20:29 2017
From: hecht at hlrs.de (Martin Hecht)
Date: Mon, 27 Mar 2017 12:20:29 +0200
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <aca826c22adc3f94@openbsd.org>
References: <aca826c22adc3f94@openbsd.org>
Message-ID: <c4be7624-6da6-15e6-3da7-7473a7a16f28@hlrs.de>

On 03/20/2017 02:31 PM, Damien Miller wrote:
> OpenSSH 7.5 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.
> [...]
>  * [Portable OpenSSH only] This version removes support for building
>    against OpenSSL versions prior to 1.0.1. OpenSSL stopped supporting
>    versions prior to 1.0.1 over 12 months ago (i.e. they no longer
>    receive fixes for security bugs).
This causes configure to fail on SLES 11 sp3 LTSS. SUSE backports
security fixes for openssl 0.9.8 until 2019.
I have found the corresponding git commit which changes configure.ac,
and would like to undo it. Apart from the concern that upstream at
openssl stopped supporting 0.9.8, are there any other reasons behind
this change (new dependencies on 1.0.1 which are not checked elsewhere)?

kind regards,
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5254 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170327/8e6a71bb/attachment-0001.bin>

From dtucker at zip.com.au  Mon Mar 27 22:00:36 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 27 Mar 2017 22:00:36 +1100
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <c4be7624-6da6-15e6-3da7-7473a7a16f28@hlrs.de>
References: <aca826c22adc3f94@openbsd.org>
 <c4be7624-6da6-15e6-3da7-7473a7a16f28@hlrs.de>
Message-ID: <CALDDTe1saTWfzEbh13BwFHAybsM01ohP2SRSun40h0o5=2etng@mail.gmail.com>

On Mon, Mar 27, 2017 at 9:20 PM, Martin Hecht <hecht at hlrs.de> wrote:

> [...]
> This causes configure to fail on SLES 11 sp3 LTSS. SUSE backports
> security fixes for openssl 0.9.8 until 2019.
> I have found the corresponding git commit which changes configure.ac,
> and would like to undo it.


You're welcome to do so however if it breaks you get to keep both pieces.


> Apart from the concern that upstream at
> openssl stopped supporting 0.9.8, are there any other reasons behind
> this change (new dependencies on 1.0.1 which are not checked elsewhere)?
>

Given that support was removed late in the development cycle and it was
tested with older versions up until then I would guess 7.5p1 might still
work.

Beyond that, there's a bunch of compatibility shims in
openbsd-compat/openssl-compat.{c,h} and a couple of
ifdef OPENSSL_VERSION_NUMBER sprinkled in the code which I would expect to
be removed in future.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From jjelen at redhat.com  Mon Mar 27 23:57:18 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 27 Mar 2017 14:57:18 +0200
Subject: Windows module-definition file for libssh
In-Reply-To: <82fef63f-39c7-825a-84c2-d49107dec1bc@gmgsystemsinc.com>
References: <82fef63f-39c7-825a-84c2-d49107dec1bc@gmgsystemsinc.com>
Message-ID: <f4032e9b-f4d3-3999-f4f8-37301d0daaee@redhat.com>

On 03/24/2017 04:05 PM, George M. Garner Jr. wrote:
> Does anyone have module-definition file (.def) for libssh, or even
> better, a script to automatically generate one?  The OpenSSL project has
> a mkdef.pl script, but that is specific to OpenSSL.
>
> Regards,
>
> George M. Garner Jr.

LibSSH mailing list is somewhere else:

https://www.libssh.org/communication/

OpenSSH builds library only for internal usage at this time.

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From vinschen at redhat.com  Tue Mar 28 01:31:03 2017
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 27 Mar 2017 16:31:03 +0200
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <be3bbc3eba9d32a3d0ca3f30c61dcfd4@smtp.hushmail.com>
References: <20170324120006.GA22109@calimero.vinschen.de>
 <be3bbc3eba9d32a3d0ca3f30c61dcfd4@smtp.hushmail.com>
Message-ID: <20170327143103.GC8279@calimero.vinschen.de>

On Mar 24 12:38, Jack Dodds wrote:
> Hello,
> 
> You seem to be saying that in 7.5, sshd can no longer be run
> under an ordinary user account. Is that accurate?

Well, yes, that's what the report claims, and it seems correct to me.

> I use sshd running under a user account in Debian Jessie to allow
> tunnels from remote devices. That capability is crucial to my
> application.
> 
> Any comments would be appreciated.

Same here.

Is it really just a bug or is the "non-priv'ed user running sshd"
scenario going to be unsupported in future?


Corinna


> Corinna Vinschen wrote:
> > ----- Forwarded message from Lionel Fourquaux -----
> > > * This release deprecates the sshd_config UsePrivilegeSeparation
> > >   option, thereby making privilege separation mandatory.
> > 
> > This has (probably not wholly intended) consequences when
> > running sshd in single user (non root) mode:
> > 
> > $ /usr/sbin/sshd -D -f ~/.ssh/sshd_config
> > Privilege separation user sshd does not exist
> > 
> > The problem is not limited to Cygwin, but is unlikely to happen
> > in a typical Unix, since ssh is probably installed globally.
> > 
> > If Cygwin was installed without administrative privileges,
> > creating a dedicated sshd user would be impossible (and makes
> > little sense if sshd runs in single user mode, anyway). I guess
> > it would be possible to add a fake user account in /etc/passwd.
> > 
> > Since user sshd and chroot /var/empty are not used in single
> > user mode, it might be better to remove the check in this case:
> > 
> > === cut after ===
> > diff --git a/sshd.c b/sshd.c
> > index 010a2c3..4f9b2c8 100644
> > --- a/sshd.c
> > +++ b/sshd.c
> > @@ -1641,7 +1641,8 @@ main(int ac, char **av)
> > 
> > 	/* Store privilege separation user for later use if required. */
> > 	if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
> > -		if (use_privsep || options.kerberos_authentication)
> > +		if ((use_privsep || options.kerberos_authentication)
> > +		    && (getuid() == 0 || geteuid() == 0))
> > 			fatal("Privilege separation user %s does not exist",
> > 			    SSH_PRIVSEP_USER);
> > 	} else {
> > @@ -1767,7 +1768,7 @@ main(int ac, char **av)
> > 		    key_type(key));
> > 	}
> > 
> > -	if (use_privsep) {
> > +	if (use_privsep && (getuid() == 0 || geteuid() == 0)) {
> > 		struct stat st;
> > 
> > 		if ((stat(_PATH_PRIVSEP_CHROOT_DIR, &st) == -1) ||
> > === cut before ===
> > 
> > Best regards,
> > 
> > 		-- Lionel
> > ----- End forwarded message -----
> > 
> > Is there a chance this could be reenabled again?
> > 
> > 
> > Thanks,
> > Corinna
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170327/acb03574/attachment.bin>

From tgc at jupiterrise.com  Tue Mar 28 02:06:48 2017
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Mon, 27 Mar 2017 17:06:48 +0200
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <aca826c22adc3f94@openbsd.org>
References: <aca826c22adc3f94@openbsd.org>
Message-ID: <d692d10c-ae02-7943-8635-a06fc8d857cc@jupiterrise.com>

On 20/03/17 14:31, Damien Miller wrote:
> OpenSSH 7.5 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.
>

I'm seeing an error in the testsuite on Solaris 2.6:
test_utf8: ........................
regress/unittests/utf8/tests.c:48 test #25 "c_esc"
ASSERT_INT_EQ(len, wantlen) failed:
          len = -1
      wantlen = 5


I seems this might be related to the fact that on Solaris < 7 
nl_langinfo(CODESET) returns an empty string when the codeset is ASCII.

To verify I put together a small testprogram that does a setlocale 
followed by nl_langinfo(CODESET) and for the 'C' locale it returns an 
empty string while 'da' returns ISO8859-1 as expected.

-tgc

From brmdamon at hushmail.com  Tue Mar 28 02:23:27 2017
From: brmdamon at hushmail.com (Jack Dodds)
Date: Mon, 27 Mar 2017 15:23:27 -0000
Subject: Is support being removed for ordinary users to run sshd?
Message-ID: <26f2ce734f9055aedea9b795492814c2@smtp.hushmail.com>

Hello Darren,

Could you comment on this issue being raised by myself and
Corinna Vinschen?

This will create big problems for me.

I'm not clear if this is a conscious decision supported by solid
reasons or if it is just collateral damage.

Thank you for all you work!

Jack DoDDs 

-------- Original Message --------
Date: Mon, 27 Mar 2017 16:31:03 +0200
Subject: Re: Announce: OpenSSH 7.5 released
From: Corinna Vinschen <vinschen at redhat.com>
To: openssh-unix-dev at mindrot.org

On Mar 24 12:38, Jack Dodds wrote:
> Hello,
> 
> You seem to be saying that in 7.5, sshd can no longer be run
> under an ordinary user account. Is that accurate?

Well, yes, that's what the report claims, and it seems correct to
me.

> I use sshd running under a user account in Debian Jessie to allow
> tunnels from remote devices. That capability is crucial to my
> application.
> 
> Any comments would be appreciated.

Same here.

Is it really just a bug or is the "non-priv'ed user running sshd"
scenario going to be unsupported in future?


Corinna


> Corinna Vinschen wrote:
> > ----- Forwarded message from Lionel Fourquaux -----
> > > * This release deprecates the sshd_config UsePrivilegeSeparation
> > >   option, thereby making privilege separation mandatory.
> > 
> > This has (probably not wholly intended) consequences when
> > running sshd in single user (non root) mode:
> > 
> > $ /usr/sbin/sshd -D -f ~/.ssh/sshd_config
> > Privilege separation user sshd does not exist
> > 
> > The problem is not limited to Cygwin, but is unlikely to happen
> > in a typical Unix, since ssh is probably installed globally.
> > 
> > If Cygwin was installed without administrative privileges,
> > creating a dedicated sshd user would be impossible (and makes
> > little sense if sshd runs in single user mode, anyway). I guess
> > it would be possible to add a fake user account in /etc/passwd.
> > 
> > Since user sshd and chroot /var/empty are not used in single
> > user mode, it might be better to remove the check in this case:
> > 
> > === cut after ===
> > diff --git a/sshd.c b/sshd.c
> > index 010a2c3..4f9b2c8 100644
> > --- a/sshd.c
> > +++ b/sshd.c
> > @@ -1641,7 +1641,8 @@ main(int ac, char **av)
> > 
> > 	/* Store privilege separation user for later use if required. */
> > 	if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
> > -		if (use_privsep || options.kerberos_authentication)
> > +		if ((use_privsep || options.kerberos_authentication)
> > +		    && (getuid() == 0 || geteuid() == 0))
> > 			fatal("Privilege separation user %s does not exist",
> > 			    SSH_PRIVSEP_USER);
> > 	} else {
> > @@ -1767,7 +1768,7 @@ main(int ac, char **av)
> > 		    key_type(key));
> > 	}
> > 
> > -	if (use_privsep) {
> > +	if (use_privsep && (getuid() == 0 || geteuid() == 0)) {
> > 		struct stat st;
> > 
> > 		if ((stat(_PATH_PRIVSEP_CHROOT_DIR, &st) == -1) ||
> > === cut before ===
> > 
> > Best regards,
> > 
> > 		-- Lionel
> > ----- End forwarded message -----
> > 
> > Is there a chance this could be reenabled again?
> > 
> > 
> > Thanks,
> > Corinna
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Encryption key for Jack Dodds.asc
Type: application/pgp-keys
Size: 1702 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170327/68e672e1/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170327/68e672e1/attachment-0003.bin>

From djm at mindrot.org  Wed Mar 29 11:23:26 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 29 Mar 2017 11:23:26 +1100 (AEDT)
Subject: Announce: OpenSSH 7.5 released
In-Reply-To: <20170324102930.GB7273@riva.ucam.org>
References: <aca826c22adc3f94@openbsd.org>
 <20170324102930.GB7273@riva.ucam.org>
Message-ID: <alpine.BSO.2.20.1703291123150.61163@natsu.mindrot.org>

On Fri, 24 Mar 2017, Colin Watson wrote:

> On Mon, Mar 20, 2017 at 07:31:35AM -0600, Damien Miller wrote:
> > OpenSSH 7.5 has just been released. It will be available from the
> > mirrors listed at http://www.openssh.com/ shortly.
> 
> I don't see the usual V_7_5_P1 tag in git.  Did somebody forget to push
> that?

Yes, I forgot. Pushed now.

From dtucker at zip.com.au  Wed Mar 29 13:03:37 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 29 Mar 2017 13:03:37 +1100
Subject: Is support being removed for ordinary users to run sshd?
In-Reply-To: <26f2ce734f9055aedea9b795492814c2@smtp.hushmail.com>
References: <26f2ce734f9055aedea9b795492814c2@smtp.hushmail.com>
Message-ID: <CALDDTe0JakQd0DEx7FX9EMqE43JvnwB2ttAksDR7F-5FDRVH9w@mail.gmail.com>

On Tue, Mar 28, 2017 at 2:23 AM, Jack Dodds <brmdamon at hushmail.com> wrote:

> Hello Darren,
>
> Could you comment on this issue being raised by myself and
> Corinna Vinschen?
>
> This will create big problems for me.
>
> I'm not clear if this is a conscious decision supported by solid
> reasons or if it is just collateral damage.
>
> Thank you for all you work!
>
> Jack DoDDs
>
> -------- Original Message --------
> Date: Mon, 27 Mar 2017 16:31:03 +0200
> Subject: Re: Announce: OpenSSH 7.5 released
> From: Corinna Vinschen <vinschen at redhat.com>
> To: openssh-unix-dev at mindrot.org
>
> On Mar 24 12:38, Jack Dodds wrote:
> > Hello,
> >
> > You seem to be saying that in 7.5, sshd can no longer be run
> > under an ordinary user account. Is that accurate?
>
> Well, yes, that's what the report claims, and it seems correct to
> me.
>

It's not quite accurate.  The issue is that it checks for the existence of
the privsep user and directory even though it does not use them.  If they
exist (even if only because you configure'ed --with-privsep-user and
--with-privsep-dir to point to other existing ones) then it'll work.  This
is what we use for the regression tests when SUDO is not set (but because
all our test systems have the user and dir, we never observed the problem).


> > I use sshd running under a user account in Debian Jessie to allow
> > tunnels from remote devices. That capability is crucial to my
> > application.
> >
> > Any comments would be appreciated.
>
> Same here.
>
> Is it really just a bug or is the "non-priv'ed user running sshd"
> scenario going to be unsupported in future?
>

My opinion:
 - running as a non-privileged user should be supported.
 - running with privsep disabled (ie one unprivileged process) will not be
supported.

This will mean that you'll have two sshd processes per connection running
as an unprivileged user, same as you would for a privileged user.

Rationale: we want to reduce the code complexity by removing the !privsep
code paths, and some privilege dropping mechanisms like OpenSBD's pledge
can still be employed by unprivileged code).

I've just committed a variation on the patch to both HEAD and the 7.5
branch.

https://anongit.mindrot.org/openssh.git/commit/?id=d13281f2964abc5f2e535e1613c77fc61b0c53e7

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From brmdamon at hushmail.com  Wed Mar 29 13:32:11 2017
From: brmdamon at hushmail.com (Jack Dodds)
Date: Wed, 29 Mar 2017 02:32:11 -0000
Subject: Is support being removed for ordinary users to run sshd?
In-Reply-To: <CALDDTe0JakQd0DEx7FX9EMqE43JvnwB2ttAksDR7F-5FDRVH9w@mail.gmail.com>
References: <CALDDTe0JakQd0DEx7FX9EMqE43JvnwB2ttAksDR7F-5FDRVH9w@mail.gmail.com>
Message-ID: <f434d394122fbce4e452144ce93cf79c@smtp.hushmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Darren,

Thank you for the explanation. As long as a non-privileged user
can run sshd (listening on a high-numbered port), my application
is OK.

SSH is a great tool for those of us concerned about privacy. Your
work is really appreciated!

Jack

Darren Tucker <dtucker at zip.com.au> wrote:
> On Tue, Mar 28, 2017 at 2:23 AM, Jack Dodds
> <brmdamon at hushmail.com> wrote:
> 
> > Hello Darren,
> >
> > Could you comment on this issue being raised by myself and
> > Corinna Vinschen?
> >
> > This will create big problems for me.
> >
> > I'm not clear if this is a conscious decision supported by solid
> > reasons or if it is just collateral damage.
> >
> > Thank you for all you work!
> >
> > Jack DoDDs
> >
> > -------- Original Message --------
> > Date: Mon, 27 Mar 2017 16:31:03 +0200
> > Subject: Re: Announce: OpenSSH 7.5 released
> > From: Corinna Vinschen <vinschen at redhat.com>
> > To: openssh-unix-dev at mindrot.org
> >=
> > On Mar 24 12:38, Jack Dodds wrote:
> > > Hello,
> > >
> > > You seem to be saying that in 7.5, sshd can no longer be run
> > > under an ordinary user account. Is that accurate?
> >
> > Well, yes, that's what the report claims, and it seems correct to
> > me.
> >
> 
> It's not quite accurate. The issue is that it checks for the
> existence of the privsep user and directory even though it does
> not use them. If they exist (even if only because you
> configure'ed --with-privsep-user and --with-privsep-dir to
> point to other existing ones) then it'll work. This is what we
> use for the regression tests when SUDO is not set (but because
> all our test systems have the user and dir, we never observed
> the problem).
> 
> 
> > > I use sshd running under a user account in Debian Jessie to allow
> > > tunnels from remote devices. That capability is crucial to my
> > > application.
> > >
> > > Any comments would be appreciated.
> >
> > Same here.
> >
> > Is it really just a bug or is the "non-priv'ed user running sshd"
> > scenario going to be unsupported in future?
> >
> 
> My opinion:
>  - running as a non-privileged user should be supported.
>  - running with privsep disabled (ie one unprivileged process) will not be
> supported.
> 
> This will mean that you'll have two sshd processes per
> connection running as an unprivileged user, same as you would
> for a privileged user.
> 
> Rationale: we want to reduce the code complexity by removing
> the !privsep code paths, and some privilege dropping mechanisms
> like OpenSBD's pledge can still be employed by unprivileged
> code).
> 
> I've just committed a variation on the patch to both HEAD and
> the 7.5 branch.
> 
> https://anongit.mindrot.org/openssh.git/commit/?id=d13281f2964abc5f2e535e1613c77fc61b0c53e7
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJY2xywAAoJEChpvIQG4DsHRngIAIFlboNrrJ8dKoOSFOex6lIy
dwH92dF3gsIdHB2Uuya8UElfi+fHl1Rypc3ToDT53lbGJTI3N/ERY7VK5vs69UFz
BlKQ8tD+E43VBmM6dqWAIXY2t+DDdOn/pg1zC8sWIxoH/YvKGUp+dqMIHpnjnVyQ
DKxQUiv+ygXapJGaNwIe8lFicdxyqerwxXJX9gwbs73iTTEK7sfqK9WGoTox5yqN
PORJi73zmjBastFKvO+wDM4F+5xXtX4cH9eufNa/eAouZpIVpUut5MwGbL0LDVNL
8jeolgLZMx/dnBpgy8eezUXnF6e41k0y7Iw0LFmzCYHBGQ82lyn4TxV/BG/+QrQ=
=B/Dp
-----END PGP SIGNATURE-----

From cgf1993 at foxmail.com  Wed Mar 29 20:47:39 2017
From: cgf1993 at foxmail.com (=?ISO-8859-1?B?Q0dG?=)
Date: Wed, 29 Mar 2017 17:47:39 +0800
Subject: openssh7.5 can't make in ubuntu14.04LTS system
Message-ID: <tencent_3173520B13C5BFC3370C2F69@qq.com>

I followed the instructions as below(https://www.openssh.com/openbsd.html). 


 
https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openssh-7.5.tar.gz
 


 


 
# cd /usr/src/usr.bin
 
# tar zxvf .../openssh-7.5.tar.gz
 
# cd ssh
 
# make obj
 
# make cleandir
 
# make depend
 
# make
 
# make install
 
# cp ssh_config sshd_config /etc/ssh





But when I input and execute "make obj" instruction, I got this error "Makefile:3: *** missing separator.  Stop."
And the Makefile in /usr/src/usr.bin/ssh folder is as below.


---------------------------------------------------------------------------
# $OpenBSD: Makefile,v 1.15 2010/02/09 08:55:31 markus Exp $


.include <bsd.own.mk>


SUBDIR= lib ssh sshd ssh-add ssh-keygen ssh-agent scp sftp-server \
    ssh-keysign ssh-keyscan sftp ssh-pkcs11-helper


distribution:
    ${INSTALL} -C -o root -g wheel -m 0644 ${.CURDIR}/ssh_config \
        ${DESTDIR}/etc/ssh/ssh_config
    ${INSTALL} -C -o root -g wheel -m 0644 ${.CURDIR}/sshd_config \
        ${DESTDIR}/etc/ssh/sshd_config


.include <bsd.subdir.mk>
---------------------------------------------------------------------------


I have no idea how to solve it?


Thanks for your help.

From dtucker at zip.com.au  Wed Mar 29 21:10:23 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 29 Mar 2017 21:10:23 +1100
Subject: openssh7.5 can't make in ubuntu14.04LTS system
In-Reply-To: <tencent_3173520B13C5BFC3370C2F69@qq.com>
References: <tencent_3173520B13C5BFC3370C2F69@qq.com>
Message-ID: <CALDDTe0rFzyWZdWxw_dpV1Nbyi7ekLr9NDEZQts=HTLERypJ7Q@mail.gmail.com>

-openssh at openssh.com

On Wed, Mar 29, 2017 at 8:47 PM, CGF <cgf1993 at foxmail.com> wrote:

> I followed the instructions as below(https://www.openssh.com/openbsd.html
> ).
> <https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openssh-7.5.tar.gz>
>

Unlikely, since that says "The following versions of OpenSSH are available
for putting on your OpenBSD machines" and you're trying to install it on
Ubuntu.

You also sent this to openssh at openssh.com, which is not mentioned on that
page but where it is it says
"openssh at openssh.com. [...] Not appropriate for: How-to queries, reports of
problems on platforms other than OpenBSD or with third-party patches,
general discussion"

https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openssh-7.5.tar.gz
>

You want https://www.openssh.com/portable.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From reuti at staff.uni-marburg.de  Wed Mar 29 22:02:15 2017
From: reuti at staff.uni-marburg.de (Reuti)
Date: Wed, 29 Mar 2017 13:02:15 +0200
Subject: Man page "sshd_config" ambiguousness
Message-ID: <5E387830-1B25-4094-9585-474E0CC7367C@staff.uni-marburg.de>

Hi,

Defining in "sshd_config" one or more of the possible entries DenyUsers, AllowUsers, DenyGroups, and AllowGroups it turns out, that all of these must be satisfied to grant access. I found many entries on the web clearly stating that it's essentially an intersection of the sets AllowGroups and AlowUsers and not an union. While I can live with this fact when it's the intended behavior, I wonder why the man page explaining these entries was never adjusted. I mean:

===
$ man sshd_config
?
AllowGroups
[?] The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.
===

For me this always sounded like having an effect one usually find in firewalls: the first matching rule will deny or allow access, and the fall through case must be defined as a special rule.

But it's not the case. While I understand that internal to the `sshd` daemon one must handle one constraint after the other, the behavior for the user (and the user is here is an admin setting it up) is more like:

===
$ man sshd_config
?
AllowGroups
[?] The allow/deny directives (if present) DenyUsers, AllowUsers, DenyGroups, and AllowGroups will all be checked and a user will be granted access only, if all files permit this. By default a user is permitted to login, unless one or both of the files AllowUsers and AllowGroups is present, where all users not being listed therein are denied access.
===

I would really like to see an update man page to avoid the confusion which AFAICS many trapped into.

-- Reuti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170329/7b438681/attachment.bin>

From jjelen at redhat.com  Thu Mar 30 00:26:54 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 29 Mar 2017 15:26:54 +0200
Subject: X11 forwarding with IPv6 disabled
Message-ID: <a46bfc27-7bfb-4eed-f3fb-2b636799e9e2@redhat.com>

Hello all,
one more (ever-returning) bug [1] reported recently caught my eye. The 
problem is that disabling IPv6 in kernel leads to OpenSSH failing to 
bind localhost IPv6 address and after the fix for CVE-2008-1483 [2] 
leads to the whole X11 forwarding fail.

If I read the description of the CVE in question correctly, we should 
care only of the case when the address is already used (errno = 
EADDRINUSE). Other errors or at least EADDRNOTAVAIL (trying to bind IPv6 
address when disabled or the other way round) should not lead to fatal 
errors and fallback to the other address (if any).

This was already discussed in the bug #2143 [2] and #1356 [3] with 
basically the same patch I came up with. The comments from Darren nor 
Damien in any of them did not come with any convincing reasoning why not 
to include this change. Therefore I am bringing this issue up again 
here. Can you have a look into that and get that fixed almost 10 years 
later? Any comments welcome.


Other discussed solution would be not to return IPv6 address from 
getaddrinfo() if disabled, but I don't think we will be able to justify 
this change of behavior.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1436097
[2] https://github.com/openssh/openssh-portable/commit/5f5cd746
[3] https://bugzilla.mindrot.org/show_bug.cgi?id=2143

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From oleg.newyorker at gmail.com  Fri Mar 31 09:31:44 2017
From: oleg.newyorker at gmail.com (Oleg NewYorker)
Date: Thu, 30 Mar 2017 18:31:44 -0400
Subject: Private host key is sent instead of public in DH KEX?
Message-ID: <CABRT3we545dfjBZYuGq=nX0hfKcPiphYAGGy7gTDptEAJL5A5A@mail.gmail.com>

Hello,

Can someone please tell me if I am right or wrong that in the code below
private key can be sent (in DH KEX) instead of public one (need_private is
0). Both keys are available (sensitive_data.host_keys[i] and
sensitive_data.host_pubkeys[i] are not NULL).
I hope I am just missing something here.

Thanks.

static Key *
get_hostkey_by_type(int type, int nid, int need_private, struct ssh *ssh)
{
    int i;
    Key *key;

    for (i = 0; i < options.num_host_key_files; i++) {
        switch (type) {
        case KEY_RSA_CERT:
        case KEY_DSA_CERT:
        case KEY_ECDSA_CERT:
        case KEY_ED25519_CERT:
            key = sensitive_data.host_certificates[i];
            break;
        default:
            key = sensitive_data.host_keys[i];
            if (key == NULL && !need_private)
                key = sensitive_data.host_pubkeys[i];
            break;
        }
        if (key != NULL && key->type == type &&
            (key->type != KEY_ECDSA || key->ecdsa_nid == nid))
            return need_private ?
                sensitive_data.host_keys[i] : key;
    }
    return NULL;
}

From openssh at tlinx.org  Fri Mar 31 13:34:00 2017
From: openssh at tlinx.org (L. A. Walsh)
Date: Thu, 30 Mar 2017 19:34:00 -0700
Subject: X11 forwarding with IPv6 disabled
In-Reply-To: <a46bfc27-7bfb-4eed-f3fb-2b636799e9e2@redhat.com>
References: <a46bfc27-7bfb-4eed-f3fb-2b636799e9e2@redhat.com>
Message-ID: <58DDC018.4090207@tlinx.org>

Jakub Jelen wrote:
> Hello all,
> one more (ever-returning) bug [1] reported recently caught my eye. The 
> problem is that disabling IPv6 in kernel leads to OpenSSH failing to 
> bind localhost IPv6 address and after the fix for CVE-2008-1483 [2] 
> leads to the whole X11 forwarding fail.
---
    I can see the user-friendliness issue being possibly a
good thing, but have some questions that might
support current behavior (as you describe):

    1) Why would openssh be configured to try IPV6 on a system
where it doesn't exist?  Or -- wouldn't it be an error to
try to configure a transport that doesn't exist on that system?
(why not just fix the global defaults?)

    2) How would it be different than asking openssh to configure
Netware sockets (or whatever) and use them?

    3) I'm not sure that expecting an application (like openssh
or others), upon failing some random proto's open, should
fall back to IPv4.  Should IPv4 always be expected to be "the"
fallback if any other proto fails?

    Maybe I'm wondering how a non-existent protocol should be
dealt with and whether or not any such non-existent proto should
fall back to "something" and if that something should be ipv4?

curious...
-linda


From jjelen at redhat.com  Fri Mar 31 19:04:05 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Fri, 31 Mar 2017 10:04:05 +0200
Subject: X11 forwarding with IPv6 disabled
In-Reply-To: <58DDC018.4090207@tlinx.org>
References: <a46bfc27-7bfb-4eed-f3fb-2b636799e9e2@redhat.com>
 <58DDC018.4090207@tlinx.org>
Message-ID: <ba36ac3c-31c8-e13d-ccbe-b87bee87d355@redhat.com>

On 03/31/2017 04:34 AM, L. A. Walsh wrote:
> Jakub Jelen wrote:
>> Hello all,
>> one more (ever-returning) bug [1] reported recently caught my eye. The
>> problem is that disabling IPv6 in kernel leads to OpenSSH failing to
>> bind localhost IPv6 address and after the fix for CVE-2008-1483 [2]
>> leads to the whole X11 forwarding fail.
> ---
>    I can see the user-friendliness issue being possibly a
> good thing, but have some questions that might
> support current behavior (as you describe):
>
>    1) Why would openssh be configured to try IPV6 on a system
> where it doesn't exist?  Or -- wouldn't it be an error to
> try to configure a transport that doesn't exist on that system?
> (why not just fix the global defaults?)

Probably because enabling both of stacks is a default configuration of 
all standard OSes these days.

>    3) I'm not sure that expecting an application (like openssh
> or others), upon failing some random proto's open, should
> fall back to IPv4.  Should IPv4 always be expected to be "the"
> fallback if any other proto fails?

It is not about random proto and fallback to IPv4. It is more about 
handling common use case in a fail-proof way. The proposed solution 
would work also the other way round in case IPv4 is not enabled/configured.

>    Maybe I'm wondering how a non-existent protocol should be
> dealt with and whether or not any such non-existent proto should
> fall back to "something" and if that something should be ipv4?

This is pretty common practice in all the other cases (connecting from 
ssh client is handled correctly) and in all the other tools (browsers, 
...) so I don't see a reason why it should not be handled in the X11 
forwarding initialization code.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From felix at kngnt.org  Fri Mar 31 19:44:12 2017
From: felix at kngnt.org (Felix Rubio)
Date: Fri, 31 Mar 2017 10:44:12 +0200
Subject: Buffer flush when using =?UTF-8?Q?pam=5Finfo?=
Message-ID: <405beeefa214818f98ec88c720e052d0@kngnt.org>

Hi all,

    I had posted a related question to pam developers list, but I have 
continued investigating and seems to be a question for this mailing 
list. I have a script to be used by pam_exec when logging into a system 
through openssh client. This script writes a message in its stdout, that 
is passed to ssh_thread_conv(auth-pam.c) by a call to pam_info, in 
pam_exec.so. The message is passed to ssh_msg_send, which issues a write 
into the corresponent file descriptor.

    The problem is: I never get to see that message in the ssh client. 
OTOH, if I modify pam_exec module to issue a pam_prompt instead of a 
pam_info, the message appears on the ssh client. The relevant code for 
both functionalities in auth-pam.c is:

static int
sshpam_thread_conv(int n, sshpam_const struct pam_message **msg,
     struct pam_response **resp, void *data)
{
  .....
                 case PAM_PROMPT_ECHO_OFF:
                 case PAM_PROMPT_ECHO_ON:
                         buffer_put_cstring(&buffer,
                             PAM_MSG_MEMBER(msg, i, msg));
                         if (ssh_msg_send(ctxt->pam_csock,
                             PAM_MSG_MEMBER(msg, i, msg_style), &buffer) 
== -1)
                                 goto fail;
                         if (ssh_msg_recv(ctxt->pam_csock, &buffer) == 
-1)
                                 goto fail;
                         if (buffer_get_char(&buffer) != PAM_AUTHTOK)
                                 goto fail;
                         reply[i].resp = buffer_get_string(&buffer, 
NULL);
                         break;
                 case PAM_ERROR_MSG:
                 case PAM_TEXT_INFO:
                         buffer_put_cstring(&buffer,
                             PAM_MSG_MEMBER(msg, i, msg));
                         if (ssh_msg_send(ctxt->pam_csock,
                             PAM_MSG_MEMBER(msg, i, msg_style), &buffer) 
== -1)
                                 goto fail;
                         break;
.....
}

As can be seen, the only difference (I have also checked the contents of 
ssh_msg_send) is in the fact that, when pam_prompt is used, a 
ssh_msg_send is followed by a ssh_msg_recv, whereas for a pam_info, only 
the ssh_msg_send is performed.

The OpenSSH version is 7.5p1, and the operating system is CentOS7.3.

Can somebody advice on whether this is a client or a server issue, 
and... yeah.. what can I do?

Thank you!
Felix

-- 
Felix Rubio
"Don't believe what you're told. Double check."