Siapa sebenarnya melihat kata laluan SSH anda pada VPN yang tidak dipercayai?

Halakan sesi SSH melalui VPN yang tidak anda uruskan sendiri, dan kata laluan itu masih milik pelayan SSH, bukan rangkaian di antaranya. Jika pengangkutan ke hos yang disahkan dilindungi dengan betul, pemerhati pasif di laluan itu tidak memperoleh kata laluan dalam bentuk yang boleh dibaca. Tetapi ubah satu syarat, dan jawapannya berubah: hos yang tidak disahkan, senarai sifer yang dilemahkan atau stesen kerja yang diceroboh semuanya menghasilkan kesan berbeza. Jalankan pemeriksaan di bawah mengikut urutan, dan anggap setiap satu sebagai syarat berhenti.

Namakan penerima sebelum anda menaip apa-apa

Medan kata laluan bergerak di dalam mesej pengesahan, dan mesej itu bergerak di dalam pengangkutan yang disulitkan. Kerahsiaan ialah sifat pengangkutan, bermakna ia bergantung kepada sama ada perlindungan telah dirundingkan dan sama ada ia dirundingkan dengan hos yang anda maksudkan. Bahagian kedua itulah yang orang langkau. Sambungan yang disulitkan kepada penipu adalah rahsia dan tidak berguna pada masa yang sama. Log masuk VPN tidak membuktikan apa-apa tentang hos SSH, dan reputasi pembekal bukan pengganti pemeriksaan kunci.

Pisahkan kedua-dua arah dalam fikiran anda. Kunci hos menjawab pelayan mana yang anda capai. Pengesahan kata laluan atau kunci menjawab pengguna mana yang diterima oleh pelayan. Memperbaiki yang kedua tidak pernah membaiki yang pertama.

Periksa identiti hos, rekod dan rundingan

Mulakan pada klien dengan rekod yang anda sudah ada. Cap jari yang diterbitkan dan dibandingkan dengan sumber dipercayai, serta entri known_hosts yang masih sepadan, memberi anda satu-satunya bukti yang penting sebelum pengesahan bermula.

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

Di sebelah pelayan, cetak cap jari yang anda berhasrat untuk terbitkan dan bukannya menyalinnya dari ingatan. Mengedarkannya di luar saluran itulah intinya; cap jari yang ditampal dari saluran sembang yang sama dengan nama hos hanya membuktikan kedua-duanya datang dari tempat yang sama.

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

Algoritma yang dirundingkan datang daripada persilangan kedua-dua pihak. Jika konfigurasi klien memaku pertukaran kunci yang lapuk untuk mencapai peranti lama, pilihan itu terpakai kepada setiap hos yang ia bercakap, jadi hadkannya kepada hos itu dan bukan secara global.

Baca kaedah yang benar-benar diterima oleh pelayan

Mengetahui kaedah pengesahan yang dibenarkan oleh pelayan memberitahu anda untuk apa kata laluan itu sebenarnya. Hos yang hanya menerima kunci awam tidak mempunyai pertukaran kata laluan untuk dilindungi, dan hos yang masih menerima kata laluan wajar mendapat keputusan yang disengajakan dan bukannya lalai warisan.

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

Memindahkan pengguna kepada pengesahan kunci mengeluarkan kata laluan pengguna itu daripada pertukaran tersebut. Ia tidak menjadikan stesen kerja yang diceroboh selamat, dan tidak menjadikan sesi jauh yang tidak dipercayai tidak berbahaya. Itu risiko berbeza dengan kawalan berbeza. Putuskan juga tentang pemajuan ejen. Memajukan ejen ke hos yang tidak dipercayai memberi hos itu keupayaan menggunakan kunci anda selagi sesi berlangsung, dan itu pendedahan yang lebih besar daripada persoalan kata laluan yang memulakannya.

Tangani amaran kunci hos sebagai langkah insiden

Apabila klien memberi amaran bahawa pengenalan hos telah berubah, berhenti dan sahkan melalui saluran yang tidak melalui laluan rangkaian yang sama. Bandingkan cap jari dengan konsol pelayan atau dengan pengendali yang membinanya semula. Memadam entri lama untuk mendiamkan amaran ialah satu-satunya tindakan yang harus anda tolak. Ia membuang bukti dan menukar kemungkinan pemintasan menjadi log masuk biasa.

Jika hos dibina semula secara sah, keluarkan entri lapuk hanya selepas cap jari baharu disahkan, kemudian sambung semula dan periksa rundingan sekali lagi. Catat perubahan itu dengan tarikh dan sebab, kerana orang seterusnya akan melihat amaran yang sama dan perlu tahu ia telah diselesaikan.

Apa yang tidak diliputi buku panduan ini

Pengendali VPN yang memerhati trafik tidak sama dengan perisian yang mempunyai keistimewaan setempat pada mesin anda. Pencabulan titik akhir, sambungan pelayar yang bermusuhan atau perakam papan kekunci berada di bawah segala yang SSH boleh rundingkan, dan tiada terowong mengubahnya. Jika stesen kerja mencurigakan, ikuti proses insiden dan bukannya menguji kerahsiaan dengan menyambung semula melalui jalan keluar lain. Menyambung semula membuktikan laluan rangkaian berubah dan tidak membuktikan apa-apa tentang titik akhir.

Akhiri dengan kes biasa: hos disahkan, pengangkutan dilindungi, kaedah pengesahan yang anda pilih dengan sengaja, dan tiada pemajuan yang tidak anda perlukan. Gabungan itulah jawapan kepada soalan dalam tajuk, dan ia empat keputusan, bukan satu.