Bien sûr, vous ne pouvez pas faire ça. Cela irait à l'encontre de l'objectif même de 2FA. Votre serveur doit avoir un moyen de vérifier les informations d'identification de l'utilisateur, et ces informations ne doivent pas être envoyées sur le réseau (c'est-à-dire que vous ne pouvez pas utiliser uniquement le fichier client.ovpn).
Bien que vous n'ayez pas nécessairement à créer des utilisateurs Unix, vous devez laisser vos utilisateurs installer leurs codes de vérification sur le serveur. Vous pouvez utiliser sftp avec des utilisateurs virtuels en utilisant leur certificat déjà émis, https avec une autorisation (mutuelle) côté client, CIFS (samba), ou un bon vieux ftp avec une extension TLS ou tout autre moyen permettant au serveur de connaître les codes de vérification créés par les utilisateurs . Le canal de communication doit être sécurisé (crypté || local).
Naturellement, si vos utilisateurs téléchargent leurs propres fichiers, vous ne pouvez pas utiliser les informations d'identification basées sur des fichiers agrégés utilisées par openvpn-otp. Heureusement, nous avons une autre option (et bien meilleure) en utilisant linux excellent module de sécurité pam.
Tout d'abord, vous devez collecter les fichiers utilisateur créés par google-authentifier dans un répertoire par l'une des méthodes mentionnées ci-dessus. Dans notre cas, ce sera / etc / google-auth.
Vous devez appliquer ici un ID utilisateur unique pour tous les fichiers, car vous n'avez pas de vrais utilisateurs. Que ce soit openvpn . Les autorisations doivent être 0400 (-r --------). Pam n'aime pas les informations d'identification lisibles dans le monde / groupe (certainement). Vous pouvez facilement appliquer cela avec samba, apache, ftp ou au pire des cas en utilisant un onglet cron (non recommandé).
À des fins de test, procédez comme suit:
mkdir /etc/google-auth
apt-get install libpam-google-authenticator
google-authenticator
# set up as you wish, save image and/or codes
mv ~/.google_authenticator /etc/google-auth/some_username
chown -R openvpn /etc/google-auth
Après cela, vous demandez à openvpn de s'authentifier auprès de libpam, qui a son propre module d'authentification google. Ajoutez ceci à votre fichier serveur openvpn:
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn
Cela signifie que nous utiliserons la méthode d'authentification pam avec l'id d' authentification pam openvpn .
Maintenant, créez la configuration pam pour openvpn. Modifiez /etc/pam.d/openvpn:
auth requisite /lib/security/pam_google_authenticator.so secret=/etc/google-auth/${USER} user=openvpn
account required pam_permit.so
Ici, nous disons que sans une authentification réussie de Google, nous échouons immédiatement (requis), nous utilisons un fichier secret spécial au lieu du $ HOME / .google_authenticator par défaut (secret =) et nous accédons aux fichiers en tant qu'utilisateur openvpn car il n'y a pas de véritable ID utilisateur associé avec nos utilisateurs. Dans la ligne suivante, nous disons simplement que nous autorisons tout le monde à se connecter après une authentification réussie. Bien sûr, vous devez mettre en œuvre votre propre politique d'autorisation ici. Vous pouvez contrôler les utilisateurs autorisés par fichier, mysql db ou ldap avec les modules pam respectifs.
Ajoutez-le à votre fichier client openvpn
auth-user-pass
auth-nocache
reneg-sec 0
Nous utilisons auth-user-pass pour permettre au client openvpn de demander un nom d'utilisateur et un mot de passe. Nous n'aimons pas la mise en cache (le "mot de passe" change) et la renégociation périodique est mauvaise pour nous pour la même raison.
Après cela, vous devriez pouvoir vous connecter sans openvpn-otp. Veuillez considérer que c'est une méthode beaucoup plus flexible, car vous pouvez implémenter des règles très complexes dans les fichiers de contrôle pam si vous le souhaitez. Vous pouvez activer / désactiver les utilisateurs en fonction de votre répertoire mysql ou ldap sans toucher à ces certificats par exemple.