From OP:

I have a ~/.ssh/known_hosts file which stores all my ssh keys for all aps.

Others have done a great job of going through the issues you had with your code, but I wanted to clear up something about that sentence. I believe you are misunderstanding the purpose and use of the known_hosts file.

The known_hosts file contains the public host key of known servers, and is used to protect against impersonation or man-in-the-middle attacks by allowing the user to verify that the server they are connecting to is the same one they connected to previously. When your SSH client connects, it will consult the system's /etc/ssh/ssh_known_hosts and the user's known_hosts file for that system's public host key. If one is present it will be compared and either allowing the connection or failing depending on if it is verified or not. If a public host key is not found, generally a fingerprint of the key will be displayed and there will be the option to add the key to the file.

The format of a known_hosts file differs from that of either a public or private key file. My experience with these files has been as follows:

• Private key files have a header and footer indicating the beginning and end of the encoded key.
• Public key files are one key per line each, consisting of a space-separated key type, key, and optionally a trailing comment (useful when searching for one key out of many).
• known_hosts files have one line per unique host/port combination which consists of a space-separated host (may have several names/IP addresses comma-separated, and may have the port appended if a non-standard port is used), the key type, followed by the key.

Out of curiosity I did try using a recent (9.x) OpenSSH client against a constructed known_hosts file consisting only of key file contents (public key, private key, or a mix of the two) and was prompted each time if the server's host key was not present in the known_hosts file. I also tried using the same constructed known_hosts files as the identity file (key file) for a connection and while it did report "invalid known_host entry" lines when done verbosely ("-v" option) it did connect successfully.

While the default private key file names (in the user's .ssh directory, normally $HOME/.ssh) are id_rsa, id_ecdsa, id_ecdsa_sk, id_ed25519, id_ed25519_sk, and id_dsa (and the associated public key file names are the name with ".pub" appended), key files can be given other names (using ssh-keygen's "-f $filename" option) and specified to the command-line client using the "-i $filename" option, the "-o IdentityFile=$filename" option, or specifying the "IdentityFile $filename" option in an appropriate .ssh/config entry.

I'm not aware of a particular issue you might encounter at this time, but it might be a good idea to put the files in expected locations -- from a documentation point, a "best practices" point, and especially if you expect someone else may help you with supporting the apps in the future.

Good luck.

2023-04-22 - Fixed typo.