How aggressively should I subclass to keep DRY?

This question occurred to me when an answer was proposed to another question I asked. Suppose I have a base class

public abstract class BaseClass {}

with some decent number of derived classes- let's say more than half a dozen. Most of those derived classes share no similarity beyond what they inherit from the base class, but two of them have a similarity like so

public class OneOfMyDerivedClasses : BaseClass
{
    public string SimilarProperty {get; set;}
    //Other implementation details
}

public class AnotherOneOfMyDerivedClasses : BaseClass
{
    public string SimilarProperty {get; set;}
    //Other implementation details, dissimilar to those in OneOfMyDerivedClasses
}

That's it. That's the only similarity that any of the subclasses share beyond what was inherited from BaseClass. In my actual application I've solved this with an interface IHaveSimilarProperty defining the single SimilarProperty property, as all I care about is that an object implements said interface in use. But since I have duplication, should I be defining an intermediate base class for these two derived classes to inherit from, ie

public abstract IntermediateBaseClass : BaseClass
{
    public string SimilarProperty {get; set;}
}

I could also combine both approaches, decorating the intermediate class with the interface...

So my question is around whether or not this is sufficient duplication to warrant an intermediate base class in terms of OOP best practices. Should I aggressively eliminate all duplication at every turn or should I take a more pragmatic approach? If the latter, what are the rules of thumb that would push me to choose one approach over the other?