У меня установлена Ubuntu 14.04, которую я установил более 6 месяцев. Около недели назад я начал получать сообщение об ошибке:
Could not grab keyboard. A malicious client may be eavesdropping on your session.
Я видел его только когда возвращался на свой компьютер после долгого отсутствия (обычно в течение ночи). Несколько раз это препятствовало блокировке экрана после установленного времени ожидания (я начал активно блокировать его перед уходом).
Я использую USB-клавиатуру (Kinesis Advantage), напрямую подключенную к USB-порту на материнской плате. Я использую беспроводную мышь ELECOM .
Я собираюсь попробовать отключить ключ мыши перед уходом. Как еще я могу определить, есть ли вредоносный клиент, отслеживающий мои нажатия клавиш, или это проблема с подключением?
Вот то, как решить Вашу тайну. Цель больше для обучения пользователей, "как ловить рыбу" при помощи стандартных утилит Ubuntu для рытья в детали любого процесса в их системе.
# -- 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
В моем ENV единственная программа, которая содержит эту строку предупреждения в ее двоичном файле, gnome-ssh-askpass
. Я мог искать, если существует ошибка, зарегистрированная на этой конкретной программе, и даже загрузите ее источник apt-get source ssh-askpass-gnome
(обратите внимание, что имя пакета отличается, чем название программы) для дальнейшего контроля.
Однако я подозреваю, что первопричиной не является проблема в gnome-ssh-askpass
. С тех пор gnome-ssh-askpass
просит Ваш пароль, его разработчики просто приняли решение допустить ошибку на стороне осторожности при отказе захватить клавиатуру, принять худший вариант и заставить сообщение звучать uber-параноидальным. Но обратите внимание, что ввод Вашего пароля или пароля в некоторое случайное диалоговое окно веб-сайта случайно является, вероятно, не хорошей идеей, так в этом смысле gnome-ssh-askpass
разработчики выполнили правильный вызов.
Недавно все больше веб-сайтов начало участвовать в практике отображения всплывающего окна, исчезновения все остальное вне всплывающего диалогового окна и настойчиво захвата фокуса. Это могло бы быть первопричиной для gnome-ssh-askpass
отказ захватить клавиатуру. Если, при этом Ваш браузер открыт на таком сайте, закрывая браузер или перейдя далеко от агрессивного веб-сайта, может помочь. Если это - причина, можно интересоваться настольной установкой, препятствующей тому, чтобы отдельные процессы захватили полное (полный рабочий стол) фокус. В KDE, например, эта установка может быть найдена под (Параметры настройки системы-> поведение Окна-> Фокус-> предотвращение кражи Фокуса). Если бы Вы чувствуете себя действительно параноиками, я рекомендовал бы установить его на High
или Extreme
. Конечно, это может также предотвратить gnome-ssh-askpass
самостоятельно от захвата клавиатуры, или более точно: захват X
фокус.
Зная, что в Unix, устройства появляются как вымя файлов /dev
, следующий вопрос - то, какое устройство представляет "клавиатуру" в иерархии файловой системы. Мы можем использовать lsof
(перечислите открытые файлы), утилита для этого.
# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'
Заметьте, что большинство зажимных приспособлений процессов, открытых в типичном настольном ENV, содержит /dev/pts/<N>
(псевдо tty) открытый. Это "устройства" интереса.
В типичном Linux графический рабочий стол процессы не говорят с клавиатурой непосредственно. Вместо этого X
программа (Xorg) управляет всеми событиями клавиатуры через устройство /dev/input/event<N>
. X
использует обработчик событий (evdev) который среди прочего, события клавиатуры дескрипторов. Можно также проверить это путем взгляда на X
журнал: /var/log/Xorg.0.log
где keyboard
упоминается.
События клавиатуры передаются от X
обработчик событий к процессу, который имеет фокус указателя мыши в любое время через процесс, введенный стандартом, который открыт на /dev/pts/<N>
. Строго говоря: процесс на самом деле "не захватывает клавиатуру", клавиатура сохранена X
, процесс только имеет (или захваты) "фокус" или внимание X
так X
может передать события клавиатуры ему через открытый stdin дескриптор файла на /dev/pts/<N>
.
Как фигурировать, какой процесс имеет фокус в какое-либо конкретное время? Вот 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
После того как Вам определили подозрительный процесс, последний шаг должен исследовать этот отдельный процесс. Для этого можно обратиться к Linux /proc
файловая система (man 5 proc
).
Почти что-либо, что можно хотеть знать о процессе, доступно под /proc
. На самом деле, программы как lsof
(перечислите открытые файлы), отладчики, которые исследуют состояние процесса и перечисляющие процесс утилиты как ps
или top
, все полагаются /proc
который заполняется ядром для данных.
Используя proc
можно найти, где исполняемая программа процесса находится на диске (например, любая программа вне стандартных системных каталогов, особенно если это пытается скрыться под, "не обращают внимание на меня" вид имени, может быть подозреваемый), и использование отладчика или трассировщика системного вызова, можно исследовать то, что точно является ими делающий на уровне системного вызова (даже если у Вас нет их исходного кода).
Шаги № 2 и № 3 должны дать Вам все идентификаторы процесса (PID
s) это может потенциально читать Вашу клавиатуру. Для каждого из этих 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 трассировки (и его дети-procs) действие системного вызова в режиме реального времени:
strace -f -p $pid
(Существует больше: посмотрите man 5 proc
)
Если Вы видите незнакомый процесс, который реагирует на каждое нажатие клавиши путем хранения его в файл (через write
) или отправка его по сети к через sendto
, Вы, возможно, нашли сниффера клавиатуры.
Можно также проверить, какие процессы имеют (tcp+udp) открытые сетевые оконечные точки:
# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee
Наиболее вероятной причиной для ошибки не является вредоносное программное обеспечение, но несколько процессов, пытающихся получить контроль клавиатурой одновременно. Один из этих двух gnome-ssh-askpass
(тот, печатающий ошибку). Другой может быть открытый браузер на сайте с агрессивным получающим фокус диалоговым окном.
Даже в удаленном шансе, что у Вас на самом деле есть некоторое установленное вредоносное программное обеспечение, хорошие новости - то, что, так как Вы находитесь на Linux, все процессы прозрачны, чтобы Вы исследовали и осмотрели. Вредоносному программному обеспечению было бы очень трудно действительно скрыться от Вас или предотвратить Вас от легкого определения местоположения его с помощью вышеупомянутых методов, уничтожив его процессы, и удалив все его файлы.
Моя проблема была должна два параллельных gnome-ssh-askpass
окна. У меня было два rsync задания к тому же серверу через SSH, и оба пытались попросить пароль сертификата SSH. Группировка (и объединение в цепочку) их вместе решенный для меня!