Securing Your Linux System Through Proper Shell Configuration
The Secure Shell (SSH) protocol allows remote login access and command execution on Linux systems. While extremely useful, SSH can also pose a security risk if not properly configured. By tweaking SSH server settings and hardening user accounts, administrators can dramatically improve the security posture of Linux machines against attacks.
Limit Access Through SSH Configuration
The first step towards securing SSH is to limit which users can gain access to the system remotely. This is accomplished by editing the SSH daemon configuration file, typically located at /etc/ssh/sshd_config.
Restrict root Login and Password Authentication
PermitRootLogin should be set to “no” to prevent remote login by the root superuser account. This forces privilege escalation through a normal user account first, providing additional audit trail.
PasswordAuthentication can also be set to “no” to restrict authentication to SSH keys only. Public key authentication is more secure than password-based login.
Allow Only Specific Users and Require Key-Based Login
AllowUsers lists user accounts allowed to login via SSH while DenyUsers specifies accounts that should be blocked. This whitelist/blacklist allows access control on a per-user basis.
AuthorizedKeysFile can be set to “.ssh/authorized_keys” for each user’s home directory to designate the public keys allowed for SSH login. Keys offer stronger authentication than reusable passwords.
Change Default SSH Port to Non-Standard Port
By default, SSH runs on port 22. Changing to a non-standard port such as 2222 reduces scan traffic attempting to brute force credentials on the standard SSH port. This increases security through obscurity.
Harden User Accounts for Remote Access
Properly configuring the user accounts authorized for SSH login is just as important as restricting access to the SSH daemon itself. Users with remote shell access should have strong credentials and utilize SSH keys.
Enforce Strong Passwords with Password Policies
For any accounts still reliant on password-based authentication, password policies should enforce a minimum level of complexity. The pam_cracklib PAM module can set requirements for password length, character composition, reuse, and expiration.
Use SSH Keys for Authentication Instead of Passwords
SSH key pairs provide a much more secure method of authentication than static passwords. A private key can be configured on a user’s workstation while the public key gets installed on the servers authorized for access. Tools like ssh-copy-id simplify SSH public key distribution.
Revoke Keys When No Longer Needed
When an employee leaves the company or no longer needs remote access, any authorized SSH keys should be removed immediately from servers through the authorized_keys file. Failing to revoke old keys enables future unauthorized access.
Isolate Critical Services With Chroots
For an added layer of protection, chroot jails can isolate and limit remote SSH access to specific directories only. This reduces the reachable attack surface in case of compromise.
Chroot SSH Daemon for Minimal Attack Surface
By chrooting the SSH daemon to an empty directory, remote attackers are restricted to interacting with just the files and directories descended from the chroot jail. This minimizes damage potential.
Limit Damage if a Breach Occurs
If an attacker does fully compromise an SSH account, the chroot severely limits reachable files and commands. Critical system directories like /etc, /bin and /usr now sit outside the isolated chroot view of the server.
Example Chroot Jail Configuration
A sample chroot directory can be created at /var/chroot/sshd containing fake versions of standard directories like /bin and /tmp. Bind mounts can then connect the real /etc/ssh into this chroot to isolate the SSH process and files.
Log and Monitor SSH Connections
Logging all SSH connection attempts and monitoring logs for anomalies provides both an audit trail and a method for detecting brute force attacks.
Enable Logging of Connection Attempts
SyslogFacility and LogLevel settings in sshd_config specify how much detail to log for all SSH connections both successful and failed. Syslog servers centralize logs for analysis.
Send Logs to Remote Server
Allowing logs to persist on the compromised host itself makes tampering trivial. Remote syslog servers with high availability ensure access to SSH audit trails.
Set Up Alerts for Multiple Failed Logins
By default, SSH disconnects after 6 bad password attempts to slow brute force attacks. Monitoring for repeated failed logins via scripts triggers alerts to block attack origin IP addresses.
Test and Verify SSH Hardening Steps
Changes made to secure SSH must be thoroughly tested to prevent accidental lockout. Penetration testing also validates the effectiveness against common attack vectors.
Use Penetration Testing Tools to Validate
Ethical hacking tools simulate unauthorized users attempting access through techniques like password cracking, port scans and exploitation scripts. Successful tests indicate vulnerabilities.
Check Configurations with sshd Validation Tool
The sshd validator inspects SSH server configs for common mistakes that weaken security. The tool detects issues like weak ciphers, incorrect file permissions and poor mac algorithms.
Confirm Only Allowed Users Can Connect
Finally, all authorized admins should attempt to connect via SSH using keys to validate that the AllowUsers list works as expected without locking anyone out.
