MaxSessions, MaxStartups, atau pendaftaran: batas SSH mana yang dipilih
MaxSessions menghitung kanal di dalam satu transport, MaxStartups menjaga handshake yang belum diautentikasi, dan keduanya tidak menghitung perangkat. Tentukan dulu janjinya.
Layanan terowongan yang menjanjikan satu perangkat per pelanggan jarang mendapatkan janji itu dari MaxSessions, dan uji pertama biasanya membuktikannya. Pelanggan membuka proses ssh kedua, sesi pertama tetap berjalan, dan kedua terowongan membawa lalu lintas. Setiap opsi konfigurasi menghitung hal yang berbeda, dan tidak satu pun menghitung perangkat. Menamai janji lebih dulu adalah yang membuat pilihan di antara keduanya jelas.
Apa yang sebenarnya dihitung setiap opsi
MaxSessions membatasi jumlah sesi terbuka yang dibawa oleh satu koneksi jaringan yang diautentikasi. Sesi di sini berarti shell, permintaan exec, subsistem seperti SFTP, atau kanal serupa yang dimultiplekskan di dalam satu transport SSH. Pemanggilan ssh kedua membuka transport kedua, mengautentikasi ulang dan mendapatkan jatahnya sendiri. Jumlah sesi koneksi pertama tidak relevan baginya.
MaxStartups membatasi koneksi bersamaan yang belum diautentikasi, dinyatakan sebagai ambang mulai, laju dan ambang penuh. Ini ada agar ledakan handshake setengah terbuka tidak dapat menghabiskan sumber daya daemon sebelum autentikasi. Setelah klien diautentikasi, koneksi itu berhenti dihitung terhadap MaxStartups dan menjadi sesi seseorang. Itu tidak pernah menjadi kuota per pengguna, dan menaikkannya tidak membuat pelanggan bisa berbuat lebih banyak.
Aturan pendaftaran perangkat sama sekali bukan opsi sshd. Itu milik sistem mana pun yang menerbitkan kredensial dan melacak perangkat mana yang memegangnya, yang berarti membutuhkan pendaftaran, inventaris dan pencabutan alih-alih penghitung. Mencampurkan persyaratan itu ke konfigurasi sshd adalah tempat sebagian besar desain ini macet.
Di mana MaxSessions berhenti menjadi kuota
Blok Match User mengubah nilai konfigurasi mana yang berlaku untuk pengguna itu, jadi itu tempat alami untuk menetapkan MaxSessions yang lebih ketat bagi akun layanan. Yang tidak bisa dilakukannya adalah menggabungkan antar koneksi, karena opsi dievaluasi per transport. Dua transport masing-masing mendapat batasnya sendiri, dan pengguna akhirnya memiliki dua kali lipat dari yang diizinkan blok.
Penerusan adalah kejutan tersendiri. Penerusan TCP tidak memerlukan kanal sesi, jadi MaxSessions 0 dapat melarang shell dan subsistem sambil tetap mengizinkan terowongan -L dan -R. Layanan yang hanya meneruskan dan menganggap jumlah sesi sebagai kuota terowongannya tidak mengukur apa pun. Perilaku itu didokumentasikan dalam referensi konfigurasi server OpenSSH, dan layak dibaca sebelum merancang di sekitar nama opsi.
Buang konfigurasi efektif, bukan file yang Anda kira dimuat. Penyertaan dan direktori drop-in sering berarti nilai yang berlaku bukan nilai yang Anda edit.
MaxStartups melindungi daemon, bukan pelanggan
Bentuk tiga bagian MaxStartups menjelaskan berapa banyak koneksi yang belum diautentikasi boleh ada sebelum daemon mulai menjatuhkan persentase koneksi baru. Bentuk bawaannya ada karena koneksi SSH yang belum diautentikasi murah dibuka dan mahal dipertahankan. Itu kontrol perlindungan sumber daya untuk server, dan berlaku untuk semua orang sekaligus.
Menaikkannya selama badai login menukar perlindungan daemon dengan penerimaan, yang kadang merupakan pertukaran tepat dan selalu disengaja. Itu tidak melakukan apa pun bagi pelanggan yang ingin terowongan kedua, karena terowongan pertama sudah diautentikasi. Mencampurkan keduanya menghasilkan perubahan yang memperbaiki gejala yang salah dan melemahkan server pada saat yang sama.
Ketika login ditolak secara beruntun, lihat log daemon untuk pesan pra-autentikasi sebelum menyentuh salah satu opsi. Pesan itu menyebut penjaga mana yang aktif, dan para penjaga tidak dapat dipertukarkan.
Slot per pengguna memerlukan keadaan bersama
Kebijakan satu transport aktif yang sungguh-sungguh memerlukan reservasi yang disimpan di suatu tempat di luar sshd. Langkah penerimaan harus mengklaim slot akun secara atomik, melepaskannya saat koneksi ditutup, membiarkannya kedaluwarsa saat klien menghilang tanpa menutup, dan memutuskan apakah upaya baru ditolak atau menggantikan yang lama. Keputusan terakhir itu adalah keputusan produk, bukan detail teknis, karena mengganti terowongan aktif memutus seseorang.
Reservasi juga harus dibagi oleh setiap server yang menerima akun. Dua host dengan penghitung lokal independen menegakkan dua batas terpisah, dan pelanggan yang menyambung ulang melalui gateway lain mendapatkan slot kedua gratis. Apa pun yang menyimpan keadaan memerlukan perilaku kegagalannya sendiri, karena penyimpanan yang tak terjangkau tidak boleh mengunci semua pelanggan.
Untuk janji satu perangkat, terbitkan kredensial berbeda per perangkat yang terdaftar dan kendalikan pendaftaran dan pencabutan pada lapisan itu. Kunci privat yang disalin tetap diautentikasi dari mana saja, jadi menerbitkan satu kunci per pengguna bukan bukti berapa banyak mesin yang memegangnya.
Uji kebijakan dengan dua koneksi nyata
Tulis tes penerimaan sebagai perintah sebelum Anda menulis kebijakan. Kelima kasus itu adalah transport kedua yang dibuka saat yang pertama aktif, banyak kanal di dalam satu transport, klien yang hanya meneruskan port, penyambungan ulang setelah tautan putus, dan akun yang sama tiba di gateway lain.
Baca batas efektif lebih dulu, lalu buka koneksi yang seharusnya ditolak kebijakan. Kedua bagian uji itu penting, dan tidak satu pun menggantikan yang lain.
sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]Jalankan perintah terowongan dua kali di dua terminal dan hitung koneksi yang terbentuk pada port 22. Jika keduanya membawa lalu lintas sementara kebijakan Anda mengklaim satu transport aktif, kebijakan itu dokumentasi, bukan penegakan. Perbaiki celah itu di lapisan penerimaan, bukan dengan menurunkan MaxSessions dan berharap transport kedua menyadarinya.