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

SSH 연결 거부 오류 빠르게 해결하기

sshd 상태, 포트, 방화벽 규칙, sshd_config, SELinux 및 서버 로그를 확인하여 SSH 연결 거부 오류를 해결하세요.

SSH 연결 거부 오류 빠르게 해결하기

SSH(Secure Shell)는 원격 서버 관리의 핵심으로, 로컬 머신과 원격 서버 간의 안전하고 암호화된 통신을 가능하게 합니다. 그러나 ssh: connect to host <IP_ADDRESS> port 22: Connection refused 오류가 발생하면 중요한 시스템에 접근하지 못하는 좌절스러운 장애물이 될 수 있습니다.

이 글은 일반적인 '연결 거부' 오류를 진단하고 해결하기 위한 포괄적인 단계별 가이드를 제공합니다. 비활성화된 SSH 데몬부터 잘못 구성된 방화벽 및 잘못된 서버 설정까지 주요 원인을 탐구하여 신속하게 서버에 다시 접근할 수 있는 지식과 명령어를 제공합니다.

'연결 거부' 오류 이해하기

Connection refused 오류가 발생하면 SSH 클라이언트가 원격 서버에 성공적으로 도달했지만 서버가 지정된 포트에서 연결을 명시적으로 거부했음을 의미합니다. 이는 클라이언트가 서버에 전혀 도달할 수 없는 Connection timed out 오류나 네트워크 경로가 끊어진 No route to host 오류와는 다릅니다.

'거부' 상태는 SSH 서비스가 연결을 수락하지 못하도록 적극적으로 방해하는 서버 측 문제를 직접적으로 가리킵니다. 일반적으로 SSH 데몬이 실행되지 않거나, 방화벽이 연결을 차단하거나, SSH 서비스 자체의 구성 오류가 포함됩니다.

'연결 거부'의 일반적인 원인

여러 요인이 SSH 연결 거부로 이어질 수 있습니다. 이를 이해하면 문제 해결 과정을 좁히는 데 도움이 됩니다.

  • SSH 데몬(sshd)이 실행되지 않음: 가장 일반적인 원인입니다. SSH 서버 프로세스가 충돌하거나 중지되었거나 부팅 시 시작되지 않았을 수 있습니다.
  • 방화벽이 포트 22(또는 사용자 지정 포트) 차단: 서버 방화벽(예: UFW, firewalld, iptables)이 SSH 포트로 들어오는 연결을 차단하고 있습니다.
  • SSH 데몬 구성 오류: sshd_config 파일이 잘못 구성되어 SSH 데몬이 다른 포트, 잘못된 네트워크 인터페이스에서 수신 대기하거나 특정 사용자/방법에 대한 연결을 거부할 수 있습니다.
  • 네트워크 연결 문제('거부'의 경우 덜 일반적): '거부' 오류의 가능성은 낮지만 근본적인 네트워크 문제가 예기치 않게 나타날 수 있습니다.
  • SELinux 또는 AppArmor 제한: SELinux 또는 AppArmor와 같은 보안 강화 기능이 특히 사용자 지정 구성 또는 시스템 변경 후에 sshd가 올바르게 작동하지 못하도록 방해할 수 있습니다.

단계별 문제 해결 가이드

'연결 거부' 오류를 진단하고 해결하기 위한 실용적인 단계를 살펴보겠습니다.

1단계: 서버에서 SSH 데몬 상태 확인

가장 먼저 확인해야 할 것은 원격 머신에서 SSH 서버 데몬(sshd)이 실제로 실행 중인지 여부입니다. SSH에 완전히 접근할 수 없는 경우 이러한 확인을 수행하려면 일반적으로 콘솔 액세스(예: 클라우드 제공업체의 콘솔 또는 물리적 연결)가 필요합니다.

  1. SSH 데몬 상태 확인: 대부분의 최신 Linux 배포판(systemd를 사용하는 Ubuntu, CentOS 7+, Debian 8+ 등)에서:
    sudo systemctl status sshd

Debian/Ubuntu에서는 서비스 이름이 ssh일 수 있습니다:

sudo systemctl status ssh ``` sshd가 실행 중이 아니면 출력에 inactive (dead) 또는 유사한 상태가 표시됩니다.

  1. SSH 데몬 시작: 상태가 비활성인 경우 서비스를 시작해 보십시오:
    sudo systemctl start sshd

또는 Debian/Ubuntu:

sudo systemctl start ssh ```

  1. 부팅 시 SSH 데몬이 시작되도록 활성화: 재부팅 후 SSH가 자동으로 시작되도록 하려면 활성화하십시오:
    sudo systemctl enable sshd

또는 Debian/Ubuntu:

sudo systemctl enable ssh ```

  1. SSH 데몬 로그 확인: sshd가 시작되지 않으면 로그에서 중요한 단서를 제공할 수 있습니다. systemd 시스템의 경우:
    sudo journalctl -u sshd --since "10 minutes ago"

또는 배포판에서 ssh 유닛을 사용하는 경우:

sudo journalctl -u ssh --since "10 minutes ago" 또는 일반 인증 로그를 확인하십시오: bash sudo tail -f /var/log/auth.log # 또는 RHEL/CentOS: sudo tail -f /var/log/secure ```

2단계: 방화벽 규칙 확인

서버 측 방화벽이 연결 거부의 원인인 경우가 많습니다. 기본 SSH 포트(22) 또는 사용하려는 사용자 지정 포트를 차단하고 있을 수 있습니다. 방화벽이 SSH 포트로 들어오는 연결을 허용하는지 확인해야 합니다.

  1. 방화벽 식별: 일반적인 방화벽은 다음과 같습니다:

    • UFW(Uncomplicated Firewall): Ubuntu/Debian에서 일반적입니다.
    • firewalld: CentOS/RHEL 7+에서 일반적입니다.
    • iptables: Linux의 기본 방화벽으로, 직접 또는 프런트 엔드를 통해 구성됩니다.

  2. 방화벽 상태 및 규칙 확인:

    • UFW:
      sudo ufw status verbose
      port 22(또는 사용자 지정 SSH 포트)에 대한 트래픽을 허용하는 규칙을 찾으십시오. SSH가 나열되면 ALLOW되었는지 확인하십시오.
    • firewalld:
      sudo firewall-cmd --list-all
      services 및 ports 섹션에서 ssh 또는 port 22/tcp를 확인하십시오.
    • iptables:
      sudo iptables -L -v -n
      이 출력은 복잡할 수 있습니다. INPUT 체인에서 tcp dpt:22(또는 사용자 지정 포트)와 관련된 DROP 또는 REJECT 규칙을 찾으십시오.

  3. 방화벽을 통해 SSH 포트 허용:

    • UFW:
      sudo ufw allow ssh        # 포트 22 허용
# 또는 사용자 지정 포트(예: 2222)의 경우:
sudo ufw allow 2222/tcp
sudo ufw enable           # UFW가 비활성화된 경우
    • firewalld:
      sudo firewall-cmd --permanent --add-service=ssh
# 또는 사용자 지정 포트(예: 2222)의 경우:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
    • iptables: iptables 규칙을 직접 추가하는 것은 저장하지 않으면 더 복잡하고 일시적입니다. 가능하면 firewalld 또는 ufw를 사용하는 것이 좋습니다. 빠른 테스트(영구적이지 않음)의 경우:
      sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 재부팅 후에도 유지하려면 이러한 규칙을 저장해야 합니다.

    경고: 특히 원격 서버에 SSH로 연결할 때 방화벽 규칙을 수정할 때는 주의하십시오. 잘못된 규칙으로 인해 영구적으로 잠길 수 있습니다. 열려 있는 SSH 세션이 있는 경우 새 로그인이 성공할 때까지 현재 세션을 닫기 전에 변경 사항이 작동하는지 항상 확인하십시오.

3단계: SSH 구성 확인(sshd_config)

SSH 데몬의 구성 파일(/etc/ssh/sshd_config)은 서비스 작동 방식을 결정합니다. 여기서 잘못 구성하면 연결이 거부될 수 있습니다.

  1. sshd_config 찾기: 기본 구성 파일은 일반적으로 /etc/ssh/sshd_config에 있습니다.

  2. 주요 설정 검사: 텍스트 편집기(예: nano, vi)로 파일을 엽니다:

    sudo nano /etc/ssh/sshd_config

    다음 지시문을 찾으십시오:

    • Port: sshd가 수신 대기하는 포트를 지정합니다. 클라이언트에서 연결하려는 포트와 일치하는지 확인하십시오. 주석 처리된 경우(#) 기본값은 포트 22입니다.
    • ListenAddress: 있는 경우 sshd가 수신 대기해야 하는 IP 주소를 지정합니다. 내부 IP(예: 127.0.0.1)로 설정되고 외부 네트워크에서 연결하는 경우 연결을 거부합니다. 모든 인터페이스에서 수신 대기하려면 일반적으로 주석 처리되거나 0.0.0.0 또는 ::(IPv6의 경우)로 설정됩니다.
    • PermitRootLogin: no로 설정하면 root로 로그인할 수 없습니다. 엄밀히 말해 '연결 거부'는 아니지만(종종 연결 후 권한 거부), 성공적인 로그인 시도를 방해할 수 있습니다.
    • PasswordAuthentication: no로 설정하면 암호 인증이 비활성화되어 키 기반 인증이 필요합니다.

    팁: sshd_config를 변경한 후에는 변경 사항을 적용하려면 SSH 서비스를 반드시 다시 시작해야 합니다:

    sudo systemctl restart sshd

4단계: 네트워크 연결(기본 확인)

'연결 거부'는 일반적으로 서버에 도달했음을 의미하지만 클라이언트 머신에서 서버 IP 주소로의 기본 네트워크 연결 가능성을 빠르게 확인하는 것이 좋습니다.

  1. 서버 핑: 클라이언트 머신에서 서버의 IP 주소 또는 호스트 이름을 핑해 보십시오:

    ping <SERVER_IP_ADDRESS_OR_HOSTNAME>

    핑이 실패하면(100% 패킷 손실) SSH보다 먼저 해결해야 하는 더 근본적인 네트워크 문제(예: 잘못된 IP, 서버 오프라인, 네트워크 라우팅 문제)가 있는 것입니다.

  2. nc 또는 telnet 사용(클라이언트에서): 클라이언트 관점에서 포트가 열려 있고 수신 대기 중인지 테스트하려면:

    # netcat(nc) 사용
nc -zv <SERVER_IP_ADDRESS> 22

# telnet 사용
telnet <SERVER_IP_ADDRESS> 22

    nc에 Connection refused가 표시되거나 telnet이 즉시 종료되면 서버가 해당 포트에서 적극적으로 거부하고 있음을 확인하며 이는 SSH 데몬 또는 방화벽을 가리킵니다.

5단계: SELinux 또는 AppArmor 확인(고급)

일부 강화된 환경이나 사용자 지정 구성 후에는 SELinux(Security-Enhanced Linux) 또는 AppArmor가 특히 비표준 SSH 포트를 사용하는 경우 sshd가 올바르게 작동하지 못하도록 방해할 수 있습니다.

  1. SELinux 상태 확인:

    sestatus

    SELinux가 enforcing인 경우 사용자 지정 포트에서 sshd를 허용하도록 정책을 조정해야 할 수 있습니다. 예를 들어 SSH에 포트 2222를 허용하려면:

    sudo semanage port -a -t ssh_port_t -p tcp 2222
sudo systemctl restart sshd

    (semanage가 없으면 설치: Debian/Ubuntu에서 sudo apt install policycoreutils-python-utils, RHEL 계열 릴리스에 해당하는 패키지 sudo yum install policycoreutils-python-utils)

  2. AppArmor 상태 확인:

    sudo aa status

    AppArmor가 enforcing인 경우 sshd와 관련된 거부에 대한 로그(/var/log/syslog 또는 dmesg)를 검토하십시오.

6단계: 서버 로그 다시 검토

이전 단계를 시도한 후에는 항상 sshd와 관련된 새로운 오류 메시지가 있는지 서버 로그를 다시 확인하십시오. 이것이 서버가 경험하는 상황에 대한 궁극적인 정보 출처입니다.

  • sudo journalctl -u sshd
  • sudo tail -f /var/log/auth.log (또는 /var/log/secure)

서비스가 시작되지 않는 이유, 연결이 끊어지는 이유 또는 기타 관련 정보를 나타내는 메시지를 찾으십시오.

향후 문제를 방지하기 위한 모범 사례

  • OS를 정기적으로 업데이트하십시오: 서버의 운영 체제와 openssh-server를 포함한 패키지를 최신 상태로 유지하십시오.
  • 방화벽 규칙 테스트: 방화벽 규칙을 구현하거나 수정한 후에는 즉시 테스트하십시오.
  • sshd_config 백업: /etc/ssh/sshd_config를 변경하기 전에 백업을 만드십시오(sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • 관리 콘솔 사용: 클라우드 인스턴스의 경우 SSH를 사용할 수 없을 때 네트워크 문제를 해결하기 위해 서버 콘솔(예: AWS EC2 직렬 콘솔, Google Cloud 콘솔)에 액세스하는 방법을 알아두십시오.
  • 로그 모니터링: 비정상적인 활동이나 지속적인 오류가 있는지 auth.log 또는 secure 로그를 정기적으로 검토하십시오.

최종 요점

SSH 연결 거부 오류는 일반적으로 서버에 연결할 수 있지만 해당 포트에서 연결을 수락하는 항목이 없음을 의미합니다. 배포판의 SSH 서비스 이름을 확인하고, 포트가 수신 대기 중인지 확인하고, 방화벽을 열고, sshd_config의 유효성을 검사하고, 더 큰 변경을 하기 전에 로그를 읽으십시오. 여전히 작동 중인 세션이 하나 열려 있으면 새 로그인이 성공할 때까지 해당 세션을 열어 두십시오.