So this is about Centos7, SSH remote login setup, and the fact that Macs don't have a root user.
I've asked this question a couple times and been provided explanations about how ssh works. Some of that was interesting.
The goal is passwordless ssh login for the root user on a centos7 machine.
I can perform the normal setup for my non-root user as follows:
- remove my ~/.ssh folder.
- ssh-keygen (accept the default to create ~/.ssh/id_rsa private/public keys).
- ssh-copy-id myuser@server (to put the public key in the authorized_keys file on the remote machine).
- modify sshd_config to Permit Root login (yes) and PublicKeyAuthentication (yes) and PasswordAuthorization (no).
- Restart sshd and check status on sshd.
- ssh myuser@server without password (using key) successfully
Then I try to do the same with the root user:
- ssh-keygen -f root-key (places new private and public keys in ~/.ssh/root-key and root-key.pub. -- in the myuser ssh folder.)
- ssh-copy-id -i ~/.ssh/root-key root@server (this succeeds and I can find the public key in the remote server's root ~/.ssh/authorized_keys file.)
- Because I have already changed PasswordAuthentication to no and PublicKeyAuthentication to yes, this works without password: ssh -i ~/.ssh/root-key root@server
- However, this, which should work, does not: ssh root@server it yields a 'permission error (PublicKey).
Having gone around the mulberry for several weeks with this, I know that no alteration to the sshd_config has any influence (I've tried all permutations).
What seems to be true is that copying the key to the root@server's ~/.ssh folder authorized_keys file is not sufficient to enable normal passwordless authentication.
The SSH process as depicted here: process description and graph indicates that the problem as occurring during the 'Authenticate user to Server phase' when the client should send the "root's" public key to the server to be compared with the contents of the server root's authorized_keys file.
The fact seems to be that the CLI syntax that works includes the '-i ~/.ssh/root-key' phrase that explicitly forwards the specific public key that the ssh-copy-id step copied to the server root's authorized_keys file.
But 'normal' ssh says that 'ssh root@server' is all that is sufficient to initiate that key transfer and comparison process.
Now... in my previous questions, many responders wanted to emphasize that SSH "doesn't care" if the remote user name is different from the local user name, and all operations proceed 'as normal' regardless of the user name, account, and so forth.
However, as I tried to point out in those questions, there's something about the fact that the root's public key is located in a folder that is not named 'root' so that the username field of the keys do not match, some similar 'dumb stuff' that is getting in the way.
My best guess is that the code of SSH, at least on a MAC (although I've been having this same problem on Centos7 vm's as well) defaults to the preferred id_rsa.pub key as the one to send to the remote server to match with the ssh-copy-id'd root-key.pub that exists in the remote server's authorized_keys file.
So... the fact that SSH will allow a connection from a local user named 'me' to connect to a remote user named 'you' actually has no bearing on the problem, or a possible solution.
Now the obstacle is that I'm trying to set up a TripleO controller to deploy as an UnderCloud for OpenStack. And the Ansible scripts are quite particular about the permissions the that the remote 'root' and 'stack' users have during the running of the Ansible roles. And they don't want to have to deal with any extra parameter's like '-i ~/.ssh/root-key' on the scripted command lines.
So this is really holding up my progress. Therefore any experienced help is welcome!