SSH "Permission denied (publickey)" 5분 진단 가이드 (EC2 포함)
똑같은 에러, 원인은 10가지
터미널에 Permission denied (publickey)가 뜨고 작업이 멈췄다면, 지금 가장 먼저 알아야 할 사실은 이겁니다. 이건 "비밀번호가 틀렸다"는 뜻이 아닙니다. 서버가 "공개키 인증으로만 받아주는데, 네가 제출한 키로는 너를 증명하지 못했다"고 거절한 겁니다.
문제는 그 "증명 실패"의 원인이 한 곳이 아니라는 점입니다. 키를 아예 안 내밀었을 수도 있고(클라이언트 문제), 키는 맞는데 서버의 authorized_keys 권한이 700/600을 벗어나서 sshd가 무시했을 수도 있습니다(서버 문제). 그래서 무작정 키를 다시 만들거나 권한을 바꾸면 오히려 멀쩡한 설정을 망칩니다.
이 글의 진단 순서는 딱 한 줄입니다. 에러 메시지로 분류 → ssh -vvv로 클라/서버 분기 → 해당 측 명령어로 원인 특정. 바로 시작하겠습니다.
30초 분류: 에러 메시지별 원인 진단 표
화면에 뜬 메시지를 아래 표와 대조하고, "확인 위치" 컬럼이 가리키는 섹션으로 바로 점프하세요.
| 에러 메시지 | 유력 원인 | 확인 위치 |
|---|---|---|
Permission denied (publickey) | 키 미제출 또는 서버가 키 거부 | 먼저 ssh -vvv로 분기 |
Permission denied (publickey,password) | 키 실패 후 비밀번호 인증도 가능한 상태 | 클라이언트(키 매칭) |
No such identity: ~/.ssh/id_xxx | -i로 지정한 키 파일이 없음 | 클라이언트 |
Too many authentication failures | ssh-agent가 키를 너무 많이 제출 | 클라이언트(agent) |
server refused our key | 서버가 키 알고리즘 거부(ssh-rsa 비활성화 등) | 서버(sshd_config) |
Authentication refused: bad ownership or modes (auth.log) | 권한/소유자 문제 | 서버(권한·SELinux) |
Permission denied (publickey)는 대부분의 케이스가 여기 해당하므로, 먼저 ssh -vvv로 클라이언트인지 서버인지부터 가릅니다.
클라이언트 측 진단: 키·ssh-agent·사용자명
ssh -vvv로 분기점 잡기
가장 먼저 디버그 로그를 켭니다.
ssh -vvv -i ~/.ssh/id_ed25519 ubuntu@<서버IP>출력에서 아래 라인을 찾으세요.
debug1: Offering public key: ~/.ssh/id_ed25519 ED25519 SHA256:abc...
↑ 키를 서버에 "제안"함 → 여기까지 왔다면 클라 키는 정상, 서버 측 문제 의심
debug1: Authentications that can continue: publickey
↑ 서버가 publickey만 허용 중
debug1: Trying private key: ~/.ssh/id_rsa
debug1: No more authentication methods to try.
↑ 제안할 키가 더 없음 → 키 미지정/짝 안 맞음 (클라이언트 문제)판별 기준은 명확합니다. Offering public key가 한 번이라도 나오면 클라이언트는 키를 제대로 내민 것이고, 그럼에도 거부됐다면 서버 측(다음 섹션)으로 가세요. 반대로 Offering이 아예 안 나오고 바로 No more authentication methods로 끝나면 클라이언트 측 문제입니다.
클라이언트 측 흔한 원인 4가지
- 키 미지정 —
-i옵션을 안 줬거나~/.ssh/config에 IdentityFile이 없습니다.
# ~/.ssh/config 에 호스트별로 명시해두면 매번 -i 안 써도 됩니다
Host myserver
HostName 13.x.x.x
User ubuntu
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes- ssh-agent에 키 미등록 — 특히
Too many authentication failures가 뜨면 agent가 엉뚱한 키를 잔뜩 제출하는 중입니다.
ssh-add -l # 등록된 키 목록 확인
ssh-add ~/.ssh/id_ed25519 # 키 추가
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 ubuntu@<IP> # agent 무시하고 이 키만- 짝이 안 맞는 키 — 서버에 등록된 공개키와 로컬 개인키가 다른 경우입니다. 로컬 공개키 지문을 확인해 서버
authorized_keys와 대조하세요.
ssh-keygen -lf ~/.ssh/id_ed25519.pub- 클라우드 기본 사용자명 혼동 — 의외로 가장 흔합니다.
ssh root@...로 접속하면 키가 맞아도 거부됩니다. AMI별 기본 계정이 다르기 때문입니다.
| 이미지 | 기본 사용자명 |
|---|---|
| Amazon Linux / Amazon Linux 2023 | ec2-user |
| Ubuntu | ubuntu |
| Debian | admin (구버전 root) |
| CentOS / Rocky / RHEL | ec2-user 또는 centos/rocky |
| Fedora | fedora |
ssh [email protected] 대신 ssh [email protected]로 바꾸기만 해도 풀리는 경우가 정말 많습니다.
여기까지 했는데 Offering public key가 나오면서도 거부된다면 → 다음 섹션(서버 측)으로.
서버 측 진단: 권한·sshd_config·SELinux
서버에 들어갈 수 있는 다른 경로(콘솔, EC2 Instance Connect, SSM Session Manager)가 있다면 그걸로 접속해 아래를 확인합니다.
1) 권한 점검·수정 (복붙)
sshd는 ~/.ssh나 authorized_keys 권한이 느슨하면 보안상 키를 조용히 무시합니다.
ls -la ~/.ssh
stat -c '%a %U %n' ~ ~/.ssh ~/.ssh/authorized_keys
# 표준 권한으로 한 번에 교정
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh함정 하나: 홈 디렉토리 자체에 그룹/기타 쓰기 권한이 있으면 권한이 700/600이어도 거부됩니다. 홈 디렉토리는 755 이하여야 합니다.
chmod 755 ~ # 또는 750. 그룹 write(20) 비트가 켜져 있으면 안 됨2) sshd_config 확인
sudo grep -Ei 'PubkeyAuthentication|AuthorizedKeysFile|PermitRootLogin|PasswordAuthentication' /etc/ssh/sshd_config
sudo sshd -t # 문법 검증 (오류 없으면 무출력)
sudo systemctl restart sshdPubkeyAuthentication yes인지, AuthorizedKeysFile이 기본값(.ssh/authorized_keys)인지 확인하세요. 2026년 현재 OpenSSH 9.x에서는 ssh-rsa(RSA+SHA-1)가 기본 비활성화라, 오래된 RSA 키를 쓰면 server refused our key가 납니다. 이 경우 임시 회피보다는 ed25519 키로 재발급을 권장합니다.
ssh-keygen -t ed25519 -C "you@company"3) 결정적 로그 라인 찾기
원인을 한 방에 알려주는 건 결국 서버 로그입니다.
# Debian/Ubuntu
sudo tail -f /var/log/auth.log
# RHEL/Amazon Linux
sudo journalctl -u sshd -f여기서 아래 라인이 보이면 권한 문제로 확정입니다.
Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh4) SELinux 컨텍스트 (RHEL 계열 함정)
권한이 다 맞아 보이는데도 거부된다면 SELinux 컨텍스트를 의심하세요. authorized_keys를 직접 복사해 만들면 컨텍스트가 깨지는 경우가 있습니다.
getenforce # Enforcing이면 영향 있음
restorecon -Rv ~/.ssh # 올바른 컨텍스트 복구실무 한마디
운영 환경에서 가장 흔한 케이스는 1위 사용자명 혼동(root vs ubuntu), 2위 authorized_keys를 sudo로 root 소유로 만들어버린 소유자 문제입니다. ssh -vvv로 "키를 내미는지"만 먼저 확인하면 클라/서버 분기에서 헤매는 시간을 거의 없앨 수 있습니다.
복구 후 재발 방지 체크리스트
한 장으로 정리하는 진단 순서:
- 에러 메시지로 1차 분류 (위 표)
ssh -vvv→Offering public key나오면 서버, 안 나오면 클라- 클라:
-i/config,ssh-add -l, 사용자명 - 서버: 권한(700/600/홈755),
sshd -t,auth.log, SELinux
신규 서버 셋업 시 이것만 지키면 같은 에러를 거의 안 봅니다.
- 키는 ed25519로 표준화, RSA는 폐기
-
~/.ssh700,authorized_keys600, 홈 디렉토리 그룹 write 제거 -
~/.ssh/config에 Host별 IdentityFile +IdentitiesOnly yes템플릿화 - 비상 접속 경로 확보 — EC2 Instance Connect, SSM Session Manager를 활성화해 키 문제로 완전히 잠기는 상황을 방지
참고: 공식 문서
이 글에서 다루는 동작·설정·에러의 1차 출처는 다음 공식 문서입니다. 버전별 옵션과 정확한 동작은 여기서 확인하세요.
자주 묻는 질문 (FAQ)
Q. Permission denied (publickey)는 비밀번호를 틀렸다는 뜻인가요?
A. 아닙니다. 서버가 공개키 인증만 허용하는데 제출된 키로 인증에 실패했다는 의미입니다. 비밀번호 인증 자체가 시도되지 않은 상태일 수 있습니다.
Q. 키도 맞고 권한도 700/600인데 계속 거부됩니다.
A. 홈 디렉토리에 그룹 쓰기 권한이 남아 있거나(chmod 755 ~), RHEL 계열의 SELinux 컨텍스트 문제일 가능성이 큽니다. sudo tail -f /var/log/auth.log에서 bad ownership or modes 라인을 확인하고 restorecon -Rv ~/.ssh를 실행해 보세요.
Q. EC2에서 자꾸 막히는데 가장 흔한 원인은?
A. 사용자명 혼동입니다. root 대신 AMI 기본 계정(Amazon Linux는 ec2-user, Ubuntu는 ubuntu)으로 접속해야 합니다. 그래도 안 되면 EC2 Instance Connect로 들어가 authorized_keys를 직접 점검하세요.
이 글은 AI 에이전트가 자료 조사와 1차 초안 작성을 담당하고, 사람 편집자가 사실관계·출처·톤과 맥락을 검토한 뒤 발행했습니다. 환경(OS·버전)에 따라 결과가 다를 수 있으니 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.
댓글
첫 번째 댓글을 남겨보세요.