CyberFr

Surtout sur un DS218 Play qui est positionné en entrée de gamme et manque un peu de puissance.

DuckDuckGo est ton ami 😀 Mais ce n'est pas vraiment une priorité.

Apparemment tu ne l'a pas fait @Tcitron alors que ce que suggère @cadkey pourrait être une piste sérieuse d'autant que tu dis toi-même que les disques sont utilisés entre 60 et 100%. Les trois premières licences sont gratuites.

Il faut cliquer sur les trois petits points en haut et à droite du premier message que tu as posté et choisir "Editer".

Tu devrais changer le titre du sujet en "Oubli de mot de passe administrateur." Non, ce n'est pas normal. Si ton utilisateur "tartempion" a vraiment un compte d'administrateur il doit pouvoir changer le mot de passe du compte "admin". Mémorise ce mot de passe car tu pourras en avoir besoin en cas de reset. La modification est refusée pour quelle raison ? Avec à l'appui une copie d'écran si possible.

Bonjour @Tcitron et bienvenue sur le forum !

Bonjour @Gocebo et bienvenue sur le forum !

Si le disque ne fait pas partie d'un groupe RAID et qu'il n'a pas été sauvegardé ça me semble sans issue puisqu'il ne peut pas être monté. La seule solution serait de le placer dans un dock et de faire appel à un outil de récupération de données du fabricant du disque. Sans garantie aucune.

Tu as donc bien renseigné le Portail de connexion dans DSM et l'accès à Synology Photos est du genre "https://photos.ndd.fr". Si tu passes par un proxy inversé défini dans le Portail de connexion, il n'est pas nécessaire d'ouvrir ce port sur l'extérieur. Sauf si, une fois de plus tu passes par un proxy inversé, ce port est forcément ouvert puisque c'est le port d'administration de DSM. De plus c'est le port HTTP non sécurisé et non le port HTTPS...

Bonjour @Flamby55, que voilà une belle présentation ! Bienvenue sur le forum et n'hésite pas à poser des question.

Bonjour @Cindy Sauvage, Je pense que tu devrais scinder ton problème en deux. L'excellent tutoriel que tu as lu porte sur la sécurisation du NAS en général. Ne t'en écarte pas. Après il y a Synology Photo qui utilise son propre port que tu dois ouvrir sur l'extérieur en modifiant les règles du pare-feu en conséquence, à l'exclusion de tout autre port. Si tu peux le gérer derrière un reverse-proxy c'est encore mieux. Après il te faut consulter la documentation de Synology Photo. Je te recommande de procéder pas à pas en testant l'application sur un Mac ou un PC puis avec un utilisateur invité puis sur des appareils mobiles. Oublies les notifications pour l'instant. Si tu veux tout faire en même temps tu risques de te planter.

Ne pas confondre vitesse et précipitation ! Parce que cela nécessite de modifier le fichier système sshd_config et d'utiliser un éditeur de texte en CLI comme vi. Les Macounets y sont-ils prêts ? J'aborderai ce point lorsqu'il y aura une demande parce que je ne veux pas qu'on puisse me reprocher après que le jouet est cassé. À part que si tu modifies le fichier sshd_config, la modif s'applique à tous les utilisateurs et que tu ne pourras pas utiliser ton super mot de passe de 64 caractères.

Je ne sais pas si, concernant le fichier de config, on parle de la même chose. C'est pourquoi j'ai complété le tutoriel en y ajoutant un exemple de fichier de config avec plusieurs entrées.

Je vais essayer, promis. Il sera temps à ce moment là de revenir sur le tuto si tu le souhaites 😀 Errare humanum est, perseverare diabolicum. Je le ferai en temps voulu. J'ai souhaité parler de l'essentiel car le tuto est déjà assez dense. En ce qui concerne le fichier de config, j'ai bien conscience que je ne t'apprendrai rien alors à quoi bon l'ajouter pour l'instant ?

Mais quel est l'intérêt de SSH dans ce cas ? Le seul intérêt de ce choix serait de se prémunir d'un vol où la personne malveillante aurait physiquement accès à ton Mac. Si c'est le cas cette personne aura de toute façon accès à toutes les clés qu’héberge ton Mac. Cela ne présente donc aucun intérêt a priori. Je n'y avais pas pensé. Tu mérites bien ta réputation de barbu 😀 Je commence déjà à écrire le script parce qu'il faut que je m'y prenne un peu à l'avance quand même ! Je l'ai lu mais la commande « cat » fait le même boulot. On est pas sur la même longueur d'ondes, je m'explique. J'ai écrit ce tuto à destination d'un public disposant d'un Mac et d'un NAS et qui souhaitait pouvoir établir une connexion SSH avec une paire de clés. Étant entendu que le NAS était de marque Synology. Toi, tu gères plusieurs serveurs de marques différentes dont l'un, si j'ai bien compris, tourne sur une machine virtuelle. De plus tu utilises une clé privée par serveur ce qui n'est pas habituel, y compris chez des utilisateurs avancés. Tu comprendras facilement que le contexte qui est le tien est sans rapport avec l'objet de ce tuto. Je te propose de commencer avec un Mac et un NAS et de suivre le tuto pas à pas en respectant sa chronologie, ses étapes et sa logique sinon celui-ci ne te servira à rien.

Sans doute et je compte sur toi pour le confirmer 😀 Pas vraiment, ça compliquerait les choses au niveau de la gestion des clés. Je n'ai rien fait du tout. Je décline toute responsabilité dans ce cas ! Mais je connais ta témérité 😀 Il faut vraiment mieux repartir de zéro mais c'est toi qui voit. Je ne comprends pas le rapport avec le SFTP. De plus c'est quoi le proxmox dont tu parles ? Chez moi SSL et SFTP sont deux services distincts qui utilisent des ports différents. De mémoire je n'ai activé aucun service sur le NAS pour le SSL, par contre j'ai activé le serveur SFTP. Tu n'en a pas besoin pour l'instant, comme je te l'ai indiqué il faut le créer à la fin lorsque le SSL avec clés fonctionne. Il simplifie la vie, pas plus et l'on peut s'en passer dans un premier temps. On sort un peu du champ du tuto là. J'ai modifié le fichier sshd_config sur mon NAS mais une fois de plus je l'ai fait en dernier. Parce que si tu le modifies avant d'avoir testé que tout se passe bien, tu prends de gros risques. En effet tu modifies le fichier sshd_config et tu interdis donc la connexion SSH par mot de passe. Et si tu constates par la suite que la connexion par clés ne fonctionne pas, tu seras forcé de constater par la même occasion que tu es définitivement banni de SSH ! Il ne te restera plus qu'à réinstaller DSM. Et même en dehors de ce cas extrême il vaut mieux anticiper tout renouvellement de clés @Fenrir recommande de le faire au moins une fois par an. J'ai un fichier sshd_config_backup que je devrai réinstaller avant tout changement de clés. Si je n'oublies pas bêtement de le faire 😀

J'ai testé le tuto sur la version de macOS qui précède Sonoma, à savoir Ventura. Comme indiqué dans le tuto dans la rubrique "GÉNÉRATION DES CLÉS". Tu peux ne pas choisir l'emplacement qui est proposé par défaut mais pourquoi se compliquer la vie puisque la clé est cryptée ? La clé privée reste sur ton ordinateur quoiqu'il arrive et n'est jamais communiquée au serveur. Lors du lancement de la session SSH c'est le NAS qui envoie une requête à l'ordinateur local et c'est ce dernier qui, en confrontant la clé publique et la clé privée, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Comment veux-tu que je te réponde puisque je n'en suis pas l'auteur ? Le plus simple sans doute est de tout reprendre à zéro avec le tuto que j'ai écrit. Un utilisateur lambda devrait faire ça en 20 minutes mais un as de la CLI comme toi devrait expédier cela en 10 minutes 😀 Moi j'ai conservé les deux, le SSH avec la paire de clés ,et le SFTP. Ils cohabitent à merveille. À mon humble avis c'est une raison de plus pour repartir de zéro. Mais attention ,ne crée pas de fichier de config avant d'avoir terminé le tuto où tu risques de tout casser. J'ai créé un tel fichier de config sur mon Mac après m'être assuré que tout fonctionnait. Et donc au moindre problème il me suffisait de supprimer le fichier de config pour repartir du bon pied.

Bon, le [TUTO] Se connecter à SSH avec une paire de clé sur Mac est réapparu 😀

Bonjour et bienvenue sur le forum @Cindy Sauvage ! Belle machine que ce DS 423. N'hésite pas à poser des questions si nécessaire.

Bonjour et bienvenue sur le forum @Will31 !

Ce tutoriel nécessite DSM 6.2.4 ou une version ultérieure. Son but est de permettre à des clients macOS de se connecter à SSH sans avoir à fournir de mot de passe, que ce soit au niveau d'un compte administrateur ou du compte root. Ce tutoriel a été rédigé à partir de la contribution de référence du regretté unPixel : Et à partir d'une documentation émanant de Synology : Comment puis-je me connecter à DSM avec des paires de clés RSA via SSH ? Le tutoriel de unPixel est plutôt orienté PC et fait appel à des outils comme PuTTY, Pageant ou WinSCP totalement inconnus du monde Mac. Dans ce dernier on n'utilise qu'un seul outil, le Terminal. Il y a bien une partie consacrée aux environnements Mac et Linux ajoutée par @Fenrir mais toutes mes tentatives pour l'appliquer ont été vaines, du moins sous macOS Ventura. unPixel lui-même disait avec humour qu'il n'appliquait pas ce tutoriel sur son Mac et utilisait la bonne vieille méthode du mot de passe. C'est sans doute qu'il y avait quelque part un problème de mise en œuvre. Il est vrai qu'Apple, dont la dernière chimère est de de vouloir créer un système théoriquement inviolable, ne cesse de durcir de façon drastique les mesures de sécurité concernant macOS ce qui explique à mon avis les problèmes rencontrés qui sont des problèmes de droits. Bref, vous l'aurez compris, ce tutoriel est né d'une frustration. Pourquoi ça marche sur PC et pas sur Mac ? 😀 J'ai refondu la documentation de Synology et j'ai dû faire appel à leur support technique après avoir constaté qu'on ne pouvait pas l'appliquer en l'état. Le support a accepté d'ouvrir un ticket et a proposé des modifications qui se sont avérées déterminantes. Merci à eux. Facilité du tutoriel : FACILE si l'on maîtrise un peu l'interface en ligne de commande Durée : 20 minutes environ INTRODUCTION L’authentification par clés SSH (Secure Shell) fonctionne en utilisant une clé publique sur le NAS et une clé privée sur l'ordinateur local. La clé publique peut être placée sur n’importe quel serveur distant auquel on souhaite accéder. C'est d'ailleurs ce que nous ferons par la suite. La clé privée reste sur le Mac et n'est jamais communiquée à quiconque : lors du lancement de la session SSH le NAS envoie une requête à l'ordinateur local et c'est lui qui, en confrontant la clé publique transmise par le NAS et la clé privée qu'il détient, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Dans ce dernier cas l'ouverture de session est bien entendu refusée. Comme l'a dit @.Shad. que je me permets de citer « En gros la clé publique c'est ta réservation au restaurant, et la clé privée c'est le fait de prouver ton identité. ». SSH utilise des algorithmes de cryptage puissants pour sécuriser la communication entre le client et le serveur. Il garantit que les données transmises sur le réseau ne peuvent pas être interceptées ou modifiées par des entités malveillantes. Remarque : la mise en œuvre du tutoriel implique de faire des allers-retours constants entre le Mac (via l'application Terminal) et DSM. Suivez bien les instructions qui sont données car elles vous indiquent où vous vous trouvez et ne vous perdez pas ! N'hésitez pas à m'indiquer les difficultés que vous aurez pu rencontrer afin que j'améliore le tutoriel. De toute façon, si vous rencontrez des problèmes qui vous obligent à tout recommencer, la marche à suivre est décrite en fin de document. N'hésitez pas à m'en faire part là encore. Il est vivement recommandé pour des raisons de sécurité de changer le port par défaut de SSH dans le panneau "Terminal & SNMP" du Panneau de configuration. À chaque fois que vous verrez une commande "ssh ... -p XX" par la suite, remplacez XX par le port que vous avez spécifié. ATTENTION : N'ouvrez pas ce port sur votre box Internet car il doit être utilisé en local pour des raisons de sécurité une fois de plus. Si vous devez absolument vous connecter à SSH sur le NAS hors du réseau local utilisez un VPN. LANCEZ L'APPLICATION TERMINAL SUR LE MAC Inutile de la télécharger, elle est présente sur tous les Mac. Dans tout ce qui suit vous devrez remplacer "username" par par votre nom d'utilisateur sur le NAS et sur le Mac. Ils peuvent être différents (c'est le cas chez moi). Il faut faire attention au contexte dans ce cas afin d'appliquer la bonne substitution : Terminal Mac --> usernameX, SSH --> usernameY. GÉNÉRATION DES CLÉS On génère une paire de clés SSH à partir du Terminal du Mac avec la commande ssh-keygen en spécifiant l’algorithme de chiffrement désiré. J'ai retenu ed25519 qui est le plus sûr à ce jour : ssh-keygen -t ed25519 Vous êtes invité à saisir le chemin d'accès au dossier qui contiendra la clé publique et la clé privée. Laissez l’emplacement par défaut, à savoir : /Users/username/.ssh/id_ed25519 en appuyant sur Entrée. Vous êtes invité à saisir une phrase de passe (passphrase) pour la clé privée CE QUI EST VIVEMENT RECOMMANDÉ VOIRE INDISPENSABLE. Vous pouvez cependant l'ignorer en appuyant deux fois sur la touche Entrée si vous ne souhaitez pas saisir de passphrase à chaque fois que vous utilisez la clé. @Fenrir recommande, je cite « de protéger la clef avec un super mot de passe » et « de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne ». La clé publique (id_ed25519.pub) et la clé privée (id_ed25519) ont été crées sur le Mac dans le dossier choisi plus haut. Il est possible de stocker la passphrase dans le Trousseau d'accès du Mac en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins : La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement tronquée à 10 caractères dans le Trousseau... Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté. Dans tous les cas de figure il est nécessaire pour se connecter à SSH de connaître la passphrase, il ne faut pas faciliter la tâche des intrus en la stockant quelque part sauf dans des coffres sécurisé comme Vaultwarden ou 1Password qui ont leur propre mot de passe et ne sont pas débloqués automatiquement à l'ouverture de session. Vous devrez par la suite copier la clé publique (id_ed25519.pub) dans le dossier home de votre compte administrateur sur le NAS en utilisant File Station. Cette clé se trouve actuellement dans un dossier masqué sur le Mac (.ssh est masqué car précédé d'un point). C'est pourquoi ce dossier n'apparaîtra pas dans la fenêtre de File Station. Pour contourner le problème, le plus simple est d'utiliser le terminal. Il faut se positionner dans le dossier .ssh sur le Mac : cd ~/.ssh puis copier la clé à la racine de son home sur le Mac : cp id_ed25519.pub ~/id_ed25519.pub ENREGISTREMENT DE LA CLÉ PUBLIQUE DANS VOTRE COMPTE ADMINISTRATEUR SUR LE NAS Connectez-vous à DSM avec votre compte administrateur. Accédez à File Station. Dans votre dossier home créez un sous-dossier nommé .ssh (n'oubliez pas le point au début de .ssh). Transférez la clé publique id_ed25519.pub (qui est désormais visible) dans le dossier .ssh en utilisant l'onglet "Charger" de File Station comme illustré ci-dessous (lionel est mon dossier home). Il faut ensuite accéder au dossier home sur le Mac avec le Terminal et supprimer la clé qui s'y trouve afin de faire le ménage (on l'avait déplacé là afin qu'elle soit visible). cd ~/ rm id_ed25519.pub CONNEXION SSH ADMINISTRATEUR AVEC LA PAIRE DE CLÉS Connectez-vous à SSH avec votre compte administrateur sur le NAS. Un message d'avertissement apparaît : The authenticity of host '[192.168.1.2]:22 ([192.168.1.2]:22)' can't be established. ED25519 key fingerprint is SHA256:4nLwr4EVpCwt/jjH9kIEXDUaILvWhVXCzbDCzJv4z66. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? Ce message apparaît lors de la première connexion SSH ce qui est normal. Répondez simplement 'yes'. Warning: Permanently added '[192.168.1.2]:22' (ED25519) to the list of known hosts. Après, vous pouvez être déconnecté auquel cas vous aurez le message : Connection closed by 192.168.1.2 port 22 Il vous faut vous reconnecter dans ce cas. Si vous avez le message : username@192.168.1.2's password: On vous demande simplement votre mot de passe à la suite de quoi vous serez déconnecté de toute façon ! Pour des raisons qui m'échappent, les deux cas se sont produits lors des tests que j'ai réalisés. Pour faire simple dans tous les cas de figure reconnectez-vous ! Accédez au dossier .ssh précédemment créé sur le NAS : cd ~/.ssh Ajoutez la clé publique à un fichier, authorized_keys qui sera créé à cette occasion : cat id_ed25519.pub >> authorized_keys Le dossier .ssh sur le NAS contient désormais deux fichiers : authorized_keys et la clé publique id_ed25519.pub. Se positionner dans son home sur le NAS cd ~/ Puis taper les instructions suivantes où 711 donne les droits en lecture et en écriture au seul propriétaire (vous) et le droit d'exécution à tout le monde : chmod 711 .ssh chmod 711 .ssh/authorized_keys chown -R username .ssh/ Où username est votre nom d'administrateur sur le NAS. Ceci afin d'être sûr que les droits sur ces dossiers sont conformes aux règles. Ces instructions sont très importantes. La première partie du tutoriel est terminée. Vous pouvez maintenant vous connecter à SSH à l'aide de votre compte administrateur sans avoir à saisir un mot de passe. Mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés (ce qui, je le rappelle, est vivement recommandé). Par exemple : ssh username@192.168.1.1 -p XX Enter passphrase for key '/Users/username/.ssh/id_ed25519':_ CONNEXION SSH ROOT AVEC LA PAIRE DE CLÉS Sur le NAS, se connecter à SSH en tant que root à partir de votre compte administrateur en tapant "sudo -i". Soyez conscients qu'en tant que root vous avez tous les droits sur le NAS et qu'une erreur sur une commande peut provoquer des dommages irrémédiables. En cas de doute, il est préférable de copier les commandes du tutoriel et de les coller dans la session SSH. Exécutez la commande mkdir /root/.ssh afin de créer le dossier .ssh s'il n'existe pas. Il peut avoir été créé auparavant si des clés d'administrateurs autres que vous ont été consignées. Vous aurez dans ce cas le message d'erreur : mkdir: cannot create directory ‘/root/.ssh’: File exists qui est sans gravité. Accédez à votre propre dossier .ssh sur le NAS qui se trouve dans votre dossier home : cd /volume1/homes/username/.ssh où volume1 est le volume dans lequel se trouve le fichier id_ed25519.pub et username votre nom d'utilisateur sur le NAS. On crée le fichier authorized_keys de root s'il n'existe pas et on ajoute la clé publique id_ed25519.pub. cat id_ed25519.pub >> /root/.ssh/authorized_keys Entrez la commande chmod 700 -R /root/.ssh afin d'être certain que tout ce qui se trouve dans le dossier .ssh n'est accessible qu'au compte root et ceci est très important (700 donne l'exclusivité de tous les droits à root). ON REDÉMARRE LE SERVICE SSH POUR QUE LES CHANGEMENTS SOIENT PRIS EN COMPTE DSM6 : synoservicectl --reload sshd DSM7 : systemctl restart sshd Vous pouvez maintenant vous connecter en tant que root sans avoir à saisir de mot de passe mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés comme indiqué plus haut. Par exemple : ssh root@192.168.1.1 -p XX Le tutoriel est terminé. MODIFIER LA PASSPHRASE Lancer le Terminal sur le Mac et taper : ssh-keygen -p -f ~/.ssh/id_ed25519 On demande l'ancienne phrase de passe puis la nouvelle. Il faut parfois relancer le service SSH pour que le changement soit pris en compte. Le plus simple est d'essayer de se connecter en tant que root avec la nouvelle passphrase et, si elle est refusée, de saisir l'ancienne. Les changements n'ont pas été pris en compte dans ce cas et il faut utiliser la commande de redémarrage du service SSH indiquée ci-dessus (celle-ci nécessite les droits root). EN CAS D'ERREUR LORS DE LA MISE EN ŒUVRE DU TUTORIEL QUI VOUS OBLIGE A TOUT RECOMMENCER NB : Ces instructions ne s'appliquent que si vous êtes le seul administrateur du NAS ou si vous avez créé une session SSH avec paire de clés pour la première fois. Si un historique préexiste n'hésitez pas à me contacter. Connectez-vous à SSH en tant que root sur le NAS et supprimez son dossier .ssh : rm -R .ssh Connectez-vous à SSH avec votre compte administrateur sur le NAS et supprimez le dossier .ssh qui se trouve dans votre dossier home : rm -R .ssh Lancez l'application Terminal et supprimez le dossier .ssh qui se trouve dans votre dossier home sur le MAC : rm -R .ssh VOUS AUREZ COMPRIS QUE CES ACTIONS SONT IRRÉVERSIBLES ! CRÉATION D'UN FICHIER DE CONFIGURATION SUR LE MAC Un fichier de configuration permet de définir des profils par défaut (hosts) en renseignant l'adresse IP du serveur, le nom d'utilisateur sur le serveur, le port utilisé par SSH et le chemin d'accès à la clé privée. Ainsi au lieu de taper ssh username@192.168.1.1 -p XX pour initier une session SSH, il suffit de taper ssh username Il est possible de créer dans le fichier de config plusieurs hosts avec des adresses IP différentes ce qui permet de se connecter à des serveurs distincts. Ne créez un fichier de config qu'après de la mise en œuvre complète du tutoriel lorsque vous serez sûr que tout fonctionne. # point d'entrée : tapez ssh server_1 pour vous connecter Host server_1 HostName 192.168.1.1 # nom d'utilisateur sur le serveur User username Port XXX # Chemin d'accès à la clé privée IdentityFile ~/.ssh/id_ed25519 Host nas HostName ndd.fr User cyberfr Port XXX IdentityFile ~/.ssh/id_ed25519 Host root HostName 192.168.1.2 User root Port XXX IdentityFile ~/.ssh/id_ed25519 Le fichier de configuration doit être placé sous le nom "config" (sans extension) dans le dossier .ssh de votre home où résident déjà les clés publiques et privées id_ed25519 et id_ed25519.pub. Le plus simple est de le rédiger dans un traitement de texte (TextEdit ou BBEdit) puis de le déplacer au bon endroit. Il vaut mieux respecter le canevas des exemples donnés ci-dessus et ne pas utiliser de tabulations (je n'ai pas essayé donc je ne sais pas si elles sont acceptées 😀).

Dommage que tu n'aies pas pris connaissance du tuto que j'ai écrit à ce sujet pour les utilisateurs de Mac, document qui s'intitulait [TUTO] Se connecter à SSH avec une paire de clé sur Mac. Il intégrait des notions plus modernes que le tuto d'origine dans lequel tu postes. Devant la multitude de réponse suscitée (à savoir zéro), je l'ai retiré. Il a pourtant été lu par plusieurs dizaines de personnes.

Chez moi les liens donnés par @PiwiLAbruti et @Jeff777 ne fonctionnent plus. Lorsque je clique sur Tierce partie (en dessous de Synology) il ne se passe rien. Il est vrai que j'ai réglé Firefox en mode navigation privée. Mais c'était déjà le cas lorsque j'y étais parvenu.

Le 2 avril je suis parvenu à consulter la liste des disques de tierce partie compatibles, aujourd'hui nada, impossible d'obtenir la liste avec pourtant le même navigateur.

Si ton nom de domaine est ndd.fr le nom d'hôte doit être par exemple music.ndd.fr.