Désactiver le module PAM pour le groupe

10

J'ai récemment activé l'authentification à deux facteurs à l'aide de Google-Authenticator sur mon serveur SSH. Cependant, je suis maintenant confronté à un problème:

J'ai un groupe d'utilisateurs différent sur mon serveur que j'utilise pour SFTP, mais ce groupe n'est plus en mesure de se connecter car 2FA n'est pas configuré pour les utilisateurs du groupe. Est-il possible de désactiver le module d'authentification Google pour ce groupe? L'activer pour les utilisateurs du groupe n'est pas une option car plusieurs utilisateurs utiliseront ce compte.

PS: j'utilise openssh-server

— Z3r0byte
source

Répondu dans ce commentaire - J'espère que cela aide askubuntu.com/a/1051973/846342

— Abhimanyu Garg

13

Vous pouvez utiliser le pam_succeed_ifmodule (voir la page de manuel) avant pam_google_authenticatorde sauter cette partie pour votre groupe:

# the other authentication methods, such as @include common-auth
auth [success=1 default=ignore] pam_succeed_if.so user ingroup group
auth required pam_google_authenticator ...

— Jakuje
source

2

Il devrait probablement être au [success=1 default=ignore]lieu de required. À l'heure actuelle, un utilisateur qui n'est pas dans le groupe entraînera l'échec de l'authentification, je pense. success=1fera sauter la méthode suivante, default=ignoresignifie que les utilisateurs qui ne sont pas dans le groupe passeront simplement à la méthode suivante.

— muru

@muru oui, vous avez évidemment raison. Toujours en train d'apprendre les détails et toute la magie de la pile PAM :)

— Jakuje

Est-ce que cela dépend si vous avez plusieurs "AuthenticationMethods" dans / etc / ssh / sshd_config? Avec la ligne ci-dessus ajoutée, je reçois toujours 'Autorisation refusée (clavier-interactif)'

— Arj

@Arj cela signifie que vous avez une configuration différente, donc cette réponse spécifique ne s'applique pas à vous.

— Jakuje

1

Certains clients SFTP peuvent gérer 2FA. Par exemple, j'utilise 2FA avec FileZilla et WinSCP et ils fonctionnent. J'ai également configuré l'authentification par clé ssh et cela fonctionne avec 2FA.

Cependant, votre question est intéressante et j'ai fait un bref sondage. J'ai trouvé cette réponse .

Ainsi, il est possible (et facile) d'exécuter des instances ssh distinctes. Je l'ai déjà testé.

Faites des copies séparées du sshd_configfichier.

$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_pwd
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_2fa

Modifiez ces nouveaux configfichiers. Une des choses que vous devez changer est le port shh. Selon l'exemple:

2.a) sshd_config_pwdles lignes spécifiques sont:
```
Port 1022
...
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
```
2.b) sshd_config_2fales lignes spécifiques sont:
```
Port 2022
...
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
```
Ouvrez les ports nécessaires dans le pare-feu. Selon l'exemple:
```
$ sudo ufw limit 1022
$ sudo ufw limit 2022
```

Exécutez les nouvelles instances ssh:

$ sudo /usr/sbin/sshd -f /etc/ssh/sshd_config_pwd
$ sudo /usr/sbin/sshd -f /etc/ssh/sshd_config_2fa

C'est ça.

— pa4080
source

Comment cela répond-il à la question? Qu'est-ce que vous modifiez dans sshd_configpour utiliser une pile PAM différente et ne pas utiliser 2FA?

— Jakuje

@Jakuje J'ai mis à jour ma réponse.

— pa4080

Ok, donc le point est "ne pas utiliser PAM". Cela peut fonctionner dans certains cas, mais PAM ne concerne pas seulement l'authentification, mais également la configuration de la session et bien plus encore, il peut donc cesser de fonctionner de jour en jour. Le changement de port est également très déroutant, surtout si vous souhaitez qu'un tiers se connecte à votre serveur. Bien que oui, solution possible.

— Jakuje

Oui, c'est juste une solution possible, qui est encore incomplète, car je ne connais pas de manière élégante de démarrer ces instances ssh distinctes au démarrage du système.

— pa4080

0

Ce qui suit fera Google 2FA obligatoire pour tous les utilisateurs ,
sauf les utilisateurs appartenant au sudo et administrateur groupe
( qui signifie que si un utilisateur du groupe ou admin ne sudo pas 2FA configuré, il l'authentifier / elle en fonction de leur clé publique):

Fichier: /etc/pam.d/sshd

auth required pam_google_authenticator.so nullok
auth optional pam_succeed_if.so user ingroup sudo
auth optional pam_succeed_if.so user ingroup admin

Fichier: /etc/ssh/sshd_config

AuthenticationMethods publickey,keyboard-interactive
UsePAM yes
ChallengeResponseAuthentication yes

Résultats:

          |  Belongs to sudo or  |  Has 2FA Already Setup      |  Authentication Result
          |  admin group         |  in ~/.google_authenticator | 
----------+----------------------+-----------------------------+------------------------
User A    |          NO          |       NO                    | DENIED LOGIN UNTIL 2FA IS SETUP
User B    |          YES         |       NO                    | CAN LOGIN (PRIVATE/PUBLIC KEY USED)

User C    |          NO          |       YES                   | CAN LOGIN (PRIVATE/PUBLIC KEY AND 2FA USED)

User D    |          YES         |       YES                   | CAN LOGIN (PRIVATE/PUBLIC KEY AND 2FA USED)

Selon la documentation README.md de Google Authenticator :

nullok

PAM nécessite au moins une réponse SUCCESS d'un module, et nullok fait dire à ce module IGNORE. Cela signifie que si cette option est utilisée, au moins un autre module doit avoir dit SUCCÈS. Une façon de procéder consiste à ajouter l'authentification requise pam_permit.so à la fin de la configuration PAM.

Cela rend l'utilisation d' nullokici sûre.

— Basil A
source