MaxSessions, MaxStartups ou rexistro: que límite SSH escoller

Os servizos de túnel que prometen un dispositivo por subscritor raramente obteñen esa promesa de MaxSessions, e a primeira proba adoita demostralo. O subscritor abre un segundo proceso ssh, a primeira sesión segue funcionando e ambos os túneles levan tráfico. Cada opción de configuración conta algo distinto, e ningunha delas conta dispositivos. Nomear primeiro a promesa é o que fai obvia a elección entre elas.

Que conta realmente cada opción

MaxSessions limita o número de sesións abertas que transporta unha conexión de rede autenticada. Unha sesión aquí significa un shell, unha solicitude exec, un subsistema como SFTP ou unha canle similar multiplexada dentro dun só transporte SSH. Unha segunda invocación de ssh abre un segundo transporte, autentícase de novo e obtén o seu propio cupo. O número de sesións da primeira conexión é irrelevante para el.

MaxStartups limita as conexións simultáneas que aínda non se autenticaron, expresadas como limiar de inicio, taxa e limiar completo. Existe para que unha ráfaga de handshakes a medio abrir non poida esgotar os recursos do demonio antes da autenticación. Cando un cliente se autentica, esa conexión deixa de contar contra MaxStartups e convértese na sesión de alguén. Nunca foi unha cota por usuario, e subilo non permite ao subscritor facer máis.

Unha regra de rexistro de dispositivos non é en absoluto unha opción de sshd. Pertence a calquera sistema que emita credenciais e rastree que dispositivo as ten, o que significa que necesita rexistro, inventario e revogación en lugar dun contador. Mesturar ese requisito na configuración de sshd é onde se atascan a maioría destes deseños.

Onde MaxSessions deixa de ser unha cota

Un bloque Match User cambia que valores de configuración se aplican a ese usuario, así que é o lugar natural para fixar un MaxSessions máis estrito para unha conta de servizo. O que non pode facer é agregar entre conexións, porque a opción avalíase por transporte. Dous transportes reciben cada un o seu propio límite, e o usuario acaba co dobre do que permite o bloque.

O reenvío é unha sorpresa aparte. O reenvío TCP non necesita unha canle de sesión, así que MaxSessions 0 pode prohibir shells e subsistemas mentres aínda permite túneles -L e -R. Un servizo que só reenvía e trata o número de sesións como a súa cota de túnel non mide nada en absoluto. Ese comportamento está documentado na referencia de configuración do servidor OpenSSH, e paga a pena lela antes de deseñar arredor dun nome de opción.

Volve a configuración efectiva en lugar do ficheiro que cres que está cargado. As inclusións e os directorios drop-in adoitan significar que o valor vixente non é o valor que editaches.

MaxStartups protexe o demonio, non o subscritor

A forma de tres partes de MaxStartups describe cantas conexións non autenticadas poden existir antes de que o demonio comece a descartar unha porcentaxe das novas. A súa forma predeterminada existe porque unha conexión SSH non autenticada é barata de abrir e cara de manter. É un control de protección de recursos para o servidor, e aplícase a todos á vez.

Subilo durante unha tormenta de inicios de sesión cambia protección do demonio por admisión, o que ás veces é o intercambio correcto e sempre é deliberado. Non fai nada polo subscritor que quere un segundo túnel, porque o primeiro túnel xa está autenticado. Confundir os dous leva a un cambio que arranxa o síntoma equivocado e debilita o servidor ao mesmo tempo.

Cando se rexeitan inicios de sesión a ráfagas, mira no rexistro do demonio a mensaxe previa á autenticación antes de tocar calquera das dúas opcións. A mensaxe nomea que gardián se activou, e os gardiáns non son intercambiables.

Unha franxa por usuario necesita estado compartido

Unha política xenuína dun só transporte activo necesita unha reserva gardada nalgún lugar fóra de sshd. O paso de admisión debe reclamar atomicamente a franxa da conta, liberala cando se pecha a conexión, facela caducar cando un cliente desaparece sen pechar, e decidir se un novo intento se rexeita ou substitúe o antigo. Esa última decisión é unha decisión de produto, non un detalle técnico, porque substituír un túnel activo desconecta a alguén.

A reserva tamén debe ser compartida por cada servidor que acepta a conta. Dous hosts con contadores locais independentes aplican dous límites separados, e un subscritor que se reconecta pola outra porta de enlace obtén unha segunda franxa gratis. O que almacene o estado necesita o seu propio comportamento de fallo, xa que un almacén inalcanzable non debe bloquear a todos os subscritores.

Para unha promesa dun dispositivo, emite unha credencial distinta por cada dispositivo rexistrado e controla o rexistro e a revogación nesa capa. Unha clave privada copiada segue autenticándose desde calquera lugar, así que emitir unha clave por usuario non é proba de cantas máquinas a teñen.

Comproba a política con dúas conexións reais

Escribe as probas de aceptación como ordes antes de escribir a política. Os cinco casos son un segundo transporte aberto mentres o primeiro está activo, varias canles dentro dun transporte, un cliente que só reenvía portos, unha reconexión tras perder unha ligazón, e a mesma conta chegando a outra porta de enlace.

Le primeiro os límites efectivos e logo abre as conexións que a política debería rexeitar. Ámbalas dúas metades desa proba importan, e ningunha substitúe a outra.

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 a orde do túnel dúas veces en dous terminais e conta as conexións establecidas no porto 22. Se ambos levan tráfico mentres a túa política afirma un só transporte activo, a política é documentación e non aplicación. Corrixe esa fenda na capa de admisión, non baixando MaxSessions e esperando que o segundo transporte o note.