On Fri, Apr 22, 2016 at 3:41 AM, Damien Miller <djm at mindrot.org> wrote:> On Tue, 19 Apr 2016, Elouan Keryell-Even wrote: > >> Hello, >> >> I have a client machine and a server machine. I generated a pair of >> private-public rsa keys using ssh-keygen. >> >> On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa >> >> On the server machine, I appended the content of the public key to >> .ssh/authorized_keys >> >> I can successfully connect from the client to the server with that config. >> >> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file >> that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with >> ?Permission denied (publickey).? >> >> Error on the server-side (sshd logs): >> >> error: RSA_public_decrypt failed: >> error:0407006A:lib(4):func(112):reason(106) > > 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.> diff --git a/sshconnect2.c b/sshconnect2.c > index 1cf48a2..5a27392 100644 > --- a/sshconnect2.c > +++ b/sshconnect2.c > @@ -1243,6 +1243,14 @@ load_identity_file(Identity *id) > quit = 1; > break; > } > + if (private != NULL && id->key != NULL && > + !sshkey_equal(id->key, private)) { > + error("Load key \"%s\": private key does not match " > + "public key", id->filename); > + sshkey_free(private); > + private = NULL; > + quit = 1; > + } > if (!quit && private != NULL && id->agent_fd == -1 && > !(id->key && id->isprivate)) > maybe_add_key_to_agent(id->filename, private, comment, > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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
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). > > -dIs 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?