رفع خطای اتصال SSH به سرور اوبونتو

یک تلاش تازه را ثبت کنید

نشست سالم را باز نگه دارید و کنسول بازیابی معتبر را پیدا کنید. فرمان‌های مشتری روی رایانه شما اجرا می‌شوند؛ فرمان‌های سرور از نشست موجود یا کنسول. آدرس 203.0.113.10، کاربر ubuntu، پورت 22 و نام کلید نمونه‌اند و باید با مقادیر واقعی جایگزین شوند.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

خروجی ssh -G تنظیمات مؤثر را نشان می‌دهد. تلاش دوم اشتراک اتصال را غیرفعال می‌کند. زمان و آخرین خطا را یادداشت کنید؛ پیش از ارسال گزارش، آدرس و مسیر حساس را حذف کنید و کلید خصوصی نفرستید.

پیام خطا مسیر بعدی را مشخص می‌کند

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

این‌ها علت قطعی نیستند. اگر Connection established قبل از timeout آمده، مذاکره SSH و گزارش سرور را هم بررسی کنید؛ فرض مسدود بودن همه بسته‌ها کافی نیست.

timeout: مسیر شبکه را دنبال کنید

مقصد ssh -v را با پنل مقایسه کنید. DNS قدیمی یا IPv6 متفاوت می‌تواند اتصال را جای دیگری بفرستد. نیاز به آدرس عمومی، VPN یا میزبان واسط را مشخص کنید.

روشن بودن ماشین، مسیر عمومی، پورت مقصد و IP عمومی فعلی شما باید با قواعد شبکه و مهمان هماهنگ باشند. در Oracle همه security list و NSG را ببینید و فایروال ایمیج را حفظ کنید. شکست ping به‌تنهایی نبود دسترسی SSH را ثابت نمی‌کند.

refused: سرویس شنونده را بررسی کنید

پس از تأیید آدرس و پورت، روی سرور از دسترسی موجود یا کنسول این بررسی‌های فقط‌خواندنی را اجرا کنید.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Ubuntu می‌تواند از socket activation استفاده کند؛ غیرفعال بودن ssh.service وقتی ssh.socket گوش می‌دهد کافی نیست که SSH را خراب بدانید. sshd -t تنظیمات را بررسی می‌کند، نه مسیر اینترنت را. پیش از بازخوانی سرویس خطای مشخص را پیدا کنید.

publickey: حساب و کلید ارائه‌شده

کاربر اولیه ارائه‌دهنده یا مدیر ساخته‌شده را به کار ببرید، نه یک نام حدسی. اثر انگشت کلید ارائه‌شده را در گزارش مشتری پیدا کنید. برای محدود کردن کلیدهای عامل، روی رایانه امتحان کنید:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

IdentityFileهای پیکربندی همچنان می‌توانند اعمال شوند. دسترسی به فایل خصوصی محلی را پیش از تغییر سرور بررسی کنید. روی سرور، مسیر خانه واقعی کاربر را از getent بگیرید؛ مثال زیر /home/ubuntu را فرض می‌کند.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

اثر انگشت کلیدهای مجاز را مقایسه کنید. مالکیت، مجوز، AuthorizedKeysFile، قواعد Match و روش مدیریت کلید ارائه‌دهنده را بررسی کنید. کلیدهای موجود را حفظ کنید؛ StrictModes را برای پنهان کردن علت غیرفعال نکنید.

تغییر هویت: پیش از اتصال تأیید کنید

نصب مجدد یا تغییر IP می‌تواند کلید میزبان را عوض کند، اما تغییر غیرمنتظره ممکن است مقصد اشتباه یا رهگیری باشد. شناسه ماشین و عملیات برنامه‌ریزی‌شده را در پنل معتبر بررسی کنید. در کنسول مهمان کلید عمومی هم‌نوع با هشدار را بخوانید؛ برای Ed25519:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

اثر انگشت SHA256 باید با هشدار تطبیق داشته باشد. این کلید میزبان است، نه کلید ورود کاربر یا درگاه کنسول. فقط پس از تأیید، ورودی همان میزبان را با حفظ سایر ورودی‌ها اصلاح کنید؛ کل known_hosts را حذف یا بررسی هویت را دور نزنید.

اصلاح محدود و آزمایش ورود جدید

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

با اشتراک اتصال غیرفعال دوباره وارد شوید و حساب مورد انتظار و sudo لازم را تأیید کنید. سپس به ادامه راه‌اندازی برگردید. اگر هیچ دسترسی ندارید، مسیر بازیابی ارائه‌دهنده لازم است؛ نصب مجدد نخستین گام تشخیص نیست.