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?
yes places the fingerprint of vm1's machine key in your
ssh user@vm1 returns
Permission denied (publickey, gssapi, ...)
ssh-keygen generates a local key pair for the logged in user ('user') in
id_rsa.pub. Both these are tagged with the user's machine identity:
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
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
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
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?