Resumen

  • Una coincidencia SSHFP autenticada con DNSSEC puede unir el algoritmo y la huella de una clave de host SSH a un nombre propietario concreto. No demuestra que ese nombre fuese el servicio pretendido ni codifica puerto, usuario u orden.
  • La aceptación compone selección de nombre, estado DNSSEC, comparación exacta, prueba de posesión SSH y política local. La rotación añade los relojes de cachés DNS y almacenes de claves conocidas.

Una respuesta auténtica a una pregunta equivocada

No hubo falsificación en la escena inicial. El resolvedor escogió un nombre completo, una cadena DNSSEC validó el RRset y el servidor firmó el intercambio con la clave privada asociada a la clave pública publicada por huella.

Faltaba una pregunta anterior: ¿por qué esa expansión de db era el destino correcto?

RFC 4255 advierte específicamente sobre nombres sin calificar. Recomienda consultar primero una base local porque una ruta de búsqueda inyectada puede llevar al cliente a otro host. Un resultado puede ser criptográficamente auténtico y operacionalmente ajeno a la intención.

Por eso la traza debe separar etiqueta original, nombre canónico, sufijo o CNAME aplicado, propietario SSHFP, dirección y puerto. La palabra genérica «host» borra el momento donde una regla local eligió el sujeto de la prueba.

El objeto que SSHFP compara

SSHFP es el tipo DNS 44. Su RDATA contiene número de algoritmo de clave pública, tipo de huella y huella. El nombre propietario pertenece al RR y no está dentro de esos tres campos.

La verificación exige que coincidan el algoritmo de la clave recibida y el número publicado. Después, el resumen calculado sobre el blob de clave pública con el tipo de huella indicado debe igualar los bytes del registro.

El intercambio SSH sigue siendo necesario. El servidor firma datos del intercambio y demuestra control de la clave privada en esa sesión. Control no significa custodia exclusiva: una copia robada produce una firma igualmente válida.

El formato tampoco incluye puerto, cuenta, orden, rol, dirección IP ni vigencia. Una asociación para host.example no decide si el operador quería el puerto 22, otro demonio, un salto intermedio o un entorno de producción.

Secure no significa «todo aprobado»

RFC 4255 prohíbe confiar por este método en una clave cuando el SSHFP usado no fue autenticado por una firma DNS de confianza. El cliente puede validar localmente. Si delega la validación, necesita un canal protegido hasta el validador; aceptar un bit de resultado por una red no confiable repite el problema.

Los estados importan. Secure autentica los datos bajo un ancla aceptada. Insecure establece que la cadena no los protege. Bogus indica que la validación esperada falló. Indeterminate carece de información suficiente de confianza.

Una huella coincidente bajo Insecure puede orientar a una persona, pero no gana confianza automática. Bogus no debe convertirse en Insecure para evitar una caída. Indeterminate debe mostrar qué ancla o prueba falta.

Incluso Secure protege el RRset del nombre consultado, no la intención que llevó a consultarlo. Un sufijo aprendido por DHCP o una regla de canonicalización puede seleccionar con autenticidad el nombre equivocado.

La preferencia de SHA-256 incluye un rechazo

IANA registra números para RSA, DSA, ECDSA, Ed25519 y Ed448, y tipos de huella SHA-1 y SHA-256. El registro da interoperabilidad; no prueba que un cliente soporte o habilite una combinación.

RFC 6594 añade una disciplina contra degradación. Si el cliente soporta SHA-256 y encuentra huellas SHA-256 y SHA-1, debe preferir SHA-256. Si la prueba SHA-256 no coincide, debe rechazar la clave en vez de buscar una coincidencia SHA-1 que salve la operación.

Un único campo sshfp=match es insuficiente. Deben quedar propietario, algoritmo de clave, tipo de huella, resumen calculado y resultado de cada intento. Así se ve si una evidencia más fuerte dijo no antes de que otra más débil dijera sí.

La configuración efectiva conserva el veto

RFC 4255 permite ordenar SSHFP, ficheros locales y otros métodos mediante política. OpenSSH documenta VerifyHostKeyDNS=no como valor predeterminado. Con yes, confía implícitamente en una clave que coincide con una huella DNS segura; una huella insegura se trata como ask. Con ask, se muestra la coincidencia, pero una clave nueva todavía sigue StrictHostKeyChecking.

Intervienen además ficheros globales y personales, bloques Host y Match, canonicalización, CNAME permitidos y precedencia de configuración. El registro operativo debe capturar valores efectivos, no solo el archivo que alguien esperaba que ganara.

Un pin local antiguo en conflicto con un SSHFP Secure nuevo es un desacuerdo real. La política debe decidir si DNS distribuye la rotación, si el pin conserva el veto o si se exige aprobación adicional.

El puerto queda fuera del RR

OpenSSH permite mantener known_hosts con [hostname]:port; ssh-keygen -r genera SSHFP para un hostname. La diferencia muestra que un pin local puede calificar un puerto mientras el RDATA SSHFP no lo hace.

Si un nombre sirve dos demonios con claves distintas, la aplicación debe modelar esa realidad. Un match DNS no elige el puerto. Del mismo modo, autenticar el destino final a través de un bastión no autentica automáticamente la clave del bastión. Cada transporte relevante necesita su propia evidencia.

Rotar significa coordinar dos tiempos

RFC 4255 contempla reemplazar SSHFP para distribuir una clave y, cuando la política lo exige, eliminarlo como parte de la revocación. El efecto solo existe en clientes que realmente ejecutan esa regla.

Los RR antiguos viven en cachés durante su TTL; las RRSIG tienen otra ventana y known_hosts otra memoria. Presentar la clave nueva antes de que su huella se propague provoca un rechazo correcto. Borrar la huella vieja en el autoritativo no demuestra que los resolvedores dejaron de servirla.

Una rotación normal prepublica la huella nueva por un canal de inscripción seguro, la observa desde validadores materiales, mantiene solapamiento, cambia la clave del servicio, retira la antigua y prueba el rechazo tras expirar las cachés. En un compromiso urgente puede elegirse indisponibilidad; debe registrarse como decisión de riesgo.

La identidad del servidor precede al permiso

SSH separa autenticación del servidor en transporte y autenticación del usuario. Una clave de host aceptada protege el canal hacia el servidor seleccionado. No admite la cuenta, el shell, el reenvío ni la orden solicitada.

La automatización que traduce «host verificado» en permiso para desplegar secretos o ejecutar mantenimiento salta una frontera. Cuenta, autorización de orden, alcance del cambio e idempotencia siguen teniendo controles propios.

Pruebas donde los sujetos no desaparecen

Resuelva el mismo nombre corto con dos sufijos. Pruebe una huella idéntica bajo Secure, Insecure, Bogus e Indeterminate. Haga fallar SHA-256 mientras SHA-1 coincide. Enfrente un pin local con un SSHFP nuevo. Use dos puertos, un bastión y una clave privada copiada. Verifique el host y rechace después al usuario y a la orden.

Cada resultado debe nombrar el propietario DNS, estado, ancla, clave, puerto, transporte, política y permiso posterior. La meta no es que todo falle: es que ningún pass cambie de sujeto.