There are several directives that allow multiple values to be configured. This is mostly done by space or comma separating them. The ListenAddress and Port directives however accept only a single value. In order to configure multiple values, the directive should be used multiple times. Consider AcceptEnv: "Multiple environment variables may be separated by whitespace or spread across multiple AcceptEnv directives". If the configuration was done like AcceptEnv it would not break current configs, and the inconsistency would be fixed. FYI the reason I'm looking to have this patched is that my sshd_configs are being constructed from a configuration management system that has key->value pairs, so using multiple directives isn't possible. This isn't a problem as almost all directives allow multiple values - except the mentioned ones.
I'm not sure what you're asking for: are you asking 1) that Port and ListenAddress accept multiple arguments on the one line? or 2) That Port and ListenAddress accept multiple values on multiple lines? IMO #1 is possible (Port already does AFAIK, but not ListenAddress). #2 is not going to happen - AcceptEnv was a mistake I wish I could undo :(
(In reply to Damien Miller from comment #1) > I'm not sure what you're asking for: are you asking > > 1) that Port and ListenAddress accept multiple arguments on the one > line? > > or > > 2) That Port and ListenAddress accept multiple values on multiple > lines? > > IMO #1 is possible (Port already does AFAIK, but not ListenAddress). > #2 is not going to happen - AcceptEnv was a mistake I wish I could > undo :( Ah OK, I see. Maybe AcceptEnv is the wrong example. What I'm after is being able to do: ListenAddress 192.168.1.6 10.10.12.4 172.16.8.3 2001:610:148::1 This is possible for many other configuration options. Instead I'm having to do: ListenAddress 192.168.1.6 ListenAddress 10.10.12.4 ListenAddress 172.16.8.3 ListenAddress 2001:610:148::1 This is inconsistent and means I'm having to create exceptions in my Ansible deployment code... Dick
Unfortunately this is another case we can't easily fix as ListenAddress accepts multiple space-separated arguments already (e.g. "ListenAddress [::]:2222 rdomain 1").
closing resolved bugs as of 8.6p1 release