Cómo configurar ssh's umask para todo tipo de conexiones

He estado buscando una manera de configuración de OpenSSH máscara de usuario a 0027de una manera consistente a través de todos los tipos de conexión.

Por tipos de conexión me refiero a:

1. sftp
2. scp
3. nombre de host ssh
4. programa de nombre de host ssh

La diferencia entre 3. y 4. es que el primero inicia un shell que generalmente lee la /etc/profileinformación mientras que el segundo no.

Además, al leer esta publicación, me di cuenta de la opción -u que está presente en las versiones más recientes de OpenSSH. Sin embargo, esto no funciona.

También debo agregar que /etc/profileahora incluye umask 0027.

Yendo punto por punto:

• SFTP - Configuración -u 0027en sshd_configcomo se ha mencionado aquí , no es suficiente.

Si no configuro este parámetro, sftp usa de forma predeterminada umask 0022. Esto significa que si tengo los dos archivos:

-rwxrwxrwx 1 user user 0 2011-01-29 02:04 execute
-rw-rw-rw- 1 user user 0 2011-01-29 02:04 read-write

Cuando uso sftp para ponerlos en la máquina de destino, en realidad obtengo:

-rwxr-xr-x 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

Sin embargo, cuando me puse -u 0027en sshd_configla máquina de destino en realidad me sale:

-rwxr--r-- 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

lo cual no se espera, ya que en realidad debería ser:

-rwxr-x--- 1 user user 0 2011-01-29 02:04 execute
-rw-r----- 1 user user 0 2011-01-29 02:04 read-write

Alguien entiende por qué sucede esto?

• scp : independientemente de lo que está configurado para sftp , los permisos son siempre umask 0022. Actualmente no tengo idea de cómo alterar esto.

• nombre de host ssh : no hay problema aquí ya que el shell lee /etc/profilede forma predeterminada, lo que significa umask 0027en la configuración actual.

• programa de nombre de host ssh : la misma situación que scp .

En resumen, configurar umask en sftpaltera el resultado, pero no como debería, ssh hostnamefunciona como se esperaba /etc/profiley ambos, scpy ssh hostname programparece que se ha umask 0022codificado en alguna parte.

Cualquier idea sobre cualquiera de los puntos anteriores es bienvenida.

EDITAR: Me gustaría evitar parches que requieran compilar manualmente openssh. El sistema ejecuta Ubuntu Server 10.04.01 (lúcido) LTS con opensshpaquetes de Maverick.

Respuesta: Como lo indica poige, el uso de pam_umask hizo el truco.

Los cambios exactos fueron:

Líneas agregadas a /etc/pam.d/sshd:

# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session    optional     pam_umask.so umask=0027

Además, para afectar a todos los shells de inicio de sesión, independientemente de si se originan /etc/profileo no, también se agregaron las mismas líneas /etc/pam.d/login.

EDITAR : después de algunos de los comentarios volví a probar este problema.

Al menos en Ubuntu (donde probé) parece que si el usuario tiene un conjunto de umask diferente en los archivos de inicio de su shell (.bashrc, .zshrc, ...), se ignora la máscara de usuario de PAM y se usa la máscara de usuario definida en su lugar. Los cambios /etc/profileno afectaron el resultado a menos que el usuario explícitamente obtenga esos cambios en los archivos de inicio.

No está claro en este momento si este comportamiento ocurre en todas las distribuciones.

Puedo sugerir probar 2 cosas:

1. pam_umask
2. Contenedor LD_PRELOAD (¿autoescrito?)

Aquí hay una solución que le permitirá hacer lo que quiera por usuario. Utiliza solo sshdcaracterísticas nativas y no requiere mucking con parches mantenidos localmente. Esta solución aprovecha el ForceCommandcomportamiento de sshd para insertar un script de configuración del entorno en cada conexión ssh y luego ejecuta el comando original.

Primero, cree un script en algún lugar de su sistema con los siguientes contenidos:

#!/bin/sh

umask 0027
exec /bin/sh -c "${SSH_ORIGINAL_COMMAND:-$SHELL}"

A los fines de este ejemplo, supondré que lo has llamado /usr/bin/umask-wrapper.

Ahora, tiene algunas opciones para configurar esto. Si desea que esta sea una configuración obligatoria para todos los usuarios (lo que parece un poco improbable), puede modificar su configuración sshd para incluir lo siguiente:

ForceCommand /usr/bin/umask-wrapper

Si solo desea que esto se aplique a algunos usuarios, puede usar un Matchbloque (esto va al final de su sshd_config):

Match User user1,user2
ForceCommand /usr/bin/umask-wrapper

Si desea que este sea un comportamiento controlable por el usuario, puede usar la command=opción en un authorized_keyarchivo para seleccionar este comportamiento para claves específicas. Por ejemplo, al probar esto, agregué una entrada a mi authorized_keysarchivo que se parece a esto:

command="/home/lars/bin/umask-wrapper" ssh-rsa AAAAB3NzaC1 ... umask-test

Y aquí hay algunos resultados de mi prueba:

Usar sshsin comando:

localhost$ ssh remotehost
remotehost$ touch umask-test/file1
remotehost$ ls -l umask-test/file1
-rw-r-----. 1 lars lars 0 Feb  2 06:02 file1

Usando sshcon un comando:

localhost$ ssh remotehost touch umask-test/file2
localhost$ ssh remotehost ls -l umask-test/file2
-rw-r-----. 1 lars lars 0 Feb  2 06:03 file2

Utilizando scp:

localhost$ touch file3
localhost$ ls -l file3
-rw-r--r--  1 lars  staff  0 Feb  2 06:03 file3
localhost$ scp file3 remotehost:umask-test/file3
localhost$ ssh remotehost ls -l umask-test/file3
-rw-r-----. 1 lars lars 0 Feb  2 06:03 file3

Utilizando sftp:

localhost$ sftp remotehost
sftp> put file3 umask-test/file4
sftp> ls -l umask-test/file4
-rw-r-----    0 500      500             0 Feb  2 06:05 umask-test/file4

Y ahí lo tienes. Creo que este es el comportamiento que estabas buscando. Si tiene alguna pregunta sobre esta solución, me complacerá brindarle detalles adicionales.

Tomé un enfoque ligeramente diferente para centralizar la configuración.

Esto fue agregado a /etc/pam.d/common-session:

session    optional     pam_umask.so

Esto fue modificado en /etc/login.defs:

UMASK           0027

He conseguido que pam_umask funcione con ssh, pero no con scp o sftp.

El método wrapper tampoco hace nada para sftp o scp. No estoy seguro de que 027 sea un buen ejemplo, ya que la mayoría de las distribuciones ya tienen umask configurado para eso. Pruebe con 002 y vea si eso funciona.

Los programas que no configuran su propia umask heredan la umask de la aplicación que la inició. Detenga sshd por completo, configure su umask en 0027 y luego vuelva a iniciarlo. (Puede agregar el comando umask en el script de inicio para futuros reinicios).

Probado para trabajar con scp.

Si pam_umaskno parece afectar sus sesiones SFTP, verifique si UsePamestá configurado Yesen el /etc/ssh/sshd_configarchivo.

Si ha deshabilitado la autenticación de contraseña y UsePamse configuró o se configuró de manera predeterminada No. Es posible que desee configurar ChallengeResponseAuthentication Noel sshd_configarchivo porque, de lo contrario, puede habilitar inadvertidamente una autenticación de contraseña a través de ese sistema.

Una nota adicional a la respuesta del usuario188737 anterior:

Esto puede ser evidente, pero si lo que no se utiliza el openssh-server paquete, y ha manualmente compilado OpenSSH, asegúrese de que "habilitar el soporte PAM" pasando el --with-pamindicador de configuración.

De lo contrario, UsePAM=yesen sshd_config, además de cualquier cambio, /etc/pam.d/*será efectivamente ignorado por sshd.

Finalmente me di cuenta de por qué ninguna de las soluciones PAM recomendadas estaba teniendo pruebas de efecto a través de conexiones SFTP no interactivas ...

Dado que umask se hereda del proceso padre, en un sistema Slackware que usa /etc/rc.d/rc.sshdpara iniciar / detener / reiniciar sshd, simplemente puede colocarlo umask 0027en una línea directamente encima de "sshd_start" o "sshd_restart", o alternativamente, en cualquier punto antes del La sección principal de ejecución comienza en /etc/rc.d/rc.sshd:

case "$1" in
'start')
  umask 0027
  sshd_start
  ;;
'stop')
  sshd_stop
  ;;
'restart')
  umask 0027
  sshd_restart
  ;;
*)

O, alternativamente, en la parte superior del archivo:

#!/bin/sh
# Start/stop/restart the secure shell server:
umask 0027

Acabo de probar una posible mejora en las opciones de sshd_config de larsks en solaris 11

Configure un grupo con los usuarios que se administrarán y mueva el script al archivo de configuración en sí mismo, en mi caso, quería establecer la umask en 0002.

la configuración resultante se convierte en ...

Match Group managedgroup
ForceCommand /bin/sh -c 'umask 0002; ${SSH_ORIGINAL_COMMAND:-$SHELL}'

He estado luchando con este problema, específicamente con los permisos de archivo después de copiar un archivo usando scp , y finalmente se me ocurrió simplemente usar ssh para cambiar los permisos después de la copia.

Aquí está la solución:

1. Copia tu archivo: localhost$ scp filename remotehost:umask-test/filename
2. Fijar permiso: localhost$ ssh remotehost "chmod go+r umask-test/filename"

Lo mejor de todo es que no se necesita acceso de root para realizar esta solución.