SSH connection error: alamin kung saan pumapalya
Gamitin ang eksaktong SSH error upang piliin ang susunod na check. Pinaghihiwalay ng gabay na ito ang network, service, authentication at host-identity problems habang pinapanatili ang anumang gumaganang access.
VPSuntu · Na-update noong · Tinatayang 5 minutong pagbasa
Nilalaman ng gabay
Itala ang isang failure at panatilihin ang access
Huwag isara ang gumaganang SSH session. Hanapin ang recovery console ng provider. Ang client commands ay sa computer mo gamit ang Linux, macOS o WSL; ang server commands ay sa umiiral na SSH o authenticated recovery console. Huwag patakbuhin ang server commands sa client terminal.
Palitan ang documentation address na 203.0.113.10, username ubuntu, port 22 at key path ng aktuwal mong gamit. Ipakita muna ang evaluated client configuration, pagkatapos gumawa ng isang bagong connection attempt:
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.10Tingnan ang hostname, user, port, identityfile at proxy settings. Pinapatay ng pangalawang command ang connection sharing para sa attempt na ito. Itala ang oras at huling error. Patunayan ang bagong host-key prompt gamit ang identity section sa ibaba. Alisin ang sensitibong usernames, addresses at paths bago ibahagi ang debug output; huwag ibahagi ang private key.
Piliin ang branch ayon sa mensahe
Sa maliit na screen, i-scroll ang talahanayan pahalang upang makita ang lahat ng column.
| Mensahe o yugto | Ipinahihiwatig | Susunod na check |
|---|---|---|
| Connection timed out bago ma-establish | Hindi nakumpleto ang TCP connection | Address, route, firewalls at provider state |
| Connection refused | May aktibong pagtanggi sa address at port | Inaasahang port, listener at reject rules |
| Permission denied (publickey) | Umabot sa authentication ngunit hindi tinanggap ang credentials | Username, key at server policy |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Iba ang ipinakitang host identity sa naka-save | Trusted host-key verification bago magpatuloy |
Nililimitahan lamang ng mga palatandaan ang paghahanap; hindi iisang sanhi ang napapatunayan. Kung may Connection established bago ang timeout, tingnan ang SSH handshake at server logs sa halip na ipagpalagay na lahat ng packet ay naharang.
Timeout: sundan ang tamang network path
Ihambing ang destination sa ssh -v sa kasalukuyang address sa provider panel. Maaaring lumang DNS o ibang IPv6 address ang gamit ng hostname. Alamin kung public IP, VPN o jump host ang kailangan.
Tiyaking Running ang instance at may public route. Suriin ang aktuwal na SSH port at kasalukuyang public source address sa provider firewall. Maaaring magbago ang home connection IP habang nananatili ang lumang /32 rule. Tingnan din ang guest firewall sa console.
Sa OCI, kailangang tama ang security lists, NSGs, routing at guest firewall. Panatilihin ang supplied image rules; hindi diagnostic step ang pag-install ng UFW o pag-flush ng iptables. Nasa Oracle setup ang layout. Hindi sapat ang failed ping upang sabihing walang SSH.
Connection refused: suriin ang listening service
Hindi pinatutunayan ng refusal na tamang VPS ang destination. Tiyakin ang identity at port, pagkatapos patakbuhin ang read-only checks sa server sa pamamagitan ng gumaganang access o recovery console:
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-pagerHanapin ang listener sa tamang port at address at itugma ang logs sa oras ng attempt. Maaaring socket-activated ang Ubuntu SSH: hindi sapat ang inactive ssh.service upang sabihing hindi gumagana kung nakikinig ang ssh.socket.
Sinusuri ng sshd -t ang configuration at host keys nang hindi sinisimulan ang daemon. Hindi nito pinatutunayan ang network reachability. Kung may error, tukuyin muna ang file o setting; huwag basta mag-restart.
Rejected public key: suriin ang account at identity
Gamitin ang paunang account ng provider o administrator na ginawa mo. Sa client debug output, hanapin ang fingerprint ng inialok na key. Upang bawasan ang unrelated agent keys, subukan ito sa client:
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Maaaring may bisa pa rin ang configured IdentityFile entries; tingnan ang ssh -G. Kung hindi mabasa ang private key o sobrang bukas ang permissions nito, ayusin muna ang local file access bago baguhin ang server.
Sa server, suriin ang target account at authorized public keys. Ipinagpapalagay na /home/ubuntu ang home sa halimbawa; palitan ayon sa getent result:
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysIhambing ang authorized fingerprints sa inialok ng client. Tingnan ang journal para sa ownership, permissions at account-policy failures. Suriin ang AuthorizedKeysFile, included snippets at Match rules kung iba ang path. Maaari ring may provider-managed key service. Panatilihin ang existing keys; huwag i-disable ang StrictModes o paganahin ang passwords para lamang maitago ang sanhi.
Nagbago ang host identity: patunayan muna
Maaaring magbago ang key pagkatapos ng rebuild o IP reassignment, ngunit maaaring maling endpoint o interception din ito. Tiyakin ang instance identifier at planadong rebuild sa authenticated provider panel.
Sa trusted console ng guest, tingnan ang public host key na tugma sa algorithm sa client. Para sa Ed25519:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Ihambing ang SHA256 sa warning. Server key ito, hindi login key o console gateway key. Kung napatunayang lehitimo ang replacement, maaaring kailangang i-update ang entry para sa server na iyon: mag-backup muna at panatilihin ang ibang entries. Huwag burahin ang buong known_hosts o i-bypass ang checking. Kung hindi maipaliwanag ang identity, huwag ituloy ang connection.
Patunayan ang correction sa bagong session
Ayusin ang natukoy na address, user, key, makitid na network rule o configuration error. Panatilihin ang independent access habang nagbabago sa server at i-validate ang SSH configuration bago ilapat. Maaaring kailangan ding baguhin ang socket activation para sa bagong port.
Ulitin ang orihinal na attempt nang disabled ang connection sharing. Tiyaking bagong login ito sa tamang account at gumagana ang kailangang sudo. Hindi sapat ang lumang session na nanatiling konektado. Itala ang failure at correction, pagkatapos bumalik sa deployment guide.
Mga karaniwang tanong
Kailangan bang i-reinstall ang Ubuntu para ayusin ang SSH?
Mag-diagnose muna. Hindi nangangailangan ng reinstall ang maling address, user o key; maaari pang mawala ang data sa reinstall. Gamitin ang provider recovery procedure kung wala nang access.
Kapag gumagana ang console, dapat ba gumana rin ang SSH?
Magkaiba ang mga path nila. Kailangan pa ring tama ang guest listener, account authentication at network rules para sa public SSH.