User accounts can be used to wreak havoc when in the wrong hands or manipulated by malicious scripts. And remember, while we may tend to think of users as being human, they need not be. As well as the root superuser and the web server user (you), for example, many system users are created by new packages with privileges to run processes.
Human or not, our responsibility is to contain user accounts so they cannot create direct damage, nor be hijacked. The level of control we have over this will depend on our hosting option but an awareness overall is a jolly sensible thing.
Never share human accounts
Follow the logic. Shared user accounts – where Jack and Jill use the same one – lead to an increased risk of passwords, else maybe an authentication key, falling into the wrong hands. Not only that, they handicap troubleshooting because they obscure logging.
Admin account best practises
Admin users needn't and shouldn't log into a server as root. If you need to elevate rights, you can do so temporarily using sudo -i or su –.
Otherwise, be extra careful before deleting administrators. Be sure to scrutinize file ownership and any scheduled cronjobs for reassignment.
Delete redundant user accounts
Human or not, the fewer the users the better! If a user goes AWOL, then bin the account:
That won't, however, delete a human's home directory, and a new user with the same username would be able to access it. Short of deleting an old home folder you could archive it (using root permissions):
Similarly, backup and delete their databases, else reassign the user's rights to a database because they may have access via a GUI such as phpMyAdmin.
Correct home directory permissions
If you share a server it is imperative that you cannot see each others files.
To ensure 750 is the default for new users, adjust the file /etc/adduser.conf, modifying the DIR_MODE variable to read DIR_MODE=0750.
Securing server access for humans
The same password principles – as set out in wpCop's How to Set Passwords – persist for server access as they do for Dashboard access. Let's not repeat ourselves but here are some additional points. Unless absolutely necessary, don't use passwords but instead employ user-unique authentication keys as set out in Lock Down WP Connections and Harden SSH. Then again, do users such as web developers even need extended access? Probably not. Instead, provide SFTP with SSH for specific folders only as we cover in Setup chroot SFTP Jail for WordPress using OpenSSH.
If you have database administrators then provide access to their databases only.
Deleting unnecessary non-human users
As touched on previously, users need not be human.
Non-human users are there because when we install a package some user has to have rights to make the thing run. That user may be the almighty root-on-high, but in many cases is a new user altogether.
To become acquainted with your system users, human or not, you'll be wanting this file:
So quite a few.
Every one of those, manipulated, poses a security risk so trash the layabouts.
The thing to do is to assess what services are running or installed that are unnecessary, removing them, and ensuring its user is also canned. But be careful, sure. wpCop chats up services and how to identify and terminate those that we do not require in Disable Daemons & Close Server Ports, so there's some fun.