Loading
_ DESCIFRANDO CONEXIÓN SEGURA...
whoami-labs PRO
Aprende — mapa de rutas Empieza aquí Iniciar sesión Elige tu Rol Precios Preguntas Frecuentes Empresas

Claves SSH y certificados SSH

5 tareas · 40 min · Principiante

Hay dos maneras de que un servidor reconozca una llave SSH: tenerla escrita en una lista de llaves autorizadas, o confiar en una autoridad que la firmó en un certificado con nombre, vigencia y alcance. La primera vale hasta que alguien borra la línea; la segunda caduca sola. En Aserríos del Sinú lees las dos formas en un mismo servidor y la política que dice cuál usar para qué: la llave de alguien que ya se fue, las llaves sin restricción de origen y el certificado que dura más de lo permitido. Todo es lectura de evidencia ficticia, con llaves y huellas de marcador.

0 de 5 · 0%

Objetivo de la sala

Hay dos maneras de que un servidor reconozca una llave SSH: tenerla escrita en una lista de llaves autorizadas, o confiar en una autoridad que la firmó en un certificado con nombre, vigencia y alcance. La primera vale hasta que alguien borra la línea; la segunda caduca sola. En Aserríos del Sinú lees las dos formas en un mismo servidor y la política que dice cuál usar para qué: la llave de alguien que ya se fue, las llaves sin restricción de origen y el certificado que dura más de lo permitido. Todo es lectura de evidencia ficticia, con llaves y huellas de marcador.

Una llave en authorized_keys no dice quién es su dueño más allá de un comentario que cualquiera pudo escribir, no caduca y hay que ir servidor por servidor para quitarla. Un certificado es la misma llave pública firmada por la autoridad de la empresa (CA): lleva un id, los principals que afirma, una validez y puede llevar restricciones. El servidor solo necesita confiar en la CA.

La consecuencia práctica no es que el certificado sea más fuerte criptográficamente, sino que se puede gobernar: con validez de horas, una baja se queda sin acceso sola, y el id del certificado queda en el registro del servidor. Ojo: si el servidor además sigue leyendo authorized_keys, las llaves antiguas siguen funcionando junto a los certificados.

Responde para continuar

¿Qué ventaja de gobierno aporta un certificado SSH de pocas horas frente a una llave en authorized_keys?

Ver pista de ayuda

Piensa en lo que ocurre el día después de una baja, sin que nadie haga nada.

La política P5 exige retirar las llaves de una persona el mismo día de su baja. Como una llave en authorized_keys no se vence, la revisión es siempre la misma: cruzar los comentarios de las llaves con la lista de bajas. El comentario suele tener la forma cuenta@equipo, y hay que fijarse en la cuenta.

Abre authorized_keys-erp01.txt y bajas.txt. La respuesta es el comentario completo de la llave.

Responde para continuar

¿Cuál es el comentario de la llave autorizada en sinu-erp01 que pertenece a una persona dada de baja?

La opción from="…" al inicio de la línea limita las direcciones desde las que se acepta la llave. Si la llave se copia o se roba, sigue sirviendo, pero solo desde donde la empresa espera. La política P2 exige from= en toda llave que quede en authorized_keys. Una línea que empieza directamente con el tipo de llave no tiene restricción.

Cuenta en authorized_keys-erp01.txt las líneas que no comienzan con from=.

Responde para continuar

¿Cuántas llaves autorizadas de sinu-erp01 no tienen restricción de origen?

Un certificado trae su validez escrita: desde cuándo y hasta cuándo. La política P1 fija 12 horas para las personas, incluidos los proveedores externos (P4), y P3 fija 30 días para las cuentas de servicio. Para revisar, se resta el fin menos el inicio y se compara con el límite que corresponde a quién lo usa: no todos los certificados largos incumplen.

Lee certificados-vigentes.txt junto con politica-ssh.txt. La respuesta es el número de serie.

Responde para continuar

¿Cuál es la serie del certificado cuya validez supera el límite que le corresponde?

Un principal es un nombre que el certificado afirma, como sistemas o dba. El servidor no entrega acceso por el nombre en sí: con AuthorizedPrincipalsFile, cada cuenta del servidor tiene una lista de principals admitidos. Un certificado con el principal dba entra solo a las cuentas cuya lista incluya dba.

Responde para continuar

Un certificado afirma el principal `dba`. ¿Qué decide si entra a una cuenta concreta del servidor?

Ver pista de ayuda

Fíjate en el archivo que enlaza cada cuenta del servidor con los principals.

Inicia sesión para registrar tus puntos y progreso en el ranking.
Entrar · Registrarse

Whoami-Labs Pro

Whoami-Labs Pro utiliza cookies

Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad