일반적인 SSH 'Permission Denied' 오류 및 연결 문제 해결 가이드

Secure Shell (SSH)은 원격 서버 관리의 기반이며, 원격 시스템에 접속하고 제어하기 위한 암호화된 통신을 제공합니다. 신뢰할 수 있지만, 특히 키 기반 인증을 사용하는 SSH 설정은 때때로 답답한 연결 실패로 이어질 수 있습니다. 가장 흔한 원인은 바로 악명 높은 Permission denied 오류입니다.

이 종합 가이드는 가장 자주 발생하는 SSH 오류를 진단하고 해결하는 방법을 안내할 것입니다. 특히 Permission denied (publickey)의 근본 원인을 이해하고, 파일 권한, 잘못된 구성, 클라이언트/서버 설정 불일치와 관련된 일반적인 함정을 다루는 데 중점을 둘 것입니다. 이러한 문제 해결 단계를 숙달하면 원격 인프라에 대한 안전하고 신뢰할 수 있는 액세스를 보장할 수 있습니다.

SSH 인증 흐름 이해하기

문제 해결에 앞서 SSH가 사용자를 어떻게 인증하는지 이해하는 것이 중요합니다. 연결을 시도하면 서버는 일반적으로 (구성 설정에 따라) 다음 순서로 자격 증명을 확인합니다.

공개 키 인증: 클라이언트가 공개 키를 제시하고, 서버는 해당 비공개 키가 유효하고 승인된 키 (authorized_keys 파일)와 일치하는지 확인합니다.
패스워드 인증: 키 인증이 실패하거나 비활성화된 경우, 서버는 패스워드를 요청합니다.

Permission denied 메시지를 받았다면, 이는 거의 항상 서버가 1단계 또는 2단계에서 자격 증명을 거부했음을 의미합니다.

연결 문제 진단: 상세 모드의 위력

SSH 문제를 진단하는 가장 효과적인 도구는 클라이언트를 상세 모드(verbose mode)로 실행하는 것입니다. -v, -vv, 또는 -vvv 플래그를 추가하면 클라이언트는 협상 과정에 대한 상세한 디버깅 정보를 출력합니다.

상세 플래그 사용하기

다음 명령 구조를 사용하세요:

ssh -vvv user@remote_host

출력에서 찾아야 할 것:

키 교환: 클라이언트가 시도한 인증 방법(예: Offering RSA key: /path/to/id_rsa)을 나타내는 줄을 찾으세요.
서버 응답: 서버의 거부 메시지에 특히 주의하세요. 출력에서 서버가 키를 확인했지만 일치시키지 못하는 것으로 나타나면, 문제는 서버 측의 키 구성 또는 권한 문제일 가능성이 높습니다.
패스워드 프롬프트: 출력이 키 확인을 건너뛰고 즉시 패스워드를 요구한다면, 서버에서 키 인증이 비활성화되었을 수 있습니다.

`Permission denied (publickey)` 해결하기

이 오류는 서버가 제공된 공개 키 자격 증명을 명시적으로 거부했음을 나타냅니다. 해결책은 보통 권한 또는 키 페어링에 있습니다.

1. 키 파일 권한 확인 (클라이언트 측)

보안을 위해 SSH 클라이언트는 비공개 키 파일(예: ~/.ssh/id_rsa)의 권한에 대해 매우 엄격합니다. 이 파일들의 권한이 너무 개방적이면 클라이언트는 사용을 거부할 것입니다.

실행 가능한 해결책 (클라이언트): 비공개 키가 본인만 읽을 수 있도록 보장하세요.

chmod 600 ~/.ssh/id_rsa

2. 키 존재 여부 및 올바른 키 사용 확인

특히 비표준 키나 여러 키 페어를 사용하는 경우 올바른 ID 파일로 연결하고 있는지 확인하세요.

실행 가능한 해결책 (클라이언트): -i 플래그를 사용하여 올바른 비공개 키를 지정하세요.

ssh -i /path/to/your/specific_private_key user@remote_host

3. 서버 측 권한 및 소유권

이것이 가장 흔한 실패 원인입니다. SSH는 로그인하려는 사용자에 대해 서버의 디렉터리 및 파일 권한에 엄격한 규칙을 적용합니다.

서버 상의 경로	필요한 권한	소유자
`~/.ssh` 디렉터리	`700` (rwx------)	사용자
`~/.ssh/authorized_keys` 파일	`600` (rw-------)	사용자

실행 가능한 해결책 (서버): 콘솔 또는 (활성화된 경우) 패스워드 인증을 통해 로그인한 후 다음 명령을 실행하세요:

# 디렉터리 권한 설정
chmod 700 ~/.ssh

# authorized_keys 권한 설정
chmod 600 ~/.ssh/authorized_keys

# 소유권 확인 ('myuser'를 실제 사용자 이름으로 바꾸세요)
chown -R myuser:myuser ~/.ssh

경고: 사용자 홈 디렉터리(~)의 권한이 너무 광범위하면(예: 그룹 또는 다른 사용자가 쓰기 가능), 보안상의 이유로 SSH가 실패할 수도 있습니다. 문제가 지속된다면 ~에 대해 755 또는 더 엄격한 권한을 목표로 하세요.

4. 키가 실제로 추가되었는지 확인

클라이언트의 공개 키 문자열이 서버의 ~/.ssh/authorized_keys 파일에 붙여넣어진 내용과 정확히 일치하는지 확인하세요. 누락된 문자나 뒤에 오는 공백은 인증 실패를 유발할 것입니다.

팁: 키를 추가할 때, 가능하다면 ssh-copy-id를 사용하세요. 이 명령은 권한 및 서식 지정을 자동으로 처리합니다:

ssh-copy-id user@remote_host

구성 파일 문제 해결 (`sshd_config`)

키와 권한이 올바르다면, 문제는 종종 서버의 SSH 데몬 구성 파일(일반적으로 /etc/ssh/sshd_config에 위치)에 있습니다.

1. 인증 방법 확인

공개 키 인증이 명시적으로 허용되어 있는지 확인하세요.

구성 확인: 다음 줄을 찾아 주석 처리되지 않았는지(#이 없는지) 그리고 올바르게 설정되었는지 확인하세요:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. 패스워드 인증 상태

임시로 패스워드 로그인을 사용하고 있다면, 이것이 활성화되어 있는지 확인하세요. no로 설정되어 있다면, 반드시 키를 사용해야 합니다.

PasswordAuthentication yes

3. PermitRootLogin

root로 로그인하려 한다면, 이것이 허용되어 있는지 확인하세요. 일반적인 모범 사례는 표준 사용자로 로그인하여 sudo를 사용하는 것이지만, 문제 해결을 위해 이 설정을 확인할 수 있습니다:

PermitRootLogin yes

핵심 단계: /etc/ssh/sshd_config에 어떤 변경을 가한 후에는 변경 사항이 적용되도록 SSH 서비스를 다시 시작해야 합니다:
bash sudo systemctl restart sshd # 또는 service ssh restart

기타 일반적인 연결 오류

키 관련 문제가 주요 원인이지만, 다른 오류도 액세스를 차단할 수 있습니다:

A. 연결 시간 초과 (Connection Timed Out)

이것은 일반적으로 클라이언트가 서버에 전혀 도달할 수 없었음을 의미하며, 인증 문제가 아닌 네트워크 문제를 나타냅니다.

가능한 원인:
* 서버가 다운되었거나 도달할 수 없는 상태입니다.
* 방화벽(로컬 또는 네트워크)이 22번 포트(또는 사용자 지정 SSH 포트)의 연결을 차단하고 있습니다.
* 잘못된 IP 주소 또는 호스트 이름입니다.

문제 해결: ping을 사용하여 기본적인 연결을 확인하고, telnet 또는 nc(netcat)를 사용하여 포트가 열려 있는지 확인하세요:

# 22번 포트에 도달 가능한지 확인
telnet remote_host 22

B. 호스트에 대한 경로 없음 (No Route to Host)

타임아웃과 유사하게, 이것은 네트워크 인프라 문제입니다. 클라이언트가 서버의 IP 주소로 가는 경로를 찾을 수 없습니다. 라우팅 테이블, VPN 상태를 확인하거나 원격 서버에 유효한 네트워크 인터페이스가 활성화되어 있는지 확인하세요.

C. 서버가 우리의 키를 거부함 (Server Refused Our Key)

상세 출력에서 서버가 키를 적극적으로 거부하지만 authorized_keys 파일을 확인했다면, 서버의 SELinux 또는 AppArmor 보안 컨텍스트를 확인하세요. 이러한 보안 모듈은 파일 권한을 재정의하고 컨텍스트가 잘못된 경우 SSH 액세스를 차단할 수 있습니다.

모범 사례 요약

진단을 위해 항상 상세 모드(-vvv)를 사용하세요.
클라이언트 키 보안: 비공개 키가 600으로 설정되어 있는지 확인하세요 (chmod 600).
서버 파일 무결성: ~/.ssh가 700이고 authorized_keys가 600인지 확인하세요.
데몬 재시작: /etc/ssh/sshd_config를 수정한 후에는 항상 sshd를 다시 시작하세요.
키 배포 자동화를 위해 가능한 한 ssh-copy-id를 사용하세요.