sshd_config: ability to define more than one ListenAddress

[alexanderdavidsen]

It would have been great if sshd_config should was able to define more than one ListeAddress. When I try to define two or more ListenAddresses only the first is written to the configuration file.

I have tried defined ListenAddress in the following way:

                sshd_config {'ListenAddress':
                        value => ['10.0.0.1', '10.0.0.2'],
                }

Only 10.0.0.1 is written to /etc/ssh/sshd_config

Please let me know if I need to provide more information.

Regards,
Alexander

[domcleal]

This has now been fixed in 3700366, so it creates a new setting for each value in the array (with the exception of the existing multi-value settings such as AcceptEnv).

Thanks for the report.

[domcleal]

Hi Alexander,

Please could you try out the fix present in this branch and let me if that fixes it?
https://github.com/domcleal/augeasproviders/tree/13-sshd-listen

This now includes tests for cases when the Match section doesn't exist in the config file so should be more robust.

[alexanderdavidsen]

Hi Dominic!

Great work!!

Seems to working as it should now. The only this I can see is that the
tests are case-sensitive (probably by design?).

If I have listenaddress or Listenaddress defined with a IP, this is ignored
and two new entries are added. I get:
Listenaddress 10.0.0.1
ListenAddress 10.0.0.2
ListenAddress 10.0.01

This could be by design and I'm not sure whether this should be handled by
the module or just ignored. Opensshd accepts both values, but I assume that
ListenAddres is the correct way of defining the options. I guess this
applies to other options as well.

Regards,
Alexander

On Sun, Sep 23, 2012 at 4:24 PM, Dominic Cleal notifications@github.comwrote:

Hi Alexander,

Please could you try out the fix present in this branch and let me if that
fixes it?
https://github.com/domcleal/augeasproviders/tree/13-sshd-listen

This now includes tests for cases when the Match section doesn't exist in
the config file so should be more robust.

—
Reply to this email directly or view it on GitHubhttps://github.com/domcleal/augeasproviders/issues/13#issuecomment-8798907.

[domcleal]

Thanks for testing, I'll push that code later then.

The case sensitivity is definitely a problem, but I don't have a good solution yet. Raphael is trying to get a regexpi() function for case-insensitive regular expressions into Augeas, which might give us a way to match on existing entries irrespective of case.

Until then I think we'd need to rewrite aug_match ourselves, which might be an option. I'll file another issue about it anyway.

[domcleal]

964c5f8 pushed and issue #15 filed for case sensitivity.