I don't like being prompted for passwords every time I turn around. I log into my desktop from which I adminster a lot of systems. The last thing I want is to get double authentication prompts on every system I touch (once to login and again to sudo). I fix this a few ways.
- Keep your 'home' account secure
- Relax sudo security
- Configure your SSH client properly
- Run services as unprivliged users
Keep your home account secure
This is the most important bit. If an attacker ever gains access to your system, they'll potentially gain access to all your private keys and thus gain access to every other system you have rights to. Practice safe browsing is the cardinal rule. Be wary of e-mail. Be wary of any free application. Don't steal digital media. People who bypass software licenses aren't good people; they provide cracks and cracked applications in order to load malware onto your PC.
Most malware is targeted at windows, but that's only because they hold the market majority. Don't believe people who foolishly insist OSX or linux are malware imune. There are so many threat vectors in our modern systems. For example: malware authors purchase popular browser plugins and inject malware into them. Yup, that's right! You may have installed a browser plugin once-upon-a-time and since forgot about it. Well, the original author might have also gotten tired of it and received an offer from another developer wanting to take control of it. This is how trusted plugins can become malicious. So if you're not using it, disable/remove it. To get back on topic, the malware industry monetizes their efforts by operating at scale. They strive to infect massive numbers of systems with minimal effort. The best security feature of OSX/linux is their lack of market share.
I love open source, but it also scares me. I trust the community implicitly, but let's consider the unlikely for a moment. Say you use an obscure library in your Node.JS application. Open source is great because you have the ability to review every line of code. But you're using libraries to save time, so of course you don't go through their code; you only dig into something when it doesn't work. Imagine if at any point it had a malicious payload. Loading such a library could let a malicious party steal all your private keys and if you've relaxed sudo they can also trivially pwn your local system. Now, having pointed this out let's not be paranoid. Good malware works to be invisible, and something like this would be highly visible to the open community, so it just isn't likely. But the threat exists because if you didn't check the code yourself, how do you know someone else did? The point here is simply when you have a privliged account, or an account that holds privliged information, you must always be careful about what you choose to run from it.
Rule #1: keep your home account secure. If you're going to relax other security mechanisms, you must always be careful to protect your master account. It should have a strong and unique password and you must be vigilant about protecting the integrity of the system it runs from.
Relax sudo security
I frequently require escalated privliges on my home system as I'm constantly working on projects, creating development environments and needing to edit config files of system services. It would be highly annoying if the system was constantly asking for my password. To limit this, I adjust sudo settings by adding a file to the
/etc/sudoers.d/ directory. The filename can be anything; since I'm just changing my user account I like to make the filename match my username. Add just one line to that file:
#change username as appropriate: username ALL=(ALL:ALL) NOPASSWD:ALL
Now you can open a new terminal. You can
sudo commands to run them as root. Which means you can
sudo su to become root without having to type in a password. The only thing this doesn't work for is the GUI (you'll still get a password prompt for automatic updates or other GUI applications needing escalated privliges), but when working in the terminal this will eliminate password reprompting.
On critical systems, you'll want to take a different approach. You can use sudoer files to provide just as much access as is strictly necessary to specific users/groups. Keeping the password reprompt in place can help protect the system in case a privliged user's private key (used for SSH authentication) becomes compromised.
Configure your SSH client
I run password-less SSH logins by using public key authentication. But doing so doesn't limit the number of public keys you can use to access systems. Using multiple keys will limit your exposure to compromise as long as your home account is secure. If one key becomes compromised, only the system that key provides access to will be vulnerable.
Never host private keys on shared systems; host private keys only on your home system and like rule #1 says, keep your home account secure. For example, don't SSH into a shared remote system and branch out to other systems from there -- anyone with access to the remote system can potentially gain access to your private keys.
If you've made keys for SSH before, you know they're stored in
~/.ssh/. Now make a new one and call it
example because we'll use it for accessing example.com. Then just edit the file
~/.ssh/config and add the following lines:
Host example.com PreferredAuthentications publickey IdentityFile ~/.ssh/example
Do this for as many hosts as you like. You just have to set it up once so that any time you SSH to that host it'll automagically authenticate you with the appropriate key!
Run services with limited privliges
I write a lot of APIs because I do a lot of web development. These APIs and all services should only run with just as much permission as they strictly require. Don't run them under your user account or as root. Take the time to make a limited user account and configure the init process to run the service with this limited account. This way if the service ever gets compromised, the exposure to the underlying system should be limited to the privliges of the user account responsible for running the service.