SH를 통해 서버에 접속하려는데 “Permission Denied (publickey, gssapi-keyex, gssapi-with-mic)” 오류가 발생해서 답답하셨나요? 특히 AWS EC2와 같은 리눅스 서버 환경에서 자주 발생하는 이 오류는 서버 관리자와 개발자에게 흔한 골칫거리입니다. 하지만 걱정 마세요! 이 글에서는 해당 오류의 주요 원인을 명확히 파악하고, 단계별 해결 방법을 상세하게 안내하여 여러분의 문제를 시원하게 해결해 드릴게요.
1. 프라이빗 키 권한 및 경로 제대로 확인했나요?
가장 기본적인 원인이자 흔히 발생하는 실수 중 하나는 프라이빗 키 파일의 권한 설정 오류 또는 잘못된 경로 지정입니다. SSH는 프라이빗 키를 통해 안전하게 서버에 접근하므로, 키 파일의 권한이 적절하지 않거나 SSH 명령어에서 키 파일의 경로를 정확하게 지정하지 않으면 접속이 거부될 수 있습니다.
해결 방법:
- 프라이빗 키 파일 권한 확인 및 변경: 터미널을 열고 다음 명령어를 실행하여 프라이빗 키 파일의 권한을
600으로 설정합니다. (일반적으로 프라이빗 키 파일은 본인만 읽고 쓸 수 있어야 합니다.)
코드:
chmod 600 ~/.ssh/your_private_key.pem
팁: ~/.ssh/ 경로는 사용자 홈 디렉토리 아래의 .ssh 폴더를 의미합니다. your_private_key.pem은 실제 사용하고 있는 프라이빗 키 파일 이름으로 변경해야 합니다.
- SSH 명령어에서 프라이빗 키 경로 정확하게 지정: SSH 접속 시
-i옵션을 사용하여 프라이빗 키 파일의 정확한 경로를 명시해야 합니다.
코드:
ssh -i “/path/to/your_private_key.pem” ec2-user@your_server_ip
주의: /path/to/your_private_key.pem 부분을 실제 프라이빗 키 파일이 위치한 경로로 수정해야 합니다. 경로가 틀리면 오류가 발생하므로, 다시 한번 확인해 보세요.
2. AWS EC2 기본 사용자 이름이 맞는지 확인하세요
AWS EC2 인스턴스를 생성할 때 선택하는 AMI(Amazon Machine Image)에 따라 기본 사용자 이름이 다릅니다. 잘못된 사용자 이름으로 접속을 시도하면 서버에서 사용자를 찾을 수 없어 접속이 거부됩니다.
주요 AMI별 기본 사용자 이름:
- Amazon Linux 2:
ec2-user - Ubuntu:
ubuntu - CentOS:
centos또는ec2-user - Debian:
admin또는debian - RHEL:
ec2-user또는root
해결 방법:
본인이 사용하는 EC2 인스턴스의 AMI에 맞는 기본 사용자 이름으로 SSH 명령어를 실행해야 합니다. AWS Management Console에서 인스턴스 세부 정보를 확인하여 정확한 사용자 이름을 파악할 수 있습니다.
3. 서버의 authorized_keys 파일 점검하기
authorized_keys 파일은 서버가 클라이언트의 공개 키를 인증하는 데 사용되는 핵심 파일입니다. 이 파일에 클라이언트의 공개 키가 없거나, 권한이 잘못 설정되었거나, 내용이 올바르지 않으면 “Permission Denied” 오류가 발생할 수 있습니다.
해결 방법:
- authorized_keys 파일 권한 확인 및 변경: 서버에 접속하여 (일단 다른 방법으로 접속이 가능하다면) 다음 명령어를 실행하여
authorized_keys파일의 권한을600으로 설정합니다.
코드:
chmod 600 ~/.ssh/authorized_keys
- authorized_keys 파일 내용 확인 및 수정: 다음 명령어를 사용하여
authorized_keys파일의 내용을 확인합니다.
코드:
cat ~/.ssh/authorized_keys
이 파일에는 여러분의 공개 키가 한 줄로 저장되어 있어야 합니다.
- 공개 키 누락: 만약 파일이 비어 있거나, 여러분의 공개 키가 없다면, 로컬 컴퓨터의 공개 키 (
~/.ssh/id_rsa.pub또는~/.ssh/id_ed25519.pub등) 내용을 복사하여 서버의authorized_keys파일에 추가해야 합니다. 각 공개 키는 한 줄로 작성해야 합니다. - 잘못된 공개 키: 기존에 등록된 공개 키가 변경되었거나, 실수로 잘못된 키가 등록된 경우, 해당 줄을 삭제하고 올바른 공개 키를 다시 추가해야 합니다.
주의: authorized_keys 파일을 수정할 때는 신중해야 합니다. 잘못된 수정은 서버 접속 불능으로 이어질 수 있습니다.
4. 혹시 보안 그룹과 네트워크 설정에 문제가 있나요?
AWS EC2를 사용하는 경우, 보안 그룹 설정은 SSH 접속에 매우 중요한 역할을 합니다. 보안 그룹에서 SSH 접속에 사용되는 22번 포트가 열려 있지 않으면 외부에서 서버로의 접속 자체가 차단됩니다. 또한, 서버의 퍼블릭 IP 주소 또는 DNS 이름이 정확한지도 확인해야 합니다.
해결 방법:
- 보안 그룹 설정 확인: AWS Management Console의 EC2 인스턴스 보안 그룹 설정을 확인하여, 인바운드 규칙에 22번 포트가 열려 있는지 확인합니다. 필요하다면 22번 포트를 허용하는 규칙을 추가해야 합니다. 접속 IP 주소 범위를 적절하게 설정하는 것도 중요합니다.
- 퍼블릭 IP 및 DNS 이름 확인: EC2 인스턴스의 퍼블릭 IP 주소 또는 DNS 이름이 변경되었을 수 있으므로, AWS Management Console에서 최신 정보를 확인하고 SSH 명령어에 정확하게 입력했는지 확인합니다.
5. 서버 SSH 설정 (sshd_config) 도 한번 살펴보세요
드물지만, 서버의 SSH 설정 파일 (sshd_config)에서 공개 키 인증 관련 설정이 비활성화되어 있을 수도 있습니다.
해결 방법:
- sshd_config 파일 확인 및 수정: 서버에 접속하여 다음 명령어를 실행하여 SSH 설정 파일을 엽니다.
코드:
sudo nano /etc/ssh/sshd_config
- 파일 내용에서 다음 옵션을 찾습니다.
코드:
PubkeyAuthentication yes
만약 해당 줄이 주석 처리되어 (#으로 시작) 있거나 no로 설정되어 있다면, 주석을 제거하고 yes로 변경해야 합니다.
- SSH 서비스 재시작: 설정을 변경한 후에는 SSH 서비스를 재시작하여 변경 사항을 적용해야 합니다.
코드:
sudo systemctl restart sshd
또는
코드:
sudo service ssh restart
(운영체제에 따라 명령어가 다를 수 있습니다.)
마무리하며
“Permission Denied (publickey)” 오류는 다양한 원인으로 발생할 수 있지만, 대부분 위에서 설명드린 설정 문제나 파일 권한 문제인 경우가 많습니다. 제시된 해결 방법들을 차근차근 따라 해보시면 대부분의 상황에서 문제를 해결하고 서버에 성공적으로 접속할 수 있을 거예요.