Précédent | Sommaire | Index | Suivant
ssh.com ?WS2_32.DLL.cat sur un fichier binaire, j'obtiens 'PuTTYPuTTYPuTTY' à répétition sur ma ligne de commande.cat sur un fichier binaire, le titre de ma fenêtre se met à afficher n'importe quoi.screen.127.0.0.2.VirtualLock() pour empêcher les clés privées d'être écrites sur le disque ?Cette FAQ figure sur le site web de PuTTY, et elle est aussi fournie en annexe du manuel ( NdT : en anglais dans les deux cas ).
PuTTY est un programme client pour les protocoles réseaux SSH, Telnet et Rlogin.
Tous ces protocoles servent à lancer une session sur une machine distante, via le réseau. PuTTY constitue la partie client de cette session, autrement dit l'extrémité de la liaison où les commandes sont tapées, et où les résultats sont affichés, par opposition à celle où sont exécutés les traitements.
Pour dire les choses plus simplement, vous lancez PuTTY sur une machine Windows, et vous lui demandez de se connecter à une machine Unix ( par exemple ). PuTTY ouvre une fenêtre, et à partir de là, tout ce que vous tapez au clavier dans cette fenêtre est envoyé directement à la machine Unix, et tout ce que la machine Unix renvoie en retour est affiché dans la fenêtre PuTTY. Cela vous permet d'utiliser la machine Unix comme si vous étiez assis devant, alors qu'en fait, vous vous trouvez ailleurs.
D'une façon générale, si vous voulez savoir si PuTTY sait faire telle ou telle chose, vous devriez chercher dans le site web de PuTTY. En particulier, vous devriez :
Oui, depuis la version 0.50 de PuTTY.
L'authentification par clé publique SSH-2 ( aussi bien RSA que DSA ) a été ajoutée dans la version 0.52.
ssh.com ?Pas de façon native ( si vous voulez savoir pourquoi, lisez l'entrée correspondante dans la page des desiderata ), mais depuis la version 0.53, PuTTYgen sait convertir les fichiers de clés privées de ces deux formats dans le format de PuTTY.
Oui. PuTTY a toujours supporté le SSH-1.
Oui. L'écho local est géré correctement depuis la version 0.52.
Dans la version 0.51 et les versions précédentes, l'écho local allait forcément de pair avec l'édition locale de ligne ( quand on tape une ligne de texte en local, et qu'elle n'est pas envoyée à la machine distante avant qu'on ait appuyé sur Entrée, cela permet de corriger d'éventuelles fautes de frappe avant que la machine distante ne les voie, contrairement à ce qui se passe quand les caractères tapés au clavier sont envoyés au fur et à mesure à la machine distante ). Depuis la version 0.52, l'écho local et l'édition de ligne en local sont des options distinctes, et par défaut, PuTTY essaie de déterminer automatiquement s'il y a ou non lieu de les activer, en fonction du protocole sélectionné, et en fonction d'indications fournies par la machine distante. Si les choix par défaut de PuTTY ne vous conviennent pas, vous pouvez modifier ces réglages. Pour cela, allez dans le panneau de configuration Terminal, dans la partie intitulée 'Line discipline options'.
Oui, tous les réglages de PuTTY peuvent être enregistrés dans des profils de sessions, ou sessions sauvegardées. Vous pouvez aussi modifier les réglages par défaut qui sont utilisés pour les nouvelles sessions ( pour plus d'informations à ce sujet, veuillez vous reporter à la section 4.1.2 ).
Pas pour l'instant. Toutefois, dans la section 4.26, vous trouverez la marche à suivre pour obtenir le même effet.
Oui, c'était l'une des nouveautés de la version 0.52.
Non, il ne sait pas faire cela, et c'est tant mieux. La mémorisation d'un mot de passe est une mauvaise idée, pour d'évidentes raisons de sécurité : quiconque réussit à accéder à votre machine en votre absence peut découvrir les mots de passe sauvegardés, les utiliser, en faire mauvais usage, voire même les modifier dans votre dos.
De plus, PuTTY ne peut pas envoyer automatiquement votre mot de passe pour ouvrir une session Telnet, parce que le protocole Telnet n'indique d'aucune manière au logiciel client à quel moment précis il attend qu'on lui envoie le mot de passe. Il faudrait que PuTTY devine cela, en surveillant par exemple l'apparition de mots tels que 'password' dans les données échangées avec le serveur Telnet, lors de l'établissement de la session. Pour peu que le programme à l'autre bout ne parle pas anglais, il faudrait surveiller aussi le mot 'mot de passe' en français, 'Passwort' en allemand, etc., et on ne s'en sortirait pas.
Avec SSH, il serait théoriquement possible de mémoriser votre mot de passe, mais cela ne présenterait pas grand intérêt, puisque SSH gère de toute façon l'authentification par clé publique, qui est à la fois plus souple et plus sûre. Veuillez vous reporter au chapitre 8 pour des explications complètes au sujet de l'authentification par clé publique.
Non, il n'y en a pas. Et il n'y en aura pas. Même si vous écrivez vous-même le correctif nécessaire, et que vous nous l'envoyez, nous ne l'accepterons pas.
Ces « ennuyeux messages au sujet des clés d'hôte » sont au coeur même de SSH. Sans eux, toute la technologie cryptographique que SSH utilise pour sécuriser votre session ne servirait à rien d'autre qu'à rendre le travail du pirate un peu plus difficile. Au lieu de simplement s'intercaler entre vous et la machine distante avec un renifleur de paquets ( pour prendre connaissance de votre mot de passe, même si celui-ci est crypté, et le décrypter après, tout à loisir ), l'attaquant doit réussir à pirater un routeur et à modifier à la volée les paquets qui transitent dans un sens et dans l'autre. Mais même ça, ce n'est pas beaucoup plus difficile que de renifler des paquets, et sans vérification de la clé d'hôte, cela pourrait passer complètement inaperçu, tant du côté du client ( vous ) que du côté du serveur ( la machine distante ).
La vérification de la clé d'hôte vous garantit que la méthode de chiffrement que vous utilisez côté client est bien la même que ( ou l'inverse de ) celle qui est appliquée côté serveur, pour récupérer les données en clair. Elle vous garantit que les données n'ont pas été décryptées en cours de route, par une personne mal intentionnée, puis ré-encryptées ( après modification, éventuellement ). La vérification de la clé d'hôte rend le travail du pirate incroyablement difficile, comparé au reniflage de paquets, et même comparé au piratage de routeur. Au lieu de faire preuve d'un minimum d'intelligence et de garder un oeil sur Bugtraq, le pirate doit effectuer une attaque par force brute contre au minimum un chiffrement de classe militaire. Vu sous cet angle, les « ennuyeux messages au sujet des clés d'hôte » sont bien peu de chose.
Si vous rencontrez un problème précis avec la vérification de la clé d'hôte, par exemple si vous voulez utiliser PSCP ou Plink dans un script batch pour automatiser une connexion ou un transfert, et que la vérification interactive de la clé d'hôte fait échouer le processus, alors la bonne manière de procéder, pour régler le problème, consiste à ajouter la clé d'hôte de la machine distante dans la Base de registres de Windows ( côté client, donc sur votre machine à vous ) avant de lancer le script. De cette façon, vous conservez ce qui fait tout l'intérêt de la vérification de la clé d'hôte : la clé d'hôte de la machine distante sera acceptée, mais les clés d'hôte que pourraient envoyer les machines utilisées par un pirate ne le seront pas. Ajouter une option dans PuTTY pour désactiver complètement la vérification de la clé d'hôte n'est pas la bonne solution, et nous ne le ferons pas.
Si vous avez des clés d'hôtes au format known_hosts, sachez que nous tenons à votre disposition un script nommé kh2reg.py pour les convertir en un fichier Windows .REG, grâce auquel vous pourrez inscrire ces clés d'hôtes dans la Base de registres, avant d'utiliser votre script de connexion automatisée, soit en double-cliquant sur le fichier .REG, soit via l'outil REGEDIT.
Non. La seule raison qui pourrait justifier cela serait qu'il nous soit possible de réutiliser suffisament de code existant pour que cela diminue de façon sensible le travail de développement. Nous ne pensons pas que ce soit le cas. Il n'y a tout simplement pas suffisament de choses en commun entre un client SSH et un serveur SSH, pour que le jeu en vaille la chandelle.
Si quelqu'un souhaite utiliser des parties du code source de PuTTY pour écrire un serveur SSH pour Windows, il est tout à fait le bienvenu, bien sûr, mais je ne suis vraiment pas persuadé que cela demande moins d'efforts que d'écrire un serveur SSH en partant de rien. Nous n'avons ni le temps ni la motivation nécessaires pour le faire nous-mêmes, mais si quelqu'un d'autre veut s'y essayer, notre code est à sa disposition.
Malheureusement non. Pendant longtemps, cela s'est expliqué par une limitation des protocoles de transfert de fichiers : les protocoles SCP et SFTP ne savaient pas transférer un fichier autrement qu'en binaire ( c'est d'ailleurs toujours le cas, en ce qui concerne SCP ).
Une spécification actuellement à l'étude du protocole SFTP propose une façon d'effectuer des transferts en mode ASCII. Il n'est donc pas impossible que PSCP/PSFTP mettent cela en oeuvre un jour ou l'autre.
Le but in fine est de faire de PuTTY un programme multi-plateformes, qui tourne au moins sous Windows, MacOS et sous Unix.
Le portage vers d'autres systèmes deviendra plus facile une fois que PuTTY aura une couche de portage globale, qui permettra de tirer un trait bien net entre le code spécifique à une plateforme donnée et celui qui est commun à toutes.
L'idée, c'était que cette couche de portage évolue petit à petit, au cours de la mise au point du premier portage. Une version Unix est maintenant terminée, et il semble que notre plan fonctionne, jusqu'ici.
Pour l'instant, les versions stables des outils PuTTY ne fonctionnent que sur les systèmes Win32 et Unix. 'Win32', cela veut dire Windows 95, 98, et ME, Windows NT, Windows 2000 et Windows XP.
Parmi les versions en cours de développement, un portage partiel vers Mac OS est en cours ( cf. question A.3.6 ).
Actuellement, PuTTY ne fonctionne pas sous Windows CE ( cf. question A.3.4 ), et pas vraiment bien avec l'environnement Win32s de Windows 3.1 ( cf. question A.3.5 ).
Nous n'avons pas de portages stables pour d'autres systèmes à l'heure actuelle. Si quelqu'un vous a dit que nous avons une version EPOC, ou une version iPaq, ou n'importe quelle autre version de PuTTY, cette personne s'est trompée. Nous n'en avons pas.
En revanche, il existe quelques versions destinées à différentes plateformes, qui ont été écrites par d'autres personnes, et qui sont mentionnées dans la page Links de notre site web.
Depuis la version 0.54, il existe des versions Unix de la plupart des outils PuTTY traditionnels, ainsi qu'une application entièrement nouvelle.
Si vous regardez dans la version qui inclut les codes sources, vous y trouverez un sous-répertoire unix, avec dedans un fichier Makefile.gtk, qui sert à compiler les versions Unix de Plink, de PuTTY lui-même, de PuTTYgen, PSCP, PSFTP, et aussi de pterm - un programme de type xterm qui supporte le même type d'émulation de terminal que PuTTY. Nous n'avons pas encore de version Unix de Pageant.
Si vous n'avez pas Gtk, vous pouvez tout de même compiler les versions en ligne de commande des outils.
Veuillez noter que la version Unix de PuTTY a principalement été testée sous Linux jusqu'ici. Il faut donc s'attendre à de possibles soucis de portabilité avec les ptys façon BSD, ou à ce qu'il y ait besoin de fichiers d'entête différents.
La version Unix présente un intérêt pour différentes raisons. pterm, par exemple, est directement utile pour les gens qui préfèrent l'émulation de terminal de PuTTY à celle de xterm, et c'est le cas d'au moins un certain nombre de gens. La version Unix de Plink semble avoir trouvé un public parmi les gens qui trouvent que la complexité d'OpenSSL le rend difficile à installer, et que cela ne dérange pas que Plink n'ait pas autant de fonctionnalités. Certaines personnes, enfin, apprécient de générer un grand nombre de clés SSH sous Unix et veulent pouvoir les copier ensuite dans PuTTY, et la version Unix de PuTTYgen se doit de leur permettre d'automatiser ce processus de conversion.
Il y a aussi des avantages pour nous, l'équipe de développement : le fait de porter PuTTY sous Unix nous a demandé un travail qui bénéficiera directement aux autres portages, et cela nous a permis d'utiliser l'excellent outil Linux de mise au point Valgrind, qui nous a déjà permis d'améliorer la stabilité de PuTTY sur toutes les plateformes.
Cela étant, si vous utilisez Unix et que vous ne voyez aucune raison de passer de OpenSSH à PuTTY et à Plink, ce n'est pas un problème. La version Unix de nos outils n'a pas l'ambition d'être LA seule et unique réponse à tous les besoins de tout le monde.
Nous avons travaillé un petit peu dessus, mais nous n'en sommes pas encore bien loin, et le résultat est loin d'être utilisable. Pour l'instant, cela ne fait plus partie des choses sur lesquelles nous travaillons activement. Cela dit, il existe un portage réalisé par une personne extérieure à l'équipe de développement de PuTTY. Vous pouvez le trouver sur http://www.pocketputty.net/.
PuTTY est une application entièrement 32 bits, qui ne peut donc pas fonctionner sous Windows 3.1 comme le ferait un programme 16 bits natif. Et il serait très difficile de le modifier pour en faire un programme 16 bits, en raison des infâmes mécanismes d'allocation mémoire de Windows 3.1.
Cependant, il reste théoriquement possible de compiler les sources de PuTTY, sans modification, de telle façon que l'application puisse fonctionner sous Win32s ( une extension de Windows 3.1 destinée à permettre l'utilisation de programmes 32 bits ). Pour cela, il vous faudra un compilateur C qui sache générer des binaires compatibles avec Win32s, ce qui n'est pas le cas des versions récentes de Visual C++. De plus, la dernière fois que vous avons essayé, ça n'a pas très bien marché.
Donc, si vous êtes bien motivé(e), et que vous avez vraiment envie de faire tourner PuTTY sous Windows 3.1, votre aide est la bienvenue !
Il y a plusieurs réponses à cette question :
Je l'espère, mais étant donné que les portages n'avancent pas très vite, même sur les systèmes que les développeurs maîtrisent déjà, il risque de passer de l'eau sous les ponts d'ici que l'un d'entre nous arrive à prendre le temps d'apprendre ce nouveau système et de faire le portage correspondant.
Toutefois, une partie du travail a déjà été faite par d'autres personnes, et une version bêta de PuTTY pour la série Nokia 9200 Communicator est disponible ici : http://s2putty.sourceforge.net/
Non. Cela demanderait un certain travail de réécriture pour faire en sorte que ce soit possible, et comme les développeurs du projet PuTTY ne croient eux-mêmes pas aux DLL ( parce qu'ils estiment qu'elles rendent l'installation des programmes sujette aux erreurs ), aucun d'entre nous n'a pris le temps de le faire.
Cela dit, un nettoyage du code ne serait pas une mauvaise chose, donc si quelqu'un se sentait prêt à donner un coup de main de ce côté-là, nous ne dirions pas non.
Non. Aucun des membres de l'équipe PuTTY n'utilise Visual Basic, et aucun d'entre nous n'a besoin d'établir une connexion SSH depuis une application en Visual Basic. Sans compter qu'il faudrait tout un travail préliminaire pour convertir le code correspondant en DLL. En plus, nous ne savons même pas écrire des composants VB. Alors si quelqu'un se propose de le faire à notre place, ça peut s'envisager, mais dans le cas contraire, je n'arrive pas à imaginer l'intégration PuTTY / Visual Basic ailleurs que tout en bas tout en bas de notre liste des priorités.
La meilleure solution, dans votre cas, consiste probablement à utiliser Plink, l'outil de connexion en ligne de commande. Si vous parvenez à démarrer Plink à partir de votre programme, et à faire en sorte que votre programme puisse envoyer des données au processus Plink, et en recevoir de lui, au travers de canaux ( « pipes » ), alors vous devriez pouvoir établir des connexions SSH à partir de votre programme. C'est ce que fait CVS pour Windows, par exemple.
Dans la plupart des cas, PuTTY peut être considéré comme un terminal xterm.
PuTTY reconnaît aussi certaines séquences de contrôle de terminal que ne reconnaît pas le vrai xterm, comme par exemple les séquences de contrôle de la console Linux qui permettent de changer la palette de couleurs, et les séquences de contrôle de la barre de titre qu'utilise DECterm ( ces séquences sont différentes de celles de xterm, et PuTTY les reconnaît toutes les deux ).
Par défaut, PuTTY annonce son type de terminal à la machine distante en se présentant comme un xterm. Si cela vous pose un problème, vous pouvez le reconfigurer pour qu'il annonce quelque chose d'autre, comme vt220, par exemple.
Sous Windows, PuTTY stocke la plupart de ses données ( sessions sauvegardées, clés d'hôtes SSH ) dans la Base de registres. L'emplacement exact est le suivant :
HKEY_CURRENT_USER\Software\SimonTatham\PuTTYet, à l'intérieur de cette zone, les sessions sauvegardées sont stockées dans Sessions, tandis que les clés d'hôtes se trouvent dans SshHostKeys.
PuTTY a aussi besoin d'un fichier dans lequel il stocke la graine destinée au générateur de nombres pseudo-aléatoires, de façon à améliorer le caractère imprévisible des données choisies au hasard qui sont requises dans le cadre du processus de cryptographie SSH. Cette graine est stockée par défaut dans un fichier nommé PUTTY.RND dans votre répertoire personnel Windows ( %HOMEDRIVE%\%HOMEPATH% ), ou dans le répertoire de Windows lui-même ( par exemple C:\WINDOWS ) si vous n'avez pas de répertoire personnel, comme par exemple si vous utilisez Windows 95. Si vous voulez changer l'emplacement du fichier de graine du générateur de nombres pseudo-aléatoires, vous pouvez indiquer l'emplacement de votre choix dans la Base de registres, en le mettant ici :
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFileVous pouvez demander à PuTTY de supprimer toutes ces données ( veuillez vous reporter à la question A.8.2 pour plus d'informations ).
Sous Unix, PuTTY stocke toutes ses données dans le répertoire ~/.putty.
Ce n'est pas à nous que vous devriez poser cette question.
PuTTY est un outil de communication, qui sert à se connecter à d'autres ordinateurs. Nous, nous maintenons l'outil. Nous n'administrons aucun des ordinateurs auxquels vous êtes susceptible de vous connecter, de la même façon que les gens qui écrivent les navigateurs Web ne sont en rien responsables du contenu que vous regardez avec leur programme. Nous ne pouvons pas vous aider pour ce genre de questions.
Si vous connaissez le nom de la machine à laquelle vous voulez vous connecter, mais que vous ne savez pas quel nom d'utilisateur ou quel mot de passe utiliser, vous devriez poser la question à la personne ou aux personnes qui administre(nt) cette machine. Si vous ne savez de qui il s'agit, regardez la question suivante, cela vous aidera à trouver la réponse.
Une fois encore, ce n'est pas à nous que vous devriez poser cette question. Il faut que vous lisiez la documentation, ou que vous demandiez à l'administrateur, de la machine à laquelle vous vous êtes connecté.
PuTTY ne traite pas les commandes que vous tapez. Ce n'est qu'un outil de communication. Il établit la connexion avec un autre ordinateur, lui transmet les commandes que vous tapez dans sa fenêtre, et il vous retransmet ce que l'autre machine renvoie comme réponse. C'est pourquoi la gamme de commandes que vous pouvez utiliser ne dépend pas de PuTTY, mais du type d'ordinateur auquel vous êtes connecté, et des logiciels qui fonctionnent dessus. L'équipe de PuTTY ne peut pas vous aider là-dessus.
Dites-vous que PuTTY est une sorte de téléphone. Si vous appelez quelqu'un et que vous ne savez pas en quelle langue lui parler pour vous faire comprendre, ce n'est pas à le travail de la compagnie de téléphone de le trouver à votre place. Nous, nous fournissons juste le moyen de communication. Arriver à vous faire comprendre, ce n'est pas notre travail à nous.
Si vous ne savez pas par où commencer, pour chercher l'administrateur de la machine distante que vous souhaitez utiliser, ce peut être une bonne idée de commencer par vous demander comment vous avez eu connaissance du nom de la machine distante. Si ce nom vous a été indiqué dans un courrier électronique, par exemple, vous pourriez commencer par poser la question à la personne qui vous a envoyé ce courrier électronique. Si le service informatique de votre société vous a fourni des sessions PuTTY sauvegardées toutes faites, alors ce même service informatique peut probablement aussi vous en dire un peu sur les commandes que vous pouvez/devez taper pendant ces sessions. Quoi qu'il en soit, l'équipe de développement de PuTTY n'administre aucune des machines auxquelles vous êtes susceptible de vous connecter, et ne peut donc pas vous aider à ce niveau-là.
Créez un raccourci Windows pour lancer PuTTY, et configurez-le pour que l'application démarre en plein écran ( réglez la propriété 'Exécuter' du raccourci sur 'Agrandie' ).
Pour lancer une session PuTTY sauvegardée sous le nom 'ma_session', créez un raccourci Windows qui invoque PuTTY avec une ligne de commande telle que celle-ci :
\chemin\d'accès\à\putty.exe -load "ma_session"N.B. : avant la version 0.53, la syntaxe était @session. Cette syntaxe est maintenant obsolète, et il se peut que nous retirions un jour ou l'autre la partie du programme qui assure la reconnaissance de cette syntaxe.
Utilisez la ligne de commande putty -ssh host.name. Vous pouvez aussi créer une session PuTTY sauvegardée qui indique d'utiliser le protocole SSH, et démarrer la session sauvegardée comme cela est indiqué dans la question A.6.4.
Le copier/coller fonctionne de la même manière dans PuTTY et dans le système X Window. Utilisez le bouton gauche de la souris pour sélectionner du texte dans la fenêtre de PuTTY. Le fait de sélectionner copie automatiquement ce texte dans le presse-papiers : il n'y a pas besoin d'appuyer sur Ctrl-Ins, ou Ctrl-C, ou quoi que ce soit d'autre. Attention, d'ailleurs, si vous appuyez sur Ctrl-C, cela va envoyer un caractère Ctrl-C à la machine distante, ce qui peut avoir des effets indésirables. La seule chose que vous ayez à faire, pour copier du texte dans le presse-papiers, c'est de le sélectionner ( avec le bouton gauche ).
Pour coller le contenu du presse-papiers dans la fenêtre de PuTTY, par défaut, il vous suffit de cliquer avec le bouton droit. Si vous avez une souris à trois boutons, et que vous avez l'habitude d'utiliser des applications X, vous pouvez configurer PuTTY pour que le 'coller' se fasse avec le bouton du milieu, plutôt qu'avec le bouton droit, mais ce n'est pas le comportement par défaut, parce que la plupart des souris utilisées sur les PC Windows n'ont que deux boutons.
Vous pouvez également coller le contenu du presse-papier en appuyant sur Maj-Inser ( Shift-Ins ).
La plupart des fonctionnalités principales ( comme par exemple les clés publiques, ou le transfert de port ) sont disponibles sous forme d'options de ligne de commande. Veuillez consulter la documentation.
Cela étant, toutes les fonctionnalités ne sont pas encore disponibles à partir de la ligne de commande, même si cela fait partie de nos objectifs. D'ici là, vous pouvez utiliser la plupart des fonctionnalités de PuTTY en passant par une session PuTTY sauvegardée, puis en utilisant le nom de cette session sauvegardée en ligne de commande, à la place du nom de la machine distante. Cela fonctionne pour PSCP, PSFTP et Plink ( mais n'espérez pas faire du transfert de port dans les applications de transfert de fichiers ! ).
PSCP est une application en ligne de commande, pas une application dotée d'une interface utilisateur graphique. Si vous lancez PSCP sans arguments, l'application affiche simplement un message d'aide et se termine.
Pour utiliser PSCP correctement, lancez-le à partir d'une invite de commandes ( veuillez vous reporter au chapitre 5 pour plus de détails ).
Si PSCP utilise le protocole SCP traditionnel, il faut faire attention, car plusieurs cas se présentent : si le nom de fichier que vous indiquez correspond à un fichier situé en local, sur votre PC à vous, alors mettez le nom du fichier entre quotes ( guillemets ), avec une seule paire de quotes, comme vous le feriez en temps normal :
pscp "nom de fichier local avec des espaces" utilisateur@machine_distante:
pscp utilisateur@machine_distante:nom_de_fichier_distant_sans_espaces "nom de fichier local avec des espaces"Par contre, si le nom de fichier correspond à un fichier situé sur la machine distante, il faut utiliser des barres obliques inverses et deux paires de quotes :
pscp utilisateur@machine_distante:"\"nom de fichier distant avec des espaces\"" local_filename
pscp nom_de_fichier_local_sans_espaces utilisateur@machine_distante:"\"nom de fichier distant avec des espaces\""Pire encore, dans le cas d'une copie depuis la machine distante vers le PC local, vous devez indiquer explicitement le nom local du fichier, faute de quoi PSCP va se plaindre que les deux noms ne correspondent pas ( sauf si vous ajoutez l'option -unsafe ). La commande suivante donne donc un message d'erreur :
c:\>pscp utilisateur@machine_distante:"\"oo er\"" .
warning: remote host tried to write to a file called 'oo er'
when we requested a file called '"oo er"'.Pour éviter cela, il faut que vous mettiez le nom local du fichier en entier :
c:\>pscp utilisateur@machine_distante:"\"oo er\"" "oo er"En revanche, si PSCP utilise le protocole SFTP, plus récent, aucun de ces problèmes ne se pose, puisqu'il suffit de mettre les noms comportant des espaces entre quotes ( une seule paire de quotes ), comme on le ferait spontanément :
pscp "fichier local" utilisateur@machine_distante:
pscp utilisateur@machine_distante:"fichier distant" .L'une des causes possibles d'apparition de ce message, qui était assez répandu, à une époque, tient à un bug dans les anciens serveurs SSH-2 de ssh.com ( mais ce n'est pas la seule cause possible, veuillez vous référer à la section 10.11 pour plus d'informations ). Les versions de leur serveur SSH-2 jusqu'à la 2.3.0 fabriquaient de façon erronée les codes d'authentification des messages, et attendaient de la part du client SSH qu'il en fasse autant. Par défaut, PuTTY fabrique correctement ces codes d'authentification, ce qui explique les problèmes rencontrés par les utilisateurs de PuTTY avec ces anciens serveurs.
Si vous utilisez PuTTY 0.52 ou une version plus récente, tout devrait fonctionner correctement. En effet, maintenant, PuTTY doit normalement détecter ces anciens serveurs buggés d'après le numéro de version qu'ils annoncent lors de l'établissement de la connexion, et à partir de là, il se met à fabriquer les codes d'authentification des messages de la façon erronée qu'attend l'autre machine, ce qui permet la communication avec ces anciennes versions de serveurs.
Si vous utilisez encore PuTTY 0.51 ou une version plus ancienne, vous pouvez activer le contournement de ce bug en allant dans le panneau de configuration SSH, et en cochant la case intitulée 'Imitate SSH2 MAC bug'. Il se peut que vous deviez faire cela aussi avec la version 0.52, ou une version plus récente, si jamais le serveur SSH de la machine distante présente ce bug, mais qu'il n'est pas recensé comme tel dans PuTTY.
Dans ce contexte, les trois lettres MAC signifient Message Authentication Code ( code d'authentification de message ). C'est un terme utilisé en cryptographie, qui n'a rien à voir avec les adresses MAC ( dans le contexte d'un réseau Ethernet, MAC signifie Media Access Control ).
Ceci se produit parce que PSCP s'attendait à recevoir du serveur des données faisant partie des échanges liés au protocole PSCP, et qu'au lieu de cela, il a reçu des données qu'il n'a pas compris, et dont il n'a su que faire. Ce message est presque toujours dû au fait que des scripts de démarrage associés à votre compte sur la machine distante produisent des sorties qui sont envoyées via la connexion PSCP au lieu d'être affichées à l'écran de la machine distante. Il est impossible d'éviter cela, que ce soit pour PSCP ou pour un autre client SCP. Pour bien faire, vous ne devriez jamais utiliser de scripts de démarrage ( .bashrc, .cshrc, etc. ) qui affichent des choses pendant les sessions non-interactives.
Ce n'est pas réellement un problème lié à PuTTY. Si PSCP se comporte de cette manière, alors il y a de bonnes chances que tous les autres clients SCP en fassent autant. Le problème se situe côté serveur.
Il ne faut pas se méprendre sur le rôle de la liste déroulante de couleurs qui figure dans le panneau de configuration 'Colours', où l'on trouve notamment des couleurs ANSI ( de 'ANSI Black' jusqu'à 'ANSI White Bold' ).
Par défaut, PuTTY affiche le texte en blanc sur fond noir, mais il ne faut pas croire que la liste des couleurs du panneau 'Colours' sert à choisir une autre couleur, pour que PuTTY affiche son texte en vert sur fond noir au lieu de blanc sur fond noir, par exemple ( d'ailleurs, ce n'est pas du vrai blanc, en réalité, mais du gris clair ). Ces couleurs sont des couleurs 'logiques', aussi bien les couleurs ANSI que les six premières couleurs de la liste ( de 'Default Foreground' à 'Cursor Colour' ). Et PuTTY peut toutes les utiliser au cours d'une session, même si la plupart du temps, il n'en utilise que deux ( les couleurs d'avant-plan et d'arrière-plan par défaut ).
Le panneau de configuration 'Colours' sert à vous permettre de choisir la nuance de couleur ( la couleur 'réelle' ) associée à chacune de ces couleurs 'logiques'. Pour changer la couleur du curseur, par exemple, il faut choisir 'Cursor Colour', cliquer sur le bouton 'Modify', et sélectionner une nouvelle couleur dans la boîte de dialogue qui apparaît à ce moment-là. De la même manière, si vous voulez que le texte principal de votre session soit affiché en vert, prenez 'Default Foreground', cliquez sur 'Modify', et choisissez une autre couleur. Mais le fait de cliquer sur 'ANSI Green' ( autrement dit 'vert ANSI' ) ne va pas faire passer l'affichage instantanément au vert. Cela vous permet uniquement de choisir la teinte de vert utilisée lorsque PuTTY reçoit de la machine distante l'ordre d'afficher du texte en vert ANSI.
NdT : les explications d'origine ne me semblaient pas tout à fait limpides, donc je me suis permis de reformuler ce paragraphe, plutôt que de le traduire simplement. J'espère que l'auteur de cette partie de la documentation d'origine ne m'en voudra pas...
WS2_32.DLL.Plink a besoin de la version étendue de la bibliothèque réseau Windows pour fonctionner, la WinSock version 2. Celle-ci est installée en standard sous Windows 98 et les versions suivantes, et sous Windows NT, ainsi que sur les dernières versions de Windows 95, mais les premières versions de Windows 95 ne l'avaient pas.
Pour pouvoir utiliser Plink avec ces versions de Windows, il vous faut télécharger la mise à jour WinSock 2 :
http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/Si cela se produit juste lors de l'établissement de la connexion, c'est souvent l'indication que pour une raison ou pour une autre, le client et le serveur n'ont pas réussi à se mettre d'accord sur une clé de cryptage de la session. Ils ont effectués chacun de leur côté des calculs qui auraient normalement dû leur donner la même clé, mais qui ont donné des résultats différents, sans que l'on sache pourquoi. Résultat, les données cryptées par l'un et décryptées par l'autre, ou l'inverse, ne ressemblent à rien d'autre que de la « bouillie ».
Cela provoque une erreur 'Out of memory' ( à court de mémoire ) parce que la première donnée que PuTTY s'attend à trouver est la longueur du message SSH. Normalement, ce doit être une valeur inférieure à 100 octets. Si le décryptage échoue, PuTTY se retrouve avec une longueur de message complètement aléatoire, qui peut aller jusqu'à deux giga-octets, et va essayer d'allouer suffisament de mémoire pour stocker ce message qui n'existe pas. Cela va immédiatement lui faire croire qu'il n'a pas pas suffisament de mémoire, et le faire paniquer.
Si cela vous arrive, il est assez probable que ce soit un bug de PuTTY, et vous devriez le signaler ( bien que cela puisse aussi être un bug dans le serveur SSH ). Mais cela ne veut pas nécessairement dire que vous êtes réellement à court de mémoire.
La cause de ce problème est presque toujours liée à un script d'ouverture de session, exécuté côté serveur, qui affiche du texte ( en fait : qui vous envoie du texte via la connexion, pour qu'il soit affiché sur votre PC à vous ). PSCP et PSFTP reçoivent ce texte, à un moment où ils attendaient le début des échanges liés au protocole de transfert de fichiers, et ils essaient de l'interpréter, alors que ça n'a aucun sens au niveau du protocole. Cela donne généralement lieu à une erreur 'Out of memory' ( autrement dit « à court de mémoire », ou « mémoire insuffisante » ) pour quasiment les mêmes raisons que celles expliquées dans la réponse à la question A.7.5.
Ceci est un problème de configuration au niveau de votre compte utilisateur sur la machine distante, ce n'est pas un bug de PSCP ou PSFTP. Vos scripts d'ouverture de session ne devraient jamais rien afficher pendant des sessions non interactives, et le transfert de fichiers sécurisé n'est pas le seul genre d'applications qui peut « partir en vrille » dans un cas comme celui-ci.
Sous Unix, une solution simple consiste à vérifier que toutes les commandes de votre script d'ouverture de session qui pourraient éventuellement vouloir afficher du texte se trouvent dans .profile ( si vous utilisez le shell Bourne ou l'une de ses variantes, telle que bash ) ou dans .login ( si vous utilisez le shell C ). Le fait de placer ces commandes dans des fichiers plus généraux tels que .bashrc ou .cshrc est susceptible de causer des ennuis.
Le débit de PSFTP devrait être bien meilleur depuis la version 0.54, par rapport à la 0.53b et aux versions précédentes. Nous avons fait le nécessaire dans SFTP pour qu'il soit possible de mettre plusieurs blocs de données en file d'attente, plutôt que d'attendre un acquittement pour chacun d'entre eux ( le client SCP n'avait pas ce problème de performance, parce que le protocole SCP est bien plus simple que SFTP ).
Il faut probablement que vous changiez le réglage 'Use background colour to erase screen' ( [NdT] « Utiliser la couleur d'arrière-plan pour effacer l'écran » ), dans le panneau de configuration Terminal. S'il y a trop de noir ( ce qui est le plus fréquent ), vous devriez cocher la case, alors que s'il y a trop de couleurs, vous devriez la décocher ( veuillez vous reporter à la section 4.3.4 ).
Dans les anciennes versions de PuTTY, ce réglage était désactivé par défaut, et les changements n'étaient pas pris en compte tant qu'on ne redémarrait pas le terminal ( cf. question A.7.9 ). Depuis la version 0.54, ce réglage est activé par défaut, et les changements sont pris en compte immédiatement.
Certaines options de terminal ( notamment 'Auto Wrap' et 'Background-colour screen erase' ) sont en réalité les réglages par défaut, et non la valeur sélectionnée à un instant donné. La machine distante peut envoyer des séquences de contrôle qui modifient ces options en cours de session, mais lorsque le terminal est réinitialisé ( du fait du serveur, ou si vous, vous choisissez 'Reset Terminal' dans le menu système ), les valeurs par défaut sont restaurées.
Dans PuTTY 0.53b et les versions précédentes, si vous changez l'une de ces options en cours de session, vous constaterez que la modification n'est pas immédiate. Elle ne prend effet que lorsque vous réinitialisez le terminal.
Depuis la version 0.54, les modifications apportées à ces options prennent effet immédiatement.
Certains types de pare-feu, et quasiment tous les routeurs qui font du NAT ( Network Address Translation = IP masquerading = translation d'adresses réseau ), vont finir par « oublier » une connexion qui transite par eux, si aucun échange n'a lieu pendant un certain temps. Résultat, la connexion est interrompue brutalement au rétablissement du contact, lorsqu'il y a à nouveau des échanges.
Vous pouvez essayer de lutter contre cela en demandant à PuTTY d'envoyer des signes de vie ( des « keepalives » ), autrement dit des paquets de données qui n'ont pas d'effet réel sur la session, mais qui signalent au routeur ou au pare-feu que la connexion réseau est toujours active, et qu'il faut en garder trace.
Les signes de vie ne sont toutefois pas LA solution miracle. Bien qu'ils permettent aux connexions de mieux « résister » à ce genre de routeurs, ils provoquent également une moindre robustesse contre les pertes de connexion réseau ( veuillez vous reporter à la section 4.13.1 pour plus d'informations à ce sujet ).
C'est un problème Windows, pas un problème PuTTY. La valeur du timeout ne peut pas être réglée application par application, ou session par session. Pour augmenter globalement la valeur du timeout TCP, il faut aller faire la modification dans la Base de registres.
Sous Windows 95, 98 ou Millenium, la clé de Base de registres que vous devez créer ou modifier est celle-ci :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
MSTCP\MaxDataRetriesCette clé doit être de type DWORD sous Win95, et de type String sous Win98/ME ( veuillez vous reporter à l'article 158474 de la base de connaissance Microsoft, la « MS Knowledge Base » pour plus d'informations à ce sujet ).
Sous Windows NT, 2000, et XP, la clé à créer ou modifier est celle-ci :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\TcpMaxDataRetransmissionset elle doit être de type DWORD ( veuillez vous reporter aux articles 120642 et 314053 de la « Knowledge Base » pour plus d'informations ).
Donnez à cette clé une valeur de l'ordre de 10. De cette façon, Windows s'efforcera de garder les connexions ouvertes, au lieu de les abandonner.
cat sur un fichier binaire, j'obtiens 'PuTTYPuTTYPuTTY' à répétition sur ma ligne de commande.Eh bien, ne le faites pas, alors...
En fait, c'est un comportement tout à fait normal : lorsque PuTTY reçoit le caractère Control-E de la machine distante, il l'interprète comme une demande d'identification, et c'est pour cela qu'il renvoie la chaîne 'PuTTY', comme si cette chaîne avait été tapée au clavier. Le caractère Control-E ne devrait normalement être émis que par les programmes qui sauront quoi faire de la réponse. Il est probable que le fait d'afficher un fichier binaire sur votre terminal va provoquer l'apparition de nombreux caractères Control-E, et induire ce résultat. Alors ne le faites pas, ce n'est pas une bonne idée.
Pour limiter les effets indésirables, vous pourriez faire en sorte que la chaîne renvoyée en réponse au caractère Control-E soit la chaîne vide ( pour plus d'infos à ce sujet, veuillez vous reporter à la section 4.3.6 ), mais il est probable que le fait de faire afficher des fichiers binaires sur votre terminal provoquera d'autres résultats déplaisants, donc ce n'est qu'un pis-aller.
cat sur un fichier binaire, le titre de la fenêtre se met à afficher n'importe quoi.Eh bien, ne le faites pas, alors...
PuTTY se doit de savoir modifier le titre de sa fenêtre en réponse à des instructions reçues de la machine distante. Normalement, la séquence de caractères de contrôle qui provoque ce résultat ne devrait être émise que volontairement, par des programmes qui savent ce qu'ils font et qui souhaitent réellement modifier le titre de la fenêtre du terminal. Le fait de faire afficher des fichiers binaires sur votre terminal induit le risque que cette même séquence de contrôle soit émise par accident, et provoque des modifications inattendues dans le titre de la fenêtre. Ne le faites pas.
Rassurez-vous, votre clavier va très bien : c'est juste que PuTTY n'affiche strictement rien quand vous tapez un mot de passe, même pas des étoiles ou des petits ronds noirs, contrairement à ce qui se passe quand vous ouvrez votre session Windows. Comme cela, si quelqu'un regarde par dessus votre épaule, il ne pourra rien voir, même pas le nombre de caractères qu'il y a dans votre mot de passe, ce qui serait une information intéressante pour quelqu'un de mal intentionné.
Si vous avez déjà essayé toutes les options appropriées dans le panneau de configuration 'Keyboard' de PuTTY, il se peut que vous ayez besoin d'envoyer un e-mail aux mainteneurs de PuTTY et de leur soumettre votre problème.
Il n'est généralement pas utile de nous dire juste quelle application pose problème, avec quel système d'exploitation côté serveur, et quelle est la touche qui ne fonctionne pas comme vous le voudriez. Pour que nous puissions reproduire le problème, il faudrait que nous ayons un exemplaire de chacun des systèmes d'exploitation, et de chacune des applications, au sujet desquels quelqu'un s'est plaint ne serait-ce qu'une fois.
PuTTY réagit à l'appui sur les touches de fonction en envoyant une séquence de caractères de contrôle à la machine distante. Si une touche de fonction ne fait pas ce que vous voudriez qu'elle fasse, il y a des chances que la séquence de caractères que votre application s'attend à recevoir ne soit pas la même que celle que PuTTY lui envoie. Par conséquent, ce que nous avons réellement besoin de savoir, c'est quelle séquence l'application attend.
La façon la plus simple d'enquêter à ce sujet, c'est de trouver un autre environnement de terminal, dans lequel cette touche de fonction fait effectivement ce que vous en attendez, et partant de là, de chercher quelle séquence de caractères la touche de fonction émet dans cette situation. Une façon raisonnablement facile de faire cela, sur un système Unix, consiste à taper la commande cat, puis à appuyer sur la touche de fonction en question. Il y a des chances que cela donne quelque chose du genre ^[[11~. Vous pouvez faire pareil dans PuTTY, et voir ainsi quelle séquence de caractères la touche de fonction génère, pour comparer. Une fois que c'est fait, vous pouvez envoyer un mail aux mainteneurs de PuTTY, et nous dire ( en anglais, SVP ) « Je voudrais que la touche F1 ( par exemple ) envoie ^[[11~, et au lieu de ça, elle envoie ^[OP, pouvez-vous jeter un coup d'oeil, SVP ? » ( « I wanted the F1 key to send ^[[11~, but instead it's sending ^[OP, can this be done, please? » ). Ou quelque chose dans ce genre.
Vous devriez quand même lire la page Feedback du site web de PuTTY ( qui figure aussi dans l'annexe B de cette documentation ), et suivre les indications qui y sont données.
Il y a un problème connu qui se pose lorsque OpenSSH a été compilé avec une version incorrecte de OpenSSL. Un contournement rapide à ce problème consiste à configurer PuTTY pour qu'il utiliser la version 2 du protocole SSH et le cryptage Blowfish.
Pour plus de détails à ce sujet, et pour obtenir les patches de OpenSSH, veuillez vous reporter au bug 138 dans le système de suivi des bugs de OpenSSH.
Ce n'est pas un problème spécifique à PuTTY. Si vous essayez de vous connecter à la machine distante avec un autre client SSH, vous rencontrerez des problèmes similaires ( bien que le cryptage par défaut de PuTTY diffère de celui de nombreux autres clients ).
Les configurations suivantes de OpenSSH 3.1p1 sont connues pour poser des problèmes, et voici quels en sont les symptômes :
sshaes.c, ou 'Out of memory', ou plante )À partir de la version OpenSSH 3.4p1, seul le problème avec SSH-1 et Blowfish demeure. Recompilez votre serveur, appliquez le correctif correspondant au bug 138 ci-dessus, ou utilisez un autre cryptage, comme 3DES, par exemple.
En ce qui concerne les autres versions, on nous signale de temps à autre que les mêmes symptômes se manifestent avec des versions plus anciennes de OpenSSH, et que les mêmes contournements s'appliquent, mais il n'est pas établi que la cause sous-jacente soit effectivement la même.
Il est probable que vous avez généré une clé correspondant à la version 2 du protocole SSH avec PuTTYgen, mais que vous essayez de l'utiliser dans une connexion SSH-1. Les clés SSH-1 et SSH-2 ont des formats différents, et ( au moins dans la version 0.52 ) la façon dont PuTTY signale que la clé n'est pas dans le bon format n'est pas optimale.
Pour vous connecter avec SSH-2 à un serveur qui accepte les deux versions, il faut que vous le sélectionniez explicitement ( champ 'Prefered SSH protocol version' dans le panneau de configuration 'SSH' ).
On nous signale fréquemment que les tirets et autres traits d'union des pages de manuel Unix sont remplacés à l'affichage par des a accent aïgu ( á ).
Au moment de la sortie de la version 8.0, Red Hat semble avoir fait d'UTF-8 le jeu de caractères par défaut, mais les émulateurs de terminal tels que PuTTY n'ont pas de moyen de le savoir ( pour autant que nous le sachions, la séquence d'échapement qui sert à passer en mode UTF-8 n'est pas émise ).
Une solution consiste à configurer les sessions de connexion à des machines RH8 pour qu'elles utilisent la traduction UTF-8 ( cf. section 4.10.1 ). Notez que si vous utilisez 'Change Settings', les modifications peuvent ne pas être effectives immédiatement - voir à ce sujet la question A.7.9.
Si vous voulez vraiment changer le jeu de caractères utilisé par la machine distante, c'est dans /etc/sysconfig/i18n qu'il faut aller, mais cela ne devrait pas être nécessaire.
screen.L'émulateur de terminal de PuTTY a toujours eu pour principe de ne rien ajouter au tampon de défilement arrière lorsque l'écran secondaire ( cf. [NdT] ci-dessous ) est en cours d'utilisation, parce que les programmes qui se servent habituellement de l'écran secondaire sont des programmes du genre éditeur de texte, qui ont tendance à user et abuser du défilement, dans un sens et dans l'autre, au sein d'un même document. Non seulement, si on les laissait faire, ils rempliraient rapidement le tampon de défilement arrière avec de grandes quantités de texte inutile et désordonné, mais en plus, ils contiennent leur propre méthode pour permettre à l'utilisateur d'atteindre un endroit précis dans le document. Nous avons donc décidé, par expérience, que c'était LA bonne chose à faire dans quasiment toutes les situations.
[NdT] : l'écran secondaire dont il est question ici est une zone réservée, à l'intérieur de la mémoire de l'ordinateur, qui permet d'avoir le contenu de deux écrans, présents en mémoire en même temps, et de passer instantanément de l'un à l'autre : absolument rien à voir avec les cartes graphiques récentes, qui sont capables de gérer deux moniteurs à la fois.
Malheureusement, screen est en quelque sorte l'exception qui confirme la règle, puisqu'il utilise l'écran secondaire, mais que pendant l'utilisation de screen, il est quand même utile que le défilement arrière de PuTTY continue de fonctionner. La solution la plus simple consiste à aller dans le panneau de configuration 'Features', et à cocher la case 'Disable switching to alternate terminal screen' ( autrement dit : désactiver le basculement vers l'écran secondaire ). Veuillez vous reporter à la section 4.6.4 pour plus de détails. Autre solution, vous pouvez dire à screen lui-même de ne pas utiliser l'écran secondaire. La Foire Aux Questions de screen suggère d'ajouter la ligne 'termcapinfo xterm ti@:te@' à votre fichier .screenrc.
Si cela ne pose problème que depuis la version 0.54 de PuTTY, c'est parce que screen utilise une séquence de contrôle inhabituelle pour basculer vers l'écran secondaire, et que les versions de PuTTY antérieures à la 0.54 ne reconnaissaient pas cette séquence.
127.0.0.2.Certaines personnes qui demandent à PuTTY d'écouter sur des adresses de type 'localhost' autres que 127.0.0.1, pour faire transiter des services tels que SMB et Windows Terminal Services, ont découvert que cela ne fonctionne plus après avoir installé le Service Pack 2 de Windows XP.
Il semble que ce soit un problème lié au SP2 dont Microsoft fait état dans l'article 884020 de la base de connaissance Microsoft ( MS Knowledge Base ). L'article comporte un lien qui permet de télécharger un correctif.
Ceci dit, nous avons également entendu dire que le Service Pack 2 corrigeait aussi le bug qui rendait nécessaire le recours à des adresses 'loopback' autres que 127.0.0.1 pour faire transiter les connexions Terminal Services.
Certaines personnes ont signalé le comportement suivant de PSFTP, qui est incorrect :
psftp> pwd
Remote directory is /dir1/dir2
psftp> get filename.ext
/dir1/dir2filename.ext: no such file or directoryCeci n'est pas un bug dans PSFTP. Il y a un bug connu dans certaines versions de la variante portable de OpenSSH ( bug 697 ) qui provoque ces symptômes. Il semblerait que ce bug ait été introduit aux alentours de la version 3.7.x. Il ne se manifeste que sur certaines plates-formes ( on nous l'a signalé sous AIX ).
Il y a un correctif pour OpenSSH correspondant à ce bug. Il est également résolu dans les versions récentes de la variante portable de OpenSSH ( depuis aux alentours de la version 3.8 ).
Dans la documentation des versions 0.53 et 0.53b de PuTTY, nous disions que nous aimerions être tenus au courant quand cette erreur se produit. Depuis la sortie de PuTTY 0.54, cependant, nous sommes convaincus que cette erreur n'est pas révélatrice d'un mauvais fonctionnement de PuTTY, et il n'est plus utile de nous signaler cette erreur si vous la rencontrez. Veuillez vous reporter à la section 10.14 pour des informations à jour au sujet de cette erreur.
Les versions récentes de PuTTY lancent automatiquement un renouvellement des clés une fois toutes les heures, pour augmenter la sécurité de la session. Si l'une des deux machines, votre PC ou la machine distante, est un peu lent, il se peut que cela vous donne l'impression d'un blocage d'environ une trentaine de secondes ( maximum ).
Ces délais sont malcommodes, c'est vrai, mais ils sont là pour votre protection. Si cela vous cause vraiment un problème, vous pouvez désactiver volontairement le renouvellement périodique des clés, en allant dans le panneau de configuration 'Kex' ( voir à ce sujet la section 4.19 ), mais soyez bien conscient que c'est au détriment de la sécurité ( revenir à SSH-1 aurait aussi pour effet de supprimer ces délais, mais cela serait encore bien plus gênant en termes de sécurité ). Nous ne le recommandons pas.
C'est dû à un bug de certaines versions de Windows XP, qui se manifeste dans PuTTY 0.58. Le problème a été corrigé dans la version 0.59. Pour plus de détails à ce sujet, veuillez consulter l'entrée ‘xp-wont-run’ dans la page des desiderata de PuTTY.
Tout dépend si vous pensez pouvoir utiliser ce PC en toute confiance, ou non. Si vous n'avez pas confiance dans un PC, alors il ne faut utiliser dessus ni PuTTY, ni aucun autre logiciel dans lequel vous pouvez avoir besoin de taper des mots de passe. Il se peut qu'un enregistreur de frappes clavier ( un keylogger ) soit installé dessus, ou que "quelque chose" vienne modifier le binaire de PuTTY que vous téléchargez. Il n'existe aucun programme informatique qui soit suffisament sûr pour que vous puissiez l'utiliser et taper des mots de passe dedans en toute confiance, s'il est installé sur un PC qui a été compromis par des programmes mal intentionnés.
Si vous pensez pouvoir utiliser le PC en confiance, alors vous pouvez sans doute utiliser PuTTY dessus sans problème ( mais si vous craignez que le réseau lui-même ne soit compromis, et donc que le binaire de PuTTY que vous téléchargez ne risque d'avoir été modifié par une personne mal intentionnée, alors il vaut sans doute mieux amener votre propre exemplaire de PuTTY sur une disquette ou une clé USB ).
PuTTY laisse quelques entrées dans la Base de registres, et un fichier graine pour le générateur de nombres pseudo-aléatoires ( cf. question A.5.2 ). Si vous utilisez PuTTY sur un PC public, ou sur la machine de quelqu'un d'autre, c'est une bonne idée de les effacer une fois que vous avez fini. Vous pouvez le faire automatiquement, en lançant la commande putty -cleanup ( N.B. : sur un système multi-utilisateurs, cela n'enlève ce fichier et ces entrées de Base de registres que pour l'utilisateur courant ).
Si PuTTY a été installé avec le programme d'installation, il apparaît également dans la liste 'Ajout/Suppression de programmes'. Les versions anciennes du désinstalleur ne suppriment pas ce fichier et ces entrées de Base de registres.
DSA présente un défaut de sécurité majeur s'il est mal implémenté : son fonctionnement est beaucoup trop dépendant du générateur de nombres pseudo-aléatoires. Si ce générateur de nombres pseudo-alétoires produit des séquences de nombres qu'un attaquant peut réussir à prédire, alors la clé privée DSA est en danger - cela signifie que le pirate peut potentiellement se faire passer pour vous sur tous les systèmes qui acceptent cette clé.
Nous avons changé d'avis au sujet du cryptage DSA lorsque nous avons appris qu'il existait des moyens de l'implémenter, qui ne présentent pas ces défaut de sécurité, et qui ne reposent d'ailleurs pas du tout sur des nombres pseudo-alétoires. C'est la raison pour laquelle nous pensons que le cryptage DSA, tel qu'il est implémenté dans PuTTY, peut être utilisé sans crainte. Cependant, si vous en avez la possibilité, nous vous recommandons d'utiliser plutôt le cryptage RSA.
VirtualLock() pour empêcher les clés privées d'être écrites sur le disque ?Malheureusement non. La fonction VirtualLock() de l'API Windows ne convient pas pour cela : elle peut effectivement empêcher que de petites parties de la mémoire allouée à un processus ne soient 'swappées' sur le disque dur pendant que le processus est actif, mais elle n'empêche pas que la totalité de la mémoire allouée au processus ne soit 'swappée' sur le disque lorsque le processus reste longtemps inactif. Et Pageant passe le plus clair de son temps à ne rien faire.
C'est gentil de proposer, mais non, merci. Même si vous arriviez à en trouver un ( la plupart d'entre eux semblent avoir déjà été réservés, par des gens qui ne nous ont pas demandé si nous les voulions ), l'adresse actuelle du site de PuTTY nous convient très bien comme elle est. Elle n'est pas difficile à trouver ( il suffit de taper 'putty' dans Google, nous sommes le premier résultat renvoyé ), et nous ne sommes pas convaincus que le travail administratif que cela nous demanderait pour déplacer le site en vaille la peine.
De plus, même si nous voulions un nom de domaine personnalisé, nous voudrions le gérer nous-mêmes, de façon à pouvoir être sûrs qu'il pointe bien toujours là où nous voulons qu'il pointe, et qu'il ne risque pas de changer subitement, ou de faire des choses bizarres dans ce genre-là. Faire enregistrer notre nom de domaine par une tierce personne, qui ferait cela pour nous alors que nous ne connaissons même pas cette personne, n'est sans doute pas la meilleure manière d'atteindre ce but.
Merci, mais le site de PuTTY est déjà hébergé gratuitement.
Uniquement si le contenu de votre site présente un intérêt évident pour les utilisateurs de PuTTY. Si son contenu n'a rien à voir avec PuTTY, ou seulement de loin, alors le lien que vous nous demandez serait tout simplement de la pub pour votre site.
L'un des bons côtés du mécanisme de classement de Google ( le "pagerank" ), c'est que les sites les plus populaires obtiennent les meilleurs classements, de loin. Cela veut dire que quand une personne ordinaire fait une recherche ( par "personne ordinaire", nous voulons dire "pas quelqu'un qui connaît à fond les moteurs de recherche, et qui sait comment influer sur les résultats" ), le site qui apparaît tout en haut, dans les résultats, a de grandes chances d'être un site de grande qualité, ou le site que cherche effectivement la personne, plutôt qu'un site qui a dépensé plein d'argent pour obtenir un bon classement.
Le site web de PuTTY est tenu en haute estime par Google, précisément pour cette raison : beaucoup de gens ont fait pointer des liens vers ce site, simplement parce qu'ils apprécient PuTTY, sans que nous leur ayons jamais demandé quoi que ce soit. Nous considérons que ce serait abuser de cette estime que de l'utiliser pour améliorer le classement Google des sites de tel ou tel annonceur. Si vous voulez que votre site web ait un aussi bon classement Google que le nôtre, faites plutôt comme nous : soyez assez bons dans votre domaine pour que les gens mettent d'eux-mêmes des liens qui pointent chez vous, simplement parce qu'ils vous apprécient.
En particulier, cela ne nous intéresse pas de mettre en place des liens pour de l'argent ( cf. ci-dessus ), et encore moins de mettre en place des liens en échange d'autres liens ( dans la mesure où il n'y a pas de publicités sur notre site, notre classement chez Google ne présente même pas d'intérêt direct à nos yeux ). Si nous ne voulons pas mettre sur notre site de liens pointant sur le vôtre à titre gratuit, alors il est probable que nous n'avons pas envie d'en mettre du tout, indépendamment de toute histoire d'argent.
Si l'un de vos logiciels est basé sur PuTTY, ou conçu spécifiquement pour interagir avec PuTTY, ou qu'il présente d'une façon ou d'une autre un réel intérêt pour les utilisateurs de PuTTY, alors nous ajouterons sans doute volontiers un lien pointant chez vous sur notre page 'Links'. Et si vous avez un miroir du site web de PuTTY, alors là, oui, cela nous intéresse.
En partie parce que nous ne voulons pas changer l'adresse du site ( cf. question A.9.1 ). Mais ce n'est pas la seule raison.
C'est aussi pour des raisons de sécurité. PuTTY est un logiciel qui a trait à la sécurité, et en tant que tel, il est particulièrement important de protéger le code et le site contre toute modification non autorisée, qui risquerait d'introduire de subtiles failles de sécurité. En conséquence, nous préférons que le référentiel Subversion, le site web et le site FTP restent là où ils sont, sous le contrôle direct d'administrateurs système que nous connaissons personnellement et en qui nous avons confiance, plutôt que les faire administrer par une grande organisation pleine de gens que nous n'avons jamais rencontrés, et dont on sait qu'elle a reçu plusieurs fois la visite de pirates, par le passé. Que les gens de SourceForge ne le prennent pas mal. Je pense qu'ils font un boulot super. Mais leur système d'hébergement ne peut pas convenir pour tout le monde, et en particulier, il ne convient pas dans notre cas.
Parce que vous ne faites pas partie de l'équipe de développement de PuTTY. La liste de diffusion 'putty-bugs' n'est pas un forum de discussion façon newsgroup. C'est une adresse de contact pour les développeurs qui sont au coeur de PuTTY, et une liste de diffusion à usage interne pour que nous puissions discuter entre nous de choses et d'autres. Si nous l'ouvrions à tout un chacun, cela deviendrait quelque chose comme un newsgroup, et nous serions complètement dépassés par le volume des échanges. Nous avons déjà bien assez de mal pour suivre les discussions sur la liste telle qu'elle est.
À notre connaissance, il n'y en a pas. Si quelqu'un veut mettre en place une liste de diffusion, ou un forum de discussion, pour que les utilisateurs de PuTTY puissent s'entraider, cela ne nous pose aucun problème. L'équipe de PuTTY n'aura toutefois sans doute pas le temps de la lire. Il vaut sans doute mieux utiliser l'un des groupes de discussion qui existent déjà pour cela ( cf. section B.1.2 ).
S'il vous plaît, ne vous croyez pas obligé de le faire. Vraiment. PuTTY est gratuit, ce n'est pas un shareware ( un "partagiciel", en bon français ). Nous estimons qu'il est très important que quiconque souhaite utiliser PuTTY puisse le faire, que cette personne ait de l'argent ou non. Nous ne souhaitons vraiment pas qu'un utilisateur de PuTTY se sente coupable de ne pas nous avoir payé quoi que ce soit. Si vous voulez garder votre argent, il n'y a pas de problème, gardez-le. Ce n'est pas là notre motivation.
Bon, ceci étant dit, si vous voulez quand même nous donner de l'argent, ce n'est pas un problème non plus :-) Le plus commode pour nous, c'est si vous envoyez de l'argent à <anakin@pobox.com> via PayPal ( www.paypal.com ). Une autre possibilité, si vous n'avez pas confiance en PayPal, consiste à passer par e-gold ( www.e-gold.com ) : déposez votre don sur le compte n°174769, puis envoyez-nous un mail pour nous avertir, parce que sinon, il risque de se passer plusieurs mois sans qu'on ne remarque quoi que ce soit.
Les petites sommes ( quelques dizaines de dollars ou d'euros ) seront probablement dépensées en bière ou en bouffe indienne, histoire de motiver les troupes. Les dons plus importants seront utilisés acheter quelque chose qui fasse réellement avancer le schmilblick, si nous réussissons à trouver une idée ( peut-être du nouveau matériel, ou un exemplaire de Windows XP ). Et si nous ne trouvons pas d'idée, alors l'argent sera sans doute distribué entre les développeurs. Si vous voulez être sûr que votre don sera utilisé à quelque chose d'utile, parlez-nous en avant. Si ce mode de fonctionnement ne vous convient pas, eh bien, ne faites pas de don, ce n'est pas un souci.
Oui. Pour ce genre de choses, vous n'avez pas besoin de vous embêter à demander notre permission explicite. Notre licence vous donne déjà la permission de le faire.
Veuillez vous reporter à la section B.7 pour plus d'informations à ce sujet.
Non !
Un marchand de produits de sécurité physiques, matériels, concrets, tels que des verrous, des cadenas, ou des antivols, pourrait logiquement accepter une responsabilité financière si jamais l'un de ses produits ne s'avérait pas conforme à ce qui est écrit sur l'emballage, ou à ce qui figure dans une publicité, et qu'il en résulte un tort causé à des utilisateurs de ce produit ( des affaires volées, par exemple ). Il pourrait se le permettre parce qu'il vend un grand nombre d'exemplaires de chacun de ses produits, et que sur la quantité, il y a de bonnes chances que seuls un petit nombre d'entre eux s'avère défectueux. Il pourrait donc supporter cette responsabilité financière, tout en ayant de bonnes chances de rester bénéficiaire, de par le reste de ses ventes. La responsabilité financière est intrinsèquement liée au fait de vendre un produit contre de l'argent.
Il y a deux raisons qui font que PuTTY n'est pas comparable à un cadenas ou à un verrou, dans ce contexte. La première, c'est que les logiciels ne présentent pas de variations aléatoires : quand PuTTY a un trou de sécurité ( ce qui arrive parfois, bien que nous fassions de notre mieux pour l'éviter, et pour réagir au plus vite lorsque cela se produit ), chaque exemplaire de PuTTY a ce même trou, et tous les utilisateurs de PuTTY risquent alors de se trouver affectés en même temps. Donc même si les gens nous payaient pour pouvoir utiliser PuTTY, nous ne pourrions pas leur verser, à tous en même temps, une compensation financière qui aille au delà du prix qu'ils nous auraient versé à l'origine. Ce ne serait pas possible.
L'autre raison, encore plus importante, c'est que les utilisateurs de PuTTY ne nous payent pas. L'équipe de PuTTY ne retire pas de revenu de cette activité de développement. PuTTY résulte de l'effort conjoint de personnes qui consacrent leur temps libre à essayer d'écrire des logiciels utiles. Nous ne sommes pas une société, nous n'avons aucune forme de structure qui soit reconnue sur le plan légal, comme une organisation ou une association. Nous sommes juste un groupe de gens qui bricolons pendant notre temps libre.
C'est pourquoi nous demander d'assumer une responsabilité financière quant aux éventuels défauts de PuTTY reviendrait pour nous à prendre le risque d'avoir à payer cette compensation de notre poche, en prenant sur notre argent personnel, le même qui nous sert à nous acheter à manger, à nous habiller, et à payer le loyer. C'est plus que ce que nous sommes prêts à donner. Nous consacrons déjà une grande part de notre temps libre à développer des logiciels sans que cela ne nous rapporte un kopeck, alors s'il fallait en plus qu'on paye de notre poche pour le faire, il y aurait de quoi se demander à quoi bon...
Le logiciel libre ne repose fondamentalement pas sur la base de garanties financières. La seule assurance que vous ayez, comme quoi le logiciel fonctionne correctement, c'est que le code source est librement disponible, et que vous pouvez le vérifier avant d'utiliser le logiciel. Si vous voulez être sûr qu'il n'y a pas de trous de sécurité, soumettez le code source de PuTTY à un audit sécurité, ou embauchez un ingénieur sécurité pour le faire à votre place si vous n'avez pas vous-même les compétences requises. Plutôt que de chercher à vous assurer une compensation financière en cas de problème, essayez donc de commencer par vous assurer qu'il n'y a pas de problème.
Si vous voulez vraiment une garantie financière, voyez si vous pouvez trouver un ingénieur sécurité qui accepte de se porter garant - financièrement parlant - de la validité de son audit. À défaut, voyez si vous pouvez convaincre une compagnie d'assurances de vous garantir contre des incidents de sécurité, et si l'assureur l'exige, faites auditer notre code par un ingénieur sécurité agréé par cet assureur.
Si le papier que vous voudriez nous faire signer comporte une phrase du genre « Je, soussigné, [...], certifie et garantie que [...] », alors nous ne le signerons pas. Ceci est tout particulièrement vrai s'il s'agit pour nous de garantir que PuTTY est sûr ( veuillez vous reporter à la question A.9.9 pour plus d'informations à ce sujet ). Mais en fait, peu importe ce que nous sommes censés garantir : même s'il s'agit de quelque chose dont nous sommes profondément convaincus, comme le fait que PuTTY ne viole aucun copyright tiers, nous ne signerons aucun document qui entraînerait une responsabilité légale ou financière. Tout simplement parce que le projet de développement de PuTTY n'a pas de revenus qui lui permettraient d'assurer cette responsabilité, ou de payer les frais de justice, si jamais il devait y en avoir besoin. Nous ne pouvons pas nous permettre d'être poursuivis en justice. Nous vous promettons que nous avons fait de notre mieux. Si cela ne vous suffit pas, eh bien tant pis pour vous.
La licence de PuTTY vous accorde d'ores et déjà, de façon très permissive, le droit d'utiliser et de distribuer PuTTY. Il faut juste ne pas chercher à faire croire que c'est vous qui avez écrit le logiciel, ni nous intenter un procès en cas de problème. Nous estimons que cela devrait suffire.
Veuillez consulter la réponse à la question A.9.12 : nous y expliquons une autre raison pour laquelle nous ne souhaitons pas signer ce genre de papiers.
Nous pourrions le faire, en principe, mais il n'est pas évident que ce serait bien utile. Si vous pensiez qu'il y a un risque réel pour que l'un des détenteurs du copyright de PuTTY vous intente un procès ( même si ces craintes nous semblent infondées ! ), alors vous souhaiteriez sans doute obtenir un accord écrit de chacun d'entre eux. Et nous ne serions pas en mesure de vous le fournir, même si nous le voulions, parce que bon nombre des détenteurs du copyright sont des gens qui ont contribué au projet par le passé, en fournissant du code, mais avec qui nous avons perdu le contact, depuis lors. À partir de là, le mieux que nous pourrions faire serait d'obtenir que toute l'équipe de développement principale vous signe un document, mais cela ne vous garantirait pas qu'aucun autre détenteur du copyright de PuTTY ne vous poursuivra jamais en justice.
Veuillez consulter la réponse à la question A.9.12 : nous y expliquons une autre raison pour laquelle nous ne souhaitons pas signer ce genre de papiers.
Pas à moins qu'il y ait une vraiment très bonne raison.
D'une façon générale, nous ne souhaitons pas passer d'accords individuels avec des utilisateurs de PuTTY, afin de ne pas créer de précédent. Nous évaluons le nombre des utilisateurs de PuTTY à plusieurs millions, et nous n'avons certainement pas le temps de faire le tour de ces utilisateurs, et de signer des accords au cas par cas avec chacun d'entre eux. Alors si vous tenez à ce que nous vous signions quelque chose en particulier, vous gagnerez du temps en cessant de croire que vous avez quelque chose en plus, qui vous distingue des 999.999 autres utilisateurs, et donc qu'il y a une raison pour laquelle nous devrions avoir envie de vous signer quelque chose, sans que cela ne crée un tel précédent.
Si la politique de la société dans laquelle vous travaillez exige de vous que vous ayez un accord individuel avec l'éditeur de chacun des logiciels que vous utilisez, alors c'est que la politique de votre société est tout simplement bien mal adaptée à l'usage de logiciels libres, et nous vous encourageons à considérer cela comme un défaut dans cette politique.
Oui et non.
Si vous voulez avoir l'assurance qu'une certaine version de PuTTY, actuelle ou passée, que vous avez déjà téléchargée, restera libre, alors vous l'avez déjà, de par la licence PuTTY elle-même. Cette licence vous accorde le droit d'utiliser, de distributer et de copier le logiciel auquel elle s'applique. Une fois que nous avons accordé cette permission ( ce qui est le cas ), nous ne pouvons tout simplement pas la révoquer.
Par contre, si vous voulez avoir l'assurance que les futures versions de PuTTY ne seront pas en sources fermés, c'est plus difficile. En principe, nous pourrions signer un document disant que que nous ne sortirons jamais une version de PuTTY dont les sources seraient fermés, mais ce ne serait pas pour autant une garantie que nous continuerions à sortir des versions de PuTTY en sources ouverts : nous aurions toujours la possibilité d'arrêter complètement le développement de PuTTY, ce qui serait encore pire, pour vous, que si nous sortions des PuTTY en sources fermés ! Et il est quasiment certain que nous ne sommes pas prêts à signer un document garantissant que nous continuerons à travailler indéfiniment sur PuTTY ( en tous cas, si nous le faisions, ce ne serait sûrement pas à titre gratuit ! ). De tels documents portent un nom ( cela s'appelle un contrat de travail ), et ne sont généralement pas signés sans un salaire conséquent en échange.
Si nous étions sur le point d'arrêter le développement de PuTTY, ou de décider que toutes les versions à venir seront en sources fermés, alors vous auriez encore la possibilité de prendre la dernière version sortie en sources ouverts, conformément à la licence actuelle, et en particulier, vous pourriez démarrer votre propre « fork », c'est à dire votre propre branche de développement du projet, à partir de cette version. Si cela devait se produire, je pense pouvoir prédire que quelqu'un le ferait, et que le PuTTY libre et gratuit que vous connaissez continuerait à être développé. Il y a déjà eu des précédents dans le domaine du logiciel libre. Nous ne pouvons pas garantir que quelqu'un d'autre que vous le ferait, bien entendu. Il se pourrait que vous deviez le faire vous-même. Mais nous pouvons vous assurer qu'il n'y a rien qui empêcherait quiconque de continuer le développement d'une version libre si jamais nous, nous arrêtions.
Pour finir, nous pensons aussi pouvoir prédire que si jamais nous décidions de mettre PuTTY en sources fermés, et que quelqu'un en commençait une branche parallèle en sources ouverts, la plupart des utilisateurs adopteraient cette nouvelle branche. Ce serait donc tout à fait stupide de notre part.
Certaines personnes nous ont demandé un numéro ECCN pour PuTTY ( [NdT] ECCN = Export Control Classification Number : il s'agit d'un numéro de classification délivré par l'administration américaine dans le cadre du contrôle des exportations ). Nous ne savons pas si nous en avons un, et vu que nous sommes une équipe de développeurs de logiciels libres, et que nous sommes situés au Royaume Uni, nous n'avons ni le temps, ni l'argent nécessaires pour creuser la question, et pas de temps à perdre avec l'administration américaine. Nous croyons savoir que PuTTY appartient à la catégorie 5D002 sur la liste américaine du contrôle du commerce, mais cette information est à prendre avec précaution. Si vous avez besoin d'en savoir plus, vous devriez consulter un conseiller juridique. Il en va de même pour les exigences légales et les restrictions imposées par tous les autres pays.
De la même façon, certaines personnes nous ont demandé une certification FIPS pour les outils PuTTY. À moins que quelqu'un d'autre ne soit prêt à faire le travail nécessaire, et à payer ce que cela coûtera, nous ne sommes pas en mesure de fournir cette certification.
Non. Le code source de PuTTY a presque entièrement été écrit « from scratch », en partant de rien. La seule partie de code que nous ayons en commun avec OpenSSH, c'est le détecteur d'attaques par compensation CRC sur SSH-1, qui a été écrit par la société CORE SDI S.A.
Ah, là vous n'êtes pas sur le bon site. Le seul PuTTY dont il est question ici est un programme d'ordinateur. Si vous êtes à la recherche de « putty », le jouet pour passer ses nerfs et se détresser, l'équipe de développement de PuTTY est bien placée pour vous conseiller « Thinking Putty », que vous pouvez vous procurer sur le site Crazy Aaron's Putty World ( www.puttyworld.com ).
Rien de particulier. PuTTY, c'est le nom d'un client SSH et Telnet bien connu. Pour le reste, c'est vous qui voyez. Des rumeurs prétendent que 'PuTTY', c'est le contraire de 'getty', ou que c'est ce qui rend Windows utile, ou encore que c'est un sorte de télétype au plutonium ( [NdT] le symbole chimique du plutonium est Pu, et 'télétype' est souvent écrit TTY, en abrégé ). Nous ne ferons aucun commentaire là-dessus.
[NdT] accessoirement, 'putty' est aussi un nom commun, en anglais, qui signifie 'mastic'.
Exactement comme le mot anglais 'putty', que nous prononçons /ˈpʌti/.
[NdT] : en français, on prononce tout simplement 'pouti'.
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.