راهنمای امن‌سازی SSH لینوکس (۲۰۲۶)

مقدمه: چرا امن‌سازی SSH در سال ۲۰۲۶ بیش از هر زمانی حیاتی است؟

خب، بیایید رک باشیم — SSH ستون فقرات مدیریت سرورهای لینوکس است. تقریباً هر سروری که روی اینترنت هست، یک سرویس SSH دارد که منتظر اتصال مدیر سیستم نشسته. و دقیقاً همین موضوع SSH را تبدیل کرده به یکی از اولین اهدافی که مهاجمان سراغش می‌روند. طبق آمار سال ۲۰۲۵، بیش از ۱۵ میلیون حمله brute-force روزانه علیه سرویس‌های SSH در سراسر جهان ثبت شده. بله، روزانه!

اما تهدیدات فقط به حملات brute-force محدود نمی‌شوند. ظهور محاسبات کوانتومی یک تهدید جدید و — صادقانه بگویم — نگران‌کننده ایجاد کرده: حملات «الان ذخیره کن، بعداً رمزگشایی کن» (Harvest Now, Decrypt Later). ایده‌اش ساده ولی ترسناک است: مهاجمان ترافیک SSH رمزنگاری‌شده شما را الان ضبط می‌کنند و صبر می‌کنند تا کامپیوترهای کوانتومی به اندازه کافی قدرتمند بشوند تا آن را رمزگشایی کنند. تخمین‌ها می‌گویند این اتفاق تا اواسط دهه ۲۰۳۰ محتمل است.

خبر خوب این‌ است که OpenSSH 10.0 (منتشرشده آوریل ۲۰۲۵) و OpenSSH 10.1 (منتشرشده اکتبر ۲۰۲۵) ابزارهای لازم برای مقابله با این تهدیدات را در اختیارمان گذاشته‌اند. از رمزنگاری پساکوانتومی پیش‌فرض گرفته تا پشتیبانی بهبودیافته از کلیدهای سخت‌افزاری FIDO2.

در این راهنما، یک مسیر عملی و گام‌به‌گام برای امن‌سازی کامل SSH در سال ۲۰۲۶ ارائه می‌دهیم — از تنظیمات پایه‌ای که هر مدیر سیستم باید بداند، تا پیکربندی‌های پیشرفته‌ای مثل رمزنگاری پساکوانتومی، احراز هویت سخت‌افزاری FIDO2 و گواهی‌نامه‌های SSH با طول عمر کوتاه. پس بیایید شروع کنیم.

تنظیمات پایه‌ای امن‌سازی SSH

قبل از اینکه سراغ موضوعات پیشرفته برویم، بیایید مطمئن شویم که تنظیمات پایه‌ای sshd_config درست انجام شده. شاید وسوسه‌تان بشود که مستقیم بروید سراغ رمزنگاری پساکوانتومی، ولی این تنظیمات ساده به‌تنهایی بیش از ۹۹ درصد حملات خودکار را خنثی می‌کنند. جدی می‌گویم.

غیرفعال‌سازی ورود root و احراز هویت رمز عبور

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

# غیرفعال‌سازی ورود root
PermitRootLogin no

# غیرفعال‌سازی احراز هویت رمز عبور
PasswordAuthentication no

# غیرفعال‌سازی رمز عبور خالی
PermitEmptyPasswords no

# فعال‌سازی احراز هویت مبتنی بر کلید عمومی
PubkeyAuthentication yes

# محدود کردن تعداد تلاش‌های احراز هویت
MaxAuthTries 3

# قطع جلسات بیکار پس از ۱۵ دقیقه
ClientAliveInterval 300
ClientAliveCountMax 3

یک هشدار مهم: قبل از غیرفعال کردن احراز هویت رمز عبور، حتماً مطمئن شوید که احراز هویت مبتنی بر کلید به‌درستی کار می‌کند. این کار را در یک ترمینال جداگانه تست کنید — وگرنه واقعاً از سرور خودتان قفل می‌شوید! (این اشتباهی است که تقریباً هر مدیر سیستمی حداقل یک بار مرتکبش شده.)

محدود کردن دسترسی به کاربران خاص

اصل حداقل دسترسی (Principle of Least Privilege) ساده است: فقط کاربرانی که واقعاً نیاز دارند باید بتوانند از SSH استفاده کنند. نه بیشتر.

# فقط این کاربران اجازه اتصال SSH دارند
AllowUsers deployer admin sysops

# یا محدود کردن بر اساس گروه
AllowGroups ssh-users

تغییر پورت پیش‌فرض و محدودسازی شبکه

یک بحث قدیمی و همیشگی: آیا تغییر پورت SSH از ۲۲ فایده‌ای دارد؟ جواب کوتاه: بله، ولی نه به‌عنوان «امنیت از طریق ابهام» — بلکه به‌عنوان کاهش نویز. واقعیت این است که بیش از ۹۰ درصد ربات‌های اسکن فقط پورت ۲۲ را بررسی می‌کنند:

# تغییر پورت SSH
Port 2222

# محدود کردن به آدرس IP خاص (اگر ممکن باشد)
ListenAddress 10.0.1.5

بعد از تغییر پورت، فراموش نکنید فایروال را هم به‌روزرسانی کنید:

# با استفاده از nftables
sudo nft add rule inet filter input tcp dport 2222 accept

# یا با UFW
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp

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

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

# بررسی صحت فایل پیکربندی
sudo sshd -t

# ریستارت سرویس
sudo systemctl restart sshd

# بررسی وضعیت سرویس
sudo systemctl status sshd

تولید و مدیریت کلیدهای SSH مدرن

نوع کلید SSH که استفاده می‌کنید واقعاً اهمیت دارد. در سال ۲۰۲۶، Ed25519 انتخاب پیش‌فرض و توصیه‌شده است. کلیدهای DSA به‌طور کامل از OpenSSH 10.0 حذف شده‌اند (بالاخره!) و کلیدهای RSA کمتر از ۳۰۷۲ بیت هم دیگر قابل‌قبول نیستند.

تولید کلید Ed25519

# تولید کلید Ed25519 — توصیه‌شده برای سال ۲۰۲۶
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519

# اگر به سازگاری با سیستم‌های قدیمی نیاز دارید — RSA 4096
ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/id_rsa

چرا Ed25519؟

اگر هنوز از RSA استفاده می‌کنید، وقتش رسیده که سوییچ کنید. دلایلش:

سریع‌تر: تولید و تأیید کلید بسیار سریع‌تر از RSA است
کوچک‌تر: کلید ۲۵۶ بیتی Ed25519 امنیتی معادل RSA 3072 بیتی دارد
امن‌تر: پیاده‌سازی ساده‌تر یعنی فرصت کمتر برای حملات کانال جانبی
مقاوم در برابر حملات زمان‌بندی: طراحی Ed25519 ذاتاً در برابر timing attacks مقاوم است

پیکربندی الگوریتم‌های مجاز روی سرور

در فایل sshd_config، الگوریتم‌های ضعیف را حذف و فقط الگوریتم‌های قوی را مجاز کنید:

# فقط کلیدهای Ed25519 و RSA قوی پذیرفته شوند
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# حداقل اندازه کلید RSA
RequiredRSASize 3072

# رمزنگاری‌های مجاز — AES-GCM اولویت دارد (تغییر OpenSSH 10.0)
Ciphers [email protected],[email protected],[email protected]

# الگوریتم‌های MAC
MACs [email protected],[email protected]

نکته: یکی از تغییرات مهم OpenSSH 10.0 این است که AES-GCM حالا بر AES-CTR ترجیح داده می‌شود. AES-GCM هم رمزنگاری و هم تأیید اصالت را در یک مرحله انجام می‌دهد — هم سریع‌تر، هم امن‌تر. یک تیر و دو نشان.

رمزنگاری پساکوانتومی با OpenSSH 10.0

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

تهدید «الان ذخیره کن، بعداً رمزگشایی کن» چیست؟

کل محرمانگی یک اتصال SSH به توافق کلید (Key Exchange) بستگی دارد. اگر مهاجم بتواند این توافق را بشکند، می‌تواند کل جلسه را رمزگشایی و مشاهده کند.

نکته ترسناک اینجاست: مهاجم نیازی نیست این کار را در لحظه انجام بدهد. می‌تواند جلسات رمزنگاری‌شده SSH شما را الان ضبط کند و هر وقت کامپیوتر کوانتومی در دسترس قرار گرفت، آنها را رمزگشایی کند. فکرش را بکنید — تمام دستوراتی که الان روی سرور می‌زنید، ممکن است ۱۰ سال بعد قابل مشاهده باشند.

الگوریتم mlkem768x25519-sha256

OpenSSH از نسخه ۹.۰ (آوریل ۲۰۲۲) رمزنگاری پساکوانتومی را ارائه کرده — ابتدا با sntrup761x25519-sha512. بعد در OpenSSH 9.9 الگوریتم جدید mlkem768x25519-sha256 اضافه شد و حالا در OpenSSH 10.0 به الگوریتم پیش‌فرض تبدیل شده.

این الگوریتم یک رویکرد ترکیبی (hybrid) دارد:

ML-KEM-768: الگوریتم پساکوانتومی استاندارد NIST (FIPS 203) بر اساس مسئله Learning with Errors — مقاوم در برابر حملات کوانتومی
X25519: الگوریتم کلاسیک Elliptic Curve Diffie-Hellman — اثبات‌شده و مورد اعتماد

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

بررسی پشتیبانی سرور

قبل از هر کاری، ببینید نسخه OpenSSH شما از این الگوریتم پشتیبانی می‌کند یا نه:

# بررسی نسخه OpenSSH
ssh -V

# مشاهده الگوریتم‌های Key Exchange پشتیبانی‌شده
ssh -Q kex

# تست اتصال با الگوریتم پساکوانتومی
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 [email protected] 2>&1 | grep "kex:"

پیکربندی سمت سرور

در فایل /etc/ssh/sshd_config:

# الگوریتم‌های Key Exchange — پساکوانتومی اولویت دارد
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected]

# بررسی صحت پیکربندی
sudo sshd -t

# ریستارت سرویس
sudo systemctl restart sshd

پیکربندی سمت کلاینت

در فایل ~/.ssh/config یا /etc/ssh/ssh_config:

# تنظیمات عمومی — پساکوانتومی اولویت دارد
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

# استثنا برای سرورهای قدیمی که پساکوانتومی ندارند
Host legacy-server.example.com
    KexAlgorithms +curve25519-sha256,[email protected],diffie-hellman-group16-sha512

هشدار OpenSSH 10.1

یک تغییر جالب در نسخه 10.1: از این به بعد OpenSSH وقتی از الگوریتم غیرپساکوانتومی استفاده کنید، بهتان هشدار می‌دهد:

WARNING: connection is not using a post-quantum key exchange algorithm.
This session may be vulnerable to 'store now, decrypt later' attacks.

اگر واقعاً نیاز دارید این هشدار را برای سرورهای قدیمی غیرفعال کنید (که توصیه نمی‌شود):

# فقط برای سرورهای قدیمی خاص
Host legacy.internal
    WarnWeakCrypto no

احراز هویت سخت‌افزاری با کلیدهای FIDO2

کلیدهای SSH حتی اگر Ed25519 باشند، در نهایت روی دیسک ذخیره می‌شوند. یعنی چی؟ یعنی اگر لپ‌تاپ شما هک بشود یا کلید خصوصی دزدیده بشود، مهاجم به همه سرورهایتان دسترسی پیدا می‌کند. کلیدهای سخت‌افزاری FIDO2 این مشکل را ریشه‌ای حل می‌کنند: کلید خصوصی هرگز از دستگاه سخت‌افزاری خارج نمی‌شود. اصلاً فیزیکاً امکانش نیست.

تجهیزات سازگار

هر دستگاه FIDO2 که از OpenSSH 8.2 به بعد پشتیبانی می‌شود کار می‌کند. چند گزینه محبوب:

YubiKey 5 Series — محبوب‌ترین انتخاب، پشتیبانی از NFC و USB
SoloKey v2 — متن‌باز و ارزان‌تر
Google Titan Security Key — گزینه خوبی برای کسانی که در اکوسیستم گوگل هستند
Nitrokey FIDO2 — ساخت اروپا، متن‌باز

تولید کلید FIDO2 مقیم (Resident Key)

# تولید کلید Ed25519 با پشتوانه FIDO2
# -O resident: ذخیره handle روی دستگاه (قابل حمل بین سیستم‌ها)
# -O verify-required: نیاز به PIN + لمس فیزیکی
ssh-keygen -t ed25519-sk -O resident -O verify-required \
  -C "[email protected]" -f ~/.ssh/id_ed25519_sk

هنگام اجرای این دستور:

از شما خواسته می‌شود کلید FIDO2 را به USB وصل کنید
PIN دستگاه را وارد کنید
دستگاه را لمس فیزیکی کنید

نتیجه؟ احراز هویت دو عاملی واقعی — چیزی که دارید (کلید سخت‌افزاری) + چیزی که می‌دانید (PIN). بدون نیاز به هیچ اپلیکیشن اضافی.

استفاده از کلید روی سیستم‌های مختلف

یکی از مزایای استفاده از -O resident این است که می‌توانید روی هر سیستم جدیدی کلید را بازیابی کنید. کافی است کلید سخت‌افزاری را وصل کنید:

# بازیابی کلید مقیم از دستگاه FIDO2
ssh-add -K

# حالا می‌توانید به سرور متصل شوید
ssh [email protected]

پیکربندی سرور برای کلیدهای FIDO2

در فایل sshd_config:

# پذیرش کلیدهای FIDO2
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],[email protected]

بعد کلید عمومی FIDO2 را به فایل ~/.ssh/authorized_keys سرور اضافه کنید — دقیقاً مثل کلیدهای معمولی. هیچ تفاوتی از سمت سرور ندارد.

گواهی‌نامه‌های SSH: جایگزین مدرن authorized_keys

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

گواهی‌نامه SSH چگونه کار می‌کند؟

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

سرورها فقط باید کلید عمومی CA را بشناسند — نه کلید تک‌تک کاربران
گواهی‌نامه‌ها تاریخ انقضا دارند — معمولاً ۱ تا ۲۴ ساعت
لغو دسترسی فوری ممکن است — کافی است گواهی‌نامه تمدید نشود
شرکت‌هایی مثل Facebook، Google، Netflix و Uber همگی از این روش استفاده می‌کنند

راه‌اندازی CA با step-ca

step-ca از Smallstep یک مرجع صدور گواهی‌نامه متن‌باز است که هم X.509 و هم SSH را پشتیبانی می‌کند. نصبش هم نسبتاً ساده است:

# نصب step CLI و step-ca
# Debian/Ubuntu:
wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.deb
sudo dpkg -i step-cli_amd64.deb

wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.deb
sudo dpkg -i step-ca_amd64.deb

# مقداردهی اولیه CA با پشتیبانی SSH
step ca init --ssh \
  --name "MyOrg SSH CA" \
  --dns ca.myorg.internal \
  --address :8443

پیکربندی سرورها برای اعتماد به CA

# دریافت کلید عمومی CA برای کاربران
step ssh config --roots > /etc/ssh/ssh_user_ca.pub

# اضافه کردن به sshd_config
echo "TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub" | sudo tee -a /etc/ssh/sshd_config

# دریافت گواهی‌نامه میزبان برای خود سرور
step ssh certificate $(hostname) /etc/ssh/ssh_host_ecdsa_key.pub \
  --host --sign --provisioner "sshpop"

# اضافه کردن به sshd_config
echo "HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub" | sudo tee -a /etc/ssh/sshd_config

sudo systemctl restart sshd

صدور گواهی‌نامه کاربر

# درخواست گواهی‌نامه SSH (معمولاً با SSO)
step ssh certificate [email protected] ~/.ssh/id_ed25519.pub

# بررسی جزئیات گواهی‌نامه
step ssh inspect ~/.ssh/id_ed25519-cert.pub

# اتصال به سرور — گواهی‌نامه به‌صورت خودکار استفاده می‌شود
ssh [email protected]

احراز هویت چندعاملی (MFA) با Google Authenticator

اگر کلید سخت‌افزاری FIDO2 ندارید یا می‌خواهید یک لایه امنیتی اضافی بالای آن داشته باشید، احراز هویت چندعاملی با کدهای یک‌بار مصرف TOTP گزینه خوبی است. راه‌اندازیش هم خیلی وقت نمی‌برد.

نصب و پیکربندی

# نصب ماژول PAM برای Google Authenticator
# Debian/Ubuntu:
sudo apt install libpam-google-authenticator

# RHEL/Rocky/Alma:
sudo dnf install google-authenticator

# اجرا به‌عنوان کاربر (نه root)
google-authenticator

# به سؤالات پاسخ دهید:
# - Do you want time-based tokens? y
# - Update .google_authenticator file? y
# - Disallow multiple uses? y
# - Rate limiting? y

پیکربندی PAM

فایل /etc/pam.d/sshd را ویرایش کنید:

# اضافه کردن در انتهای فایل
auth required pam_google_authenticator.so

پیکربندی SSH برای MFA

در فایل sshd_config:

# فعال‌سازی احراز هویت چندعاملی
# نیاز به کلید عمومی + کد TOTP
AuthenticationMethods publickey,keyboard-interactive

# فعال‌سازی Challenge-Response
KbdInteractiveAuthentication yes

# فعال‌سازی PAM
UsePAM yes

تمام! حالا برای هر اتصال SSH، کاربر باید هم کلید خصوصی‌اش را داشته باشد و هم کد ۶ رقمی از اپلیکیشن Google Authenticator را وارد کند. دو لایه امنیتی بهتر از یکی است.

محافظت فعال با Fail2Ban

Fail2Ban لاگ‌های SSH را زیر نظر می‌گیرد و آدرس‌های IP مهاجم را به‌صورت خودکار مسدود می‌کند. شاید فکر کنید اگر احراز هویت مبتنی بر کلید دارید دیگر نیازی به Fail2Ban نیست. ولی اینطور نیست — Fail2Ban همچنان نویز لاگ‌ها و بار سرور را به‌شکل محسوسی کاهش می‌دهد.

نصب و پیکربندی

# نصب Fail2Ban
# Debian/Ubuntu:
sudo apt install fail2ban

# RHEL/Rocky/Alma:
sudo dnf install fail2ban

فایل /etc/fail2ban/jail.local بسازید:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
banaction = nftables-multiport

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
bantime = 86400

# فعال‌سازی و شروع سرویس
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# مشاهده وضعیت
sudo fail2ban-client status sshd

# مشاهده آدرس‌های مسدود شده
sudo fail2ban-client get sshd banned

استفاده از nftables به جای iptables

توجه کنید که در پیکربندی بالا از banaction = nftables-multiport استفاده کردیم. در سال ۲۰۲۶ با توجه به اینکه nftables رسماً جایگزین iptables شده، منطقی است که Fail2Ban هم از nftables استفاده کند. اگر هنوز از iptables استفاده می‌کنید، شاید وقتش رسیده که مهاجرت کنید.

استفاده از سرور Bastion (Jump Host)

یک قانون طلایی برای محیط‌های تولید: هرگز پورت SSH سرورها را مستقیماً به اینترنت باز نکنید. به جای آن از یک سرور Bastion (یا Jump Host) استفاده کنید — یک سرور حداقلی و سخت‌شده که تنها نقطه ورود به شبکه داخلی‌تان می‌شود.

# پیکربندی ~/.ssh/config برای اتصال از طریق Bastion
Host bastion
    HostName bastion.myorg.com
    Port 2222
    User admin
    IdentityFile ~/.ssh/id_ed25519_sk

Host production-*
    ProxyJump bastion
    User deployer

Host production-web
    HostName 10.0.1.10

Host production-db
    HostName 10.0.1.20

# اتصال مستقیم از طریق Bastion — شفاف و خودکار
ssh production-web

# انتقال فایل از طریق Bastion
scp app.tar.gz production-web:/opt/deploy/

نکته مهم: حتماً از ProxyJump به جای ProxyCommand یا Agent Forwarding استفاده کنید. ProxyJump امن‌تر است چون کلید خصوصی شما هرگز روی سرور Bastion قرار نمی‌گیرد. این تفاوت ظریف ولی مهمی است.

ممیزی و نظارت مستمر بر SSH

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

ممیزی پیکربندی با ssh-audit

ابزار ssh-audit پیکربندی سرور SSH شما را تحلیل می‌کند و الگوریتم‌های ضعیف و مشکلات امنیتی را شناسایی می‌کند. یکی از آن ابزارهایی است که هر مدیر سیستم باید در جعبه‌ابزارش داشته باشد:

# نصب ssh-audit
pip3 install ssh-audit

# ممیزی سرور محلی
ssh-audit localhost

# ممیزی سرور ریموت
ssh-audit --port 2222 server.example.com

# خروجی JSON برای اتوماسیون
ssh-audit --json server.example.com

نظارت بر لاگ‌ها با auditd

# اضافه کردن قوانین audit برای SSH
sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config
sudo auditctl -w /etc/ssh/ -p wa -k ssh_config_dir
sudo auditctl -a always,exit -F arch=b64 -S execve -F path=/usr/sbin/sshd -k sshd_exec

# جستجو در لاگ‌های audit
sudo ausearch -k sshd_config --interpret

# بررسی ورودهای ناموفق SSH
sudo journalctl -u sshd --since "1 hour ago" | grep "Failed"

# شمارش تلاش‌های ناموفق به تفکیک IP
sudo journalctl -u sshd --since "24 hours ago" | grep "Failed" | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

جدول زمانی ممیزی پیشنهادی

یک برنامه زمانی واقع‌بینانه برای نگهداری امنیت SSH:

هفتگی: بررسی به‌روزرسانی‌های OpenSSH و اعمال پچ‌ها
هفتگی: بررسی لاگ‌های احراز هویت و شناسایی الگوهای مشکوک
ماهانه: اجرای ssh-audit و رفع مشکلات شناسایی‌شده
فصلی: بازبینی لیست کاربران مجاز و حذف کلیدهای غیرفعال
فصلی: بررسی الگوریتم‌های رمزنگاری و به‌روزرسانی در صورت نیاز

فایل نهایی sshd_config امن‌شده برای ۲۰۲۶

خب، بیایید همه چیز را کنار هم بگذاریم. این فایل پیکربندی تمام موارد امنیتی بحث‌شده در این مقاله را ترکیب می‌کند. می‌توانید آن را به‌عنوان نقطه شروع استفاده کنید و بر اساس نیازهای خودتان تنظیم کنید:

# === OpenSSH Server Configuration — Hardened for 2026 ===

# --- شبکه ---
Port 2222
ListenAddress 0.0.0.0
AddressFamily inet

# --- پروتکل و الگوریتم‌ها ---
# Key Exchange — پساکوانتومی اولویت دارد
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

# رمزنگاری — AES-GCM اولویت دارد (توصیه OpenSSH 10.0)
Ciphers [email protected],[email protected],[email protected]

# MAC
MACs [email protected],[email protected]

# کلیدهای میزبان
HostKey /etc/ssh/ssh_host_ed25519_key

# --- احراز هویت ---
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256
RequiredRSASize 3072

# احراز هویت چندعاملی (در صورت استفاده از TOTP)
# AuthenticationMethods publickey,keyboard-interactive
# KbdInteractiveAuthentication yes
# UsePAM yes

# --- محدودسازی دسترسی ---
AllowGroups ssh-users
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# --- جلسات ---
ClientAliveInterval 300
ClientAliveCountMax 3

# --- ویژگی‌های غیرضروری را غیرفعال کنید ---
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no

# --- لاگ ---
LogLevel VERBOSE
SyslogFacility AUTH

# --- جلوگیری از ارتقای دسترسی ---
StrictModes yes
PermitUserEnvironment no

# --- بنر ---
Banner /etc/ssh/banner.txt

پرسش‌های متداول

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

تغییر پورت SSH از ۲۲ به‌تنهایی یک اقدام امنیتی قوی نیست — یک مهاجم مصمم با اسکن پورت‌ها می‌تواند پورت جدید را پیدا کند. ولی واقعیت این است که بیش از ۹۰ درصد حملات خودکار و ربات‌ها فقط پورت ۲۲ را اسکن می‌کنند. بنابراین تغییر پورت به‌عنوان کاهش نویز بسیار مؤثر است: لاگ‌های تمیزتر، بار کمتر روی سرور و Fail2Ban، و شناسایی آسان‌تر حملات هدفمند واقعی.

رمزنگاری پساکوانتومی چیست و آیا الان باید آن را فعال کنم؟

رمزنگاری پساکوانتومی الگوریتم‌هایی است که در برابر حملات کامپیوترهای کوانتومی مقاوم هستند. و بله، باید همین الان آن را فعال کنید. حتی اگر کامپیوترهای کوانتومی هنوز عملی نشده‌اند، مهاجمان می‌توانند ترافیک رمزنگاری‌شده شما را الان ضبط و بعداً رمزگشایی کنند (حمله Harvest Now, Decrypt Later). OpenSSH 10.0 به‌صورت پیش‌فرض از الگوریتم ترکیبی mlkem768x25519-sha256 استفاده می‌کند که هم در برابر حملات کلاسیک و هم کوانتومی مقاوم است.

تفاوت کلید FIDO2 با کلید SSH معمولی چیست؟

در کلیدهای SSH معمولی، کلید خصوصی به‌صورت فایل روی دیسک ذخیره می‌شود و اگر سیستم شما هک بشود، کلید قابل سرقت است. در کلیدهای FIDO2، کلید خصوصی داخل دستگاه سخت‌افزاری (مثل YubiKey) تولید و ذخیره می‌شود و اصلاً از آن خارج نمی‌شود. علاوه بر این، هر بار استفاده نیاز به لمس فیزیکی دستگاه و وارد کردن PIN دارد — یعنی احراز هویت دو عاملی واقعی بدون نیاز به اپلیکیشن جداگانه.

گواهی‌نامه SSH بهتر است یا کلید عمومی authorized_keys؟

بستگی به مقیاس محیط شما دارد. برای محیط‌های کوچک (چند سرور)، کلید عمومی کافی است و لزومی به پیچیده کردن کار نیست. اما در محیط‌های بزرگ‌تر، گواهی‌نامه‌های SSH قطعاً بهتر هستند. مزایا: مدیریت متمرکز، تاریخ انقضای خودکار، لغو فوری دسترسی، و نیازی به توزیع کلید روی تک‌تک سرورها نیست. شرکت‌هایی مثل Google، Facebook و Netflix هم همین رویکرد را دارند — و این بی‌دلیل نیست.

آیا OpenSSH 10.0 با سرورها و کلاینت‌های قدیمی سازگار است؟

بله، OpenSSH 10.0 سازگاری عقب‌گرد دارد اما با چند تغییر مهم: پشتیبانی از DSA به‌طور کامل حذف شده و Diffie-Hellman با گروه‌های محدود به‌صورت پیش‌فرض غیرفعال شده. اگر سرورهای قدیمی دارید که هنوز از این الگوریتم‌ها استفاده می‌کنند، باید قبل از ارتقا آنها را به‌روزرسانی کنید. خبر خوب اینکه می‌توانید در فایل ssh_config با استفاده از بلوک Host تنظیمات متفاوتی برای سرورهای قدیمی تعریف کنید تا همه چیز کنار هم کار کند.