On one VM we had two files in ~/.ssh: ~/.ssh/id_ed25519 & ~/.ssh/id_ed25519.pub.
I wanted to deploy an SSH keypair to said machine and basically did
[component:sshkeypair]
id_ed25519 = <redacted>
Now, ~/.ssh/id_ed25519 had the correct private key, but ~/.ssh/id_ed25519.pub had an old public key.
Interestingly, this lead to SSH failing with "Permission denied (public key)" while cloning a git repository. The issue could be fixed by updating the .pub file, though I'm pretty sure that removing it would've solved the issue as well.
This is counter-intuitive and should be changed IMHO. I'd suggest that when updating the private key, the corresponding pubkey should be removed or always being derived from the private key (i.e. ssh-keygen -y -f ~/.ssh/id_ed25519). To me, this seems like a more sensible default than what we currently have, so I'd explicitly suggest to make this the default given how SSH behaves if pubkey and private key don't match.
On one VM we had two files in
~/.ssh:~/.ssh/id_ed25519&~/.ssh/id_ed25519.pub. I wanted to deploy an SSH keypair to said machine and basically didNow,
~/.ssh/id_ed25519had the correct private key, but~/.ssh/id_ed25519.pubhad an old public key.Interestingly, this lead to SSH failing with "Permission denied (public key)" while cloning a git repository. The issue could be fixed by updating the
.pubfile, though I'm pretty sure that removing it would've solved the issue as well.This is counter-intuitive and should be changed IMHO. I'd suggest that when updating the private key, the corresponding pubkey should be removed or always being derived from the private key (i.e.
ssh-keygen -y -f ~/.ssh/id_ed25519). To me, this seems like a more sensible default than what we currently have, so I'd explicitly suggest to make this the default given how SSH behaves if pubkey and private key don't match.