MaxSessions, MaxStartups ou enrôlement : quel plafond SSH choisir

Les services de tunnel qui promettent un appareil par abonné obtiennent rarement cette promesse de MaxSessions, et le premier test le prouve généralement. L’abonné ouvre un second processus ssh, la première session continue de tourner, et les deux tunnels transportent du trafic. Chaque option de configuration compte une chose différente, et aucune d’elles ne compte les appareils. Nommer d’abord la promesse est ce qui rend le choix entre elles évident.

Ce que chaque option compte réellement

MaxSessions limite le nombre de sessions ouvertes transportées par une connexion réseau authentifiée. Une session ici désigne un shell, une requête exec, un sous-système comme SFTP ou un canal similaire multiplexé dans un seul transport SSH. Un second appel ssh ouvre un second transport, s’authentifie de nouveau et obtient sa propre autorisation. Le nombre de sessions de la première connexion lui est indifférent.

MaxStartups limite les connexions simultanées qui ne sont pas encore authentifiées, exprimées par un seuil de départ, un taux et un seuil plein. Il existe pour qu’une rafale de handshakes à moitié ouverts ne puisse pas épuiser les ressources du démon avant l’authentification. Dès qu’un client s’authentifie, cette connexion cesse de compter contre MaxStartups et devient la session de quelqu’un. Ce n’était jamais un quota par utilisateur, et l’augmenter ne permet pas à l’abonné d’en faire plus.

Une règle d’enrôlement d’appareil n’est pas du tout une option de sshd. Elle appartient à quel que soit le système qui émet les identifiants et suit quel appareil les détient, ce qui signifie qu’il lui faut enrôlement, inventaire et révocation plutôt qu’un compteur. Mélanger cette exigence dans la configuration de sshd est l’endroit où la plupart de ces conceptions se bloquent.

Où MaxSessions cesse d’être un quota

Un bloc Match User change les valeurs de configuration qui s’appliquent à cet utilisateur, c’est donc l’endroit naturel pour fixer un MaxSessions plus strict pour un compte de service. Ce qu’il ne peut pas faire, c’est agréger entre connexions, car l’option est évaluée par transport. Deux transports reçoivent chacun leur propre limite, et l’utilisateur finit avec le double de ce que le bloc autorise.

La redirection est une surprise à part. La redirection TCP n’a pas besoin d’un canal de session, donc MaxSessions 0 peut interdire les shells et les sous-systèmes tout en autorisant encore les tunnels -L et -R. Un service qui ne fait que rediriger et traite le nombre de sessions comme son quota de tunnel ne mesure rien du tout. Ce comportement est documenté dans la référence de configuration du serveur OpenSSH, et il vaut la peine de la lire avant de concevoir autour d’un nom d’option.

Affichez la configuration effective plutôt que le fichier que vous croyez chargé. Les inclusions et les répertoires drop-in signifient souvent que la valeur en vigueur n’est pas celle que vous avez modifiée.

MaxStartups protège le démon, pas l’abonné

La forme en trois parties de MaxStartups décrit combien de connexions non authentifiées peuvent exister avant que le démon commence à rejeter un pourcentage des nouvelles. Sa forme par défaut existe parce qu’une connexion SSH non authentifiée est bon marché à ouvrir et coûteuse à garder. C’est un contrôle de protection des ressources pour le serveur, et il s’applique à tout le monde à la fois.

L’augmenter pendant une tempête de connexions échange la protection du démon contre l’admission, ce qui est parfois le bon compromis et toujours un compromis délibéré. Cela ne fait rien pour l’abonné qui veut un second tunnel, car le premier tunnel est déjà authentifié. Confondre les deux conduit à un changement qui corrige le mauvais symptôme et affaiblit le serveur en même temps.

Quand les connexions sont refusées par rafales, regardez dans le journal du démon le message pré-authentification avant de toucher à l’une ou l’autre option. Le message nomme quel garde s’est déclenché, et les gardes ne sont pas interchangeables.

Un emplacement par utilisateur exige un état partagé

Une véritable politique d’un seul transport actif a besoin d’une réservation détenue quelque part hors de sshd. L’étape d’admission doit revendiquer atomiquement l’emplacement du compte, le libérer quand la connexion se ferme, le faire expirer quand un client disparaît sans fermer, et décider si une nouvelle tentative est rejetée ou remplace l’ancienne. Cette dernière décision est une décision produit, pas un détail technique, car remplacer un tunnel actif déconnecte quelqu’un.

La réservation doit aussi être partagée par chaque serveur qui accepte le compte. Deux hôtes avec des compteurs locaux indépendants appliquent deux limites séparées, et un abonné qui se reconnecte par l’autre passerelle obtient un second emplacement gratuitement. Tout ce qui stocke l’état a besoin de son propre comportement en cas de panne, car un magasin injoignable ne doit pas verrouiller tous les abonnés.

Pour une promesse d’un appareil, émettez un identifiant distinct par appareil enrôlé et contrôlez l’enrôlement et la révocation à cette couche. Une clé privée copiée s’authentifie toujours depuis n’importe où, donc émettre une clé par utilisateur ne prouve pas combien de machines la détiennent.

Vérifiez la politique avec deux connexions réelles

Écrivez les tests d’acceptation sous forme de commandes avant d’écrire la politique. Les cinq cas sont un second transport ouvert pendant que le premier est actif, plusieurs canaux dans un transport, un client qui ne fait que rediriger des ports, une reconnexion après la perte d’un lien, et le même compte arrivant sur une autre passerelle.

Lisez d’abord les limites effectives, puis ouvrez les connexions que la politique est censée refuser. Les deux moitiés de ce test comptent, et aucune ne remplace l’autre.

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]

Exécutez la commande de tunnel deux fois dans deux terminaux et comptez les connexions établies sur le port 22. Si les deux transportent du trafic alors que votre politique affirme un seul transport actif, la politique est de la documentation plutôt que de l’application. Corrigez cet écart dans la couche d’admission, pas en baissant MaxSessions et en espérant que le second transport le remarque.