امن‌سازی SSH از تغییر پورت شروع نمی‌شود؛ از کنترل هویت مدیر، کلید قابل لغو، محدودسازی مبدأ، patch و مسیر بازیابی شروع می‌شود. خطر عملی اصلی این است که مدیر قبل از آزمون کلید یا firewall، ورود فعلی را ببندد و از سرور production بیرون بماند. هر تغییر باید در session دوم و با console اضطراری آماده آزمون شود.
پاسخ سریع: برای هر مدیر حساب جدا بسازید، کلید عمومی معتبر را نصب و login و sudo را در session دوم آزمایش کنید. سپس root login و password authentication را متناسب با نیاز محدود کنید، مبدأ SSH را در firewall یا VPN کاهش دهید و log، alert، rotation و revoke را برقرار کنید. session قبلی را تا تأیید نهایی نبندید.
Threat Model دسترسی مدیریتی
مشخص کنید چه کسانی، از کدام شبکه و برای چه کاری باید SSH داشته باشند. IP ثابت دفتر، VPN، bastion و دسترسی اضطراری هرکدام مدل متفاوتی دارند. سرور عمومی که SSH را به کل اینترنت ارائه می‌کند نیازمند کنترل‌های بیشتری از hostی است که فقط از شبکه مدیریت قابل دسترسی است.
قبل از تغییر: مسیر نجات
console یا rescue mode ارائه‌دهنده را باز و credential حساب provider را با MFA تأیید کنید. یک backup از config فعلی و روش rollback داشته باشید. snapshot جای console و backup مستقل را نمی‌گیرد. اگر syntax اشتباه باشد یا rule شبکه دسترسی را ببندد، تنها مسیر بازگشت ممکن است out-of-band باشد.
وضعیت فعال را حدس نزنید
ss -lntp
systemctl status ssh --no-pager
systemctl status sshd --no-pagerنام unit میان توزیع‌ها متفاوت است؛ ممکن است فقط یکی از دو نام وجود داشته باشد. مسیر config و includeها را از سرویس واقعی پیدا کنید. listener فعال، address family و port را ثبت کنید. خروجی شامل IP یا نام داخلی را قبل از اشتراک عمومی پاک کنید.
حساب جدا برای هر مدیر
استفاده از حساب مشترک attribution و revoke را دشوار می‌کند. هر مدیر باید user خودش، کلید خودش و sudo متناسب با نقش داشته باشد. پایان همکاری باید با غیرفعال‌کردن همان حساب یا کلید انجام شود، نه تعویض اضطراری یک credential مشترک برای همه.
کلید عمومی، نه جابه‌جایی Private Key
فقط public key روی سرور قرار می‌گیرد. private key باید روی دستگاه امن بماند، passphrase مناسب داشته باشد و هرگز از طریق ایمیل عمومی، Git یا ticket ارسال نشود. fingerprint کلید عمومی را از یک کانال مستقل تأیید کنید تا کلید اشتباه به حساب مدیریتی اضافه نشود.
Permission فایل‌های SSH
مالکیت home، پوشه .ssh و فایل authorized keys باید با سیاست daemon سازگار باشد. permission بیش‌ازحد باز باعث رد شدن کلید یا افزایش ریسک می‌شود. استفاده از chmod 777 هم ناامن است و هم ممکن است login را خراب کند. مقدار درست را با مستندات توزیع و config فعال تطبیق دهید.
ترتیب امن محدودسازی Password و Root
- حساب مدیریتی جدا و public key را اضافه کنید.
- از terminal دوم با همان حساب وارد شوید.
- sudo و عملیات ضروری را آزمایش کنید.
- config را با ابزار daemon همان نسخه syntax-check کنید.
- password/root login را مرحله‌ای محدود کنید.
- reload کنترل‌شده انجام دهید، نه قطع session موجود.
- ورود جدید موفق و ورود ممنوع واقعاً رد شود.
عبارت‌های config و رفتار آن‌ها به نسخه OpenSSH و include order وابسته‌اند. فایل نمونه قدیمی را کامل جایگزین نکنید؛ config مؤثر و overrideهای بعدی را بررسی کنید.
Syntax Test و Config مؤثر
OpenSSH ابزار بررسی syntax و نمایش config مؤثر دارد، اما مسیر binary و نیاز به پارامترهای connection در نسخه‌ها فرق می‌کند. از binary همان daemon فعال استفاده کنید. موفق بودن syntax فقط ساختار را تأیید می‌کند؛ منطق allow/deny و Match block باید با login واقعی آزمون شود.
تغییر Port چه ارزشی دارد؟
پورت غیرپیش‌فرض حجم bot و نویز log را کم می‌کند، اما سرویس همچنان قابل کشف است و هیچ ضعف هویتی را رفع نمی‌کند. تغییر port نیازمند هماهنگی firewall، cloud security group، monitoring و مستندات است. آن را کنترل اصلی امنیت تلقی نکنید.
Firewall، VPN و Allowlist
اگر مبدأهای مدیریت ثابت‌اند، محدودسازی شبکه از مؤثرترین کنترل‌هاست. برای IP پویا، VPN یا bastion مدیریت‌شده می‌تواند سطح exposure را کم کند. قبل از اعمال allowlist، مسیر جایگزین و IPv4/IPv6 را بررسی کنید. راهنمای تنظیم Firewall لینوکس ترتیب ضد قفل‌شدن را پوشش می‌دهد.
MFA کجا قرار می‌گیرد؟
احراز چندمرحله‌ای می‌تواند در VPN، bastion، identity-aware proxy یا PAM قرار گیرد. طراحی باید دسترسی اضطراری، recovery code، automation و service account را در نظر بگیرد. فعال‌سازی PAM ناشناخته روی production بدون session باز و console ممکن است همه loginها را قطع کند.
SSH Agent و Agent Forwarding
agent استفاده از کلید رمزگذاری‌شده را آسان می‌کند، اما forwarding آن به host غیرقابل‌اعتماد امکان سوءاستفاده از agent را در زمان اتصال می‌دهد. forwarding را عمومی فعال نکنید. برای دسترسی زنجیره‌ای، ProxyJump یا bastion با سیاست محدود و logging روشن معمولاً قابل‌کنترل‌تر است.
Service Account و Automation
کلید CI/CD نباید shell و sudo نامحدود داشته باشد. command، مسیر، مبدأ و دسترسی فایل را به نیاز deployment محدود کنید. rotation و expiration را مستند کنید و secret runner را از log محافظت کنید. حساب انسان و ماشین جدا باشند تا revoke و audit قابل فهم بماند.
الگوریتم و نسخه قدیمی
فعال‌کردن الگوریتم منسوخ فقط برای اتصال یک client قدیمی، سطح امنیت همه کاربران را پایین می‌آورد. ابتدا client را به‌روزرسانی یا مسیر جدا و محدود طراحی کنید. فهرست الگوریتم‌های پشتیبانی‌شده از نسخه واقعی client/server استخراج شود؛ template عمومی ممکن است با build شما سازگار نباشد.
Rate Control و Fail2ban
محدودسازی تلاش تکراری می‌تواند نویز brute-force را کم کند، اما جای کلید، firewall و patch نیست. ابزار باید log صحیح، backend مناسب و مسیر unban داشته باشد. مقاله Fail2ban چیست و آیا لازم است؟ نحوه تصمیم و آزمون آن را توضیح می‌دهد.
Log و Alert
login موفق و ناموفق، تغییر account/key، sudo و تغییر config را نگه دارید. timestamp و NTP باید صحیح باشد. alert روی هر اسکن اینترنتی نویز می‌سازد؛ رویدادهای پرخطر مانند ورود root، ورود از مبدأ جدید، چند شکست برای حساب معتبر یا تغییر authorized keys اولویت بیشتری دارند.
Sessionهای طولانی و Multiplexing
connection دائمی می‌تواند بعد از revoke شبکه یا تغییر نقش باقی بماند. سیاست idle و lifecycle session را با نیاز عملیات هماهنگ کنید. timeout بسیار کوتاه نیز مدیر را وسط recovery قطع می‌کند. برای فرمان‌های طولانی از ابزار مناسب و ثبت خروجی استفاده کنید، نه session رهاشده نامعلوم.
Patch و سطح سرویس
daemon، کتابخانه رمزنگاری و سیستم‌عامل باید patch شوند. reload یا restart پس از update را با maintenance window و session جایگزین انجام دهید. حذف banner نسخه در ظاهر، آسیب‌پذیری واقعی را patch نمی‌کند. package source معتبر و inventory نسخه لازم است.
آزمون نهایی
- ورود حساب مجاز با key از مبدأ مجاز
- sudo فقط برای نقش لازم
- رد شدن password/root طبق سیاست
- رد شدن مبدأ غیرمجاز
- کار کردن IPv4 و IPv6 موردنیاز
- ثبت log و رسیدن alert
- دسترسی console و روش rollback
موفق بودن login مدیر کافی نیست؛ کنترل‌های ممنوعیت نیز باید از محیط آزمایشی امن بررسی شوند. session قبلی را فقط بعد از این آزمون‌ها ببندید.
اشتباه‌های رایج
- بستن password قبل از تست key
- بستن firewall بدون console
- اشتراک private key میان مدیران
- دادن sudo کامل به automation
- اتکا به تغییر port
- فعال‌کردن الگوریتم قدیمی برای همه
- Agent Forwarding عمومی
- ویرایش config بدون syntax test
چه زمانی کمک تخصصی لازم است؟
اگر چند مدیر، runner CI/CD، VPN یا شبکه دوگانه دارید، یک Match یا firewall اشتباه می‌تواند دسترسی production را قطع کند. نصب و کانفیگ سرور لینوکس می‌تواند دسترسی SSH را با حساب‌های جدا، مسیر اضطراری، logging و rollback پیاده کند.
پرسش‌های متداول
آیا باید Root Login را ببندیم؟
پس از ساخت حساب جدا، تست key و sudo و تأیید console، دسترسی مستقیم root طبق سیاست محدود شود.
کلید SSH بدون Passphrase امن است؟
سرقت فایل کلید بدون passphrase سوءاستفاده را آسان‌تر می‌کند؛ برای automation باید secret storage و دسترسی محدود جایگزین حفاظت انسانی شود.
آیا Fail2ban به‌تنهایی کافی است؟
خیر؛ فقط تلاش تکراری قابل‌مشاهده در log را محدود می‌کند و جای authentication قوی یا firewall نیست.
آیا تغییر پورت SSH ضروری است؟
ضروری نیست؛ می‌تواند نویز را کم کند، اما کنترل امنیتی اصلی محسوب نمی‌شود.