SSH

บันทึกเมื่อ 2026-07-28 จาก CE หนึ่งตัวของการปรับใช้นี้ sitecli/capture-manifest.json บันทึกโหนดที่ใช้ และ scripts/capture-sitecli.sh --check ตรวจสอบพื้นผิวคำสั่งอีกครั้ง กับ CE ที่ใช้งานจริง

SSH เข้าถึงบัญชี admin ของอุปกรณ์ ซึ่งมี login shell เป็น 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 prompt ให้ลงจอด: login 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; การสร้างก่อนหน้ามีลำดับแตกต่างออกไปโดยสิ้นเชิง และ NIC ของไคลเอนต์ทดสอบอยู่ใน ซับเน็ตเดียวกันและเคยถือที่อยู่ที่ CE เคยถือมาก่อน การเชื่อมต่อไปยังที่อยู่ที่จำไว้ จึงอาจลงเอยที่โหนดผิด บน VM ที่ไม่ใช่ CE หรือไม่ไปถึงไหนเลย — และอย่างสุดท้าย ดูเหมือน “SSH ไม่ได้เปิดใช้งาน” ทุกประการ

terraform output -json ce_sli_private_ips คือการแมปที่ใช้ได้ หากไม่มี state ในมือ ชื่อ NIC คงที่แม้ที่อยู่จะไม่คงที่:

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

cloud-init write_files ทำงาน ครั้งเดียว เมื่อบูตครั้งแรก หลังจากนั้นจะมี ตัวบ่งชี้ /etc/cloud/cloud-init.disabled อยู่บนโหนด และ cloud-init จะไม่ทำงานอีก

ดังนั้นจึงไม่มีเส้นทางในสถานที่ไปยัง CE ที่กำลังทำงาน custom_data เป็นแบบแทนที่อย่างเดียว ใน Azure ซึ่งหมายความว่าการนำสิ่งนี้ไปใช้กับการปรับใช้ที่มีอยู่ จะแทนที่ CE VM ทุกตัว การให้สิทธิ์ SSH ของผู้ดำเนินการกับโหนดที่กำลังทำงานอยู่แล้วคือการสร้างใหม่ ไม่ใช่การเปลี่ยนแปลงการกำหนดค่า — และคำเตือนถัดไปคือสิ่งที่การสร้างใหม่นั้นเคยต้องใช้ และเหตุใดจึงไม่เป็นเช่นนั้นอีกต่อไป

ควรทราบก่อนวางแผนการสร้างใหม่ เพราะรูปแบบของความล้มเหลวอธิบาย การเชื่อมโยงที่คุณจะเห็นในแผน

เคยเป็นว่าการลงทะเบียนของโหนดที่ถูกลบยังคงถือดัชนีที่ไม่ซ้ำกัน (tenant, cluster_name, hostname) ของ control plane ดังนั้นการลงทะเบียนของโหนดทดแทนจึงถูกปฏิเสธด้วย UniqueSecondaryIndexViolationError และลองใหม่ตลอดเวลา การลบการลงทะเบียนนั้นไม่เพียงพอด้วยตัวเอง: StatusObject ที่เหลืออยู่ จะคืน 500 สำหรับคำขอ workload และ ณ จุดนั้นแต่ละโหนดได้บันทึก registration-obj.yml ที่ผูกไว้กับการลงทะเบียนที่คุณลบไปแล้ว ทำให้วนซ้ำบน 404 โดยไม่มีการกู้คืนด้วยตัวเอง การกู้คืนต้องใช้การสร้างใหม่สองครั้งเต็ม ตลอดเวลา terraform plan รายงาน “No changes” เพราะจากมุมมองของ Terraform สถานะที่ต้องการได้รับการบรรลุแล้ว

Issue 674 ปิดแล้ว โดย PR 693 ขณะนี้ modules/xc-site ตั้งชื่อ CE VM instance ใน replace_triggered_by ดังนั้นการแทนที่ VM จะแทนที่ site object และการลบ site จะนำการลงทะเบียนไปด้วย — คีย์ดัชนีว่างก่อนที่โหนดทดแทนจะบูต ฟลีตได้รับการสร้างใหม่ตั้งแต่ต้นและทั้งสามไซต์ขึ้นมา ONLINE โดยไม่ต้องมีการแทรกแซง

การเชื่อมโยงนั้นสังเกตได้จริง ไม่ใช่แค่สมมติ แต่ละไซต์ผูกกับ VM instance id และการลงทะเบียนที่ตรงกันรายงานค่าเดียวกันกับ infra.instance_id:

cd terraform && terraform output -json ce_bound_instance_ids

ความไม่ตรงกันระหว่างทั้งสองหมายความว่าไซต์ยังคงผูกกับโหนดที่ไม่มีอยู่แล้ว ซึ่งเป็นสถานะที่ CE ที่สร้างใหม่ไม่สามารถออกจากการลงทะเบียนได้ การอ่านครึ่งหนึ่งของการลงทะเบียน ยังต้องใช้การเรียก API โดยตรง — provider issue 1376 คือสิ่งที่จะ นำมาไว้บน data source

เหตุใด cloud-init จึงเขียนคีย์ ไม่ใช่ API

admin_user_credentials.ssh_key บน site object ดูเหมือนฟิลด์สำหรับสิ่งนี้พอดี มันได้รับการยอมรับ มันคงอยู่หลังจาก read-back และมันไม่ได้กำหนดค่าอะไรเลย vpm เป็นเจ้าของ ผู้ใช้ในเครื่องของโหนดและปฏิเสธที่จะแตะตัวนี้ — จากล็อกของโหนดเอง สามครั้ง ในการบูตครั้งเดียว:

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

ทุกอย่างที่ตามมาเป็นผลจากบรรทัดเดียวนั้น /var/home/admin/.ssh ไม่เคยมีอยู่ ก่อนหรือ หลังจากที่ไซต์ถึง ONLINE วันที่เปลี่ยน shadow ของ admin คงอยู่ที่วันที่สร้าง image ในขณะที่ vesbkp และ vesopcon แสดงวันที่ปัจจุบัน เพราะ vpm ตั้งค่าทั้งสองนั้น และข้าม admin ไป และ vpm ไม่บันทึกอะไรเกี่ยวกับ ssh_key หรือ authorized_keys เลยในทุกจุด

ดังนั้นไฟล์จึงต้องเขียนนอก vpm admin คือ uid 2202 ที่ฝังอยู่ใน image ของโหนด ดังนั้นมันมีอยู่ก่อนที่ cloud-init จะทำงาน และ owner: admin:admin จะแก้ไขได้ตอนเขียน — ไม่ต้องมี runcmd ไม่ต้องแก้ไข ownership:

- 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 ทั้งสองที่มาพร้อมกับโหนด ไม่เคยมีอะไร ที่ต้องเปิดใช้งาน — มีแค่ไฟล์ที่หายไป

เหตุใดจึงตอบสนองที่ที่อยู่เดียวเท่านั้น

sshd ผูก 0.0.0.0:22 แต่มีเฉพาะที่อยู่ ภายใน (SLI) เท่านั้นที่อยู่บน host network stack ในแบบที่ sshd จะตอบสนอง eth0 ถูกเปลี่ยนชื่อเป็น a-i-eth0 และไม่มี host IP เลย — Argo data plane เป็นเจ้าของอินเทอร์เฟซนั้น และที่อยู่ management/SLO ที่มันจะถือ ปรากฏบน vhost0 แทน NIC อีกสองตัวยังคงอยู่บน host stack ภายใต้ชื่อของตัวเอง

ทดสอบจาก 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)

การทดสอบกับที่อยู่ที่คุณรู้จักโหนดจึงคืนค่าเหมือนกับที่ security group ปิดอยู่ ไม่มีอะไรบล็อกมัน ไม่มี listener บนที่อยู่นั้น

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 ก็ไม่มี listener บน 22 เช่นกัน ซึ่งเป็นสาเหตุที่คำสั่งด้านบน ผ่าน -J: VM ของผู้ดำเนินการภายใน VNet ในซับเน็ตเดียวกับที่อยู่ SLI การปรับใช้นี้สร้างขึ้นมาหนึ่งตัวเพื่อจุดประสงค์นี้ — terraform output -raw client_vm_name ตั้งชื่อมัน

ตัวเลือกที่ให้ในบรรทัดคำสั่งจะใช้กับ hop สุดท้าย ดังนั้น -o UserKnownHostsFile=/dev/null ที่ใช้คู่กับ -J จะยังคงเปิดอ่านและเขียน known_hosts จริงของคุณสำหรับ jump host ซึ่งเป็นสิ่งที่น่าประหลาดใจหากคุณพยายามไม่ให้ฟลีตที่สร้างใหม่เข้าไปอยู่ในนั้น สะกด hop แรกออกมาเมื่อสำคัญ:

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 จะทำการ handshake TCP เองบนพอร์ตทั่วไป พอร์ต 80 และ 443 อ่านว่าเปิดบน ที่อยู่สาธารณะของ CE จากเวิร์กสเตชันและปิดเมื่อทดสอบจากภายใน VNet ให้ทดสอบจาก VM ภายใน VNet

Site CLI ต้องการเทอร์มินัลและ carriage return

login shell ของ admin ไม่ใช่ shell มันคือแอปพลิเคชัน go-prompt ซึ่งนำเทอร์มินัล เข้าสู่ raw mode และอ่าน keystrokes แทนที่จะเป็นบรรทัด มีผลสี่ประการ แต่ละอย่างล้มเหลว ในแบบที่ดูเหมือนปัญหาคนละอย่าง:

กลไก	สิ่งที่เกิดขึ้นหากไม่มี
จัดสรรเทอร์มินัล (`ssh -tt`)	`panic: no such device or address` จาก `go-prompt.NewStandardInputParser` ซึ่งอ่านดูเหมือนอุปกรณ์ที่ crash
ส่ง carriage return ไม่ใช่ line feed สำหรับ Enter	บรรทัดไม่เคยถูกส่ง และเซสชันปิดเมื่อ end-of-input โดยไม่พิมพ์อะไร
เปิด standard input ไว้	การเชื่อมต่อสิ้นสุดก่อนที่คำสั่งจะแสดงผล ดังนั้นคำสั่งที่ทำงานได้จะดูเหมือนไม่มีเสียง
เขียนข้อความคำสั่งและไบต์ Enter แยกกัน	newline ลงเอยในบัฟเฟอร์เป็นอักขระตัวอักษรและ CLI ตอบ `unknown command` ซึ่งอ่านดูเหมือนคำสั่งไม่มีอยู่

ssh host 'some-command' จึงใช้ไม่ได้: อาร์กิวเมนต์ถูกเพิกเฉยและ prompt แบบโต้ตอบ เริ่มต้นอยู่ดี ให้ขับเคลื่อนมันเป็นเทอร์มินัลหรือไม่ก็เลิก scripts/sitecli_ssh_harvest.py คือ reference implementation

การเชื่อมต่อครั้งถัดไปจะเตือน REMOTE HOST IDENTIFICATION HAS CHANGED และปฏิเสธ ล้างรายการเก่า สำหรับที่อยู่นั้นและเชื่อมต่อใหม่ มีสองสิ่งที่ทริกเกอร์มัน:

การแทนที่โหนด การแทนที่นำเสนอคีย์ที่แตกต่างที่ที่อยู่เดิม เนื่องจากการให้สิทธิ์ SSH แทนที่ VM ทั้งหมด ให้คาดหวังสิ่งนี้ในการเชื่อมต่อครั้งแรกหลังจากนำมาใช้
การอัปเกรดระบบปฏิบัติการในสถานที่ โดยไม่มีการแทนที่เลย สังเกตเมื่อ 2026-07-28: โหนดที่การอัปเกรด ce_os_version เสร็จสมบูรณ์แสดง host key ใหม่ที่ที่อยู่เดิม บน virtual machine เดิม

StrictHostKeyChecking=accept-new ไม่ช่วยกับทั้งสองกรณี มันยอมรับคีย์สำหรับโฮสต์ที่ไม่เคย เห็นมาก่อน คีย์ที่ เปลี่ยน คือสิ่งที่มันปฏิเสธพอดี มีเพียงการลบรายการที่เก่าเท่านั้นที่แก้ไขได้

ที่อยู่ก็อาจย้ายได้เช่นกัน การสร้างการปรับใช้ใหม่จะกำหนดที่อยู่ใหม่จากซับเน็ตเดิม ดังนั้น CE และ jump host อาจสลับที่อยู่กัน — หลังจากนั้นรายการที่เก่าไม่ได้แค่ล้าสมัย แต่แนบกับเครื่องผิด

ก่อนที่คุณจะพิมพ์อะไร login banner ได้ตอบคำถามหลายข้อที่คุณจะต้องใช้คำสั่งไปถามไปแล้ว จาก f5-xc-ce-vm-01 ASCII art และ public 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 คือ build string ที่กำหนดว่าคำสั่งใดมีอยู่ DNS และ NTP ครอบคลุมสองข้อกำหนดที่ทำลายการลงทะเบียนก่อน ดังนั้นโหนดที่ไม่เคย ออนไลน์มักจะบอกคุณว่าทำไมที่นี่แล้ว — ก่อนที่จะต้องใช้ chronyc-sources หรือ dig เลย

การจัดหา keypair

สร้าง keypair หากคุณยังไม่มี Ed25519 แทนที่จะเป็น RSA: สั้นกว่า และได้รับการยอมรับจาก sshd ของอุปกรณ์
Terminal window
```
ssh-keygen -t ed25519 -C "ce-operator" -f ~/.ssh/id_ed25519
```
ชี้การปรับใช้ไปที่ครึ่ง สาธารณะ root module อ่านไฟล์ครั้งเดียว และส่ง string ลงไปทุกโหนด:
terraform/terraform.tfvars
```
ssh_public_key_path = "~/.ssh/id_ed25519.pub"
```
ssh_public_key รับเนื้อหา inline แทน ซึ่งเป็นสิ่งที่ plan tests ใช้ ครึ่งส่วนตัวไม่เคยออกจากเวิร์กสเตชันของคุณ
Apply อ่านคำเตือนที่ด้านบนของหน้านี้ก่อน — บนการปรับใช้ที่มีอยู่ สิ่งนี้ จะแทนที่ CE VM

สิ่งที่นี่ไม่ใช่

แต่ละอย่างเหล่านี้ได้รับการทดสอบและถูกตัดออกในขณะที่ยังเชื่อว่าเส้นทางนั้นเป็นไปไม่ได้ แต่ละอย่างมีความน่าเชื่อถือพอที่จะเสียเวลาได้หนึ่งวัน

ไม่ใช่สาเหตุ	วิธีที่ถูกตัดออก
credential ใช้ได้เฉพาะตอน create เท่านั้น	`sshd` เริ่มต้นประมาณ 90 วินาทีหลังบูตครั้งแรก ก่อนที่ site object จะมีอยู่ `admin_user_credentials` ยังปรากฏใน `ReplaceSpecType` และใช้ in place
`block_all_services`	การปิดพอร์ต 22 บนที่อยู่ management เหมือนกันไม่ว่าบริการจะถูกบล็อกหรือไม่
trailing newline บนคีย์	ทดสอบทั้งสองแบบ ไม่มีการเปลี่ยนแปลง cloud-init ยังคง strip มันออก เพราะ literal block จะแสดงผลเป็นบรรทัดที่สอง ว่าเปล่า
CE software เวอร์ชันเก่าที่ถูก pin	ทำซ้ำได้บนสาม builds รวมถึงหนึ่งที่รัน OpenSSH 9.9
`admin_password` ที่หายไป	การตั้ง `admin_password` ควบคู่กับ `ssh_key` บน CE ที่สร้างจากศูนย์ไม่ได้เปลี่ยนแปลงอะไร

gc_spec.admin_ssh_key ว่างเปล่าหรือไม่มีอยู่บน ไซต์ทั้ง 58 ไซต์ใน f5-sales-demo — รวมถึง สองไซต์ที่ตั้ง admin_user_credentials.ssh_key การเปรียบเทียบระหว่างไซต์ที่ทำงานได้และ ไม่ทำงานบอกคุณอะไรไม่ได้ เพราะมันอ่านว่าว่างแม้แต่กับไซต์ที่ มี การกำหนดค่า credential

registrations_by_site ละเว้นฟิลด์นี้โดยสิ้นเชิงและคืน None สำหรับมัน ซึ่งอ่านว่า “ไม่ได้กำหนดค่า” มากกว่า “ไม่ได้รายงาน”

เส้นทางอื่น ๆ

Debug APIใช้สคริปต์ได้ ไม่ต้องการการเข้าถึงภายใน VNet และเป็นตัวเลือกที่ถูกต้องสำหรับหลักฐานที่ทำซ้ำได้ ครอบคลุม 34 คำสั่งและต้องการให้ไซต์ ONLINE

Site ConsoleUI สำหรับแก้ปัญหาโหนดของ F5 ผ่านอุโมงค์ Azure Bastion ไม่ต้องใช้คีย์ ไม่ต้องใช้ jump host และตอบสนองก่อนที่ไซต์จะลงทะเบียน

Serial consoleสำหรับโหนดที่ไม่เคยลงทะเบียน หรือไม่มีเส้นทางเครือข่ายที่ใช้งานได้ ต้องการเทอร์มินัลหรือ websocket harness

ประมาณ 25 ถึง 30 นาทีหลังจากที่ไซต์ใหม่รายงาน ONLINE endpoint vpm/debug จะคืนหน้า BIG-IP 503 ที่อ่านว่า The requested URL was rejected นั่นดูเหมือน การบล็อกของ web application firewall หรือ token ที่ถูกเพิกถอน และไม่ใช่ทั้งสองอย่าง: ไซต์ยังไม่พร้อมที่จะส่งต่อ รอและลองใหม่แทนที่จะเปลี่ยนแปลงอะไร

SSH ไม่มีการอุ่นเครื่องเช่นนั้น มันตอบสนองทันทีที่ sshd ขึ้นมา ซึ่งเป็นเหตุผลที่มัน เป็นเส้นทางที่ใช้งานได้ในขณะที่โหนดยังลงทะเบียนอยู่