DevOps 지식 허브
DevOps 지식 허브

SSH 연결 거부 오류를 신속하게 해결하기

SSH "연결 거부" 오류가 발생하면 원격 서버 관리가 중단될 수 있습니다. 이 종합 가이드는 서버 측의 주요 진단에 중점을 두고 단계별 문제 해결 방법을 자세히 설명합니다. SSH 데몬 상태 확인, 방화벽 규칙(UFW, firewalld) 검토 및 구성, `sshd_config` 설정 검사, 기본 네트워크 연결 테스트 활용 방법을 알아보십시오. 실용적인 명령과 실행 가능한 조언을 제공하여 문제를 신속하게 해결하고 시스템에 대한 안전한 액세스를 복원하여 즉시 제어권을 되찾을 수 있도록 합니다.

46 조회수

SSH 연결 거부 오류 신속하게 해결하기

SSH(Secure Shell)는 로컬 머신과 원격 서버 간의 안전하고 암호화된 통신을 가능하게 하는 원격 서버 관리의 근간입니다. 하지만, ssh: connect to host <IP_ADDRESS> port 22: Connection refused 오류를 마주하는 것은 중요한 시스템에 접근하는 것을 방해하는 좌절스러운 장애물이 될 수 있습니다.

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

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

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

'거부됨(refused)' 상태는 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 배포판(Ubuntu, CentOS 7+, Debian 8+와 같이 systemd를 사용하는 배포판)에서:
    bash sudo systemctl status sshd
    sshd가 실행 중이 아닌 경우, 출력에 inactive (dead) 또는 유사한 상태가 표시됩니다.

  2. SSH 데몬 시작:
    상태가 비활성화된 경우, 서비스를 시작해 봅니다:
    bash sudo systemctl start sshd

  3. 부팅 시 SSH 데몬 시작되도록 활성화:
    재부팅 후에도 SSH가 자동으로 시작되도록 하려면 활성화합니다:
    bash sudo systemctl enable sshd

  4. SSH 데몬 로그 확인:
    sshd가 시작되지 않으면 로그에서 중요한 단서를 얻을 수 있습니다. systemd 시스템의 경우:
    bash sudo journalctl -u sshd --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:
      bash sudo ufw status verbose
      port 22(또는 사용자 지정 SSH 포트)를 허용하는 규칙을 찾습니다. SSH가 나열된 경우 ALLOW인지 확인합니다.
    • firewalld:
      bash sudo firewall-cmd --list-all
      ssh 또는 port 22/tcp에 대한 services 및 ports 섹션을 확인합니다.
    • iptables:
      bash sudo iptables -L -v -n
      이 출력은 복잡할 수 있습니다. INPUT 체인에서 tcp dpt:22(또는 사용자 지정 포트)와 관련된 DROP 또는 REJECT 규칙을 찾습니다.

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

    • UFW:
      bash sudo ufw allow ssh # port 22 허용 # 또는, 사용자 지정 포트(예: 2222)의 경우: sudo ufw allow 2222/tcp sudo ufw enable # UFW가 비활성화된 경우
    • firewalld:
      bash sudo firewall-cmd --permanent --add-service=ssh # 또는, 사용자 지정 포트(예: 2222)의 경우: sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reload
    • iptables:
      iptables 규칙을 직접 추가하는 것은 복잡하고 영구적이지 않습니다(저장하지 않는 한). 사용 가능한 경우 firewalld 또는 ufw를 사용하는 것이 일반적으로 권장됩니다. 빠른 테스트(영구적이지 않음)의 경우:
      bash 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)로 파일을 엽니다:
    bash sudo nano /etc/ssh/sshd_config
    다음 지시문을 확인합니다:

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

    팁: sshd_config를 수정한 후에는 변경 사항을 적용하기 위해 SSH 서비스를 반드시 다시 시작해야 합니다:
    bash sudo systemctl restart sshd

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

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

  1. 서버 핑 테스트:
    클라이언트 머신에서 서버의 IP 주소 또는 호스트 이름을 핑 테스트합니다:
    bash ping <SERVER_IP_ADDRESS_OR_HOSTNAME>
    핑 테스트가 실패하면(패킷 손실률 100%), SSH를 시도하기 전에 해결해야 할 더 근본적인 네트워크 문제(예: 잘못된 IP, 서버 꺼짐, 네트워크 라우팅 문제)가 있는 것입니다.

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

    telnet 사용

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

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

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

  1. SELinux 상태 확인:
    bash sestatus
    SELinux가 enforcing인 경우, 사용자 지정 포트에서 sshd를 허용하도록 정책을 조정해야 할 수 있습니다.
    예를 들어, 포트 2222를 SSH에 허용하려면:
    bash sudo semanage port -a -t ssh_port_t -p tcp 2222 sudo systemctl restart sshd
    (Debian/Ubuntu에서 semanage가 없는 경우 설치: sudo apt install policycoreutils-python-utils, CentOS/RHEL에서: sudo yum install policycoreutils-python).

  2. AppArmor 상태 확인:
    bash 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 데몬 상태, 방화벽 규칙 및 sshd_config 파일을 체계적으로 확인하여 해결하는 경우가 많습니다. 이 가이드에 설명된 단계를 따르면 근본 원인을 효율적으로 진단하고 안전한 원격 액세스를 복원할 수 있습니다. 서버에 대한 액세스가 차단되는 것을 방지하기 위해 항상 변경 사항을 신중하게 적용하고 기능을 확인하십시오.

이러한 문제 해결 기술을 통해 SSH 연결 문제를 처리하고 원격 시스템에 대한 원활한 제어를 유지할 수 있는 충분한 준비를 갖추게 될 것입니다. 즐거운 SSH 사용 되시길 바랍니다!