Selesaikan masalah SSH tanpa kehilangan akses

Rekod satu cubaan sambungan

Buka konsol pemulihan penyedia dan jangan tutup sesi SSH yang berjaya. Arahan klien dijalankan pada komputer Linux, macOS atau WSL; arahan server hanya melalui sesi pelayan atau konsol dipercayai.

Gantikan 203.0.113.10, ubuntu, port 22 dan laluan kunci dengan butiran anda. Alamat tersebut ialah contoh dokumentasi. Cetak tetapan klien yang digunakan dan buat satu cubaan tanpa perkongsian sambungan.

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

Semak hostname, user, port, identityfile dan proxy. Rekod masa serta ralat terakhir. Sahkan permintaan kunci hos melalui bahagian identiti di bawah. Lindungi nama pengguna, alamat dan laluan sebelum berkongsi log; jangan kongsi kunci peribadi.

Pilih pemeriksaan berdasarkan ralat

Pada skrin kecil, tatal jadual ke sisi untuk melihat semua lajur.

Mesej mengecilkan skop, bukan membuktikan satu punca. Jika output sudah menyebut Connection established sebelum timeout, periksa handshake dan log SSH, bukan terus menganggap semua paket disekat.

Timeout: ikut laluan rangkaian

Bandingkan alamat dalam ssh -v dengan panel penyedia. DNS lama atau destinasi IPv6 boleh membawa sambungan ke mesin lain. Pastikan anda tahu sama ada akses memerlukan IP awam, VPN atau jump host.

Semak status instans, route awam, port SSH sebenar dan alamat sumber awam komputer anda. Alamat rumah boleh berubah sedangkan peraturan /32 masih lama. Semak firewall dalam sistem melalui konsol juga.

Dalam OCI, security list, NSG, routing dan firewall imej semuanya berperanan. Kekalkan peraturan asal; memasang UFW atau mengosongkan iptables bukan langkah diagnosis. Panduan Oracle menerangkan susunan rangkaian. Ping yang gagal sahaja tidak membuktikan SSH gagal.

Sambungan ditolak: periksa listener

Penolakan tidak membuktikan alamat itu milik VPS yang dimaksudkan. Sahkan identiti dan port, kemudian jalankan pemeriksaan baca sahaja ini pada server melalui akses sedia ada.

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

Cari listener pada alamat serta port yang betul, dan padankan masa log dengan cubaan anda. Ubuntu boleh menggunakan socket activation; ssh.service yang tidak aktif sahaja tidak membuktikan SSH tidak tersedia jika ssh.socket sedang mendengar.

sshd -t memeriksa konfigurasi dan kesahan kunci hos tanpa memulakan daemon. Output senyap bermaksud ujian itu lulus, bukan rangkaian sudah boleh dicapai. Selesaikan ralat yang dikenal pasti sebelum mempertimbangkan reload.

Kunci ditolak: semak akaun dan identiti klien

Gunakan akaun awal penyedia atau pentadbir yang anda cipta. Cari fingerprint kunci yang ditawarkan dalam log klien. Untuk mengurangkan kunci lain daripada SSH agent, cuba dari komputer anda:

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

Tetapan IdentityFile lain masih boleh terpakai; lihat ssh -G. Jika fail peribadi tidak boleh dibaca atau kebenarannya terlalu terbuka, betulkan fail tempatan dahulu.

Pada server, semak akaun sasaran. Contoh mengandaikan home /home/ubuntu; gantikan dengan hasil getent sebenar.

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

Bandingkan fingerprint yang dibenarkan dengan kunci yang ditawarkan. Periksa pemilikan, kebenaran, AuthorizedKeysFile, fail include dan peraturan Match. Pengurusan kunci oleh penyedia mungkin menggunakan mekanisme lain. Kekalkan kunci sedia ada; jangan matikan StrictModes atau hidupkan kata laluan untuk menyembunyikan punca.

Identiti berubah: sahkan sebelum menerima

Bina semula atau alamat IP yang diperuntukkan semula boleh menukar kunci hos. Perubahan tidak dijangka juga boleh menandakan endpoint salah atau pemintasan. Sahkan ID instans dan sejarah perubahan melalui panel akaun anda.

Dalam konsol tetamu yang dipercayai, periksa kunci awam hos mengikut algoritma yang dipaparkan klien. Bagi Ed25519:

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

Bandingkan SHA256 dengan amaran klien. Ini kunci pelayan, bukan kunci log masuk anda atau gateway konsol penyedia. Jika penggantian disahkan, sandarkan known_hosts dan kemas kini entri hos itu sahaja. Jangan padam seluruh fail atau memintas pemeriksaan. Jika identiti belum jelas, hentikan sambungan.

Uji pembetulan dalam sesi baharu

Betulkan alamat, akaun, kunci atau peraturan sempit yang dikenal pasti. Kekalkan laluan akses bebas dan uji konfigurasi sebelum menerapkan perubahan. Port baharu mungkin turut memerlukan tetapan socket activation.

Ulang cubaan asal tanpa perkongsian sambungan. Sahkan akaun yang betul dan akses sudo jika diperlukan. Sesi lama yang kekal terbuka bukan ujian log masuk baharu. Catat punca dan pembetulan, kemudian sambung tetapan laman web.

Soalan lazim