MaxSessions, MaxStartups eller enhetsregistrering: vilken SSH-gräns ska väljas

Tunneltjänster som lovar en enhet per abonnent får sällan det löftet från MaxSessions, och det första testet brukar bevisa det. Abonnenten öppnar en andra ssh-process, den första sessionen fortsätter köra, och båda tunnlarna bär trafik. Varje konfigurationsval räknar något annat, och inget av dem räknar enheter. Att namnge löftet först är det som gör valet mellan dem självklart.

Vad varje alternativ faktiskt räknar

MaxSessions begränsar antalet öppna sessioner som en autentiserad nätverksanslutning bär. En session här betyder ett shell, en exec-begäran, ett undersystem som SFTP eller en liknande kanal multiplexad inom en SSH-transport. Ett andra ssh-anrop öppnar en andra transport, autentiserar igen och får sitt eget tillstånd. Den första anslutningens sessionsantal är irrelevant för den.

MaxStartups begränsar samtidiga anslutningar som ännu inte är autentiserade, uttryckta som en starttröskel, en hastighet och en full tröskel. Det finns för att en våg av halvöppna handskakningar inte ska kunna tömma daemonens resurser före autentisering. När en klient autentiserar slutar den anslutningen att räknas mot MaxStartups och blir någons session. Det var aldrig en kvot per användare, och att höja det låter inte abonnenten göra mer.

En enhetsregistreringsregel är inte alls något sshd-alternativ. Den hör till vilket system som helst som utfärdar inloggningsuppgifter och håller reda på vilken enhet som har dem, vilket betyder att det behövs registrering, inventering och återkallelse i stället för en räknare. Att blanda in det kravet i sshd-konfigurationen är där de flesta av dessa konstruktioner fastnar.

Var MaxSessions slutar vara en kvot

Ett Match User-block ändrar vilka konfigurationsvärden som gäller för den användaren, så det är den naturliga platsen att sätta en strängare MaxSessions för ett tjänstekonto. Det den inte kan är att aggregera över anslutningar, eftersom alternativet utvärderas per transport. Två transporter får var sin gräns, och användaren får till slut det dubbla av vad blocket tillåter.

Vidarebefordran är en egen överraskning. TCP-vidarebefordran behöver ingen sessionskanal, så MaxSessions 0 kan förbjuda shellar och undersystem medan -L- och -R-tunnlar fortfarande tillåts. En tjänst som bara vidarebefordrar och ser sessionsantalet som sin tunnelkvot mäter ingenting alls. Det beteendet är dokumenterat i konfigurationsreferensen för OpenSSH-servern, och den är värd att läsa innan man designar runt ett alternativnamn.

Dumpa den effektiva konfigurationen i stället för filen du tror är laddad. Inkluderingar och drop-in-kataloger innebär ofta att värdet som gäller inte är det värde du redigerade.

MaxStartups skyddar daemonen, inte abonnenten

Den tredelade formen av MaxStartups beskriver hur många oautentiserade anslutningar som får finnas innan daemonen börjar släppa en procentandel av nya. Dess standardform finns eftersom en oautentiserad SSH-anslutning är billig att öppna och dyr att hålla. Det är en resursbeskyttningskontroll för servern, och den gäller för alla samtidigt.

Att höja den under en inloggningsstorm byter daemonskydd mot tillträde, vilket ibland är rätt byte och alltid är medvetet. Det gör inget för abonnenten som vill ha en andra tunnel, eftersom den första tunneln redan är autentiserad. Att förväxla de två leder till en ändring som åtgärdar fel symtom och försvagar servern samtidigt.

När inloggningar avvisas i vågor, titta i daemonloggen efter meddelandet före autentisering innan du rör något av de två alternativen. Meddelandet namnger vilken vakt som utlöstes, och vakterna är inte utbytbara.

En plats per användare kräver delat tillstånd

En genuin policy för en aktiv transport kräver en reservation som hålls någonstans utanför sshd. Tillträdessteget måste atomiskt kräva kontots plats, frigöra den när anslutningen stängs, låta den löpa ut när en klient försvinner utan att stänga, och avgöra om ett nytt försök avvisas eller ersätter det gamla. Det sista beslutet är ett produktbeslut, inte en teknisk detalj, eftersom att ersätta en aktiv tunnel kopplar bort någon.

Reservationen måste också delas av varje server som accepterar kontot. Två värdar med oberoende lokala räknare upprätthåller två separata gränser, och en abonnent som återansluter via den andra gatewayen får en andra plats gratis. Vad som än lagrar tillståndet behöver sitt eget felbeteende, eftersom ett oåtkomligt lager inte får låsa ute alla abonnenter.

För ett löfte om en enhet, utfärda en separat inloggningsuppgift per registrerad enhet och kontrollera registrering och återkallelse på det lagret. En kopierad privat nyckel autentiserar fortfarande varifrån som helst, så att utfärda en nyckel per användare är inte bevis för hur många maskiner som har den.

Kontrollera policyn med två riktiga anslutningar

Skriv acceptanstesterna som kommandon innan du skriver policyn. De fem fallen är en andra transport öppnad medan den första är aktiv, flera kanaler inom en transport, en klient som bara vidarebefordrar portar, en återanslutning efter att en länk fallit, och samma konto som anländer till en annan gateway.

Läs de effektiva gränserna först och öppna sedan de anslutningar som policyn ska avvisa. Båda halvorna av det testet spelar roll, och ingen av dem ersätter den andra.

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 tunnelkommandot två gånger i två terminaler och räkna de etablerade anslutningarna på port 22. Om båda bär trafik medan din policy hävdar en aktiv transport, är policyn dokumentation och inte efterlevnad. Åtgärda den luckan i tillträdeslagret, inte genom att sänka MaxSessions och hoppas att den andra transporten märker det.