☰

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

...そして他のファイアウォールはインストールされていません。これは比較的新しいDebian netinstです。

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

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

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

答え1

非常に残念な自己回答

問題を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上で双方向にpingを送信することに問題はありませんでした。

私のテストに合格しました：

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

仮想マシンの場合は、ホストでも同じことを行います。

関連情報