#تنظیمات امنیتی اولیه

پیش از هر تغییری در تنظیمات SSH، یک بکاپ از فایل اصلی sshd_config بگیرید تا در صورت بروز مشکل، بدون دسترسی فیزیکی به سرور، بتوانید به حالت قبلی برگردید. این چک لیست بر اساس مستندات رسمی sshd_config(5) و دستورات استاندارد سیستم‌عامل اوبنتو تنظیم شده است.

bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

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

bash
sudo nano /etc/ssh/sshd_config

در فایل ویرایش‌شده، چهار پارامتر زیر را با مقادیر مشخص‌شده تنظیم کنید:

conf
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

تغییر پورت از 22 به 2222، حجم حملات خودکار (Brute-force) را کاهش می‌دهد. غیرفعال‌سازی ورود مستقیم با کاربر root، سطح دسترسی را محدود می‌کند و الزام استفاده از کلید عمومی (Key-based authentication)، ایمنی اتصال را افزایش می‌دهد.

bash
sudo sshd -t

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

bash
sudo systemctl restart ssh

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

bash
sudo ss -tlnp | grep ssh

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

bash
ssh -i ~/.ssh/id_rsa -p 2222 user@server_ip

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

نکته مهم: پس از اعمال تغییرات، حتماً یک ترمینال دوم را باز بگذارید تا در صورت بروز مشکل در اتصال، بتوانید از ترمینال اول به سرور دسترسی داشته باشید و تغییرات را اصلاح کنید.

خارج از محدوده این چک لیست:

  • تنظیم Fail2ban برای جلوگیری از حملات Brute-force
  • فعال‌سازی SELinux یا AppArmor
  • پیکربندی Firewalld یا UFW برای محدودسازی دسترسی شبکه
  • مدیریت کلیدهای عمومی و چرخه‌بندی آن‌ها

اشتباهات رایج:

  • فراموش کردن بکاپ قبل از تغییر پیکربندی
  • عدم تست اتصال با کلید عمومی قبل از بستن ترمینال فعلی
  • استفاده از پورت‌های غیراستاندارد بدون اطلاع‌رسانی به تیم‌های عملیاتی
  • عدم بررسی خروجی sshd -t قبل از ری‌استارت سرویس

#بررسی وضعیت فعلی و لگ‌ها قبل از هر تغییر

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

bash
sudo systemctl status ssh

این دستور وضعیت سرویس ssh را نشان می‌دهد. اگر در خروجی عبارت active (running) را می‌بینید، سرویس در حال کار است. اگر inactive یا failed دیدید، قبل از هر چیز باید علت را پیدا کنید.

bash
sudo ss -tlnp | grep ssh

این خط پورت‌های TCP فعال و فرآیند مربوط به آن‌ها را نشان می‌دهد. روی اوبنتو معمولاً :22 را می‌بینید. اگر پورت دیگری دیدید، یعنی قبلاً تغییر پورت انجام شده است.

bash
sudo journalctl -u ssh --since "$(date -d '1 day ago' +%Y-%m-%d)"

این دستور لاگ‌های سرویس ssh از یک روز گذشته را از journald می‌خواند. روی اوبنتو جدیدتر، جزئیات اتصال و خطاهای sshd اینجا ثبت می‌شوند.

bash
sudo grep -i "Failed password" /var/log/auth.log

این خط تلاش‌های ورود با رمز اشتباه را از /var/log/auth.log استخراج می‌کند. اگر تعداد زیادی از این خط‌ها را دیدید، احتمالاً سرور تحت حمله برزنی (Brute Force) قرار دارد.

bash
sudo grep -i "Invalid user" /var/log/auth.log

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

Jan 15 08:23:11 ubuntu sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 43210
Jan 15 08:23:12 ubuntu sshd[12346]: Invalid user root from 192.168.1.100 port 43211

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

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

#غیرفعال‌سازی ورود مستقیم با root

ورود مستقیم با root روی SSH ریسک بالایی دارد؛ اگر یک حمله Brute-Force موفق شود، مهاجم مستقیماً کنترل کامل سیستم را به دست می‌آورد. قبل از تغییر، مطمئن شوید که یک کاربر عادی با دسترسی sudo دارید، وگرنه بعد از غیرفعال‌سازی root، دیگر راه ورودی نخواهید داشت.

bash
sudo nano /etc/ssh/sshd_config

در فایل sshd_config، خط PermitRootLogin را پیدا کنید و مقدار آن را به no تغییر دهید:

conf
PermitRootLogin no

اگر این خط کامنت‌شده باشد، آن را غیرکامنت کنید و مقدار را تنظیم کنید.

bash
sudo systemctl restart ssh

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

bash
sudo systemctl restart sshd
bash
sudo grep -n 'PermitRootLogin' /etc/ssh/sshd_config

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

bash
sudo systemctl status ssh

این دستور وضعیت سرویس را نشان می‌دهد؛ اگر active (running) باشد، تغییر اعمال شده و سرویس بدون خطا بالا آمده است.

مرز کار این تغییر: غیرفعال‌سازی PermitRootLogin فقط ورود مستقیم با root را مسدود می‌کند؛ دسترسی sudo از طریق کاربر عادی همچنان فعال است. این کار Brute-Force را سخت‌تر می‌کند، اما اگر مهاجر یک کاربر عادی با رمز ضعیف پیدا کند، باز هم می‌تواند با sudo به root برسد. برای همین، این تغییر باید همراه با تغییر رمز قوی و فعال‌سازی کلید SSH انجام شود.

#تغییر پورت پیش‌فرض 22

پورت 22 هدف اصلی حملات brute-force است. با تغییر آن، ترافیک اسکن‌های عمومی از روی سرور شما رد می‌شود، هرچند این به‌تنهایی امنیت را تضمین نمی‌کند؛ فقط سطح نویز را کاهش می‌دهد.

bash
sudo nano /etc/ssh/sshd_config

در فایل sshd_config خط Port 22 را پیدا کنید و آن را به Port 2222 تغییر دهید. اگر خط Port وجود ندارد، در ابتدای فایل اضافه کنید.

bash
sudo systemctl restart ssh

سپس وضعیت شنود را بررسی کنید:

bash
sudo ss -tlnp | grep ssh

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

tcp LISTEN 0 128 0.0.0.0:2222 users:(("sshd",pid=1234,fd=3))

این خروجی تأیید می‌کند که سرویس SSH روی پورت جدید فعال شده و پورت 22 دیگر شنود نمی‌کند. اگر پورت 22 همچنان در لیست باشد، احتمالاً یک instance دیگر از sshd یا یک reverse proxy در حال شنود است و باید بررسی شود.

نکته مهم: بعد از تغییر پورت، کلاینت‌های شما باید از ssh -p 2222 user@host استفاده کنند. اگر کلاینت‌های خودکار (cron، CI/CD) دارید، آن‌ها را هم به‌روز رسانی کنید.

bash
ssh -p 2222 -i ~/.ssh/id_rsa user@192.168.1.10

این دستور تأیید می‌کند که اتصال از پورت جدید کار می‌کند. اگر خطای Connection refused بگیرید، بررسی کنید که فایروال (iptables یا ufw) پورت 2222 را باز کرده باشد:

bash
sudo ufw allow 2222/tcp

تغییر پورت به‌تنهایی root login را غیرفعال نمی‌کند و محافظت از brute-force را کامل نمی‌کند. برای لایه‌های بعدی به بخش‌های بعدی چک‌لیست مراجعه کنید.

#محدودسازی ورود به کلیدهای SSH و غیرفعال‌سازی Password Authentication

ورود با رمز عبور روی SSH یکی از رایج‌ترین نقاط ضعف در سرورهای اوبنتو است؛ مهاجم می‌تواند با brute-force یا credential stuffing به حساب کاربری‌های ضعیف‌رمز دسترسی پیدا کند. با فعال‌سازی کلیدهای عمومی و غیرفعال‌سازی PasswordAuthentication، سطح حمله را به‌شدت کاهش می‌دهیم.

bash
sudo nano /etc/ssh/sshd_config

در فایل sshd_config این سه پارامتر را تنظیم کنید:

conf
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers masoud

PasswordAuthentication no ورود با رمز را کاملاً قطع می‌کند. PubkeyAuthentication yes تضمین می‌کند که فقط کلیدهای معتبر پذیرفته شوند. AllowUsers دسترسی را به یک کاربر خاص محدود می‌کند و حتی اگر کلید دیگری روی سرور باشد، آن کاربر نمی‌تواند وارد شود.

bash
sudo systemctl restart ssh
bash
sudo grep -E 'PasswordAuthentication|PubkeyAuthentication|AllowUsers' /etc/ssh/sshd_config

خروجی باید دقیقاً همین سه خط را نشان دهد. اگر PasswordAuthentication روی yes باشد، تغییر اعمال نشده است.

PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers masoud

این خروجی ثابت می‌کند که ورود با رمز غیرفعال شده و فقط کلیدهای عمومی معتبر پذیرفته می‌شوند. این بررسی چیزی را ثابت نمی‌کند که کلید شما روی کلاینت صحیح نصب است؛ برای آن باید از کلاینت یک اتصال تستی با ssh -i ~/.ssh/id_rsa masoud@server انجام دهید.

معمولاً قبل از اعمال این تغییر، کاربر باید کلید عمومی خود را در ~/.ssh/authorized_keys روی سرور داشته باشد. بدون این، پس از غیرفعال‌سازی PasswordAuthentication دیگر راهی برای ورود نخواهد بود.

bash
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

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

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

#محدودسازی دسترسی به گروه‌های خاص (AllowUsers / AllowGroups)

وقتی کلیدهای SSH و غیرفعال‌سازی Password Authentication انجام شد، لایهٔ بعدی این است که فقط کاربران یا گروه‌های مشخص بتوانند وارد شوند. این کار سطح دسترسی را از «هر کسی که کلید دارد» به «فقط این افراد» کاهش می‌دهد.

قبل از تغییر، وضعیت فعلی را بررسی کنید:

bash
sudo grep -E "AllowUsers|AllowGroups" /etc/ssh/sshd_config

اگر هیچ‌کدام تعریف نشده باشد، یعنی همهٔ کاربرانی که کلید معتبر دارند می‌توانند وارد شوند.

برای محدودسازی به یک گروه خاص، مثلاً ops، در فایل sshd_config این خط را اضافه کنید:

conf
AllowGroups ops

اگر می‌خواهید فقط یک کاربر خاص را مجاز کنید:

conf
AllowUsers masoud

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

بعد از ویرایش:

bash
sudo sshd -t

این دستور فقط syntax را بررسی می‌کند و سرور را ری‌استارت نمی‌کند. اگر خطا ندهد:

bash
sudo systemctl reload ssh

برای اطمینان از اینکه محدودسازی کار می‌کند، از یک کاربر خارج از گروه ops تلاش کنید:

bash
ssh -i ~/.ssh/id_rsa -p 2222 otheruser@server

اگر دسترسی رد شود، یعنی AllowGroups درست اعمال شده. از کاربر داخل گروه:

bash
ssh -i ~/.ssh/id_rsa -p 2222 masoud@server

این باید موفق باشد.

نکته: AllowGroups و AllowUsers فقط روی ورودی SSH اعمال می‌شوند و روی دسترسی‌های داخلی سرور (مثل sudo) تأثیر ندارند. اگر کاربری در گروه ops باشد، ممکن است باز هم با sudo دسترسی کامل داشته باشد؛ این لایهٔ جداگانه‌ای است.

اشتباه رایج: فکر کردن به اینکه AllowGroups یک ACL کامل است. این فقط ورودی SSH را محدود می‌کند. برای کنترل کامل‌تر، باید روی sudo و دسترسی‌های فایل‌سیستم هم کار کنید.

#غیرفعال‌سازی X11 Forwarding و Protocol Version 2

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

برای غیرفعال‌سازی، فایل sshd_config را باز می‌کنیم:

bash
sudo nano /etc/ssh/sshd_config

دو پارامتر را تنظیم می‌کنیم:

conf
X11Forwarding no
Protocol 2

X11Forwarding no کانال گرافیکی را می‌بندد. Protocol 2 اطمینان می‌دهد که فقط پروتکل نسخه 2 استفاده شود؛ نسخه 1 (SSH1) از سال‌ها قبل غیرمعتبر و آسیب‌پذیر شناخته می‌شود و در OpenSSH جدید به‌طور پیش‌فرض غیرفعال است، اما صریح نوشتن آن یک لایه دفاعی اضافی است.

بعد از ذخیره، تغییرات را بررسی می‌کنیم:

bash
sudo grep -E 'X11Forwarding|Protocol' /etc/ssh/sshd_config

خروجی باید دقیقاً این دو خط را نشان دهد:

X11Forwarding no
Protocol 2

اگر خط Protocol در خروجی نبود، یعنی در نسخه جدید OpenSSH این کلید دیگر وجود ندارد و نیازی به تنظیم نیست؛ در این صورت فقط X11Forwarding no کافی است.

حالا سرویس را ری‌استارت می‌کنیم:

bash
sudo systemctl restart sshd

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

bash
sudo ss -tlnp | grep ssh

این تأیید می‌کند که sshd در حال گوش دادن است. نکته مهم: اگر قبلاً پورت را تغییر داده‌اید، اینجا باید پورت جدید را ببینید، نه 22.

خارج از محدوده این بخش:

  • اگر سرور شما واقعاً X11 Forwarding برای دسترسی گرافیکی به دسکتپ نیاز دارد (مثلاً در محیط‌های Desktop Server)، غیرفعال‌سازی آن ممکن است کارکرد شما را خراب کند. در این حالت فقط Protocol 2 را اعمال کنید.
  • اگر از OpenSSH نسخه 8.4 به بالا استفاده می‌کنید، Protocol به‌طور خودکار روی 2 تنظیم است و نیازی به صریح نوشتن آن نیست.
  • این تغییرات روی کلاینت‌های SSH شما تأثیر نمی‌گذارند؛ فقط کانال‌های جانبی سرور را محدود می‌کنند.

#بررسی نهایی با sshd -T و تست‌های عملی

بعد از تمام تغییرات، مهم‌ترین سؤال این است که آیا سرور واقعاً همان چیزی را اجرا می‌کند که در فایل کانفیگ نوشته‌ایم؟ sshd -T خروجی مؤثر (effective configuration) را نشان می‌دهد، یعنی ترکیب فایل اصلی و هر Include یا override موجود. این دستور به‌جای حدس زدن، واقعیت را می‌گوید.

bash
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|port'

خروجی باید دقیقاً با مقادیر انتخاب‌شده در /etc/ssh/sshd_config هم‌خوانی داشته باشد. اگر مثلاً permitrootlogin no و port 2222 را تنظیم کرده‌اید، همین دو مقدار باید در خروجی دیده شوند. این تست اثبات می‌کند که تغییرات با موفقیت اعمال شده‌اند و هیچ override پنهانی وجود ندارد.

برای اطمینان از اینکه کلید‌های جدید واقعاً کار می‌کنند، یک اتصال تستی از کلاینت انجام دهید:

bash
ssh -i ~/.ssh/id_rsa -p 2222 user@server

اگر اتصال موفق باشد، یعنی کلید‌های SSH به‌درستی نصب و شناسایی شده‌اند. اگر خطای Permission denied (publickey) دریافت کنید، احتمالاً کلید در authorized_keys نیست یا permissions فایل نادرست است. این تست اثبات عملی می‌کند که دسترسی با کلید کار می‌کند، اما اثبات نمی‌کند که Password Authentication واقعاً غیرفعال است — برای آن باید به خروجی sshd -T مراجعه کنید.

برای مقایسه مستقیم با فایل کانفیگ:

bash
sudo grep -E 'PermitRootLogin|PasswordAuthentication|Port' /etc/ssh/sshd_config

این دستور مقادیر خام را از فایل نشان می‌دهد. اگر بین خروجی sshd -T و این grep تفاوت وجود داشت، یعنی یک Include یا directive دیگر مقدار را override کرده است. در این حالت باید فایل‌های داخل /etc/ssh/sshd_config.d/ را بررسی کنید.

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