Método para desaprobar el par de claves SSH localmente

10

He usado mis teclas ssh por un tiempo. Estoy pensando en actualizar mi par de claves ssh a un cifrado más seguro y no conozco todos los dispositivos donde están registradas mis claves.

¿Es posible "desaprobar" una clave SSH localmente para recibir una advertencia si me autentico con una clave SSH desaprobada?

security ssh-keys

— tim0_o
fuente

Mientras lo hace, le sugiero que deje de usar la misma clave SSH para varios hosts; aumenta innecesariamente la superficie de ataque, así como el valor de esa clave en caso de incumplimiento. En su lugar, use una clave para cada host al que se conecte; idealmente, use una clave para cada par de cliente y servidor (pero esto se escala mal si tiene muchos sistemas cliente conectados a muchos servidores). También me gusta etiquetar las claves con la fecha de generación en el comentario o el nombre de la clave, lo que me permite hacer un seguimiento de la antigüedad. Luego configure un recordatorio recurrente cada 6-24 meses en su calendario para renovarlo.

— un CVn

@ MichaelKjörling No estoy de acuerdo con la primera parte de su sugerencia. Generar muchos pares de claves donde todas las claves privadas se almacenan en la misma máquina con los mismos permisos no proporciona mejoras de seguridad significativas. Si uno está comprometido, lo más probable es que el resto de ellos también lo estén. Y en ese caso, tener muchos pares de claves solo significa que habrá más trabajo para rotarlos una vez que vea una razón para generar un nuevo par de claves. La parte sobre agregar una fecha de generación al comentario es un buen consejo (desearía ssh-keygenhacerlo de forma predeterminada).

— Kasperd

@kasperd Haces un buen punto. Supongo que, como siempre, depende mucho de su modelo de amenaza. Sospecho que supuse implícitamente que las claves tendrían diferentes frases de contraseña, lo que puedo ver cómo con una gran cantidad de claves no siempre es práctico, a menos que esté dispuesto a agregar un administrador de contraseñas a la mezcla. Que no permite, sin embargo algo muy cercano a lo que el PO está describiendo, ya que una llave puede ser "obsoleto" muy fácilmente sin afectar a otras conexiones. Sospecho que al final es una cuestión de gusto personal.

— un CVn

9

No conozco ninguna forma de hacer algo como esto, pero puedo ver cómo sería útil. Lo que me inclinaría a hacer es dejar de agregar la clave obsoleta a mi agente SSH. De esa forma, cada vez que se use, tendré que volver a ingresar la frase de contraseña. Si es algo como "uf, otro para arreglar", entonces me recordará cada vez que tengo que girar mi llave en esa máquina también.

— womble
fuente

a este respecto, puede ser útil (dependiendo de la distribución / DE) mover el archivo a otro directorio, seahorse , por ejemplo, usa todas las claves ~/. sshautomáticamente.

— Guntbert

1

Cualquier cosa que haga eso debe ser quemada. Significa que en el momento en que tenga más de seis claves (tengo un par de docenas), terminará fallando la autenticación debido a demasiadas fallas (cada clave presentada y rechazada cuenta para la cuenta de fallas).

— womble

5

Puede mover la antigua clave ssh a una ubicación no predeterminada (es decir, ~ / .ssh / deprecated_id_rsa) y luego crear una nueva clave ssh con sus propiedades deseadas en ~ / .ssh / id_rsa

De esa manera, todavía tiene su clave obsoleta disponible si es necesario ssh -i ~/.ssh/deprecated_id_rsa ..., pero por defecto usará su nueva clave.

— dedo del pie
fuente