SSH

이 배포의 CE 중 하나에서 2026-07-28에 캡처되었습니다. 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"

해당 명령줄의 모든 부분은 필수적이며, 다음 세 섹션에서 각 요소가 방지하는 장애를 설명합니다.

착지할 쉘 프롬프트는 없습니다: admin의 로그인 쉘 자체가 Site CLI이므로, 해당 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가 사용하던 주소를 보유했을 수 있습니다. 따라서 기억하고 있는 주소로 접속하면 잘못된 노드, CE가 아닌 VM, 또는 아무 곳에도 연결되지 않을 수 있으며, 마지막 경우는 “SSH가 활성화되지 않음”과 동일하게 보입니다.

terraform output -json ce_sli_private_ips가 해당 매핑을 제공합니다. 상태를 확인할 수 없는 경우, 주소는 변경되더라도 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

부트스트랩 전용 — 기존 CE는 재생성 없이 SSH를 추가할 수 없습니다

cloud-init의 write_files는 최초 부팅 시 한 번만 실행됩니다. 이후 노드에 /etc/cloud/cloud-init.disabled 마커가 생성되며 cloud-init은 다시 실행되지 않습니다.

따라서 실행 중인 CE에 인플레이스로 적용하는 방법은 없습니다. Azure에서 custom_data는 교체 전용이므로, 기존 배포에 이를 적용하면 모든 CE VM이 교체됩니다. 이미 가동 중인 노드에 운영자 SSH 권한을 부여하는 것은 구성 변경이 아니라 재구축입니다 — 다음 경고는 해당 재구축이 이전에 어떤 비용을 초래했는지, 그리고 왜 지금은 그렇지 않은지를 설명합니다.

CE VM 교체 시 등록이 영구적으로 막히는 문제가 있었으나 수정되었으며, 이것이 사이트 객체와 VM이 결합된 이유입니다

재구축을 계획하기 전에 알아두어야 할 사항입니다. 장애의 형태가 플랜에서 볼 수 있는 결합 구조를 설명하기 때문입니다.

이전에는 삭제된 노드의 등록이 컨트롤 플레인의 고유한 (tenant, cluster_name, hostname) 인덱스를 유지했기 때문에, 교체 노드의 등록이 UniqueSecondaryIndexViolationError로 거부되고 무한 재시도 상태가 되었습니다. 등록을 삭제하는 것만으로는 충분하지 않았습니다: 남아 있는 StatusObject가 워크로드 요청에 500을 반환했고, 그 시점에서 각 노드는 삭제한 등록에 고정된 registration-obj.yml을 영구 저장했기 때문에 자기 복구 없이 404로 루프했습니다. 복구에는 두 번의 완전한 재구축이 필요했습니다. 그 과정 내내 terraform plan은 “No changes” 를 보고했는데, Terraform의 관점에서는 원하는 상태에 도달했기 때문입니다.

Issue 674는 PR 693에 의해 해결되었습니다. 이제 modules/xc-site는 CE VM 인스턴스를 replace_triggered_by에 명시하여, VM을 교체하면 사이트 객체도 교체되고, 사이트를 삭제하면 해당 등록도 함께 삭제됩니다 — 교체 노드가 부팅되기 전에 인덱스 키가 해제됩니다. 이후 플릿이 처음부터 재구축되었으며 세 사이트 모두 개입 없이 ONLINE 상태로 올라왔습니다.

결합은 가정이 아닌 관찰 가능한 사실입니다. 각 사이트는 VM 인스턴스 ID에 바인딩되며, 일치하는 등록이 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의 shadow 최종 변경 날짜는 이미지 빌드 날짜로 유지되는 반면 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은 노드에 포함된 두 개의 sshd_config 파일 모두에서 AllowUsers에 나타납니다. 활성화할 것이 전혀 없었습니다 — 단지 파일이 없었을 뿐입니다.

admin_user_credentials를 다시 추가하거나 sshd_config를 편집하지 마십시오

admin_user_credentials는 terraform/modules/xc-site에 연결되었다가 이 증거가 수집된 후 되돌려졌습니다(#660, PR #663). 채워야 할 공백이 아닙니다.

sshd_config는 등록 중에 교체되므로 편집 내용은 가장 불편한 순간에 폐기됩니다.

하나의 주소에서만 응답하는 이유

sshd는 0.0.0.0:22에 바인딩되지만, sshd가 응답하는 방식으로 호스트 네트워크 스택에 있는 주소는 내부(SLI) 주소뿐입니다. eth0은 a-i-eth0으로 이름이 변경되고 호스트 IP를 전혀 가지지 않습니다 — Argo 데이터 플레인이 해당 인터페이스를 소유하며, 원래 있어야 할 관리/SLO 주소는 대신 vhost0에 나타납니다. 나머지 두 NIC는 자체 이름으로 호스트 스택에 유지됩니다.

VNet 내부의 VM에서 하나의 CE를 대상으로 프로빙한 결과:

관리/SLO 주소        타임아웃
외부 주소            타임아웃
내부/SLI 주소        열림     SSH-2.0-OpenSSH_8.7
사용되지 않는 주소    타임아웃    (대조군)

노드를 알고 있는 주소로 프로빙하면 닫힌 보안 그룹이 반환하는 것과 정확히 동일한 결과가 나옵니다. 아무것도 차단하지 않으며, 해당 주소에 리스너가 없는 것입니다.

게스트 인터페이스 이름으로 서브넷을 파악하지 마십시오

eth1과 eth2 중 어느 것이 내부 주소를 전달하는지는 이 동일한 배포의 노드 간에도 다릅니다. 세 CE 모두에서 라이브로 읽은 결과:

f5-xc-ce-vm-01    eth1 -> 외부      eth2 -> 내부/SLI
f5-xc-ce-vm-02    eth2 -> 외부      eth1 -> 내부/SLI
f5-xc-ce-vm-03    eth1 -> 외부      eth2 -> 내부/SLI

모든 노드에서 일정한 것은 두 가지뿐입니다: a-i-eth0은 주소가 없고, vhost0은 관리/SLO 주소를 전달합니다. 그 외의 모든 것은 인터페이스 이름이 아닌 ip addr 출력의 주소를 기준으로 매칭하십시오.

CE 공용 주소에도 22번 포트에 리스너가 없으므로, 위의 명령이 -J를 통해 이동하는 이유입니다: SLI 주소와 동일한 서브넷에 있는 VNet 내부의 운영자 VM이 필요합니다. 이 배포는 해당 목적으로 하나를 구축합니다 — terraform output -raw client_vm_name이 그 이름을 제공합니다.

-J는 점프 레그에 옵션을 전달하지 않습니다

명령줄에서 주어진 옵션은 최종 홉에 적용됩니다. -J와 함께 -o UserKnownHostsFile=/dev/null을 지정해도 점프 호스트에 대해서는 여전히 실제 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 핸드셰이크를 완료합니다. 워크스테이션에서 CE 공용 주소의 80번과 443번 포트는 열린 것으로 읽히지만 VNet 내부에서 프로빙하면 닫혀 있습니다. VNet 내부의 VM에서 프로빙하십시오.

Site CLI에는 터미널과 캐리지 리턴이 필요합니다

admin 로그인 쉘은 일반 쉘이 아닙니다. 터미널을 raw 모드로 전환하고 라인이 아닌 키 입력을 읽는 go-prompt 애플리케이션입니다. 네 가지 결과가 있으며, 각각 다른 문제처럼 보이는 방식으로 실패합니다:

설정	없을 때 발생하는 문제
터미널 할당(ssh -tt)	go-prompt.NewStandardInputParser에서 panic: no such device or address 발생, 어플라이언스가 충돌한 것처럼 보임
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. 키페어가 아직 없다면 생성합니다. RSA 대신 Ed25519를 사용하십시오: 더 짧고 어플라이언스 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 VM이 교체됩니다.

VM 자체의 admin_ssh_key는 별개입니다

modules/ce-node의 azurerm_linux_virtual_machine.admin_ssh_key는 어플라이언스 admin 계정이 아닌 Azure VM 관리자를 인증합니다. Site CLI 접근 권한을 부여하지 않으며, 이것이 설정되어 있다고 해서 CE SSH가 구성되었다는 증거가 아닙니다.

해당하지 않는 것

다음 각 항목은 경로가 불가능하다고 여겨지는 동안 테스트되고 배제되었습니다. 각각 하루를 낭비할 만큼 그럴듯합니다.

원인이 아닌 것	배제 방법
자격증명은 생성 시에만 적용됨	sshd는 사이트 객체가 존재하기 전인 최초 부팅 후 약 90초에 시작됩니다. admin_user_credentials는 ReplaceSpecType에도 있으며 인플레이스로 적용됩니다.
block_all_services	관리 주소의 22번 포트 닫힘은 서비스 차단 여부에 관계없이 동일합니다.
키에 후행 줄 바꿈	두 가지 방식 모두 테스트했으나 변화 없음. cloud-init이 여전히 이를 제거하는데, 리터럴 블록은 그렇지 않으면 두 번째 빈 줄을 렌더링합니다.
고정된 구버전 CE 소프트웨어	OpenSSH 9.9를 실행하는 빌드를 포함한 세 번의 빌드에서 재현됨.
admin_password 누락	처음부터 새로운 CE에서 ssh_key와 함께 admin_password를 설정해도 변화 없음.

판별자처럼 보이지만 그렇지 않은 두 가지 API 필드

gc_spec.admin_ssh_key는 admin_user_credentials.ssh_key를 설정한 두 사이트를 포함하여 f5-sales-demo의 모든 58개 사이트에서 비어 있거나 없습니다. 동작하는 사이트와 동작하지 않는 사이트 간에 비교해도 아무런 정보를 얻을 수 없습니다. 자격증명이 실제로 구성된 사이트에서도 비어 있는 것으로 읽히기 때문입니다.

registrations_by_site는 해당 필드를 완전히 생략하고 None을 반환하는데, 이는 “구성되지 않음”이 아니라 “보고되지 않음”으로 읽힙니다.

다른 경로

Debug API스크립트로 구동 가능하며, VNet 내부 접근이 필요 없고, 반복 가능한 증거 수집에 적합합니다. 34개의 명령어를 다루며 사이트가 ONLINE 상태여야 합니다.

사이트 콘솔Azure Bastion 터널을 통한 F5의 노드 문제 해결 UI입니다. 키나 점프 호스트가 필요 없으며 사이트 등록 전에도 응답합니다.

시리얼 콘솔등록되지 않았거나 네트워크 경로가 없는 노드에 사용합니다. 터미널 또는 웹소켓 하네스가 필요합니다.

새로 생성된 사이트는 debug API가 응답하기까지 약 30분이 필요합니다

새 사이트가 ONLINE을 보고한 후 약 25~30분 동안 vpm/debug 엔드포인트는 The requested URL was rejected라는 BIG-IP 503 페이지를 반환합니다. 이는 웹 애플리케이션 방화벽 차단이나 폐기된 토큰처럼 보이지만 둘 다 아닙니다: 사이트가 아직 릴레이할 준비가 되지 않은 것입니다. 아무것도 변경하지 말고 기다렸다가 재시도하십시오.

SSH에는 이런 워밍업이 없습니다. sshd가 올라오는 즉시 응답하므로, 노드가 아직 등록 중일 때 동작하는 경로가 바로 SSH입니다.