Module compatibility issues are a longtime recurring matter. A variety of approaches to various aspects of the problem have been devised over the years. The best and most reliable solution I have so far encountered is first and foremost architectural: plan and implement your modules and manifest set so that each resource is the responsibility of exactly one module. Having done that, you can rely on the singleton character of Puppet classes to allow you to declare your need for a particular feature wherever is appropriate, without risking duplicate resource errors.
In your particular case, that would involve factoring the ssh server resources out into their own module, either one of your own or one of the many existing third-party modules for the purpose, such as
ghoneycutt's. Then each of the two modules you started with uses an include-like declaration of the appropriate class(es) from that module to assert its need for ssh services. For ghoneycutt-ssh, that would be simply
Note well that an include-like class declaration should be used, not a resource-like class declaration. That also means that whatever customization is required must be performed via
automated data binding.
This does tend to apply pressure toward having many fine-grained modules. A well-regarded way to deal with that, among other issues, is to implement the
Roles & Profiles pattern. That won't reduce the number of modules, but it will provide a way to aggregate them into sensible logical units.
John