One extremely underutilized feature in Linux is capabilities. For example, nmap usually requires root privileges for most of its scan probes. However, an admin can give the nmap binary the capabilities to access raw network sockets (CAP_NET_RAW, CAP_NET_ADMIN, and CAP_NET_BIND_SERVICE), which in turn allows unprivileged users to run nmap with their own account, no sudo required, yet still performing raw network operations.
I work in the opposite direction. I run Everything as root. No users. If I need a sandbox, Docker containers. Obviously no user besides root inside the container. Try it. You'll never look back again at the sudo nonsense. If you grew up with C64, Amiga, and DOS, this makes perfect sense.
@@henrikholst7490honestly, i kind of do the same. i just find myself having to run commands as root so frequently that i often log into a client and run "sudo -i". maybe i should also just ditch regular users for these servers.
sudo -i Runs an interactive sudo shell. similar to logging in as root. One of the major benefits of sudo is accountability. It logs all sudo activity in fine detail.
I'm a novice-intermediate user and honestly when I set up our local network and servers I was originally using Ubuntu for most of my systems, I swapped to Debian 11 and Debian 12 (depending on the system) after Snap packages broke and completely destroyed one of my server boxes. When setting them up for the first time I'd made the assumption having a root account would be a small vulnerability due to its static nature, kinda glad I was right.
I also recently switched my new installs from Ubuntu to Debian 12. And I made the mistake of setting a root password once. Ubuntu with their snap obsession yet still delivering a really old version of docker on snap have really pushed me away
Some cloud imstallers (VPS services) still set a root password and have root login over ssh enabled even on ubuntu or debian. It is wise to harden those: - create a normal user - disable root login over ssh And consider other steps like pubkey login only.
This remembers me of my high school, they had the root password as the regular user password and the user was in the sudoers file as well, detail, the password was printed in a paper taped on the desk
worth pointing out that with no root password set, you can still `sudo su` to log-in as root using your personal password instead of the root password. Helps in the cases where you need to run a lot of privileged commands in a row with a disabled root password (as covered in the video, doing this is less secure than running everything with sudo, but convenience is nice)
Came to comment section to say exactly this. THIS is the solution to the problem Brodie brought up. It works because sudo can allow a user to run `su` as root and su allows the root user to login to any account (including root itself) without a password.
Why is everyone on the internet suggesting "sudo su"? That runs "su" as root, so you switch to root using sudo, to then switch to root again using su. Just use "sudo -i" which gives you an interactive shell as root. Same effect, same amount of keystrokes, one less executable involved. Yes, "sudo su" just also works, but promoting that online screams "I give tips about sudo without knowing sudo".
I really enjoyed that video you did a while back on *all of the other limited-scope no-login accounts* that exist on a modern Linux system. Those never have passwords, and I think of *root* in the same vein.
As always brilliant, now to educate people install Slackware on an 386 or 486 system from maybe 1996 or a vm simulating such a system, if not for anything else but to show how easy Linux has become to install and use 😉
Having no root account actually caused me a few issues on fedora linux. I once incorrectly set up my fstab file, so at bootup it failed to mount. For some reason, fedora automatically sends you into emergency mode when anything goes wrong during bootup (including something going wrong while mounting drives). And guess what. It tries to log you into a root account...... which I had disabled because I didn't know any better. So now I'm completely locked out of my computer because of something so trivial as a failed drive mount. Had to create a usb live environment and fix the fstab file from there.
Some distros use Grub to provide a single-user mode for each kernel version in the menu alongside the regular login so you can still access from there to make the minimum of changes in that scenario, but yes it is always worth knowing the process with a live USB. It's also a reminder that not having a root password set has no bearing on leaving someone unattended with physical access except that you'd know they restarted.
@@UKprl The different menu entries that fedora has for different kernels all entered emergency mode so I was locked out of my computer anyway. Now that I have my root user setup this isnt an issue though. I can just login as root and just do that journalctl -xb command or whatever it was to figure out what went wrong.
IIRC there is an option to disable strict mode per volume and let systemd ignore failed mounts at boot for that volume. Strict mode is handy for stuff like databases where it could render the whole server useless/corrupted anyway if the mount has failed.
@@giusdbg Not sure what a recovery mode is but when something during boot fails fedora throws you into a CLI only environment and asks you to log into your root account. If you don't have it you are locked out of your system.
You don't need an active root account to keep a shell in root mode. A simple "sudo -s", "sudo bash" etc will do the work just fine. The only valid reason for disabling root login (which I always do), is because of what you said. It's the first thing that anyone will try because it exists on all systems. There are no other benefits or security reasons to do so.
Using sudo every time is still a good thing because it will hopefully cause you to stop and think about the command you’re about to run. Also, for piping, you can run “sudo su”, just enter the command normally, and exit afterwards.
I've noticed suse being a bit weird in that regard. Instead of locking the root-account if sets the same Password as the sudo user and sudo asks for the root Password (which technically is the users pw, but it specifically states root user)
ubuntu might not have a root password set but you can always sudo su. 4:20 Very good point. No matter how you go about it, never allow logging in as root directly in your sshd config. I mean of course ssh via username and password should be disabled in general once the keys are all set up but root login is always extra dangerous. Also on a server that has sshd enabled I'd set the timeout for sudo to something really low like 5 seconds or make the user enter the password every time to begin with.
First, it's "sudo -s", no need to name the "su" binary directly in this dirty way; second, and he mentioned it, this starts a root shell which, guess what, is able to be left unattended (yes, there is a chance, here in Greece we call it "earthquake").
One issue that involves sudo is environment context switching and environment variable and path sourcing when doing upstream "vanilla" development and installation management (e.g., TeXlive). Not only are there differences among distro families (e.g., Arch, Debian, Fedora) but also within them (Debian, MX). One must remember to use "sudo -i" in order to get a clean context switch and also determine if secure path sourcing is on or not (Debian family). Otherwise, doing upstream development on distro-independent projects by just using sudo can fail in certain instances due to keeping the normal user's context instead of the system's context, or losing access to the desired command path and not knowing why at first. In certain cases, having a root account with an assigned password might help, but using "sudo -i" and full paths from root to wherever the binary you want to run will also get the same result.
Yeah. One of the big learning curves for me in switching to Arch has been that build scripts for AUR packages use the tools in the *environment's paths.* Since I have a habit of having conda activated by default (advice on any other OS is *never* to use the system Python), I'd keep having builds fail (or install correctly but be unusuable) due to confusion about which dependencies existed on the system. At one point I went as far as adding: `alias yay=conda deactivate && yay` to my .bashrc
@@GSBarlev You should never use system _pip._ Using system python is fine, so long you don't need additional packages. Tho remember that all python-* packages in Arch are dependencies needed for regular Arch packages. They aren't really designed for Python development. Personally, I just create plain venvs for every Python project I start. And installing a Jupyter kernel inside of there isn't too hard either.
Yep. I have a root passwd set on my local systems but at work there are no local accounts ... sssd/ldap and all that. One thing I didn't hear you say about having a root shell open and walking away was that if you do then a quick super+l before hand helps quite a lot. :D
Its the basic premise of security. Dont leave your system logged in. And exiting a root shell is as simple as ctrl+d. Or lock your system with super+l.
there one more point, the log of system changes. If each user has its own profile, all the changes could be backtracked to the specific user that made the change.
So 4 days ago, I ran a giant wire shark scan, the morning after I was very tired and Mint had just forgotten WiFi existed. I started trying to troubleshoot but my first thought was that adding the user to the wire shark group had somehow impacted permissions to use certain files in /dev. In my very bleary state, I wanted to just remove all groups for my account, so i opened a terminal and typed sudo usermod -G richard richard, and pressed enter. About a second after entering my stupidly complex password correctly on the first go, my heart jumped straight to my mouth. Thinking oh yeah I’ll just restore from a time shift backup. Nope, that requires root. Sighted people can just launch a recovery menu and bring up a root prompt at boot. My blindness and the lack of a screen reader meant the next 90 minutes was spent pressing random buttons and photographing and ocr-ing my screen with an iPhone, trying to figure out the exact menu layout in recovery, terminal output and desperately trying to add my account back to the sudo group. Moral of the story, think before you press enter. Also screen readers in recovery mode need to be a thing.
I've been using Linux since 1997. My first distro was Red Hat, and I actually bought it in a store. The reason I got it was because my brother had it, and seemed to like it, and Windows pissed me off so much that I just took the leap into Linux. It had a functional root account. I don't believe that it shipped with sudo, but could be mistaken.
I'm realizing now that Brodie is an evil genius-getting all of us to comment with whether we use root or not. With TH-cam logging our IPs, that means that he now has the ability to bruteforce into a nonzero number of our systems. 🤣
I was surprised to hear him mention the wheel group as I am familiar with its function on FreeBSD-based stuff but not all distros use this group; I'll have another look next time I boot an Arch VM.
@@glidersuzuki5572thanks and also even primarily living on deb type systems I still consult the Arch Wiki because it has some of the most practical documentation with examples. I'll be looking mainly so that I don't just assume wheel is treated exactly as on the BSDs and blunder into some difference.
6:35: With multiple users and multiple permissions, I just create groups to which I apply "CAP_" (see man 7 capabilities) which apply to the group and then assign users to the groups as appropriate or even assign secondary accounts those users can tap on to to do certain actions. For the most critical things where control is absolute, I has small bits of software in C which I install into /usr/local/adm_actions to which I set 4555 permissions to do those tasks.
Ubuntu never had root password set by default, it was famous that it didn't ask for root password set in the installer back then. Also sudo can spawn a shell of another user (including root) with -s and just have that prompt up. That can be configured to not happen, but default wheel sudoers settings on ubuntu allows it.
"Also sudo can spawn a shell of another user (including root) with -s and just have that prompt up." which he mentioned in passing, along with the fact that this presents the same issue as leaving a root account logged in...
@@erikkonstas Nah, he said you could sudo sh, or sudo bash, and yes and no to same as root account logged in as it may or may not be a login shell in terms of environement setup. In most cases that will make little difference, but with some setups it could be important (-s by default is not a login shell, -l is).
The first thing I do in Llinux (Arch btw😜) after install, is add myself to the wheel group, and edit the sudoers file, where I have a time set in my sudoer's file, set to 10 minutes. It doesn't annoy me when having to do some kind of maintenance, and is not so long that my computer is ever compromised. Since I'm the only one here it could be much longer, but you never know, and I'd rather be more secure than I have to, than less.
Sounds like a lot of boilerplate. I just run Everything as root. You lose a lot of your life on boilerplate with the sudo nonsense. For the first 10 years of my computer Exposure, when I was a Newbie, I was "root" (C64, Amiga, and DOS). This entire video is a workaround for the fact that people use a timeshare Multi user paradigm on their PC (Personal computer) with just one single user.....
@@henrikholst7490 Sorry, but you are wrong on all levels. Who cares what it "Sounds like" to you, because you are obviously filling in blanks and assuming things not said at all. He never said this all applies to single user systems, and even mentioned multi user systems, which I do have, and I am the different users, as I keep my business separate from my everyday private stuff, and myself as a musician for home recording where I have each account setup for best workflow and use in each role, and even use separate drives for each; me, myself, and I. I was computing since 79, when security wasn't nearly as big of a deal, nor did everybody no matter how inept have a freaking computer, but only those in need of one in advancing programming, making software, or geeks already somewhat tech savvy, as far as the private sector. I have very good reasons for what and how I do things, and Linux's paradigm is great for several reasons, better security is one especially in protecting the less savvy from themselves. As administrator, or root or in any OS whatever they call it, it's not just you who have elevated privileges. it's also many of the apps you use that get elevated to, so if one of them is compromised and has elevated privileges, it can do way more harm, or gain even more access, or send out info for remote intrusion... As for "Boilerplate", as in: accepting a commonly held viewpoint: Nothing at all wrong with it if the viewpoint is reasonable and logically valid, and in this case it is.
Anaconda has always required me to set a root password on Fedora, so that's what i've always done and it's disallowed in sshd, but still active. Sometimes, such as when configuring CUPS via its web interface, it needs the root password. I haven't worried too much about it for my personal system.
You have to either enable the root account and set a password, or create a user who is an admin. Anaconda will highlight both with an orange triangle indicating you need to do something, but as long as you do one or the other, both will stop being highlighted and you will be able to proceed to starting the installation.
I only ever utilize the root account if I'm editing files outside of my home directory ( i.e. /etc/(yadda yadda) ), but even then if it's just a single file I'll use sudo. It's a good balance.
I was in I.T. for 20+ years. Not having root/password feels...dirty. Heh. So yeah, home Arch rigs all have root/passwords set up. I almost never need them, but every once in awhile the need arises.
I prefer *sudo -i* to actually login temporarily for the scenario towards the end where you have multiple commands to run in any case only use it for as long as required and mainly for doing something with files or directories normally owned by root or a system service. Be wary of opening your regular files while root because you may inadvertently change ownership or permissions when saving a file.
@@qlumto clarify I have had the normal root login disabled via having no password set on Ubuntu desktops and servers for over 15 years and I checked sudo -i worked correctly before making the post. Have you tested this yourself? People like to moan about Ubuntu but when you install packages / services (or for the standard set of installed packages) they do at least take care of coming setup with sensible defaults.
2:30 I just have aliases set for common stuff that requires sudo. I like tea so my aliases are brew- sudo apt install brewget- sudo apt-get install pour- sudo apt remove refill- sudo apt update boil- sudo apt upgrade
I use `sudo -s` on the super rare occasion when I need a root shell (when I don't feel like looking up how to use pipe tees). Just have to remember to ctrl+d after.
My user shell's history mostly just contains "sudo su -" and I do most shell work as root, working locally. For SSH access, I have root login enabled, but it requires an SSH key, which I make unique to each system.
I have the WTF zsh extension so if the last command news Sudo, I double tap escape and the command is there with Sudo. I generally prefer a root account incase my user account permissions get messed up and I can't login.
With openSUSE, enabling root login is a choice option in the installer and GNOME won't display the name but will allow root login if typed into other. With POP OS it's not a choice, and even enabling with su passwd root still won't by default allow login to GNOME as root. With POP the only way is via terminal as #su If ~/.bashhistory stores passwords and a wifi password finds it's way into that for root then I think it may be possible to establishing unwanted routes.
Let's say I'm in a cli only server and i use sudo su to give my shell session superuser permissions, how do i close my session so i don't just leave a privileged session open on my server?
I absolutely, 100%, without question, support locking out the root account. I also fully, without question, support limiting the sudo system. Far too many systems run into problems because everyone wants to be an admin, with, maybe .1% of users needing to be.
Well everyone with a personal linux system may not want to be an admin, but there needs to be an admin, and there's only 1 possible user to be said admin, even if they're still in high school.
I use sudo, but with an enabled root account and the "targetpw" option. And only the ropt user is in the wheel group, so i have to use the root password for polkit.
On my servers, my default setup is ONLY root has a password and is NOT allowed to login. Other users do not have a password and ONLY login via SSH keys. They are allowed to use sudo without a password.
Let's put it this way. If I have access to your user account I potentially own your data and can make you personally have a real bad day. If I have access to root I can use your machine to make others have a real bad day more or less invisibly until your ISP or a 3 letter agency comes knocking wondering why you're DDoSing Djibouti.
Always set the root password, even if you don’t need it. I was annoyed to find out that “disabled root” is irrelevant in recovery mode, at least on Ubuntu based Linux. If you have no root password set, someone can reboot to recovery mode and do whatever they want, no password required
That's why disk encryption is the only* proper solution * Yeah, it's insufficient for evil maid attacks. You also need something like measured boot and ideally a way to authenticate the computer before inputting anything.
@@mskiptr That prevents your data from being read easily, but it doesn't prevent your data from being destroyed, nor does it prevent the drive itself from being stolen so the attacker can try to decrypt it in a more safe location where they can afford to wait or to get better decrypting tools.
Unless your drive is inaccessible to mount on another box or you can boot another OS with it. Boot Sysrescue, mount the drive with root problem, change the root password and whatever else you want
I am the sole user of my systems, and typically there in no one else in my household that would even have a clue about doing command-line on Linux. Nevertheless, I don't like leaving root logged in. I do have a password set, one that is not easily guessable let alone brute-forceable. All my passwords are committed to memory. None of this writing them down anywhere!!! I also use pass to deal with my online passwords. 20 characters of random hash.
Using Arch with a root password set, and I don't see how it makes any difference really. Sure if someone gets the root account they could blow up the OS. At which point I just... reinstall it. No big deal, might take an afternoon. Whatever. What does matter are my personal files, which would be vulnerable equally to the root account or my personal account. I get that it's a very different situation for servers and shared corporate environments. But for a single user system I don't think it matters much either way.
Normally im a security guy but having a root account has its utilities. There are workarounds? Most of the time but as said, they may even have the same or worse security implications. And the advantage is very small. You shouldn't allow root to remotely login, you shouldn't use root as your primary account, so the scenario where the root account is compromised shouldn't happen and on a consumer system, where Ubuntu and Fedora are the focus your user account is probably more important than root. I maybe see the appeal on servers but even so, having a root acount and be responsible with it outweighs the benefits of not having a root account at all.
I have my own private computer - I'm not running a server on it, and root doesn't have permission to sign in remotely. So root has a password, and for some things I login as root and do them and then return to my regular account. Renaming a user and all the user's files etc, for example, is much easier when one is not logged in as that user. I think my system is not automatically going to get trashed by my ensuring that I have whatever permissions I need whenever I need them , and - it's my PC, if I trash it (which I don't need a working root account to do), I'll sign in with a live OS USB and fix it.
Cos "root" is a role, not a user. Solaris was ahead of the game, linux might one day catch up when it comes to roles, authorization and privileges. In the meantime, sudo, correctly setup, is easier to manage. Ergo, no requirement for a root password, just a password for each user that is permitted to request privilege elevation ( or a role password). Capability management awareness would be next on the list.
I was in the Situation that not having a root Account ment for me to reinstall my distro because the rescue didn't accepted ASCII code input of my sudo user password. Now i have passwords that are US keyboard comforn for the rescue moments...
I enable the root account on Debian after having an experience where i tried to create a new user, and then locked myself out because i made a mistake in the sudoers file. If i had the root account enabled i could have recovered from my error. But i did. So my only option was to chroot it and take ownership and edit the file, or.. just reinstall. Since then i keep my root account enabled because sometimes you need it. Better to have it, and not need it, than need it and not have it.
I do have a root password, just in case, but other than when I first got started with Linux and logged in just to dick around, I haven't actually needed to do so more than when I do initial setup and installation on a system.
Sudo should ask for the root password imo, asking for current user password is dumb. Because if the user is in sudoers and its password was compromised, you basically have compromised root access as well. Granting partial root access does not work and only gives false sense of security. E.g. if you allow user to "only" install packages, this is already a fatal mistake. Because it allows to simply craft and install modified sudo package with new config or modified sudo binary. In fact you can install any arbitrary executable with suid flag set and it will run as root automatically. So yeah, granting users sudo without asking for the root password is very unsafe.
You're thinking of su. Principle of least privilege is that a sudoer *should not know* the root password (because if they did they would have logged in as the root user). Remember also that sudoers can be configured to give really granular access to what an individual user can and cannot do.
@@GSBarlev I already described why granular access is not helpful. It only gives a false sense of security. Almost every partial access scenario I can think of can be exploited to get full root access.
@@framegrace1 if you'd read correctly, I state quite the opposite. Noone should be able to use sudo except the admin. I will repeat again: partial root access can be exploited to gain full access. Every minor oversight will be fatal. Not to mention that sudo itself had serious vulnerabilities in the past and who knows home many there are undiscovered yet. So better not let to use it anyone who you don't fully trust.
You make valid point but I think the solution to your problem is uninstall sudo, not have sudo ask for root password. The whole point of sudo is to run privileged command without root account access. What you are asking for is a system with just su installed instead of sudo.
I don't mind someone having root access on my machine, unless they can access my data. At the same time, I don't like typing a password or giving nvim root privs each time I want to access that data. A hacker with a normal user priv can do a lot of damage. As an average user, I mostly care about the home directory, I don't care if the OS renders disfunctional.
Hahaha... yeah. I have no password, but I force any user to press the "no evil" button before login. That way is better, even if some app have a bug, they can not exploit it because the evil setting is disabled.
I'm on Arch/Qtile and always don't setup a root account, rely on sudo and haven't yet been in a situation where I wish I could just login to root account, and I fing sudo a very short word to be bothered by having to write it 😁
i am used to using pre configured systems like manjaro, ubuntu or mint. Where sudo is always implemented. i am so used to having to sudo all the time, sometimes multiple times after each other that i fill in the pass on lightspeed. But I have noticed the new sudo implemenetion reckonizes weather you need to fill multiple sudos and thus remembers the password for a short time in your terminal session. So i really do not get the point he is making about that it is a hassle. besides Security before comfort!!
On my system, I opted to not install sudo because it requires PAM and PAM takes a lot RAM and just is a mess to deal with. So, what's my solution? Just use root if I'm gonna be compiling stuff, or if it's a small command: su -c "command" which is essentially sudo although probably more dangerous, but I'm the only one using my system so it's not a big deal really.
PAM may use few kb's of RAM with no extra modules, maybe half a meg?.... Where are you running Linux if that's too much? (su is perfectly OK for what we are talking about, btw... just lest flexible)
@framegrace1 I was and still am using LFS and used PAM on it for a few hours. Checking in htop before, while using PAM, and after, while using PAM, the memory usage was 100 MB more and for some reason made my system slower - this difference was noticeable on my HDD. I uninstalled PAM and the issue went away, so I swore off it. Maybe with other distros, it's set up so it's not as bad, but it burned me on LFS and I don't wanna deal with that again.
I managed to lock myself out of a cloud VM once because all accounts were locked and for some weird reason SSH-Key-Login still worked until it didn't... I wish I had a root password set back then...
I have a root account on my systems. They are heavily modified so that the typical user isn’t likely to be able to use them. I once attempted to run a rootless system which resulted in issues with some packages that required root access. I haven’t attempted it again since then.
root disabled != no root user. All linux distros need a root account that's out of the question of course. We are discussing here just to disable the ability to log in with it.
I always use that. On most systems, su alone works... but good sysadmins only allow to run it with sudo, i worked a long time on such systems, so I got the habit of always using it.
This was such an interesting question, I looked it up, and the answer is: it depends on the distro. For some-like SUSE-the answer is "HECK NO!" For others like Arch, it's "Pls no," meaning you can find scripts to do it complete with all the reasons *not* to do it and the things to do instead (read: use /etc/aliases)
You can change the "name" but not the ID. All Unix systems need a user 0. Most things will work, but expect a lot of scripts and things like that to break.
When I need to type a lot of commands as root, I just do a "sudo bash" and an "exit" at the end. I also have only 1 account as I don´t have a problem if my wife use the same account as me. We are only 2 at home.
obviously the solution to that is to edit the uid 0 account to be named steve, not root. (Don't do this.) And what's wrong with my 50 character long password Brodie? 😛
This is obviously not how it's build, since sudo is not part of the shell, but it would be nice if sudo would have at least be distributive over & | etc.
On my ASUSTOR NAS, they 'solved' the root account problem by creating two users (admin and another one defined during setup) in the group administrators. Somehow, all members of the 'administrators' group ignore most file permissions in most partitions. I am not sure how they managed to do that ; probably with a kernel patch. Want to remove /etc/shadow or modify /root/.ssh/authorized_keys as an administrator? Not a problem. Sudo is not even required. The funny thing is that administrators are the only users allowed to connect via ssh because you know ... "ssh is dangerous". Yeah! Sure...
No magic... admin group was part of the root group... usually that's how it's setup. (It can get more complex playing with groups, but you get the idea). Today instead of grouping by users, systems tend to be grouped by "functions" Instead of admin that can access all root group files, more granular groups are created like; disk-admin, printer-admin. That combined with sudo is a lot more flexible.
@@framegrace1 I am not sure to understand what you mean by "admin group was part of the root group" since, as far as I know, Linux groups are not hierarchical. Here, the user 'admin' is member of the group 'administrators (999)' but not of the group 'root (0)'. Also, Asustor administrators can access all files regardless of the owner, group and other permissions so they really behave like the root user. Something I noticed is that this works in filesystems such as ext4 but not in tmpfs or overlay so they probably patched some filesystem kernel modules.
Maybe check the file access control lists using `getfacl` command. Were probably set on install on your ext4 file system. Which would explain why your other file systems don't behave the same.
@@cynodont7391 Oh, then is just a filesystem with ACL support enabled. For the names of the groups, most probably shared with a windows network so it makes sense. ext4 has acl support, so it may be it. Is not usuall to have it enabled unless the main use is file sharing. No need to do anything special, just use the 'acl' flag on mount and then use setacl and getacl commands to add/remove permissions.
@@bjbboy71697 That was also one of my first ideas but fgetacl shows nothing suspicious . Also, administrators have the same behavior in a loopback ext4 partition I created myself. Pure black magic :-)
I found it odd that my root didn't have a password. Thankfully I use Ubuntu (planning on moving to Arch to learn more about Linux in general), so my root account is already locked. However, I am still paranoid, so I may end up making a password and locking it again just to be sure...
Definitely try Arch, at least for a while, and make sure you keep good notes as you go thru the install and as you continue using, you'll learn so much. Sure there's a learning curve, but eventually it just feels like any regular distro, which is a great thing, except you know exactly whats going on since it didn't hold your hand through the important bits.
You can check to set up something like fail2ban or something. It won't stop them from trying to log in (not much you can do about that), but it will automatically bad their ip if they fail too many times (that obviously goes for you as well). You can set it up so the time they are banned is longer every time they trigger it as well. So it at least prevents them from bruteforcing. And I highly recommend not just using username/password for login. I would use ssh keys and disable password login and disable root login to ssh if there is an other user available. In the end it doesn't really matter that they are trying to get into your system as long as they don't really have a chance to get in without your ssh private key. And I know from experience that this stuff happens on NAS systems like Synology and QNAP as well. I remember geoip blocking a huge amount of countries back in the day on a NAS. Changing the ssh port helped a bit on that NAS, but it probably won't help if they do a portscan or something. So I think the most important thing is preventing them from loging in with just a username/password. Also, it seems like the attempts on the VPS server I rent has gone down by a lot ever since they took down that botnet not too long ago.
You know you don't need to have a root password to use sudo -s which general works in places where you need to have root. Without having a root password. That's what I use when I get lazy and want to execute a couple of commands as root.
Switching to a root account will not always give you all tools/locations available, you'll get the user path by default ("su" vs "su -"). IMHO, sudo is useless on a single user desktop only machine.
It's easier to type _sudo + your password_ than _su + root's password_
ปีที่แล้ว
Not having a root password doesn't really address the issue of leaving a root shell open. You can just use sudo -i, sudo su -, or use sudo to start a shell 🤷
One extremely underutilized feature in Linux is capabilities. For example, nmap usually requires root privileges for most of its scan probes. However, an admin can give the nmap binary the capabilities to access raw network sockets (CAP_NET_RAW, CAP_NET_ADMIN, and CAP_NET_BIND_SERVICE), which in turn allows unprivileged users to run nmap with their own account, no sudo required, yet still performing raw network operations.
I work in the opposite direction. I run Everything as root. No users. If I need a sandbox, Docker containers. Obviously no user besides root inside the container. Try it. You'll never look back again at the sudo nonsense.
If you grew up with C64, Amiga, and DOS, this makes perfect sense.
@@henrikholst7490 😂
@@henrikholst7490honestly, i kind of do the same. i just find myself having to run commands as root so frequently that i often log into a client and run "sudo -i". maybe i should also just ditch regular users for these servers.
@@henrikholst7490If you grew up using DOs of course you're going to completely ignore reason. It's the DOS way. UNIX > DOS && UNIX.birthdate < DOS
@@henrikholst7490 What's your IP address?
sudo -i
Runs an interactive sudo shell. similar to logging in as root.
One of the major benefits of sudo is accountability.
It logs all sudo activity in fine detail.
*This incident will be reported.*
sudo su
I'm a novice-intermediate user and honestly when I set up our local network and servers I was originally using Ubuntu for most of my systems, I swapped to Debian 11 and Debian 12 (depending on the system) after Snap packages broke and completely destroyed one of my server boxes.
When setting them up for the first time I'd made the assumption having a root account would be a small vulnerability due to its static nature, kinda glad I was right.
I also recently switched my new installs from Ubuntu to Debian 12. And I made the mistake of setting a root password once.
Ubuntu with their snap obsession yet still delivering a really old version of docker on snap have really pushed me away
Some cloud imstallers (VPS services) still set a root password and have root login over ssh enabled even on ubuntu or debian. It is wise to harden those:
- create a normal user
- disable root login over ssh
And consider other steps like pubkey login only.
This remembers me of my high school, they had the root password as the regular user password and the user was in the sudoers file as well, detail, the password was printed in a paper taped on the desk
worth pointing out that with no root password set, you can still `sudo su` to log-in as root using your personal password instead of the root password. Helps in the cases where you need to run a lot of privileged commands in a row with a disabled root password (as covered in the video, doing this is less secure than running everything with sudo, but convenience is nice)
Came to comment section to say exactly this. THIS is the solution to the problem Brodie brought up. It works because sudo can allow a user to run `su` as root and su allows the root user to login to any account (including root itself) without a password.
Why is everyone on the internet suggesting "sudo su"? That runs "su" as root, so you switch to root using sudo, to then switch to root again using su. Just use "sudo -i" which gives you an interactive shell as root. Same effect, same amount of keystrokes, one less executable involved. Yes, "sudo su" just also works, but promoting that online screams "I give tips about sudo without knowing sudo".
@@christophsarnowski9849use sudo su
Nice Greninja print you got there :D
I really enjoyed that video you did a while back on *all of the other limited-scope no-login accounts* that exist on a modern Linux system. Those never have passwords, and I think of *root* in the same vein.
The first thing i always do when i setup a new server:
Setup SSH Keys,
Disable root account.
(And sometimes put the ssh port behind a VPN)
Yeh I need to actually finish my SSH Key exchanges lol...
As always brilliant, now to educate people install Slackware on an 386 or 486 system from maybe 1996 or a vm simulating such a system, if not for anything else but to show how easy Linux has become to install and use 😉
Having no root account actually caused me a few issues on fedora linux.
I once incorrectly set up my fstab file, so at bootup it failed to mount. For some reason, fedora automatically sends you into emergency mode when anything goes wrong during bootup (including something going wrong while mounting drives). And guess what. It tries to log you into a root account...... which I had disabled because I didn't know any better. So now I'm completely locked out of my computer because of something so trivial as a failed drive mount.
Had to create a usb live environment and fix the fstab file from there.
Some distros use Grub to provide a single-user mode for each kernel version in the menu alongside the regular login so you can still access from there to make the minimum of changes in that scenario,
but yes it is always worth knowing the process with a live USB.
It's also a reminder that not having a root password set has no bearing on leaving someone unattended with physical access except that you'd know they restarted.
@@UKprl The different menu entries that fedora has for different kernels all entered emergency mode so I was locked out of my computer anyway.
Now that I have my root user setup this isnt an issue though. I can just login as root and just do that journalctl -xb command or whatever it was to figure out what went wrong.
IIRC there is an option to disable strict mode per volume and let systemd ignore failed mounts at boot for that volume.
Strict mode is handy for stuff like databases where it could render the whole server useless/corrupted anyway if the mount has failed.
@@giusdbg Not sure what a recovery mode is but when something during boot fails fedora throws you into a CLI only environment and asks you to log into your root account. If you don't have it you are locked out of your system.
@@giusdbg How can I mount / when I cant even login?
You don't need an active root account to keep a shell in root mode. A simple "sudo -s", "sudo bash" etc will do the work just fine. The only valid reason for disabling root login (which I always do), is because of what you said. It's the first thing that anyone will try because it exists on all systems. There are no other benefits or security reasons to do so.
sudo su also works
There's also "sudo -i", which launches a login shell as the root user (or other user if combined with the "-u" switch).
Using sudo every time is still a good thing because it will hopefully cause you to stop and think about the command you’re about to run. Also, for piping, you can run “sudo su”, just enter the command normally, and exit afterwards.
Nah. If I'm a regular user and forget to sudo, I just run "sudo !!" to run the previous command again, as root. No time for stopping and thinking 😂
sudo -s is generally recommended instead of using su.
@@user2C47 Did you watch the video...?
Thanks Brodie - i've used Linux systems for 25 years, and you just taught me something new, the 'tee' command!
I've noticed suse being a bit weird in that regard. Instead of locking the root-account if sets the same Password as the sudo user and sudo asks for the root Password (which technically is the users pw, but it specifically states root user)
ubuntu might not have a root password set but you can always sudo su. 4:20 Very good point. No matter how you go about it, never allow logging in as root directly in your sshd config. I mean of course ssh via username and password should be disabled in general once the keys are all set up but root login is always extra dangerous. Also on a server that has sshd enabled I'd set the timeout for sudo to something really low like 5 seconds or make the user enter the password every time to begin with.
First, it's "sudo -s", no need to name the "su" binary directly in this dirty way; second, and he mentioned it, this starts a root shell which, guess what, is able to be left unattended (yes, there is a chance, here in Greece we call it "earthquake").
One issue that involves sudo is environment context switching and environment variable and path sourcing when doing upstream "vanilla" development and installation management (e.g., TeXlive). Not only are there differences among distro families (e.g., Arch, Debian, Fedora) but also within them (Debian, MX). One must remember to use "sudo -i" in order to get a clean context switch and also determine if secure path sourcing is on or not (Debian family). Otherwise, doing upstream development on distro-independent projects by just using sudo can fail in certain instances due to keeping the normal user's context instead of the system's context, or losing access to the desired command path and not knowing why at first. In certain cases, having a root account with an assigned password might help, but using "sudo -i" and full paths from root to wherever the binary you want to run will also get the same result.
Yeah. One of the big learning curves for me in switching to Arch has been that build scripts for AUR packages use the tools in the *environment's paths.* Since I have a habit of having conda activated by default (advice on any other OS is *never* to use the system Python), I'd keep having builds fail (or install correctly but be unusuable) due to confusion about which dependencies existed on the system. At one point I went as far as adding: `alias yay=conda deactivate && yay` to my .bashrc
@@GSBarlev You should never use system _pip._ Using system python is fine, so long you don't need additional packages. Tho remember that all python-* packages in Arch are dependencies needed for regular Arch packages. They aren't really designed for Python development.
Personally, I just create plain venvs for every Python project I start. And installing a Jupyter kernel inside of there isn't too hard either.
@@mskiptr Brodie's video also taught me the joys of pipx. It's great for software that doesn't need a specific version of Python.
Yep. I have a root passwd set on my local systems but at work there are no local accounts ... sssd/ldap and all that. One thing I didn't hear you say about having a root shell open and walking away was that if you do then a quick super+l before hand helps quite a lot. :D
Its the basic premise of security. Dont leave your system logged in. And exiting a root shell is as simple as ctrl+d. Or lock your system with super+l.
@@arturpaivads Yep. It is. You'd be surprised how many folks don't though. I've punked more than one co-worker for not doing these basic things.
there one more point, the log of system changes. If each user has its own profile, all the changes could be backtracked to the specific user that made the change.
So 4 days ago, I ran a giant wire shark scan, the morning after I was very tired and Mint had just forgotten WiFi existed. I started trying to troubleshoot but my first thought was that adding the user to the wire shark group had somehow impacted permissions to use certain files in /dev. In my very bleary state, I wanted to just remove all groups for my account, so i opened a terminal and typed sudo usermod -G richard richard, and pressed enter. About a second after entering my stupidly complex password correctly on the first go, my heart jumped straight to my mouth. Thinking oh yeah I’ll just restore from a time shift backup. Nope, that requires root. Sighted people can just launch a recovery menu and bring up a root prompt at boot. My blindness and the lack of a screen reader meant the next 90 minutes was spent pressing random buttons and photographing and ocr-ing my screen with an iPhone, trying to figure out the exact menu layout in recovery, terminal output and desperately trying to add my account back to the sudo group. Moral of the story, think before you press enter. Also screen readers in recovery mode need to be a thing.
I've been using Linux since 1997. My first distro was Red Hat, and I actually bought it in a store. The reason I got it was because my brother had it, and seemed to like it, and Windows pissed me off so much that I just took the leap into Linux.
It had a functional root account. I don't believe that it shipped with sudo, but could be mistaken.
Can't remember the last time I used a separate root passwd. Always remember to add user to wheel in Arch
I'm realizing now that Brodie is an evil genius-getting all of us to comment with whether we use root or not. With TH-cam logging our IPs, that means that he now has the ability to bruteforce into a nonzero number of our systems. 🤣
I was surprised to hear him mention the wheel group as I am familiar with its function on FreeBSD-based stuff but not all distros use this group; I'll have another look next time I boot an Arch VM.
@@UKprl Arch Wiki suggests some groups like wheel, audio, video in the installation guide hyperlinks.
@@glidersuzuki5572thanks and also even primarily living on deb type systems I still consult the Arch Wiki because it has some of the most practical documentation with examples.
I'll be looking mainly so that I don't just assume wheel is treated exactly as on the BSDs and blunder into some difference.
In Fedora you can use *sudo -i* to enter the root account even if it doesn't have a password. The Rescue mode is still broken.
6:35: With multiple users and multiple permissions, I just create groups to which I apply "CAP_" (see man 7 capabilities) which apply to the group and then assign users to the groups as appropriate or even assign secondary accounts those users can tap on to to do certain actions.
For the most critical things where control is absolute, I has small bits of software in C which I install into /usr/local/adm_actions to which I set 4555 permissions to do those tasks.
I belive using sudo -i can log you in as root without having a root password set.
Ubuntu never had root password set by default, it was famous that it didn't ask for root password set in the installer back then.
Also sudo can spawn a shell of another user (including root) with -s and just have that prompt up. That can be configured to not happen, but default wheel sudoers settings on ubuntu allows it.
"Also sudo can spawn a shell of another user (including root) with -s and just have that prompt up." which he mentioned in passing, along with the fact that this presents the same issue as leaving a root account logged in...
@@erikkonstas Nah, he said you could sudo sh, or sudo bash, and yes and no to same as root account logged in as it may or may not be a login shell in terms of environement setup. In most cases that will make little difference, but with some setups it could be important (-s by default is not a login shell, -l is).
@@EwanMarshall Yeah, I don't think the adversary will care if that's a login shell or not... 😂
@@erikkonstas it can matter with the right setup, one can also use it to other user accounts and limit it to that.
The first thing I do in Llinux (Arch btw😜) after install, is add myself to the wheel group, and edit the sudoers file, where I have a time set in my sudoer's file, set to 10 minutes. It doesn't annoy me when having to do some kind of maintenance, and is not so long that my computer is ever compromised. Since I'm the only one here it could be much longer, but you never know, and I'd rather be more secure than I have to, than less.
Sounds like a lot of boilerplate. I just run Everything as root. You lose a lot of your life on boilerplate with the sudo nonsense. For the first 10 years of my computer Exposure, when I was a Newbie, I was "root" (C64, Amiga, and DOS). This entire video is a workaround for the fact that people use a timeshare Multi user paradigm on their PC (Personal computer) with just one single user.....
@@henrikholst7490 Sorry, but you are wrong on all levels. Who cares what it "Sounds like" to you, because you are obviously filling in blanks and assuming things not said at all. He never said this all applies to single user systems, and even mentioned multi user systems, which I do have, and I am the different users, as I keep my business separate from my everyday private stuff, and myself as a musician for home recording where I have each account setup for best workflow and use in each role, and even use separate drives for each; me, myself, and I. I was computing since 79, when security wasn't nearly as big of a deal, nor did everybody no matter how inept have a freaking computer, but only those in need of one in advancing programming, making software, or geeks already somewhat tech savvy, as far as the private sector. I have very good reasons for what and how I do things, and Linux's paradigm is great for several reasons, better security is one especially in protecting the less savvy from themselves. As administrator, or root or in any OS whatever they call it, it's not just you who have elevated privileges. it's also many of the apps you use that get elevated to, so if one of them is compromised and has elevated privileges, it can do way more harm, or gain even more access, or send out info for remote intrusion...
As for "Boilerplate", as in: accepting a commonly held viewpoint: Nothing at all wrong with it if the viewpoint is reasonable and logically valid, and in this case it is.
I do have a root account but I run Arch and like you said, they recommend you do.
Anaconda has always required me to set a root password on Fedora, so that's what i've always done and it's disallowed in sshd, but still active. Sometimes, such as when configuring CUPS via its web interface, it needs the root password. I haven't worried too much about it for my personal system.
You have to either enable the root account and set a password, or create a user who is an admin. Anaconda will highlight both with an orange triangle indicating you need to do something, but as long as you do one or the other, both will stop being highlighted and you will be able to proceed to starting the installation.
I’m just that one person that is insistent on their friends locking the root account and not being stupid with ut
I only ever utilize the root account if I'm editing files outside of my home directory ( i.e. /etc/(yadda yadda) ), but even then if it's just a single file I'll use sudo. It's a good balance.
I was in I.T. for 20+ years. Not having root/password feels...dirty. Heh. So yeah, home Arch rigs all have root/passwords set up. I almost never need them, but every once in awhile the need arises.
This is why i love sudo su
Or just sudo -s
@@Slymeballor: sudo -sE (to preserve current environment variables)
I prefer *sudo -i* to actually login temporarily
for the scenario towards the end where you have multiple commands to run
in any case only use it for as long as required and mainly for doing something with files or directories normally owned by root or a system service.
Be wary of opening your regular files while root because you may inadvertently change ownership or permissions when saving a file.
sudo su and sudo -i do not work when you have the root account disabled, sudo -s still works though.
@@qlumto clarify I have had the normal root login disabled via having no password set on Ubuntu desktops and servers for over 15 years and I checked sudo -i worked correctly before making the post.
Have you tested this yourself?
People like to moan about Ubuntu but when you install packages / services (or for the standard set of installed packages) they do at least take care of coming setup with sensible defaults.
If I need to run lots of commands as root in Ubuntu I tend to run sudo bash and do everything there
2:30
I just have aliases set for common stuff that requires sudo.
I like tea so my aliases are
brew- sudo apt install
brewget- sudo apt-get install
pour- sudo apt remove
refill- sudo apt update
boil- sudo apt upgrade
I use `sudo -s` on the super rare occasion when I need a root shell (when I don't feel like looking up how to use pipe tees). Just have to remember to ctrl+d after.
My user shell's history mostly just contains "sudo su -" and I do most shell work as root, working locally. For SSH access, I have root login enabled, but it requires an SSH key, which I make unique to each system.
I have the WTF zsh extension so if the last command news Sudo, I double tap escape and the command is there with Sudo.
I generally prefer a root account incase my user account permissions get messed up and I can't login.
With openSUSE, enabling root login is a choice option in the installer and GNOME won't display the name but will allow root login if typed into other.
With POP OS it's not a choice, and even enabling with su passwd root still won't by default allow login to GNOME as root. With POP the only way is via terminal as #su
If ~/.bashhistory stores passwords and a wifi password finds it's way into that for root then I think it may be possible to establishing unwanted routes.
Yep. Same story I've heard a hundred times before.
•••
I *died* at the outro 😂
Let's say I'm in a cli only server and i use sudo su to give my shell session superuser permissions, how do i close my session so i don't just leave a privileged session open on my server?
I absolutely, 100%, without question, support locking out the root account. I also fully, without question, support limiting the sudo system. Far too many systems run into problems because everyone wants to be an admin, with, maybe .1% of users needing to be.
Well everyone with a personal linux system may not want to be an admin, but there needs to be an admin, and there's only 1 possible user to be said admin, even if they're still in high school.
I've mainly been using "sudo -s" for times when I otherwise need to repeatedly use sudo.
you know it never really dawned on me but, why tf does arch name the group for sudo-in' called "wheel"? Just a weird name now that I think about it.
Weird indeed. It's not just Arch though, I think it's universal.
I use sudo, but with an enabled root account and the "targetpw" option. And only the ropt user is in the wheel group, so i have to use the root password for polkit.
On my servers, my default setup is ONLY root has a password and is NOT allowed to login. Other users do not have a password and ONLY login via SSH keys. They are allowed to use sudo without a password.
Let's put it this way. If I have access to your user account I potentially own your data and can make you personally have a real bad day. If I have access to root I can use your machine to make others have a real bad day more or less invisibly until your ISP or a 3 letter agency comes knocking wondering why you're DDoSing Djibouti.
Djibouti had it coming. Seriously-what self-respecting nation has a capital with the same name as the country.
Always set the root password, even if you don’t need it. I was annoyed to find out that “disabled root” is irrelevant in recovery mode, at least on Ubuntu based Linux. If you have no root password set, someone can reboot to recovery mode and do whatever they want, no password required
That's why disk encryption is the only* proper solution
* Yeah, it's insufficient for evil maid attacks. You also need something like measured boot and ideally a way to authenticate the computer before inputting anything.
@@mskiptr That prevents your data from being read easily, but it doesn't prevent your data from being destroyed, nor does it prevent the drive itself from being stolen so the attacker can try to decrypt it in a more safe location where they can afford to wait or to get better decrypting tools.
@@angeldude101 Proper encryption should be impossible to brute-force. But yeah, no solution is perfect and destroying stuff is sadly quite easy
“Root” and “Administrator” are the first accounts I disable on a system setup
There is always way around not have password for root account. For example just used sudo -i to drop in root account.
If you're using sudo on a compromised account, all bets are also off.
I always think those threat models are completely unrealistic.
But what can you do to my Raspberry pi if I hold it in my hands (no wifi, no LAN cable :P) :D? Even if the root password is a default password.
Sudo -i feels ignored
Unless your drive is inaccessible to mount on another box or you can boot another OS with it. Boot Sysrescue, mount the drive with root problem, change the root password and whatever else you want
I am the sole user of my systems, and typically there in no one else in my household that would even have a clue about doing command-line on Linux.
Nevertheless, I don't like leaving root logged in. I do have a password set, one that is not easily guessable let alone brute-forceable.
All my passwords are committed to memory. None of this writing them down anywhere!!!
I also use pass to deal with my online passwords. 20 characters of random hash.
Using Arch with a root password set, and I don't see how it makes any difference really. Sure if someone gets the root account they could blow up the OS. At which point I just... reinstall it. No big deal, might take an afternoon. Whatever.
What does matter are my personal files, which would be vulnerable equally to the root account or my personal account.
I get that it's a very different situation for servers and shared corporate environments. But for a single user system I don't think it matters much either way.
Normally im a security guy but having a root account has its utilities. There are workarounds? Most of the time but as said, they may even have the same or worse security implications. And the advantage is very small. You shouldn't allow root to remotely login, you shouldn't use root as your primary account, so the scenario where the root account is compromised shouldn't happen and on a consumer system, where Ubuntu and Fedora are the focus your user account is probably more important than root.
I maybe see the appeal on servers but even so, having a root acount and be responsible with it outweighs the benefits of not having a root account at all.
How do I make my sudo password differ from my login password? I'm on Debian
I like to have a separate root password on my NAS and server.
Less so on desktop systems where it's just annoying.
I have my own private computer - I'm not running a server on it, and root doesn't have permission to sign in remotely. So root has a password, and for some things I login as root and do them and then return to my regular account. Renaming a user and all the user's files etc, for example, is much easier when one is not logged in as that user. I think my system is not automatically going to get trashed by my ensuring that I have whatever permissions I need whenever I need them , and - it's my PC, if I trash it (which I don't need a working root account to do), I'll sign in with a live OS USB and fix it.
Good security precausson why so you Need Root Account in login anyway
For doing a bunch of root commands, just sudo tcsh. (or bash if you prefer)
Cos "root" is a role, not a user. Solaris was ahead of the game, linux might one day catch up when it comes to roles, authorization and privileges. In the meantime, sudo, correctly setup, is easier to manage. Ergo, no requirement for a root password, just a password for each user that is permitted to request privilege elevation ( or a role password).
Capability management awareness would be next on the list.
I was in the Situation that not having a root Account ment for me to reinstall my distro because the rescue didn't accepted ASCII code input of my sudo user password. Now i have passwords that are US keyboard comforn for the rescue moments...
7:45 Personally, I would just use "sudo sh" to do something that requires me to type multiple times of sudo.
I enable the root account on Debian after having an experience where i tried to create a new user, and then locked myself out because i made a mistake in the sudoers file. If i had the root account enabled i could have recovered from my error. But i did. So my only option was to chroot it and take ownership and edit the file, or.. just reinstall. Since then i keep my root account enabled because sometimes you need it. Better to have it, and not need it, than need it and not have it.
I do have a root password, just in case, but other than when I first got started with Linux and logged in just to dick around, I haven't actually needed to do so more than when I do initial setup and installation on a system.
Sudo should ask for the root password imo, asking for current user password is dumb. Because if the user is in sudoers and its password was compromised, you basically have compromised root access as well.
Granting partial root access does not work and only gives false sense of security. E.g. if you allow user to "only" install packages, this is already a fatal mistake. Because it allows to simply craft and install modified sudo package with new config or modified sudo binary. In fact you can install any arbitrary executable with suid flag set and it will run as root automatically.
So yeah, granting users sudo without asking for the root password is very unsafe.
You're thinking of su.
Principle of least privilege is that a sudoer *should not know* the root password (because if they did they would have logged in as the root user).
Remember also that sudoers can be configured to give really granular access to what an individual user can and cannot do.
@@GSBarlev I already described why granular access is not helpful. It only gives a false sense of security. Almost every partial access scenario I can think of can be exploited to get full root access.
YEah, full access is much better. Let everyone do everything on the servers.
@@framegrace1 if you'd read correctly, I state quite the opposite. Noone should be able to use sudo except the admin.
I will repeat again: partial root access can be exploited to gain full access. Every minor oversight will be fatal.
Not to mention that sudo itself had serious vulnerabilities in the past and who knows home many there are undiscovered yet. So better not let to use it anyone who you don't fully trust.
You make valid point but I think the solution to your problem is uninstall sudo, not have sudo ask for root password. The whole point of sudo is to run privileged command without root account access. What you are asking for is a system with just su installed instead of sudo.
I don't mind someone having root access on my machine, unless they can access my data.
At the same time, I don't like typing a password or giving nvim root privs each time I want to access that data.
A hacker with a normal user priv can do a lot of damage. As an average user, I mostly care about the home directory, I don't care if the OS renders disfunctional.
Hahaha... yeah. I have no password, but I force any user to press the "no evil" button before login. That way is better, even if some app have a bug, they can not exploit it because the evil setting is disabled.
@@framegrace1 let me guess, ubkey?
I'm on Arch/Qtile and always don't setup a root account, rely on sudo and haven't yet been in a situation where I wish I could just login to root account, and I fing sudo a very short word to be bothered by having to write it 😁
i am used to using pre configured systems like manjaro, ubuntu or mint. Where sudo is always implemented. i am so used to having to sudo all the time, sometimes multiple times after each other that i fill in the pass on lightspeed. But I have noticed the new sudo implemenetion reckonizes weather you need to fill multiple sudos and thus remembers the password for a short time in your terminal session. So i really do not get the point he is making about that it is a hassle. besides Security before comfort!!
from my understanding, sudo -s solves most of the issues you mention without having to set up a root password.
Then there are those who after a while get tired of typing their password and discovering you can have passwordless sudo :)
On my system, I opted to not install sudo because it requires PAM and PAM takes a lot RAM and just is a mess to deal with. So, what's my solution? Just use root if I'm gonna be compiling stuff, or if it's a small command: su -c "command" which is essentially sudo although probably more dangerous, but I'm the only one using my system so it's not a big deal really.
Pretty much the opposite. PAM so sudo works with touch id and ssh requires TOTP :-)
PAM may use few kb's of RAM with no extra modules, maybe half a meg?.... Where are you running Linux if that's too much?
(su is perfectly OK for what we are talking about, btw... just lest flexible)
@framegrace1 I was and still am using LFS and used PAM on it for a few hours. Checking in htop before, while using PAM, and after, while using PAM, the memory usage was 100 MB more and for some reason made my system slower - this difference was noticeable on my HDD. I uninstalled PAM and the issue went away, so I swore off it. Maybe with other distros, it's set up so it's not as bad, but it burned me on LFS and I don't wanna deal with that again.
Well, surely wasn't pam, no way it consumes 100 MB of memory. Maybe some other software was doing something.@@zeckma
I managed to lock myself out of a cloud VM once because all accounts were locked and for some weird reason SSH-Key-Login still worked until it didn't...
I wish I had a root password set back then...
I have a root account on my systems. They are heavily modified so that the typical user isn’t likely to be able to use them. I once attempted to run a rootless system which resulted in issues with some packages that required root access. I haven’t attempted it again since then.
root disabled != no root user.
All linux distros need a root account that's out of the question of course. We are discussing here just to disable the ability to log in with it.
@@giusdbg Are you sure you are replying to the correct comment? Or maybe all this information can be read between lines and I'm just dumb.
Even if your root account isnt set you can still use the command 'sudo su' to start a root level session
I always use that. On most systems, su alone works... but good sysadmins only allow to run it with sudo, i worked a long time on such systems, so I got the habit of always using it.
On desktop machines if I need to do lots of admin things I just do sudo bash ;)
I have stupid questions
Also also, can I "rename" the root account. I know it's pointless and may break things haha, but is it possible?
This was such an interesting question, I looked it up, and the answer is: it depends on the distro. For some-like SUSE-the answer is "HECK NO!" For others like Arch, it's "Pls no," meaning you can find scripts to do it complete with all the reasons *not* to do it and the things to do instead (read: use /etc/aliases)
Not stupid. I suspect nothing will work if root isn’t user id 0 but a different name will have only “moderate” breakage on sme systems :-)
You can change the "name" but not the ID. All Unix systems need a user 0.
Most things will work, but expect a lot of scripts and things like that to break.
Call me old school, but I need to make sure I have a root account configured just in case.
When I need to type a lot of commands as root, I just do a "sudo bash" and an "exit" at the end.
I also have only 1 account as I don´t have a problem if my wife use the same account as me. We are only 2 at home.
obviously the solution to that is to edit the uid 0 account to be named steve, not root.
(Don't do this.)
And what's wrong with my 50 character long password Brodie? 😛
First thing I do, when I log into you is sudo -i
This is obviously not how it's build, since sudo is not part of the shell, but it would be nice if sudo would have at least be distributive over & | etc.
On my ASUSTOR NAS, they 'solved' the root account problem by creating two users (admin and another one defined during setup) in the group administrators. Somehow, all members of the 'administrators' group ignore most file permissions in most partitions. I am not sure how they managed to do that ; probably with a kernel patch. Want to remove /etc/shadow or modify /root/.ssh/authorized_keys as an administrator? Not a problem. Sudo is not even required. The funny thing is that administrators are the only users allowed to connect via ssh because you know ... "ssh is dangerous". Yeah! Sure...
No magic... admin group was part of the root group... usually that's how it's setup. (It can get more complex playing with groups, but you get the idea).
Today instead of grouping by users, systems tend to be grouped by "functions"
Instead of admin that can access all root group files, more granular groups are created like; disk-admin, printer-admin. That combined with sudo is a lot more flexible.
@@framegrace1 I am not sure to understand what you mean by "admin group was part of the root group" since, as far as I know, Linux groups are not hierarchical. Here, the user 'admin' is member of the group 'administrators (999)' but not of the group 'root (0)'. Also, Asustor administrators can access all files regardless of the owner, group and other permissions so they really behave like the root user. Something I noticed is that this works in filesystems such as ext4 but not in tmpfs or overlay so they probably patched some filesystem kernel modules.
Maybe check the file access control lists using `getfacl` command. Were probably set on install on your ext4 file system. Which would explain why your other file systems don't behave the same.
@@cynodont7391 Oh, then is just a filesystem with ACL support enabled. For the names of the groups, most probably shared with a windows network so it makes sense.
ext4 has acl support, so it may be it. Is not usuall to have it enabled unless the main use is file sharing.
No need to do anything special, just use the 'acl' flag on mount and then use setacl and getacl commands to add/remove permissions.
@@bjbboy71697 That was also one of my first ideas but fgetacl shows nothing suspicious . Also, administrators have the same behavior in a loopback ext4 partition I created myself. Pure black magic :-)
I found it odd that my root didn't have a password. Thankfully I use Ubuntu (planning on moving to Arch to learn more about Linux in general), so my root account is already locked. However, I am still paranoid, so I may end up making a password and locking it again just to be sure...
Definitely try Arch, at least for a while, and make sure you keep good notes as you go thru the install and as you continue using, you'll learn so much. Sure there's a learning curve, but eventually it just feels like any regular distro, which is a great thing, except you know exactly whats going on since it didn't hold your hand through the important bits.
No need to overcomplicate things, if you need a root shell you just run "sudo bash" - much better than having to set a root password.
I think even Microsoft does this with administrator account on Windows now.
You can always run "sudo bash" and I never saw it not working.
Bold of ya'll to assume I'm not paranoid enough to lock my system even if I'm away for 10 seconds.
I just checked my server (no production stuff), it's getting slammed 24/7 with failed login attempts! Can't believe I didn't check this before 🤦
Should I change SSH to another port?
You can check to set up something like fail2ban or something. It won't stop them from trying to log in (not much you can do about that), but it will automatically bad their ip if they fail too many times (that obviously goes for you as well). You can set it up so the time they are banned is longer every time they trigger it as well. So it at least prevents them from bruteforcing. And I highly recommend not just using username/password for login. I would use ssh keys and disable password login and disable root login to ssh if there is an other user available.
In the end it doesn't really matter that they are trying to get into your system as long as they don't really have a chance to get in without your ssh private key. And I know from experience that this stuff happens on NAS systems like Synology and QNAP as well. I remember geoip blocking a huge amount of countries back in the day on a NAS. Changing the ssh port helped a bit on that NAS, but it probably won't help if they do a portscan or something. So I think the most important thing is preventing them from loging in with just a username/password.
Also, it seems like the attempts on the VPS server I rent has gone down by a lot ever since they took down that botnet not too long ago.
Broddie , personally when i am installing arch/artix i dont set root password
a linux machine with a root password vs me and my hammer
Is that a Seinfeld reference on the board this time?
thanks, removed passwordless sudo
i use arch and i'm a lot of time with root, even with graphic session
in fact, in one of my VMs, the only user with password, home and shell is root
I switch to root (su) on my servers pretty often 😅
sudo -i ?
You know you don't need to have a root password to use sudo -s which general works in places where you need to have root. Without having a root password.
That's what I use when I get lazy and want to execute a couple of commands as root.
You don't need it without -s either...
For sudo you normally need to enter the user password, unless you use the rootpw flag.
Switching to a root account will not always give you all tools/locations available, you'll get the user path by default ("su" vs "su -"). IMHO, sudo is useless on a single user desktop only machine.
It's easier to type _sudo + your password_ than _su + root's password_
Not having a root password doesn't really address the issue of leaving a root shell open. You can just use sudo -i, sudo su -, or use sudo to start a shell 🤷