3 Add PasswordAuthentication=no to reduce possible exposure; re-work the cautions into the text rather than as an afterthough
source | link

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). For If you want to blindly accept the new host key, you can do so, but be aware that this removes any defence against impersonation of the other side. It may be appropriate for low-risk actions on a well-controlled network, but is not recommended for use on the public Internet!

For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no

There doesn't seem to be an option for SSH to never check known_hostsknown_hosts.

To answer thisIf the problem in the question is that the host keys were never known to this client (as opposed to known but now changed), it's probablythen it should be sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

To reiterate, Note that this makes the SSH connection insecure against active attacks since it won't be able to detect impersonation attempts! Use this only inside a physically secure network. Do notonly do this if you don't understandaccept the risks.reduction in security. I'm assuming you do, as you say you want to unconditionally respond yes to interactive SSH.

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no

There doesn't seem to be an option for SSH to never check known_hosts.

To answer this question, it's probably sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

Note that this makes the SSH connection insecure against active attacks since it won't be able to detect impersonation attempts! Use this only inside a physically secure network. Do not do this if you don't understand the risks.

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). If you want to blindly accept the new host key, you can do so, but be aware that this removes any defence against impersonation of the other side. It may be appropriate for low-risk actions on a well-controlled network, but is not recommended for use on the public Internet!

For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no

There doesn't seem to be an option for SSH to never check known_hosts.

If the problem in the question is that the host keys were never known to this client (as opposed to known but now changed), then it should be sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

To reiterate, only do this if you accept the reduction in security. I'm assuming you do, as you say you want to unconditionally respond yes to interactive SSH.

2 an insecure solution may be acceptable sometimes, but an answer that doesn't warn about the insecurity is not
source | link

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no

There doesn't seem to be an option for SSH to never check known_hosts.

To answer this question, it's probably sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

Note that this makes the SSH connection insecure against active attacks since it won't be able to detect impersonation attempts! Use this only inside a physically secure network. Do not do this if you don't understand the risks.

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no

There doesn't seem to be an option for SSH to never check known_hosts.

To answer this question, it's probably sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no

There doesn't seem to be an option for SSH to never check known_hosts.

To answer this question, it's probably sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

Note that this makes the SSH connection insecure against active attacks since it won't be able to detect impersonation attempts! Use this only inside a physically secure network. Do not do this if you don't understand the risks.

1
source | link

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no

There doesn't seem to be an option for SSH to never check known_hosts.

To answer this question, it's probably sufficient to add -o StrictHostKeyChecking=no to the SSH command line.