MaxSessions, MaxStartups of apparaatregistratie: welke SSH-limiet kiezen
MaxSessions telt kanalen binnen één transport, MaxStartups beschermt niet-geauthenticeerde handshakes, en geen van beide telt apparaten. Bepaal eerst de belofte.
Tunneldiensten die één apparaat per abonnee beloven, krijgen die belofte zelden van MaxSessions, en de eerste test bewijst het meestal. De abonnee opent een tweede ssh-proces, de eerste sessie blijft draaien, en beide tunnels dragen verkeer. Elke configuratieoptie telt iets anders, en geen ervan telt apparaten. De belofte eerst benoemen is wat de keuze ertussen vanzelfsprekend maakt.
Wat elke optie werkelijk telt
MaxSessions beperkt het aantal open sessies dat één geauthenticeerde netwerkverbinding draagt. Een sessie betekent hier een shell, een exec-verzoek, een subsysteem zoals SFTP, of een vergelijkbaar kanaal dat binnen één SSH-transport wordt gemultiplext. Een tweede ssh-aanroep opent een tweede transport, authenticeert opnieuw en krijgt zijn eigen toewijzing. Het sessieaantal van de eerste verbinding is voor hem irrelevant.
MaxStartups beperkt gelijktijdige verbindingen die nog niet zijn geauthenticeerd, uitgedrukt als startdrempel, snelheid en volledige drempel. Het bestaat zodat een uitbarsting van halfopen handshakes de bronnen van de daemon vóór authenticatie niet kan uitputten. Zodra een client authenticeert, telt die verbinding niet meer mee voor MaxStartups en wordt het iemands sessie. Het was nooit een quotum per gebruiker, en het verhogen ervan laat de abonnee niet meer doen.
Een apparaatregistratieregel is helemaal geen sshd-optie. Die hoort bij welk systeem dan ook dat inloggegevens uitgeeft en bijhoudt welk apparaat ze heeft, wat betekent dat het registratie, inventaris en intrekking nodig heeft in plaats van een teller. Die eis in de sshd-configuratie mengen is waar de meeste van deze ontwerpen vastlopen.
Waar MaxSessions ophoudt een quotum te zijn
Een Match User-blok verandert welke configuratiewaarden voor die gebruiker gelden, dus het is de natuurlijke plek om een strengere MaxSessions voor een serviceaccount in te stellen. Wat het niet kan, is over verbindingen heen aggregeren, omdat de optie per transport wordt beoordeeld. Twee transporten krijgen elk hun eigen limiet, en de gebruiker houdt uiteindelijk het dubbele van wat het blok toestaat.
Doorsturen is een aparte verrassing. TCP-doorsturen heeft geen sessiekanaal nodig, dus MaxSessions 0 kan shells en subsystemen verbieden terwijl -L- en -R-tunnels nog steeds zijn toegestaan. Een dienst die alleen doorstuurt en het sessieaantal als zijn tunnelquotum beschouwt, meet helemaal niets. Dat gedrag is gedocumenteerd in de OpenSSH-serverconfiguratiereferentie, en het is de moeite waard die te lezen voordat je rond een optienaam ontwerpt.
Dump de effectieve configuratie in plaats van het bestand waarvan je denkt dat het is geladen. Includes en drop-in-mappen betekenen vaak dat de geldende waarde niet de waarde is die je hebt bewerkt.
MaxStartups beschermt de daemon, niet de abonnee
De driedelige vorm van MaxStartups beschrijft hoeveel niet-geauthenticeerde verbindingen mogen bestaan voordat de daemon een percentage van nieuwe begint te laten vallen. De standaardvorm bestaat omdat een niet-geauthenticeerde SSH-verbinding goedkoop te openen en duur te houden is. Het is een bescherming van bronnen voor de server, en het geldt voor iedereen tegelijk.
Het verhogen tijdens een login-storm ruilt daemonbescherming in voor toelating, wat soms de juiste ruil is en altijd een bewuste. Het doet niets voor de abonnee die een tweede tunnel wil, omdat de eerste tunnel al is geauthenticeerd. De twee verwarren leidt tot een wijziging die het verkeerde symptoom verhelpt en tegelijk de server verzwakt.
Wanneer logins in golven worden geweigerd, kijk dan in het daemonlog naar het bericht vóór authenticatie voordat je een van beide opties aanraakt. Het bericht noemt welke bewaking afging, en de bewakingen zijn niet uitwisselbaar.
Een slot per gebruiker vereist gedeelde status
Een echte policy van één actief transport vereist een reservering die ergens buiten sshd wordt gehouden. De toelatingsstap moet de slot van het account atomair claimen, hem vrijgeven wanneer de verbinding sluit, hem laten verlopen wanneer een client verdwijnt zonder te sluiten, en beslissen of een nieuwe poging wordt geweigerd of de oude vervangt. Die laatste beslissing is een productbeslissing, geen technisch detail, omdat het vervangen van een actieve tunnel iemand loskoppelt.
De reservering moet ook worden gedeeld door elke server die het account accepteert. Twee hosts met onafhankelijke lokale tellers handhaven twee afzonderlijke limieten, en een abonnee die opnieuw verbindt via de andere gateway krijgt gratis een tweede slot. Wat de status ook opslaat, het heeft zijn eigen faalgedrag nodig, omdat een onbereikbare opslag niet elke abonnee mag buitensluiten.
Voor een belofte van één apparaat, geef per geregistreerd apparaat afzonderlijke inloggegevens uit en beheer registratie en intrekking op die laag. Een gekopieerde privésleutel authenticeert nog steeds vanaf elke plek, dus één sleutel per gebruiker uitgeven is geen bewijs van hoeveel machines hem hebben.
Controleer het beleid met twee echte verbindingen
Schrijf de acceptatietests als commando's voordat je het beleid schrijft. De vijf gevallen zijn een tweede transport dat wordt geopend terwijl het eerste actief is, meerdere kanalen binnen één transport, een client die alleen poorten doorstuurt, opnieuw verbinden na een weggevallen link, en hetzelfde account dat bij een andere gateway aankomt.
Lees eerst de effectieve limieten en open dan de verbindingen die het beleid hoort te weigeren. Beide helften van die test doen ertoe, en geen ervan vervangt de andere.
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]Voer het tunnelcommando twee keer uit in twee terminals en tel de tot stand gebrachte verbindingen op poort 22. Als beide verkeer dragen terwijl je beleid één actief transport beweert, is het beleid documentatie en geen handhaving. Repareer die kloof in de toelatingslaag, niet door MaxSessions te verlagen en te hopen dat het tweede transport het opmerkt.