0

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?

Thanks,

  • 1
    "still logged as user, ssh-copy-id root@vm1 (skipping the password auth step...) succeeds" what? O.o – muru Jun 21 at 5:34
  • "MAC's have no root user ~/.ssh/ folder." Unless you enable the root user and use ssh on that account. Where would you expect root's ssh files to be stored other than ~root/.ssh ? – user4556274 Jun 21 at 12:29
  • "any user on any other machine can create an ssh root login account to any machine for which they have the root password". Yes, any user who already has root access can further configure that root access. How does it weaken root access protection to allow public-key as well as password authentication for a user connecting as root? (I disable all root access with PermitRootLogin no in sshd_config, but that's a separate consideration.) – user4556274 Jun 21 at 12:33
  • @user4556274 - yes, that is my point about SSH from a Mac. And I believe needing to create a root .ssh folder doesn't justify the need to create a native Mac root user. And I think that means the choice to create a root SSH access to a linux server must always be based on the public key of a 'normal' user on the mac. – Stato Machino Jun 21 at 19:58
  • @user4556274 - my specific point is shouldn't access to a root account on a remote server be available only to a privileged account on the local machine, not to 'anyone'? – Stato Machino Jun 21 at 20:08
3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.