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

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

همین موضوع باعث می‌شود تنظیمات امنیتی SSH اهمیت زیادی داشته باشند.

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

جلوگیری از ورود مستقیم کاربر root
غیرفعال کردن ورود با Password و استفاده از SSH Key

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

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

ساخت کاربر مدیریتی
↓
دادن دسترسی sudo
↓
انتقال SSH Key
↓
تست ورود در Session دوم
↓
تغییر تنظیمات SSH
↓
بررسی با sshd -t
↓
بررسی تنظیمات نهایی با sshd -T
↓
Restart سرویس
↓
تست مجدد قبل از بستن Session قبلی

اگر این ترتیب را رعایت کنید، احتمال Lock Out شدن از سرور بسیار کمتر می‌شود.

هشدار مهم: تا زمانی که ورود با کاربر جدید و SSH Key را در یک Terminal جداگانه با موفقیت آزمایش نکرده‌اید، Session فعلی SSH را نبندید.

چرا باید SSH را امن‌تر کنیم؟

سرورهایی که دارای IP عمومی هستند معمولاً توسط Botها و Scannerهای اینترنتی شناسایی می‌شوند.

پس از شناسایی سرویس SSH، ممکن است تلاش‌هایی برای:

حدس زدن Username
حدس زدن Password
ورود به حساب root
استفاده از Credentialهای لو رفته
Brute Force
Password Spraying

انجام شود.

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

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

قبل از شروع چه چیزهایی نیاز داریم؟

برای انجام امن این آموزش بهتر است موارد زیر را داشته باشید:

یک VPS یا سرور Ubuntu
دسترسی فعلی SSH
دسترسی root یا یک کاربر دارای sudo
یک SSH Key سالم روی سیستم خودتان
امکان باز کردن حداقل دو Session هم‌زمان SSH
ترجیحاً دسترسی Console از پنل ارائه‌دهنده VPS

وجود Console یا Rescue Mode بسیار مفید است؛ چون اگر تنظیمات SSH اشتباه شود، یک مسیر اضطراری برای ورود به سرور خواهید داشت.

مرحله صفر: Session فعلی SSH را باز نگه دارید

این مهم‌ترین نکته مقاله است.

فرض کنید اکنون با SSH وارد VPS شده‌اید.

این Terminal را تا پایان تمام مراحل نبندید.

یک Terminal دوم باز کنید تا تغییرات را در آن آزمایش کنید.

ساختار کار:

Terminal 1
اتصال فعلی و سالم
هرگز تا پایان کار بسته نشود

Terminal 2
برای تست کاربر جدید و تنظیمات جدید

اگر Terminal دوم نتوانست وصل شود، هنوز Session اول را دارید و می‌توانید تنظیمات را اصلاح کنید.

مرحله اول: بررسی وضعیت فعلی SSH

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

sudo systemctl status ssh

در حالت عادی باید وضعیت مشابه زیر باشد:

Active: active (running)

برای خروج از صفحه وضعیت:

نسخه OpenSSH را نیز می‌توانید ببینید:

ssh -V

برای بررسی Configuration بدون نمایش تمام جزئیات:

sudo sshd -t

اگر دستور خروجی نداشت و Exit Code موفق بود، Syntax تنظیمات فعلی معتبر است.

فایل تنظیمات SSH در Ubuntu کجاست؟

فایل اصلی OpenSSH Server معمولاً:

/etc/ssh/sshd_config

است.

اما در Ubuntu جدید یک مسیر مهم دیگر نیز وجود دارد:

/etc/ssh/sshd_config.d/

فایل‌های دارای پسوند .conf داخل این مسیر می‌توانند بخشی از Configuration نهایی SSH باشند.

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

Include /etc/ssh/sshd_config.d/*.conf

برای بررسی:

grep -n '^Include' /etc/ssh/sshd_config

همچنین فایل‌های موجود را ببینید:

ls -la /etc/ssh/sshd_config.d/

چرا فقط ویرایش sshd_config همیشه کافی نیست؟

OpenSSH برای بسیاری از Directiveها اولین مقدار مؤثری را که هنگام خواندن Configuration پیدا می‌کند استفاده می‌کند.

در Ubuntu معمولاً فایل‌های sshd_config.d/*.conf از طریق Include در ابتدای Configuration خوانده می‌شوند.

بنابراین ممکن است داخل:

/etc/ssh/sshd_config

بنویسید:

PasswordAuthentication no

اما یک فایل Snippet که زودتر خوانده شده قبلاً مقدار دیگری برای آن تعیین کرده باشد.

به همین دلیل در این مقاله دو کار انجام می‌دهیم:

یک Snippet مشخص و زودخوان برای تنظیمات خودمان می‌سازیم.
مقدار نهایی را با sshd -T بررسی می‌کنیم.

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

مرحله دوم: از تنظیمات فعلی Backup بگیرید

قبل از تغییر:

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

اگر پوشه Snippetها وجود دارد، فهرست آن را نیز برای مرجع ذخیره کنید:

sudo ls -la /etc/ssh/sshd_config.d/

برای اطمینان از وجود Backup:

ls -lh /etc/ssh/sshd_config.backup

Backup به‌تنهایی جای Console اضطراری را نمی‌گیرد، اما در Rollback بسیار مفید است.

مرحله سوم: بررسی کاربر فعلی

ببینید با چه کاربری وارد شده‌اید:

whoami

اگر خروجی:

root

باشد، بهتر است قبل از غیرفعال کردن Root Login یک کاربر عادی با دسترسی sudo بسازید.

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

مرحله چهارم: ساخت کاربر مدیریتی جدید

در مثال این مقاله نام کاربر جدید:

netadmin

است.

شما می‌توانید نام مناسب دیگری انتخاب کنید.

کاربر را بسازید:

sudo adduser netadmin

سیستم از شما Password و چند اطلاعات اختیاری می‌خواهد.

حتی اگر بعداً Password Authentication را غیرفعال کنیم، داشتن Password محلی برای بعضی عملیات مدیریتی می‌تواند لازم باشد.

نام کاربری را از قبل انتخاب کنید و در تمام دستورات این مقاله netadmin را با نام واقعی کاربر خودتان جایگزین کنید.

مرحله پنجم: دادن دسترسی sudo

کاربر را به گروه sudo اضافه کنید:

sudo usermod -aG sudo netadmin

بررسی عضویت:

groups netadmin

باید sudo را در خروجی ببینید.

برای بررسی دقیق‌تر:

id netadmin

تست sudo قبل از تغییر SSH

اگر امکانش وجود دارد، از Session فعلی به کاربر جدید Switch کنید:

su - netadmin

سپس:

sudo whoami

اگر Password کاربر را وارد کردید و خروجی:

root

بود، دسترسی sudo کار می‌کند.

برای برگشت:

exit

مرحله ششم: مطمئن شوید SSH Key دارید

قبل از غیرفعال کردن Password Login، باید ورود با Public Key واقعاً کار کند.

اگر هنوز SSH Key ندارید، ابتدا آن را روی کامپیوتر خودتان بسازید و Public Key را روی سرور قرار دهید.

برای کاربران Windows، راهنمای زیر در وبلاگ نتزو مرتبط است:

آموزش ساخت SSH Key در ویندوز و اتصال امن به سرور لینوکس

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

مرحله هفتم: انتقال Authorized Key به کاربر جدید

اگر کاربر فعلی شما از قبل با SSH Key وارد می‌شود، Public Key مجاز معمولاً در فایل زیر قرار دارد:

~/.ssh/authorized_keys

ابتدا بررسی کنید:

ls -la ~/.ssh/

اگر authorized_keys وجود دارد، برای کاربر جدید پوشه SSH بسازید:

sudo install -d -m 700 -o netadmin -g netadmin /home/netadmin/.ssh

سپس Keyهای مجاز کاربر فعلی را کپی کنید:

sudo cp ~/.ssh/authorized_keys /home/netadmin/.ssh/authorized_keys

مالکیت را اصلاح کنید:

sudo chown netadmin:netadmin /home/netadmin/.ssh/authorized_keys

Permission:

sudo chmod 600 /home/netadmin/.ssh/authorized_keys

بررسی:

sudo ls -la /home/netadmin/.ssh/

باید چیزی شبیه این ببینید:

drwx------ netadmin netadmin .ssh
-rw------- netadmin netadmin authorized_keys

اگر کاربر فعلی شما اصلاً با SSH Key وارد نشده یا فایل authorized_keys ندارد، این مرحله را کورکورانه اجرا نکنید. ابتدا Public Key صحیح خودتان را برای کاربر جدید نصب کنید.

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

Session اول را باز نگه دارید.

در Terminal دوم از سیستم خودتان اجرا کنید:

ssh netadmin@SERVER_IP

برای مثال:

ssh netadmin@203.0.113.10

اگر SSH روی پورت دیگری است:

ssh -p PORT netadmin@SERVER_IP

بعد از ورود:

whoami

باید:

netadmin

را ببینید.

سپس:

sudo whoami

باید:

root

نمایش داده شود.

اگر این دو تست موفق نیستند، هنوز Root Login یا Password Login را غیرفعال نکنید.

از کجا بفهمیم ورود واقعاً با SSH Key انجام شده؟

می‌توانید Client را با Verbose Mode اجرا کنید:

ssh -v netadmin@SERVER_IP

در خروجی اطلاعات مربوط به Authentication نمایش داده می‌شود.

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

sudo journalctl -u ssh -n 50 --no-pager

یا بسته به تنظیمات Logging سیستم:

sudo tail -n 50 /var/log/auth.log

مرحله نهم: بررسی Effective Configuration فعلی

قبل از ایجاد تغییرات، مقدار نهایی چند گزینه مهم را ببینید:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

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

permitrootlogin prohibit-password
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no

این خروجی از نگاه کردن به فایل Configuration مهم‌تر است، چون نشان می‌دهد sshd در نهایت چه مقداری را در نظر گرفته است.

مرحله دهم: ساخت Snippet امنیتی SSH

برای جلوگیری از تداخل با Snippetهای دیگری که ممکن است روی Ubuntu یا Cloud Image وجود داشته باشند، فایل زیر را می‌سازیم:

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

محتوا:

PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

فایل را ذخیره کنید.

در Nano:

Ctrl + O
Enter
Ctrl + X

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

PubkeyAuthentication yes

PubkeyAuthentication yes

اجازه Authentication با Public Key را فعال می‌کند.

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

PermitRootLogin no

PermitRootLogin no

ورود مستقیم کاربر root از طریق SSH را غیرفعال می‌کند.

بعد از آن برای مدیریت سیستم با کاربر عادی وارد می‌شوید و در صورت نیاز از sudo استفاده می‌کنید.

PasswordAuthentication no

PasswordAuthentication no

روش Password Authentication را غیرفعال می‌کند.

یعنی داشتن Username و Password به‌تنهایی برای ورود با این روش کافی نخواهد بود.

KbdInteractiveAuthentication no

KbdInteractiveAuthentication no

Keyboard-Interactive Authentication را غیرفعال می‌کند.

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

مهم: اگر از MFA/2FA یا PAM Authenticationای استفاده می‌کنید که به Keyboard-Interactive نیاز دارد، این گزینه را بدون بررسی معماری Authentication خود غیرفعال نکنید.

چرا فایل را 00-netzo-hardening.conf نام‌گذاری کردیم؟

در Ubuntu استاندارد، Snippetهای:

/etc/ssh/sshd_config.d/*.conf

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

OpenSSH برای بسیاری از Keywordها اولین مقدار خوانده‌شده را نگه می‌دارد.

بنابراین یک فایل مثل:

00-netzo-hardening.conf

قبل از فایل‌هایی مانند:

50-cloud-init.conf
60-cloudimg-settings.conf

خوانده می‌شود.

این موضوع مهم است، چون ساخت فایلی مثل:

99-hardening.conf

برخلاف تصور رایج، برای Directiveهایی که قبلاً مقدار گرفته‌اند ممکن است Override مؤثری ایجاد نکند.

با این حال هیچ‌وقت فقط به نام فایل اعتماد نکنید؛ مقدار واقعی را با sshd -T بررسی کنید.

مرحله یازدهم: تست Syntax قبل از Restart

اکنون:

sudo sshd -t

را اجرا کنید.

اگر Configuration معتبر باشد، معمولاً هیچ خروجی نمایش داده نمی‌شود.

برای دیدن Exit Code:

echo $?

اگر:

باشد، تست موفق بوده است.

اگر خطا دریافت کردید، سرویس SSH را Restart نکنید.

ابتدا فایل را اصلاح کنید:

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

و دوباره:

sudo sshd -t

را اجرا کنید.

مرحله دوازدهم: بررسی مقدار نهایی تنظیمات

قبل از Restart:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

خروجی مورد انتظار برای تنظیم این مقاله:

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no

اگر خروجی با چیزی که انتظار دارید متفاوت است، هنوز Restart نکنید.

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

grep -RniE '^(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication|PubkeyAuthentication)[[:space:]]' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

این دستور کمک می‌کند ببینید چه فایل‌هایی برای این Directiveها مقدار تعیین کرده‌اند.

مرحله سیزدهم: Restart سرویس SSH

بعد از اینکه:

sudo sshd -t

موفق بود و:

sudo sshd -T

مقادیر درست را نشان داد، سرویس را Restart کنید:

sudo systemctl restart ssh

سپس:

sudo systemctl status ssh --no-pager

باید سرویس Active باشد.

هنوز Session اولیه را نبندید.

مرحله چهاردهم: تست ورود بعد از اعمال تنظیمات

یک Terminal جدید باز کنید.

با کاربر مدیریتی جدید متصل شوید:

ssh netadmin@SERVER_IP

ورود باید با SSH Key موفق شود.

سپس:

sudo whoami

را تست کنید.

اگر خروجی:

root

است، مسیر مدیریت سرور سالم است.

مرحله پانزدهم: تست غیرفعال شدن Root Login

اکنون می‌توانید از Terminal دیگری تست کنید:

ssh root@SERVER_IP

ورود مستقیم Root باید رد شود.

اگر SSH پورت دیگری دارد:

ssh -p PORT root@SERVER_IP

اگر هنوز Root می‌تواند وارد شود، Effective Configuration را بررسی کنید:

sudo sshd -T | grep permitrootlogin

خروجی مورد انتظار:

permitrootlogin no

مرحله شانزدهم: تست غیرفعال شدن Password Authentication

برای آزمایش از SSH Client بخواهید Public Key را استفاده نکند:

ssh -o PubkeyAuthentication=no netadmin@SERVER_IP

در تنظیم این مقاله، نباید بتوانید فقط با Password وارد شوید.

برای تست دقیق‌تر می‌توانید Verbose Mode را فعال کنید:

ssh -v -o PubkeyAuthentication=no netadmin@SERVER_IP

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

تفاوت PermitRootLogin no و prohibit-password چیست؟

دو مقدار رایج:

PermitRootLogin no

و:

PermitRootLogin prohibit-password

رفتار متفاوتی دارند.

PermitRootLogin no

ورود SSH برای root را به‌طور کامل غیرفعال می‌کند.

PermitRootLogin prohibit-password

ورود Root با Password و Keyboard-Interactive را غیرفعال می‌کند، اما ممکن است ورود Root با Public Key همچنان مجاز باشد.

برای VPS معمولی که مدیریت آن با یک کاربر sudo انجام می‌شود، no انتخاب ساده‌ای است.

اما بعضی سیستم‌های Automation، Backup یا مدیریت زیرساخت ممکن است به Root Login مبتنی بر Key نیاز داشته باشند.

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

آیا غیرفعال کردن Root Login یعنی حساب root حذف می‌شود؟

خیر.

این تنظیم:

PermitRootLogin no

فقط ورود مستقیم Root از طریق SSH را محدود می‌کند.

کاربر root همچنان بخشی از سیستم است.

یک کاربر دارای sudo می‌تواند دستور مدیریتی اجرا کند:

sudo COMMAND

یا در صورت نیاز Shell مدیریتی بگیرد:

sudo -i

بنابراین نیازی نیست برای جلوگیری از Root SSH، حساب Root را حذف کنید.

آیا بعد از غیرفعال کردن Password هنوز sudo کار می‌کند؟

بله.

این گزینه:

PasswordAuthentication no

به Authentication اتصال SSH مربوط است.

ممکن است sudo همچنان برای تأیید عملیات مدیریتی Password محلی کاربر را درخواست کند.

این دو مفهوم متفاوت هستند:

SSH Password Authentication
≠
sudo password prompt

آیا SSH Key واقعاً امن‌تر از Password است؟

Public Key Authentication در صورت استفاده صحیح مقاومت بسیار بالایی در برابر Password Guessing دارد.

Private Key روی دستگاه Client باقی می‌ماند و سرور Public Key را نگهداری می‌کند.

اما SSH Key نیز باید درست محافظت شود.

نکات مهم:

Private Key را به دیگران ندهید.
برای Key حساس Passphrase در نظر بگیرید.
Keyهای قدیمی و بلااستفاده را حذف کنید.
فایل authorized_keys را دوره‌ای بررسی کنید.
Keyهای هر کاربر را جدا مدیریت کنید.

بررسی authorized_keys

برای کاربر:

cat ~/.ssh/authorized_keys

یا برای کاربر مدیریتی جدید:

sudo cat /home/netadmin/.ssh/authorized_keys

هر خط معمولاً یک Public Key مجاز است.

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

Permission صحیح فایل‌های SSH

Permission اشتباه می‌تواند باعث شود OpenSSH Key را نپذیرد.

برای کاربر netadmin:

sudo chmod 700 /home/netadmin/.ssh
sudo chmod 600 /home/netadmin/.ssh/authorized_keys
sudo chown -R netadmin:netadmin /home/netadmin/.ssh

بررسی:

sudo ls -ld /home/netadmin/.ssh
sudo ls -l /home/netadmin/.ssh/authorized_keys

خطای Permission denied (publickey)

اگر بعد از تغییرات خطای:

Permission denied (publickey)

دریافت کردید، چند مورد را بررسی کنید.

1. Key روی Client وجود دارد؟

روی سیستم Client:

ssh-add -l

اگر از ssh-agent استفاده می‌کنید، Keyهای Loadشده را نمایش می‌دهد.

می‌توانید Key مشخصی را نیز معرفی کنید:

ssh -i ~/.ssh/id_ed25519 netadmin@SERVER_IP

2. Public Key روی سرور وجود دارد؟

در Session قدیمی:

sudo cat /home/netadmin/.ssh/authorized_keys

3. Permission صحیح است؟

sudo chmod 700 /home/netadmin/.ssh
sudo chmod 600 /home/netadmin/.ssh/authorized_keys
sudo chown -R netadmin:netadmin /home/netadmin/.ssh

4. PubkeyAuthentication فعال است؟

sudo sshd -T | grep pubkeyauthentication

باید:

pubkeyauthentication yes

باشد.

در وبلاگ نتزو راهنمای جداگانه‌ای برای خطای Public Key نیز وجود دارد:

رفع خطای Permission denied (publickey) در SSH؛ علت‌ها و راه‌حل قدم‌به‌قدم

اگر بعد از Restart دیگر نمی‌توانیم وصل شویم چه کنیم؟

اگر Session قبلی هنوز باز است، از همان استفاده کنید.

ابتدا:

sudo sshd -t

و:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

را بررسی کنید.

اگر Snippet جدید مشکل ایجاد کرده است، می‌توانید موقتاً نام آن را تغییر دهید:

sudo mv /etc/ssh/sshd_config.d/00-netzo-hardening.conf \
  /etc/ssh/sshd_config.d/00-netzo-hardening.conf.disabled

سپس:

sudo sshd -t
sudo systemctl restart ssh

را اجرا کنید.

اگر تمام Sessionهای SSH بسته شده‌اند، باید از Console، VNC Console، Serial Console یا Rescue Mode ارائه‌دهنده VPS استفاده کنید.

به همین دلیل قبل از تغییر SSH باید مطمئن شوید مسیر اضطراری دارید.

Rollback سریع تنظیمات این مقاله

برای حذف Snippet:

sudo rm /etc/ssh/sshd_config.d/00-netzo-hardening.conf

سپس:

sudo sshd -t
sudo systemctl restart ssh

اگر فایل اصلی نیز تغییر کرده بود و می‌خواهید Backup را برگردانید:

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

و بعد:

sudo sshd -t
sudo systemctl restart ssh

قبل از جایگزینی فایل مطمئن شوید Backup مربوط به همان Configuration صحیح است.

بررسی Logهای SSH

برای عیب‌یابی:

sudo journalctl -u ssh -n 100 --no-pager

برای مشاهده زنده:

sudo journalctl -u ssh -f

در بعضی سیستم‌ها /var/log/auth.log نیز اطلاعات Authentication را نگهداری می‌کند:

sudo tail -f /var/log/auth.log

برای خروج:

Ctrl + C

مشاهده Loginهای موفق و ناموفق

برای مشاهده Login History:

last

برای Loginهای ناموفق، بسته به سیستم می‌توانید:

sudo lastb

را بررسی کنید.

لاگ‌های systemd نیز برای تحلیل SSH بسیار مهم هستند:

sudo journalctl -u ssh --since "today"

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

تغییر پورت پیش‌فرض می‌تواند حجم Bot Scanهای بسیار ساده را کمتر کند، اما جایگزین Authentication امن نیست.

یعنی حتی اگر SSH را از Port 22 به Port دیگری منتقل کنید، همچنان بهتر است:

SSH Key داشته باشید
Root Login را محدود کنید
Password Login غیرضروری را غیرفعال کنید
Firewall را درست تنظیم کنید
Logها را بررسی کنید

برای این موضوع مقاله جداگانه نتزو را ببینید:

آموزش تغییر پورت SSH در لینوکس بدون قطع دسترسی به سرور

استفاده از UFW برای محدود کردن SSH

یکی دیگر از لایه‌های امنیتی، Firewall است.

برای مثال اگر SSH روی Port 22 است، قبل از فعال کردن UFW مطمئن شوید دسترسی SSH مجاز است:

sudo ufw allow OpenSSH

یا:

sudo ufw allow 22/tcp

سپس وضعیت:

sudo ufw status

اگر SSH روی Port دیگری قرار دارد باید همان Port را مجاز کنید.

راهنمای کامل‌تر:

آموزش فایروال UFW در اوبونتو؛ باز کردن پورت بدون قطع SSH

Fail2Ban چه نقشی دارد؟

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

Fail2Ban لاگ‌ها را بررسی می‌کند و می‌تواند IPهایی را که تعداد زیادی تلاش ناموفق دارند موقتاً Ban کند.

با این حال Fail2Ban جایگزین SSH Key و Configuration امن نیست.

یک معماری بهتر چند لایه دارد:

Firewall
+
SSH Key
+
No Root Login
+
No Password Login
+
Fail2Ban
+
Monitoring

آیا باید Password حساب کاربر را هم حذف کنیم؟

نه لزوماً.

غیرفعال کردن:

PasswordAuthentication no

یعنی Password برای ورود SSH استفاده نمی‌شود.

Password محلی کاربر ممکن است برای sudo یا دسترسی Console مفید باشد.

حذف یا Lock کردن Password حساب یک تصمیم جداگانه است و باید با توجه به روش‌های بازیابی و سیاست دسترسی سرور انجام شود.

اگر فقط Root User داریم چه کنیم؟

قبل از:

PermitRootLogin no

باید یک کاربر جایگزین بسازید.

حداقل مراحل:

sudo adduser netadmin
sudo usermod -aG sudo netadmin

سپس SSH Key را برای آن کاربر نصب کنید و در یک Session دوم ورود را آزمایش کنید.

فقط بعد از موفقیت این تست، Root SSH را غیرفعال کنید.

اگر VPS Provider به‌صورت پیش‌فرض Password Login را بسته باشد چه؟

بعضی Ubuntu Cloud Imageها Password Authentication را از ابتدا غیرفعال می‌کنند و فقط SSH Key را می‌پذیرند.

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

sudo sshd -T | grep passwordauthentication

از ابتدا نشان دهد:

passwordauthentication no

این طبیعی است.

هدف مقاله این نیست که تنظیم موجود را بی‌دلیل تغییر دهید؛ بلکه باید Effective Configuration را بررسی کنید و فقط موارد موردنیاز را Hardening کنید.

sshd -t و sshd -T چه فرقی دارند؟

این دو دستور بسیار مهم هستند.

sshd -t

sudo sshd -t

Configuration را از نظر Syntax و اعتبار اولیه بررسی می‌کند.

اگر مشکلی باشد خطا می‌دهد.

sshd -T

sudo sshd -T

Configuration مؤثری را که OpenSSH بعد از پردازش فایل‌ها به دست آورده نمایش می‌دهد.

برای مثال:

sudo sshd -T | grep passwordauthentication

بنابراین:

sshd -t
= آیا Configuration معتبر است؟

sshd -T
= Configuration نهایی چه مقداری دارد؟

استفاده از هر دو قبل از Restart بسیار مفید است.

یک Configuration پایه پیشنهادی برای VPS معمولی

بعد از اینکه SSH Key و کاربر sudo را واقعاً تست کردید، یک Baseline ساده می‌تواند چنین باشد:

PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

فایل:

/etc/ssh/sshd_config.d/00-netzo-hardening.conf

بعد:

sudo sshd -t

و:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

و در نهایت:

sudo systemctl restart ssh

را اجرا کنید.

این Baseline برای تمام محیط‌ها مناسب نیست؛ مخصوصاً اگر از MFA، Automation مبتنی بر Root، PAM سفارشی یا سیستم‌های مدیریت Configuration خاص استفاده می‌کنید.

چک‌لیست امن قبل از بستن Session قدیمی

قبل از اینکه Terminal اولیه را ببندید مطمئن شوید:

کاربر غیر Root ساخته شده است.
کاربر عضو گروه sudo است.
SSH Key برای کاربر جدید نصب شده است.
Permissionهای .ssh صحیح است.
ورود با کاربر جدید در Session دوم موفق است.
sudo برای کاربر جدید کار می‌کند.
sshd -t بدون خطاست.
sshd -T مقادیر مورد انتظار را نشان می‌دهد.
سرویس SSH بعد از Restart فعال است.
اتصال جدید با SSH Key موفق است.
Root Login واقعاً رد می‌شود.
Password Authentication واقعاً غیرفعال شده است.
در صورت مشکل، Console اضطراری در دسترس است.

فقط بعد از تمام این موارد Session اولیه را ببندید.

دستورات مهم این آموزش در یک نگاه

وضعیت SSH:

sudo systemctl status ssh

Backup:

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

ساخت کاربر:

sudo adduser netadmin

دادن sudo:

sudo usermod -aG sudo netadmin

بررسی گروه‌ها:

groups netadmin

ساخت .ssh:

sudo install -d -m 700 -o netadmin -g netadmin /home/netadmin/.ssh

کپی Authorized Keys:

sudo cp ~/.ssh/authorized_keys /home/netadmin/.ssh/authorized_keys
sudo chown netadmin:netadmin /home/netadmin/.ssh/authorized_keys
sudo chmod 600 /home/netadmin/.ssh/authorized_keys

ساخت Snippet:

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

محتوا:

PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

تست Syntax:

sudo sshd -t

بررسی Configuration نهایی:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Restart:

sudo systemctl restart ssh

لاگ:

sudo journalctl -u ssh -n 100 --no-pager

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

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

برای بسیاری از VPSهای عمومی، مدیریت سرور با کاربر عادی دارای sudo به‌جای ورود مستقیم Root می‌تواند سطح دسترسی مستقیم از طریق SSH را محدودتر کند. اما بعضی سیستم‌های Automation ممکن است به Root Key Login نیاز داشته باشند؛ بنابراین نیاز محیط خود را بررسی کنید.

آیا بعد از PasswordAuthentication no دیگر هیچ Passwordی روی سرور کار نمی‌کند؟

خیر. این گزینه به Password Authentication در SSH مربوط است. Password کاربر همچنان ممکن است برای sudo یا ورود از Console استفاده شود.

آیا می‌توان Root Login را فقط با Password بست ولی SSH Key را نگه داشت؟

بله. مقدار:

PermitRootLogin prohibit-password

Password و Keyboard-Interactive را برای Root غیرفعال می‌کند، در حالی که Public Key می‌تواند همچنان مجاز باشد. برای محیط‌هایی که Root Key Login لازم ندارند، PermitRootLogin no محدودکننده‌تر است.

چرا تغییر داخل sshd_config اثر نکرده؟

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

/etc/ssh/sshd_config.d/

قبلاً برای همان Directive مقدار تعیین کرده باشند. مقدار واقعی را با:

sudo sshd -T

بررسی کنید.

چرا از فایل 00-netzo-hardening.conf استفاده کردیم؟

چون در Ubuntu استاندارد Snippetها زودتر از بسیاری از تنظیمات اصلی پردازش می‌شوند و OpenSSH برای اکثر Directiveها اولین مقدار را نگه می‌دارد. نام 00- کمک می‌کند تنظیم ما قبل از Snippetهایی با شماره بالاتر خوانده شود. مقدار نهایی را همیشه با sshd -T تأیید کنید.

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

اگر Session قبلی باز است از همان برای Rollback استفاده کنید. اگر هیچ Sessionی ندارید، از Console یا Rescue Mode ارائه‌دهنده VPS استفاده کنید.

آیا فقط SSH Key برای امنیت کافی است؟

خیر. امنیت بهتر از چند لایه تشکیل می‌شود: Firewall، Update سیستم، SSH Key، محدود کردن Root، مدیریت کاربران، Fail2Ban، Monitoring و Backup.

آیا باید پورت SSH را هم تغییر دهیم؟

تغییر پورت می‌تواند نویز Scanهای ساده را کمتر کند، اما جایگزین SSH Key یا Authentication امن نیست. اگر پورت را تغییر می‌دهید، Firewall و دسترسی جدید را قبل از بستن Port قدیمی تست کنید.

جمع‌بندی

Hardening کردن SSH نباید با یک تغییر عجولانه در sshd_config شروع شود.

ترتیب امن‌تر این است:

ساخت کاربر sudo
↓
نصب SSH Key
↓
تست اتصال جدید
↓
Backup تنظیمات
↓
ساخت Hardening Snippet
↓
sshd -t
↓
sshd -T
↓
Restart SSH
↓
تست مجدد
↓
بستن Session قدیمی

برای یک VPS معمولی که فقط قرار است با SSH Key مدیریت شود، تنظیمات پایه می‌تواند چنین باشد:

PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

اما مهم‌ترین دستورهای این مقاله در واقع این دو هستند:

sudo sshd -t

و:

sudo sshd -T

اولی کمک می‌کند Configuration خراب را قبل از Restart پیدا کنید و دومی نشان می‌دهد OpenSSH در نهایت چه تنظیماتی را واقعاً اعمال خواهد کرد.

و مهم‌تر از همه:

تا زمانی که ورود با کاربر جدید، SSH Key و sudo را در Session دوم تست نکرده‌اید، Session سالم فعلی را نبندید.

مطالب مرتبط

# امنیت SSH

امن‌سازی SSH در Ubuntu؛ غیرفعال کردن Root Login و ورود با پسورد