MaxSessions, MaxStartups o inscripció: quin límit SSH triar

Els serveis de túnel que prometen un dispositiu per subscriptor poques vegades obtenen aquesta promesa de MaxSessions, i la primera prova normalment ho demostra. El subscriptor obre un segon procés ssh, la primera sessió continua funcionant i tots dos túnels porten trànsit. Cada opció de configuració compta una cosa diferent, i cap d’elles no compta dispositius. Anomenar primer la promesa és el que fa òbvia l’elecció entre elles.

Què compta realment cada opció

MaxSessions limita el nombre de sessions obertes que transporta una connexió de xarxa autenticada. Una sessió aquí vol dir un shell, una sol·licitud exec, un subsistema com SFTP o un canal semblant multiplexat dins d’un sol transport SSH. Una segona invocació d’ssh obre un segon transport, s’autentica de nou i obté la seva pròpia assignació. El recompte de sessions de la primera connexió li és irrellevant.

MaxStartups limita les connexions simultànies que encara no s’han autenticat, expressades com a llindar d’inici, taxa i llindar ple. Existeix perquè una ràfega d’handshakes mig oberts no pugui esgotar els recursos del dimoni abans de l’autenticació. Quan un client s’autentica, aquella connexió deixa de comptar contra MaxStartups i es converteix en la sessió d’algú. Mai no ha estat una quota per usuari, i apujar-lo no permet al subscriptor fer més.

Una regla de registre de dispositiu no és cap opció d’sshd. Pertany a qualsevol sistema que emeti credencials i faci el seguiment de quin dispositiu les té, cosa que vol dir que necessita inscripció, inventari i revocació en lloc d’un comptador. Barrejar aquest requisit a la configuració d’sshd és on s’encallen la majoria d’aquests dissenys.

On MaxSessions deixa de ser una quota

Un bloc Match User canvia quins valors de configuració s’apliquen a aquell usuari, així que és el lloc natural per fixar un MaxSessions més estricte per a un compte de servei. El que no pot fer és agregar entre connexions, perquè l’opció s’avalua per transport. Dos transports reben cadascun el seu límit, i l’usuari acaba amb el doble del que permet el bloc.

El reenviament és una sorpresa a part. El reenviament TCP no necessita un canal de sessió, així que MaxSessions 0 pot prohibir shells i subsistemes mentre encara permet túnels -L i -R. Un servei que només reenvia i tracta el nombre de sessions com la seva quota de túnel no mesura res. Aquest comportament està documentat a la referència de configuració del servidor OpenSSH, i val la pena llegir-la abans de dissenyar al voltant d’un nom d’opció.

Aboca la configuració efectiva en lloc del fitxer que creus que està carregat. Les inclusions i els directoris drop-in sovint fan que el valor vigent no sigui el valor que has editat.

MaxStartups protegeix el dimoni, no el subscriptor

La forma de tres parts de MaxStartups descriu quantes connexions no autenticades poden existir abans que el dimoni comenci a descartar un percentatge de les noves. La seva forma per defecte existeix perquè una connexió SSH no autenticada és barata d’obrir i cara de mantenir. És un control de protecció de recursos per al servidor, i s’aplica a tothom alhora.

Apujar-lo durant una tempesta d’inici de sessió canvia protecció del dimoni per admissió, cosa que de vegades és el bon intercanvi i sempre és deliberat. No fa res pel subscriptor que vol un segon túnel, perquè el primer túnel ja està autenticat. Confondre els dos porta a un canvi que arregla el símptoma equivocat i debilita el servidor alhora.

Quan es rebutgen inicis de sessió a ràfegues, mira al registre del dimoni el missatge previ a l’autenticació abans de tocar cap de les dues opcions. El missatge diu quin guardià s’ha disparat, i els guardians no són intercanviables.

Un espai per usuari necessita estat compartit

Una política genuïna d’un sol transport actiu necessita una reserva guardada en algun lloc fora d’sshd. El pas d’admissió ha de reclamar atòmicament l’espai del compte, alliberar-lo quan es tanca la connexió, fer-lo caducar quan un client desapareix sense tancar, i decidir si un nou intent es rebutja o substitueix l’antic. Aquesta última decisió és una decisió de producte, no un detall tècnic, perquè substituir un túnel actiu desconnecta algú.

La reserva també ha de ser compartida per cada servidor que accepta el compte. Dos hosts amb comptadors locals independents apliquen dos límits separats, i un subscriptor que es reconnecta per l’altra passarel·la obté un segon espai gratis. Allò que guarda l’estat necessita el seu propi comportament de fallada, ja que un magatzem inabastable no ha de bloquejar tots els subscriptors.

Per a una promesa d’un dispositiu, emet una credencial distinta per cada dispositiu inscrit i controla el registre i la revocació en aquesta capa. Una clau privada copiada encara s’autentica des de qualsevol lloc, així que emetre una clau per usuari no és prova de quantes màquines la tenen.

Comprova la política amb dues connexions reals

Escriu les proves d’acceptació com a ordres abans d’escriure la política. Els cinc casos són un segon transport obert mentre el primer és actiu, diversos canals dins d’un transport, un client que només reenvia ports, una reconnexió després de perdre un enllaç, i el mateix compte arribant a una altra passarel·la.

Llegeix primer els límits efectius i després obre les connexions que la política hauria de rebutjar. Totes dues meitats d’aquesta prova importen, i cap no substitueix l’altra.

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]

Executa l’ordre del túnel dues vegades en dos terminals i compta les connexions establertes al port 22. Si tots dos porten trànsit mentre la teva política afirma un sol transport actiu, la política és documentació i no aplicació. Arregla aquesta escletxa a la capa d’admissió, no baixant MaxSessions i esperant que el segon transport se n’adoni.