OpenSSH Clé publique/privé passphrase et LDAP
Résolu
vincsilver
Messages postés
36
Date d'inscription
Statut
Membre
Dernière intervention
-
vincsilver Messages postés 36 Date d'inscription Statut Membre Dernière intervention -
vincsilver Messages postés 36 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
J'ai installé et configuré récemment un serveur ssh (openssh) sur un serveur Ubuntu 10.
J'ai mis en place la configuration suivante :
L'Accès au serveur en ssh uniquement autorisé aux utilisateurs possédants :
- la clé privée correspondant à la clé publique déclarée dans le fichier "autorized_keys" et qui se trouve dans leur dossier "/home/user/.ssh/"
- le passphrase associé à la clé privée
Cette configuration me semble sécurisée mais j'aimerai savoir s'il est possible d'ajouter une couche supplémentaire d'authentification ?
Par exemple : serait-il possible après que le passphrase soit saisi et accepté par le serveur, qu'il y ai un seconde authentification de type identifiant / password ?
L'idéal serait que le mot de passe de l'utilisateur Unix correspond au mot de passe d'un utilisateur LDAP portant le même nom
J'ai installé et configuré récemment un serveur ssh (openssh) sur un serveur Ubuntu 10.
J'ai mis en place la configuration suivante :
L'Accès au serveur en ssh uniquement autorisé aux utilisateurs possédants :
- la clé privée correspondant à la clé publique déclarée dans le fichier "autorized_keys" et qui se trouve dans leur dossier "/home/user/.ssh/"
- le passphrase associé à la clé privée
Cette configuration me semble sécurisée mais j'aimerai savoir s'il est possible d'ajouter une couche supplémentaire d'authentification ?
Par exemple : serait-il possible après que le passphrase soit saisi et accepté par le serveur, qu'il y ai un seconde authentification de type identifiant / password ?
L'idéal serait que le mot de passe de l'utilisateur Unix correspond au mot de passe d'un utilisateur LDAP portant le même nom
A voir également:
- OpenSSH Clé publique/privé passphrase et LDAP
- Clé usb non détectée - Guide
- Numero prive - Guide
- Clé windows 8 - Guide
- Formater clé usb - Guide
- Clé usb - Accueil - Stockage
2 réponses
Ajout d'éléments :
Il me semble qu'avec l'option : "PasswordAuthentication no" dans le fichier /etc/ssh/sshd_config il n' y a que l'authentification avec la paire de clés publique/privé et éventuellement le passphrase qui permettent d'accéder au serveur en SSH.
Dès lors que je passe l'option "PasswordAuthentication yes" je retrouve l'authentification classique en SHH avec user/password mais ma clé privé n'est plus utilisé.
Serait-il possible d'avoir en premier lieu : authentification par clé privé
Puis en seconde lieu : authentification par identifiant/mot de passe ?
Merci par avance.
Il me semble qu'avec l'option : "PasswordAuthentication no" dans le fichier /etc/ssh/sshd_config il n' y a que l'authentification avec la paire de clés publique/privé et éventuellement le passphrase qui permettent d'accéder au serveur en SSH.
Dès lors que je passe l'option "PasswordAuthentication yes" je retrouve l'authentification classique en SHH avec user/password mais ma clé privé n'est plus utilisé.
Serait-il possible d'avoir en premier lieu : authentification par clé privé
Puis en seconde lieu : authentification par identifiant/mot de passe ?
Merci par avance.
Je reviens sur ce post afin d'apporter moi même la réponse.
==> Il n'est pas possible d'avoir l'authentification via clés publique+privé couplé à l'authentification classique (user + mot de passe).
Tout fois il semble que cette action soit possible via Kerberos et/ou GSSAPI
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
==> Il n'est pas possible d'avoir l'authentification via clés publique+privé couplé à l'authentification classique (user + mot de passe).
Tout fois il semble que cette action soit possible via Kerberos et/ou GSSAPI
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no