4 ms·
> 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 passwo
by jldugger 10y ago
> 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.
- shujito 10y agoWhat if it is a VPS?
- throwanem 10y agoBoot from a rescue volume, or use the VPS provider's root password reset functionality.
- optimuspaul 10y agoterminate and launch a new one? You have automation to provision your servers right?
- gshulegaard 10y agoAgreed. Stopped reading when I got to that.
- codelitt 10y agoIt 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.
- mwpmaybe 10y agosudo passwd -l
- codelitt 10y agoSo 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.
- danudey 10y agoLocking 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.
- codelitt 10y agoGreat! Thanks for the answer.
- bch 10y agoNot 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.
- djsumdog 10y agoThe 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.
- gcb0 10y agowhat about protecting against the physical host of the machine?
- taneq 10y agoThis 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.
- corney91 10y ago>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.
- codelitt 10y agoYou 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.