امنیت SSH؛ چگونه SSH Server را در برابر Brute Force امن کنیم؟

SSH اصلی‌ترین راه مدیریت سرورهای لینوکسی است و دقیقاً به همین دلیل، از اولین دقیقه‌ای که سرور به اینترنت وصل می‌شود، ربات‌ها با حدس زدن رمز عبور (Brute Force) به آن حمله می‌کنند. در این راهنما قدم‌به‌قدم امنیت SSH را بالا می‌بریم: ورود با کلید، غیرفعال کردن رمز عبور، محدود کردن کاربران، تنظیم فایروال و Fail2ban، بدون اینکه دسترسی خودتان به سرور قطع شود.

حمله Brute Force به SSH چگونه انجام می‌شود؟

ربات‌های خودکار دائماً کل فضای IP اینترنت را برای پورت ۲۲ اسکن می‌کنند. وقتی سرور شما را پیدا کنند، با فهرستی از نام‌های کاربری رایج (root، admin، ubuntu، test) و رمزهای پرتکرار، هزاران بار تلاش به ورود می‌کنند. اگر نگاهی به فایل /var/log/auth.log یک سرور تازه بیندازید، معمولاً بعد از چند ساعت صدها خط «Failed password» می‌بینید.

رمز عبور قوی جلوی این حمله را می‌گیرد، اما راه‌حل قطعی این است که ورود با رمز عبور کاملاً غیرفعال شود و فقط کلید رمزنگاری پذیرفته شود. در این حالت Brute Force عملاً بی‌اثر است.

قبل از شروع؛ قفل نشدن پشت در

اشتباه در تنظیمات SSH می‌تواند دسترسی شما را قطع کند. سه قانون را رعایت کنید:

1. نشست SSH فعلی را تا پایان کار نبندید.
2. هر تغییر را در یک ترمینال جدید تست کنید.
3. مطمئن شوید راه دسترسی جایگزین (کنسول VNC پنل سرور) دارید.

همچنین قبل از غیرفعال کردن root، یک کاربر عادی با دسترسی sudo بسازید:

adduser admin
usermod -aG sudo admin

ساخت کلید ED25519 و ورود بدون رمز

روی کامپیوتر خودتان (نه سرور) یک جفت کلید بسازید. الگوریتم ED25519 امن‌تر و سریع‌تر از RSA است و کلید کوتاه‌تری دارد:

ssh-keygen -t ed25519 -C "admin@my-laptop"

هنگام ساخت، برای کلید یک Passphrase بگذارید تا اگر فایل کلید دزدیده شد، به‌تنهایی قابل استفاده نباشد. سپس کلید عمومی را به سرور منتقل کنید:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@SERVER_IP

در ویندوز ۱۰ و ۱۱ هم دستور ssh-keygen در PowerShell در دسترس است. اگر ssh-copy-id ندارید، محتوای فایل id_ed25519.pub را در فایل ~/.ssh/authorized_keys کاربر روی سرور قرار دهید. حالا در یک ترمینال جدید تست کنید که ورود بدون رمز انجام می‌شود:

ssh admin@SERVER_IP

تنظیمات امن sshd_config

به‌جای ویرایش فایل اصلی، تنظیمات را در یک فایل جداگانه در پوشه /etc/ssh/sshd_config.d/ بنویسید تا با آپدیت سیستم‌عامل بازنویسی نشود:

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers admin
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

دام رایج: فایل‌های sshd_config.d

در SSH، اولین مقداری که برای هر تنظیم خوانده شود اعمال می‌شود و فایل‌های پوشه sshd_config.d به ترتیب الفبایی خوانده می‌شوند. در بسیاری از ایمیج‌های ابری Ubuntu فایلی به نام 50-cloud-init.conf وجود دارد که PasswordAuthentication yes را تنظیم می‌کند. به همین دلیل نام فایل ما با 10- شروع شد تا زودتر خوانده شود. برای اطمینان، فایل‌های موجود را بررسی کنید:

grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

بررسی و اعمال تنظیمات

قبل از ری‌استارت، صحت فایل را بررسی کنید و تنظیمات مؤثر نهایی را ببینید:

sudo sshd -t
sudo sshd -T | grep -E "passwordauthentication|permitrootlogin|allowusers"

اگر خطایی نبود، سرویس را ری‌استارت کنید. نام سرویس در Ubuntu و Debian ssh و در RHEL، AlmaLinux و Rocky sshd است:

sudo systemctl restart ssh

حالا در یک ترمینال جدید دوباره وارد شوید. همچنین تست کنید که ورود با رمز رد می‌شود:

ssh -o PubkeyAuthentication=no admin@SERVER_IP
# انتظار: Permission denied (publickey)

محدود کردن دسترسی با فایروال

اگر از IP ثابت یا VPN به سرور وصل می‌شوید، بهترین کار این است که پورت SSH فقط برای همان IP باز باشد. با UFW:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable

اگر IP ثابت ندارید، حداقل از محدودیت نرخ اتصال استفاده کنید:

sudo ufw limit 22/tcp

تفاوت ابزارهای فایروال لینوکس را در مقاله UFW یا iptables یا nftables مقایسه کرده‌ایم.

مسدودسازی خودکار با Fail2ban

حتی با ورود فقط با کلید، ربات‌ها همچنان تلاش می‌کنند و لاگ‌ها را پر می‌کنند. Fail2ban لاگ‌ها را می‌خواند و IPهایی را که چند بار پشت سر هم ناموفق بوده‌اند، برای مدتی مسدود می‌کند. آموزش کامل نصب و تنظیم را در نصب Fail2ban روی Ubuntu ببینید.

آیا تغییر پورت SSH لازم است؟

تغییر پورت از ۲۲ به یک عدد دیگر امنیت واقعی ایجاد نمی‌کند، چون اسکنرها همه پورت‌ها را بررسی می‌کنند. اما حجم تلاش‌های خودکار و نویز لاگ‌ها را به‌شدت کم می‌کند. اگر پورت را تغییر می‌دهید، قبل از ری‌استارت SSH، پورت جدید را در فایروال باز کنید. در غیر این صورت دسترسی‌تان قطع می‌شود. در توزیع‌های دارای SELinux هم باید پورت جدید را با semanage مجاز کنید.

پایش ورودها

سخت‌سازی یک کار یک‌باره نیست. به‌صورت دوره‌ای ورودهای موفق را بررسی کنید:

last -a | head -20
sudo journalctl -u ssh --since "24 hours ago" | grep -i accepted

روش کامل بررسی ورودهای مشکوک را در مقاله تنظیمات امنیتی ضروری بعد از خرید VPS هم مرور کرده‌ایم.

سوالات متداول