일반적인 SSH 오류 문제 해결: 연결 거부됨 및 권한 거부됨

SSH(Secure Shell)는 원격 시스템 관리의 기반이며, 서버에 접근하기 위한 암호화된 통신을 제공합니다. 그러나 연결 오류가 발생하면 즉시 생산성이 저하될 수 있습니다. 사용자들이 직면하는 가장 흔하고 답답한 두 가지 오류는 "Connection Refused"(연결 거부됨)와 "Permission Denied"(권한 거부됨)입니다.

이 가이드에서는 이러한 문제를 진단하고 해결하기 위한 체계적인 접근 방식을 안내합니다. 네트워크 방해부터 잘못된 인증 구성에 이르는 일반적인 원인을 이해함으로써 원격 시스템에 대한 보안 접근을 신속하게 복구할 수 있습니다. 서버 상태 확인부터 인증 메커니즘 디버깅에 이르기까지 필수적인 점검 사항을 다룰 것입니다.

오류 이해: 거부됨(Refused) vs. 거부됨(Denied)

두 가지 주요 오류 메시지를 구별하는 것이 중요합니다. 왜냐하면 각각 매우 다른 근본 원인을 가리키기 때문입니다:

연결 거부됨(Connection Refused): 이는 일반적으로 네트워크 연결이 서버에 도달했지만, 지정된 포트에서 아무것도 수신 대기하고 있지 않거나 운영 체제가 연결 시도를 적극적으로 거부했음을 의미합니다.
권한 거부됨(Permission Denied): 이는 SSH 서비스(sshd)가 연결 요청을 성공적으로 수신했지만, 서버 구성에 따라 인증 시도(암호 또는 키)가 실패했음을 의미합니다.

1부: 연결 거부됨(Connection Refused) 문제 해결

"Connection Refused"(종종 ssh: connect to host <hostname> port 22: Connection refused와 같이 표시됨)는 일반적으로 데몬이 수신 연결을 허용하지 못하게 하는 서버 측 문제를 나타냅니다.

1. SSH 데몬(sshd) 상태 확인

거부의 가장 흔한 원인은 SSH 서버 프로세스가 실행되고 있지 않거나 충돌한 경우입니다.

실행 가능한 단계 (원격 서버에서):

systemctl(최신 Linux 배포판에서 일반적)을 사용하여 서비스 상태를 확인합니다:

systemctl status sshd

상태가 inactive 또는 failed로 표시되면 서비스를 시작합니다:

sudo systemctl start sshd
# 부팅 시 자동으로 시작하도록 활성화
sudo systemctl enable sshd

2. 수신 대기 포트 및 구성 확인

기본적으로 SSH는 TCP 포트 22에서 실행됩니다. 보안 강화를 위해 포트가 변경된 경우, 연결 시 올바른 포트를 지정하거나 서버가 예상 포트에서 수신 대기하고 있는지 확인해야 합니다.

A. `sshd_config` 검토

일반적으로 /etc/ssh/sshd_config에 있는 SSH 구성 파일을 검토합니다. Port 지시문을 찾습니다:

# /etc/ssh/sshd_config 예시
Port 2222  # 이 값이 22가 아닌 경우, 클라이언트 측에서 지정해야 합니다.

이 파일을 변경하는 경우, 변경 사항을 적용하려면 sshd 서비스를 반드시 다시 시작해야 합니다.

B. 수신 대기 소켓 확인

sshd가 예상 인터페이스와 포트에서 활발하게 수신 대기하고 있는지 확인하려면 ss 또는 netstat을 사용하십시오. 여기서는 포트 22를 확인합니다:

# ss 사용 (최신 시스템에서 선호됨)
sudo ss -tuln | grep 22

# 수신 대기 상태를 보여주는 예상 출력:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

포트 22에 대해 아무것도 나타나지 않으면 데몬이 실행되고 있지 않거나 다른 주소/포트에서 수신 대기하도록 구성된 것입니다.

3. 방화벽 및 네트워크 확인

sshd 프로세스에 도달하기 전에 트래픽을 차단하는 방화벽은 종종 타임아웃을 유발하지만, 때로는 거부로 나타날 수도 있습니다. 서버 측 방화벽 규칙을 확인하는 것이 중요합니다.

일반적인 방화벽 명령 (Ubuntu/Debian의 UFW):

SSH 트래픽이 허용되는지 확인합니다:

# 현재 상태 확인
sudo ufw status

# 기본 포트 22에서 트래픽 허용
sudo ufw allow ssh
# 또는 포트 번호로
sudo ufw allow 22/tcp

# 방화벽 규칙 다시 로드
sudo ufw reload

⚠️ 외부 방화벽 경고: 원격 네트워크에서 연결하는 경우, 중간 네트워크 장치, 클라우드 보안 그룹(예: AWS 보안 그룹 또는 Azure NSG) 또는 하드웨어 방화벽이 SSH 포트의 트래픽을 명시적으로 허용하는지 확인하십시오.

2부: 권한 거부됨(Permission Denied) 문제 해결

서버에 성공적으로 연결했지만 즉시 "Permission denied (publickey,password)" 메시지를 받는다면, 문제는 전적으로 인증에 있습니다.

1. 사용자 이름과 비밀번호 확인

이것은 가장 간단하지만 종종 간과되는 확인 사항입니다:

사용자 이름: 대상 시스템에 올바른 사용자 이름을 사용하고 있습니까? 루트 로그인이 비활성화되어 있을 수 있습니다.
비밀번호: 비밀번호 인증을 사용하는 경우, Caps Lock, 오타를 확인하고 계정이 잠겨 있지 않은지 확인하십시오.

클라이언트 측 확인: 자세한 디버그 출력을 보려면 클라이언트를 상세(verbose) 플래그와 함께 실행하십시오:

ssh -vvv user@hostname

이 출력은 클라이언트가 시도한 인증 방법과 서버가 거부한 방법을 명확하게 보여줄 것입니다.

2. 키 기반 인증 실패

키 기반 인증이 더 우수하지만, 구성 오류는 거부의 빈번한 원인입니다.

A. `.ssh` 디렉터리의 잘못된 권한

SSH는 보안을 위해 파일 권한에 대해 매우 엄격합니다. 권한이 너무 개방적이면 서버는 키 파일을 완전히 무시합니다.

원격 서버에서 (권한 수정):

# 사용자 홈 디렉터리 권한은 일반적으로 괜찮지만, .ssh 폴더를 확인합니다.
chmod 700 ~/.ssh

# authorized_keys 파일은 소유자만 쓰기 가능해야 합니다.
chmod 600 ~/.ssh/authorized_keys

B. 키가 없거나 형식이 잘못된 경우

공개 키(id_rsa.pub 또는 유사한 파일)가 대상 사용자의 서버 ~/.ssh/authorized_keys 파일에 올바르게 추가되었는지 확인하십시오. 각 키는 키 문자열 중간에 줄 바꿈 없이 자체 줄에 있어야 합니다.

C. 서버 구성에서 키 비활성화

서버의 /etc/ssh/sshd_config에서 키 인증이 허용되는지 확인하십시오:

PubkeyAuthentication yes

# 비밀번호에 의존하는 경우 비밀번호 인증이 비활성화되지 않았는지 확인합니다.
PasswordAuthentication yes

3. 서버 측 로그 조사

인증이 실패할 경우, 서버 로그는 진실을 알려주는 궁극적인 정보원입니다. 실패한 로그인 시도와 관련된 메시지를 찾아보십시오.

일반적인 로그 위치:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

grep을 사용하여 최근 연결 시도를 필터링합니다:

# RHEL/CentOS 시스템에서
sudo grep 'Failed password' /var/log/secure

# 또는 일반적인 SSH 활동을 확인합니다.
sudo tail -f /var/log/secure

로그 메시지는 종종 키가 거부된 이유를 명시적으로 나타냅니다(예: 잘못된 옵션, 일치하는 키 없음 또는 잘못된 사용자 컨텍스트).

안정적인 SSH 접근을 위한 모범 사례 요약

키 쌍 사용: 키 접근이 확인되면 sshd_config에서 비밀번호 인증(PasswordAuthentication no)을 비활성화합니다.
기본 포트 변경: SSH를 포트 22에서 이동하면 자동 스캔 노이즈가 줄어듭니다.
PermitRootLogin no 사용: 표준 사용자를 통한 관리 접근을 강제하고, sudo 사용을 강제합니다.
구성 백업: /etc/ssh/sshd_config에 중요한 변경을 하기 전에 항상 원본 파일을 백업하십시오:
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
로컬에서 테스트: 구성 변경 후, 활성 세션 연결을 끊기 전에 서버에서 로컬로 연결을 테스트하십시오(가능한 경우) 자가 잠김을 피하기 위해서입니다.

서비스 상태, 네트워크 경로 및 인증 구성 계층을 체계적으로 확인함으로써 원격 접근 관리에서 발생하는 답답한 Connection Refused 및 Permission Denied 오류를 신속하게 해결할 수 있습니다.