깃허브(GitHub) 리포지토리에 코드를 원격 푸시하거나, AWS EC2 등의 리눅스 서버에 접속할 때 터미널에 “Permission denied (publickey)” 오류가 발생하며 연결이 차단되는 경우가 있습니다.
이 에러는 보안 통신을 위한 SSH(Secure Shell) 인증 과정에서 서버가 클라이언트의 신원을 확인하지 못했을 때 발생합니다. 이번 글에서는 SSH 키 인증의 구조를 살펴보고, 새로운 키 생성부터 권한 수정까지 문제를 해결하는 정석적인 과정을 단계별로 정리합니다.
1. 에러 발생 원인과 인증 구조
SSH는 안전한 통신을 위해 두 개의 키 페어를 사용하는 비대칭 암호화(Asymmetric Encryption) 방식을 기반으로 작동합니다. 인증은 다음과 같은 메커니즘으로 진행됩니다.
- 비밀키 (Private Key): 내 컴퓨터(~/.ssh/id_ed25519)에 보관하며, 절대 외부에 유출되어서는 안 되는 핵심 키입니다.
- 공개키 (Public Key): 접속 대상인 깃허브나 원격 서버(~/.ssh/authorized_keys)에 미리 등록해두는 자물쇠 역할을 하는 키입니다.
사용자가 접속을 시도하면 시스템 내부적으로 다음과 같은 키 대조 과정이 실행됩니다.
[클라이언트: 내 컴퓨터] ───(접속 요청)───> [원격 서버 또는 GitHub]
│ │
[비밀키 🔑] ◀━━━━━ (자물쇠 일치 검사) ━━━━━▶ [공개키 🔒]
│
❌ 등록된 공개키가 없거나 파일 권한이 꼬인 경우인증 실패 (Permission denied)
인증이 거부되는 구체적인 실패 요인은 다음과 같습니다.
- 요인 A: 내 컴퓨터에서 생성한 공개키를 대상 서버에 등록하지 않았을 때
- 요인 B: 내 컴퓨터에 비밀키 파일은 존재하지만, 현재 터미널 세션에 해당 키가 로드(등록)되지 않았을 때
- 요인 C: 리눅스 보안 정책상 SSH 관련 폴더 및 파일 권한이 너무 느슨하게 열려 있어 시스템이 키를 무효화했을 때
📌 1세션 핵심 요약: SSH 인증은 내 컴퓨터의 ‘비밀키’와 서버의 ‘공개키’가 매칭되어야 뚫립니다. 둘 중 하나라도 유실되거나 설정 권한이 어긋나면 브라우저와 터미널은 접속을 원천 차단합니다.
2. 단계별 해결 방법
오류를 해결하기 위해 기존 키 쌍을 점검하는 단계부터 서버 등록까지 순서대로 진행합니다.
1단계: 기존 SSH 키 존재 여부 확인
터미널을 열고 아래 명령어를 입력하여 이미 생성된 키 파일이 존재하는지 검사합니다.
ls -al ~/.ssh
출력 결과 목록에 id_rsa나 id_ed25519(비밀키), 그리고 .pub으로 끝나는 공개키 파일이 보이지 않는다면 다음 단계로 이동하여 키를 생성해야 합니다.
2단계: 새로운 SSH 키 페어 생성
현재 보안성과 성능이 가장 우수한 ed25519 알고리즘을 지정하여 새로운 인증 키를 생성합니다.
ssh-keygen -t ed25519 -C "your_email@example.com"
- -t ed25519: 암호화 알고리즘의 종류를 ed25519로 지정합니다.
- -C “이메일”: 생성된 키를 식별하기 위한 주석(Comment) 문구입니다.
경로 지정 안내가 나오면 Enter를 눌러 기본값으로 넘어가고, 비밀번호(Passphrase) 입력창 역시 Enter를 눌러 빈 값으로 설정을 완료합니다.
3단계: ssh-agent에 비밀키 등록
터미널 환경이 내 컴퓨터 내부의 비밀키 위치를 항상 인지할 수 있도록 백그라운드 인증 대리자(ssh-agent)에 키를 추가합니다.
# SSH 에이전트 프로세스 백그라운드 실행eval "$(ssh-agent -s)"# 생성한 비밀키 파일 등록ssh-add ~/.ssh/id_ed25519
4단계: 원격 플랫폼에 공개키 등록
아래 명령어를 입력하여 자물쇠 역할을 하는 공개키 문역을 터미널에 출력하고, 이를 그대로 복사(Ctrl+C)합니다.
cat ~/.ssh/id_ed25519.pub
- GitHub 등록법: GitHub 우측 상단 프로필 ➡️ Settings ➡️ SSH and GPG keys ➡️ [New SSH Key]를 누르고 복사한 키를 붙여넣습니다.
- 리눅스 서버 등록법: 대상 서버에 접속한 뒤
~/.ssh/authorized_keys파일을 열고 복사한 공개키 텍스트를 맨 아래 줄에 추가합니다.
📌 2세션 핵심 요약: 키가 없다면
ssh-keygen으로 생성하고,ssh-add로 내 시스템에 등록한 뒤,.pub파일의 공개키 텍스트 내용을 복사하여 대상 서버(또는 깃허브)에 심어주면 됩니다.
3. 필수 점검 사항: 파일 및 폴더 권한 수정
키를 올바르게 등록했음에도 에러가 지속된다면, 리눅스 자체의 파일 권한(Permission) 검증 시스템에 걸린 상태입니다. SSH 정책상 권한이 과도하게 열려 있는 키 파일은 보안 위협으로 간주되어 작동이 중지됩니다. 터미널에 아래 명령어를 실행하여 소유자 외의 접근을 차단하세요.
# .ssh 디렉토리는 소유자만 읽고 쓰고 진입할 수 있어야 함chmod 700 ~/.ssh# 개인 비밀키 파일은 소유자 외에 읽기/쓰기가 불가능해야 함chmod 600 ~/.ssh/id_ed25519# 서버 측 authorized_keys 자물쇠 파일 권한 설정chmod 600 ~/.ssh/authorized_keys
⚠️ 보안 위험 안내: 확장자가 없는 순수 비밀키(Private Key)는 본인의 인감도장과 같습니다. 이 파일 내부의 텍스트가 외부나 퍼블릭 깃허브 저장소에 노출되면 패스워드 없이 내 서버를 제어할 수 있는 권한이 통째로 넘어가므로 관리상 절대적인 주의가 필요합니다.
📌 3세션 핵심 요약: SSH는 보안에 극도로 민감합니다. 폴더 권한은
700, 키 파일 권한은600으로 확실하게 잠가주어야 정상 승인됩니다.
4. 자주 묻는 질문 (FAQ)
Q1. 하나의 키 쌍을 여러 컴퓨터에 복사해서 같이 쓰면 안 되나요?
보안 관례상 권장하지 않습니다. 기기마다 독립된 키 쌍을 생성하여 서버에 각각의 공개키로 등록하는 것이 정석입니다. 기기 분실 시 해당 기기의 공개키만 원격 서버에서 제거하면 되기 때문에 리스크 관리에 유리합니다.
Q2. 이미 사용 중인 기존 id_rsa 키가 있는데 ed25519를 또 만들면 충돌하나요?
충돌하지 않습니다. SSH 시스템은 인증 시 내부적으로 여러 키를 순차적으로 대조하며 매칭되는 키를 찾습니다. 만약 여러 개의 키를 더 체계적으로 관리하고 싶다면, 나중에 ~/.ssh/config 파일에 호스트(Host)별로 사용할 키의 경로를 미리 지정해 두면 키 꼬임 없이 깔끔하게 다중 키를 사용할 수 있습니다.
Q3. 키를 등록했는데도 계속 비밀번호(Password)를 입력하라고 나옵니다.
원격 저장소나 서버의 주소가 SSH 방식이 아닌 HTTPS 주소로 잡혀있을 가능성이 높습니다. git remote -v 명령어로 현재 주소를 확인하고 git@github.com:유저명/저장소명.git 형태의 SSH 주소로 변경해 주어야 키 인증이 동작합니다.
Q4. 패스프레이즈(Passphrase) 암호는 왜 입력하라고 하는 건가요?
비밀키 파일 자체를 한 번 더 암호화하는 추가 비밀번호입니다. 내 컴퓨터를 분실하여 비밀키 파일이 통째로 유출되더라도 패스프레이즈를 모르면 키를 사용할 수 없게 보호하는 장치입니다. 분실 위험이 적은 로컬 환경이라면 엔터로 생략해도 무방합니다.
📌 4세션 핵심 요약: 다중 키 관리가 필요할 땐
config파일을 활용하고, 자꾸 비밀번호 요구가 뜬다면 접속 프로토콜 주소가git@github.com구조의 SSH 포맷이 맞는지 재확인하세요.
5. 핵심 요약 및 마치며
- Permission denied 오류는 비밀키와 공개키의 불일치 혹은 유실로 인해 발생합니다.
- 해결을 위해 키 쌍 재생성 -> 에이전트 등록 -> 원격 서버 공개키 추가 단계를 밟아야 합니다.
- 마지막으로 파일 권한 수정을 통해 ~/.ssh(700) 및 키 파일(600)의 내부 보안을 격상해야 합니다.
비대칭 키 인증 방식을 한 번 정석대로 세팅해 두면 패스워드나 인증 토큰 입력 없이 안전하고 매끄러운 개발 및 인프라 제어가 가능해집니다.
댓글 남기기