On 2/20/25 22:17, jeremy ardley wrote:
On 21/2/25 09:40, Tom Dial wrote:
The TL;DR here is that for maintaining personal workstations and servers it makes more sense to log in as root, do the work as required, then log out. Or there is "sudo -i" to get an interactive root shell and avoid prepending every command with "sudo."
Logging in as root on a server is highly dangerous, especially if it has an
internet facing ssh port. The big cloud providers like AWS provision images
where there is no root login, and any access requires a client certificate for
a non root user.
I do not see how login as the root user is meaningfully more dangerous in the case of
personal workstations and servers than having a sudoers file that includes "%sudo
ALL=(ALL:ALL) ALL."
The logged in user can sudo. However on some systems like Ubuntu derived, root
user doesn't even have a password or a shell. So the first thing I do is
sudo passwd root
and work from there.
With an enabled root password?
However, certificate based access using e.g. ssh-copy-id is a time-bomb. Best
practice is a separate IAM mechanism with centralised access control. I
personally use LDAP to maintain ssh public keys backed up by an authenticator
on each host. I do not permit root accounts in the IAM.
This seems a bit heavy-duty for personally owned and operated equipment on,
e.g., residential premises.
For whatever it is worth, I use ssh with passworded login prohibited for all
network logins. Root login is restricted to a single account on each system and
one on a server that runs the backups. On some of the systems the root account
does not have a password, on on most it does; this depends on the installer
defaults and my inclination at installation time. It probably is better
practice to not have a root password, but having it makes it marginally easier
to handle a possible failure of the ssh server.
Regards,
Tom Dial
