MaxSessions, MaxStartups o registrazione: quale limite SSH scegliere

I servizi tunnel che promettono un dispositivo per abbonato raramente ottengono quella promessa da MaxSessions, e il primo test di solito lo dimostra. L’abbonato apre un secondo processo ssh, la prima sessione continua a funzionare e entrambi i tunnel trasportano traffico. Ogni opzione di configurazione conta qualcosa di diverso, e nessuna di esse conta i dispositivi. Nominare prima la promessa è ciò che rende ovvia la scelta tra loro.

Cosa conta davvero ogni opzione

MaxSessions limita il numero di sessioni aperte trasportate da una connessione di rete autenticata. Una sessione qui significa una shell, una richiesta exec, un sottosistema come SFTP o un canale simile multiplato dentro un solo trasporto SSH. Una seconda invocazione di ssh apre un secondo trasporto, si autentica di nuovo e ottiene il proprio limite. Il numero di sessioni della prima connessione gli è irrilevante.

MaxStartups limita le connessioni simultanee che non sono ancora autenticate, espresse come soglia di avvio, tasso e soglia piena. Esiste perché un’ondata di handshake a metà apertura non possa esaurire le risorse del demone prima dell’autenticazione. Quando un client si autentica, quella connessione smette di contare contro MaxStartups e diventa la sessione di qualcuno. Non è mai stata una quota per utente, e alzarlo non permette all’abbonato di fare di più.

Una regola di registrazione del dispositivo non è affatto un’opzione di sshd. Appartiene a qualunque sistema che emetta credenziali e tenga traccia di quale dispositivo le possiede, il che significa che servono registrazione, inventario e revoca invece di un contatore. Mescolare questo requisito nella configurazione di sshd è il punto in cui la maggior parte di questi progetti si blocca.

Dove MaxSessions smette di essere una quota

Un blocco Match User cambia quali valori di configurazione si applicano a quell’utente, quindi è il posto naturale per impostare un MaxSessions più severo per un account di servizio. Ciò che non può fare è aggregare tra connessioni, perché l’opzione viene valutata per trasporto. Due trasporti ricevono ciascuno il proprio limite, e l’utente finisce con il doppio di quanto il blocco consente.

L’inoltramento è una sorpresa a parte. L’inoltramento TCP non ha bisogno di un canale di sessione, quindi MaxSessions 0 può vietare shell e sottosistemi pur consentendo ancora i tunnel -L e -R. Un servizio che si limita a inoltrare e considera il numero di sessioni la propria quota tunnel non misura proprio nulla. Questo comportamento è documentato nella guida di configurazione del server OpenSSH, e vale la pena leggerla prima di progettare intorno a un nome di opzione.

Stampate la configurazione effettiva invece del file che pensate sia caricato. Le inclusioni e le directory drop-in spesso significano che il valore in vigore non è quello che avete modificato.

MaxStartups protegge il demone, non l’abbonato

La forma in tre parti di MaxStartups descrive quante connessioni non autenticate possono esistere prima che il demone inizi a scartare una percentuale delle nuove. La sua forma predefinita esiste perché una connessione SSH non autenticata è economica da aprire e costosa da mantenere. È un controllo di protezione delle risorse per il server, e si applica a tutti contemporaneamente.

Alzarlo durante una tempesta di accessi scambia la protezione del demone con l’ammissione, che a volte è lo scambio giusto e sempre è deliberato. Non fa nulla per l’abbonato che vuole un secondo tunnel, perché il primo tunnel è già autenticato. Confondere i due porta a una modifica che corregge il sintomo sbagliato e indebolisce il server nello stesso momento.

Quando gli accessi vengono rifiutati a ondate, guardate nel log del demone il messaggio pre-autenticazione prima di toccare una delle due opzioni. Il messaggio indica quale guardia è scattata, e le guardie non sono intercambiabili.

Uno slot per utente richiede stato condiviso

Una politica genuina di un solo trasporto attivo richiede una prenotazione tenuta da qualche parte fuori da sshd. Il passo di ammissione deve rivendicare atomicamente lo slot dell’account, rilasciarlo alla chiusura della connessione, farlo scadere quando un client scompare senza chiudere, e decidere se un nuovo tentativo viene rifiutato o sostituisce quello vecchio. Quest’ultima decisione è una decisione di prodotto, non un dettaglio tecnico, perché sostituire un tunnel attivo disconnette qualcuno.

La prenotazione deve essere condivisa anche da ogni server che accetta l’account. Due host con contatori locali indipendenti applicano due limiti separati, e un abbonato che si riconnette attraverso l’altro gateway ottiene un secondo slot gratis. Qualunque cosa memorizzi lo stato ha bisogno del proprio comportamento in caso di guasto, perché un archivio irraggiungibile non deve bloccare tutti gli abbonati.

Per una promessa di un dispositivo, emettete una credenziale distinta per ogni dispositivo registrato e controllate registrazione e revoca a quel livello. Una chiave privata copiata si autentica comunque da qualsiasi luogo, quindi emettere una chiave per utente non è prova di quante macchine la possiedano.

Verificate la politica con due connessioni reali

Scrivete i test di accettazione come comandi prima di scrivere la politica. I cinque casi sono un secondo trasporto aperto mentre il primo è attivo, più canali dentro un trasporto, un client che inoltra solo porte, una riconnessione dopo la caduta di un collegamento, e lo stesso account che arriva a un altro gateway.

Leggete prima i limiti effettivi, poi aprite le connessioni che la politica dovrebbe rifiutare. Entrambe le metà di quel test contano, e nessuna sostituisce 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]

Eseguite il comando del tunnel due volte in due terminali e contate le connessioni stabilite sulla porta 22. Se entrambi trasportano traffico mentre la vostra politica dichiara un solo trasporto attivo, la politica è documentazione e non applicazione. Correggete quel divario nel livello di ammissione, non abbassando MaxSessions e sperando che il secondo trasporto se ne accorga.