SSH terbalik untuk satu perangkat: pendengar loopback atau VPN dengan rute?
Satu port manajemen untuk perangkat yang hanya bisa menghubungi keluar. Tiga kondisi menentukan apakah terowongan terbalik cukup atau Anda perlu jalur berute yang sebenarnya.
Perangkat Anda berada di belakang NAT operator, dapat membuka koneksi keluar, dan menjalankan server SSH yang tidak dapat dijangkau siapa pun. Permintaan yang datang biasanya dirumuskan sebagai "beri perangkat itu VPN", yang merupakan salah satu jawaban di antara beberapa. Sebelum menerimanya, putuskan apakah Anda memerlukan satu port TCP administratif atau jalur berute ke seluruh subnet, karena itu proyek yang berbeda dengan paparan yang berbeda.
Terowongan terbalik menjawab versi sempit dengan baik. Perangkat menghubungi hub Anda, meminta hub mendengarkan pada port loopback, dan meneruskan port itu kembali ke layanan SSH-nya sendiri. Setelah itu administrator mencapai pendengar melalui hub, bukan melalui internet publik.
Tiga kondisi yang menentukan pilihan
Tuliskan ini sebelum konfigurasi apa pun. Ini adalah batas antara pintu masuk manajemen yang terbatas dan perluasan jaringan, dan mencampuradukkannya adalah cara terowongan lima baris berubah menjadi jaringan datar tanpa pemilik.
| Condition | Reverse tunnel fits | Something else is needed |
|---|---|---|
| How many services must be reachable? | One, or a small fixed set on loopback | Anything that needs many ports or dynamic discovery |
| Who connects, and how are they authenticated? | Named administrators with their own hub accounts | Third parties, or anything needing per-flow audit you do not control |
| Does the device's own LAN need to be reachable? | No | Yes, so a routed VPN or a managed platform is the honest answer |
Baris ketiga adalah yang diperdebatkan orang. Terowongan ke port SSH perangkat tidak menempatkan tetangganya di jaringan Anda, dan tidak boleh dibuat tampak demikian melalui rantai penerusan lebih lanjut. Jika kebutuhannya memang LAN, katakan itu dan rancang itu sebagai gantinya.
Sisi hub: akun relai yang terbatas
Beri setiap perangkat akun relainya sendiri dengan autentikasi kunci publik dan tanpa sesi interaktif. Match blok yang dibatasi pada akun itu menjaga izin tetap kecil, dan kunci privat tetap berada di perangkat tempat ia seharusnya.
Match User relay-dev-7
AuthenticationMethods publickey
PubkeyAuthentication yes
AllowTcpForwarding remote
PermitListen 127.0.0.1:21022
GatewayPorts no
MaxSessions 0
PermitTTY no
X11Forwarding no
AllowAgentForwarding no
MaxSessions 0 adalah baris yang menarik. Itu menolak sesi shell dan subsistem sambil tetap mengizinkan penerusan yang dibutuhkan perangkat, sehingga kunci yang dicuri tidak dapat diubah menjadi login interaktif. PermitListen memakukan alamat dan port pendengar di sisi hub, dan GatewayPorts no menjaganya tetap di loopback alih-alih membukanya ke jaringan tempat hub berada.
Uji konfigurasi efektif sebelum memuat ulang, dan biarkan sesi kedua tetap terbuka selama Anda melakukannya. Match blok yang secara tidak sengaja berlaku untuk semua orang, atau salah ketik pada nama opsi, adalah cara klasik untuk mengunci diri sendiri keluar dari kotak yang sedang Anda keraskan. Buang konfigurasi yang berjalan dan bacalah opsi kembali alih-alih memercayai berkas yang baru Anda tulis. Perhatikan bahwa dukungan opsi berbeda antar build, sehingga baris yang diterima di server yang lebih baru bisa saja diabaikan oleh yang lebih lama.
Sisi perangkat: penerusan yang gagal dengan berisik
Perangkat membuka koneksi dan meminta pendengar. Dua alamat dalam argumen -R berarti hal yang berbeda, dan membacanya dari kiri ke kanan adalah cara tercepat untuk mengingat mana yang mana.
ssh -NT \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=30 \
-o ServerAliveCountMax=3 \
-R 127.0.0.1:21022:127.0.0.1:22 \
[email protected]
Pasangan kiri adalah tempat hub seharusnya mendengarkan. Pasangan kanan adalah tujuan perangkat terhubung ketika permintaan datang, diselesaikan dari sisi perangkat itu sendiri. Menukarnya menghasilkan terowongan yang naik dengan bersih dan meneruskan ke tempat yang salah, yang lebih buruk daripada kegagalan.
ExitOnForwardFailure=yes membuat perintah keluar ketika pendengar yang diminta tidak dapat dibentuk, sehingga loop mulai ulang memberi tahu Anda kebenaran alih-alih meninggalkan sesi yang setengah berfungsi. Itu tidak mengatakan apa pun tentang apakah layanan SSH lokal sehat nanti, jadi pasangkan dengan manajer proses dan uji koneksi nyata sesekali.
Jangan pernah mengganti alamat dengaran loopback dengan wildcard untuk menghindari lompatan tambahan. Perubahan tunggal itu adalah perbedaan antara jalur manajemen dan port yang dapat dijangkau publik, dan biasanya terjadi saat penelusuran kesalahan lalu menetap. Jika rekan kerja tidak dapat mencapai port melalui hub, perbaiki konfigurasi lompatan alih-alih memperlebar pengikatan. Loopback adalah seluruh argumen keamanan desain ini.
Akses administrator melalui hub
Administrator dengan akun biasa di hub dapat melompat melaluinya ke port yang diteruskan. Akun relai tidak digunakan untuk ini, dan itulah inti dari menjaganya tetap terpisah.
ssh -J [email protected] -o HostKeyAlias=device-7 \
-p 21022 [email protected]
Verifikasi kunci host perangkat di bawah alias yang Anda pilih, karena kunci itu mengidentifikasi perangkat di ujung rantai dan terowongan hanyalah transportasi. Login ujung ke ujung tetap mengautentikasi kedua ujung; terowongan yang berakhir di hub bersama tidak dengan sendirinya membuatnya menjadi jalur tepercaya.
Miliki siklus hidupnya
Jalankan perintah perangkat di bawah manajer proses dengan tepat satu instans aktif dan kebijakan mulai ulang yang Anda pilih dengan sengaja. Opsi keepalive mendeteksi rekan yang mati; opsi itu tidak menghidupkan kembali proses yang sudah keluar.
Lalu tulis prosedur penonaktifan. Setiap perangkat mendapat pendengar dan kuncinya sendiri, jadi menonaktifkan berarti mencabut akun itu dan menghapus kunci itu, bukan merotasi rahasia yang dibagi seluruh armada.
Terakhir, ingat apa yang loopback berikan kepada Anda. Itu membatasi paparan jaringan dan tidak melakukan apa pun terhadap pengguna lokal lain di hub bersama, jadi kebijakan akses hub itu sendiri tetap harus benar. Referensi sshd_config mendokumentasikan setiap opsi yang digunakan di atas, dan ada baiknya membaca bagian penerusan secara lengkap sebelum memperlebar salah satunya.