allowing host wildcards in PermitOpen

[Peter Moody]

I have a need to be able to permit ssh proxying to any host in prod,
but only permit arbitrary ssh port forwards to a very small set of
hosts. With the current PermitOpen config syntax, I can only specify a
wildcard in the port field, but I would like to be able to add
something like the following on my production jumphosts:

PermitOpen *:22 special-forwarding-gateway:*

the attached patch implements this functionality in the most basic way
possible. It's possible people may want fancier filtering (CIDR based,
or *.corp.foo.com), I could add that too if you'd prefer.

Let me know what sort of CLA you need to have signed. I've gotten the
go-ahead from our legal folks to submit this.

Cheers,
peter
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Darren Tucker]

On Tue, Jul 19, 2016 at 1:05 PM, Peter Moody <pmo...@uber.com> wrote:
> I have a need to be able to permit ssh proxying to any host in prod,
> but only permit arbitrary ssh port forwards to a very small set of
> hosts. With the current PermitOpen config syntax, I can only specify a
> wildcard in the port field, but I would like to be able to add
> something like the following on my production jumphosts:
>
> PermitOpen *:22 special-forwarding-gateway:*
>
> the attached patch implements this functionality in the most basic way
> possible.

Your patch got stripped by the list software (it strips any non-text
mime types for safety reasons).

There's already an open bug for this:
https://bugzilla.mindrot.org/show_bug.cgi?id=2582.
I'd suggest adding your patch there (and maybe comparing it to the
other implementation).

> It's possible people may want fancier filtering (CIDR based,
> or *.corp.foo.com), I could add that too if you'd prefer.
>
> Let me know what sort of CLA you need to have signed. I've gotten the
> go-ahead from our legal folks to submit this.

As long as any new code is licensed under BSD-compatible terms[1] it
should be fine. For new code we prefer ISC[2] style but from your
description is sounds like there may not be a significant piece of new
work.

[1] http://www.openbsd.org/policy.html
[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/misc/license.template?rev=HEAD

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