MaxSessions, MaxStartups sau înregistrarea dispozitivului: ce limită SSH alegi

Serviciile de tunel care promit un dispozitiv per abonat primesc arareori această promisiune de la MaxSessions, iar primul test de obicei dovedește acest lucru. Abonatul deschide un al doilea proces ssh, prima sesiune continuă să ruleze, iar ambele tuneluri transportă trafic. Fiecare opțiune de configurare numără altceva, iar niciuna dintre ele nu numără dispozitive. Numirea promisiunii mai întâi este ceea ce face alegerea dintre ele evidentă.

Ce numără de fapt fiecare opțiune

MaxSessions limitează numărul de sesiuni deschise transportate de o singură conexiune de rețea autentificată. O sesiune aici înseamnă un shell, o cerere exec, un subsistem precum SFTP sau un canal similar multiplexat într-un singur transport SSH. Un al doilea apel ssh deschide un al doilea transport, se autentifică din nou și primește propria permisiune. Numărul de sesiuni al primei conexiuni este irelevant pentru el.

MaxStartups limitează conexiunile simultane care nu au fost încă autentificate, exprimate ca prag de pornire, rată și prag complet. Există pentru ca o rafală de handshake-uri pe jumătate deschise să nu poată epuiza resursele daemonului înainte de autentificare. Odată ce un client se autentifică, acea conexiune nu mai contează împotriva MaxStartups și devine sesiunea cuiva. Nu a fost niciodată o cotă per utilizator, iar creșterea lui nu îi permite abonatului să facă mai mult.

O regulă de înregistrare a dispozitivului nu este deloc o opțiune sshd. Aparține oricărui sistem care emite credențiale și urmărește ce dispozitiv le deține, ceea ce înseamnă că are nevoie de înregistrare, inventar și revocare în locul unui contor. Amestecarea acestei cerințe în configurația sshd este locul unde majoritatea acestor proiecte se blochează.

Unde MaxSessions încetează să fie o cotă

Un bloc Match User schimbă ce valori de configurare se aplică acelui utilizator, deci este locul natural pentru a stabili un MaxSessions mai strict pentru un cont de serviciu. Ceea ce nu poate face este să agregheze între conexiuni, deoarece opțiunea este evaluată per transport. Două transporturi primesc fiecare propria limită, iar utilizatorul ajunge cu dublul a ceea ce permite blocul.

Redirecționarea este o surpriză separată. Redirecționarea TCP nu are nevoie de un canal de sesiune, așa că MaxSessions 0 poate interzice shell-urile și subsistemele în timp ce permite în continuare tunelurile -L și -R. Un serviciu care doar redirecționează și tratează numărul de sesiuni ca pe cota sa de tunel nu măsoară nimic. Acest comportament este documentat în referința de configurare a serverului OpenSSH, și merită citită înainte de a proiecta în jurul unui nume de opțiune.

Afișați configurația efectivă, nu fișierul despre care credeți că este încărcat. Includerile și directoarele drop-in înseamnă adesea că valoarea în vigoare nu este valoarea pe care ați editat-o.

MaxStartups protejează daemonul, nu abonatul

Forma în trei părți a MaxStartups descrie câte conexiuni neautentificate pot exista înainte ca daemonul să înceapă să arunce un procent din cele noi. Forma sa implicită există pentru că o conexiune SSH neautentificată este ieftin de deschis și scump de întreținut. Este un control de protecție a resurselor pentru server, și se aplică tuturor deodată.

Creșterea lui în timpul unei furtuni de autentificări schimbă protecția daemonului pe admitere, ceea ce uneori este schimbul corect și întotdeauna este deliberat. Nu face nimic pentru abonatul care vrea un al doilea tunel, pentru că primul tunel este deja autentificat. Confundarea celor două duce la o schimbare care repară simptomul greșit și slăbește serverul în același timp.

Când autentificările sunt refuzate în rafale, uitați-vă în jurnalul daemonului la mesajul dinaintea autentificării înainte de a atinge oricare dintre cele două opțiuni. Mesajul numește ce gardă s-a declanșat, iar gărzile nu sunt interschimbabile.

Un slot per utilizator necesită stare partajată

O politică autentică de un singur transport activ are nevoie de o rezervare ținută undeva în afara sshd. Pasul de admitere trebuie să revendice atomic slotul contului, să îl elibereze când conexiunea se închide, să îl lase să expire când un client dispare fără să închidă, și să decidă dacă o nouă încercare este respinsă sau o înlocuiește pe cea veche. Această ultimă decizie este o decizie de produs, nu un detaliu tehnic, pentru că înlocuirea unui tunel activ deconectează pe cineva.

Rezervarea trebuie să fie partajată și de fiecare server care acceptă contul. Două gazde cu contoare locale independente aplică două limite separate, iar un abonat care se reconectează prin cealaltă gateway primește un al doilea slot gratuit. Orice stochează starea are nevoie de propriul comportament la eșec, deoarece un depozit inaccesibil nu trebuie să blocheze toți abonații.

Pentru o promisiune de un dispozitiv, emiteți o credențială distinctă pentru fiecare dispozitiv înregistrat și controlați înregistrarea și revocarea la acel nivel. O cheie privată copiată se autentifică în continuare de oriunde, așa că emiterea unei chei per utilizator nu este dovada câte mașini o dețin.

Verificați politica cu două conexiuni reale

Scrieți testele de acceptare ca comenzi înainte de a scrie politica. Cele cinci cazuri sunt un al doilea transport deschis în timp ce primul este activ, mai multe canale într-un transport, un client care doar redirecționează porturi, o reconectare după căderea unei legături, și același cont ajungând la o altă gateway.

Citiți mai întâi limitele efective, apoi deschideți conexiunile pe care politica ar trebui să le refuze. Ambele jumătăți ale acelui test contează, și niciuna nu o înlocuiește pe cealaltă.

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]

Rulați comanda de tunel de două ori în două terminale și numărați conexiunile stabilite pe portul 22. Dacă ambele transportă trafic în timp ce politica dumneavoastră susține un singur transport activ, politica este documentație și nu aplicare. Remediați acea lacună în stratul de admitere, nu prin scăderea MaxSessions și sperând că al doilea transport va observa.