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
...そして他にファイアウォールはありません-比較的新しいDebian 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
tcpdumpに、wlan1インターフェース（-i = 'interface'）、ポート22のみ、DNS名前解決を無視（-n = '名前解決なし'）、着信トラフィックと発信トラフィックの両方を確認したい（-Qはin、out、またはinoutを受け入れます。 inoutがデフォルトです）。
リモートマシン経由で接続を試みているときにSSHサーバーでこのコマンドを実行すると、問題の正確な場所がすぐに明らかになります。基本的に、3つの可能性があります。
- リモートマシンからのincomingトラフィックが表示されているが、ローカルサーバーからのoutgoingトラフィックが表示されている場合、問題はサーバーにあります。ファイアウォールルールにより、変更されるなど.
- 受信と送信の両方が表示されていても、リモートマシンが応答を受信していない場合は、ルーターである可能性があります。これは、受信トラフィックを許可していますが、送信パケットをドロップしています。
- トラフィックがまったくないの場合は、おそらくルーターの問題でもあります。リモートマシンの
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が許可されます。
ほとんどの場合、ファイアウォールが原因です。行うservice iptables stopおよびservice ip6tables stop。
サービスの停止が機能しない場合は、iptable flushを実行します。
iptables --flush.
A VMの場合、ホストでも同じようにします
他の人のために：
-Qの代わりにtcpdumpで-Pオプションを使用する必要があった
tcpdump -i wlan1 port 22 -n -P inout