SSH Permission denied (publickey) 진짜 해결법

02시 10분, 천 번쯤 입력해 본 한 줄에서 배포가 죽었습니다. ssh deploy@staging → Permission denied (publickey). 키는 멀쩡했습니다. 문제는 제출이었습니다.

TL;DR: Permission denied (publickey)는 클라이언트가 제출한 모든 키가 서버에 거부됐다는 뜻입니다 — 비밀번호 오타가 아니라 협상의 판결입니다. ssh -vvv(어떤 키가 제출됐는지)와 서버 로그 journalctl -u ssh(어떤 키가 왜 거부됐는지)로 진단하세요. 그다음 네 가지 원인 중 하나를 고칩니다. 잘못된 사용자, authorized_keys에 없는 키, 너무 열린 권한, 또는 OpenSSH 8.8+이 거부하는 ssh-rsa 키. ssh-copy-id가 재발의 대부분을 막아 줍니다.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

이 오류는 힌트가 아니라 판결입니다. 제출된 것은 모두 거부됐다는 뜻이죠.

SSH는 왜 “Permission denied (publickey)“라고 말할까?

공개 키 인증은 제출–거부 협상입니다. 클라이언트는 찾을 수 있는 모든 키를 제출합니다. 에이전트의 신원, ~/.ssh/config, 기본 파일 이름(id_ed25519, id_rsa), 그리고 -i로 넘긴 것까지 전부입니다. 서버는 각 제출을 대상 계정의 ~/.ssh/authorized_keys와 대조합니다. 아무것도 맞지 않고 비밀번호 인증이 비활성화되었거나 소진됐다면, 클라이언트는 모든 devops 엔지니어가 암기하고 있는 그 한 줄을 출력합니다.

디버깅에 중요한 사실 두 가지. 첫째, 이 메시지는 어떤 사용자로 접근했는지 알려 주지 않습니다 — 절반의 사례는 완벽히 정상적인 키가 잘못된 계정의 authorized_keys에 앉아 있는 경우입니다. 둘째, 서버는 이미 이유를 말했습니다. sshd는 거부된 모든 제출을 기록합니다. 아무도 요청하지 않았지만 모두에게 필요한 스택 트레이스가 바로 -vvv입니다.

SSH가 실제로 제출하는 키는 어떻게 확인하나?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

세 줄을 읽으세요. Offering public key(클라이언트가 제출한 것), Authentications that can continue(서버가 아직 받아들이는 것 — password가 없으면 비밀번호 질문은 영원히 오지 않습니다), 그리고 최종 판결. 내 키가 제출 목록에 한 번도 안 나온다면 문제는 클라이언트 쪽입니다. 잘못된 -i 경로, ~/.ssh/config에 잊힌 IdentityFile, 또는 낡은 신원이 먼저 응답하는 에이전트(ssh-add -l)입니다.

네 가지 실제 원인은 무엇인가?

원인	단서	해결
잘못된 사용자	root@host에서는 되고 deploy@host에서는 실패	키가 그 사용자의 ~/.ssh/authorized_keys에 있어야 함
키 미설치	서버 로그가 매번 Failed publickey	ssh-copy-id user@host
권한이 너무 열림	클라이언트: WARNING: UNPROTECTED PRIVATE KEY FILE — 키가 건너뛰어져 제출조차 안 됨	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
낡은 ssh-rsa 키	서버가 OpenSSH 8.8+. 오래된 RSA 키는 절대 수용 안 됨	ed25519로 재생성하거나 키를 교체

권한 원인은 별도로 짚을 가치가 있습니다. OpenSSH는 이를 엄격하게 강제하기 때문입니다. 그룹이나 다른 사용자가 읽을 수 있는 개인 키는 클라이언트 스스로 거부하며 제출 목록에서 조용히 빠집니다. 해결은 명령 두 개입니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

ssh-rsa 원인은 오래된 CI 이미지와 라즈베리 파이를 걸립니다. OpenSSH 8.8(2021-10-01 릴리스, openssh.com/txt/release-8.8)은 ssh-rsa 서명 — SHA-1 기반 방식 — 을 기본값으로 비활성화했습니다. 릴리스 노트의 표현을 빌리면, “the ssh-rsa signature scheme is … disabled by default”. 2018년에 만든 RSA 키가 망가진 게 아닙니다. 서명 형식이 더 이상 통하지 않을 뿐입니다. ed25519 키를 새로 만드는 것(ssh-keygen -t ed25519)이 지속 가능한 답이고, 클라우드 콘솔에는 직렬 콘솔이 있어 작업 중에 스스로를 잠가 놓아도 복귀할 수 있습니다.

설정을 고치는 중에 sshd 자체가 안 뜬다면 그건 다른 사냥입니다. systemd service not starting을 참고하세요.

서버가 키를 거부한 이유는 어떻게 보나?

서버 쪽 로그가 정직한 증인입니다. 우분투(systemd)에서 sshd는 제출마다의 판정을 기록합니다.

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

생뚱맞은 지문이 찍힌 Failed publickey는 클라이언트가 생각한 것과 다른 키를 제출했다는 뜻입니다. 다시 -vvv로 돌아가세요. 내 지문이 찍힌 Failed publickey는 키는 맞지만 그 계정에 설치되지 않았거나, 서버 쪽 홈 디렉터리 권한이 틀렸다는 뜻입니다(서버의 ~/.ssh와 ~/.ssh/authorized_keys에도 같은 700/600 규칙이 적용됩니다).

키를 올바르게 설치하는 방법은?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # 비대화형 증명

ssh-copy-id는 공개 키를 대상 계정의 authorized_keys에 알맞은 권한으로 추가해 줍니다. 이 명령이 존재하는 이유는, authorized_keys에 손으로 붙여 넣는 방식이 줄바꿈 하나, 없는 디렉터리 하나만으로도 딱 자주 실패하기 때문입니다. BatchMode 확인이 진짜 시험입니다. 모든 프롬프트를 끄므로, 성공은 키만으로 로그인이 됐다는 뜻입니다. 키가 통하면 scp와 rsync는 같은 인증을 공짜로 물려받습니다. 둘 중 선택은 대역폭 문제지 자격 증명 문제가 아닙니다(rsync vs scp).

30초 트리아지

ssh -vvv user@host 2>&1 | grep -i offering      # 1. 어떤 키가 제출됐나?
journalctl -u ssh -n 50 | grep -i publickey     # 2. 왜 거부됐나?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600인가?
ssh-copy-id user@host                           # 4. 설치 후 BatchMode로 검증

Permission denied (publickey)는 비밀번호 요청이 아니라 협상의 결과입니다. 서버는 제출된 모든 키를 거부했고, 로그는 이미 이유를 알고 있습니다.

네 명령을 순서대로 돌리면 장애는 더 이상 미스터리가 아닙니다. 매번 그중 하나가 범인을 지목합니다. 제 경우엔 올바른 키보다 먼저 응답한 낡은 에이전트 신원이었습니다. ssh-add -d 하고, 02시 31분에 배포는 다시 초록이 됐습니다.