يبدو أنه يعمل في روتين الفحص في نافذة بيانات الاعتماد الجديدة.
ومع ذلك: عندما أستخدم بيانات الاعتماد في عقدة SSH أحصل على نفس الخطأ مرة أخرى.
عندما أعود إلى بيانات الاعتماد، يتغير محتوى حقل المفتاح الخاص إلى شيء مثل __n8n_BLANK_VALUE_e5362baf-c777-4d57-a609-6eaf1f9e87f6.
يحدث نفس الشيء عندما أدخل المفتاح كتعبير وأغلق نافذة بيانات الاعتماد وأعيد فتحها مباشرة. ثم يفشل فحص المفتاح أيضاً.
بالنظر إلى JSON المقدم منك، أنت تحاول التعامل مع ملفات المفاتيح يدويًا داخل عقدة Execute a command باستخدام فك تشفير base64 وshred.
بدلاً من إدارة المفاتيح المستندة إلى الملفات يدويًا في السكريبتات، من الأكثر أماناً واستقراراً بكثير تخزين مفتاح SSH في SSH Private Key Credential مناسب في n8n واختيار هذا بيانات الاعتماد داخل إعدادات المصادقة في عقدة SSH.
إذا استمررت في الحصول على رسالة خطأ “Unsupported key format” حتى مع مفتاح PEM منسق بشكل صحيح، تأكد من أن المفتاح لا يحتوي على عبارة مرور، أو إن كان يحتويها، فتأكد من إدخالك لها بشكل صحيح في حقل “Passphrase” من إعداد بيانات الاعتماد.
توضيح بشأن __n8n_BLANK_VALUE_xxx الذي تراه عند إعادة فتح بيانات الاعتماد: هذا سلوك طبيعي ومتوقع، وليس فقداناً للبيانات. لا تعيد n8n أبداً القيمة الفعلية لحقل حساس (كلمة المرور/المفتاح الخاص) إلى المتصفح بعد الحفظ، لأسباب أمنية — بل تعرض رمز نائب بدلاً منها. المفتاح محفوظ بشكل صحيح على جانب الخادم؛ ما تراه على الشاشة ليس محتواه الحقيقي.المشكلة الفعلية تأتي من استخدام تعبير لملء الحقل:```
={{-----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- }}
حقل Private Key هو ببساطة منطقة نص متعددة الأسطر: لا حاجة على الإطلاق لاستخدام تعبير للحفاظ على فواصل الأسطر. الصق المفتاح مباشرة (Ctrl+V)، مع فواصل الأسطر الحقيقية — يعمل هذا بشكل أصلي. استخدام تعبير هنا يخلط منطق حل وقت التشغيل مع إخفاء الحقل الحساس، مما قد يفسر الفشل عندما يحاول عقدة SSH حل القيمة.
إذا بدت فواصل الأسطر مسطحة دائماً بعد لصق مباشر، تحقق من المفتاح المصدر: الصقه أولاً في محرر نصوص عادي للتأكد من أنه يحتوي على فواصل أسطر حقيقية (وليس `\n` حرفية) قبل لصقه في n8n — قد تضغط بعض مديري كلمات المرور أو الطرفيات صيغة PEM على سطر واحد عند التصدير.
مرحبا! لقد واجهت خللاً معروفاً إلى حد ما في n8n: تخزين مفاتيح SSH الخاصة متعددة الأسطر مباشرة في واجهة المفاتيح.
ملاحظتك بشأن تغيير الحقل إلى __n8n_BLANK_VALUE_... دقيقة تماماً. هذه طريقة n8n لإخفاء المفاتيح المحفوظة، لكنها غالباً ما تكسر التسلسل الهرمي للنصوص متعددة الأسطر (مثل مفاتيح RSA) عند إعادة فتح العقدة، مما يؤدي إلى خطأ “Unsupported key format”.
الحل الأكثر قوة لتجاوز هذه المشاكل في التحليل هو استخدام متغيرات البيئة. إليك كيفية إصلاحه خصيصاً لإعداد Docker/CasaOS الخاص بك:
1. تحضير مفتاحك الخاص (سطر واحد)
استبدل فواصل الأسطر الفعلية في ملف PEM الخاص بك بـ \n. يجب أن يبدو هكذا (احتفظ بعلامات الاقتباس): "-----BEGIN RSA PRIVATE KEY-----\nMIICdgIBADANBgkqhkiG9w...\n-----END RSA PRIVATE KEY-----"
2. قم بتعيين متغير البيئة
في إعدادات تطبيق CasaOS الخاص بك (أو docker-compose.yml)، أضف متغير بيئة جديد:
الاسم: N8N_SSH_PRIVATE_KEY
القيمة: [مفتاحك من سطر واحد من الخطوة 1]
احفظ وأعد تشغيل حاوية n8n.
3. حدّث بيانات اعتماد n8n الخاصة بك
أنشئ حساب مفتاح SSH خاص جديد في n8n. في حقل المفتاح الخاص، بدلاً من لصق المفتاح مباشرة، استخدم تعبيراً للإشارة إلى متغير البيئة الجديد: ={{ $env.N8N_SSH_PRIVATE_KEY }}
هذا يضخ المفتاح الأولي والمنسق بشكل صحيح في عميل SSH في وقت التشغيل، متجاوزاً الواجهة تماماً. يجب أن يعمل على الفور.
مرحباً @Me.MyBase أهلاً وسهلاً!
“Unsupported key format” هو مُحلِّل ssh2 الذي يرفض محتوى المفتاح، وليس تلف حقلك لفواصل الأسطر. بيانات اعتماد SSH الخاصة بـ n8n تتوقع المفتاح بتنسيق OpenSSH، بينما مفتاحك هو مفتاح PEM كلاسيكي (-----BEGIN RSA PRIVATE KEY-----)، وهذا المُحلِّل لن يقبله. حوّله في مكانه، نفس زوج المفاتيح بحيث يبقى authorized_keys على الخادم صحيحاً، وأزِل كلمة المرور حتى لا يحتاج شيء إلى فك التشفير وقت التحليل:
ssh-keygen -p -N "" -f ./id_rsa
يجب أن يتغيّر الرأس إلى -----BEGIN OPENSSH PRIVATE KEY-----. الصق المفتاح المحوّل كاملاً، بما فيه أسطر الرأس والتذييل، واترك حقل كلمة المرور فارغاً.
مرحباً، شكراً على الرد.
المحتوى في عقدة SSH ليس المشكلة. لا أستطيع حفظ مفتاح SSH الخاص بطريقة قابلة للاستخدام في بيانات الاعتماد. الخطوة في العقدة لا تزال اختباراً ولا يتم تطبيقها حالياً على الإطلاق.
مرحبا، شكرا على الرد. حقل المفتاح الخاص في الإصدار المذكور هو بسطر واحد فقط وليس متعدد الأسطر. ولهذا السبب الحيلة مع التعبير الذي يبدو أنه يعمل في الفحص أيضا. لكن عندما أستخدم بيانات الاعتماد، فإنه يفشل مرة أخرى.
-----BEGIN PRIVATE KEY----- هو PKCS#8، وهيكل تحليل ssh2 خلف عقدة SSH لا يقبله أيضًا، لذلك تفشل هذه المحاولة في الصيغة قبل حتى إشراك الحقل. رأس الملف الذي تريده هو -----BEGIN OPENSSH PRIVATE KEY-----.
بما أن الحقل يضغط المفتاح في إصدارك، اكتب بيانات الاعتماد مباشرة بدلاً من لصقها. احفظ المفتاح الموجود غير مشفر:
هذا ينتهي به الحال في مجلد n8n المثبت الخاص بك بحيث يمكنك تحريره من المضيف. ضع مفتاح OpenSSH الكامل في privateKey كسلسلة JSON واحدة مع \n في كل فاصل سطر، ثم استورده مرة أخرى بنفس المعرّف: