Quelles sont les étapes du système lors de la gestion d'une connexion SSH?


9

Quelles sont les étapes du système lors de la gestion d'une connexion SSH?

  1. Nous essayons de nous connecter via ssh
  2. sshd démarre pam et pam module pour nous authentifier
  3. Selon la configuration de pam, nous devons fournir un nom d'utilisateur et un mot de passe (vérifications passwdet shadowfichiers pam )
  4. contrôles pam pour hosts.allow/deny, /etc/shellset d' autres choses
  5. Si tout se passe bien, nous sommes connectés
  6. ???
  7. Shell est démarré

Ma question est donc de savoir quel mécanisme est chargé de vérifier quel shell est attribué à l'utilisateur dans son passwdfichier (à l'étape 6)? S'agit-il de pam lui-même, d'un module de pam spécifique sshdou de quelque chose d'autre? Je sais que je peux remplacer le passwdfichier (pour vérifier le nom d'utilisateur et le mot de passe) en écrivant un module pam, mais comment puis-je remplacer le passwdfichier pour l'entrée shell?

Réponses:


8

Pour autant que je sache, PAM ne détermine pas le shell de l'utilisateur, cela est laissé à l'application. Les modules de session de PAM effectuent des actions génériques et des vérifications qui doivent être effectuées à chaque connexion utilisant ce service particulier. Si l'application souhaite ensuite démarrer un shell, elle est libre de le faire et recherchera généralement le shell dans la base de données utilisateur.

En supposant que votre question concerne OpenSSH , c'est exactement ce qu'elle fait: une fois que l'utilisateur est authentifié et que la session PAM est terminée (s'il est configuré pour utiliser PAM¹), le serveur ssh recherche le shell dans la base de données utilisateur (directement, pas via la bibliothèque PAM).

La base de données des utilisateurs n'est pas limitée à /usr/passwdet amis. Sous Linux (que je suppose que vous utilisez depuis que vous le mentionnez shadow), ce qui constitue la base de données utilisateur est déterminé par le passwdparamètre dans /etc/nsswitch.conf. Dans les configurations multi-ordinateurs, les ajouts courants à la base de données locale sont NIS et LDAP . Si vous souhaitez utiliser un shell qui n'est pas celui de/etc/passwd , cela peut être ce qu'il faut configurer (bien que ce soit un peu étrange, et peut-être que les gens peuvent offrir de meilleures suggestions si vous nous dites ce que vous essayez d'accomplir).

Si vous voulez avoir des utilisateurs sans accès complet au shell, la solution naturelle est de changer /etc/passwdpour mettre un shell restreint - peut-être rssh pour n'autoriser que quelques applications de type copie de fichiers telles que scp, rsync et cvs. Vous pouvez également utiliser des commandes forcées dans le ~/.ssh/authorized_keysfichier de l'utilisateur .

Si vous souhaitez voir une trace de ce que fait le serveur ssh, démarrez le démon en tant que ssh -ddd. Vous pouvez également obtenir la vue du client avec ssh -vvv, bien qu'ici la vue du serveur soit celle qui vous intéressera le plus.

¹ OpenSSH n'utilise PAM que s'il est configuré avec le support PAM et que la UsePAMdirective est définie sur yesin sshd_config. Même lorsqu'il utilise PAM, il propose d'autres méthodes d'authentification en plus de PAM; en particulier, l'authentification par clé publique ne passe pas par PAM.


Je souhaite autoriser les utilisateurs de mon application à se connecter au shell en tant qu'utilisateur normal sans créer de compte dans le système. Les données des utilisateurs (nom d'utilisateur, pass et shell) seront stockées dans sqlite db. La première étape est le module sqlite pam qui authentifie les utilisateurs contre db. La deuxième étape consiste à fournir un shell lu à partir de la base de données. Je pense donc que cela pourrait être accompli en écrivant le module nis approprié. Merci pour la réponse ...
pbm

@pbm: Je ne pense pas que vous vouliez nisplutôt db(ou peut-être un module personnalisé).
Gilles 'SO- arrête d'être méchant'

c'est une faute de frappe .. Je voulais dire "en écrivant un module nss approprié (personnalisé)" ...
pbm
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.