bugzilla-daemon at mindrot.org
2024-Apr-09 17:08 UTC
[Bug 3678] New: ssh "Failed to add the host to the list of known hosts" in "~/.ssh/known_hosts.d/" yet also can read ~/.ssh/known_hosts file
https://bugzilla.mindrot.org/show_bug.cgi?id=3678
Bug ID: 3678
Summary: ssh "Failed to add the host to the list of known
hosts" in "~/.ssh/known_hosts.d/" yet also
can read
~/.ssh/known_hosts file
Product: Portable OpenSSH
Version: 9.2p1
Hardware: amd64
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: ssh
Assignee: unassigned-bugs at mindrot.org
Reporter: ps at chiltern.org.uk
I have to Debian servers, one running OpenSSH_9.2p1 Debian-2+deb12u2
and one running OpenSSH_8.4p1 Debian-5+deb11u3. I need to ssh between
them from time to time. Having not done this since doing debian
distrobution updates I was getting unknown host messages, which is odd
because I can still ssh into both machines from another computer
(running OpenSSH_7.9p1, LibreSSL 2.7.3) without any issue or any
warnings about unknown hosts....
The authenticity of host '#############' can't be established.
ECDSA key fingerprint is SHA256:########################.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Failed to add the host to the list of known hosts
(/home/#####/.ssh/known_hosts.d/host1).
I other than a different host name and fingerprint I get exactly the
same error on both debian servers.... In both cases I can login fine,
but since known host is never saved so know checking of impersonation
can happen. I've tried manually adding the host key to
~/.ssh/known_hosts file:
host1 ecdsa-sha2-nistp256 ######################################...
But it still can't find it. Yet it I manually generate a figureprint
using "ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub" it matches...
So
there isn't any impersonation going on, just ssh can't read old
known_hosts file, and can't create it's new known_host.d folder or
files within....
The folder ~/.ssh/known_hosts.d/ didn't exist on either server, so I've
tried creating it on one, but ssh still didn't seem to about able to
create the key file, even after checking permission and folder
ownership (with just ls -lh):
-rw-r--r-- 1 user user 888 May 5 2021 known_hosts
drw-r--r-- 1 user user 38 Apr 9 16:51 known_hosts.d
I then manually created file that ssh was trying to create using nano,
which I could only then save if using root permissions.
What is very odd is that you can see this file without root
permissions:
user at host2:~/.ssh$ ls -lh ./known_hosts.d/
ls: cannot access './known_hosts.d/host1': Permission denied
total 0
-????????? ? ? ? ? ? host1
peter at debianThinkCentre:~/.ssh$ sudo ls -lh ./known_hosts.d/
[sudo] password for user:
total 4.0K
-rw-r--r-- 1 user user 1 Apr 9 16:51 host1
This would explain why ssh can't create the file, but it's beyond me
why this permissions issue exists.
I search other bug on here for "~/.ssh/known_hosts.d/" and only one
came up which didn't seem relevent. I've spend a few hours today search
internet more widely for anything about ~/.ssh/known_hosts.d/ and all
of the documentation and guidance all seems to talk of known_hosts file
and nothing of known_hosts.d folder. I notice this was only introduced
in v8.4 which is I guess why machine running OpenSSH_7.9p1 which I
mostly use as ssh client doesn't have the same issue.
This seems like there might be a bug to me, but it might be some quirk
of this configuation/setup which lack of documentation of known_hosts.d
folder make hard to unpick. Advice would be much appreciated if this
isn't a bug. Happy to try more things or share more infomation helpful.
---------------------------------
The only other think I think relevent to flag is that on both machines
I've got file in /etc/ssh/sshd_config.d/ with the following:
"AllowUsers ...
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
HostKeyAlgorithms
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
Macs hmac-sha2-256,hmac-sha2-512"
However commenting this out seems to make no difference.
--
You are receiving this mail because:
You are watching the assignee of the bug.