New Edits:

So I went back and did some significant testing and revised my opinions about my problem a little.

First, here's a link to a thorough and quickly graspable diagram of the SSH Handshake (to get on the same page): SSH Keys Explained.

So I cleaned out the .ssh folders for the user and the root on each of the two Centos7 machine's I'm using - the controller is a VM and the server is metal.

Here are the SSHD_Config values of interest:

#Port22, Protocol 2, PermitRootLogin yes, #StrictModes yes, 
PubKeyAuthentication yes, AuthorizedKeysFile .ssh/authorized_keys,
AllowUsers root me_meaning_me, PasswordAuthentication yes (only to allow ssh-copy-id operations to start), #PasswordAuthentication no, 
#ChallengeResponseAuthentication yes, ChallengeResponseAuthentication no,
ClientAliveTime 120, ClientAliveCountMax 720 for tripleo openstack timeout
UsePAM yes, GSSAPI yes

Begin: no files or folders in any ~/.ssh/ locations, me-user, root-user, local or server.

  1. ssh me@server - password accepted - final state: new server fingerprint in new local known_hosts.
  2. ssh-keygen me@server - no visible result - final state; id_rsa private, id_rsa.pub files in local ~/ssh/.
  3. ssh-copy-id me@server - no visible result - final state: rsa-shaw in server me's ~/.ssh/authorized_keys file named with me@server.
  4. me@server can SSH into server but must provide the server-side password.
  5. ssh-keygen -f root-key root@server - no visible result - final state: root-key rsa private key and root-key.pub public key in local me's ~/.ssh/.
  6. ssh-copy-id -i ~/.ssh/root-key.pub root@server - some response about the key and root@server must provide the server-side password.
  7. edit server-side /etc/ssh/sshd_config - change to #PasswordAuthentication yes and PasswordAuthentication no.
  8. ssh me@server succeeds and no password is requested.
  9. ssh root@server fails with PublicKey, GSSAPI error.
  10. Tried many variations of values in sshd_config - but revert them all.
  11. Used the k-v-m switch to log into server and inspected root's ~/.ssh/authorized_keys file - the single key in the file is identical to the key generated for me@server.
  12. The ssh-keygen -f root-key root@sever produced an identical key and added the me@server identity.
  13. The ssh-copy-id -i root-key.pub root@server moved the key identical to me@server's key to the root's ~/.ssh/authorized_keys file.

Now, my original name for this issue was based on having gone through those steps several times over some hours, always with the same results.

So now what do we think?

  • "the procedures fail when i try to copy a self-generated id_rsa.pub file..." Please edit your question to show exactly what command(s) you are running and exactly what happens, including any error messages. You don't need to be root on the mac to ssh into a remote host as root.
    – Kenster
    Jun 15, 2019 at 22:14
  • There is no relation between a user on one machine and another, except that ssh fills in the user name in userName@machineName, if one is not specified, using the current user-name. Jun 15, 2019 at 22:38
  • @kenster: thanks for noticing that I left out some details and left over some others - detailing now. Jun 17, 2019 at 3:24
  • @ctrl-alt-delor: I appreciate your point-- that there's no 'necessary' relationship between two users on one (or two) control (source) machines who want to SSH into a server(target) machine. However my edits may prove that there can be some unexpected relationships created by the normal SSH command process. Jun 17, 2019 at 3:28
  • 1
    Testing on macOS 10.14.5 and on Debian 9, your stated command at step 5) produces a "too many arguments" error and an usage listing from ssh-keygen, and no new keys generated.
    – telcoM
    Jun 17, 2019 at 6:13

1 Answer 1


If I have read your question correctly you seem to be stuck on the fact your mac does not have matching usernames (including root) with your server.

You really don't need to use a matching username on the client when logging into or setting up access to a server. If you don't specify a username then the ssh client will assume your current username, but you can always specify a different username if you want to using the form: user@remote_host

You mentioned that you are using the ssh-copy-id command. On the command line you get get a user manual page for this by typing man ssh-copy-id. For reference it should show you this: https://linux.die.net/man/1/ssh-copy-id


ssh-copy-id [-i [identity_file]] [user@]machine

That is from your regular user on the mac you can call:

ssh-copy-id root@remote-server

Or you can specify which public key to install. eg:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote-host
  • @PhillipCouling: I appreciate your patient willingness to address the technicalities. I've updated my question to reflect the verification of the actual behavior of the SSH commands you pointed out. Jun 17, 2019 at 3:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .