امن‌سازی دسترسی SSH به سرور لینوکس: کلید، غیرفعال کردن رمز عبور، fail2ban و تنظیمات sshd_config

SSH معمولاً اصلی‌ترین مسیر مدیریت یک سرور لینوکس است. همین دسترسی، از چند دقیقه پس از قرار گرفتن سرور روی اینترنت، هدف اسکن خودکار، آزمون رمزهای عبور افشاشده و حملات brute-force قرار می‌گیرد. وجود رمز قوی مفید است، اما به‌تنهایی روش مناسبی برای محافظت از یک سرویس مدیریتی عمومی نیست. برای امن‌سازی SSH در سرور لینوکس باید چند لایه دفاعی ایجاد کنیم: ورود با کلید را جایگزین رمز عبور کنیم، ورود مستقیم کاربر root را ببندیم، فقط کاربران لازم را مجاز بدانیم، تنظیمات سرویس را با احتیاط سخت‌گیرانه‌تر کنیم و با fail2ban سرعت حملات تکراری را کاهش دهیم.

در این راهنما فرض می‌کنیم به سرور دسترسی sudo دارید. هنگام انجام تغییرات، نشست فعلی SSH را باز نگه دارید و پیش از خروج، ورود از یک ترمینال دوم را آزمایش کنید. یک اشتباه کوچک در تنظیمات می‌تواند دسترسی راه دور را قطع کند؛ به‌خصوص اگر کنسول اضطراری ارائه‌دهنده در دسترس نباشد.

پیش از تغییر تنظیمات SSH

ابتدا یک نسخه پشتیبان از فایل تنظیمات بگیرید:

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

مسیر برنامه و نام سرویس ممکن است میان توزیع‌ها متفاوت باشد. در Ubuntu و Debian معمولاً سرویس ssh است، اما در Rocky Linux، AlmaLinux، CentOS و Fedora اغلب sshd نام دارد:

sudo systemctl status ssh
sudo systemctl status sshd

نسخه OpenSSH را نیز بررسی کنید:

ssh -V

بعضی گزینه‌ها به نسخه OpenSSH وابسته‌اند. به همین دلیل، کپی کردن یک فایل آماده از اینترنت بدون بررسی نسخه سیستم کار درستی نیست. اگر هنوز فقط با root وارد می‌شوید، قبل از بستن این دسترسی یک کاربر مدیریتی بسازید. در Debian و Ubuntu می‌توانید بنویسید:

sudo adduser adminuser
sudo usermod -aG sudo adminuser

در توزیع‌های خانواده RHEL، گروه مدیریتی معمولاً wheel است:

sudo useradd -m adminuser
sudo passwd adminuser
sudo usermod -aG wheel adminuser

نامی مثل adminuser صرفاً نمونه است. انتخاب نام غیرقابل‌حدس جای کنترل‌های امنیتی اصلی را نمی‌گیرد، اما استفاده از نامی متناسب با سیاست سازمان بهتر از ایجاد حساب‌های مشترک است.

ساخت کلید Ed25519 برای ورود به سرور

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

ssh-keygen -t ed25519 -a 100 -C "admin@example.com"

پارامتر -a 100 تعداد دورهای تابع مشتق‌سازی کلید را برای محافظت از فایل خصوصی افزایش می‌دهد. برای کلید خصوصی یک passphrase مناسب تعیین کنید. این عبارت در صورت سرقت فایل کلید، لایه محافظ دیگری ایجاد می‌کند. مسیر پیش‌فرض کلیدها معمولاً چنین است:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

فایل بدون پسوند، کلید خصوصی است و نباید برای فرد دیگری ارسال یا روی سرور بارگذاری شود. فقط محتوای فایل دارای پسوند .pub باید در اختیار سرور قرار بگیرد.

انتقال کلید عمومی به سرور

اگر ورود رمزی هنوز فعال است، ساده‌ترین راه استفاده از ssh-copy-id است:

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

در سیستم‌هایی که ssh-copy-id ندارند، کلید عمومی را به فایل زیر در حساب مقصد اضافه کنید:

/home/adminuser/.ssh/authorized_keys

مجوزهای نادرست ممکن است باعث رد شدن کلید شوند. روی سرور این مقادیر را تنظیم کنید:

sudo chown -R adminuser:adminuser /home/adminuser/.ssh
sudo chmod 700 /home/adminuser/.ssh
sudo chmod 600 /home/adminuser/.ssh/authorized_keys

اکنون در یک ترمینال جدید اتصال را آزمایش کنید:

ssh -i ~/.ssh/id_ed25519 adminuser@SERVER_IP

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

مقایسه روش‌های ورود به SSH

هر روش ورود ریسک و کاربرد متفاوتی دارد. جدول زیر برای یک سرور متصل به اینترنت، وضعیت رایج گزینه‌ها را نشان می‌دهد.

روش ورود	مقاومت در برابر brute-force	ریسک اصلی	پیشنهاد
رمز عبور	کم تا متوسط	رمز ضعیف، تکراری یا افشاشده	برای مدیریت عمومی غیرفعال شود
کلید بدون passphrase	زیاد	استفاده مستقیم از فایل خصوصی سرقت‌شده	فقط برای سناریوهای خودکار با محدودیت دقیق
کلید Ed25519 با passphrase	زیاد	آلودگی دستگاه کاربر یا افشای نشست agent	گزینه مناسب برای مدیران
کلید سخت‌افزاری FIDO2	بسیار زیاد	گم شدن توکن و نداشتن روش بازیابی	مناسب دسترسی‌های حساس

کلید SSH امنیت دستگاه کاربر را بی‌اهمیت نمی‌کند. فایل‌های خصوصی باید با مجوز مناسب نگهداری شوند و بهتر است دیسک دستگاه نیز رمزگذاری شده باشد.

تنظیم امن فایل sshd_config

فایل اصلی معمولاً /etc/ssh/sshd_config است. در نسخه‌های جدید ممکن است فایل‌های داخل /etc/ssh/sshd_config.d/ نیز بارگذاری شوند. خروجی تنظیمات مؤثر را می‌توان با دستور زیر دید:

sudo sshd -T

این موضوع مهم است، چون یک گزینه ممکن است در فایل دیگری تعریف شده باشد. همچنین جای قرار گرفتن دستورهای Match اهمیت دارد؛ گزینه‌های عمومی را ناخواسته زیر یک بلوک Match ننویسید. نمونه زیر نقطه شروع مناسبی است، اما باید با نسخه OpenSSH، کاربران مجاز و نیازهای عملیاتی سرور تطبیق داده شود:

Port 22
Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AllowUsers adminuser deploy
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 4
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE

بستن ورود مستقیم root

گزینه زیر ورود SSH با حساب root را به‌طور کامل می‌بندد:

PermitRootLogin no

مدیر سیستم باید با حساب شخصی خود وارد شود و برای عملیات مدیریتی از sudo استفاده کند. با این کار فعالیت‌ها بهتر ثبت می‌شوند و نام کاربری root از مسیر ورود حذف می‌شود. اگر یک سامانه خودکار فعلاً به ورود root با کلید وابسته است، ابتدا وابستگی را اصلاح کنید. گزینه prohibit-password ورود رمزی root را می‌بندد ولی همچنان ورود کلیدی را می‌پذیرد؛ این وضعیت می‌تواند یک مرحله گذار باشد، نه الزاماً پیکربندی نهایی.

غیرفعال کردن ورود با رمز

پس از تأیید ورود کلیدی، این گزینه‌ها را تنظیم کنید:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

بستن PasswordAuthentication همیشه همه روش‌های مبتنی بر رمز را متوقف نمی‌کند. PAM و keyboard-interactive ممکن است مسیر جداگانه‌ای ایجاد کنند، بنابراین تنظیم مؤثر را با sshd -T بررسی کنید:

sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

محدود کردن کاربران مجاز

با AllowUsers فقط حساب‌های مشخص‌شده اجازه ورود دارند:

AllowUsers adminuser deploy

اگر تعداد کاربران بیشتر است، مدیریت یک گروه ساده‌تر خواهد بود:

AllowGroups ssh-users

سپس کاربران مجاز را به آن گروه اضافه کنید:

sudo groupadd ssh-users
sudo usermod -aG ssh-users adminuser

از تعریف هم‌زمان محدودیت‌های پیچیده AllowUsers، AllowGroups، DenyUsers و DenyGroups بدون مستندسازی خودداری کنید؛ عیب‌یابی ترکیب این قواعد دشوار می‌شود.

غیرفعال کردن قابلیت‌های غیرضروری

قابلیت‌هایی مانند agent forwarding، TCP forwarding، تونل و X11 کاربرد واقعی دارند. اگر از آن‌ها استفاده نمی‌کنید، غیرفعالشان کنید:

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

برای مثال، یک سرور bastion ممکن است به forwarding نیاز داشته باشد. در چنین شرایطی می‌توان قابلیت موردنیاز را فقط برای یک کاربر یا گروه و داخل بلوک Match فعال کرد.

آیا تغییر پورت SSH امنیت را افزایش می‌دهد؟

تغییر پورت پیش‌فرض، تعداد زیادی از اسکن‌های ساده و پیام‌های تکراری لاگ را کم می‌کند، اما جای کلید، فایروال یا غیرفعال کردن رمز عبور را نمی‌گیرد. مهاجم همچنان می‌تواند پورت‌های باز را پیدا کند. اگر تصمیم به تغییر پورت دارید، ابتدا پورت جدید را در فایروال و در صورت وجود در پنل شبکه ارائه‌دهنده باز کنید. برای نمونه با UFW:

sudo ufw allow 2222/tcp
sudo ufw status

سپس در تنظیمات SSH بنویسید:

Port 2222

در سیستم‌های دارای SELinux ممکن است لازم باشد پورت جدید برای نوع ssh_port_t مجاز شود:

sudo semanage port -a -t ssh_port_t -p tcp 2222

پس از موفقیت اتصال روی پورت جدید، قانون پورت قبلی را حذف کنید. اتصال بعدی چنین خواهد بود:

ssh -p 2222 adminuser@SERVER_IP

اعتبارسنجی و اعمال تنظیمات بدون قطع دسترسی

پیش از reload یا restart، صحت نحوی فایل را بررسی کنید:

sudo sshd -t

نبود خروجی معمولاً یعنی خطای نحوی پیدا نشده است. سپس تنظیمات را بدون قطع نشست‌های موجود reload کنید:

sudo systemctl reload ssh

یا در توزیع‌هایی با نام سرویس sshd:

sudo systemctl reload sshd

از یک ترمینال دوم وارد شوید و موارد زیر را آزمایش کنید: - ورود با کلید برای کاربر مجاز موفق باشد. - ورود رمزی پذیرفته نشود. - ورود مستقیم root رد شود. - sudo برای حساب مدیریتی کار کند. - در صورت تغییر پورت، اتصال روی پورت جدید برقرار شود. نشست اول را فقط پس از موفقیت همه آزمون‌ها ببندید. اگر سرویس بالا نیامد، وضعیت و لاگ‌ها را بررسی کنید:

sudo systemctl status sshd
sudo journalctl -u sshd --since "10 minutes ago"

نام واحد را در Debian یا Ubuntu در صورت نیاز به ssh تغییر دهید.

نصب و تنظیم fail2ban برای SSH

fail2ban گزارش‌های ورود ناموفق را بررسی می‌کند و آدرس‌هایی را که در یک بازه مشخص بیش از حد خطا دارند، موقتاً مسدود می‌کند. این ابزار اثر اسکن و brute-force را کم می‌کند، اما ضعف رمز یا پیکربندی اشتباه را جبران نمی‌کند. در Debian و Ubuntu:

sudo apt update
sudo apt install fail2ban

در توزیع‌های خانواده RHEL، بسته ممکن است از مخزن EPEL نصب شود:

sudo dnf install epel-release
sudo dnf install fail2ban

فایل توزیع‌شده jail.conf را مستقیم ویرایش نکنید، چون به‌روزرسانی بسته می‌تواند آن را تغییر دهد. یک فایل محلی بسازید:

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

نمونه تنظیم: ```ini