SSH 퍼블릭키 권한 거부 문제 해결
SSH 사용 시 'Permission Denied (publickey)' 오류가 발생하시나요? 이 가이드는 일반적인 인증 오류를 해결하기 위한 포괄적인 방법을 제공합니다. SSH 키 쌍을 꼼꼼히 확인하고, 클라이언트와 서버 모두에서 잘못된 파일 권한을 진단하며, `authorized_keys` 파일이 올바르게 구성되었는지 확인하는 방법을 알아보세요. 실용적인 예제와 단계별 지침을 통해 원격 시스템에 대한 안전한 액세스를 다시 확보할 수 있습니다.
SSH 퍼블릭키 권한 거부 문제 해결
Permission denied (publickey)는 서버에 연결할 수 있었지만, 시도한 사용자에 대한 공개키 인증 시도를 수락하지 않았음을 의미합니다. 이는 문제의 범위를 좁혀줍니다. 더 이상 라우팅, DNS, 또는 SSH 포트가 열려 있는지 디버깅하지 않습니다. 사용자 이름, 클라이언트가 제공한 개인 키, 서버에 저장된 공개 키, 그리고 로그인 허용 여부를 결정하는 서버 규칙 등 신원을 디버깅하는 것입니다.
가장 빠른 유용한 명령어는 다음과 같습니다:
ssh -vvv user@your_server_ip
Authenticating to ... as 'user'를 찾은 다음 Offering public key를 찾으세요. 예상 키가 제공되지 않으면 클라이언트를 수정하세요. 예상 키가 제공되었으나 거부되면 서버 측 authorized_keys, 소유권, 권한 또는 SSH 데몬 정책을 수정하세요.
'Permission Denied (publickey)'의 일반적인 원인
'Permission Denied (publickey)' 오류는 여러 구성 문제로 인해 발생할 수 있습니다. 근본 원인을 파악하려면 일반적으로 다음 구성 요소를 체계적으로 확인해야 합니다:
- 잘못된 파일 권한: SSH는 보안상의 이유로 파일 및 디렉토리 권한에 매우 민감합니다. 로컬
~/.ssh디렉토리, 개인 키 파일, 또는 서버 측~/.ssh디렉토리와authorized_keys파일의 권한이 잘못되면 인증이 차단될 수 있습니다. authorized_keys항목 누락 또는 오류: 서버의authorized_keys파일에는 로그인하려는 사용자의 올바른 공개 키가 포함되어 있어야 합니다. 키가 없거나, 형식이 잘못되었거나, 잘못된 사용자와 연결된 경우 인증이 실패합니다.- 잘못된 키 쌍 연결: SSH 클라이언트가 잘못된 개인 키를 제공하거나, 서버가
authorized_keys파일에 해당 공개 키를 가지고 있지 않을 수 있습니다. - SSH 에이전트 문제: SSH 에이전트를 사용하는 경우 개인 키가 제대로 로드되지 않았거나 잘못 구성되었을 수 있습니다.
- 서버 측 SSH 구성: 이 특정 오류의 경우 덜 일반적이지만, 서버의 SSH 데몬 구성(
sshd_config)에 공개키 인증에 대한 특정 제한이 있을 수 있습니다.
단계별 문제 해결 가이드
이러한 문제를 진단하고 해결하기 위한 실용적인 단계를 살펴보겠습니다.
1. 로컬 개인 키 및 권한 확인
로컬 SSH 구성이 첫 번째 확인 사항입니다. 개인 키에 접근 가능하고 올바른 권한이 있는지 확인하세요.
개인 키 존재 확인
개인 키는 일반적으로 ~/.ssh/id_ed25519 또는 ~/.ssh/id_rsa에 있지만, 많은 팀에서 프로젝트별 이름을 사용합니다. 키를 나열하세요:
ls -la ~/.ssh
개인 키를 authorized_keys에 업로드하거나 붙여넣지 마세요. 서버에는 .pub 파일 내용이 필요하며, 개인 키가 아닙니다.
로컬 파일 권한 확인
~/.ssh 디렉토리와 개인 키 파일은 무단 액세스를 방지하기 위해 제한적인 권한을 가져야 합니다.
~/.ssh디렉토리:700(drwx------)이어야 합니다.- 개인 키 파일 (예:
id_rsa):600(-rw-------)이어야 합니다.
chmod 명령을 사용하여 올바른 권한을 설정하세요:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
팁: 다른 키 이름을 사용하는 경우 id_rsa를 실제 개인 키 파일 이름으로 바꾸세요.
특정 키를 테스트하는 경우 강제로 지정하세요:
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@your_server_ip
이렇게 하면 에이전트가 먼저 관련 없는 키 목록을 제공하는 것을 방지할 수 있습니다.
2. 서버 측 authorized_keys 구성 확인
이것이 가장 일반적인 원인인 경우가 많습니다. 서버는 인증하려는 사용자에 대해 공개 키가 올바르게 나열되어 있어야 합니다.
서버 접속 (가능한 경우)
다른 방법(예: 비밀번호 인증, 다른 사용자 계정, 콘솔)으로 서버에 여전히 접속할 수 있다면 로그인하여 authorized_keys 파일을 확인하세요.
authorized_keys 파일 위치 확인
authorized_keys 파일은 일반적으로 로그인하려는 사용자의 홈 디렉토리 내 ~/.ssh/authorized_keys에 있습니다.
서버 측 파일 권한 확인
클라이언트 측과 마찬가지로 서버 측 권한도 중요합니다:
- 서버의
~/.ssh디렉토리:700(drwx------)이어야 합니다. - 서버의
authorized_keys파일:600(-rw-------)이어야 합니다.
서버에서 이러한 권한이 올바르게 설정되었는지 확인하세요:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
또한 소유권을 확인하세요. .ssh 디렉토리와 authorized_keys 파일은 일반적으로 로그인하는 계정에 속해야 합니다:
chown -R youruser:youruser ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
sshd_config에서 StrictModes가 활성화된 경우, 홈 디렉토리나 .ssh 경로가 잘못된 사용자에 의해 쓰기 가능하면 OpenSSH가 키를 거부할 수 있습니다.
authorized_keys 내용 확인
텍스트 편집기(예: nano, vim)를 사용하여 ~/.ssh/authorized_keys 파일을 엽니다. 각 공개 키는 한 줄에 하나씩 있어야 합니다. 사용하려는 공개 키가 존재하고 올바르게 형식화되었는지 확인하세요. ssh-rsa, ssh-ed25519 등으로 시작하고, 긴 문자열과 선택적으로 주석이 뒤따라야 합니다.
authorized_keys 항목 예시:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... your_public_key_string user@hostname
개인 키를 authorized_keys에 추가하지 마세요. 여기에는 공개 키만 있어야 합니다.
3. 올바른 공개 키가 추가되었는지 확인
잘못된 공개 키가 복사되었거나 서버의 공개 키가 로컬 개인 키와 일치하지 않을 수 있습니다.
로컬 공개 키 검색
공개 키는 개인 키의 대응입니다. ssh-keygen 명령을 사용하여 볼 수 있습니다:
cat ~/.ssh/id_rsa.pub
이 명령은 공개 키를 출력합니다. 이 출력을 서버의 ~/.ssh/authorized_keys 파일 항목과 신중하게 비교하세요. 단 하나의 오타나 누락된 문자도 인증 실패를 초래합니다.
더 깔끔한 비교를 위해 사용하려는 개인 키에서 파생된 공개 키를 출력하세요:
ssh-keygen -y -f ~/.ssh/id_ed25519_prod
해당 출력은 원격 사용자의 authorized_keys에 있는 한 줄과 일치해야 합니다.
팁: 서버에 비밀번호 접속 권한이 있는 경우 공개 키를 빠르게 추가하는 방법은 ssh-copy-id를 사용하는 것입니다.
ssh-copy-id user@your_server_ip
이 명령은 기본 공개 키(~/.ssh/id_rsa.pub)를 원격 서버의 ~/.ssh/authorized_keys 파일에 자동으로 추가하고 올바른 권한을 설정합니다.
4. 올바른 개인 키 지정 (기본값이 아닌 경우)
기본값이 아닌 개인 키(예: ~/.ssh/my_other_key)를 사용하는 경우 SSH 클라이언트에 사용할 키를 알려야 합니다.
-i 플래그 사용
-i 옵션으로 ID 파일(개인 키)을 지정할 수 있습니다:
ssh -i ~/.ssh/my_other_key user@your_server_ip
~/.ssh/config 구성
편의를 위해 특정 호스트에 대해 항상 특정 키를 사용하도록 SSH 클라이언트를 구성할 수 있습니다:
로컬 머신에서 ~/.ssh/config 파일을 생성하거나 편집하고 다음과 같은 항목을 추가하세요:
Host your_server_alias
HostName your_server_ip_or_domain
User your_username
IdentityFile ~/.ssh/my_other_key
IdentitiesOnly yes
그런 다음 간단히 다음을 사용하여 연결할 수 있습니다:
ssh your_server_alias
5. SSH 에이전트 상태 확인
SSH 에이전트를 사용하여 키를 관리하는 경우 에이전트가 실행 중이고 키가 로드되었는지 확인하세요.
에이전트 실행 확인
echo "$SSH_AUTH_SOCK"
경로가 출력되면 에이전트가 실행 중일 가능성이 높습니다. 비어 있으면 에이전트를 시작해야 할 수 있습니다.
에이전트에 키 추가
키가 로드되지 않은 경우 추가하세요:
ssh-add ~/.ssh/id_rsa
암호를 묻는 경우 입력하세요. ssh-add -l로 추가된 키를 확인할 수 있습니다.
ssh-add -l에 관련 없는 키가 많이 표시되고 여러 번 시도 후 서버 연결이 끊어지면 에이전트에서 이전 키를 제거하거나 해당 호스트에 대해 IdentitiesOnly yes를 사용하세요.
6. 상세 모드로 디버깅
SSH에는 인증 프로세스가 실패하는 위치에 대한 귀중한 단서를 제공할 수 있는 상세 모드(-v, -vv, 또는 -vvv)가 있습니다.
ssh -vvv user@your_server_ip
키 인증, 키 제공 및 서버 응답과 관련된 메시지가 있는지 출력을 검토하세요. 이는 종종 문제를 직접 가리킵니다.
공개키 실패를 나타내는 상세 출력 예시:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
이 출력은 클라이언트가 id_rsa를 시도했지만 서버가 이를 수락하지 않았고 클라이언트가 허용된 다음 방법으로 넘어갔음을 의미합니다.
7. 서버 측 sshd_config 검토 (고급)
/etc/ssh/sshd_config 및 /etc/ssh/sshd_config.d/의 모든 파일을 확인하세요. 공개키 인증이 활성화되어 있는지 확인하세요:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
그런 다음 파일 하단 근처에서 Match 블록을 찾으세요. 이후의 Match User, Match Group 또는 Match Address 블록은 테스트 중인 정확한 계정에 대한 이전 설정을 재정의할 수 있습니다.
변경 후에는 다시 로드하기 전에 구문의 유효성을 검사하세요:
sudo sshd -t
sudo systemctl reload sshd
일부 시스템에서는 sshd 대신 ssh를 서비스 이름으로 사용합니다.
신뢰할 수 있는 문제 해결 순서
추측을 피하기 위해 상세 출력을 사용하세요. 먼저 사용자 이름을 확인하세요. 그런 다음 클라이언트가 예상하는 개인 키를 제공하는지 확인하세요. 그런 다음 일치하는 공개 키가 대상 사용자의 authorized_keys에 있는지 확인하세요. 그런 다음 소유권과 권한을 확인하세요. 이러한 항목이 깔끔해진 후에야 sshd_config, Match 블록, SELinux 컨텍스트 또는 계정 제한 사항에 시간을 투자해야 합니다.
이 순서는 무작위 변경 없이 대부분의 Permission denied (publickey) 사례를 해결하며, 긴급 로그인 하나를 위해 SSH 보안을 약화시키지 않도록 합니다.