اشتباهات رایج در امن سازی SSH که دسترسی سرور را به خطر می اندازد

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

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

برای راحت تر یادگرفتن، با یه تشبیه ساده جلو می ریم: SSH در ورودی ساختمونه. رمز ساده یعنی کلید زیر پادری. ورود root یعنی کلید مادری که همه می دونن کجاست. عوض کردن پورت هم یعنی عوض کردن شماره پلاک روی دری که قفل نداره.

۱. ورود با رمز: کلید زیر پادری

اشتباه معمول اینه که سرور رو با رمز می سازن و همون رو نگه می دارن، چون راحته. رمز «Shop1403» یادآوریش برای خودت ساده است، ولی برای ربات ها هم همین قدر ساده است.

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

sudo grep "Failed password" /var/log/auth.log | tail

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

راه درست: کلید SSH

روی سیستم خودت (نه روی سرور) یه جفت کلید بساز. الگوریتم Ed25519 این روزها انتخاب رایجیه، ولی پیش از استفاده سازگاریش رو با نسخه SSH سرورت چک کن:

ssh-keygen -t ed25519 -C "ali@laptop"
ssh-copy-id ali@SERVER_IP

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

رمز رو با احتیاط ببند

وقتی مطمئن شدی ورود با کلید کار می کنه، تو فایل /etc/ssh/sshd_config این رو بذار:

PasswordAuthentication no

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

۲. ورود مستقیم با root: کلید مادری که همه می دونن کجاست

خیلی ها همه کارها رو با root انجام می دن و ورود مستقیمش رو هم باز می ذارن. دلیلش معمولاً اینه که «همه چی بدون خطای دسترسی کار می کنه».

مشکل اینه که اسم کاربری root رو همه می دونن. مهاجم نصف کار رو انجام شده می بینه و فقط باید رمز یا کلید رو پیدا کنه. اشتباه تایپی هم با بالاترین سطح دسترسی اجرا می شه. یه rm اشتباه تو مسیر اشتباه، همون لحظه ای که می گی «کاش یه لایه بینش بود».

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

کاربر عادی با sudo جای root

یه کاربر عادی بساز، بهش sudo بده و ورود root رو ببند (دستورها برای دبیان و اوبونتو هستن؛ تو توزیع های دیگه گروه معمولاً wheel ه):

sudo adduser ali
sudo usermod -aG sudo ali

بعد تو sshd_config:

PermitRootLogin no

حالا هر دستور حساس با sudo و به اسم همون کاربر ثبت می شه. اگه ابزار یا اسکریپتی واقعاً به ورود root نیاز داره، حداقل اون رو فقط با کلید و نه رمز مجاز کن (PermitRootLogin prohibit-password). ولی اول مطمئن شو واقعاً لازمش داری.

۳. عوض کردن پورت: پلاک تازه روی دری که قفل نداره

بعضی ها پورت ۲۲ رو به یه عدد دیگه تغییر می دن و فکر می کنن کار تموم شده. این کار بی فایده نیست، ولی امن سازی هم نیست.

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

اگه خواستی پورت رو عوض کنی، این ترتیب رو رعایت کن:

1. پورت جدید رو اول تو فایروال باز کن.
2. بعد تنظیم SSH رو عوض کن و سرویس رو دوباره بارگذاری کن.
3. با یه نشست جدید ورود رو امتحان کن.
4. فقط بعد از موفقیت، پورت قدیمی رو ببند.

روی بعضی نسخه های جدید اوبونتو، تغییر پورت فقط با sshd_config جواب نمی ده. پیش از شروع مستند توزیع خودت رو ببین.

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

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

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

فایروال: فقط پورت های لازم باز باشه

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

مثال روی ufw (اول SSH رو مجاز کن، بعد فعالش کن):

sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

اگه آی پی ثابت داری (مثلاً دفتری با اینترنت ثابت)، می تونی SSH رو فقط برای همون آی پی باز کنی. ولی تو ایران خیلی از خط های خونگی آی پی عوض می کنن. اگه آی پی تو عوض بشه، یه روز صبح خودت پشت در می مونی. تو این حالت یا یه آی پی ثابت بگیر یا یه راه واسطه مثل VPN داشته باش.

محدود کردن تلاش های ناموفق

ابزاری مثل fail2ban بعد از چند تلاش ناموفق، آی پی مهاجم رو برای مدتی مسدود می کنه. تنظیم نمونه (عددها پیشنهادی هستن و بسته به نیازت عوض می شن):

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

یه نکته صادقانه: اگه ورود با رمز رو بستی، fail2ban جلوی نفوذ رو نمی گیره، چون رمزی برای حدس زدن نیست. کارش بیشتر کم کردن شلوغی لاگ هاست. در عوض می فهمی کی داره امتحان می کنه.

۵. کلیدها رو مثل خود سرور نگه دار

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

• کلید خصوصی رو برای همکار می فرستی. فایل کلیدی که تو پیام رسان رد و بدل بشه دیگه راز نیست. هر نفر باید کلید خودش رو بسازه و فقط بخش عمومی اش رو به سرور بده.
• یه کلید برای همه چی. اگه همون کلید برای سرور، گیت و ابزار انتشار استفاده بشه، با لو رفتنش همه چیز با هم می ریزه.
• کلید آدم های رفته هنوز تو سرور هست. وقتی یه همکار یا فریلنسر کارش تموم می شه، کلیدش رو از ~/.ssh/authorized_keys پاک کن. هر چند ماه یه بار این فایل رو بخون. کنار هر کلید یه توضیح (مثل اسم و سیستم) بذار تا بدونی مال کیه.
• حساب مشترک. چند نفر با یه کاربر کار می کنن و ردپایی نمی مونه. تو میزبانی چند سایت هم این دردسر پیش میاد؛ حساب مشترک چه خطرهایی داره رو جداگانه نوشتیم.

یه مثال از کار روزمره: گاهی دریافت ایمیج از Docker Hub و بعضی مخزن ها روی سرورهای داخل ایران به خاطر محدودیت ها درست کار نمی کنه. تو این مواقع ایمیج ها رو روی سیستم توسعه می سازیم و با SSH به سرور منتقل می کنیم. برای این کار یه کاربر مخصوص انتقال با کلید جدا لازم داری. یه هشدار هم داره: کاربری که تو گروه docker باشه عملاً معادل root است. پس کلیدش رو هم مثل کلید مدیر نگه دار.

۶. امن سازی SSH رو به ترتیب انجام بده، وگرنه خودت بیرون می مونی

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

ترتیب پیشنهادی:

1. یه نشست SSH باز نگه دار و تا آخر کار نبندش.
2. کاربر عادی بساز و sudo رو با یه نشست جدید امتحان کن.
3. کلید رو نصب کن و با یه نشست جدید ورود رو چک کن.
4. فایروال رو تنظیم کن و مطمئن شو پورت SSH مجازه.
5. حالا PasswordAuthentication و PermitRootLogin رو ببند.
6. تنظیمات رو بررسی کن و سرویس رو بارگذاری کن:

sudo sshd -t && sudo systemctl reload ssh

اسم سرویس بسته به توزیع فرق داره؛ تو بعضی ها sshd است. اگه sshd -t خطا داد، بارگذاری نکن و اول خطا رو درست کن.

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

سوالات متداول

کلید SSH بدون passphrase هم امنه؟

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

اگه کلید خصوصی رو گم کنم چی می شه؟

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

اگه ورود با رمز بسته باشه، باز هم fail2ban لازمه؟

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

از کجا بفهمم کسی سعی کرده وارد بشه؟

لاگ ورود سرور (مثلاً /var/log/auth.log یا journalctl -u ssh) تلاش های موفق و ناموفق رو نشون می ده. پیشنهاد می کنم هفته ای یه بار نگاهش کنی، یا برای هشدار خودکار از یه ابزار مانیتورینگ و پایداری استفاده کنی.

اگه فقط ده دقیقه وقت داری

اول کلید SSH بساز و ورود با رمز رو ببند. بعد یه کاربر عادی با sudo داشته باش و ورود root رو غیرفعال کن. فایروال رو طوری تنظیم کن که فقط پورت های لازم باز بمونن. پورت رو فقط برای کم کردن شلوغی لاگ عوض کن، نه برای امنیت. کلیدها رو هر چند ماه مرور کن و کلید آدم های رفته رو پاک کن.

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