☰

SSH 서버가 연결 요청에 응답하지 않습니다

tag-icon • tag-icon ssh 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.94SSH 서버는 어디에 있나요?

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.94SSH 서버는 어디에 있나요?

이것은 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입니다.

그럼:또 무엇이 있을까요?트래픽을 무시하는 방화벽이나 무언가처럼 보이지만 라우터가 아니고, iptables도 아니고, SSH 서버의 또 다른 방화벽도 아니고... 또 뭐죠?

편집: 내부 네트워크의 연결 요청 오류

yoshimi@robots:/$ ssh [email protected]
ssh: connect to host 192.168.1.90 port 22: No route to host

답변1

매우 실망스러운 자체 답변

문제를 하루 동안 그대로 두었다가 문제를 해결하기 위해 다시 돌아온 후 모든 것이 이상하게 제대로 작동하고 있다는 사실을 알게 되자 나는 안도감과 불안함을 동시에 느꼈습니다.

그렇다면 문제는 무엇입니까?

라우터, SSH 서버, SSH 클라이언트 컴퓨터가 아닌 설정이 변경되거나 조정되지 않았습니다. 라우터가 올바르게 설정되었음에도 불구하고 라우터가 들어오는 트래픽을 제대로 처리하지 못한다고 해도 과언이 아닙니다. 소규모 가정용 라우터 소프트웨어가 그렇지 않다는 점을 고려하면진짜포트 포워딩을 처리하도록 설계된 이 불쌍한 사람은 필요한 변경 사항을 구현하는 데 시간이 걸렸습니다.

그런데 6시간이 지났습니다!

응, 나도 알아. 하루 종일 문제를 찾으려고 노력했지만 찾지 못했습니다.아니요뭔가 잘못되었다. 라우터 설정이 적용되려면 최대 6시간(아마도 그 이상)이 걸릴 수 있습니다.

그렇다면 이것이 내 문제인지 어떻게 알 수 있습니까?

이 모험에서 제가 발견한 훌륭한 도구는 바로 tcpdump이 마른 사람이 교통 정보를 탐지하여 실제로 무슨 일이 일어나고 있는지에 대한 귀중한 통찰력을 제공하는 것입니다. 게다가, 보고 싶은 것/찾고 싶은 것의 범위를 정확하게 좁힐 수 있는 몇 가지 슈퍼 필터링 기능도 있습니다. 예를 들어 다음 명령은 다음과 같습니다.

tcpdump -i wlan1 port 22 -n -Q inout

wlan1 인터페이스(="인터페이스")를 통해 트래픽을 찾고 tcpdump포트 22를 통해서만 DNS 이름 확인을 무시하고(="이름 확인 없음") 들어오는 트래픽과 나가는 트래픽을 모두 보고 싶다는 것을 나타냅니다(수락 또는; 기본값입니다).-i-n-Qinoutinoutinout

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

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

문제를 발견하면 해결 방법은 (대개) 간단합니다.

답변2

저는 Mint(Ubuntu)를 실행하고 있습니다.

나는 모든 작업을 수행했습니다...authorized_keys, chmodding, chowning, ssh 및 sshd 다시 시작 등에서 올바른 형식으로 공개 키를 가져왔습니다. 모든 곳에서 문서화되어 있습니다.

나에게는 ufw 방화벽입니다. 이 사실을 알려주는 SSH 응답은 전혀 없었지만 LAN에서 양방향으로 핑을 보내는 데 아무런 문제가 없었습니다.

내 테스트는 통과되었습니다:

sudo ufw service stop

...그리고 잘 작동합니다. 즉, SSH 호출에 대한 응답을 받았습니다.

따라서 ufw를 다시 시작하십시오.

sudo ufw service start

...규칙을 추가합니다.

sudo ufw allow openssh

이제 모든 것이 잘 작동합니다.

답변3

저처럼 UFW를 활성화했다면(저의 경우 Linux, Ubuntu에서) 다음을 시도해 보세요:

sudo ufw enable OpenSSH

그러면 방화벽에서 OpenSSH가 허용됩니다.

답변4

대부분의 경우 방화벽이 원인입니다. 확인 service iptables stop하고 service ip6tables stop.

서비스 중지가 작동하지 않으면 iptable 새로 고침을 수행하십시오.

iptables --flush

가상 머신인 경우 호스트에서도 동일한 작업을 수행합니다.

관련 정보