Using OpenSSH Certificate Authentication
neocri.me
neocri.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
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".
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. :-)
rsync --rsync-path='sudo rsync' ...
ssh remote sudo passwd -l root (note diffs between rhel and deb/ubu)
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.
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.
asap, passwd -l root; sed -i "s/PermitRootLogin *yes/PermitRootLogin no/" /etc/ssh/sshd_config
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.
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.
In either case, unless you use different passwords for every machine, ssh-agent is already a net gain.
http://askubuntu.com/questions/159007/how-do-i-run-specific-...
1. It slows down your initial connection while it does another connection to check the key
2. You must convince everyone to use it, which is hard since gpg is hard.
I'd love to see more discussion of Monkeysphere on here. Every time I post something about it it gets no votes.
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.