You're conflating two different types of SSH keys there. Although they are similar in structure, they have a very different purpose.
Your public key is what could be called a user key: although it is public, i.e. there is no need to keep it secret, it is not published automatically by any means. If you want to put it on your web page, sure, you can do that. But you must do it on your own.
The per-machine keys, on the other hand, are called host keys. Those are exchanged automatically at login, so they can be considered published. But host keys don't go into an
authorized_keys file: they go into
known_hosts instead. Just having the host key from some machine won't give anyone any kind of access: it just lets your SSH client confirm that the machine is the same as before when you connect to it.
If the system administrator chooses to enable
/etc/ssh/sshd_config, and the host key of the remote host is in system-wide
/etc/ssh/ssh_known_hosts file, then it would be possible to add the name of the remote host to
/etc/ssh/shosts.equiv to allow everyone on that remote host to log onto corresponding accounts on the local host, without entering a password. If the system administrator also sets
no, then you as a regular user could similarly allow a specific user on a specific remote host to access your account on the local host without a password, by putting the host key of the remote host to your
~/.ssh/known_hosts and the username@hostname into your
~/.shosts. But this authentication method is disabled by default.
(Why two files like
~/.rhosts, you think? Well, it's because the
.rhosts file was used by the old non-encrypted
rcp tools, and SSH was originally designed as a drop-in replacement for it. You'd use
hosts.equiv if you wanted to allow access via both
ssh tools, and
shosts.equiv if you wanted to allow only SSH access.)