Los servicios de túnel que prometen un dispositivo por suscriptor rara vez obtienen esa promesa de MaxSessions, y la primera prueba suele demostrarlo. El suscriptor abre un segundo proceso ssh, la primera sesión sigue funcionando y ambos túneles llevan tráfico. Cada opción de configuración cuenta algo distinto, y ninguna de ellas cuenta dispositivos. Nombrar primero la promesa es lo que hace obvia la elección entre ellas.

Qué cuenta realmente cada opción

MaxSessions limita el número de sesiones abiertas que transporta una conexión de red autenticada. Una sesión aquí significa un shell, una solicitud exec, un subsistema como SFTP o un canal similar multiplexado dentro de un solo transporte SSH. Una segunda invocación de ssh abre un segundo transporte, se autentica de nuevo y obtiene su propio cupo. El número de sesiones de la primera conexión le es irrelevante.

MaxStartups limita las conexiones concurrentes que aún no se han autenticado, expresadas como umbral de inicio, tasa y umbral completo. Existe para que una ráfaga de handshakes a medio abrir no pueda agotar los recursos del demonio antes de la autenticación. Cuando un cliente se autentica, esa conexión deja de contar contra MaxStartups y se convierte en la sesión de alguien. Nunca fue una cuota por usuario, y subirlo no permite al suscriptor hacer más.

Una regla de registro de dispositivos no es en absoluto una opción de sshd. Pertenece a cualquier sistema que emita credenciales y rastree qué dispositivo las tiene, lo que significa que necesita registro, inventario y revocación en lugar de un contador. Mezclar ese requisito en la configuración de sshd es donde se atascan la mayoría de estos diseños.

Dónde MaxSessions deja de ser una cuota

Un bloque Match User cambia qué valores de configuración se aplican a ese usuario, así que es el lugar natural para fijar un MaxSessions más estricto para una cuenta de servicio. Lo que no puede hacer es agregar entre conexiones, porque la opción se evalúa por transporte. Dos transportes reciben cada uno su propio límite, y el usuario acaba con el doble de lo que permite el bloque.

El reenvío es una sorpresa aparte. El reenvío TCP no necesita un canal de sesión, así que MaxSessions 0 puede prohibir shells y subsistemas mientras sigue permitiendo túneles -L y -R. Un servicio que solo reenvía y trata el número de sesiones como su cuota de túnel no mide nada en absoluto. Ese comportamiento está documentado en la referencia de configuración del servidor OpenSSH, y vale la pena leerla antes de diseñar en torno a un nombre de opción.

Vuelque la configuración efectiva en lugar del archivo que cree que está cargado. Las inclusiones y los directorios drop-in suelen significar que el valor vigente no es el valor que editó.

MaxStartups protege al demonio, no al suscriptor

La forma de tres partes de MaxStartups describe cuántas conexiones no autenticadas pueden existir antes de que el demonio empiece a descartar un porcentaje de las nuevas. Su forma predeterminada existe porque una conexión SSH no autenticada es barata de abrir y cara de mantener. Es un control de protección de recursos para el servidor, y se aplica a todos a la vez.

Subirlo durante una tormenta de inicios de sesión cambia protección del demonio por admisión, lo que a veces es el intercambio correcto y siempre es deliberado. No hace nada por el suscriptor que quiere un segundo túnel, porque el primer túnel ya está autenticado. Confundir los dos lleva a un cambio que arregla el síntoma equivocado y debilita el servidor al mismo tiempo.

Cuando se rechazan inicios de sesión a ráfagas, mire en el registro del demonio el mensaje previo a la autenticación antes de tocar cualquiera de las dos opciones. El mensaje nombra qué guardián se activó, y los guardianes no son intercambiables.

Una ranura por usuario necesita estado compartido

Una política genuina de un solo transporte activo necesita una reserva guardada en algún lugar fuera de sshd. El paso de admisión debe reclamar atómicamente la ranura de la cuenta, liberarla cuando se cierra la conexión, hacerla caducar cuando un cliente desaparece sin cerrar, y decidir si un nuevo intento se rechaza o sustituye al antiguo. Esa última decisión es una decisión de producto, no un detalle técnico, porque sustituir un túnel activo desconecta a alguien.

La reserva también debe ser compartida por cada servidor que acepta la cuenta. Dos hosts con contadores locales independientes aplican dos límites separados, y un suscriptor que se reconecta por la otra puerta de enlace obtiene una segunda ranura gratis. Lo que almacene el estado necesita su propio comportamiento de fallo, ya que un almacén inalcanzable no debe bloquear a todos los suscriptores.

Para una promesa de un dispositivo, emita una credencial distinta por cada dispositivo registrado y controle el registro y la revocación en esa capa. Una clave privada copiada sigue autenticándose desde cualquier lugar, así que emitir una clave por usuario no es prueba de cuántas máquinas la tienen.

Compruebe la política con dos conexiones reales

Escriba las pruebas de aceptación como comandos antes de escribir la política. Los cinco casos son un segundo transporte abierto mientras el primero está activo, varios canales dentro de un transporte, un cliente que solo reenvía puertos, una reconexión tras perder un enlace, y la misma cuenta llegando a otra puerta de enlace.

Lea primero los límites efectivos y luego abra las conexiones que la política debería rechazar. Ambas mitades de esa prueba importan, y ninguna sustituye a la otra.

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]

Ejecute el comando del túnel dos veces en dos terminales y cuente las conexiones establecidas en el puerto 22. Si ambos llevan tráfico mientras su política afirma un solo transporte activo, la política es documentación y no aplicación. Corrija esa brecha en la capa de admisión, no bajando MaxSessions y esperando que el segundo transporte lo note.

Artículos relacionados