He estado usando una clave RSA de 1024 bits para SSH sin contraseña entre mis propios sistemas durante años. Más recientemente, también comencé a usarlo para acceder sin contraseña a mis proveedores de alojamiento y a los repositorios de código fuente.
¿Es un problema usar el mismo par de claves durante un período de tiempo prolongado y para acceder a múltiples recursos?
Sí, estrictamente hablando, se recomienda caducar las claves SSH después de un tiempo (esto podría depender de la longitud de la clave, las vulnerabilidades encontradas en el generador de claves, etc.). Sin embargo, dicho mecanismo no fue previsto por SSH. Y es complicado ir a todos los hosts remotos posibles y eliminar la clave pública.
Hay una solución, aunque nunca la probé, pero guárdela para cuando tenga tiempo libre, MonkeySphere para Proyecto OpenSSH . ¡Permitirá administrar la caducidad de sus claves hasta donde lo entendí!
Voy a tomar una posición diferente de los demás aquí. Mi recomendación: No es necesario cambiar su clave privada SSH, a menos que tenga una buena razón para cambiarla.
Justificación: Crypto no se desgasta. No se debilita con el uso repetido.
La razón más importante para cambiar su clave privada es si tiene una razón para sospechar que se ha comprometido o ya no es seguro. Por ejemplo, si una de sus máquinas es pirateada y tiene una copia de su clave privada almacenada en esa máquina, le recomendaría cambiar su clave SSH. De manera similar, si una de sus copias de seguridad se desplaza a pie, y tiene una copia de su clave privada SSH, le recomendaría cambiar su clave SSH. O, si generó su clave privada en un sistema Debian antiguo, entonces puede ser inseguro y le recomendaría cambiarlo. Sin embargo, si no tiene una razón como esa para sospechar que su clave privada está comprometida, no veo la necesidad de cambiarla.
La desventaja de cambiar la clave innecesariamente es que ahora tiene que actualizar el archivo authorized_keys en cada máquina en la que pueda iniciar sesión. Eso es un poco tedioso.
Sospecho que la razón por la que algunas personas le recomiendan cambiar su clave privada es por razones profilácticas: ¿qué pasaría si una de las máquinas que almacenaba su clave privada fuera pirateada y no estaba al tanto, y ahora el hacker ya no tiene acceso? El hacker aún puede tener su clave privada. Por lo tanto, puede haber algún valor para cambiar ocasionalmente su clave privada SSH, para limitar la exposición en ese tipo de escenario. Pero personalmente, sospecho que este tipo de escenario es muy raro y probablemente no valga la pena cambiar su clave SSH. Entonces, si otros prefieren cambiar sus claves SSH periódicamente, puedo entender sus razones, pero personalmente, no me molestaría.
P.S. Si estuviéramos hablando de una clave de host (en lugar de su clave personal), entonces hay una razón aún más importante para no cambiar innecesariamente la clave de host: si cambia la clave de host, todos los que intenten iniciar sesión en esa máquina comenzarán a recibir advertencias. que puedan estar bajo ataque. Si las personas ven estas advertencias de manera rutinaria, comenzarán a tratarlas como un ruido sin sentido (será una situación de lobo llorón), lo que socavará su valor. Por lo tanto, no cambie las claves de host de forma rutinaria sin una buena razón.
Bueno, por supuesto, depende de la sensibilidad de sus datos: ¿está protegiendo sus datos de su vecindario, de los ataques comerciales, del gobierno?
Este artículo estima que es posible construir una computadora que pueda romper las claves RSA, 1024 bits, En un año, gastando unos millones. Mencionan muchos estudios, todos recomiendan al menos 2048 bits.
Este sitio puede ayudarlo a calcular cuánto tiempo resistirá su clave a los ataques.
Y esta pregunta da muchas respuestas sobre el tamaño de las llaves.
Además, recuerde que usar su clave privada correctamente no significa que tendrá problemas si tiene más de un host con su clave pública, ni las veces que la use se debilitará. Es por eso que se crearon claves públicas y privadas: para usar sin aumentar los riesgos a medida que se usaban más.
Por lo que sé, no hay "desgaste de la llave" con las claves RSA, por lo que no hay problema en mantener el mismo conjunto de claves. Si sospecha que sus claves podrían haber sido comprometidas, puede generar nuevas claves, pero de lo contrario no es realmente necesario.
Es su confianza del servidor remoto, si no confía en el servidor remoto, entonces cambiar su clave ssh (nueva clave privada) y cargar una nueva parte pública a un servidor remoto no tiene ningún beneficio.
Su clave ssh privada no viaja a través de la red ... La seguridad de sus claves ssh privadas es su responsabilidad.
Si la pregunta es más general, significa cómo revalidar las claves de los usuarios, entonces depende. Puede usar algunas herramientas como cfengine, títere para cargar las claves públicas ssh de los usuarios a sus servidores de forma regular desde un repositorio / DB que tendría una marca de tiempo. Luego, puede enviar el correo al usuario para revalidar el uso de la clave, o a su administrador. O puede utilizar certificados con ssh. Aunque el equipo de OpenSSH no ha desarrollado ninguna información sobre certificados que expiran ...
Aléjate de varias soluciones openssh pirateadas y sus parches. ¿Lo apoyarían en el futuro?
Lea otras preguntas en las etiquetas ssh