5 ms·

well that's what PermitRootLogin no is for

by eik3_de 13y ago

peterwwillis 13y ago
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.
- vertex-four 13y ago
  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.
  - jamiesonbecker 13y ago
    cool - thx for this. 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/
- skywhopper 13y ago
  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.
  - peterwwillis 13y ago
    s/problems/requirements/. And I wasn't trying to invalidate a rule, but merely point out that rules are made to be broken ;)
  - dspillett 13y ago
    > 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).
- ctz 13y ago
  This is what userv is for.
  - jamiesonbecker 13y ago
    +1 for userv
- deleted 13y ago
  [deleted]
- jcalvinowens 13y ago
  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.
  - jamiesonbecker 13y ago
    root is prime target for brute force. 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.
    - jcalvinowens 13y ago
      > root is prime target for brute force. So disable password logins. Even outside of root, that's a much more secure practice anyway.
      - jamiesonbecker 13y ago
        always disable password logins -- but that has nothing to do with disabling root login as well.
e12e 13y ago
I generally have both: PermitRootLogin no AllowGroups dial-in #or something similar The one time I need to grant someone login, I'll probably scratch my head why they can't log in, then remember to add them to the right group... [edit: and, of course: PasswordAuthentication no ]

well that's what PermitRootLogin no is for

by eik3_de 13y ago

well that's what PermitRootLogin no is for

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.

vertex-four 13y ago
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.
- jamiesonbecker 13y ago
  cool - thx for this. 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/
skywhopper 13y ago
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.
- peterwwillis 13y ago
  s/problems/requirements/. And I wasn't trying to invalidate a rule, but merely point out that rules are made to be broken ;)
- dspillett 13y ago
  > 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).
ctz 13y ago
This is what userv is for.
- jamiesonbecker 13y ago
  +1 for userv
deleted 13y ago
[deleted]
jcalvinowens 13y ago
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.
- jamiesonbecker 13y ago
  root is prime target for brute force. 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.
  - jcalvinowens 13y ago
    > root is prime target for brute force. So disable password logins. Even outside of root, that's a much more secure practice anyway.
    - jamiesonbecker 13y ago
      always disable password logins -- but that has nothing to do with disabling root login as well.

e12e 13y ago

I generally have both: PermitRootLogin no AllowGroups dial-in #or something similar The one time I need to grant someone login, I'll probably scratch my head why they can't log in, then remember to add them to the right group... [edit: and, of course: PasswordAuthentication no ]