☰

Efecto de las entradas en /etc/securetty

tag-icon • tag-icon security login pam
Efecto de las entradas en /etc/securetty

De forma predeterminada en RHEL 5.5 tengo

[deuberger@saleen trunk]$ sudo cat /etc/securetty 
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11

¿Cuál es la diferencia entre cada uno de los tipos de entrada ( console, vc/*y tty*)? Específicamente, ¿cuál es el resultado final de agregar y eliminar cada tipo de entrada?

Según tengo entendido, afectan cómo y cuándo puede iniciar sesión, pero ¿existen otros efectos? ¿Y cuándo puedes y cuándo no puedes iniciar sesión dependiendo de las entradas que haya?

EDITAR 1

Lo que sí sé es que tty1-6corresponde a si puedes iniciar sesión desde las primeras 6 consolas a las que llegas usando Ctrl- Alta F1través de Ctrl- . Siempre pensé que eran consolas virtuales, así que estoy un poco confundido. ¿Y a qué corresponde?AltF6console

Gracias.

EDITAR 2

¿Cuál es el efecto, si lo hay, en el modo de usuario único?

Respuesta1

/etc/securettySe consulta por pam_securettymódulo para decidir desde qué terminales virtuales ( tty*) rootse permite iniciar sesión.

En el pasado, /etc/securettylos programas lo consultaban logindirectamente, pero ahora PAM se encarga de eso. Por lo tanto, los cambios /etc/securettyafectarán a cualquier cosa que utilice PAM con un archivo de configuración que utilice pam_securetty.so. Por lo tanto, sólo el loginprograma se ve afectado de forma predeterminada.

/etc/pam.d/loginse usa para inicios de sesión locales y /etc/pam.d/remotepara inicios de sesión remotos (como telnet).

Los tipos de entrada principales y sus efectos son los siguientes:

  • Si /etc/securettyno existe, rootse permite iniciar sesión desde cualquiertty
  • Si /etc/securettyexiste y está vacío, rootel acceso se restringirá al modo de usuario único o a programas que no estén restringidos por pam_securetty(es decir su, sudo, ssh, scp, sftp)
  • Si está utilizando devfs(un sistema de archivos obsoleto para el manejo /dev), agregar entradas del formulario vc/[0-9]*permitirá el inicio de sesión raíz desde el número de consola virtual proporcionado.
  • Si está utilizando udev(para administración dinámica de dispositivos y reemplazo de devfs), agregar entradas del formulario tty[0-9]*permitirá el inicio de sesión raíz desde el número de consola virtual proporcionado.
  • El listado consolenormalmente /etc/securettyno tiene ningún efecto ya que /dev/consoleapunta a la consola actual y normalmente solo se usa como ttynombre de archivo en el modo de usuario único, que no se ve afectado por/etc/securetty
  • Agregar entradas como pts/[0-9]*permitirá que los programas que usan pseudo-terminales ( pty) pam_securettyinicien sesión rootasumiendo que el asignado ptyes uno de los enumerados; normalmente es una buena ideanoincluir estas entradas porque es un riesgo de seguridad; permitiría, por ejemplo, que alguien inicie sesión en root a través de telnet, que envía contraseñas en texto sin formato (tenga en cuenta que pts/[0-9]*es el formato udevque se usa en RHEL 5.5; será diferente si se usa devfsalguna otra forma de administración de dispositivos).

Para el modo de usuario único, /etc/securettyno se consulta porque suloginse usa en lugar de login(consulte la suloginpágina de manual para obtener más información). También puede cambiar el programa de inicio de sesión utilizado /etc/inittabpara cada nivel de ejecución.

Tenga en cuenta que no debe utilizar /etc/securettypara controlar rootlos inicios de sesión a través de ssh. Para hacer eso cambie el valor de PermitRootLoginin /etc/ssh/sshd_config. Por defecto /etc/pam.d/sshdno está configurado para consultar pam_securetty(y por tanto /etc/securetty). Podría agregar una línea para hacerlo, pero sshno establece el valor real ttyhasta algún momento después de la authetapa, por lo que no funciona como se esperaba. Durante las etapas authy account, al menos para openssh, tty( PAM_TTY) está codificado en ssh.

La respuesta anterior se basa en RHEL 5.5. Gran parte pertenecerá a distribuciones actuales de otros sistemas *nix, pero existen diferencias, algunas de las cuales noté, pero no todas.

Respondí esto yo mismo porque las otras respuestas estaban incompletas o inexactas. Muchos otros foros, blogs, etc. en línea también tienen información inexacta e incompleta sobre este tema, por lo que he realizado investigaciones y pruebas exhaustivas para tratar de obtener los detalles correctos. Si algo de lo que he dicho está mal, házmelo saber.

Fuentes:

Respuesta2

vc/Xy ttyXson sinónimos: diferentes caminos hacia los mismos dispositivos. El objetivo de la redundancia es detectar varios casos para no dejarlo fuera.

Tradicionalmente login(y posiblemente getty, no lo recuerdo con certeza) verificaba /etc/securettyy denegaba rootlos inicios de sesión en terminales no listados. En los sistemas modernos, existen otras formas de hacer esto y también otras medidas de seguridad. Consulte el contenido de /etc/login.defs(que también cubre securettyla funcionalidad de y es recomendado por la securetty(5)página de manual), y también /etc/pam.d/login, donde puede controlar el comportamiento de esta característica.

Dado que securettysolo lo verifica login, los medios de inicio de sesión que no utilizan login(por ejemplo, SSH con use_login=no, administradores de visualización X, etc.) no se ven afectados.

información relacionada