MaxSessions, MaxStartups oder Geräteregistrierung: Welches SSH-Limit sie wählen

Tunneldienste, die ein Gerät pro Abonnent versprechen, bekommen dieses Versprechen selten von MaxSessions, und der erste Test beweist es meist. Der Abonnent startet einen zweiten ssh-Prozess, die erste Sitzung läuft weiter, und beide Tunnel übertragen Datenverkehr. Jede Konfigurationsoption zählt etwas anderes, und keine von ihnen zählt Geräte. Das Versprechen zuerst zu benennen macht die Wahl zwischen ihnen offensichtlich.

Was jede Option tatsächlich zählt

MaxSessions begrenzt die Anzahl offener Sitzungen, die eine authentifizierte Netzwerkverbindung trägt. Eine Sitzung bedeutet hier eine Shell, eine exec-Anfrage, ein Subsystem wie SFTP oder einen ähnlichen Kanal, der innerhalb eines SSH-Transports gemultiplext wird. Ein zweiter ssh-Aufruf öffnet einen zweiten Transport, authentifiziert sich erneut und erhält seine eigene Erlaubnis. Die Sitzungszahl der ersten Verbindung ist für ihn unerheblich.

MaxStartups begrenzt gleichzeitige Verbindungen, die noch nicht authentifiziert sind, ausgedrückt als Startschwelle, Rate und volle Schwelle. Es existiert, damit ein Schub halboffener Handshakes die Ressourcen des Daemons vor der Authentifizierung nicht erschöpfen kann. Sobald sich ein Client authentifiziert, zählt diese Verbindung nicht mehr gegen MaxStartups und wird jemandes Sitzung. Es war nie ein Kontingent pro Benutzer, und eine Erhöhung erlaubt dem Abonnenten nicht, mehr zu tun.

Eine Geräteregistrierungsregel ist überhaupt keine sshd-Option. Sie gehört zu welchem System auch immer Anmeldedaten ausstellt und verfolgt, welches Gerät sie hält, was bedeutet, dass es Registrierung, Inventar und Widerruf statt eines Zählers braucht. Diese Anforderung in die sshd-Konfiguration zu mischen, ist der Punkt, an dem die meisten dieser Entwürfe stecken bleiben.

Wo MaxSessions aufhört, ein Kontingent zu sein

Ein Match User-Block ändert, welche Konfigurationswerte für diesen Benutzer gelten, ist also der natürliche Ort, ein strengeres MaxSessions für ein Dienstkonto festzulegen. Was er nicht kann, ist über Verbindungen hinweg zu aggregieren, weil die Option pro Transport bewertet wird. Zwei Transporte erhalten jeweils ihr eigenes Limit, und der Benutzer hat am Ende doppelt so viel, wie der Block erlaubt.

Weiterleitung ist eine eigene Überraschung. TCP-Weiterleitung braucht keinen Sitzungskanal, sodass MaxSessions 0 Shells und Subsysteme verbieten kann, während -L- und -R-Tunnel weiterhin erlaubt sind. Ein Dienst, der nur weiterleitet und die Sitzungszahl als sein Tunnelkontingent betrachtet, misst überhaupt nichts. Dieses Verhalten ist in der OpenSSH-Server-Konfigurationsreferenz dokumentiert, und es lohnt sich, sie zu lesen, bevor man um einen Optionsnamen herum entwirft.

Geben Sie die effektive Konfiguration aus, nicht die Datei, von der Sie glauben, dass sie geladen ist. Includes und Drop-in-Verzeichnisse bedeuten häufig, dass der wirksame Wert nicht der Wert ist, den Sie bearbeitet haben.

MaxStartups schützt den Daemon, nicht den Abonnenten

Die dreiteilige Form von MaxStartups beschreibt, wie viele nicht authentifizierte Verbindungen bestehen dürfen, bevor der Daemon beginnt, einen Prozentsatz neuer zu verwerfen. Ihre Standardform existiert, weil eine nicht authentifizierte SSH-Verbindung billig zu öffnen und teuer zu halten ist. Das ist eine Ressourcenschutzkontrolle für den Server, und sie gilt für alle gleichzeitig.

Eine Erhöhung während eines Anmeldesturms tauscht Daemonschutz gegen Zulassung, was manchmal der richtige Tausch und immer ein bewusster ist. Sie tut nichts für den Abonnenten, der einen zweiten Tunnel will, weil der erste Tunnel bereits authentifiziert ist. Die beiden zu verwechseln führt zu einer Änderung, die das falsche Symptom behebt und gleichzeitig den Server schwächt.

Wenn Anmeldungen in Schüben abgelehnt werden, sehen Sie im Daemon-Log nach der Meldung vor der Authentifizierung, bevor Sie eine der beiden Optionen anfassen. Die Meldung nennt, welche Sperre ausgelöst hat, und die Sperren sind nicht austauschbar.

Ein Slot pro Benutzer braucht gemeinsamen Zustand

Eine echte Richtlinie für einen aktiven Transport braucht eine Reservierung, die irgendwo außerhalb von sshd gehalten wird. Der Zulassungsschritt muss den Slot des Kontos atomar beanspruchen, ihn freigeben, wenn die Verbindung schließt, ihn ablaufen lassen, wenn ein Client ohne Schließen verschwindet, und entscheiden, ob ein neuer Versuch abgelehnt oder der alte ersetzt wird. Diese letzte Entscheidung ist eine Produktentscheidung, kein technisches Detail, denn das Ersetzen eines aktiven Tunnels trennt jemanden.

Die Reservierung muss auch von jedem Server geteilt werden, der das Konto akzeptiert. Zwei Hosts mit unabhängigen lokalen Zählern setzen zwei getrennte Limits durch, und ein Abonnent, der sich über das andere Gateway neu verbindet, bekommt einen zweiten Slot gratis. Was auch immer den Zustand speichert, braucht sein eigenes Fehlerverhalten, da ein nicht erreichbarer Speicher nicht jeden Abonnenten aussperren darf.

Für ein Ein-Gerät-Versprechen stellen Sie pro registriertem Gerät eigene Anmeldedaten aus und steuern Registrierung und Widerruf auf dieser Ebene. Ein kopierter privater Schlüssel authentifiziert sich weiterhin von überall, daher ist die Ausgabe eines Schlüssels pro Benutzer kein Beweis dafür, wie viele Maschinen ihn halten.

Prüfen Sie die Richtlinie mit zwei echten Verbindungen

Schreiben Sie die Abnahmetests als Befehle, bevor Sie die Richtlinie schreiben. Die fünf Fälle sind ein zweiter Transport, der geöffnet wird, während der erste aktiv ist, mehrere Kanäle in einem Transport, ein Client, der nur Ports weiterleitet, eine Wiederverbindung nach einem Verbindungsabbruch und dasselbe Konto, das an einem anderen Gateway ankommt.

Lesen Sie zuerst die effektiven Limits und öffnen Sie dann die Verbindungen, die die Richtlinie ablehnen soll. Beide Hälften dieses Tests zählen, und keine ersetzt die 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]

Führen Sie den Tunnelbefehl zweimal in zwei Terminals aus und zählen Sie die aufgebauten Verbindungen auf Port 22. Wenn beide Datenverkehr tragen, während Ihre Richtlinie einen aktiven Transport behauptet, ist die Richtlinie Dokumentation statt Durchsetzung. Beheben Sie diese Lücke in der Zulassungsschicht, nicht indem Sie MaxSessions senken und hoffen, dass der zweite Transport es bemerkt.