SSHサーバーが接続要求に応答しない

OpenSSHを使用して、ローカルマシンにSSHサーバーをセットアップしようとしています。リモートホストからローカルSSHサーバーにSSHで接続しようとすると、SSHサーバーが応答せず、リクエストがタイムアウトします。私は単にこれを見落としている、これに対する本当に明らかな修正があると確信しています。

リモートホストからSSHで接続しようとするとどうなりますか。

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

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 Webディレクトリに直接移動します。ポート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            

...そして、私は他のファイアウォールを設置していません-それは比較的新しいDebian netinstです。

だから、それから：それは他に何でしょうか？確かに、トラフィックを無視するだけのファイアウォールのようなもののように見えますが、ルーターではない場合、iptablesではなく、SSHサーバー上の別のファイアウォールでもありません...他に何がありますか？

編集：内部ネットワークエラーからの接続要求

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

指示しますtcpdumpWLAN1インターフェース（経由でトラフィックを探しに-i=「インタフェース」）、専用ポート22を介して、DNSの名前解決（無視-n=「なし名前解決を」）、そして私たちは、着信と発信の両方のトラフィックを見たいと思って（-Q受け入れin、outまたはinout;inoutデフォルトです）。

リモートマシン経由で接続を試みている間にSSHサーバーでこのコマンドを実行すると、問題の正確な場所がすぐにわかります。基本的に、3つの可能性があります。

1. あなたは見ている場合は、着信リモートマシンからのトラフィックが、なしの発信をローカルサーバーからのトラフィック、サーバーに問題の嘘は：ニーズが変更することをファイアウォールルールなどは、おそらくあります
2. 着信と発信の両方が表示されている場合が、あなたのリモートマシンが応答を受信していない、それが最も可能性の高いルータです：それは、着信トラフィックを許可するが、あなたの発信パケットをドロップします。
3. トラフィックがまったくない場合は、おそらくルーターの問題でもあります。リモートマシンのSYNパケットは無視され、サーバーに到達する前にルーターによってドロップされます。

そして、問題がどこにあるかを発見したら、修正は（通常）些細なことです。

Mint（Ubuntu）を実行しています。

私はすべてを行いました... authorized_keys、chmodding、chowning、sshとsshdの再起動などで正しい形式の公開鍵。すべてが至る所で文書化されています。

私にとって、それはufwファイアウォールでした。sshの応答がまったくなかったため、これに気づきましたが、LANで両方向に問題なくpingを実行できました。

私がテストしたのは：

sudo ufw service stop

...それは完全に機能しました。つまり、ssh呼び出しから応答がありました。

そのため、再びufwを起動します。

sudo ufw service start

...そしてルールを追加します：

sudo ufw allow openssh

すべて正常に動作しています。

私のように、UFW（Linuxの場合はUbuntu）を有効にしている場合は、これを試してください：

sudo ufw enable OpenSSH

これにより、ファイアウォールでOpenSSHが許可されます。

他の人のためだけに：

-Qではなくtcpdumpで-Pオプションを使用する必要がありました

tcpdump -i wlan1 port 22 -n -P inout

ほとんどの場合、ファイアウォールは犯人です。やるservice iptables stopとservice ip6tables stop。

サービスの停止が機能しない場合は、iptable flushを実行します。

iptables --flush.

そのVMがホストでも同じ場合