El problema
En servidores modernos (sobre todo basados en RHEL8/CentOS8 y derivados), los archivos subidos vía SFTP/SSH por usuarios de Plesk aparecen con permisos 0600 (solo lectura/escritura para el propietario). Esto provoca que Apache/nginx no puedan leerlos, dando errores 403 Forbidden.
La causa principal es que desde estas versiones de sistema, el valor por defecto del umask en sshd es 0077, lo que restringe los permisos. Por el contrario, cuando subes archivos por FTP tradicional, sí se aplican los permisos estándar porque el umask es diferente.
Solución definitiva: ajustar el umask para SFTP
- Editar la configuración de sshd como root:
nano /etc/ssh/sshd_config
- Localizar la línea que define el subsistema SFTP. Puede variar según la distro:
- En RHEL/CentOS/Alma/Rocky:
Subsystem sftp /usr/libexec/openssh/sftp-server
- En Debian/Ubuntu:
Subsystem sftp /usr/lib/openssh/sftp-server
- Añadir la opción -u 022 para forzar umask 022 (archivos 0644, directorios 0755):
Subsystem sftp /usr/libexec/openssh/sftp-server -u 022
o
Subsystem sftp /usr/lib/openssh/sftp-server -u 022
- Guardar y reiniciar el servicio SSH:
systemctl restart sshd
- Probar subiendo un archivo nuevo por SFTP. Ahora debería aparecer automáticamente con 0644.
⚠️ Nota: el flag -u solo está disponible en versiones recientes de OpenSSH. Compruébalo con:
man sftp-server | grep -A3 "\-u"
Lenguaje del código: JavaScript (javascript)
Alternativas si tu versión no soporta -u
- Ajustar umask global en /etc/login.defs
Edita/etc/login.defs
y busca la línea:UMASK 077
cámbiala a:UMASK 022
Reinicia sesión y prueba. Esto afecta a nuevas sesiones SSH en general. - Bloques Match en sshd_config
Puedes definir umask diferente para un grupo de usuarios o directorios:Match Group psacln
ForceCommand internal-sftp -u 022
⚠️ Requiere probar bien porque puede afectar a usuarios Plesk. - Usar ForceCommand con internal-sftp en versiones modernas de OpenSSH
Desde OpenSSH >8.2 se puede usar directamente:ForceCommand internal-sftp -u 022
Alternativas prácticas si lo anterior falla
- Modificar login.defs: fija
UMASK 022
y reiniciasshd
. - Script cron para reparar permisos en
httpdocs/
:find /var/www/vhosts/DOMINIO/httpdocs -type f -exec chmod 0644 {} \;
find /var/www/vhosts/DOMINIO/httpdocs -type d -exec chmod 0755 {} \;
- Hook de Plesk o script post-upload si usas despliegues automatizados (Git o SFTP).
- Aplicar
chmod
tras cada subida desde el cliente SFTP o mediante automatización en el propio cliente.
Alternativa rápida: cambiar permisos después de subir
- Desde el cliente SFTP:
chmod 644 archivo.html
- Crear un script automático post-upload (por ejemplo, con
lftp
o hooks de despliegue). - Usar el administrador de archivos de Plesk para ajustar permisos manualmente.
Esto soluciona el problema puntual, pero no de raíz.
Resumen
- El origen del problema es el umask por defecto en OpenSSH (0077).
- La solución más limpia es modificar la línea
Subsystem sftp
en/etc/ssh/sshd_config
añadiendo-u 022
y reiniciar SSH. - Si tu versión no soporta la opción
-u
, puedes:- Ajustar
UMASK
en/etc/login.defs
. - Usar bloques
Match
ensshd_config
. - Forzar
internal-sftp -u 022
en versiones modernas.
- Ajustar
- Como plan B, puedes recurrir a un script cron que repare permisos, hooks de Plesk o cambiar permisos manualmente.
- Con cualquiera de estas medidas, los archivos subidos vía SFTP deberían quedar en 0644 y ser legibles por el servidor web, evitando errores 403.