謎を解く方法は次のとおりです。目標は、標準のUbuntuユーティリティを使用してシステム上のプロセスの詳細を掘り下げることにより、ユーザーに「釣り方」を教えることです。
ステップ＃1（主に好奇心のため）：どのプログラムがこのエラーを出しているのかを特定します：
# -- You may need to search under more dirs, YMMV
# List files (incl. binaries) which contain the warning string
$ sudo grep -ral 'malicious client may be eavesdropping' /usr /bin /lib
/usr/lib/openssh/gnome-ssh-askpass
私の環境では、この警告文字列をバイナリに含む唯一のプログラムはgnome-ssh-askpassです。この特定のプログラムにバグがあるかどうかを検索し、さらにソースをダウンロードしてapt-get source ssh-askpass-gnome（パッケージ名がプログラム名と異なることに注意してください）、さらに調査することができます。
ただし、根本的な原因はの問題ではないと思われgnome-ssh-askpassます。gnome-ssh-askpassパスフレーズを要求しているので、開発者はキーボードをつかまない場合に注意を怠って、最悪のシナリオを想定し、メッセージを非常に偏執的に聞こえるようにしました。しかし、偶然にパスフレーズやパスワードをランダムなWebサイトのダイアログボックスに入力することは、おそらく良い考えではないことに注意してくださいgnome-ssh-askpass。
最近、ますます多くのWebサイトが、ポップアップの表示、ポップアップダイアログ以外のすべての表示のフェードアウト、および積極的なフォーカスの獲得に取り組んでいます。これがgnome-ssh-askpass、キーボードの取得に失敗した根本的な原因である可能性があります。そのようなサイトでブラウザを開いている場合は、ブラウザを閉じるか、攻撃的なWebサイトから移動してください。これが原因である場合、個々のプロセスが完全な（フルデスクトップ）フォーカスを取得できないようにするデスクトップ設定に関心があるかもしれません。たとえば、KDEでは、この設定は（[システム]-[設定]-> [ウィンドウの動作]-> [フォーカス]-> [フォーカスの盗難防止]）にあります。もしあなたが本当に妄想を感じているなら、Highまたはに設定することをお勧めしますExtreme。もちろん、これも防ぐことができますgnome-ssh-askpassキーボードをつかむこと自体、より正確には、Xフォーカスをつかむことです。
ステップ＃2：疑わしいプロセスを特定する：
Unixでは、デバイスはファイルuderのように見えることを知っている/devため、次の質問は、ファイルシステム階層で「キーボード」を表すデバイスは何かということです。これにはlsof（開いているファイルを一覧表示する）ユーティリティを使用できます。
# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'
典型的なデスクトップ環境でデバイスを開いたままにしているプロセスのほとんどが/dev/pts/<N>（擬似tty）開いたままになっていることに注意してください。これらは関心のある「デバイス」です。
ここで何が起こっているかの背景：
典型的なLinuxグラフィカルデスクトップでは、プロセスはキーボードと直接対話しません。代わりに、Xプログラム（Xorg）はdeviceを介してすべてのキーボードイベントを制御します/dev/input/event<N>。X特にキーボードイベントを処理するイベントハンドラー（evdev）を使用します。Xログを見て、これを確認することもできます。/var/log/Xorg.0.logどこkeyboard言及されています。
キーボードイベントは、Xイベントハンドラから、で開いているプロセス標準入力を介して、マウスポインタがフォーカスされているプロセスにいつでも転送され/dev/pts/<N>ます。厳密に言えば：プロセスは、実際に「キーボードをつかむ」しない、キーボードがで開催されX、プロセスが唯一持っている（またはグラブ）「フォーカス」やの注意Xので、Xオープン標準入力ファイルディスクリプタ上を経由して、それにキーボードイベントを転送することができます/dev/pts/<N>。
ステップ＃3：特定の時点でどのプロセスがXorgに焦点を当てていますか？
どのプロセスが特定の時間にフォーカスを持っているかをどのように把握しますか？これに答えるaskubuntuの質問は次のとおりです。
マウスの下でアプリケーションを見つける
答えの要約は、マウスでナビゲートしながら端末で次のようなスクリプトを実行することです。
#!/bin/bash
# Print the process tree of the window currently in focus.
# prereqs:
# sudo apt-get install xdotool psmisc
while true; do
pstree -spaul $(xdotool getwindowpid "$(xdotool getwindowfocus)")
sleep 2
done
ステップ＃4：プロセスアクティビティをより深く掘り下げる
疑わしいプロセスを特定したら、最後のステップはこの個々のプロセスを調査することです。そのためには、Linux /procファイルシステム（man 5 proc）を使用できます。
プロセスについて知りたいことはほとんど何でも入手可能です/proc。実際、lsof（開いているファイルを一覧表示する）プログラム、プロセスの状態を調べるデバッガー、psまたはなどのプロセス一覧表示ユーティリティtopはすべて/proc、カーネルがデータを取り込むのに依存しています。
を使用procすると、プロセス実行可能プログラムがディスク上のどこにあるかを見つけることができます（たとえば、標準システムディレクトリ外のプログラム、特に「私に注意を払わない」で隠そうとしている場合）種類の名前で場合は疑わしい）デバッガーまたはシステムコールトレーサーを使用すると、システムコールレベルで何を行っているかを正確に調べることができます（ソースコードがない場合でも）。
ステップ2と3はPID、キーボードを潜在的に読み取っている可能性のあるすべてのプロセスIDを提供するはずです。これらの各PIDSについて（それぞれをとして示しましょう$pid）、次のことができます。
$ pidを完全なコマンドラインにマッピングします。
cat /proc/$pid/cmdline
$ pidをディスク上の実行可能ファイルにマッピングします。
ls -l /proc/$pid/exe
$ pidを現在の作業ディレクトリにマップします。
ls -l /proc/$pid/cwd
$ pidを元の環境にマッピングします
cat /proc/$pid/environ | tr '\000' '\012'
$ pid（およびその子プロセス）のシステムコールアクティビティをリアルタイムでトレースします。
strace -f -p $pid
（他にもあります：を参照man 5 proc）
を介してファイルに保存するwriteか、ネットワーク経由sendtoでに送信することにより、すべてのキープレスに反応するなじみのないプロセスが表示される場合は、キーボードスニファーが見つかりました。
また、どのプロセスが（tcp + udp）ネットワークエンドポイントを開いているかを確認することもできます。
# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee
結論：
エラーの原因として最も可能性が高いのはマルウェアではなく、複数のプロセスが同時にキーボード制御を取得しようとしていることです。2つgnome-ssh-askpassのうちの1つ（エラーを出力するもの）です。もう1つは、積極的なフォーカス取得ダイアログボックスを備えたサイトで開かれているブラウザです。
マルウェアが実際にインストールされている可能性はほとんどありませんが、幸いなことに、Linuxを使用しているため、すべてのプロセスが透過的に調査および検査されます。マルウェアが実際にあなたから隠れたり、上記の手法を使用して簡単に見つけたり、プロセスを殺したり、すべてのファイルを削除したりするのを防ぐことは非常に困難です。