¿Es posible otorgar a los usuarios acceso sftp sin acceso de shell? En caso afirmativo, ¿cómo se implementa?

29

Tengo una gran variedad de usuarios que solo necesitan subir archivos a sus homedirs establecidos. Creo que sftp sería suficiente, pero no quiero que inicien sesión a través de shell. Entonces, ¿es posible? Mi plataforma es centos 7, los homedires del usuario están almacenados, digamos / personal / $ user

Creé un usuario con esta configuración

useradd -m -d /personal/user1 -s /sbin/nologin

asignado al usuario una contraseña, luego, cuando uso sftp para iniciar sesión en la máquina, dice que no se puede conectar.

sftp nologin Sollosa
fuente
scponly github.com/scponly/scponly/wiki chroot opcional
usuario2497
1
duplicado de serverfault.com/questions/354615/allow-sftp-but-disallow-ssh
Tom

Respuestas:

11

Edite su /etc/ssh/sshd_configpara contener:

Match User [SFTP user]
ForceCommand internal-sftp

Reiniciar sshd. Si tiene varios usuarios, póngalos todos en la línea de usuario del partido separados por comas de esta manera:

Match User User1,User2,User3

La clave para configurar sftppara no permitir el acceso de shell es limitar a los usuarios a través de la ForceCommand opción.

kemotep
fuente
Ok me siga todos los pasos pero no ingrese
Sollosa
2
@Sollosa Pruébalo Match User [SFTP user] ForceCommand internal-sftpsolo, sin hacer chrooting.
Martin Prikryl
@MartinPrikryl funcionó Martin, gracias, acabo de eliminar el parámetro chrootdirectory y viola
Sollosa
1
Además de eso, puede chrootlos usuarios para que no puedan navegar hacia arriba y fuera de su "cárcel" definida
Ivanivan
37

Me gusta la siguiente configuración para administrar el acceso SSH, que uso en el trabajo para administrar un grupo de usuarios en una pequeña flota de servidores. La seguridad y la facilidad de administración ocupan un lugar destacado en la lista de mis prioridades.

Sus características clave son administrar fácilmente los derechos SSH a través de la membresía de grupo Unix, tener permisos bien definidos y ser seguros de forma predeterminada.

Configuración

Instalar software (opcional pero útil):

yum install members   # or apt install members

Agregar grupos:

addgroup --system allowssh
addgroup --system sftponly

En /etc/ssh/sshd_config, asegúrese de que la siguiente configuración sea No:

PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no

Y al final de /etc/ssh/sshd_config, agregue estas dos estrofas:

Match Group allowssh
    PubkeyAuthentication yes

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

(no olvide reiniciar SSH después de editar el archivo)

Explicación

Entonces, ¿qué hace todo esto?

  • Siempre deshabilita los inicios de sesión de raíz, como medida de seguridad adicional.
  • Siempre deshabilita los inicios de sesión basados ​​en contraseña (las contraseñas débiles son un gran riesgo para los servidores que ejecutan sshd).
  • Solo permite el inicio de sesión (pubkey) para los usuarios del allowsshgrupo.
  • Los usuarios del sftponlygrupo no pueden obtener un shell a través de SSH, solo SFTP.

La administración de quién tiene acceso se realiza simplemente administrando la membresía del grupo (estos cambios entran en vigencia inmediatamente, no se requiere reiniciar SSH):

# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#

Tenga en cuenta que los usuarios de sftp deben ser miembros de ambos sftponly(para asegurarse de que no obtendrán un shell) y de allowssh(para permitir el inicio de sesión en primer lugar).

Más información

  1. Tenga en cuenta que esta configuración no permite inicios de sesión de contraseña ; Todas las cuentas deben usar la autenticación de clave pública. Esta es probablemente la mayor ganancia de seguridad que puede obtener con SSH, por lo que creo que vale la pena el esfuerzo, incluso si tiene que comenzar ahora.

    Si realmente no quieres esto, agrega también PasswordAuthentication yesa la Match Group allowsshestrofa. Esto permitirá la autenticación de clave pública y contraseña para los allowsshusuarios.

  2. Esta configuración limita a cualquier sftponlyusuario a su directorio de inicio. Si no quiere eso, elimine la ChrootDirectory %hdirectiva.

    Si no desea que el cambiar la raíz de trabajo, es importante que el directorio personal del usuario (y cualquier directorio por encima de ella) es propiedad de root:rooty no puede ser escrito por grupo / otros. Está bien que los subdirectorios del directorio de inicio sean propiedad del usuario y / o se puedan escribir.

    Sí, el directorio de inicio del usuario debe ser propiedad de la raíz y no debe poder escribirse para el usuario. Lamentablemente, hay buenas razones para esta limitación. Dependiendo de su situación, ChrootDirectory /homepodría ser una buena alternativa.

  3. Configurar el shell de los sftponlyusuarios /sbin/nologinno es necesario ni perjudicial para esta solución, ya que SSH ForceCommand internal-sftpanula el shell del usuario.

    Sin /sbin/nologinembargo, el uso puede ser útil para evitar que inicien sesión de otras maneras (consola física, samba, etc.).

  4. Esta configuración no permite rootinicios de sesión directos a través de SSH; Esto forma una capa adicional de seguridad. Si realmente no necesita conexiones de root directos, cambiar la PermitRootLogindirectiva. Considere configurarlo en forced-commands-only, prohibit-passwordy (como último recurso) yes.

  5. Para obtener puntos de bonificación, eche un vistazo a restringir quién puede surootear; añadir un grupo sistema llamado wheel, y añadir / activar auth required pam_wheel.soen /etc/pam.d/su.

marcelm
fuente
2
Esta debería ser la respuesta aceptada. Proporciona la solución y desglosa el razonamiento detrás de cada paso.
kemotep
1
Esta es una respuesta realmente excelente con excelentes consejos de seguridad adicionales, pero me preocupo por aquellos usuarios cuyos sistemas dependen de inicios de sesión de contraseña, inicios de sesión de raíz, etc. Por supuesto, hacerlo no es bueno, pero tal vez mover los cambios relacionados con la mejora de seguridad general a sus propia sección para que una respuesta a la pregunta con cambios mínimos esté disponible?
Josh Rumbut
1
@JoshRumbut No quería volver a escribir la respuesta para sus comentarios (muy correctos), en parte porque en realidad solo muestra My Way ™, y en parte con la esperanza de que pueda ser una especie de configuración SSH canónica de seguridad por defecto ejemplo que mucha más gente encuentra útil. Como compromiso, traté de
aclarar
1
Buena respuesta, en mi opinión, las mayores deficiencias de las otras respuestas no fueron tener en cuenta los aspectos de seguridad, principalmente chroot. +1
Rui F Ribeiro
1
Chroot no funcionará para un genérico% h. Sorprendentemente, se requiere chown root:rootychmod og-w
kubanczyk
1

simplemente cambie su shell predeterminado a / sbin / nologin. Asumiendo la mayoría de las variedades de Linux:

# usermod -s /sbin/nologin username
Kefka
fuente
Lo he intentado, pero el usuario no puede iniciar sesión a través de sftp, no sé por qué. Estoy usando centos por cierto.
Sollosa
@Sollosa Probablemente, ya sea un problema de permiso en su chroot sftp o sshd_config tiene un problema. Debe actualizar su pregunta para incluir los permisos de su directorio chroot y su sshd_config con cualquier información confidencial eliminada.
Kefka
Creo (aunque no puedo probarlo ahora) que esto permite SFTP solo si también hay Subsystem sftp internal-sftp) (o tal vez ForceCommand internal-sftp). Si hay algo común Subsystem sftp /path/to/sftp-server, nologinevitará incluso SFTP.
Martin Prikryl
@MartinPrikryl Entendí mal su pregunta original sin editar de preguntar cómo deshabilitar el acceso de shell para los usuarios en un servidor sftp que de otro modo sería funcional. Había estado despierto durante unos diez minutos en ese momento, así que no estaba tan lúcido como podría haberme sentido. Aunque no sabía que el servidor sftp requiere que un usuario tenga un shell válido para funcionar, eso parece potencialmente peligroso. Solo uso internal-sftp solo por costumbre porque así es como siempre lo he hecho.
Kefka
Vea mi respuesta a OpenSSH: Diferencia entre internal-sftp y sftp-server (particularmente la sección al final)
Martin Prikryl
0

puedes usar tftp. cualquier cosa sobre ssh requerirá alguna autenticación (clave | paso).

Si bien tftp se puede asegurar, puede valer la pena revisar la decisión de proporcionar acceso a cualquier cosa sin autenticación.

http://manpages.ubuntu.com/manpages/bionic/man1/tftp.1.html

Justin
fuente
2
Creo que OP quería que los usuarios (que presumiblemente tienen nombres de usuario y contraseñas) no puedan usar un cliente SSH normal para conectarse al servidor y ejecutar comandos arbitrarios, pero esos mismos usuarios pueden cargar archivos a través de SFTP.
John_ReinstateMonica