Indeed, correct. I must have known this as recently as a few months ago,
as I did have to verify a host key not long ago and it was a non-event.
I guess this morning I was overthinking it.
The longer story is that I got an unrepeatable host key error doing a
backup with "rsync -e ssh" which is what got me started comparing keys
(or erroneously, key hashes) in the first place. The error was a
transient... I'll never know what it was.
Thanks again!
Judah
On 4/15/24 08:49, J. Milgram wrote:
ohhh... that would explain both. Thanks! (I'll check the keys later
today and report back.)
Judah
On 4/15/24 08:26, Moshe M. Katz wrote:
The known_hosts file does not contain a hash of the public key, it
contains the actual ASCII-armored content of the public key. (There's
also a `HashKnownHosts` option, but it is disabled by default, and if
you had it enabled you would not see the IP address in the file.)
If you look at the man page for ssh-keygen, you will see that it
always returns the fingerprint of the PUBLIC key - If you provide it
with a private key file name, it will look for the matching public
key in the same directory.
Moshe
On Mon, Apr 15, 2024, 8:01 AM J. Milgram <milg...@cgpp.com> wrote:
UMLUG,
For my education on ssh, a question:
desktop:~: ssh -v laptop
...
debug1: Host '10.0.0.172' is known and matches the ED25519 host key.
debug1: Found key in /home/milgram/.ssh/known_hosts:21
...
And connects as expected.
Which is comforting. But the key in line 21 in that file (on
desktop)
doesn't actually match the host key on laptop.
desktop:~/.ssh: sed -n '21 p' known_hosts
10.0.0.172 ssh-ed25519 AAAAC3Nz...SajQBib
laptop:/etc/ssh: ssh-keygen -l -f ssh_host_ed25519_key.pub
256 SHA256:NGSOhqPQ...AjzClhc r...@dart.cgpp.com (ED25519)
(ellipses mine)
And indeed I can't find lqptop's ...AjzClhc host key anywhere in
desktop's ~/.ssh/known_hosts file.
How can this be?
BTW I haven't set StrictHostKeyChecking, but whatever the case, it
should refuse to connect if host key changes.
Again, this is an inverse problem: everything works ... but it
shouldn't.
Related question: It seems "ssh-keygen -l" generates the same
footprint
for each of the private and public key pairs.
laptop:/etc/ssh:ROOT: for f in ssh_host_ed25519_key*; do echo $f &&
ssh-keygen -l -f $f; done
ssh_host_ed25519_key
256 SHA256:NGSOhqPQvvz/MmzhK4xD...DAjzClhc root@laptop... (ED25519)
ssh_host_ed25519_key.pub
256 SHA256:NGSOhqPQvvz/MmzhK4xD...DAjzClhc root@laptop... (ED25519)
But the key and key.pub files are obviously different ... is this
the
way it's supposed to work? I guess it's convenient to have the key
map
to the pair, rather than having two keys. But how can this work?
That
is, private and public keys are different files, how can both
yield the
same fingerprint, especially when one only has access to one of
them at
a time? Must be one of those PKI things.
thanks, as always!
Judah
-- =====
milg...@cgpp.com
301-257-7069
You received this email because you are subscribed to the UM Linux
User's Group (UM-LINUX) mailing list. If you would like to
unsubscribe from this list, simply send an email to
lists...@listserv.umd.edu with the message signoff UM-LINUX in the
body.
--
=====
milg...@cgpp.com
301-257-7069
You received this email because you are subscribed to the UM Linux User's Group
(UM-LINUX) mailing list. If you would like to unsubscribe from this list,
simply send an email to lists...@listserv.umd.edu with the message signoff
UM-LINUX in the body.
