Ok, so I have the following happening on my RHEL/OL7 System:

pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"

Fine, I get it, SSHD is blocking ssh access to any account (specifically Root) not over UID 1000.

I also get it that it's a BAD idea to allow direct login to root from off box as it allows brute force password attempts, I'm all there with this.

Here's the simple conundrum I want to solve without breaking the security and "bad ideaness" of the above:

I have a file in /root that needs to get to /root on another box. How does that happen?

scp -r root@<box>:~/<dir>/* .

Fails miserably due to the login block so how exactly, in today's security world, am I expected to get files moved from one root home directory to another?

Do I have to setup/tear down a public / private key every time I want to copy a file?

I'm sure there's a simple solution that I'm just overlooking.

It is possible to turn on root ssh access for only specific hosts using pam, so that two servers could ssh into each other as root but no other machines could:
http://serverfault.com/questions/897...ne-ip-hostname

Alternatively, you could scp the file from root on machine 1 to your regular user account on machine 2, then change the ownership and move it to /root in a second step.

I was afraid this was the conversation we were going to get into.

I'm a sysadmin for a fortune 350, I maintain something along the lines of 500 servers at this point, of which about 150 of them are moved to OL7. At any point, any of these servers may need to move a root owned file from one box to another box.

Administration tasks and programs (like Ansible) seem to understand the SUDO methodology for administration...that's become the new norm, but not for file migration (there is no such thing as SCP SUDO).

Not that this is my specific use case, but lets talk about this theoretically for a few moments:

* Say I have a file with secure information in it that I need to keep secure. The file exists on a box with other users present.
* I need to move that file to another box, again, into another secured location.
* The current location the file resides is owned 700 by root. This is a secure location because the default permissions on the location are such that ONLY the root user has access to that location.
* The location I need to move the file to (again, a box with other users present) is also owned 700 by root.

SSH Handles the migration of the file "in transit" so that the information is not being passed in the clear.
However, I do not think, given the information in the original post, that there is a solution to this problem.

By removing access to log in as root, I am now REQUIRED to jump through hurdles by mocking up a non-root user on the box, setting locked permissions on a DIFFERENT location, copying the file to that new location, logging in to the new user from root on the second box and copying the file via SCP. I then need to tear down that infrastructure to not leave ANOTHER hole open on the system.

If that file needs to go to 500 boxes, what's my solution?

People MUCH smarter than me must have realized this is a rather large problem already...what easy method am I missing to solve this? There's got to be one.

I recently had the same error ssh'ing as root to a centos7 computer. Turned out I'd done some yum updates but never took care of the .rpmnew sshd_config file. I merged the active old /etc/sshd_config with the new sshd_config.rpmnew , restarted sshd and problem solved.

I already gave you a link showing how to allow root ssh only to/from specific machines. Does that not work for you?