web-dev-qa-db-ja.com

VirtualBoxを使用してUbuntuServer仮想マシンにログインすると、SSHセッションが応答しなくなります

私は本当にここで私の知恵の終わりにいるので、ここの誰かが私を助けてくれることを願っています。 Ubuntu Server9.10を実行している仮想マシンがあります。これは小さな開発環境なので、コードをテスト環境や本番環境から分離しておくことができます。 Ubuntuデスクトップ9.10を実行しているラップトップでVirtualBox3.1.6を介して実行しています。ブリッジネットワーク接続でセットアップし、ラップトップのワイヤレスアダプターにブリッジしました。このオフィスには有線接続がありません。

VMを起動すると、すべて問題ありません。gnome-terminalを使用してSSHで接続でき、しばらくの間、すべてがコーシャです。その後、ランダムに見えるように、SSHターミナルセッションがハングします。エラーメッセージはありません。 、何もありません。応答しなくなります。VirtualBoxターミナルにアクセスすると、VM自体は完全に問題ありません。pingを実行でき、SSHで接続できます。ネットワークを再起動するとVM gnome-terminalのSSHセッションは、ほとんどの場合、再び応答するようになります。

ここに興味深い点があります。SSHセッションは、何かを入力している最中に終了することがあります(これは、アイドルセッションの問題ではないことを示しています)。VirtualBoxターミナルに移動してネットワークを再起動し、gnomeに戻ると-ターミナルSSHセッションそれが生き返り、セッションが最初にハングしたときに入力したものが魔法のようにバッファに入力されることがわかりました。したがって、私の入力はどこかに保存されており、VMのネットワークが再起動されるまで、VM.

さまざまなバージョンのVirtualBoxを試し、vmdkイメージとvdiイメージを使用しましたが、何も機能しないようです。問題がラップトップ、VirtualBox、またはUbuntu ServerVDIのいずれにあるのかわかりません。この問題をデバッグする方法はありますか?それとも、似たようなものを見た人はいますか?

5
nickbart

OK、それで問題の根本原因を見つけました。それはとても単純なので、少し恥ずかしいです。ネットワークIPの競合です。それは私が推測したように確かにネットワークの問題でした、しかしそれは私がそれを作っているほど複雑ではありませんでした。

ブリッジネットワークを使用しているため、VMは、ネットワーク上の他のすべてのマシンとともにDHCPクライアントテーブルに表示されます。これらの他のマシンのいずれかがDHCPからVMのIPを取得した場合(たとえば、私が起動する前にVMその日のために)それは私のVMがオンラインになるたびに競合を引き起こし、私のVM SSHへの応答を停止します。これは、VirtualBox端末を使用していたときにまったく問題が発生しなかった理由を説明しています。

ほとんどのルーターがIPの競合をどのように処理するかは正確にはわかりませんが、ネットワークアクティビティが最後に発生したマシンが優先されるようです。したがって、自分のマシンでネットワークをバウンスしたとき、IPを共有しているマシンがネットワークアクティビティを実行することを決定し、その後BOOM ...接続がハングするまでは問題ありませんでした。

VMの静的ネットワークIPを範囲内でかなり高くなるようにリセットしました。これにより、同僚のマシンとのIPの競合が回避されることを願っています。

1
nickbart

これがsshセッションを存続させる正しい方法です

リモートサーバー側を所有している場合は、SSHデーモン構成ファイルを編集します

Sudo vi /etc/ssh/sshd_config  #  on your server

これらの行を追加します

ClientAliveInterval 120 # server sends clients "null packet" every 120 seconds
ClientAliveCountMax 720 # allow clients to stay alive for  720 intervals

720間隔===(120秒* 720 = 86400秒= 24時間)

または、サーバー側を所有していない場合は、ローカルマシン(ラップトップ)でこの変更を行います

vi  ~/.ssh/config   #  on local Host NOT on server

ServerAliveInterval 120
1
Scott Stensland

まあ、私はこの問題の根本的な原因を見つけたことはありませんが、それは間違いなくネットワークに関連したものです。ここには確かにほんの一握りのCiscoルーターがあるので、公式の答えはそこにあるかもしれません。しかし、私は回避策を思いついた。非常に単純なシェルスクリプトを作成しました。これは、rootユーザーの下でクローンを作成して毎分実行します。

#!/bin/bash

#keep-alive.sh

/etc/init.d/networking restart
/etc/init.d/ssh restart

これは、ネットワークとOpenSSHをVMサーバーで毎分バウンスします。これはハッキーでエレガントなソリューションですが、SSHセッションが永続的にハングするのを防ぎます。これが許容できると思う唯一の理由はそれは仕事を成し遂げ、それは小さなVMサーバー開発環境のためだけです。当然のことながら、私は絶対にこの種のことをいかなる種類の実稼働環境にも推奨していません。

0
nickbart

私はブリッジ接続とワイヤレスが一緒に機能していることに気づいていませんでした-少なくとも私が試したほとんどのVMでは。 natまたはHostのみを使用して、それを機能させることができるかどうかを確認する必要があります。

0
Journeyman Geek

入力していますか Ctrl+S、(レガシーの理由で)セッションを停止する可能性がありますか?押す Ctrl+Q これらの時間の1つは凍結し、凍結が解除されるかどうかを確認します。

0
indiv