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

SSH Permission denied 오류는 일반적으로 서버에 도달했지만 인증이 거부되었음을 의미합니다. 이는 Connection timed out, Connection refused 또는 No route to host와는 다릅니다. 이러한 모든 오류를 "SSH가 고장났다"고 처리하면 시간이 낭비되므로, 먼저 인증 실패와 네트워크 실패를 구분하세요.

실패한 명령을 상세 로깅과 함께 실행하세요:

ssh -vvv user@remote_host

클라이언트가 사용한 사용자 이름, 제공한 키 파일, 서버가 키를 수락했는지 여부, 그리고 남은 인증 방법 등 명확한 단서를 찾으세요. 대부분의 아래 수정 사항은 이러한 단서를 서버 측 상태와 일치시키는 데서 비롯됩니다.

SSH 인증 흐름 이해

연결을 시도할 때 서버는 구성에서 활성화된 인증 방법만 허용합니다. 일반적인 서버는 먼저 공개 키 인증을 시도하고 정책에 따라 이후에 비밀번호 인증을 허용할 수 있습니다:

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

Permission denied를 받으면 TCP 연결은 작동한 것입니다. 서버가 해당 사용자에 대해 제시한 자격 증명을 수락하지 않은 것뿐입니다.

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

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

상세 플래그 사용

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

ssh -vvv user@remote_host

출력에서 찾아야 할 사항:

사용자 이름: Authenticating to ... as 'user'를 찾으세요. 잘못된 Linux 사용자 이름은 놓치기 쉬운 실수 중 하나입니다.
제공된 키: Offering public key를 찾으세요. 예상 키가 나타나지 않으면 클라이언트 구성을 수정하세요.
서버 응답: 제공된 모든 키 뒤에 Authentications that can continue가 오면 서버가 해당 키를 거부한 것입니다.
인증 방법: publickey가 나열되지 않으면 서버가 해당 계정 또는 호스트 블록에 대해 키 인증을 허용하지 않을 수 있습니다.

`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

에이전트에 많은 키가 로드된 경우 이 테스트를 위해 IdentitiesOnly=yes를 추가하세요:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod 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

사용자의 홈 디렉토리가 그룹이나 다른 사용자에 의해 쓰기 가능한 경우, StrictModes가 활성화되면 OpenSSH가 키를 거부할 수도 있습니다. 다음으로 확인하세요:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

대부분의 일반 사용자 홈의 경우 755 또는 더 엄격한 것이 괜찮습니다.

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

클라이언트의 공개 키가 서버의 ~/.ssh/authorized_keys 파일에 붙여넣은 것과 일치하는지 확인하세요. 누락된 문자, 줄 바꿈 또는 복사된 개인 키는 인증 실패를 초래합니다.

키를 추가할 때 비밀번호 접근이 아직 가능하면 ssh-copy-id를 사용하세요:

ssh-copy-id user@remote_host

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

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

1. 인증 방법 확인

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

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

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

또한 파일 하단 근처의 Match 블록을 확인하세요. 전역 설정이 공개 키를 허용할 수 있지만, 이후의 Match User, Match Group 또는 Match Address 블록이 테스트 중인 정확한 로그인에 대해 이를 비활성화할 수 있습니다.

2. 비밀번호 인증 상태

임시로 비밀번호 로그인에 의존하는 경우 활성화되어 있는지 확인하세요. no로 설정된 경우 반드시 키를 사용해야 합니다.

PasswordAuthentication yes

3. PermitRootLogin

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

PermitRootLogin prohibit-password

루트 로그인의 경우 많은 시스템이 키 전용 루트 액세스를 기본값으로 하거나 루트 로그인을 완전히 비활성화합니다. sudo가 있는 일반 사용자를 선호하세요. SSH 데몬 설정을 변경해야 하는 경우 다시 로드하기 전에 구문을 검증하세요:

sudo sshd -t
sudo systemctl reload sshd  # 일부 시스템: sudo systemctl reload ssh

기타 일반적인 연결 오류

키 문제가 주된 원인이지만 다른 오류도 접근을 차단할 수 있습니다:

A. 연결 시간 초과

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

가능한 원인:

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

기본 연결 가능성 힌트를 위해 ping을 사용하고 SSH 포트를 확인하려면 nc를 사용하세요:

nc -vz remote_host 22

B. 호스트로의 경로 없음

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

C. 서버가 키를 거부함

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

일반적으로 작동하는 실용적인 순서

먼저 사용자 이름을 확인하세요. 그런 다음 ssh -o IdentitiesOnly=yes -i ...로 예상 키를 강제로 사용하세요. 클라이언트가 올바른 키를 제공하고 서버가 이를 거부하면 서버에서 authorized_keys, 소유권 및 권한을 검사하세요. 키가 제공되지 않으면 로컬 ~/.ssh/config, 에이전트 또는 키 경로를 수정하세요. 연결이 인증에 도달하지 못하면 키 파일을 변경하는 대신 네트워크 문제 해결로 전환하세요.