Ubuntu VPS SSH bağlantı xətasını müəyyən edin
SSH xətasını bağlantının mərhələsinə görə araşdırın: şəbəkəyə çatmaq, SSH xidmətinə qoşulmaq, istifadəçi açarı ilə daxil olmaq və host identity-ni təsdiqləmək. İşləyən sessiyanı bağlamayın; dəyişiklikdən əvvəl provayderin bərpa konsolunu hazırlayın.
VPSuntu · Yenilənib: · Oxuma vaxtı: təxminən 4 dəqiqə
Bələdçinin məzmunu
Xətanı yeni bağlantıda təkrarlayın
Müştəri əmrlərini kompüterinizdə Bash-da, server yoxlamalarını isə işləyən SSH sessiyasında və ya etibarlı konsolda edin. 203.0.113.10, ubuntu, port və açar yolunu öz məlumatınıza uyğunlaşdırın. Cəhd vaxtını və dəqiq xəta mətnini qeyd edin. Paylaşacağınız jurnallardan məxfi məlumatları çıxarın; şəxsi açarı heç vaxt göndərməyin.
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.10ssh -G istifadə olunacaq konfiqurasiyanı göstərir. Diaqnostik bağlantıda connection sharing söndürülür: köhnə sessiyadan istifadə edilməsi yeni girişin işlədiyini sübut etmir.
Xətanın hansı mərhələdə yarandığını tapın
Kiçik ekranda bütün sütunları görmək üçün cədvəli üfüqi sürüşdürün.
| Əlamət | Nə deməkdir | Növbəti yoxlama |
|---|---|---|
| Connection timed out, bağlantı qurulmayıb | Ünvana və ya porta çatılmayıb | IP, route, şəbəkə və firewall |
| Handshake-dən sonra timeout | TCP qurulub, sonrakı mərhələ dayanıb | SSH debug mərhələsi, xidmət və aralıq şəbəkə |
| Connection refused | Hədəfdən cavab var, port bağlantını qəbul etmir | SSH listener, port və reject qaydası |
| Permission denied (publickey) | SSH xidmətinə çatılıb, açar qəbul edilməyib | İstifadəçi, açar və authorized_keys |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Saxlanmış host identity uyğun gəlmir | Etibarlı konsolda konkret serveri təsdiqləmək |
Refused cavabı təkbaşına düzgün serverə çatdığınızı təsdiqləmir. Timeout zamanı dərhal autentifikasiyanı dəyişməyin; əvvəlcə dayanma mərhələsini müəyyən edin.
Ünvanı, marşrutu və firewall-u yoxlayın
ssh -v çıxışındakı IP-ni provider console ilə müqayisə edin. DNS, köhnə IPv6, VPN, jump host, ProxyJump və müştəri konfiqurasiyası hədəfi dəyişə bilər. VM-in işlədiyini və ictimai ünvanı olduğunu yoxlayın.
Provayder firewall-u cari administrator IP /32 ünvanından faktiki SSH portuna icazə verməlidir; guest firewall da həmin yolu açmalıdır. Oracle-da bütün bağlı security list və NSG-ləri nəzərdən keçirin, obrazın iptables və iSCSI qaydalarını saxlayın. Qaydaları bütövlükdə silməyin, obrazın sənədini oxumadan UFW əlavə etməyin. Ping cavabının olmaması SSH-ın bloklandığını təkbaşına göstərmir.
SSH listener və konfiqurasiyanı yoxlayın
Serverin açıq sessiyasında və ya konsolda portu, ssh.service və ssh.socket vəziyyətini yoxlayın:
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-pagerSocket activation istifadə edilirsə, inactive ssh.service mütləq nasazlıq deyil. Faktiki dinlənən porta baxın. sshd -t konfiqurasiya və key fayllarını yoxlayır, xarici şəbəkə əlçatanlığını yoxlamır. Hansı service/socket-in idarə etdiyini müəyyənləşdirdikdən sonra uyğun reload addımını seçin.
İstifadəçini və göndərilən açarı müqayisə edin
Provayderin verdiyi və ya öz yaratdığınız düzgün istifadəçini seçin. Müştərinin təqdim etdiyi açarın fingerprint-i serverdəki açıq açarla uyğun gəlirmi? IdentitiesOnly açar seçimini məhdudlaşdırsa da, ssh -G-də bir neçə IdentityFile qala bilər. Əvvəlcə şəxsi açarın yerli icazə problemini düzəldin.
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Serverdə getent ilə həqiqi home yolunu tapın; nümunə istifadəçi və yollarını uyğunlaşdırın. authorized_keys fingerprint-lərini, fayl sahibini, icazələri və journal qeydlərini yoxlayın.
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysMatch bloklarını və faktiki xidmət parametrlərini nəzərə alın. Mövcud lazım olan açarları qoruyun. Xətanı gizlətmək üçün StrictModes-u söndürməyin və parolla girişi aktivləşdirməyin.
Dəyişmiş host key-i etibarlı yolla təsdiqləyin
VM yenidən yaradılmış, IP başqa instance-ə verilmiş və ya səhv hədəf seçilmiş ola bilər; bağlantının ələ keçirilməsi ehtimalını da yoxlayın. Instance identity və yenidən yaradılma tarixçəsini təsdiqləyin, etibarlı konsolda guest Ed25519 host key fingerprint alın:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Bu istifadəçi açarı və ya console gateway açarı deyil. known_hosts faylının nüsxəsini saxlayıb yalnız təsdiqlənmiş konkret host:port qeydini yeniləyin. Bütün known_hosts faylını təmizləməyin, StrictHostKeyChecking-i söndürməyin və təsdiqlənməmiş açarı qəbul etməyin.
Məhdud düzəliş edib yeni girişi sınayın
Yalnız müəyyən edilmiş səbəbi düzəldin. Konfiqurasiya, icazə və ya port dəyişirsə, əvvəlcə uyğun yoxlamanı edin; socket activation zamanı port dəyişikliyi socket parametrinə də toxuna bilər. Recovery console və köhnə işləyən sessiya açıq qalsın.
Kompüterdən connection sharing olmadan təzə bağlantı yaradın. Gözlənilən host və istifadəçi olduğunu yoxlayın, lazım gəlsə sudo sınayın. Köhnə sessiyada əmr işləməsi yeni girişi yoxlamır. Səbəbi, dəyişiklikləri və nəticə vaxtını qeyd edin.
Tez-tez verilən suallar
Timeout və publickey eyni problemdir?
Xeyr. Birincisi bağlantı mərhələsini, ikincisi SSH-a çatdıqdan sonra autentifikasiyanı araşdırmağı tələb edir.
Köhnə sessiya açıqdırsa giriş işləyir?
Yeni giriş ayrıca sınanmalıdır. Açıq sessiya son firewall və ya açar xətasını göstərməyə bilər.
Host key xəbərdarlığını gizlətmək olarmı?
Əvvəlcə server kimliyini etibarlı konsoldan təsdiqləyin. Xəbərdarlığı keçmək yoxlamanı əvəz etmir.