Day 03 · Linux
Secure Root SSH Access
Technical Overview
By default, standard Linux installations may allow the root administrative account to log in directly via SSH. Because root is a universally known username across all Linux distributions, it is the primary target for malicious automated dictionary and brute-force attacks.
Disabling direct root SSH access is a fundamental step in securing Linux server infrastructure. Instead, developers and system administrators should log in using their own unprivileged personal accounts and elevate their permissions as needed using the sudo privilege layer. This architecture:
- Prevents direct brute-force attacks against the superuser account.
- Enforces accountability by ensuring all administrative actions are logged under a specific user identity in
/var/log/secureor/var/log/auth.log. - Reduces the risk of accidental commands executed with administrative privileges.
This guide outlines the steps to connect to the Application Servers, disable direct root SSH access by modifying the SSH daemon configuration (sshd_config), and restart the service to apply the security policy.
Infrastructure & Configuration Requirements
- Target Hosts: Application Servers (e.g.,
stapp01,stapp02,stapp03) - SSH Configuration File:
/etc/ssh/sshd_config - Configuration Directive:
PermitRootLogin - Secure Value:
no
Step-by-Step Implementation
Apply the following steps to each of the target application servers:
Step 1: Connect to the Application Server
From the Jump Host, SSH into the target application server using your standard user credentials:
# Example for App Server 1
ssh tony@stapp01
Step 2: Edit the SSH Daemon Configuration File
Open the SSH daemon configuration file with superuser privileges using your preferred text editor (e.g., vi or nano):
sudo vi /etc/ssh/sshd_config
Locate the PermitRootLogin directive inside the file.
- If the line is commented out with a hash symbol (e.g.,
#PermitRootLogin yes), remove the#to uncomment it. - Update the value to
no:
PermitRootLogin no
Save and exit the text editor (in vi, press Esc, type :wq, and press Enter).
Step 3: Restart the SSH Service
For the changes to take effect, restart the SSH daemon (sshd) using systemd:
sudo systemctl restart sshd
Verify that the SSH service is active and running correctly:
sudo systemctl status sshd
Step 4: Repeat on Other App Servers
Repeat Steps 1-3 on all other application servers in your environment (e.g., stapp02 and stapp03):
# Connect to App Server 2
ssh steve@stapp02
# Connect to App Server 3
ssh banner@stapp03
Post-Deployment Verification
1. Test Direct Root SSH Login (Should Fail)
From the Jump Host, attempt to SSH directly into the target server using the root account. The server should immediately reject the connection:
ssh root@stapp01
Expected output:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Even if you enter the correct password, access will be denied.
2. Test Standard User SSH Login with Sudo (Should Pass)
Verify that standard users can still successfully log in and run commands with elevated privileges:
# 1. SSH into the server as standard user
ssh tony@stapp01
# 2. Elevate privileges using sudo
sudo -i
The standard user should be authenticated and successfully switch to the root prompt: root@stapp01:~#.