You need to analyze your security risk, starting with what does your server host?
You should look at the Confidentiality, Integrity, and Availability of your server and the data it holds compared to your security posture. How important is the Confidentiality, Integrity, and Availability of the information that your authentication provides access to?
Given that I'm the only human who should have access to a Linux server, what are the major security risks associated with updating sudo to not require a password for my local user?
Some examples of the risks;
Making a mistake that you screw something up and you've taken down your server, reduces the server's availability. So protecting sudo to prevent this puts you in the mindset "should I do this action?" before you do it.
Running malicious (even accidentally malicious) software or script that uses root access (and not realizing it) can put your servers confidentiality and integrity at risk. Then availability risks, for the downtime to fix.
An attacker getting in, say through social engineering or other means and being able to run root commands without sudo asking for password, easily takes over the system.
Where putting sudo behind a password wall will reduce these risks and attack vectors.
You should ask yourself;
- "What (or How much) risk am I willing to accept?"
- "If data is leaked, lost, or destroyed what liability do I have?" (Particularly financial responsibility?)
- "Am I losing money if my server is down?" (customers not having access? advertisements not being seen?)
- "Am I losing money if my server is taken over?" (someone now installs a bot on your server, and uses its resources, costing you network bandwidth and high CPU costs?)
Is this all "likely", probably not, but are you willing or able to accept that risk?
Are there other ways of making sudo less cumbersome without running everything as root?
This question is a little confusing, running sudo is running as root. Running
sudo whoami will return "root". I presume you mean "instead of logging in as root" or "using
sudo su -" to persitently switch to the root user (su; switch user).
The answer is you shouldn't be using sudo all the time, you shouldn't need to be root all the time. You should install and run software in a way that doesn't require root privilages. Add groups to objects that need special access, like devices and other files, and let the software run in the account with limited access. Run services and cron jobs with limited user accounts. Similarly your user should be a part of the softwares group if you're going to modify it or files it has access to regularly.
Yes, there are times you need to have root access, but that should not be normal or regular.
Lets take an example, a minecraft server. It should run or be executed as a service with its own user account (ie. have a service script that runs minecraft in a screen session using the user minecraft), and the files should be owned and accessed by that user and group account. You as the application administrator should have access via the group permissions, and should be able to access the data, and settings of the minecraft application. Rarely, but occasionally you may need to switch to that application user, using
su minecraft or switching to that screen session for that applications console interface.
You should only need root access to modify system settings (network configs for example), security settings (user passwords or firewall), and patches/updates (apt). Not running end-user facing software or modifying application settings (minecraft settings or user files, or a web server config or web data, or database server settings) As the system administrator you should use your root permissions only to modify the system itself.
Keeping a separation of duties is good security.
Something I'll touch on, but I'm not a great source about is your legal obligation of the information your server stores. (This is not legal advice!) You may think it's acceptable to risk the users data, but if you have certain types of data and your server is breached you may be put at legal or financial liabilities that you aren't ready for. If a forensic analysis is done, and you've specifically shown a lack of care of security measures, like just letting a user use passwordless sudo (or worse just using sudo through ssh) and it was the attack vector, that can put you personally at fault for a leak or loss, where if (and can prove) you followed proper security measures your personal liability may be reduced if something happened. (This is not legal advice!)
I hope you're not running a site with financial or other protected data types, but it's something you should be aware of if you store any user data. (Even home address and phone number.)
The US Government provides Unclassified Standard Technical Implementation Guides that you can use to look at best practices to secure a system, literal step by step guides to protecting your system. (The RedHat guide can be used mostly in whole for any linux system.)
The National Institute of Science and Technology (NIST) provides a comprehensive manual about the security controls and why you apply them. You can directly map the STIG guidance to the NIST Control.
Going back to the Confidentility, Availability, and Integrity, the 800-53 provides some guidance with what controls are more important depending on what is important to the data/system you control.