امن‌سازی SSH روی VPS لینوکس؛ راهنمای کامل افزایش امنیت در ۲۰۲۶

خلاصه سریع: برای امن‌سازی SSH روی VPS، اول یک کاربر sudo و ورود با کلید SSH را آماده و تست کنید؛ سپس ورود مستقیم root و احراز هویت با رمز عبور را غیرفعال کنید، دسترسی پورت SSH را با فایروال محدود کنید، Fail2Ban و مانیتورینگ لاگ‌ها را فعال کنید و قبل از هر reload حتماً sshd -t بزنید. تغییر پورت SSH می‌تواند نویز اسکن‌های خودکار را کم کند، اما جایگزین احراز هویت قوی و محدودسازی دسترسی نیست.

این راهنما برای کاربری نوشته شده که یک VPS لینوکسی در اختیار دارد و می‌خواهد بدون قطع دسترسی، تنظیمات SSH را مرحله‌به‌مرحله سخت‌گیرانه‌تر کند. تمرکز اصلی روی Ubuntu/Debian است، اما اصول برای AlmaLinux، Rocky Linux و سایر توزیع‌های مجهز به OpenSSH نیز مشابه است.

چک‌لیست سریع امن‌سازی SSH روی VPS

قبل از هر تغییر: راه برگشت را باز نگه دارید

بیشتر قطعی‌های SSH نه به‌خاطر حمله، بلکه به‌خاطر یک تغییر اشتباه در /etc/ssh/sshd_config رخ می‌دهند. قبل از شروع:

1. یک نشست SSH فعلی را باز نگه دارید.
2. اگر پنل VPS کنسول وب، VNC یا Rescue Console دارد، مطمئن شوید به آن دسترسی دارید.
3. از فایل تنظیمات SSH نسخه پشتیبان بگیرید:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

هر تغییر را ابتدا اعتبارسنجی کنید و فقط بعد از موفقیت، سرویس را reload کنید.

مرحله ۱: OpenSSH و سیستم‌عامل را به‌روز کنید

امن‌سازی کانفیگ روی نرم‌افزار قدیمی کافی نیست. در Ubuntu/Debian:

sudo apt update
sudo apt upgrade -y
ssh -V

در AlmaLinux/Rocky Linux:

sudo dnf update -y
ssh -V

توجه کنید بعضی توزیع‌ها وصله‌های امنیتی OpenSSH را backport می‌کنند؛ بنابراین فقط از روی شماره نسخه نتیجه نگیرید که بسته ناامن است. وضعیت امنیتی را با advisory همان توزیع بررسی کنید. اگر می‌خواهید درباره نسل جدید OpenSSH و تبادل کلیدهای جدید بیشتر بدانید، مقاله OpenSSH 10.5 و SSH پساکوانتومی مکمل خوبی برای این راهنماست.

مرحله ۲: یک کاربر مدیریتی جدا از root بسازید

مدیریت روزمره سرور با root مستقیم ریسک غیرضروری ایجاد می‌کند. یک کاربر معمولی بسازید و دسترسی sudo بدهید:

sudo adduser adminuser
sudo usermod -aG sudo adminuser

در توزیع‌های RHEL-base معمولاً گروه مدیریتی wheel است:

sudo usermod -aG wheel adminuser

قبل از بستن ورود root، ورود این کاربر و اجرای sudo -v را تست کنید.

مرحله ۳: ورود با SSH Key را فعال کنید

برای اغلب کاربران، کلید Ed25519 انتخاب مناسبی است:

ssh-keygen -t ed25519 -a 64

سپس کلید عمومی را روی VPS کپی کنید:

ssh-copy-id adminuser@SERVER_IP

اگر ssh-copy-id در دسترس نیست، محتوای فایل ~/.ssh/id_ed25519.pub را در فایل ~/.ssh/authorized_keys کاربر مقصد قرار دهید و permissionها را درست کنید:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

حالا در یک ترمینال دوم ورود با کلید را تست کنید. تا وقتی این مرحله موفق نشده، رمز عبور را غیرفعال نکنید.

مرحله ۴: ورود root و پسورد را غیرفعال کنید

فایل تنظیمات را باز کنید:

sudo nano /etc/ssh/sshd_config

برای یک VPS معمولی که ورود با کلید تست شده، این تنظیمات پایه مناسب‌اند:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
MaxAuthTries 3
LoginGraceTime 30

نکته مهم: اگر از MFA، PAM یا روش‌های تعاملی استفاده می‌کنید، گزینه‌هایی مثل KbdInteractiveAuthentication را بدون بررسی غیرفعال نکنید. هدف امن‌سازی است، نه شکستن جریان احراز هویت.

مرحله ۵: کاربران مجاز را محدود کنید

اگر فقط یک یا چند حساب مشخص باید به SSH دسترسی داشته باشند، می‌توانید از AllowUsers استفاده کنید:

AllowUsers adminuser deploy

یا برای سناریوهای تیمی از AllowGroups استفاده کنید. این کار جلوی تلاش برای ورود با حساب‌های محلی غیرضروری را می‌گیرد.

مرحله ۶: دسترسی شبکه به SSH را با فایروال کنترل کنید

در Ubuntu با UFW، اگر SSH روی پورت 22 است:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

اگر IP مدیریتی ثابتی دارید، محدودسازی به همان IP بسیار مؤثرتر است:

sudo ufw allow from YOUR_PUBLIC_IP to any port 22 proto tcp

قبل از حذف Rule عمومی مطمئن شوید Rule محدود جدید کار می‌کند. در سرورهایی که چند مدیر با IPهای پویا دارند، VPN مدیریتی، WireGuard یا راهکارهای Zero Trust می‌تواند انتخاب بهتری باشد.

آیا تغییر پورت SSH امنیت را بالا می‌برد؟

به‌تنهایی نه. انتقال SSH از پورت 22 به یک پورت دیگر معمولاً تعداد اسکن‌های رباتیک و لاگ‌های brute-force را کمتر می‌کند، اما مهاجم می‌تواند پورت‌های باز را اسکن کند. بنابراین تغییر پورت را فقط یک لایه کمکی برای کاهش نویز بدانید، نه کنترل امنیتی اصلی.

اگر پورت را تغییر می‌دهید، ابتدا Rule فایروال پورت جدید را باز کنید، سپس sshd_config را تغییر دهید و بعد از تست، پورت قبلی را ببندید. راهنمای قدیمی‌تر تغییر پورت SSH در لینوکس نیز این بخش را پوشش می‌دهد.

مرحله ۷: Fail2Ban را برای حملات brute-force فعال کنید

Fail2Ban لاگ‌های سیستم را بررسی می‌کند و IPهایی را که رفتار مشکوک تکراری دارند، موقتاً مسدود می‌کند. در Ubuntu/Debian:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

به‌جای ویرایش فایل پیش‌فرض، یک فایل local بسازید:

sudo nano /etc/fail2ban/jail.d/sshd.local

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

سپس:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

اگر SSH روی پورت سفارشی است، تنظیمات Fail2Ban و فایروال را با پورت واقعی هماهنگ کنید.

مرحله ۸: قابلیت‌هایی را که نیاز ندارید محدود کنید

هر قابلیت اضافه‌ای که واقعاً استفاده نمی‌کنید، می‌تواند سطح حمله یا ریسک سوءاستفاده را بیشتر کند. در سناریوهای ساده می‌توانید موارد زیر را بررسی کنید:

X11Forwarding no
AllowAgentForwarding no

اما AllowTcpForwarding را فقط زمانی غیرفعال کنید که مطمئنید تونل SSH، توسعه از راه دور، بکاپ، CI/CD یا ابزارهای مدیریتی شما به آن نیاز ندارند.

مرحله ۹: لاگ‌های SSH را مانیتور کنید

در Ubuntu/Debian:

sudo journalctl -u ssh --since "24 hours ago"
sudo grep -E "Failed password|Invalid user|Accepted" /var/log/auth.log | tail -n 100

در بعضی توزیع‌ها سرویس sshd و فایل لاگ /var/log/secure استفاده می‌شود:

sudo journalctl -u sshd --since "24 hours ago"
sudo tail -n 100 /var/log/secure

افزایش ناگهانی تلاش‌های ورود، ورود از کشور یا IP غیرمنتظره و حساب‌هایی که نباید SSH داشته باشند، نشانه‌هایی هستند که باید بررسی شوند.

مرحله ۱۰: کانفیگ را بدون ریسک اعتبارسنجی و reload کنید

این مرحله را هیچ‌وقت حذف نکنید:

sudo sshd -t

اگر خروجی ندارد، syntax معمولاً معتبر است. بعد سرویس را reload کنید:

sudo systemctl reload ssh

یا در برخی توزیع‌ها:

sudo systemctl reload sshd

حالا نشست فعلی را نبندید. یک ترمینال دوم باز کنید و با کاربر جدید و کلید SSH وارد شوید. فقط بعد از موفقیت تست، نشست قبلی را ببندید.

یک نمونه کانفیگ امن برای VPS

این نمونه نقطه شروع است، نه نسخه مناسب برای همه سرورها:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers adminuser

اگر سرویس‌های اتوماسیون، GitHub Actions، بکاپ یا مانیتورینگ از SSH استفاده می‌کنند، قبل از سخت‌گیری بیشتر سازگاری آن‌ها را تست کنید. برای همین سناریو، راهنمای استقرار خودکار روی VPS با GitHub Actions و SSH را هم ببینید.

برای چه VPSهایی این سخت‌گیری مهم‌تر است؟

اگر VPS شما مستقیماً روی اینترنت است، پنل مدیریتی، API، دیتابیس، سایت فروشگاهی یا سرویس سازمانی میزبانی می‌کند، SSH یکی از حساس‌ترین نقاط ورود است. در چنین محیطی داشتن زیرساخت پایدار، snapshot/backup، کنسول اضطراری و کنترل شبکه اهمیت بیشتری پیدا می‌کند. اگر در حال راه‌اندازی سرور جدید هستید، می‌توانید پلن‌های خرید سرور مجازی وان سرور را بررسی کنید و از همان روز اول SSH را با کلید، فایروال و دسترسی محدود پیکربندی کنید.

اشتباهات رایج در امن‌سازی SSH

• بستن نشست فعلی قبل از تست نشست دوم: رایج‌ترین راه قفل کردن خودتان بیرون از سرور.
• غیرفعال کردن PasswordAuthentication قبل از تست کلید: ممکن است هیچ روش ورود فعالی باقی نماند.
• اعتماد بیش از حد به تغییر پورت: پورت غیرپیش‌فرض فقط نویز را کم می‌کند.
• بستن Forwarding بدون بررسی: می‌تواند توسعه، بکاپ یا CI/CD را مختل کند.
• نداشتن کنسول اضطراری: قبل از تغییرات شبکه و SSH باید راه بازیابی خارج از SSH داشته باشید.
• نادیده گرفتن لاگ‌ها: امن‌سازی فقط کانفیگ نیست؛ مشاهده‌پذیری هم بخشی از امنیت است.

جمع‌بندی

امن‌سازی SSH روی VPS یک تنظیم جادویی ندارد. ترکیب SSH Key، حذف ورود مستقیم root، غیرفعال کردن رمز عبور، فایروال، Fail2Ban، به‌روزرسانی و مانیتورینگ لاگ‌ها لایه‌های اصلی دفاع را می‌سازد. مهم‌تر از همه، هر تغییر را مرحله‌ای انجام دهید: یک نشست باز نگه دارید، کانفیگ را با sshd -t بررسی کنید، در نشست دوم تست ورود بگیرید و بعد محدودیت بعدی را اعمال کنید.

منابع

• Ubuntu Server Documentation — OpenSSH Server
• OpenBSD Manual — sshd_config
• Fail2Ban Project