Précédent | Sommaire | Index | Suivant
Le présent chapitre recense un certain nombre de messages d'erreur courants que PuTTY et les outils associés peuvent afficher, et explique en détail leur signification.
Nous n'avons pas essayé de faire la liste exhausitve des messages d'erreur qui peuvent apparaître dans PuTTY : certains d'entre eux ne devraient jamais apparaître à l'écran, et certains qui doivent normalement être suffisamment explicites. Si vous vous trouvez face à un message d'erreur qui ne figure ici, et que vous ne comprenez pas, signalez-le nous comme un bug ( voir à ce sujet l'annexe B ) et nous l'ajouterons dans cette documentation.
Ce message apparaît lorsque PuTTY se connecte pour la première fois à un nouveau serveur SSH. Chaque serveur s'identifie au moyen d'une clé d'hôte. Une fois que PuTTY connaît la clé d'hôte d'un serveur, il est en mesure de détecter si un pirate intercepte votre connexion et la redirige vers une autre machine.
Si vous voyez ce message, cela veut dire que PuTTY n'a encore jamais rencontré cette clé d'hôte auparavant, et qu'il n'a aucun moyen de savoir si elle est correcte ou non. Vous devriez essayer de vérifier la clé d'hôte par d'autres moyens, comme par exemple en demandant à l'administrateur de la machine distante.
Si vous voyez apparaître ce message, et que vous savez que le PuTTY que vous utilisez a déjà été utilisé pour se connecter à la même machine distante auparavant, cela peut vouloir dire que son serveur SSH a récemment été mis à jour et qu'il est passé en SSH version 2. Les versions 1 et 2 du protocole SSH utilisent des clés d'hôte différentes, ce qui fait que quand vous vous connectez pour la première fois en SSH-2 à un serveur auquel vous ne vous êtes connecté jusqu'ici qu'en SSH-1, vous reverrez apparaître ce message. Vous devriez alors vérifier que la nouvelle clé d'hôte est bien authentique, en procédant cette fois-ci avec la même prudence et la même rigueur que la fois prédente ( la sécurité de vos communications en dépend ).
Pour plus d'informations au sujet des clés d'hôtes, veuillez vous reporter à la section 2.2.
Ce message, suivi par la phrase « The server's host key does not match the one PuTTY has cached in the registry » ( la clé d'hôte du serveur ne correspond pas à celle que PuTTY a mis en cache dans la base de registres ), signifie que PuTTY s'est déjà connecté auparavant au serveur SSH de cette machine distante, qu'il sait quelle devrait être la clé d'hôte correspondante, mais qu'il en a reçu une différente, cette fois-ci.
Ceci peut vouloir dire qu'un petit malin a remplacé le serveur auquel vous essayez de vous connecter par un autre, ou qu'il a redirigé votre connexion réseau vers sa propre machine ( NdT : vraisemblablement pour essayer d'intercepter vos mots de passe, ou d'autres données confidentielles ). Mais cela peut également vouloir dire que l'administrateur légitime de la machine distante a modifié accidentellement la clé d'hôte à l'occasion d'une mise à jour du logiciel SSH. Normalement, cela ne devrait pas arriver, mais c'est malheureusement néanmoins possible.
Si vous voyez apparaître ce message, abandonnez provisoirement votre tentative de connexion, et prenez contact avec l'administrateur de la machine distante, pour lui demander s'il a fait quelque chose qui peut expliquer ce comportement. Si c'est le cas, assurez-vous de l'authenticité de la nouvelle clé d'hôte en vous y prenant de la même façon que si vous vous connectiez à cette machine distante pour la première fois.
Pour plus d'informations au sujet des clés d'hôte, veuillez vous reporter à la section 2.2.
PuTTY dispose d'une mémoire tampon de taille fixe qu'il utilise pour enregistrer les caractéristiques de tous les transferts de port que vous mettez en place au cours d'une session SSH. Si vous demandez trop de transferts de ports, soit dans PuTTY, soit sur la ligne de commande de Plink, et que cette mémoire tampon arrive à saturation, vous verrez apparaître ce message d'erreur.
Nous savons que nous devons corriger cela ( utiliser des mémoires tampon de taille fixe est presque toujours une erreur ) mais nous n'avons pas encore trouvé le temps de nous en occuper. Si cela vous pose réellement un problème, signalez-le nous et nous le remonterons dans notre ordre des priorités.
En attendant, à titre de dépannage, vous pouvez essayer d'utiliser le transfert dynamique de port, qui est expliqué dans la section 3.5.
Ceci se produit lorsqu'aucune des méthodes de chiffrement que propose le serveur SSH de la machine distante n'est considérée par PuTTY comme suffisamment sûre, compte tenu des réglages effectués dans le panneau de configuration SSH. Par défaut, PuTTY n'affiche cet avertissement que pour les chiffrements « single-DES » et « Arcfour ». Pour plus d'informations à ce sujet, veuillez vous reporter à la section 4.18.5. Choix d'un algorithme de cryptage.
Ce message est généré par un serveur OpenSSH ( ou Sun SSH ) quand il voit passer plus de tentatives d'authentification échouées qu'il n'est disposé à en tolérer.
Cela peut facilement se produire si vous utilisez Pageant et que vous avez un grand nombre de clés chargées dedans, parce que ces serveurs comptent chaque fois qu'on leur présente une clé publique comme une tentative d'authentification. Ce problème peut être contourné facilement, en indiquant dans la configuration de PuTTY quelle est la clé à utiliser pour vous authentifier auprès de telle ou telle machine distante ( cf. section 4.20.8 ). PuTTY ignorera alors toutes les autres clés chargées dans Pageant, mais demandera quand même à Pageant de se charger de l'authentification, afin que vous n'ayez pas besoin de saisir votre phrase de passe.
Côté serveur, cela peut être contourné en désactivant l'authentification par clé publique ou ( uniquement dans le cas de Sun SSH ) en augmentant la valeur de MaxAuthTries dans sshd_config.
Ceci se produit lorsque PuTTY essaye d'allouer plus de mémoire que le système ne peut lui en accorder. Cela peut arriver pour de bonnes raisons, comme par exemple, si l'ordinateur est réellement à court de mémoire, ou si vous avez demandé un nombre de lignes extrêmement grand pour l'historique de la session. PuTTY ne sait pas reprendre un fonctionnement normal après s'être retrouvé à court de mémoire. Le programme se termine donc automatiquement, tout de suite après l'affichage de cette erreur.
Toutefois, cette erreur peut également se produire alors que le système n'est pas du tout à court de mémoire, parce que PuTTY reçoit des données dans un format incorrect. Avec SSH-2, et aussi avec SFTP, par exemple, la machine distante envoie la longueur de chaque message avant le message lui-même. PuTTY reçoit cette indication de longueur, essaye d'allouer l'espace mémoire correspondant, puis réceptionne le reste du message. Si jamais la valeur numérique que PuTTY reçoit, au moment où il attend la longueur du message qui va suivre, se trouve être du gros n'importe quoi, PuTTY peut essayer d'allouer une quantité de mémoire ridiculement élevée, et se terminer avec un message d'erreur « Out of memory ».
Ceci peut arriver avec SSH-2, si PuTTY et la machine distante ne se sont pas bien mis d'accord sur la méthode de chiffrement ( cf. question A.7.5 dans la Foire Aux Questions ). Certaines versions de OpenSSH ont un problème connu à ce niveau : veuillez vous reporter à la question A.7.16 dans la FAQ pour plus d'informations à ce sujet.
Cela peut aussi se produire avec PSCP ou PSFTP, si des scripts de login exécutés sur la machine distante génèrent un résultat affichable : le programme client ( PSCP ou PSFTP ) s'attend à recevoir un message commençant par une indication de longueur, et au lieu de cela, il va recevoir le texte affiché par vos scripts de login, qu'il va essayer d'interpréter comme une longueur de message. Veuillez vous reporter à la question A.7.6 de la FAQ pour plus d'informations à ce sujet.
Aucune erreur commençant par le mot « Internal » ne devrait jamais se produire. Si une telle erreur se produit, c'est qu'il y a un bug dans PuTTY, par définition. S'il vous plaît, consultez l'annexe B, et signalez-nous ce bug.
De même, tout message d'erreur commençant par « Assertion failed » constitue un bug dans PuTTY. Merci de nous le signaler, en indiquant bien le texte exact qui figure dans le message d'erreur.
Différentes formes de cette erreur peuvent apparaître dans la fenêtre de PuTTY, ou être écrites dans le journal d'événements de PuTTY ( cf. section 3.1.3.1 ) quand on essaye de s'authentifier par clé publique, ou encore être affichées par Pageant quand on essaye de charger une clé privée.
Si vous voyez apparaître l'un de ces messages, cela veut souvent dire que vous avez essayé de charger dans PuTTY, Plink, PSCP, PSFTP, ou Pageant une clé d'un type inapproprié.
Il se peut, par exemple, que vous ayez indiqué une clé qui ne convient pas pour la connexion que vous cherchez à établir. Les protocoles SSH-1 et SSH-2 utilisent des formats différents de clés privée, et une clé SSH-1 ne peut pas servir pour établir une connexion SSH-2 ( et vice versa ).
Il se peut aussi que vous ayez essayé de charger une clé SSH-2 d'un format « étranger » ( OpenSSH ou ssh.com ) directement dans l'un des outils associés à PuTTY, auquel cas il faut la convertir auparavant dans le format de clé natif de PuTTY ( *.PPK ), à l'aide de PuTTYgen. Pour plus d'informations à ce sujet, veuillez vous reporter à la section 8.2.12.
Différentes formes de cette erreur peuvent apparaître dans la fenêtre de PuTTY, ou être écrites dans le journal d'événements de PuTTY ( cf. section 3.1.3.1 ) quand on essaye de s'authentifier par clé publique.
Si vous voyez apparaître l'un de ces messages, cela veut dire que PuTTY a envoyé une clé publique à la machine distante et proposé de vous authentifier à l'aide de cette clé, mais que la machine distante a refusé la demande d'authentification. En général, c'est parce que le serveur SSH de la machine distante n'est pas configuré pour accepter cette clé afin d'authentifier l'utilisateur correspondant.
On peut dire avec une quasi-certitude qu'il ne s'agit pas d'un problème lié à PuTTY. Si vous voyez apparaître ce genre de message, la première chose à faire est de vérifier soigneusement la configuration du serveur. Parmi les erreurs courantes à ce niveau, il y a des permissions incorrectes ou un propriétaire incorrect sur la clé publique, ou sur le répertoire personnel de l'utilisateur sur la machine distante. Pensez aussi à consulter le journal d'événements de PuTTY. Il se peut que la machine distante ait envoyé des messages de diagnostic qui expliquent précisément quel problème elle a rencontré avec votre configuration.
La section 8.3 contient quelques indications au sujet de la mise en place des clés publiques côté serveur.
Différentes formes de cette erreur peuvent apparaître dans la fenêtre de PuTTY, ou être écrites dans le journal d'événements de PuTTY ( cf. section 3.1.3.1 ) au cours du processus d'authentification.
Si vous voyez apparaître l'un de ces messages, cela veut dire que la machine distante a refusé toutes les formes d'authentification que PuTTY a essayées, et que PuTTY ne sait plus quoi tenter d'autre.
Cela peut valoir la peine de regarder dans le journal d'événements de PuTTY, pour voir s'il n'y aurait pas dedans des messages de diagnostic, émis par la machine distante, qui donneraient plus de détails.
Ce peut être dû à un serveur SSH-1 bugué, qui ne sait pas gérer correctement les différentes stratégies que nous utilisons pour dissimuler les mots de passe lors de leur transit entre votre machine et la machine distante. Mettez à jour le logiciel serveur de la machine distante, si vous le pouvez, ou employez les solutions de contournement décrites dans la section 4.25.1, ou dans la section 4.25.2.
Cette erreur indique que PuTTY est à court de méthodes d'authentification pour vous authentifier auprès du serveur SSH de la machine distante. Il se peut que ce soit parce que l'authentification TIS, ou authentification interactive au clavier, soit désactivée dans PuTTY, auquel cas il faut vous reporter aux sections 4.20.4 et 4.20.5.
Cette erreur se produit lorsque PuTTY décode un paquet SSH et que sa somme de contrôle n'est pas correcte. Cela signifie probablement que quelque chose s'est mal passé, soit au moment du chiffrement, soit au moment du déchiffrement, mais il est difficile de dire, à partir de ce message d'erreur, si le problème se situe côté client, côté serveur, ou quelque part entre les deux.
En particulier, si c'est le réseau qui corrompt les données au niveau TCP, cela peut ne se voir qu'avec des protocoles cryptographiques tels que SSH, qui vérifient explicitement l'intégrité des données transférées, et qui protestent bruyamment en cas d'échec des contrôles à ce niveau-là. Dans le cas des protocoles qui ne procèdent pas à une telle vérification d'intégrité, comme HTTP, par exemple, une corruption des données se traduira de façon moins visible ( comme par exemple par du texte ou des images qui ne s'affichent pas correctement dans un navigateur ), et pourra même passer inaperçue.
Un problème connu, côté serveur, qui peut provoquer l'apparition de cette erreur, est décit dans la question A.7.16 de la Foire Aux Questions.
Cette erreur se produit lorsque PuTTY décode un paquet SSH et qu'il s'avère que les données, une fois décodées, n'ont aucun sens. Ceci signifie probablement que quelque chose s'est mal passé, soit au moment du chiffrement, soit au moment du déchiffrement. Il est difficile de dire, quand on voit apparaître ce message d'erreur, si le problème se trouve côté client, ou côté serveur, ou quelque part entre les deux.
Si vous obtenez cette erreur, vous pouvez essayer de changer la valeur sélectionnée dans la liste déroulante « Miscomputes SSH-2 encryption keys » ( cf. section 4.25.6 ), ou dans la liste déroulante « Ignores SSH-2 maximum packet size » ( cf. section 4.25.10 ), que vous trouverez toutes deux dans le panneau de configuration Bugs.
Un autre problème connu, côté serveur, qui peut provoquer cette erreur, est décrit dans la question A.7.16 de la Foire Aux Questions.
Les erreurs de cette famille apparaissent lorsque PuTTY procède au chiffrement d'une session X ( quand il fait du « X11 forwarding », comme on dit en bon français ). Elles sont renvoyées à l'application X qui s'exécute sur le serveur SSH, lequel signale alors généralement l'erreur à l'utilisateur.
Lorsque PuTTY active le chiffrement de session X ( cf. section 3.4 ), il crée un display X virtuel, qui s'exécute sur le serveur SSH. Ce display requiert une authentification pour s'y connecter ( c'est comme cela que PuTTY procède pour empêcher d'autres personnes, qui utilisent eux aussi la machine serveur, de se connecter à votre vrai display X en passant par le proxy de PuTTY ). PuTTY envoie également au serveur les informations dont il a besoin pour pour permettre aux clients de se connecter, et le serveur doit normalement mettre ce mécanisme en place de façon automatique, ce qui fait que vos applications X devraient fonctionner, tout simplement.
Il n'est pas rare de voir apparaître l'un de ces messages d'erreur lorsqu'on utilise SSH pour ouvrir une session avec un certain compte utilisateur ( « fred », par exemple ), puis qu'on utilise la commande Unix su pour devenir quelqu'un d'autre ( « root », le plus souvent ). L'utilisateur d'origine, « fred », peut accéder aux informations d'authentification X, qui lui sont fournies par le serveur SSH, et il peut lancer des applications X, dont l'affichage est alors transmis via la connexion SSH. Toutefois, le second utilisateur (« root », dans cet exemple ) ne reçoit pas automatiquement ces informations d'authentification X, et c'est pourquoi, quand on essaie de lancer une application X depuis ce deuxième compte utilisateur, cela échoue souvent, avec cette erreur.
Si cela se produit, ce n'est pas un problème lié à PuTTY. Il faut que vous fassiez le nécessaire pour que les données d'authentification utilisées par X Window soient transmises depuis le compte utilisateur que vous avez utilisé pour ouvrir la session jusqu'à celui que vous êtes devenu grâce à la commande su. La façon de procéder pour cela varie d'un système à l'autre. En fait, de nombreuses implémentations modernes de la commande su le font automatiquement.
Ce message est une erreur générique que la couche réseau de Windows affiche lorsque, pour une raison ou pour une autre, elle « tue » une connexion établie entre deux machines. Par exemple, ce message peut apparaître si jamais vous débranchez le câble réseau d'un ordinateur muni d'une connexion Ethernet, ou si Windows a une raison de penser que le réseau dans son ensemble est soudainement devenu inaccessible.
Windows affiche également cette erreur si jamais la machine située à l'autre extrémité de la connexion a cessé de lui répondre. Si le réseau entre votre PC et la machine distante vient à « tomber », et que votre PC essaie d'envoyer des données à la machine distante pendant cette interruption de la connexion, par exemple, Windows réessaye plusieurs fois d'envoyer les données avant d'abandonner et de mettre fin à la connexion. Cela peut se produire même si vous n'avez rien tapé au clavier, et rien envoyé volontairement, mais que vous utilisez SSH-2 et que PuTTY essaye de procéder à un nouvel échange de clés ( pour plus d'informations au sujet des rééchanges de clés, veuillez vous reporter à la section 4.19.2 ).
N.B. : cela peut également se produire si vous utilisez des signes de vie pour garder votre connexion ouverte. Certaines personnes ont même signalé que l'emploi de signes de vie résolvait ce problème, dans leur cas ( veuillez vous reporter à la section 4.13.1 pour plus d'informations sur les avantages et les inconvénients des signes de vie ).
Nous n'avons connaissance d'aucune raison pour laquelle cette erreur pourrait se manifester, qui constituerait un bug dans PuTTY. Le problème se trouve entre vous, votre PC Windows, votre réseau et la machine distante. PuTTY n'y est a priori pour rien.
Cette erreur se produit quand les machines situées à chaque extrémité d'une connexion réseau perdent trace de l'état de la connexion qui les relie l'une à l'autre. Par exemple, il se peut que vous la voyiez apparaître si le serveur SSH de la machine distante « plante », et réussit à finir de rebooter avant que vous n'essayiez de lui renvoyer des données depuis le poste client.
Cependant, là où vous avez le plus de chances de voir apparaître ce message, c'est quand vous vous connectez à la machine distante en passant par un pare-feu ou un routeur NAT, et que ce pare-feu ou ce routeur NAT considère que la connexion a expiré ( qu'elle est « partie en time-out », comme on dit en bon français ). Pour plus d'informations à ce sujet, veuillez vous reporter à la question A.7.10 de la Foire Aux Questions. Il se peut que vous arriviez à améliorer les choses en essayant de modifier la configuration des signes de vie, ou keepalives. Veuillez vous reporter à la section 4.13.1 pour plus de détails à ce sujet.
Veuillez noter que Windows peut faire apparaître cette erreur dans certaines circonstances, sans qu'il y ait eu réinitialisation de la connexion côté serveur, en cas de perte de la connexion au réseau, côté client.
Cette erreur signifie que la connexion réseau que PuTTY a tenté d'établir avec la machine distante a été rejetée par celle-ci. En général, cela se produit quand la machine distante ne fournit pas le service auquel PuTTY essaye d'accéder.
Vérifiez que vous utilisez le bon protocole ( SSH, Telnet ou Rlogin ), et que le numéro de port est correct. Si cela échoue, voyez avec l'administrateur de la machine distante.
Cette erreur signifie que PuTTY a essayé de se connecter à la machine distante, et qu'il n'a pas reçu la moindre réponse de la part de celle-ci. En général, cela se produit parce que la machine distante est complètement isolée du réseau, ou parce qu'elle est éteinte.
Vérifiez que vous n'avez pas fait d'erreur dans le nom d'hôte ou dans l'adresse IP de la machine distante, et si ce n'est pas le cas, voyez avec l'administrateur.
Sous Unix, cette erreur apparaît aussi lorsque votre machine essaye d'émettre des données via une connexion et que le contact avec la machine distante a été complètement perdu ( il y a un délai de plusieurs minutes avant qu'Unix n'abandonne, lorsqu'il attend une réponse de la machine distante ). Cela peut se produire si vous tapez des choses dans PuTTY à un moment où le réseau est « en vrac », mais cela peut aussi se produire si PuTTY décide de sa propre initiative d'envoyer des données, à l'occasion d'un nouvel échange de clés dans SSH-2 ( cf. section 4.19.2 ), ou à cause des signes de vie ( voir à ce sujet la section 4.13.1 ).
Si vous souhaitez faire part aux auteurs de PuTTY de votre avis sur ce manuel, ou sur les outils PuTTY eux-mêmes, veuillez vous reporter à la page "Feedback"
( merci de leur écrire exclusivement en anglais ). Si vos remarques portent sur la traduction, merci de vous adresser directement au traducteur, et non à l'équipe de
développement.
