website: dbclient 감사로그 actor 매칭을 키 원문 비교로 재설계

dbclient 세션 감사로그에서 접속자를 식별하는 로직이 계속 "unknown"만 찍혀서, 지문 비교 방식 자체를 버리고 키 원문 문자열 비교로 다시 짰다.

원래 이 스크립트는 ExposeAuthInfo가 SSH_USER_AUTH 파일에 남기는 값을 SHA256 지문이라고 가정하고, authorized_keys에 등록된 키들을 ssh-keygen -lf로 지문 계산해서 비교하는 방식이었다. #453에서 필드 파싱 버그를 고쳤을 때는 그걸로 해결됐다고 생각했는데, 배포하고 라이브 dbclient 세션으로 다시 확인해보니 여전히 unknown(publickey 인증정보 없음)이 찍혔다.

로그를 다시 들여다보니 원인이 파싱 문제가 아니었다. SSH_USER_AUTH에 실제로 남는 값은 "publickey <알고리즘> SHA256:지문" 형태가 아니라, 인증에 쓴 공개키 원문(base64) 그 자체였다. 즉 애초에 "이 파일에 지문이 들어있다"는 전제부터 틀린 상태에서 파싱 로직만 고치고 있었던 셈이다. #453 커밋 메시지를 보면 그때도 "$2를 지문으로 잘못 읽어서" 문제라고 판단했는데, 실은 필드 위치가 아니라 값 자체의 성격을 잘못 알고 있었다.

전제가 틀렸다는 게 확인된 이상 지문 계산 로직은 필요가 없어졌다. ssh-keygen -lf로 authorized_keys의 각 줄과 SSH_USER_AUTH의 값을 각각 지문으로 변환해서 비교하던 걸 걷어내고, 대신 두 값을 있는 그대로 문자열 비교하도록 바꿨다.

used_key=" $(a w k^{'}$ 1=="publickey"{ $1="";sub(/^ /,"");print;exit}' "$ SSH_USER_AUTH")"
...
if [ " $k e y_{p} a r t " = "$ used_key" ]; then
    echo "$name"
    return
fi

authorized_keys 쪽도 grep -oE 'ssh-[a-z0-9]+ [A-Za-z0-9+/=]+'로 "알고리즘 + base64" 부분만 뽑아서 같은 형태로 맞췄다. 지문 계산 단계가 아예 사라지니 로직도 단순해졌고, ssh-keygen -lf 호출 자체가 없어져서 스크립트 실행 경로도 하나 줄었다.

매칭이 또 실패할 가능성을 염두에 두고 로그도 손봤다. 이전에는 실패해도 "unknown(등록되지 않은 키, fp=...)" 식으로 계산된 지문만 남겼는데, 이번엔 실제로 받은 값의 앞 40자를 그대로 로그에 남기게 했다. 전체 키를 다 남기면 로그가 길어지니 원인 파악에 필요한 만큼만 잘랐다. 이렇게 해두면 다음에 또 안 맞는 케이스가 나와도 서버에 직접 붙어서 스크립트를 열어보지 않고 감사로그만 보고 어디가 문제인지 짐작할 수 있다.

검증은 bash -n으로 문법만 확인하고, awk 로직은 시뮬레이션 입력으로 별도 테스트했다. 실제 배포 후 라이브 세션으로 재확인하는 건 이번이 두 번째 시도라 PR 설명에도 "검증 예정"이라고 적어뒀다. 같은 문제를 두 번 잘못 짚었던 걸 생각하면, 이런 종류의 값은 문서나 추측으로 판단하지 말고 처음부터 실제 세션에서 찍히는 원문을 직접 떠서 확인했어야 했다는 게 이번에 다시 확인된 지점이다.

글 수정