I think we are all guilty of this far more often then we like to admit. On this particular one, I use root logins far too often rather than observing best practise.
Ya know, people go on and on about disabling root logins. Have you ever had to write a piece of automation to login to a host as a non-root user, interact with a user interface, drop to a normal user shell, then run a sudo scp command, and then pass back non-interactive raw non-TTY access to an scp control program?
It's hard. I know because I wrote a really crappy script that does it. You know what's so much easier and more stable? Running scp as root. Sadly, sometimes the best engineering choice is not a good one.
I'll point out that Ansible can do this just fine. Assuming you've got a non-root user set up in your node list file...
ansible [server] --sudo -m copy -a "src=filename dest=filename"
Other parts of Ansible might not be great (specifically, fully automated datacenter orchestration isn't possible without writing your own tools on top of Ansible; I use Salt for that), but it's really good for ad-hoc management without having to put additional infrastructure or daemons in place.
Sounds like you have other problems besides just needing root access. It's always possible to come up with an edge case, but that doesn't invalidate the rule. Avoid direct root login at all costs.
> It's always possible to come up with an edge case, but that doesn't invalidate the rule
That is why we have risk registers in professional contexts. Whenever following policy (or the less specifically defined "accepted best practise") is impractical or inconvenient a note is made in the project's risk register with who made the decision, why, and who signed off on accepting the risk of not following policy in this case.
Doing it this way forces people to ask themselves "is it really that impractical/inconvenient?", "have I properly considered the possible implications and calculated the risk (waving a hand and saying it'll all be fine because you've done it before does not constitute calculating the risk!)", and "have we applied as much mitigation to the risk as possible (enforcing secure password policy and so forth)". After considering those things then by all means allow password based remote logins for root and put your name against the choice in the register (or try get someone else to if you do not have sufficient authority).
I think there are lots of perfectly valid reasons to use root logins over SSH.
Sure, you absolutely shouldn't be doing development work or suchlike as root. But if you need to run administrative scripts on a bunch of servers, SSH as root is usually the easiest way to do that. I certainly trust sshd and RSA/ECDSA a lot more than some supposedly-secure setuid executable that lets me run commands as root.
Plus (as you probably know) you can specify in public key files that only certain IP addresses can log in using that keypair.
I've read that the general "don't log in as root" mentality is really an artifact of the telnet days when you didn't want people to sniff your passwords easily... not sure how true that is.
not only that, but it's a violation of pci/fips/hippa/sox etc to share administrative accounts, so if you're a team of one that's one thing, but don't share root with anyone else.
Just by the way, in the period of English with the -eth ending (Early Modern English), the correct grammar would be (wait for it) "Do what I say, not what I do".
I think we are all guilty of this far more often then we like to admit. On this particular one, I use root logins far too often rather than observing best practise.