Error: Permission denied (publickey)

SSH로 서버에 접속할 때 Permission denied (publickey) 에러를 만나면 비밀번호도 못 쓰는 상태라 당황하기 쉽다. 이 에러는 서버가 클라이언트가 제시한 공개 키 중 어느 것도 인증에 성공시키지 못했다는 뜻인데, 원인이 키 등록 누락부터 파일 권한, 서버 설정까지 여러 곳에 걸쳐 있어서 하나씩 좁혀가며 확인해야 한다. 이 글에서는 대표적인 원인과 확인 순서, 그리고 각 원인을 실제로 재현한 결과를 정리한다.

Contents:

주요 원인

원인	확인 방법
서버에 공개 키가 등록되지 않음	`ssh -v`로 “Server accepts key” 줄이 나오는지 확인
클라이언트가 다른 키를 제시(여러 키가 있을 때)	`ssh -v`로 “Offering public key” 파일 경로 확인, 필요하면 `-i`로 명시
비공개 키/`.ssh` 권한이 너무 열려 있음	`ls -l ~/.ssh`, 클라이언트가 키를 조용히 무시함
서버 쪽 `~/.ssh`/`authorized_keys` 권한이 너무 열려 있음	sshd의 StrictModes가 인증을 거부, 서버 `/var/log/auth.log` 확인
SSH 에이전트에 키가 로드되지 않음	`ssh-add -l`
서버가 공개 키 인증을 비활성화함	서버의 `/etc/ssh/sshd_config`에서 `PubkeyAuthentication` 확인

실습: 원인별로 직접 재현

테스트용 키를 새로 만들어 실제 서버에 붙여보면서 각 원인이 정말 이 에러로 이어지는지 확인했다.

1. 서버에 등록되지 않은 키로 접속

$ ssh-keygen -t ed25519 -f ./test_key -N "" -C "demo@blog"
$ ssh -i ./test_key -o IdentitiesOnly=yes -o PasswordAuthentication=no -o BatchMode=yes noble@192.168.0.42 echo hi
noble@192.168.0.42: Permission denied (publickey,password).

공개 키를 서버의 authorized_keys에 추가하면 바로 접속된다.

$ ssh noble@192.168.0.42 "echo '$(cat ./test_key.pub)' >> ~/.ssh/authorized_keys"
$ ssh -i ./test_key -o IdentitiesOnly=yes -o PasswordAuthentication=no -o BatchMode=yes noble@192.168.0.42 echo hi
hi

2. 비공개 키 권한이 너무 열려 있는 경우

같은 키라도 로컬 파일 권한이 644면 SSH 클라이언트가 서버에 제시하지도 않고 바로 무시한다.

$ chmod 644 ./test_key
$ ssh -i ./test_key -o IdentitiesOnly=yes -o PasswordAuthentication=no -o BatchMode=yes noble@192.168.0.42 echo hi
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for './test_key' are too open.
Load key "./test_key": bad permissions
noble@192.168.0.42: Permission denied (publickey,password).

$ chmod 600 ./test_key
$ ssh -i ./test_key -o IdentitiesOnly=yes -o PasswordAuthentication=no -o BatchMode=yes noble@192.168.0.42 echo hi
hi

chmod은 파일마다 한 줄씩 실행해야 한다 — 아래처럼 한 줄에 이어 쓰면 두 번째 인자가 chmod의 파일 경로로 처리되지 않고 명령 자체가 깨진다.

chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh

3. ssh -v로 어느 단계에서 막히는지 확인

정상 인증 시 -v 로그에는 키를 제시(Offering)하고 서버가 받아들이는(Server accepts) 과정이 그대로 찍힌다.

$ ssh -v -i ./test_key noble@192.168.0.42 echo hi 2>&1 | grep -iE "identity file|Offering|Server accepts"
debug1: identity file ./test_key type 3
debug1: Offering public key: ./test_key ED25519 SHA256:uPh1cU... explicit
debug1: Server accepts key: ./test_key ED25519 SHA256:uPh1cU... explicit
Authenticated to 192.168.0.42 using "publickey".

“Offering public key” 줄이 아예 없다면 클라이언트가 그 키를 시도조차 안 한 것(권한 문제 또는 에이전트 미로드)이고, “Offering”은 있는데 “Server accepts”가 없다면 서버 쪽에 등록이 안 된 것이다.

그 밖의 확인 사항

상황	명령
SSH 에이전트에 키 추가	`ssh-add ~/.ssh/id_rsa`
서버 쪽 authorized_keys/.ssh 권한 재설정	`chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys`
서버 설정에서 공개 키 인증 허용 여부	`grep -i pubkeyauth /etc/ssh/sshd_config`
포트/사용자 지정해서 접속	`ssh -i ~/.ssh/id_rsa -p 22 user@hostname`

주의사항

서버 설정을 바꿨다면 sshd 재시작을 잊지 말 것: sudo systemctl restart sshd.
GitHub/GitLab 같은 서비스가 대상이라면 서버 설정이 아니라 해당 플랫폼의 SSH 키 등록 페이지에 공개 키를 추가해야 한다.
StrictModes가 켜져 있으면(기본값) 서버 쪽 ~/.ssh나 authorized_keys가 그룹/전체 쓰기 권한을 가지고 있는 것만으로도 인증이 조용히 거부된다 — 클라이언트 쪽 권한만 보고 넘어가지 말 것.

마무리

Permission denied (publickey)는 원인이 한 곳으로 정해져 있지 않은 에러라 ssh -v로 어느 단계에서 막히는지부터 확인하는 게 가장 빠르다. Offering까지도 안 된다면 로컬 키/권한 문제, Offering은 되는데 거부된다면 서버 쪽 등록/권한 문제로 좁혀서 접근하면 된다.