MaxSessions, MaxStartups ar įrenginio registracija: kurią SSH ribą pasirinkti

Tunelių paslaugos, žadančios vieną įrenginį vienam abonentui, šį pažadą retai gauna iš MaxSessions, ir pirmasis testas paprastai tai įrodo. Abonentas atidaro antrą ssh procesą, pirmoji sesija toliau veikia, ir abu tuneliai perduoda srautą. Kiekviena konfigūracijos parinktis skaičiuoja skirtingą dalyką, ir nė viena jų neskaičiuoja įrenginių. Pažado įvardijimas pirmiausia ir padaro pasirinkimą tarp jų akivaizdų.

Ką iš tikrųjų skaičiuoja kiekviena parinktis

MaxSessions riboja vienos autentifikuotos tinklo jungties perduodamų atvirų sesijų skaičių. Sesija čia reiškia apvalkalą, exec užklausą, posistemę, tokią kaip SFTP, ar panašų kanalą, multipleksuotą viename SSH transporte. Antrasis ssh iškvietimas atidaro antrą transportą, iš naujo autentifikuojasi ir gauna savo leidimą. Pirmosios jungties sesijų skaičius jam nesvarbus.

MaxStartups riboja vienalaikes jungtis, kurios dar nėra autentifikuotos, išreikštas pradiniu slenksčiu, norma ir visišku slenksčiu. Jis egzistuoja, kad pusiau atvirų rankos paspaudimų protrūkis negalėtų išsekinti demono išteklių prieš autentifikavimą. Kai klientas autentifikuojasi, ta jungtis nustoja būti skaičiuojama prieš MaxStartups ir tampa kažkieno sesija. Tai niekada nebuvo kvota vienam naudotojui, ir jos padidinimas neleidžia abonentui daryti daugiau.

Įrenginio registracijos taisyklė visai nėra sshd parinktis. Ji priklauso bet kuriai sistemai, kuri išduoda prisijungimo duomenis ir seka, kuris įrenginys juos turi, o tai reiškia, kad jai reikia registracijos, inventorizacijos ir atšaukimo, o ne skaitiklio. Šio reikalavimo sumaišymas su sshd konfigūracija yra vieta, kur dauguma tokių projektų įstringa.

Kur MaxSessions nustoja būti kvota

Match User blokas pakeičia, kurios konfigūracijos reikšmės taikomos tam naudotojui, tad tai natūrali vieta griežtesniam MaxSessions nustatyti paslaugos paskyrai. Ko jis negali, tai agreguoti tarp jungčių, nes parinktis vertinama kiekvienam transportui. Du transportai gauna po savo ribą, ir naudotojas galiausiai turi dvigubai daugiau, nei leidžia blokas.

Persiuntimas yra atskira staigmena. TCP persiuntimui nereikia sesijos kanalo, todėl MaxSessions 0 gali uždrausti apvalkalus ir posistemes ir vis tiek leisti -L bei -R tunelius. Paslauga, kuri tik persiunčia ir sesijų skaičių laiko savo tunelio kvota, nieko nematuoja. Šis elgesys dokumentuotas OpenSSH serverio konfigūracijos žinyne, ir verta jį perskaityti prieš projektuojant aplink parinkties pavadinimą.

Išverskite veiksmingą konfigūraciją, o ne failą, kuris, jūsų manymu, įkeltas. Įtraukimai ir drop-in katalogai dažnai reiškia, kad galiojanti reikšmė nėra ta, kurią redagavote.

MaxStartups saugo demoną, o ne abonentą

Tridalė MaxStartups forma aprašo, kiek neautentifikuotų jungčių gali egzistuoti prieš demonui pradedant mesti naujų procentą. Jo numatytoji forma egzistuoja todėl, kad neautentifikuotą SSH jungtį atidaryti pigu, o išlaikyti brangu. Tai serverio išteklių apsaugos kontrolė, ir ji taikoma visiems vienu metu.

Padidinti jį prisijungimų audros metu reiškia išmainyti demono apsaugą į priėmimą, kas kartais yra teisinga mainai ir visada sąmoningi. Tai nieko neduoda abonentui, kuris nori antro tunelio, nes pirmasis tunelis jau autentifikuotas. Sumaišius abu, gaunamas pakeitimas, kuris ištaiso netinkamą simptomą ir tuo pačiu susilpnina serverį.

Kai prisijungimai atmetami būriais, prieš liesdami bet kurią parinktį pažiūrėkite demono žurnale pranešimą prieš autentifikavimą. Pranešimas įvardija, kuri apsauga suveikė, ir apsaugos nėra keičiamos.

Vienam naudotojui skirtas lizdas reikalauja bendros būsenos

Tikra vieno aktyvaus transporto politika reikalauja rezervacijos, laikomos kažkur už sshd ribų. Priėmimo žingsnis turi atomiškai užimti paskyros lizdą, atlaisvinti jį, kai jungtis uždaroma, leisti jam pasibaigti, kai klientas dingsta neuždarydamas, ir nuspręsti, ar naujas bandymas atmetamas, ar pakeičia senąjį. Šis paskutinis sprendimas yra produkto sprendimas, o ne techninė detalė, nes aktyvaus tunelio pakeitimas ką nors atjungia.

Rezervaciją turi dalytis ir kiekvienas serveris, kuris priima paskyrą. Du hostai su nepriklausomais vietiniais skaitikliais taiko dvi atskiras ribas, ir abonentas, kuris iš naujo prisijungia per kitą šliuzą, nemokamai gauna antrą lizdą. Kad ir kas saugotų būseną, jam reikia savo gedimo elgsenos, nes nepasiekiama saugykla neturi užrakinti visų abonentų.

Dėl vieno įrenginio pažado išduokite atskirus prisijungimo duomenis kiekvienam registruotam įrenginiui ir kontroliuokite registraciją bei atšaukimą tame sluoksnyje. Nukopijuotas privatus raktas vis tiek autentifikuojasi iš bet kur, todėl vieno rakto vienam naudotojui išdavimas nėra įrodymas, kiek mašinų jį turi.

Patikrinkite politiką dviem tikromis jungtimis

Parašykite priėmimo testus kaip komandas prieš rašydami politiką. Penki atvejai yra antras transportas, atidarytas pirmajam esant aktyviam, keli kanalai viename transporte, klientas, kuris tik persiunčia portus, prisijungimas iš naujo po nutrūkusios jungties, ir ta pati paskyra atvykstanti į kitą šliuzą.

Pirmiausia perskaitykite veiksmingas ribas, tada atidarykite jungtis, kurias politika turėtų atmesti. Abi to testo pusės svarbios, ir nė viena nepakeičia kitos.

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]

Paleiskite tunelio komandą du kartus dviejuose terminaluose ir suskaičiuokite užmegztas jungtis 22 prievade. Jei abi perduoda srautą, kol jūsų politika teigia vieną aktyvų transportą, politika yra dokumentacija, o ne vykdymas. Ištaisykite šią spragą priėmimo sluoksnyje, o ne sumažindami MaxSessions ir tikėdamiesi, kad antrasis transportas tai pastebės.