MaxSessions, MaxStartups eller tilmelding: hvilken SSH-grænse skal vælges

Tuneltjenester, der lover én enhed pr. abonnent, får sjældent det løfte fra MaxSessions, og den første test beviser det som regel. Abonnenten åbner en anden ssh-proces, den første session kører videre, og begge tunneler bærer trafik. Hver konfigurationsmulighed tæller noget forskelligt, og ingen af dem tæller enheder. At navngive løftet først er det, der gør valget mellem dem indlysende.

Hvad hver mulighed faktisk tæller

MaxSessions begrænser antallet af åbne sessioner, som én autentificeret netværksforbindelse bærer. En session her betyder en shell, en exec-anmodning, et undersystem som SFTP eller en lignende kanal multiplekset inde i én SSH-transport. Et andet ssh-kald åbner en anden transport, autentificerer igen og får sin egen tilladelse. Den første forbindelses sessionstal er irrelevant for den.

MaxStartups begrænser samtidige forbindelser, der endnu ikke er autentificeret, udtrykt som en starttærskel, en rate og en fuld tærskel. Det findes, så et udbrud af halvt åbne håndtryk ikke kan udtømme daemonens ressourcer før autentificering. Når en klient autentificerer, holder den forbindelse op med at tælle mod MaxStartups og bliver nogens session. Det var aldrig en kvote pr. bruger, og at hæve det lader ikke abonnenten gøre mere.

En enhedsregistreringsregel er slet ikke en sshd-mulighed. Den hører til det system, der udsteder legitimationsoplysninger og holder styr på, hvilken enhed der har dem, hvilket betyder, at den har brug for tilmelding, inventar og tilbagekaldelse i stedet for en tæller. At blande det krav ind i sshd-konfigurationen er der, hvor de fleste af disse design går i stå.

Hvor MaxSessions holder op med at være en kvote

En Match User-blok ændrer, hvilke konfigurationsværdier der gælder for den bruger, så det er det naturlige sted at sætte en strammere MaxSessions for en tjenestekonto. Det, den ikke kan, er at aggregere på tværs af forbindelser, fordi muligheden vurderes pr. transport. To transporter får hver deres grænse, og brugeren ender med det dobbelte af, hvad blokken tillader.

Videresendelse er en separat overraskelse. TCP-videresendelse har ikke brug for en sessionskanal, så MaxSessions 0 kan forbyde shells og undersystemer, mens -L- og -R-tunneler stadig tillades. En tjeneste, der kun videresender, og som betragter sessionstallet som sin tunelkvote, måler intet som helst. Den adfærd er dokumenteret i OpenSSH-serverens konfigurationsreference, og den er værd at læse, før man designer omkring et mulighedsnavn.

Dump den effektive konfiguration i stedet for den fil, du tror er indlæst. Inkluderinger og drop-in-mapper betyder ofte, at den gældende værdi ikke er den værdi, du redigerede.

MaxStartups beskytter daemonen, ikke abonnenten

Den tredelte form af MaxStartups beskriver, hvor mange uautentificerede forbindelser der må findes, før daemonen begynder at droppe en procentdel af nye. Dens standardform findes, fordi en uautentificeret SSH-forbindelse er billig at åbne og dyr at holde. Det er en ressourcebeskyttelseskontrol for serveren, og den gælder for alle på én gang.

At hæve den under en loginstorm bytter daemonbeskyttelse for adgang, hvilket nogle gange er den rigtige handel og altid en bevidst en. Det gør intet for abonnenten, der vil have en anden tunnel, fordi den første tunnel allerede er autentificeret. At forveksle de to fører til en ændring, der retter det forkerte symptom og svækker serveren på samme tid.

Når logins afvises i udbrud, så kig i daemonloggen efter beskeden før autentificering, før du rører nogen af de to muligheder. Beskeden navngiver, hvilken vagt der udløste, og vagterne kan ikke udskiftes.

En slot pr. bruger kræver delt tilstand

En ægte politik om én aktiv transport kræver en reservation, der holdes et sted uden for sshd. Adgangstrinnet skal atomisk beslaglægge kontoens slot, frigive den, når forbindelsen lukkes, lade den udløbe, når en klient forsvinder uden at lukke, og beslutte, om et nyt forsøg afvises eller erstatter det gamle. Den sidste beslutning er en produktbeslutning, ikke en teknisk detalje, fordi erstatning af en aktiv tunnel afbryder nogen.

Reservationen skal også deles af hver server, der accepterer kontoen. To værter med uafhængige lokale tællere håndhæver to separate grænser, og en abonnent, der genopretter forbindelsen gennem den anden gateway, får en anden slot gratis. Uanset hvad der gemmer tilstanden, har det brug for sin egen fejlopførsel, da et utilgængeligt lager ikke må låse alle abonnenter ude.

For et løfte om én enhed skal du udstede en særskilt legitimationsoplysning pr. tilmeldt enhed og kontrollere registrering og tilbagekaldelse på det lag. En kopieret privat nøgle autentificerer stadig fra hvor som helst, så udstedelse af én nøgle pr. bruger er ikke bevis for, hvor mange maskiner der har den.

Tjek politikken med to rigtige forbindelser

Skriv accepttestene som kommandoer, før du skriver politikken. De fem tilfælde er en anden transport åbnet, mens den første er aktiv, flere kanaler inde i én transport, en klient, der kun videresender porte, en genoprettet forbindelse efter et mistet link, og den samme konto, der ankommer til en anden gateway.

Læs de effektive grænser først, og åbn derefter de forbindelser, som politikken skal afvise. Begge halvdele af den test betyder noget, og ingen af dem erstatter den anden.

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]

Kør tunnelkommandoen to gange i to terminaler, og tæl de etablerede forbindelser på port 22. Hvis begge bærer trafik, mens din politik hævder én aktiv transport, er politikken dokumentation frem for håndhævelse. Ret det hul i adgangslaget, ikke ved at sænke MaxSessions og håbe på, at den anden transport bemærker det.