☰

SSH 서버가 연결 요청에 응답하지 않음

tag-icon • tag-icon linux networking ssh firewall openssh
SSH 서버가 연결 요청에 응답하지 않음

OpenSSH를 사용하여 로컬 컴퓨터에 SSH 서버를 설정하려고 합니다. 원격 호스트에서 로컬 SSH 서버로 SSH를 시도하면 SSH 서버가 응답하지 않고 요청 시간이 초과됩니다. 나는 내가 간과하고 있는 이 문제에 대한 정말 명백한 해결책이 있다고 확신합니다.

원격 호스트에서 SSH를 시도할 때 발생하는 상황은 다음과 같습니다.

yoshimi@robots:/$ ssh -vv [email protected]
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

내 원격 호스트는 어디에 robots있고 99.3.26.94로컬 SSH 서버는 어디에 있나요?

SSH가 실행 중입니다.

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

arnold내 로컬 SSH 서버는 어디에 있습니까?

포트 전달이 라우터에 설정되어 있습니다.

포트 80과 22를 SSH 서버로 전달하도록 홈 라우터를 설정했습니다. 흥미롭게도 포트 80은 문제 없이 작동하여 Apache 웹 디렉토리로 바로 연결됩니다. 포트 22 - 그다지 많지는 않습니다.

NMap은 필터링되었다고 말합니다

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

내 원격 호스트는 어디에 robots있고 99.3.26.94로컬 SSH 서버는 어디에 있나요?

IPTables가 아닙니다. (내 생각에는)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

...그리고 다른 방화벽은 없습니다. 비교적 새로운 데비안 netinst입니다.

그럼:또 무엇이 있을까요?확실히 트래픽을 무시하는 것이 일종의 방화벽인 것처럼 보이지만 라우터도 아니고 iptable도 아니고 SSH 서버의 또 다른 방화벽도 아닌데... 도대체 또 뭐가 있는 걸까요??

편집: NetStat 서버 출력

SSH 서버에서:

tcp6       0      0 :::22                   :::*                    LISTEN      5784/sshd

답변1

매우 실망스러운 자기 답변

이 문제를 하루 동안 미뤄두었다가 다시 돌아와 보니 모든 것이 이상하게도 제대로 작동하고 있다는 사실에 안도감과 동요가 있었습니다(안도감보다는 당황스러움이 더 컸습니다).

그렇다면 문제는 무엇이었나요?

라우터나 SSH 서버, SSH 클라이언트 시스템에서는 설정이 변경되거나 조정되지 않았습니다. 적절한 설정에도 불구하고 라우터가 들어오는 트래픽을 제대로 처리하지 못했다고 말하는 것이 상당히 안전합니다. 작은 홈 라우터 소프트웨어가 그렇지 않다는 점을 고려하면정말포트 포워딩을 처리하도록 설계되었으므로 필요한 변경 사항을 구현하는 데 시간이 걸렸습니다.

그런데 6시간이나 지났어요!!

응 친구, 나도 알아. 나는 하루 종일 무엇이 잘못되었는지 알아내려고 노력했지만 찾지 못했습니다.아니었다아무것도 잘못되었습니다. 분명히 라우터 설정이 적용되는 데는 6시간(아마도 그 이상)이 걸릴 수 있습니다.

그렇다면 이것이 내 문제인지 어떻게 알 수 있나요?

이 탈출 과정에서 제가 발견한 멋진 도구는 tcpdump. 이 날씬한 작은 녀석은 교통 체증을 탐지하여 실제로 무슨 일이 일어나고 있는지에 대한 귀중한 통찰력을 제공합니다. 게다가, 그는 당신이 보고 싶은 것/대상의 범위를 정확하게 좁힐 수 있는 몇 가지 슈퍼 필터링 기능을 가지고 있습니다. 예를 들어 다음 명령은 다음과 같습니다.

tcpdump -i wlan1 port 22 -n -Q inout

tcpdumpwlan1 인터페이스( = '인터페이스')를 통해 트래픽을 찾도록 지시하고 -i포트 22를 통해서만 DNS 이름 확인( -n= '이름 확인 없음')을 무시하며 들어오고 나가는 트래픽( -Qaccepts in, out또는 inout; inout기본값입니다).

원격 시스템을 통해 연결을 시도하는 동안 SSH 서버에서 이 명령을 실행하면 문제가 정확히 어디에 있는지 빨리 알 수 있습니다. 기본적으로 3가지 가능성이 있습니다.

  1. 보고 계시다면들어오는원격 시스템의 트래픽이지만발신 없음로컬 서버의 트래픽이 있는 경우 문제는 서버에 있습니다. 변경해야 할 방화벽 규칙이 있을 수 있습니다.
  2. 보고 계시다면들어오는 것과 나가는 것 모두, 그러나 원격 시스템이 응답을 받지 못하고 있으며 라우터일 가능성이 높습니다. 들어오는 트래픽은 허용하지만 나가는 패킷은 삭제됩니다.
  3. 만약 있다면교통량이 전혀 없어, 이는 아마도 라우터 문제일 수도 있습니다. 원격 시스템의 SYN패킷이 서버에 도달하기도 전에 라우터에 의해 무시되고 삭제됩니다.

그리고 문제가 있는 위치를 발견한 후에는 해결 방법이 (보통) 간단합니다.

관련 정보