Keychain 이야기

"push 는 성공. CLI 는 실패. 같은 기계, 같은 user, 같은 초 — 유일하게 다른 건 문이었어."

상황

control-plane Mac 의 headless SSH session 이 repository 를 bootstrap 하고 있었어. git over SSH 는 완벽히 됐어: remote 에 인증하고 불평 없이 push 했어. 모든 명백한 척도로, 이 session 은 GitHub 접근이 됐어.

벽

그다음 gh, GitHub CLI 가 같은 상자에서, 같은 session 에서, 같은 user 로 실패했어. 왜? gh 는 자기 auth 토큰을 login Keychain 에 두는데, headless SSH session 은 SecuritySessionID 가 없어 — 그 Keychain 을 unlock 할 login session 이 없어. git 의 SSH key 는 SSH envelope 이 닿는 데 살았고; gh 의 토큰은 못 닿는 데 살았어. 기계 하나, user 하나, 다른 두 방의 credential 둘 — 그리고 이 문은 그 중 하나만 열었어.

틀린 fix

반사는 gh auth login 이었어 — 재인증, 그럼 auth 실패가 당연히 고쳐지지. 안 고쳐져. 구조적으로 credential 을 못 쥐는 envelope 안에서 재인증하면 fresh 한 실패만 나와. gh auth login 을 백 번 돌려도; headless 문은 새 토큰이 내려앉을 Keychain 을 unlock 할 session 이 여전히 없어. loop 은 진전처럼 느껴지고 순수한 헛수고야.

맞는 fix

실제로 가진 capability 를 써. SSH transport 는 이미 인증하고 push 했어 — 그러니 그걸 기대. 아니면, 작업이 진짜로 Keychain 토큰이 필요하면, login session 을 가진 interactive executor 로 돌려. operation 은 새 credential 이 필요했던 게 아니라; 이미 가진 credential 을 위한 맞는 envelope 이 필요했어. host 정체성이 credential 가용성을 함의 안 했고 — 그 gap 이 교훈 전부야.

기계에 닿는 건 걔 열쇠를 쥐는 게 아냐. credential 이 한 envelope 에서 실패하면, fix 는 다른 envelope 이지 — 더 세게 두드린 같은 닫힌 문이 아냐.

Code

같은 session, credential 둘, 결과 둘·bash

# control-plane Mac 의 headless SSH session. 같은 user, 같은 초.

git push origin main       # OK   -- SSH key auth; 이 envelope 에서 닿음
gh pr create ...           # FAIL -- 토큰이 login Keychain 에 있고, headless
                           #         SSH session 은 그걸 unlock 할 login session
                           #         (SecuritySessionID)이 없음

# 틀린 fix -- key 를 못 쥐는 문에서 재인증:
gh auth login              # '성공', 그다음 같은 방식으로 또 실패. 영원히.

# 맞는 fix -- 되는 envelope 이나 Keychain 접근 있는 걸 써:
#   * 이미 인증한 SSH transport 를 기대거나, OR
#   * login session 가진 INTERACTIVE executor 로 gh 돌리기.
# credential 은 없던 게 아니라; envelope 이 못 닿았을 뿐이야.

Exercise

'인증' 에러랑 싸웠는데 알고 보니 credential 이 아니라 context 문제였던 때를 떠올려(env 를 못 본 cron job, secret 빠진 CI runner, keychain/agent 에 못 닿은 SSH session). 처음 시도한 틀린 fix 랑, 실제로 된 envelope-레벨 fix 를 적어.

Hint

틀린 fix 는 거의 항상 'credential 을 다시 해' 야. 진짜 fix 는 거의 항상 '이미 credential 을 가진 문에서 돌리거나, 문에 credential 을 명시적으로 건네' 야. 문을 먼저 이름 붙였으면 그 우회로를 아꼈을 거야.

상황

벽

틀린 fix

맞는 fix

Code

External links

Exercise

Progress

댓글 0