Deshabilitar shell de usuario por razones de seguridad


58

Tenemos varias cuentas de usuario que creamos para tareas automatizadas que requieren permisos específicos, como la transferencia de archivos a través de sistemas, monitoreo, etc.

¿Cómo bloqueamos estas cuentas de usuario para que estos "usuarios" no tengan shell y no puedan iniciar sesión? Queremos evitar la posibilidad de que alguien pueda ingresar a SSH como una de estas cuentas de usuario.

Respuestas:


63

Puede usar el usermodcomando para cambiar el shell de inicio de sesión de un usuario.

usermod -s /sbin/nologin myuser

o

usermod -s /usr/sbin/nologin myuser

Si su sistema operativo no proporciona / sbin / nologin, puede configurar el shell en un comando NOOP como / bin / false:

usermod -s /bin/false myuser

1
/bin/falseParece más común que /bin/true.
jw013

@ jw013 Actualizo mi respuesta, pero ambas deberían funcionar bien.
jordanm

1
Tenga en cuenta que en Debians, nologinen realidad se encuentra en/usr/sbin/nologin
Xebeche

Esta fue mi primera idea, desafortunadamente el uso "válido" de algunas cuentas de usuario se deshabilita cuando se configuranologin
Javier

2
@ jw013 En realidad tengo /usr/local/bin/maybecuál /dev/urandomly selecciona entre esos dos. Tal vez debería usarlo: D
hegez

21

Cambiar el shell de inicio de sesión no necesariamente impide que los usuarios se autentiquen (excepto en algunos servicios que verifican si se menciona el shell del usuario /etc/shells).

Es posible que las personas aún puedan autenticarse en los diversos servicios que su sistema proporciona a los usuarios de Unix, y aún pueden estar autorizados para realizar algunas acciones, aunque probablemente no ejecuten comandos arbitrarios directamente.

Cambiar el shell /bin/falseo /usr/sbin/nologinsolo evitará que ejecuten comandos en aquellos servicios que se pueden usar para ejecutar comandos (inicio de sesión de consola, ssh, telnet, rlogin, rexec ...), por lo que afectan la autorización solo para algunos servicios.

Por sshejemplo, eso todavía les permite hacer reenvío de puertos.

passwd -ldeshabilitará la autenticación de contraseña, pero el usuario aún puede usar otros métodos de autenticación (como authorized_keyscon ssh).

Con pamen Linux, al menos, se puede utilizar el pam_shellsmódulo para restringir la autenticación o autorización a los usuarios con una cáscara permitido (los mencionados en /etc/shells). Para ssh, querrá hacerlo a nivel de autorización ( account) en cuanto a los sshdusos de autenticación pam además de otros métodos de autenticación (como authorized_keys), o puede hacerlo con sshd_configdirectivas en /etc/ssh/sshd_config(como AllowUsersy amigos).

Sin embargo, tenga en cuenta que agregar algunas restricciones en la autorización global de pam evitará potencialmente ejecutar crontrabajos como esos usuarios.


Gracias. Entonces, ¿qué recomendaría dado el siguiente esquema: Necesito crear un usuario que necesite acceso a su carpeta de inicio a través de sftp o sshfs, pero no debe poder iniciar sesión con un shell. ¿Es eso posible? Me sentí como si los módulos PAM fueran la solución de ir a Goto, pero no lo entiendo todo:|
Stphane

@Stphane puedes echar un vistazo a rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
Hart Simha

4

Edita el /etc/passwdarchivo y cambia el shell de usuarios desde /bin/basho /bin/shhacia/sbin/nologin


8
La respuesta es correcta, pero nunca se debe recomendar la edición manual / etc / passwd.
jordanm

3
¿Por qué? Esto es algo que hemos estado haciendo durante el tiempo que he sido un administrador de sistemas profesional. (hace aproximadamente 20 años) De hecho, no todas las distribuciones de Linux / Unix tienen herramientas para modificar / etc / passwd o / etc / group ... A menos que use algo como Yast o Smit, que son herramientas que almacenan en caché la configuración y sobreescriben ellos no hay daño en la edición manual.
Mark Cohen el

66
Es mucho más fácil cometer un error de "interrumpe el inicio de sesión de todos" mediante la edición manual, en lugar de un solo usuario.
jordanm

2
@jordanm: existe lo vipwque evita ese tipo de error.
eudoxos

4

Primero, deshabilite la contraseña, usando passwd -l username.

También tenga en cuenta en la manpágina passwdpara la opción -l:

   -l, --lock
       Lock the password of the named account. This option disables a password by changing it to a value which matches no
       possible encrypted value (it adds a ´!´ at the beginning of the password).

       Note that this does not disable the account. The user may still be able to login using another authentication token
       (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
       expire date to Jan 2, 1970).

       Users with a locked password are not allowed to change their password.

1
Esto puede no ser deseable. Es posible que necesiten una contraseña en su cuenta del sistema para acceder al correo electrónico, por ejemplo.
jordanm

1
Algunos sistemas de correo electrónico permiten el uso de sus propios mecanismos de contraseña. Yo uso Dovecot y Exim con una contraseña de correo electrónico solamente. Esto permite el uso de correo web en servidores. No usaría la contraseña de mi sistema. Los dominios de correo electrónico virtuales requieren su propia contraseña, ya que no están acoplados al sistema de contraseña del servidor.
BillThor

2

Puedes usar el comando chsh:

~# chsh myuser

Ingrese nuevos detalles de shell cuando se le solicite:

Login Shell [/bin/sh]: /bin/nologin

O versión más corta:

~# chsh myuser -s /bin/nologin

0

Para evitar que el usuario inicie sesión e incluso la autenticación a través de ssh que permite el reenvío de puertos (como se describe aquí, Stephane), modifico el usuario para que sea similar al nobodyusuario del sistema :

  • autenticación de contraseña bloqueada en /etc/shadow(con *o !!en el campo apropiado)
  • shell deshabilitado en /etc/passwd(por ejemplo, /sbin/nologinen el campo adecuado)
  • directorio de inicio de solo lectura en /etc/passwd(por ejemplo, /en el campo adecuado)
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.