문제 해결

SSH "Permission denied (publickey)": 해결 방법

Permission denied (publickey)는 서버가 당신의 인증을 거부했다는 뜻입니다. 가능성이 높은 순서로 다섯 가지 원인 ── 사용자명, 키 미제시, authorized_keys, 권한, 서버 설정 ── 과 정확한 해결 방법.

CC Chen Chen· 창업자·2026년 6월 24일·6분 분량

"Permission denied (publickey)"의 의미

이 오류는 서버가 당신의 인증을 거부했다는 뜻입니다 ── 네트워크 연결은 됐지만, 클라이언트가 제시한 어떤 자격 증명도 서버가 받아들이지 않은 것입니다. 괄호 안에 (publickey)가 있으면, 서버가 키 인증만 허용하는데 당신의 키 중 어느 것도 일치하지 않았다는 뜻입니다. 원인은 거의 항상 다섯 가지 중 하나입니다:잘못된 사용자명, 잘못된/없는 키, 공개 키가 서버에 없음, ~/.ssh 권한 오류, 또는 서버가 당신의 인증 방식을 허용하지 않음. 어느 것이 원인인지 몇 분 만에 찾는 방법을 알려드립니다.

가능성이 높은 순서로 다섯 가지 원인

#원인빠른 확인
1사용자명이 틀림ubuntu, root, pi, ec2-user 중 무엇? 클라우드 이미지마다 다름
2클라이언트가 올바른 키를 제시하지 않음연결 설정에서 키가 선택되어 있는가?
3공개 키가 authorized_keys에 없음이 서버에 키를 설치한 적이 있는가?
4서버 측 권한이 너무 개방됨~/.ssh는 700, authorized_keys는 600이어야 함
5서버 설정이 허용하지 않음PasswordAuthentication no + 키 미설치

1 — 먼저 사용자명을 확인

가장 흔한 원인, 특히 클라우드 서버에서:각 이미지에는 고유한 기본 사용자가 있습니다 ── ubuntu(Ubuntu), ec2-user(Amazon Linux), root(많은 VPS 이미지), pi(구형 Raspberry Pi OS), debian, admin……. 사용자명이 틀리면, 서버는 당신의 키를 고려하기도 전에 거부하며, 오류는 똑같아 보입니다.

2 — 올바른 키가 제시되는지 확인

데스크톱에서는 ssh -v user@host가 클라이언트가 시도한 키를 보여줍니다("Offering public key…"). 모바일 클라이언트에서는 연결 설정을 열어 이 연결에 실제로 키가 첨부되어 있는지 확인하세요 ── "비밀번호로" 생성한 연결은 키를 전혀 제시하지 않습니다. TermAI에서는 연결을 편집해 인증을 당신의 키로 전환하세요.

3 — 공개 키를 서버에 설치

서버는 당신이 로그인하는 사용자~/.ssh/authorized_keys에 나열된 키만 받아들입니다. 다른 방법(비밀번호, 콘솔)으로 아직 들어갈 수 있다면:

# from a machine that can log in:
ssh-copy-id user@host
# or manually append your public key:
cat your_key.pub >> ~/.ssh/authorized_keys

휴대폰에서는 TermAI가 대신 해줄 수 있습니다:Ed25519 키를 생성하고, 원탭 서버에 배포로 기존의 작동하는 로그인을 통해 공개 키를 authorized_keys에 기록합니다. 참고:키는 특정 사용자의 홈 아래에 들어갑니다 ── root용으로 설치해도 ubuntu로 로그인하는 데는 도움이 되지 않습니다.

4 — 서버 측 권한 수정

파일이나 디렉터리 권한이 너무 개방되어 있으면, OpenSSH는 authorized_keys를 조용히 무시합니다. 서버에서:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

홈 디렉터리 자체가 그룹/전체 쓰기 가능하지 않은지도 확인하세요. 이것이 "키를 설치했는데도 계속 실패한다"는 전형적인 원인입니다 ── 서버의 /var/log/auth.log를 확인하면 "Authentication refused: bad ownership or modes"라고 기록됩니다.

5 — 서버가 무엇을 허용하는지 확인

/etc/ssh/sshd_config에서:만약 PasswordAuthentication no인데 키가 설치되지 않았다면, 실패하는 경로에 갇힌 것입니다;만약 PermitRootLogin no인데 root를 시도하고 있다면, 그것이 거부의 원인입니다. 설정을 수정하고(또는 올바른 사용자를 사용하고), 그다음 sudo systemctl restart ssh. root 로그인을 안전하게 비활성화하기를 참조하세요.

휴대폰에서 이것을 디버깅하기

이것이 휴대폰에서 발생하면, 괴로운 부분은 장황한 오류를 읽고 진단 명령을 기억하는 것입니다. 그 서버로의 어떤 작동하는 세션이라도 있다면, 오류 출력을 선택해 어시스턴트에게 물어보세요 ── TermAI의 AI는 실제 메시지와 서버 컨텍스트를 읽고, 다섯 가지 원인 중 어느 것인지 알려주며, 검토하고 실행할 정확한 수정 명령을 제시합니다.

SSH 오류를 설명하고 수정 명령을 제안하는 TermAI의 AI 어시스턴트
오류를 선택해 AI에게 물어보세요:실시간 서버에 기반해 권한 문제와 키 누락을 구분하고, 실행할 정확한 chmod/ssh-copy-id를 제시합니다.

자주 묻는 질문

Permission denied (publickey)는 무슨 뜻인가요?
서버가 SSH 키 인증만 받아들이는데 클라이언트가 제시한 키가 어느 것도 일치하지 않은 것입니다. 사용자명, 키 선택, authorized_keys, 권한 순서로 확인하세요.

키를 설치했는데도 왜 실패하나요?
보통 권한:~/.ssh는 700, authorized_keys는 600이어야 하며 로그인 사용자가 소유해야 합니다. 또는 로그인하는 사용자와 다른 사용자 아래에 키가 설치되었습니다.

실제로 무엇이 실패하는지 어떻게 확인하나요?
데스크톱에서는 ssh -v user@host를 실행하고;서버에서는 /var/log/auth.log(또는 journalctl -u ssh)를 확인하세요 ── 이유가 명시적으로 기록됩니다.

휴대폰에서 고칠 수 있나요?
네, 들어갈 수 있는 어떤 방법(비밀번호 로그인 또는 다른 키)이라도 있다면. TermAI는 원탭으로 새 키를 서버에 배포할 수 있고, 그 AI가 auth.log 출력을 진단할 수 있습니다.

핵심 요약

  • 의미:서버가 인증 거부 ── 제시된 키가 일치하지 않음(네트워크가 아니라 인증)
  • 주요 원인:사용자명 오류 · 키 미제시 · authorized_keys에 없음 · 권한 오류 · 서버 설정
  • 권한:~/.ssh 700, authorized_keys 600
  • 실제 이유 확인:클라이언트 측 ssh -v, 서버 측 /var/log/auth.log
Try TermAI

Free on iOS and Android. 5 AI requests/day on the free tier, plus unlimited SSH/SFTP and built-in Tailscale.

CC
Chen Chen — Founder of TermAI

Writes about mobile DevOps, terminal UX, and the surprising depth of "boring" infrastructure.

Was this useful? ← Back to blog