기술 · 실용 가이드
SSH 접속에서 “Permission denied (publickey)” 오류가 나면? 다른 키를 복사하기 전에 실제로 제시된 공개키 지문과 대상 계정을 먼저 증명하세요
유효한 접속 대상과 호출 환경을 먼저 고정하고, 실제로 제시된 공개키 지문을 대상 계정과 연결합니다. 권한이나 서버 정책을 바꾸기 전에 거부가 발생한 정확한 경계의 증거를 확인하세요.
“Permission denied (publickey)”는 SSH 연결이 사용자 인증 단계까지 도달했지만 요청한 원격 계정에서 유효한 공개키 인증 경로가 수락되지 않았다는 뜻입니다. 그러나 이 메시지만으로는 별칭이나 사용자 이름이 잘못됐는지, 의도한 키가 아예 제시되지 않았는지, 제시된 키가 서버에서 거부됐는지 판단할 수 없습니다.
유효한 접속 대상, 실제로 제시된 지문, 대상 계정의 권한 매핑, 서버 거부 증거라는 네 열의 원장을 만드세요. 추측으로 키를 더 복사하거나 인증 정책을 약화하지 말고, 증거가 처음 끊긴 경계만 수정한 뒤 원래 실패한 호출 환경에서 다시 검증합니다.
정확한 대상과 호출자를 고정하세요
실패한 command, alias, remote user, port, jump path와 실행 환경을 그대로 보존하고 같은 목적지에 대해 ssh -G 유효 설정을 기록합니다. hostname과 user뿐 아니라 IdentityFile, IdentitiesOnly, ProxyJump, 실제로 읽힌 설정 파일까지 확인해 터미널과 IDE 같은 서로 다른 호출 환경을 섞지 않습니다.
로컬 사용자 이름이나 키 파일 이름만 보고 remote account를 추정하지 마세요. 공개키 권한은 원격 계정에 연결되므로 올바른 키를 가지고 있어도 user가 다르면 거부됩니다. 유효 설정이 보여 주는 대상을 증거 원장의 첫 번째 열로 고정합니다.
실제로 제시한 키만 기록하세요
같은 대상에서 ssh -vvv를 실행하고 인증 구간에 나타나는 각 “Offering public key”의 출처와 지문을 순서대로 기록합니다. 설정에 키가 적혀 있거나 agent에 키가 있다는 사실은 서버에 실제로 제시됐다는 증거와 다릅니다. identity file 누락과 offered-but-rejected도 별도 분기입니다.
의도한 지문이 목록에 없다면 IdentityFile, agent socket, HOME, 실행 사용자와 파일 권한을 확인합니다. 필요하면 -i와 IdentitiesOnly=yes를 사용한 제한된 테스트로 해당 키만 제시되는지 재확인합니다. 영구 설정을 바꾸기 전에 원래 호출 환경과 테스트 환경의 차이도 함께 기록하세요.
지문을 대상 계정에 연결하세요
공개키 파일이나 승인된 키 에이전트 목록에서 ssh-keygen -lf를 사용해 SHA256 지문을 얻습니다. 개인 키 내용은 표시하거나 공유하지 않고 지문과 공개키의 출처만 기록합니다. 그 지문을 원격 계정, Git 호스팅 계정, 또는 관리형 권한 원장에 등록된 키와 정확히 대조합니다.
지문과 대상 계정의 관계를 모른 채 키를 다시 복사하면 불필요한 권한만 늘고 IDE나 서비스는 계속 다른 키를 제시할 수 있습니다. 실제 제시 지문과 대상 계정의 등록 지문이 일치한다는 증거를 확보한 뒤에만 서버 측 조사로 넘어갑니다.
제시 후 거부된 경우에만 서버를 보세요
올바른 지문이 실제로 제시됐는데 거부된 경우에만 권한이 있는 서버 관리자가 실제 권한 소스와 같은 시각의 인증 로그를 확인합니다. 대상 account, AuthorizedKeysFile, ownership, mode, certificate, Match 조건, 허용 algorithm, 외부 권한 디렉터리를 차례로 대조하고 다른 계정이나 경로의 증거를 섞지 않습니다.
재귀 chmod, 소유자 일괄 변경, 공개키 인증 비활성화, 비밀번호 인증의 무분별한 활성화는 피하세요. 로그와 유효 설정으로 증명된 account와 path의 요구 사항만 수정해 정상 사용자나 다른 키에 미치는 영향을 최소화합니다.
전후 증거로 마무리하세요
수정 후 원래 실패한 환경에서 ssh -G와 ssh -vvv를 다시 실행해 대상과 user가 그대로인지, 의도한 SHA256 지문이 제시되는지, 인증 방식을 약화하지 않고 성공하는지 확인합니다. 다른 터미널에서만 성공했다면 완료로 보지 말고 실패했던 IDE, Git, 서비스, 컨테이너에서 같은 경계를 재검증합니다.
민감정보를 제거한 증거 원장, 검증 시각, caller, 변경한 한 항목, 결과를 저장합니다. 나중에 agent, HOME, alias, 설정 관리가 바뀌면 이 전후 차이를 비교해 키 재배포나 광범위한 권한 변경 없이 원인으로 돌아갈 수 있습니다.
