SSH kapcsolati hibák: indulj a hibaüzenettől

Rögzíts egy hibát a meglévő hozzáférés megtartásával

A kliensparancsok a saját Linux, macOS vagy WSL gépeden futnak; a szerverparancsok meglévő SSH-n vagy a hitelesített konzolon. A dokumentációs 203.0.113.10 címet, ubuntu felhasználót, 22-es portot és kulcsútvonalat a saját adataiddal helyettesítsd.

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

Nézd meg a hostname, user, port, identityfile és proxy beállításokat. A második parancs ehhez a próbához kikapcsolja a kapcsolatok megosztását. Jegyezd fel az időpontot és a végső hibát. Új kiszolgálókulcsot csak igazolás után fogadj el; privát kulcsot ne ossz meg, a hibakeresési naplóból pedig távolítsd el a személyes adatokat.

Válaszd ki a hiba megfelelő ágát

Kis képernyőn görgesd oldalra a táblázatot a többi oszlophoz.

Ezek jelek, nem egyetlen ok bizonyítékai. Ha a naplóban már Connection established szerepel, az utána következő timeoutnál a kézfogást és szervernaplót vizsgáld, ne feltételezd minden csomag blokkolását.

Timeoutnál kövesd a tervezett hálózati útvonalat

A ssh -v célcímét vesd össze a szolgáltatói panellel. Elavult DNS vagy más IPv6-cél rossz gépre vihet. Ellenőrizd, nyilvános cím, VPN vagy ugrógép szükséges-e.

A példány fusson, legyen megfelelő útvonal, a szolgáltatói szabály pedig a tényleges célportot és az aktuális nyilvános forráscímedet engedje. Az otthoni cím változhat, miközben a /32 szabály változatlan marad. A vendég tűzfalát a konzolon is vizsgáld.

OCI-nál listák, NSG-k, útvonalak és vendégszabályok egyaránt számítanak. Ne telepíts UFW-t és ne üríts iptables-szabályokat diagnosztika címén. Az Oracle hálózati útmutató mutatja a felépítést. Sikertelen ping önmagában nem bizonyít SSH-hibát.

Visszautasításnál vizsgáld a figyelő szolgáltatást

A refusal még nem igazolja, hogy a kívánt szervert érted el. Ellenőrizd az azonosságot és portot, majd a szerveren, meglévő hozzáféréssel vagy konzolból futtasd:

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

A megfelelő címen és porton figyelő socketet keresd, a naplót pedig a próbád időpontjához rendeld. Ubuntu socket activationt is használhat: az inaktív ssh.service nem bizonyít hibát, ha az ssh.socket figyel.

Az sshd -t a konfigurációt és kiszolgálókulcsokat ellenőrzi, nem indít démont és nem teszteli a hálózatot. Hiba esetén azonosítsd a fájlt vagy beállítást, mielőtt újratöltenél.

Elutasított kulcsnál ellenőrizd a fiókot és az azonosságot

A szolgáltató kezdeti felhasználóját vagy a saját létrehozott adminisztrátort használd. A helyi naplóban keresd a felajánlott kulcs ujjlenyomatát. A sok ügynökkulcs kizárására a saját gépeden próbáld:

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

Az IdentityFile beállítások továbbra is számíthatnak; nézd meg a ssh -G kimenetét. Olvashatatlan vagy túl nyitott helyi privátkulcs-fájlnál előbb annak hozzáférését javítsd.

A szerveren vizsgáld a célfiókot és az engedélyezett kulcsokat. A /home/ubuntu helyére a getent által visszaadott könyvtár kerüljö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_keys

Egyeztesd az ujjlenyomatokat és a naplóban a tulajdonost, jogosultságot, fiókházirendet. Eltérő mechanizmusnál az AuthorizedKeysFile, Include és Match szabályokat vagy a szolgáltatói kulcskezelést is nézd meg. Ne töröld a meglévő kulcsokat, és ne kapcsold ki a StrictModes ellenőrzést a tünet elfedésére.

Megváltozott szerverkulcsnál előbb igazold a gépet

Újratelepítés vagy újra kiosztott IP megváltoztathatja a kulcsot, de rossz végpont vagy lehallgatás is lehetséges. Hitelesített panelen ellenőrizd a példány azonosítóját és a tervezett változást.

A vendég megbízható konzolján a kliensben szereplő algoritmushoz tartozó nyilvános kulcsot vizsgáld. Ed25519 esetén:

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

A SHA256-ot a figyelmeztetéssel egyeztesd. Ez a szerver kulcsa, nem a belépési kulcsod vagy a konzolátjáróé. Igazolt csere után a mentett fájl biztonsági másolatával csak az érintett bejegyzést módosítsd. Ne töröld az egész known_hosts fájlt és ne kerüld meg az ellenőrzést. Ismeretlen változásnál állj meg.

Új kapcsolattal igazold a célzott javítást

Csak az azonosított címet, fiókot, kulcsot, szűk hálózati szabályt vagy konfigurációhibát javítsd. Szerverváltoztatás közben maradjon független hozzáférés, alkalmazás előtt pedig ellenőrizd a konfigurációt. Egy portváltás a socket activationt is érintheti.

Ismételd az eredeti próbát megosztás nélkül. A várt fiók és sudo-jog működését igazold; egy régi munkamenet fennmaradása nem ez a teszt. Rögzítsd az okot és javítást, majd folytasd a webhely beállítását.