SSH Server không đáp ứng yêu cầu kết nối

Tôi đang cố gắng thiết lập máy chủ SSH trên máy cục bộ của mình bằng OpenSSH. Khi tôi cố gắng SSH từ một máy chủ từ xa vào máy chủ SSH cục bộ của mình, máy chủ SSH không phản hồi và hết thời gian yêu cầu. Tôi khá chắc chắn rằng có một sửa chữa thực sự rõ ràng cho điều này mà tôi chỉ đơn giản là nhìn ra.

Đây là những gì xảy ra khi tôi cố gắng SSH từ một máy chủ từ xa:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
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

Máy robotschủ từ xa của tôi ở đâu và 99.3.26.94là máy chủ SSH cục bộ của tôi.

SSH đang chạy

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

Trong trường hợp arnoldlà máy chủ SSH địa phương của tôi.

Chuyển tiếp cổng được thiết lập trên bộ định tuyến

Tôi đã cài đặt bộ định tuyến tại nhà để chuyển tiếp các cổng 80 và 22 đến máy chủ SSH của mình. Thật thú vị, cổng 80 hoạt động mà không gặp trở ngại - đi thẳng vào thư mục web Apache. Cổng 22 - không quá nhiều.

NMap nói rằng nó được lọc

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

Máy robotschủ từ xa của tôi ở đâu và 99.3.26.94là máy chủ SSH cục bộ của tôi.

Đó không phải là IPTables (tôi nghĩ)

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            

... Và tôi không có bất kỳ tường lửa nào khác - đó là một mạng Debian tương đối mới.

Vì vậy, sau đó: nó có thể là gì khác? Nó chắc chắn dường như là một loại tường lửa để bỏ qua lưu lượng truy cập, nhưng nếu không phải là bộ định tuyến, thì nó không phải là iptables và nó không phải là một tường lửa khác trên máy chủ SSH, ... còn cái quái gì nữa không ??

EDIT: Đầu ra máy chủ NetStat

Từ máy chủ SSH:

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

Một câu trả lời rất đáng thất vọng

Đặt vấn đề này sang một ngày và trở lại với nó, tôi vừa nhẹ nhõm vừa bối rối (bối rối hơn là nhẹ nhõm) khi thấy mọi thứ đều hoạt động bình thường.

Vì vậy, vấn đề là gì?

Không có cài đặt nào được thay đổi hoặc điều chỉnh - không phải trên bộ định tuyến, không phải trên máy chủ SSH và không phải trên máy của máy khách SSH. Nó khá an toàn để nói rằng đó là bộ định tuyến không xử lý lưu lượng đến đúng cách, bất chấp các cài đặt thích hợp. Cho rằng phần mềm bộ định tuyến nhà dinky không thực sự được thiết kế để đối phó với chuyển tiếp cổng, anh chàng nghèo phải mất một thời gian để thực hiện các thay đổi cần thiết.

Nhưng nó đã được 6 giờ !!

Vâng anh bạn, tôi biết. Tôi đã dành cả ngày cố gắng tìm ra những gì là sai - và không bao giờ tìm thấy nó vì có không phải là điều gì sai trái. Rõ ràng, có thể mất 6 giờ - có thể nhiều hơn - để các cài đặt bộ định tuyến có hiệu lực.

Vậy làm thế nào để tôi biết nếu đây là vấn đề của tôi?

Một công cụ tiện lợi tôi đã gặp trong quá trình thoát hiểm này là tcpdump. Anh chàng gầy gò này đánh hơi giao thông cho bạn, cung cấp cái nhìn sâu sắc có giá trị về những gì đang thực sự xảy ra. Ngoài ra, anh ta có một số tính năng siêu lọc cho phép bạn thu hẹp chính xác những gì bạn muốn xem / cho. Ví dụ: lệnh:

tcpdump -i wlan1 port 22 -n -Q inout

Nói tcpdumpđể tìm kiếm thông qua giao diện wlan1 ( -i= 'giao diện'), chỉ thông qua cổng 22, bỏ qua độ phân giải tên DNS ( -n= 'no name độ phân giải'), và chúng tôi muốn nhìn thấy cả lưu lượng vào và ra ( -Qchấp nhận in, outhoặc inout; inoutlà mặc định).

Bằng cách chạy lệnh này trên máy chủ SSH của bạn trong khi cố gắng kết nối qua một máy từ xa, nó sẽ nhanh chóng trở nên rõ ràng chính xác vấn đề nằm ở đâu. Về cơ bản, có 3 khả năng:

1. Nếu bạn đang thấy lưu lượng truy cập đến từ máy từ xa, nhưng không có lưu lượng đi từ máy chủ cục bộ của bạn, thì vấn đề nằm ở máy chủ: có thể có một quy tắc tường lửa cần được thay đổi, v.v.
2. Nếu bạn thấy cả đến và đi , nhưng máy từ xa của bạn không nhận được phản hồi, rất có thể đó là bộ định tuyến: nó cho phép lưu lượng đến, nhưng bỏ các gói đi của bạn.
3. Nếu hoàn toàn không có lưu lượng , thì đó cũng có thể là một vấn đề về bộ định tuyến: các SYNgói của máy từ xa đang bị bộ định tuyến bỏ qua và bỏ qua trước khi chúng đến máy chủ của bạn.

Và một khi bạn đã phát hiện ra vấn đề nằm ở đâu, một sửa chữa (thường) là tầm thường.