On Fri, Apr 22, 2016 at 8:39 PM, Damien Miller <djm@xxxxxxxxxxx> 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? _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
