Authorized Keys Et Multi Compte

Lokomass · le 4 mai 2013

Bonjour a tous,

J'utilise les clés de chaque serveur pour pouvoir de connecter en ssh sans mot de passe sur chacun d'entre eux. Tout ceci sous root. J'ai voulu faire pareil pour pouvoir me connecter sans mot de passe d'un compte root sur un compte admin en ssh sans mdp. J'ai donc générer des clés en admin sous chaque nas et recopier celles ci sur chacun. Mais a la connexion il me demande un mot de passe. Comment faire ? Y'a t'il un moyen d'utiliser une clé pour plusieurs comptes et si, non comment faire pour me connecter de root a admin en ssh sans mdp ???

Merci d'avance

CoolRaoul · le 4 mai 2013

Rien compris...

(et pourtant je ne suis pas un newbie en ssh)

Peux-tu essayer d'être plus clair?

Déja le "généreré des clés en admin sous chaque nas" me laisse perplexe,

Il suffit de faire *une seule* génération de clé (privée/publique) et de mettre la clé publique sur tous les authorized_keys des comptes cibles.

Lokomass · le 4 mai 2013

Lol désolé pour mon explication foireuse, je suis sur un téléphone et j'ai fait ça rapidement.

En fait j'ai donc généré sur chaque nas en root, les clés publiques privées. Ensuite je les ai mises dans chaque .ssh/authorized_keys de chaque syno, de ce fait je me connecte en ssh sur chaque syno sans mot de passe avec le compte root. Jusque la c'est ok ??

Ensuite, j'aimerai faire la même chose avec le compte admin, c'est a dire, pouvoir me connecter sur chaque syno en ssh via le compte admin sans mot de passe. Quand je regarde les clefs dans chaque authorized_keys elles font toutes références au compte root. Donc comment faire la même chose avec admin ? Sachant qu'aujourd'hui si je fais un ssh en admin sur mes syno il me demande un mot de passe, alors qu'en root non...

J'espère être plus clair

CoolRaoul · le 4 mai 2013

Lol désolé pour mon explication foireuse, je suis sur un téléphone et j'ai fait ça rapidement.

En fait j'ai donc généré sur chaque nas en root, les clés publiques privées. Ensuite je les ai mises dans chaque .ssh/authorized_keys de chaque syno, de ce fait je me connecte en ssh sur chaque syno sans mot de passe avec le compte root. Jusque la c'est ok ??

Non,

Il te suffit de générer *une seule clé*.

A faire sur la machine à partir de laquelle tu va te connecter sur les different NAS (ton PC j'imagine).

La clé publique associée a cette clé devra être déployée dans les differents authorized_keys des comptes de tous les NAS.

Ou alors tu veux te connecter sn SSH à partir d'un NAS vers un autre NAS, mais ce n'est pas ce que l'on comprend dans ta prose.

Ensuite, j'aimerai faire la même chose avec le compte admin, c'est a dire, pouvoir me connecter sur chaque syno en ssh via le compte admin sans mot de passe. Quand je regarde les clefs dans chaque authorized_keys elles font toutes références au compte root. Donc comment faire la même chose avec admin ? Sachant qu'aujourd'hui si je fais un ssh en admin sur mes syno il me demande un mot de passe, alors qu'en root non...

J'espère être plus clair

Que veux-tu faire avec le compte admin en SSH?

Lokomass · le 4 mai 2013

Je veux uniquement me connecter d'un nas vers un Autre. En fait ce n'est pas vraiment du ssh mais du scp pour être précis en admin pour que les fichiers soient copier en admin tout simplement.

CoolRaoul · le 4 mai 2013

Je veux uniquement me connecter d'un nas vers un Autre. En fait ce n'est pas vraiment du ssh mais du scp pour être précis en admin pour que les fichiers soient copier en admin tout simplement.

Le compte "admin" ne sert normalement uniquement pour administrer le NAS va l'interface DSM, en ligne de commande on utilise root plutot mais bref c'est toi qui vois ...

Tu veux que ces copies s'exécutent en cron, sans connexion interactive c'est bien ça?

CoolRaoul · le 4 mai 2013

Je dois avouer ne pas comprendre non plus la phrase:

"je les ai mises dans chaque .ssh/authorized_keys de *chaque* syno,"

Le dossier ".ssh" n'est pas unique par machine: il y en a (potentiellement) un pour chaque *compte* ($HOME/.ssh)

Pour root c'est /root/.ssh, mais pour admin c'est "/var/services/homes/admin/.ssh" (qui correspond en général à /volume1/homes/admin/.ssh)

Modifié le 4 mai 2013 par CoolRaoul

Lokomass · le 4 mai 2013

Ah j'ai en effet pas essayer de mettre les clés publiques de chaque nas dans les répertoires ssh des compte admin....

Je sais pourtant qu'il y a un répertoire ssh par compte.

Mais est ce que ça marchera si je lance un scp sur un compte admin depuis un compte root ?

Modifié le 4 mai 2013 par Lokomass

CoolRaoul · le 4 mai 2013

Ah j'ai en effet pas essayer de mettre les clés publiques de chaque nas dans les répertoires ssh des compte admin.... Mais est ce que ça marchera si je lance un scp sur un compte admin depuis un compte root ?

Bien entendu Modifié le 4 mai 2013 par CoolRaoul

Lokomass · le 4 mai 2013

Ok je reste ça des demain ou lundi, et te tiens au jus merci beaucoup

Lokomass · le 6 mai 2013

En fait mes clés publiques ressemblent à ".....== root@NAS"

Le souci, c'est que pour admin, j'ai donc essayé de reprendre la même clé, la copier dans le fichier authorized_keys dans le rep /volume1/homes/admin/.ssh, en remplacant root par admin et au test d'un ssh, y me demande quand même le mdp

CoolRaoul · le 6 mai 2013

En fait mes clés publiques ressemblent à ".....== root@NAS"

Le souci, c'est que pour admin, j'ai donc essayé de reprendre la même clé, la copier dans le fichier authorized_keys dans le rep /volume1/homes/admin/.ssh, en remplacant root par admin et au test d'un ssh, y me demande quand même le mdp

La partie qui suit les "=" de padding est du commentaire, donc ton problème est ailleurs.

Vérifier que les droits du fichier authorized_keys et du répertoire .ssh soient assez "serrés" (en fait par défaut le démon ssh refuse de prendre en compte authorized_keys si ce dernier et *tout répertoire intermédiaire* qui y mène est modifiable un autre utilisateur que "root" ou le compte cible).

Dans ce cas L'erreur est loggée dans /var/log/messages; comme cela:

May 6 15:16:23 sshd[26590]: Authentication refused: bad ownership or modes for file /volume1/homes/admin/.ssh/authorized_keys

Modifié le 6 mai 2013 par CoolRaoul

Lokomass · le 6 mai 2013

Je n'ai pas cette erreur non...

En fat sur mes 3 serveurs, y'en a pour lequel ça fonctionne bien.

J'ai mes deux clés (une pour root une pour admin), et je me connecte bien sans mdp avec les deux comptes.

En revanche elles commencent par ssh-rsa et les autres par ssh-dss, y'aurait-il un rapport ?

Y'aurait-il également un rapport sur la commande qui génére les clés ? ssh-keygen (avec quel argument -t ou -b 1024 ?)

CoolRaoul · le 6 mai 2013

Je n'ai pas cette erreur non...

En fat sur mes 3 serveurs, y'en a pour lequel ça fonctionne bien.

J'ai mes deux clés (une pour root une pour admin), et je me connecte bien sans mdp avec les deux comptes.

En revanche elles commencent par ssh-rsa et les autres par ssh-dss, y'aurait-il un rapport ?

Y'aurait-il également un rapport sur la commande qui génére les clés ? ssh-keygen (avec quel argument -t ou -b 1024 ?)

J'ai l'impression que tu ne maitrises pas tout.

Déja tu parles de 3 serveurs, mais j'ai du mal a comprendre dans quels sens se font les connexions SSH. Si tu les nommait A, B et C pour l'exemple et énumérait les différentes connexions dont tu as besoin (pas plus de 2 j'imagine) ça serait plus clair, comme cela par exemple

root@A -> admin@B : OK
root@A -> admin@C : OK
root@A -> root@C : echec
etc ..

Ou à tu mis tes deux clés privées? Est-ce que les clés publiques correspondantes sont biens dans *chacun* des authorized_keys cibles? Est-tu sur que la commande ssh utilise bien la bonne clé privée?

Lorsque tu fais une connexion ssh d'une machine A vers le compte U de la machine B, tu va devoir indiquer à ton client ssh quelle clé privée utiliser (on va partir de l'hypothese que tu n'utilise pas d'agent pour ne pas compliquer)

Par défaut il va chercher les clés privés ~/.ssh/id_dsa et ~/.ssh/id_rsa si elles sont la.

Mais tu peux en ligne de commande lui indiquer d'autres clés privée à essayer (sous la forme "-i <chemin fichier clé>", option pouvant être répétée).

Il est même possible d'indiquer les clés privées à utiliser dans le fichier ~/.ssh/config:

Host *
    IdentityFile <chemin1>
    IdentityFile <chemin2>

Si tu veux dédier une clé pour chaque host cible, tu peux mettre plusieurs sections "Host" avec le nom de host à la place de "*" (le test est fait avec le nom de host utilisé en paramètre de la commande ssh, en utilisant des alias tu peux avoir des config différentes). Bref, plein de possibilités.

Pour que la connexion soit acceptée il est faut qu'au moins une des clé publiques correspondant à une des clés privées spécifiés soit présente sur la machine B dans ~U/.ssh/authorized_keys.

Vérifie bien tout ça dans le cas du couple <user>X<server> -> <user2>X<server2> qui ne marche pas.

le prefixe ssh-rsa ou ssh-dss indique le type de clé (rsa ou dss respectivement), le nombre de bits permet de régler la force du cryptage, mais, à part ça, ça ne change rien fonctionnellement

Modifié le 6 mai 2013 par CoolRaoul

Lokomass · le 6 mai 2013

Alors on reprend tout proprement ok. J'ai 3 NAS, deux en locals, et un distant.

J'aimerai pouvoir faire du ssh/scp de chaque NAS vers un autre avec chaque compte root/admin sans mot de passe.

Pour ce faire, j'ai fais générer les cléfs publiques/privées pour chaque compte.

Donc :

ssh-keygen -t dsa -b 1024

et

ssh-keygen -t rsa -b 1024

que je lancent sous root dans /root/.ssh et sous admin dans /var/service/homes/admin/.ssh.

Ensuite je créer un fichier unique de clé, dans le lequel je mets les deux clés générées précédemment pour root et pour admin dans chaque authorized_keys.

Je leur ai attribué tous les bons droits.

Ce qui est bizarre, c'est que tous les ssh sans pwd root fonctionnent, et uniquement depuis les locaux vers le distant en admin... à comprendre pourquoi ?

CoolRaoul · le 6 mai 2013

Alors on reprend tout proprement ok. J'ai 3 NAS, deux en locals, et un distant.

J'aimerai pouvoir faire du ssh/scp de chaque NAS vers un autre avec chaque compte root/admin sans mot de passe.

Tu veux pouvoir te connecter de n'importe lequel des 3 NAS vers n'importe lequel avec toutes les combinaisons de comptes admin et root?

Es-tu *sur* d'avoir besoin de la matrice compléte de connexions : (NAS1, NAS2, NAS2) x (root,admin) -> (NAS1, NAS2, NAS2) X (root,admin) ?

Si oui, tu vas avoir besoin de 6 clés privées root@NAS<i> et admin@NAS<i> pour i = 1..3!

Pour ce faire, j'ai fais générer les cléfs publiques/privées pour chaque compte.

Donc :
ssh-keygen -t dsa -b 1024
et
ssh-keygen -t rsa -b 1024

Quel interêt de generer 2 clés (une dsa et une rsa) par compte?

que je lancent sous root dans /root/.ssh et sous admin dans /var/service/homes/admin/.ssh.

Ensuite je créer un fichier unique de clé, dans le lequel je mets les deux clés générées précédemment pour root et pour admin dans chaque authorized_keys.

Comprend pas en quoi consiste ce "fichier unique de clé".

Pour chaque clé privée générée ssh-keygen t'a generé simultanément une clé publique associée (qui peut être regenérée si necessaire). C'est cette clé publique qui doit figurer dans le authorized_keys du compte du NAS cible

Je leur ai attribué tous les bons droits.

Ce qui est bizarre, c'est que tous les ssh sans pwd root fonctionnent, et uniquement depuis les locaux vers le distant en admin... à comprendre pourquoi ?

C'est franchement compliqué ton truc, déja tu t'emm*** à utiliser root *et* admin, je ne comprend pas bien pourquoi.

Focalise toi sur la connexion qui ne marche pas et pose toi les deux question suivantes:

quelle est la clé privée utilisée dans ce cas (pour ne pas dépendre des défaut, utilise le switch "-i" de la commande ssh)
est-ce que la clé publique correspondant à cette clé privée figure bien dans le authorized keys du répertoire .ssh du compte cible

TIP: l'utilisation du switch "-v" de la commande ssh pourrait te donner des pistes sur ce qui coince.

Et si tu ne parviens pas a désembrouiller tout ça, il y a beaucoup plus simple: rien ne t'empêche d'utiliser la *même* clé pour tous les comptes, c'est pas dans les "best practices" niveau sécurité, mais ça simplifiera d'un facteur considérable tes problèmes.

Pour cela:

tu génère une seule clé sans passphrase (de type rsa par exemple) sur le compte root d'un des NAS
Ca va te donner un fichier id_rsa et un id_rsa.pub
tu copie le id_rsa dans les 5 autres répertoires .ssh
tu ajoute le contenu du id_rsa.pub aux chacun des authorized_keys des 6 comptes (admin et root sur les 3 NAS)

Modifié le 6 mai 2013 par CoolRaoul

Lokomass · le 7 mai 2013

Si j'ai bien suivi, pour pouvoir que mes 3 nas communiquent avec les 2 comptes dans tous les sens sans mdp, il faut :

- ssh-keygen -t rsa -b 1024 (sur nas1)

- id_rsa et un id_rsa.pub sont bien créées

- je recopie donc id_rsa dans les 5 rep

          * sur nas1 => cp /root/.ssh/id_rsa /var/service/homes/admin/.ssh/
          * sur nas1 => scp /root/.ssh/id_rsa root@nas2:/root/.ssh/id_rsa
          * sur nas1 => scp /root/.ssh/id_rsa root@nas3:/root/.ssh/id_rsa
          * sur nas1 => scp /root/.ssh/id_rsa root@nas2:/var/service/homes/admin/.ssh/
          * sur nas1 => scp /root/.ssh/id_rsa root@nas3:/var/service/homes/admin/.ssh/

- ajouter la clé à tous les authorized keys

           * sur nas1 => cat /root/.ssh/id_rsa.pub /var/service/homes/admin/.ssh/authorized_keys
           * sur nas1 => scp /var/service/homes/admin/.ssh/authorized_keys root@nas2 /root/.ssh/authorized_keys
           * sur nas1 => scp /var/service/homes/admin/.ssh/authorized_keys root@nas2 /var/service/homes/admin/.ssh/authorized_keys
           * sur nas1 => scp /var/service/homes/admin/.ssh/authorized_keys root@nas3 /root/.ssh/authorized_keys
           * sur nas1 => scp /var/service/homes/admin/.ssh/authorized_keys root@nas3 /var/service/homes/admin/.ssh/authorized_keys

Si j'ai bien compris c'est "tout" ce qu'il y a à faire, et ensuite je devrais pouvoir réaliser toutes les connexion, mais je ne comprend pas tout, on copie qu'une clé d'un seule serveur, donc entre les deux autres comment ça pourras marcher ?

Merci

CoolRaoul · le 7 mai 2013

Attention, dans la 2eme partie, tes commandes "scp" ont une syntaxe incorrecte:

scp /var/service/homes/admin/.ssh/authorized_keys root@nas2 /root/.ssh/authorized_keys

ne peut pas marcher, scp n'ayant qu'un seul argument

Le plus propre est de procéder ainsi, cela ajoute le contenu de ~root/.ssh/id_rsa aux 6 authorized_keys :

for nas in nas1 nas2 nas3 ; do
    for user in root admin ; do
       ssh $user@$nas "cat >> .ssh/authorized_keys" < /root/.ssh/id_rsa
    done
done

Pour compléter, je vais tenter de procéder par analogie te faire comprendre le mécanisme.

On peut considérer le fichier ".ssh/authorized_keys" comme la "serrure" du compte auquel le fichier appartient.

Mais, contrairement à une vraie serrure, ici il est possible d'accepter *plusieurs* clés différentes.

La liste des clés autorisée est simplement déterminé par son contenu: pour toute clé publique qu'il contient (une clé par ligne), "présenter" la clé privée correspondante autorise la connexion. (je schématise un peu en disant "présenter" mais ça suffit pour avoir une idée)

Lorsque tu te connectes sur un compte d'une machine distante (user@host) tu va donc "présenter" une ou plusieurs clés privées à la "serrure" via l'argument "-i" de la commande ssh. La premiere des clés présentées qui "matche" te donne accès.

Donc, en copiant même clé privée sur *tous* les comptes root et admin de serveurs (ce qui je le répète n'est pas tip top niveau sécurité, mais je n'ai pas la patience de te proposer une solution plus complexe), et en copiant la clé publique correspondante dans *tous* les fichiers authorized_keys de ces memes comptes (en 6 exemplaires donc), tu pourra te connecter à partir de n'importe quel des 6 comptes vers chacun des autres, pour peu que ta commande ssh fasse reférence, via le switch "-i" au fichier contenant la clé privée. Chaque compte disposant d'une copie en propre de ce fichier. (le "-i <chemin fichier>" étant inutile si le fichier clé privée se nomme ~/.ssh/id_rsa qui fait partie des chemins essayés par défaut par la commande ssh)

Modifié le 8 mai 2013 par CoolRaoul

Lokomass · le 8 mai 2013

Je ne comprend plus, il n'était pas question de mettre le id_rsa.pub dans les authorized_keys, et copier le id_rsa dans les .ssh ?

Dans ton petit script tu parle de id_rsa tout court ?

CoolRaoul · le 8 mai 2013

Je ne comprend plus, il n'était pas question de mettre le id_rsa.pub dans les authorized_keys, et copier le id_rsa dans les .ssh ?

Dans ton petit script tu parle de id_rsa tout court ?

Oups, bien vu!

Voici le script corrigé:

for nas in nas1 nas2 nas3 ; do
    for user in root admin ; do
        ssh $user@$nas "cat >> .ssh/authorized_keys" < /root/.ssh/id_rsa.pub
    done
done

Et bien entendu faut aussi déployer le id_rsa tel quel dans les .ssh de chaque compte sur chaque NAS.

Modifié le 8 mai 2013 par CoolRaoul

Lokomass · le 8 mai 2013

Après avoir suivi ton conseil à la lettre, ça ne fonctionne pas.

Je peux uniquement me connecter depuis le serveur sur lequel j'ai fait les clés, sur les autres et en root uniquement.

J'ai pourtant bien mis la clé du serveur nas1 dans authorized_keys de tous les autres. Et copié aussi le id_rsa quand .ssh de tous les autres dans /root/.ssh et /volume1/homes/admin/.ssh.

CoolRaoul · le 8 mai 2013

Après avoir suivi ton conseil à la lettre, ça ne fonctionne pas.

Je peux uniquement me connecter depuis le serveur sur lequel j'ai fait les clés, sur les autres et en root uniquement.

J'ai pourtant bien mis la clé du serveur nas1 dans authorized_keys de tous les autres. Et copié aussi le id_rsa quand .ssh de tous les autres dans /root/.ssh et /volume1/homes/admin/.ssh.

Si tu as vraiment suivi mon conseil *à la lettre* tu es bien d'accord que la situation doit être maintenant entièrement symétrique puisque sur les 6 comptes (root et admin des 3 serveurs) le contenu des fichiers authorized_keys est identique et que la clé privée que tu utilises est bien la même (tu spécifie bien le paramètre "-i <chemin_clé_privée>" pour la commande ssh?, essaie d'ajouter aussi "-oIdentitiesOnly=yes" )

Faudrait lancer la commande ssh en mode verbeux (ajouter "-v") et venir poster le résultat ici.

Vérifier aussi, quand ça ne marche pas, le contenu du fichier /var/log/message du serveur *cible*. Ca pourrait donner des pistes.

Et enfin, soit plus précis dans tes explications, quand tu écris "Je peux uniquement me connecter depuis le serveur sur lequel j'ai fait les clés" on ne comprend pas si tu peux te connecter *depuis* ce serveur ou *a partir de* ce serveur

Modifié le 8 mai 2013 par CoolRaoul

Lokomass · le 8 mai 2013

Voici ce qui se passe sur une connexion par exemple :

NAS> ssh -i /volume1/homes/admin/.ssh/id_rsa "-oIdentitiesOnly=yes" -v admin@192.168.100.160
OpenSSH_5.8p1-hpn13v11, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Connecting to 192.168.100.160 [192.168.100.160] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /volume1/homes/admin/.ssh/id_rsa type -1
debug1: identity file /volume1/homes/admin/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v11
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 00:60:89:72:26:fb:20:42:27:a3:3b:92:8a:8e:c8:4a
debug1: Host '192.168.100.160' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /volume1/homes/admin/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

CoolRaoul · le 8 mai 2013

Faudrait maintenant regarder ce qui a été loggé dans /var/log/messages sur la machine 192.168.100.160 au moment de cette tentative de connexion.

Modifié le 8 mai 2013 par CoolRaoul

Lokomass · le 8 mai 2013

Ah pardon voilà,

May  8 23:15:23 postfix/smtpd[5380]: error: ConvertFullUserName: SYNOUserLoginNameConvert(holding) failed
May  8 23:15:25 postfix/smtpd[5380]: warning: unknown[212.91.92.30]: SASL LOGIN authentication failed: authentication failure
May  8 23:15:29 postfix/smtpd[5380]: error: ConvertFullUserName: SYNOUserLoginNameConvert(holding1) failed
May  8 23:15:31 postfix/smtpd[5380]: warning: unknown[212.91.92.30]: SASL LOGIN authentication failed: authentication failure
May  8 23:15:33 postfix/smtpd[5380]: error: ConvertFullUserName: SYNOUserLoginNameConvert(holding123) failed
May  8 23:15:35 postfix/smtpd[5380]: warning: unknown[212.91.92.30]: SASL LOGIN authentication failed: authentication failure

Connexion

Authorized Keys Et Multi Compte

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Rejoindre la conversation

Qui est en ligne 6 membres, 0 anonyme, 243 invités (Afficher la liste complète)

Contributeurs populaires

Information importante