Ubuntu VPS SSH ulanish xatosini aniqlang
Ubuntu VPS’ga SSH orqali kirilmasa, avval aniq xabardan kelib chiqib tekshiring. Tarmoq, xizmat, autentifikatsiya va host kimligini ajrating. Ishlayotgan kirishni saqlash diagnostikaning bir qismidir.
VPSuntu · Yangilandi: · O‘qish: taxminan 4 daqiqa
Qo‘llanma mazmuni
Bitta xatoni qayd eting va ishlayotgan kirishni saqlang
Muvaffaqiyatli SSH sessiyasini yopmang, provayder recovery console’ini toping. Mijoz buyruqlari Linux, macOS yoki WSL’dagi kompyuteringizda; server buyruqlari mavjud sessiya yoki tasdiqlangan console orqali bajariladi. Server buyrug‘ini tasodifan mahalliy terminalda bajarmang.
203.0.113.10 hujjat manzili o‘rniga haqiqiy server IP’ini, ubuntu, 22 va kalit yo‘li o‘rniga o‘zingizning hisob, port va yopiq kalitingizni yozing. Avval qo‘llanadigan sozlamalarni chiqaring, keyin yangi ulanishni sinang.
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.10hostname, user, port, identityfile va proxy sozlamalarini tekshiring. Ikkinchi buyruq shu urinish uchun connection sharing’ni o‘chiradi. Vaqt va yakuniy xatoni yozing. Yangi host prompt’ini pastdagi tartibda tekshiring; debug’ni ulashishda hisob, manzil va yo‘llarni yashiring. Yopiq kalitni hech kimga yubormang.
Xatoga mos yo‘nalishni tanlang
Kichik ekranda barcha ustunlarni ko‘rish uchun jadvalni yon tomonga suring.
| Xabar yoki bosqich | Nimani bildiradi | Keyingi tekshiruv |
|---|---|---|
| Connection timed out, ulanish hali o‘rnatilmagan | TCP ulanishi tugamagan | Manzil, route, firewall, provayder holati |
| Connection refused | Manzil va portda faol rad etish | Kutilgan port, listener va reject qoidalari |
| Permission denied (publickey) | SSH autentifikatsiyagacha yetgan | Foydalanuvchi, yuborilgan kalit va server siyosati |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Ko‘rsatilgan host saqlanganidan farq qiladi | Davom etishdan oldin ishonchli host-key tekshiruvi |
Bu kuzatuvlar sababni toraytiradi, lekin bitta sababni isbotlamaydi. Debug’da Connection established chiqqandan keyin timeout bo‘lsa, barcha paket bloklangan deb emas, SSH handshake va server jurnallarini tekshiring.
Timeout: kerakli tarmoq yo‘lini kuzating
ssh -v ko‘rsatgan manzilni provayder panelidagi joriy manzil bilan solishtiring. Hostname’da eski DNS yoki boshqa IPv6 manzili urinishni boshqa joyga yuborishi mumkin. Kirish uchun public IP, VPN yoki jump host kerakligini aniqlang.
Instance Running holatidami, public route bormi — tekshiring. Provayder firewall’ida haqiqiy SSH porti va hozirgi public source IP’ingizga ruxsat bo‘lsin. Uy interneti IP’i o‘zgarsa, eski /32 qoida yetmaydi. Guest firewall’ni console’dan ko‘ring.
Oracle’da security list, NSG, route va guest firewall birga ishlaydi. UFW o‘rnatish yoki iptables’ni tozalash diagnostika bosqichi emas. Oracle Ubuntu yo‘riqnomasi shu tarmoq tuzilishini tushuntiradi. Ping ishlamasligi o‘zi SSH mavjud emasligini isbotlamaydi.
Connection refused: tinglayotgan xizmatni tekshiring
Rad javobi manzil aynan sizning VPS ekanini tasdiqlamaydi. Server kimligi va portini tekshirib, mavjud sessiya yoki recovery console’da quyidagi o‘qish buyruqlarini bajaring.
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-pagerKerakli manzil va portdagi listener’ni toping, urinish vaqti bilan jurnallarni solishtiring. Ubuntu socket activation ishlatishi mumkin: ssh.socket tinglayotganda ssh.service inactive bo‘lishi xizmat yo‘qligini anglatmaydi.
sshd -t konfiguratsiya va host key’ni daemon’ni yoqmasdan tekshiradi. Xabarsiz muvaffaqiyat tarmoq orqali kirish borligini isbotlamaydi. Xato bersa, reload’dan oldin aynan shu fayl yoki parametrni aniqlang; xizmatni ko‘r-ko‘rona restart qilmang.
Public key rad etildi: hisob va yuborilgan kalitni tekshiring
Taxminiy nom o‘rniga provayderning boshlang‘ich foydalanuvchisi yoki o‘zingiz yaratgan administratorni ishlating. Debug’da qaysi fingerprint taklif qilinganini toping. Agentdagi ortiqcha kalitlarni kamaytirish uchun kompyuteringizda qayta sinang.
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Konfiguratsiyadagi boshqa IdentityFile qatorlari ham qo‘llanishi mumkin; ssh -G’ni ko‘ring. Kalit o‘qilmasa yoki yopiq kalit fayli ruxsatlari haddan tashqari ochiq bo‘lsa, avval mahalliy faylni tuzating.
Serverda kerakli hisob va authorized public key’larni tekshiring. Misol /home/ubuntu’ni oladi; uni getent qaytargan haqiqiy home bilan almashtiring.
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysAuthorized fingerprint’larni yuborilgan kalit bilan solishtiring. Jurnalda owner, ruxsat va hisob siyosati xatolarini tekshiring. Standart yo‘l ishlatilmasa AuthorizedKeysFile, include va Match qoidalarini o‘qing. Provayder boshqaradigan key service ham mexanizmni o‘zgartirishi mumkin. Mavjud kalitlarni saqlang; sababni yashirish uchun StrictModes’ni o‘chirmang yoki parol kirishini yoqmang.
Host kimligi o‘zgargan bo‘lsa, avval tasdiqlang
Rebuild yoki boshqa instance’ga berilgan IP kalitni o‘zgartirishi mumkin. Kutilmagan o‘zgarish noto‘g‘ri endpoint yoki tutib olish belgisi ham bo‘lishi mumkin. Tasdiqlangan panelda instance ID va rejalashtirilgan rebuild’ni tekshiring.
Ishonchli guest console’da mijoz ko‘rsatgan algoritmning public host key’ini oling. Ed25519 uchun:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256SHA256 qiymatini ogohlantirish bilan solishtiring. Bu login kaliti yoki provayder console gateway kaliti emas, serverning host key’i. Tasdiqlangan almashtirishda faqat shu server yozuvini yangilang, avval fayldan nusxa olib boshqa yozuvlarni saqlang. known_hosts’ni butunlay o‘chirmang yoki tekshiruvni chetlab o‘tmang. Kimlik tushuntirilmasa, ulanishni to‘xtatib tekshiring.
Aniq tuzatishni yangi sessiyada sinang
Topilgan noto‘g‘ri manzil, foydalanuvchi, kalit, tor tarmoq qoidasi yoki konfiguratsiyani tuzating. Server o‘zgarishida mustaqil kirish yo‘lini saqlang, SSH konfiguratsiyasini qo‘llashdan oldin tekshiring. Yangi port socket activation sozlamasiga ham bog‘liq bo‘lishi mumkin.
Connection sharing o‘chirilgan yangi urinishni takrorlang. Kutilgan hisobga kirish va kerakli sudo ishlasin; eski sessiyaning ochiq qolishi bu sinov o‘rniga o‘tmaydi. Xato va tuzatishni yozib, Ubuntu VPS sozlashga qayting.
Ko‘p so‘raladigan savollar
SSH uchun Ubuntu’ni qayta o‘rnatish kerakmi?
Avval sababni aniqlang. Noto‘g‘ri IP, foydalanuvchi yoki kalit OS reinstall talab qilmaydi; reinstall ma’lumotni yo‘qotishi mumkin. Kirish umuman qolmasa, provayder recovery tartibidan foydalaning.
Console ishlashi SSH ham ishlashini isbotlaydimi?
Yo‘q. Ular turli yo‘llar. Guest listener, autentifikatsiya va tarmoq qoidalari SSH ulanishiga alohida ruxsat berishi kerak.