Debug kegagalan SSH setelah upgrade ke OpenSSH 10.4 biasanya tidak berhenti pada satu penyebab. Di sistem backend, masalahnya sering muncul sebagai deploy yang gagal, job backup yang berhenti, atau worker yang tidak bisa menarik artefak dari host lain. Gejalanya bisa terlihat sederhana seperti Permission denied atau Connection closed, tetapi akar masalahnya sering terkait perubahan default, algoritma lama yang tidak lagi diterima, file permission yang salah, atau entri known_hosts yang sudah tidak valid.

Artikel ini membahas studi kasus nyata pada layanan deploy otomatis yang mendadak gagal setelah client SSH di-upgrade ke OpenSSH 10.4. Fokusnya bukan sekadar “ganti konfigurasi sampai jalan”, tetapi bagaimana membaca log verbose, membedakan masalah autentikasi dari masalah host key atau negosiasi algoritma, lalu menerapkan perbaikan yang aman dan bertahap. Sebagai konteks, rujukan utama perubahan perilaku diambil dari release notes OpenSSH 10.4.

Konteks sistem dan kronologi insiden

Bayangkan arsitektur berikut:

  • Sebuah layanan deploy internal menjalankan perintah SSH non-interaktif dari server CI/CD ke beberapa VM target.
  • Sebuah job backup malam hari mengirim arsip ke server penyimpanan melalui SSH.
  • Semua koneksi menggunakan key-based authentication tanpa password.

Sebelum upgrade, koneksi berjalan stabil. Setelah package OpenSSH client diperbarui ke 10.4 di node orchestrator, gejala berikut mulai muncul:

  • Pipeline deploy gagal di langkah git pull atau rsync over ssh.
  • Job backup menandai host tujuan sebagai unreachable.
  • Sebagian host masih bisa diakses, sebagian lain gagal.
  • Kegagalan tidak konsisten di semua target, yang menandakan ini bukan sekadar masalah jaringan umum.

Dari sudut pandang operasional, ini petunjuk penting: jika hanya host tertentu yang gagal, kemungkinan besar ada perbedaan konfigurasi server SSH, jenis host key, atau algoritma yang didukung pada host-host tersebut.

Gejala yang paling sering muncul setelah upgrade

1. Auth gagal walau key benar

Pesan yang sering terlihat:

Permission denied (publickey).

Masalah ini belum tentu berarti private key salah. Bisa juga karena:

  • client menawarkan algoritma signature yang tidak cocok dengan yang diterima server,
  • server menolak key karena permission direktori home atau .ssh terlalu longgar,
  • konfigurasi AuthorizedKeysFile atau akun target berubah.

2. Host key berubah

Contoh pesan:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Ini sering terjadi bila server diganti, direprovision, atau tipe host key yang diprioritaskan berubah setelah upgrade. Pada automation, kegagalan ini bisa tampak seperti “SSH putus” padahal sebenarnya client sengaja memblokir koneksi demi keamanan.

3. Algoritma lama ditolak

Contoh gejala:

Unable to negotiate with 10.0.0.12 port 22: no matching key exchange method found

atau:

no matching host key type found

Ini biasanya mengarah ke server lama atau perangkat yang masih bergantung pada algoritma lawas. OpenSSH modern cenderung memperketat default demi keamanan, sehingga konfigurasi yang dulu “masih diterima” bisa gagal setelah upgrade.

4. Koneksi langsung ditutup

Contoh:

Connection closed by remote host

atau:

kex_exchange_identification: Connection closed by remote host

Ini bisa terkait pembatasan akses di sisi server, masalah kompatibilitas awal sesi SSH, atau bahkan lapisan lain seperti load balancer, firewall, atau sshd yang kehabisan resource.

Langkah reproduksi yang benar

Sebelum mengubah apa pun, reproduksi dulu masalahnya secara manual dari host yang sudah di-upgrade. Ini penting agar Anda tidak menebak-nebak dari log aplikasi saja.

Gunakan mode verbose

ssh -vvv deploy@target-host

Jika koneksi dijalankan oleh job automation dengan private key tertentu dan opsi khusus, tirukan sedekat mungkin:

ssh -vvv -i /opt/deploy/keys/id_ed25519 \
  -o BatchMode=yes \
  -o StrictHostKeyChecking=yes \
  deploy@target-host

Mengapa ini penting: log verbose memperlihatkan urutan negosiasi, host key yang dicocokkan, key yang ditawarkan client, dan alasan penolakan server. Tanpa ini, diagnosis sering berhenti di pesan generik.

Cek konfigurasi efektif client

Jangan hanya membaca ~/.ssh/config. SSH bisa mengambil nilai dari banyak sumber. Gunakan:

ssh -G deploy@target-host

Perintah ini menampilkan konfigurasi efektif setelah semua blok Host, file include, dan default diterapkan. Di sinilah Anda bisa menemukan override tak terduga seperti:

  • IdentityFile yang salah,
  • UserKnownHostsFile kustom,
  • HostKeyAlgorithms atau KexAlgorithms yang memaksa pilihan tertentu.

Membaca log verbose SSH dan auth log dengan tepat

Contoh pembacaan log client

Misalnya potongan log berikut muncul:

debug1: Offering public key: /opt/deploy/keys/id_rsa RSA SHA256:...
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Interpretasinya:

  • Client berhasil mencapai server.
  • Client menawarkan public key.
  • Server menolak key tersebut.
  • Masalah kemungkinan besar ada pada otorisasi key, bukan jaringan.

Bandingkan dengan log negosiasi algoritma:

Unable to negotiate with 10.0.0.12 port 22: no matching host key type found. Their offer: ssh-rsa

Interpretasinya berbeda:

  • Client dan server bertemu di fase awal negosiasi.
  • Server hanya menawarkan tipe host key tertentu.
  • Client menolak karena algoritma itu tidak masuk set default yang diterima.

Log server: auth log atau journal

Di sisi server target, baca log sshd. Lokasinya tergantung distro, tetapi pola umum yang aman adalah:

sudo journalctl -u ssh
sudo journalctl -u sshd

atau file log seperti:

/var/log/auth.log
/var/log/secure

Pesan yang perlu dicari:

  • Authentication refused
  • bad ownership or modes
  • userauth_pubkey
  • Unable to negotiate
  • Connection closed

Contoh kasus permission:

Authentication refused: bad ownership or modes for directory /home/deploy

Jika pesan ini muncul, private key client boleh jadi benar, tetapi server menolak penggunaannya karena permission direktori atau file terlalu longgar. Ini sangat umum pada home directory yang dipasang ulang dari backup atau dibuat otomatis oleh tool provisioning.

Studi kasus: layanan deploy gagal ke host lama setelah upgrade OpenSSH 10.4

Kondisi awal

Server CI/CD diperbarui. Setelah itu, deploy ke host baru tetap berjalan, tetapi deploy ke dua host lama selalu gagal. Backup ke storage lama juga ikut gagal. Semua target memakai user deploy, namun generasi sistem operasinya berbeda.

Gejala yang terlihat

Dari pipeline:

ssh: connect to host app-legacy port 22: Connection closed

Saat diuji manual dengan verbose:

ssh -vvv deploy@app-legacy

Muncul potongan seperti:

debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: (no match)
Unable to negotiate with 10.10.20.15 port 22: no matching host key type found. Their offer: ssh-rsa

Host lain menunjukkan gejala berbeda:

debug1: Offering public key: /opt/deploy/keys/id_ed25519
debug1: Authentications that can continue: publickey
Permission denied (publickey).

Dari sini sudah jelas ada lebih dari satu akar masalah.

Hipotesis awal

  1. Host lama hanya menawarkan algoritma host key lama yang tidak lagi cocok dengan default client modern.
  2. Host lain menerima negosiasi, tetapi menolak public key karena masalah konfigurasi akun atau permission.

Isolasi penyebab per kategori

1. Host key dan known_hosts

Langkah pertama, pastikan masalah bukan karena fingerprint host berubah:

ssh-keygen -F app-legacy
ssh-keyscan -T 5 app-legacy

Jika fingerprint yang tersimpan tidak cocok dengan host saat ini, jangan langsung menghapusnya tanpa verifikasi. Konfirmasi dulu apakah server memang direbuild atau IP dipindahkan. Bila valid, bersihkan entri lama:

ssh-keygen -R app-legacy

Lalu sambungkan kembali dan verifikasi fingerprint yang baru.

Catatan: di automation, mematikan StrictHostKeyChecking memang bisa membuat pipeline “jalan lagi”, tetapi itu menurunkan keamanan dan berisiko menerima host yang salah. Gunakan hanya sebagai langkah darurat yang terkontrol, bukan solusi permanen.

2. Algoritma host key atau key exchange tidak kompatibel

Jika log menunjukkan no matching host key type atau no matching key exchange method, cek kemampuan server:

ssh -Q key
ssh -Q kex
ssh-keyscan app-legacy

Untuk kebutuhan debugging, Anda bisa menguji koneksi dengan mengaktifkan algoritma tambahan secara eksplisit pada host yang bermasalah saja. Contoh pola umum:

ssh -o HostKeyAlgorithms=+ssh-rsa deploy@app-legacy

atau bila masalahnya ada pada key exchange:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha256 deploy@app-legacy

Mengapa ini berhasil: Anda memberi tahu client untuk mengizinkan algoritma tambahan di luar default yang lebih ketat. Namun ini bukan solusi ideal bila digunakan luas-luas, karena artinya Anda mempertahankan kompatibilitas dengan konfigurasi lama yang sebaiknya dimodernisasi.

Solusi yang lebih sehat adalah memperbarui konfigurasi server agar mendukung algoritma yang lebih modern dan aman, lalu menghapus pengecualian di sisi client setelah migrasi selesai.

3. Auth gagal karena key atau permission

Pada host kedua, negosiasi berhasil tetapi public key ditolak. Di sisi server ditemukan log:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Perbaikannya biasanya:

chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Terkadang masalahnya justru ada pada direktori home:

chmod 755 /home/deploy
chown deploy:deploy /home/deploy

Mengapa OpenSSH peduli pada permission: jika file terlalu terbuka, user lain di sistem bisa mengubah authorized_keys atau isi direktori .ssh. Karena itu server akan menolak autentikasi meskipun key-nya benar.

4. Konfigurasi client salah setelah upgrade

Dalam beberapa kasus, upgrade bukan penyebab langsung. Upgrade hanya memunculkan konfigurasi yang sudah lama rapuh. Misalnya file konfigurasi client berisi override lama seperti:

Host *
  IdentityFile ~/.ssh/legacy_rsa
  IdentitiesOnly yes

Akibatnya, client hanya menawarkan satu key lama ke semua host, termasuk host yang sekarang mengharapkan key berbeda. Cek dengan:

ssh -G deploy@app-legacy | grep -Ei 'identityfile|identitiesonly|hostkeyalgorithms|kexalgorithms'

Perbaikan yang lebih tepat adalah menyempitkan override hanya ke host yang memang memerlukannya:

Host app-legacy
  HostKeyAlgorithms +ssh-rsa
  IdentityFile ~/.ssh/legacy_rsa

Host app-modern
  IdentityFile ~/.ssh/id_ed25519

Dengan begitu, kompatibilitas lama tidak “bocor” ke semua target.

Perbaikan bertahap yang aman

Pada studi kasus ini, perbaikannya dilakukan bertahap agar tidak menambah risiko:

Tahap 1: verifikasi host key

  • Bandingkan fingerprint dengan data inventaris atau akses konsol.
  • Hapus entri known_hosts yang memang sudah usang.
  • Jangan menerima host key baru secara buta di automation.

Tahap 2: aktifkan kompatibilitas terbatas untuk host lama

Untuk sementara, di node deploy ditambahkan blok khusus:

Host app-legacy backup-legacy
  HostKeyAlgorithms +ssh-rsa

Langkah ini dipilih hanya untuk host yang belum sempat dimodernisasi. Ini menjaga pipeline tetap jalan sambil menunggu perubahan di server.

Tahap 3: perbaiki server target

  • Pastikan sshd memiliki host key modern yang aktif.
  • Periksa konfigurasi sshd_config agar tidak memaksa algoritma lawas saja.
  • Perbaiki permission /home/deploy, .ssh, dan authorized_keys.

Setelah konfigurasi server dibetulkan, reload atau restart sshd sesuai prosedur operasional yang aman, sebaiknya dari sesi konsol atau dengan koneksi cadangan agar tidak mengunci diri sendiri.

Tahap 4: hapus pengecualian sementara

Begitu host lama sudah mendukung konfigurasi modern, hapus override seperti +ssh-rsa dari client. Ini penting agar sistem tidak bergantung pada pengecualian yang terlupakan bertahun-tahun.

Verifikasi pasca-fix

Perbaikan belum selesai jika baru lolos uji manual sekali. Lakukan verifikasi berlapis:

1. Uji SSH manual tanpa interaksi

ssh -o BatchMode=yes deploy@app-legacy 'echo ok'

Mode ini memastikan koneksi benar-benar cocok untuk automation. Jika masih ada prompt interaktif tersembunyi, perintah ini akan gagal.

2. Uji perintah yang benar-benar dipakai aplikasi

Misalnya deploy menggunakan rsync:

rsync -e "ssh -o BatchMode=yes" -avz ./artifact.tar.gz deploy@app-legacy:/tmp/

Atau backup memakai remote command:

ssh -o BatchMode=yes backup@storage-host 'mkdir -p /data/incoming/test'

Ini penting karena beberapa masalah baru muncul saat tool pembungkus SSH menerapkan opsi berbeda.

3. Pantau log server dan metrik job

  • Pastikan tidak ada lagi pesan penolakan algoritma.
  • Pastikan tidak ada peringatan permission di auth log.
  • Lihat apakah tingkat kegagalan job kembali normal.

Pelajaran dari release notes OpenSSH 10.4

Release notes OpenSSH 10.4 layak dibaca bukan untuk menghafal semua detail, tetapi untuk memahami pola perubahan: OpenSSH secara berkala memperketat perilaku default, merapikan kompatibilitas lama, dan memperjelas batas antara konfigurasi aman dengan konfigurasi usang. Dalam praktik debugging, ini berarti:

  • Jangan mengasumsikan host lama akan terus bekerja tanpa perubahan.
  • Upgrade client bisa mengungkap kelemahan yang selama ini tersembunyi di server.
  • Masalah kompatibilitas sebaiknya diperlakukan sebagai utang teknis yang perlu dikurangi, bukan dibiarkan permanen.

Dengan kata lain, upgrade ke OpenSSH 10.4 mungkin terlihat sebagai pemicu insiden, tetapi sering kali akar masalah sebenarnya adalah infrastruktur SSH yang tidak seragam, host legacy yang belum dimigrasikan, atau automation yang terlalu bergantung pada default lama.

Pencegahan agar insiden tidak terulang

1. Simpan inventaris fingerprint dan algoritma host

Minimal, dokumentasikan fingerprint host penting dan tipe key yang digunakan. Ini mempercepat validasi saat muncul peringatan host key berubah.

2. Uji koneksi SSH di staging sebelum rollout package

Buat smoke test sederhana untuk host-host kritis:

for host in app1 app2 backup1 legacy1; do
  ssh -o BatchMode=yes -o ConnectTimeout=5 deploy@$host 'true' || echo "FAIL: $host"
done

Jalankan test ini di environment yang memakai versi OpenSSH baru sebelum upgrade massal.

3. Hindari override global yang terlalu longgar

Contoh buruk:

Host *
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

atau override algoritma lawas untuk semua host. Praktik ini memang mengurangi friksi jangka pendek, tetapi membuat debugging dan audit keamanan jauh lebih sulit.

4. Standarkan konfigurasi akun otomatisasi

Untuk user seperti deploy atau backup:

  • pastikan owner dan mode file konsisten,
  • gunakan lokasi key yang jelas,
  • cek bahwa provisioning tidak membuat permission terlalu permisif.

5. Pisahkan kompatibilitas legacy per host

Jika masih harus mendukung server lama, taruh pengecualian hanya pada blok Host tertentu dan beri komentar alasan bisnisnya. Ini memudahkan pembersihan saat migrasi selesai.

Checklist ringkas saat debug kegagalan SSH setelah upgrade ke OpenSSH 10.4

  1. Reproduksi manual dengan ssh -vvv.
  2. Cek konfigurasi efektif dengan ssh -G.
  3. Pastikan masalahnya bukan host key mismatch di known_hosts.
  4. Baca auth log atau journal sshd di server target.
  5. Bedakan auth failure dari algorithm negotiation failure.
  6. Periksa permission home, .ssh, dan authorized_keys.
  7. Tambahkan kompatibilitas lama hanya sebagai langkah sementara dan terbatas.
  8. Verifikasi ulang lewat command non-interaktif yang sama dengan workflow produksi.

Penutup

Debug kegagalan SSH setelah upgrade ke OpenSSH 10.4 paling efektif jika dilakukan secara sistematis: lihat gejala, reproduksi dengan verbose logging, cocokkan dengan log server, lalu isolasi masalah ke salah satu kategori utama—host key, autentikasi, algoritma, atau permission. Dalam studi kasus layanan deploy dan backup, akar masalah ternyata bukan satu bug tunggal, melainkan kombinasi host legacy, permission file yang salah, dan konfigurasi client yang terlalu umum.

Solusi terbaik biasanya bukan sekadar menambahkan pengecualian agar koneksi hidup kembali, tetapi juga memodernisasi konfigurasi SSH, merapikan inventaris host key, dan menguji automation sebelum upgrade client berikutnya. Dengan pendekatan ini, Anda tidak hanya menyelesaikan insiden saat ini, tetapi juga mengurangi kemungkinan kegagalan yang sama terulang di upgrade berikutnya.