☰

Configuración de sftp en Amazon Linux 2 con claves ssh, segregación de usuarios (sftp vs ssh), diferentes puertos y restricciones de directorio de usuarios

tag-icon • tag-icon amazon-ec2 sftp ssh-keys amazon-linux amazon-linux-2
Configuración de sftp en Amazon Linux 2 con claves ssh, segregación de usuarios (sftp vs ssh), diferentes puertos y restricciones de directorio de usuarios

TDLR: Tengo un problema en el que, dependiendo de los permisos en el directorio de inicio del usuario, puedo hacer que funcione la autenticación SSH o las restricciones del directorio de usuario, pero no ambas.

Por cierto, realmente quiero implementar mi propio servidor SFTP. No recomiende que pruebe el servicio AWS Transfer o alguna alternativa. Gracias.

Aquí hay contenido relevante (cambiado del predeterminado) en /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Port 22
Port 2299
Match Group sftpusers LocalPort 2299
  ChrootDirectory /sftp-data/%u
  ForceCommand internal-sftp
Match Group sftpusers LocalPort 22
  DenyGroups sftpusers
Match LocalPort 2299  Group *,!sftpusers
  DenyUsers *

Quiero que el puerto 22 funcione como normalmente lo hace ssh, pero solo para usuarios que no son ftp. Para los usuarios de sftp, en el grupo "sftpusers", quiero que el puerto 2299 funcione solo como sftp y no como ssh. Para los usuarios que no son sftpus, quiero que se les niegue el acceso al puerto 2299.

Bien, creé un usuario "usuario1" con el directorio de inicio /sftp-data/user1 y el shell /sbin/nologin. Creé /sftp-data/user1/.ssh/authorized_keys y lo completé con la clave ssh pública. /sftp-data es propiedad de root con 700 permisos. /sftp-data/user1/.ssh y siguientes son propiedad del usuario1, y /sftp-data/user1/.ssh/authorized_keys tiene el permiso 600. La propiedad/permisos de /sftp-data/user1 están bajo duda aquí. Más abajo.

Creé el grupo de usuarios sftpusers y agregué usuario1 a ese grupo. Sin embargo, el usuario ec2 integrado que obtiene con AWS no es miembro de ese grupo. Las pruebas con ec2-user funcionaron muy bien: acceso a través de ssh, el puerto 22 funcionó como siempre, pero no hubo acceso al puerto 2299.

Entonces, probar con el usuario1 es donde se volvió interesante. El usuario1 no tiene acceso al puerto 22. ¡Eso es genial! Dado que el usuario1 posee /sftp-data/user1, la autenticación de clave pública ssh se realiza correctamente en el puerto 2299, pero el usuario cierra la sesión inmediatamente y se guarda este mensaje en /var/log/secure:

Sep  2 19:21:38 ip-192-168-0-25 sshd[10369]: Accepted publickey for user1 from <ip-address redacted> port 61110 ssh2: ECDSA SHA256:<sha redacted>
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: fatal: bad ownership or modes for chroot directory "/sftp-data/user1" [postauth]
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session closed for user user1

Claro, eso tiene sentido. Chroot requiere que /sftp-data/user1 sea propiedad de root, permisos 700. Entonces, hazlo así y ahora la autenticación sftp (clave ssh) falla.

Sep  2 19:41:00 ip-192-168-0-25 sshd[11693]: error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys user1 SHA256:<sha redacted> failed, status 22

Por cierto, eic_run_authorized_keys es un contenedor que AWS utiliza para la autenticación ssh estándar para habilitar AWS Instance Connect.

Para obtener crédito adicional... si el problema anterior no es lo suficientemente desafiante, ¿puede idear un esquema en el que pueda dar acceso a determinados usuarios de sftp a directorios de proyectos concretos, y sólo a esos, sin crear un grupo para cada proyecto? Un enlace desde el directorio de inicio de cada usuario a un directorio de proyecto sería fantástico.

Información adicional solicitada por @anx:

# getent passwd user1
user1:x:1001:1001::/sftp-data/user1:/sbin/nologin
# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

Activé el registro DEBUG para sshd. Usando la directiva ChrootDirectory, con /sftp-data/user1 propiedad de root y la autenticación SSH falla, veo esto en /var/log/secure:

debug1: No se pudieron abrir las claves autorizadas '/sftp-data/user1/.ssh/authorized_keys': Permiso denegado

ps me muestra claramente que root está ejecutando el proceso sshd.

Respuesta1

Tu ChrootDirectoryes /sftp-data/user1, que debe ser propiedad de root. Y es:

# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

Sin embargo, en este punto, el sshd ya cambió el usuario a usuario1 y perdió privilegios, por lo que usuario1 no puede descender a directorios de nivel inferior. Para hacer eso, el directorio necesita permiso de búsqueda ( a+x).

chmod a+x /sftp-data/user1

Ahora el usuario1 puede descender a subdirectorios y el .sshdirectorio debería ser legible.

Respuesta2

Creo que esto es principalmente una cuestión de permisos de carpeta. Creo que eso /sftp-data/user1/.sshy los directorios a continuación deben ser propiedad de user1, pero parece que son propiedad de root. Pruebe lo siguiente como root:

Verifique que la clave pública /sftp-data/user1/.ssh/authorized_keyssea precisa. Después de eso, creo que estos son los permisos que quizás necesites cambiar:

chmod 700 /sftp-data/user1/.ssh
chmod 600 /sftp-data/user1/.ssh/authorized_keys
chown root:sftpusers /sftp-data
chown -R user1:user1 /sftp-data/user1/.ssh

Reinicie SSH y creo que estará listo.

información relacionada