Cómo Resolver Problemas de Permisos SFTP en Amazon Linux 2023: Configuración y Seguridad

En este artículo, exploramos cómo resolver los problemas de permisos predeterminados para usuarios SFTP en servidores Amazon Linux 2023, donde los archivos subidos reciben permisos 600.

Cómo Resolver Problemas de Permisos SFTP en Amazon Linux 2023: Configuración y Seguridad

Los servidores SFTP todavía son utilizados por algunos proveedores, al menos en los sistemas que implementamos, pero estos servidores funcionaban con antiguas imágenes de EC2 basadas en CentOS. Recientemente, AWS nos informó de que debíamos actualizar a Amazon Linux 2023, ya que dejarían de recibir soporte.

Durante el proceso de migración, descubrimos algunas configuraciones que no habíamos considerado anteriormente. Una de ellas era la necesidad de habilitar conexiones a través de un puerto diferente para SFTP. Además, nos dimos cuenta de que todos los usuarios que se conectaban por SFTP contaban con permisos 600 para subir o crear archivos, lo que impedía que los usuarios locales pudieran leerlos. Veamos cómo solucionamos el problema con el puerto 2112. Esta fue una solución muy sencilla, pero me tomó tiempo llegar a ella.

Habilitar conexiones SFTP a través del puerto 2112

Hace tiempo, incorporé en mi script la funcionalidad para modificar el archivo /etc/ssh/sshd_config. Este script localiza la línea #Subsystem sftp internal-sftp, la descomenta y añade un nuevo puerto al encontrar la configuración de Port 22. Luego, reinicia el servicio sshd para que los cambios surtan efecto.

sed -i "/#Subsystem sftp internal-sftp -l VERBOSE/c Subsystem sftp internal-sftp" /etc/ssh/sshd_config
sed -i "/Port 22/c Port 22\nPort 2112" /etc/ssh/sshd_config
semanage port -a -t ssh_port_t -p tcp 2112
systemctl restart sshd

Sin embargo, esto no estaba dando resultados. Tras revisar los grupos de seguridad y las conexiones entre los servidores, y sin encontrar inconvenientes, decidimos investigar en uno de los clientes conectados para verificar si el firewall permitía las conexiones. A pesar de ello, telnet sftp-server.url 2112 seguía sin funcionar.

Al seguir revisando, noté que el firewall de Amazon Linux 2023 estaba activado. Por ello, añadí los siguientes comandos, que permiten las conexiones a través de ese puerto:

firewall-cmd --permanent --add-port=2112/tcp
firewall-cmd --reload

En esencia, así fue como se resolvió el problema de conectividad.

Cambiar los permisos de 600 a 644

Cuando un usuario SFTP carga un archivo a un servidor con Amazon Linux 2023, el sistema asigna, de forma predeterminada, permisos 600 a esos archivos. Estos permisos indican:

  • Los permisos 600 significan que solo el propietario del archivo tiene permisos de lectura y escritura.

    • El propietario puede leer y escribir el archivo.

    • El grupo y los demás usuarios no tienen ningún tipo de acceso al archivo.

¿Por qué Amazon Linux usa 600 por defecto?

La principal razón detrás de este comportamiento es la seguridad. Los servidores SFTP se utilizan comúnmente para transferir datos sensibles o privados entre el cliente y el servidor. Establecer permisos restrictivos es fundamental para evitar que otros usuarios del sistema accedan, modifiquen o incluso lean archivos que no les corresponden.

Cómo funciona: umask y la creación de archivos

El comportamiento de los permisos predeterminados está vinculado a un valor conocido como umask. La umask determina qué permisos se eliminan automáticamente al momento de crear un archivo.

En numerosos sistemas Linux, la configuración de umask predeterminada es 0022, lo que permite que los archivos se generen con permisos 644, concediendo lectura a todos, pero restringiendo la escritura únicamente al propietario. No obstante, en el caso de SFTP en Amazon Linux 2023, se implementa una umask más restrictiva o personalizada dentro del servicio SSH, lo que provoca que las transferencias de archivos por SFTP tengan permisos 600.

Configuración y personalización de los permisos SFTP

Si es necesario cambiar estos permisos predeterminados, existen diversas formas de hacerlo. Sin embargo, es fundamental considerar que alterar configuraciones globales puede impactar la seguridad del sistema.

  1. Modificar el archivo sshd_config:

    • En el archivo /etc/ssh/sshd_config, donde se descomentó el subsistema SFTP (Subsystem sftp internal-sftp), es posible establecer reglas específicas:

      Subsystem sftp internal-sftp -m 644

      o

      Subsystem sftp internal-sftp -u 0022

      Es importante saber que hacerlo de este modo afectaría globalmente a todos los usuarios de SFTP.

  2. Usar umask para controlar permisos:

    • La umask se puede ajustar para usuarios específicos o en scripts de inicio de sesión, como ~/.bashrc o ~/.bash_profile. Sin embargo, es importante tener en cuenta que en el caso de SFTP, estos archivos no siempre son leídos durante la sesión.

  3. Control mediante authorized_keys:

    • Para aquellos usuarios que emplean llaves SSH, es posible forzar la ejecución de comandos personalizados que establezcan la configuración de umask al iniciar sesión en SFTP.

Para resolver el problema, añadí la línea command="umask 0022; /usr/libexec/openssh/sftp-server", seguida de la clave ssh-rsa AAAA..., en el archivo /home/${USER}/.ssh/authorized_keys. Esto lo hice para cada uno de los usuarios y las claves necesarios.

Fue bastante fácil, ya que contaba con una lista de usuarios que se recorría al iniciar el servidor y las claves se encontraban en AWS Secrets Manager.

users='[
{
"name": "user1",
"group": "1004",
"keys": "public_key1 public_key2 public_key3 public_key4",
"directories": "/External/BI/dir1 /External/BI/dir2
},
{
"name": "user2",
"group": "1008",
"keys": "public_key",
"directories": "/External/dir"
},
{
"name": "user3",
"group": "1006",
"keys": "public_key public_key2 public_key3 public_key4 public_key5 public_key6",
"directories": "/External/BI/dir1 /External/BI/dir2"
},
{
"name": "user4",
"group": "1005",
"keys": "public_key1 public_key2 public_key3 public_key4 public_key5",
"directories": "/External/BI/dir1 /External/BI/dir2"
},
]'
for row in $(echo "$${users}" | /usr/local/bin/jq -r '.[] | @base64'); do
_jq() {
echo $row | base64 --decode | /usr/local/bin/jq -r $${1}
}
group=$(_jq '.group')
user=$(_jq '.name')
if [ $(id -u) -eq 0 ]; then
egrep "^$user" /etc/passwd >/dev/null
if [ $? -eq 0 ]; then
echo "$user exists"
else
echo "Adding user: $user"
home="/home/$${user}"
groupadd -g $group $user
useradd -m -d $${home} -u $group -g $user $user
PASSWORD=$(/usr/bin/aws secretsmanager get-secret-value --secret-id /app-server/$${APP_ENV}/sftp/$${user} --region $${REGION} --query 'SecretString' --output text | /usr/local/bin/jq -r '."password"')
for key in $(_jq '.keys');do
PUBLIC_KEY=$(/usr/bin/aws secretsmanager get-secret-value --secret-id /app-server/$${APP_ENV}/sftp/$${user} --region $${REGION} --query 'SecretString' --output text | /usr/local/bin/jq -r '.'$${key}'')
if [[ ! -d "$${home}/.ssh/" ]]; then
mkdir -p "$${home}/.ssh/"
chmod 750 $${home}/.ssh
fi
if [ ! -f "$${home}/.ssh/authorized_keys" ]
then
if [[ -n $PUBLIC_KEY ]]; then
echo "command=\"umask 0022; /usr/libexec/openssh/sftp-server\" $PUBLIC_KEY" > $${home}/.ssh/authorized_keys
fi
else
if [[ -n $PUBLIC_KEY ]]; then
echo "command=\"umask 0022; /usr/libexec/openssh/sftp-server\" $PUBLIC_KEY" >> $${home}/.ssh/authorized_keys
fi
fi
done
chmod 600 $${home}/.ssh/authorized_keys
chown -R $user:$user $${home}
for directory in $(_jq '.directories'); do
if [ ! -d "$${directory}" ]
then
mkdir -p "$${directory}"
chown $user:$user $${directory}
fi
chmod 775 $${directory}
done
usermod -a -G app-user $user
fi
else
echo "Only root may add a user to the system"
exit 2
fi
done

Conclusión

En Amazon Linux 2023, los permisos predeterminados de 600 para usuarios SFTP son una medida de seguridad que protege los archivos recién subidos al evitar que otros usuarios tengan acceso a ellos. Si bien esto refuerza la privacidad y la seguridad, es posible personalizar estos permisos utilizando configuraciones avanzadas como umask, o mediante scripts y ajustes en las sesiones SFTP. Al implementar estas configuraciones, es importante considerar el equilibrio entre seguridad y funcionalidad para mantener un entorno seguro y eficiente.

Comparte este artículo

Sigue leyendo

Artículos relacionados

AWS

Novedades de AWS, Azure, GCP y OCI — 15 al 20 de septiembre de 2026

Descubre las novedades de AWS, Azure, Google Cloud y OCI del 15 al 20 de septiembre de 2026: Kubernetes, bases de datos, observabilidad, seguridad y networking.

AWS

Novedades de AWS, Azure, GCP y OCI — 8 al 14 de septiembre de 2026

Las novedades más importantes de AWS, Azure, Google Cloud y OCI del 8 al 14 de septiembre de 2026: troubleshooting, networking, serverless, seguridad, Kubernetes, observabilidad y disaster recovery.

AWS

Novedades de AWS, Azure, GCP y OCI — 1 al 7 de septiembre de 2026

Las novedades más importantes de AWS, Azure, Google Cloud y OCI del 1 al 7 de septiembre de 2026: Linux, serverless, bases de datos, networking, observabilidad y seguridad.

Comentarios