Well, I goofed and entered the wrong network name while trying to set up keys for a new network: # tincd -n existing_net -K Generating 2048 bits keys: ............................................+++++ p ..................................................................+++++ q Done. Please enter a file to save private RSA key to [/etc/tinc/existing_net/rsa_key.priv]: Warning: old key(s) found and disabled. Please enter a file to save public RSA key to [/etc/tinc/existing_net/hosts/host_on_existing_net]: ^C I realized my error when tinc warned me, thus the ^C. Now /etc/tinc/existing_net/rsa_key.priv has been replaced, while /etc/tinc/existing_net/hosts/host_on_existing_net still contains the old public key. When tinc says it "disabled" the old key, did it it in fact *delete* it? I haven't found it anywhere on the system. I should look at source, but pressed for time right now. (Of course, that's when these mistakes ALWAYS happen.) host_on_existing_net still has access to existing_net. I assume it will lose access when tinc is restarted unless I fix the config. It's a problem because some remote hosts are reachable only via existing_net, and have host_on_existing_net's now-old public key. Thanks, Frank
On 2019/11/24 16:52, Frank Myhr wrote: > When tinc says it "disabled" the old key, did it it in fact *delete* it? > I haven't found it anywhere on the system. Crisis averted. Turns out I have another local host whose public key is known by my remote hosts. So I can use this 2nd local host to update host_on_existing_net's public key on the remote hosts and all should be good. Still, I'd prefer tincd to issue a warning and prompt for confirmation *before* it proceeds to overwrite an existing key.
On Sun, Nov 24, 2019 at 04:52:41PM -0500, Frank Myhr wrote:> Well, I goofed and entered the wrong network name while trying to set up > keys for a new network: > > # tincd -n existing_net -K > Generating 2048 bits keys: > ............................................+++++ p > ..................................................................+++++ q > Done. > Please enter a file to save private RSA key to > [/etc/tinc/existing_net/rsa_key.priv]: > Warning: old key(s) found and disabled. > Please enter a file to save public RSA key to > [/etc/tinc/existing_net/hosts/host_on_existing_net]: ^C > > I realized my error when tinc warned me, thus the ^C. > Now /etc/tinc/existing_net/rsa_key.priv has been replaced, while > /etc/tinc/existing_net/hosts/host_on_existing_net still contains the old > public key. > > When tinc says it "disabled" the old key, did it it in fact *delete* it?No, it did not. The old key is still in rsa_key.priv, between markers that say "BEGIN OLD" and "END OLD". To recover the old key, remove the new key (which has been placed after the old one), and change the words "OLD" to "RSA".> I assume it will lose > access when tinc is restarted unless I fix the config.Correct. I hope this helps! -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20191125/6cfaffee/attachment.sig>
On Sun, Nov 24, 2019 at 06:07:40PM -0500, Frank Myhr wrote:> Still, I'd prefer tincd to issue a warning and prompt for confirmation > *before* it proceeds to overwrite an existing key.It doesn't ever overwrite old keys. And it does print out a warning when it disables an old key. But I can indeed add a prompt in this case that asks whether to update the key files or not. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20191125/dcc42000/attachment.sig>
On 2019/11/25 02:19, Guus Sliepen wrote:> On Sun, Nov 24, 2019 at 04:52:41PM -0500, Frank Myhr wrote: > >> Well, I goofed and entered the wrong network name while trying to >> set up keys for a new network: >> >> # tincd -n existing_net -K Generating 2048 bits keys: >> ............................................+++++ p >> ..................................................................+++++ >> q Done. Please enter a file to save private RSA key to >> [/etc/tinc/existing_net/rsa_key.priv]: Warning: old key(s) found >> and disabled. Please enter a file to save public RSA key to >> [/etc/tinc/existing_net/hosts/host_on_existing_net]: ^C >> >> I realized my error when tinc warned me, thus the ^C. Now >> /etc/tinc/existing_net/rsa_key.priv has been replaced, while >> /etc/tinc/existing_net/hosts/host_on_existing_net still contains >> the old public key. >> >> When tinc says it "disabled" the old key, did it it in fact >> *delete* it? > > No, it did not. The old key is still in rsa_key.priv, between > markers that say "BEGIN OLD" and "END OLD". To recover the old key, > remove the new key (which has been placed after the old one), and > change the words "OLD" to "RSA". > >> I assume it will lose access when tinc is restarted unless I fix >> the config. > > Correct. I hope this helps!Yes! Thank you very much, that helps a lot! tinc's behavior now makes good sense. I should have taken a closer look at the old key file, I just saw that its modification date and signature had changed, didn't think to actually look inside...!>> Still, I'd prefer tincd to issue a warning and prompt for >> confirmation *before* it proceeds to overwrite an existing key. > > It doesn't ever overwrite old keys. And it does print out a warning > when it disables an old key. But I can indeed add a prompt in this > case that asks whether to update the key files or not.It's great that tinc doesn't overwrite old keys, thank you very much for explaining that. That said, having that prompt would have saved me some (more) gray hairs yesterday. As it was, I finally remembered that the filesystem in question was on ZFS. So recovering the old key file was as easy as copying it back from a recent snapshot. Of course if I manage to do this again (!) I'll simply edit the key file as you point out. Thanks! Frank