docs: record 24 deploy ssh auth recovery

journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md

@@ -15,7 +15,8 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
 
 ## 결정
 - 이번 문제는 `rb8001` 코드가 아니라 `배포 인프라 경로 + 51123 runner 실행층` 문제로 다룬다.
-- `c7bca94`로 `.env.deploy`와 예시 파일은 이미 SSOT에 맞춰졌으므로, 이제 수정 우선순위는 `runner 실행 복구 -> dispatch/task 로그 확인 -> workflow 본문 재진입 검증 -> 필요 시 secret/variable화` 순서다.
+- `c7bca94`로 `.env.deploy`와 예시 파일은 이미 SSOT에 맞춰졌고, `github_deploy` 공개키를 24 `authorized_keys`에 반영해 수동 SSH 인증도 복구됐다.
+- 따라서 남은 우선순위는 `runner 실행 복구 확인 -> deploy key 인증 유지 확인 -> workflow 본문 재진입 검증 -> 24에서 최종 닫힘/worklog 작성` 순서다.
 
 ## 범위
 - 포함:
@@ -23,7 +24,7 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
   - runner 시작 방식과 운영 기준(systemd vs script) 정리
   - 최신 `#677`과 같은 `0s` 종료 run의 dispatch/task fetch 경로 확인
   - 24 배포 대상 host/port/path SSOT 확인
-  - 필요 시 Gitea Actions secret/variable 교정
+  - 23 runner deploy key와 24 `authorized_keys` 정합성 확인
   - 실제 push 기반 자동 배포 재검증
 - 제외:
   - 애플리케이션 기능 수정
@@ -33,17 +34,18 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
 1. 51123에서 runner 프로세스, 시작 스크립트, 등록 정보(`/etc/act_runner/.runner`)를 기준으로 실제 기동 경로를 확정한다.
 2. `/home/admin/scripts/start-act-runner.sh` 기반 재기동 구조가 맞는지 확인하고, 같은 방식으로 runner를 재기동해 `ps -ef`, `act_runner.log`, Gitea DB `action_runner.last_online`이 현재 시각으로 갱신되는지 본다.
 3. backlog가 다시 흐르기 시작하는지 `action_task` 신규 row 생성과 pending queue 감소로 확인한다.
-4. `rb8001 #677`이 backlog를 통과하면 `action_run_job.task_id`가 `0`에서 실제 task id로 바뀌는지 확인한다.
-5. `rb8001/.gitea/workflows/cicd.yml`, `.env.deploy`, `.env.deploy.example`가 현재 SSOT(`192.168.0.106:51124`, `/home/admin/robeing/rb8001`)를 유지하는지 재확인한다.
-6. workflow가 본문에 진입하면 SSH 접속, `git pull`, `docker compose down && docker compose up -d --build`, health check까지 실제 로그를 확인한다.
-7. backlog를 지나도 `rb8001`만 `task_id=0`이면 `#677` 재실행 또는 새 push 재트리거로 개별 run 상태를 분리 진단한다.
-8. runner 재기동 후에도 `0s` 종료가 계속되면 Gitea의 runner online 상태, dispatch/task 저장 경로, repo-level Actions 설정을 추가로 점검한다.
-9. 복구 후 runner 운영 방식을 systemd 유닛 또는 동등한 자동복구 경로로 정리해, 수동 스크립트만 남는 단일 장애점을 제거한다.
+4. `rb8001/.gitea/workflows/cicd.yml`, `.env.deploy`, `.env.deploy.example`가 현재 SSOT(`192.168.0.106:51124`, `/home/admin/robeing/rb8001`)를 유지하고, `DEPLOY_SSH_KEY_PATH=/home/admin/.ssh/github_deploy`가 실제 운영 키와 일치하는지 재확인한다.
+5. 24 `admin ~/.ssh/authorized_keys`에 `github_deploy` 공개키가 유지되는지 확인하고, 51123에서 `ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 'echo SSH_OK'` 재검증을 남긴다.
+6. `rb8001`을 단독으로 다시 실행해 `action_run_job.task_id`가 실제 task id로 바뀌는지, `Test SSH Connection`을 넘어 `Deploy to Target Server`까지 진입하는지 확인한다.
+7. workflow가 본문에 진입하면 `git pull`, `docker compose down && docker compose up -d --build`, health check까지 실제 로그를 확인한다.
+8. 복구 후 닫힘 판단과 worklog 작성은 24 서버에서 실제 배포 성공 근거를 붙여 마무리한다.
+9. runner 재기동 후에도 유사 증상이 반복되면 Gitea runner online 상태, dispatch/task 저장 경로, repo-level Actions 설정을 추가 점검하고, 운영 방식은 systemd 유닛 또는 동등한 자동복구 경로로 별도 승격한다.
 
 ## 완료 기준
 - `cicd.yml` task가 `0s` 종료가 아니라 checkout 이후 실제 실행 로그를 남긴다.
+- 51123에서 `github_deploy`로 24 `51124` 포트 수동 SSH가 지속적으로 성공한다.
 - Gitea DB 기준 `action_run_job.task_id != 0`, `action_task` 신규 row 생성, `action_runner.last_online` 현재 시각 갱신이 확인된다.
-- backlog가 실제로 감소하고, `rb8001 #677`도 queue 대기에서 task 실행 상태로 전이된다.
+- `rb8001` 새 run이 `Test SSH Connection`과 `Deploy to Target Server`를 통과한다.
 - `git push origin main` 후 24 서버 `rb8001` 컨테이너가 자동 재시작된다.
 - 수동 배포 없이도 `docker ps`, 헬스체크, 최신 커밋 반영이 확인된다.
 

journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md

@@ -37,6 +37,11 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
 - 재기동 직후 `act_runner.log`에는 `Starting runner daemon`, `runner ... declare successfully`, 신규 task `2109`, `2110` 시작 로그가 남았다.
 - Gitea DB `action_runner` 기준 runner id `4`의 `last_online`, `last_active`는 `2026-03-11 21:25:15+09`로 갱신됐다.
 - 2026-03-11 21:25 KST 기준 pending run은 총 8건이며, `rb8001 #677` 앞에 더 이른 시각의 pending run 6건이 남아 있다.
+- 이후 `rb8001` workflow 화면상 `Setup SSH`는 통과했고 `Test SSH Connection` 단계에서 약 57초 정체했다.
+- 현재 `rb8001/.env.deploy`의 `DEPLOY_SSH_KEY_PATH`는 `/home/admin/.ssh/github_deploy`다.
+- 2026-03-11 51123에서 `ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106` 수동 접속은 `Permission denied (publickey,password)`로 실패했다.
+- 24 서버 `admin ~/.ssh/authorized_keys`에는 기존 `51123-to-51124-deploy` RSA 키는 있었지만, `github_deploy`의 `ssh-ed25519` 공개키는 없었다.
+- `ssh-keygen -y -f /home/admin/.ssh/github_deploy`로 산출한 공개키를 24 `authorized_keys`에 추가한 뒤, `ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 'echo SSH_OK'`가 성공했다.
 
 ## Interpretation
 - 수동 배포가 정상 성공하고, `.env.deploy` 계열도 `c7bca94` 이후 SSOT에 맞춰졌기 때문에 `rb8001` 코드나 현재 저장소 파일 상태만으로 최신 `0s` 종료를 설명하기는 어렵다.
@@ -44,6 +49,8 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
 - 특히 runner 프로세스가 현재 없고 로그도 2026-03-06 이후 멈춰 있으므로, 최신 `#677`은 workflow 본문 실행 전 dispatch/task fetch 단계에서 종료됐을 가능성이 높다.
 - `action_run_job.task_id=0`와 `action_task` 신규 생성 부재가 함께 보여서, 최신 이슈는 `job 생성 후 task 할당이 되지 않는 상태`로 보는 것이 가장 근거가 강하다.
 - 다만 재기동 뒤 신규 task가 실제로 다시 생성되는 것이 확인됐으므로, 지금 남은 상태를 `runner fetch 경로 완전 불능`으로 보기는 어렵고 `backlog 복구 진행 중`으로 보는 편이 정확하다.
+- 이후 단계별 수동 검증으로 보면, `Setup SSH` 통과와 `github_deploy` 직접 인증 실패가 함께 확인돼 남은 병목은 `23 runner가 읽는 deploy key`와 `24 authorized_keys`의 불일치로 좁혀진다.
+- 공개키 추가 후 `SSH_OK`가 즉시 반환됐으므로, 현재는 `23 -> 24 SSH 인증 경로` 자체는 복구된 상태로 판단할 수 있다.
 - 다만 2026-03-06의 `127.0.0.1:5432 connection refused`가 단발성인지, runner 중단의 직접 원인인지, 현재 재시작 불가와 연결되는지는 아직 확정할 수 없다.
 
 ## Unresolved
@@ -54,11 +61,14 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
 - runner 재기동 직후 `action_runner.last_online`이 현재 시각으로 갱신되는지
 - runner 재기동 후 `#677`이 기존 pending 상태에서 순차 처리되는지, 아니면 새 run을 만들어야 하는지
 - runner 재기동 후 동일 커밋 재실행 시 workflow 본문 로그가 실제로 생기는지
+- `rb8001` 새 run이 `Test SSH Connection` 이후 `Deploy to Target Server`까지 실제로 통과하는지
+- 24 서버에서 최종 배포 성공과 후속 정리(worklog, 닫힘 기준)가 확보되는지
 
 ## 결론
-- 현재는 `rb8001 deploy SSOT 불일치`가 1차 원인이었음은 확인됐지만, 2026-03-11 기준 남아 있는 최신 `0s` 종료는 `51123 self-hosted runner 실행층 중단`이 더 가까운 원인 후보다.
+- 현재는 `rb8001 deploy SSOT 불일치`가 1차 원인이었고, 2026-03-11 기준 남은 직접 병목은 `51123 runner 복구 이후 드러난 23 -> 24 deploy key 인증 불일치`로 보는 것이 가장 근거가 강하다.
 
 ## 권장
 - 1순위: `/home/admin/scripts/start-act-runner.sh`로 runner를 재기동하고 `ps -ef`, `act_runner.log`, `action_runner.last_online` 갱신 여부를 동시에 확인한다.
 - 2순위: backlog가 실제로 줄어드는지 확인하고, `rb8001 #677`이 대기열을 지나도 `task_id=0`이면 그때 `#677` 재실행 또는 새 push로 재트리거한다.
-- 3순위: runner 복구가 확인되면 수동 스크립트 의존을 줄이기 위해 systemd 유닛화 또는 동등한 부팅 자동복구 경로를 별도 계획으로 승격한다.
+- 3순위: `github_deploy` 공개키가 24 `authorized_keys`에 유지되는지 확인한 뒤 `rb8001`만 재실행해 `Test SSH Connection`과 실제 배포 단계를 통과하는지 검증한다.
+- 4순위: runner 복구가 확인되면 수동 스크립트 의존을 줄이기 위해 systemd 유닛화 또는 동등한 부팅 자동복구 경로를 별도 계획으로 승격한다.

journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md

@@ -40,6 +40,12 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
 - Gitea DB `action_runner` 기준 runner id `4`의 `last_online`, `last_active`는 `2026-03-11 21:25:15+09`로 갱신됐다.
 - 2026-03-11 21:25 KST 기준 pending run/job은 총 8건이며, `skill-slack`, `skill-email`, `auth-server`, `skill-calendar`, `robeing-monitor`, `admin-dashboard`, `rb8001`, `nginx-infra` 순으로 backlog가 남아 있다.
 - 따라서 현재 `rb8001 #677`은 `runner가 죽어서 영구 정지` 상태는 벗어났지만, 아직 자기 차례 task를 받기 전인 queue 대기 상태다.
+- 이후 `rb8001` workflow 로그를 재확인하니 `Setup SSH`는 통과했지만 `Test SSH Connection` 단계에서 약 57초 정체 후 더 진행되지 않았다.
+- 현재 `rb8001/.env.deploy`의 `DEPLOY_SSH_KEY_PATH`는 `/home/admin/.ssh/github_deploy`다.
+- 2026-03-11 51123에서 `ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106` 수동 테스트는 `Permission denied (publickey,password)`로 실패했다.
+- 같은 시각 24 서버 `~/.ssh/authorized_keys`에는 기존 `51123-to-51124-deploy` RSA 키는 있었지만, `github_deploy`에 대응하는 `ssh-ed25519` 공개키는 없었다.
+- 2026-03-11 `ssh-keygen -y -f /home/admin/.ssh/github_deploy`로 산출한 `github_deploy` 공개키를 24 서버 `admin ~/.ssh/authorized_keys`에 추가했다.
+- 추가 후 51123에서 `ssh -i /home/admin/.ssh/github_deploy -p 51124 admin@192.168.0.106 'echo SSH_OK'`가 성공해 `23 runner -> 24 SSH 인증` 경로가 실증적으로 복구됐다.
 
 ## 현재 해석
 - `rb8001` 저장소의 deploy SSOT 불일치 자체는 `c7bca94`로 상당 부분 해소됐고, 이 사실만으로는 최신 `0s` 종료를 더 이상 설명하기 어렵다.
@@ -47,7 +53,8 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
 - 특히 runner 프로세스 부재, systemd 유닛 부재, 로그 정지 시점(2026-03-06)이 함께 보여서 최신 `#677`은 workflow 본문 이전 단계에서 종료됐을 가능성이 높다.
 - DB 기준으로도 `#677`은 task 미생성 대기 상태라, `0s 종료`는 workflow 내부 스텝 실패보다 `runner fetch/할당 경로 미작동` 해석이 더 맞다.
 - 재기동 이후 새 task가 다시 생성되는 것이 실증됐으므로, `runner fetch 경로 자체는 복구 가능`함이 확인됐다.
-- 남은 미해결 범위는 `rb8001 #677` 개별 run이 backlog를 통과해 실제 task를 할당받고 24 자동배포까지 닫히는지 여부다.
+- 이후 수동 SSH 테스트 결과, 남은 핵심 병목은 `runtime SSOT` 자체보다 `23에서 사용하는 deploy key`가 24에 등록되지 않았던 인증 불일치였음이 확인됐다.
+- runner 실행층과 SSH 인증 경로는 각각 별개로 확인됐고, 현재 남은 미해결 범위는 `rb8001` 새 run이 실제로 `Test SSH Connection -> Deploy to Target Server`까지 통과하는지 여부다.
 - 다만 `start-act-runner.sh`의 `--config .runner` 사용이 실제 재기동 실패와 연결되는지는 아직 미확정이므로, 관측 사실과 추정 원인을 분리해서 다뤄야 한다.
 
 ## 직접 영향
@@ -56,4 +63,4 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
 - runner가 실제로 죽어 있으면 `rb8001`뿐 아니라 같은 self-hosted runner를 쓰는 다른 저장소도 dispatch를 받아도 실행층에서 멈출 수 있다.
 
 ## 한 줄 결론
-- 이번 자동 배포 실패는 `rb8001 deploy SSOT 불일치`에서 시작됐지만, 2026-03-11 기준 남아 있는 `0s` 종료의 더 유력한 원인은 `51123 self-hosted runner 실행층 중단`이다.
+- 이번 자동 배포 실패는 `rb8001 deploy SSOT 불일치`에서 시작됐지만, 2026-03-11 기준 실증된 직접 병목은 `51123 self-hosted runner 복구 이후에도 남아 있던 23 -> 24 deploy key 인증 불일치`다.