¿Puede decirle a OpenSSH que fuerce una nueva clave de acuerdo con un límite de número de paquete?

Su respuesta se aborda parcialmente en la página de manual de SSH:

 RekeyLimit
     Specifies the maximum amount of data that may be transmitted
     before the session key is renegotiated, optionally followed a
     maximum amount of time that may pass before the session key is
     renegotiated.  The first argument is specified in bytes and may
     have a suffix of 'K', 'M', or 'G' to indicate Kilobytes,
     Megabytes, or Gigabytes, respectively.  The default is between
     '1G' and '4G', depending on the cipher.  The optional second
     value is specified in seconds and may use any of the units docu-
     mented in the TIME FORMATS section.  The default value for
     RekeyLimit is ''default none'', which means that rekeying is per-
     formed after the cipher's default amount of data has been sent or
     received and no time based rekeying is done.

Un valor predeterminado ya está establecido en 1Gig y 4Gigs de datos, pero ¿qué significa eso? Si está enviando paquetes pequeños, le tomaría mucho tiempo volver a introducir la clave, si está enviando paquetes grandes, la nueva codificación se produciría con mayor frecuencia. Entonces, permítame preguntar: "¿Cuál cree que es su objetivo al establecer esto para que las cantidades de paquetes se logren?"

La modificación de las claves se realizó para que nadie pudiera almacenar / obtener / rastrear fragmentos de datos para los ataques de criptoanálisis. (Y o ataques de canal lateral). Hay un costo por realizar estos tipos de ataques: almacenamiento, tiempo, conocimiento de encriptación / criptoanálisis. Fuera de los programas patrocinados por el estado de la nación para atacar esto, todavía tengo que ver, leer o escuchar acerca de un actor no estatal, incluso tratando de lograr esto. Hay otras formas de atacar un sistema.

Pero para responder a su pregunta, no hay un método definitivo para hacer esto (cambio de clave basado en paquetes), por lo que tiene una opción: basar su tráfico, dividir el total de datos enviados, por paquetes enviados, luego usarlo como su número de cambio de clave. P.ej. 1Gig de tráfico / 1000 paquetes (cantidad promedio de paquetes que se tardó en enviar 1Gig) = número de clave.

Me doy cuenta de que esta es una pregunta antigua, pero otros pueden tropezar con ella. La pregunta de @Pandrei es legítima para los usuarios de Common Criteria. Sin embargo, como lo indica @munkeyoto, OpenSSH te da las asas para jugar con el volumen de datos. Lo que no parecía entender @Pandrei era que a 1 GB de datos, esto es 2 ^ 28 paquetes dado el tamaño de paquete más pequeño posible en el protocolo SSH para un algoritmo de cifrado específico (16 bytes). Por lo tanto, si establece el límite de datos en 1 GB, automáticamente cumplirá con el perfil de protección de NDcPP CC. El número de paquetes es intrascendente, ya que simplemente puede hacer cálculos matemáticos para averiguar el número de paquetes que depende del algoritmo de cifrado que se negoció. Específicamente, vea la sección 9.3.2 de RFC 4251:

  

Debido a que los MAC utilizan un número de secuencia de 32 bits, pueden comenzar a filtrarse      información después de 2 ^ 32 paquetes han sido enviados. Sin embargo, siguiendo      Las recomendaciones de cambio de clave deben evitar este ataque. los      protocolo de transporte [SSH-TRANS] recomienda cambiar la clave después de un gigabyte      de datos, y el paquete más pequeño posible es de 16 bytes. Por lo tanto,      la clave debe suceder después de 2 ^ 28 paquetes como máximo.

Al final, esto es discutible, ya que v2.0 de NDcPP reemplazará la necesidad de volver a codificar en paquetes con límites de tiempo y datos según las recomendaciones de RFC.