Problémy s SSH riešte podľa chybového hlásenia

Zachyťte jednu chybu

Ponechajte úspešnú SSH reláciu otvorenú a pripravte overenú konzolu poskytovateľa. Klientske príkazy patria do počítača s Linuxom, macOS alebo WSL. Serverové spúšťajte v existujúcom prístupe alebo konzole, nie v lokálnom termináli.

Nahraďte dokumentačnú IP 203.0.113.10, meno ubuntu, port 22 a cestu ku kľúču skutočnými hodnotami. Najprv vypíšte vyhodnotenú konfiguráciu klienta a potom vykonajte jeden nový pokus:

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

Skontrolujte hostname, user, port, identityfile a prípadné proxy nastavenia. Druhý príkaz pre tento pokus vypína zdieľanie spojenia. Uložte čas a konečné hlásenie. Nový hostiteľský kľúč overte nižšie uvedeným spôsobom. Pred zdieľaním logu odstráňte súkromné mená, adresy a cesty; súkromný kľúč nezdieľajte.

Vyberte vetvu podľa fázy zlyhania

Na malom displeji posuňte tabuľku do strán, aby ste videli všetky stĺpce.

Hlásenie zužuje príčinu, ale nedokazuje ju samo. Ak log pred timeoutom uvádza Connection established, skúmajte SSH handshake a serverové logy; nepredpokladajte blokovanie všetkých paketov.

Pri timeoute sledujte sieťovú cestu

Porovnajte cieľ v ssh -v s aktuálnou adresou v paneli. Staré DNS alebo iné IPv6 môže smerovať inde. Zistite, či prístup potrebuje verejnú IP, VPN alebo medziľahlý server.

Overte stav VM, verejnú trasu, skutočný cieľový SSH port a aktuálnu verejnú zdrojovú IP. Domáca adresa sa môže zmeniť, kým pravidlo /32 zostane staré. Firewall hosťa kontrolujte cez konzolu.

V Oracle overte security lists, NSG, smerovanie aj pravidlá obrazu. Inštalácia UFW alebo vyprázdnenie iptables nie je diagnostický krok. Sieťový postup nájdete v návode pre Oracle. Neúspešný ping sám nedokazuje nedostupné SSH.

Pri odmietnutí skontrolujte službu

Odmietnutie ešte neoveruje, že cieľ je váš VPS. Potvrďte identitu a port, potom cez fungujúci prístup alebo konzolu vykonajte serverové kontroly:

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

Hľadajte listener na správnom porte a adrese a porovnajte logy s časom pokusu. Ubuntu môže používať aktiváciu cez socket; neaktívna ssh.service sama neznamená nedostupné SSH, ak počúva ssh.socket.

Príkaz sshd -t kontroluje konfiguráciu a kľúče bez spustenia démona. Tichý úspech neoveruje sieť. Pri chybe najprv identifikujte nastavenie a až potom zvažujte načítanie zmeny. Nereštartujte službu naslepo.

Pri odmietnutom kľúči overte účet a identitu klienta

Použite úvodný účet poskytovateľa alebo správcu, ktorého ste vytvorili. V lokálnom logu nájdite odtlačok ponúknutého kľúča. Na obmedzenie nesúvisiacich kľúčov z agenta skúste na počítači:

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

Aj naďalej môžu platiť IdentityFile z konfigurácie; skontrolujte ssh -G. Ak klient nevie prečítať súkromný kľúč alebo odmieta jeho oprávnenia, opravte najprv lokálny súbor.

Na serveri overte účet a jeho verejné kľúče. Príklad používa /home/ubuntu; nahraďte ho domovským adresárom z getent.

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

Porovnajte autorizované a ponúknuté odtlačky. V logu hľadajte vlastníctvo, oprávnenia a obmedzenia účtu. Skontrolujte AuthorizedKeysFile, zahrnuté konfigurácie a pravidlá Match. Poskytovateľ môže kľúče spravovať vlastnou službou. Zachovajte existujúce záznamy; nevypínajte StrictModes ani nepovoľujte heslá iba na skrytie príčiny.

Zmenu hostiteľského kľúča najprv vysvetlite

Preinštalovanie alebo zmena pridelenej IP môže zmeniť kľúč, ale nečakaná zmena môže znamenať nesprávny endpoint alebo zachytenie spojenia. V overenom paneli skontrolujte identifikátor VM a plánované zmeny.

V dôveryhodnej konzole hosťa overte verejný hostiteľský kľúč rovnakého algoritmu ako vo výzve klienta. Pre Ed25519:

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

SHA256 porovnajte s upozornením klienta. Ide o kľúč servera, nie váš prihlasovací kľúč ani kľúč konzolovej brány poskytovateľa. Až po potvrdení oprávnenej zmeny aktualizujte konkrétny záznam hostiteľa; súbor zálohujte a ostatné záznamy zachovajte. Nemažte celý known_hosts a nevypínajte overovanie.

Otestujte presnú opravu novým spojením

Opravte zistenú adresu, účet, kľúč, úzke sieťové pravidlo alebo chybu konfigurácie. Počas serverových zmien zachovajte nezávislý prístup a overte konfiguráciu pred jej použitím. Zmena portu môže zahŕňať aj socket, nie len reštart služby.

Zopakujte pôvodný pokus bez zdieľania spojenia. Potvrďte očakávaný účet a potrebné sudo. Staré spojenie, ktoré zostalo otvorené, tento test nenahrádza. Zaznamenajte príčinu aj zmenu a vráťte sa k nastaveniu webu.

Otázky a odpovede