<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Soumitra Roy</title>
    <description>The latest articles on DEV Community by Soumitra Roy (@sou).</description>
    <link>https://dev.to/sou</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3956538%2F0c828128-5bac-4e77-a114-66d69597ee71.png</url>
      <title>DEV Community: Soumitra Roy</title>
      <link>https://dev.to/sou</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/sou"/>
    <language>en</language>
    <item>
      <title>SSH Hardening on Linux: What Most Tutorials Skip</title>
      <dc:creator>Soumitra Roy</dc:creator>
      <pubDate>Thu, 28 May 2026 14:23:15 +0000</pubDate>
      <link>https://dev.to/sou/ssh-hardening-on-linux-what-most-tutorials-skip-3585</link>
      <guid>https://dev.to/sou/ssh-hardening-on-linux-what-most-tutorials-skip-3585</guid>
      <description>&lt;p&gt;Most tutorials on SSH hardening stop at changing the default port and blocking root access. Sure, that helps, but it barely scratches the surface. Attackers usually look for the less obvious misconfigurations to gain entry.&lt;br&gt;
This isn't a beginner checklist. It assumes you already know your way around sshd_config, so let's skip the basics and look at what actually stops an attack.&lt;br&gt;
Disable Password Authentication Entirely&lt;br&gt;
Leaving password authentication enabled alongside SSH keys leaves the door open for credential stuffing. Once an attacker finds a valid username, they will brute-force it. Force public key authentication only.&lt;br&gt;
PasswordAuthentication no&lt;br&gt;
AuthenticationMethods publickey&lt;br&gt;
Restrict Cryptographic Algorithms&lt;br&gt;
Out of the box, SSH on many Linux distributions will happily negotiate weak, outdated algorithms. You need to explicitly define what is acceptable.&lt;br&gt;
KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512&lt;br&gt;
Ciphers &lt;a href="mailto:chacha20-poly1305@openssh.com"&gt;chacha20-poly1305@openssh.com&lt;/a&gt;,&lt;a href="mailto:aes256-gcm@openssh.com"&gt;aes256-gcm@openssh.com&lt;/a&gt;&lt;br&gt;
MACs &lt;a href="mailto:hmac-sha2-512-etm@openssh.com"&gt;hmac-sha2-512-etm@openssh.com&lt;/a&gt;&lt;br&gt;
Always run ssh -Q kex to verify what your current version supports before you edit.&lt;br&gt;
Drop Idle Connections&lt;br&gt;
An open but inactive session is an open door for anyone walking by. To drop dead or unresponsive connections, set a strict timeout rule in your sshd_config:&lt;br&gt;
ClientAliveInterval 300&lt;br&gt;
ClientAliveCountMax 2&lt;br&gt;
This cuts unresponsive connections after 10 minutes. However, to drop a true idle session (when a user simply walks away from their keyboard), you need to enforce a shell timeout. Add this to your shell profile (e.g., /etc/profile or .bashrc):&lt;br&gt;
TMOUT=600&lt;br&gt;
readonly TMOUT&lt;br&gt;
export TMOUT&lt;br&gt;
Simple fix. Almost nobody does it.&lt;br&gt;
Tighten Who Can Even Connect&lt;br&gt;
System-level user management won't cut it. Use the native allowlist capabilities of sshd. While AllowUsers supports CIDR notation directly (AllowUsers &lt;a href="mailto:deploy@192.168.1.0"&gt;deploy@192.168.1.0&lt;/a&gt;/24), a Match block is often cleaner for complex rules:&lt;br&gt;
Match Address 192.168.1.0/24&lt;br&gt;
    AllowUsers deploy&lt;br&gt;
IP wildcards like AllowUsers &lt;a href="mailto:deploy@192.168.1"&gt;deploy@192.168.1&lt;/a&gt;.* work too. Same logic applies to AllowGroups.&lt;br&gt;
Turn Off Unnecessary Forwarding&lt;br&gt;
TCP and Agent forwarding are enabled by default. Turn them off. Leaving Agent forwarding running on a shared host is a massive risk — any remote process with root privileges can hijack your local SSH agent.&lt;br&gt;
AllowAgentForwarding no&lt;br&gt;
AllowTcpForwarding no&lt;br&gt;
X11Forwarding no&lt;br&gt;
Test Before You Reload&lt;br&gt;
Never restart sshd blindly after making changes. Always validate the syntax first using root privileges:&lt;br&gt;
sudo sshd -t&lt;br&gt;
Keep your current SSH window open and start a new connection to test. Once you are sure the new configuration works, use reload instead of restart:&lt;br&gt;
sudo systemctl reload sshd&lt;br&gt;
Locking yourself out of your own remote box because of a typo is a headache you only want to experience once.&lt;/p&gt;

</description>
      <category>security</category>
      <category>linux</category>
      <category>devops</category>
      <category>tutorial</category>
    </item>
  </channel>
</rss>
