MaxSessions, MaxStartups eller enhetsregistrering: hvilken SSH-grense bør velges

Tjenester for tunneler som lover én enhet per abonnent, får sjelden det løftet fra MaxSessions, og den første testen beviser det vanligvis. Abonnenten åpner en andre ssh-prosess, den første økten fortsetter å kjøre, og begge tunnelene bærer trafikk. Hvert konfigurasjonsvalg teller noe forskjellig, og ingen av dem teller enheter. Å navngi løftet først er det som gjør valget mellom dem åpenbart.

Hva hvert valg faktisk teller

MaxSessions begrenser antallet åpne økter som én autentisert nettverksforbindelse bærer. En økt her betyr en shell, en exec-forespørsel, et undersystem som SFTP eller en lignende kanal multiplekset i én SSH-transport. Et andre ssh-kall åpner en andre transport, autentiserer på nytt og får sin egen tillatelse. Øktantallet til den første forbindelsen er irrelevant for den.

MaxStartups begrenser samtidige forbindelser som ennå ikke er autentisert, uttrykt som en startterskel, en rate og en full terskel. Det finnes for at en byge av halvåpne håndtrykk ikke skal kunne tømme daemonens ressurser før autentisering. Når en klient autentiserer, slutter den forbindelsen å telle mot MaxStartups og blir noens økt. Det var aldri en kvote per bruker, og å øke det lar ikke abonnenten gjøre mer.

En enhetsregistreringsregel er ikke en sshd-innstilling i det hele tatt. Den hører til hvilket som helst system som utsteder påloggingsinformasjon og holder oversikt over hvilken enhet som har den, noe som betyr at det trengs registrering, oversikt og tilbakekalling i stedet for en teller. Å blande det kravet inn i sshd-konfigurasjonen er der de fleste av disse designene stopper.

Hvor MaxSessions slutter å være en kvote

En Match User-blokk endrer hvilke konfigurasjonsverdier som gjelder for den brukeren, så det er det naturlige stedet å sette en strengere MaxSessions for en tjenestekonto. Det den ikke kan, er å aggregere på tvers av forbindelser, fordi innstillingen vurderes per transport. To transporter får hver sin grense, og brukeren ender opp med det dobbelte av det blokken tillater.

Videresending er en egen overraskelse. TCP-videresending trenger ingen øktkanal, så MaxSessions 0 kan forby sheller og undersystemer mens -L- og -R-tunneler fortsatt tillates. En tjeneste som bare videresender og betrakter øktantallet som sin tunnelkvote, måler ingenting i det hele tatt. Den atferden er dokumentert i konfigurasjonsreferansen for OpenSSH-serveren, og den er verdt å lese før man designer rundt et innstillingsnavn.

Dump den effektive konfigurasjonen i stedet for filen du tror er lastet. Inkluderinger og drop-in-kataloger betyr ofte at verdien som gjelder, ikke er verdien du redigerte.

MaxStartups beskytter daemonen, ikke abonnenten

Den tredelte formen av MaxStartups beskriver hvor mange uautentiserte forbindelser som kan eksistere før daemonen begynner å droppe en prosentandel av nye. Standardformen finnes fordi en uautentisert SSH-forbindelse er billig å åpne og dyr å holde. Det er en ressursbeskyttelseskontroll for serveren, og den gjelder for alle samtidig.

Å øke den under en påloggingsstorm bytter daemonbeskyttelse mot adgang, noe som noen ganger er den riktige bytten og alltid er bevisst. Det gjør ingenting for abonnenten som vil ha en andre tunnel, fordi den første tunnelen allerede er autentisert. Å forveksle de to fører til en endring som retter det gale symptomet og svekker serveren samtidig.

Når pålogginger avvises i byger, se i daemonloggen etter meldingen før autentisering før du rører noen av de to innstillingene. Meldingen navngir hvilken vakt som utløste, og vaktene kan ikke byttes om.

En plass per bruker trenger delt tilstand

En ekte policy om én aktiv transport trenger en reservasjon som holdes et sted utenfor sshd. Adgangstrinnet må atomisk kreve kontoens plass, frigjøre den når forbindelsen lukkes, la den utløpe når en klient forsvinner uten å lukke, og avgjøre om et nytt forsøk avvises eller erstatter det gamle. Den siste avgjørelsen er en produktbeslutning, ikke en teknisk detalj, fordi å erstatte en aktiv tunnel kobler fra noen.

Reservasjonen må også deles av hver server som godtar kontoen. To verter med uavhengige lokale tellere håndhever to separate grenser, og en abonnent som kobler til på nytt via den andre gatewayen, får en andre plass gratis. Uansett hva som lagrer tilstanden, trenger det sin egen feilatferd, siden et utilgjengelig lager ikke må låse alle abonnenter ute.

For et løfte om én enhet, utsted en egen påloggingsinformasjon per registrert enhet og kontroller registrering og tilbakekalling på det laget. En kopiert privat nøkkel autentiserer fortsatt fra hvor som helst, så å utstede én nøkkel per bruker er ikke bevis for hvor mange maskiner som har den.

Sjekk policyen med to ekte forbindelser

Skriv aksepttestene som kommandoer før du skriver policyen. De fem tilfellene er en andre transport åpnet mens den første er aktiv, flere kanaler i én transport, en klient som bare videresender porter, en ny tilkobling etter at en lenke falt, og den samme kontoen som ankommer en annen gateway.

Les de effektive grensene først, og åpne deretter forbindelsene som policyen skal avvise. Begge halvdelene av den testen betyr noe, og ingen av dem erstatter den andre.

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]

Kjør tunnelkommandoen to ganger i to terminaler og tell de etablerte forbindelsene på port 22. Hvis begge bærer trafikk mens policyen din hevder én aktiv transport, er policyen dokumentasjon og ikke håndhevelse. Rett opp det gapet i adgangslaget, ikke ved å senke MaxSessions og håpe at den andre transporten legger merke til det.