امن‌سازی SSH روی سرور ابری: حذف لاگین پسوردی، بستن Root و جلوگیری از Brute Force

روی اینترنت، حمله‌های brute force / password spraying یکی از رایج‌ترین مسیرهای “دسترسی اولیه” است (MITRE آن را به‌عنوان تکنیک مشخص مستند کرده). MITRE ATT&CK
گزارش‌های ریسک و تله‌متری امنیتی هم نشان می‌دهند brute force login هنوز از پرتکرارترین رخدادهای شناسایی‌شده است. Trend Micro

هدف این مقاله: کم‌کردن سطح حمله SSH تا حدی که عملاً “حدس‌زدن پسورد” بی‌معنا شود.

خروجی مطلوب (Definition of Done)

اگر این موارد برقرار باشد، SSH شما در سطح “Production-Ready” است:

• فقط با SSH Key وارد می‌شوید (پسورد کاملاً بسته است)
• Root از طریق SSH وارد نمی‌شود
• فقط کاربران/گروه‌های مشخص اجازه ورود دارند
• تلاش‌های مکرر ناموفق rate-limit/ban می‌شوند
• لاگ‌ها قابل رصد و مانیتور هستند

گام‌های اجرایی (بدون کلی‌گویی)

0) قبل از هر چیزی: ضد قفل‌شدن (Anti Lockout)

1. مطمئن شوید کنسول اضطراری دارید (console / web VNC / recovery mode)
2. یک کاربر غیر-root بسازید و sudo بدهید. (این “بهترین‌پرکتیس” رایج در سخت‌سازی است) Frank’s Blog
3. اول کلید را اضافه کنید و تست کنید، بعد پسورد را ببندید. (هشدار رایج برای جلوگیری از قفل شدن) Ask Ubuntu

1) تنظیمات کلیدی sshd_config برای Keys-only

فایل‌های تنظیمات را درست پیدا کنید:

• در اوبونتوهای جدید معمولاً این مسیر وجود دارد:
  /etc/ssh/sshd_config
  و همچنین پوشه‌ی include:
  /etc/ssh/sshd_config.d/*.conf

نکته مهم (دام رایج): cloud-init می‌تواند تنظیمات را Override کند

روی خیلی از VPSها/Cloud VMها یک فایل مثل زیر ممکن است تنظیم شما را برگرداند:
/etc/ssh/sshd_config.d/50-cloud-init.conf
و حتی اگر شما در sshd_config مقدار را تغییر دهید، نتیجه همان قبلی بماند. Ask Ubuntu+2GitHub+2

پس تنظیمات را در فایل درست (یا همان 50-cloud-init.conf) اعمال کنید.

حداقل کانفیگ پیشنهادی

در یکی از فایل‌های فعال sshd (ترجیحاً یک فایل جدا مثل 99-hardening.conf در sshd_config.d) این‌ها را قرار دهید:

PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

PubkeyAuthentication yes
PermitRootLogin no

MaxAuthTries 3
LoginGraceTime 30

AllowUsers youruser
X11Forwarding no

سپس:

• sshd -t برای چک صحت کانفیگ
• ری‌استارت سرویس SSH

منطق امنیتی “بستن root login از طریق SSH” در بنچمارک‌های سخت‌سازی مثل CIS هم به‌عنوان کنترل توصیه‌شده آمده است. Anarcho Copy

2) لایه ضد Brute Force: Fail2Ban (در صورت نیاز)

اگر شما (یا تیم‌تان) مجبورید هنوز برای بعضی کاربران “پسورد” را نگه دارید، یا IP محدودسازی ندارید، Fail2Ban می‌تواند تلاش‌های تکراری را ban کند. راهنمای عملی آن در منابع ارائه‌دهندگان زیرساخت هم وجود دارد. Akamai

حداقل کاری که انجام می‌دهد:

• لاگ‌های SSH را می‌خواند
• اگر X بار تلاش ناموفق دید → IP را برای مدت مشخص مسدود می‌کند

3) ارتقای سطح امنیت: کلید سخت‌افزاری FIDO2 برای SSH (اختیاری ولی عالی)

اگر می‌خواهید یک گام جلوتر بروید: کلیدهای امنیتی U2F/FIDO در OpenSSH پشتیبانی می‌شوند و می‌توانند “کلید خصوصی سخت‌افزاری” بدهند (یعنی حتی اگر لپ‌تاپ آلوده شود، سرقت کلید سخت‌تر می‌شود). خود OpenSSH این قابلیت را مستند کرده است. GitHub+1

این گزینه مخصوصاً برای ادمین‌ها و دسترسی‌های حساس ارزشمند است.

4) تست سریع (همان روز اجرا کنید)

• از یک ترمینال جدید وارد شوید و مطمئن شوید با کلید کار می‌کند
• تلاش کنید با پسورد وارد شوید → باید رد شود
• تلاش کنید با root وارد شوید → باید رد شود
• لاگ‌ها را چک کنید و مطمئن شوید پیام‌ها ثبت می‌شوند