DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

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

'연결 거부' 및 '권한 거부' 오류를 진단하여 실망스러운 SSH 연결 문제를 해결하세요. 이 실용적인 가이드는 sshd 서비스 상태 확인, 방화벽 규칙(UFW) 디버깅, 키 기반 인증 권한 수정, 신속한 해결을 위한 서버 인증 로그 해석 등 체계적인 문제 해결 단계를 자세히 설명합니다.

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

SSH 오류는 전송 문제와 인증 문제를 분리하면 더 쉽게 해결할 수 있습니다. 연결 거부는 SSH 클라이언트가 호스트에 도달했지만 해당 포트에서 TCP 연결을 수락하는 서비스가 없음을 의미합니다. 권한 거부는 SSH 서버가 응답했지만 로그인을 거부했음을 의미합니다. 둘 다 '접속할 수 없음'으로 느껴질 수 있지만, 서로 다른 문제입니다.

서버 설정을 변경하는 동안 하나의 활성 SSH 세션을 유지하세요. 가장 고통스러운 SSH 중단 사고는 /etc/ssh/sshd_config를 편집하고, 서비스를 재시작하고, 연결을 끊은 후에야 새 구성이 모든 로그인 경로를 차단한다는 것을 발견할 때 발생합니다.

오류 이해: 거부 vs. 거부됨

무엇이든 변경하기 전에 정확한 클라이언트 메시지를 읽으십시오:

  • 연결 거부: 호스트가 TCP 연결을 적극적으로 거부했습니다. 일반적으로 sshd가 해당 포트에서 수신 대기 중이지 않거나 방화벽이 차단하고 있기 때문입니다.
  • 연결 시간 초과: 패킷이 드롭되거나 네트워크 경로가 끊어졌습니다. 방화벽, 경로, VPN, 보안 그룹 또는 잘못된 IP 문제일 가능성이 더 높습니다.
  • 권한 거부 (publickey): 서버에 연결할 수 있지만 키를 수락하지 않았습니다.
  • 권한 거부 (publickey,password): 서버가 하나 이상의 인증 방법을 시도했지만 모두 거부했습니다.
  • 호스트 키 확인 실패: 클라이언트가 해당 호스트 이름 또는 IP에 대해 현재 제시된 서버 ID를 신뢰하지 않습니다.

1부: 연결 거부 문제 해결

ssh: connect to host example port 22: Connection refused는 일반적으로 원격 호스트 또는 포트를 가리킵니다. 시스템이 응답했지만 SSH가 해당 포트에서 연결을 수락하지 않았습니다.

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

거부의 가장 일반적인 원인은 SSH 서버 프로세스가 실행되고 있지 않거나 충돌했기 때문입니다.

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

많은 Linux 배포판에서 서비스 이름은 sshd이고, Debian 및 Ubuntu에서는 종종 ssh입니다. 시스템에 맞는 것을 사용하세요:

systemctl status sshd
systemctl status ssh

서비스가 비활성 상태이거나 실패한 경우 시작하세요:

sudo systemctl start sshd
sudo systemctl enable sshd

구성 변경 후 sshd가 시작되지 않으면 구성을 확인하세요:

sudo sshd -t

이 명령은 SSH를 다시 시작하기 전에 실행할 수 있는 가장 안전한 검사 중 하나입니다.

2. 수신 포트 및 구성 확인

기본적으로 SSH는 TCP 포트 22를 사용하지만 많은 서버가 다른 포트를 사용합니다. 서버가 2222에서 수신 대기하는 경우 클라이언트 명령에 이를 포함해야 합니다:

ssh -p 2222 [email protected]

A. sshd_config 검토

일반적으로 /etc/ssh/sshd_config에 있는 SSH 구성 파일을 살펴보십시오. Port 지시문을 찾으십시오:

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

파일을 편집한 후 다시 로드하기 전에 sudo sshd -t를 실행하십시오. 구문이 유효하면 서비스를 다시 로드하거나 다시 시작하십시오. 다시 로드하는 것이 일반적으로 덜 방해가 됩니다:

sudo systemctl reload sshd

B. 수신 소켓 확인

ss를 사용하여 sshd가 수신 대기 중인지 확인하십시오:

sudo ss -tuln | grep 22

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

SSH가 127.0.0.1:22에서만 수신 대기하는 경우 원격 클라이언트가 연결할 수 없습니다. 0.0.0.0:22 또는 특정 개인 인터페이스 주소에서 수신 대기하는 경우 방화벽 규칙에 따라 원격 액세스가 가능할 수 있습니다.

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

패킷을 드롭하는 방화벽은 일반적으로 시간 초과를 유발합니다. 패킷을 거부하는 방화벽은 거부를 유발할 수 있습니다. 호스트 방화벽과 호스트 외부의 네트워크 방화벽을 모두 확인하십시오.

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

SSH 트래픽이 허용되는지 확인하십시오:

# 현재 상태 확인
sudo ufw status

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

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

클라우드 보안 그룹, 네트워크 ACL, VPN 경로 및 사무실 방화벽은 트래픽이 서버에 도달하기 전에 SSH를 차단할 수 있습니다. sshd가 수신 대기 중이고 호스트 방화벽이 열려 있는 경우 동일한 개인 네트워크 내의 시스템에서 테스트하십시오. 이를 통해 문제가 서버 자체에 있는지 아니면 외부 경로에 있는지 알 수 있습니다.

2부: 권한 거부 문제 해결

서버가 Permission denied로 응답하면 네트워크 경로가 작동 중인 것입니다. 사용자 이름, 허용된 인증 방법, 키, 계정 상태 및 파일 권한에 집중하십시오.

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

이것은 가장 간단한 확인이지만 종종 간과됩니다:

  • 사용자 이름: 클라우드 이미지는 종종 ubuntu, ec2-user, admin, debian 또는 rocky와 같은 특정 사용자를 사용합니다. root는 비활성화될 수 있습니다.
  • 비밀번호: 비밀번호 인증이 활성화된 경우 오타, 계정 잠금, 만료된 비밀번호 및 PAM 규칙을 확인하십시오.
  • 포트 및 호스트: 놀랍게도 많은 인증 실패는 SSH가 실행 중인 잘못된 서버에 연결하여 발생합니다.

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

ssh -vvv user@hostname

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

2. 키 기반 인증 실패

키 인증은 클라이언트가 잘못된 개인 키를 제공하거나, 서버에 일치하는 공개 키가 없거나, 권한이 너무 열려 있거나, sshd_config가 로그인을 차단할 때 실패합니다.

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

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

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

# 사용자 홈 디렉토리 권한은 일반적으로 괜찮지만 .ssh 폴더를 확인하십시오.
chmod 700 ~/.ssh

# authorized_keys 파일은 소유자만 쓸 수 있어야 합니다.
chmod 600 ~/.ssh/authorized_keys

소유권도 확인하십시오:

chown -R "$USER:$USER" ~/.ssh

서버에서 StrictModes가 일반적으로 활성화되어 있습니다. 홈 디렉토리, .ssh 디렉토리 또는 authorized_keys 파일을 다른 사용자가 쓸 수 있는 경우 sshd가 키를 무시할 수 있습니다.

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

공개 키가 대상 사용자의 ~/.ssh/authorized_keys에 한 줄에 하나의 키로 있는지 확인하십시오. 개인 키는 클라이언트에 남아 있습니다. 개인 키를 authorized_keys에 붙여넣지 마십시오.

클라이언트에서 디버깅하는 동안 특정 키를 강제로 사용하십시오:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

자세한 출력에서 어떤 키가 제공되었고 서버가 이를 수락하거나 거부한 이유를 보여주는 줄을 찾으십시오.

C. 키를 비활성화하는 서버 구성

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

PubkeyAuthentication yes

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

AllowUsers, AllowGroups, DenyUsers 또는 DenyGroups가 있는 경우 유효한 키 설정처럼 보이는 것을 재정의할 수 있습니다. 올바른 키를 가진 사용자도 이러한 지시문에 의해 차단될 수 있습니다.

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

systemd 저널링이 있는 시스템에서는 종종 더 쉽습니다:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

로그 메시지에는 "bad ownership or modes", "user not allowed", "invalid user", "authentication refused" 또는 PAM 계정 실패가 표시될 수 있습니다. 이러한 메시지는 클라이언트 측에서 추측하는 것보다 더 신뢰할 수 있습니다.

호스트 키 확인 실패

Host key verification failed는 잘못된 비밀번호나 키와 동일하지 않습니다. 이는 클라이언트가 해당 호스트 이름 또는 IP에 대해 저장된 서버 ID를 가지고 있고 서버가 이제 다른 ID를 제시하고 있음을 의미합니다. 이는 재구축, IP 재사용, 로드 밸런서 변경 또는 실제 중간자 공격 위험 후에 발생할 수 있습니다.

프로덕션 환경에서 경고를 무턱대고 삭제하지 마십시오. 클라우드 콘솔, 구성 관리 또는 기존 신뢰할 수 있는 채널을 통해 서버 지문을 확인하십시오. 변경이 예상된 것임을 확인한 후 이전 항목을 제거하십시오:

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

그런 다음 다시 연결하고 지문이 예상과 일치하는 경우에만 새 호스트 키를 수락하십시오.

안정적인 SSH 액세스를 위한 모범 사례 요약

  1. 키 쌍 사용: 두 번째 세션에서 키 액세스를 테스트한 후에만 비밀번호 인증을 비활성화하십시오.
  2. 로그인 가능한 사용자 제한: 적절한 경우 AllowUsers 또는 AllowGroups를 사용하되 문서화하여 향후 운영자가 잘못된 권한 문제를 쫓지 않도록 하십시오.
  3. PermitRootLogin no 사용: sudo가 있는 일반 사용자를 선호하십시오.
  4. 구성 백업: /etc/ssh/sshd_config를 변경하기 전에 복사하십시오:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. 다시 로드하기 전에 확인: sudo sshd -t를 실행하십시오. 6. 비상 경로 유지: 클라우드 서버의 경우 SSH가 중단될 경우 직렬 콘솔, 복구 모드, 인스턴스 연결 기능 또는 구성 관리를 사용하는 방법을 알고 있어야 합니다.

SSH 문제 해결의 가장 빠른 방법은 정확한 오류를 식별하고, 서버가 수신 대기 중인지 확인하고, 네트워크 경로가 해당 포트에 도달하는지 확인한 다음 인증 실패에 대한 서버 로그를 읽는 것입니다. 추측하는 것은 일반적으로 이러한 검사를 순서대로 실행하는 것보다 시간이 더 오래 걸립니다.