20 Preguntas de Práctica de Autenticación y endurecimiento del sistema con Respuestas

1. 1. En la pila auth de /etc/pam.d/login, un módulo tiene la marca de control requisite y aparece antes de varios otros módulos auth. ¿Qué ocurre cuando ese módulo devuelve un fallo?

   • A.La pila sigue ejecutando los módulos auth posteriores y el resultado global es un fallo al terminar.
   • B.El fallo queda registrado pero se ignora y el resultado depende solo de los demás módulos de la pila.
   • C.Los módulos restantes se omiten y la autenticación se concede, porque un módulo anterior ya fue válido.
   • D.La pila se detiene de inmediato y la autenticación falla; los módulos auth posteriores no se consultan.✓ Respuesta

   requisite es fatal en el momento: la biblioteca devuelve el fallo a la aplicación de inmediato, por lo que no se ejecuta nada posterior de ese grupo de gestión. required también hace fallar la pila, pero solo después de ejecutar los módulos restantes, y por eso se prefiere cuando no se quiere revelar en qué paso ocurrió el fallo.

   Ref. QB-H5VM6RFuente: Linux-PAM System Administrators' Guide — control flags (requisite, required, sufficient, optional) in /etc/pam.d configurationReportar un problema con esta pregunta

2. 2. La política exige que una contraseña nueva tenga al menos una longitud mínima definida, use varias clases de caracteres y no repita ninguna de las contraseñas recientes del usuario. ¿Qué mecanismo aplica esas tres reglas en un host Linux?

   • A.PASS_MIN_DAYS y PASS_MAX_DAYS en /etc/login.defs, que passwd aplica en cada cambio de contraseña.
   • B.La utilidad chage con -m y -M, porque los campos de caducidad de /etc/shadow guardan las reglas de robustez.
   • C.El grupo de gestión password de la pila PAM, mediante los módulos pam_pwquality y pam_pwhistory.✓ Respuesta
   • D.Las comprobaciones propias del comando passwd, configuradas por cuenta con las opciones passwd -n y -x.

   La longitud, las clases de caracteres y la reutilización son comprobaciones de calidad que se ejecutan al fijar la contraseña, de modo que corresponden al grupo password de la pila conectable: pam_pwquality evalúa la candidata y pam_pwhistory la compara con el historial guardado. chage y login.defs solo controlan la caducidad (días mínimos y máximos, aviso e inactividad) y no pueden expresar complejidad.

   Ref. QB-YMB5EPFuente: pam_pwquality(8) and pam_pwhistory(8) manual pages; chage(1) and login.defs(5) for aging fieldsReportar un problema con esta pregunta

3. 3. Un host está unido a un directorio central. Ejecutar grep alice /etc/passwd no devuelve nada, pero getent passwd alice imprime una entrada de cuenta completa. ¿Qué archivo decide que las búsquedas de cuentas puedan ir más allá del archivo local?

   • A./etc/pam.d/system-auth, cuyas líneas auth deciden qué back end valida una solicitud de inicio de sesión.
   • B./etc/security/access.conf, cuyas reglas deciden qué cuentas pueden entrar desde qué hosts o terminales.
   • C./etc/resolv.conf, cuyas líneas nameserver deciden qué servidores resuelven nombres para las bibliotecas.
   • D./etc/nsswitch.conf, cuyas líneas passwd y group enumeran, en orden, las fuentes consultadas de cuentas.✓ Respuesta

   El conmutador de servicios de nombres es la tabla que asocia cada base de datos (passwd, group, shadow, hosts) con una lista ordenada de fuentes, así que añadir ahí una fuente de directorio es lo que hace visibles las cuentas remotas para cualquier llamada de biblioteca. Por eso getent es la forma correcta de probar la resolución de cuentas: grep solo lee el archivo plano, mientras getent recorre el mismo conmutador que usa el inicio de sesión.

   Ref. QB-G5HAZPFuente: nsswitch.conf(5) and getent(1) manual pagesReportar un problema con esta pregunta

4. 4. Un entorno ejecuta tanto un servicio de directorio central como un servicio de autenticación basado en tickets para clientes Linux. ¿Qué afirmación divide correctamente el trabajo entre ambos?

   • A.El directorio aporta atributos como UID, grupos y ruta del home, y los tickets prueban la identidad sin enviar la contraseña a cada servicio.✓ Respuesta
   • B.El directorio emite tickets con límite de tiempo a cada cliente, y el servicio de tickets guarda atributos como UID, grupos y shell.
   • C.El directorio sustituye por completo a /etc/shadow en cada cliente, y el servicio de tickets solo cifra en tránsito las consultas al directorio.
   • D.El directorio decide qué comandos puede ejecutar un usuario, y el servicio de tickets guarda la caché de credenciales para uso sin red.

   Un directorio es un almacén de identidades al que se consultan atributos de cuenta y pertenencia a grupos, mientras que un protocolo basado en tickets es un mecanismo de autenticación: el cliente prueba su identidad una vez ante el centro de distribución de claves y luego presenta tickets, por lo que ningún servicio maneja la contraseña. Como los tickets llevan marcas de tiempo y una validez corta, los relojes deben coincidir, y por eso la sincronización horaria es una dependencia estricta.

   Ref. QB-XMYS8NFuente: CompTIA Linux+ Security content domain — authentication, authorization and accounting methods (directory services versus ticket-based authentication); krb5.conf(5) and kinit(1)Reportar un problema con esta pregunta

5. 5. Un administrador ejecuta auditctl -w /etc/shadow -p wa -k shadow_changes. La regla aparece en auditctl -l y se registran eventos, pero desaparece tras reiniciar. ¿Qué hace que la vigilancia sea persistente?

   • A.Añadir la regla a un archivo de /etc/rsyslog.d y reiniciar el servicio de registro, que la recarga al arrancar.
   • B.Escribir la regla en un archivo de /etc/audit/rules.d y cargarla con augenrules --load, que reconstruye el conjunto.✓ Respuesta
   • C.Activar el almacenamiento persistente del journal en /etc/systemd/journald.conf, porque las vigilancias se guardan allí.
   • D.Añadir la regla con auditctl -e 2, que bloquea la configuración en ejecución y la escribe en disco al apagar.

   auditctl carga reglas solo en el kernel en ejecución, así que lo añadido de ese modo se pierde al reiniciar. La vía persistente es un archivo de reglas en /etc/audit/rules.d, que augenrules compila en el conjunto que carga el demonio de auditoría al iniciarse; -e 2 hace otra cosa: bloquea la configuración para que no se acepten más cambios hasta reiniciar.

   Ref. QB-F56YTNFuente: auditctl(8) and augenrules(8) manual pagesReportar un problema con esta pregunta

6. 6. A un proceso web se le deniega el acceso a un archivo aunque los bits de modo lo permiten, y nada aparece en el journal del servicio. ¿Dónde queda registrada la denegación y qué distingue a ese subsistema del registro del sistema?

   • A.En /var/log/messages: el demonio de registro recoge los eventos de control de acceso del kernel con authpriv.
   • B.En /var/log/audit/audit.log: el subsistema de auditoría del kernel registra llamadas y eventos de control de acceso.✓ Respuesta
   • C.En el journal de la propia unidad: las denegaciones las emite como mensajes el proceso al que se le negó el acceso.
   • D.En /var/log/btmp: los intentos de acceso rechazados se añaden a ese archivo y se leen con la utilidad lastb.

   El registro del sistema recoge mensajes que las aplicaciones deciden emitir, mientras que el subsistema de auditoría es una función del kernel que anota los eventos que el propio kernel observa (llamadas al sistema, accesos vigilados y denegaciones del control de acceso obligatorio) en su registro propio, independiente del journal y del demonio de registro. Por eso una denegación puede no verse en el journal del servicio y estar documentada en el registro de auditoría.

   Ref. QB-WMMF3MFuente: auditd(8) and ausearch(8) manual pages; CompTIA Linux+ Security content domain — accounting and audit proceduresReportar un problema con esta pregunta

7. 7. ¿Por qué se prefiere en general delegar una tarea mediante sudo en lugar de que el operador ejecute su - para convertirse en root?

   • A.sudo autentica con la contraseña de root pero baja privilegios tras cada comando, así que no queda un shell de root abierto.
   • B.sudo autentica al invocante con su propia contraseña y registra cada comando ejecutado, de modo que las acciones son atribuibles.✓ Respuesta
   • C.su - consulta /etc/sudoers para las reglas del invocante, así que un comando no listado se rechaza antes de abrir el shell.
   • D.su - autentica con la contraseña del propio invocante y registra cada comando, pero no puede limitar qué comandos se ejecutan.

   sudo reautentica al invocante con sus propias credenciales, consulta una política que puede nombrar comandos concretos y una identidad destino, y escribe una entrada de registro por cada invocación, de modo que la traza indica qué persona ejecutó qué comando. su - exige la contraseña de la cuenta destino, que debe compartirse para ser útil, y devuelve un shell interactivo en el que toda acción posterior se atribuye solo a root.

   Ref. QB-E5TMNMFuente: sudo(8) and su(1) manual pages; sudoers(5) on logging and command specificationsReportar un problema con esta pregunta

8. 8. Un administrador va a añadir una regla de delegación. ¿Por qué debe editarse la política con visudo en vez de abrir /etc/sudoers directamente en un editor de texto?

   • A.visudo cifra el archivo al guardar, de modo que no puedan leer las reglas los usuarios que aún no tienen una delegación.
   • B.visudo bloquea el archivo frente a ediciones simultáneas y lo analiza al guardar, y no lo instala si hay error.✓ Respuesta
   • C.visudo recarga después el servicio en ejecución, un paso necesario para que cualquier regla recién añadida surta efecto.
   • D.visudo aplica la regla nueva a la sesión de shell actual, así que el cambio puede probarse sin cerrar y volver a abrir sesión.

   visudo toma un bloqueo para que dos administradores no se sobrescriban y ejecuta el analizador de la política antes de sustituir el archivo activo, ofreciendo reeditar si la sintaxis es incorrecta. Importa porque un archivo de política mal formado hace que todo el mecanismo de delegación se niegue a funcionar y el host puede quedarse sin forma de obtener privilegios elevados; la misma comprobación puede ejecutarse de forma no interactiva para validar un archivo antes de instalarlo.

   Ref. QB-5N4T9VFuente: visudo(8) manual page — file locking and syntax checking of the sudoers policyReportar un problema con esta pregunta

9. 9. Los miembros del grupo dba deben poder reiniciar únicamente el servicio de base de datos, como root, en todos los hosts. ¿Qué entrada, colocada en un archivo dentro de /etc/sudoers.d, expresa exactamente eso?

   • A.%dba ALL=(root) /usr/bin/systemctl restart postgresql✓ Respuesta
   • B.%dba ALL=(root) NOPASSWD: ALL, restart postgresql only
   • C.dba ALL=(ALL:ALL) /usr/bin/systemctl restart postgresql
   • D.%dba postgresql=(root) /usr/bin/systemctl restart ALL

   Una regla se lee user host=(runas) comandos, el prefijo % convierte el primer campo en un grupo y el campo host es el host al que se aplica la regla (ALL, nunca un nombre de servicio). Indicar la ruta completa del comando con su argumento es lo que limita la delegación; conceder ALL, sobre todo con la etiqueta sin contraseña, entrega root sin restricciones y elimina la reautenticación, lo que desvirtúa la delegación de una sola tarea. Omitir el % crea en silencio una regla para una cuenta de usuario llamada dba en lugar del grupo.

   Ref. QB-N5AYUVFuente: sudoers(5) manual page — user specifications, group prefix, host and runas fields, and #includedir drop-in filesReportar un problema con esta pregunta

10. 10. Una regla permite a un operador ejecutar un editor de texto como root para corregir un archivo de configuración. Los auditores objetan que el editor puede abrir un shell con :!sh. ¿Qué etiqueta de sudoers resuelve eso?

    • A.NOPASSWD:, que impide que el editor vuelva a pedir credenciales y por tanto que llegue a un shell.
    • B.NOEXEC:, que impide que el programa delegado ejecute por su cuenta ningún otro programa.✓ Respuesta
    • C.PASSWD:, que fuerza la reautenticación cada vez que el editor intenta iniciar otro programa.
    • D.SETENV:, que limpia el entorno para que el editor no encuentre un shell en la ruta de búsqueda.

    Editores, paginadores, intérpretes y herramientas con una opción de tipo exec pueden lanzar un proceso hijo que hereda el privilegio elevado, convirtiendo una delegación estrecha en un shell de root completo. La etiqueta NOEXEC bloquea esas ejecuciones hijas, de modo que el programa delegado hace solo su trabajo; las etiquetas de contraseña solo cambian si el invocante debe reautenticarse y cuándo, y no afectan a las fugas al shell.

    Ref. QB-ZSVGTYFuente: sudoers(5) manual page — NOEXEC and EXEC tags, preventing shell escapesReportar un problema con esta pregunta

11. 11. El inicio de sesión con clave pública falla y vuelve a pedir contraseña. En el servidor, ls -ld muestra /home/bob/.ssh como drwxrwxrwx y su authorized_keys como -rw-rw-r--, y el registro dice "Authentication refused: bad ownership or modes". ¿Cómo se corrige?

    • A.Ejecutar chmod 777 en /home/bob/.ssh y 666 en authorized_keys, para que el demonio, que corre como root, lea la clave.
    • B.Poner PubkeyAuthentication yes y recargar el demonio, porque ese rechazo significa que la clave pública está desactivada.
    • C.Copiar la clave privada en /home/bob/.ssh/authorized_keys, porque el servidor compara con esa mitad la clave ofrecida.
    • D.Ejecutar chmod 700 en /home/bob/.ssh y 600 en authorized_keys: el servidor ignora claves escribibles por grupo u otros.✓ Respuesta

    El servidor se niega a aceptar un archivo de claves autorizadas que el grupo del propietario u otros puedan modificar, porque un archivo escribible permitiría a un tercero añadir su propia clave; por eso la comprobación estricta exige el directorio en 700 y el archivo en 600, ambos propiedad del usuario. En el servidor solo se instala la mitad pública del par (ssh-copy-id la añade a authorized_keys), mientras la privada queda en el cliente y solo la lee su propietario.

    Ref. QB-GAQB8YFuente: sshd(8) manual page — AuthorizedKeysFile and StrictModes; ssh-copy-id(1)Reportar un problema con esta pregunta

12. 12. El sshd_config de un servidor contiene PermitRootLogin prohibit-password junto con PasswordAuthentication yes. ¿Cuál es el efecto de esa combinación y qué la endurece más?

    • A.root todavía puede entrar con una clave, y solo PermitRootLogin no rechaza el acceso de root por cualquier método.✓ Respuesta
    • B.root ya no puede entrar por ningún método; el único cambio pendiente es PasswordAuthentication no para los usuarios normales.
    • C.root puede entrar con contraseña pero no con clave, y PermitRootLogin no bloquearía solo la vía basada en clave.
    • D.root solo puede entrar desde la consola, y PermitRootLogin forced-commands-only seguiría permitiendo un acceso interactivo con clave.

    prohibit-password bloquea solo las vías de contraseña e interactiva por teclado para root; la autenticación por clave pública o certificado sigue funcionando, así que las sesiones remotas de root siguen siendo posibles. Poner la directiva en no es lo que rechaza el acceso de root por completo, y desactivar aparte la autenticación por contraseña es lo que obliga a las demás cuentas a usar claves.

    Ref. QB-2T8UYZFuente: sshd_config(5) manual page — PermitRootLogin and PasswordAuthenticationReportar un problema con esta pregunta

13. 13. Al conectarse a un servidor accesible desde hace meses, ssh imprime WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED y se niega a continuar. ¿Qué indica eso?

    • A.La contraseña de la cuenta cambió en el servidor, así que la credencial que el agente guardaba para ese host ya no se acepta.
    • B.La clave privada del usuario ya no coincide con la pública de authorized_keys, así que el servidor rechazó la clave ofrecida.
    • C.La clave de host del servidor llegó al final de su validez y hay que generar un par nuevo en el cliente para reconectar.
    • D.La clave de host ya no coincide con la registrada en known_hosts, como tras una reinstalación o en una interceptación.✓ Respuesta

    En la primera conexión el cliente guarda la clave de host del servidor y en cada conexión posterior compara la clave presentada con ese registro; una discrepancia significa que la identidad del servidor cambió de verdad (reinstalación, imagen restaurada, clave regenerada) o que algo responde en su lugar. El cliente se detiene en vez de preguntar, porque continuar permitiría a un interceptor capturar la sesión, así que lo correcto es confirmar la huella nueva por otro canal antes de borrar la entrada obsoleta.

    Ref. QB-HA3PDZFuente: ssh(1) manual page — host key verification and the known_hosts fileReportar un problema con esta pregunta

14. 14. Un ingeniero usa ssh -A para llegar a servidores internos a través de un host de salto compartido por muchos equipos. ¿Por qué se desaconseja reenviar el agente de autenticación en ese host?

    • A.El archivo de clave privada se copia al host de salto durante la sesión y allí queda legible después de cerrarla.
    • B.La frase de paso viaja en claro hasta el host de salto para que el extremo remoto descifre la clave cuando la necesite.
    • C.El host de salto se añade a known_hosts como host de confianza, así que los cambios posteriores de su clave se aceptan en silencio.
    • D.Quien tenga root en el host de salto puede usar el socket reenviado del agente para autenticarse como el ingeniero en otros servidores.✓ Respuesta

    El reenvío del agente no copia la clave: expone en el host intermedio un socket por el que se pueden solicitar firmas con la clave que está en la estación de trabajo. Quien alcance ese socket (root o cualquiera que pueda leerlo) puede autenticarse en todos los sitios donde la clave sea de confianza mientras dure la sesión; por eso el reenvío debe limitarse a hosts tan fiables como el propio y sustituirse por una opción de salto que nunca exponga el agente.

    Ref. QB-XS6UFWFuente: ssh(1) manual page — ForwardAgent and the -A option security caveat; ssh_config(5) ProxyJumpReportar un problema con esta pregunta

15. 15. En un host de la familia RHEL, getenforce informa Enforcing. Un administrador quiere primero confirmar que la política es lo que bloquea un servicio y después desactivar el mecanismo por completo. ¿Qué es cierto de esos dos pasos?

    • A.setenforce 0 pasa el host directamente a Disabled, y Permissive solo puede elegirse editando /etc/selinux/config.
    • B.Tanto Permissive como Disabled se eligen con setenforce, y el valor de /etc/selinux/config solo rige el etiquetado del sistema de archivos.
    • C.setenforce 0 pasa a Permissive, donde las denegaciones solo se registran, pero llegar a Disabled exige /etc/selinux/config y reiniciar.✓ Respuesta
    • D.Permissive sigue bloqueando el acceso aunque lo registre, así que solo Disabled en /etc/selinux/config prueba que la política es la causa.

    setenforce solo alterna entre Enforcing y Permissive, y el cambio dura hasta el siguiente arranque; en Permissive la política se sigue evaluando y las denegaciones se escriben en el registro de auditoría, pero nada se bloquea, lo que la convierte en un diagnóstico que confirma la causa. Entrar o salir de Disabled significa no cargar la política, así que exige el ajuste SELINUX en /etc/selinux/config y reiniciar, y dejar el host desactivado no es una solución: el remedio correcto suele ser una etiqueta o un booleano.

    Ref. QB-EAZNVVFuente: setenforce(8), getenforce(8) and selinux(8) manual pages; /etc/selinux/config on RHEL-family systemsReportar un problema con esta pregunta

16. 16. En un servidor web de la familia RHEL, un archivo movido con mv al directorio publicado devuelve un error de permisos y el registro de auditoría muestra un tipo de contexto que no coincide. ¿Qué acción corrige la etiqueta de forma duradera?

    • A.Fijar el tipo a mano con chcon -t, que escribe la etiqueta nueva en la política para que los reetiquetados la conserven.
    • B.Volver a copiar el archivo con cp --preserve=context, que le pone la etiqueta predeterminada del directorio destino.
    • C.Añadir la ruta a las reglas de contexto con semanage fcontext y luego aplicarlas al árbol con restorecon -Rv.✓ Respuesta
    • D.Ejecutar setenforce 0 y dejar el host permisivo, porque la etiqueta se corregirá por sí sola en el siguiente arranque.

    mv conserva el contexto de seguridad que ya tenía el archivo, mientras cp crea un archivo nuevo que hereda el predeterminado del directorio destino, y por eso mover contenido a un directorio publicado es la causa clásica de un tipo que no coincide. La reparación duradera es registrar el contexto esperado de esa ruta en las reglas de contexto y reetiquetar, para que la etiqueta sobreviva a cualquier reetiquetado futuro; chcon cambia la etiqueta al instante pero no queda en las reglas, así que un reetiquetado o una restauración la revierte en silencio.

    Ref. QB-YSH6NXFuente: semanage-fcontext(8), restorecon(8) and chcon(1) manual pagesReportar un problema con esta pregunta

17. 17. En un host de la familia RHEL, setsebool httpd_can_network_connect on permite a la aplicación web alcanzar un servicio de back end, pero tras reiniciar las conexiones salientes vuelven a rechazarse. ¿Por qué?

    • A.El reinicio restauró los contextos de archivo del árbol, y el booleano se guarda como atributo extendido de ese directorio.
    • B.El booleano elegido fue el equivocado, y solo un módulo de política propio puede permitir conexiones salientes de un servicio.
    • C.El cambio solo se escribió en la política en ejecución; hace falta la opción -P para guardarlo como predeterminado.✓ Respuesta
    • D.Los booleanos se leen de /etc/selinux/config al arrancar, así que el ajuste debe añadirse como una línea de ese archivo.

    Un booleano es un interruptor que activa o desactiva una parte opcional de la política sin escribir reglas nuevas, y setsebool lo cambia solo en el kernel en ejecución. Añadir -P escribe además el valor en el almacén persistente de la política, de modo que se restaura al arrancar; se pueden listar los valores actuales de todos los booleanos para comprobar cuáles están activos y si el valor guardado coincide con el vigente.

    Ref. QB-FACZ2XFuente: setsebool(8) and getsebool(8) manual pages — the -P option and persistent boolean valuesReportar un problema con esta pregunta

18. 18. Una norma de endurecimiento exige que una cuenta se bloquee automáticamente tras cierto número de fallos de contraseña consecutivos y se desbloquee al cabo de un intervalo definido. ¿Dónde se aplica eso y con qué?

    • A.En la pila PAM, mediante el módulo faillock, cuyos ajustes deny y unlock_time cuentan los fallos de cada cuenta.✓ Respuesta
    • B.En sshd_config, mediante MaxAuthTries, que bloquea la cuenta tras ese número de fallos dentro de una misma conexión.
    • C.En /etc/shadow, mediante el campo inactive, que bloquea la cuenta cuando el recuento de fallos supera el límite.
    • D.En /etc/login.defs, mediante PASS_MAX_DAYS, que desactiva la cuenta cuando se registran intentos fallidos repetidos.

    El bloqueo es una decisión del momento de autenticar, así que corresponde a la pila conectable: el módulo faillock mantiene por usuario un recuento de fallos consecutivos y deniega la autenticación al alcanzar el umbral configurado, liberando la cuenta tras el intervalo de desbloqueo, y el administrador puede poner el contador a cero antes con la utilidad faillock. El antiguo módulo tally que hacía esto se eliminó de la biblioteca, por lo que faillock es la implementación actual; MaxAuthTries solo limita los intentos de una conexión y no bloquea nada.

    Ref. QB-5TAUG5Fuente: pam_faillock(8) and faillock(8) manual pages; sshd_config(5) MaxAuthTriesReportar un problema con esta pregunta

19. 19. Un paquete crea una cuenta de servicio que posee archivos y ejecuta un demonio, pero que nunca debe poder abrir una sesión interactiva. ¿Qué ajuste expresa ese requisito?

    • A.Poner como shell de inicio de la cuenta nologin, de modo que un intento interactivo imprima un aviso y termine al instante.✓ Respuesta
    • B.Fijar con chage -E una fecha de caducidad pasada, para que el demonio siga activo mientras se rechaza toda sesión.
    • C.Darle a la cuenta un UID por debajo del rango de usuarios normales, para el que el programa de login no abre un shell.
    • D.Poner un solo asterisco en el campo de contraseña de /etc/shadow, lo que le quita el acceso a su directorio personal.

    Sustituir el shell de inicio por nologin es la forma estándar de decir «esta identidad existe para poseer procesos y archivos, no para iniciar sesión»: el programa imprime un mensaje de rechazo y termina con estado de error, así que nunca se abre un shell para esa cuenta. Un UID dentro del rango del sistema es solo una convención y no impide abrir un shell, y una fecha de caducidad es un control de ciclo de vida pensado para usuarios reales.

    Ref. QB-MA5PW4Fuente: nologin(8) manual page; useradd(8) -r and -s options for system accountsReportar un problema con esta pregunta

20. 20. Los inicios de sesión SSH en un servidor deben exigir tanto una clave válida como un código de un solo uso de una aplicación autenticadora, en ese orden. ¿Qué ajuste de sshd_config, junto con un módulo PAM para el código, lo expresa?

    • A.PubkeyAuthentication yes junto con PasswordAuthentication yes, para que el cliente presente cualquiera de los dos métodos.
    • B.AuthenticationMethods publickey keyboard-interactive, que deja al cliente usar el de los dos métodos que tenga disponible.
    • C.AuthenticationMethods publickey,keyboard-interactive, que obliga a la sesión a cumplir ambos métodos por turno antes de abrirse.✓ Respuesta
    • D.UsePAM yes junto con PermitEmptyPasswords no, que añade la petición del código una vez aceptada la clave ofrecida.

    AuthenticationMethods enumera los métodos que una sesión debe completar y el separador aporta el significado: la coma une métodos que deben cumplirse todos en el orden indicado, mientras el espacio separa listas alternativas de las que basta una. Por eso la forma con coma es la que produce dos factores (algo que se tiene, la clave, y algo generado por la aplicación autenticadora a través de la vía interactiva por teclado hacia la pila conectable), mientras que solo habilitar dos métodos deja al cliente usar uno.

    Ref. QB-ABTMZNFuente: sshd_config(5) manual page — AuthenticationMethods, comma-separated required methods versus space-separated alternativesReportar un problema con esta pregunta

Preguntas de práctica redactadas según los objetivos publicados del examen CompTIA Linux+ y la práctica estándar de administración de Linux. CompTIA y Linux+ son marcas de CompTIA, y Linux es una marca registrada de Linus Torvalds; este sitio no está afiliado ni respaldado por CompTIA. El examen real combina preguntas de opción múltiple con preguntas basadas en desempeño que piden ejecutar una tarea en un entorno simulado: eso no puede reproducirse en un formato de cuatro opciones, así que este banco cubre la mitad teórica y conviene practicar en un sistema real en paralelo. CompTIA revisa y numera las versiones de los objetivos periódicamente: confirma los objetivos, el código de examen y los requisitos vigentes con CompTIA antes de examinarte. Sobre la certificación CompTIA Linux+ →