Archivos SFTP en Plesk con permisos 0600 en lugar de 0644: cómo arreglarlo

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

  1. Editar la configuración de sshd como root:
nano /etc/ssh/sshd_config
  1. 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
  1. 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
  1. Guardar y reiniciar el servicio SSH:
systemctl restart sshd
  1. 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 reinicia sshd.
  • 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 en sshd_config.
    • Forzar internal-sftp -u 022 en versiones modernas.
  • 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.

Suscríbete al boletín SysAdmin

Este es tu recurso para las últimas noticias y consejos sobre administración de sistemas, Linux, Windows, cloud computing, seguridad de la nube, etc. Lo enviamos 2 días a la semana.

¡Apúntate a nuestro newsletter!


– patrocinadores –

Noticias destacadas

– patrocinadores –

¡SUSCRÍBETE AL BOLETÍN
DE LOS SYSADMINS!

Scroll al inicio
×