Client-side public key causing mess

[Nico Kadel-Garcia]

On Fri, Apr 22, 2016 at 8:39 PM, Damien Miller <djm at mindrot.org> wrote:
> On Fri, 22 Apr 2016, Mauricio Tavares wrote:
>
>> > ssh uses the public key to avoid loading or decrypting the private
>> > key for cases were it isn't necessary. We should improve the handling
>> > of cases where they don't match.
>> >
>>       But if it does not have the public key whose name matches the
>> private key being used, it will still work, right? If that is the case
>> I too think it should handle non-matching key pairs better. i.e.
>> ignore behave as if there was just a private key there (which is how I
>> use it). Or let user decide if it should warn, ignore completely, or
>> quit.
>
> Having a mismatched private and public key is an invalid configuration.
> We don't need to implement complicated recovery logic for it, we can
> just tell the user and they can fix it themself (or not).
>
> -d

Is a published requirement that a local copy of a key, such as
$HOME/.ssh/id_rsa, match a copy of the local public key, such as
$HOME/.ssh/id_rsa.pub, and vice versa? While it seems very sensible,
I've certainly seen people replicate one to a new working environment
without the other, and later accidentally copy the other file from a
new working environment. I've not really seen anyone get bitten hard
by this discrepancy since they'mostly using ssh-agent or the Windows
"Pageant" tool, but if it's a requirement I've seen nothing stating it
explicitly.

Is this a good reason to discard keeping public keys around?