3 ms·

>rescue password which can be entered via IPMI or by physically attaching to the server. If it's an emergency you can reboot into a single user/recovery/rescue

>rescue password which can be entered via IPMI or by physically attaching to the server. If it's an emergency you can reboot into a single user/recovery/rescue state and reset it. No need to increase the attack surface just for that. >Also, `sudo` password (which is also handled by /etc/shadow) is a good measure on production servers and should be set somehow. I agree about a sudo password being a good idea, but if we're talking about the "right" way I'd say a authentication directory backend of some sort would be better suited for that.

seletskiy 11y ago
Often, the only way to know what's wrong with server/software is to login through IPMI and see it while it's still alive. Reboot will lost that information. Don't see exactly how enabling root password login at physical/IMPI console will increase attack surface (not SSH). Regarding authentication backend I've already tried to address that vision. Unable to become root when auth backend offline/unreachable/misconfigured is significantly worse than having local shadow which is always works.
- brazzledazzle 11y ago
  The chance of your central authentication system being down at the same time you have to troubleshoot an issue with a live system seems unlikely. And for those rare cases you can just enable the account in single user and troubleshoot after the reboot.