# ¿Puede una clave de host SSH revocada dejar entrar al agente?

Una clave de host SSH revocada debe detener a un agente antes de autenticar al usuario, sin importar el nombre o la dirección que use. Si la prueba solo intenta una vez el nombre de host habitual, demuestra mucho menos de lo que parece. La configuración de SSH puede asignar varios nombres a un servidor, un puerto no predeterminado cambia el identificador de búsqueda de known-hosts y un cliente multiplexado puede abrir otro canal sin repetir la comprobación de la clave de host.

Trata la revocación como una propiedad de la identidad criptográfica y prueba todas las rutas que puedan presentar o reutilizar esa identidad. Para eso necesitas una lista de revocación de claves, un estado de cliente limpio, variantes de conexión explícitas y un procedimiento separado para las conexiones que ya existen. Un aviso de cambio de clave resulta útil, pero no aplica el mismo control.

## La revocación debe seguir a la clave, no al nombre de host

Una clave de host autentica al servidor durante el intercambio de claves SSH. RFC 4253 describe cómo el cliente recibe la clave pública del servidor, comprueba que pertenece al servidor esperado y verifica la firma del servidor sobre el intercambio. La revocación corresponde a ese punto: si el servidor presenta una clave pública prohibida, el cliente debe rechazarla antes de considerar una clave de usuario, una contraseña o un comando remoto.

OpenSSH ofrece dos mecanismos que parecen similares, pero tienen distinto alcance. Una línea que empieza por `@revoked` en un archivo known-hosts combina un patrón de host con una clave revocada. Funciona cuando el nombre de búsqueda de la conexión coincide con esa línea. Un alias u otra forma de dirección puede no coincidir con el patrón aunque el servidor presente la misma clave. El manual de `sshd` de OpenSSH dice que una entrada revocada coincidente nunca debe aceptarse, pero la condición de coincidencia importa.

La opción de cliente `RevokedHostKeys` encaja mejor con una revocación durante un incidente. Apunta a un archivo de texto con claves públicas o a una lista de revocación de claves de OpenSSH (KRL). OpenSSH compara la identidad presentada con ese archivo sin depender de que el usuario escriba `build-test`, `build-test.example` o una dirección IP literal. Uso entradas `@revoked` para mantener known-hosts de un host concreto; uso `RevokedHostKeys` cuando una identidad criptográfica debe quedar invalidada en todas partes.

No confundas ninguno de estos mecanismos con `StrictHostKeyChecking=yes`. La comprobación estricta rechaza hosts desconocidos y claves modificadas, lo que impide confiar en silencio durante el primer uso. No declara revocada una clave que, por lo demás, es de confianza. Una prueba que borra la entrada known-host anterior y celebra un fallo por host desconocido ha probado una base de confianza vacía, no una revocación.

## Crea un host de prueba que puedas romper a propósito

Usa un servidor SSH desechable con puerto, clave de host, cuenta de usuario y directorio de cliente propios. No ensayes una revocación en un host de preproducción compartido. Necesitas sustituir claves, detener procesos y cerrar sockets de control sin preguntarte quién más depende de ellos.

La siguiente disposición mantiene las pruebas en un solo directorio. La ruta exacta de `sshd` y el modelo de privilegios cambian según el sistema operativo, así que ejecuta el demonio en el contenedor, la máquina virtual o el fixture que tu equipo ya use para pruebas de integración SSH.

```bash
set -eu
work="$PWD/ssh-revocation-fixture"
mkdir -p "$work/client" "$work/server"
chmod 700 "$work/client"

ssh-keygen -q -t ed25519 -N '' \
  -C revoked-host-test -f "$work/server/ssh_host_ed25519_key"
ssh-keygen -q -t ed25519 -N '' \
  -C agent-test-user -f "$work/client/id_ed25519"

ssh-keygen -lf "$work/server/ssh_host_ed25519_key.pub"
```

El último comando imprime una línea con esta forma:

```text
256 SHA256:<base64-fingerprint> revoked-host-test (ED25519)
```

Registra esa huella en el log de la prueba. Nunca copies una huella de un ticket y des por hecho que el archivo del fixture contiene la misma clave. Calcúlala a partir del archivo de clave pública que carga realmente el servidor de prueba.

Configura el demonio de prueba para que use solo esa clave de host. Rellena su `AuthorizedKeysFile` con la clave pública del cliente, desactiva las contraseñas y vincúlalo a una dirección de bucle local o aislada. Un fixture mínimo también debe definir un `PidFile` y un registro detallado. El objetivo es la repetibilidad: un listener, una identidad de host y una ruta de autenticación.

Antes de añadir la revocación, haz que una conexión estricta tenga éxito y ejecute un comando señal inocuo, como `printf BASELINE_OK`. Obtén la clave de host mediante un paso de aprovisionamiento autenticado, no con un `ssh-keyscan` sin verificar sobre la misma ruta de red que intentas proteger. `ssh-keyscan` recupera claves sin demostrar quién las entregó.

## Incluye la identidad revocada en una KRL

Una KRL hace que la prueba trate sobre la clave y no sobre cómo se escribe el destino. Genérala directamente con la clave pública cargada por el fixture y consúltala antes de intentar una conexión de red:

```bash
work="$PWD/ssh-revocation-fixture"
ssh-keygen -k -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"

if ssh-keygen -Q -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"; then
  printf '%s\n' 'FAIL: fixture host key is not revoked'
  exit 1
else
  printf '%s\n' 'OK: fixture host key is revoked'
fi
```

El estado de salida invertido confunde con frecuencia. El manual de `ssh-keygen` especifica que `-Q` devuelve un valor distinto de cero si alguna clave consultada está revocada o si ocurre un error; cero significa que ninguna está revocada. No descartes stderr y distingue en el registro circundante una KRL ilegible de una coincidencia de revocación válida.

Ahora conecta el archivo a la configuración de cliente en el ámbito más amplio que use el agente:

```sshconfig
Host *
    BatchMode yes
    StrictHostKeyChecking yes
    UserKnownHostsFile ./ssh-revocation-fixture/client/known_hosts
    RevokedHostKeys ./ssh-revocation-fixture/client/revoked-hosts.krl
    ConnectTimeout 5
    ConnectionAttempts 1
```

OpenSSH falla de forma cerrada si el archivo `RevokedHostKeys` no existe o no se puede leer: rechaza la autenticación de host para todos los destinos cubiertos por esa configuración. Es más seguro que ignorar el archivo, pero puede hacer que un despliegue roto parezca una prueba de revocación correcta. La consulta previa demuestra que el archivo es legible y contiene la clave prevista.

También sirve un archivo de texto sencillo con una clave pública por línea. La complejidad de las KRL compensa cuando hay muchas claves o certificados de host porque pueden revocar claves simples, números de serie de certificados, identificadores de certificado o claves firmadas por una CA. Usa el formato más sencillo que tus procesos de distribución e inspección puedan manejar y prueba el mismo formato que despliegas.

## Un marcador limitado al hostname necesita una prueba adversa

Conserva un caso deliberadamente débil en el fixture para mostrar por qué hace falta la KRL. Crea una segunda configuración de cliente sin `RevokedHostKeys` que dependa solo de esta entrada known-hosts:

```text
@revoked revoked-lab ssh-ed25519 AAAA...fixture-public-key...
```

Conecta como `revoked-lab` y confirma que OpenSSH rechaza la entrada coincidente. Después conecta al mismo listener como `127.0.0.1`, con una entrada known-host de confianza independiente para `[127.0.0.1]:2222`. Si esa forma de dirección funciona, el fixture ha reproducido la brecha de cobertura: la clave no cambió, pero el nombre de búsqueda ya no coincide con el marcador revocado. Mantén esta demostración aislada de la configuración de producción porque su fin es probar que un control resulta insuficiente.

No pegues el valor abreviado `AAAA...` del ejemplo. Construye el marcador desde el archivo de clave pública real para que el algoritmo y los datos base64 sean exactos. Un comando seguro del fixture puede leer los campos de algoritmo y clave del archivo público y anteponer el marcador junto con el patrón de host. Verifica la entrada resultante con `ssh-keygen -F revoked-lab -f known_hosts`; repite la búsqueda para la dirección literal y muestra que allí no existe la entrada.

Este fallo explica por qué añadir cada alias conocido a una línea `@revoked` resulta frágil. El inventario cambia cuando alguien añade un nombre corto, un registro DNS, una entrada local de hosts, un puerto no predeterminado, un alias de túnel o un `HostKeyAlias`. Los nombres known-host cifrados dificultan la revisión manual, aunque `ssh-keygen -F` todavía puede buscarlos. Un marcador con comodín amplía la coincidencia, pero solo revoca la clave cuando un destino cae dentro del patrón y hace más difícil revisar el alcance previsto.

El caso con KRL debe usar el mismo servidor, clave de usuario, ruta de red y entradas known-host de confianza. Cambia solo el mecanismo de revocación. Con `RevokedHostKeys` activo, tanto `revoked-lab` como `127.0.0.1` deben fallar después de presentar la clave del fixture. Este experimento emparejado convierte una advertencia abstracta sobre alias en un fallo que los revisores pueden ver y repetir.

Prueba también la precedencia. OpenSSH conserva el primer valor que obtiene para una opción, de modo que un ajuste temprano específico de un host puede anular el valor predeterminado posterior que pretendías aplicar. Ejecuta `ssh -G` contra cada destino y compara byte por byte la ruta `revokedhostkeys` resuelta. Encontrar la palabra `RevokedHostKeys` en algún lugar de un archivo de configuración no demuestra que el agente la use.

La configuración del sistema y la del usuario crean otra separación. Un ingeniero puede tener `/etc/ssh/ssh_config` apuntando a la KRL de la organización, mientras el agente arranca con `ssh -F private-config`, que indica a OpenSSH que use otro archivo. También puede ocurrir que una cuenta limpia de CI pase la prueba pero no represente a un runner de producción que inyecta opciones en la línea de comandos. Captura la invocación completa en el límite de acción del agente y haz explícita allí la ruta de revocación.

Los permisos forman parte de la aceptación. Según el manual de OpenSSH, no poder leer `RevokedHostKeys` rechaza la autenticación de todos los hosts. Comprueba el archivo como el usuario del sistema operativo que ejecuta el agente antes de conectar y consulta la clave prevista. Así separas tres resultados que parecen un mismo comando SSH fallido: una coincidencia de revocación válida, un archivo de revocación ausente o ilegible y una KRL mal formada.

La distribución también tiene un problema de tiempo. Si varias máquinas runner pueden iniciar al agente, publicar la KRL en una sola no completa la revocación. Registra un resumen del contenido de la KRL y exige que cada runner informe de ese resumen antes de aceptar nuevas tareas SSH. Usa una sustitución atómica para que ningún lector vea un archivo escrito a medias. Después de distribuirlo, ejecuta la prueba negativa desde cada imagen de cliente o clase de configuración distinta, no solo desde la máquina que produjo la KRL.

La reversión debe tener un significado comprobable. Quitar una huella de la KRL porque se cerró un ticket puede restaurar la confianza mientras la clave privada comprometida todavía existe. Es preferible sustituir la identidad del servidor, distribuir el nuevo registro de confianza y conservar la identidad anterior como revocada. Si la política permite retirar una revocación, exige pruebas de que la clave privada antigua no puede volver y conserva un caso de regresión que la presente.

El registro de aceptación de una identidad revocada debe incluir la huella, el algoritmo de clave pública, el resumen de la KRL, las formas de destino probadas, la configuración efectiva de cada forma y el resultado de un intercambio nuevo. Añade por separado el resultado de la sesión multiplexada porque responde a otra pregunta. Así los revisores pueden distinguir entre coincidencia de identidad, cobertura de rutas, configuración, distribución y limpieza del transporte.

## Una conexión nueva debe fallar antes de ejecutar la señal

Obliga al primer caso negativo a establecer un transporte nuevo. Desactiva la conexión compartida en la línea de comandos aunque la configuración SSH del usuario la habilite, mantén el cliente sin interacción e incluye en el comando remoto una marca imposible de confundir si llegara a ejecutarse.

```bash
work="$PWD/ssh-revocation-fixture"
config="$work/client/config"
log="$work/client/direct.stderr"

set +e
ssh -F "$config" \
  -o ControlMaster=no -o ControlPath=none \
  -i "$work/client/id_ed25519" \
  -p 2222 testuser@127.0.0.1 \
  'printf REVOKED_KEY_EXECUTED' \
  >"$work/client/direct.stdout" 2>"$log"
rc=$?
set -e

if [ "$rc" -eq 0 ]; then
  printf '%s\n' 'FAIL: SSH accepted a revoked host identity'
  exit 1
fi
if grep -q REVOKED_KEY_EXECUTED "$work/client/direct.stdout"; then
  printf '%s\n' 'FAIL: remote sentinel ran'
  exit 1
fi
printf 'PASS rc=%s\n' "$rc"
```

Comprueba el resultado, no un texto de error exacto en inglés. Las versiones de OpenSSH y los sistemas operativos pueden redactar los diagnósticos de otra forma. Cuando falle un caso, conserva la salida detallada de cliente de una segunda ejecución con `-vv` y busca la huella presentada junto con el diagnóstico de revocación. Un tiempo de espera TCP, un puerto rechazado, un host desconocido, una clave de usuario ausente o una cuenta denegada también devuelven un valor distinto de cero, pero ninguno demuestra que la revocación detuvo la conexión.

El log del servidor aporta la otra mitad de la comprobación. El cliente debe desconectarse durante el intercambio de claves, antes de que el servidor registre una autenticación de usuario correcta y antes de iniciar una sesión. Si el fixture no permite distinguir esas fases en sus pruebas, es demasiado opaco para este ensayo.

Ejecuta un caso de control con una KRL vacía y legible o con otra clave de servidor no revocada. Esa conexión debe alcanzar `BASELINE_OK`. Una prueba negativa sin control positivo suele pasar porque DNS, las rutas, los permisos o la cuenta del fixture ya estaban rotos.

## Cada alias y forma de dirección necesita su propio caso

Una KRL debe rechazar la clave bajo distintos nombres, pero la resolución de la configuración todavía puede llevar una forma alrededor de la opción de revocación. Prueba la configuración efectiva del cliente y el resultado de red para cada forma de destino que el agente pueda producir.

Empieza con una matriz pequeña ligada al fixture:

1. El alias configurado, como `revoked-lab`, cuyo `HostName` apunta a la dirección de prueba.
2. El nombre de host completo y cualquier nombre corto aceptado por las reglas locales de resolución.
3. La dirección IPv4 literal y, si el listener dispone de ella, la dirección IPv6 literal.
4. El identificador known-host de puerto no predeterminado, escrito normalmente como `[host]:port` en las herramientas known-hosts.
5. Un alias que configure `HostKeyAlias`, porque esa opción reemplaza el nombre real al buscar claves y validar certificados de host.

Guarda las variantes en un archivo de datos o una función de prueba en lugar de duplicar un bloque de shell. Para cada nombre visible, inspecciona `ssh -G destination` y guarda los valores resueltos de `hostname`, `port`, `hostkeyalias`, `userknownhostsfile`, `revokedhostkeys`, `proxycommand`, `proxyjump`, `controlmaster` y `controlpath`. `ssh -G` expande la configuración sin conectar, por lo que detecta una sección `Host` que sustituya en silencio la ruta de la KRL.

`Hostname` y `HostKeyAlias` cumplen funciones distintas. `Hostname` selecciona el destino de red. `HostKeyAlias` selecciona el nombre que OpenSSH usa para leer o guardar claves y validar certificados de host. Ninguno debería debilitar una comprobación global de `RevokedHostKeys`, pero ambos pueden cambiar qué entrada known-host de confianza considera OpenSSH. Por eso una línea `@revoked` limitada a un hostname es un control pobre durante un incidente.

La canonicalización requiere un caso cuando está habilitada. `CanonicalizeHostname yes` puede añadir dominios configurados y hace que OpenSSH vuelva a procesar la configuración con el destino reescrito. Una sección posterior puede elegir otro archivo known-hosts u omitir el archivo de revocación. Prueba la entrada corta y el nombre canónico resultante, y confirma que ambas configuraciones efectivas apuntan a la misma KRL.

No consideres `CheckHostIP=yes` como cobertura de alias. El manual de OpenSSH dice que además comprueba la IP de destino en known-hosts y que no está disponible con un comando proxy. Puede detectar una asociación modificada, pero no sustituye un archivo de revocación centrado en la clave. Las rutas mediante proxy y salto todavía necesitan una prueba completa del destino final, con configuración de confianza separada para cada host de salto.

## Las conexiones en caché marcan un límite de respuesta

Un maestro SSH multiplexado activo ya ha autenticado al servidor. Abrir otra sesión mediante su socket de control no crea una conexión TCP nueva ni repite el intercambio de clave de host, por lo que una KRL recién instalada no puede rechazar la clave de forma retroactiva. Llamarlo evasión de la revocación confunde el modelo. Es la reutilización de un transporte autenticado que sigue existiendo.

Demuestra este comportamiento en el fixture en vez de suponer que un reinicio lo limpiará. Primero establece un maestro multiplexado mientras la clave está permitida. Mantenlo activo con `ControlPersist`, añade la clave a la KRL y muestra que `ssh -O check` todavía encuentra al maestro. Un comando enviado por ese socket puede seguir ejecutándose. Regístralo como control esperado antes de la corrección, no como resultado correcto de la revocación.

Después aplica la respuesta: impide que el agente abra trabajo nuevo, termina los maestros relacionados y revoca o detiene la sesión de agente propietaria. Para un socket dedicado del fixture, el comando local tiene esta forma:

```bash
socket="$PWD/ssh-revocation-fixture/client/cm-testuser-127.0.0.1-2222"
ssh -S "$socket" -O exit testuser@127.0.0.1
```

Cuando desaparezca el socket, repite la conexión con `ControlMaster=no` y `ControlPath=none`; debe fallar por la clave revocada. Prueba también la configuración habitual de multiplexación del agente después de limpiar. Los modos oportunistas como `ControlMaster auto` recurren a una conexión nueva si no hay un maestro escuchando, y esa conexión debe consultar la KRL.

Un archivo de socket obsoleto no es una conexión autenticada. OpenSSH intentará usarlo, descubrirá que no escucha ningún maestro y puede recurrir a una conexión normal. Mantén este caso en la batería porque los bloqueos dejan archivos antiguos. El resultado seguro sigue siendo un fallo de revocación durante el nuevo intercambio.

Revocar una identidad durante un incidente activo exige dos controles: rechazar intercambios futuros y terminar los transportes autenticados antes de la revocación. Una prueba que solo cubra uno deja al agente una ruta nueva o una ruta antigua que nunca se cerró.

## Un servidor puede presentar más de una identidad

Los servidores suelen cargar varias claves de host o un certificado junto con su clave subyacente. Revocar una huella no implica que el endpoint deje de ser accesible. Durante la negociación, cliente y servidor eligen un algoritmo compatible; otra clave de confianza no revocada puede autenticar al mismo servidor.

Decide qué significa la declaración del incidente. Si se filtró una clave privada de host, el cliente debe rechazar esa clave, mientras otra clave protegida de forma independiente puede seguir aceptándose después de revisarla. Si la máquina perdió su integridad, revoca todas las identidades que pueda presentar, incluidos los certificados, y retira la confianza hasta reconstruirla. Escribir "host revocado" en un ticket sin enumerar identidades deja la decisión a la negociación de algoritmos.

Inventaría el fixture a partir de la configuración del demonio y los registros de confianza, no de un único escaneo. Prueba cada algoritmo habilitado restringiendo `HostKeyAlgorithms` al que estás examinando. La clave revocada debe fallar. Cada identidad destinada a sobrevivir necesita su caso positivo y su huella documentada.

Los certificados de host añaden otra distinción. Puedes revocar el certificado como objeto público, revocar su número de serie o ID en una KRL, o revocar la CA que autoriza una clase de hosts. Las opciones tienen alcances distintos. El manual de `ssh-keygen` de OpenSSH documenta directivas KRL para números de serie, IDs, claves públicas y huellas; consulta la KRL terminada con el archivo de certificado exacto que presenta el servidor.

`UpdateHostKeys` también merece atención. OpenSSH puede aprender claves adicionales después de autenticar un host con una clave simple que ya era de confianza. Facilita la rotación planificada, pero las alternativas aprendidas antes siguen siendo candidatas salvo que la decisión de revocación las incluya. Extrae los registros known-hosts del cliente de prueba con `ssh-keygen -F` para cada nombre y forma `[name]:port`, y compara cada clave pública con el alcance del incidente.

## Ejecuta la prueba por la ruta real del agente

Una prueba de terminal con la cuenta de un ingeniero no demuestra que un agente autónomo use el mismo binario SSH, configuración, directorio personal, resolutor, ruta proxy o socket de control. La batería final debe invocar el límite de acción exacto que usa el agente y arrancar con el mismo entorno que recibe en producción.

Haz que el banco devuelva pruebas estructuradas para cada variante: etiqueta de destino, hostname y puerto resueltos, huella presentada, resumen KRL, estado de conexión compartida, código de salida, presencia de la señal y fase en que el servidor cerró el intento. No incluyas secretos. La comprobación útil es sencilla: apareció la identidad revocada, el cliente la reconoció como tal y no hubo autenticación de usuario ni comando después.

Aislar el entorno de prueba descubre dependencias accidentales. Define de forma explícita la ruta de configuración SSH, el archivo known-hosts, la KRL, el archivo de identidad y el control path. Borra o sustituye `SSH_AUTH_SOCK` si el agente no debe tomar prestadas claves ajenas. Limita el tiempo de conexión para que CI no quede bloqueado. Conserva stderr y los logs del servidor como artefactos si falla; el informe correcto puede guardar sus hashes y las líneas decisivas.

Si los agentes emiten SSH mediante Sallyport, usa esa ruta en la prueba negativa: su asistente sin estado `sp-ssh` ejecuta las acciones SSH, mientras los diarios Sessions y Activity registran la ejecución del agente y cada llamada. Verifica la cadena offline con `sp audit verify` si la prueba también cubre la integridad de las pruebas; el rechazo de la clave debe seguir procediendo de la configuración de confianza SSH que ejerce la acción real.

No debilites el cliente para facilitar la automatización. `StrictHostKeyChecking=no`, un destino known-hosts vacío o enviar diagnósticos a `/dev/null` convierte una prueba de seguridad en una comprobación de conectividad. `BatchMode=yes` elimina preguntas; no compensa la falta de material de confianza.

## La prueba debe fallar por una sola razón

Incluye la matriz en CI, pero conserva un fixture lo bastante pequeño para diagnosticarlo. Ejecuta un control positivo con una identidad permitida, comprueba previamente la KRL, inicia el listener y prueba las variantes de conexión nueva. Examina la multiplexación en otro trabajo o fase porque su preparación y resultados esperados son distintos. Al final, detén el listener y comprueba que no queda ningún maestro ni socket del fixture.

Rechaza el build si algún destino alcanza la señal, si alguna configuración efectiva carece del archivo de revocación requerido o si el servidor ofrece una identidad que el inventario no clasifica. Rechaza también una ejecución sin conclusión. Un tiempo de espera o una KRL ilegible indican una prueba rota, aunque SSH haya devuelto un valor distinto de cero.

Conserva la huella esperada y el resumen KRL en el informe. Cuando una rotación cambie la identidad del fixture, la revisión debe mostrar ambos valores cambiando juntos. Esa pequeña fricción evita el fallo habitual en el que el servidor obtiene una clave nueva mientras la prueba sigue revocando un archivo público abandonado.

Ejecuta la batería con un proceso de agente incapaz de mostrar preguntas. Un diálogo de aprobación, una solicitud de contraseña o una confirmación de host puede dejar el trabajo esperando hasta que un tiempo de espera genérico oculte la causa. `BatchMode=yes` debe hacer que esas rutas fallen enseguida, mientras el control positivo prueba que el fixture no requiere interacción. Pon un límite duro al trabajo exterior, pero nunca lo cuentes como prueba de revocación.

Conserva una traza detallada y saneada por cada versión de cliente compatible. Da a los responsables una referencia del orden de expansión de configuración, reutilización de conexión, intercambio de claves, selección de identidad y rechazo. Cuando una actualización cambie el comportamiento o las palabras de OpenSSH, compara la traza nueva con esa referencia y modifica las comprobaciones solo después de confirmar que la huella y la fase siguen coincidiendo. Las pruebas de seguridad se degradan si el equipo normaliza cada fallo nuevo como un cambio inofensivo de salida.

Conserva el resultado incómodo del maestro activo. Recuerda a los responsables que distribuir una KRL no revoca una sesión. Cierra los transportes existentes, demuestra que el siguiente intento realiza un intercambio y observa cómo el cliente rechaza la huella exacta que marcaste. Solo entonces habrás demostrado que los alias, el estado en caché y la forma de escribir la dirección no pueden devolver al agente el acceso.