Disable Root SSH Login & Use sudo -i for Secure Access: Secure Operational Account Separation
This time, I once again keenly realized that simply not revealing usernames to attackers can significantly increase the difficulty of an attack. When operating a server, we intellectually know we should always pay attention to security, but it's easy to forget until it's right in front of us. I almost forgot again. My personal server allowed direct SSH access as the root account, and looking at the logs, there were an enormous number of brute-force attack attempts targeting the root account daily. Thinking, 'This could really lead to big trouble,' I finally carried out the long-delayed security hardening. I switched to blocking direct root login and accessing with a regular account, then escalating privileges with sudo -i only when necessary. I'd like to share my experiences and the methods I applied during this process.
What you will learn here:
Understand why direct root SSH login is dangerous.Learn how to block direct root login using the PermitRootLogin setting.Learn the process of securely escalating privileges with sudo -i after SSHing with a regular account.Get important tips to prevent locking yourself out of the server.Learn how to verify applied values after changing sshd settings.Target Audience: This will be helpful for solo operators or individual developers who are currently directly SSHing into their server as the root account and want to further enhance server security.Difficulty: Beginner
The Importance of Not Revealing Usernames to Attackers
What I felt most strongly while reconfiguring server security this time was how crucial it is to reduce the attack surface. Especially well-known usernames like 'root' are practically free information for attackers. Looking at my server logs, a significant number of login attempts were persistently trying to access using only the 'root' account. I felt dizzy at the thought that if the root account's password were ever compromised, the entire server could be taken over in an instant. Discovering a username is half the battle in a brute-force attack. By blocking direct root login, attackers must first find a valid username again, which significantly increases the difficulty of the attack. It's a small change, but it can make a considerable difference from a security perspective.
Security Vulnerabilities and Attack Attempts I Faced
In fact, for a long time, my server allowed direct SSH access as the root account. I didn't think much of it, citing convenience. However, a recent check of the server logs revealed a continuous stream of hundreds, even thousands, of login attempts from foreign IPs every day. Most attempts targeted the 'root' username, using a brute-force method to guess my password. I felt a sense of crisis that if this situation continued, even a complex password could eventually be cracked. Root is an account with all system privileges, so if it's compromised, it can lead to irreversible damage. I concluded that leaving it as is was truly dangerous.
PermitRootLogin: Why Was It a Dangerous Setting?
The reason direct SSH access as the root account was possible was because the PermitRootLogin option in the OpenSSH server configuration file, sshd_config, was set to 'yes' or 'prohibit-password' by default, allowing it. This setting means direct login to the root account is permitted. From an attacker's perspective, they already know the username 'root,' so they only need to brute-force the password or SSH key. In other words, they start with half of the attack already solved. Furthermore, when performing operational tasks, it was common to habitually log in directly as the root account, which unnecessarily increased the time spent using root privileges, thereby increasing risk. I decided to change the PermitRootLogin setting to correct these habits and enhance security.
Securely Escalate Privileges with sudo -i After Regular Account Login
Now, I've switched to blocking direct root login and only allowing SSH access with a regular operational account. First, I changed the PermitRootLogin setting to 'no' in the sshd_config file. This setting completely blocks direct SSH login for the root account. Before applying this change, it is crucial to verify that SSH key access with a regular operational account and privilege escalation using the sudo command (by being included in the sudo group) work correctly. Skipping this step could permanently lock you out of the server. After logging in with a regular account, when root privileges are needed, escalate with the following command: sudo -i This allows you to use a shell with root privileges. By requiring a password for each escalation, an additional layer of defense is added, preventing immediate root access even if an SSH key is compromised. Once all settings are complete, restart the SSH service to apply the changes: sudo systemctl restart ssh
Verifying the New Security Settings Are Properly Applied
After changing the settings and restarting the SSH service, it's time to verify that the new security rules are properly applied. First, open a new session and attempt to SSH directly as the root account. Access should clearly be denied. Next, I logged in with a regular account and confirmed that root privilege escalation with the sudo -i command worked correctly. Also, you can use the sshd -T command to check the actual values of the currently applied sshd_config. This is very useful because it shows the final applied values by combining all configuration files. sudo sshd -T | grep -i permitrootlogin If this command outputs 'permitrootlogin no,' then the direct root login blocking setting has been applied as intended. Finally, checking the server logs again, I could see that login attempts from foreign IPs targeting 'root' were no longer proceeding to the authentication stage and were being blocked. This was reassuring.
Concluding Thoughts
By blocking direct root SSH access and switching to logging in with a regular account then escalating with sudo -i, I feel that server security has been significantly strengthened. It's especially important to 'verify that the new path (regular account key access + sudo) works before making the change.' Please remember that if you disregard this order, a careless developer like me could accidentally lock themselves out of the server.
Top comments (0)