Efecto de entradas en / etc / securetty

Por defecto 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 (consola, vc / y tty )? Específicamente, ¿cuál es el resultado final de agregar y eliminar cada tipo de entrada?

Tengo entendido que afectan cómo y cuándo puede iniciar sesión, pero ¿hay otros efectos? ¿Y cuándo puedes y cuándo no puedes iniciar sesión dependiendo de qué entradas hay?

EDITAR 1 Lo que sí sé es que tty 1-6 corresponde a si puede iniciar sesión desde las primeras 6 consolas a las que llega utilizando CTRL-ALT-F1 a través de CTRL-ALT-F6. Siempre pensé que eran consolas virtuales, así que estoy un poco confundido. ¿Y a qué se corresponde la consola también? Gracias.

EDIT 2 ¿Cuál es el efecto si alguno en modo de usuario único?

/etc/securettyes consultado por el módulo pam_securetty para decidir desde qué raíz virtual (ttyS) puede iniciar sesión la raíz. En el pasado, /etc/securettyfue consultado por programas como iniciar sesión directamente, pero ahora PAM maneja eso. Por lo tanto, los cambios /etc/securettyafectarán cualquier cosa que use PAM con un archivo de configuración que use pam_securetty.so. Por lo tanto, solo el programa de inicio de sesión se ve afectado por defecto. /etc/pam.d/loginse usa para inicios de sesión locales y /etc/pam.d/remotese usa para inicios de sesión remotos (como telnet).

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

• Si /etc/securettyno existe, la raíz puede iniciar sesión desde cualquier tty
• Si /etc/securettyexiste y está vacío, el acceso raíz estará restringido al modo de usuario único o 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 / desarrollo), agregar entradas con el formato vc / [0-9] * permitirá el inicio de sesión raíz desde el número de consola virtual dado
• si está utilizando udev (para la administración dinámica de dispositivos y el reemplazo de devfs), agregar entradas de la forma tty [0-9] * permitirá el inicio de sesión raíz desde el número de consola virtual dado
• listar la consola en securetty, normalmente no tiene efecto ya que / dev / console apunta a la consola actual y normalmente solo se usa como el nombre de archivo tty en 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) y pam_securetty inicien sesión en la raíz, suponiendo que pty asignado sea uno de los listados; normalmente es una buena idea no incluir estas entradas porque es un riesgo de seguridad; permitiría, por ejemplo, que alguien inicie sesión en la raíz a través de telenet, que envía contraseñas en texto sin formato (tenga en cuenta que pts / [0-9] * es el formato para udev que se usa en RHEL 5.5; será diferente si usa devfs o alguna otra forma de gestión de dispositivos)

Para el modo de usuario único, /etc/securettyno se consulta porque se usa sulogin en lugar de iniciar sesión. Consulte la página de manual de sulogin 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 usar /etc/securettypara controlar los inicios de sesión de raíz a través de ssh. Para hacer eso, cambie el valor de PermitRootLogin en /etc/ssh/sshd_config. Por defecto /etc/pam.d/sshdno está configurado para consultar pam_securetty (y por lo tanto /etc/securetty). Puede agregar una línea para hacerlo, pero ssh no establece el tty real hasta algún momento después de la etapa de autenticación, por lo que no funciona como se esperaba. Durante las etapas de autenticación y cuenta, al menos para openssh, el tty (PAM_TTY) está codificado en "ssh".

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

Yo mismo respondí esto porque las otras respuestas eran incompletas y / 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 una amplia investigación y pruebas para intentar obtener los detalles correctos. Si algo de lo que he dicho está mal, házmelo saber.

Fuentes:

• http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-sec-network.html#s1-wstation-privileges
• http://www.mathematik.uni-marburg.de/local-doc/centos5/pam-0.99.6.2/html/sag-pam_securetty.html
• http://linux.die.net/man/1/login
• http://www.tldp.org/HOWTO/html_single/Text-Terminal-HOWTO/
• http://www.kernel.org/doc/Documentation/devices.txt
• http://en.wikipedia.org/wiki/Virtual_console
• http://en.wikipedia.org/wiki/Linux_console
• http://www.kernel.org/doc/man-pages/online/pages/man4/console.4.html
• http://www.unix.com/security/8527-restricting-root-login.html
• http://www.redhat.com/mirrors/LDP/HOWTO/Serial-HOWTO-11.html#ss11.3
• http://www.mathematik.uni-marburg.de/local-doc/centos5/udev-095/udev_vs_devfs

vc/Xy ttyXson sinónimos: diferentes rutas a los mismos dispositivos. El objetivo de la redundancia es detectar varios casos para no bloquearlo.

Tradicionalmente, login(y posiblemente getty, no puedo recordar con certeza) verificaría /etc/securettyy negaría los rootinicios de sesión en terminales no listados. En los sistemas modernos, hay otras formas de hacer esto y otras medidas de seguridad también. Consulte el contenido de /etc/login.defs(que también cubre securettyla funcionalidad de la página de securetty(5)manual y lo recomienda ), y también /etc/pam.d/logindónde puede controlar el comportamiento de esta función.

Dado securettyque solo se verifica por login, los medios de inicio de sesión que no se utilizan login(por ejemplo, SSH con use_login=noX gestores de pantalla, etc.) no se ven afectados.