PuTTY demande un fichier de clé privée au format PPK, tandis qu’un serveur Linux OpenSSH autorise une clé publique dans le compte visé. Ces deux fichiers ne vont pas au même endroit : le PPK reste sur votre poste Windows, la clé publique est ajoutée à authorized_keys sur le serveur.
Vous pouvez créer une nouvelle paire avec PuTTYgen ou importer une clé privée OpenSSH déjà existante. Dans les deux cas, gardez une session fonctionnelle ou une console de secours pendant le déploiement. Une clé nouvellement créée ne donne pas accès au serveur tant que sa partie publique n’y a pas été autorisée.
Pour les paramètres de l’hôte, du port, du compte et la vérification initiale de son empreinte, suivez le guide configurer la connexion PuTTY à votre serveur Linux. Ici, le sujet est la préparation de la clé et la preuve que PuTTY l’utilise vraiment.
Identifier les deux clés et le compte Linux cible
Une paire SSH contient une clé privée et une clé publique. La privée sert à prouver votre identité : ne la transmettez jamais et ne la placez pas sur le serveur. PuTTYgen l’enregistre au format .ppk. Protégez ce fichier sur Windows par une passphrase et conservez-en, si nécessaire, une sauvegarde chiffrée dans un emplacement protégé.
La clé publique peut être communiquée au serveur. Pour OpenSSH, elle se présente normalement sur une seule ligne dans le fichier ~/.ssh/authorized_keys du compte Linux concerné. Le compte, son répertoire personnel et le chemin autorisé doivent être confirmés avant toute modification. Un serveur administré peut définir un autre emplacement avec AuthorizedKeysFile.
La passphrase protège la clé privée locale ; elle n’est pas le mot de passe du compte Linux. Une authentification par clé peut aussi rester soumise à un second facteur. Enfin, la clé d’hôte vérifie l’identité du serveur : elle est différente de votre clé utilisateur et doit toujours être contrôlée.
Créer une paire avec PuTTYgen et enregistrer le PPK
Sur le poste Windows, ouvrez PuTTYgen. Choisissez EdDSA avec Ed25519 si le serveur et sa politique l’acceptent. Selon la version, le libellé du type peut varier. RSA reste une option de compatibilité si l’environnement l’exige ; ne réactivez pas une ancienne signature SHA-1 ou SSH-1 pour contourner un problème de client. Si vous préférez créer la paire depuis un poste Ubuntu, suivez ce guide pour générer une clé SSH depuis Ubuntu ; PuTTYgen reste le parcours décrit ici pour Windows.
Cliquez sur Generate et suivez la demande de mouvement de souris de l’outil. Ajoutez un commentaire reconnaissable qui ne révèle aucune information sensible. Renseignez Key passphrase et Confirm passphrase, puis cliquez sur Save private key. Choisissez un dossier privé accessible uniquement aux utilisateurs autorisés de votre poste et notez l’emplacement du fichier .ppk. La génération seule n’enregistre pas le fichier.
Copiez la valeur affichée dans Public key for pasting into OpenSSH authorized_keys file. C’est cette ligne qu’il faudra ajouter au compte Linux. Le bouton Save public key peut produire un format différent, notamment RFC 4716. Ne collez pas un bloc BEGIN SSH2 PUBLIC KEY dans le fichier OpenSSH. Conservez les réglages de format PPK proposés par PuTTYgen ; si un client ne sait pas lire le format, mettez-le à jour plutôt que d’affaiblir la protection de la clé.
Importer une clé OpenSSH existante en PPK
Si vous possédez déjà la clé privée OpenSSH, importez-la sur le poste Windows avec PuTTYgen : choisissez Conversions > Import key, sélectionnez le fichier privé, puis saisissez sa passphrase si PuTTYgen la demande. Enregistrez ensuite une copie au format PPK avec Save private key.
Cette opération convertit le conteneur pour PuTTY ; elle ne crée pas une nouvelle identité. La clé publique et son empreinte doivent rester celles de la paire d’origine. Vérifiez l’empreinte dans PuTTYgen avant et après l’import, puis assurez-vous que la publique correspondante est bien autorisée sur le compte Linux. Une clé publique seule, souvent nommée avec l’extension .pub, ne permet pas de reconstruire la privée. Renommer un fichier .pem en .ppk ne le convertit pas non plus : les formats varient, il faut l’importer et vérifier que PuTTYgen le reconnaît.
Ne transmettez pas votre clé privée à un convertisseur Web et ne la récupérez pas depuis un compte root sur le serveur. Si elle est perdue ou si sa passphrase est oubliée, créez une nouvelle paire, faites autoriser sa clé publique par un accès de secours, testez-la, puis retirez l’ancienne autorisation si elle n’est plus nécessaire.
Ajouter la clé publique au bon compte sans écraser les autres
Les commandes suivantes s’exécutent dans un shell Linux déjà ouvert sous le compte cible, pas dans PowerShell et pas automatiquement sous root. Elles servent d’abord à confirmer l’identité du compte et les chemins concernés :
whoami
printf '%s\n' "$HOME"
ls -ld "$HOME" "$HOME/.ssh"
ls -l "$HOME/.ssh/authorized_keys"Vérifiez que whoami affiche le compte prévu et que $HOME est son répertoire personnel. Les commandes ls permettent de contrôler l’existence, le propriétaire et les permissions du dossier et du fichier. Un message indiquant qu’un chemin n’existe pas peut être normal pour une première installation. Ne créez pas par inadvertance les fichiers dans le répertoire de root.
Dans le cas standard où vous êtes bien connecté sous ce compte, ces commandes préparent le répertoire et ouvrent le fichier avec Nano :
umask 077
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
nano "$HOME/.ssh/authorized_keys"
chmod 600 "$HOME/.ssh/authorized_keys"umask 077 limite les droits par défaut dans ce shell. mkdir -p crée le dossier s’il manque sans supprimer son contenu. Le mode 700 réserve le dossier .ssh au compte ; le mode 600 réserve le fichier au propriétaire. Dans Nano, ajoutez la ligne publique copiée depuis PuTTYgen à la fin du fichier, sans supprimer les lignes existantes. Enregistrez puis quittez l’éditeur. Si le fichier existe déjà, faites-en une sauvegarde avant de le modifier. N’utilisez pas une redirection > qui l’écraserait.
Après l’édition, toujours dans le shell du compte cible, cette commande lit les empreintes des clés publiques présentes dans authorized_keys :
ssh-keygen -lf "$HOME/.ssh/authorized_keys" -E sha256Comparez l’empreinte attendue avec celle montrée par PuTTYgen et identifiez la bonne entrée si le fichier contient plusieurs clés. Ce contrôle porte sur les clés utilisateur autorisées, pas sur l’empreinte de la machine distante. Ne retirez pas les autres clés pour simplifier la comparaison.
Si le répertoire personnel, les propriétaires, les ACL ou le chemin des clés sont personnalisés, demandez à l’administrateur de confirmer la configuration. Évitez chmod -R et un chown appliqué à l’aveugle : ils peuvent modifier des fichiers sans rapport avec SSH. Depuis un poste Linux, une autre méthode consiste à installer une clé publique avec ssh-copy-id. Cette commande concerne un client Linux, pas PuTTY sous Windows.
Sélectionner le PPK dans PuTTY et vérifier l’authentification
Dans PuTTY, chargez la session concernée. Ouvrez Connection > SSH > Auth > Credentials, puis choisissez le fichier dans Private key file for authentication. Revenez dans Session et enregistrez la configuration. Gardez le compte distant déjà prévu pour cette session.
Conservez votre session de secours et ouvrez une nouvelle fenêtre PuTTY pour le test. Si PuTTY signale une empreinte d’hôte inconnue ou modifiée, comparez-la à une valeur obtenue par un canal fiable avant de continuer. La passphrase de la clé privée peut être demandée : cela ne signifie pas que PuTTY réclame le mot de passe Linux.
Pour confirmer la méthode utilisée, ouvrez l’Event Log de PuTTY et vérifiez que la clé attendue est proposée puis acceptée pour l’authentification par clé publique. Un shell obtenu ne suffit pas à lui seul : Pageant peut avoir fourni une autre clé et PuTTY peut aussi disposer d’un autre mode d’authentification. Pour isoler le test, quittez temporairement Pageant ou retirez ses clés, puis sélectionnez explicitement le PPK dans la session. Si PuTTY demande le mot de passe Linux, interrompez ce test : une connexion par repli ne prouve pas que la clé a fonctionné. Respectez les facteurs supplémentaires imposés par le serveur.
Dans le shell de la seconde connexion, ces commandes confirment le compte et la machine atteints, mais pas la méthode d’authentification :
whoami
hostnameComparez le compte affiché à celui visé et vérifiez le nom de l’hôte attendu. L’Event Log PuTTY et, si nécessaire, les journaux côté serveur établissent la méthode employée. Ne fermez la session de secours qu’après avoir confirmé le résultat.
Utiliser Pageant sans lui confier plus que nécessaire
Pageant est facultatif. Commencez par réussir un test direct avec le PPK. Pour éviter de ressaisir la passphrase pendant les connexions suivantes, lancez Pageant, ouvrez sa fenêtre, choisissez Add Key, puis sélectionnez le fichier PPK. Déverrouillez-le localement et contrôlez le commentaire ou l’empreinte affichée. PuTTY peut alors demander à l’agent de signer les échanges.
La passphrase protège le fichier sur disque ; Pageant facilite son utilisation tant que la clé déverrouillée reste disponible en mémoire. L’agent n’installe pas la clé publique sur le serveur et ne remplace pas la vérification de l’empreinte d’hôte. Remove Key retire la clé de l’agent, pas de authorized_keys. Pour révoquer l’accès de ce poste, retirez séparément la bonne ligne publique sur le serveur depuis une session encore autorisée.
Ne chargez que les clés utiles et laissez le transfert d’agent désactivé, sauf besoin précis vers des machines de confiance. Un processus malveillant sur le poste peut tenter d’abuser des signatures de l’agent. Retirez les clés de Pageant ou fermez-le quand elles ne sont plus nécessaires. Ne placez jamais une passphrase dans un raccourci ou un script.
Diagnostiquer un refus sans affaiblir le serveur
- Couldn’t load private key ou Unable to use key file : vérifiez le chemin du fichier, son format et la version du client. Importez proprement la clé avec PuTTYgen ; changer son extension ne suffit pas.
- Server refused our key : confirmez le compte distant, la correspondance entre privée et publique, la ligne OpenSSH complète, le chemin autorisé et les permissions/propriétaires. Si vous administrez le serveur, consultez les journaux au moment précis de l’essai.
- Too many authentication failures : l’agent propose peut-être trop de clés. Pour un test, sélectionnez la bonne clé et retirez les autres de Pageant. N’augmentez pas arbitrairement
MaxAuthTries. - PuTTY demande un mot de passe : distinguez la passphrase de la clé, le mot de passe Linux et un éventuel facteur supplémentaire. Arrêtez le test si le mot de passe du compte est demandé ; ce n’est pas une preuve d’authentification par clé.
Depuis une console indépendante ou une session d’administration existante, l’administrateur peut consulter l’unité de journalisation présente sur la distribution. Ces commandes lisent les 50 dernières entrées de l’unité indiquée ; utilisez celle qui existe, souvent ssh sur Debian ou Ubuntu, ou sshd sur d’autres distributions :
sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u sshd -n 50 --no-pagerUn journal vide ne prouve pas qu’aucune tentative n’a eu lieu : la distribution peut utiliser une autre unité ou une autre destination de logs. Ne partagez que les lignes utiles, après avoir masqué les détails d’infrastructure. Si la configuration utilise des règles Match ou un chemin personnalisé, faites vérifier par l’administrateur la configuration effective pour le compte concerné. Cet article ne demande ni de modifier la configuration SSH, ni de désactiver un contrôle de sécurité.
Ne désactivez pas StrictModes, le MFA ou la vérification de l’hôte pour faire passer le test. N’autorisez pas root comme raccourci et ne réactivez pas SSH-1 ou les signatures faibles. Si la clé privée ou sa passphrase est perdue, déployez une nouvelle paire via un accès de secours et vérifiez-la avant de retirer l’ancienne autorisation. Le contrôle final porte sur quatre éléments : le bon fichier privé sur Windows, la bonne clé publique dans le compte visé, les permissions attendues et l’acceptation de cette clé dans l’Event Log PuTTY.