web-dev-qa-db-ja.com

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の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            

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

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

編集:NetStatサーバー出力

SSHサーバーから:

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

非常に残念な自己回答

この問題を1日脇に置いて戻ってきたとき、私は安心し、混乱しました(安心するよりも混乱しました)。不思議なことに、すべてが正常に機能していることがわかりました。

それで、問題は何でしたか?

設定は変更または調整されていません。ルーター、SSHサーバー、SSHクライアントのマシンではありません。適切に設定されているにもかかわらず、ルーターが着信トラフィックを適切に処理していなかったと言っても過言ではありません。ちっぽけなホームルーターソフトウェアが本当にポートフォワーディングを処理するように設計されていないことを考えると、貧しい人が必要な変更を実装するのにしばらく時間がかかりました。

でも6時間くらいでした!!

ええ、私は知っています。私は一日中何が悪いのかを理解しようとして過ごしましたが、何も問題がなかったので、それを見つけることはできませんでした。明らかに、ルーターの設定が有効になるまでに6時間(場合によってはそれ以上)かかることがあります。

それで、これが私の問題であるかどうかをどうやって知ることができますか?

このエスケープ中に出くわした気の利いたツールはtcpdumpです。この痩せた小さな男はあなたのためにトラフィックを嗅ぎ、実際に何が起こっているのかについての貴重な洞察を提供します。さらに、彼はあなたが見たい/探したいものを正確に絞り込むことを可能にするいくつかのスーパーフィルタリング機能を持っています。たとえば、次のコマンドを実行します。

tcpdump -i wlan1 port 22 -n -Q inout

tcpdumpにwlan1インターフェースを介してトラフィックを探すように指示します(-i = 'インターフェイス')、ポート22を介してのみ、DNS名前解決を無視します(-n = '名前解決なし')、そして着信トラフィックと発信トラフィックの両方を見たい(-Qinout、またはinoutを受け入れます。 inoutがデフォルトです)。

リモートマシン経由で接続しようとしているときにSSHサーバーでこのコマンドを実行すると、問題がどこにあるのかがすぐに明らかになります。基本的に、3つの可能性があります。

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

そして、問題がどこにあるかを発見したら、修正は(通常)簡単です。

1