Couldn't connect with these settings
SSH connection failed: Cannot parse privateKey: Unsupported key format
Description
J’essaie de configurer un « SSH Private Key Account » dans les identifiants. Quand je transmets la clé au champ « Private Key », j’obtiens toujours le message d’erreur.
Il semble que ce champ détruise les sauts de ligne de la clé. Quand je la transmets en tant qu’expression
cela semble fonctionner dans la routine de vérification de la boîte de dialogue Nouvel identifiant.
Cependant : quand j’utilise les identifiants dans un nœud SSH, j’obtiens à nouveau la même erreur.
Quand je reviens à l’identifiant, le contenu du champ Private Key a changé en quelque chose comme __n8n_BLANK_VALUE_e5362baf-c777-4d57-a609-6eaf1f9e87f6.
La même chose se produit quand je saisis la clé en tant qu’expression, je ferme la fenêtre des identifiants et la rouvre immédiatement. Ensuite, la vérification de la clé échoue également.
Comment puis-je même stocker des clés SSH dans n8n sans qu’elles soient détruites ?
Workflow
Informations sur votre configuration n8n
version n8n : 2.30.7
Base de données (par défaut : SQLite) : par défaut
En examinant le JSON que vous avez fourni, vous tentez de gérer les fichiers de clés manuellement dans un nœud « Exécuter une commande » en utilisant le décodage base64 et shred.
Au lieu de gérer les clés basées sur des fichiers manuellement dans les scripts, il est beaucoup plus sûr et stable de stocker la clé SSH dans une véritable Credential de clé privée SSH dans n8n et de sélectionner cette credential dans les paramètres d’authentification du nœud SSH.
Si vous continuez à recevoir une erreur « Format de clé non pris en charge » même avec une clé PEM correctement formatée, assurez-vous que la clé n’a pas de phrase de passe, ou si c’est le cas, assurez-vous de l’avoir saisie correctement dans le champ « Phrase de passe » de la configuration de la credential.
Une précision sur le __n8n_BLANK_VALUE_xxx que vous voyez en rouvrant le credential : c’est un comportement normal et attendu, pas une perte de données. n8n ne renvoie jamais la valeur réelle d’un champ sensible (password/private key) au navigateur après l’enregistrement, pour des raisons de sécurité — il affiche un jeton placeholder à la place. La clé est bien stockée côté serveur ; ce que vous voyez à l’écran n’est pas son contenu réel.
Le vrai souci vient plutôt de l’utilisation d’une expression pour remplir le champ :
Le champ Private Key est un simple textarea multiligne : il n’y a aucun besoin de passer par une expression pour conserver les retours à la ligne. Collez la clé directement (Ctrl+V), avec ses vrais sauts de ligne — ça fonctionne nativement. Utiliser une expression ici mélange la logique de résolution runtime avec le masquage du champ sensible, ce qui peut expliquer l’échec au moment où le nœud SSH tente de résoudre la valeur.
Si après un collage direct les sauts de ligne semblent toujours aplatis, vérifiez la clé source : collez-la d’abord dans un éditeur de texte brut pour confirmer qu’elle contient bien des retours à la ligne réels (et pas des \n littéraux) avant de la coller dans n8n — certains gestionnaires de mots de passe ou terminaux compressent le format PEM sur une seule ligne à l’export.
Hé! Tu as découvert une particularité plutôt célèbre de n8n : stocker les clés privées SSH multilignes directement dans l’interface de saisie des identifiants.
Ton observation concernant le champ qui se transforme en __n8n_BLANK_VALUE_... est très juste. C’est la façon qu’a n8n de masquer les identifiants sauvegardés, mais cela brise souvent la sérialisation des chaînes multilignes (comme les clés RSA) lorsque tu rouvres le nœud, ce qui provoque l’erreur « Unsupported key format ».
La solution la plus robuste pour contourner ces problèmes d’analyse est d’utiliser des variables d’environnement. Voici comment la corriger spécifiquement pour ton installation Docker/CasaOS :
1. Prépare ta clé privée (sur une seule ligne)
Remplace les sauts de ligne réels dans ton fichier PEM par \n. Cela devrait ressembler à ceci (garde les guillemets) : "-----BEGIN RSA PRIVATE KEY-----\nMIICdgIBADANBgkqhkiG9w...\n-----END RSA PRIVATE KEY-----"
2. Configure la variable d’environnement
Dans les paramètres de ton application CasaOS (ou docker-compose.yml), ajoute une nouvelle variable d’environnement :
Nom : N8N_SSH_PRIVATE_KEY
Valeur : [Ta clé sur une seule ligne issue de l'étape 1]
Sauvegarde et redémarre le conteneur n8n.
3. Mets à jour ton identifiant n8n
Crée un nouveau compte de clé privée SSH dans n8n. Dans le champ Clé privée, au lieu de coller la clé directement, utilise une expression pour référencer ta nouvelle variable d’environnement : ={{ $env.N8N_SSH_PRIVATE_KEY }}
Ceci injecte la clé brute et correctement formatée dans le client SSH au moment de l’exécution, en contournant complètement l’interface utilisateur. Cela devrait fonctionner instantanément.
Salut @Me.MyBase Bienvenue !
« Unsupported key format » signifie que le parseur ssh2 rejette le contenu de la clé, pas un problème de formatage des sauts de ligne. Les identifiants SSH de n8n attendent la clé au format OpenSSH, tandis que la vôtre est une clé PEM classique (-----BEGIN RSA PRIVATE KEY-----), que ce parseur n’acceptera pas. Convertissez-la sur place, même paire de clés pour que le fichier authorized_keys du serveur reste valide, et supprimez la passphrase pour qu’aucun déchiffrement ne soit nécessaire au moment du parsing :
ssh-keygen -p -N "" -f ./id_rsa
L’en-tête devrait devenir -----BEGIN OPENSSH PRIVATE KEY-----. Collez la clé convertie en entier, lignes d’en-tête et de pied incluses, et laissez le champ Passphrase vide.
Bonjour, merci pour la réponse.
Le contenu du nœud SSH n’est pas le problème. Je n’arrive pas à enregistrer la clé privée SSH de manière utilisable dans les identifiants. L’étape du nœud est encore un test et n’est actuellement pas utilisée du tout.
Bonjour, merci pour la réponse. Le champ Private Key est simplement monoligne et non multiligne dans la version mentionnée. C’est pourquoi j’utilise cette astuce avec l’expression, qui semble d’ailleurs fonctionner dans la vérification. C’est seulement quand j’utilise les identifiants que cela échoue à nouveau.
-----BEGIN PRIVATE KEY----- est PKCS#8, que le parseur ssh2 derrière le nœud SSH n’accepte pas non plus, donc cette tentative échoue sur le format avant même que le champ ne soit impliqué. L’en-tête que vous voulez est -----BEGIN OPENSSH PRIVATE KEY-----.
Comme le champ aplatit la clé dans votre version, écrivez la credential directement au lieu de la coller. Exportez celle existante déchiffrée :
Cela se retrouve dans votre volume n8n monté afin que vous puissiez l’éditer depuis l’hôte. Mettez la clé OpenSSH complète dans privateKey comme une seule chaîne JSON avec \n à chaque saut de ligne, puis réimportez-la sur le même ID :