¿Cómo debo depurar el error "No se pudo tomar el teclado. Un cliente malintencionado puede estar espiando tu sesión ".

Estoy ejecutando una instalación de Ubuntu 14.04 que configuré más de 6 meses. Hace aproximadamente una semana, comencé a recibir un mensaje de error:

Could not grab keyboard. A malicious client may be eavesdropping on your session.

Solo lo he visto cuando vuelvo a mi computadora después de estar ausente durante bastante tiempo (generalmente de la noche a la mañana). Varias veces ha evitado que la pantalla se bloquee después del tiempo de espera establecido (he comenzado a bloquearla activamente antes de salir).

Estoy usando un teclado usb (Kinesis Advantage) conectado directamente a un puerto usb en la placa base. Estoy usando un mouse inalámbrico ELECOM .

Voy a intentar desconectar la llave del mouse antes de irme. ¿De qué otra forma podría identificar si hay un cliente malintencionado que rastrea mis pulsaciones de teclas o si se trata de un problema de conectividad?

Aquí te explicamos cómo resolver tu misterio. El objetivo es más enseñar a los usuarios "cómo pescar" mediante el uso de utilidades estándar de Ubuntu para profundizar en los detalles de cualquier proceso en su sistema.

Paso # 1 (principalmente por curiosidad): identifica qué programa te está dando este error:

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

En mi entorno, el único programa que contiene esta cadena de advertencia en su binario es gnome-ssh-askpass. Podría buscar si hay un error archivado en este programa en particular e incluso descargar su fuente apt-get source ssh-askpass-gnome(tenga en cuenta que el nombre del paquete es diferente al nombre del programa) para una inspección adicional.

Sin embargo, sospecho que la causa raíz no es un problema gnome-ssh-askpass. Como gnome-ssh-askpassestá solicitando su frase de contraseña, sus desarrolladores simplemente eligieron errar por precaución cuando no agarran el teclado, asumen el peor de los casos y hacen que el mensaje suene súper paranoico. Pero tenga en cuenta que escribir su frase de contraseña o contraseña en un cuadro de diálogo aleatorio de un sitio web por accidente probablemente no sea una buena idea, por lo que, en ese sentido, los gnome-ssh-askpassdesarrolladores han tomado la decisión correcta.

Recientemente, cada vez más sitios web han comenzado a participar en la práctica de mostrar una ventana emergente, desvanecer todo lo demás fuera del cuadro de diálogo emergente y enfocarse agresivamente. Esta podría ser la causa principal de gnome-ssh-askpassno poder agarrar el teclado. Si su navegador está abierto en dicho sitio, puede ser útil cerrar el navegador o navegar fuera del sitio web agresivo. Si esta es la causa, es posible que le interese una configuración de escritorio que evite que los procesos individuales capten el enfoque completo (escritorio completo). En KDE, por ejemplo, esta configuración se puede encontrar en ( Configuración del sistema -> Comportamiento de la ventana -> Enfoque -> Prevención de robo de foco ). Si te sientes realmente paranoico, te recomendaría configurarlo en Higho Extreme. Por supuesto, esto también puede prevenirgnome-ssh-askpassde agarrar el teclado, o más exactamente: agarrar el Xfoco.

Paso # 2: Identificar procesos sospechosos:

Sabiendo que en Unix, los dispositivos aparecen como archivos uder /dev, la siguiente pregunta es qué dispositivo representa "el teclado" en la jerarquía del sistema de archivos. Podemos usar la utilidad lsof(lista de archivos abiertos) para esto.

# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'

Tenga en cuenta que la mayoría de los procesos que contienen dispositivos abiertos en un entorno de escritorio típico mantienen /dev/pts/<N>(un pseudo tty ) abierto. Estos son los "dispositivos" de interés.

En un escritorio gráfico típico de Linux, los procesos no hablan directamente con el teclado. En cambio, el Xprograma (Xorg) controla todos los eventos del teclado a través de un dispositivo /dev/input/event<N>. Xutiliza un controlador de eventos (evdev) que, entre otras cosas, maneja eventos de teclado. También puede verificar esto mirando el Xregistro: /var/log/Xorg.0.logdonde keyboardse menciona.

Los eventos del teclado se reenvían desde el Xcontrolador de eventos al proceso que tiene el foco del puntero del mouse en cualquier momento a través de la entrada estándar del proceso que está abierta /dev/pts/<N>. En sentido estricto: un proceso en realidad no "agarrar el teclado", el teclado está en manos de X, el proceso sólo tiene (o juego) "enfoque" o la atención de Xlo que Xpuede reenviar los eventos de teclado para que a través de un descriptor de archivo abierto sobre la entrada estándar /dev/pts/<N>.

Paso # 3: ¿qué proceso tiene el foco Xorg en un momento particular?

¿Cómo calcular qué proceso tiene el foco en un momento particular? Aquí hay una pregunta de askubuntu que responde a esto:

descubre la aplicación bajo el mouse

El resumen de la respuesta es ejecutar un script como el siguiente en una terminal mientras navega con el mouse:

#!/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

Paso # 4: profundiza en la actividad del proceso

Una vez que haya identificado un proceso sospechoso, el último paso es investigar este proceso individual. Para eso, puede recurrir al sistema de /procarchivos Linux ( man 5 proc).

Casi todo lo que desee saber sobre un proceso está disponible en /proc. De hecho, los programas como lsof(listar archivos abiertos), depuradores que examinan el estado del proceso y utilidades de listado de procesos como pso top, todos dependen de los /procque se encuentran en el núcleo para obtener datos.

Usando procpuede encontrar dónde está el programa ejecutable del proceso en el disco (por ejemplo, cualquier programa fuera de los directorios estándar del sistema, especialmente si está tratando de esconderse bajo un tipo de nombre "no me preste atención" , puede ser sospechoso) y usar un depurador o rastreador de llamadas del sistema puede examinar qué están haciendo exactamente en el nivel de llamadas del sistema (incluso si no tiene su código fuente).

Los pasos 2 y 3 deberían proporcionarle todas las ID de proceso PIDque pueden estar leyendo su teclado. Para cada uno de estos PIDS (denotémoslos como $pid) puede:

Asigne $ pid a su línea de comando completa:

cat /proc/$pid/cmdline

Asigne $ pid a su ejecutable en el disco:

ls -l /proc/$pid/exe

Asigne $ pid a su directorio de trabajo actual:

ls -l /proc/$pid/cwd

Mapa $ pid a su entorno original

cat /proc/$pid/environ | tr '\000' '\012'

Rastree la actividad de llamada al sistema $ pid (y sus hijos-procs) en tiempo real:

strace -f -p $pid

(Hay más: ver man 5 proc)

Si ve un proceso desconocido que reacciona a cada pulsación de tecla almacenándolo en un archivo (vía write) o enviándolo a través de la red a través de sendto, es posible que haya encontrado un rastreador de teclado.

También puede verificar qué procesos tienen abiertos los puntos finales de red (tcp + udp):

# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee

Línea de fondo:

La causa más probable del error no es el malware, sino múltiples procesos que intentan obtener el control del teclado al mismo tiempo. Uno de los dos es gnome-ssh-askpass(el que imprime el error). El otro puede ser un navegador abierto en un sitio con un cuadro de diálogo de enfoque agresivo.

Incluso en la remota posibilidad de que tengas algún malware instalado, la buena noticia es que, dado que estás en Linux, todos los procesos son transparentes para que puedas investigarlos e inspeccionarlos. Sería muy difícil para el malware realmente esconderse de usted o evitar que lo localice fácilmente utilizando las técnicas anteriores, eliminando sus procesos y eliminando todos sus archivos.

Mi problema se debió a dos gnome-ssh-askpassventanas simultáneas . Tuve dos trabajos rsync en el mismo servidor a través de SSH, y ambos intentaron pedir la contraseña del certificado SSH. ¡Agruparlos (y encadenarlos) juntos me resolvió!