Many times when we install Linux, the default SSH config is very weak and have many security holes. If you run a CIS L1 Server scan on your fresh machine, it will show seven big fails on your SSH configuration. These bad fails is about missing warning banner, no limit for login tries, no limit for login grace time, too many sessions and startups allowed, not enough log detail, and no user restrictions. To fix all these problems, we can write only one simple override file and put it inside the directory /etc/ssh/sshd_config.d/99-cfg-hardening.conf so when you do package updates, the system does not delete your changes.
Step 1: Open the override config file
First, we must to write a new configuration file in the safe directory. We use a number like 99 in front of the name because SSH reads files in alphabetical order, so 99 will load last and overwrite any old settings that was there before. Open your terminal and type this command to create the file with admin permission:
sudo vi /etc/ssh/sshd_config.d/99-cfg-hardening.conf
If you do not like vi editor because it is too hard, you can use nano editor instead. Now you must copy and paste all the lines below into this file:
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM yes
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
MaxAuthTries 3
MaxSessions 4
MaxStartups 10:30:60
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
Banner /etc/issue.net
AuthorizedKeysFile .ssh/authorized_keys
Protocol 2
KexAlgorithms [email protected],curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected]
AllowGroups ssh-users
Step 2: Understanding what all these config lines mean
I will explain why we need every line in this configuration. If you do not know what they do, it is bad because you might break your server.
The first part is about how users login to the server. We write PermitRootLogin no because root is the most powerful user. If hackers try to guess your root password, they can destroy everything. So we block root from login directly. Next, PasswordAuthentication no is very important because we do not want passwords. Passwords is very easy to guess by automatic botnets. We only want to use SSH keys because they are super strong. PermitEmptyPasswords no makes sure nobody can login if they do not have a password or key. KbdInteractiveAuthentication no turns off interactive typing for password prompts. We write UsePAM yes because it lets the system use Pluggable Authentication Modules for other security checks.
The second part is about forwarding things. We write X11Forwarding no because we do not need to show graphical windows from the server on our home computer. Attackers can use X11 to steal information. We also do AllowAgentForwarding no and AllowTcpForwarding no because bad guys can use these options to tunnel into your other local networks and hack more computers.
The third part is about limits for connection and time. We put MaxAuthTries 3 so if someone tries to guess your key or password and fails three times, the server kicks them out. This stops brute force attacks. MaxSessions 4 means one connection can only have four sessions. We use MaxStartups 10:30:60 to prevent denial of service attacks. This means if 10 people try to login at the same time, the server will start dropping 30 percent of new connections, and if 60 people try, it blocks all new connection tries. LoginGraceTime 30 gives you only 30 seconds to finish your login, if you take too long, it disconnects. ClientAliveInterval 300 and ClientAliveCountMax 2 will check if your connection is still active every 300 seconds. If you do not do anything for a long time, it will close your connection automatically so nobody can steal your open terminal.
The fourth part is about logs and files. We use LogLevel VERBOSE because the default log level is too quiet. Verbose level will log the fingerprint of the SSH key that was used for login, which is very useful for audit. We set Banner /etc/issue.net to show a warning text before login. AuthorizedKeysFile .ssh/authorized_keys tells the system where to look for your public keys. Protocol 2 is because protocol 1 is very old and has many security bugs.
The fifth part is about crypto algorithms. We write KexAlgorithms, Ciphers, and MACs with very specific modern algorithms like curve25519, ChaCha20-Poly1305, and AES-GCM. We do not want old ciphers like 3DES or SHA1 because they are weak and computers can break them now.
The last part is AllowGroups ssh-users. This is a very strong security rule. It means only people who belong to the group called ssh-users can connect to this server. Even if someone has a correct SSH key, if they are not in this group, the server says no.
Step 3: Create the security group and add your user account
If you save the config file now and restart SSH, you will lock yourself out forever because the group ssh-users does not exist yet and you are not in it. We must create this group now. Run this command:
sudo groupadd -f ssh-users
This creates the group. Now we must add your current user account to this new group so you do not lose access. Run this command:
sudo usermod -aG ssh-users $USER
Please make sure you type this command correctly. The $USER variable will automatically use your current username. If you want to add another user later, you can replace $USER with their real username.
Step 4: Create the login warning banner file
In our configuration, we told SSH to use a banner file at /etc/issue.net. If this file is empty or does not exist, it might look bad or fail security scans. We can write some scary warning text inside it to tell hackers they are not welcome. Run this command:
sudo tee /etc/issue.net > /dev/null <<'EOF'
WARNING: Authorized users only. All activity is logged.
Disconnect now if you are not an authorized user.
EOF
This command will write the warning message into the correct file. If someone tries to connect to your server now, they will see this text before they can do anything.
Step 5: Test the configuration and restart SSH service
Before we reload the SSH service, we must check if we made any typing mistakes in our config file. If there is a mistake, SSH service will crash and you cannot connect anymore. Run this test command:
sudo sshd -t
If this command returns nothing and does not show any error message, it means your configuration is safe and has no syntax errors. Now you can reload the SSH service to apply all the changes:
sudo systemctl reload sshd
It is very important that you do not close your current terminal window yet. Keep this session open! Open a completely new terminal window on your computer and try to login to the server to see if it works. If the new login works, then you did everything correctly. If it does not work, you still have the old terminal open to fix the configuration mistakes or remove the bad lines.
Step 6: Bonus configuration for trusted networks
If you have a fixed network range like an office network or a home VPN, you can add a special rule at the end of your file to make things easier for your trusted IP addresses. You can use the Match block like this:
Match Address 10.0.0.0/8
PasswordAuthentication yes
This block must be at the very bottom of the file. It means if you connect from an IP address that starts with 10., the server will let you use password authentication instead of only keys. You can change the network address to your own IP range if you want to use this option.
Conclusion
We have successfully secured the SSH server by fixing all seven findings from the CIS L1 Server scan. We put all changes into one single file in the /etc/ssh/sshd_config.d/ directory so it does not get overwritten by system updates. We limited login attempts, blocked root, turned off dangerous forwardings, used strong modern cryptography, and restricted access to a specific user group.