Permission denied (publickey) 원인별 진단 순서 정리

$ ssh deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

키도 만들었고 공개키도 올렸는데 이 한 줄만 반복해서 뜨는 상황입니다. 이 에러는 원인이 하나가 아닙니다. 클라이언트가 키를 아예 안 보냈을 수도 있고, 보냈는데 서버가 파일을 못 읽고 있을 수도 있습니다. 처음부터 다시 세팅하지 말고, 로그를 보고 갈림길을 하나씩 좁히는 게 훨씬 빠릅니다.

먼저 로그부터 봅니다: ssh -vvv 읽는 법

무조건 -vvv를 붙여서 다시 접속해 봅니다. 출력이 길어 보이지만 실제로 봐야 할 줄은 서너 개뿐입니다.

ssh -vvv deploy@203.0.113.10

출력 중에서 이 부분들을 찾습니다.

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/me/.ssh/id_ed25519 ED25519 SHA256:xxxx...
debug3: send packet: type 50
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

Authentications that can continue: publickey는 서버가 공개키 인증만 받겠다는 뜻입니다. 비밀번호 인증은 이미 꺼져 있는 상태라 “비밀번호라도 물어봐 줬으면” 하는 기대는 접어야 합니다.

갈림길은 여기서 갈립니다

Offering public key: 줄이 아예 없다면 클라이언트가 키를 하나도 안 보낸 겁니다. 이건 로컬 문제입니다. 줄이 있는데도 거부됐다면 서버가 그 키를 받아주지 않은 겁니다. 서버 쪽 권한이나 authorized_keys를 봐야 합니다.

이런 줄이 보이면 경로부터 틀린 경우입니다.

debug1: identity file /home/me/.ssh/id_rsa type -1
debug3: no such identity: /home/me/.ssh/id_rsa: No such file or directory

type -1은 파일을 못 읽었다는 뜻입니다. 기본 이름(id_rsa, id_ed25519)이 아닌 키를 쓰고 있는데 지정을 안 했을 때 자주 나옵니다.

서버에 다른 경로로 들어갈 수 있다면 서버 로그가 결정적입니다.

sudo journalctl -u sshd -n 50 --no-pager
# 데비안/우분투 계열은
sudo tail -n 50 /var/log/auth.log

여기에 Authentication refused: bad ownership or modes for directory /home/deploy 같은 문구가 찍혀 있으면 원인이 바로 나온 겁니다.

클라이언트 쪽 원인 4가지

1. 키를 아예 안 보내는 경우

-i로 직접 지정해서 재현되는지 봅니다.

ssh -i ~/.ssh/deploy_key -o IdentitiesOnly=yes deploy@203.0.113.10

이걸로 들어가진다면 키 자체는 멀쩡합니다. 평소 명령이 다른 키를 집어 들고 있었던 것뿐입니다.

2. 개인키 권한이 느슨할 때

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/me/.ssh/id_ed25519' are too open.

이 경고가 뜨면 ssh는 그 키를 아예 안 씁니다. 결과는 똑같이 publickey 거부입니다.

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

윈도우에서 키를 복사해 왔을 때 특히 자주 봅니다.

3. 키가 많아서 시도 횟수를 넘기는 경우

~/.ssh에 키가 대여섯 개 있으면 ssh가 전부 순서대로 던집니다. 서버의 MaxAuthTries(기본 6) 를 넘기면 정답 키에 도달하기 전에 끊깁니다. 로그에 Too many authentication failures가 보이면 이겁니다.

~/.ssh/config에 호스트별로 못 박아 둡니다.

Host prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/deploy_key
    IdentitiesOnly yes
    Port 22

IdentitiesOnly yes가 핵심입니다. 지정한 키 하나만 보냅니다. 이제 ssh prod로 끝입니다.

4. ssh-agent에 키가 안 올라간 경우

ssh-add -l

The agent has no identities.

에이전트를 쓰는 환경(에이전트 포워딩, 패스프레이즈 걸린 키)에서 이 출력이 나오면 키를 다시 넣어야 합니다.

ssh-add ~/.ssh/deploy_key

그리고 계정명

의외로 이게 제일 흔합니다. 이미지마다 기본 계정이 다릅니다.

이미지	기본 계정
Ubuntu (AWS/일반)	ubuntu
Amazon Linux	ec2-user
CentOS / Rocky	centos, rocky
Debian	admin 또는 debian
직접 설치한 서버	본인이 만든 계정

root로만 열 번 시도하다 포기하는 경우를 자주 봅니다. 대부분의 클라우드 이미지는 PermitRootLogin이 막혀 있거나 root의 authorized_keys에 Please login as the user "ubuntu" rather than the user "root". 안내가 박혀 있습니다.

키를 처음부터 다시 만들고 등록하는 절차 자체가 헷갈린다면 SSH 키 인증 설정하는 법, 접속 거부까지 잡는 실전 순서를 먼저 훑고 오는 편이 낫습니다.

서버 쪽 원인: 권한과 authorized_keys

sshd는 파일 권한이 조금이라도 느슨하면 그 키를 무시합니다. 에러 메시지는 안 알려주고 그냥 거부합니다. 그래서 헷갈립니다.

chmod 755 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy ~/.ssh

홈 디렉터리가 775나 777이면 거부됩니다. 그룹 쓰기 권한이 있으면 안 됩니다. chmod 750 ~도 괜찮습니다.

소유자가 root인 경우

sudo로 파일을 만들면 소유자가 root가 됩니다. 그러면 deploy 계정으로 로그인할 때 sshd가 읽지 않습니다. 위 chown -R로 잡습니다.

줄바꿈이 끼어든 경우

공개키는 한 줄입니다. 복사 과정에서 중간에 개행이 들어가면 깨집니다. 눈으로는 안 보입니다.

cat -A ~/.ssh/authorized_keys

$가 줄 끝에만 하나씩 있어야 정상입니다. 줄 중간에 $가 있거나 ^M$(윈도우 개행)이 보이면 그게 원인입니다. ^M은 이렇게 지웁니다.

sed -i 's/\r$//' ~/.ssh/authorized_keys

.pub이 아닌 개인키를 올린 실수

authorized_keys 내용이 -----BEGIN OPENSSH PRIVATE KEY-----로 시작하면 잘못 올린 겁니다. 올라가야 하는 건 ssh-ed25519 AAAAC3Nza... 또는 ssh-rsa AAAAB3Nza...로 시작하는 한 줄입니다. 이 경우 개인키가 서버에 노출된 셈이니 키 쌍을 새로 만드는 게 안전합니다.

sshd_config 확인

sudo grep -Ei 'PubkeyAuthentication|AuthorizedKeysFile|PermitRootLogin|AllowUsers|DenyUsers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf

항목	확인할 것
PubkeyAuthentication	yes 여야 합니다
AuthorizedKeysFile	보통 .ssh/authorized_keys. 다른 경로로 바뀐 서버가 있습니다
PermitRootLogin	root로 들어가려면 prohibit-password 이상
AllowUsers / DenyUsers	여기 목록에 없으면 무조건 거부

sshd_config.d/ 안의 파일이 본 파일을 덮어쓰는 배포판이 많습니다. 본 파일만 고치고 왜 안 되냐고 하는 경우가 여기서 나옵니다.

고친 뒤에는 반드시 문법 검사

sudo sshd -t

아무 출력도 없으면 정상입니다. 오류가 있으면 줄 번호와 함께 알려줍니다. 통과했으면 재시작합니다.

sudo systemctl restart sshd

지금 붙어 있는 SSH 세션은 절대 끊지 마세요. 새 터미널을 열어 접속이 되는지 확인한 뒤에 닫습니다. 설정을 잘못 건드려 놓고 세션까지 끊으면 콘솔로 들어가는 수밖에 없습니다.

잘 놓치는 원인들

SELinux 컨텍스트

RHEL, Rocky, CentOS 계열에서 .ssh 디렉터리를 다른 곳에서 복사해 왔거나 새로 만들면 보안 컨텍스트가 틀어집니다. 권한은 다 맞는데 거부되는 전형적인 경우입니다.

restorecon -R -v ~/.ssh

/var/log/audit/audit.log에 avc: denied 줄이 있으면 확정입니다.

암호화된 홈 디렉터리

우분투의 ecryptfs 홈 암호화를 켜 두면, 로그인하기 전에는 홈이 복호화되지 않습니다. sshd가 ~/.ssh/authorized_keys를 읽지 못합니다. 닭과 달걀 문제입니다.

해결은 홈 밖에 키 파일을 두고 sshd_config에서 경로를 바꾸는 방식입니다.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

오래된 RSA 키가 막히는 경우

OpenSSH 8.8 이후로 ssh-rsa(SHA-1 서명)가 기본 비활성화됐습니다. 몇 년 전에 만든 키로 접속하다가 갑자기 막히는 일이 여기서 생깁니다. 로그에 send_pubkey_test: no mutual signature algorithm이 보이면 이겁니다.

임시 우회는 클라이언트 쪽에서 이렇게 합니다.

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa \
    -o HostKeyAlgorithms=+ssh-rsa \
    deploy@203.0.113.10

옵션 이름은 OpenSSH 버전에 따라 PubkeyAcceptedKeyTypes인 경우도 있습니다. ssh -V로 버전을 확인하고, 안 먹으면 다른 이름으로 시도해 보세요. 어디까지나 임시 방편입니다. 들어가지면 바로 ed25519 키로 갈아타는 게 맞습니다.

ssh-keygen -t ed25519 -C "deploy@prod"

디스크가 꽉 찬 경우

df -h

/나 /home이 100%면 인증 관련 임시 파일 생성이 실패해서 접속이 거부될 수 있습니다. 로그에 No space left on device가 찍힙니다. 로그 파일이 폭주해서 이렇게 되는 경우가 실제로 있습니다.

최후 수단

전부 안 되면 클라우드 콘솔의 시리얼 콘솔이나 복구 모드로 들어갑니다. AWS는 EC2 Serial Console, GCP는 Serial console, 국내 호스팅은 대부분 콘솔 메뉴가 따로 있습니다. 여기서 권한을 고치거나 임시로 PasswordAuthentication yes를 켜서 들어간 뒤 정리합니다.

원인별 빠른 대조표

로그에 뜨는 문구	추정 원인	실행할 것
Offering public key: 줄 자체가 없음	키를 안 보냄	ssh -i ~/.ssh/키 -o IdentitiesOnly=yes
no such identity: ... No such file	키 경로 오타/없음	ls -l ~/.ssh 후 config에 IdentityFile 지정
WARNING: UNPROTECTED PRIVATE KEY FILE!	개인키 권한 느슨	chmod 600 ~/.ssh/id_ed25519
Too many authentication failures	키를 너무 많이 시도	IdentitiesOnly yes 설정
The agent has no identities (ssh-add -l)	에이전트에 키 없음	ssh-add ~/.ssh/키
Authentication refused: bad ownership or modes	서버 권한 문제	chmod 700 ~/.ssh, chmod 600 authorized_keys
no mutual signature algorithm	ssh-rsa 비활성	PubkeyAcceptedAlgorithms +ssh-rsa 또는 키 교체
avc: denied (audit.log)	SELinux 컨텍스트	restorecon -R -v ~/.ssh
User deploy not allowed because...	AllowUsers/DenyUsers	sshd_config 확인 후 sudo sshd -t

다음에 할 일 체크리스트

• [ ] ~/.ssh/config에 자주 쓰는 서버를 Host 별칭으로 등록하고 User, IdentityFile, IdentitiesOnly yes를 명시해 둡니다. 접속할 때마다 옵션을 기억할 필요가 없어집니다.
• [ ] 백업 접속 수단을 하나 확보합니다. 두 번째 키를 authorized_keys에 미리 넣어두거나, 클라우드 콘솔 로그인이 되는지 지금 확인해 둡니다.
• [ ] sshd_config를 고칠 때는 sudo sshd -t → 재시작 → 새 터미널로 접속 확인 → 기존 세션 종료 순서를 습관으로 만듭니다.
• [ ] 아직 ssh-rsa 키를 쓰고 있다면 ed25519로 교체 계획을 잡습니다. 언젠가는 막힙니다.
• [ ] 서버 로그 위치(journalctl -u sshd 또는 /var/log/auth.log)를 메모해 둡니다. 다음에 같은 일이 생기면 여기부터 보면 5분 안에 끝납니다.