SSH melalui relai aliran NGINX tanpa merosakkannya

Pengepala PROXY ialah mesej kepada penerima yang menjangkakannya, dan rekod DNS yang diproksikan bukan relai TCP. Betulkan tepi dan huluan secara berasingan.

SSH awam melalui relai gagal pada dua sempadan yang tidak berkaitan, dan membetulkan satu biasanya mendedahkan yang lain. Sama ada tepi mengembalikan respons HTTP dan bukannya membawa aliran, atau relai menambah pengepala di hadapan yang tidak pernah dipersetujui oleh backend untuk dibaca. Tiga syarat menentukan yang mana anda lihat: ke mana rekod awam sebenarnya menunjuk, apa yang dihantar blok aliran ke huluan, dan nama mana yang disahkan oleh klien SSH. Kendalikan mengikut urutan itu.

Dua sempadan, dua simptom

Kegagalan di tepi kelihatan seperti halaman status HTTP tiba di tempat sepanduk SSH sepatutnya berada. Sambungan lengkap pada peringkat TCP dan bait pertama ialah teks milik pelayan web. Itu ketidakpadanan protokol, bukan paket hilang. Ia juga memberitahu anda bahawa tepi sengaja menyajikan sesuatu yang lain untuk nama itu.

Kegagalan di huluan kelihatan berbeza. Sambungan sampai ke sshd, sshd membaca bait yang bukan pertukaran pengenalan yang dijangka, dan sesi mati atau tergantung tanpa pernah menawarkan kunci.

Kedua-duanya mudah dikelirukan kerana kedua-duanya menghasilkan klien yang bersambung dan kemudian gagal. Respons protokol pertama yang anda terima ialah yang membezakannya, sebab itu ia patut ada dalam tiket.

Pengepala PROXY ialah mesej, bukan suis

Dalam modul aliran, proxy_protocol on mengarahkan NGINX menulis pengepala protokol PROXY ke arah huluan sebelum muatan. Ia tidak mengaktifkan proksi TCP, dan tiada kaitan dengan penyulitan SSH. Ia ialah nota yang ditujukan kepada penerima. Jika penerima tidak dapat membacanya, ia menjadi sampah pada permulaan aliran.

Perkhidmatan penerima mesti menggunakan pengepala itu dengan sengaja. sshd biasa menjangkakan pertukaran pengenalan SSH sebagai bait pertama pada sambungan, jadi mukadimah yang tidak dijangka memecahkan jabat tangan dengan cara yang kelihatan seperti pelayan rosak.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

Serpihan itu ialah keseluruhan relai yang berfungsi untuk backend yang boleh dicapai melalui VPN. Tiada arahan PROXY muncul kerana penerima tidak bertutur dalam protokol itu, dan ketiadaan itu ialah keputusan, bukan ketinggalan.

Pisahkan juga kedua-dua arah. Menetapkan proxy_protocol pada baris listen bermakna NGINX menjangkakan kliennya sendiri menghantar pengepala dahulu; mengaktifkannya untuk klien SSH biasa menghasilkan tepat sebaliknya daripada masalah yang biasanya cuba diselesaikan orang.

Apa yang sebenarnya dicapai oleh nama hos awam

Halaman HTTP 400 dalam sesi SSH ialah bukti tentang tepi. Sesuatu di laluan bertutur dalam HTTP, dan tiada kerja kunci atau akaun di backend akan mengubahnya. Berhenti mengubah backend sehingga tepi diselesaikan.

Rekod berproksi biasa Cloudflare membawa trafik HTTP dan HTTPS yang disokongnya pada port yang ditentukan. Menghidupkan proksi untuk nama hos tidak mencipta relai TCP umum, dan memindahkan SSH ke port 443 tidak menjadikannya HTTPS.

Terdapat dua arah yang boleh dilaksanakan. Rekod DNS sahaja boleh menunjuk ke relai TCP anda sendiri, yang meletakkan keputusan pendedahan di tangan anda. Sebagai alternatif, gunakan produk yang mendokumenkan pengangkutan SSH secara eksplisit, dengan konfigurasi asal, klien dan aksesnya sendiri.

Apa pun yang anda pilih, relai masih memerlukan laluan VPN ke backend, sambungan yang dibenarkan dan laluan balik. Laluan itu bukan pilihan kerana bahagian awam berfungsi.

Kekalkan identiti SSH stabil melalui alias

Pengguna biasanya mahu terus menaip nama hos sedia ada mereka. Alias konfigurasi SSH boleh melakukannya tanpa mengubah apa-apa pada relai, dan mengekalkan perubahan di sebelah klien di tempat yang sepatutnya.

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

Tanpa HostKeyAlias, OpenSSH mencari kunci hos di bawah nama yang disambungkan, jadi entri bergerak dan setiap pengguna melihat amaran kunci berubah pada penggunaan pertama. Menetapkan alias mengekalkan entri known-hosts stabil sementara sambungan masih pergi ke relai.

Alias ini hanya terpakai kepada repositori jauh berasaskan SSH. URL Git HTTPS tidak merujuknya, dan URL jauh biasa mesti sepadan dengan pengangkutan yang benar-benar anda sediakan.

Apa yang anda tidak boleh lakukan ialah mematikan pengesahan kunci hos supaya amaran hilang. Itu membuang perlindungan yang tidak pernah diminta oleh pembaikan pemajuan untuk disentuh, dan mengubah kacauan kosmetik menjadi pendedahan sebenar.

Sahkan setiap lompatan secara berasingan

Uji pendengar awam sendirian, kemudian sambungan relai ke backend dari hos relai, dan hanya selepas itu klien dari hujung ke hujung. Setiap satu daripada tiga ujian itu menyingkirkan lapisan yang berbeza. Melangkau satu bermakna dua hasil yang tinggal tidak dapat ditafsirkan. Tiga pemerhatian, tiga tempat kegagalan boleh hidup.

Simpan alamat destinasi, port dan bait protokol pertama bersama setiap hasil. Tiga serangkai itu membezakan ralat tepi daripada masalah penghalaan VPN dan kegagalan pengesahan SSH, dan itulah perbezaan antara pembaikan dan tekaan.

Akhir sekali, dokumenkan pendedahan yang dimaksudkan. Relai TCP yang membawa SSH ke backend peribadi ialah pembukaan yang disengajakan dalam perimeter awam, dan ia wajar mendapat semakan yang sama seperti mana-mana perkhidmatan masuk lain.

Artikel berkaitan