In working through an SSH Configuration for User and Root accounts for accessing a group of VM's and Hardware servers, I have encountered situations that do not make a great deal of sense to me from the perspective of Public/Private key relationships.
The recommended steps seem to be as follows:
ssh user@vm1 produces 'the authenticity of host 10.1.10.9 can't be established. are you sure you want to connect?'
Selecting 'yes' places the fingerprint of vm1's machine key in your ~/.ssh/known_hosts file.
ssh user@vm1 returns 'permission denied' (publickey, gssapi, ...)
ssh-keygen generates a local key pair for the logged in user ('user') in ~/.ssh/id_rsa and id_rsa.pub. both these are tagged with the user's machine identity: 'email@example.com'.
One version of the next step is: ssh-copy-id [-i ~/.ssh/id_rsa.pub] user@vm1 That typically fails because the PasswordAuthentication is set to 'no' and an out of band modification to /etc/ssh/sshd_config must be made. Then ssh-copy-id can copy 'user's public key to the ~/.ssh/_authorizedkeys file of vm1.
The result of a successful ssh-copy-id identifies the (local) source of the public file and the count of the keys added to the remote (1).
At that point the PasswordAuthentication can be set back to 'no'.
And now, the user's ~./ssh/authorized_keys file holds a single key tagged with user's name and machine id.
So now let's set up an ssh login for another user, say, root:
still logged as user, ssh-copy-id root@vm1 (skipping the password auth step...) succeeds, copying the [user]'s public key to the authorized_keys file in vm1's root ~/.ssh/ folder. The key is still tagged with the name and machine of the [user].
While this operation may seem obviously flawed, or maybe not... if you are on a MAC something like this is the only option, since MAC's have no root user ~/.ssh/ folder.
The consequence of this seems to me to be that any user on any other machine can create an ssh root login account to any machine for which they have the root password. And they can login as root on that machine based on their [user] account public key which becomes stored in the authorized_keys file of the target systems root ~/.ssh/ folder.
To me, this seems to weaken the root access protection on the target machine because the user's public key verifies the login privilege, but the target root's corresponding private key is not stored in a restricted root account ~/.ssh/ folder on the source machine.
Am I missing something?