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 HostbasedAuthentication
in /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/hosts.equiv
or /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 IgnoreRhosts
to 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 ~/.rhosts
or ~/.shosts
. But this authentication method is disabled by default.
(Why two files like ~/.shosts
and ~/.rhosts
, you think? Well, it's because the .rhosts
file was used by the old non-encrypted rsh
/rlogin
/rexec
/rcp
tools, and SSH was originally designed as a drop-in replacement for it. You'd use .rhosts
or hosts.equiv
if you wanted to allow access via both rsh
and ssh
tools, and .shosts
or shosts.equiv
if you wanted to allow only SSH access.)