☰

OpenSSH - sshd_config - Permitir sftp-chroot Y inicio de sesión ssh normal con el mismo usuario

tag-icon • tag-icon ssh sftp
OpenSSH - sshd_config - Permitir sftp-chroot Y inicio de sesión ssh normal con el mismo usuario

Con suerte, no es una duplicación, pero no puedo encontrar una respuesta a esta... Encontré esto, que en la superficie parece ser el mismo, pero es muy antiguo y la única respuesta que contiene no responde a la pregunta real: Configure los usuarios como chroot para sftp, pero permita que los usuarios inicien sesión en SSH

He configurado con éxito un entorno ChrootDirectory que funcione a través de sftp para los usuarios del grupo 'sftp_users'. Funciona bien, todos los permisos adecuados y demás, restringiendo el acceso solo a sftp, y pueden rw en su(s) subdirectorio(s) dentro de ChrootDirectory. Esto es excelente para usuarios sin privilegios, ya que no permite el acceso ssh y solo permite rw dentro de sus subcarpetas dentro de ChrootDirectory.

Me gustaría tener usuarios un poco más privilegiados que aún puedan usar ssh normalmente; sin embargo, al iniciar sesión a través de sftp tendré el entorno ChrootDirectory. Esto es un problema menor de seguridad, ya que se consideran privilegiados y obviamente pueden navegar por el sistema de archivos en ssh dentro de sus permisos de usuario normales. El problema es que no veo una manera de hacer Chroot cuando inician sesión en sftp sin impedir el inicio de sesión ssh. Esto es más por estandarización y conveniencia que cualquier otra cosa, por lo que cuando usan sftp simplemente llegan a su ubicación Chrooted como los usuarios que solo usan sftp.

Pensé que esto funcionaría si dejaba su shell como predeterminado (no /bin/false o nologin). Desafortunadamente, cuando están en el grupo sftp_only, no les permitirá ingresar a través de ssh, solo sftp. ¿Existe alguna solución para esto, además de tener dos cuentas separadas: una agregada a 'sftp_users' y otra que no está en ese grupo? Hasta ahora, todo lo que puedo encontrar es documentación sobre cómo restringir sftp Chroot y simultáneamente no permitir ssh si están en ese grupo.

El usuario de ejemplo es 'prueba'. 'test' está en el grupo sftp_users y, por lo tanto, puede iniciar sesión a través de sftp y acceder a su carpeta especificada ('/sftp/test') y leer o escribir en su carpeta de inicio montada en '/sftp/test/home'. . Todo esto funciona. Pero incluso si su shell todavía está configurado en /etc/passwd a /bin/bash, 'test' no puede iniciar sesión a través de ssh si se agrega al grupo sftp_users. Elimine la membresía en ese grupo y podrá hacer ambas cosas, pero luego no podrá hacer Chroot en sftp.

Los usuarios que no están en el grupo 'sftp_users' aún pueden iniciar sesión a través de ssh o sftp, pero no reciben Chroot en sftp.

¿Hay alguna manera de hacer coincidir qué protocolo se utiliza y/o tal vez establecer una coincidencia adicional para un grupo diferente? Solo busco el chroot cuando inician sesión a través de sftp. La opción no chroot a través de ssh está bien para estos usuarios.

A continuación se muestra mi sshd_config:

Port XXXX
#ListenAddress ::
#ListenAddress 0.0.0.0

Protocol 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin no
StrictModes yes

PubkeyAuthentication yes

IgnoreRhosts yes
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes

ClientAliveCountMax 10
ClientAliveInterval 3600
TCPKeepAlive no

#Banner /etc/issue.net

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server -u 0027

UsePAM yes
PasswordAuthentication yes



Match Group sftp_users
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp -u 0027
  X11Forwarding no
  AllowTcpForwarding no
  PasswordAuthentication yes

Respuesta1

OpenSSH no admite la anulación de palabras clave globales según el comando enviado. Debe diferenciar según algunos (combinación de) criterios que ofrece OpenSSH para la Matchdeclaración.

Los criterios disponibles son Usuario, Grupo, Host, Dirección Local, Puerto Local, Dominio R y Dirección (donde RDomain representa el rdomain(4) en el que se recibió la conexión).

-- hombre 5 sshd_config

Una opción común es ofrecer servicios restringidos intencionalmente en direcciones IP alternativas a las que se llega a través de dominios alternativos, como snapshot.backup.exampley sftp.backup.example.

Los comentarios sobre elpregunta vinculadaSin embargo, explica claramente el problema.

Si crees quedesearacceso sftp chroot para usuarios privilegiados, es probable que esté manipulando diferentesrolesen idénticousuarios, y eso está generando riesgos de seguridad. En la mayoría de los casos, las preocupaciones sobre auditoría y separación de privilegios se solucionan mejor medianteusando un usuario diferentepor lo que sea que te haya hecho considerar configurar la configuración de chroot incluso para usuarios que no están limitados por eso. Si hay dos tareas diferentes, incluso si son ejecutadas por el mismopersona, y uno se hace de manera más segura si se restringe intencionalmente, entonces configure un nuevo usuario del sistema (por ejemplo, tenga un usuario persony person-taskcomparta la mayoría de las restricciones y métodos de autenticación, y solo restrinja uno de ellos en ssh).

Respuesta2

También me confundió este problema, cuando configuro chroot sftp para usuarios que no pueden iniciar sesión mediante ssh. Mi escenario es ligeramente diferente, necesito proporcionar un entorno de shell limitado para los usuarios, mientras que los usuarios aún necesitan sftp y scp para acceder a su directorio de inicio para RW, así como un directorio público designado, por ejemplo, /home/public para RDONLY.

En primer lugar, desarrollé un shell encarcelado, deseaba que este shell pudiera cooperar con openssh internal-sftp para cumplir mis requisitos. Luego descubrí que fallaba porque openssh no permitirá a los usuarios iniciar sesión mediante ssh junto con el chroot internal-sftp habilitado.

Así que tuve que modificar el shell encarcelado para admitir sftp y scp encarcelados en casa. Es un poco complicado que haya usado ptrace syscalls para implementar el sftp encarcelado. Si esta información le resulta útil, puede consultar https://github.com/diggerwoo/jsh.

información relacionada