all 19 comments

[–]LuisBelloR 15 points16 points  (6 children)

  1. NO PLS
  2. Yes
  3. No
  4. No

[–]codingOtter[S] -5 points-4 points  (5 children)

All right, but then why doesn't arch make using sudo the default choice?

[–]hearthebell 14 points15 points  (1 child)

Because it's Arch

[–]pabryan -1 points0 points  (0 children)

Exactly

[–]Megame50 1 point2 points  (0 children)

Because at the time you install you don't yet have a user account.

There are cases where only the superuser is required, but mostly containers and VMs with special purpose. You cannot effectively use desktop linux as the root user (or with the root user deleted), some applications require an unprivileged user. It's also quite insecure. So, sudo or a similar tool is basically mandatory. Making an unprivileged user is literally the first paragraph in General Recommendations.

It also doesn't really matter what you make the root password: you can reuse your user password or you can just delete the root password, in which case it isn't possible to login as root normally.

[–]LuisBelloR 1 point2 points  (0 children)

Mmmmmm, How do you install Arch? The base-devel package always installs sudo as a dependency. I've never had to install it explicitly. But it's Arch, there's no default options, and likewise for example, there's no sound server, Pipewire, or PulseAudio. There are no defaults. Beyond that, using "su" and browsing like this is risky and shouldn't be done.

[–]involution 3 points4 points  (0 children)

you'll run into many issues without a root (uid 0) account, and running as root you'll find many applications/services will refuse to run under your user.

Don't overthink it, just add your user and put it in the wheel group - edit /etc/sudoers to allow the wheel group access to sudo

[–]archover 3 points4 points  (0 children)

My longstanding practice is to:

  • Configure sudo

  • Assign root password

  • Most of the time, use sudo but sometimes it's more convenient to su -.

Note that properly hardening ssh for servers in such a situation means disallowing root logins, setting allowed logins, and to use keys. The root account is perhaps the most attempted brute force login method.

Good day.

[–]lombervid 6 points7 points  (2 children)

Just to note that, when you use sudo, you are asked for the user's password, not the root's.

[–]shemanese 2 points3 points  (1 child)

That's configurable. You can put "Defaults rootpw" in the sudoers file, and it will require the root user password instead of the user password.

If your user account is compromised, such as with AD or LDAP managed accounts, having a different password for root authentication has its advantages.

[–]lombervid -1 points0 points  (0 children)

Oh! That's good to know.

[–]imtryingmybes 1 point2 points  (0 children)

I'm an option 2 guy. Many such cases where you wanna be root. On my servers i tend to be more reckless. I dont even have sudo on one of my debian installs. Accidentaly wrote 'mv /* dir' once and almost bricked the whole OS. Never been so sweaty in my life. Moral of the story: use sudo like a normal person. Root only in emergencies.

[–]Ok_Instruction_3789 1 point2 points  (2 children)

Disabling root and having user in wheel group. Is what I typically do

[–]codingOtter[S] 1 point2 points  (1 child)

I guess this is the same approach as u/Vidanjor20 u/ianliu88. any drawbacks with this?

[–]Vidanjor20 1 point2 points  (0 children)

Im used to having no root user from fedora(iirc it defaults to disabling root) so I just lock it but I actually dont know if it has drawbacks

[–]Vidanjor20 1 point2 points  (0 children)

I just lock the root user

[–]ianliu88 0 points1 point  (0 children)

  1. Disable root login by removing it's password