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

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

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

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

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

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

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

ssh-keygen -t ed25519

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

ssh-copy-id user@your-server

سپس یک نشست SSH جدید باز کنید. اگر بدون درخواست رمز عبور به شما اجازه ورود داد، کلید شما کار می‌کند و با خیال راحت می‌توانید رمزهای عبور را غیرفعال کنید. اگر با خطای Permission denied (publickey) مواجه شدید، آن خطا پنج نقص مختلف را پنهان می‌کند و خروجی ssh -v به شما می‌گوید که پیش از تغییر هر چیز دیگری، با کدام یک مواجه هستید. اگر کلیدها برای شما تازگی دارند یا از بیش از یک کامپیوتر استفاده می‌کنید، اصول مدیریت کلید SSH مدل کامل آن را توضیح می‌دهد: یک کلید برای هر دستگاه، مجوزهایی که sshd مطالبه می‌کند، و نحوه ابطال کلید در صورتی که لپ‌تاپ گم شود.

گام 2: ایمن‌سازی sshd با استفاده از یک فایل drop-in

فایل /etc/ssh/sshd_config را مستقیماً ویرایش نکنید. سیستم‌عامل Ubuntu 24.04 فایل‌های drop-in را از مسیر /etc/ssh/sshd_config.d/ می‌خواند. یک فایل کوچک در این مسیر، تمیزتر است، در هنگام ارتقای بسته‌ها دست‌نخورده باقی می‌ماند و در صورت بروز مشکل، به‌راحتی قابل حذف است. نام فایل اهمیت دارد: sshd اولین مقداری را که برای هر تنظیم می‌خواند، اعمال می‌کند. تصاویر ابری Ubuntu فایلی به نام 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 مهم‌ترین مورد است: با غیرفعال کردن رمز عبور، حملات brute-force دیگر هدفی برای اجرا ندارند. KbdInteractiveAuthentication no مسیر دوم مبتنی بر رمز عبور را مسدود می‌کند. PermitRootLogin no به این معناست که مهاجم باید علاوه بر داشتن کلید شما، نام کاربری‌تان را نیز بداند و نمی‌تواند صرفاً حساب کاربری root را که در تمام سرورها وجود دارد، هدف قرار دهد.

گام 3: تست پیکربندی و سپس بارگذاری مجدد

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

sudo sshd -t

sudo sshd -t

اگر خروجی نمایش داده نشد، پیکربندی معتبر است. SSH را بارگذاری مجدد کنید:

sudo systemctl reload ssh

sudo systemctl reload sshd

سپس تنظیماتی را که sshd در حال حاضر استفاده می‌کند بررسی کنید تا مطمئن شوید فایل‌های drop-in جایگزین تنظیمات اصلی نشده باشند:

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

sshd -T | grep -E 'passwordauthentication|pubkeyauthentication'

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

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

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

گام 5: لایه‌بندی دفاع‌های تکمیلی

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

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

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

SSH تنها یک مورد از یک چک‌لیست بزرگ‌تر است: 10 دقیقه اول روی یک VPS جدید مراحل را به ترتیب مشخص می‌کند و به‌روزرسانی‌های امنیتی خودکار در Ubuntu سرور را پس از آن وصله (patch) نگه می‌دارند. قفل کردن درب ورودی برای سرویس‌های پشت آن کاری انجام نمی‌دهد؛ بنابراین اگر همین VPS یک password vault را اجرا می‌کند، یک بررسی امنیتی روی Vaultwarden دو موردی را که احراز هویت با کلید هرگز پوشش نمی‌دهد، ایمن می‌کند: توکن مدیریت و فایل پشتیبان آن.

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 را انجام دهید. پیش از آنکه به این روش تکیه کنید، در یک نشست جدید تأیید کنید که ورود با کلید به‌درستی کار می‌کند. ویرایش یک فایل drop-in به‌جای تغییر مستقیم sshd_config، باعث می‌شود تنظیمات شما در هنگام ارتقای بسته‌ها حفظ شود و بازگرداندن آن نیز آسان باشد.

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

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

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

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

آیا در صورت استفاده از کلیدهای SSH همچنان به Fail2ban نیاز دارم؟

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

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

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