PuTTY 연결 거부: 문제 수정

PuTTY에서 « Network error: Connection refused » 메시지는 TCP 연결을 열 수 없음을 나타냅니다. 클라이언트는 아직 비밀번호나 SSH 키 단계에 도달하지 않았습니다. 거부는 대상 컴퓨터에서 발신될 수 있지만 방화벽, 게이트웨이 또는 잘못 구성된 리디렉션에서도 발생할 수 있습니다: 따라서 이 메시지만으로는 올바른 서버가 응답했는지 단정할 수 없습니다.

클라이언트에서 서버로 진행하세요 : 대상 주소를 확인하고, 포트를 검증한 다음, 독립적인 콘솔에서 청취 및 필터링을 검사하세요. 서버를 재시작하거나 « 시도 »하기 위해 방화벽을 수정하지 마세요. 비상 콘솔이나 이미 열린 접근이 없다면, 서버 측 수정 전에 멈추고 관리자에게 도움을 요청하세요.

TCP 거부인지 확인하세요

PuTTY에서 표시된 정확한 텍스트, 시도 시간 및 사용된 세션을 기록하세요. PuTTY 창 메뉴에서 이벤트 로그를 열고, 호스트, 포트 및 프록시 여부를 확인하세요. 내부 이름과 주소는 이 정보를 전달하기 전에 숨기세요. PuTTY 매뉴얼은 Connection refused와 Connection timed out를 명확히 구분합니다.

• Connection refused : TCP 시도가 거부를 받고, 종종 RST 패킷이 반환됩니다. 거부는 호스트에서 발신되거나 거부하도록 설정된 중간 장비에서 발생할 수 있습니다.
• Connection timed out : 유용한 응답이 시간 내에 도착하지 않습니다. DROP 유형의 조용한 필터링, 경로, 잘못된 주소 또는 사용 불가능한 장비가 이 결과로 이어질 수 있습니다. 이는 같은 진단이 아니며; 타임아웃 세부 사항은 별도의 가이드에 할당됩니다.
• Server refused our key : SSH 연결이 키 인증 단계에 도달했지만, 서버가 이 계정에 대해 해당 키를 허용하지 않습니다. 키와 계정 설정을 확인하세요; PuTTY에서 SSH 키를 사용하는 방법에 대한 가이드를 참조하세요. 키를 변경해도 초기 TCP 거부는 해결되지 않습니다.

핑은 판단에 도움이 되지 않습니다: ICMP 및 SSH의 TCP 포트는 다르게 필터링될 수 있습니다. 응답이 없는 핑은 SSH가 다운되었다는 것을 증명하지 않으며, 성공적인 핑은 SSH 포트를 검증하지 않습니다.

PuTTY에서 호스트와 포트를 확인하세요

PuTTY에서 해당 세션을 로드하고, 호스팅 업체 또는 관리자에서 제공한 정보와 필드를 비교하세요: Host Name은 이름이나 주소를 포함해야 하며, https:// 접두사는 포함하지 않아야 합니다; 연결 유형은 SSH여야 합니다; 포트는 실제 게시된 SSH 포어야 합니다. 항상 포트 22일 것이라고 가정하지 마세요. 값을 수정하는 경우, 올바른 대상을 확인한 후 세션을 저장하세요. 세션의 기본 설정에 대해서는 PuTTY 세션 설정 확인하기 가이드를 참조하세요.

Windows PowerShell에서 예제 이름과 포트를 세션의 것으로 교체하세요:

Resolve-DnsName serveur.example.net
Test-NetConnection -ComputerName serveur.example.net -Port 22 -InformationLevel Detailed

Resolve-DnsName는 이름에 연관된 주소를 표시합니다; 예상되는 대상으로 비교하세요. Test-NetConnection은 지정된 TCP 포트를 테스트합니다: TcpTestSucceeded : True는 이 테스트가 TCP 연결을 확립했음을 의미하며, 이는 서버의 신원이나 SSH 인증이 검증되었음을 의미하지는 않습니다. False 값은 거부와 타임아웃을 구분하는 데 충분하지 않습니다: PuTTY에서 정확한 메시지를 보존하세요. PuTTY가 프록시 또는 VPN을 경유하면 직접 테스트가 다른 경로를 사용할 수 있으며; 두 결과는 직접 비교할 수 없습니다.

사용할 수 있는 Linux 클라이언트에서 netcat이 설치된 경우, 특정 포트를 테스트할 수 있습니다:

nc -vz -w 3 serveur.example.net 22

두 값을 교체하세요. -z 및 -v 옵션은 애플리케이션 교환 없이 연결 테스트와 읽을 수 있는 결과를 요청하며; -w 3는 기다림을 3초로 제한합니다. netcat의 변형은 다를 수 있으므로, 옵션이 인식되지 않는 경우 nc -h를 참조하고, 설치된 버전에 맞게 조정하세요, 포트 범위를 테스트하지 마세요. 연결이 설정되면 해당 클라이언트에서 TCP 접근이 확인되고; 거부는 거부 추적을 지원합니다; 시간 초과가 발생하면 다른 진단 경로를 열게 됩니다. netcat으로 TCP 포트 테스트하기 가이드도 참조하세요.

Linux 콘솔에서 서비스 확인하기

이 단계는 호스팅 업체의 콘솔, 가상 머신 또는 서버 앞에서 수행되어야 하며, 실패한 PuTTY 세션에서는 수행하지 않아야 합니다. 이 콘솔과 이미 열려 있는 모든 관리자 세션을 유지하세요: 이는 수정이 접근을 차단할 경우 복구 수단이 됩니다. 장치 이름은 배포판 및 시작 모드에 따라 다릅니다.

systemctl list-unit-files 'ssh*' --no-pager
sudo systemctl status ssh.service --no-pager
sudo systemctl status sshd.service --no-pager
sudo systemctl status ssh.socket --no-pager

첫 번째 명령은 ssh로 시작하는 유닛을 나열합니다. 다음으로 실제 존재하는 유닛을 확인하세요: ssh.service는 Debian 및 Ubuntu에서 일반적이며; sshd.service는 Fedora 및 RHEL에서 자주 사용됩니다; 일부 시스템에서는 ssh.socket으로 활성화 됩니다. « Unit not found »는 단순히 이 유닛 이름이 이 머신에 존재하지 않음을 나타냅니다. 활성 유닛은 요청된 포트가 올바른 인터페이스에서 청취하고 있다는 것을 증명하지 않습니다. 소켓을 통한 활성화에서는 systemd가 연결을 수락하고 요청에 따라 서비스를 시작할 수 있습니다. systemd가 없는 시스템에서는 이러한 명령을 이 배포판의 도구로 사용하세요.

SSH 서버가 설치되어 있지 않다면, 먼저 관리자에게 이 머신이 실제로 SSH를 제공해야하는지 확인하세요. 서버 패키지를 설치하는 것은 이 경우에만 그리고 배포판 절차에 따라 정당화됩니다; 이는 잘못된 포트나 네트워크 거부의 보편적인 수정이 아닙니다.

유효한 듣기 주소와 포트를 확인하세요

여전히 Linux 콘솔에서, 인터페이스, 청취 중인 TCP 소켓 및 SSH 구성을 관찰하세요:

ip -br address
sudo ss -ltnp
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address는 로컬 주소를 보여줍니다; NAT 뒤에 있는 서버는 일반적으로 공용 주소를 표시하지 않습니다. ss -ltnp에서, -l은 청취 중인 소켓으로 출력 제한을 두고, -t는 TCP로, -n은 숫자 포트를 유지하며, -p는 프로세스가 이용할 수 있는 경우 표시합니다. 예상 포트와 소유 프로세스를 찾으세요; 소켓이 활성화되어 있으면 시스템이 systemd가 될 수 있습니다.

주소는 포트만큼 중요합니다. 127.0.0.1:22에서의 청취는 로컬 루프에 한정되며; 정확한 LAN 주소는 다른 인터페이스를 포함하지 않습니다. 0.0.0.0은 모든 IPv4 인터페이스를 나타내며; [::]에서의 청취는 IPv6에 해당하며, 단독으로는 IPv4 접근을 보장하지 않습니다. 트래픽이 도착하는 포트에서 아무것도 청취하지 않는다면, 방화벽을 여는 것으로 시작하지 마세요: 이 경우 해당 목적지에서 서비스가 전혀 없습니다.

sshd -t는 서비스 시작 또는 재시작 없이 구문 및 호스트 키를 확인합니다. 유효한 실행은 일반적으로 메시지를 생성하지 않으며 성공 코드를 반환합니다; 오류 메시지는 서비스에 대한 조치를 취하기 전에 수정해야 합니다. sshd -T는 읽기 및 검증 후 실제 구성을 표시하며, 특히 포트 및 청취 주소 값을 포함합니다. 민감한 세부정보를 숨기고 전체 출력을 공유하지 마세요. 공식 매뉴얼은 sshd(8) 옵션 및 포트 및 ListenAddress 지시문을 설명합니다. 이러한 페이지는 OpenSSH에 대한 문서를 포함하며; 경로 및 유닛은 배포판에 따라 다릅니다. ssh.socket을 사용하는 구성에서 ss의 결과를 활성 유닛에 비교하세요: sshd -T의 출력만으로는 systemd가 실제로 노출되는 내용을 증명하지 않습니다.

Port 또는 ListenAddress는 잘못된 설정을 식별하고 관련 구성을 백업한 후에만 수정하세요. 어떤 인터페이스에 접근할 수 있어야 하는지 확인하고; 기본적으로 모든 인터페이스에 청취를 확대하지 마세요. 모든 수정이나 재로드 전에 비상 콘솔과 기존 접근이 열려 있는 상태를 유지하세요. Ubuntu는 OpenSSH Server 문서에서 서버 구성과 관련된 주의 사항을 상기시킵니다.

로컬 필터링, 네트워크 및 NAT 비교하기

포트가 올바른 인터페이스에서 청취하고 있지만 외부 테스트가 거부되면, 실제로 사용되고 있는 방화벽 관리자를 식별하고 트래픽 경로를 확인하세요. 아래 명령어들은 읽기 전용입니다: 당신의 시스템에 맞는 것만 실행하세요.

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

UFW, nftables 및 firewalld는 상호 교환할 수 없습니다. 명령어가 없어도 필터링이 전혀 없다는 것을 의미하지 않습니다. firewalld에서 public는 단지 영역의 예일 뿐입니다: 인터페이스와 연관된 영역을 식별하고, 그 다음 규칙, 순서, TCP 프로토콜, 포트, 허용된 원본 및 거부 작업을 검토하세요. 변경을 적용하기 위해 여러 관리자 결합하지 마세요; 테스트를 위해 방화벽을 비활성화하지 마세요.

그 다음에는, 읽기 전용으로 클라우드 또는 호스팅 제공업체의 방화벽 규칙을 확인하세요: 공개된 포트, 프로토콜 및 허용된 원본 주소. 서버가 라우터 뒤에 있다면, 외부 포트가 올바른 개인 주소와 실제 청취 중인 포트로 리디렉션되고 있는지 확인하세요. 예를 들어 외부 포트 2222가 내부 포트 22로 리디렉션된다면, PuTTY는 인터넷에서 포트 2222에 연결해야 하며, ss는 서버의 포트 22를 표시합니다. 또한 머신의 개인 주소가 변하지 않았는지 확인하세요. VPN이나 중계점이 예정되어 있다면, SSH를 인터넷에 노출하기보다는 이 경로를 우선시하세요.

같은 로컬 네트워크에서 공용 주소로의 테스트는 라우터의 NAT 루프백 지원 여부에 따라 다릅니다; 이는 허가된 외부 테스트를 대체하지 않습니다. 라우팅, 공용 주소 또는 CGNAT와 관련된 응답이 없으면, 이는 종종 타임아웃 경로로 이어집니다: 유효성을 검증 없이 포트를 열려고 시도하지 마세요.

검증된 단일 수정만 적용하고, 다시 테스트하세요

• 세션에서 잘못된 호스트나 포트: 관리자에 의해 확인된 클라이언트 목적지만 수정하세요.
• SSH를 제공해야 하는데 서비스가 없는 경우: 배포판에 따라 설치 및 활성화를 확인하세요.
• 서비스가 중지되어 있고, 구성은 유효하며, 유닛이 정확하고 콘솔 접근이 보장된 경우: 제어된 시작이 적절할 수 있습니다.
• 청취 주소가 잘못됨: 확인된 바인드만 수정하고 먼저 구성을 확인하세요.
• 거부 규칙이 명확하게 나타남: SSH 포트, 프로토콜 및 필요한 원본으로 한정된 규칙을 요청하거나 적용하세요.
• 잘못된 리디렉션: 예상되는 경로가 확인된 후 개인 주소나 외부 포트를 수정하세요.

사실상 중지된 systemd 서비스에 대해, 서버가 SSH를 제공해야 하고, sshd -t 가 성공적이며, 사용 중인 유닛이 확인되고, 비상 콘솔에 접근 가능할 때, 제어된 시작은:

sudo systemctl start ssh.service

ssh.service를 실제 유닛인 경우 sshd.service로 바꾸세요; 두 개를 모두 시작하지 마세요; 소켓과 경쟁하여 서비스를 시작하지 마세요. 이 명령은 머신의 상태를 변경하므로 첫 번째 테스트로 사용해서는 안 됩니다. 구성 수정 후, 해당 배포와 유닛에서 지원되는 재로드 메커니즘을 먼저 확인하세요; 자동으로 재시작하는 것은 여기서 권장되지 않습니다. 공식 Ubuntu 문서는 SSH 변경이 접근을 잠글 수 있음을 상기시킵니다: 따라서 확인하는 동안 세션을 열어 두고 비상 콘솔을 유지하세요.

각 수정 후에는 따로 진행하세요: 서버 측에서 ss -ltnp를 다시 읽고, 수정된 호스트와 포트로 PuTTY에서 새 창을 여세요. PuTTY가 새로운 호스트 지문을 표시하면, 수락하기 전에 신뢰할 수 있는 채널로 확인하세요. SSH 배너나 인증 화면에 도달하면 TCP 거부가 해제된 것입니다; 이는 계정이 이미 인증되었음을 의미하지는 않습니다. 새로운 연결이 완료될 때까지는 백업 접근을 유지하세요.

ufw disable, nft flush ruleset 또는 iptables -F를 사용하지 마세요. 원천 제한 없이 SSH를 전 세계적으로 열지 마세요, root 접속을 활성화하여 문제를 우회하지 마세요, SSH 권한이나 다중 인증을 약화하지 마세요.

거부가 지속되면 로그 검토하기

Linux 콘솔에서 실제로 존재하는 유닛을 선택하고 PuTTY에서 기록된 시간 근처의 최근 창을 확인하세요:

sudo journalctl -u ssh.service -n 50 --no-pager
sudo journalctl -u sshd.service -n 50 --no-pager
sudo journalctl -u ssh.socket -n 50 --no-pager

존재하는 유닛에 해당하는 명령어만 실행하세요. 구성 오류, 주소 불가 또는 포트의 중복을 찾아보세요. 배포 및 로깅에 따라 /var/log/auth.log 또는 /var/log/secure와 같은 파일이 로그를 보완할 수 있습니다; 모든 곳에 존재하지는 않습니다. SSH 설정 전에 거부가 일어났다면 인증 입력이 없을 수 있습니다. 또한, 라우터나 클라우드 방화벽에 의해 발생한 거부는 journalctl에 나타나지 않을 수 있습니다: 줄이 없다는 것이 시도가 없다는 것을 증명하지는 않습니다.

서버를 관리하고 tcpdump를 사용할 수 있다면, 짧은 캡처를 시도하여 거부를 찾는 데 도움이 될 수 있습니다. 문서 주소를 서버에서 실제로 볼 수 있는 소스 주소로 바꾸세요, 이는 NAT 후에 달라질 수 있습니다; 한 머신과 네트워크에서만 캡처하세요. 진단할 수 있는 권한이 있는 경우에만 캡처합니다.

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

timeout 10는 캡처를 10초로 제한하며; -c 20는 최대 20패킷 후에 정지합니다; -n은 이름 확인을 방지하고 -i any는 사용 가능한 인터페이스를 모니터링합니다. 이 예시는 내부 포트 22를 대상으로 하므로 필터를 관찰된 포트에 조정하세요. 해당 캡처 지점에서 들어오는 SYN과 RST가 연속으로 발생하면 이 위치에서 거부가 있었음을 뒷받침합니다. 이는 자동으로 책임 장비를 식별하지 않습니다. 캡처된 패킷이 없다면 잘못된 인터페이스, 나쁜 필터 또는 다른 네트워크 경로로 인한 것일 수 있습니다. 유용한 부하 디코딩 옵션으로 콘텐츠를 캡처하지 마세요, 영구 캡처 파일을 보존하지 마세요 그리고 결과를 공유할 때 주소와 시간을 숨기세요.

독립 콘솔이나 방화벽 검사 의 권한이 없다면, 원격에서 수정을 계속하지 마세요. 관리자에게 목표 호스트와 포트, 시간, 정확한 PuTTY 메시지 및 수행한 테스트를 전달하고, 내부 정보를 제거하세요.