Apakah --key-password di OpenConnect adalah kata sandi akun VPN Anda?

Baca nama opsi itu secara harfiah. Opsi itu menyebut sebuah kunci, dan kebingungan dimulai saat berkas yang dibuka dikira akun yang diautentikasi. Tempelkan kata sandi akun ke opsi itu dan klien akan mencoba membuka berkas kunci dengannya, yang gagal karena alasan yang sama sekali tidak berkaitan dengan login VPN.

Bagian yang membingungkan adalah satu koneksi bisa sah-sah saja membutuhkan kedua rahasia. Autentikasi sertifikat klien mungkin memerlukan kunci terenkripsi, dan gateway yang sama mungkin masih menjalankan pertukaran autentikasi pengguna setelah sertifikat diterima. Tidak ada rahasia yang memenuhi tahap lainnya, dan kegagalan di satu sisi terlihat sangat mirip dengan kegagalan di sisi lain dari luar.

Dua rahasia, dua tugas berbeda

Baca perannya sebagai akses berkas versus izin masuk jaringan. Kata sandi kunci mendekripsi kunci privat PEM yang disebut di --sslkey agar sertifikat klien TLS dapat disajikan. Dekripsi itu terjadi secara lokal, di dalam proses klien, dan frasa sandi itu sendiri tidak pernah dikirim ke gateway. Yang dilihat gateway adalah sertifikat dan tanda tangan yang dibuat dengan kunci tersebut. Manual OpenConnect menempatkan --key-password di samping --certificate dan --sslkey, dan pada build yang dapat memakai kunci di TPM opsi yang sama justru membawa kata sandi kunci akar penyimpanan.

Kata sandi akun berbeda jenisnya. Kata sandi itu masuk ke pertukaran autentikasi: formulir nama pengguna dan kata sandi, token, putaran SAML, atau kombinasi tertentu yang diumumkan gateway. Sebagian penerapan tidak memintanya sama sekali bila sertifikat adalah satu-satunya faktor, dan sebagian memintanya bahkan setelah sertifikat, karena sertifikat membuktikan perangkat sedangkan akun membuktikan orang.

Mencampur keduanya menghasilkan kesalahan yang menyesatkan. Gateway yang menolak login biasanya melaporkan kegagalan autentikasi, sedangkan frasa sandi kunci yang salah biasanya gagal lebih awal, saat lapisan TLS tidak dapat membaca berkas kunci. Itu tahap yang berbeda dengan perbaikan yang berbeda, dan namanya cukup mirip sehingga orang menukarnya lalu mengejar log yang salah. Perhatikan perintah mana yang muncul sebelum Anda mengubah pengaturan apa pun, karena kata-kata pada perintah itu adalah diagnostik termurah yang Anda miliki.

Kapan kata sandi kunci benar-benar diperlukan

Opsi ini hanya bermakna bila ada kunci terenkripsi untuk dibuka. Jika Anda terhubung dengan nama pengguna dan kata sandi tanpa sertifikat klien, --key-password tidak punya sasaran untuk bekerja, dan menyertakannya tidak mengubah apa pun. Jika Anda terhubung dengan --certificate dan --sslkey, format berkas kunci itu sendiri yang menentukan apakah frasa sandi akan diminta.

Kedua rahasia dalam satu perintah lazim di lingkungan terkelola: sertifikat perangkat dalam kunci terenkripsi, ditambah login per pengguna. Urutan yang benar adalah membiarkan klien meminta frasa sandi kunci secara lokal, menyelesaikan jabat tangan sertifikat, lalu menangani permintaan akun dari gateway secara terpisah. Mencoba mengisi keduanya di muka lewat satu skrip yang dipakai ulang adalah tempat kekacauan biasanya dimulai.

Diagnostik yang berguna adalah melihat kapan kegagalan terjadi. Jika klien berhenti sebelum autentikasi jaringan dimulai, curigai berkas kunci, formatnya, atau frasa sandinya. Jika sesi TLS terbentuk dan gateway kemudian menolak pengguna, kunci sudah menjalankan tugasnya dan masalahnya ada pada pertukaran akun.

Menjauhkan kedua rahasia dari riwayat shell

Argumen baris perintah dapat dibaca pengguna lokal lain melalui tabel proses dan sering tertangkap di riwayat shell, skrip, dan transkrip dukungan. OpenConnect dapat membaca kata sandi akun dari masukan standar dengan --passwd-on-stdin, dan frasa sandi kunci dapat berasal dari perintah interaktif atau agen alih-alih argumen. Tidak ada mekanisme yang membuat rahasia aman dengan sendirinya, tetapi keduanya menjauhkannya dari tempat yang paling terbuka.

Berkas pun perlu perlakuan yang sama. Skrip yang menulis frasa sandi ke berkas sementara sebaiknya membuatnya dengan izin yang ketat, menghapusnya saat keluar, dan menghindari direktori yang dapat dibaca semua orang. Frasa sandi yang bertahan setelah sesi di direktori sementara adalah salinan yang lupa Anda buat. Variabel lingkungan terlihat oleh proses anak dan sering ikut tercetak oleh alat debug, jadi bukan peningkatan gratis dibandingkan argumen.

Keluaran diagnostik adalah kebocoran yang senyap. Log klien pada tingkat detail lebih tinggi dapat menampilkan isi permintaan atau nilai opsi, dan transkrip terminal yang tersalin mudah ditempel ke tiket, jadi baca keluarannya sebelum membagikannya.

Tombol desktop yang mati adalah gangguan yang berbeda

Entri VPN desktop yang menampilkan pemintal lalu tidak melakukan apa-apa biasanya bukan masalah autentikasi sama sekali. Tombol itu milik pengelola jaringan, applet vendor, atau plugin yang menjalankan OpenConnect atas nama Anda, dan komponen yang hilang atau profil yang tidak terbaca dapat menghasilkan gejala persis seperti itu. Cari tahu proses apa yang dijalankan tombol itu dan baca galatnya sebelum menyentuh kredensial.

Ada godaan untuk melonggarkan verifikasi sertifikat atau mematikan pemeriksaan saat GUI menolak terhubung. Itu mengubah gangguan integrasi klien menjadi penurunan keamanan dan jarang memperbaiki masalah peluncuran. Biarkan verifikasi server tetap utuh, pastikan profil mengarah ke gateway yang dimaksud, dan periksa apakah pembantu yang diharapkan GUI benar-benar terpasang.

Daftar periksa singkat memisahkan kasusnya. Kegagalan lokal sebelum ada paket keluar mengarah ke kunci atau pemasangan klien. Penolakan gateway setelah sesi TLS mengarah ke pertukaran akun. Tombol yang tidak pernah menjalankan klien mengarah ke integrasi desktop. Tiga gangguan berbeda, salah satunya kata sandi yang hampir Anda tempel di kotak yang salah.