It's great to see someone who reads something in depth! Thanks for taking the time and commenting. :-)
My point with with the comment "Logging in directly as root user is a bad idea — even in examples" was that you should have enough pre-requsite knowledge to understand why that is bad, and that you should not follow my examples 100%.
That and I was poking fun at myself for being sloppy. :-)
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".
There are always priviledge escalation bugs open on Linux, and the attacker can always just try to guess the password, with several different sessions running su. I don't trust my systems to survive local atacks, or at least I trust them much, much less then surviving external attacks.
Personaly, I have my machines on a hierarchy of trust. More trusted machines can ssh as root into less trusted one, but not the other way around. It's much easier to automatize things this way.
There is literally never a reason for one machine to log into another as root except for your convenience. Put stuff that needs to run as root into a shell script (or use rsync --rsync-cmd) and then use sudo.
You know what? Sometimes, it's fine. You should not share a root account with other users. This advice comes from a time where you'd have the "root password" and log into remote servers that way. Then, when someone leaves your organization, you'd hopefully change the root password to make sure they person that left no longer has access.
However, there are some concrete cases where logging in as root is just fine:
- Making a database backup remotely. You have to give the backup user enough privileges to initiate a database dump, stop the database process, grab the backup, rotate the backups, start the database process up again. You can go through the giant pain of setting up the permissions just so, or you can put a separate SSH public key into /root/.ssh/authorized_keys and just let root do all of this.
- Initial VM setup. If you are automating something like provisioning EC2 instances, sure go ahead and set up individual users, but it's a lot easier to first connect as root using your own keypair.
- A remote monitor that logs into a single purpose VM to restart a process. Same as the backups example, but more broad. Once again, you could set it up using specific users, but the system would be more brittle.
- Lots of other cases where root is really what you want and doing sudo won't work because the session is not interactive.
I figure it this way: if I compromised a local account on a server, I'd just add `alias sudo=~/.bin/my-evil-sudo-that-emails-your-password` to your .bashrc. That way I'd get root without any local exploits in the kernel, etc. Basically, adding extra protection around the root account does nothing if you are a sudoer.
Some steps you can take to actually increase your security instead of following the advice that is so misunderstood:
- Set the root password to a long random string, then lose the string. `su` should never be used by anyone but root.
- Disable password logins. Period. Do this now, and do it everywhere.
- Disable password-based sudo. Use pam_ssh_agent_auth [1] to escalate privileges and ssh-agent to forward your key through your ssh session. I am not sure why this isn't the default, but it really ought to be.
- Make sure your local key is encrypted with a strong passphrase. Once again, use ssh-agent to not have to enter the password every single time.
- Set up a VPN to access your servers and only allow ssh from the VPN.
- For the truly paranoid, set up two-factor auth over SSH. This is easy to do with Google Authenticator (it's just a random number with the seed being shared and secret and the number being generated every 30 seconds), or using SMS which is just slightly more complex/costly.
With regards to initial VM's, I agree sometimes -- sometimes you just gotta get it done. But the others (db backup, remote monitor, etc) should use separate acct plus sudo. use userify or cloudadmins or something home-grown to manage those system accts, don't one-off and don't leave root on a net-connected machine for more than a few minutes. (also goes for all other generic accounts like ec2-user, ubuntu, etc).
asap, passwd -l root; sed -i "s/PermitRootLogin *yes/PermitRootLogin no/" /etc/ssh/sshd_config
I think the advantage of using a separate but privileged account is not as great as you think. If an attacker compromises that privileged account, chances are they will own root anyways. Why bother with the complexity then?
If knowing an account exists is like getting to the moon, logging into it if it requires a private key is like getting to Andromeda.
I mean, I tend to turn root access off, but let's not oversell what kind of security it gets you. There is effectively zero security difference between a non-root account + passwordless sudo and a root account if they both require a key to log in.
I think jamiesonbecker was implying that this new user would have sudo restricted to just doing the tasks required for its individual purpose, not completely open sudo. I disagree with their point, but yeah, that would have nothing to do with guessing the account name.
no idea how to get notifications for responses to my comments, sorry.
No, I am mostly implying that the name alone is a risk. If you've ever brought up a box on the net, you know that the first account that's attacked is root. While the above moon/andromeda analogy is apt, some types of vulns could also leave you open as well with a known username to login with. Better to block those outright.
Plus, there's no reason to log in as root anyway as a simple matter of best practices; it's against virtually every security standard; no auditing of privileged access and hopefully no root account sharing!
heavy opinion: logging into a remote machine as root on modern Linux/UNIX is just laziness.
I agree with you, but I do want to mention that it's possible and relatively easy to configure sudo not to ask for a password for specific commands for a specific user.
You can also setup the authorized_keys file to only run specific commands as root with a given certificate. This is usually easier for automated tasks. Especially if the key is also restricted by remote IP address b
I agree with everything except using ssh-agent to forward the key. The reason is that if that one server is compromised, the root user can forward your credentials to any other server that you have access to and if it is set up the same way, also get root there. If you use password for sudo authentication on that machine, they have your password but still don't have your credentials to get into the other server. Reference: http://unixwiz.net/techtips/ssh-agent-forwarding.html
Unfortunately it doesn't list the machine that requested it. It's only possible to tell what local process connected to the agent and login as what username will be authenticated (the packet that the agent signs contains essentially the username and hash of session secrets; notably absent is the target hostname and target's public key fingerprint).
You can specify '-c' to require interactive confirmation from the agent before signing the key, but not all ssh agents (gnome's keyring, for a prominent example) support this, and will silently ignore it.
Finally set this up on my Mac. Found the scripts at https://github.com/TimZehta/mac-ssh-confirm and modified them to my needs. Works pretty well so far, and I believe this should make things a bit more secure.
This reminded me I wanted to investigate switching to this for our infrastructure, but uh... it seems that on at least ubuntu's build of openssh if you pass a serial number to ssh-keygen it segfaults. Even if it's the default (0). That's kind of terrible.
about time. this has been needed for a long time. ssh mitm attacks were too easy, and legitimately changing server keys (which happens more often than you would expect) would just confuse the issue.
so - about time.
tatu's decision to NOT use this feature of public key crypto when he designed ssh keys has always been a point of frustration for me.
> Logging in directly as root user is a bad idea — even in examples
further down..
> ~/ssh_cert_authority/user_ca $ scp -rp user_ca.pub root@example.host.net:/etc/ssh