برای امن‌سازی SSH در لینوکس، چند تنظیم در فایل /etc/ssh/sshd_config بیشترین اثر را دارند: ورود root را ببندید، ورود با رمز را بعد از نصب کلید خاموش کنید، کاربران مجاز را مشخص کنید و تعداد تلاش‌های ورود را محدود کنید. بعد از هر تغییر، کانفیگ را با sshd -t تست کنید و قبل از بستن نشست فعلی، یک نشست دوم باز کنید تا اگر اشتباهی شد، از سرور بیرون نمانید.
SSH معمولاً اولین سرویسی است که ربات‌ها روی هر سرور جدید امتحان می‌کنند. لاگ سروری که روی اینترنت است، ساعت‌ها بعد از راه‌اندازی پر از تلاش‌های ورود ناموفق است. این تلاش‌ها خودشان خطرناک نیستند، ولی رمز ضعیف و ورود root با رمز راه آسان نفوذ را باز می‌کند. دیگر لایه‌های امنیتی سرور در چک لیست امنیت سرور لینوکس آمده است.
پیش از امن‌سازی SSH: دو قانون ایمنی
- همیشه یک نشست SSH باز را نگه دارید و تنظیم جدید را در نشست دیگر امتحان کنید. اگر بعد از تغییر نتوانستید وارد شوید، نشست قدیمی هنوز برای اصلاح در دسترس است.
- کنسول سرور را از پنل ارائه‌دهنده در دسترس داشته باشید. اگر قفل شدید، تنها راه برگشت همین است.
فایل را پیش از ویرایش نسخه‌برداری کنید:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakدر Ubuntu 22.04 به بعد، تنظیم‌های سفارشی را بهتر است در فایل جداگانه‌ای زیر /etc/ssh/sshd_config.d/ با پسوند conf بنویسید، چون فایل اصلی دست نمی‌خورد و در به‌روزرسانی‌ها بازنویسی نمی‌شود. مثال: /etc/ssh/sshd_config.d/99-hardening.conf. توجه کنید که برای بیشتر تنظیم‌ها، مقدار اولین جایی که خوانده شود معتبر است و فایل‌های این پوشه پیش از ادامه کانفیگ اصلی خوانده می‌شوند.
مرحله اول: نصب کلید و ورود با آن
پیش از بستن ورود با رمز، باید ورود با کلید کار کند. ساخت کلید و نصب آن روی سرور در آموزش SSH Key آمده است. با کلید از یک نشست تازه وارد شوید و مطمئن شوید بدون رمز کار می‌کند.
مرحله دوم: تنظیم‌های اصلی امن‌سازی SSH
این تنظیم‌ها را در فایل hardening بنویسید:
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy admin
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2معنی هر کدام:
| تنظیم | اثر |
|---|---|
PermitRootLogin no | ورود مستقیم root را می‌بندد؛ با کاربر معمولی وارد شوید و sudo بگیرید |
PasswordAuthentication no | ورود با رمز را می‌بندد و فقط کلید قبول می‌شود |
KbdInteractiveAuthentication no | روش رمز تعاملی را هم می‌بندد تا ورود با رمز از راه دیگر ممکن نباشد |
MaxAuthTries 3 | تعداد تلاش ناموفق در هر اتصال |
LoginGraceTime 30 | مهلت تکمیل ورود به ثانیه |
AllowUsers | فقط این کاربران اجازه ورود دارند؛ نام‌ها را با کاربران خودتان عوض کنید |
X11Forwarding no | انتقال محیط گرافیکی را که روی سرور لازم نیست می‌بندد |
ClientAliveInterval و ClientAliveCountMax | نشست بی‌حرکت را بعد از مدتی قطع می‌کند |
اگر روی سرور کاربر معمولی با دسترسی sudo ندارید، تنظیم PermitRootLogin no را قبل از ساخت چنین کاربری نزنید. در AllowUsers نام کاربر واقعی خودتان باشد، وگرنه خودتان هم رد می‌شوید.
مرحله سوم: تست و اعمال
sudo sshd -t
sudo systemctl reload sshدستور sshd -t خطاهای نگارشی را نشان می‌دهد و اگر چیزی ننوشت، فایل درست است. نام سرویس در Ubuntu و Debian برابر ssh و در AlmaLinux و Rocky برابر sshd است. حالا بدون بستن نشست فعلی، از یک ترمینال دوم وارد شوید. اگر موفق بود، تنظیم درست اعمال شده است. برای دیدن مقدار نهایی هر تنظیم:
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers'تغییر پورت SSH
عوض کردن پورت از 22 به عدد دیگر، تعداد تلاش‌های ربات‌ها در لاگ را کم می‌کند، ولی امنیت واقعی نمی‌آورد: اسکنر پورت‌های دیگر را هم می‌بیند. اگر پورت را عوض می‌کنید:
Port 2222پیش از reload، پورت جدید را در فایروال باز کنید و پورت قدیمی را فعلاً نگه دارید تا مطمئن شوید با پورت جدید وارد می‌شوید. در لینوکس با SELinux، مثل AlmaLinux، پورت جدید را باید به SELinux هم معرفی کنید: sudo semanage port -a -t ssh_port_t -p tcp 2222. روش‌های ساخت قانون فایروال در مدیریت فایروال آمده است.
محدود کردن به IP مجاز
اگر IP ثابت دفتر یا VPN دارید، بهترین حالت این است که SSH فقط از همان آدرس‌ها قابل دسترسی باشد. این کار را در فایروال انجام دهید و در صورت نیاز در sshd_config هم:
Match Address 203.0.113.0/24
PasswordAuthentication noبخش Match تنظیم‌ها را فقط برای شرایط مشخص عوض می‌کند. آدرس نمونه است. دسترسی به SSH از یک شبکه مدیریتی یا VPN، جلوی بسیاری از تلاش‌های بیرونی را از پایه می‌گیرد.
بستن حدس رمز با Fail2ban
حتی با خاموش بودن رمز، ربات‌ها تلاش می‌کنند و لاگ را پر می‌کنند. Fail2ban آدرس‌هایی را که چند بار شکست می‌خورند موقتاً مسدود می‌کند. راه‌اندازی آن در نصب و تنظیم Fail2ban آمده است. وقتی ورود با رمز بسته است، Fail2ban بیشتر نویز لاگ را کم می‌کند و اثر امنیتی اصلی را کلید و فایروال می‌دهند.
بررسی لاگ ورودها
sudo journalctl -u ssh --since "1 hour ago"
sudo grep "Failed password" /var/log/auth.log | tail
last -a | headدر توزیع‌هایی که فایل /var/log/auth.log ندارند، از journalctl استفاده کنید. ورودهای موفق از آدرس‌هایی که نمی‌شناسید نشانه جدی‌تری از تلاش‌های ناموفق ربات‌هاست؛ اگر چنین چیزی دیدید، به رفع هک و پاک‌سازی مالور مراجعه کنید.
خطاهای رایج
| نشانه | علت و راه حل |
|---|---|
Permission denied (publickey) | کلید نصب نیست، دسترسی ~/.ssh نادرست است یا کاربر در AllowUsers نیست |
| بعد از reload نمی‌توانم وارد شوم | تنظیم اشتباه؛ از نشست قدیمی فایل را برگردانید یا از کنسول سرور وارد شوید |
sshd -t خطا می‌دهد | خطای نگارشی در تنظیم؛ پیام شماره خط را نشان می‌دهد |
| تنظیم اثر ندارد | مقدار دیگری زودتر خوانده شده؛ sshd -T مقدار نهایی را نشان می‌دهد |
| کلید قبول نمی‌شود | دسترسی ~/.ssh باید 700 و authorized_keys باید 600 باشد |
سوالات متداول
آیا بستن ورود root لازم است؟
بله، توصیه می‌شود. با کاربر معمولی وارد شوید و با sudo کار کنید. اینجوری نام کاربری هدف هم برای مهاجم حدس‌زدنی نیست و ورودها قابل ردیابی‌ترند.
اگر کلیدم را گم کنم چه می‌شود؟
اگر ورود با رمز بسته است و کلید دیگری ندارید، فقط کنسول سرور از پنل ارائه‌دهنده کمک می‌کند. بنابراین کلید را بکاپ بگیرید و دست‌کم دو کلید معتبر روی سرور نگه دارید.
تفاوت reload و restart برای SSH چیست؟
reload کانفیگ جدید را بدون قطع نشست‌های فعلی می‌خواند و برای تغییر تنظیم‌ها کافی است. restart هم معمولاً نشست‌های فعلی را قطع نمی‌کند، ولی reload ایمن‌تر است.
آیا احراز هویت دومرحله‌ای را می‌شود برای SSH فعال کرد؟
بله، با ماژول‌هایی مثل Google Authenticator PAM. این کار پیچیدگی بیشتری دارد و باید با دقت و با کنسول در دسترس انجام شود.
