Forum Linux.debian/ubuntu Connexion SHH fail avec LDAPS

Posté par dubis le 21 juin 2010 à 15:38.

Étiquettes :

juin

2010

Bonjour,

J'ai réussi à faire un authentification SSH avec LDAP entre 2 machine virtuel Debian l'une cliente l'autre serveur.
Pour corser, un peut la chose j'ai de faire la même chose avec du LDAPS. Le problème c'est que je pense que le mot de passe de l'utilisateur n'est pas interpréter par SHH.
Il n'y aucun problème du coté LDAP car j'arrive à faire un "su - user" depuis l'utilisateur "root", et ce dernier apparaît dans la liste "getent passwd".

Voici ce que j'ai pu observer dans la log /var/log/auth.log :



Jun 21 15:24:39 ldapclient sshd[2239]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=lsdbot  user=coco

Jun 21 15:24:42 ldapclient sshd[2241]: pam_ldap: ldap_simple_bind Can't contact LDAP server

Jun 21 15:24:42 ldapclient sshd[2241]: pam_ldap: reconnecting to LDAP server...

Jun 21 15:24:42 ldapclient sshd[2241]: pam_ldap: ldap_simple_bind Can't contact LDAP server

Jun 21 15:24:42 ldapclient sshd[2241]: pam_unix(sshd:auth): unrecognized option [use_pass]

Jun 21 15:24:42 ldapclient sshd[2241]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=lsdbot user=coco

Jun 21 15:24:44 ldapclient sshd[2241]: Failed password for coco from 134.59.140.39 port 52742 ssh2

# ldaps

Posté par nono14 (site web personnel) le 21 juin 2010 à 15:49. Évalué à 1.

Comme tu le dis , l'authentification ssh fonctionne en ldap, donc pam à l'air d'être correctement configuré.

Un soucis de certificat, utilisateur proxy en ldaps ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
- [^] # Commentaire supprimé
  
  Posté par tiffanyyu le 23 juin 2010 à 09:01. Évalué à -1.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# Test unitaire / log ?

Posté par ze_lionix (site web personnel) le 21 juin 2010 à 20:28. Évalué à 2.

Hello,

Quand tu fais une connexion à la main avec ton client ldap cela te sort pas un message d'erreur genre 'can't bind' ?
Je pense au coup classique du certificat généré à la main et vérifié par le client ldap ( voir directive TLS_REQCERT )

Sinon les logs de ton slapd ils disent quelque chose ?
Fuse : j'en Use et Abuse !
- [^] # Re: Test unitaire / log ?
  
  Posté par dubis le 23 juin 2010 à 11:41. Évalué à 0.
  
  TLS_REQCERT n'est pas configurer il prend donc la valeur par défaut qui est ????
  Par contre tls_checkpeer prend la valeur yes ....
# Tls or ssl ?

Posté par nono14 (site web personnel) le 22 juin 2010 à 12:53. Évalué à 1.

Un ldapsearch -Z fonctionne ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
- [^] # Re: Tls or ssl ?
  
  Posté par dubis le 23 juin 2010 à 11:37. Évalué à 1.
  
  Le LDAPS est en SSL. la commande ldapsearch fonctionne. Il n'y a pas d'erreur dans la log du LDAP. Comme noté dans mon poste, je pense que c'est un problème c'est un problème de compatibilité d'encryption entre LDAPS et SHH :
  
  ssh -vvv coco@ldapclient .../... debug3: Wrote 64 bytes for a total of 1127 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/xxx/.ssh/identity debug3: no such identity: /home/xxx/.ssh/identity debug1: Trying private key: /home/xxx/.ssh/id_rsa debug3: no such identity: /home/xxx/.ssh/id_rsa debug1: Trying private key: /home/xxx/.ssh/id_dsa debug3: no such identity: /home/xxx/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password coco@ldapclient's password: debug3: packet_send2: adding 64 (len 53 padlen 11 extra_pad 64) debug2: we sent a password packet, wait for reply debug3: Wrote 144 bytes for a total of 1271 debug1: Authentications that can continue: publickey,password Permission denied, please try again. coco@ldapclient's password:
  
  Mais a ce niveau je ne vois pas ou je pourrais investiguer
  - [^] # Re: Tls or ssl ?
    
    Posté par nono14 (site web personnel) le 23 juin 2010 à 13:47. Évalué à 1.
    
    ssh s'appuie sur pam. Ensuite, pam contacte le serveur ldap en clair ou chiffrée. (en bref )
    
    Si je comprends ce que tu écris, une connexion ssh s'établit lorsque tu passe en ldap et échoue en ldaps.
    
    Si c'est un soucis de mot de passe, une connexion par clé devrait fonctionner.
    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
    - [^] # Re: Tls or ssl ?
      
      Posté par dubis le 23 juin 2010 à 15:17. Évalué à 1.
      
      Oui,
      
      La connexion SHH passe en LDAP et échoue en LDAPS.
      
      Dans le fichier libnss-ldap.conf, j'ai mit :
      pam_password MD5
      
      le fichier sshd qui est dans le répertoire /etc/pam.d est d'origine:
      auth required pam_env.so envfile=/etc/default/locale @include common-auth account required pam_nologin.so @include common-account @include common-session session required pam_limits.so @include common-password
      - [^] # Re: Tls or ssl ?
        
        Posté par nono14 (site web personnel) le 23 juin 2010 à 15:57. Évalué à 1.
        
        Donc, il semblerait qu'il y ait un soucis de certificats...
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
        
        [^] # Re: Tls or ssl ?
        
        Posté par dubis le 23 juin 2010 à 16:32. Évalué à 1.
        
        Pourtant le client et le serveur communique, je ne comprend pourquoi on incrimine tout de suite les certificats ......

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.