روش ایمن‌سازی SSH در VPS

چرا SSH اولین اولویت برای ایمن‌سازی است

SSH ابزاری است که با آن سرور خود را کنترل می‌کنید؛ به همین دلیل، این سرویس اولین هدفی است که هر مهاجمی برای ورود امتحان می‌کند. به محض آنلاین شدن یک VPS، اسکنرها شروع به حدس زدن نام کاربری و رمز عبور در port 22 می‌کنند. شما می‌توانید شاهد این اتفاق در لاگ‌های خود در عرض چند دقیقه باشید. ایمن‌سازی SSH یعنی حذف مواردی که مهاجمان می‌توانند حدس بزنند: قابلیت login با password را کاملاً غیرفعال کنید، login با root را غیرفعال کنید و فقط اجازه ورود با cryptographic keys را بدهید. پس از انجام این کار، تلاش‌های مداوم برای حدس زدن رمز عبور شکست می‌خورند، زیرا دیگر رمزی برای یافتن وجود ندارد.

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

مرحله 1: ابتدا از کارکرد صحیح احراز هویت با کلید اطمینان حاصل کنید

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

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

ssh-keygen -t ed25519

بخش عمومی کلید را به سرور کپی کنید:

ssh-copy-id user@your-server

سپس یک session SSH جدید باز کنید. اگر بدون درخواست رمز عبور اجازه ورود داد، کلید شما کار می‌کند و می‌توانید با خیال راحت رمز عبور را خاموش کنید. اگر با کلیدها آشنا نیستید یا از بیش از یک کامپیوتر استفاده می‌کنید، مبانی مدیریت SSH key مدل کامل را توضیح می‌دهد: یک کلید برای هر دستگاه، مجوزهای مورد نیاز sshd، و نحوه لغو دسترسی یک کلید در صورت گم شدن لپ‌تاپ.

Step 2: Harden sshd with a drop-in file

فایل /etc/ssh/sshd_config را مستقیماً ویرایش نکنید. Ubuntu 24.04 فایل‌های drop-in را از /etc/ssh/sshd_config.d/ می‌خواند. استفاده از یک فایل کوچک در آن مسیر، تمیزتر است، در هنگام ارتقای پکیج‌ها باقی می‌ماند و در صورت بروز مشکل، حذف آن آسان است. نام فایل اهمیت دارد: sshd اولین مقداری را که برای هر تنظیم می‌خواند نگه می‌دارد؛ و Ubuntu cloud images فایل 50-cloud-init.conf را با PasswordAuthentication yes در این دایرکتوری ارائه می‌دهند. نام فایل خود را 00- بگذارید تا قبل از آن فایل مرتب شود و اولویت داشته باشد؛ یک فایل 99- بدون اطلاع، نادیده گرفته می‌شود. یک فایل بسازید:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

این را در آن قرار دهید:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

هر خط یک راه ورود را می‌بندد. PasswordAuthentication no مهم‌ترین مورد است: با غیرفعال کردن password، حملات brute-force چیزی برای حمله ندارند. KbdInteractiveAuthentication no مسیر دوم مبتنی بر password را می‌بندد. PermitRootLogin no به این معناست که مهاجم باید نام کاربری شما را بداند و کلید شما را داشته باشد، نه اینکه فقط یک حساب کاربری واحد یعنی root را که در همه سیستم‌ها وجود دارد، هدف قرار دهد.

Step 3: Test the config, then reload

پیش از اعمال تنظیمات، فایل config را برای یافتن خطا بررسی کنید تا اشتباه تایپی باعث از کار افتادن service نشود:

sudo sshd -t

اگر خروجی خالی بود، config معتبر است. SSH را reload کنید:

sudo systemctl reload ssh

سپس تنظیماتی که sshd واقعاً از آن‌ها استفاده می‌کند را بررسی کنید تا از اعمال تنظیمات در فایل‌های دیگر (drop-in) که باعث نادیده گرفته شدن تنظیمات شما شده باشند، مطمئن شوید:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

هر دو باید no باشند. اکنون، بدون بستن session فعلی، یک session جدید از یک terminal دیگر باز کنید. اگر با استفاده از key وارد شدید، کار تمام است. اگر مشکلی وجود داشت، session اول شما همچنان باز است تا بتوانید آن را اصلاح کنید. این هم‌پوشانی یک شبکه ایمنی است، پس هرگز از آن چشم‌پوشی نکنید.

Step 4: پورت غیر استاندارد اختیاری

تغییر پورت SSH از 22 به پورت‌هایی مانند 2222 امنیت واقعی ایجاد نمی‌کند، زیرا یک مهاجم مصمم تمام پورت‌ها را اسکن می‌کند. این کار تنها باعث کاهش نویز در logها می‌شود، زیرا اکثر اسکنرهای خودکار فقط پورت 22 را بررسی می‌کنند. اگر مایل به این کار هستید، ابتدا Port 2222 را به فایل drop-in خود اضافه کنید، پورت جدید را در firewall مجاز کنید، سپس sudo systemctl daemon-reload && sudo systemctl restart ssh.socket را اجرا کرده و با استفاده از ssh -p 2222 متصل شوید. در Ubuntu 24.04، سرویس ssh.socket مالک پورت شنود است، بنابراین یک دستور ساده‌ی reload ssh باعث باقی ماندن sshd روی پورت 22 می‌شود؛ برای اعمال پورت جدید، باید socket را restart کنید. این کار را به عنوان یک اقدام برای نظم‌بخشی در نظر بگیرید، نه یک اقدام حفاظتی.

Step 5: لایه‌های دفاعی اضافی را اضافه کنید

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

Fail2ban لاگ‌های شما را بررسی می‌کند و آدرس‌هایی که مدام در ورود شکست می‌خورند را مسدود می‌کند؛ این کار باعث کاهش نویز اسکنرها و اخراج زودهنگام آن‌ها می‌شود. این ابزار با روش احراز هویت فقط با کلید (key-only auth) هماهنگی کامل دارد: نصب Fail2ban در Ubuntu برای توقف حملات SSH را ببینید.

روش قدرتمندتر، قطع دسترسی کامل SSH از اینترنت عمومی است. اگر شما SSH را پشت یک WireGuard VPN قرار دهید و پورت 22 را فقط برای تونل محدود کنید، هیچ فردی خارج از VPN حتی نمی‌تواند به آن دسترسی داشته باشد؛ در این حالت، حملات brute-force به جای دشوار شدن، غیرممکن می‌شوند. تمام این موارد مستلزم داشتن یک فایروال با تنظیمات default-deny است که در تنظیم UFW روی VPS توضیح داده شده است.

SSH تنها یکی از مراحل یک چک‌لیست بزرگتر است: اولین 10 دقیقه در یک VPS جدید مراحل را به ترتیب قرار می‌دهد و به‌روزرسانی‌های امنیتی خودکار در Ubuntu سیستم را در ادامه نیز پچ و ایمن نگه می‌دارد.

FAQ

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

یک فایل drop-in در /etc/ssh/sshd_config.d/00-hardening.conf ایجاد کنید (پیشوند 00 باعث می‌شود این فایل قبل از 50-cloud-init.conf مرتب شود؛ در غیر این صورت مقدار PasswordAuthentication yes برنده می‌شود، زیرا sshd اولین مقداری را که می‌خواند نگه می‌دارد) که شامل PasswordAuthentication no و KbdInteractiveAuthentication no باشد. دستور sudo sshd -t را برای بررسی اجرا کنید و سپس sudo systemctl reload ssh را اجرا کنید. قبل از اینکه به آن اعتماد کنید، مطمئن شوید که ورود با کلید در یک session جدید کار می‌کند. ویرایش یک فایل drop-in به جای sshd_config باعث می‌شود تنظیمات شما پس از ارتقای پکیج باقی بماند و بازگرداندن آن آسان باشد.

آیا باید ورود root را از طریق SSH غیرفعال کنم؟

بله. مقدار PermitRootLogin no را تنظیم کنید تا هیچ‌کس نتواند مستقیماً به عنوان root وارد شود. با کاربر معمولی خود وارد شوید و از sudo برای کارهای مدیریتی استفاده کنید. کاربر root در هر سیستم لینوکسی وجود دارد، بنابراین در دسترس نگه داشتن آن، یک نام کاربری مشخص را در اختیار مهاجم قرار می‌دهد. غیرفعال کردن آن یعنی مهاجم باید نام حساب شما را بداند و کلید شما را داشته باشد.

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

به طور معناداری خیر. تغییر پورت از 22، شما را از اسکنرهای بی‌دقتی که فقط پورت 22 را بررسی می‌کنند مخفی می‌کند و نویز لاگ‌ها را کاهش می‌دهد، اما یک مهاجم واقعی تمام پورت‌ها را اسکن می‌کند و آن را پیدا می‌کند. احراز هویت فقط با کلید (key-only authentication) است که واقعاً جلوی ورود غیرمجاز را می‌گیرد. اگر پورت را تغییر دادید، ابتدا پورت جدید را در فایروال باز کنید و سپس sudo systemctl daemon-reload && sudo systemctl restart ssh.socket را اجرا کنید؛ در Ubuntu 24.04، socket مالک listener است و یک reload ساده باعث می‌شود sshd همچنان روی پورت 22 باقی بماند.

اگر از SSH keys استفاده کنم، آیا به Fail2ban نیاز دارم؟

استفاده از آن اختیاری است اما همچنان مفید است. با احراز هویت فقط با کلید، حدس زدن رمز عبور نمی‌تواند موفقیت‌آمیز باشد، بنابراین Fail2ban عامل اصلی جلوگیری از ورود مهاجمان نیست. این ابزار تعداد دفعات شکست‌های مکرر از یک آدرس را محدود می‌کند که باعث کاهش نویز اسکنرها در لاگ‌ها و حذف مهاجمان تکراری در مراحل اولیه می‌شود؛ یک حمله کند و توزیع‌شده در هر صورت زیر آستانه مسدودسازی (ban threshold) آن باقی می‌ماند. آن را در کنار احراز هویت با کلید اجرا کنید و در حالت ایده‌آل، SSH را پشت یک VPN نگه دارید.

اگر خودم را از طریق SSH مسدود کردم، چگونه دسترسی را بازیابی کنم؟

از کنسول وب ارائه‌دهنده خود استفاده کنید که از طریق یک اتصال serial یا VNC به سرور متصل می‌شود و از طریق SSH عبور نمی‌کند. از آن طریق می‌توانید وارد شوید، فایل drop-in sshd را اصلاح کنید و سرویس را reload کنید. دقیقاً به همین دلیل است که باید تنظیمات جدید SSH را در یک ترمینال دوم تست کنید و قبل از بستن session اول، مطمئن شوید که احراز هویت با کلید از قبل کار می‌کند.