Ndandani sambungan SSH VPS kanthi runtut

Cathet siji kegagalan lan jaga akses sing isih bisa

Aja nutup sesi SSH sing kasil; goleki recovery console panyedhiya. Prentah client ditindakake ing komputer nganggo Linux, macOS, utawa WSL. Prentah server ditindakake liwat sesi sing wis ana utawa recovery console sing wis diautentikasi, dudu ing terminal lokal.

Ganti alamat dokumentasi 203.0.113.10, akun ubuntu, port 22, lan path key nganggo setelan nyata. Tampilake setelan client sing wis dievaluasi, banjur coba siji sambungan anyar:

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

Priksa hostname, user, port, identityfile, lan proxy. Prentah kapindho mateni connection sharing mung kanggo upaya iki. Cathet wektu lan error pungkasan. Yen ana prompt host anyar, verifikasi kaya bagean identitas ing ngisor. Tutupi username, alamat, lan path sadurunge nuduhake debug output; aja tau nuduhake private key.

Pilih cabang saka pesen sing katon

Ing layar cilik, geser tabel menyang sisih kanggo ndeleng kabeh kolom.

Iki nyuda kemungkinan, ora mbuktekake siji sebab. Yen debug wis nulis Connection established sadurunge timeout, priksa handshake SSH lan log server; aja langsung nganggep kabeh paket diblokir.

Timeout: telusuri jalur jaringan sing dikarepake

Cocogake tujuan ssh -v karo alamat saiki ing panel. Hostname bisa duwe DNS lawas utawa IPv6 menyang panggonan liya. Priksa apa VPS iki mbutuhake public IP, VPN, utawa jump host.

Priksa instance mlaku lan routing umum ana. Ing firewall panyedhiya, cocogake port SSH lan public IP sumber saiki. IP sambungan omah bisa owah nalika aturan /32 isih lawas. Priksa firewall guest liwat console uga.

Ing Oracle, security lists, NSG, routing, lan guest firewall kabeh penting. Aja masang UFW utawa flush iptables kanggo nyoba. Jaga aturan image lan deleng layout jaringan Oracle. Ping gagal wae ora mbuktekake SSH ora kasedhiya.

Connection refused: priksa listener

Penolakan ora ngenali tujuan minangka VPS sing dikarepake. Priksa identitas lan port, banjur jalanake pamriksan maca informasi iki ing server liwat akses lawas utawa 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-pager

Goleki listener ing alamat lan port sing bener, banjur cocogake log karo wektu upaya. Ubuntu bisa nggunakake socket activation: ssh.service inactive ora mesthi SSH mati yen ssh.socket isih listening.

sshd -t mriksa konfigurasi lan host key tanpa miwiti daemon. Asil meneng sing kasil ora mbuktekake jaringan bisa digayuh. Yen error, temokake file utawa setelan sing salah sadurunge mikir reload; aja restart tanpa ngerti sebabe.

Public key ditolak: priksa akun lan key sing ditawakake

Gunakake akun wiwitan saka panyedhiya utawa admin sing pancen wis digawe. Deleng fingerprint key sing ditawakake ing debug client. Kanggo nyuda key liyane saka agent, coba ing komputer:

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

IdentityFile saka konfigurasi isih bisa ditrapake; priksa ssh -G. Yen client ora bisa maca key utawa ijin private file kelonggaran, benakake file lokal dhisik sadurunge ngganti server.

Ing server, priksa akun tujuan lan authorized public keys. Conto nganggep home /home/ubuntu; ganti miturut asil 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

Cocogake fingerprint authorized karo sing ditawakake. Deleng journal kanggo ownership, permission, utawa policy akun. Yen path ora standar, priksa AuthorizedKeysFile, included snippets, lan Match rules. Layanan key sing diatur panyedhiya uga bisa beda. Jaga key lawas; aja mateni StrictModes utawa nguripake password mung kanggo ndhelikake masalah.

Host identity owah: verifikasi sadurunge nerusake

Rebuild utawa IP sing diwenehake maneh bisa ngganti host key. Owah-owahan tanpa sebab uga bisa ateges endpoint salah utawa intersepsi. Priksa ID instance lan rebuild sing direncanakake liwat panel sing wis diautentikasi.

Ing console guest sing dipercaya, priksa public host key kanthi algorithm sing katon ing client. Kanggo Ed25519:

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

Cocogake SHA256 karo warning client. Iki key server, dudu key login utawa gateway console panyedhiya. Yen pergantian wis kabukten, backup known_hosts banjur ganti mung entri server kasebut. Jaga entri liyane; aja mbusak file sakabehe utawa ngliwati checking. Yen identitas durung cetha, mandheg lan tliti.

Tes koreksi kanthi sesi anyar

Benakake alamat, akun, key, aturan jaringan sing sempit, utawa konfigurasi sing wis ditemokake salah. Jaga jalur akses kapisah lan validasi konfigurasi SSH sadurunge ditrapake. Port anyar bisa uga mbutuhake setelan socket activation, dudu mung restart service.

Baleni upaya awal kanthi connection sharing mati. Priksa login anyar tekan akun sing dikarepake lan sudo sing dibutuhake bisa. Sesi lawas sing tetep urip ora padha karo tes iki. Cathet kegagalan lan owah-owahan, banjur bali menyang pandhuan deployment yen setup mau mandheg.

Pitakon lan wangsulan

Dokumentasi lan sumber

• Sumber: Ubuntu OpenSSH server documentation
• Sumber: OpenSSH client manual
• Sumber: OpenSSH client configuration manual
• Sumber: OpenSSH server test modes
• Sumber: OpenSSH server configuration manual
• Sumber: OpenSSH key fingerprint tools
• Sumber: Ubuntu 24.04 OpenSSH socket activation
• Sumber: Oracle image firewall requirements