آموزش غیرفعال کردن Password Login در SSH و ورود فقط با SSH Key

یکی از رایج‌ترین روش‌های ورود به یک سرور لینوکسی، استفاده از Username و Password است:

ssh user@SERVER_IP

اما روی سروری که مستقیماً از اینترنت در دسترس است، SSH معمولاً با تعداد زیادی تلاش خودکار برای حدس Username و Password روبه‌رو می‌شود.

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

در این مدل:

Password Login ==> ✗

SSH Key        ==> ✓

یعنی حتی اگر شخصی Password کاربر را بداند، SSH Server آن را به‌عنوان روش ورود قبول نمی‌کند و برای ورود باید Private Key معتبر در اختیار داشته باشد.

اما یک هشدار جدی وجود دارد:

تا زمانی که ورود با SSH Key را در یک Terminal جداگانه با موفقیت تست نکرده‌اید، Password Login را غیرفعال نکنید.

اگر Key اشتباه باشد و هم‌زمان Password Authentication را هم ببندید، ممکن است دسترسی Remote خودتان به سرور را از دست بدهید.

در این آموزش روش امن انجام این کار را قدم‌به‌قدم بررسی می‌کنیم.

Password Authentication در SSH چگونه کار می‌کند؟

OpenSSH از چند روش مختلف Authentication پشتیبانی می‌کند.

برای مثال:

Public Key
Password
Keyboard Interactive
GSSAPI
Host-based

وقتی Password Authentication فعال باشد، SSH Server می‌تواند Password مربوط به User را برای ورود بررسی کند.

Directive اصلی مرتبط با آن:

PasswordAuthentication

است.

اگر مقدار آن:

PasswordAuthentication ==> yes

باشد، Password Authentication مجاز است.

اگر:

PasswordAuthentication ==> no

باشد، این روش غیرفعال می‌شود.

طبق مستندات رسمی OpenSSH، PasswordAuthentication دقیقاً تعیین می‌کند آیا روش Password برای Authentication مجاز باشد یا نه. (OpenSSH sshd_config)

چرا استفاده از SSH Key بهتر از اتکا به Password است؟

یک Password ممکن است:

• ضعیف انتخاب شود

• دوباره در سرویس دیگری استفاده شده باشد

• لو برود

• توسط Phishing سرقت شود

• هدف Brute Force قرار بگیرد

در مقابل SSH Key Authentication از یک جفت کلید استفاده می‌کند:

Private Key + Public Key

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

در نتیجه Server برای Login به‌دنبال اثبات در اختیار داشتن Private Key متناظر است.

این یعنی غیرفعال کردن Password Login می‌تواند یکی از مسیرهای رایج حمله به SSH را حذف کند.

اما SSH Key هم باید درست مدیریت شود:

• Private Key نباید منتشر شود

• بهتر است Key شخصی Passphrase داشته باشد

• Keyهای قدیمی باید از Server حذف شوند

• دسترسی Userها باید محدود باشد

• Backup امن از Keyها در صورت نیاز وجود داشته باشد

پس SSH Key جایگزین «مدیریت امنیت» نیست؛ فقط Authentication قوی‌تری در اختیار ما قرار می‌دهد.

قبل از شروع: Session فعلی را نبندید

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

فرض کنید همین حالا با SSH داخل Server هستید:

ssh deploy@SERVER_IP

این Terminal را تا پایان کار باز نگه دارید.

یک Terminal دوم برای تست Login جدید باز کنید.

ساختار امن کار:

Session فعلی

↓
باز می‌ماند

Configuration تغییر می‌کند
↓
Key Login تست می‌شود

Terminal دوم

↓
Login موفق؟

بله → ادامه

نه → اصلاح از Session قبلی

حواستون باشه :

اگر Provider VPS شما Web Console، VNC، Serial Console یا Recovery Console دارد، بهتر است قبل از تغییر تنظیمات حساس SSH مطمئن شوید به آن دسترسی دارید.

قدم اول: مطمئن شوید SSH Key واقعاً کار می‌کند

قبل از غیرفعال کردن Password باید ورود با Key را تست کنیم.

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

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

در Windows PowerShell:

ssh -i "$env:USERPROFILE\.ssh\id_ed25519" user@SERVER_IP

اگر SSH روی Port دیگری اجرا می‌شود:

ssh -p 2222 -i ~/.ssh/id_ed25519 user@SERVER_IP

هدف این است که بتوانید بدون استفاده از Password حساب Server وارد شوید.

اگر Private Key شما Passphrase دارد، درخواست Passphrase خود Key طبیعی است و با Password Account روی Server فرق دارد.

چگونه مطمئن شویم SSH واقعاً از Public Key استفاده کرده است؟

برای تست دقیق‌تر می‌توانید Password Authentication را فقط در Client همین اتصال غیرفعال کنید:

ssh \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  -i ~/.ssh/id_ed25519 \
  user@SERVER_IP

اگر Login موفق شد، می‌دانیم Public Key Authentication واقعاً کار می‌کند.

برای Debug بیشتر:

ssh -vvv -i ~/.ssh/id_ed25519 user@SERVER_IP

و در خروجی به دنبال خطوط مربوط به Public Key Authentication بگردید.

اگر هنوز SSH Key ندارید، ابتدا مقاله «آموزش ساخت SSH Key در ویندوز و اتصال امن به سرور لینوکس» را انجام دهید و بعد به این آموزش برگردید.

قدم دوم: Public Key Authentication را روی Server بررسی کنید

این را روی Server اجرا کنید:

sudo sshd -T | grep -i pubkeyauthentication

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

pubkeyauthentication yes

در OpenSSH، PubkeyAuthentication مشخص می‌کند آیا Public Key Authentication مجاز است یا خیر و مقدار پیش‌فرض آن yes است. (OpenSSH)

همچنین می‌توانید مسیر Keyهای مجاز را ببینید:

sudo sshd -T | grep -i authorizedkeysfile

معمولاً چیزی شبیه:

authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

خواهید دید.

Public Key کاربر معمولاً در:

~/.ssh/authorized_keys

قرار دارد.

قدم سوم: وضعیت فعلی Password Authentication را ببینید

قبل از تغییر، Configuration مؤثر Server را بررسی کنید:

sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods)'

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

pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no
authenticationmethods any

نکته مهم اینجاست:

فقط به چیزی که داخل /etc/ssh/sshd_config نوشته شده اعتماد نکنید؛ خروجی sshd -T نشان می‌دهد OpenSSH در نهایت چه Configuration مؤثری می‌بیند.

این موضوع مخصوصاً روی Cloud Serverها مهم است، چون Configuration ممکن است از چند فایل مختلف خوانده شود.

قدم چهارم: یک فایل جدا برای Hardening SSH بسازید

در Ubuntu و بسیاری از نصب‌های جدید OpenSSH می‌توان Configurationهای اختصاصی را داخل:

/etc/ssh/sshd_config.d/

قرار داد.

به‌جای تغییر مستقیم فایل اصلی می‌توانیم یک Snippet بسازیم:

sudo nano /etc/ssh/sshd_config.d/00-disable-password-login.conf

و داخل آن بنویسیم:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

سپس فایل را Save کنید.

این Configuration سه کار انجام می‌دهد:

Public Key =============> ✓

Password   =============> ✗

Keyboard Interactive ===> ✗

چرا باید تنظیم KbdInteractiveAuthentication را هم بررسی کنیم؟

این نکته مهم است.

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

PasswordAuthentication no

روش Authentication با نام password را می‌بندد.

اما در بعضی سیستم‌ها، PAM می‌تواند از مسیر:

keyboard-interactive

برای Authentication تعاملی استفاده کند.

به همین دلیل اگر هدف شما واقعاً حذف Login مبتنی بر Password است، باید وضعیت:

KbdInteractiveAuthentication

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

Cloud-init نیز در مستندات خودش هشدار می‌دهد که روی Distributionهایی که PAM و Keyboard Interactive Authentication فعال است، PasswordAuthentication no به‌تنهایی ممکن است برای حذف تمام Authenticationهای مبتنی بر Password کافی نباشد.

یک استثنای مهم

اگر از مواردی مثل:

OTP
Duo
PAM MFA
Keyboard-interactive MFA

استفاده می‌کنید، کورکورانه:

KbdInteractiveAuthentication => no

قرار ندهید.

چون ممکن است مکانیزم MFA شما دقیقاً به همین Authentication Method وابسته باشد.

در چنین زیرساختی باید سیاست Authentication مخصوص خودتان را طراحی کنید.

آیا باید UsePAM را روی no قرار دهیم؟

خیر؛ صرفاً برای غیرفعال کردن Password Login این کار را انجام ندهید.

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

UsePAM yes

و تصور کنید برای بستن Password باید آن را به:

UsePAM no

تغییر دهید.

اما PAM فقط برای گرفتن Password استفاده نمی‌شود و می‌تواند در مدیریت Account و Session نیز نقش داشته باشد.

برای هدف این مقاله تمرکز ما روی:

PasswordAuthentication no
KbdInteractiveAuthentication no

است.

UsePAM را بدون شناخت دقیق Stack احراز هویت Server تغییر ندهید.

قدم پنجم: Configuration را قبل از اعمال تست کنید

قبل از Reload یا Restart سرویس SSH اجرا کنید:

sudo sshd -t

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

اگر خطا وجود داشته باشد، مثلاً:

Bad configuration option

ابتدا همان مشکل را برطرف کنید.

هیچ‌وقت با Config دارای خطا سرویس SSH را Restart نکنید.

Ubuntu نیز در مستندات رسمی OpenSSH درباره خطر Lockout در اثر Configuration اشتباه هشدار می‌دهد. (Ubuntu OpenSSH Server)

قدم ششم: Effective Configuration را دوباره بررسی کنید

قبل از اعمال نهایی:

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

هدف ما چیزی شبیه این است:

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no

اگر هنوز می‌بینید:

passwordauthentication yes

یعنی Configuration دیگری روی نتیجه اثر گذاشته است.

در این شرایط تمام تعریف‌های مرتبط را پیدا کنید:

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

ممکن است فایل دیگری مثل Configuration ساخته‌شده توسط Cloud Image وجود داشته باشد.

نکته مهم درباره Cloud-init

بعضی VPSها و Cloud Imageها از cloud-init برای تنظیم اولیه SSH استفاده می‌کنند.

ممکن است فایلی شبیه:

/etc/ssh/sshd_config.d/50-cloud-init.conf

وجود داشته باشد.

و داخل آن مثلاً:

PasswordAuthentication yes

یا:

PasswordAuthentication no

قرار گرفته باشد.

به همین دلیل نام فایل پیشنهادی ما:

00-disable-password-login.conf

است تا در Configurationهای معمول Ubuntu زودتر خوانده شود.

OpenSSH برای بسیاری از Keywordها اولین مقدار دریافت‌شده را استفاده می‌کند؛ بنابراین ترتیب فایل‌های Configuration اهمیت دارد. (OpenSSH sshd_config)

اما دوباره تأکید می‌کنیم:

به نام فایل اعتماد نکنید؛ نتیجه واقعی را با sshd -T Verify کنید.

قدم هفتم: Configuration جدید را اعمال کنید

در Ubuntu معمولاً می‌توانید:

sudo systemctl reload ssh

را اجرا کنید.

در صورت نیاز:

sudo systemctl restart ssh

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

روی توزیع‌های RHEL-based مانند AlmaLinux یا Rocky Linux نام Service معمولاً:

sudo systemctl reload sshd

یا:

sudo systemctl restart sshd

است.

Session فعلی را همچنان نبندید.

قدم هشتم: ورود با SSH Key را در Terminal جدید تست کنید

از کامپیوتر خودتان یک Terminal کاملاً جدید باز کنید.

اجرا کنید:

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

یا اگر Key در مسیر پیش‌فرض است:

ssh user@SERVER_IP

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

بعد برای تست اینکه Server دیگر Password Authentication را ارائه نمی‌کند:

ssh \
  -o PreferredAuthentications=password \
  -o PubkeyAuthentication=no \
  user@SERVER_IP

اگر Password Login به‌درستی غیرفعال شده باشد، این روش نباید بتواند شما را وارد Server کند.

ممکن است خطایی مثل:

Permission denied (publickey).

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

قبل از بستن Session قدیمی این Checklist را انجام دهید

در Terminal جدید:

whoami

را اجرا کنید.

سپس اگر User شما sudo دارد:

sudo whoami

باید:

root

برگرداند.

یعنی هم:

SSH Key Login ✓

و هم:

sudo Access ✓

را Verify کرده‌اید.

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

آیا لازم است PermitRootLogin را هم تغییر دهیم؟

این یک سیاست جداگانه است.

وضعیت فعلی را ببینید:

sudo sshd -T | grep -i permitrootlogin

OpenSSH مقدار پیش‌فرض:

prohibit-password

را برای PermitRootLogin تعریف می‌کند؛ در این حالت Login مبتنی بر Password و Keyboard Interactive برای Root غیرفعال است، اما Public Key می‌تواند مجاز باشد. (OpenSSH)

اگر یک User مدیریتی با sudo دارید و اصلاً نمی‌خواهید Root مستقیم از طریق SSH Login کند، می‌توانید در سیاست Hardening خود:

PermitRootLogin no

را هم در نظر بگیرید.

اما این تغییر را با موضوع اصلی مقاله قاطی نکنید.

ابتدا مطمئن شوید User معمولی شما:

SSH Key Login ✓
sudo ✓

دارد.

آیا AuthenticationMethods publickey لازم است؟

در بیشتر Serverهای معمولی اگر این‌ها را دارید:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

عملاً Authenticationهای رایج مبتنی بر Password را حذف کرده‌اید.

اما OpenSSH گزینه‌ای پیشرفته‌تر به نام:

AuthenticationMethods

هم دارد.

مثلاً:

AuthenticationMethods publickey

یعنی برای Login باید Public Key Authentication موفق باشد.

این گزینه برای Policyهای سخت‌گیرانه‌تر مفید است، اما پیشنهاد می‌کنم آن را فقط زمانی اضافه کنید که Configuration کامل Authentication Server را می‌شناسید.

Serverهای Enterprise ممکن است از:

GSSAPI
MFA
Certificate Authentication
PAM

یا روش‌های دیگری استفاده کنند.

بنابراین برای یک VPS معمولی، Configuration ساده و قابل‌فهم بهتر از Hardening پیچیده‌ای است که بعداً خودتان هم دلیلش را به یاد نمی‌آورید.

اگر بعد از تغییر هنوز Password کار می‌کند چه کنیم؟

اول Configuration مؤثر را ببینید:

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

اگر:

passwordauthentication yes

می‌بینید، Configuration شما Override نشده یا فایل دیگری زودتر مقدار را تعیین کرده است.

تمام فایل‌ها را جستجو کنید:

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

بعد از هر تغییر:

sudo sshd -t

و سپس:

sudo systemctl reload ssh

را انجام دهید.

اگر بعد از تغییر Permission denied بگیریم چه؟

فرض کنید Terminal جدید:

Permission denied (publickey)

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

Session قدیمی را نبندید.

از همان Session سالم بررسی کنید:

cat ~/.ssh/authorized_keys

و Permissionها:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

یک تنظیم رایج:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

است.

سپس با:

ssh -vvv user@SERVER_IP

بررسی کنید Client چه Keyی را ارائه می‌کند.

این همان جایی است که مقاله اختصاصی «رفع خطای Permission denied (publickey) در SSH» به کار می‌آید.

اگر خودمان را از Server Lock Out کردیم چه؟

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

بسته به Provider:

Web Console
Serial Console
VNC
Recovery Mode
Rescue Mode

ممکن است در دسترس باشد.

از Console وارد Server شوید و Configuration را اصلاح کنید.

مثلاً فایل:

/etc/ssh/sshd_config.d/00-disable-password-login.conf

را موقتاً ویرایش کنید.

اگر نیاز اضطراری دارید Password Login را موقتاً برگردانید:

PasswordAuthentication yes

سپس:

sudo sshd -t
sudo systemctl reload ssh

را اجرا کنید.

بعد مشکل SSH Key را اصلاح کنید و دوباره Password Login را ببندید.

آیا غیرفعال کردن Password Login جلوی Brute Force را می‌گیرد؟

تا حد زیادی مسیر حمله مبتنی بر حدس Password را بی‌اثر می‌کند.

Bot هنوز می‌تواند به Port SSH متصل شود، اما Server Password Authentication را قبول نمی‌کند.

ممکن است همچنان Logهایی از:

Invalid user
Authentication attempt
Public key failure

ببینید.

پس هدف این نیست که Server دیگر هیچ Traffic مخربی نبیند.

هدف این است که یکی از روش‌های رایج Authentication از دسترس مهاجم خارج شود.

Firewall، Rate Limiting، Fail2ban و محدودسازی Source IP همچنان می‌توانند در معماری مناسب مفید باشند.

تغییر پورت SSH یا غیرفعال کردن Password؛ کدام مهم‌تر است؟

اگر بخواهیم بین این دو از نظر امنیت Authentication انتخاب کنیم:

غیرفعال کردن Password Login و استفاده صحیح از SSH Key اهمیت بیشتری از صرفاً تغییر Port دارد.

تغییر Port:

22 → 2222

بیشتر می‌تواند Noise و Scanهای ساده را کاهش دهد.

اما:

PasswordAuthentication no

یک Authentication Method را واقعاً حذف می‌کند.

بهترین رویکرد این است که اقدامات مختلف مکمل هم باشند:

SSH Key
+
Password Login Disabled
+
Firewall
+
Non-root Admin User
+
Updates
+
Monitoring

چک‌لیست امن غیرفعال کردن Password Login

• SSH Key معتبر ساخته‌ام

• Public Key روی User صحیح Server قرار دارد

• Login با Key را در Terminal دوم تست کرده‌ام

• Session اصلی را باز نگه داشته‌ام

• PubkeyAuthentication yes را بررسی کرده‌ام

• PasswordAuthentication no تنظیم شده

• وضعیت KbdInteractiveAuthentication را بررسی کرده‌ام

• در صورت استفاده از MFA، Keyboard Interactive را کورکورانه غیرفعال نکرده‌ام

• sshd -t بدون خطا اجرا شده

• Effective Configuration را با sshd -T بررسی کرده‌ام

• Configuration Reload شده

• Login جدید با SSH Key موفق است

• Password Login دیگر کار نمی‌کند

• User من دسترسی sudo موردنیاز را دارد

• بعد از همه این تست‌ها Session قدیمی را بسته‌ام

دستورات سریع برای Ubuntu

اگر SSH Key شما از قبل درست کار می‌کند، خلاصه فرایند به این شکل است.

ساخت Config:

sudo nano /etc/ssh/sshd_config.d/00-disable-password-login.conf

محتوا:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

تست Syntax:

sudo sshd -t

بررسی Configuration مؤثر:

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

اعمال تنظیم:

sudo systemctl reload ssh

و در Terminal دوم:

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

تست Password Authentication:

ssh \
  -o PreferredAuthentications=password \
  -o PubkeyAuthentication=no \
  user@SERVER_IP

فقط پس از موفقیت تست Key Login می‌توانید Session قبلی را ببندید.

جمع‌بندی

برای غیرفعال کردن Password Login در SSH، مهم‌ترین بخش خود Directive نیست؛ ترتیب انجام کار است.

اگر بدون تست SSH Key مستقیماً بنویسید:

PasswordAuthentication no

و سرویس را Reload کنید، ممکن است راه ورود خودتان را ببندید.

روش امن:

Create / Install SSH Key
↓
Test Key Login
↓
Keep Old Session Open
↓
Disable Password
↓
sshd -t
↓
Verify with sshd -T
↓
Reload SSH
↓
Test New Session
↓
Verify sudo
↓
Close Old Session

Configuration رایج برای Serverی که قرار است با Public Key وارد آن شوید:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

است؛ البته اگر از MFA مبتنی بر Keyboard Interactive یا PAM استفاده می‌کنید باید Policy متناسب با همان زیرساخت را طراحی کنید.

و در نهایت:

SSH Key Only یک لایه مهم برای Hardening است، اما امنیت SSH فقط با یک Directive کامل نمی‌شود.

Firewall، Update، User Management، Monitoring و محدودکردن دسترسی‌ها همچنان اهمیت دارند.

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

چگونه Password Login در SSH را غیرفعال کنیم؟

در Configuration OpenSSH مقدار:

PasswordAuthentication no

را تنظیم کنید، سپس Config را با sshd -t بررسی و سرویس را Reload کنید. قبل از این کار حتماً Login با SSH Key را در یک Terminal دیگر تست کنید.

آیا فقط PasswordAuthentication no کافی است؟

برای غیرفعال کردن روش password بله، اما اگر سیستم از Keyboard Interactive/PAM برای Authentication مبتنی بر Password استفاده کند باید KbdInteractiveAuthentication را هم بررسی کنید. در زیرساخت‌های دارای MFA نباید این گزینه را بدون بررسی غیرفعال کرد.

آیا باید UsePAM no قرار دهیم؟

خیر. برای غیرفعال کردن Password Login نیازی نیست UsePAM را کورکورانه غیرفعال کنید. PAM می‌تواند مسئولیت‌های دیگری در Account و Session Management داشته باشد.

چطور مطمئن شویم Password Login واقعاً غیرفعال شده است؟

ابتدا:

sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication)'

را بررسی کنید. سپس از Client تلاش کنید فقط با Password وارد شوید:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@SERVER_IP

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

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

ممکن است بله. غیرفعال کردن PasswordAuthentication فقط روش ورود SSH را تغییر می‌دهد و به‌صورت خودکار Password موردنیاز sudo را حذف نمی‌کند. این دو موضوع مستقل هستند.

آیا Root Login هم غیرفعال می‌شود؟

PasswordAuthentication no Password Login را به‌صورت عمومی غیرفعال می‌کند، اما Policy مربوط به Root را باید با PermitRootLogin جداگانه بررسی کنید.

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

اگر Session قبلی هنوز باز است، از همان Session Configuration را اصلاح کنید. در غیر این صورت باید از Console یا Recovery Access ارائه‌دهنده VPS استفاده کنید.