SSH 키를 바꾼 뒤 터미널에서는 접속되는데 자동 배포만 실패할 수 있습니다. 이때 수동 접속 성공은 배포 작업도 새 키를 사용한다는 증거가 아닙니다. 두 작업이 같은 서버에 접속하더라도 실행하는 계정과 읽는 파일, 인증 정보를 전달받는 환경이 다를 수 있기 때문입니다.
접속 계정과 실행 계정부터 분리
가령 관리자는 노트북에서 접속하고 배포는 별도 Linux 실행기에서 수행하는 상황을 가정하겠습니다. 노트북의 키만 교체했다면 실행기에 남은 키는 그대로일 수 있습니다. 같은 서버에서 실행하더라도 관리자 계정과 배포 서비스 계정은 서로 다른 설정을 읽을 수 있습니다.
먼저 작업을 실행하는 로컬 계정과 원격 서버에 로그인하는 계정을 나눠 기록합니다. 아래 명령은 배포 작업 안에서 실행하는 예시입니다. deploy-target은 실제 배포 명령에서 사용하는 호스트 별칭으로 바꿉니다.
id -un
pwd
ssh -G deploy-targetssh 공식 문서에 따르면 -G는 Host·Match 조건을 평가한 설정을 출력하고 종료합니다. 출력의 hostname, user, port, identityfile을 성공한 수동 접속과 비교합니다. 실제 작업이 -F나 -i를 지정한다면 진단에도 같은 옵션을 반영해야 비교가 성립합니다.
배포 작업이 읽는 개인키의 실제 위치
ssh_config 문서는 명령행 옵션, 사용자 설정, 시스템 설정 순으로 값을 읽는다고 설명합니다. IdentityFile은 여러 개가 누적될 수 있으므로 키 경로 한 줄만 보고 다른 후보가 없다고 판단하면 안 됩니다.
상대 경로는 작업 디렉터리에 따라 다른 파일을 가리킬 수 있습니다. CI가 비밀정보를 임시 파일로 주입한다면 저장소의 파일명보다 작업 시점에 만들어진 경로와 읽기 권한을 확인합니다. 아래 경로와 계정은 설명용이며 실제 환경에 맞춰 바꿔야 합니다.
test -r /srv/deploy/.ssh/release_key
ls -ld /srv/deploy/.ssh
ls -l /srv/deploy/.ssh/release_key첫 명령은 종료 상태로 읽기 가능 여부를 확인합니다. 파일이 존재해도 실행 계정이 상위 디렉터리를 통과하지 못하거나 키 파일을 읽지 못하면 사용할 수 없습니다. 반대로 개인키 권한을 과도하게 넓히면 SSH가 사용을 거부할 수 있으므로 소유자와 접근 범위를 함께 확인합니다.
서버 쪽에는 해당 원격 계정이 허용하는 공개키가 등록돼 있어야 합니다. sshd 문서의 authorized_keys 설명처럼 허용 키는 사용자별로 관리됩니다. 다른 계정에 새 공개키를 넣은 경우와 배포용 키 자체가 갱신되지 않은 경우를 구별해야 합니다.
수동 접속에서만 제공되는 인증 정보
수동 접속은 ssh-agent에 이미 등록된 키를 이용할 수 있습니다. ssh-agent는 개인키를 이용한 인증을 도와주는 프로그램입니다. ssh-add 문서는 에이전트가 실행 중이고 SSH_AUTH_SOCK이 해당 소켓을 가리켜야 한다고 설명합니다.
ssh-add -l이 명령으로 배포 환경에서 접근 가능한 에이전트의 키 지문을 확인합니다. 에이전트에 연결할 수 없다는 결과만으로 장애라고 단정하지 않습니다. 키 파일을 직접 사용하는 작업은 에이전트가 없어도 인증할 수 있기 때문입니다. 암호문구가 있는 키라면 무인 실행에서 이를 제공하는 방식도 별도로 준비돼 있어야 합니다.
파일 기반 키를 쓰는 작업에서는 다음처럼 접속 조건을 명시해 진단할 수 있습니다. 호스트 키는 별도로 검증하고 known_hosts에 준비한 상태를 전제로 합니다.
ssh -vv -o BatchMode=yes -o IdentitiesOnly=yes \
-i /srv/deploy/.ssh/release_key deploy@app.example.com trueBatchMode=yes는 비밀번호 입력 등 대화형 처리를 끕니다. IdentitiesOnly=yes는 설정한 인증 ID로 후보를 제한하지만 기존 IdentityFile 설정을 지우는 옵션은 아닙니다. 따라서 이 명령도 적용 설정과 함께 해석해야 합니다. 디버그 로그를 공유할 때는 사용자명·서버 주소·내부 경로를 가립니다.
실패 지점에 따라 나누는 다음 조치
로그에서는 키 파일을 읽지 못한 단계, 공개키를 제시한 단계, 인증을 마친 단계를 구별합니다. 아래 표는 점검 방향이며 메시지 하나만으로 원인을 확정하는 표가 아닙니다.
| 관찰된 결과 | 다음 확인 대상 |
|---|---|
| 개인키 경로 없음·읽기 실패 | 실행 계정, 파일 주입 위치, 소유자와 권한 |
| Permission denied (publickey) | 제시한 키, 원격 사용자, 허용 공개키와 서버 인증 기록 |
| 호스트 키 검증 실패 | 접속 대상과 신뢰한 서버 호스트 키의 일치 여부 |
| 인증 성공 뒤 배포 명령 실패 | 원격 명령, 배포 디렉터리 권한, 필요한 실행 환경 |
인증이 성공했다면 키 교체를 반복하기보다 그 뒤의 배포 명령을 확인합니다. 반대로 호스트 키 검증 실패는 서버 신원 확인 문제이므로 사용자 인증 키 문제와 구분합니다. 오류를 없애려고 호스트 키 검증을 끄면 접속 대상의 신뢰 문제를 가릴 수 있습니다.
자주 묻는 질문
수동 접속이 성공하면 새 키가 정상 등록된 것 아닌가요?
그 수동 접속에 실제로 사용된 키와 원격 계정에 대해서는 인증이 성공한 것입니다. 자동 배포가 같은 키와 계정을 사용하는지는 별도로 확인해야 합니다. 수동 환경의 에이전트가 다른 키를 제공했을 가능성도 있으므로 적용 설정과 인증 로그를 대조합니다.
배포 환경에서 ssh-add -l이 실패하면 에이전트를 설치해야 하나요?
반드시 그렇지는 않습니다. 개인키 파일을 직접 읽도록 구성한 작업은 에이전트 없이도 인증할 수 있습니다. 에이전트를 이용하도록 설계한 작업이라면 해당 프로세스가 실행 중인지와 배포 작업에서 그 소켓에 접근할 수 있는지를 확인합니다.
새 키로 접속한 뒤 기존 키를 바로 삭제해도 되나요?
관리자 터미널에서 한 번 접속한 결과만으로 회수를 결정하지 않습니다. 같은 배포 실행기와 계정에서 새 연결의 인증과 실제 배포 결과를 확인하고, 기존 키를 공유하던 다른 작업의 의존성도 확인한 뒤 회수를 마무리합니다.
결론
자동 배포만 실패할 때는 새 키의 생성 여부보다 실제 작업의 인증 경로를 확인해야 합니다. 배포 작업 안에서 실행 계정과 적용 설정을 수집하고, 개인키 경로·에이전트·원격 계정의 공개키를 차례로 대조합니다. 수정 후에는 관리자 터미널의 접속 결과가 아니라 같은 배포 실행기와 계정에서 새 연결의 인증 및 배포 결과를 확인한 뒤 이전 키의 회수를 마무리합니다.