편리함의 함정
문서 예제의 ForwardAgent yes 를 그대로 복사하면 사람 디버깅과 무인 Runner 가 같은 전략을 공유한다. 노트북 ssh-agent 에 개인 GitHub 키와 회사 키가 섞이면 공격면을 모두 적어낼 수 없다.
전달된 agent 소켓은 리모트 Unix 사용자 공간에서 다른 프로세스가 서명 요청을 반복 시도할 수 있게 한다. launchd·cron·패키지 후크가 같은 계정에 있으면 노출 시간이 길어진다.
노트북→바스션→리모트 Mac→사내 Git 네 홉 중 어디든 높은 권한 계정이 관측할 수 있다. 이는 ControlMaster 가 다루는 성능 문제와 다른 축이다.
배포 산출물 SFTP 계정과 소스 checkout 을 하나의 Unix 사용자에 얹으면 ForwardAgent 남용 시 두 영역을 동시에 오염한다.
조직이 장기적으로 바스션 인프라를 재편할 때 ForwardAgent 정책을 함께 재검토하지 않으면 새 호스트명과 오래된 예외 규칙이 충돌한다.
비공개 패키지 레지스트리나 내부 PyPI 미러까지 같은 ssh-agent 를 재사용하면 의도치 않게 넓은 서명 권한이 연결된다.
위협 모델
단일 테넌트 리스 Mac 과 공유 바스션은 같은 전제가 아니다.
배포 전용 읽기 deploy key, GitHub App, OIDC 발급 단기 토큰이 전역 ForwardAgent 보다 감사 친화적이다.
바스션 로그가 어떤 지문이 서명했는지 설명하지 못하면 전달을 허용하지 않는다.
rm-dev/rm-ci 로 Host 별명을 분리한다.
ForwardAgent 는 프로토콜 결함이 아니라 서명 결정을 외부로 위임하는 기능이다.
측정 가능한 실험
RTT 120–400ms 라도 ForwardAgent 가 줄이는 것은 대역폭이 아니라 키 배포 횟수다.
deploy key/OIDC 로 대부분을 커버하면 ForwardAgent 는 예외 승인으로 내려야 한다.
지문 교체는 체크섬 게이트 와 같은 변경 티켓에 묶는다.
여러 지역이면 바스션 지역과 Git 호스트 지역의 데이터 상주 요건을 검토한다.
분기마다 ssh -v 로 키 순서를 확인한다.
신규 입사자 온보딩 문서에 ForwardAgent 예외 신청 절차와 보안 검토 체크리스트를 명시해 템플릿 복사 실수를 줄인다.
훈련 A: 바스션 침해 가정으로 키 폐기를 전달 켜고/끄고 각각 수행하고 “안전” 선언까지 분과 티켓을 함께 기록한다.
훈련 B: deploy key 분기 교체 후 서브모듈 URL에 남은 예전 Host 별명이 없는지 검색한다.
훈련 C: 전달 세션에서 ssh-agent 서명을 SIEM 질문 세 개로 설명할 수 있는지 검증하고, 답 못 하면 공유 바스션에서는 금지한다.
규제 환경에서는 서명 이벤트마다 명시적 승인이 요구될 수 있으며 ForwardAgent 는 에이전트 안에서 승인 경계를 섞는다.
Apple Silicon 에서 Homebrew 와 시스템 OpenSSH 가 공존하면 launchd 작업과 대화형 셸의 IdentityFile 선택이 어긋날 수 있으니 전달 논의 전 ssh -G 로 일치를 확인한다.
매트릭스
| 상황 | ForwardAgent | 이점 | 리스크 | 대안 |
|---|---|---|---|---|
| 단독 리스 Mac | 단기 허용 | 복사 생략 | 노트북 agent 혼재 | 단기 인증서 |
| 공유 bastion | 기본 거부 | — | 로깅 부족 | ProxyJump+분할 키 |
| 셀프호스트 Runner | 비추천 | 편해 보임 | 탈취 시 집약 | OIDC+deploy key |
| SFTP만 | 금지 | — | 문맥 혼합 | Unix 분리 |
| 깊은 서브모듈 | 신중 | 키 감소 | 감사 어려움 | 미러/vendor |
| 고규제 | 보통 금지 | — | 부인 곤란 | SSH CA |
표를 탑재 고객 온보딩 체크리스트로 쓰되 「공유 bastion」 행은 기본 거부로 두고, 「단독 리스 Mac」 행만 계약·모니터링이 단일 테넌트임을 증명할 때 좁은 예외를 허용한다.
행 사이에 걸친 경우에는 먼저 계정·서브모듈을 재점검하고 ssh_config 예외는 마지막에 둔다.
How-to
Host rm-dev
ForwardAgent yes
IdentitiesOnly yes
Host rm-ci
ForwardAgent no
IdentitiesOnly yes
Host bastion
ForwardAgent no
1단계: 사람/자동/SFTP 별 Host.
2단계:OIDC 우선.
3단계: 전달 후 SSH_AUTH_SOCK 해제.
4단계:IdentitiesOnly + 단일 IdentityFile.
5단계:known_hosts.
6단계:산출물 파이프라인 분리.
7단계:ControlMaster 긴급 별명과 동일 원칙.
관련 읽기
ProxyJump → OIDC → known_hosts → 동시 SFTP → 홈 / 요금 / 도움말
순서를 지키면 경로상 어디에 서명 권한이 실리는지 설명하기 쉽다. OIDC 로 단기 자격을 먼저 깔면 에이전트 전제의 설정 비대를 줄인다.
known_hosts 고정 후 동시 SFTP 를 보면 세션 경합과 keepalive 창이 드러나 전달이 가리는 운영 리스크가 줄어든다.
FAQ
TCP 포워딩과 차이?
서명 권한 vs 바이트 이동.
FIDO2 sk?
원격에서 불안정, CI 키 사용.
IdentitiesOnly 지연?
호스트 잠금보다 저렴.
서브모듈에 전달 필수?
드물다. 미러·모노레포로 상류를 줄이면 deploy key 와 OIDC 로 충분한 경우가 많다.
SOC2 증적은?
바스션 기록과 CI 파이프라인 ID 를 시각으로 맞춰야 한다. 공백만 있으면 금지가 현실적이다.
요약:ForwardAgent 는 서명을 잠깐 위임한다.
한계:악성 dotfile 은 못 막는다.
비교:SFTPMAC 리스 Mac 은 격리와 SLA 를 계약으로.
운영팀은 인프라 변경 후 ForwardAgent 설정이 자동 배포 파이프라인에 동기화되는지 확인해야 한다. 장애 대응 훈련에서도 동일 체크리스트를 재사용한다.
예외와 키 로테를 같은 장부에.