What are the precise relationships between the keys in a Multi-user SSH Installation?

Question

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: user@machine.domain.extension.

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?

Answer 1

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].

The principle that SSH key-based authentication is: if the client can cryptographically prove it holds a private key that corresponds to a public key in ~/.ssh/authorized_keys file of the requested username on the server, access is allowed. That's it. The "name and machine of the [user]" are actually a free-form text field, that allows humans to easily identify a particular public key. The contents of that field are not used in authentication in any way.

By default, the SSH server does not care about what username the incoming connection claims to be at the client side, because:

• the client might not wish to disclose that to the server
• the server has no way to verify the client-side username in any way
• even if it had, a malicious client with a stolen key can be configured with whatever client-side username is advantageous to the client.

If you want to restrict the use of SSH key authentication, you can do it by prefixing the SSH key in the authorized_keys file with from="<hostname-or-IP-address-pattern>". As the sshd man page says:

The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key).

---

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.

That would be true only if the source machine is always guaranteed to be under the same administrative control as the target machine. SSH does not assume this, and recognizes that it is futile to base anything on who the user of the source machine claims to be unless there is some way to verify that claim.

---

If you meant that the user@vm1 ran ssh-copy-id root@vm1 and successfully entered the root password, then you may have been surprised by what ssh-copy-id did in this case. If there was no SSH private key in user@vm1:.ssh/id_* and the sshd of vm1 allowed SSH agent forwarding, then ssh-copy-id used the agent connection to get the public key from the Mac client host. And that's how a public key tagged with the name and machine of the [user] ends up in the root@vm1:.ssh/authorized_keys file.

Modern macOS has an extended ssh-agent that integrates with the macOS keyring, and is available on each macOS user's session by default. If you expect plain old OpenSSH behavior, this may also be a surprise.