[Bug 3392] New: allow to unset additive options

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Thu Feb 17 13:28:07 AEDT 2022


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

            Bug ID: 3392
           Summary: allow to unset additive options
           Product: Portable OpenSSH
           Version: 8.8p1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

There are a number of options, for which the general principle:
  "For each parameter, the first obtained value will be used."
doesn't apply, e.g. ListenAddress, (Deny|Allow)(Users|Groups), and
more,
but which are rather additive.

This has several problems, especially with more complex configurations,
when using e.g. Match blocks (consider different services that are
tunnels via SSH, like git and so on).
In a Match block, one couldn't e.g. "undo" an earlier DenyUser * .

It's also unfortunate when one wants to do some general base config
file (e.g. the sshd_config) which is used on all nodes, and adapted to
the host via "smart" Includes.

E.g. the following works:
sshd_config:
   Include user-authz.config
   PermitRootLogin      no

If user-authz.config doesn't exist, it will fall back to
PermitRootLogin no, but if it was overwritten in user-authz.config
(which may be a nicely documented template), it wouldn't be used, cause
it already gotten it's value before.


This doesn't however work in e.g. this:
sshd_config:
   Include user-authz.config
   DenyUsers *

where the idea would be to simply deny any users, unless this was
revised with some "DenyUser <unset>" in user-authz.config.

A workaround (read: hack) would be:
sshd_config:
   Include user-authz.config
   AllowUsers nobdy
trusting/hoping, that nobody has it's shell set to /bin/false or so.


Similarly one cannot have:
sshd_config:
   Include listen-addresses.config
   ListenAddress localhost
well, one can but not with the following in mind:
If nothing is set in listen-addresses.config, sshd should fallback to
listening on localhost ONLY (better safe than sorry)... okay that still
works actually, but then, one really must specify the outbund interface
as ListenAddress 1.2.3.4 in listen-addresses.config.

For servers that's easily possible (with the caveat, that one couldn't
undo the listening on localhost)... but on e.g. VMs or so I'd want
something for listen-addresses.config like: ListenAddress <any>




One could do this with +/-/etc. operands (which is already supported by
some.

E.g.
AllowUsers + foo bar baz      (add these)
AllowUsers - badboy           (remove that)
ListenAddress = 1.2.3.4       (set these, and remove whatever has been
there before)

with just and empty:
ListenAddress =
or
DenyUsers =
meaning, go back to it's default.


With some smart re-ordering, that would make the above example working:
sshd_config:
   DenyUsers *
   Include user-authz.config

user-authz.config:
   AllowUsers alice bob
   DenyUsers =

It would of course still require some "manual" un-setting (back to the
default) of DenyUsers in the subconfig.




An alternative could be yet another operator like e.g. '?', where:
?directive would mean, to only consider that line, if the directive has
not yet a value, so above one could do then:
sshd_config:
   Include user-authz.config
   ?DenyUsers *

user-authz.config:
   AllowUsers alice bob
   #DenyUsers =     (not anymore needed)

But that's perhaps a bit overkill (or did I already propose to swtich
so some XML-based config schema?! O;-P )



Thanks,
Chris.


[0] Speaking of ListenAddress, did I ever ask for supporting hostnames
there? I.e. just resolved once for the address(es) on startup.
That had the benefit, that one could e.g. do something like:
4.4.4.4 myserverip.localhost
and use myserverip.localhost as addresse... should the address
change,... one only needs to modify it in one central place.
Works with many daemons...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list