PuTTY는 Network error: Connection timed out를 표시합니까? 세션을 시작할 때 이는 유용한 응답이 예상된 시간 내에 오지 않음을 의미합니다. 주소나 포트가 잘못되었거나 네트워크 경로가 접근할 수 없거나 비대칭일 수 있으며, 장비가 패킷에 대한 응답을 하지 않을 수 있습니다. 이 단계에서는 비밀번호와 SSH 키는 아직 문제가 되지 않습니다.
연결 거부는 다릅니다: TCP 연결이 거부되었으며, 예를 들어 서비스가 대기 중이지 않은 포트나 중간 장비에 의해 거부되었을 수 있습니다. 이 거부만으로는 올바른 서버가 응답했다는 것을 증명하지 않습니다. 이 다른 브랜치에 대해서는 PuTTY에서의 Connection refused 진단를 참조하십시오. 매뉴얼은 PuTTY 타임아웃을 서버의 응답 없음으로 공식적으로 설명하고 특히 분리되거나 꺼진 서버와 확인해야 할 주소를 언급합니다. 또한, 타임아웃이 연결 중 통신 상실 후 발생할 수 있음을 알리며: 이 가이드는 세션 시작에 중점을 둡니다.
서버를 변경하지 않고 순차적으로 진행합니다: 먼저 Windows에서 목적지와 경로를 확인한 후, 이러한 관찰을 Linux 측에서 수신, 회신 경로 및 필터링과 비교하십시오. 서버 명령어는 호스팅 제공업체, VM 또는 물리적 접근을 통해 제공되는 독립 콘솔을 사용하십시오. 이미 열린 SSH 세션을 유지하십시오.
변경하기 전에 타임아웃 식별하기
PuTTY에 의해 표시된 정확한 텍스트, 시간과 시간대, 사용된 세션, 호스트 이름, 포트, 실패가 발생한 단계를 기록하십시오. PuTTY에서 구성된 프록시, VPN 또는 방화벽을 경유하는지 여부도 주의 깊게 살펴보십시오. PuTTY의 이벤트 로그에 제공된 세부 정보는 시도된 경로와 주소 확인에 도움이 될 수 있습니다.
- 세션 시작 시 타임아웃: 예상된 시간 내에 유용한 응답이 오지 않았습니다. 이는 주소, 라우팅 또는 조용한 필터링을 나타내며 이러한 원인을 구별하지 않습니다.
- Connection refused: 경로가 TCP 거부를 받았습니다. 거부된 연결을 위해 전용 브랜치를 확인하십시오.
- Server refused our key: 전송이 인증 단계에 도달했습니다; 이는 또 다른 실패입니다. 그런 다음 PuTTY에서 SSH 키 사용에 대한 가이드를 참조하십시오.
- 활성 세션이 비활성 상태 후 종료됨: 이는 세션 시작 시 타임아웃과는 다른 경우입니다. 응답하지 않는 초기 TCP 경로를 수정하기 위해 keepalive 설정을 기대하지 마십시오.
PuTTY에서 조정할 보편적인 기간을 찾지 마십시오: 대기 시간을 늘려도 없는 경로나 필터링된 패킷을 수정할 수 없습니다.
주소, DNS 및 실제 게시된 포트 확인하기
PuTTY에서 저장된 세션을 열고 SSH 설정에서 호스트와 포트를 확인하십시오. 호스트 필드는 이름이나 주소를 포함하고 있으며 https://가 포함된 URL이 아닙니다. 이러한 값을 관리자에게 확인하거나 교체하기 전에 공급자의 콘솔에서 확인하십시오. 세션 필드를 다시 보려면 PuTTY에서 SSH 세션의 설정을 확인하십시오.
PowerShell에서 serveur.example.net을 확인된 이름으로 교체하고 22를 실제 게시된 외부 TCP 포트로 교체하십시오. 이러한 값은 예시이며, 실제 서버의 매개변수가 아닙니다.
Resolve-DnsName serveur.example.net -Type A
Resolve-DnsName serveur.example.net -Type AAAA
Test-NetConnection -ComputerName serveur.example.net -Port 22 -InformationLevel Detailed처음 두 명령은 DNS 해석을 통해 얻은 IPv4(A) 및 IPv6(AAAA) 주소를 별도로 표시합니다. 반환된 주소가 공급자의 콘솔에 기대되는 주소와 비교하십시오. AAAA 레코드는 PuTTY가 IPv4 경로와 다른 IPv6 경로를 사용하게 할 수 있습니다. Test-NetConnection의 Microsoft 문서는 TCP 결과와 경로 진단을 자세히 설명합니다.
Test-NetConnection의 상세 결과에서 RemoteAddress, SourceAddress, InterfaceAlias, TcpTestSucceeded를 주의 깊게 확인하십시오. 이미 확인된 주소에 대해 별도로 테스트하여 해석 문제와 TCP 실패를 구별할 수 있습니다. 임의로 발견된 주소를 사용하지 말고 신뢰할 수 있는 채널을 통해 호스트 키의 새 지문을 확인하지 않고 수락하지 마십시오.
TcpTestSucceeded : True는 이 테스트가 해당 목적지, 해당 포트 및 해당 경로로 TCP를 설정했음을 의미합니다. 이는 서버의 SSH 신원을 확인하지 않습니다. PuTTY가 여전히 실패하면 사용된 주소와 포트, 가능한 프록시 및 세션 설정을 비교하십시오.TcpTestSucceeded : False는 TCP 테스트의 실패를 나타내지만 시간 초과와 거부를 구분하지 않으며 소실 위치를 찾지도 않습니다. PuTTY의 정확한 메시지를 보존하고 점검을 계속하십시오.
개인 주소는 일반적으로 예상된 네트워크 또는 올바른 경로의 VPN에서만 도달할 수 있습니다. NAT가 있는 경우, 클라이언트가 사용하는 포트는 내부 수신 포트와 다를 수 있습니다: 예를 들어, 개념적 외부 포트 2222가 내부 포트 22로 리디렉션될 수 있습니다. 일치를 확인하십시오; 이러한 예시를 가상의 값으로 대체하지 마십시오. DNS 캐시를 단순하게 비우지 마십시오: 로컬 항목의 노후화가 입증된 경우에만 하십시오.
Windows, VPN 및 네트워크 경로 비교하기
활성 네트워크, 요청된 VPN 또는 방화벽 접근, 경로 및 사용된 출발지 주소를 확인하십시오. PuTTY가 프록시를 경유하는 경우, 직접 PowerShell 테스트는 해당 프록시를 검증하지 않습니다: 두 시도는 반드시 동일한 경로를 따르지 않을 수 있습니다.
다음 명령은 Windows 측에서의 읽기입니다. tracert에서 192.0.2.20을 테스트할 수 있는 서버의 주소로 교체하십시오. 192.0.2.20은 문서의 예시로 예약된 주소이며, 실제 서버의 주소가 아닙니다.
ipconfig
route print
Test-NetConnection -ComputerName serveur.example.net -DiagnoseRouting -InformationLevel Detailed
tracert -d 192.0.2.20ipconfig와 route print는 로컬 인터페이스와 경로를 측정하는 데 도움이 됩니다. -DiagnoseRouting은 경로 진단을 요청하며, 이는 -Port와는 다른 매개변수 집합입니다. 두 가지를 동일한 명령어에서 결합하지 마십시오. tracert는 경과 단계를 표시하지만, 별표는 ICMP 응답이 반환되지 않음을 나타낼 수 있습니다. 이는 SSH를 차단하는 장비를 확실하게 지시하지 않습니다. 마찬가지로, 성공적인 핑은 SSH에 접근 가능하다는 것을 증명하지 않으며, 실패한 핑은 서버가 꺼졌다는 것을 증명하지 않습니다.
허용되는 경우, 다른 네트워크에서 동일한 호스트와 동일한 포트에 대해 나머지 매개변수는 변경하지 않고 비교하십시오. 예를 들어, 핫스팟을 통해 성공하면 첫 번째 네트워크상의 경로, 출발지 또는 권한 차이를 나타내며, 이는 자동으로 ISP가 포트 22를 차단하고 있음을 증명하지 않습니다. 허용된 출발지 주소 목록이 이러한 차이를 설명할 수 있습니다. Windows의 발신 규칙과 네트워크 정책을 관리자와 확인하십시오. 방화벽이나 안티바이러스를 비활성화하지 말고, 네트워크 정책을 우회하지 마십시오.
Linux에서 수신 검토 및 경로 확인하기
이 측정을 서버의 독립 콘솔에서 실행하고 실패한 PuTTY 창에서 실시하지 마십시오. 192.0.2.10을 서버가 실제로 보는 출발지 주소로 교체하십시오, NAT 또는 VPN 후에. 192.0.2.10은 문서의 주소로 교체해야 하며, 클라이언트의 실제 IP가 아닙니다. IPv6 목적지에 대해서는 관찰된 IPv6 주소와 함께 ip -6 route get를 사용하십시오.
ip -br address
ip route
ip route get 192.0.2.10
sudo ss -ltnp
systemctl list-unit-files 'ssh*' --no-pager
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -Tip -br address는 인터페이스의 주소 요약을 제공합니다; ip route는 IPv4 경로를 표시하며 ip route get는 돌려보낼 출발지에 대한 선택된 경로를 나타냅니다. 이 경로를 실제 경로와 비교하십시오: 기본 경로가 있다고 해서 응답이 클라이언트에 도달하지 않는다고는 보장할 수 없습니다. /usr/sbin/sshd에 바이너리가 없는 배포판에서 이 경로가 비어 있다고 결론 내리지 마십시오.
ss -ltnp는 수신 중인 TCP 소켓을 보여주며, 권한에 따라 관련 프로세스를 표시합니다. 내부 포트와 수신 주소를 확인하십시오: 127.0.0.1에 한정된 수신은 외부에서 접근할 수 없습니다. [::]에서 수신된다고 해서 IPv4로 접근 가능하다고도 보장되지 않습니다. NAT 뒤의 서버의 공인 주소는 Linux 인터페이스에서 반드시 나타나지 않습니다.
실제로 사용된 유닛을 찾아 해당 상태를 확인하십시오. 배포판에 따라 ssh.service 또는 sshd.service라고 불릴 수 있으며, 소켓에 의한 활성화는 ssh.socket를 사용할 수 있습니다. 알려지지 않은 유닛은 반드시 SSH가 없음을 의미하지 않습니다. 확인된 유닛만 점검하십시오, 예를 들어:
systemctl status ssh.service --no-pagerssh.service를 기존 유닛으로 교체하십시오. OpenSSH의 sshd 매뉴얼는 -t를 구성 및 키의 일관성을 확인하는 것으로 설명하고, -T는 실제 구성을 표시합니다. 이러한 옵션은 서비스를 다시 시작하지 않습니다. Match 규칙은 연결 매개변수에 따라 달라질 수 있으므로, -T만으로는 모든 클라이언트에 적용되는 구성을 증명하지 않습니다. 소켓에 의해 활성화된 경우, 반드시 실제 수신을 ss와 소켓 유닛과 함께 관찰하십시오.
ListenAddress 및 Port는 구성 내 수신하는 주소 및 포트를 결정합니다; 이는 경로 보장, 방화벽 규칙이나 NAT에 의한 포트 게시를 보장하지 않습니다. 수신되지 않는 포트는 종종 패킷이 필터링 없이 호스트에 도달했을 때 거부를 생성합니다: 따라서 모든 타임아웃이 SSH 서비스가 정지되었다고 결론 내리지 마십시오.
SSH를 모든 인터넷에 열지 않고 필터링 찾기
해석할 규칙을 확인하기 전에 실제 사용 중인 방화벽을 식별하십시오. 이 명령은 읽기용이며, 모든 배포판에서 사용 가능하지 않을 수 있습니다:
sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones만약 firewalld가 활성화되어 있다면, 실제 인터페이스에 연결된 영역을 확인하십시오. ZONE를 해당 이름으로 교체하십시오:
sudo firewall-cmd --zone=ZONE --list-all명령이 없다고 해서 필터링이 없다고 증명하지는 않습니다: 규칙이 다른 관리 도구, 라우터 또는 호스팅 제공업체에 있을 수 있습니다. 장애 수정을 위해 방화벽 관리자를 조합하지 마십시오.
관찰된 경로에 일치하는 규칙을 확인할 때, TCP 프로토콜, 내부 포트, 서버에서 본 출발지 주소, 규칙 순서 및 행동을 확인하십시오. DROP 규칙은 연결을 응답하지 않게 할 수 있으며; REJECT는 거부 형태에 따라 거부를 초래할 수 있습니다. 보안 그룹이나 클라우드 방화벽, 공급자의 경로, 라우터, NAT 리디렉션, VPN 및 CGNAT를 점검하십시오. LAN에서 공인 주소에 대한 테스트는 NAT 루프백 지원 여부와 관련이 있습니다; 리디렉션은 CGNAT 뒤에 반드시 작동하지 않습니다.
관찰을 기반으로 식별된 단독 규칙이나 경로만 수정하며, 필요한 주소로 출발지를 제한하십시오. 기본적으로 0.0.0.0/0에 포트를 열지 않고, SSH를 자동 우회로 포트 443으로 이동하지 마십시오.
로그 및 짧은 TCP 캡처 교차 확인하기
기록된 시간을 기준으로 로그를 확인하되, 실제 사용된 유닛을 적용하십시오:
sudo journalctl -u ssh.service --since '10 minutes ago' --no-pagerssh.service를 기존 유닛으로 교체하십시오, 예를 들어 sshd.service 또는 경우에 따라 ssh.socket로 대체하십시오. 일부 배포판은 /var/log/auth.log 또는 /var/log/secure와 같은 파일에 이벤트를 기록합니다. SSH 교환 전의 타임아웃은 인증 라인을 남기지 않을 수 있습니다: 로그가 비어 있다고 해서 시도가 없었던 것은 아닙니다.
만약 tcpdump와 GNU timeout를 사용할 수 있고 캡처가 허용되는 경우, 포트와 주소를 서버에서 실제로 본 내부 포트와 출발지로 교체하여 새 PuTTY 시도 전에 캡처를 시작하십시오:
sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'이 명령에서 포트 22와 192.0.2.10은 문서의 예시이며 교체해야 할 값입니다; 장애 데이터를 위한 것이 아닙니다. 캡처는 10초 후 또는 20개의 패킷 후에 중지됩니다. -A 또는 -X 옵션을 사용하지 말고 영구 캡처를 실행하지 마십시오. 출력을 공유하기 전에 주소를 마스킹하십시오.
- 관찰된 지점에 SYN 없음: 인터페이스, 캡처 필터, 시간 및 출발지를 확인 후 목적지, 경로 또는 상위 필터링을 검토하십시오. 이는 클라우드 방화벽이 트래픽을 차단하고 있다는 것을 단독으로 증명하지 않습니다.
- SYN을 수신했으나 응답 없음: 로컬 필터링, 수신 및 캡처 조건을 확인하십시오.
sshd를 의심하지 마십시오, 추가 증거 없이. - SYN 수신 후 SYN-ACK 발신, 그러나 최종 ACK 없음: 회신 경로나 클라이언트/중간측 필터링을 조사하십시오. 서버 쪽 캡처만으로는 손실을 DEFINITELY 위치를 찾지 못합니다.
- SYN 뒤에 RST: TCP 거부의 지점에 있습니다; Connection refused에 대한 진단을 참조하십시오.
- TCP 핸드셰이크 완료: TCP는 이 시점에 작동하고 있습니다. 캡처를 PuTTY 시도, 프록시와 SSH 단계에 비교하십시오. 이는 서버의 신원이나 인증 성공을 증명하지 않습니다.
입증된 원인을 수정하고 SSH를 끊지 않고 확인하기
수정을 진행하기 전에 관련된 파일의 백업을 생성하고 백업 콘솔에 접근할 수 있는지 확인하십시오. 한 번에 하나의 수정을 진행하십시오: 세션의 목적지, VPN 경로 또는 테스트에 의해 확인된 특정 규칙을 수정하십시오. 독립 콘솔이 없다면 원격 변경을 중단하고 결과를 관리자에게 전달하십시오.
네트워크 인증 전, 네트워크 침묵을 수정하기 위해 키, 비밀번호, PermitRootLogin 또는 SSH 알고리즘을 수정하지 마십시오. SSH 구성을 변경하는 경우, 먼저 sshd -t가 성공해야 하며, 작동 여부를 확인한 후 유닛 및 배포에서 지원하는 리로드를 사용하십시오. 재시작이나 재부팅은 첫 번째 테스트가 아니며, 리로딩이 반드시 잘못 노출된 systemd 소켓을 수정하지는 않습니다.
ufw disable, nft flush ruleset 또는 iptables -F를 실행하지 마십시오. 눈치를 채지 못하고 Fail2ban을 정지하지 마십시오, SSH를 모든 소스로 열지 마시고, 검증 없이 구식 세션을 종료하지 마십시오.
수정이 끝난 후에는 콘솔과 이전 세션이 열려 있어야 합니다. 새로운 PuTTY 창에서 동일한 호스트, 포트 및 경로를 다시 테스트하십시오. 신뢰할 수 있는 채널을 통해 SSH 지문을 확인하고 인증까지 진행한 다음 세션이 작동함을 확인하십시오. 메시지가 Connection refused로 바뀌면 타임아웃의 진단을 진행하기보다 이 브랜치로 돌아가십시오.
도움을 요청할 때는 시간, 호스트 및 포트, 해석된 주소 및 출발지 주소, VPN/프록시 경로, TCP 결과 및 서버 측 관찰, 의심되는 규칙을 전달하십시오. 주소 및 민감한 정보를 정리하십시오. 실행되지 않은 명령의 출력을 결과로 제시하지 마십시오.