Lets face it: passwords are a usability nightmare, decent passwords are hard to remember and often hard to enter. Most system administrators hate passwords, and in Unix systems administration they’ve mostly been replaced by ssh keys, as those provide better usability and security. Unfortunately ssh keys don’t work in non-networked scenarios, so on consoles we’re still stuck with passwords.
Passwords exist as a trade-off between usability and security. They are only secure when combined with strong policies. Not reusing passwords, and not writing passwords down are very common policies, although that’s not really feasible when you’re managing hundreds of servers. When managing thousands of servers, it is common practice just to not have known passwords. When we need to access a server, we use ssh. Except when the server has network issues.
When some server cannot be managed over the network, the we just reboot it with init=/bin/bash as a boot parameter. To do that for hardware, physical access is required, for cloud instances cloud administrator access is required. These two types of access are extremely security sensitive anyway, so we go to great lengths to secure those. Basically we’re using access to the console as a security mechanism.
When you’re not confident that console access is adequately prevented for non-authorized entities, go fix that. When you recognize that console access is your actual security mechanism, the password may become redundant. You could retain it as an additional layer of security, but you could also disable it.
Once you’ve evaluated the security and usability trade-offs, you may decide to disable passwords for the console: Just add -a root to your getty invocation. For Ubuntu that’s in /etc/init/tty1.conf, for Debian it’s in /etc/inittab, for CentOS it’s in /etc/init/tty.conf, for FreeBSD it’s in /etc/ttys. Restart the appropriate services or just reboot the machine.
Comments