Doeth what I say, not'th 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.
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.
PermitRootLogin no
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.
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.
also can use secure tmp files or rsync:
rsync --rsync-cmd='sudo rsync' -rpave ssh \ /some/dir/ \ me@remote:/some/dir/
(or, pulling backups for best security)
vault$ rsync --rsync-cmd='sudo rsync' -rpave ssh \ backup_user@dbserver:/var/ /backups/var/
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).
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.
So disable password logins. Even outside of root, that's a much more secure practice anyway.
PermitRootLogin no
AllowGroups dial-in #or something similar
[edit: and, of course:
PasswordAuthentication no
]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".