From djm at mindrot.org  Mon May  1 12:09:01 2017
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 May 2017 12:09:01 +1000 (AEST)
Subject: SSH1 deleted
Message-ID: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>

Hi,

I just deleted SSHv1 support in OpenBSD and portable OpenSSH. There's
probably a little dead code still to be expunged, but all user-visible
functionality and the bulk of the supporting infrastructure is gone.

Sic transit gloria mundi.

-d

From dtucker at zip.com.au  Mon May  1 12:40:53 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 1 May 2017 12:40:53 +1000
Subject: SSH1 deleted
In-Reply-To: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>
References: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>
Message-ID: <CALDDTe3Oipu2-chfhFYzdBK5+38xZt=FrtFcsXeN0PFzpbPm=A@mail.gmail.com>

On Mon, May 1, 2017 at 12:09 PM, Damien Miller <djm at mindrot.org> wrote:

> Hi,
>
> I just deleted SSHv1 support in OpenBSD and portable OpenSSH. There's
> probably a little dead code still to be expunged, but all user-visible
> functionality and the bulk of the supporting infrastructure is gone.
>
> Sic transit gloria mundi.
>

Quamvis ejus problems, est etiam a magnus lenimentus super eam telnet.

-- 
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 jmknoble at pobox.com  Mon May  1 23:20:43 2017
From: jmknoble at pobox.com (Jim Knoble)
Date: Mon, 1 May 2017 06:20:43 -0700
Subject: SSH1 deleted
In-Reply-To: <CALDDTe3Oipu2-chfhFYzdBK5+38xZt=FrtFcsXeN0PFzpbPm=A@mail.gmail.com>
References: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>
 <CALDDTe3Oipu2-chfhFYzdBK5+38xZt=FrtFcsXeN0PFzpbPm=A@mail.gmail.com>
Message-ID: <65A3AF70-591C-440B-9B1F-119A5BEB07B3@pobox.com>



-- 
jim knoble | jmknoble at pobox.com

> On Apr 30, 2017, at 19:40, Darren Tucker <dtucker at zip.com.au> wrote:
> 
>> On Mon, May 1, 2017 at 12:09 PM, Damien Miller <djm at mindrot.org> wrote:
>> 
>> Hi,
>> 
>> I just deleted SSHv1 support in OpenBSD and portable OpenSSH. There's
>> probably a little dead code still to be expunged, but all user-visible
>> functionality and the bulk of the supporting infrastructure is gone.
>> 
>> Sic transit gloria mundi.
>> 
> 
> Quamvis ejus problems, est etiam a magnus lenimentus super eam telnet.

Ut cum multa -- linguam latinam, exempli gratia -- pugnatum est multo longior quam exspectavimus.

Ni esperas, ke la dua provo renkontas pli bonan finon.

-- 
jim knoble | jmknoble at pobox.com



From doctor at doctor.nl2k.ab.ca  Mon May  1 23:40:37 2017
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 1 May 2017 07:40:37 -0600
Subject: SSH1 deleted
In-Reply-To: <65A3AF70-591C-440B-9B1F-119A5BEB07B3@pobox.com>
References: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>
 <CALDDTe3Oipu2-chfhFYzdBK5+38xZt=FrtFcsXeN0PFzpbPm=A@mail.gmail.com>
 <65A3AF70-591C-440B-9B1F-119A5BEB07B3@pobox.com>
Message-ID: <20170501134037.GD34615@doctor.nl2k.ab.ca>

On Mon, May 01, 2017 at 06:20:43AM -0700, Jim Knoble wrote:
> 
> 
> -- 
> jim knoble | jmknoble at pobox.com
> 
> > On Apr 30, 2017, at 19:40, Darren Tucker <dtucker at zip.com.au> wrote:
> > 
> >> On Mon, May 1, 2017 at 12:09 PM, Damien Miller <djm at mindrot.org> wrote:
> >> 
> >> Hi,
> >> 
> >> I just deleted SSHv1 support in OpenBSD and portable OpenSSH. There's
> >> probably a little dead code still to be expunged, but all user-visible
> >> functionality and the bulk of the supporting infrastructure is gone.
> >> 
> >> Sic transit gloria mundi.
> >> 
> > 
> > Quamvis ejus problems, est etiam a magnus lenimentus super eam telnet.
> 
> Ut cum multa -- linguam latinam, exempli gratia -- pugnatum est multo longior quam exspectavimus.
> 
> Ni esperas, ke la dua provo renkontas pli bonan finon.
> 
> -- 
> jim knoble | jmknoble at pobox.com
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Getting back to English,  word on USENet is that there is a proposed
open ssl 1.1 patch.

Can it be implemented?

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
BC Keep your province Healthy!! Vote Liberal.

From cristian.ionescu-idbohrn at axis.com  Tue May  2 00:25:41 2017
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Mon, 1 May 2017 16:25:41 +0200 (CEST)
Subject: playing around with removing algos
Message-ID: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>

Example, 'Macs'.

On the man page I read:

"Multiple algorithms must be comma-separated.
...
If the specified value begins with a '-' character, then the
specified algorithms (including wildcards) will be removed"

It seems that just one algo name is supported on such a line, example:

	Macs -umac-64*

But this form is not supported:

	Macs -umac-64*,-hmac-sha1*

nor is this:

	Macs -umac-64*
	Macs -hmac-sha1*

And I have difficulties in finding _one_ pattern that matches _only_ 
the above algo families, but nothing else.

Can you confirm this behaviour?  Can it be improved?


Cheers,

-- 
Cristian

From cristian.ionescu-idbohrn at axis.com  Tue May  2 00:48:46 2017
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Mon, 1 May 2017 16:48:46 +0200 (CEST)
Subject: playing around with removing algos
In-Reply-To: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
Message-ID: <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>

On Mon, 1 May 2017, Cristian Ionescu-Idbohrn wrote:
> 
> Example, 'Macs'.
> 
> On the man page I read:
> 
> "Multiple algorithms must be comma-separated.
> ...
> If the specified value begins with a '-' character, then the
> specified algorithms (including wildcards) will be removed"
> 
> It seems that just one algo name is supported on such a line, example:
> 
> 	Macs -umac-64*
> 
> But this form is not supported:
> 
> 	Macs -umac-64*,-hmac-sha1*
> 
> nor is this:
> 
> 	Macs -umac-64*
> 	Macs -hmac-sha1*
> 
> And I have difficulties in finding _one_ pattern that matches _only_ 
> the above algo families, but nothing else.
> 
> Can you confirm this behaviour?  Can it be improved?

More observations.

After doing one of the above in /etc/ssh/sshd_config:

# sshd -tT | sort | egrep '^macs'
macs umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,
hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,
umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

umac-64* is gone, but I can still use umac-64 at openssh.com to login:

$ ssh -oMacs=umac-64 at openssh.com localhost

Can you confirm this behaviour?


Cheers,

-- 
Cristian

From jjelen at redhat.com  Tue May  2 17:37:50 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 2 May 2017 09:37:50 +0200
Subject: Strange identity ordering with sshclient and agent
In-Reply-To: <CAA0VkZxPgDn-c97b=WQw+SdBnfds9BG-U38epcmb-Ogbub7V_w@mail.gmail.com>
References: <CAA0VkZxPgDn-c97b=WQw+SdBnfds9BG-U38epcmb-Ogbub7V_w@mail.gmail.com>
Message-ID: <dd6581c7-de42-f89f-c1af-161a108d2930@redhat.com>

On 04/27/2017 07:27 PM, Martino Io wrote:
> Hello, I have a rather strange problem with a setup where keys are fed to
> SSH_AGENT and a PAM integration, let me be clear that works flawlessly, the
> only problem I have is that wherever a key is coming from an agent, the
> order seems to be messed up, not honouring the -i option:
> 
> This is the output from a console with the agent disabled and it works as
> it should, I'm specifying the identity manually here (-i
> ~/.ssh/id_rsa_laptop)
> 
> debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
> debug2: key: /home/martino/.ssh/id_rsa_laptop (0x561c908da690), explicit
> debug2: key: /home/martino/.ssh/id_rsa (0x561c908da9d0)
> debug3: send packet: type 5
> debug3: receive packet: type 6
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug3: send packet: type 50
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey
> debug3: start over, passed a different list publickey
> debug3: preferred publickey,keyboard-interactive,password
> debug3: authmethod_lookup publickey
> debug3: remaining preferred: keyboard-interactive,password
> debug3: authmethod_is_enabled publickey
> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: /home/martino/.ssh/id_rsa_laptop
> debug3: send_pubkey_test
> debug3: send packet: type 50
> debug2: we sent a publickey packet, wait for reply
> debug3: receive packet: type 60
> debug1: Server accepts key: pkalg ssh-rsa blen 279
> debug2: input_userauth_pk_ok
> 
> And this is the output where the agent is enabled:
> 
> debug2: key: /home/martino/.ssh/id_rsa (0x55a4dcddd9e0), agent
> debug2: key: /home/martino/.ssh/id_rsa_laptop (0x55a4dcddd6a0), explicit,
> agent
> debug3: send packet: type 5
> debug3: receive packet: type 6
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug3: send packet: type 50
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey
> debug3: start over, passed a different list publickey
> debug3: preferred publickey,keyboard-interactive,password
> debug3: authmethod_lookup publickey
> debug3: remaining preferred: keyboard-interactive,password
> debug3: authmethod_is_enabled publickey
> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: /home/martino/.ssh/id_rsa
> debug3: send_pubkey_test
> debug3: send packet: type 50
> debug2: we sent a publickey packet, wait for reply
> debug3: receive packet: type 60
> debug1: Server accepts key: pkalg ssh-rsa blen 279
> debug2: input_userauth_pk_ok
> 
> The settings are stored in ~/.ssh/config and both identities are added
> correctly to the agent:
> 
> 2048 SHA256: /home/martino/.ssh/id_rsa (RSA)
> 2048 SHA256: /home/martino/.ssh/id_rsa_laptop (RSA)
> 
> 
> The problem lies in the fact that both identities are accepted by the
> server (id_rsa and id_rsa_laptop) but I need the explicit key to be used
> first as it has different ACL settings in the server, not sure why it is
> not working at this point. Any help would be appreciated

This is how it works ever since. The manual page explicitly says that 
the default locations ~/.ssh/id_{rsa,dsa,ecdsa,ed25519} will be used "by 
default". There are various possibilities how to get around that:

  * Use IdentitiesOnly as advised by the man ssh_config to use only the 
listed identities
  * Move the id_rsa away and configure it in ssh_config to get use of it 
in cases you need it.

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From jjelen at redhat.com  Tue May  2 18:03:42 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 2 May 2017 10:03:42 +0200
Subject: playing around with removing algos
In-Reply-To: <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
Message-ID: <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>

On 05/01/2017 04:48 PM, Cristian Ionescu-Idbohrn wrote:
> On Mon, 1 May 2017, Cristian Ionescu-Idbohrn wrote:
>>
>> Example, 'Macs'.
>>
>> On the man page I read:
>>
>> "Multiple algorithms must be comma-separated.
>> ...
>> If the specified value begins with a '-' character, then the
>> specified algorithms (including wildcards) will be removed"
>>
>> It seems that just one algo name is supported on such a line, example:
>>
>> 	Macs -umac-64*
>>
>> But this form is not supported:
>>
>> 	Macs -umac-64*,-hmac-sha1*
>>
>> nor is this:
>>
>> 	Macs -umac-64*
>> 	Macs -hmac-sha1*
>>
>> And I have difficulties in finding _one_ pattern that matches _only_
>> the above algo families, but nothing else.
>>
>> Can you confirm this behaviour?  Can it be improved?

I believe this is expected behavior and limitation of the current 
behavior. The manual page also says

 > For each parameter, the first obtained value will be used. [...]

 > [...] will be removed *from the default set instead of replacing them*.

Therefore:
  * Only the default set is affected
  * The second Macs option is ignored (because Macs are already set)

This might be confusing especially when specifying multiple values and 
improving that would be very nice.

> More observations.
> 
> After doing one of the above in /etc/ssh/sshd_config:
> 
> # sshd -tT | sort | egrep '^macs'
> macs umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,
> hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,
> umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> 
> umac-64* is gone, but I can still use umac-64 at openssh.com to login:
> 
> $ ssh -oMacs=umac-64 at openssh.com localhost
> 
> Can you confirm this behaviour?

I would investigate the debug log with -vvv switches to see what is 
actually offered by server and client.


-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From cristian.ionescu-idbohrn at axis.com  Wed May  3 02:17:47 2017
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Tue, 2 May 2017 18:17:47 +0200 (CEST)
Subject: playing around with removing algos
In-Reply-To: <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
Message-ID: <alpine.DEB.2.20.1705021756170.2919@enwn.fr.nkvf.pbz>

On Tue, 2 May 2017, Jakub Jelen wrote:
> 
> I believe this is expected behavior and limitation of the current behavior.
> The manual page also says
> 
> > For each parameter, the first obtained value will be used. [...]
> 
> > [...] will be removed *from the default set instead of replacing them*.
> 
> Therefore:
>  * Only the default set is affected
>  * The second Macs option is ignored (because Macs are already set)

Yes.  I missed that.  Sorry :(

> This might be confusing especially when specifying multiple values and
> improving that would be very nice.

Yes, please.

> I would investigate the debug log with -vvv switches to see what is 
> actually offered by server and client.

Alright, I just did:

$ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac'
debug2: MACs ctos: umac-64 at openssh.com
debug2: MACs stoc: umac-64 at openssh.com
debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

No error/warning/anything.

I should also mention that this is the Debian packaged openssh 7.5p1.
It applies some 31 patches to the source.  I can't tell if they 
interfere with the proper behaviour, it doesn't seem so, but I can't 
exclude the risc.  Colin might.


Cheers,

-- 
Cristian

From cjwatson at debian.org  Wed May  3 02:41:11 2017
From: cjwatson at debian.org (Colin Watson)
Date: Tue, 2 May 2017 17:41:11 +0100
Subject: playing around with removing algos
In-Reply-To: <alpine.DEB.2.20.1705021756170.2919@enwn.fr.nkvf.pbz>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
 <alpine.DEB.2.20.1705021756170.2919@enwn.fr.nkvf.pbz>
Message-ID: <20170502164110.GE2509@riva.ucam.org>

On Tue, May 02, 2017 at 06:17:47PM +0200, Cristian Ionescu-Idbohrn wrote:
> $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac'
> debug2: MACs ctos: umac-64 at openssh.com
> debug2: MACs stoc: umac-64 at openssh.com
> debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> debug2: MACs stoc: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> 
> No error/warning/anything.
> 
> I should also mention that this is the Debian packaged openssh 7.5p1.
> It applies some 31 patches to the source.  I can't tell if they 
> interfere with the proper behaviour, it doesn't seem so, but I can't 
> exclude the risc.  Colin might.

A clean build from upstream git master produces identical output from
the above test command.

-- 
Colin Watson                                       [cjwatson at debian.org]

From cristian.ionescu-idbohrn at axis.com  Wed May  3 03:21:20 2017
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Tue, 2 May 2017 19:21:20 +0200 (CEST)
Subject: playing around with removing algos
In-Reply-To: <20170502164110.GE2509@riva.ucam.org>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
 <alpine.DEB.2.20.1705021756170.2919@enwn.fr.nkvf.pbz>
 <20170502164110.GE2509@riva.ucam.org>
Message-ID: <alpine.DEB.2.20.1705021918490.2919@enwn.fr.nkvf.pbz>

On Tue, 2 May 2017, Colin Watson wrote:
> On Tue, May 02, 2017 at 06:17:47PM +0200, Cristian Ionescu-Idbohrn wrote:
> > $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac'
> > debug2: MACs ctos: umac-64 at openssh.com
> > debug2: MACs stoc: umac-64 at openssh.com
> > debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> > debug2: MACs stoc: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> > 
> > No error/warning/anything.
> > 
> > I should also mention that this is the Debian packaged openssh 7.5p1.
> > It applies some 31 patches to the source.  I can't tell if they 
> > interfere with the proper behaviour, it doesn't seem so, but I can't 
> > exclude the risc.  Colin might.
> 
> A clean build from upstream git master produces identical output from
> the above test command.

Thanks.  This points then to an upstream bug.


Cheers,

-- 
Cristian

From jjelen at redhat.com  Wed May  3 16:14:20 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 3 May 2017 08:14:20 +0200
Subject: playing around with removing algos
In-Reply-To: <alpine.DEB.2.20.1705021918490.2919@enwn.fr.nkvf.pbz>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
 <alpine.DEB.2.20.1705021756170.2919@enwn.fr.nkvf.pbz>
 <20170502164110.GE2509@riva.ucam.org>
 <alpine.DEB.2.20.1705021918490.2919@enwn.fr.nkvf.pbz>
Message-ID: <ed1deed8-fe18-a81a-daf3-aaa3b4ae1d13@redhat.com>

On 05/02/2017 07:21 PM, Cristian Ionescu-Idbohrn wrote:
> On Tue, 2 May 2017, Colin Watson wrote:
>> On Tue, May 02, 2017 at 06:17:47PM +0200, Cristian Ionescu-Idbohrn wrote:
>>> $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac'
>>> debug2: MACs ctos: umac-64 at openssh.com
>>> debug2: MACs stoc: umac-64 at openssh.com
>>> debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
>>> debug2: MACs stoc: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
>>>
>>> No error/warning/anything.
>>>
>>> I should also mention that this is the Debian packaged openssh 7.5p1.
>>> It applies some 31 patches to the source.  I can't tell if they
>>> interfere with the proper behaviour, it doesn't seem so, but I can't
>>> exclude the risc.  Colin might.
>>
>> A clean build from upstream git master produces identical output from
>> the above test command.
> 
> Thanks.  This points then to an upstream bug.

My guess is that you are using chacha20-poly1305 at openssh.com cipher (not 
visible from this output), which does not need MAC (the message 
authentication is already part of the cipher definition -- poly1305). 
Therefore it does not need to agree on common MAC and it just works 
without that.

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

From jjelen at redhat.com  Wed May  3 18:27:10 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 3 May 2017 10:27:10 +0200
Subject: Changed behavior of ControlPath too long errors
Message-ID: <91836348-c6da-edac-2e4d-56e690156baa@redhat.com>

Hello,
recently we noticed that the behavior of too long ControlPath sockets 
changed in OpenSSH 6.7 from non-fatal error to fatal. The change was 
brought in by the unix-domain socket forwarding [1] and is not 
completely clear if it is intentional or not. It can be simply 
reproduced by trying to set up long ControlPath (common in Ansible):

ssh -o 
ControlPath=/var/lib/very-long-installer/.ansible/cp/ansible-ssh-%h-%p-%r 
-o ControlMaster=yes jenkins.localdomain hostname
ControlPath 
"/var/lib/very-long-installer/.ansible/cp/ansible-ssh-jenkins-localdomain-22-installer.RpqsfHyo1aAYZIg2" 
too long for Unix domain socket

The OpenSSH 6.6p1 successfully falls back to not using MUX (goto 
disable_mux_master;), but newer versions interpret it as a fatal errors 
and exit.

I understand that I might be late for party and being strict about 
configuration options is a good thing, but having this functionality 
backward compatible would be very helpful for existing scripts.

Is this intentional change? Can we stick back to the old behavior?

[1] https://github.com/Jakuje/openssh-portable/commit/7acefbbc

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

From dtucker at zip.com.au  Wed May  3 20:28:59 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 3 May 2017 20:28:59 +1000
Subject: SSH1 deleted
In-Reply-To: <20170501134037.GD34615@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>
 <CALDDTe3Oipu2-chfhFYzdBK5+38xZt=FrtFcsXeN0PFzpbPm=A@mail.gmail.com>
 <65A3AF70-591C-440B-9B1F-119A5BEB07B3@pobox.com>
 <20170501134037.GD34615@doctor.nl2k.ab.ca>
Message-ID: <CALDDTe0-jj=VXqdB1hFraJn+C04qX0dsUezCLgLQDTQgYD56rQ@mail.gmail.com>

On Mon, May 1, 2017 at 11:40 PM, The Doctor <doctor at doctor.nl2k.ab.ca>
wrote:

> [...]
> Getting back to English,  word on USENet is that there is a proposed
> open ssl 1.1 patch.
>
> Can it be implemented?


The problems with doing so have been mentioned previously on this list
(tl;dr: lack of forward compatibility between openssl 1.0.x and 1.1.x APIs).

https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html
https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035458.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 dtucker at zip.com.au  Wed May  3 22:16:50 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 3 May 2017 22:16:50 +1000
Subject: Changed behavior of ControlPath too long errors
In-Reply-To: <91836348-c6da-edac-2e4d-56e690156baa@redhat.com>
References: <91836348-c6da-edac-2e4d-56e690156baa@redhat.com>
Message-ID: <CALDDTe0Sn-5pgAafOUbFQLhNF0+ZXALsfY9XYzrTqnW=M0m68w@mail.gmail.com>

On Wed, May 3, 2017 at 6:27 PM, Jakub Jelen <jjelen at redhat.com> wrote:

> [...]
> Is this intentional change? Can we stick back to the old behavior?
>

Leaving aside whether or not it was a deliberate change, it was more than
three years ago so complaints now about backward compatibility seem, well,
a bit late.

-- 
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 mh+openssh-unix-dev at zugschlus.de  Thu May  4 00:35:22 2017
From: mh+openssh-unix-dev at zugschlus.de (Marc Haber)
Date: Wed, 3 May 2017 16:35:22 +0200
Subject: some thoughts about ssh-add -c -t
Message-ID: <20170503143522.GD2481@torres.zugschlus.de>

Hi,

first let me thank you all for writing and maintainig OpenSSH. Working
with Linux for almost 20 years, my life would be totally different
without OpenSSH. And it wouldn't be any better.

I have recently experimented with ssh-add -c -t and AddKeysToAgent to
reduce attack vectors against my ssh-agent connections. While this seems
to me generally useable, having a graphical ssh-askpass pop up so often
has been proven to be generally annoying.

Additionally, I frequently ssh to another host with AgentForwarding and
X11 Forwarding disabled, start another agent there, load a key there and
ssh to a second host. That way, the second ssh-agent doesn't have a
display to invoke ssh-askpass.

Is there a way to have a non-graphical ssh-askpass on the terminal, even
if that means to have the ssh-client that was just invoked prompt for
confirmation like it does for the passphrase with AddKeysToAgent
enabled?

Also, how about allowing wildcards in IdentityFile, therefore allowing
things like IdentityFile %d/.ssh/id_* ?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

From doctor at doctor.nl2k.ab.ca  Thu May  4 00:32:10 2017
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 3 May 2017 08:32:10 -0600
Subject: SSH1 deleted
In-Reply-To: <CALDDTe0-jj=VXqdB1hFraJn+C04qX0dsUezCLgLQDTQgYD56rQ@mail.gmail.com>
References: <alpine.BSO.2.20.1705011207080.2134@natsu.mindrot.org>
 <CALDDTe3Oipu2-chfhFYzdBK5+38xZt=FrtFcsXeN0PFzpbPm=A@mail.gmail.com>
 <65A3AF70-591C-440B-9B1F-119A5BEB07B3@pobox.com>
 <20170501134037.GD34615@doctor.nl2k.ab.ca>
 <CALDDTe0-jj=VXqdB1hFraJn+C04qX0dsUezCLgLQDTQgYD56rQ@mail.gmail.com>
Message-ID: <20170503143210.GA65860@doctor.nl2k.ab.ca>

On Wed, May 03, 2017 at 08:28:59PM +1000, Darren Tucker wrote:
> On Mon, May 1, 2017 at 11:40 PM, The Doctor <doctor at doctor.nl2k.ab.ca>
> wrote:
> 
> > [...]
> > Getting back to English,  word on USENet is that there is a proposed
> > open ssl 1.1 patch.
> >
> > Can it be implemented?
> 
> 
> The problems with doing so have been mentioned previously on this list
> (tl;dr: lack of forward compatibility between openssl 1.0.x and 1.1.x APIs).
> 
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035458.html
>

The other problem is that openssl 1.0.X will be removed.

Only 1.0.2 will remain and that will come to an end.

OPenssl 1.0.1 is now dead.

Certainly you can do

if (openssl is less than 1.1)

Code

else

Code accordingly

> -- 
> 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.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
BC Keep your province Healthy!! Vote Liberal.

From cristian.ionescu-idbohrn at axis.com  Thu May  4 01:52:17 2017
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Wed, 3 May 2017 17:52:17 +0200 (CEST)
Subject: *FLAWED* Re: playing around with removing algos
In-Reply-To: <ed1deed8-fe18-a81a-daf3-aaa3b4ae1d13@redhat.com>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
 <alpine.DEB.2.20.1705021756170.2919@enwn.fr.nkvf.pbz>
 <20170502164110.GE2509@riva.ucam.org>
 <alpine.DEB.2.20.1705021918490.2919@enwn.fr.nkvf.pbz>
 <ed1deed8-fe18-a81a-daf3-aaa3b4ae1d13@redhat.com>
Message-ID: <alpine.DEB.2.20.1705031742010.26888@enwn.fr.nkvf.pbz>

On Wed, 3 May 2017, Jakub Jelen wrote:
> On 05/02/2017 07:21 PM, Cristian Ionescu-Idbohrn wrote:
> > On Tue, 2 May 2017, Colin Watson wrote:
> > > On Tue, May 02, 2017 at 06:17:47PM +0200, Cristian Ionescu-Idbohrn wrote:
> > > > $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i
> > > > 'macs|umac'
> > > > debug2: MACs ctos: umac-64 at openssh.com
> > > > debug2: MACs stoc: umac-64 at openssh.com
> > > > debug2: MACs ctos:
> > > > umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> > > > debug2: MACs stoc:
> > > > umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> > > > 
> > > > No error/warning/anything.
> > > > 
> > > > I should also mention that this is the Debian packaged openssh 7.5p1.
> > > > It applies some 31 patches to the source.  I can't tell if they
> > > > interfere with the proper behaviour, it doesn't seem so, but I can't
> > > > exclude the risc.  Colin might.
> > > 
> > > A clean build from upstream git master produces identical output from
> > > the above test command.
> > 
> > Thanks.  This points then to an upstream bug.
> 
> My guess is that you are using chacha20-poly1305 at openssh.com cipher 
> (not visible from this output), which does not need MAC (the message 
> authentication is already part of the cipher definition -- 
> poly1305). Therefore it does not need to agree on common MAC and it 
> just works without that.

Very good guess ;)

$ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i kex:
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none

Thanks.  That made me read PROTOCOL.chacha20poly1305.

Another check, forcing ciphers to something else, produces expected 
result:

$ ssh -oMacs=umac-64 at openssh.com -ociphers=aes128-ctr localhost :
Unable to negotiate with 127.0.0.1 port 22: no matching MAC found. 
Their offer: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

Not a bug there, just user confusion.


Cheers,

-- 
Cristian

From devin.nate at QHRtech.com  Thu May  4 05:43:15 2017
From: devin.nate at QHRtech.com (Devin Nate)
Date: Wed, 3 May 2017 19:43:15 +0000
Subject: OpenSSH contract development / patch
Message-ID: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>

Hi OpenSSH developers;

Thank you for your amazing work.

I?m emailing to see if any knowledgeable OpenSSH developer is willing to help us review / revamp some patches we have for OpenSSH, and provide advice on some of the more advanced uses of OpenSSH. This would be a for pay contract engagement. We are trying to be super respectful of the process, and are happy to be very creative ? we are willing to open source our patches, pay directly, donate to openssh/openbsd, donate hardware if applicable, etc., as desired by a developer. Having contributed to open source before, but never having tried to request contract work before, we?re trying to be very flexible.

We are looking for a review of our current patches, especially with an eye to security and completeness. Our current patches introduce:
- A similar feature to permitopen in the authorized_keys file, except for gateway ports. Whereas permitopen defines what an ssh -L can do, our permitgwopen option does similar for what a ssh -R client could request.
- Defaults sshd to not open ports, unless explicitely permitted by a permitopen or permitgwopen statement.
- Except as permitted otherwise, no data should be forwardable one way or another.
- Basically, make a ssh client unable to open anything except that which is explicitly defined at the server using authorized_keys methods.

Additionally, we?re looking for some creative advice around handling thousands of keys in our specific environment.

As I said, we?re more than happy to open source our patches or development (or not) ? I?m sensitive to the fact that patches we develop may never become part of OpenSSH mainline, and we?re fine with that. Or if they do become part of OpenSSH mainline, we?re fine to sign off on that too. We haven?t done so far because we really aren?t looking to manage a public debate - we needed to solve a problem, and have a working solution and want to readdress.

I want to thank the key openssh contributers I?ve reached out to so far for their consideration about this request ? thank you for your time and attention.

Prospective interested parties should contact me via email, or if desired by public posting in response to my email.


Thanks,
Devin Nate
---
Director of Technology, QHR Technologies Inc.





From adam at continusec.com  Thu May  4 09:37:59 2017
From: adam at continusec.com (Adam Eijdenberg)
Date: Thu, 4 May 2017 09:37:59 +1000
Subject: OpenSSH contract development / patch
In-Reply-To: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
Message-ID: <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>

On Thu, May 4, 2017 at 5:43 AM, Devin Nate <devin.nate at qhrtech.com> wrote:
> Additionally, we?re looking for some creative advice around handling thousands of keys in our specific environment.

Hi Devin, have you looked at using openssh certificates to help manage
your key distribution problem? By issuing host certificates signed by
a common CA, it means that your clients need only a single entry in
their known_hosts file, and by issuing user certificates signed by a
common CA, you can simplify management of the authorized_keys file (or
their certificate equivalent, authorized_principals).

While the feature has been around for a while now (and is really
useful), there doesn't seem to be huge amount of documentation around
it. I found the following useful when getting a client of my running
with it: https://ef.gy/hardening-ssh and in their case we ended up
open-sourcing the command-line tool we built that does SSO with their
IdP, fetch a short-lived certificate and then automatically configure
the client SSH to use it: https://github.com/continusec/geecert

Facebook also published a recent article about their use of SSH
certificates here:
https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/

From lists at spuddy.org  Thu May  4 10:44:35 2017
From: lists at spuddy.org (Stephen Harris)
Date: Wed, 3 May 2017 20:44:35 -0400
Subject: OpenSSH contract development / patch
In-Reply-To: <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
 <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
Message-ID: <20170504004435.GA31986@mercury7.spuddy.org>

On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote:
> Hi Devin, have you looked at using openssh certificates to help manage
[...]
> While the feature has been around for a while now (and is really
> useful), there doesn't seem to be huge amount of documentation around
> it. I found the following useful when getting a client of my running

Yeah, when I wrote about it last year I didn't find many clients
(just the openssh client) understood it:
  https://www.sweharris.org/post/2016-10-30-ssh-certs/

How many clients do work with CA signed keys?

-- 

rgds
Stephen

From djm at mindrot.org  Thu May  4 11:01:42 2017
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 May 2017 11:01:42 +1000 (AEST)
Subject: OpenSSH contract development / patch
In-Reply-To: <20170504004435.GA31986@mercury7.spuddy.org>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
 <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
 <20170504004435.GA31986@mercury7.spuddy.org>
Message-ID: <alpine.BSO.2.20.1705041050330.2134@natsu.mindrot.org>



On Wed, 3 May 2017, Stephen Harris wrote:

> On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote:
> > Hi Devin, have you looked at using openssh certificates to help manage
> [...]
> > While the feature has been around for a while now (and is really
> > useful), there doesn't seem to be huge amount of documentation around
> > it. I found the following useful when getting a client of my running
> 
> Yeah, when I wrote about it last year I didn't find many clients
> (just the openssh client) understood it:
>   https://www.sweharris.org/post/2016-10-30-ssh-certs/

Nice guide. You might want to mention hostname canonicalisation[1] in
relation to host certs, it keeps things happy when users specify
unqualified hostnames.

> How many clients do work with CA signed keys?

The Go x/crypto/ssh package supports OpenSSH certificates and offers
a callback that's pretty easy to hook up with them. I don't know whether
anybody is using it for that though.

I do know of some of certified host keys in the wild with only OpenSSH
as the client.

-d

[1] http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html

From ronf at timeheart.net  Thu May  4 12:07:02 2017
From: ronf at timeheart.net (Ron Frederick)
Date: Wed, 3 May 2017 19:07:02 -0700
Subject: OpenSSH contract development / patch
In-Reply-To: <20170504004435.GA31986@mercury7.spuddy.org>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
 <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
 <20170504004435.GA31986@mercury7.spuddy.org>
Message-ID: <1B08EDA0-9056-4B92-8BED-87152F7BAF01@timeheart.net>

On May 3, 2017, at 5:44 PM, Stephen Harris <lists at spuddy.org> wrote:
> On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote:
>> Hi Devin, have you looked at using openssh certificates to help manage
> [...]
>> While the feature has been around for a while now (and is really
>> useful), there doesn't seem to be huge amount of documentation around
>> it. I found the following useful when getting a client of my running
> 
> Yeah, when I wrote about it last year I didn't find many clients
> (just the openssh client) understood it:
>  https://www.sweharris.org/post/2016-10-30-ssh-certs/
> 
> How many clients do work with CA signed keys?


My AsyncSSH package for Python supports OpenSSH-format certificates. For more info, check out http://asyncssh.readthedocs.io <http://asyncssh.readthedocs.io/>.
-- 
Ron Frederick
ronf at timeheart.net




From mindrot at hda3.com  Thu May  4 13:41:37 2017
From: mindrot at hda3.com (Peter Moody)
Date: Wed, 3 May 2017 20:41:37 -0700
Subject: OpenSSH contract development / patch
In-Reply-To: <alpine.BSO.2.20.1705041050330.2134@natsu.mindrot.org>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
 <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
 <20170504004435.GA31986@mercury7.spuddy.org>
 <alpine.BSO.2.20.1705041050330.2134@natsu.mindrot.org>
Message-ID: <CADbMJxmL3Dwc0Ed5ByhX7f7iJaXDTAwPN8M1CSL-F2S_4wZPGA@mail.gmail.com>

On Wed, May 3, 2017 at 6:01 PM, Damien Miller <djm at mindrot.org> wrote:
>
>
> On Wed, 3 May 2017, Stephen Harris wrote:
>
>> On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote:
>> > Hi Devin, have you looked at using openssh certificates to help manage
>> [...]
>> > While the feature has been around for a while now (and is really
>> > useful), there doesn't seem to be huge amount of documentation around
>> > it. I found the following useful when getting a client of my running
>>
>> Yeah, when I wrote about it last year I didn't find many clients
>> (just the openssh client) understood it:
>>   https://www.sweharris.org/post/2016-10-30-ssh-certs/
>
> Nice guide. You might want to mention hostname canonicalisation[1] in
> relation to host certs, it keeps things happy when users specify
> unqualified hostnames.
>
>> How many clients do work with CA signed keys?
>
> The Go x/crypto/ssh package supports OpenSSH certificates and offers
> a callback that's pretty easy to hook up with them.

and how

> I don't know whether anybody is using it for that though.

we use the go stuff to write certs to to an ssh-agent process, so it's
still just an openssh client that's using the resulting cert/key

the terminal emulation stuff scares me more than writing/maintaining
an ssh ca, so I've never really tried to write a full openssh client
replacement.

> I do know of some of certified host keys in the wild with only OpenSSH
> as the client.
>
> -d
>
> [1] http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From edgar.zaiser at ipcomm.de  Fri May  5 01:09:41 2017
From: edgar.zaiser at ipcomm.de (Edgar Zaiser)
Date: Thu, 4 May 2017 17:09:41 +0200 (CEST)
Subject: Support for RFC6187
Message-ID: <000a01d2c4e8$7498e680$5dcab380$@ipcomm.de>

Hello,



I was wondering if there?s any reason why openssh is not supporting server
authentication using ?x509v3-rsa2048-sha256? which is defined in RFC6187?



Since it is recommended by the official document in Germany, namely
?BSI-TR-02102-4?, maybe it?s worth going for it




Greetings,



Mit freundlichen Gr??en / Best regards

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

Dipl. Ing. Edgar Zaiser


IPCOMM GmbH
Walter-Bouhon-Stra?e 4
90427 N?rnberg
Germany

Tel.: +49 911 18 07 91-62
Fax: +49 911 18 07 91-10
 <http://www.ipcomm.de/> http://www.ipcomm.de



 <http://www.ipcomm.de/article/Workshop/de/sheet.html>

JETZT NEU! Informieren Sie sich ?ber unser Produktportfolio und unser
Leistungsspektrum bei einem kostenlosen
<http://www.ipcomm.de/article/Workshop/de/sheet.html> Webinar, live und
online, oder entscheiden Sie sich f?r eine unserer
<http://www.ipcomm.de/article/Workshop/de/sheet.html> Basis- oder
Expertenschulungen aus erster Hand, die Ihrer jeweiligen Situation und
Ihren Anforderungen Rechnung tragen.
NEW! We will be glad to give you the information about our product
portfolio and our range of services in a free
<http://www.ipcomm.de/article/Workshop/de/sheet.html> webinar, live and
online. Or you decide to participate in a first-hand
<http://www.ipcomm.de/article/Workshop/de/sheet.html> basic course or
expert training that meet your individual situation and requirements.

Gesch?ftsf?hrer / General Manager: Artur Votteler

Sitz der Gesellschaft / Headquarters: D-90427 Nuremberg, Germany

Amtsgericht / Local Court: Nuremberg - HR B 31759

WEEE-Reg.-Nr. / WEE-Reg.-No.: DE51203130

UST-IDNR.: DE813859506

Hinweis: Diese E-Mail und etwaige Anlagen k?nnen Betriebs- oder
Gesch?ftsgeheimnisse, dem Anwaltsgeheimnis unterliegende oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich
erhalten haben, ist Ihnen der Status dieser E-Mail bekannt. Bitte
benachrichtigen Sie uns in diesem Fall sofort durch Antwort-Mail und
l?schen Sie diese E-Mail nebst etwaigen Anlagen von Ihrem System. Ebenso
d?rfen Sie diese E-Mail oder seine Anlagen nicht kopieren oder an Dritte
weitergeben. Vielen Dank.




From devin.nate at QHRtech.com  Fri May  5 02:43:26 2017
From: devin.nate at QHRtech.com (Devin Nate)
Date: Thu, 4 May 2017 16:43:26 +0000
Subject: OpenSSH contract development / patch
In-Reply-To: <20170504004435.GA31986@mercury7.spuddy.org>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
 <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
 <20170504004435.GA31986@mercury7.spuddy.org>
Message-ID: <11E2C54E-EE7D-4FB4-BD95-AF8D8C2F12C6@qhrtech.com>

Thank you to all that have replied so far, I appreciate your time.

1. For anyone who may be interested, I have attached our current patch. If others feel it helpful, feel free to use. It is released under the terms of the OpenSSH project. The intention of this patch is:
a. This adds a permitgwport option for the authorized_keys file handling, allowing that file to control what ssh -R options a client may submit.
b. This makes sshd require a permitopen option for any ports to be allowed. i.e. if no permitopen appears, then no ssh -L ports will be forwarded.
c. This patch has been somewhat tested, but anyone that wants to use should review on their own.

2. Our thought is combining the AuthorizedKeysCommand with the key, and then gluing the port forward firewall rules our system builds. Our users are all AD so we have some extra items we want to do. Our problem isn?t lack of vision or understanding, it?s lack of time ? hence me trying to find and pay for smart people and their time!

Thanks,
Devin




On 2017-05-03, 6:44 PM, "Stephen Harris" <lists at spuddy.org> wrote:

    On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote:
    > Hi Devin, have you looked at using openssh certificates to help manage
    [...]
    > While the feature has been around for a while now (and is really
    > useful), there doesn't seem to be huge amount of documentation around
    > it. I found the following useful when getting a client of my running
    
    Yeah, when I wrote about it last year I didn't find many clients
    (just the openssh client) understood it:
      https://www.sweharris.org/post/2016-10-30-ssh-certs/
    
    How many clients do work with CA signed keys?
    
    -- 
    
    rgds
    Stephen
    
    


From gbdj at gbdj.ru  Fri May  5 02:45:42 2017
From: gbdj at gbdj.ru (Anton Worshevsky)
Date: Thu, 4 May 2017 20:45:42 +0400
Subject: sshd: SSH_CLIENT_CERT and SSH_CLIENT_PUBKEY env variables
In-Reply-To: <e4d074d5-0eb0-7d8a-07c1-20687289c0df@redhat.com>
References: <20170426070016.3e5c9d91@beer.gbdj.ru>
 <e4d074d5-0eb0-7d8a-07c1-20687289c0df@redhat.com>
Message-ID: <20170504204542.0c58d2a0@beer.gbdj.ru>

On Wed, 26 Apr 2017 10:52:07 +0200
Jakub Jelen <jjelen at redhat.com> wrote:

JJ> > There are environment variables SSH_CLIENT and SSH_CONNECTION
JJ> > with information about client of current session.
JJ> > 
JJ> > I want to implement new variables with info about credentials used for session authentication.
JJ> > Such as:
JJ> > 
JJ> > SSH_CLIENT_CERT
JJ> > SSH_CLIENT_CERT_ID
JJ> > SSH_CLIENT_CERT_PRINCIPALS
JJ> > 
JJ> > SSH_CLIENT_PUBKEY
JJ> > SSH_CLIENT_PUBKEY_FINGERPRINT
JJ> > 
JJ> > Some of that information available in logs but not inside the session.
JJ> > Is there good reason why it's not implemented yet?
JJ> > Do i need to hold myself from writing it? =)
JJ> 
JJ> very similar thing was already implemented by and waits for review, more 
JJ> use cases or higher interest by users:
JJ> 
JJ> https://bugzilla.mindrot.org/show_bug.cgi?id=2408
JJ> 
JJ> This creates variables SSH_USER_AUTH which contains all the successfully 
JJ> used authentication methods with all the needed information. It also 
JJ> provides configuration options to expose these information to PAM (for 
JJ> possible additional authentication methods outside of SSH) or to user 
JJ> session.
JJ> 
JJ> Rather than implementing something new, it would be better to work on 
JJ> improving this feature to suit your needs and merging it upstream.

Thank you for pointing me to the right direction.

After reading the patch I see now it's not so easy because of privilege separation.
Also PAM support will be usable in much more use cases.
I can not provide a review from security standpoint, 
but I plan to test shell use case and enhance it if needed.

My use case:
Use sshd for authentication
but expose verified pubkey/certificate to API server application
for sophisticated authorization by role based access control.
PAM is not used by several reasons.

Regards,

--

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

From devin.nate at QHRtech.com  Fri May  5 03:55:47 2017
From: devin.nate at QHRtech.com (Devin Nate)
Date: Thu, 4 May 2017 17:55:47 +0000
Subject: OpenSSH contract development / patch
In-Reply-To: <20170504004435.GA31986@mercury7.spuddy.org>
References: <686513F6-E6C8-4F23-8634-8C60966BC116@qhrtech.com>
 <CAD0Csb5_EdrpAmDJvwbM6ukqhfkSdATz6H-9+Y64qENKY7u1EQ@mail.gmail.com>
 <20170504004435.GA31986@mercury7.spuddy.org>
Message-ID: <2A34E8F7-6148-47E0-8333-35F2F3C3EC7F@qhrtech.com>

Sorry to double post. I see the mailing list does not prefer attachments.

permitgwport patch inline here, and changes behavior to require permitopen in an authorized_keys file, otherwise no ports may be opened (default deny).

Thanks,
Devin


permitgwports-and-permitopen-mandatory-openssh-7.2p2.patch 


--- auth-options.c.orig	2016-05-02 11:25:41.420811342 -0600
+++ auth-options.c	2016-05-02 13:06:23.149347634 -0600
@@ -81,6 +81,7 @@
 	authorized_principals = NULL;
 	forced_tun_device = -1;
 	channel_clear_permitted_opens();
+	channel_clear_permitted_gatewayports();
 }
 
 /*
@@ -326,6 +327,51 @@
 			/* deny access */
 			return 0;
 		}
+		cp = "permitgwport=\"";
+		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
+			char *p;
+			int port;
+			char *patterns = xmalloc(strlen(opts) + 1);
+
+			opts += strlen(cp);
+			i = 0;
+			while (*opts) {
+				if (*opts == '"')
+					break;
+				if (*opts == '\\' && opts[1] == '"') {
+					opts += 2;
+					patterns[i++] = '"';
+					continue;
+				}
+				patterns[i++] = *opts++;
+			}
+			if (!*opts) {
+				debug("%.100s, line %lu: missing end quote",
+				    file, linenum);
+				auth_debug_add("%.100s, line %lu: missing "
+				    "end quote", file, linenum);
+				free(patterns);
+				goto bad_option;
+			}
+			patterns[i] = '\0';
+			opts++;
+			p = patterns;
+			port = a2port(p);
+			if (port <= 0 || port >= 65536) {
+				debug("%.100s, line %lu: Bad permitgwport "
+				    "specification <%.100s>", file, linenum,
+				    patterns);
+				auth_debug_add("%.100s, line %lu: "
+				    "Bad permitgwport specification", file,
+				    linenum);
+				free(patterns);
+				goto bad_option;
+			}
+			if ((options.allow_tcp_forwarding & FORWARD_REMOTE) != 0)
+				channel_add_permitted_gatewayports(port);
+			free(patterns);
+			goto next_option;
+		}
 		cp = "permitopen=\"";
 		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
 			char *host, *p;
--- channels.c.orig	2016-05-02 11:18:46.095511183 -0600
+++ channels.c	2016-05-03 16:50:46.033883347 -0600
@@ -135,6 +135,12 @@
 /* Number of permitted host/port pair in the array permitted by the admin. */
 static int num_adm_permitted_opens = 0;
 
+/* List of all permitted ports allowed to be gateway ports by the user */
+static int *permitted_gatewayports = NULL;
+
+/* Number of permitted ports allowed to be gateway ports by the user */
+static int num_permitted_gatewayports = 0;
+
 /* special-case port number meaning allow any port */
 #define FWD_PERMIT_ANY_PORT	0
 
@@ -3303,6 +3309,24 @@
 	return 1;
 }
 
+int
+gatewayport_permit(int requestedport)
+{
+	int i, permit = 0;
+	for (i = 0; i < num_permitted_gatewayports; i++) {
+		if (permitted_gatewayports[i] == requestedport) {
+			permit = 1;
+			break;
+		}
+	}
+	if (!permit) {
+		logit("Received request for gateway port %d, "
+		    "but the request was denied.", requestedport);
+		return 0;
+	}
+	return 1;
+}
+
 /*
  * Note that in the listen host/port case
  * we don't support FWD_PERMIT_ANY_PORT and
@@ -3482,8 +3506,8 @@
 void
 channel_permit_all_opens(void)
 {
-	if (num_permitted_opens == 0)
-		all_opens_permitted = 1;
+	/* always require explicit permitopens */
+	all_opens_permitted = 0;
 }
 
 void
@@ -3503,6 +3527,16 @@
 	all_opens_permitted = 0;
 }
 
+void
+channel_add_permitted_gatewayports(int port)
+{
+	debug("allow gatewayport %d", port);
+	permitted_gatewayports = xreallocarray(permitted_gatewayports,
+	    num_permitted_gatewayports + 1, sizeof(*permitted_gatewayports));
+	permitted_gatewayports[num_permitted_gatewayports] = port;
+	num_permitted_gatewayports++;
+}
+
 /*
  * Update the listen port for a dynamic remote forward, after
  * the actual 'newport' has been allocated. If 'newport' < 0 is
@@ -3577,6 +3611,14 @@
 }
 
 void
+channel_clear_permitted_gatewayports(void)
+{
+	free(permitted_gatewayports);
+	permitted_gatewayports = NULL;
+	num_permitted_gatewayports = 0;
+}
+
+void
 channel_clear_adm_permitted_opens(void)
 {
 	int i;
--- channels.h.orig	2016-05-02 11:27:24.917708255 -0600
+++ channels.h	2016-05-02 18:55:21.789555565 -0600
@@ -261,10 +261,12 @@
 void	 channel_set_af(int af);
 void     channel_permit_all_opens(void);
 void	 channel_add_permitted_opens(char *, int);
+void	 channel_add_permitted_gatewayports(int);
 int	 channel_add_adm_permitted_opens(char *, int);
 void	 channel_disable_adm_local_opens(void);
 void	 channel_update_permitted_opens(int, int);
 void	 channel_clear_permitted_opens(void);
+void	 channel_clear_permitted_gatewayports(void);
 void	 channel_clear_adm_permitted_opens(void);
 void 	 channel_print_adm_permitted_opens(void);
 int      channel_input_port_forward_request(int, struct ForwardOptions *);
@@ -281,6 +283,7 @@
 int	 channel_cancel_rport_listener(struct Forward *);
 int	 channel_cancel_lport_listener(struct Forward *, int, struct ForwardOptions *);
 int	 permitopen_port(const char *);
+int	 gatewayport_permit(int);
 
 /* x11 forwarding */
 
--- serverloop.c.orig	2016-05-02 17:15:09.745831104 -0600
+++ serverloop.c	2016-05-03 16:52:02.181666652 -0600
@@ -1240,6 +1240,7 @@
 		if ((options.allow_tcp_forwarding & FORWARD_REMOTE) == 0 ||
 		    no_port_forwarding_flag ||
 		    (!want_reply && fwd.listen_port == 0)
+		    || !gatewayport_permit(fwd.listen_port)
 #ifndef NO_IPPORT_RESERVED_CONCEPT
 		    || (fwd.listen_port != 0 && fwd.listen_port < IPPORT_RESERVED &&
 		    pw->pw_uid != 0)





From adam at continusec.com  Fri May  5 07:57:38 2017
From: adam at continusec.com (Adam Eijdenberg)
Date: Fri, 5 May 2017 07:57:38 +1000
Subject: sshd: SSH_CLIENT_CERT and SSH_CLIENT_PUBKEY env variables
In-Reply-To: <20170504204542.0c58d2a0@beer.gbdj.ru>
References: <20170426070016.3e5c9d91@beer.gbdj.ru>
 <e4d074d5-0eb0-7d8a-07c1-20687289c0df@redhat.com>
 <20170504204542.0c58d2a0@beer.gbdj.ru>
Message-ID: <CAD0Csb5CDkjo5qty6697mdPnUM42fyizabDhdFKA9++MJSve+A@mail.gmail.com>

On Fri, May 5, 2017 at 2:45 AM, Anton Worshevsky <gbdj at gbdj.ru> wrote:
> My use case:
> Use sshd for authentication
> but expose verified pubkey/certificate to API server application
> for sophisticated authorization by role based access control.

Last year for a time I thought we might also want something like this,
and I'll share the thought process we went through in case it's
helpful for others, even though it's not directly related to this
patch proposal.

The problem that I was trying to solve was to make use of SSH
certificates to authenticate (using git command line tooling) to a
locally hosted GitLab server.

GitLab by default, expects all clients to connect as the "git" user,
but then automatically maintains an "authorized_keys" file that
essentially acts as a map between the key used to authenticate and a
specific command (that includes a GitLab user identifier) to run.

I ended up auto-generating an authorized_principals file for our
GitLab users instead and documented what we did here:
https://github.com/gitlabhq/gitlab-shell/issues/249

Initially I thought this would have been simpler if an environment
variable with the principals presented during authentication was
present, however the immediate next question would be which one to use
if more than one is present? (and in our case, many of our certs
included multiple principals)

Upon reflection, it felt to me like this was still pretty hacky, and
that a better approach for our particular use-case (with GitLab) may
have been to have the users specify git remotes with their own normal
SSH usernames, then let sshd do it's thing, and then have the
"gitlab-shell" command (or similar on the server) do some kind of SUID
magic to map from the actual unix user authenticated to a command
running as git with corresponding GitLab user ID as an argument
however we ended up feeling that was too invasive a set of changes,
and stuck with our 1-line GitLab patch documented above.

From djm at mindrot.org  Fri May  5 10:02:59 2017
From: djm at mindrot.org (Damien Miller)
Date: Fri, 5 May 2017 10:02:59 +1000 (AEST)
Subject: Support for RFC6187
In-Reply-To: <000a01d2c4e8$7498e680$5dcab380$@ipcomm.de>
References: <000a01d2c4e8$7498e680$5dcab380$@ipcomm.de>
Message-ID: <alpine.BSO.2.20.1705050958030.2134@natsu.mindrot.org>



On Thu, 4 May 2017, Edgar Zaiser wrote:

> Hello,
> 
> I was wondering if there?s any reason why openssh is not supporting server
> authentication using ?x509v3-rsa2048-sha256? which is defined in RFC6187?
> 
> Since it is recommended by the official document in Germany, namely
> ?BSI-TR-02102-4?, maybe it?s worth going for it?

Hi,

We consider X.509 too complex a format to support. It dramatically
multiplies attack surface, especially in the crucial pre-authentication
phase of the protocol.

There are third-party patches to add X.509 to OpenSSH:
http://roumenpetrov.info/secsh/

Alternately, OpenSSH supports a much simpler certificate format that
achieves much the same result. There are a few guides and quite a few
third-party tools to manage these (e.g. CAs).

Cheers,
Damien Miller

From vijay.chukka21 at gmail.com  Fri May  5 10:36:31 2017
From: vijay.chukka21 at gmail.com (VIJAY chukka)
Date: Thu, 4 May 2017 17:36:31 -0700
Subject: Logging issue.
Message-ID: <CADx=nk6bOub0_SOaueRe1ZJDr_bq7CuTzvfxbJGAkGVvRirSVg@mail.gmail.com>

Hi,

Why is the logging disabled until the private host key files are loaded.
I think it will be good idea to remove this check so that the errors while
loading the host key files will also go to the sshd.log file.

Here is the code snippet,
*File - sshd.c*
[image: Inline image 1]

thanks

From philipp.heckel at gmail.com  Mon May  8 05:17:31 2017
From: philipp.heckel at gmail.com (Philipp Heckel)
Date: Sun,  7 May 2017 15:17:31 -0400
Subject: [PATCH] Add "permitlisten" support for -R style forwards
Message-ID: <1494184651-31452-1-git-send-email-pheckel@datto.com>

Hi there,

this patch adds support for per-key restriction of -R style forwards
via a "permitlisten"-option in the authorized_keys file -- similar to
the "permitopen"-option for -L style forwards.

This is desirable if you want to have restricted accounts/keys that
can only be used for -R style forwards on certain ports.

With this example authorized_keys file:
  restrict,permitlisten="localhost:8080" ssh-rsa AAAAB3Nza...

This is allowed:
$ ssh -R 8080:localhost:80 root at localhost -N

While this is not allowed (note port 8081):
$ ssh -R 8081:localhost:80 root at localhost -N
Error: remote port forwarding failed for listen port 8081

This is a preliminary patch (no support for a servconf option
"PermitListen" yet), because I wanted to get early feedback before
continuing. 

Do you think this approach is correct? Would this be a desirable
feature? Is "permitlisten" the correct name for this? Or would 
"permitropen", "permitremoteopen" be better suited?

My WIP branch/pull can also be found here: 
https://github.com/openssh/openssh-portable/pull/65

Best,
Philipp Heckel

---
 auth-options.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++
 channels.c     | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 channels.h     |  3 +++
 serverloop.c   |  5 +++--
 4 files changed, 128 insertions(+), 2 deletions(-)

diff --git a/auth-options.c b/auth-options.c
index 57b49f7..61034be 100644
--- a/auth-options.c
+++ b/auth-options.c
@@ -82,6 +82,7 @@ auth_clear_options(void)
 	authorized_principals = NULL;
 	forced_tun_device = -1;
 	channel_clear_permitted_opens();
+	channel_clear_permitted_listens();
 }
 
 /*
@@ -383,6 +384,61 @@ auth_parse_options(struct passwd *pw, char *opts, char *file, u_long linenum)
 			free(patterns);
 			goto next_option;
 		}
+		cp = "permitlisten=\"";
+		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
+			char *host, *p;
+			int port;
+			char *patterns = xmalloc(strlen(opts) + 1);
+
+			opts += strlen(cp);
+			i = 0;
+			while (*opts) {
+				if (*opts == '"')
+					break;
+				if (*opts == '\\' && opts[1] == '"') {
+					opts += 2;
+					patterns[i++] = '"';
+					continue;
+				}
+				patterns[i++] = *opts++;
+			}
+			if (!*opts) {
+				debug("%.100s, line %lu: missing end quote",
+				    file, linenum);
+				auth_debug_add("%.100s, line %lu: missing "
+				    "end quote", file, linenum);
+				free(patterns);
+				goto bad_option;
+			}
+			patterns[i] = '\0';
+			opts++;
+			p = patterns;
+			/* XXX - add streamlocal support */
+			host = hpdelim(&p);
+			if (host == NULL || strlen(host) >= NI_MAXHOST) {
+				debug("%.100s, line %lu: Bad permitlisten "
+				    "specification <%.100s>", file, linenum,
+				    patterns);
+				auth_debug_add("%.100s, line %lu: "
+				    "Bad permitlisten specification", file,
+				    linenum);
+				free(patterns);
+				goto bad_option;
+			}
+			host = cleanhostname(host);
+			if (p == NULL || (port = permitopen_port(p)) < 0) {
+				debug("%.100s, line %lu: Bad permitlisten port "
+				    "<%.100s>", file, linenum, p ? p : "");
+				auth_debug_add("%.100s, line %lu: "
+				    "Bad permitopen port", file, linenum);
+				free(patterns);
+				goto bad_option;
+			}
+			if ((options.allow_tcp_forwarding & FORWARD_REMOTE) != 0)
+				channel_add_permitted_listens(host, port);
+			free(patterns);
+			goto next_option;
+		}
 		cp = "tunnel=\"";
 		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
 			char *tun = NULL;
diff --git a/channels.c b/channels.c
index 4092a67..551c2f0 100644
--- a/channels.c
+++ b/channels.c
@@ -129,12 +129,18 @@ static ForwardPermission *permitted_opens = NULL;
 /* List of all permitted host/port pairs to connect by the admin. */
 static ForwardPermission *permitted_adm_opens = NULL;
 
+/* List of all permitted remote host/port pairs to connect by the user. */
+static ForwardPermission *permitted_listens = NULL;
+
 /* Number of permitted host/port pairs in the array permitted by the user. */
 static int num_permitted_opens = 0;
 
 /* Number of permitted host/port pair in the array permitted by the admin. */
 static int num_adm_permitted_opens = 0;
 
+/* Number of permitted remote host/port pairs. */
+static int num_permitted_listens = 0;
+
 /* special-case port number meaning allow any port */
 #define FWD_PERMIT_ANY_PORT	0
 
@@ -148,6 +154,10 @@ static int num_adm_permitted_opens = 0;
  */
 static int all_opens_permitted = 0;
 
+/**
+ * If this is true, all remote opens are permitted.
+ */
+static int all_listens_permitted = 0;
 
 /* -- X11 forwarding */
 
@@ -3503,6 +3513,23 @@ channel_add_permitted_opens(char *host, int port)
 	all_opens_permitted = 0;
 }
 
+void
+channel_add_permitted_listens(char *host, int port)
+{
+	debug("allow remote port forwarding to host %s port %d", host, port);
+
+	permitted_listens = xreallocarray(permitted_listens,
+        num_permitted_listens + 1, sizeof(*permitted_listens));
+	permitted_listens[num_permitted_listens].host_to_connect = xstrdup(host);
+	permitted_listens[num_permitted_listens].port_to_connect = port;
+	permitted_listens[num_permitted_listens].listen_host = NULL;
+	permitted_listens[num_permitted_listens].listen_path = NULL;
+	permitted_listens[num_permitted_listens].listen_port = 0;
+	num_permitted_listens++;
+
+	all_listens_permitted = 0;
+}
+
 /*
  * Update the listen port for a dynamic remote forward, after
  * the actual 'newport' has been allocated. If 'newport' < 0 is
@@ -3592,6 +3619,21 @@ channel_clear_adm_permitted_opens(void)
 }
 
 void
+channel_clear_permitted_listens(void)
+{
+    int i;
+
+    for (i = 0; i < num_permitted_listens; i++) {
+        free(permitted_listens[i].host_to_connect);
+        free(permitted_listens[i].listen_host);
+        free(permitted_listens[i].listen_path);
+    }
+    free(permitted_listens);
+    permitted_listens = NULL;
+    num_permitted_listens = 0;
+}
+
+void
 channel_print_adm_permitted_opens(void)
 {
 	int i;
@@ -3885,6 +3927,30 @@ channel_connect_to_path(const char *path, char *ctype, char *rname)
 	return connect_to(path, PORT_STREAMLOCAL, ctype, rname);
 }
 
+/* Check if connecting to that port is permitted and connect. */
+int
+channel_connect_check_permitted_listens(const char *host, u_short port)
+{
+    int i, permit = 1;
+
+    permit = all_listens_permitted;
+    if (!permit) {
+        for (i = 0; i < num_permitted_listens; i++)
+            if (open_match(&permitted_listens[i], host, port)) {
+                permit = 1;
+                break;
+            }
+    }
+
+    if (!permit) {
+        logit("Received request for remote forward to host %.100s port %d, "
+                      "but the request was denied.", host, port);
+        return -1;
+    }
+
+    return 0;
+}
+
 void
 channel_send_window_changes(void)
 {
diff --git a/channels.h b/channels.h
index 4e9b77d..7d55055 100644
--- a/channels.h
+++ b/channels.h
@@ -267,15 +267,18 @@ struct ForwardOptions;
 void	 channel_set_af(int af);
 void     channel_permit_all_opens(void);
 void	 channel_add_permitted_opens(char *, int);
+void	 channel_add_permitted_listens(char *, int);
 int	 channel_add_adm_permitted_opens(char *, int);
 void	 channel_disable_adm_local_opens(void);
 void	 channel_update_permitted_opens(int, int);
 void	 channel_clear_permitted_opens(void);
 void	 channel_clear_adm_permitted_opens(void);
+void	 channel_clear_permitted_listens(void);
 void 	 channel_print_adm_permitted_opens(void);
 Channel	*channel_connect_to_port(const char *, u_short, char *, char *, int *,
 	     const char **);
 Channel *channel_connect_to_path(const char *, char *, char *);
+int channel_connect_check_permitted_listens(const char *host, u_short port);
 Channel	*channel_connect_stdio_fwd(const char*, u_short, int, int);
 Channel	*channel_connect_by_listen_address(const char *, u_short,
 	     char *, char *);
diff --git a/serverloop.c b/serverloop.c
index 2976f55..50d8feb 100644
--- a/serverloop.c
+++ b/serverloop.c
@@ -729,11 +729,12 @@ server_input_global_request(int type, u_int32_t seq, void *ctxt)
 		    fwd.listen_host, fwd.listen_port);
 
 		/* check permissions */
-		if ((options.allow_tcp_forwarding & FORWARD_REMOTE) == 0 ||
+		if (channel_connect_check_permitted_listens(fwd.listen_host, fwd.listen_port) < 0 &&
+		    ((options.allow_tcp_forwarding & FORWARD_REMOTE) == 0 ||
 		    no_port_forwarding_flag || options.disable_forwarding ||
 		    (!want_reply && fwd.listen_port == 0) ||
 		    (fwd.listen_port != 0 &&
-		     !bind_permitted(fwd.listen_port, pw->pw_uid))) {
+		     !bind_permitted(fwd.listen_port, pw->pw_uid)))) {
 			success = 0;
 			packet_send_debug("Server has disabled port forwarding.");
 		} else {
-- 
2.7.4


From cristian.ionescu-idbohrn at axis.com  Mon May  8 22:16:55 2017
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Mon, 8 May 2017 14:16:55 +0200 (CEST)
Subject: playing around with removing algos
In-Reply-To: <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
Message-ID: <alpine.DEB.2.20.1705081407480.8532@enwn.fr.nkvf.pbz>

On Tue, 2 May 2017, Jakub Jelen wrote:
> On 05/01/2017 04:48 PM, Cristian Ionescu-Idbohrn wrote:
> > On Mon, 1 May 2017, Cristian Ionescu-Idbohrn wrote:
> > > 
> > > Example, 'Macs'.
> > > 
> > > On the man page I read:
> > > 
> > > "Multiple algorithms must be comma-separated.
> > > ...
> > > If the specified value begins with a '-' character, then the
> > > specified algorithms (including wildcards) will be removed"
> > > 
> > > It seems that just one algo name is supported on such a line, example:
> > > 
> > > 	Macs -umac-64*
> > > 
> > > But this form is not supported:
> > > 
> > > 	Macs -umac-64*,-hmac-sha1*
> > > 
> > > nor is this:
> > > 
> > > 	Macs -umac-64*
> > > 	Macs -hmac-sha1*
> > > 
> > > And I have difficulties in finding _one_ pattern that matches _only_
> > > the above algo families, but nothing else.
> > > 
> > > Can you confirm this behaviour?  Can it be improved?

Back here, then...

> I believe this is expected behavior and limitation of the current 
> behavior. The manual page also says

Couldn't find this part:

> > For each parameter, the first obtained value will be used. [...]

Which manual page was that on?

But I found this:

> > [...] will be removed *from the default set instead of replacing them*.
> 
> Therefore:
>  * Only the default set is affected
>  * The second Macs option is ignored (because Macs are already set)
> 
> This might be confusing especially when specifying multiple values 
> and improving that would be very nice.

Created bz#2715 with:

By accident, I just discovered a list of this form:

	Macs=-umac-64*,hmac-sha1*

is supported (the '-' operates on the whole list).

This form:

	Macs=-umac-64*,-hmac-sha1*

('-' in front of each pattern) is not supported.

Ideally, a mix like this:

	Macs=-umac-64*,+foo*,-hmac-sha1*

offers the best flexibility, IMO.


Cheers,

-- 
Cristian

From devin.nate at QHRtech.com  Tue May  9 03:51:21 2017
From: devin.nate at QHRtech.com (Devin Nate)
Date: Mon, 8 May 2017 17:51:21 +0000
Subject: [PATCH] / permitgwports / permitlisten
Message-ID: <E81EE6F2-D2B9-45B8-98B1-AD42FDAEF3E8@qhrtech.com>

Hi Phillipp, developers;

I likewise just submitted a patch for similar. It i buried under the thread named OpenSSH contract development / patch.

At the request of the OpenSSH dev team, I submitted our patch in the mindrot Bugzilla

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

Your patch, I see is available there too

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

Anyhow, just drawing attention of these 2 patches together ? they?re similar, though not identical. Ours also changes the behavior of permitopen. Your approaches looks very familiar, it felt like deja vu.

Thanks,
Devin



From jjelen at redhat.com  Tue May  9 16:28:44 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 9 May 2017 08:28:44 +0200
Subject: playing around with removing algos
In-Reply-To: <alpine.DEB.2.20.1705081407480.8532@enwn.fr.nkvf.pbz>
References: <alpine.DEB.2.20.1705011606230.21932@enwn.fr.nkvf.pbz>
 <alpine.DEB.2.20.1705011638470.21932@enwn.fr.nkvf.pbz>
 <41f8e1c4-c099-7232-a86d-dbae289e43fc@redhat.com>
 <alpine.DEB.2.20.1705081407480.8532@enwn.fr.nkvf.pbz>
Message-ID: <4bf8d061-8aa1-ccd8-4cd7-a33801681e2d@redhat.com>

On 05/08/2017 02:16 PM, Cristian Ionescu-Idbohrn wrote:
> On Tue, 2 May 2017, Jakub Jelen wrote:
>> I believe this is expected behavior and limitation of the current
>> behavior. The manual page also says
> 
> Couldn't find this part:
> 
>>> For each parameter, the first obtained value will be used. [...]
> 
> Which manual page was that on?

In manual page of ssh_config. The logic in client and server 
configurations is very similar.

> 
> But I found this:
> 
>>> [...] will be removed *from the default set instead of replacing them*.
>>
>> Therefore:
>>   * Only the default set is affected
>>   * The second Macs option is ignored (because Macs are already set)
>>
>> This might be confusing especially when specifying multiple values
>> and improving that would be very nice.
> 
> Created bz#2715 with:

That makes sense. Thanks.

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

From jjelen at redhat.com  Tue May  9 16:50:57 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 9 May 2017 08:50:57 +0200
Subject: Logging issue.
In-Reply-To: <CADx=nk6bOub0_SOaueRe1ZJDr_bq7CuTzvfxbJGAkGVvRirSVg@mail.gmail.com>
References: <CADx=nk6bOub0_SOaueRe1ZJDr_bq7CuTzvfxbJGAkGVvRirSVg@mail.gmail.com>
Message-ID: <d733f116-1006-1b5e-727b-3cdc8d8668af@redhat.com>

On 05/05/2017 02:36 AM, VIJAY chukka wrote:
> Hi,
> 
> Why is the logging disabled until the private host key files are loaded.

The host keys names are picked up from the sshd_config. The logging 
configuration as well. So before reading the configuration, the server 
does not know how to log and logs errors to stderr if I am right.

> I think it will be good idea to remove this check so that the errors while
> loading the host key files will also go to the sshd.log file.
> 
> Here is the code snippet,
> *File - sshd.c*
> [image: Inline image 1]

The image did not arrive. Please, use text snippet.

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

From ebarretto at linux.vnet.ibm.com  Wed May 10 03:27:13 2017
From: ebarretto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Tue,  9 May 2017 14:27:13 -0300
Subject: [PATCH 1/3] Allow flock and ipc syscall for s390 architecture
In-Reply-To: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
References: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
Message-ID: <1494350835-24813-2-git-send-email-ebarretto@linux.vnet.ibm.com>

In order to use the OpenSSL-ibmpkcs11 engine it is needed to allow flock
and ipc calls, because this engine calls OpenCryptoki (a PKCS#11
implementation) which calls the libraries that will communicate with the
crypto cards. OpenCryptoki makes use of flock and ipc and, as of now,
this is only need on s390 architecture.

Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
---
 sandbox-seccomp-filter.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index ca75cc7..6e7de31 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -166,6 +166,9 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_exit_group
 	SC_ALLOW(__NR_exit_group),
 #endif
+#if defined(__NR_flock) && defined(__s390__)
+	SC_ALLOW(__NR_flock),
+#endif
 #ifdef __NR_getpgid
 	SC_ALLOW(__NR_getpgid),
 #endif
@@ -178,6 +181,9 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_gettimeofday
 	SC_ALLOW(__NR_gettimeofday),
 #endif
+#if defined(__NR_ipc) && defined(__s390__)
+	SC_ALLOW(__NR_ipc),
+#endif
 #ifdef __NR_madvise
 	SC_ALLOW(__NR_madvise),
 #endif
-- 
1.9.1


From ebarretto at linux.vnet.ibm.com  Wed May 10 03:27:14 2017
From: ebarretto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Tue,  9 May 2017 14:27:14 -0300
Subject: [PATCH 2/3] Allow getuid and geteuid calls
In-Reply-To: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
References: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
Message-ID: <1494350835-24813-3-git-send-email-ebarretto@linux.vnet.ibm.com>

getuid and geteuid are needed when using an openssl engine that calls a
crypto card, e.g. ICA (libica).
Those syscalls are also needed by the distros for audit code.

Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
---
 sandbox-seccomp-filter.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index 6e7de31..e86aa2c 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -175,6 +175,18 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_getpid
 	SC_ALLOW(__NR_getpid),
 #endif
+#ifdef __NR_getuid
+	SC_ALLOW(__NR_getuid),
+#endif
+#ifdef __NR_getuid32
+	SC_ALLOW(__NR_getuid32),
+#endif
+#ifdef __NR_geteuid
+	SC_ALLOW(__NR_geteuid),
+#endif
+#ifdef __NR_geteuid32
+	SC_ALLOW(__NR_geteuid32),
+#endif
 #ifdef __NR_getrandom
 	SC_ALLOW(__NR_getrandom),
 #endif
-- 
1.9.1


From ebarretto at linux.vnet.ibm.com  Wed May 10 03:27:12 2017
From: ebarretto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Tue,  9 May 2017 14:27:12 -0300
Subject: [PATCH 0/3] Allow syscalls for openssl engines
Message-ID: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>

This patchset allow syscalls (flock, ipc, getuid, geteuid and ioctl), so
openssl engines, e.g. OpenSSL-ibmca and OpenSSL-ibmpkcs11, can work and
communicate with the crypto cards during ssh login.

1. The flock and ipc are allowed only for s390 architecture. They are needed
for openCryptoki project (PKCS#11 implementation), as the ibmpkcs11 engine
makes use of openCryptoki.
For more information, please check here:
https://sourceforge.net/projects/opencryptoki/

2. getuid and geteuid are allowed to any architecture as this is also needed
by the distros. libica and other crypto libraries use those syscalls.

3. The ioctl is allowed when an specific argument is passed. This argument
is from EP11 crypto card on s390 architecture.
For more information check here:
http://elixir.free-electrons.com/linux/latest/source/arch/s390/include/uapi/asm/zcrypt.h#L259


From ebarretto at linux.vnet.ibm.com  Wed May 10 03:27:15 2017
From: ebarretto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Tue,  9 May 2017 14:27:15 -0300
Subject: [PATCH 3/3] Enable specific ioctl call for EP11 crypto card (s390)
In-Reply-To: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
References: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
Message-ID: <1494350835-24813-4-git-send-email-ebarretto@linux.vnet.ibm.com>

The EP11 crypto card needs to make an ioctl call, which receives an
specific argument. This crypto card is for s390 only.

Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com>
---
 sandbox-seccomp-filter.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index e86aa2c..98062f1 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -250,6 +250,8 @@ static const struct sock_filter preauth_insns[] = {
 	SC_ALLOW_ARG(__NR_ioctl, 1, Z90STAT_STATUS_MASK),
 	SC_ALLOW_ARG(__NR_ioctl, 1, ICARSAMODEXPO),
 	SC_ALLOW_ARG(__NR_ioctl, 1, ICARSACRT),
+	/* Allow ioctls for EP11 crypto card on s390 */
+	SC_ALLOW_ARG(__NR_ioctl, 1, ZSENDEP11CPRB),
 #endif
 #if defined(__x86_64__) && defined(__ILP32__) && defined(__X32_SYSCALL_BIT)
 	/*
-- 
1.9.1


From grawity at gmail.com  Fri May 12 04:10:35 2017
From: grawity at gmail.com (=?UTF-8?q?Mantas=20Mikul=C4=97nas?=)
Date: Thu, 11 May 2017 21:10:35 +0300
Subject: [PATCH] allow [brackets] around IPv6 literals like scp requires
Message-ID: <20170511181035.495482-1-grawity@gmail.com>

It is difficult to script things when scp requires the brackets but ssh
forbids them.
---
 ssh.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ssh.c b/ssh.c
index 70631c24..7abfe51a 100644
--- a/ssh.c
+++ b/ssh.c
@@ -942,6 +942,9 @@ main(int ac, char **av)
 	if (!host)
 		usage();
 
+	/* Allow [brackets] around IPv6 addresses for consistency with scp. */
+	host = cleanhostname(host);
+
 	host_arg = xstrdup(host);
 
 #ifdef WITH_OPENSSL
-- 
2.13.0


From mh at ow2.org  Fri May 12 20:06:14 2017
From: mh at ow2.org (mh at ow2.org)
Date: Fri, 12 May 2017 12:06:14 +0200
Subject: ls hangs in internal-sftp for LDAP users
Message-ID: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>

I'm using 7.2p2-4ubuntu2.1

I have the same exact problem as described in the first comment in
https://bugzilla.mindrot.org/show_bug.cgi?id=1573

Initially, my ldap server hostname and IP is only in /etc/hosts, not in
the configured resolver. I can't use the real IP as a workaround in
ldap.conf because of the TLS configuration which cares about the hostname.

At the time I add the host name and IP in the resolver, the issue goes away.

So, I'm a bit worried to be forced to declare a record in my DNS to
enable SFTP listing ? There should be another way isn't ?

I also tried to copy /etc/hosts to etc/hosts in the folder specified by
ChrootDirectory directive with no more success.

Notice : it happens only for ldap users, not local users

Any help welcome,

Regards,

From mh at ow2.org  Fri May 12 20:31:35 2017
From: mh at ow2.org (mh at ow2.org)
Date: Fri, 12 May 2017 12:31:35 +0200
Subject: ls hangs in internal-sftp for LDAP users
In-Reply-To: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
Message-ID: <4a369111-1cd6-9657-7472-4863378dcd79@ow2.org>

In the process of writing this email, I forgot saying hello to you all.
Rather impolite for someone who looks for help.

My apologies.

Cheers

Le 12/05/2017 ? 12:06, mh at ow2.org a ?crit :
> I'm using 7.2p2-4ubuntu2.1
> 
> I have the same exact problem as described in the first comment in
> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
> 
> Initially, my ldap server hostname and IP is only in /etc/hosts, not in
> the configured resolver. I can't use the real IP as a workaround in
> ldap.conf because of the TLS configuration which cares about the hostname.
> 
> At the time I add the host name and IP in the resolver, the issue goes away.
> 
> So, I'm a bit worried to be forced to declare a record in my DNS to
> enable SFTP listing ? There should be another way isn't ?
> 
> I also tried to copy /etc/hosts to etc/hosts in the folder specified by
> ChrootDirectory directive with no more success.
> 
> Notice : it happens only for ldap users, not local users
> 
> Any help welcome,
> 
> Regards,
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


From arw at cs.fau.de  Fri May 12 20:47:21 2017
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Fri, 12 May 2017 12:47:21 +0200
Subject: ls hangs in internal-sftp for LDAP users
In-Reply-To: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
Message-ID: <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>

On 2017-05-12T12:07, mh at ow2.org <mh at ow2.org> wrote:
> I'm using 7.2p2-4ubuntu2.1
> 
> I have the same exact problem as described in the first comment in
> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
> 
> Initially, my ldap server hostname and IP is only in /etc/hosts, not in
> the configured resolver. I can't use the real IP as a workaround in
> ldap.conf because of the TLS configuration which cares about the hostname.
> 
> At the time I add the host name and IP in the resolver, the issue goes away.
> 
> So, I'm a bit worried to be forced to declare a record in my DNS to
> enable SFTP listing ? There should be another way isn't ?
> 
> I also tried to copy /etc/hosts to etc/hosts in the folder specified by
> ChrootDirectory directive with no more success.
> 
> Notice : it happens only for ldap users, not local users

There should be a /etc/nsswitch.conf in your chroot where you can
configure where users and hostnames should be looked up. E.g. to prevent
LDAP lookups altogether you could configure the respective two lines to
read:
passwd:		files
group:		files
i.e. drop the 'ldap' option there. To check why /etc/hosts isn't being
used you can look if hosts: has 'files dns' or just 'dns' altogether
behind it.

But in general I would recommend putting all your hostnames into DNS
properly, in my experience this avoids all kinds of headaches with all
kinds of software. And leave /etc/hosts as empty as possible, because
that always grows inconsistent over time.



Ciao,

Alexander Wuerstlein.

From mh at ow2.org  Fri May 12 21:49:08 2017
From: mh at ow2.org (mh at ow2.org)
Date: Fri, 12 May 2017 13:49:08 +0200
Subject: ls hangs in internal-sftp for LDAP users
In-Reply-To: <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
Message-ID: <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>

Le 12/05/2017 ? 12:47, Alexander Wuerstlein a ?crit :
> On 2017-05-12T12:07, mh at ow2.org <mh at ow2.org> wrote:
>> I'm using 7.2p2-4ubuntu2.1
>>
>> I have the same exact problem as described in the first comment in
>> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
>>
>> Initially, my ldap server hostname and IP is only in /etc/hosts, not in
>> the configured resolver. I can't use the real IP as a workaround in
>> ldap.conf because of the TLS configuration which cares about the hostname.
>>
>> At the time I add the host name and IP in the resolver, the issue goes away.
>>
>> So, I'm a bit worried to be forced to declare a record in my DNS to
>> enable SFTP listing ? There should be another way isn't ?
>>
>> I also tried to copy /etc/hosts to etc/hosts in the folder specified by
>> ChrootDirectory directive with no more success.
>>
>> Notice : it happens only for ldap users, not local users
> 
> There should be a /etc/nsswitch.conf in your chroot where you can
> configure where users and hostnames should be looked up. E.g. to prevent
> LDAP lookups altogether you could configure the respective two lines to
> read:
> passwd:		files
> group:		files
> i.e. drop the 'ldap' option there. To check why /etc/hosts isn't being
> used you can look if hosts: has 'files dns' or just 'dns' altogether
> behind it.
> 
> But in general I would recommend putting all your hostnames into DNS
> properly, in my experience this avoids all kinds of headaches with all
> kinds of software. And leave /etc/hosts as empty as possible, because
> that always grows inconsistent over time.
> 
> 

Thanks Alexander,

I'll try the nsswitch.conf suggestion. Until then I've noticed the
following : while the ldap hostname is into the DNS, if I also put a the
corresponding line to etc/hosts in the chroot the hang happens again. So
the hosts file in the chroot is red somehow.

But if it reads the hosts file propertly, what is the problem then ?

I'm a bit confused. Have a good we :)


From arw at cs.fau.de  Fri May 12 22:03:59 2017
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Fri, 12 May 2017 14:03:59 +0200
Subject: ls hangs in internal-sftp for LDAP users
In-Reply-To: <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
 <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
Message-ID: <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>

On 2017-05-12T13:49, mh at ow2.org <mh at ow2.org> wrote:
> Le 12/05/2017 ? 12:47, Alexander Wuerstlein a ?crit :
> > On 2017-05-12T12:07, mh at ow2.org <mh at ow2.org> wrote:
> >> I'm using 7.2p2-4ubuntu2.1
> >>
> >> I have the same exact problem as described in the first comment in
> >> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
> >>
> >> Initially, my ldap server hostname and IP is only in /etc/hosts, not in
> >> the configured resolver. I can't use the real IP as a workaround in
> >> ldap.conf because of the TLS configuration which cares about the hostname.
> >>
> >> At the time I add the host name and IP in the resolver, the issue goes away.
> >>
> >> So, I'm a bit worried to be forced to declare a record in my DNS to
> >> enable SFTP listing ? There should be another way isn't ?
> >>
> >> I also tried to copy /etc/hosts to etc/hosts in the folder specified by
> >> ChrootDirectory directive with no more success.
> >>
> >> Notice : it happens only for ldap users, not local users
> > 
> > There should be a /etc/nsswitch.conf in your chroot where you can
> > configure where users and hostnames should be looked up. E.g. to prevent
> > LDAP lookups altogether you could configure the respective two lines to
> > read:
> > passwd:		files
> > group:		files
> > i.e. drop the 'ldap' option there. To check why /etc/hosts isn't being
> > used you can look if hosts: has 'files dns' or just 'dns' altogether
> > behind it.
> > 
> > But in general I would recommend putting all your hostnames into DNS
> > properly, in my experience this avoids all kinds of headaches with all
> > kinds of software. And leave /etc/hosts as empty as possible, because
> > that always grows inconsistent over time.
> > 
> > 
> 
> Thanks Alexander,
> 
> I'll try the nsswitch.conf suggestion. Until then I've noticed the
> following : while the ldap hostname is into the DNS, if I also put a the
> corresponding line to etc/hosts in the chroot the hang happens again. So
> the hosts file in the chroot is red somehow.

It shouldn't hang in that case, thats strange. However, the order of the
options in nsswitch.conf determines which way to look up the hostname is
tried first, second, ... etc. One thing that might be a problem (but I'm
guessing, there might be a lot more going on[0]) would be whether you have
just the hostname or the FQDN in your ldap.conf and /etc/hosts. And if
its not the FQDN in some place, then what your search path in
/etc/resolv.conf and the value of your dnsdomainname might be. 

> But if it reads the hosts file propertly, what is the problem then ?

I'm not sure. Maybe try determining if its a ssh/sftp problem first: In
that chroot, does 'getent passwd' hang? Does it contain only local users
or ldap users as well? Does 'getent hosts $ldaphostname' hang? If yes,
its a problem with the libc name services that are behind getent and
stuff, so you would have to fix the config (in nsswitch.conf and all the
related things referenced from there). strace-ing the aforementioned
getent calls might help narrowing things further down.





Ciao,

Alexander Wuerstlein.

[0] e.g. if you are using sssd or hostnamed somewhere.

From philipp.heckel at gmail.com  Sat May 13 10:22:40 2017
From: philipp.heckel at gmail.com (Philipp Heckel)
Date: Fri, 12 May 2017 20:22:40 -0400
Subject: [PATCH] / permitgwports / permitlisten
In-Reply-To: <E81EE6F2-D2B9-45B8-98B1-AD42FDAEF3E8@qhrtech.com>
References: <E81EE6F2-D2B9-45B8-98B1-AD42FDAEF3E8@qhrtech.com>
Message-ID: <1494634960.27336.5.camel@gmail.com>

Hello Devin,

it seems I haven't done my homework, and wrote a patch without properly
checking bugzilla ...

> Anyhow, just drawing attention of these 2 patches together ? they?re
> similar, though not identical. [..] ?Your approaches looks
>?very familiar, it felt like deja vu.

The patches are indeed very, very similar. I think that does underline
the need for such an option. I must admit I was pretty surprised that
it did not exist already.

>  Ours also changes the behavior of permitopen.

While I generally agree with having to explicitly whitelist
"permitopen" host/port pairs, it does change the default behavior and
would probably break configuration in the wild. Or am I mistaken here?

Best
Philipp

From devel-net-ne-vlezay80 at yandex.ru  Mon May 15 07:24:37 2017
From: devel-net-ne-vlezay80 at yandex.ru (=?utf-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtC70LTRi9GA0LXQsg==?=)
Date: Mon, 15 May 2017 00:24:37 +0300
Subject: ssh ethernet tunnel jumbo frame udp is not work
Message-ID: <4390871494797077@web17o.yandex.ru>

root at ne-vlezay80:~# tcpdump -i tap0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:23:53.206672 ARP, Request who-has 10.194.0.2 tell 10.194.0.200, length 28
00:23:53.206691 ARP, Reply 10.194.0.2 is-at 52:54:00:38:b9:0b, length 28
00:23:53.710691 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:48:98:88.8000, length 35
00:23:55.559070 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [S], seq 2722613399, win 29200, options [mss 1460,sackOK,TS val 2910016 ecr 0,nop,wscale 6], length 0
00:23:55.559212 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [S.], seq 4252447420, ack 2722613400, win 26928, options [mss 2460,sackOK,TS val 3706806890 ecr 2910016,nop,wscale 5], length 0
00:23:55.559571 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [.], ack 1, win 457, options [nop,nop,TS val 2910016 ecr 3706806890], length 0
00:23:55.559589 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [P.], seq 1:38, ack 1, win 457, options [nop,nop,TS val 2910016 ecr 3706806890], length 37
00:23:55.559879 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [.], ack 38, win 842, options [nop,nop,TS val 3706806891 ecr 2910016], length 0
00:23:55.559913 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [P.], seq 1:2, ack 38, win 842, options [nop,nop,TS val 3706806891 ecr 2910016], length 1
00:23:55.560094 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [.], ack 2, win 457, options [nop,nop,TS val 2910016 ecr 3706806891], length 0
00:23:55.560153 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [P.], seq 38:42, ack 2, win 457, options [nop,nop,TS val 2910016 ecr 3706806891], length 4
00:23:55.600656 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [.], ack 42, win 842, options [nop,nop,TS val 3706806932 ecr 2910016], length 0
00:23:55.601099 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [P.], seq 42:117, ack 2, win 457, options [nop,nop,TS val 2910026 ecr 3706806932], length 75
00:23:55.601593 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [.], ack 117, win 842, options [nop,nop,TS val 3706806932 ecr 2910026], length 0
00:23:55.601639 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [P.], seq 2:3, ack 117, win 842, options [nop,nop,TS val 3706806932 ecr 2910026], length 1
00:23:55.602041 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 4
00:23:55.602627 IP 10.194.0.2.5201 > 10.194.0.200.43100: UDP, length 4
00:23:55.642352 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [.], ack 3, win 457, options [nop,nop,TS val 2910036 ecr 3706806932], length 0
00:23:55.642564 IP 10.194.0.2.5201 > 10.194.0.200.50356: Flags [P.], seq 3:5, ack 117, win 842, options [nop,nop,TS val 3706806974 ecr 2910036], length 2
00:23:55.642763 IP 10.194.0.200.50356 > 10.194.0.2.5201: Flags [.], ack 5, win 457, options [nop,nop,TS val 2910037 ecr 3706806974], length 0
00:23:55.642876 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:55.642925 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.642966 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.643025 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.643058 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.643115 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.723126 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:48:98:88.8000, length 35
00:23:55.743187 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:55.743240 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.743283 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.743327 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.743353 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.743357 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843261 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:55.843344 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843456 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843501 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843508 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843527 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843558 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:55.843563 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843566 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843570 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843573 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.843577 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.943215 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:55.943267 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.943272 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.943275 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.943279 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:55.943282 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043339 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:56.043489 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043535 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043544 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043548 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043552 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043589 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:56.043594 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043597 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043601 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043604 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.043608 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143438 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:56.143568 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143573 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143576 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143581 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143585 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143625 IP 10.194.0.200.43100 > 10.194.0.2.5201: UDP, length 8192
00:23:56.143632 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143635 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143639 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143642 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
00:23:56.143646 IP 10.194.0.200 > 10.194.0.2: ip-proto-17
^C
75 packets captured
141 packets received by filter
0 packets dropped by kernel

From dtucker at zip.com.au  Mon May 15 09:49:12 2017
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 15 May 2017 09:49:12 +1000
Subject: ssh ethernet tunnel jumbo frame udp is not work
In-Reply-To: <4390871494797077@web17o.yandex.ru>
References: <4390871494797077@web17o.yandex.ru>
Message-ID: <CALDDTe3GvLekCGXciAYv9tWmOxZXuYrcOv83bQNFeOoh_an55w@mail.gmail.com>

On Mon, May 15, 2017 at 7:24 AM, ??????? ???????? <
devel-net-ne-vlezay80 at yandex.ru> wrote:

> root at ne-vlezay80:~# tcpdump -i tap0 -n
>

You will likely need to supply some more information before anyone can even
offer any suggestions.  This includes:
 - what version of OpenSSH are the client and server?
 - what platforms are they running on?  which addresses in the dump
correspond to which?
 - how big the packet was before it was tunnelled?  was it fragmented?
 - what does the debug logging "ssh -vvv and sshd -ddd" say when this
occurs?

-- 
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 adam at continusec.com  Mon May 15 10:24:53 2017
From: adam at continusec.com (Adam Eijdenberg)
Date: Mon, 15 May 2017 10:24:53 +1000
Subject: Golang CertChecker hostname validation differs to OpenSSH
Message-ID: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>

Hi all,

Last week I noticed that the CertChecker in the Go implementation of
x/crypto/ssh seems to be doing host principal validation incorrectly
and filed the following bug:
https://github.com/golang/go/issues/20273

By default they are looking for a principal named "host:port" inside
of the certificate presented by the server, instead of just looking
for the host as I believe OpenSSH does.

e.g. the following error is generated:

ssh: handshake failed: ssh: principal "localhost:2022" not in the set
of valid principals for given certificate: ["localhost"]

Before I ping the bug again, it would be good to get a second opinion
as to whether that behaviour is correct or not.

Cheers, Adam

From mindrot at hda3.com  Mon May 15 11:39:09 2017
From: mindrot at hda3.com (Peter Moody)
Date: Sun, 14 May 2017 18:39:09 -0700
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
Message-ID: <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>

I think I wrote the code in question for the golang library
(https://github.com/golang/crypto/commit/527d12e53572562de9fd348d50e1ee4096803cec)

my reading of the sshd manpage is that ssh is more permissive than it should be

SSH_KNOWN_HOSTS FILE FORMAT :
  ...

  A hostname or address may optionally be enclosed within `[' and `]'
brackets then followed by `:' and a non-standard port number.

I actually noticed this last week and meant to email this list to ask
the openssh devs of the 'correct' behavior.


On Sun, May 14, 2017 at 5:24 PM, Adam Eijdenberg <adam at continusec.com> wrote:
> Hi all,
>
> Last week I noticed that the CertChecker in the Go implementation of
> x/crypto/ssh seems to be doing host principal validation incorrectly
> and filed the following bug:
> https://github.com/golang/go/issues/20273
>
> By default they are looking for a principal named "host:port" inside
> of the certificate presented by the server, instead of just looking
> for the host as I believe OpenSSH does.
>
> e.g. the following error is generated:
>
> ssh: handshake failed: ssh: principal "localhost:2022" not in the set
> of valid principals for given certificate: ["localhost"]
>
> Before I ping the bug again, it would be good to get a second opinion
> as to whether that behaviour is correct or not.
>
> Cheers, Adam
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From mindrot at hda3.com  Mon May 15 11:43:41 2017
From: mindrot at hda3.com (Peter Moody)
Date: Sun, 14 May 2017 18:43:41 -0700
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
Message-ID: <CADbMJxm=2H9Vt_p1MmojECwDwra8peJFts_uf2n4roFb-aJVWQ@mail.gmail.com>

specifically, this is what openssh says when connecting to a a host
with a otherwise valid hostcert on a non standard port

  debug1: Host 'foo.bar.com' is known and matches the ED25519-CERT
host certificate.
  debug1: Found CA key in /etc/ssh/ssh_known_hosts:1
  debug1: found matching key w/out port

and this is when the port is correctly included in the known hosts

  debug1: Host '[foo.bar.com]:1234' is known and matches the
ED25519-CERT host certificate.
  debug1: Found CA key in /etc/ssh/ssh_known_hosts:1

it definitely feels to me like the first behavior is incorrect.



On Sun, May 14, 2017 at 6:39 PM, Peter Moody <mindrot at hda3.com> wrote:
> I think I wrote the code in question for the golang library
> (https://github.com/golang/crypto/commit/527d12e53572562de9fd348d50e1ee4096803cec)
>
> my reading of the sshd manpage is that ssh is more permissive than it should be
>
> SSH_KNOWN_HOSTS FILE FORMAT :
>   ...
>
>   A hostname or address may optionally be enclosed within `[' and `]'
> brackets then followed by `:' and a non-standard port number.
>
> I actually noticed this last week and meant to email this list to ask
> the openssh devs of the 'correct' behavior.
>
>
> On Sun, May 14, 2017 at 5:24 PM, Adam Eijdenberg <adam at continusec.com> wrote:
>> Hi all,
>>
>> Last week I noticed that the CertChecker in the Go implementation of
>> x/crypto/ssh seems to be doing host principal validation incorrectly
>> and filed the following bug:
>> https://github.com/golang/go/issues/20273
>>
>> By default they are looking for a principal named "host:port" inside
>> of the certificate presented by the server, instead of just looking
>> for the host as I believe OpenSSH does.
>>
>> e.g. the following error is generated:
>>
>> ssh: handshake failed: ssh: principal "localhost:2022" not in the set
>> of valid principals for given certificate: ["localhost"]
>>
>> Before I ping the bug again, it would be good to get a second opinion
>> as to whether that behaviour is correct or not.
>>
>> Cheers, Adam
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From mindrot at hda3.com  Mon May 15 12:29:19 2017
From: mindrot at hda3.com (Peter Moody)
Date: Sun, 14 May 2017 19:29:19 -0700
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CADbMJxm=2H9Vt_p1MmojECwDwra8peJFts_uf2n4roFb-aJVWQ@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CADbMJxm=2H9Vt_p1MmojECwDwra8peJFts_uf2n4roFb-aJVWQ@mail.gmail.com>
Message-ID: <CADbMJxkfv4Up1usJRyT8tMFnkkFNo4a1iuv4Mjf5ne4Kbvsu3Q@mail.gmail.com>

I just double checked how openssh handled the case where the specific
(eg, [foo.bar.com]:1234) cert-authority had the wrong key and the
non-specific (foo.bar.com) had the correct key and this is what it
says:

  debug1: Host 'foo.bar.com' is known and matches the ED25519-CERT
host certificate.
  debug1: Found CA key in /etc/ssh/ssh_known_hosts:2
  debug1: found matching key w/out port

it does that no matter the order of specific/non-specific keys in
/etc/ssh/ssh_known_hosts.

that definitely feels wrong.




On Sun, May 14, 2017 at 6:43 PM, Peter Moody <mindrot at hda3.com> wrote:
> specifically, this is what openssh says when connecting to a a host
> with a otherwise valid hostcert on a non standard port
>
>   debug1: Host 'foo.bar.com' is known and matches the ED25519-CERT
> host certificate.
>   debug1: Found CA key in /etc/ssh/ssh_known_hosts:1
>   debug1: found matching key w/out port
>
> and this is when the port is correctly included in the known hosts
>
>   debug1: Host '[foo.bar.com]:1234' is known and matches the
> ED25519-CERT host certificate.
>   debug1: Found CA key in /etc/ssh/ssh_known_hosts:1
>
> it definitely feels to me like the first behavior is incorrect.
>
>
>
> On Sun, May 14, 2017 at 6:39 PM, Peter Moody <mindrot at hda3.com> wrote:
>> I think I wrote the code in question for the golang library
>> (https://github.com/golang/crypto/commit/527d12e53572562de9fd348d50e1ee4096803cec)
>>
>> my reading of the sshd manpage is that ssh is more permissive than it should be
>>
>> SSH_KNOWN_HOSTS FILE FORMAT :
>>   ...
>>
>>   A hostname or address may optionally be enclosed within `[' and `]'
>> brackets then followed by `:' and a non-standard port number.
>>
>> I actually noticed this last week and meant to email this list to ask
>> the openssh devs of the 'correct' behavior.
>>
>>
>> On Sun, May 14, 2017 at 5:24 PM, Adam Eijdenberg <adam at continusec.com> wrote:
>>> Hi all,
>>>
>>> Last week I noticed that the CertChecker in the Go implementation of
>>> x/crypto/ssh seems to be doing host principal validation incorrectly
>>> and filed the following bug:
>>> https://github.com/golang/go/issues/20273
>>>
>>> By default they are looking for a principal named "host:port" inside
>>> of the certificate presented by the server, instead of just looking
>>> for the host as I believe OpenSSH does.
>>>
>>> e.g. the following error is generated:
>>>
>>> ssh: handshake failed: ssh: principal "localhost:2022" not in the set
>>> of valid principals for given certificate: ["localhost"]
>>>
>>> Before I ping the bug again, it would be good to get a second opinion
>>> as to whether that behaviour is correct or not.
>>>
>>> Cheers, Adam
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From adam at continusec.com  Mon May 15 19:01:14 2017
From: adam at continusec.com (Adam Eijdenberg)
Date: Mon, 15 May 2017 19:01:14 +1000
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
Message-ID: <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>

On Mon, May 15, 2017 at 11:39 AM, Peter Moody <mindrot at hda3.com> wrote:
> my reading of the sshd manpage is that ssh is more permissive than it should be
>
> SSH_KNOWN_HOSTS FILE FORMAT :
>   ...
>
>   A hostname or address may optionally be enclosed within `[' and `]'
> brackets then followed by `:' and a non-standard port number.

Hi Peter, I'm not sure that quite answers the same question.

ie at one level there is a decision that is made about whether a line
in the known hosts file should be evaluated for a given host/port -
and I think that's what you are referring to above.

However once a line from known hosts is allowed for evaluation for a
host/port, there's a second matter of checking whether the certificate
presented contains the appropriate principal.

I think this what "check_host_cert()" does, and as far as I can tell,
OpenSSH only passes it the hostname (not "host:port"). See:
https://github.com/openssh/openssh-portable/blob/f382362e8dfb6b277f16779ab1936399d7f2af78/sshconnect.c#L866

(for better or for worse, this would be roughly inline with X.509v3
cert host matching, which also doesn't match on port numbers)

From michael at stroeder.com  Mon May 15 20:42:40 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 15 May 2017 12:42:40 +0200
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
Message-ID: <3c17462f-4f21-87ec-3fc5-b24c775adb39@stroeder.com>

Adam Eijdenberg wrote:
> I think this what "check_host_cert()" does, and as far as I can tell,
> OpenSSH only passes it the hostname (not "host:port").
> 
> (for better or for worse, this would be roughly inline with X.509v3
> cert host matching, which also doesn't match on port numbers)

If possible OpenSSH IMO should not reproduce this particular deficiency of the TLS
hostname check.

Ciao, Michael.

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

From devel-net-ne-vlezay80 at yandex.ru  Mon May 15 23:38:56 2017
From: devel-net-ne-vlezay80 at yandex.ru (=?utf-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtC70LTRi9GA0LXQsg==?=)
Date: Mon, 15 May 2017 16:38:56 +0300
Subject: ssh ethernet tunnel jumbo frame udp is not work
In-Reply-To: <CALDDTe3GvLekCGXciAYv9tWmOxZXuYrcOv83bQNFeOoh_an55w@mail.gmail.com>
References: <4390871494797077@web17o.yandex.ru>
 <CALDDTe3GvLekCGXciAYv9tWmOxZXuYrcOv83bQNFeOoh_an55w@mail.gmail.com>
Message-ID: <8082281494855536@web12m.yandex.ru>


   Client:

   root at ne-vlezay80:~# ssh -V
   OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t?  3 May 2016
   root at ne-vlezay80:~#
   Server:
   t58065487545 default # ssh -V
   OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t?  3 May 2016
   t58065487545 default #
   Platforms client:
   58065487545 default # uname -r
   3.16.0-4-amd64
   t58065487545 default #
   t58065487545 default # arch
   x86_64
   Platforms server
   root at ne-vlezay80:~# uname -r
   4.10.9
   root at ne-vlezay80:~# arch
   x86_64
   root at ne-vlezay80:~#
   >? - how big the packet was before it was tunnelled? ? was it
   fragmented?
   SSH tunnel ethernet mtu is 2500 bytes. Network MTU 1500 bytes.

   15.05.2017, 02:49, "Darren Tucker" <dtucker at zip.com.au>:

   On Mon, May 15, 2017 at 7:24 AM, ???????????? ?????????????
   <[1]devel-net-ne-vlezay80 at yandex.ru> wrote:

     root at ne-vlezay80:~# tcpdump -i tap0 -n

   You will likely need to supply some more information before anyone can
   even offer any suggestions.?  This includes:
   ? - what version of OpenSSH are the client and server?
   ? - what platforms are they running on? ? which addresses in the dump
   correspond to which?
   ? - how big the packet was before it was tunnelled? ? was it
   fragmented?
   ? - what does the debug logging "ssh -vvv and sshd -ddd" say when this
   occurs?
   --
   Darren Tucker (dtucker at [2]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.

References

   1. mailto:devel-net-ne-vlezay80 at yandex.ru
   2. http://zip.com.au/

From mindrot at hda3.com  Tue May 16 02:38:29 2017
From: mindrot at hda3.com (Peter Moody)
Date: Mon, 15 May 2017 09:38:29 -0700
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
Message-ID: <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>

On Mon, May 15, 2017 at 2:01 AM, Adam Eijdenberg <adam at continusec.com> wrote:
> On Mon, May 15, 2017 at 11:39 AM, Peter Moody <mindrot at hda3.com> wrote:
>> my reading of the sshd manpage is that ssh is more permissive than it should be
>>
>> SSH_KNOWN_HOSTS FILE FORMAT :
>>   ...
>>
>>   A hostname or address may optionally be enclosed within `[' and `]'
>> brackets then followed by `:' and a non-standard port number.
>
> Hi Peter, I'm not sure that quite answers the same question.
>
> ie at one level there is a decision that is made about whether a line
> in the known hosts file should be evaluated for a given host/port -
> and I think that's what you are referring to above.
>
> However once a line from known hosts is allowed for evaluation for a
> host/port, there's a second matter of checking whether the certificate
> presented contains the appropriate principal.
>
> I think this what "check_host_cert()" does, and as far as I can tell,
> OpenSSH only passes it the hostname (not "host:port"). See:
> https://github.com/openssh/openssh-portable/blob/f382362e8dfb6b277f16779ab1936399d7f2af78/sshconnect.c#L866
>
> (for better or for worse, this would be roughly inline with X.509v3
> cert host matching, which also doesn't match on port numbers)

possibly.

your proposed patch removes both checks though. I think you'd want to
modify knownhosts.go if you want to support not including non-standard
ports in IsHostAuthority.

Note, you can also write your own IsHostAuthority that ignores the
port, I think this just affects the HostKeyCallback provided by
golang.org/x/crypto/ssh/knownhosts.

From mindrot at hda3.com  Tue May 16 02:42:14 2017
From: mindrot at hda3.com (Peter Moody)
Date: Mon, 15 May 2017 09:42:14 -0700
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
 <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>
Message-ID: <CADbMJx=ckd=xqFzJR06mCu==nhf6An=cL7NRasH56HOGOF3dEA@mail.gmail.com>

On May 15, 2017 09:38, "Peter Moody" <mindrot at hda3.com> wrote:

On Mon, May 15, 2017 at 2:01 AM, Adam Eijdenberg <adam at continusec.com>
wrote:
> On Mon, May 15, 2017 at 11:39 AM, Peter Moody <mindrot at hda3.com> wrote:
>> my reading of the sshd manpage is that ssh is more permissive than it
should be
>>
>> SSH_KNOWN_HOSTS FILE FORMAT :
>>   ...
>>
>>   A hostname or address may optionally be enclosed within `[' and `]'
>> brackets then followed by `:' and a non-standard port number.
>
> Hi Peter, I'm not sure that quite answers the same question.
>
> ie at one level there is a decision that is made about whether a line
> in the known hosts file should be evaluated for a given host/port -
> and I think that's what you are referring to above.
>
> However once a line from known hosts is allowed for evaluation for a
> host/port, there's a second matter of checking whether the certificate
> presented contains the appropriate principal.
>
> I think this what "check_host_cert()" does, and as far as I can tell,
> OpenSSH only passes it the hostname (not "host:port"). See:
> https://github.com/openssh/openssh-portable/blob/
f382362e8dfb6b277f16779ab1936399d7f2af78/sshconnect.c#L866
>
> (for better or for worse, this would be roughly inline with X.509v3
> cert host matching, which also doesn't match on port numbers)

possibly.

your proposed patch removes both checks though. I think you'd want to
modify knownhosts.go if you want to support not including non-standard
ports in IsHostAuthority.

Note, you can also write your own IsHostAuthority that ignores the
port, I think this just affects the HostKeyCallback provided by
golang.org/x/crypto/ssh/knownhosts.


I could be wrong about that though, I'm about I to jump on an airplane and
I haven't inspected it closely.

From adam at continusec.com  Tue May 16 08:52:34 2017
From: adam at continusec.com (Adam Eijdenberg)
Date: Tue, 16 May 2017 08:52:34 +1000
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
 <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>
Message-ID: <CAD0Csb7Kg9C5fn3S7BwgiU=GUCeoa2tRvdcJ22e7GxD2HnRPSg@mail.gmail.com>

On Tue, May 16, 2017 at 2:38 AM, Peter Moody <mindrot at hda3.com> wrote:
> your proposed patch removes both checks though. I think you'd want to
> modify knownhosts.go if you want to support not including non-standard
> ports in IsHostAuthority.

My intention wasn't to modify both checks - I'm currently only
concerned with principal checking, although I can see how your recent
patch (as implemented) would also be affected (so if we do change
anything here, we'll probably need to refactor a little).

Let me give a concrete example, currently our certificates (OpenSSH
server, and OpenSSH client) look like this and everything works great:

Principals:
        auth.example.local
        auth.example.com.au

However, if I write a Go client (which requires a port number be
specified in their Dial string):

    log.Println(ssh.Dial("tcp", "auth.example.local:10000", &ssh.ClientConfig{
        HostKeyCallback: (&ssh.CertChecker{}).CheckHostKey,
    }))

I get the following error, before even attempting to evaluating
IsHostAuthority():

    ssh: handshake failed: ssh: principal "auth.example.local:10000"
not in the set of valid principals for given certificate:
["auth.example.local" "auth.example.com.au"]


If I want a certificate to work with OpenSSH server, and both Go and
OpenSSH clients, I need to re-generate a certificate like this:

Principals:
        auth.example.local
        auth.example.com.au
        auth.example.local:10000
        auth.example.com.au:10000


That doesn't seem right, and I think the Go principal evaluation is
incorrect, but I would like a second opinion.

(that code in Go also seems to be at least 3 years old)

From mindrot at hda3.com  Tue May 16 09:48:24 2017
From: mindrot at hda3.com (Peter Moody)
Date: Mon, 15 May 2017 16:48:24 -0700
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb7Kg9C5fn3S7BwgiU=GUCeoa2tRvdcJ22e7GxD2HnRPSg@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
 <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>
 <CAD0Csb7Kg9C5fn3S7BwgiU=GUCeoa2tRvdcJ22e7GxD2HnRPSg@mail.gmail.com>
Message-ID: <CADbMJxkzshr_g0vxWpCKj0yM=Aa-vVR4UYWyj7nM-mSQ3Vk8fA@mail.gmail.com>

On Mon, May 15, 2017 at 3:52 PM, Adam Eijdenberg <adam at continusec.com> wrote:
> On Tue, May 16, 2017 at 2:38 AM, Peter Moody <mindrot at hda3.com> wrote:
>> your proposed patch removes both checks though. I think you'd want to
>> modify knownhosts.go if you want to support not including non-standard
>> ports in IsHostAuthority.
>
> My intention wasn't to modify both checks - I'm currently only
> concerned with principal checking, although I can see how your recent
> patch (as implemented) would also be affected (so if we do change
> anything here, we'll probably need to refactor a little).
>
> Let me give a concrete example, currently our certificates (OpenSSH
> server, and OpenSSH client) look like this and everything works great:
>
> Principals:
>         auth.example.local
>         auth.example.com.au
>
> However, if I write a Go client (which requires a port number be
> specified in their Dial string):
>
>     log.Println(ssh.Dial("tcp", "auth.example.local:10000", &ssh.ClientConfig{
>         HostKeyCallback: (&ssh.CertChecker{}).CheckHostKey,
>     }))
>
> I get the following error, before even attempting to evaluating
> IsHostAuthority():
>
>     ssh: handshake failed: ssh: principal "auth.example.local:10000"
> not in the set of valid principals for given certificate:
> ["auth.example.local" "auth.example.com.au"]
>
>
> If I want a certificate to work with OpenSSH server, and both Go and
> OpenSSH clients, I need to re-generate a certificate like this:
>
> Principals:
>         auth.example.local
>         auth.example.com.au
>         auth.example.local:10000
>         auth.example.com.au:10000
>
>
> That doesn't seem right, and I think the Go principal evaluation is
> incorrect, but I would like a second opinion.

I can kind of see the argument that the port shouldn't be in
principal, but it seems a little odd, especially given the known_hosts
restrictions from the sshd manpage, that a cert would be good for all
2^16 ports.

> (that code in Go also seems to be at least 3 years old)

From uri at ll.mit.edu  Tue May 16 09:44:21 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 15 May 2017 23:44:21 +0000
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb7Kg9C5fn3S7BwgiU=GUCeoa2tRvdcJ22e7GxD2HnRPSg@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <CADbMJxk5bkDqpj=OacoWhC6EHYGXSBp1L6bid=WimVQRSXBEpA@mail.gmail.com>
 <CAD0Csb45K6ChcnDOfi8FDDpi=zF_aNM-s39Rh6W-Pu1-+OSwhQ@mail.gmail.com>
 <CADbMJxkf-oBLKQczBPqhjvciXA8Rntvj3xt-R-55yb=fveh=nw@mail.gmail.com>
 <CAD0Csb7Kg9C5fn3S7BwgiU=GUCeoa2tRvdcJ22e7GxD2HnRPSg@mail.gmail.com>
Message-ID: <6E794F44-F634-45C1-9863-DAC57984A95F@ll.mit.edu>

Off-hand, port is not a part of the principal. So the Go code is wrong.

Regards,
Uri

Sent from my iPhone

> On May 15, 2017, at 18:59, Adam Eijdenberg <adam at continusec.com> wrote:
> 
>> On Tue, May 16, 2017 at 2:38 AM, Peter Moody <mindrot at hda3.com> wrote:
>> your proposed patch removes both checks though. I think you'd want to
>> modify knownhosts.go if you want to support not including non-standard
>> ports in IsHostAuthority.
> 
> My intention wasn't to modify both checks - I'm currently only
> concerned with principal checking, although I can see how your recent
> patch (as implemented) would also be affected (so if we do change
> anything here, we'll probably need to refactor a little).
> 
> Let me give a concrete example, currently our certificates (OpenSSH
> server, and OpenSSH client) look like this and everything works great:
> 
> Principals:
>        auth.example.local
>        auth.example.com.au
> 
> However, if I write a Go client (which requires a port number be
> specified in their Dial string):
> 
>    log.Println(ssh.Dial("tcp", "auth.example.local:10000", &ssh.ClientConfig{
>        HostKeyCallback: (&ssh.CertChecker{}).CheckHostKey,
>    }))
> 
> I get the following error, before even attempting to evaluating
> IsHostAuthority():
> 
>    ssh: handshake failed: ssh: principal "auth.example.local:10000"
> not in the set of valid principals for given certificate:
> ["auth.example.local" "auth.example.com.au"]
> 
> 
> If I want a certificate to work with OpenSSH server, and both Go and
> OpenSSH clients, I need to re-generate a certificate like this:
> 
> Principals:
>        auth.example.local
>        auth.example.com.au
>        auth.example.local:10000
>        auth.example.com.au:10000
> 
> 
> That doesn't seem right, and I think the Go principal evaluation is
> incorrect, but I would like a second opinion.
> 
> (that code in Go also seems to be at least 3 years old)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4223 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170515/89684b01/attachment.bin>

From jjelen at redhat.com  Tue May 16 21:20:29 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 16 May 2017 13:20:29 +0200
Subject: Host certificates signed with ed25519 fails with old clients
Message-ID: <12c6bf92-d2df-2cbb-9026-85a4186ab1e0@redhat.com>

Hello all,
recently Fedora infrastructure deployed OpenSSH RSA certificates signed 
with ed25519 CA on server with GIT repositories and we encounter 
problems when connecting from old clients (openssh-5.3p1 + certificates) 
as described in the following bug [1].

There is a known workaround (using only the raw key) and after reading 
some more code around the key exchange and certificates specification, I 
don't see a simple way how to prevent it
  * the client does not know what CA key will be used
  * the server can not select raw RSA (different than would be selected 
by client)

The question is, can/should be the ED25519 keys be used for CA? The 
specification (The line 196 [2]) does not list them or is outdated.  If 
it is a bug, can this be fixed? If it is intended, how to prevent using 
ED25519 keys as CA?

Also reading through the gssgex code I noticed duplicate conditions on 
lines 168 and 172 [3]. Can this be fixed too?

Any more ideas to the current problem?

Attached patches to the minor issues, but not resolving the original 
problem.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1450609
[2] 
https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys#L196
[3] https://github.com/openssh/openssh-portable/blob/master/kexgexc.c#L172

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

From djm at mindrot.org  Wed May 17 02:46:20 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 May 2017 02:46:20 +1000 (AEST)
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>

On Mon, 15 May 2017, Adam Eijdenberg wrote:

> Hi all,
> 
> Last week I noticed that the CertChecker in the Go implementation of
> x/crypto/ssh seems to be doing host principal validation incorrectly
> and filed the following bug:
> https://github.com/golang/go/issues/20273
> 
> By default they are looking for a principal named "host:port" inside
> of the certificate presented by the server, instead of just looking
> for the host as I believe OpenSSH does.

Darren will know better, since IIRC he added the port specifier to
known_hosts originally. But I believe the behaviour is:

If the default port is in use then the host principal is just the hostname.

If a non-default port, then the host principals is "[host]:port".

If a non-default port is in use and "[host]:port" doesn't match, then
try the plain hostname.

-d

From djm at mindrot.org  Wed May 17 03:10:50 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 May 2017 03:10:50 +1000 (AEST)
Subject: Host certificates signed with ed25519 fails with old clients
In-Reply-To: <12c6bf92-d2df-2cbb-9026-85a4186ab1e0@redhat.com>
References: <12c6bf92-d2df-2cbb-9026-85a4186ab1e0@redhat.com>
Message-ID: <alpine.BSO.2.20.1705170246250.14775@natsu.mindrot.org>

On Tue, 16 May 2017, Jakub Jelen wrote:

> Hello all,
> recently Fedora infrastructure deployed OpenSSH RSA certificates signed with
> ed25519 CA on server with GIT repositories and we encounter problems when
> connecting from old clients (openssh-5.3p1 + certificates) as described in the
> following bug [1].

Yeah, the certificate fallback on the client only works if the client
can parse the certificate and the contained signature key. 5.3p1 knew nothing
about Ed25519 keys, so that's not gonna happen.

> There is a known workaround (using only the raw key) and after reading some
> more code around the key exchange and certificates specification, I don't see
> a simple way how to prevent it
>  * the client does not know what CA key will be used
>  * the server can not select raw RSA (different than would be selected by
> client)

The server can specify HostKeyAlgorithms, but that only covers the type of
the certificates offered and not the CA keys used for signatures that are
embedded in them. There's at present no way to vary HostKeyAlgorithms or
the set of hostkeys themselves for old clients.

> The question is, can/should be the ED25519 keys be used for CA? The
> specification (The line 196 [2]) does not list them or is outdated.
> If it is a bug, can this be fixed? If it is intended, how to prevent
> using ED25519 keys as CA?

It's definitely intended that Ed25519 keys are allowed as CA keys and
I've updated PROTOCOL.certkeys to reflect this.

> Also reading through the gssgex code I noticed duplicate conditions on lines
> 168 and 172 [3]. Can this be fixed too?

Fixed; thanks.

> Any more ideas to the current problem?

Not really, and note that a similar problem might happen with certificates
signed with an RSA key using SHA256/512 signatures (possible since
57464e393 by specifying a key type to ssh-keygen).

I've toyed with the idea of adding a "Match banner" capability to
sshd_config. It's a pretty hacky idea, but it would allow things like
overriding HostkeyAlgorithms for old OpenSSH for example.

-d

From adam at continusec.com  Wed May 17 08:10:45 2017
From: adam at continusec.com (Adam Eijdenberg)
Date: Wed, 17 May 2017 08:10:45 +1000
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>
Message-ID: <CAD0Csb6eJ5pM8puVFxjyPRT3KNCH0NGFUuFGqh+oBO5zs78wgw@mail.gmail.com>

On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm at mindrot.org> wrote:
> On Mon, 15 May 2017, Adam Eijdenberg wrote:
>> https://github.com/golang/go/issues/20273
>>
>> By default they are looking for a principal named "host:port" inside
>> of the certificate presented by the server, instead of just looking
>> for the host as I believe OpenSSH does.
>
> Darren will know better, since IIRC he added the port specifier to
> known_hosts originally. But I believe the behaviour is:
>
> If the default port is in use then the host principal is just the hostname.
>
> If a non-default port, then the host principals is "[host]:port".
>
> If a non-default port is in use and "[host]:port" doesn't match, then
> try the plain hostname.

Hi Damien,

I think we're still talking a bit at cross purposes. My question did
not relate to how the known_hosts file is processed (which from
examining code yesterday I think is roughly as you describe) but
rather how should we be validating that a certificate presented by a
host includes an appropriate principal for that host. OpenSSH checks
whether the hostname is a principal, whereas the Go library is instead
checking whether "host:port" is a principal.

Uri (earlier in this thread) does answer this question clearly (that
the principal should be the hostname only), and, now that I've found
PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:

"valid principals" is a string containing zero or more principals as
strings packed inside it. These principals list the names for which this
certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and
usernames for SSH_CERT_TYPE_USER certificates. As a special case, a
zero-length "valid principals" field means the certificate is valid for
any principal of the specified type.

Cheers, Adam

From michael at stroeder.com  Thu May 18 04:29:15 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 17 May 2017 20:29:15 +0200
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <CAD0Csb6eJ5pM8puVFxjyPRT3KNCH0NGFUuFGqh+oBO5zs78wgw@mail.gmail.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>
 <CAD0Csb6eJ5pM8puVFxjyPRT3KNCH0NGFUuFGqh+oBO5zs78wgw@mail.gmail.com>
Message-ID: <969b9d15-733b-0001-57e5-d70601f67e55@stroeder.com>

Adam Eijdenberg wrote:
> On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm at mindrot.org> wrote:
>> On Mon, 15 May 2017, Adam Eijdenberg wrote:
>>> https://github.com/golang/go/issues/20273
>>>
>>> By default they are looking for a principal named "host:port" inside
>>> of the certificate presented by the server, instead of just looking
>>> for the host as I believe OpenSSH does.
>>
>> Darren will know better, since IIRC he added the port specifier to
>> known_hosts originally. But I believe the behaviour is:
>>
>> If the default port is in use then the host principal is just the hostname.
>>
>> If a non-default port, then the host principals is "[host]:port".
>>
>> If a non-default port is in use and "[host]:port" doesn't match, then
>> try the plain hostname.
> 
> I think we're still talking a bit at cross purposes. My question did
> not relate to how the known_hosts file is processed (which from
> examining code yesterday I think is roughly as you describe) but
> rather how should we be validating that a certificate presented by a
> host includes an appropriate principal for that host. OpenSSH checks
> whether the hostname is a principal, whereas the Go library is instead
> checking whether "host:port" is a principal.
> 
> Uri (earlier in this thread) does answer this question clearly (that
> the principal should be the hostname only), and, now that I've found
> PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:

In turn this means:
One cannot expect several SSH services on a single host to be securely distinguishable
from each other by their particular service key. So if one of the SSH services gets
compromised all SSH services on this host are subject to MITM attacks with the private
key of the compromised service.

Ciao, Michael.

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

From michael at stroeder.com  Thu May 18 04:45:57 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 17 May 2017 20:45:57 +0200
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <3DAB53C5-49B1-4CFA-9C98-9B23BAC65F4A@ll.mit.edu>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>
 <CAD0Csb6eJ5pM8puVFxjyPRT3KNCH0NGFUuFGqh+oBO5zs78wgw@mail.gmail.com>
 <969b9d15-733b-0001-57e5-d70601f67e55@stroeder.com>
 <3DAB53C5-49B1-4CFA-9C98-9B23BAC65F4A@ll.mit.edu>
Message-ID: <47826cd1-176e-c566-6fcf-10814eeb47ed@stroeder.com>

Blumenthal, Uri - 0553 - MITLL wrote:
>  
>     > Uri (earlier in this thread) does answer this question clearly (that
>     > the principal should be the hostname only), and, now that I've found
>     > PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:
>     
> In turn this means: One cannot expect several SSH services on a single host to be
> securely distinguishable from each other by their particular service key. So if one of
> the SSH services gets compromised all SSH services on this host are subject to MITM
> attacks with the private key of the compromised service.
> 
> Yes and no. The standards wisely do not allow port numbers as a part of the DNS
> identity.

Ok, then one must access the different services by different FQDN.

> I still think it?s not a very good idea to ?securely distinguish several SSH services
> running on a single host?, but it seems entirely doable if you?re bent on it.

I'm curious: What's wrong to have a different SFTP-only service running on a different
port besides the SSH server for admin shell access?

Ciao, Michael.

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

From uri at ll.mit.edu  Thu May 18 04:42:09 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 17 May 2017 18:42:09 +0000
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <969b9d15-733b-0001-57e5-d70601f67e55@stroeder.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>
 <CAD0Csb6eJ5pM8puVFxjyPRT3KNCH0NGFUuFGqh+oBO5zs78wgw@mail.gmail.com>
 <969b9d15-733b-0001-57e5-d70601f67e55@stroeder.com>
Message-ID: <3DAB53C5-49B1-4CFA-9C98-9B23BAC65F4A@ll.mit.edu>

 
    > Uri (earlier in this thread) does answer this question clearly (that
    > the principal should be the hostname only), and, now that I've found
    > PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:
    
    In turn this means:
    One cannot expect several SSH services on a single host to be securely distinguishable
    from each other by their particular service key. So if one of the SSH services gets
    compromised all SSH services on this host are subject to MITM attacks with the private
    key of the compromised service.
    

Yes and no. The standards wisely do not allow port numbers as a part of the DNS identity.

On the other hand, nobody prevents you from having different key pairs for the same host name, given to different servers that you insist should run on the same host but on different ports (for example, I have one ?name?, but a pile of certificates and corresponding key pairs for that name that I present to different (appropriate) entities). You can even figure how to mix their port numbers into their names (just don?t make it ?hostname? :).

I still think it?s not a very good idea to ?securely distinguish several SSH services running on a single host?, but it seems entirely doable if you?re bent on it.
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/168da314/attachment.bin>

From uri at ll.mit.edu  Thu May 18 04:50:27 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 17 May 2017 18:50:27 +0000
Subject: Golang CertChecker hostname validation differs to OpenSSH
In-Reply-To: <47826cd1-176e-c566-6fcf-10814eeb47ed@stroeder.com>
References: <CAD0Csb67hvaAeC3QfiNkva3Ny8ATO0C2GzekJUh+xVFvLKO24g@mail.gmail.com>
 <alpine.BSO.2.20.1705170241580.14775@natsu.mindrot.org>
 <CAD0Csb6eJ5pM8puVFxjyPRT3KNCH0NGFUuFGqh+oBO5zs78wgw@mail.gmail.com>
 <969b9d15-733b-0001-57e5-d70601f67e55@stroeder.com>
 <3DAB53C5-49B1-4CFA-9C98-9B23BAC65F4A@ll.mit.edu>
 <47826cd1-176e-c566-6fcf-10814eeb47ed@stroeder.com>
Message-ID: <BA6FB5DF-3065-4365-8E7B-D0AA31FF4D23@ll.mit.edu>

    > Yes and no. The standards wisely do not allow port numbers as a part of the DNS
    > identity.
    
    Ok, then one must access the different services by different FQDN.
    
Apparently. That?s what everybody else has been doing for the last umpteen years. ;-)

    > I still think it?s not a very good idea to ?securely distinguish several SSH services
    > running on a single host?, but it seems entirely doable if you?re bent on it.
    
    I'm curious: What's wrong to have a different SFTP-only service running on a different
    port besides the SSH server for admin shell access?

Nothing that I can see off-hand. 

On the other hand, what?s your threat model? If it?s on the same host, how can I compromise one key but not the other?

But as I said, while I would separate by virtual hosting and FQDN, you can craft the certs the way you want ? except that the DNS name in the SAN cannot have the port.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/9e651dde/attachment.bin>

From mh at ow2.org  Thu May 18 20:17:35 2017
From: mh at ow2.org (mh at ow2.org)
Date: Thu, 18 May 2017 12:17:35 +0200
Subject: ls hangs in internal-sftp for LDAP users + numeric uid/gid
 instead of names
In-Reply-To: <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
 <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
 <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>
Message-ID: <448c40d9-bee4-88b6-3d0a-8c1aa68e7aab@ow2.org>

Le 12/05/2017 ? 14:03, Alexander Wuerstlein a ?crit :
> On 2017-05-12T13:49, mh at ow2.org <mh at ow2.org> wrote:
>> Le 12/05/2017 ? 12:47, Alexander Wuerstlein a ?crit :
>>> On 2017-05-12T12:07, mh at ow2.org <mh at ow2.org> wrote:
>>>> I'm using 7.2p2-4ubuntu2.1
>>>>
>>>> I have the same exact problem as described in the first comment in
>>>> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
>>>>
>>>> Initially, my ldap server hostname and IP is only in /etc/hosts, not in
>>>> the configured resolver. I can't use the real IP as a workaround in
>>>> ldap.conf because of the TLS configuration which cares about the hostname.
>>>>
>>>> At the time I add the host name and IP in the resolver, the issue goes away.
>>>>
>>>> So, I'm a bit worried to be forced to declare a record in my DNS to
>>>> enable SFTP listing ? There should be another way isn't ?
>>>>
>>>> I also tried to copy /etc/hosts to etc/hosts in the folder specified by
>>>> ChrootDirectory directive with no more success.
>>>>
>>>> Notice : it happens only for ldap users, not local users
>>>
>>> There should be a /etc/nsswitch.conf in your chroot where you can
>>> configure where users and hostnames should be looked up. E.g. to prevent
>>> LDAP lookups altogether you could configure the respective two lines to
>>> read:
>>> passwd:		files
>>> group:		files
>>> i.e. drop the 'ldap' option there. To check why /etc/hosts isn't being
>>> used you can look if hosts: has 'files dns' or just 'dns' altogether
>>> behind it.
>>>
>>> But in general I would recommend putting all your hostnames into DNS
>>> properly, in my experience this avoids all kinds of headaches with all
>>> kinds of software. And leave /etc/hosts as empty as possible, because
>>> that always grows inconsistent over time.
>>>
>>>
>>
>> Thanks Alexander,
>>
>> I'll try the nsswitch.conf suggestion. Until then I've noticed the
>> following : while the ldap hostname is into the DNS, if I also put a the
>> corresponding line to etc/hosts in the chroot the hang happens again. So
>> the hosts file in the chroot is red somehow.
> 
> It shouldn't hang in that case, thats strange. However, the order of the
> options in nsswitch.conf determines which way to look up the hostname is
> tried first, second, ... etc. One thing that might be a problem (but I'm
> guessing, there might be a lot more going on[0]) would be whether you have
> just the hostname or the FQDN in your ldap.conf and /etc/hosts. And if
> its not the FQDN in some place, then what your search path in
> /etc/resolv.conf and the value of your dnsdomainname might be. 


I currently have in nsswitch.conf, in the etc folder inside the sftp's
chroot (/srv/ftpchroot/etc) :

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files

hosts:          files dns


Since I've update my DNS and switched to libnss-ldapd I can't reproduce
the hang so I'm unsure what was the cause...

However, I get uid/gid numbers instead of names within sftp session (ls
-l) ? I don't know if it's new but I would definitively prefer names...

> 
>> But if it reads the hosts file propertly, what is the problem then ?
> 
> I'm not sure. Maybe try determining if its a ssh/sftp problem first: In
> that chroot, does 'getent passwd' hang? Does it contain only local users
> or ldap users as well? Does 'getent hosts $ldaphostname' hang? If yes,
> its a problem with the libc name services that are behind getent and
> stuff, so you would have to fix the config (in nsswitch.conf and all the
> related things referenced from there). strace-ing the aforementioned
> getent calls might help narrowing things further down.

I'll try to determine this if needed if I bump into the issue again.


Q: How do you mean to run getent in the sftp chroot ? you mean from the
shell ? I would need to copy a bunch of binary/lib files to achieve that
I guess.

(I'm not even sure that the files I put in /srv/ftpchroot/etc are read
in some way)

Regards,

From mh at ow2.org  Thu May 18 21:13:22 2017
From: mh at ow2.org (mh at ow2.org)
Date: Thu, 18 May 2017 13:13:22 +0200
Subject: ls hangs in internal-sftp for LDAP users + numeric uid/gid
 instead of names
In-Reply-To: <448c40d9-bee4-88b6-3d0a-8c1aa68e7aab@ow2.org>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
 <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
 <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>
 <448c40d9-bee4-88b6-3d0a-8c1aa68e7aab@ow2.org>
Message-ID: <df1700f8-5fef-dc52-da0f-f08b2514c3ac@ow2.org>

Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit :
> However, I get uid/gid numbers instead of names within sftp session (ls
> -l) ? I don't know if it's new but I would definitively prefer names...

It seems the reason is :

open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)

okay, etc folder in the chroot wasn't world readable. If I put an entry
in the passwd file, the sftp session start resolving names.

Notice the sftp process is owned by the connecting user, and if etc/
folder is world readable, it means I expose those file to sftp user. I
don't like it but unsure if there is a better solution...

Or I could simply only resolve entries from the ldap and get rid of
passwd file (see below).

I also had this error:
socket(PF_LOCAL, SOCK_STREAM, 0)        = 4
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFD, FD_CLOEXEC|0x2)       = 0
connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) =
-1 ENOENT (No such file or directory)

Of course /var/run/nslcd/socket doesn't exist in the chroot.

To solve this I did :
mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/



From ebarreto at linux.vnet.ibm.com  Thu May 18 23:17:50 2017
From: ebarreto at linux.vnet.ibm.com (Eduardo Barretto)
Date: Thu, 18 May 2017 10:17:50 -0300
Subject: [PATCH 0/3] Allow syscalls for openssl engines
In-Reply-To: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
References: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com>
Message-ID: <3407217a-6c43-e8b2-b80e-5d14a2462a01@linux.vnet.ibm.com>

On 09-05-2017 14:27, Eduardo Barretto wrote:
> This patchset allow syscalls (flock, ipc, getuid, geteuid and ioctl), so
> openssl engines, e.g. OpenSSL-ibmca and OpenSSL-ibmpkcs11, can work and
> communicate with the crypto cards during ssh login.
> 
Hi there,

Is there any doubts or information that I can help with?

Thanks,
Eduardo


From arw at cs.fau.de  Thu May 18 23:38:54 2017
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Thu, 18 May 2017 15:38:54 +0200
Subject: ls hangs in internal-sftp for LDAP users + numeric uid/gid
 instead of names
In-Reply-To: <df1700f8-5fef-dc52-da0f-f08b2514c3ac@ow2.org>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
 <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
 <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>
 <448c40d9-bee4-88b6-3d0a-8c1aa68e7aab@ow2.org>
 <df1700f8-5fef-dc52-da0f-f08b2514c3ac@ow2.org>
Message-ID: <20170518133854.h33hzrr43dhzfx5j@cip.informatik.uni-erlangen.de>

On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote:
> Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit :
> > However, I get uid/gid numbers instead of names within sftp session (ls
> > -l) ? I don't know if it's new but I would definitively prefer names...
> 
> It seems the reason is :
> 
> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
> 
> okay, etc folder in the chroot wasn't world readable. If I put an entry
> in the passwd file, the sftp session start resolving names.
> 
> Notice the sftp process is owned by the connecting user, and if etc/
> folder is world readable, it means I expose those file to sftp user. I
> don't like it but unsure if there is a better solution...
> 
> Or I could simply only resolve entries from the ldap and get rid of
> passwd file (see below).
> 
> I also had this error:
> socket(PF_LOCAL, SOCK_STREAM, 0)        = 4
> fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
> fcntl(4, F_SETFD, FD_CLOEXEC|0x2)       = 0
> connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) =
> -1 ENOENT (No such file or directory)
> 
> Of course /var/run/nslcd/socket doesn't exist in the chroot.
> 
> To solve this I did :
> mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/

Yes, and additionally you want to get rid of 'compat' nsswitch entries,
because those also consult the passwd/group/... files.

Another option, if you don't want to have a socket reaching out of the
chroot (including the corresponding possible chroot escape possibility)
is to just "copy everything from ldap into a local file". Which would be
exactly what https://github.com/google/nsscache does. YMMV.



Ciao,

Alexander Wuerstlein.

From devin.nate at QHRtech.com  Fri May 19 01:53:11 2017
From: devin.nate at QHRtech.com (Devin Nate)
Date: Thu, 18 May 2017 15:53:11 +0000
Subject: [PATCH] / permitgwports / permitlisten
In-Reply-To: <1494634960.27336.5.camel@gmail.com>
References: <E81EE6F2-D2B9-45B8-98B1-AD42FDAEF3E8@qhrtech.com>
 <1494634960.27336.5.camel@gmail.com>
Message-ID: <E4104BCF-B555-4069-ACDF-4A5C4BC12106@qhrtech.com>

Hi Philipp;

Yes, the patch I submitted is one we use to accomplish a specific outcome, and it would break configuration in the wild with respect to permitopen. We provided it in case anyone else gets use out of similar needs. By the same token, the patch I submitted will break gateway ports also (ssh -R), since if they are not explicitly defined our patch will preclude all gateway ports.

To do it more generically, I suppose you would need to have a global config value to identify if the sshd should be either:
1.  default allow all port forwards except as restricted by an authorized_key, or
2.  default deny all port forwards except as permitted by an authorized_key.

The extra wrinkle is what to do about users that auth with username and password or something different which does not allow configuration like authorized_keys, which gets into a whole bunch more complexity.

In our case we wanted the default deny, and our use case does not need to work about breaking everyone else.

Thanks!


>    While I generally agree with having to explicitly whitelist
>   "permitopen" host/port pairs, it does change the default behavior and
>    would probably break configuration in the wild. Or am I mistaken here?
    
    Best
    Philipp
    
    


From pattonme at yahoo.com  Fri May 19 07:51:04 2017
From: pattonme at yahoo.com (matthew patton)
Date: Thu, 18 May 2017 21:51:04 +0000 (UTC)
Subject: feature request: use HOME before getpwnam() in misc.c
References: <2047232830.1287054.1495144264766.ref@mail.yahoo.com>
Message-ID: <2047232830.1287054.1495144264766@mail.yahoo.com>

it's really^3 annoying that no matter the value of $HOME, that tilde_expand_filename() only looks at getpwnam() and friends instead of at least trying getenv("HOME").

What is the use case?

HOME=longpath_to_config1
ssh -i ~/.ssh/key1

HOME=longpath_to_config2
ssh -i ~/.ssh/key2

but getpwnam() defeats this by always accessing what's in the passwd file. So .ssh/known_hosts is likewise read/written outside of $HOME/.ssh/ and the config files too don't remain in local scope.

Sure 99% of users $HOME = pw->pw_dir, but there are a zillion programs that honor $HOME, so why doesn't the SSH client? Is the concern that SSHD obviously should get caught up honoring a problematic path when evaluating Authorized_Keys? Well then have a flag that forces just the use of getpwnam() for paths that are sensitive. Though frankly, I think this case can be narrowed further to just when euid=0 and should blithely use HOME when the daemon was launched by a user on a high port (eg. sshd -D -d).

Thoughts?

From pattonme at yahoo.com  Fri May 19 08:38:04 2017
From: pattonme at yahoo.com (matthew patton)
Date: Thu, 18 May 2017 22:38:04 +0000 (UTC)
Subject: Bug? unnecessarily constrained lengths in path, filename, and user
References: <800129887.1298369.1495147084078.ref@mail.yahoo.com>
Message-ID: <800129887.1298369.1495147084078@mail.yahoo.com>

in misc.c, tilde_expand_filename() PATH_MAX is used. However in readconf.c path and filename components are arbitrarily set to 100 and 100 during the xasprintf() as part of add_identity_file() instead of using NAME_MAX and PATH_MAX.

  (void)xasprintf(&path, "%.100s%.100s", dir, filename);

Also I think it's reasonable that a message should be logged if the input was truncated.

Now, I'm not sure what the knock-on effects are from a portable-edition standpoint, but I believe most libC implementations have the same or similar constants that can be utilized.


In the same vein, misc.c, tilde_expand_filename()
  char user[128]

Granted this is probably a case of sized so big,nobody will hit it. But why not actually leverage the OS' definitions? Or are these limits not easily found? In linux I believe it's 32 char but so far I haven't found the definition in either kernel source nor glibc.


From gert at greenie.muc.de  Fri May 19 16:19:15 2017
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 19 May 2017 08:19:15 +0200
Subject: feature request: use HOME before getpwnam() in misc.c
In-Reply-To: <2047232830.1287054.1495144264766@mail.yahoo.com>
References: <2047232830.1287054.1495144264766.ref@mail.yahoo.com>
 <2047232830.1287054.1495144264766@mail.yahoo.com>
Message-ID: <20170519061915.GU97029@greenie.muc.de>

Hi,

On Thu, May 18, 2017 at 09:51:04PM +0000, matthew patton wrote:
> What is the use case?
> 
> HOME=longpath_to_config1
> ssh -i ~/.ssh/key1
> 
> HOME=longpath_to_config2
> ssh -i ~/.ssh/key2

If you run things like that, the "~" is not expanded by ssh but by your shell.

Try "echo ~/"...

Barking up the wrong tree...

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

From mh at ow2.org  Fri May 19 16:52:44 2017
From: mh at ow2.org (mh at ow2.org)
Date: Fri, 19 May 2017 08:52:44 +0200
Subject: ls hangs in internal-sftp for LDAP users + numeric uid/gid
 instead of names
In-Reply-To: <20170518133854.h33hzrr43dhzfx5j@cip.informatik.uni-erlangen.de>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
 <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
 <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>
 <448c40d9-bee4-88b6-3d0a-8c1aa68e7aab@ow2.org>
 <df1700f8-5fef-dc52-da0f-f08b2514c3ac@ow2.org>
 <20170518133854.h33hzrr43dhzfx5j@cip.informatik.uni-erlangen.de>
Message-ID: <3f8509db-0e39-4f78-4841-c3d76507d97e@ow2.org>

Le 18/05/2017 ? 15:38, Alexander Wuerstlein a ?crit :
> On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote:
>> Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit :
>>> However, I get uid/gid numbers instead of names within sftp session (ls
>>> -l) ? I don't know if it's new but I would definitively prefer names...
>>
>> It seems the reason is :
>>
>> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
>>
>> okay, etc folder in the chroot wasn't world readable. If I put an entry
>> in the passwd file, the sftp session start resolving names.
>>
>> Notice the sftp process is owned by the connecting user, and if etc/
>> folder is world readable, it means I expose those file to sftp user. I
>> don't like it but unsure if there is a better solution...
>>
>> Or I could simply only resolve entries from the ldap and get rid of
>> passwd file (see below).
>>
>> I also had this error:
>> socket(PF_LOCAL, SOCK_STREAM, 0)        = 4
>> fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
>> fcntl(4, F_SETFD, FD_CLOEXEC|0x2)       = 0
>> connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) =
>> -1 ENOENT (No such file or directory)
>>
>> Of course /var/run/nslcd/socket doesn't exist in the chroot.
>>
>> To solve this I did :
>> mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/
> 
> Yes, and additionally you want to get rid of 'compat' nsswitch entries,
> because those also consult the passwd/group/... files.
> 
> Another option, if you don't want to have a socket reaching out of the
> chroot (including the corresponding possible chroot escape possibility)
> is to just "copy everything from ldap into a local file". Which would be
> exactly what https://github.com/google/nsscache does. YMMV.
> 

Hi Alex,
Thanks,
Well, yes, but isn't it comes down exposing all the users entries to the
sftp users? (as I've mentioned above). In my case it's not that critical
but still i'm not comfortable with it in a chroot'd ftp context/usage.



From arw at cs.fau.de  Fri May 19 18:56:31 2017
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Fri, 19 May 2017 10:56:31 +0200
Subject: ls hangs in internal-sftp for LDAP users + numeric uid/gid
 instead of names
In-Reply-To: <3f8509db-0e39-4f78-4841-c3d76507d97e@ow2.org>
References: <b58fcbcc-19e6-796a-1812-1a555b459232@ow2.org>
 <20170512104721.ly65me2lg53fstak@cip.informatik.uni-erlangen.de>
 <9cd9b9a4-887d-0df7-d155-82fcfde29625@ow2.org>
 <20170512120359.5n54oicmawajngdl@cip.informatik.uni-erlangen.de>
 <448c40d9-bee4-88b6-3d0a-8c1aa68e7aab@ow2.org>
 <df1700f8-5fef-dc52-da0f-f08b2514c3ac@ow2.org>
 <20170518133854.h33hzrr43dhzfx5j@cip.informatik.uni-erlangen.de>
 <3f8509db-0e39-4f78-4841-c3d76507d97e@ow2.org>
Message-ID: <20170519085631.bywwz2hr2dsadfbv@cip.informatik.uni-erlangen.de>

On 2017-05-19T08:52, mh at ow2.org <mh at ow2.org> wrote:
> Le 18/05/2017 ? 15:38, Alexander Wuerstlein a ?crit :
> > On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote:
> >> Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit :
> >>> However, I get uid/gid numbers instead of names within sftp session (ls
> >>> -l) ? I don't know if it's new but I would definitively prefer names...
> >>
> >> It seems the reason is :
> >>
> >> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
> >>
> >> okay, etc folder in the chroot wasn't world readable. If I put an entry
> >> in the passwd file, the sftp session start resolving names.
> >>
> >> Notice the sftp process is owned by the connecting user, and if etc/
> >> folder is world readable, it means I expose those file to sftp user. I
> >> don't like it but unsure if there is a better solution...
> >>
> >> Or I could simply only resolve entries from the ldap and get rid of
> >> passwd file (see below).
> >>
> >> I also had this error:
> >> socket(PF_LOCAL, SOCK_STREAM, 0)        = 4
> >> fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
> >> fcntl(4, F_SETFD, FD_CLOEXEC|0x2)       = 0
> >> connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) =
> >> -1 ENOENT (No such file or directory)
> >>
> >> Of course /var/run/nslcd/socket doesn't exist in the chroot.
> >>
> >> To solve this I did :
> >> mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/
> > 
> > Yes, and additionally you want to get rid of 'compat' nsswitch entries,
> > because those also consult the passwd/group/... files.
> > 
> > Another option, if you don't want to have a socket reaching out of the
> > chroot (including the corresponding possible chroot escape possibility)
> > is to just "copy everything from ldap into a local file". Which would be
> > exactly what https://github.com/google/nsscache does. YMMV.
> > 
> 
> Hi Alex,
> Thanks,
> Well, yes, but isn't it comes down exposing all the users entries to the
> sftp users? (as I've mentioned above). In my case it's not that critical
> but still i'm not comfortable with it in a chroot'd ftp context/usage.

Well, if you want UIDs resolved to names, you always have to expose the
UID-name-mapping to the chroot somehow[0]. Considering this exposition of
passwd, there is no big difference between doing it via LDAP or a passwd
file imho.

There are differences however. A file is a little easier to expose via
sftp, since downloading files is what sftp does in normal operations,
and a stray hardlink or some strange misconfiguration could expose it.
Whereas with the nslcd socket, you would perhaps need a more complex
vulnerability to be able to execute getent, talk to the socket, etc. 
However, such a problem which allows accessing the nslcd socket will
enable an attacker to talk to the nslcd outside the chroot, ask it for a
lot more mappings than just passwd (possibly stuff like 'shadow'
containing password hashes...), it also might allow talking to your LDAP
server directly over an authenticated connection, use LDAP exploits or
expose a lot more data that isn't properly secured by LDAP ACLs. And
maybe also escape the chroot via an nslcd vulnerability.

So it comes down to your preferences and estimates as to how likely you
think those possiblities might lead to a security problem, what the
consequences would be and how easy it is to contain those problems.



Ciao,

Alexander Wuerstlein.

[0] The only "advantage" LDAP has in that regard is that the server can
    do rate-limiting. But thats just smoke and mirrors, the attacker
    will get the data eventually. Also, rate-limiting properly is very
    hard, especially in this case where you would just want it for that
    one service, not the whole host or all of your network. Also,
    rate-limiting might also affect legitimate users who then will
    complain. I therefore consider it a very bad idea in general.

From mh at ow2.org  Fri May 19 19:38:49 2017
From: mh at ow2.org (mh at ow2.org)
Date: Fri, 19 May 2017 11:38:49 +0200
Subject: sshd_config : negation in Match blocks
Message-ID: <99d35597-e244-e44e-f5f0-5eb93fbce96f@ow2.org>

Hi,

I want to come to a specific behavior described in
https://access.redhat.com/solutions/289073

For example, taking an user who is NOT a member of a group *-foo

Match Group !*-foo
=> this won't match

Match Group *,!*-foo
=> this will match

I would expect the first to match too, intuitively.

I'm unsure if this behavior is expected, and if not, if it has a
corresponding bug report : is it that one ?
https://bugzilla.mindrot.org/show_bug.cgi?id=1918

(I'm running 7.2p2-4ubuntu2.1)

Regards,

From pattonme at yahoo.com  Fri May 19 21:34:34 2017
From: pattonme at yahoo.com (pattonme at yahoo.com)
Date: Fri, 19 May 2017 07:34:34 -0400
Subject: feature request: use HOME before getpwnam() in misc.c
In-Reply-To: <20170519061915.GU97029@greenie.muc.de>
References: <2047232830.1287054.1495144264766.ref@mail.yahoo.com>
 <2047232830.1287054.1495144264766@mail.yahoo.com>
 <20170519061915.GU97029@greenie.muc.de>
Message-ID: <20170519113434.5787733.18202.19999@yahoo.com>

I'm using bash. The shell does the correct thing.?
Sorry ?didn't give the use case clearly.?

I'm talking about the use of tilde inside client config. ?The example was to illustrate desired behavior. Ssh itself does not eval tilde with any consideration for environment. That is the problem.?

? Original Message ?
From: Gert Doering
Sent: Friday, May 19, 2017 02:19
To: matthew patton
Cc: openssh-unix-dev at mindrot.org
Subject: Re: feature request: use HOME before getpwnam() in misc.c

Hi,

On Thu, May 18, 2017 at 09:51:04PM +0000, matthew patton wrote:
> What is the use case?
> 
> HOME=longpath_to_config1
> ssh -i ~/.ssh/key1
> 
> HOME=longpath_to_config2
> ssh -i ~/.ssh/key2

If you run things like that, the "~" is not expanded by ssh but by your shell.

Try "echo ~/"...

Barking up the wrong tree...

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

From reuti at staff.uni-marburg.de  Fri May 19 21:49:57 2017
From: reuti at staff.uni-marburg.de (Reuti)
Date: Fri, 19 May 2017 13:49:57 +0200
Subject: feature request: use HOME before getpwnam() in misc.c
In-Reply-To: <20170519113434.5787733.18202.19999@yahoo.com>
References: <2047232830.1287054.1495144264766.ref@mail.yahoo.com>
 <2047232830.1287054.1495144264766@mail.yahoo.com>
 <20170519061915.GU97029@greenie.muc.de>
 <20170519113434.5787733.18202.19999@yahoo.com>
Message-ID: <BF9054D7-65EA-4BED-879E-91038307F0C3@staff.uni-marburg.de>

Hi,

> Am 19.05.2017 um 13:34 schrieb pattonme at yahoo.com:
> 
> I'm using bash. The shell does the correct thing.
> Sorry  didn't give the use case clearly.
> 
> I'm talking about the use of tilde inside client config. ?The example was to illustrate desired behavior. Ssh itself does not eval tilde with any consideration for environment. That is the problem.

I think it's by intention. It was just on the Bash mailing list, that even inside $PATH the ~ will be expanded (and it's not easy to get it inside, as it's expanded already at the time of assignment usually), and whether this behavior should be or not.

http://lists.gnu.org/archive/html/bug-bash/2017-05/msg00069.html

What other applications do to allow it (like the queuing system GridEngine), is to have a pseudo variable $HOME in the configuration. It's not the one from the shell per se, but they look it up in case they encounter it in the configuration.

But I'm not sure whether, it would be good to have it in `ssh`. Why not setting up two target machines in the config file?

-- Reuti


>   Original Message
> From: Gert Doering
> Sent: Friday, May 19, 2017 02:19
> To: matthew patton
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: feature request: use HOME before getpwnam() in misc.c
> 
> Hi,
> 
> On Thu, May 18, 2017 at 09:51:04PM +0000, matthew patton wrote:
>> What is the use case?
>> 
>> HOME=longpath_to_config1
>> ssh -i ~/.ssh/key1
>> 
>> HOME=longpath_to_config2
>> ssh -i ~/.ssh/key2
> 
> If you run things like that, the "~" is not expanded by ssh but by your shell.
> 
> Try "echo ~/"...
> 
> Barking up the wrong tree...
> 
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany gert at greenie.muc.de
> fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
> _______________________________________________
> 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: 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/20170519/e7d6050d/attachment.bin>

From pattonme at yahoo.com  Fri May 19 23:06:30 2017
From: pattonme at yahoo.com (pattonme at yahoo.com)
Date: Fri, 19 May 2017 09:06:30 -0400
Subject: feature request: use HOME before getpwnam() in misc.c
In-Reply-To: <BF9054D7-65EA-4BED-879E-91038307F0C3@staff.uni-marburg.de>
References: <2047232830.1287054.1495144264766.ref@mail.yahoo.com>
 <2047232830.1287054.1495144264766@mail.yahoo.com>
 <20170519061915.GU97029@greenie.muc.de>
 <20170519113434.5787733.18202.19999@yahoo.com>
 <BF9054D7-65EA-4BED-879E-91038307F0C3@staff.uni-marburg.de>
Message-ID: <20170519130630.5787733.26465.20001@yahoo.com>

?I have several dozen ssh config files each with 20 host definitions, some with different keys based on how I'm accessing even the same host. But the config files are logically grouped in various HOMES if you will. Think of a consultant who has several clients and for sandbox and name collision reasons needs to keep them out of each other's way. Or if you rather, an operations engineer supporting multiple environments and multiple application stacks which may have external entities manage a collection of config and key files, and obviously the upstream doesn't care if there are conflicts. ?

Being able to key off of HOME is like a mini chroot.?

Hard coding absolute paths into command lines or config files is just silly. The config file is now not sharable.?

I'm simply asking that getenv() be added to the flow instead of only ever consulting getpwnam. ?Log a warning if HOME! =pwdir is fine is you think it merits.?

? Original Message ?
From: Reuti
Sent: Friday, May 19, 2017 07:50
To: pattonme at yahoo.com
Cc: Gert Doering; openssh-unix-dev at mindrot.org
Subject: Re: feature request: use HOME before getpwnam() in misc.c

Hi,

> Am 19.05.2017 um 13:34 schrieb pattonme at yahoo.com:
> 
> I'm using bash. The shell does the correct thing.
> Sorry didn't give the use case clearly.
> 
> I'm talking about the use of tilde inside client config. ?The example was to illustrate desired behavior. Ssh itself does not eval tilde with any consideration for environment. That is the problem.

I think it's by intention. It was just on the Bash mailing list, that even inside $PATH the ~ will be expanded (and it's not easy to get it inside, as it's expanded already at the time of assignment usually), and whether this behavior should be or not.

http://lists.gnu.org/archive/html/bug-bash/2017-05/msg00069.html

What other applications do to allow it (like the queuing system GridEngine), is to have a pseudo variable $HOME in the configuration. It's not the one from the shell per se, but they look it up in case they encounter it in the configuration.

But I'm not sure whether, it would be good to have it in `ssh`. Why not setting up two target machines in the config file?

-- Reuti


> Original Message
> From: Gert Doering
> Sent: Friday, May 19, 2017 02:19
> To: matthew patton
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: feature request: use HOME before getpwnam() in misc.c
> 
> Hi,
> 
> On Thu, May 18, 2017 at 09:51:04PM +0000, matthew patton wrote:
>> What is the use case?
>> 
>> HOME=longpath_to_config1
>> ssh -i ~/.ssh/key1
>> 
>> HOME=longpath_to_config2
>> ssh -i ~/.ssh/key2
> 
> If you run things like that, the "~" is not expanded by ssh but by your shell.
> 
> Try "echo ~/"...
> 
> Barking up the wrong tree...
> 
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany gert at greenie.muc.de
> fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


From djm at mindrot.org  Sat May 20 12:36:26 2017
From: djm at mindrot.org (Damien Miller)
Date: Sat, 20 May 2017 12:36:26 +1000 (AEST)
Subject: Bug? unnecessarily constrained lengths in path, filename, and user
In-Reply-To: <800129887.1298369.1495147084078@mail.yahoo.com>
References: <800129887.1298369.1495147084078.ref@mail.yahoo.com>
 <800129887.1298369.1495147084078@mail.yahoo.com>
Message-ID: <alpine.BSO.2.20.1705201230540.18007@natsu.mindrot.org>

On Thu, 18 May 2017, matthew patton wrote:

> in misc.c, tilde_expand_filename() PATH_MAX is used. However in
> readconf.c path and filename components are arbitrarily set to 100 and
> 100 during the xasprintf() as part of add_identity_file() instead of
> using NAME_MAX and PATH_MAX.
>
>   (void)xasprintf(&path, "%.100s%.100s", dir, filename);
>
> Also I think it's reasonable that a message should be logged if the
> input was truncated.

Thanks, I've replaced the limit with a check that the result doesn't
exceed PATH_MAX.

> In the same vein, misc.c, tilde_expand_filename() char user[128]
>
> Granted this is probably a case of sized so big,nobody will hit it.
> But why not actually leverage the OS' definitions? Or are these limits
> not easily found? In linux I believe it's 32 char but so far I haven't
> found the definition in either kernel source nor glibc.

IIRC some systems lacked an accessible LOGIN_NAME_MAX and
_POSIX_LOGIN_NAME_MAX only provides a lower bound.

-d

From standby24x7 at gmail.com  Mon May 22 17:39:47 2017
From: standby24x7 at gmail.com (Masanari Iida)
Date: Mon, 22 May 2017 16:39:47 +0900
Subject: Add maximum size of RSA key length in man pages?
Message-ID: <CALLJCT1Ha+Pw2eou4P3tc2FXJ=w88hwzL1Yvpuc8US33Qd9FOQ@mail.gmail.com>

Would it possible to add maximum size of RSA key length
in man ssh-keygen.1 as ssh-keygen's limitation.
in man ssh.1 as sshd's limitation.

I think the maximum size for RSA key length in ssh-keygen
is 16384 bits.
And also the sshd support RSA key length up to 16384 bits.

These information could be obvious for developer, but end
user need to find them in man pages.

Regards,
Masanari Iida

From haris.phnx at gmail.com  Wed May 24 16:49:41 2017
From: haris.phnx at gmail.com (haris iqbal)
Date: Wed, 24 May 2017 12:19:41 +0530
Subject: openssh version upgrade
Message-ID: <CAE_WKMwc92iBQ94HMOzG-iv5PzN9v8YUWoKh8ydcudvd5oLhwg@mail.gmail.com>

Hello,

I have a personal application which uses openssh code for secure
connection. However, I have not updated the codebase from a long time.
Is it possible to get diffs for every version upgrade. That would make
my life very easy.

-- 

With regards,

Md Haris Iqbal

From phil at hands.com  Wed May 24 17:12:02 2017
From: phil at hands.com (Philip Hands)
Date: Wed, 24 May 2017 09:12:02 +0200
Subject: openssh version upgrade
In-Reply-To: <CAE_WKMwc92iBQ94HMOzG-iv5PzN9v8YUWoKh8ydcudvd5oLhwg@mail.gmail.com>
References: <CAE_WKMwc92iBQ94HMOzG-iv5PzN9v8YUWoKh8ydcudvd5oLhwg@mail.gmail.com>
Message-ID: <871sreu3st.fsf@whist.hands.com>

haris iqbal <haris.phnx at gmail.com> writes:

> Hello,
>
> I have a personal application which uses openssh code for secure
> connection. However, I have not updated the codebase from a long time.
> Is it possible to get diffs for every version upgrade. That would make
> my life very easy.

As mentioned here:

  https://anongit.mindrot.org/openssh.git

you can get hold of the complete change history via git, here:

  https://anongit.mindrot.org/openssh.git

You should probably read up on git -- it will let you wind the history
back to the point where you last did an update, apply your changes, and
then help with rebasing your patch on the latest version.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170524/cfbed1bd/attachment.bin>

From mh at ow2.org  Wed May 24 17:53:51 2017
From: mh at ow2.org (mh at ow2.org)
Date: Wed, 24 May 2017 09:53:51 +0200
Subject: sshd_config : negation in Match blocks
In-Reply-To: <99d35597-e244-e44e-f5f0-5eb93fbce96f@ow2.org>
References: <99d35597-e244-e44e-f5f0-5eb93fbce96f@ow2.org>
Message-ID: <375d8639-ce19-6be9-e4f8-b06b5512d065@ow2.org>

Hi,

Might it be the wrong place for this question ?
Or is it considered as minor because a workaround exists ?

Thanks !

Regards,

Le 19/05/2017 ? 11:38, mh at ow2.org a ?crit :
> Hi,
> 
> I want to come to a specific behavior described in
> https://access.redhat.com/solutions/289073
> 
> For example, taking an user who is NOT a member of a group *-foo
> 
> Match Group !*-foo
> => this won't match
> 
> Match Group *,!*-foo
> => this will match
> 
> I would expect the first to match too, intuitively.
> 
> I'm unsure if this behavior is expected, and if not, if it has a
> corresponding bug report : is it that one ?
> https://bugzilla.mindrot.org/show_bug.cgi?id=1918
> 
> (I'm running 7.2p2-4ubuntu2.1)
> 
> Regards,
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


From vapier at gentoo.org  Thu May 25 13:21:19 2017
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 24 May 2017 23:21:19 -0400
Subject: [PATCH] configure: actually set cache vars when cross-compiling
Message-ID: <20170525032119.4948-1-vapier@gentoo.org>

From: Mike Frysinger <vapier at chromium.org>

The cross-compiling fallback message says it's assuming the test
passed, but it didn't actually set the cache var which causes
later tests to fail.
---
 configure.ac | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5cfea38c0a6c..895c5211ea93 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3162,7 +3162,8 @@ AC_RUN_IFELSE(
 	 select_works_with_rlimit=yes],
 	[AC_MSG_RESULT([no])
 	 select_works_with_rlimit=no],
-	[AC_MSG_WARN([cross compiling: assuming yes])]
+	[AC_MSG_WARN([cross compiling: assuming yes])
+	 select_works_with_rlimit=yes]
 )
 
 AC_MSG_CHECKING([if setrlimit(RLIMIT_NOFILE,{0,0}) works])
@@ -3188,7 +3189,8 @@ AC_RUN_IFELSE(
 	 rlimit_nofile_zero_works=yes],
 	[AC_MSG_RESULT([no])
 	 rlimit_nofile_zero_works=no],
-	[AC_MSG_WARN([cross compiling: assuming yes])]
+	[AC_MSG_WARN([cross compiling: assuming yes])
+	 rlimit_nofile_zero_works=yes]
 )
 
 AC_MSG_CHECKING([if setrlimit RLIMIT_FSIZE works])
-- 
2.12.0


From djm at mindrot.org  Thu May 25 14:36:09 2017
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 May 2017 14:36:09 +1000 (AEST)
Subject: [PATCH] configure: actually set cache vars when
 cross-compiling
In-Reply-To: <20170525032119.4948-1-vapier@gentoo.org>
References: <20170525032119.4948-1-vapier@gentoo.org>
Message-ID: <alpine.BSO.2.20.1705251436040.2688@natsu.mindrot.org>

applied - thanks

On Wed, 24 May 2017, Mike Frysinger wrote:

> From: Mike Frysinger <vapier at chromium.org>
> 
> The cross-compiling fallback message says it's assuming the test
> passed, but it didn't actually set the cache var which causes
> later tests to fail.
> ---
>  configure.ac | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 5cfea38c0a6c..895c5211ea93 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3162,7 +3162,8 @@ AC_RUN_IFELSE(
>  	 select_works_with_rlimit=yes],
>  	[AC_MSG_RESULT([no])
>  	 select_works_with_rlimit=no],
> -	[AC_MSG_WARN([cross compiling: assuming yes])]
> +	[AC_MSG_WARN([cross compiling: assuming yes])
> +	 select_works_with_rlimit=yes]
>  )
>  
>  AC_MSG_CHECKING([if setrlimit(RLIMIT_NOFILE,{0,0}) works])
> @@ -3188,7 +3189,8 @@ AC_RUN_IFELSE(
>  	 rlimit_nofile_zero_works=yes],
>  	[AC_MSG_RESULT([no])
>  	 rlimit_nofile_zero_works=no],
> -	[AC_MSG_WARN([cross compiling: assuming yes])]
> +	[AC_MSG_WARN([cross compiling: assuming yes])
> +	 rlimit_nofile_zero_works=yes]
>  )
>  
>  AC_MSG_CHECKING([if setrlimit RLIMIT_FSIZE works])
> -- 
> 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  Thu May 25 15:04:25 2017
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 May 2017 15:04:25 +1000 (AEST)
Subject: sshd_config : negation in Match blocks
In-Reply-To: <375d8639-ce19-6be9-e4f8-b06b5512d065@ow2.org>
References: <99d35597-e244-e44e-f5f0-5eb93fbce96f@ow2.org>
 <375d8639-ce19-6be9-e4f8-b06b5512d065@ow2.org>
Message-ID: <alpine.BSO.2.20.1705251502060.2688@natsu.mindrot.org>

There are some bugs for this:

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

I tried to fix it once, but the obvious fix had non-obvious corner
cases.

On Wed, 24 May 2017, mh at ow2.org wrote:

> Hi,
> 
> Might it be the wrong place for this question ?
> Or is it considered as minor because a workaround exists ?
> 
> Thanks !
> 
> Regards,
> 
> Le 19/05/2017 ? 11:38, mh at ow2.org a ?crit :
> > Hi,
> > 
> > I want to come to a specific behavior described in
> > https://access.redhat.com/solutions/289073
> > 
> > For example, taking an user who is NOT a member of a group *-foo
> > 
> > Match Group !*-foo
> > => this won't match
> > 
> > Match Group *,!*-foo
> > => this will match
> > 
> > I would expect the first to match too, intuitively.
> > 
> > I'm unsure if this behavior is expected, and if not, if it has a
> > corresponding bug report : is it that one ?
> > https://bugzilla.mindrot.org/show_bug.cgi?id=1918
> > 
> > (I'm running 7.2p2-4ubuntu2.1)
> > 
> > Regards,
> > _______________________________________________
> > 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
> 

From jjelen at redhat.com  Thu May 25 19:22:28 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Thu, 25 May 2017 11:22:28 +0200
Subject: PROTOCOL still mentions v00 cert keys
Message-ID: <58405409-b15f-487c-2639-b6dec0e5b6fa@redhat.com>

Hello,
the v00 certificate keys were removed some time ago, but they are still 
mentioned in the PROTOCOL. Should not they be removed too?

[1] https://github.com/openssh/openssh-portable/blob/master/PROTOCOL#L36

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

From djm at mindrot.org  Fri May 26 11:40:21 2017
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 May 2017 11:40:21 +1000 (AEST)
Subject: PROTOCOL still mentions v00 cert keys
In-Reply-To: <58405409-b15f-487c-2639-b6dec0e5b6fa@redhat.com>
References: <58405409-b15f-487c-2639-b6dec0e5b6fa@redhat.com>
Message-ID: <alpine.BSO.2.20.1705261140140.2688@natsu.mindrot.org>

On Thu, 25 May 2017, Jakub Jelen wrote:

> Hello,
> the v00 certificate keys were removed some time ago, but they are still
> mentioned in the PROTOCOL. Should not they be removed too?

Fixed - thanks.

From tomas.kuthan at oracle.com  Fri May 26 19:16:36 2017
From: tomas.kuthan at oracle.com (Tomas Kuthan)
Date: Fri, 26 May 2017 11:16:36 +0200
Subject: sftp idle timeout
Message-ID: <72b33ade-a018-2dc8-464d-d1ffa3b11c63@oracle.com>

Hi team,

Any chance my patch introducing new sftp-server option '-t idle_timout' 
[1,2] could be accepted into openssh/openssh-portable?

Thanks!
Tomas

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2718
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2719

From djm at mindrot.org  Mon May 29 12:13:18 2017
From: djm at mindrot.org (Damien Miller)
Date: Mon, 29 May 2017 12:13:18 +1000 (AEST)
Subject: sftp idle timeout
In-Reply-To: <72b33ade-a018-2dc8-464d-d1ffa3b11c63@oracle.com>
References: <72b33ade-a018-2dc8-464d-d1ffa3b11c63@oracle.com>
Message-ID: <alpine.BSO.2.20.1705291211230.40559@natsu.mindrot.org>

On Fri, 26 May 2017, Tomas Kuthan wrote:

> Hi team,
> 
> Any chance my patch introducing new sftp-server option '-t idle_timout' [1,2]
> could be accepted into openssh/openssh-portable?

I think the best place to implement a idle timeout is in sshd. Then it
could be made per-channel and be able to cover login sessions as well.

That was requested in https://bugzilla.mindrot.org/show_bug.cgi?id=1338

-d

From devang at teaksi.com  Mon May 29 20:59:42 2017
From: devang at teaksi.com (Devang Modi)
Date: Mon, 29 May 2017 16:29:42 +0530
Subject: A Feature Request
Message-ID: <CACa9Spq9h+MwX+_CXjRJcxLbG+=-kBAyq3v1WW7WPQR57au1fQ@mail.gmail.com>

Dear Sir,

I wish to highlight a security limitation for OpenSSH/PAM.

Issue is attached with openssh-server-5.3p1-122.el6.x86_64
and pam-1.1.1-24.el6.x86_64. Or Both.

*Description of Issue:*

When some unknown visitor tries to open SSH connection and does not submit
password, */var/log/secure* log file is not logging source IP.

In absence of such information (IP) it will be tough to find and block such
visitor.

In case of DDoS attack, were attacker is not giving password but just
establishing connection on SSH, administrator become helpless.

But in same kind of attack or attempt , if unknown visitor submit password
string, openssh logs IP in /var/log/secure log file under name called rhost.

Kindly confirm and possible register this as a feature request.

thanks
Devang



---------- Forwarded message ----------
From: CVE Request <CVE-Request at mitre.org>
Date: Fri, May 19, 2017 at 6:00 PM
Subject: CVE Request 336279 for CVE ID Request
To: "devang at teaksi.com" <devang at teaksi.com>


Thank you for your submission. It will be reviewed by a CVE Assignment Team
member.





Changes, additions, or updates to your request can be sent to the CVE Team
by replying directly to this email.



Please do not change the subject line, which allows us to effectively track
your request.



CVE Assignment Team

M/S M300, 202 Burlington Road, Bedford, MA 01730 USA

[A PGP key is available for encrypted communications at

http://cve.mitre.org/cve/request_id.html]







{CMI: MCID920225}







-- 
Devang Modi
DBA, SCJP, RHCSA, RHCE
(91-79-40077845, 91-9377012569)



-- 
Devang Modi
DBA, SCJP, RHCSA, RHCE
(91-79-40077845, 91-9377012569)

From tomas.kuthan at oracle.com  Tue May 30 00:19:28 2017
From: tomas.kuthan at oracle.com (Tomas Kuthan)
Date: Mon, 29 May 2017 16:19:28 +0200
Subject: sftp idle timeout
In-Reply-To: <alpine.BSO.2.20.1705291211230.40559@natsu.mindrot.org>
References: <72b33ade-a018-2dc8-464d-d1ffa3b11c63@oracle.com>
 <alpine.BSO.2.20.1705291211230.40559@natsu.mindrot.org>
Message-ID: <c2ed890a-f48e-28a9-0a76-c973b6060e94@oracle.com>

On 05/29/17 04:13 AM, Damien Miller wrote:
> On Fri, 26 May 2017, Tomas Kuthan wrote:
>
>> Hi team,
>>
>> Any chance my patch introducing new sftp-server option '-t idle_timout' [1,2]
>> could be accepted into openssh/openssh-portable?
>
> I think the best place to implement a idle timeout is in sshd. Then it
> could be made per-channel and be able to cover login sessions as well.
>
> That was requested in https://bugzilla.mindrot.org/show_bug.cgi?id=1338

Hi Damien,

Thank you for the pointer, much appreciated.

In this particular deployment, limiting the idle timeout to sftp 
sessions only would actually be preferable. High numbers of regular sftp 
users are expected, with only an occasional admin shell access here and 
there.

What are your reasons for not liking the sftp-server-centric solution?
(I admit implementing the timeout in the underlying ssh layer is a more 
generic solution and it allows for a more graceful tear-down.)

I see ssh idle timeout surfaced on the alias a couple times before, but 
never made it into the code. Are you saying that the idea itself is 
viable and that a patch could be accepted?

Thanks!
Tomas

From frank at digennaro.com  Mon May 29 01:39:04 2017
From: frank at digennaro.com (Frank DiGennaro)
Date: Sun, 28 May 2017 11:39:04 -0400
Subject: Problem upgrading OpenSSH/SSHD on CentOS 7
Message-ID: <000301d2d7c8$8a7d1550$9f773ff0$@com>

All; 
    I've upgraded OpenSSH/SSHD on CentOS 6 to version 7.5 without a problem.
However, when I try to upgrade it on CentOS 7, I'm having problems. When I
try to start SSHD on a CentOS 7 server using "systemctl start sshd", I never
get back to the prompt. It just seems to hang there. However, when I ctrl-c
out of it and check, SSHD is running. This happens if I try to start the
service manually or automatically on boot. Has anyone seen this before? Any
insight at all would be greatly appreciated. 


Thanks; 
FSD 

 

 

 


From djm at mindrot.org  Tue May 30 10:05:13 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 May 2017 10:05:13 +1000 (AEST)
Subject: A Feature Request
In-Reply-To: <CACa9Spq9h+MwX+_CXjRJcxLbG+=-kBAyq3v1WW7WPQR57au1fQ@mail.gmail.com>
References: <CACa9Spq9h+MwX+_CXjRJcxLbG+=-kBAyq3v1WW7WPQR57au1fQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1705300959490.40559@natsu.mindrot.org>

On Mon, 29 May 2017, Devang Modi wrote:

> Dear Sir,
> I wish to highlight a security limitation for OpenSSH/PAM.
> 
> Issue is attached with?openssh-server-5.3p1-122.el6.x86_64
> and?pam-1.1.1-24.el6.x86_64. Or Both.

This is a really old OpenSSH release
https://www.openssh.com/releasenotes.html#5.3 says it's 7.5 years old.

This is what the current version does:

[djm at haru ssh]$ ssh ::1
djm@::1's password: 
^C
[djm at haru ssh]$ tail -2 /var/log/authlog
May 30 10:01:10 fuyu sshd[11899]: Connection from ::1 port 27606 on ::1 port 22
May 30 10:01:12 fuyu sshd[11899]: Connection closed by authenticating user djm ::1 port 27606 [preauth]

authlog being where OpenBSD sends auth.info syslog messages.

-d

From djm at mindrot.org  Tue May 30 16:47:21 2017
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 May 2017 16:47:21 +1000 (AEST)
Subject: sftp idle timeout
In-Reply-To: <c2ed890a-f48e-28a9-0a76-c973b6060e94@oracle.com>
References: <72b33ade-a018-2dc8-464d-d1ffa3b11c63@oracle.com>
 <alpine.BSO.2.20.1705291211230.40559@natsu.mindrot.org>
 <c2ed890a-f48e-28a9-0a76-c973b6060e94@oracle.com>
Message-ID: <alpine.BSO.2.20.1705301636080.12685@natsu.mindrot.org>

On Mon, 29 May 2017, Tomas Kuthan wrote:

> In this particular deployment, limiting the idle timeout to sftp
> sessions only would actually be preferable. High numbers of regular
> sftp users are expected, with only an occasional admin shell access
> here and there.
>
> What are your reasons for not liking the sftp-server-centric solution?
> (I admit implementing the timeout in the underlying ssh layer is a
> more generic solution and it allows for a more graceful tear-down.)
>
> I see ssh idle timeout surfaced on the alias a couple times before,
> but never made it into the code. Are you saying that the idea itself
> is viable and that a patch could be accepted?

The problem is that the mainloop is an old select()-based monster, so
adding a decent timer system to it will be ugly and will make it harder
to fix later.

Once Markus finishes the refactoring that he's working on at the moment,
I'm planning on taking a look at cleaning the mainloop up and adding a
decent timer mechanism.

I'm reticent to add a special-case timer to sftp-server before that
happens, though improving sftp's reporting of the underlying ssh
connection going away seems like a good idea.

-d

From jjelen at redhat.com  Tue May 30 19:27:39 2017
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 30 May 2017 11:27:39 +0200
Subject: Problem upgrading OpenSSH/SSHD on CentOS 7
In-Reply-To: <000301d2d7c8$8a7d1550$9f773ff0$@com>
References: <000301d2d7c8$8a7d1550$9f773ff0$@com>
Message-ID: <6399cafe-0e30-c6bc-958b-55b66483b203@redhat.com>

On 05/28/2017 05:39 PM, Frank DiGennaro wrote:
> All;
>      I've upgraded OpenSSH/SSHD on CentOS 6 to version 7.5 without a problem.
> However, when I try to upgrade it on CentOS 7, I'm having problems. When I
> try to start SSHD on a CentOS 7 server using "systemctl start sshd", I never
> get back to the prompt. It just seems to hang there. However, when I ctrl-c
> out of it and check, SSHD is running. This happens if I try to start the
> service manually or automatically on boot. Has anyone seen this before? Any
> insight at all would be greatly appreciated.

This is a problem of systemd, that it does not know how to track the 
running services:

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

Unfortunately not yet part of OpenSSH.

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

From tomas.kuthan at oracle.com  Tue May 30 22:45:54 2017
From: tomas.kuthan at oracle.com (Tomas Kuthan)
Date: Tue, 30 May 2017 14:45:54 +0200
Subject: sftp idle timeout
In-Reply-To: <alpine.BSO.2.20.1705301636080.12685@natsu.mindrot.org>
References: <72b33ade-a018-2dc8-464d-d1ffa3b11c63@oracle.com>
 <alpine.BSO.2.20.1705291211230.40559@natsu.mindrot.org>
 <c2ed890a-f48e-28a9-0a76-c973b6060e94@oracle.com>
 <alpine.BSO.2.20.1705301636080.12685@natsu.mindrot.org>
Message-ID: <7a383714-b296-394f-726f-c4134d24bc8a@oracle.com>

On 05/30/17 08:47 AM, Damien Miller wrote:
> On Mon, 29 May 2017, Tomas Kuthan wrote:
>
>> In this particular deployment, limiting the idle timeout to sftp
>> sessions only would actually be preferable. High numbers of regular
>> sftp users are expected, with only an occasional admin shell access
>> here and there.
>>
>> What are your reasons for not liking the sftp-server-centric solution?
>> (I admit implementing the timeout in the underlying ssh layer is a
>> more generic solution and it allows for a more graceful tear-down.)
>>
>> I see ssh idle timeout surfaced on the alias a couple times before,
>> but never made it into the code. Are you saying that the idea itself
>> is viable and that a patch could be accepted?
>
> The problem is that the mainloop is an old select()-based monster, so
> adding a decent timer system to it will be ugly and will make it harder
> to fix later.
>
> Once Markus finishes the refactoring that he's working on at the moment,
> I'm planning on taking a look at cleaning the mainloop up and adding a
> decent timer mechanism.
>
> I'm reticent to add a special-case timer to sftp-server before that
> happens, though improving sftp's reporting of the underlying ssh
> connection going away seems like a good idea.

Hi Damien,

Thank you for the background, that was very helpful.

Tomas


From bagajjal at microsoft.com  Wed May 31 08:33:53 2017
From: bagajjal at microsoft.com (Balu Gajjala)
Date: Tue, 30 May 2017 22:33:53 +0000
Subject: select() is not called properly in ssh_exchange_identification()
Message-ID: <BY2PR21MB00500473686BE96BF9AA784CC9F00@BY2PR21MB0050.namprd21.prod.outlook.com>

Hi,

I found an issue with select() not called properly in the ssh_exchange_identification().

Variable "fdset" is passed as readfd, exceptionfd to the select().
Select() should be called with independent fdset so we should have two different variables instead of reusing the same variable "fdset".
Here is the code snippet. The reported issue is in line 566, 567.

Please let me know the procedure to create an official bug.

[cid:image001.png at 01D2D95A.23728F00]

Thanks,
Balu

From djm at mindrot.org  Wed May 31 12:51:00 2017
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 May 2017 12:51:00 +1000 (AEST)
Subject: select() is not called properly in ssh_exchange_identification()
In-Reply-To: <BY2PR21MB00500473686BE96BF9AA784CC9F00@BY2PR21MB0050.namprd21.prod.outlook.com>
References: <BY2PR21MB00500473686BE96BF9AA784CC9F00@BY2PR21MB0050.namprd21.prod.outlook.com>
Message-ID: <alpine.BSO.2.20.1705311250370.12572@natsu.mindrot.org>

On Tue, 30 May 2017, Balu Gajjala wrote:

> Hi,
> 
> I found an issue with select() not called properly in the ssh_exchange_identification().
> 
> Variable "fdset" is passed as readfd, exceptionfd to the select().
> Select() should be called with independent fdset so we should have two different variables instead of reusing the same variable "fdset".
> Here is the code snippet. The reported issue is in line 566, 567.
> 
> Please let me know the procedure to create an official bug.

It's probably time to switch this to poll(2)

diff --git a/sshconnect.c b/sshconnect.c
index a9cc9f3..e6c8388 100644
--- a/sshconnect.c
+++ b/sshconnect.c
@@ -26,6 +26,7 @@
 #include <fcntl.h>
 #include <netdb.h>
 #include <paths.h>
+#include <poll.h>
 #include <signal.h>
 #include <pwd.h>
 #include <stdio.h>
@@ -322,12 +323,10 @@ static int
 timeout_connect(int sockfd, const struct sockaddr *serv_addr,
     socklen_t addrlen, int *timeoutp)
 {
-	fd_set *fdset;
-	struct timeval tv, t_start;
+	struct timeval t_start;
 	socklen_t optlen;
 	int optval, rc, result = -1;
-
-	gettimeofday(&t_start, NULL);
+	struct pollfd pfd;
 
 	if (*timeoutp <= 0) {
 		result = connect(sockfd, serv_addr, addrlen);
@@ -346,16 +345,18 @@ timeout_connect(int sockfd, const struct sockaddr *serv_addr,
 		goto done;
 	}
 
-	fdset = xcalloc(howmany(sockfd + 1, NFDBITS),
-	    sizeof(fd_mask));
-	FD_SET(sockfd, fdset);
-	ms_to_timeval(&tv, *timeoutp);
-
 	for (;;) {
-		rc = select(sockfd + 1, NULL, fdset, NULL, &tv);
+		gettimeofday(&t_start, NULL);
+		pfd.fd = sockfd;
+		pfd.events = POLLIN;
+		rc = poll(&pfd, 1, *timeoutp);
+		ms_subtract_diff(&t_start, timeoutp);
 		if (rc != -1 || errno != EINTR)
 			break;
 	}
+	/* Socket may have connected by exhausted timeout anyway */
+	if (*timeoutp <= 0)
+		rc = 0;
 
 	switch (rc) {
 	case 0:
@@ -364,7 +365,7 @@ timeout_connect(int sockfd, const struct sockaddr *serv_addr,
 		break;
 	case -1:
 		/* Select error */
-		debug("select: %s", strerror(errno));
+		debug("poll: %s", strerror(errno));
 		break;
 	case 1:
 		/* Completed or failed */
@@ -387,8 +388,6 @@ timeout_connect(int sockfd, const struct sockaddr *serv_addr,
 		fatal("Bogus return (%d) from select()", rc);
 	}
 
-	free(fdset);
-
  done:
  	if (result == 0 && *timeoutp > 0) {
 		ms_subtract_diff(&t_start, timeoutp);
@@ -536,12 +535,9 @@ ssh_exchange_identification(int timeout_ms)
 	int connection_out = packet_get_connection_out();
 	u_int i, n;
 	size_t len;
-	int fdsetsz, remaining, rc;
-	struct timeval t_start, t_remaining;
-	fd_set *fdset;
-
-	fdsetsz = howmany(connection_in + 1, NFDBITS) * sizeof(fd_mask);
-	fdset = xcalloc(1, fdsetsz);
+	int remaining, rc;
+	struct timeval t_start;
+	struct pollfd pfd;
 
 	send_client_banner(connection_out, 0);
 
@@ -551,10 +547,9 @@ ssh_exchange_identification(int timeout_ms)
 		for (i = 0; i < sizeof(buf) - 1; i++) {
 			if (timeout_ms > 0) {
 				gettimeofday(&t_start, NULL);
-				ms_to_timeval(&t_remaining, remaining);
-				FD_SET(connection_in, fdset);
-				rc = select(connection_in + 1, fdset, NULL,
-				    fdset, &t_remaining);
+				pfd.fd = connection_in;
+				pfd.events = POLLIN;
+				rc = poll(&pfd, 1, remaining);
 				ms_subtract_diff(&t_start, &remaining);
 				if (rc == 0 || remaining <= 0)
 					fatal("Connection timed out during "
@@ -563,7 +558,7 @@ ssh_exchange_identification(int timeout_ms)
 					if (errno == EINTR)
 						continue;
 					fatal("ssh_exchange_identification: "
-					    "select: %s", strerror(errno));
+					    "poll: %s", strerror(errno));
 				}
 			}
 
@@ -594,7 +589,6 @@ ssh_exchange_identification(int timeout_ms)
 		debug("ssh_exchange_identification: %s", buf);
 	}
 	server_version_string = xstrdup(buf);
-	free(fdset);
 
 	/*
 	 * Check that the versions match.  In future this might accept

From oleg.zhurakivskyy at intel.com  Wed May 31 17:02:42 2017
From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy)
Date: Wed, 31 May 2017 10:02:42 +0300
Subject: [PATCH 1/1] Process the IdentityFile option from the included files
In-Reply-To: <20170531070242.13299-1-oleg.zhurakivskyy@intel.com>
References: <20170531070242.13299-1-oleg.zhurakivskyy@intel.com>
Message-ID: <20170531070242.13299-2-oleg.zhurakivskyy@intel.com>

---
 readconf.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/readconf.c b/readconf.c
index 4be5327..066ab25 100644
--- a/readconf.c
+++ b/readconf.c
@@ -1032,14 +1032,12 @@ parse_time:
 		arg = strdelim(&s);
 		if (!arg || *arg == '\0')
 			fatal("%.200s line %d: Missing argument.", filename, linenum);
-		if (*activep) {
-			intptr = &options->num_identity_files;
-			if (*intptr >= SSH_MAX_IDENTITY_FILES)
-				fatal("%.200s line %d: Too many identity files specified (max %d).",
-				    filename, linenum, SSH_MAX_IDENTITY_FILES);
-			add_identity_file(options, NULL,
-			    arg, flags & SSHCONF_USERCONF);
-		}
+		intptr = &options->num_identity_files;
+		if (*intptr >= SSH_MAX_IDENTITY_FILES)
+			fatal("%.200s line %d: Too many identity files specified (max %d).",
+				filename, linenum, SSH_MAX_IDENTITY_FILES);
+		add_identity_file(options, NULL,
+					arg, flags & SSHCONF_USERCONF);
 		break;
 
 	case oCertificateFile:
-- 
2.9.3


From oleg.zhurakivskyy at intel.com  Wed May 31 17:02:41 2017
From: oleg.zhurakivskyy at intel.com (Oleg Zhurakivskyy)
Date: Wed, 31 May 2017 10:02:41 +0300
Subject: [PATCH 0/1] Process the IdentityFile option from the included files
Message-ID: <20170531070242.13299-1-oleg.zhurakivskyy@intel.com>

Hello,

This change is to get the IdentityFile option processed
from the included configuration files.

Regards,
Oleg

Oleg Zhurakivskyy (1):
  Process the IdentityFile option from the included files

 readconf.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

-- 
2.9.3