¿Cuál es la diferencia entre / sbin / nologin y / bin / false?

He oído a menudo se recomienda que una cuenta de usuario debe desactivarse mediante el establecimiento de su caparazón para /bin/false. Pero, en mis sistemas Linux existentes, veo que una gran cantidad de cuentas existentes (todas ellas cuentas de servicio) tienen un shell /sbin/nologin.

Veo en la página del manual que /sbin/nologinimprime un mensaje al usuario que dice que la cuenta está deshabilitada y luego se cierra. Presumiblemente /bin/falseno imprimiría nada.

También veo que /sbin/nologinaparece en la lista /etc/shells, mientras /bin/falseque no.

La página del manual dice que FTP deshabilitará el acceso para los usuarios con un shell que no figura en la lista /etc/shellse implica que otros programas pueden hacer lo mismo. ¿Eso significa que alguien podría enviar un FTP con una cuenta que tiene /sbin/nologincomo shell?

¿Cual es la diferencia aquí? ¿Cuál de estos debo usar para deshabilitar una cuenta de usuario y en qué circunstancias? ¿Qué otros efectos tiene un listado /etc/shells?

/bin/falsees un programa de utilidad, complementario /bin/true, que es útil en un sentido abstracto para garantizar que Unix tenga funciones completas. Sin embargo, se han encontrado propósitos emergentes para estos programas; considere la declaración BASH /some/program || /bin/true, que siempre evaluará boolean a true ( $? = 0) sin importar el retorno de /some/program.

Un uso emergente de /bin/false, como identificó, es como un shell nulo para los usuarios que no pueden iniciar sesión. El sistema en este caso se comportará exactamente como si el shell no se ejecutara.

POSIX (aunque puedo estar equivocado y puede ser el SUS) restringe estos dos comandos para hacer exactamente nada más que devolver el valor booleano apropiado.

/sbin/nologines una utilidad BSD que tiene un comportamiento similar a /bin/false(devuelve boolean false), pero también imprime la salida, como /bin/falseestá prohibido. Se supone que esto ayuda al usuario a comprender lo que sucedió, aunque en la práctica muchos emuladores de terminal simplemente se cerrarán cuando finalice el shell, haciendo que el mensaje sea casi ilegible en algunos casos.

Hay poca propósito de enumerar /sbin/nologinen /etc/shells. El efecto estándar de /etc/shellses enumerar los programas permitidos para su uso chshcuando los usuarios están cambiando su propio shell (y no hay ninguna razón creíble para cambiar su propio shell /sbin/nologin). El superusuario puede cambiar el caparazón de cualquier persona a cualquier cosa. Sin embargo, es posible que desee enumerar ambos /sbin/nologiny /bin/falseen /etc/rsh, lo que prohibirá a los usuarios con estos shells cambiar su shell utilizando chshen el desafortunado caso de que obtengan un shell.

Los demonios FTP pueden impedir el acceso a usuarios con un shell que no esté en / etc / shells, o pueden usar cualquier otra lógica que deseen. En cualquier caso, debe evitarse ejecutar FTP porque sftp(que proporciona una funcionalidad similar) es similar pero seguro. Algunos sitios usan /sbin/nologinpara deshabilitar el acceso de shell mientras permiten el acceso sftp al ponerlo /etc/shells. Esto puede abrir una puerta trasera si el usuario puede crear cronjobs.

En cualquier caso, scpno funcionará con un shell no válido. scponlyse puede usar como shell en esta instancia.

Además, la elección de shell afecta el funcionamiento de su -(AKA su -l). Particularmente, la salida de /sbin/nologinse imprimirá en stdout si es el shell; este no puede ser el caso con /bin/false. En cualquier caso, los comandos ejecutados con su -clfallarán.

Finalmente, la respuesta:

Para deshabilitar una cuenta, no dependa de ninguno de estos, pero configure el shell /sbin/nologinpara fines informativos (a menos que /sbin/nologinesté en /etc/shells, en qué punto debe usar /bin/false, que no debería estar). En su lugar, establecer el campo de contraseña en /etc/passwda !, que está garantizada por cryptser válida para ninguna contraseña. Considere configurar el hash de /etc/shadowla misma manera para evitar errores. passwd -lHará esto por ti.

Una tercera forma de deshabilitar una cuenta es establecer el campo de fecha de vencimiento de la cuenta en una fecha antigua (p. Ej. usermod --expiredate 1). Esto evitará inicios de sesión en caso de que su configuración permita a los usuarios autenticarse en su cuenta de Unix sin una contraseña y el servicio que están utilizando no requiere shell.

Después de investigar un poco sobre esto, el método que use dependerá de lo que tenga que bloquear. Si un usuario inicia sesión con este conjunto en el shell, recibirá un mensaje en el sentido de This account is currently unavailable.Tenga en cuenta que puede cambiar esto creando el archivo /etc/nologin.txtal menos en derivados RHEL.

Como sabes /bin/falseno es una concha. La forma en que funciona es que devuelve falso, que cierra la sesión inmediatamente después de las salidas binarias. Tenga en cuenta que /bin/truelograría el mismo efecto.

Respecto a su pregunta FTP: Sí, estás en lo correcto en que el tener la cáscara se establece en /sbin/nologinque permitirá a los usuarios acceder a FTP, mientras que /bin/falseo /bin/trueva a impedir por completo que el usuario inicie sesión en cualquier servicio.

Por lo tanto, /bin/falseo /bin/truees mejor evitar que un usuario inicie sesión en cualquier servicio, mientras /sbin/nologinque aún permitirá que los usuarios inicien sesión en servicios que no sean SSH o la consola local, al mismo tiempo que le informa al usuario que la cuenta está inactiva y se utiliza mejor cuando solo SSH / local La consola debe estar bloqueada.

¿Alguien intentó probar que / bin / false no permitiría el acceso a FTP?

Acabo de cambiar el shell de mi usuario a / bin / false, y pude FTP muy bien.

Utilizo / dev / null para bloquear completamente al usuario (bueno, excepto el correo electrónico, todavía pueden POP3).