How to ignore ssh known_hosts

B

balanga

I'm constantly changing various devices around my LAN and often run into the man-in-the-middle attack warning from ssh() and have no use for the known_hosts. I have tried to suppress its usage, but haven't figured out how.

Are these the parameters I need to change?

# HostbasedAuthentication
#IgnoreUserKnownHosts no
 
Yeah, ssh may be quite stubborn in cases when we want to move the slider towards convenience and away from security.

My personal working use case and local environment is based on the following:
  • I use key based authentication
  • my ssh client is OpenSSH_9.4p1, LibreSSL 3.3.6
If I already have some outdated host identification recorded within ~/.ssh/known_hosts then I get the following reasoning from the ssh:
Code: 
> ssh taarch64
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:kWUpXSI46+GTc4Nu/KkYtjP21do6UeW4//rnNIMOAI4.
Please contact your system administrator.
Add correct host key in /home/igoro/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/igoro/.ssh/known_hosts:38
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
UpdateHostkeys is disabled because the host key is not trusted.
Last login: Thu Nov 16 08:31:16 2023 from 10.0.2.2
FreeBSD 15.0-CURRENT (GENERIC) #0 main-n266315-b2b381d365fc: Thu Nov  9 03:49:34 UTC 2023
[ ... ]
root@taarch64:~ #

It explicitly says that password-based auth is off: "Password authentication is disabled to avoid man-in-the-middle attacks.".

But if I clean my ~/.ssh/known_hosts from such old records or remove the file completely, then StrictHostKeyChecking no option works with password-based authentication:
Code: 
> ssh taarch64
Warning: Permanently added '[127.0.0.1]:2202' (ED25519) to the list of known hosts.
(root@127.0.0.1) Password for root@taarch64:

I hope it helps to align it with your environment and use case.
 
igoro said:
Yeah, ssh may be quite stubborn in cases when we want to move the slider towards convenience and away from security.

My personal working use case and local environment is based on the following:
  • I use key based authentication
  • my ssh client is OpenSSH_9.4p1, LibreSSL 3.3.6
If I already have some outdated host identification recorded within ~/.ssh/known_hosts then I get the following reasoning from the ssh:

It explicitly says that password-based auth is off: "Password authentication is disabled to avoid man-in-the-middle attacks.".

But if I clean my ~/.ssh/known_hosts from such old records or remove the file completely, then StrictHostKeyChecking no option works with password-based authentication:
Code: 
> ssh taarch64
Warning: Permanently added '[127.0.0.1]:2202' (ED25519) to the list of known hosts.
(root@127.0.0.1) Password for root@taarch64:

I hope it helps to align it with your environment and use case.
Click to expand...

The point is that an entry is made in known hosts, so it will be checked in future for this host. I was hoping that there was a way of ignoring known_hosts altogether... Maybe it isn't possible...
 
I have the same issue, for example, a multiboot laptop, so I made an alias.
Code: 
alias sshopt='ssh -oUserKnownHostsFile=/dev/null'
So, if I'm ssh-ing to said laptop for something I just do sshopt 192.168.1.whatever. The downside is that I do get the message that it's not known, do I want to connect anyway, but it's more convenient than having to worry about the IP being in my UserKnownHostsFile.
 
Just a reminder: you really shouldn’t need to do this if you are connecting to what should be a stable host. (Like GitHub, for example, although they had to roll keys last year, if I recall.)

If you want to do it on your home LAN for reasons, place it under a match block that matches your local IP range. That way it doesn’t disable this MITM prevention when connecting to outside resources.
 
On multi-boot machines on plain DHCP such as laptops with local boot drives I copy the same ssh server key to all the OS installations. Well worth the effort.

Most of my lab is booted via PXE, so I get a different IP address per OS anyway and there is no problem, each OS has its own host key.

What other cases are there where host keys change?

Ideally the host keys on your own LAN should never be unknown in the first place. When you make a new install distribute the key you used on the ssh server to a global known_hosts file.
 
I have noticed that in the past a single IP would get a single key saved.
Now its all three schemes..

192.168.1.190 ecdsa-sha2-nistp256
192.168.1.192 ecdsa-sha2-nistp256
192.168.1.169 ecdsa-sha2-nistp256

192.168.1.115 ssh-ed25519
192.168.1.115 ssh-rsa
192.168.1.115 ecdsa-sha2-nistp256

I also have a lingering file named known_host.old that reinvents itself after deleting.
 
cracauer@ said:
cracauer@ said:
If you keep swapping disks in a system or booting alternative OSes, it's a pain when you suddenly can't ssh into a system you used a few minutes ago. Initially, I though I was simply misunderstanding some of the parameters, but it looks as though it isn't as simple as I thought. I'll just keep deleting known_hosts as I have done up until now.
Click to expand...
Click to expand...
This reply to cracauer@ has not been formatted properly for some reason...
 
In any case, this in my ~/.ssh/config works for me:
Code: 
host i-* mi-*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
 
Jose said:
Your ops team insisting that spot instances are the future? At least the root cause analysis is easy to write now, having done it so many times.
Click to expand...

An Ops team doing this without managing host keys invites MITM attacks. It is very unprofessional. It is like cutting out one half of ssh's protections.
 
Hey everyone)
I'm having this strange problem right now, out of the blue. Refuse to connect to a certain host. Even having done all the above, the refusal message now simply says:
Host key verification failed.

What can be the problem? Even removing .ssh/known_hosts doesn't help anything. Never had that problem before.
 
free-and-bsd said:
Hey everyone)
I'm having this strange problem right now, out of the blue. Refuse to connect to a certain host. Even having done all the above, the refusal message now simply says:
Host key verification failed.

What can be the problem? Even removing .ssh/known_hosts doesn't help anything. Never had that problem before.
Click to expand...
Before I added these things, the refusal looked like this (note it doesn't even mention ~/.ssh/known_hosts file):
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:4G1Bhosym3cEYMe3dqInNXwbRXAY/Q0gMZtLlvu6Z5Y.
Please contact your system administrator.
Add correct host key in no to get rid of this message.
Offending ED25519 key in no:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Click to expand...
 
All right, don't know what it was, but I got rid of it by purging /etc/ssh and repopulating it anew. Still wondering, WHERE did it get the wrong remote host keys after I deleted ~/.ssh/known_hosts??...
 
You must log in or register to reply here.
Back
Top