SSH jauh melalui VPN: apa yang terowong tidak lakukan

VPN memberikan pelayan SSH laluan peribadi dan menghapuskan keperluan pendengar awam pada port 22. Ia tidak mengesahkan hos, tidak memberi kuasa kepada pengguna dan tidak menentukan akaun mana yang boleh log masuk. Itu kekal tugas SSH. Sama ada VPN ialah cara yang betul untuk sampai ke pelayan bergantung pada tiga syarat, dan terowong hanyalah salah satu jawapan yang mungkin.

Apa yang terowong ubah dan apa yang SSH masih tentukan

Terowong mengubah kebolehcapaian: alamat mana yang boleh dicapai, dan dari mana. Ia tidak mengubah apa yang berlaku selepas sambungan TCP tiba, di mana pelayan membentangkan kunci hos dan meminta identiti pengguna.

Pisahkan kedua-dua lapisan dalam fikiran anda dan dalam dokumentasi anda. Log masuk VPN membuktikan siapa yang boleh menggunakan rangkaian. Ia tidak mengatakan apa-apa tentang akaun yang wujud pada sasaran, dan ia bukan kebenaran untuk log masuk ke setiap mesin yang boleh dicapai.

Mod kegagalan juga berasingan, dan itulah yang menjadikan pemisahan itu berguna semasa insiden.

Tiga syarat yang menentukan model akses

Pertama, perlukah pelayan boleh dicapai oleh orang di luar rangkaian anda? Jika tidak, laluan peribadi serta bastion atau mesh ialah reka bentuk yang lebih kecil. Kedua, bolehkah populasi klien benar-benar menjalankan klien VPN, termasuk mereka yang berada pada peranti terurus dengan sekatan?

Ketiga, adakah anda memerlukan kawalan setiap perkhidmatan atau kawalan setiap pengguna? VPN memberikan jangkauan rangkaian; SSH memberikan akses akaun. Jika keperluannya ialah kontraktor mencapai satu hos dan tiada yang lain, itu keperluan kebenaran dan terowong sahaja tidak dapat menyatakannya.

Jawab ketiga-tiganya dan model memilih dirinya sendiri. Langkau dan anda akhirnya mendedahkan SSH secara terbuka untuk mengelakkan pelaksanaan klien.

Sahkan laluan peribadi sebelum menyalahkan SSH

Sambung ke VPN yang diluluskan dan gunakan nama atau alamat peribadi sasaran yang didokumenkan. Kemudian periksa laluan yang dipilih, kebenaran get laluan dan laluan balik ke klien. Nama yang diselesaikan dengan betul bukan bukti bahawa alamat itu mengambil terowong yang dimaksudkan, kerana awalan tempatan dan jauh yang bertindih boleh menghantar permintaan ke tempat lain sama sekali. Perbezaan itu wajar ditulis dalam runbook.

Jika sambungan tidak pernah tiba, sahkan bahawa pelayan mendengar pada antara muka yang anda jangkakan dan bahawa firewall hosnya membenarkan sumber yang benar-benar dilihatnya. NAT get laluan boleh menulis semula sumber itu, jadi senarai benaran yang ditulis untuk alamat terowong klien mungkin tidak pernah sepadan.

Ketidakpadanan itu ialah kegagalan SSH yang paling biasa disebabkan sendiri melalui VPN.

Baca peringkat kegagalan, bukan ralat gabungan

Tiga peringkat menghasilkan tiga mesej berbeza, dan hanya satu daripadanya tentang kelayakan.

Gunakan ralat yang tepat dan log pelayan itu sendiri dan bukannya menetapkan semula kelayakan VPN dan SSH bersama-sama. Menetapkan semula kedua-duanya ialah cara diagnosis lima minit menjadi insiden identiti dua hari.

Output terperinci menunjukkan peringkat mana yang anda capai:

ssh -vv [email protected]

Kekalkan kunci hos dan kebenaran

Sahkan kunci hos melalui proses dipercayai yang dimaksudkan, terutamanya selepas penggantian pelayan. Amaran kunci berubah yang tidak dijangka ialah satu-satunya mesej yang tidak boleh anda abaikan hanya kerana VPN disambungkan, kerana terowong peribadi tidak menjadikan destinasi itu mesin yang anda sangkakan. Periksa cap jari terhadap sumber yang anda percayai secara bebas daripada sambungan.

Di sisi pelayan, sahkan bahawa akaun itu dibenarkan dan bahawa kaedah pengesahan yang anda konfigurasikan ialah yang ditawarkan. Kunci yang hadir tetapi diabaikan biasanya masalah kebenaran atau konfigurasi, bukan rangkaian.

Hadkan akses perkhidmatan kepada identiti yang diperlukan dan kekalkan laluan pemulihan yang dibenarkan untuk perubahan rangkaian.