امنیت SSH چیست؟ مهم‌ترین تنظیمات برای امن‌سازی دسترسی SSH سرور

امنیت SSH به مجموعه‌ای از تنظیمات و اقدامات حفاظتی گفته می‌شود که از دسترسی غیرمجاز به سرور از طریق پروتکل Secure Shell جلوگیری می‌کنند. استفاده از کلیدهای SSH، غیرفعال‌کردن ورود مستقیم Root، محدودسازی دسترسی شبکه، فعال‌سازی احراز هویت چندمرحله‌ای و نظارت بر تلاش‌های ورود، مهم‌ترین راهکارهای افزایش امنیت SSH هستند.

مقدمه؛ چرا امنیت SSH برای هر سروری ضروری است؟

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

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

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

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

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

در این راهنما، مهم‌ترین اصول امنیت SSH، تنظیمات OpenSSH در لینوکس، روش‌های احراز هویت امن، حفاظت در برابر حملات رایج و مراحل بررسی عملی امنیت سرور را بررسی می‌کنیم.

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

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

SSH مخفف Secure Shell است؛ پروتکلی شبکه‌ای که برای برقراری ارتباط رمزنگاری‌شده میان دو سیستم طراحی شده است.

این پروتکل معمولاً برای مدیریت از راه دور سیستم‌عامل‌های لینوکسی و یونیکسی استفاده می‌شود، اما کاربرد آن به اجرای دستورات محدود نیست.

انتقال امن فایل، اجرای وظایف خودکار، ایجاد تونل‌های ارتباطی و مدیریت تجهیزات شبکه نیز می‌توانند از طریق SSH انجام شوند.

اجزای اصلی ارتباط SSH

در یک ارتباط SSH معمولاً دو جزء اصلی وجود دارد:

• SSH Client: نرم‌افزاری که اتصال را از سمت کاربر آغاز می‌کند.
• SSH Server: سرویسی که درخواست اتصال را دریافت و پردازش می‌کند.

برای نمونه، برنامه ssh در لینوکس نقش کلاینت و سرویس sshd در OpenSSH نقش سرور را دارد.

ارتباط معمولاً از طریق پورت TCP شماره 22 برقرار می‌شود؛ البته مدیر سیستم می‌تواند با توجه به معماری شبکه، پورت دیگری انتخاب کند.

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

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

SSH چگونه از اطلاعات محافظت می‌کند؟

سه ویژگی امنیتی مهم در طراحی SSH وجود دارد.

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

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

احراز هویت: کلاینت می‌تواند هویت سرور را با کلید میزبان بررسی کند و سرور نیز هویت کاربر را از طریق روش‌هایی مانند کلید عمومی یا رمز عبور تأیید می‌کند.

البته این قابلیت‌ها زمانی مؤثرند که تنظیمات کلاینت و سرور صحیح باشند و کاربران هشدارهای امنیتی را نادیده نگیرند.

تفاوت SSH با Telnet و FTP

پروتکل‌های قدیمی مانند Telnet برای مدیریت از راه دور استفاده می‌شدند، اما در حالت معمول اطلاعات احراز هویت و محتوای ارتباط را بدون رمزنگاری مناسب منتقل می‌کنند.

SSH برای رفع این ضعف‌ها طراحی شده است.

نکته مهم این است که SFTP، برخلاف FTP سنتی، روی ارتباط SSH کار می‌کند. همچنین SFTP را نباید با FTPS که مبتنی بر TLS است یکسان دانست.

مهم‌ترین تهدیدهای امنیت SSH چیست؟

برای انتخاب تنظیمات دفاعی مناسب، ابتدا باید خطرهایی را شناخت که دسترسی SSH را تهدید می‌کنند.

حملات Brute Force یا حدس مکرر رمز عبور

در حملات Brute Force مهاجم تلاش می‌کند با امتحان‌کردن تعداد زیادی رمز عبور، به حساب کاربری دسترسی پیدا کند.

اگر SSH از اینترنت عمومی در دسترس باشد و ورود با رمز عبور فعال بماند، ممکن است تلاش‌های خودکار زیادی برای ورود به آن ثبت شود.

این تلاش‌ها معمولاً حساب‌های شناخته‌شده مانند root یا نام‌های کاربری رایج را هدف قرار می‌دهند.

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

استفاده از کلید SSH و غیرفعال‌کردن ورود با رمز عبور، یکی از مؤثرترین روش‌های کاهش این خطر است.

حملات Credential Stuffing

در Credential Stuffing مهاجم از اطلاعات ورود افشاشده در سرویس‌های دیگر برای امتحان‌کردن دسترسی به حساب‌های جدید استفاده می‌کند.

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

این نوع حمله با Brute Force تفاوت دارد؛ زیرا مهاجم لزوماً رمزهای تصادفی تولید نمی‌کند، بلکه از اطلاعات ورود واقعی و افشاشده استفاده می‌کند.

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

سرقت کلید خصوصی SSH

احراز هویت با کلید عمومی امنیت بالایی دارد، اما کلید خصوصی همچنان یک دارایی حساس است.

اگر مهاجم به فایل کلید خصوصی دسترسی پیدا کند، ممکن است بتواند از آن برای ورود به سرور استفاده کند.

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

بنابراین، امنیت SSH وابسته به حفاظت از دستگاه مدیر سرور نیز هست.

حمله Man-in-the-Middle

در حمله مرد میانی یا Man-in-the-Middle، مهاجم تلاش می‌کند میان کلاینت و سرور قرار بگیرد و ارتباط را تحت کنترل خود درآورد.

SSH با احراز هویت کلید میزبان برای مقابله با این تهدید طراحی شده است.

اما اگر کاربر بدون بررسی، هر کلید میزبان جدیدی را تأیید کند یا کنترل‌های اعتبارسنجی را غیرفعال کند، بخشی از این حفاظت از بین می‌رود.

به همین دلیل بررسی اثرانگشت کلید میزبان یکی از موضوعات مهم امنیت ارتباط SSH است.

سوءاستفاده از حساب‌های دارای دسترسی بالا

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

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

دسترسی غیرضروری به Root، اشتراک حساب مدیر میان چند نفر و نبود ثبت فعالیت کاربران، همگی شدت خسارت احتمالی را افزایش می‌دهند.

آسیب‌پذیری‌های نرم‌افزاری

OpenSSH و اجزای وابسته به آن مانند سایر نرم‌افزارها ممکن است در برخی نسخه‌ها دارای آسیب‌پذیری باشند.

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

ارزیابی آسیب‌پذیری باید بر اساس نسخه واقعی بسته نصب‌شده، اصلاحیه‌های توزیع لینوکس و شرایط بهره‌برداری انجام شود؛ زیرا شماره نسخه به‌تنهایی همیشه نشان‌دهنده وضعیت امنیتی بسته نیست.

پیش‌نیازهای امن‌سازی SSH بدون قطع دسترسی

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

در سرورهایی که فقط از طریق SSH مدیریت می‌شوند، چنین اشتباهی ممکن است دسترسی مدیریتی را قطع کند.

بررسی دسترسی فعلی

قبل از تغییر تنظیمات باید مشخص شود:

• کدام کاربران مجوز ورود SSH دارند؟
• آیا ورود فعلی با رمز عبور انجام می‌شود یا کلید عمومی؟
• آیا حساب مدیریتی جایگزین وجود دارد؟
• آیا فایروال یا پنل ارائه‌دهنده سرور محدودیتی اعمال می‌کند؟
• آیا کنسول اضطراری برای بازیابی دسترسی موجود است؟
• آیا سرویس‌ها یا ابزارهای خودکار از SSH استفاده می‌کنند؟

پاسخ به این پرسش‌ها تعیین می‌کند کدام تغییرات را می‌توان بدون ایجاد اختلال اجرا کرد.

ایجاد نسخه پشتیبان از تنظیمات

در توزیع‌هایی که از OpenSSH استفاده می‌کنند، فایل اصلی تنظیمات معمولاً در مسیر زیر قرار دارد:

/etc/ssh/sshd_config

قبل از ویرایش، از فایل و تنظیمات مرتبط نسخه پشتیبان تهیه کنید.

برای نمونه:

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

این نسخه پشتیبان امکان مقایسه و بازگرداندن تنظیمات را فراهم می‌کند.

البته اگر تنظیمات در فایل‌های دیگری مانند sshd_config.d تعریف شده باشند، باید از آن فایل‌ها نیز نسخه پشتیبان تهیه شود.

باز نگه‌داشتن نشست فعلی

در زمان اعمال تنظیمات، نشست SSH فعلی را باز نگه دارید.

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

این اقدام احتمال قطع کامل دسترسی را کاهش می‌دهد؛ هرچند تضمین نمی‌کند که نشست فعلی در تمام شرایط حفظ شود.

برای سرورهای حساس، دسترسی به کنسول ارائه‌دهنده زیرساخت، KVM یا روش بازیابی مستقل ضروری است.

غیرفعال‌کردن ورود مستقیم Root در SSH

یکی از مهم‌ترین اصول امنیت SSH، محدودکردن ورود مستقیم با حساب Root است.

حساب Root در لینوکس دارای بالاترین سطح دسترسی مدیریتی است. به همین دلیل، استفاده روزمره از آن ریسک اشتباهات انسانی و سوءاستفاده از اطلاعات احراز هویت را افزایش می‌دهد.

چرا ورود مستقیم Root خطرناک است؟

نام کاربری Root در بسیاری از سیستم‌های لینوکسی شناخته‌شده است.

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

بااین‌حال، باید توجه کرد که غیرفعال‌کردن ورود مستقیم Root به‌تنهایی مانع نفوذ نمی‌شود. اگر مهاجم به حسابی دسترسی پیدا کند که مجوز اجرای دستورات مدیریتی دارد، همچنان ممکن است کنترل سیستم را به دست بگیرد.

هدف اصلی این تنظیم، کاهش مسیرهای دسترسی مستقیم و ایجاد امکان کنترل دقیق‌تر فعالیت‌های مدیریتی است.

ایجاد حساب مدیریتی مستقل

پیش از ممنوع‌کردن ورود Root، یک حساب مدیریتی مستقل ایجاد کنید.

در اوبونتو یا دبیان می‌توان از دستور زیر استفاده کرد:

sudo adduser serveradmin

سپس، در صورت نیاز، این حساب را به گروه مدیریتی مناسب اضافه کنید:

sudo usermod -aG sudo serveradmin

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

این دستورها صرفاً نمونه هستند و باید بر اساس ساختار مجوزهای سرور تنظیم شوند.

پس از ایجاد حساب، کلید عمومی SSH را برای آن ثبت کنید و مطمئن شوید که ورود و اجرای دستورات مجاز از طریق این حساب امکان‌پذیر است.

تنظیم PermitRootLogin

برای ممنوع‌کردن ورود مستقیم Root از طریق SSH می‌توان از دستور پیکربندی زیر استفاده کرد:

PermitRootLogin no

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

برای بیشتر سرورهایی که امکان مدیریت با حساب مستقل و sudo را دارند، مقدار no انتخاب مناسب‌تری است.

در محیط‌هایی که از کلیدهای Root برای فرایندهای خودکار استفاده می‌کنند، باید ابتدا وابستگی‌ها بررسی شوند.

استفاده از کلید SSH به‌جای رمز عبور

یکی از مؤثرترین راهکارهای امن‌سازی SSH، استفاده از احراز هویت مبتنی بر کلید عمومی یا Public Key Authentication است.

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

کلید عمومی و کلید خصوصی چه تفاوتی دارند؟

احراز هویت کلیدی SSH معمولاً بر پایه یک جفت کلید رمزنگاری انجام می‌شود.

Public Key یا کلید عمومی: اطلاعاتی است که روی سرور ثبت می‌شود و برای تأیید امضاهای احراز هویت کاربرد دارد.

Private Key یا کلید خصوصی: اطلاعات محرمانه‌ای است که باید تحت کنترل کاربر باقی بماند.

سرور از کلید عمومی برای بررسی اثبات مالکیت کلید خصوصی استفاده می‌کند؛ بنابراین برای احراز هویت نیازی نیست کلید خصوصی به سرور ارسال شود.

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

انتخاب الگوریتم مناسب برای SSH Key

الگوریتم Ed25519 یکی از گزینه‌های مناسب برای ساخت کلیدهای SSH در محیط‌های معمول و سازگار است.

این الگوریتم کلیدهایی با اندازه نسبتاً کوچک و کارایی مناسب ارائه می‌دهد.

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

در محیط‌های دارای الزامات انطباق خاص، مانند برخی سامانه‌های مبتنی بر FIPS، انتخاب الگوریتم باید با سیاست رمزنگاری سازمان هماهنگ باشد.

ساخت کلید SSH در لینوکس

برای ایجاد یک جفت کلید Ed25519 می‌توان از دستور زیر استفاده کرد:

ssh-keygen -t ed25519 -a 100

در زمان ساخت کلید، نرم‌افزار می‌تواند از کاربر بخواهد مسیر ذخیره‌سازی و یک عبارت عبور یا Passphrase انتخاب کند.

استفاده از Passphrase مناسب برای حفاظت از کلید خصوصی اهمیت زیادی دارد؛ به‌ویژه در دستگاه‌هایی که امکان سرقت فایل‌ها وجود دارد.

پارامتر -a تعداد دورهای تابع مشتق‌سازی کلید مورد استفاده برای محافظت از کلید خصوصی ذخیره‌شده را تعیین می‌کند.

این پارامتر جایگزین انتخاب یک Passphrase قوی نیست.

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

پس از ساخت کلید، باید کلید عمومی در حساب کاربری مقصد ثبت شود.

در محیط‌هایی که ابزار ssh-copy-id در دسترس است، می‌توان از دستور زیر استفاده کرد:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

این دستور برای مرحله راه‌اندازی اولیه مناسب است؛ مشروط بر اینکه کاربر از قبل یک روش ورود معتبر داشته باشد.

پس از انتقال کلید، یک اتصال آزمایشی جدید برقرار کنید.

موفقیت این آزمایش باید پیش از غیرفعال‌کردن احراز هویت رمزی تأیید شود.

تنظیم مجوزهای فایل‌های SSH

مجوزهای نامناسب فایل‌ها ممکن است باعث بروز مشکل در احراز هویت یا افزایش خطر دسترسی غیرمجاز شوند.

در تنظیمات معمول لینوکس، برای پوشه .ssh و فایل authorized_keys می‌توان مجوزهای محدود زیر را در نظر گرفت:

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

کلید خصوصی نیز معمولاً باید فقط برای مالک قابل‌خواندن باشد.

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

در بعضی محیط‌ها، ACLها، SELinux یا سیستم‌های فایل خاص نیز بر نتیجه اثر می‌گذارند.

چگونه ورود با رمز عبور SSH را غیرفعال کنیم؟

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

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

تنظیم PasswordAuthentication

گزینه زیر ورود مستقیم با روش Password Authentication را غیرفعال می‌کند:

PasswordAuthentication no

با این تنظیم، سرور نباید احراز هویت از نوع Password را برای ورود SSH بپذیرد.

اما یک نکته مهم وجود دارد: در بعضی پیکربندی‌ها، روش Keyboard-Interactive نیز می‌تواند برای درخواست رمز عبور یا روش‌های دیگر احراز هویت استفاده شود.

بنابراین، فقط تغییر PasswordAuthentication لزوماً تمام مسیرهای ورود تعاملی مبتنی بر رمز را نمی‌بندد.

تنظیم KbdInteractiveAuthentication

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

KbdInteractiveAuthentication no

این گزینه احراز هویت تعاملی را غیرفعال می‌کند.

البته در سرورهایی که احراز هویت چندمرحله‌ای مبتنی بر PAM و کد یک‌بارمصرف دارند، غیرفعال‌کردن این گزینه ممکن است فرایند MFA را مختل کند.

بنابراین نباید تمام تنظیمات احراز هویت را بدون توجه به روش واقعی ورود تغییر داد.

آیا باید UsePAM را غیرفعال کرد؟

گزینه UsePAM در سیستم‌های سازگار با PAM می‌تواند بر احراز هویت و مدیریت نشست اثر بگذارد.

حتی وقتی ورود SSH صرفاً مبتنی بر کلید عمومی است، PAM ممکن است برای بررسی محدودیت حساب‌ها و اجرای تنظیمات نشست استفاده شود.

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

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

مهم‌ترین تنظیمات فایل sshd_config برای افزایش امنیت SSH

فایل sshd_config مرکز اصلی مدیریت تنظیمات سرویس OpenSSH است.

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

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

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

برای مثال:

AllowUsers serveradmin

با این تنظیم، فقط حساب نام‌برده واجد شرایط ورود از طریق SSH خواهد بود؛ البته باید سایر کنترل‌های احراز هویت را نیز با موفقیت پشت سر بگذارد.

در محیط‌های بزرگ‌تر، استفاده از AllowGroups برای محدودکردن دسترسی بر اساس عضویت گروه می‌تواند مدیریت کاربران را ساده‌تر کند.

محدودسازی کاربران باید با دقت انجام شود؛ زیرا حذف یک حساب ضروری از فهرست مجاز ممکن است دسترسی مدیر یا فرایندهای خودکار را قطع کند.

محدودکردن دفعات تلاش برای احراز هویت

گزینه MaxAuthTries حداکثر تعداد تلاش‌های ناموفق احراز هویت در هر اتصال را مشخص می‌کند.

برای نمونه:

MaxAuthTries 3

این مقدار می‌تواند فرصت تلاش‌های تکراری در یک اتصال را کاهش دهد.

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

مقدار بیش‌ازحد پایین نیز ممکن است برای کاربرانی که چند کلید در SSH Agent خود دارند مشکل ایجاد کند.

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

گزینه LoginGraceTime مدت‌زمان مجاز برای تکمیل احراز هویت را کنترل می‌کند.

برای مثال:

LoginGraceTime 30

این تنظیم باعث می‌شود اتصال‌هایی که احراز هویت را در زمان مشخص تکمیل نمی‌کنند، برای مدت نامحدود باز نمانند.

انتخاب مقدار مناسب باید با توجه به شرایط شبکه، تأخیر ارتباط و روش احراز هویت انجام شود.

کنترل اتصال‌های احراز هویت‌نشده

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

یک نمونه پیکربندی:

MaxStartups 10:30:60

در این قالب، با افزایش تعداد اتصال‌های احراز هویت‌نشده از آستانه اولیه، احتمال رد اتصال‌های جدید افزایش می‌یابد.

چنین محدودیتی می‌تواند در کنترل مصرف منابع مفید باشد، اما یک سامانه کامل مقابله با حملات منع سرویس یا DDoS محسوب نمی‌شود.

در سرورهای پرترافیک یا دارای تعداد زیادی اتصال خودکار، مقادیر باید متناسب با بار واقعی تنظیم شوند.

مدیریت نشست‌های غیرپاسخ‌گو

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

ClientAliveInterval 300
ClientAliveCountMax 2

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

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

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

برای مدیریت واقعی نشست‌های غیرفعال، باید قابلیت‌هایی مانند ChannelTimeout در نسخه‌های پشتیبانی‌کننده یا کنترل‌های مناسب نشست بررسی شوند.

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

SSH امکاناتی فراتر از ورود به خط فرمان دارد.

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

اگر این قابلیت‌ها در سرور مورد استفاده قرار نمی‌گیرند، می‌توان غیرفعال‌کردن آن‌ها را بررسی کرد.

X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no

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

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

اصل مناسب، فعال‌بودن فقط قابلیت‌هایی است که نیاز عملیاتی مشخص دارند.

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

تنظیمات امنیتی باید متناسب با نیاز سرور انتخاب شوند. هیچ فایل پیکربندی واحدی وجود ندارد که بدون بررسی برای تمام محیط‌ها مناسب باشد.

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

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

AllowUsers serveradmin

MaxAuthTries 3
LoginGraceTime 30
MaxStartups 10:30:60

X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
PermitUserEnvironment no

ClientAliveInterval 300
ClientAliveCountMax 2

این تنظیمات یک الگوی آموزشی هستند، نه فایلی که باید بدون بررسی روی هر سروری جایگزین شود.

قبل از استفاده از آن، باید چند موضوع مشخص شده باشد:

• حساب serveradmin واقعاً وجود داشته باشد.
• کلید عمومی مجاز برای آن حساب ثبت شده باشد.
• ورود جدید با کلید خصوصی از دستگاه مدیر با موفقیت آزمایش شده باشد.
• هیچ سرویس ضروری به ورود رمزی یا Forwarding وابسته نباشد.
• تنظیمات دیگری مانند Match یا فایل‌های Include نتیجه نهایی را تغییر ندهند.
• روش بازیابی دسترسی مستقل از SSH وجود داشته باشد.

در سرورهایی که از MFA مبتنی بر Keyboard-Interactive استفاده می‌کنند، باید پیکربندی احراز هویت متناسب با همان معماری طراحی شود.

محل صحیح قرارگیری تنظیمات در اوبونتو

در بسیاری از نسخه‌های اوبونتو، علاوه بر فایل اصلی، پوشه زیر نیز برای تنظیمات OpenSSH استفاده می‌شود:

/etc/ssh/sshd_config.d/

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

نکته مهم آن است که در OpenSSH معمولاً برای هر دستور پیکربندی، نخستین مقدار خوانده‌شده معتبر است؛ مگر اینکه مستندات همان دستور رفتار دیگری را مشخص کرده باشند.

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

ترتیب خواندن فایل‌ها و پیکربندی مؤثر باید بررسی شود.

بررسی صحت تنظیمات قبل از اعمال

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

sudo sshd -t

این دستور خطاهای نحوی و برخی مشکلات مرتبط با پیکربندی را بررسی می‌کند.

اگر خروجی خطایی نمایش داده شود، نباید بدون رفع مشکل سرویس را مجدداً راه‌اندازی کرد.

برای مشاهده تنظیمات مؤثر نیز می‌توان از دستور زیر استفاده کرد:

sudo sshd -T

این دستور برای بررسی مقدار نهایی گزینه‌هایی مانند passwordauthentication و permitrootlogin مفید است.

در پیکربندی‌های دارای قوانین Match، بررسی نتیجه برای یک کاربر و آدرس مشخص به پارامترهای تکمیلی نیاز دارد.

اعمال تنظیمات و آزمایش اتصال

در اوبونتو معمولاً سرویس SSH با نام ssh.service مدیریت می‌شود.

پس از تأیید صحت پیکربندی می‌توان در محیطی که از این سرویس استفاده می‌کند، تنظیمات را با روش مناسب بارگذاری مجدد کرد.

sudo systemctl reload ssh.service

در توزیع‌های دیگر ممکن است نام سرویس sshd.service باشد.

در بعضی نسخه‌های اوبونتو، SSH از طریق systemd socket activation نیز مدیریت می‌شود. به‌خصوص هنگام تغییر پورت یا آدرس شنود، باید وضعیت ssh.socket و روش اعمال تنظیمات آن بررسی شود.

پس از اعمال تغییرات، با یک نشست جدید اتصال را آزمایش کنید و تا تأیید کامل، نشست مدیریتی قبلی را نبندید.

افزایش امنیت SSH با فایروال

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

فایروال یکی از مهم‌ترین لایه‌های دفاعی برای کاهش این سطح دسترسی است.

چرا محدودسازی IP مهم است؟

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

محدودسازی مبدأ اتصال می‌تواند تعداد سیستم‌هایی را که امکان برقراری ارتباط اولیه با SSH دارند کاهش دهد.

این کنترل حتی پیش از مرحله احراز هویت اعمال می‌شود.

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

استفاده از UFW در اوبونتو

UFW یکی از ابزارهای مدیریت فایروال در اوبونتو است.

برای مشاهده وضعیت آن:

sudo ufw status verbose

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

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

آدرس 203.0.113.10 صرفاً نمونه مستندسازی است و باید با IP واقعی و مجاز مدیر جایگزین شود.

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

محدودکردن پورت SSH به یک IP اشتباه می‌تواند باعث قطع مدیریت سرور شود.

فایروال سیستم‌عامل در برابر فایروال ابری

در سرورهای ابری ممکن است دو لایه کنترل شبکه وجود داشته باشد:

1. فایروال سیستم‌عامل، مانند UFW یا firewalld.
2. فایروال ارائه‌دهنده سرور، مانند Security Group یا قواعد شبکه ابری.

استفاده صحیح از هر دو لایه می‌تواند مفید باشد.

فایروال ابری امکان محدودکردن بعضی ارتباط‌ها پیش از رسیدن آن‌ها به ماشین مجازی را فراهم می‌کند.

فایروال میزبان نیز کنترل مستقلی در سطح سیستم‌عامل ارائه می‌دهد.

در زمان عیب‌یابی باید هر دو لایه بررسی شوند؛ زیرا بازبودن پورت در یکی از آن‌ها به معنی قابل‌دسترسی‌بودن سرویس نیست.

توجه به IPv6

یکی از اشتباهات رایج این است که مدیر سرور فقط قوانین IPv4 را بررسی کند.

اگر سرور دارای آدرس IPv6 عمومی باشد، ممکن است سرویس SSH از این مسیر نیز قابل‌دسترسی باشد.

بنابراین باید قوانین مربوط به هر دو خانواده آدرس و وضعیت واقعی شنود سرویس بررسی شوند.

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

پورت پیش‌فرض SSH معمولاً TCP 22 است.

برخی مدیران سرور برای کاهش تلاش‌های خودکار، این پورت را تغییر می‌دهند.

تغییر پورت می‌تواند تعداد اسکن‌ها و تلاش‌های ساده‌ای را که صرفاً پورت پیش‌فرض را هدف می‌گیرند کاهش دهد.

اما نباید آن را یک سازوکار احراز هویت یا یک کنترل امنیتی اصلی دانست.

مهاجمی که پورت‌های باز سرور را شناسایی می‌کند، ممکن است سرویس SSH را روی پورت غیرپیش‌فرض نیز پیدا کند.

مزایا و محدودیت‌های تغییر پورت

اگر تغییر پورت انجام می‌شود، باید در تنظیمات سرویس، فایروال میزبان، فایروال ابری و ابزارهای مدیریتی هماهنگی وجود داشته باشد.

در سامانه‌هایی که SSH از طریق Socket Activation اجرا می‌شود، ممکن است تغییر فایل اصلی به‌تنهایی کافی نباشد.

تغییر پورت یک اقدام تکمیلی است؛ نه جایگزین کلید SSH، احراز هویت مناسب و محدودسازی دسترسی شبکه.

مقابله با حملات Brute Force با Fail2Ban

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

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

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

فرایند کلی شامل چند مرحله است:

1. سرویس SSH تلاش‌های ورود و رویدادهای مرتبط را ثبت می‌کند.
2. Fail2Ban داده‌های ثبت‌شده را بر اساس فیلترهای تعریف‌شده بررسی می‌کند.
3. در صورت عبور تعداد رویدادها از آستانه تعیین‌شده، قانون محدودسازی اعمال می‌شود.
4. پس از مدت مشخص، محدودیت می‌تواند برداشته شود.

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

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

نمونه تنظیمات Fail2Ban

در برخی توزیع‌های لینوکسی می‌توان Fail2Ban را از مخازن رسمی نصب کرد.

یک نمونه ساده از تنظیمات بخش SSH:

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

این مقادیر صرفاً یک نمونه سیاست محدودسازی هستند.

فایل تنظیمات، روش خواندن گزارش‌ها، Backend و روش اعمال مسدودسازی باید با نسخه ابزار و توزیع لینوکس سازگار باشند.

برای نمونه، در بعضی محیط‌ها ثبت وقایع از طریق systemd journal انجام می‌شود و پیکربندی باید این موضوع را در نظر بگیرد.

بررسی عملکرد Fail2Ban

در محیطی که Jail مربوط به SSH فعال است، می‌توان وضعیت آن را با دستور زیر بررسی کرد:

sudo fail2ban-client status sshd

همچنین باید مطمئن شد که ابزار فقط نصب نشده، بلکه واقعاً گزارش‌های صحیح را دریافت و قوانین موردنظر را اعمال می‌کند.

مسدودسازی اشتباه IP مدیر یا سرویس‌های قابل‌اعتماد نیز باید در طراحی سیاست‌ها در نظر گرفته شود.

احراز هویت دومرحله‌ای SSH یا 2FA

احراز هویت دومرحله‌ای یا Two-Factor Authentication یک لایه امنیتی اضافی برای تأیید هویت کاربر فراهم می‌کند.

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

برای نمونه، ممکن است استفاده از کلید SSH به همراه یک عامل تأیید اضافی الزامی شود.

تفاوت 2FA و MFA

2FA به استفاده از دو عامل احراز هویت اشاره دارد.

MFA یا Multi-Factor Authentication مفهوم گسترده‌تری است که می‌تواند دو یا چند عامل را دربر بگیرد.

عامل‌های احراز هویت معمولاً در دسته‌هایی مانند موارد زیر قرار می‌گیرند:

• چیزی که کاربر می‌داند، مانند رمز یا PIN.
• چیزی که کاربر در اختیار دارد، مانند کلید امنیتی سخت‌افزاری.
• ویژگی‌ای متعلق به کاربر، مانند عامل زیست‌سنجی.

استفاده از دو مرحله مشابه الزاماً به معنی وجود دو عامل مستقل نیست.

ترکیب SSH Key با احراز هویت دوم

OpenSSH از قابلیت AuthenticationMethods برای تعریف روش‌های احراز هویت موردنیاز پشتیبانی می‌کند.

در برخی پیکربندی‌های مبتنی بر PAM، می‌توان ورود با کلید عمومی را با یک مرحله تعاملی دیگر ترکیب کرد.

اما اجرای صحیح این ساختار به تنظیمات PAM، دسترس‌پذیری عامل دوم و سیاست‌های بازیابی وابسته است.

به همین دلیل، فعال‌سازی MFA روی سرور عملیاتی باید ابتدا در محیط آزمایشی بررسی شود.

اگر روش دوم به‌درستی پیکربندی نشده باشد، ممکن است دسترسی تمام مدیران قطع شود.

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

در محیط‌های سازگار، OpenSSH از کلیدهای امنیتی مبتنی بر FIDO پشتیبانی می‌کند.

این کلیدها می‌توانند عملیات رمزنگاری حساس را به سخت‌افزار وابسته کنند.

بسته به نوع کلید و تنظیمات، استفاده از آن ممکن است نیازمند لمس فیزیکی، PIN یا تأیید کاربر باشد.

این روش می‌تواند خطر سوءاستفاده از کلیدهای خصوصی قابل‌کپی را کاهش دهد.

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

امنیت کلیدهای SSH و مدیریت چرخه عمر آن‌ها

امنیت SSH فقط در زمان ایجاد کلید معنا پیدا نمی‌کند.

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

چرا نباید یک کلید میان چند نفر مشترک باشد؟

استفاده چند مدیر از یک کلید خصوصی مشترک باعث می‌شود تفکیک هویت و پیگیری فعالیت‌ها دشوار شود.

اگر یکی از اعضای تیم سازمان را ترک کند، مشخص نیست کلید مشترک همچنان در اختیار چه کسانی قرار دارد.

در مقابل، اختصاص کلید مستقل به هر کاربر امکان لغو دسترسی فردی را فراهم می‌کند.

این موضوع برای تیم‌هایی که چند سرور یا چند محیط توسعه و عملیاتی دارند اهمیت بیشتری پیدا می‌کند.

محافظت از کلید خصوصی

برای کاهش خطر افشای کلید خصوصی باید چند اصل رعایت شود.

کلید خصوصی نباید در مخازن عمومی Git، فایل‌های قابل‌دسترسی وب، پیام‌رسان‌های ناامن یا اسناد اشتراکی بدون کنترل دسترسی ذخیره شود.

استفاده از Passphrase، ذخیره‌سازی محافظت‌شده و کنترل امنیت دستگاه کاربر ضروری است.

همچنین باید مراقب بود که نسخه‌های پشتیبان دستگاه، کلید خصوصی را بدون حفاظت کافی در محل دیگری کپی نکنند.

حذف کلیدهای غیرضروری

کلیدهای عمومی مجاز کاربران معمولاً در فایل authorized_keys یا سامانه‌های مدیریت هویت مربوط نگهداری می‌شوند.

وقتی کاربری دیگر به دسترسی نیاز ندارد، کلید مربوط به او باید از تمام محل‌های مجاز حذف شود.

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

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

ابزارهای استقرار خودکار، پشتیبان‌گیری و سرویس‌های CI/CD ممکن است از SSH استفاده کنند.

برای این موارد نباید بدون بررسی از کلید شخصی مدیر سرور استفاده شود.

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

در صورت امکان، باید فرمان‌های مجاز و مجوزهای مرتبط با کلیدهای خودکار محدود شوند.

جلوگیری از حملات مرد میانی با بررسی Host Key

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

این هشدار بخشی از سازوکار اعتماد به هویت سرور است.

Host Key چیست؟

Host Key کلیدی است که برای اثبات هویت سرور SSH استفاده می‌شود.

این کلید با کلید شخصی کاربر تفاوت دارد.

کلید کاربر برای احراز هویت نزد سرور استفاده می‌شود، در حالی که کلید میزبان به کلاینت کمک می‌کند تشخیص دهد با سرور مورد انتظار ارتباط برقرار کرده است.

چرا اثرانگشت کلید مهم است؟

اثر انگشت یا Fingerprint نمایشی فشرده از مشخصات رمزنگاری کلید است.

در اولین اتصال، بهتر است اثرانگشت کلید میزبان از مسیری معتبر و مستقل به دست آید.

برای مثال، مدیر دارای دسترسی قابل‌اعتماد به کنسول سرور می‌تواند اثرانگشت یکی از کلیدهای میزبان را بررسی کند.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

این دستور صرفاً نمونه‌ای برای سروری است که کلید میزبان Ed25519 در مسیر موردنظر دارد.

نتیجه باید با اطلاعات ارائه‌شده در کلاینت مقایسه شود.

هشدار تغییر Host Key را نادیده نگیرید

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

تغییر کلید ممکن است دلایل مشروعی مانند نصب مجدد سیستم‌عامل یا چرخش برنامه‌ریزی‌شده کلیدهای میزبان داشته باشد.

اما می‌تواند نشانه اتصال به سرور اشتباه یا تلاش برای جعل هویت نیز باشد.

غیرفعال‌کردن کنترل StrictHostKeyChecking برای حذف هشدارها یک راهکار امنیتی مناسب نیست.

محدودسازی دسترسی SSH با VPN و Bastion Host

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

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

استفاده از VPN

در این معماری، دسترسی SSH فقط از طریق یک شبکه خصوصی مجاز انجام می‌شود.

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

این روش می‌تواند سطح دسترسی عمومی SSH را کاهش دهد.

البته امنیت نهایی همچنان به پیکربندی VPN، مدیریت هویت کاربران، حفاظت از دستگاه‌ها و قوانین شبکه وابسته است.

Bastion Host چیست؟

Bastion Host یا Jump Server یک سرور واسط کنترل‌شده است که برای دسترسی مدیریتی به سایر سرورها استفاده می‌شود.

در چنین ساختاری، سرورهای داخلی الزاماً نیازی به داشتن پورت SSH عمومی ندارند.

مدیر ابتدا از مسیر مجاز به سرور واسط دسترسی پیدا می‌کند و سپس ارتباط مدیریتی مطابق سیاست‌های سازمان برقرار می‌شود.

مزیت این معماری، تمرکز بیشتر کنترل‌های دسترسی و قابلیت مدیریت مسیرهای ارتباطی است.

در مقابل، سرور واسط به یک جزء حساس امنیتی تبدیل می‌شود و باید با دقت محافظت و پایش شود.

چه زمانی استفاده از Bastion مناسب است؟

برای یک سرور آزمایشی کوچک، ممکن است معماری پیچیده چندمرحله‌ای ضروری نباشد.

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

هدف این معماری‌ها کاهش نقاط ورود و ایجاد کنترل دقیق‌تر بر دسترسی مدیریتی است.

نظارت بر لاگ‌های SSH و شناسایی فعالیت مشکوک

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

حتی اگر همه تنظیمات دفاعی اجرا شده باشند، بدون پایش مناسب ممکن است تلاش‌های نفوذ، استفاده غیرمجاز از حساب‌ها یا مشکلات احراز هویت دیر تشخیص داده شوند.

چه رویدادهایی اهمیت دارند؟

رویدادهای زیر معمولاً ارزش بررسی امنیتی دارند:

• افزایش غیرعادی تلاش‌های ناموفق ورود.
• تلاش برای ورود به حساب‌های ناشناخته.
• ورود موفق از مبدأ غیرمنتظره.
• تغییر ناگهانی الگوی ساعات ورود مدیران.
• ورود حسابی که مدت طولانی استفاده نشده است.
• تغییر فایل‌های کلیدهای مجاز.
• تغییرات غیرمنتظره در تنظیمات سرویس SSH.

البته یک رویداد به‌تنهایی همیشه نشانه نفوذ نیست. تحلیل باید با الگوی عادی فعالیت سرور و سایر شواهد همراه باشد.

بررسی گزارش‌ها با journalctl

در سرورهای مبتنی بر systemd می‌توان گزارش‌های مربوط به سرویس SSH را بررسی کرد.

برای نمونه، در اوبونتو:

sudo journalctl -u ssh.service --since "24 hours ago"

در برخی توزیع‌ها باید به‌جای ssh.service از نام سرویس مناسب استفاده شود.

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

بررسی اتصال‌های فعال

دستور زیر می‌تواند برای مشاهده سوکت‌های TCP در حالت شنود مفید باشد:

sudo ss -tlnp

مدیر سرور می‌تواند از این اطلاعات برای بررسی پورت‌های فعال و سرویس‌های مرتبط استفاده کند.

این بررسی به‌ویژه بعد از تغییر پورت SSH یا تنظیمات شبکه کاربرد دارد.

اهمیت هشداردهی خودکار

در سرورهای مهم، بررسی دستی گزارش‌ها به‌تنهایی کافی نیست.

بهتر است برای رویدادهای غیرعادی، هشدارهای متناسب با سطح حساسیت سرویس تعریف شود.

برای مثال، افزایش قابل‌توجه تلاش‌های ورود، اضافه‌شدن کلید جدید به یک حساب مدیریتی یا تغییر فایل پیکربندی SSH می‌تواند باعث تولید هشدار شود.

در محیط‌های سازمانی، ارسال رویدادها به سامانه ثبت وقایع متمرکز یا SIEM امکان بررسی و همبستگی بهتر رخدادها را فراهم می‌کند.

مدیریت دسترسی کاربران بر اساس اصل Least Privilege

اصل Least Privilege یا حداقل سطح دسترسی می‌گوید هر کاربر و سرویس فقط باید مجوزهایی را داشته باشد که برای انجام وظایف واقعی خود نیاز دارد.

اجرای این اصل، یکی از مهم‌ترین روش‌های کاهش خسارت احتمالی پس از افشای اطلاعات احراز هویت است.

جداسازی حساب‌های مدیریتی و عملیاتی

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

به همین ترتیب، سرویس‌های خودکار نباید بدون ضرورت از حساب دارای دسترسی گسترده استفاده کنند.

تفکیک حساب‌ها کمک می‌کند هر دسترسی بر اساس نقش واقعی آن مدیریت شود.

بررسی مجوزهای sudo

در سیستم‌هایی که از sudo استفاده می‌کنند، می‌توان مجوزهای مؤثر حساب فعلی را بررسی کرد.

sudo -l

داشتن دسترسی SSH لزوماً به معنی مجوز اجرای دستورات مدیریتی نیست.

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

بنابراین کنترل SSH و کنترل sudo باید مکمل یکدیگر باشند.

محدودسازی حساب‌های انتقال فایل

در بعضی سرورها، کاربران صرفاً به SFTP نیاز دارند.

برای چنین حساب‌هایی می‌توان از معماری‌های محدودشده مانند SFTP-only و سیاست‌های مناسب Match، ForceCommand یا Chroot استفاده کرد.

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

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

اهمیت به‌روزرسانی OpenSSH و سیستم‌عامل

امنیت SSH تنها به تنظیمات فایل sshd_config وابسته نیست.

وضعیت نرم‌افزار سرور، کتابخانه‌های رمزنگاری، اجزای احراز هویت و حتی سیستم‌عامل نیز بر امنیت ارتباط تأثیر می‌گذارد.

چرا به‌روزرسانی اهمیت دارد؟

آسیب‌پذیری‌های نرم‌افزاری ممکن است در شرایط خاص امکان اختلال در سرویس، دورزدن محدودیت‌ها یا اجرای رفتارهای ناخواسته را فراهم کنند.

انتشار اصلاحیه‌های امنیتی به مدیران کمک می‌کند خطرهای شناخته‌شده را کاهش دهند.

بااین‌حال، به‌روزرسانی بدون برنامه در سرور تولید نیز می‌تواند خطر عملیاتی داشته باشد.

بهتر است اصلاحیه‌ها بر اساس شدت آسیب‌پذیری، میزان در معرض بودن سرویس و حساسیت محیط اولویت‌بندی شوند.

بررسی نسخه OpenSSH

برای مشاهده نسخه کلاینت نصب‌شده می‌توان از دستور زیر استفاده کرد:

ssh -V

این خروجی لزوماً اطلاعات کامل بسته سرور یا اصلاحیه‌های اعمال‌شده توسط توزیع را نشان نمی‌دهد.

برای ارزیابی امنیتی باید نسخه بسته openssh-server و اطلاعات امنیتی همان توزیع نیز بررسی شود.

آیا باید الگوریتم‌های رمزنگاری را دستی تغییر داد؟

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

تغییر دستی فهرست الگوریتم‌ها بدون شناخت نسخه و سیاست رمزنگاری می‌تواند باعث کاهش سازگاری یا حتی انتخاب تنظیمات نامناسب شود.

بهتر است ابتدا وضعیت واقعی الگوریتم‌های فعال و الزامات امنیتی محیط مشخص شود.

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

امنیت SSH در سرورهای وردپرس و ووکامرس

امنیت دسترسی SSH برای سرورهای میزبانی وب‌سایت اهمیت ویژه‌ای دارد؛ زیرا این دسترسی می‌تواند در سطح سیستم‌عامل، بسیار گسترده‌تر از پنل مدیریت وردپرس باشد.

چرا امنیت SSH با امنیت وردپرس ارتباط دارد؟

WordPress یک سیستم مدیریت محتواست که روی وب‌سرور و زیرساخت سیستم‌عامل اجرا می‌شود.

اگر مهاجم به حساب مدیریتی سرور دسترسی پیدا کند، ممکن است بتواند فایل‌های وب‌سایت، تنظیمات سرویس‌ها و در شرایطی اطلاعات حساس مرتبط با پایگاه داده را مشاهده یا تغییر دهد.

در این وضعیت، حتی وجود رمز عبور قوی برای پیشخوان وردپرس نیز به‌تنهایی از زیرساخت محافظت نمی‌کند.

حفاظت از فایل‌های حساس سایت

فایل‌هایی مانند wp-config.php ممکن است شامل اطلاعات اتصال به پایگاه داده و سایر تنظیمات حساس باشند.

محافظت از این فایل‌ها به مالکیت صحیح، مجوزهای سیستم‌فایل، جداسازی کاربران و پیکربندی وب‌سرور وابسته است.

امنیت SSH می‌تواند یکی از لایه‌های جلوگیری از دسترسی غیرمجاز به این اطلاعات باشد.

بااین‌حال، استفاده از SSH امن جایگزین مجوزدهی صحیح فایل‌ها یا به‌روزرسانی هسته، افزونه‌ها و قالب‌های وردپرس نیست.

سرورهای فروشگاهی چه ملاحظاتی دارند؟

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

به همین دلیل، بهتر است دسترسی‌های مدیریتی به افراد مشخص محدود شود و فعالیت‌های حساس قابلیت پیگیری داشته باشند.

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

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

برای ارزیابی اولیه امنیت SSH می‌توان از چک‌لیست زیر استفاده کرد.

احراز هویت و مدیریت حساب‌ها

• [ ] ورود مستقیم Root بر اساس سیاست امنیتی محدود یا غیرفعال شده است.
• [ ] حساب مدیریتی مستقل و آزمایش‌شده وجود دارد.
• [ ] احراز هویت با کلید عمومی به‌درستی فعال است.
• [ ] ورود با رمز عبور در صورت عدم نیاز غیرفعال شده است.
• [ ] روش Keyboard-Interactive با سیاست احراز هویت هماهنگ است.
• [ ] کلیدهای خصوصی با روش مناسب محافظت می‌شوند.
• [ ] هر مدیر دارای هویت و کلید مستقل است.
• [ ] دسترسی کاربران غیرفعال حذف شده است.
• [ ] حساب‌های حساس در صورت نیاز از MFA استفاده می‌کنند.

تنظیمات شبکه و سرویس

• [ ] فایروال فقط دسترسی‌های موردنیاز را مجاز می‌کند.
• [ ] قوانین IPv4 و IPv6 بررسی شده‌اند.
• [ ] دسترسی SSH عمومی در صورت امکان محدود شده است.
• [ ] گزینه‌های غیرضروری Forwarding غیرفعال هستند.
• [ ] تنظیمات محدودیت تلاش ورود بررسی شده‌اند.
• [ ] پیکربندی مؤثر OpenSSH با تنظیمات مورد انتظار مطابقت دارد.
• [ ] تغییر پورت، در صورت انجام، با فایروال و سرویس هماهنگ است.

نظارت و نگهداری

• [ ] گزارش‌های احراز هویت در دسترس و قابل‌بررسی هستند.
• [ ] رویدادهای مشکوک پایش می‌شوند.
• [ ] نرم‌افزار OpenSSH اصلاحیه‌های امنیتی لازم را دریافت می‌کند.
• [ ] کلیدهای میزبان از مسیر قابل‌اعتماد تأیید می‌شوند.
• [ ] از تنظیمات مهم نسخه پشتیبان وجود دارد.
• [ ] روش بازیابی دسترسی آزمایش شده است.
• [ ] تغییرات پیکربندی پیش از اعمال اعتبارسنجی می‌شوند.

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

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

بعضی اقدامات ظاهراً امنیتی، اگر بدون بررسی انجام شوند، ممکن است باعث ایجاد اختلال یا احساس امنیت کاذب شوند.

غیرفعال‌کردن رمز عبور قبل از آزمایش کلید

این اشتباه یکی از دلایل رایج قطع دسترسی مدیریتی است.

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

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

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

اشتراک کلید خصوصی میان چند مدیر باعث کاهش قابلیت پیگیری فعالیت‌ها و دشوارشدن لغو دسترسی افراد می‌شود.

راهکار مناسب، تخصیص هویت و کلید مستقل به هر کاربر است.

تکیه کامل بر تغییر پورت

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

این روش نباید جایگزین احراز هویت کلیدی یا کنترل شبکه شود.

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

نصب ابزار امنیتی به معنی فعال‌بودن حفاظت مؤثر نیست.

اگر گزارش‌ها از منبع اشتباه خوانده شوند یا قوانین مسدودسازی اعمال نشوند، ممکن است ابزار اثر مورد انتظار را نداشته باشد.

غیرفعال‌کردن کنترل Host Key

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

هشدارهای مربوط به هویت سرور باید بررسی شوند، نه اینکه صرفاً حذف شوند.

تنظیم مجوزهای بیش‌ازحد گسترده

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

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

ایجاد محدودیت‌های سخت‌گیرانه بدون توجه به عملیات

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

امنیت باید با پایداری و نیازهای واقعی سرویس متوازن باشد.

نادیده‌گرفتن حساب‌های خودکار

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

ارزیابی امنیت SSH باید تمام حساب‌های انسانی و ماشینی را پوشش دهد.

ویرایش فایل اشتباه

در بعضی توزیع‌ها، تنظیمات از چند فایل مختلف خوانده می‌شوند.

همچنین قوانین شرطی Match ممکن است نتیجه نهایی را برای کاربران مختلف تغییر دهند.

بررسی صرف محتوای فایل اصلی کافی نیست و باید پیکربندی مؤثر سرویس کنترل شود.

آموزش گام‌به‌گام امن‌سازی SSH برای مدیر سرور

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

مرحله اول: شناسایی وضعیت فعلی

ابتدا کاربران، روش‌های ورود، پورت‌ها و سرویس‌های وابسته به SSH را شناسایی کنید.

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

این مرحله مانع حذف ناخواسته دسترسی‌های ضروری می‌شود.

مرحله دوم: تهیه نسخه پشتیبان

از فایل‌های پیکربندی اصلی، تنظیمات تکمیلی و اطلاعات لازم برای بازیابی دسترسی نسخه پشتیبان تهیه کنید.

در سرورهای ابری، امکانات کنسول اضطراری ارائه‌دهنده را نیز بررسی کنید.

مرحله سوم: ایجاد حساب مدیریتی مستقل

اگر تمام مدیریت از طریق Root انجام می‌شود، حساب مستقلی ایجاد کنید.

مجوزهای موردنیاز را به آن اختصاص دهید و از دسترسی بیش‌ازحد خودداری کنید.

مرحله چهارم: راه‌اندازی احراز هویت کلیدی

برای مدیران، کلیدهای مستقل ایجاد کنید.

کلیدهای عمومی را در حساب‌های مربوط ثبت کرده و حفاظت از کلیدهای خصوصی را بررسی کنید.

مرحله پنجم: آزمایش ورود جدید

از یک نشست جداگانه با حساب جدید وارد شوید.

علاوه بر ورود، مجوزهای عملیاتی موردنیاز را آزمایش کنید.

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

مرحله ششم: محدودکردن روش‌های ورود

پس از اطمینان از عملکرد کلیدها، ورود مستقیم Root و روش‌های احراز هویت غیرضروری را مطابق سیاست امنیتی محدود کنید.

اگر MFA استفاده می‌شود، تنظیمات مربوط باید با طراحی آن هماهنگ باشند.

مرحله هفتم: اعمال محدودیت شبکه

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

مسیر IPv6، فایروال ابری و نیازهای سرویس‌های خودکار را نیز در نظر بگیرید.

مرحله هشتم: کاهش قابلیت‌های غیرضروری

امکاناتی مانند X11 Forwarding، TCP Forwarding و Agent Forwarding را ارزیابی کنید.

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

مرحله نهم: اعتبارسنجی و اعمال تغییرات

پیکربندی را با ابزارهای OpenSSH بررسی کنید.

پس از تأیید، تغییرات را با روش مناسب بارگذاری کنید.

سپس اتصال تازه را از مبدأ مجاز آزمایش کنید.

مرحله دهم: پایش و مستندسازی

پس از اجرای تغییرات، گزارش‌های ورود و وضعیت سرویس را بررسی کنید.

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

این اطلاعات هنگام عیب‌یابی یا رسیدگی به رخدادهای امنیتی ارزش زیادی دارند.

خطاهای رایج SSH پس از اعمال تنظیمات امنیتی

بعد از تغییر تنظیمات ممکن است برخی کاربران با خطاهای اتصال مواجه شوند.

هر خطا لزوماً نشانه حمله یا خرابی نرم‌افزار نیست.

عیب‌یابی با اطلاعات سمت کلاینت

کلاینت OpenSSH می‌تواند جزئیات بیشتری درباره فرایند اتصال ارائه کند.

برای بررسی یک اتصال مجاز از گزینه Verbose استفاده می‌شود:

ssh -v [email protected]

در صورت نیاز می‌توان سطح جزئیات را افزایش داد.

این اطلاعات به تشخیص مرحله شکست اتصال کمک می‌کنند، اما ممکن است شامل داده‌های فنی حساس درباره محیط باشند و نباید بدون بررسی عمومی منتشر شوند.

چرا بررسی سمت سرور ضروری است؟

پیام خطای کلاینت همیشه علت دقیق مشکل را مشخص نمی‌کند.

برای مثال، شکست احراز هویت کلیدی می‌تواند ناشی از مجوزهای فایل، محدودیت حساب، سیاست‌های PAM، قوانین Match یا کلید عمومی اشتباه باشد.

بنابراین عیب‌یابی دقیق باید اطلاعات کلاینت و گزارش‌های سرور را کنار هم قرار دهد.

امنیت SSH در محیط‌های سازمانی و زیرساخت‌های بزرگ

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

به همین دلیل، سازمان‌ها معمولاً به سازوکارهای متمرکزتری برای کنترل دسترسی نیاز دارند.

استفاده از SSH Certificate

OpenSSH از گواهی‌های SSH پشتیبانی می‌کند که با گواهی‌های رایج TLS وب‌سایت‌ها یکسان نیستند.

در این معماری، یک مرجع صدور گواهی قابل‌اعتماد می‌تواند کلیدهای کاربران را برای مدت و شرایط مشخص امضا کند.

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

این رویکرد می‌تواند مدیریت دسترسی‌های کوتاه‌مدت و کاهش وابستگی به ثبت دستی تعداد زیادی کلید عمومی را ساده‌تر کند.

البته حفاظت از کلید مرجع صدور و طراحی فرایند لغو دسترسی اهمیت بسیار زیادی دارد.

دسترسی موقت و Just-in-Time

در الگوی Just-in-Time، دسترسی مدیریتی در صورت نیاز و برای مدت مشخصی صادر می‌شود.

این روش می‌تواند مدت‌زمان وجود مجوزهای دائمی را کاهش دهد.

برای نمونه، یک کارشناس ممکن است فقط هنگام رسیدگی به درخواست پشتیبانی، دسترسی محدود و تأییدشده دریافت کند.

پس از پایان بازه مجاز، دسترسی باید مطابق سیاست سازمان خاتمه یابد.

ثبت و حسابرسی فعالیت‌های مدیریتی

در سازمان‌های حساس، ثبت موفقیت یا شکست ورود SSH تنها بخشی از نیاز حسابرسی است.

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

این نیاز را می‌توان با ابزارهای حسابرسی سیستم‌عامل، ثبت وقایع متمرکز و کنترل‌های مدیریتی تکمیل کرد.

باید توجه داشت که SSH به‌تنهایی یک سامانه کامل ضبط و حسابرسی تمام فرمان‌ها نیست.

مقایسه مهم‌ترین روش‌های افزایش امنیت SSH

هر راهکار امنیتی، نوع خاصی از خطر را کاهش می‌دهد.

برای انتخاب ترکیب مناسب، باید اثر واقعی و محدودیت هر روش مشخص باشد.

بهترین نتیجه معمولاً از ترکیب چند کنترل مکمل حاصل می‌شود.

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

سؤالات متداول درباره امنیت SSH

امنیت SSH چیست؟

امنیت SSH شامل تنظیمات، کنترل‌ها و فرایندهایی است که از دسترسی غیرمجاز به سرور از طریق Secure Shell جلوگیری می‌کنند. مدیریت امن کلیدها، محدودسازی کاربران، کنترل شبکه، احراز هویت مناسب و پایش رویدادها از اجزای اصلی آن هستند.

آیا SSH به‌صورت پیش‌فرض امن است؟

SSH در طراحی خود از رمزنگاری و سازوکارهای احراز هویت امن استفاده می‌کند، اما امنیت عملی آن به نسخه نرم‌افزار، تنظیمات سرور، روش ورود و حفاظت از کلیدها وابسته است. تنظیمات پیش‌فرض برای تمام محیط‌ها الزاماً کافی نیستند.

بهترین روش احراز هویت SSH چیست؟

برای بسیاری از سرورها، احراز هویت با کلید عمومی و حفاظت مناسب از کلید خصوصی، انتخاب مناسبی است. در محیط‌های حساس می‌توان از کلیدهای سخت‌افزاری، MFA و محدودیت شبکه نیز استفاده کرد.

آیا غیرفعال‌کردن ورود Root ضروری است؟

در بیشتر سرورهایی که حساب مدیریتی مستقل دارند، غیرفعال‌کردن ورود مستقیم Root اقدام مناسبی است. بااین‌حال، پیش از آن باید حساب جایگزین و دسترسی موردنیاز آزمایش شده باشد.

آیا تغییر پورت SSH جلوی هک سرور را می‌گیرد؟

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

آیا Fail2Ban برای امنیت SSH کافی است؟

خیر. Fail2Ban می‌تواند تلاش‌های ورود تکراری را محدود کند، اما جایگزین کلیدهای امن، فایروال، به‌روزرسانی و کنترل دسترسی کاربران نیست.

تفاوت PasswordAuthentication و PubkeyAuthentication چیست؟

گزینه PasswordAuthentication ورود با روش رمز عبور را کنترل می‌کند، در حالی که PubkeyAuthentication امکان احراز هویت با کلید عمومی را تعیین می‌کند. انتخاب روش مناسب باید با سیاست کلی احراز هویت سرور هماهنگ باشد.

آیا SSH Key بدون Passphrase امن است؟

کلید بدون Passphrase می‌تواند در بعضی فرایندهای خودکار کاربرد داشته باشد، اما در صورت افشای فایل خصوصی، حفاظت کمتری دارد. برای دسترسی انسانی معمولاً استفاده از Passphrase مناسب یا سازوکارهای سخت‌افزاری محافظت‌شده توصیه می‌شود.

آیا استفاده از VPN برای SSH ضروری است؟

برای همه سرورها الزامی نیست، اما در محیط‌های حساس می‌تواند سطح دسترسی عمومی را کاهش دهد. انتخاب VPN، Bastion یا دسترسی مستقیم محدودشده باید بر اساس نیاز عملیاتی و مدل تهدید انجام شود.

اگر پس از تغییر تنظیمات SSH دسترسی قطع شود چه باید کرد؟

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

آیا غیرفعال‌کردن SSH امنیت سرور را بیشتر می‌کند؟

اگر سرور اصلاً به SSH نیاز ندارد، غیرفعال‌کردن سرویس می‌تواند سطح حمله را کاهش دهد. اما در سرورهایی که مدیریت از راه دور ضروری است، باید به‌جای حذف بدون برنامه سرویس، دسترسی آن را به‌درستی محدود و محافظت کرد.

هر چند وقت یک بار باید امنیت SSH بررسی شود؟

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

جمع‌بندی؛ بهترین راهکار برای افزایش امنیت SSH چیست؟

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

برای امن‌سازی SSH سرور باید ابتدا روش احراز هویت بررسی شود. استفاده از کلید عمومی، حفاظت از کلید خصوصی و محدودکردن روش‌های ورود غیرضروری می‌تواند بخش مهمی از خطرهای مرتبط با رمز عبور را کاهش دهد.

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

فایروال، VPN و Bastion Host نیز می‌توانند سطح دسترسی شبکه را کاهش دهند. ابزارهایی مانند Fail2Ban و سامانه‌های پایش گزارش‌ها در کنار این کنترل‌ها، به شناسایی و محدودکردن فعالیت‌های مشکوک کمک می‌کنند.

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

نکته بسیار مهم این است که افزایش امنیت SSH نباید با از دست رفتن کنترل سرور همراه شود. تمام تغییرات حساس باید با نسخه پشتیبان، امکان بازیابی و آزمایش اتصال جدید انجام شوند.

در نهایت، امن‌ترین پیکربندی SSH لزوماً سخت‌گیرانه‌ترین تنظیمات ممکن نیست؛ بلکه ترکیبی متناسب از رمزنگاری مناسب، احراز هویت مطمئن، دسترسی محدود، نظارت مستمر و قابلیت بازیابی است.

برای مدیران سرورهای وردپرس و ووکامرس، اجرای این اصول بخشی ضروری از امنیت کل زیرساخت محسوب می‌شود؛ زیرا محافظت از وب‌سایت بدون محافظت از مسیرهای دسترسی مدیریتی کامل نخواهد بود.