Linux account security is an access-lifecycle task: know who owns each identity, grant the minimum required access, verify what it can actually do, and revoke access when its purpose ends. Account creation alone does not establish safe permissions, and an offshore location does not change these responsibilities.
Inventory identities and dependencies
Separate human administrators, application service accounts and externally managed identities. Record owner, purpose, authentication method, groups, privileged commands and review date. Check jobs, services and file ownership before disabling an unfamiliar account; a name that has not logged in interactively may still run an application.
Create and grant access deliberately
Consult the installed useradd manual and local defaults. Home-directory creation and shell selection depend on options and configuration; they are not guaranteed merely by running useradd. Keep secrets out of shell history, scripts and ordinary logs. Use an approved credential-enrolment process.
Review groups before modifying membership. The usermod manual distinguishes replacing supplementary groups from appending membership. Verify the final groups and start a fresh authorized session where needed.
Test permissions on the actual resource
File and directory permissions have different meanings. Directory search permission is needed to traverse a pathname, as described in the pathname-resolution manual. Deleting a file is controlled principally through its containing directory, with additional rules such as the sticky bit; lack of write access to the file alone is not a deletion safeguard.
Test with the intended identity: required reads and writes must work, while unrelated data and administrative actions must remain unavailable. Account for ACLs, service configuration and SELinux or AppArmor policy where applicable. Do not fix an unexplained denial by making a whole tree world-writable.
Protect administrative access without lockout
Assign individual identities and review sudo privileges. Before restricting direct root SSH access or changing authentication, verify an alternative administrator, configuration validity and console recovery. Removing remote root login is different from disabling the root identity used by the operating system.
Use the installed OpenSSH manuals for supported authentication controls. Protect private keys and recovery credentials. For repeated remote guesses, follow the separate brute-force login investigation; account governance and traffic blocking solve different problems.
Review and revoke
On a role change or departure, review keys, certificates, tokens, groups, active sessions and scheduled work. Password locking alone may leave key-based access or running processes. Preserve required evidence and reassign owned application data before any deletion. Verify that access is revoked through each relevant path.
Log access changes without collecting passwords or unnecessary session content. Assign an owner to investigate alerts; logging is not automatic prevention. WebCare360 is the hosting provider publishing this guide, and server administration remains subject to the actual service agreement.
