Siapa yang benar-benar melihat kata sandi SSH Anda di VPN yang tidak tepercaya?

Arahkan sesi SSH melalui VPN yang tidak Anda kelola, dan kata sandi tetap milik server SSH, bukan milik jaringan di antaranya. Jika transportasi ke host terverifikasi terlindungi dengan benar, pengamat pasif di jalur itu tidak mendapatkan kata sandi dalam bentuk yang terbaca. Tetapi ubah satu kondisi, dan jawabannya berubah: host yang tidak terverifikasi, daftar cipher yang dilemahkan, atau workstation yang disusupi semuanya menghasilkan akibat berbeda. Jalankan pemeriksaan di bawah ini secara berurutan, dan perlakukan setiap langkah sebagai syarat berhenti.

Sebut nama penerima sebelum Anda mengetik apa pun

Bidang kata sandi berjalan di dalam pesan autentikasi, dan pesan itu berjalan di dalam transportasi yang terenkripsi. Kerahasiaan adalah sifat transportasi, yang berarti bergantung pada sudah dinegosiasikannya perlindungan dan pada sudah dinegosiasikannya dengan host yang Anda maksud. Justru paruh kedua itulah yang dilewatkan orang. Koneksi yang terenkripsi ke penipu bersifat rahasia sekaligus tidak berguna. Login VPN tidak membuktikan apa pun tentang host SSH, dan reputasi penyedia bukan pengganti pemeriksaan kunci.

Pisahkan kedua arah di kepala Anda. Kunci host menjawab server mana yang Anda capai. Autentikasi kata sandi atau kunci menjawab pengguna mana yang diterima server. Memperbaiki yang kedua tidak pernah membetulkan yang pertama.

Periksa identitas host, catatan, dan negosiasi

Mulai di klien dengan catatan yang sudah Anda pegang. Sidik jari yang dipublikasikan dan dibandingkan dengan sumber tepercaya, serta entri known_hosts yang masih cocok, memberi Anda satu-satunya bukti yang penting sebelum autentikasi dimulai.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

Di sisi server, cetak sidik jari yang hendak Anda publikasikan alih-alih menyalinnya dari ingatan. Menyebarkannya di luar kanal justru inti persoalannya; sidik jari yang ditempel dari kanal obrolan yang sama dengan nama host hanya membuktikan bahwa keduanya berasal dari tempat yang sama.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Algoritme yang dinegosiasikan berasal dari irisan kedua pihak. Jika konfigurasi klien memaku pertukaran kunci usang untuk menjangkau perangkat lama, pilihan itu berlaku untuk setiap host yang diajak bicara, jadi batasi pada host itu dan bukan secara global.

Baca metode yang benar-benar diterima server

Mengetahui metode autentikasi apa yang diizinkan server memberi tahu Anda untuk apa kata sandi itu sebenarnya. Host yang hanya menerima kunci publik tidak punya pertukaran kata sandi untuk dilindungi, dan host yang masih menerima kata sandi pantas mendapat keputusan yang sengaja diambil, bukan bawaan warisan.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Memindahkan pengguna ke autentikasi kunci mengeluarkan kata sandi pengguna itu dari pertukaran tersebut. Itu tidak membuat workstation yang disusupi menjadi aman, dan tidak membuat sesi jarak jauh yang tidak tepercaya menjadi tidak berbahaya. Itu risiko berbeda dengan kendali berbeda. Putuskan juga soal penerusan agen. Meneruskan agen ke host yang tidak tepercaya memberi host itu kemampuan memakai kunci Anda selama sesi berlangsung, dan itu paparan yang lebih besar daripada soal kata sandi yang memulainya.

Tangani peringatan kunci host sebagai langkah insiden

Ketika klien memperingatkan bahwa identifikasi host berubah, berhentilah dan verifikasi melalui kanal yang tidak melewati jalur jaringan yang sama. Bandingkan sidik jari dengan konsol server atau dengan operator yang membangunnya ulang. Menghapus entri lama untuk membungkam peringatan adalah satu-satunya tindakan yang harus Anda tolak. Itu membuang buktinya dan mengubah kemungkinan penyadapan menjadi login biasa.

Jika host memang dibangun ulang secara sah, hapus entri usang hanya setelah sidik jari baru dikonfirmasi, lalu sambungkan lagi dan periksa ulang negosiasinya. Catat perubahan itu beserta tanggal dan alasannya, karena orang berikutnya akan melihat peringatan yang sama dan perlu tahu bahwa persoalannya sudah selesai.

Apa yang tidak dicakup buku panduan ini

Operator VPN yang mengawasi lalu lintas tidak sama dengan perangkat lunak yang punya hak istimewa lokal di mesin Anda. Kompromi titik akhir, ekstensi peramban yang bermusuhan, atau perekam papan ketik berada di bawah semua yang dapat dinegosiasikan SSH, dan tidak ada terowongan yang mengubahnya. Jika workstation mencurigakan, ikuti proses insiden alih-alih menguji kerahasiaan dengan menyambung ulang lewat jalan keluar lain. Menyambung ulang membuktikan jalur jaringan berubah dan tidak membuktikan apa pun tentang titik akhir.

Akhiri dengan kasus biasa: host terverifikasi, transportasi terlindungi, metode autentikasi yang Anda pilih dengan sengaja, dan tidak ada penerusan yang tidak Anda perlukan. Kombinasi itulah jawaban atas pertanyaan di judul, dan itu empat keputusan, bukan satu.