> We don't even have a password for our root user. We'll want to select something random and complex.
So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful.
Simple solution: leave root password blank, don't forget your sudo password. If you can't get in, use grub or a liveCD. Or tie auth to ldap or kerberos so you _can't_ forget. This is one area where Windows has a distinct advantage: AD more or less requires admins to think at the level of network of servers, and provides a baseline set of services always present.
It depends on your VPS, but many give a root password by default.
I do make sure later in the article that `/etc/ssh/sshd_config` does not allow root login:
PermitRootLogin no
But you make a good point that a simple solution is just having no root password at all. If your VPS does have a root login by default, then I believe you can get rid of it with:
sudo usermod -p '!' root
The best part about sharing things like this is getting all sorts of great info and input on things.
So it looks like from the `passwd` man page that `-l` locks it, but doesn't actually remove it completely? I wonder if there are any disadvantages to this.
Locking means it changes the password to a value that nothing could ever hash to (by putting a ! in front of it, for example). Unlocking just removes the !.
The security disadvantage is that if someone gets your /etc/shadow file they can still see the password hash, in case they wanted to try to crack it, but honestly at that point your server is likely compromised anyway.
Not on (eg) BSD. I don't know if this is Linux-only, or more pervasive, but certainly not entirely standard. On Net, Free, Dragon Fly and OpenBSD "-l" mean "update only the local database", versus Kerberos.
Well, sure, but the usermod method I was remarking on isn't standard either, and it established a Linux context for this thread. I'm not sure there's a truly portable way to lock a password across SysV, Linux, and BSD systems.
The _effect_ of what you do (make an "impossible hash") is the way, as far as I know -- whether its vipw, passwd -l, whatever...
Regardless -- I'm not trying to diminish your solution, nor Linux; I elided over the usermod example in the grandparent (didn't recognize it at all), but interestingly, as I look on my NetBSD system,there is a usermod(8), with a -p for already hashed passwords. As I test it though, it rejects '!' as an argument:
The last company I was at was more like this and had admins who were really anti LDAP...because...I have no clue.
You should have centralized auth whenever possible. LDAP servers with fallback, Shibboleth for SSO on web apps (or to implement ADFS integration or SSO with Slack or whatever),
I'd also recommend these steps being combined with Vagrant + your configuration management tools (Ansible, Chef, Puppet).
There are Vagrant + Linode, Vagrant + KVM/libvrt, Vagrant + Digital Ocean, etc. If you combine the two, you can get pretty close between local virtualbox instances and production (you'll run into some issues with each providers base box being a little different, but you can usually accommodate for both your own box and your provider's)
This makes it a little easier to move your architecture from one provider to another.
This part struck me as odd, too, especially when you consider the justification: That if you lose access to your sudo account/password, you must have some other way to get into the system.
Backups should include everything required to rebuild every server in the company. No server should be 'too critical' to wipe and start again if required. So maybe I'm being too much of an armchair warrior here, but the reason I don't like this one is less about the actual security implications, and more because of what it says about the fragility of the overall setup.
>Backups should include everything required to rebuild every server in the company. No server should be 'too critical' to wipe and start again if required.
True. But compare the effort required for, say, solving an accidentally misconfigured /etc/sudoers on a database server. You could argue that would never happen with proper testing, but shit happens and and having a particularly long root password in Keepass is a small price to pay to save that sort of headache.
You still can't login to the system. Root login is disabled as well as password authentication. The root password is just in case you lose your sudo password but it doesn't provide you a way to login if you don't have your key, passphrase to your key, access to the static IP/VPN and device with 2FA.
So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful.
Simple solution: leave root password blank, don't forget your sudo password. If you can't get in, use grub or a liveCD. Or tie auth to ldap or kerberos so you _can't_ forget. This is one area where Windows has a distinct advantage: AD more or less requires admins to think at the level of network of servers, and provides a baseline set of services always present.