Comment configurer umask de ssh pour tout type de connexion

Je cherchais un moyen de configurer umask d' OpenSSH de 0027manière cohérente pour tous les types de connexion.

Par types de connexion, je fais référence à:

1. sftp
2. scp
3. ssh nom d'hôte
4. programme ssh hostname

La différence entre 3. et 4. est que le premier démarre un shell qui lit généralement les /etc/profileinformations alors que le second ne le fait pas.

De plus, en lisant cet article, j'ai pris connaissance de l'option -u présente dans les nouvelles versions d'OpenSSH. Cependant cela ne fonctionne pas.

Je dois aussi ajouter que /etc/profilecomprend maintenant umask 0027.

Aller point par point:

• sftp - Mettre -u 0027en place sshd_configcomme mentionné ici , ne suffit pas.

Si je ne définit pas ce paramètre, sftp utilise par défaut umask 0022. Cela signifie que si j'ai les deux fichiers:

-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

Lorsque j'utilise sftp pour les mettre dans la machine de destination, je reçois réellement:

-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

Cependant, lorsque je définis -u 0027sur sshd_configla machine de destination, je reçois réellement:

-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

ce qui n'est pas prévu, puisqu'il devrait en réalité être:

-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

Quelqu'un comprend pourquoi cela se produit?

• scp - Indépendamment de ce qui est configuré pour sftp , les autorisations sont toujours umask 0022. Je n'ai actuellement aucune idée de comment modifier cela.

• ssh hostname - pas de problème ici car le shell lit /etc/profilepar défaut ce qui signifie umask 0027dans la configuration actuelle.

• programme ssh hostname - même situation que scp .

En résumé, activer umask sftpmodifie le résultat, mais pas comme il se doit, ssh hostnamefonctionne comme prévu /etc/profileet les deux scpet ssh hostname programsemble avoir umask 0022codé en dur quelque part.

Toute idée sur l'un des points ci-dessus est la bienvenue.

EDIT: je voudrais éviter les correctifs nécessitant une compilation manuelle de openssh. Le système exécute Ubuntu Server 10.04.01 (lucid) LTS avec les opensshpackages de maverick.

Réponse: Comme indiqué par poige, l'utilisation de pam_umask a été efficace.

Les changements exacts étaient:

Lignes ajoutées à /etc/pam.d/sshd:

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

De même, afin d’affecter tous les shells de connexion, qu’ils soient source /etc/profileou non, les mêmes lignes ont également été ajoutées /etc/pam.d/login.

EDIT : Après certains des commentaires, j'ai retesté ce problème.

Au moins dans Ubuntu (où j’ai testé), il semble que si l’utilisateur a un autre umask défini dans les fichiers init de son shell (.bashrc, .zshrc, ...), le umask PAM est ignoré et l’utilisateur umask utilisé est utilisé à la place. Les modifications apportées /etc/profilen'affectent pas le résultat, à moins que l'utilisateur ne les identifie explicitement dans les fichiers init.

À ce stade, il n’est pas clair si ce comportement se produit dans toutes les distributions.

Je peux suggérer d'essayer 2 choses:

1. pam_umask
2. Wrapper LD_PRELOAD (auto-écrit?)

Voici une solution qui vous permettra de faire ce que vous voulez, utilisateur par utilisateur. Il utilise uniquement des sshdfonctionnalités natives et ne nécessite pas de nettoyage avec des correctifs maintenus localement. Cette solution tire parti du ForceCommandcomportement de sshd pour insérer un script de configuration de l'environnement dans chaque connexion ssh, puis exécuter la commande d'origine.

Tout d’abord, créez un script quelque part sur votre système avec le contenu suivant:

#!/bin/sh

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

Pour les besoins de cet exemple, je suppose que vous avez appelé cela /usr/bin/umask-wrapper.

Maintenant, vous avez quelques options pour configurer cela. Si vous souhaitez que cette configuration soit obligatoire pour tous les utilisateurs (ce qui semble un peu improbable), vous pouvez modifier votre configuration sshd pour inclure les éléments suivants:

ForceCommand /usr/bin/umask-wrapper

Si vous souhaitez que cela ne s'applique qu'à certains utilisateurs, vous pouvez utiliser un Matchbloc (à la fin de votre sshd_config):

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

Si vous souhaitez que ce comportement soit contrôlable par l'utilisateur, vous pouvez utiliser l' command=option d'un authorized_keyfichier pour sélectionner ce comportement pour des clés spécifiques. Par exemple, en testant cela, j'ai ajouté une entrée à mon authorized_keysfichier qui ressemble à ceci:

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

Et voici quelques résultats de mon test:

Utilisation sshsans commande:

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

Utiliser sshavec une commande:

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

Utilisant 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

Utilisant 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

Et voila. Je crois que c'est le comportement que vous recherchiez. Si vous avez des questions sur cette solution, je me ferai un plaisir de vous fournir des détails supplémentaires.

J'ai adopté une approche légèrement différente pour centraliser le réglage.

Cela a été ajouté à /etc/pam.d/common-session:

session    optional     pam_umask.so

Ceci a été modifié dans /etc/login.defs:

UMASK           0027

J'ai obtenu pam_umask de travailler avec ssh, mais pas avec scp ou sftp.

La méthode wrapper ne fait rien non plus pour sftp ou scp. Je ne suis pas sûr que 027 soit un bon exemple car la plupart des distributions ont déjà été configurées par umask. Essayez avec 002 et voyez si cela fonctionne.

Les programmes qui ne définissent pas leur propre umask héritent de la umask de l’application qui l’a démarré. Arrêtez sshd complètement, réglez votre umask sur 0027, puis redémarrez-le. (Vous pouvez ajouter la commande umask dans le script init pour les prochains redémarrages.)

Testé pour travailler avec scp.

Si pam_umaskcela ne semble pas affecter vos sessions SFTP, vérifiez siUsePam est défini sur Yesdans le /etc/ssh/sshd_configfichier.

Si vous avez désactivé l'authentification par mot de passe et que vous l'avez UsePamdéfinie ou définie par défaut No. Vous souhaiterez peut-être définir ChallengeResponseAuthentication Nole sshd_configfichier, sinon vous pourriez activer par inadvertance une authentification par mot de passe via ce système.

Une note ajoutée à la réponse de l'utilisateur188737 ci-dessus:

Cela peut aller de soi, mais si vous n’utilisez pas le paquet openssh-server et si vous avez compilé manuellement OpenSSH, assurez-vous d’activer "Activer le support PAM" en passant le--with-pam indicateur de configuration.

Sinon, UsePAM=yesdans sshd_config, plus les modifications apportées /etc/pam.d/*seront ignorées parsshd .

Je me suis enfin rendu compte pourquoi aucune des solutions PAM recommandées n’avait de test d’effet via des connexions SFTP non interactives ...

Puisque umask est hérité du processus parent, sur un système Slackware qui utilise /etc/rc.d/rc.sshdpour démarrer / arrêter / redémarrer sshd, vous pouvez simplement placer umask 0027une ligne directement au-dessus de "sshd_start" ou "sshd_restart", ou alternativement, à tout moment avant la fin du processus. la section principale d'exécution commence, dans /etc/rc.d/rc.sshd:

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

Ou, alternativement, en haut du fichier:

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

Je viens de tester une amélioration possible des options de larsks sshd_config sur solaris 11

Configurez un groupe avec les utilisateurs à gérer et déplacez le script dans le fichier de configuration lui-même. Dans mon cas, je voulais définir le paramètre umask sur 0002.

la configuration résultante devient ....

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

J'ai eu des problèmes avec ce problème, en particulier avec les autorisations de fichiers après la copie d'un fichier à l'aide de scp , et il m'est enfin arrivé d'utiliser simplement ssh pour modifier les autorisations après la copie.

Voici la solution:

1. Copiez votre fichier: localhost$ scp filename remotehost:umask-test/filename
2. Fixer l'autorisation: localhost$ ssh remotehost "chmod go+r umask-test/filename"

Mieux encore, aucun accès root n’est nécessaire pour appliquer cette solution.