رفع خطای SSH Connection Refused؛ چرا اتصال به Port 22 رد می‌شود؟

وقتی می خوایم با SSH به سرور متصل بشیم ممکن هست با خطایی شبیه به این مواجه بشیم:

ssh: connect to host 203.0.113.10 port 22: Connection refused

معمولاً مشکل به Password، Username یا SSH Key شما مربوط نیست.

در این نوع خطا اتصال TCP به پورت مقصد رد شده و شما هنوز به مرحله Authentication نرسیده‌اید.

رایج‌ترین علت‌ها عبارت‌اند از:

• سرویس SSH روی سرور اجرا نمی‌شود

• OpenSSH Server نصب نشده است

• SSH روی پورتی غیر از 22 اجرا می‌شود

• پورت اشتباهی را در Client وارد کرده‌اید

• Firewall اتصال را به‌صورت فعال Reject می‌کند

• sshd فقط روی IP یا Interface خاصی Listen می‌کند

• Configuration اشتباه باعث Start نشدن SSH شده است

• IP یا Hostname اشتباهی را هدف گرفته‌اید

پس قبل از اینکه سراغ Private Key یا authorized_keys برویم، ابتدا باید بفهمیم:

آیا اصلاً یک SSH Server روی IP و Port موردنظر منتظر اتصال است؟

خطای Connection refused دقیقاً یعنی چه؟

برای اتصال SSH، Client ابتدا باید یک ارتباط TCP با SSH Server برقرار کنیم.

به‌صورت ساده:

SSH Client
    │
    ▼
Server IP
    │
    ▼
TCP Port 22
    │
    ▼
OpenSSH Server
    │
    ▼
Authentication
    │
    ▼
Shell

در خطای:

Connection refused

اتصال قبل از رسیدن به مرحله Authentication متوقف شده است.

در بسیاری از سناریوها، سیستم مقصد یا تجهیزی در مسیر اتصال را فعالانه رد کرده است؛ برای مثال چون هیچ سرویسی روی آن Port در حال Listen نیست.

به همین دلیل اگر خطای شما:

Permission denied (publickey)

است، مسیر عیب‌یابی کاملاً متفاوتی دارید.

در Permission denied معمولاً SSH Server در دسترس است و مشکل در Authentication رخ داده؛ اما در Connection refused هنوز ارتباط TCP موردنیاز برای شروع Session SSH برقرار نشده است.

Connection refused با Connection timed out چه تفاوتی دارد؟

این دو خطا بسیار شبیه به نظر می‌رسند، اما معنی یکسانی ندارند.

مثلاً:

ssh: connect to host 203.0.113.10 port 22: Connection refused

بیشتر ما را به سمت:

SSH Service
Port
Listener
Firewall Reject
sshd Configuration

می‌برد.

اما:

ssh: connect to host 203.0.113.10 port 22: Connection timed out

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

Network
Routing
Firewall Drop
Wrong IP
Server Offline

مرتبط باشد.

البته این‌ها قوانین مطلق نیستند؛ Firewall یا تجهیزات شبکه بسته به نحوه تنظیم می‌توانند رفتار متفاوتی داشته باشند.

قدم اول: IP و Port را دوباره بررسی کنید

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

فرض کنید دستور شما این است:

ssh root@203.0.113.10

وقتی Port مشخص نمی‌کنید، SSH معمولاً تلاش می‌کند به Port استاندارد:

22

متصل شود.

اما اگر SSH Server روی Port دیگری مثل:

2222

تنظیم شده باشد، باید بنویسید:

ssh -p 2222 root@203.0.113.10

بنابراین دو مورد را بررسی کنید:

Server IP
SSH Port

مخصوصاً اگر اخیراً Port SSH را تغییر داده‌اید.

اگر با Domain وصل می‌شوید، IP آن را هم بررسی کنید

ممکن است دستور شما این باشد:

ssh user@server.example.com

اما Domain به IP اشتباهی Resolve شود.

در Windows PowerShell می‌توانید بررسی کنید:

Resolve-DnsName server.example.com

در Linux نیز ابزارهایی مثل:

dig server.example.com

یا:

getent hosts server.example.com

قابل استفاده هستند.

اگر Domain به Server دیگری اشاره کند، ممکن است روی آن Server هیچ SSH Service روی Port موردنظر وجود نداشته باشد و در نتیجه Connection refused دریافت کنید.

برای تست می‌توانید موقتاً مستقیماً از IP صحیح استفاده کنید.

قدم دوم: از سمت Client بررسی کنید Port باز است یا نه

قبل از ورود به Console سرور، می‌تونیم از Client ببینیم Port موردنظر پاسخ می‌دهد یا خیر.

در Linux و macOS

اگر nc در دسترس است:

nc -vz SERVER_IP 22

مثلاً:

nc -vz 203.0.113.10 22

اگر اتصال برقرار شود ممکن است خروجی‌ای مشابه این ببینید:

Connection to 203.0.113.10 22 port [tcp/ssh] succeeded!

اگر ببینید:

Connection refused

می‌دونیم مشکل فقط مربوط به خود دستور ssh نیست؛ TCP Port نیز اتصال را قبول نمی‌کند.

تست Port در Windows PowerShell

در Windows نیازی نیست حتماً Netcat نصب کنید.

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

Test-NetConnection -ComputerName 203.0.113.10 -Port 22

یکی از مهم‌ترین بخش‌های خروجی:

TcpTestSucceeded

است.

اگر:

TcpTestSucceeded : True

باشد، TCP Port در دسترس است.

اگر:

TcpTestSucceeded : False

باشد، باید سمت Server، Firewall یا مسیر شبکه را بررسی کنیم.

صرفاً نتیجه Ping را معیار نگیرید؛ Server می‌تواند ICMP را Block کرده باشد ولی SSH کاملاً در دسترس باشد.

اگر SSH کار نمی‌کند، چطور وارد Server شویم؟

برای بررسی سرویس SSH باید به خود Server دسترسی داشته باشیم.

اما مشکل اینجاست:

خود SSH الان کار نمی‌کند.

در چنین شرایطی اگر VPS شما Web Console، VNC Console، Serial Console یا Recovery Console دارد، از آن استفاده کنید.

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

بعد می‌توانیم Service، Port و Firewall را از داخل Server بررسی کنیم.

اگر هیچ Console یا روش دسترسی جایگزینی ندارید، ممکن است برای بعضی مراحل نیاز به پشتیبانی ارائه‌دهنده سرور داشته باشید.

قدم سوم: بررسی کنید OpenSSH Server اجرا می‌شود یا نه

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

sudo systemctl status ssh

اگر سرویس فعال باشد باید چیزی شبیه:

Active: active (running)

ببینید.

اگر:

inactive

یا:

failed

باشد، احتمالاً علت Connection refused را پیدا کرده‌ایم.

در AlmaLinux، Rocky Linux و RHEL

نام Service معمولاً:

sshd

است.

بنابراین:

sudo systemctl status sshd

را اجرا کنید.

پس:

Ubuntu / Debian
→ ssh

RHEL / AlmaLinux / Rocky Linux
→ sshd

اگر SSH Service متوقف شده است

در Ubuntu:

sudo systemctl start ssh

سپس:

sudo systemctl status ssh

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

برای اینکه Service هنگام Boot نیز فعال شود:

sudo systemctl enable ssh

یا می‌توانید هر دو کار را هم‌زمان انجام دهید:

sudo systemctl enable --now ssh

بعد از Client دوباره اتصال را تست کنید:

ssh user@SERVER_IP

اگر OpenSSH Server اصلاً نصب نشده باشد چه کنیم؟

وجود دستور ssh روی Server الزاماً به معنی نصب بودن SSH Server نیست.

Client و Server دو Package متفاوت هستند.

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

dpkg -l | grep openssh-server

اگر نصب نیست:

sudo apt update
sudo apt install openssh-server

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

sudo systemctl status ssh

مستندات رسمی Ubuntu نیز Package openssh-server را برای راه‌اندازی بخش Server سرویس OpenSSH معرفی می‌کند.

قدم چهارم: ببینید واقعاً چه چیزی روی Port SSH Listen می‌کند

فقط Active بودن Service کافی نیست.

باید مطمئن شویم SSH واقعاً روی Port موردنظر در حال Listen است.

اجرا کنید:

sudo ss -tlnp

برای محدودکردن خروجی:

sudo ss -tlnp | grep sshd

یا برای Port 22:

sudo ss -tlnp | grep ':22'

اگر SSH روی Port 22 و تمام IPv4 Interfaceها Listen کند، ممکن است چیزی شبیه این ببینید:

LISTEN 0 128 0.0.0.0:22 0.0.0.0:*

برای IPv6 نیز ممکن است:

[::]:22

دیده شود.

اگر هیچ خروجی برای Port SSH وجود ندارد

اگر:

sudo ss -tlnp | grep ':22'

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

• SSH Service اجرا نمی‌شود

• SSH روی Port دیگری Listen می‌کند

• Configuration مشکل دارد

• SSH فقط روی Address دیگری Bind شده است

در این مرحله نباید Firewall را اولین متهم بدانیم.

اول باید مشخص شود Listener وجود دارد یا خیر.

قدم پنجم: Port واقعی SSH را از Configuration بررسی کنید

برای مشاهده Configuration مؤثر sshd:

sudo sshd -T | grep -i '^port'

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

port 22

باشد.

یا مثلاً:

port 2222

اگر خروجی 2222 است، Client نیز باید به همان Port متصل شود:

ssh -p 2222 user@SERVER_IP

این مورد مخصوصاً زمانی رخ می‌دهد که Administrator قبلاً Port پیش‌فرض SSH را تغییر داده باشد.

OpenSSH به‌طور پیش‌فرض از Port 22 استفاده می‌کند، مگر اینکه Configuration دیگری تعیین شده باشد.

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

ممکن است SSH Service روشن باشد و Port نیز درست باشد، اما فقط روی یک IP خاص Listen کند.

اجرا کنید:

sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

مثلاً اگر SSH فقط روی:

127.0.0.1

Listen کند، اتصال Remote از اینترنت انجام نخواهد شد.

همین مسئله ممکن است برای IPv4 و IPv6 نیز رخ دهد.

برای مشاهده وضعیت واقعی Listener، همچنان:

sudo ss -tlnp

یکی از بهترین ابزارهاست.

قدم ششم: Configuration سرویس SSH را تست کنید

یک تغییر اشتباه در sshd_config می‌تواند باعث شود SSH بعد از Restart اصلاً بالا نیاید.

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

sudo sshd -t

اگر Configuration صحیح باشد، معمولاً Command بدون خروجی برمی‌گردد.

اگر خطایی وجود داشته باشد، ممکن است نام فایل یا Directive مشکل‌دار نمایش داده شود.

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

/etc/ssh/sshd_config

و فایل‌های:

/etc/ssh/sshd_config.d/

قرار دارند.

بعد از اصلاح خطا دوباره:

sudo sshd -t

را اجرا کنید.

فقط زمانی که تست موفق شد:

sudo systemctl restart ssh

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

طبق مستندات رسمی Ubuntu نیز توصیه می‌شود قبل از Restart کردن OpenSSH، Configuration با sshd -t بررسی شود؛ چون Configuration اشتباه می‌تواند باعث Start نشدن سرویس و قطع دسترسی Remote شود.

اگر SSH Service در حالت Failed است چه کنیم؟

اگر:

sudo systemctl status ssh

نشان می‌دهد Service با خطا متوقف شده، Logها را بررسی کنید.

مثلاً:

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

یا برای مشاهده Logها به‌صورت زنده:

sudo journalctl -fu ssh.service

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

Invalid configuration
Bad configuration option
Address already in use
Missing host key
Permission
Port

مشاهده کنید.

به‌جای Restart مکرر Service، خطای واقعی Log را بخوانید و همان مشکل را برطرف کنید.

قدم هفتم: Firewall سرور را بررسی کنید

اگر SSH Service:

Running ✓

است و:

Port Listening ✓

نیز تأیید شده، حالا Firewall را بررسی می‌کنیم.

روی Ubuntu اگر از UFW استفاده می‌کنید:

sudo ufw status verbose

اگر SSH روی Port 22 است، باید Rule مناسب وجود داشته باشد.

برای مثال:

sudo ufw allow 22/tcp

یا:

sudo ufw allow OpenSSH

اگر SSH روی Port 2222 است:

sudo ufw allow 2222/tcp

بعد:

sudo ufw status

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

طبق مستندات Ubuntu نیز UFW می‌تواند Rule مربوط به Port SSH را به‌صورت مستقیم یا از طریق Profile مربوط به OpenSSH مدیریت کند.

Firewall همیشه Connection refused ایجاد می‌کند؟

نه.

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

اگر Firewall Packet را:

DROP

کند، Client معمولاً منتظر می‌ماند و ممکن است در نهایت:

Connection timed out

دریافت کند.

اما اگر Firewall اتصال را:

REJECT

کند، ممکن است پاسخ رد به Client برگردد و خطایی مانند:

Connection refused

ببینید.

پس وجود Connection refused معمولاً ابتدا ما را به سمت نبود Listener یا Reject فعال هدایت می‌کند، نه یک Firewall که Packetها را بی‌صدا Drop می‌کند.

Firewall پنل یا Cloud Provider را فراموش نکنید

گاهی UFW کاملاً درست است اما یک Firewall دیگر جلوی اتصال را گرفته.

مثلاً:

Cloud Firewall
Security Group
Provider Firewall
Datacenter ACL
Router Firewall

اگر سرویس‌دهنده شما Firewall جداگانه‌ای در Control Panel دارد، بررسی کنید Port واقعی SSH در آنجا نیز مجاز باشد.

مثلاً اگر SSH را از 22 به 2222 منتقل کرده‌اید:

Server Firewall → 2222 Allowed
Cloud Firewall  → 2222 Allowed
SSH Client      → Port 2222

هر سه باید با هم هماهنگ باشند.

آیا Fail2ban می‌تواند باعث این مشکل شود؟

ممکن است.

اگر روی Server از Fail2ban یا ابزار امنیتی دیگری استفاده می‌کنید، IP شما ممکن است Block شده باشد.

وضعیت Fail2ban را می‌توانید ببینید:

sudo fail2ban-client status

برای Jail مربوط به SSH ممکن است:

sudo fail2ban-client status sshd

کاربرد داشته باشد.

اما Fail2ban را فقط زمانی بررسی کنید که واقعاً روی Server نصب و فعال باشد.

قبل از آن همان ترتیب اصلی را رعایت کنید:

Service
↓
Listener
↓
Port
↓
Config
↓
Firewall
↓
Security Tools

اگر Port SSH را تغییر داده‌ایم چه چیزهایی باید هماهنگ شوند؟

فرض کنید SSH از:

22

به:

2222

منتقل شده است.

فقط تغییر Configuration کافی نیست.

باید این موارد با هم هماهنگ شوند:

sshd Port
Firewall Rule
Cloud Firewall
Client Command
Monitoring
Automation

Client:

ssh -p 2222 user@SERVER_IP

Firewall:

sudo ufw allow 2222/tcp

و Listener:

sudo ss -tlnp | grep ':2222'

باید همان Port را نشان دهند.

تغییر Port SSH به‌تنهایی راهکار امنیتی کاملی نیست

گاهی کاربران فقط برای جلوگیری از حملات SSH، Port 22 را تغییر می‌دهند.

این کار می‌تواند بخشی از Scanهای ساده و Noise موجود در Log را کاهش دهد، اما نباید جایگزین موارد اصلی امنیت شود:

• SSH Key Authentication

• محدودکردن دسترسی

• Firewall

• Updateهای امنیتی

• User غیر Root

• Monitoring

• Fail2ban در صورت نیاز

پس اگر هدف صرفاً حل Connection Refused است، بدون دلیل Port را تغییر ندهید.

اگر SSH فقط روی localhost Listen می‌کند

این خروجی را فرض کنید:

LISTEN 0 128 127.0.0.1:22

در این حالت SSH فقط روی Loopback Interface منتظر اتصال است.

از داخل همان Server ممکن است:

ssh localhost

کار کند، اما اتصال از کامپیوتر Remote شکست بخورد.

Configuration مربوط به ListenAddress را بررسی کنید:

sudo sshd -T | grep -i listenaddress

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

sudo sshd -t

را اجرا کنید و سپس Listener واقعی را دوباره با:

sudo ss -tlnp

بررسی کنید.

IPv4 و IPv6 را هم در نظر بگیرید

گاهی Domain دارای IPv4 و IPv6 است اما SSH فقط روی یکی از آن‌ها Listen می‌کند.

برای تست اجباری IPv4:

ssh -4 user@SERVER

برای IPv6:

ssh -6 user@SERVER

همچنین:

sudo ss -tlnp

نشان می‌دهد Service روی چه Addressهایی Listen می‌کند.

اگر مشکل فقط روی یکی از خانواده‌های IP رخ می‌دهد، تنظیمات:

AddressFamily
ListenAddress
DNS
Firewall IPv4/IPv6

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

اگر خطا بعد از Reboot شروع شده است

این سناریو هم رایج است:

قبل از Reboot:

SSH ✓

بعد از Reboot:

Connection refused ✗

ابتدا Console را باز کنید و اجرا کنید:

sudo systemctl status ssh

اگر Service فعال نیست:

sudo systemctl enable --now ssh

سپس:

sudo ss -tlnp

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

اگر Service در حالت failed قرار دارد، Log و Configuration را بررسی کنید:

sudo sshd -t

و:

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

اگر بعد از تغییر sshd_config اتصال قطع شد

از Console وارد Server شوید.

ابتدا:

sudo sshd -t

را اجرا کنید.

سپس Configuration مؤثر را ببینید:

sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

بعد وضعیت Service:

sudo systemctl status ssh

و Listener:

sudo ss -tlnp

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

این چهار Command معمولاً خیلی سریع مشخص می‌کنند مشکل از Configuration است یا چیز دیگری.

خطای Connection refused در localhost

گاهی اصلاً VPS در کار نیست و دستور زیر روی همان سیستم اجرا می‌شود:

ssh localhost

و نتیجه:

ssh: connect to host localhost port 22: Connection refused

است.

در این حالت احتمالاً SSH Client نصب است، اما SSH Server روی همان سیستم اجرا نمی‌شود.

روی Ubuntu بررسی کنید:

sudo systemctl status ssh

اگر OpenSSH Server نصب نیست:

sudo apt install openssh-server

بعد:

sudo systemctl enable --now ssh

و دوباره:

ssh localhost

را تست کنید.

آیا مشکل SSH Key می‌تواند Connection refused ایجاد کند؟

معمولاً خیر.

مواردی مثل:

Private Key اشتباه
Public Key اشتباه
authorized_keys
Password اشتباه
Username Authentication

بعد از برقراری اتصال با SSH Server بررسی می‌شوند.

اگر خطا دقیقاً:

Connection refused

است، معمولاً هنوز به این مرحله نرسیده‌اید.

بنابراین تغییر:

authorized_keys

یا ساخت SSH Key جدید معمولاً راه‌حل مناسبی برای این خطا نیست.

ترتیب پیشنهادی عیب‌یابی Connection refused

برای اینکه تصادفی تنظیمات Server را تغییر ندهید، این ترتیب را دنبال کنید:

1. IP و Port را بررسی کنید.

2. از Client Port را تست کنید:

nc -vz SERVER_IP 22

یا در Windows:

Test-NetConnection -ComputerName SERVER_IP -Port 22

3. از Console وارد Server شوید.

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

sudo systemctl status ssh

5. Listener را بررسی کنید:

sudo ss -tlnp

6. Port و ListenAddress مؤثر را ببینید:

sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

7. Configuration را تست کنید:

sudo sshd -t

8. UFW یا Firewall را بررسی کنید:

sudo ufw status verbose

9. Firewall پنل Cloud را بررسی کنید.

10. Log سرویس را بخوانید:

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

[[IMAGE-4: چک‌لیست رفع SSH Connection Refused]]

جدول تشخیص سریع خطا

اشتباهات رایج هنگام رفع Connection refused

تغییر SSH Key

اگر هنوز TCP Connection برقرار نشده، Key وارد ماجرا نشده است.

باز کردن تصادفی چند Port

به‌جای باز کردن:

22
2222
2200
2022

اول Port واقعی را با:

sudo sshd -T

و:

sudo ss -tlnp

پیدا کنید.

غیرفعال کردن کامل Firewall

برای Troubleshooting بهتر است Rule مشکل‌دار را پیدا کنید، نه اینکه Firewall Production Server را بدون دلیل خاموش کنید.

Restart مکرر SSH بدون بررسی Config

قبل از Restart:

sudo sshd -t

را اجرا کنید.

یک Configuration اشتباه ممکن است باعث شود Service دیگر بالا نیاید.

اتکا به Ping

موفق یا ناموفق بودن Ping به‌تنهایی مشخص نمی‌کند SSH قابل دسترسی است یا خیر.

Port واقعی SSH را تست کنید.

اگر هیچ دسترسی به Console نداریم چه کنیم؟

اگر SSH تنها روش ورود شما بوده و حالا:

Connection refused

دریافت می‌کنید، بدون دسترسی جایگزین نمی‌توانید دستوری مثل:

systemctl restart ssh

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

در این شرایط بررسی کنید ارائه‌دهنده VPS امکاناتی مثل:

Web Console
VNC
Serial Console
Rescue Mode
Recovery

دارد یا خیر.

اگر چنین دسترسی‌ای وجود ندارد، باید از پشتیبانی Provider برای دسترسی Recovery یا بررسی SSH Service کمک بگیرید.

به همین دلیل قبل از تغییر تنظیمات حساس SSH روی Production Server، داشتن یک روش Recovery اهمیت زیادی دارد.

جمع‌بندی

خطای:

ssh: connect to host SERVER_IP port 22: Connection refused

معمولاً به این معنی نیست که Password یا Private Key شما اشتباه است.

این خطا قبل از مرحله Authentication اتفاق می‌افتد.

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

IP / Port
↓
SSH Service
↓
Listener
↓
sshd Configuration
↓
Firewall
↓
Cloud Firewall
↓
Logs

ابتدا:

sudo systemctl status ssh

و:

sudo ss -tlnp

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

اگر SSH روی Port دیگری اجرا می‌شود، Client را با همان Port تنظیم کنید.

اگر Service بالا نمی‌آید:

sudo sshd -t

و:

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

معمولاً علت را مشخص می‌کنند.

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

Connection refused را با Permission denied اشتباه نگیرید.

در اولی باید دنبال Service، Port و Network Listener بگردید؛ در دومی SSH Server در دسترس است و باید Authentication را بررسی کنید.

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

خطای SSH Connection refused یعنی چه؟

یعنی تلاش برای ایجاد اتصال TCP به IP و Port مقصد رد شده است. معمولاً هیچ SSH Service روی آن Port Listen نمی‌کند یا یک Firewall/تجهیز شبکه اتصال را به‌صورت فعال Reject کرده است.

چرا Port 22 خطای Connection refused می‌دهد؟

رایج‌ترین علت‌ها متوقف بودن sshd، نصب نبودن OpenSSH Server، تغییر Port SSH یا Listen نکردن سرویس روی Port 22 هستند.

چطور بفهمیم SSH روی چه پورتی اجرا می‌شود؟

روی Server می‌توانید اجرا کنید:

sudo sshd -T | grep -i '^port'

و برای مشاهده Listener واقعی:

sudo ss -tlnp

چگونه بفهمیم SSH Service روشن است؟

در Ubuntu و Debian:

sudo systemctl status ssh

و در بسیاری از توزیع‌های RHEL-based:

sudo systemctl status sshd

آیا Firewall باعث Connection refused می‌شود؟

اگر Firewall اتصال را به‌صورت فعال Reject کند، بله. اگر Packet را بدون پاسخ Drop کند، نتیجه بیشتر ممکن است به شکل Timeout دیده شود.

آیا SSH Key اشتباه باعث Connection refused می‌شود؟

معمولاً خیر. SSH Key بعد از برقرار شدن Connection و شروع Authentication بررسی می‌شود. Key اشتباه بیشتر باعث خطاهایی مثل Permission denied (publickey) می‌شود.

اگر SSH کار نمی‌کند چطور دستورات رفع مشکل را اجرا کنیم؟

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