When and how is generated the /etc/ssh/ssh_known_hosts file?

I read the following tutorial

• How to use ssh-keyscan on Ubuntu

I confirmed that ssh-keyscan 192.168.1.X scan and prints all the public keys values of the server/host - that output comes from the following files from the server/host

/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub

I can filter them through the -t option such as:

• ssh-keyscan -t key_type 192.168.1.X

Where key_type can be rsa, ecdsa and ed25519 and even mixed such as: rsa,ecdsa

For example:

• ssh-keyscan -t rsa 192.168.1.X

Until here I understand all these 2 variations of the command. I confirmed that behavior in my PC

Now, the reason of this post, after to do a research of this command - according with:

• ssh-keyscan(1) - from man.openbsd.org
• ssh-keyscan(1) - from linux.die.net

Both do mention of the /etc/ssh/ssh_known_hosts file, exists the

If an ssh_known_hosts file is constructed using ssh-keyscan without verifying the keys, users will be vulnerable to man in the middle attacks. On the other hand, if the security model allows such a risk, ssh-keyscan can help in the detection of tampered keyfiles or man in the middle attacks which have begun after the ssh_known_hosts file was created

is not clear if the ssh_known_hosts is created/constructed automatically or using some option, such as -c for example - I know that option does not exist.

Well that file does not exist in the client - I assumed that after of the command executions that file should be generated or created automatically - that path and file name exists for some explicit reason, right? - something similar how the .ssh/known_hosts file is created/updated when the ssh username@hostname command is used and is accepted the server's fingerprint by the client

The file /etc/ssh/ssh_known_hosts normally does not exist in a typical installation. It exists specifically to provide a way to provide an equivalent to ~/.ssh/known_hosts that works for all users for a system. It isn't updated automatically because (a) most users will not have privileges to modify it and (b) just because one random user approves a key does not mean that that decision should apply to the entire system.

For example, at my work, this file is generated automatically such that every internal host's SSH key is provided so that users can log into hosts as needed without being prompted for keys. This is done by a trusted automated process that gathers the data when each server is provisioned.

The warning is essentially just telling you that all ssh-keyscan does is tell you what keys you get when you scan that server, not whether those keys are the correct, trusted keys for that server. For example, if you have a machine on your network that intercepts all connections to port 22, doing an ssh-keyscan github.com will give you the keys for the intercepting machine, not the real keys for GitHub. To know whether the keys are legitimate, you need some sort of out-of-band information, which could be a human-to-human communication, an email, a web page, or an SSHFP record validated with DNSSEC.