SSH

تم الالتقاط بتاريخ 2026-07-28 من أحد CE في هذا النشر. يُسجّل sitecli/capture-manifest.json العقدة المعنية، ويُعيد scripts/capture-sitecli.sh --check التحقق من سطح الأوامر مقارنةً بـ CE حي.

يصل SSH إلى حساب admin على الجهاز، الذي تكون قشرة تسجيل دخوله هي Site CLI (/opt/bin/vpmu). هذا هو المسار الوحيد إلى سطح الأوامر الكامل على الجهاز — يعرض debug API 34 أمرًا، بينما يوفر الجهاز نفسه أوامر أكثر بكثير غير متوفرة في ذلك الـ API.

cd terraform
SLI=$(terraform output -json ce_sli_private_ips | jq -r '.eastus01')
ssh -tt -i ~/.ssh/id_ed25519 -J azureuser@<operator-vm> "admin@$SLI"

كل جزء من سطر الأوامر هذا ضروري، وتشرح الأقسام الثلاثة التالية الخطأ الذي يمنعه كل منها.

لا يوجد موجه shell للوصول إليه: قشرة تسجيل دخول admin هي Site CLI، لذا تصل مباشرةً إلى موجه >>> الخاص بها. شغّل الأوامر على الجهاز باستخدام execcli <name> هناك — راجع الأوامر على الجهاز.

ابحث عن العنوان الداخلي دائمًا — لا تستخدم عنوانًا من جلسة سابقة

تُعيد Azure تعيين الشبكة الفرعية الداخلية عند كل إعادة بناء، وليس بترتيب العقد. بعد آخر إعادة بناء، تحمل f5-xc-ce-vm-01 و-02 و-03 العناوين 10.0.3.7 و10.0.3.5 و10.0.3.4؛ وقد احتلت بناءة سابقة ترتيبًا مختلفًا كليًا، وبطاقة الشبكة الخاصة بعميل الاختبار في الشبكة الفرعية نفسها واحتفظت بعنوان سبق أن احتفظ به أحد CE. لذا فإن الاتصال بعنوان محفوظ قد يوصلك إلى العقدة الخاطئة، أو إلى VM ليست CE، أو لا يوصلك إلى أي مكان — والأخير يبدو مطابقًا تمامًا لـ “SSH غير مُفعَّل”.

terraform output -json ce_sli_private_ips هو التعيين الصحيح. في غياب الحالة، يكون اسم بطاقة الشبكة ثابتًا حتى لو لم يكن العنوان كذلك:

az network nic show -g "$(terraform output -raw resource_group_name)" \
  -n "$(terraform output -json ce_vm_names | jq -r '.eastus01')-internal-nic" \
  --query ipConfigurations[0].privateIPAddress -o tsv

للتشغيل الأول فقط — لا يمكن لـ CE موجود اكتساب SSH دون إعادة إنشائه

يعمل write_files في cloud-init مرة واحدة فقط، عند أول تشغيل. بعد ذلك يوجد علامة /etc/cloud/cloud-init.disabled على العقدة ولا يعمل cloud-init مجددًا.

لذا لا يوجد مسار للتطبيق المباشر على CE قيد التشغيل. custom_data في Azure للاستبدال فقط، مما يعني أن تبني هذا على نشر موجود يستبدل كل CE VM. منح SSH للمشغّل على العقد التي تعمل بالفعل هو إعادة بناء، وليس تغيير إعداد — والتحذير التالي يوضح ما كانت تكلّفه إعادة البناء تلك سابقًا، ولماذا لم تعد تكلّفه كذلك.

كان استبدال CE VM يُعطّل التسجيل بشكل دائم — هذا مُصلَح، وهو سبب ارتباط كائن الموقع بالـ VM

يستحق المعرفة قبل تخطيط إعادة بناء، لأن شكل الخطأ يشرح الترابط الذي ستراه في الخطة.

اعتاد الأمر أن تحتفظ تسجيل العقدة المُتلفة بمؤشر (tenant, cluster_name, hostname) الفريد لمستوى التحكم، فكان تسجيل العقدة البديلة مرفوضًا بخطأ UniqueSecondaryIndexViolationError وتتم إعادة محاولته إلى الأبد. لم يكن حذف التسجيل كافيًا بمفرده: كان StatusObject متبقٍّ يُعيد 500 لطلب عبء العمل، وبحلول تلك المرحلة كانت كل عقدة قد ثبّتت registration-obj.yml ربطتها بالتسجيل الذي حذفته، فتحلقت على 404 دون استرداد ذاتي. استغرق الاسترداد إعادتَي بناء كاملتين. وطوال ذلك أفادت terraform plan بـ “لا تغييرات”، لأن من منظور Terraform قد تحقق الوضع المطلوب.

المسألة 674 مُغلقة بواسطة PR 693. يُسمّي modules/xc-site الآن مثيل CE VM في replace_triggered_by، لذا فإن استبدال الـ VM يستبدل كائن الموقع، وحذف موقع يأخذ معه تسجيلاته — مفتاح الفهرس يكون حرًا قبل تشغيل العقدة البديلة. منذ ذلك الحين أُعيد بناء الأسطول من الصفر ووصلت الثلاثة مواقع إلى ONLINE دون تدخل.

يمكن ملاحظة الترابط لا افتراضه. كل موقع مرتبط بمعرّف مثيل VM، والتسجيل المقابل يُبلّغ عن القيمة ذاتها كـ infra.instance_id:

cd terraform && terraform output -json ce_bound_instance_ids

أي اختلاف بين القيمتين يعني أن موقعًا لا يزال مرتبطًا بعقدة لم تعد موجودة، وهي الحالة التي لا يمكن لـ CE مُعاد بناؤه الخروج منها عبر التسجيل. قراءة نصف التسجيل لا تزال تحتاج إلى استدعاء API مباشر — مسألة الموفر 1376 هي ما سيضعها على مصدر البيانات.

لماذا يكتب cloud-init المفتاح، لا الـ API

يبدو admin_user_credentials.ssh_key على كائن الموقع تمامًا كالحقل المخصص لهذا الغرض. يُقبل، ويبقى عند القراءة الثانية، ولا يُهيّئ شيئًا. يمتلك vpm المستخدمين المحليين على العقدة ويرفض لمس هذا المستخدم — من سجل العقدة نفسه، ثلاث مرات خلال تشغيل واحد:

vpm  users.go:165: Won't do any change for user admin (internal skip)

كل شيء آخر ينبثق من هذا السطر الواحد. لا يوجد /var/home/admin/.ssh أبدًا، قبل أو بعد وصول الموقع إلى ONLINE. يبقى تاريخ آخر تغيير لكلمة مرور admin عند تاريخ بناء الصورة بينما يُظهر vesbkp وvesopcon التاريخ الحالي، لأن vpm عيّن هذين الاثنين وتخطّى admin. ولا يُسجّل vpm أي شيء عن ssh_key أو authorized_keys في أي وقت.

لذا يجب كتابة الملف خارج vpm. admin هو uid 2202، مُضمَّن في صورة العقدة، لذا فهو موجود قبل تشغيل cloud-init ويُحلَّل owner: admin:admin عند الكتابة — دون runcmd، دون إصلاح ملكية:

- path: /var/home/admin/.ssh/authorized_keys
  permissions: "0600"
  owner: admin:admin
  content: |
    ${ssh_public_key}

كان sshd دائمًا مستعدًا. تُبلّغ sshd -T عن pubkeyauthentication yes، ويظهر admin في AllowUsers في كلا ملفَّي sshd_config المُضمَّنَين في العقدة. لم يكن هناك شيء لتفعيله قط — فقط ملف مفقود.

لا تُعد إضافة admin_user_credentials، ولا تعدّل sshd_config

كان admin_user_credentials مُضمَّنًا في terraform/modules/xc-site وأُعيد الأمر إلى وضعه السابق بعد جمع هذه الأدلة (#660، PR #663). إنه ليس ثغرة تنتظر الملء.

يُستبدل sshd_config أثناء التسجيل، لذا يُتجاهل أي تعديل عليه في أسوأ لحظة ممكنة.

لماذا يستجيب على عنوان واحد فقط

يرتبط sshd بـ 0.0.0.0:22، لكن العنوان الداخلي (SLI) فقط هو الموجود في مكدس شبكة المضيف بطريقة يستجيب عليها sshd. يُعاد تسمية eth0 إلى a-i-eth0 ولا يحمل أي IP للمضيف على الإطلاق — مستوى بيانات Argo يمتلك تلك الواجهة، وعنوان management/SLO الذي كان سيحمله يظهر على vhost0 عوضًا عن ذلك. تبقى بطاقتا الشبكة الأخريان على مكدس المضيف تحت أسمائهما الخاصة.

تم الاستطلاع من VM داخل VNet، على أحد CE:

management/SLO address    timed out
external address          timed out
internal/SLI address      OPEN     SSH-2.0-OpenSSH_8.7
an unused address         timed out    (control)

استطلاع العنوان الذي تعرف العقدة به يُعيد بالضبط ما يُعيده مجموعة أمان مُغلقة. لا شيء يحجبه؛ لا يوجد مستمع على ذلك العنوان.

لا تقرأ اسم واجهة الضيف لتحديد الشبكة الفرعية التي أنت عليها

أيٌّ من eth1 وeth2 يحمل العنوان الداخلي يختلف بين العقد في هذا النشر نفسه. القراءة المباشرة من الثلاثة CE:

f5-xc-ce-vm-01    eth1 -> external      eth2 -> internal/SLI
f5-xc-ce-vm-02    eth2 -> external      eth1 -> internal/SLI
f5-xc-ce-vm-03    eth1 -> external      eth2 -> internal/SLI

شيئان فقط ثابتان على كل عقدة: a-i-eth0 لا يحمل عنوانًا، وvhost0 يحمل عنوان management/SLO. لأي شيء آخر، طابق على العنوان في مخرجات ip addr لا على اسم الواجهة.

العناوين العامة لـ CE لا يوجد عليها مستمع على المنفذ 22 أيضًا، وهو سبب استخدام الأمر أعلاه لـ -J: VM للمشغّل داخل VNet، في الشبكة الفرعية ذاتها لعناوين SLI. يبني هذا النشر واحدًا لهذا الغرض — يُسمّيه terraform output -raw client_vm_name.

-J لا يمرر خياراتك إلى قفزة الوسيط

الخيارات المعطاة في سطر الأوامر تنطبق على القفزة الأخيرة. لذا فإن -o UserKnownHostsFile=/dev/null إلى جانب -J لا يزال يستشير ويكتب في known_hosts الفعلية الخاصة بك لـ مضيف القفز، وهو المفاجأة إن كنت تحاول إبعاد أسطول مُعاد بناؤه عنه. وضّح القفزة الأولى عند أهمية ذلك:

ssh -tt -o ProxyCommand="ssh -W %h:%p -o UserKnownHostsFile=/dev/null azureuser@<operator-vm>" \
    -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_ed25519 "admin@$SLI"

خطآن في القياس يُنتجان إجابات خاطئة واثقة

استطلاع eth0، الواجهة الخارجية، أو العنوان العام للمنفذ 22 يُبلّغ عن إغلاق بغض النظر عن حالة SSH للعقدة، لذا لا يُخبرك بشيء على الإطلاق. العنوان SLI فقط هو الذي يستجيب.

واستطلاع من محطة عمل شركة قد يُبلّغ عن منفذ مفتوح في حين أنه مُغلق: يُكمل Netskope مصافحة TCP بنفسه على المنافذ الشائعة. المنفذان 80 و443 يبدوان مفتوحَين على العناوين العامة لـ CE من محطة عمل بينما هما مُغلقان عند الاستطلاع من داخل VNet. استطلع من VM داخل VNet.

تحتاج Site CLI إلى طرفية وإلى إرجاع حرف الإدخال

قشرة تسجيل دخول admin ليست shell. إنها تطبيق go-prompt يضع الطرفية في وضع raw ويقرأ ضربات المفاتيح لا الأسطر. أربع نتائج، كل منها يفشل بطريقة تبدو مشكلة مختلفة:

الآلية	ما يحدث في غيابها
تخصيص طرفية (ssh -tt)	panic: no such device or address من go-prompt.NewStandardInputParser، ما يبدو كتعطل الجهاز
إرسال إرجاع حرف (carriage return) لا تغذية سطر (line feed) لمفتاح Enter	لا يُرسَل السطر أبدًا، وتُغلق الجلسة عند نهاية الإدخال دون طباعة أي شيء
إبقاء الإدخال القياسي مفتوحًا	ينتهي الاتصال قبل عرض الأمر، فيبدو الأمر العامل صامتًا
كتابة نص الأمر وبايت Enter بشكل منفصل	يصل السطر الجديد إلى المخزن المؤقت كحرف حرفي ويُجيب الـ CLI بـ unknown command، ما يبدو كأن الأمر غير موجود

لذا لا يعمل ssh host 'some-command': المعطى يُتجاهل وتبدأ الموجه التفاعلي على أي حال. قُده كطرفية أو لا تقده أصلًا. scripts/sitecli_ssh_harvest.py هو التطبيق المرجعي.

ذعر بقراءة 'no such device or address' يعني نجاح المصادقة

يُصدره vpmu بعد تسجيل الدخول، حين لا يجد طرفية للارتباط بها. يبدو كتعطل عند قراءته كأسوأ نتيجة ممكنة، وهو في الواقع آخر خطأ قبل النجاح. أضف -tt وأعد الاتصال.

يتغير مفتاح مضيف CE لسببين مختلفين

يُحذّر الاتصال التالي من REMOTE HOST IDENTIFICATION HAS CHANGED ويرفض. امسح المدخل القديم لذلك العنوان وأعد الاتصال. سببان يُشغّلانه:

• استبدال العقدة. يُقدّم البديل مفتاحًا مختلفًا على العنوان ذاته. بما أن منح SSH يستبدل الـ VM بالكامل، توقع هذا عند أول اتصال بعد تبنّيه.
• ترقية نظام التشغيل في المكان، دون أي استبدال. لوحظ في 2026-07-28: قدّمت عقدة أكمل ترقية ce_os_version الخاصة بها مفتاح مضيف جديدًا على العنوان ذاته، على الجهاز الافتراضي نفسه.

StrictHostKeyChecking=accept-new لا يُساعد في أي من الحالتين. يقبل المفاتيح للمضيفين الذين لم يرَهم قط؛ المفتاح المُغيَّر هو بالضبط ما يرفضه. إزالة المدخل القديم فقط هي ما يحلّه.

يمكن للعناوين أن تتحرك أيضًا. إعادة إنشاء نشر يُعيد تعيينها من الشبكة الفرعية ذاتها، لذا قد ينتهي الأمر بتبادل CE ومضيف القفز للعناوين — وبعد ذلك لا يكون المدخل القديم متقادمًا فحسب، بل مُرفقًا بالجهاز الخاطئ.

البانر هو فحص صحة مجاني

قبل أن تكتب أي شيء، أجاب بانر تسجيل الدخول بالفعل على عدد من الأسئلة التي كنت ستقضي أوامر لمعرفتها. من f5-xc-ce-vm-01، مع حذف الرسم النصي ASCII والـ IP العام:

UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED
All actions performed on this device are audited

Using https://register.ves.volterra.io
OS: rhel-9.2024.6
Memory: 32768MiB
Storage: sda: 31GiB
CPU: Model: Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz | CPUs: 8
Software: crt-20250613-3382
DNS: 168.63.129.16: OK
NTP: Synced
Uptime: 0 days, 5 hours, 20 minutes
Registration Status: PROVISIONED
SLO IP: 10.0.1.4/26
WELCOME IN SITE CLI

يُميّز Registration Status عقدة لا تزال في مرحلة الإنشاء (PROVISIONING) عن تلك التي أنهت (PROVISIONED). Software هي سلسلة البناء التي تحدد الأوامر الموجودة. يُغطّي DNS وNTP التبعيتَين اللتَين تعطلان التسجيل أولًا، لذا فإن عقدة لم تأتِ على الإنترنت عادةً ما تكون قد أخبرتك بالسبب هنا — قبل الحاجة إلى chronyc-sources أو dig أصلًا.

توفير زوج المفاتيح

1. أنشئ زوج مفاتيح إن لم يكن لديك واحد. Ed25519 بدلًا من RSA: أقصر، ومقبول من sshd الجهاز.

   ssh-keygen -t ed25519 -C "ce-operator" -f ~/.ssh/id_ed25519

2. وجّه النشر إلى النصف العام. تقرأ وحدة المعالجة الجذر الملف مرة واحدة وتُمرّر السلسلة النصية إلى كل عقدة:

   terraform/terraform.tfvars

   ssh_public_key_path = "~/.ssh/id_ed25519.pub"

   يأخذ ssh_public_key المادة مضمّنة عوضًا عن ذلك، وهو ما تستخدمه اختبارات الخطة. النصف الخاص لا يغادر محطة عملك أبدًا.

3. طبّق. اقرأ التحذير في أعلى هذه الصفحة أولًا — على نشر موجود سيستبدل هذا CE VMs.

admin_ssh_key الخاص بـ VM شيء مختلف

يُخوّل azurerm_linux_virtual_machine.admin_ssh_key في modules/ce-node مدير Azure VM، لا حساب admin على الجهاز. لا يمنح وصولًا إلى Site CLI، وتعيينه ليس دليلًا على إعداد CE SSH.

ما ليس هذا

تم اختبار كل مما يلي واستبعاده أثناء الاعتقاد بأن المسار مستحيل. كل منها معقول بما يكفي لاستهلاك يوم كامل.

ليس السبب	كيف استُبعد
البيانات الاعتمادية تنطبق فقط عند الإنشاء	يبدأ sshd نحو 90 ثانية في أول تشغيل، قبل وجود كائن الموقع. admin_user_credentials موجود أيضًا في ReplaceSpecType ويُطبَّق في المكان.
block_all_services	إغلاق المنفذ 22 على عنوان management متطابق سواء كانت الخدمات محجوبة أم لا.
سطر جديد في نهاية المفتاح	اختُبر بالطريقتين، لا تغيير. cloud-init يجردها على أي حال، لأن كتلة حرفية ستُصيّر سطرًا ثانيًا فارغًا.
برمجيات CE أقدم أو مُثبَّتة	جُرّبت على ثلاثة بناءات، بما فيها واحدة تعمل بـ OpenSSH 9.9.
admin_password مفقود	تعيين admin_password إلى جانب ssh_key على CE جديد من الصفر لم يغيّر شيئًا.

حقلا API يبدوان كمميّزات وليسا كذلك

gc_spec.admin_ssh_key فارغ أو غائب على جميع الـ 58 موقعًا في f5-sales-demo — بما فيها الموقعان اللذان يُعيّنان admin_user_credentials.ssh_key. مقارنته بين موقع عامل وآخر غير عامل لا تُخبرك بشيء، لأنه يُقرأ فارغًا حتى للمواقع التي تمت فيها إعداد البيانات الاعتمادية.

registrations_by_site يحذف الحقل كليًا ويُعيد None له، ما يُقرأ كـ “غير مُعدَّة” لا “غير مُبلَّغ عنها”.

المسارات الأخرى

Debug APIScripted, needs no access inside the VNet, and the right choice for repeatable evidence. Covers 34 commands and needs the site ONLINE.

Site ConsoleF5's node troubleshooting UI over an Azure Bastion tunnel. No key, no jump host, and it answers before the site registers.

Serial consoleFor a node that never registered, or has no working network path. Needs a terminal, or the websocket harness.

يحتاج موقع تم إنشاؤه حديثًا نحو نصف ساعة قبل أن يستجيب debug API

لمدة تتراوح بين 25 و30 دقيقة تقريبًا بعد إبلاغ موقع جديد بـ ONLINE، تُعيد نقاط نهاية vpm/debug صفحة 503 من BIG-IP تقرأ The requested URL was rejected. يبدو ذلك كحجب من جدار حماية تطبيقات الويب، أو رمز مميز مُلغى، وليس أيًا منهما: الموقع ليس جاهزًا للتوصيل بعد. انتظر وأعد المحاولة بدلًا من تغيير أي شيء.

لا يوجد لـ SSH مثل هذا الإحماء. يستجيب بمجرد تشغيل sshd، وهو سبب كونه المسار الذي يعمل بينما لا تزال العقدة في مرحلة التسجيل.