リモート Debian システムによるログオンの防止

リモート Debian システムによるログオンの防止

私はネットワーク上に Debian (squeeze) を実行しているシングルボード コンピュータを 12 台ほど所有しており、ssh 経由でアクセスしています (ssh サーバーは dropbear)。これらのコンピュータのハードウェアの概要を説明すると、1.2 GHz x86 プロセッサ、1 GB の RAM、ext2 でフォーマットされた 4 GB のフラッシュ ドライブ (ジャーナリングによるフラッシュ書き込みのストレスが増すのを防ぐため、ext3 は使用していません) があり、ドライブにはスワップ パーティションもあります。

通常、使用しているセットアップはうまく機能し、すべてのコンピューターにアクセスできます。 時々、アクセスが妨げられることがあります。 何が起こるかというと、ssh (putty) 経由で接続しようとすると、ログイン プロンプトが表示され、ユーザー名とパスワードを入力すると、「アクセスが拒否されました」という応答があり、~/.ssh/authorized_keys 内の公開キーも拒否されます。 資格情報は以前と同じように正しいです。 コンピューターは ping に応答し、putty はサーバーの公開キーを認識します。これは、システムがまだ実行されていることを意味します。 サーバーを再起動すると問題が解決し、再度ログインできます。 (一時的な修正として、ルート crontab に shut down -r now を入れることを試みましたが、ハングが発生すると、これは確実に実行されないようです) ただし、再起動すると、システム ログのいずれにも何が起こったかを示す情報がないようです。システムがクラッシュしたかのように、その期間のログは単に空です。

システム上で実行されているカスタム ソフトウェアが動作を停止しているようです (これが、最初に ssh を実行したかった理由です)。このプログラムが問題の原因であると想定していますが、それがどのように発生するのか、また、何が起こっているのかをデバッグする方法がわかりません。

私が考えられる最も可能性の高い説明は、他のプログラムでメモリ リークが発生し、空きメモリが不足しているため、dropbear が新しいログイン シェルを起動できない (および crontab がシャットダウンを実行できない) というものです。ただし、他の (動作している) コンピュータのメモリ使用量を見ると、リークを示すメモリの増加は見られません (非常に大きく、高速で、まれなリークでない限り)。OS のメモリが不足すると、システムが再起動するか、プロセスが強制終了されると思います (Linux カーネルは再起動しますよね?)。他に疑問に思うのは、フラッシュ ドライブで実行されていることが、特にスワップ パーティション (フラッシュの摩耗を防ぐために削除する必要があると思います) に何らかの影響があるかどうかですが、フラッシュ ドライブは新しい (約 1 か月) ため、摩耗はまだ要因ではないと思います。

これらの症状の原因がメモリ リークによるものか、あるいは私が考えていない他の何かによるものか、誰かわかる人はいませんか。また、問題をデバッグして何が問題なのかについてさらに情報を得る方法を誰か知っていますか。

答え1

結局、問題は私が使用していた特定のフラッシュ ドライブに関係していることがわかりました。そのドライブには特殊な「U3」ジャンクが付いていて、完全にアンインストールしないと Linux で問題が発生する可能性があるようです。とにかく、より「ライブ」タイプのインストールに切り替える方がよいと判断しました。現在は、起動時にルート ファイル システムを RAM に転送してそこから実行しているので、フラッシュ ドライブはシステムの実行を継続するのに重要ではありません。

http://live.debian.net/manual/

関連情報