Disabling OpenSSH immediately after a connection does not secure your host; it merely terminates the active session while leaving the service exposed to future attacks. True security requires hardening the SSH daemon configuration, enforcing key-based authentication, and restricting access through firewalls before closing any open ports.
The Misconception of Immediate Disabling
A common mistake among system administrators is assuming that stopping or disabling the sshd service right after logging in provides immediate protection. This approach is fundamentally flawed because the vulnerability exists in the service configuration itself, not just in the active session. If the SSH daemon remains installed and enabled on the system, an attacker can attempt to connect at any time until the service is permanently disabled or properly secured. Furthermore, many Linux distributions start the SSH service automatically at boot. Therefore, simply disconnecting your current terminal does nothing to prevent new incoming connections from malicious actors scanning your IP address.
To truly secure your host, you must address the root cause: the exposure of the SSH port (typically 22) to the network. The goal is not to hide the door by locking it only when you are inside, but to reinforce the lock so that only authorized keys can open it. This involves modifying the /etc/ssh/sshd_config file to enforce stricter protocols and authentication methods. For instance, you should disable password authentication entirely in favor of public-key cryptography, which is significantly more resistant to brute-force attacks. Additionally, consider changing the default port or using a firewall to restrict SSH access to specific trusted IP addresses only.
Hardening the SSH Configuration
The most effective way to secure your host is to harden the SSH daemon configuration. Start by backing up your current configuration file with sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. Then, edit the file to implement several critical changes. First, disable root login by setting PermitRootLogin no. This prevents attackers from targeting the most privileged account directly. Next, ensure that only protocol version 2 is used, as version 1 has known vulnerabilities. You can enforce this by adding Protocol 2 to the configuration, although modern versions of OpenSSH often default to this anyway.
Another crucial step is to limit the users who can log in via SSH. Use the AllowUsers or AllowGroups directive to specify exactly which accounts have SSH access. This reduces the attack surface by ignoring all other system users. For example, AllowUsers admin deployer ensures that even if someone guesses a password for another user, they cannot log in. It is also advisable to set a maximum authentication attempts limit with MaxAuthTries 3 to slow down brute-force attempts. These settings collectively make it much harder for unauthorized users to gain entry, regardless of whether the service is running or not.
Implementing Key-Based Authentication
Password-based authentication is inherently weaker than key-based methods due to the risk of weak passwords and credential stuffing. Switching to public-key authentication is a best practice for securing your host. Generate a strong RSA or Ed25519 key pair on your local machine using ssh-keygen -t ed25519. Copy the public key to your remote server using ssh-copy-id user@host. Once the key is added to the ~/.ssh/authorized_keys file on the server, you can disable password authentication by setting PasswordAuthentication no in the sshd_config file. This ensures that only clients possessing the private key can authenticate, providing a much higher level of security.
If you encounter issues with key-based authentication, such as permission denied errors, check the ownership and permissions of the .ssh directory and the authorized_keys file. They should be owned by the user and have permissions set to 700 and 600, respectively. For more detailed troubleshooting on adding keys manually, refer to our guide on Fixing "Permission denied" with OpenSSH: Manually adding authorized_keys. Properly configured keys eliminate the need for passwords, removing a significant vector for attack.
Monitoring and Logging
Security is an ongoing process, not a one-time task. Enable verbose logging in the SSH daemon to monitor access attempts. Set LogLevel VERBOSE in the sshd_config file to capture detailed information about each connection attempt. Regularly review these logs for signs of unauthorized access or repeated failed login attempts. Tools like fail2ban can automate the process of banning IPs that show malicious behavior, adding an extra layer of defense against brute-force attacks. By combining proper configuration, key-based authentication, and active monitoring, you can significantly reduce the risk of compromise on your Linux host.
Frequently Asked Questions
Can I just turn off my computer to stop SSH attacks?
No, turning off your computer stops all network activity, but it does not secure the system for when it is back online. When you reboot, the SSH service will likely restart if it is enabled, exposing the same vulnerabilities unless you have hardened the configuration first.
What happens if I disable SSH but still need remote access later?
If you disable the SSH service, you will lose the ability to remotely manage your server via command line. You would need physical access or a console interface to re-enable it, which can be problematic if you are managing a remote data center server without out-of-band management capabilities.
Is changing the SSH port enough to secure my host?
Changing the port provides security through obscurity, which is not a robust security measure. Attackers routinely scan all ports, so moving SSH to a non-standard port will not stop determined attackers but may help reduce noise from automated bots scanning the default port 22.
How do I verify my SSH configuration changes are correct?
You can test your configuration by running sudo sshd -t, which checks the syntax of the sshd_config file without restarting the service. If there are no errors, you can safely reload the service with sudo systemctl reload sshd to apply the changes.
Should I use a different SSH client for better security?
The security of your connection depends more on the server configuration and your key management than the client software. However, keeping your SSH client updated ensures you benefit from the latest security patches and features, such as improved support for newer encryption algorithms.