Veja como resolver seu mistério. O objetivo é ensinar aos usuários "como pescar" usando os utilitários padrão do Ubuntu para descobrir os detalhes de qualquer processo em seu sistema.
Etapa # 1 (principalmente por curiosidade): identifique qual programa está causando este erro:
# -- 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
No meu env o único programa que contém essa sequência de aviso em seu binário é gnome-ssh-askpass . Eu poderia pesquisar se há um bug arquivado neste programa em particular, e até mesmo fazer o download de sua fonte apt-get source ssh-askpass-gnome (observe que o nome do pacote é diferente do nome do programa) para uma inspeção mais detalhada.
No entanto, suspeito que a causa raiz não seja um problema em gnome-ssh-askpass . Como gnome-ssh-askpass está pedindo sua frase-senha, seus desenvolvedores simplesmente optaram por tomar cuidado ao falhar em pegar o teclado, assumir o pior cenário possível, e fazer a mensagem soar paranóica. Mas note que digitar sua senha ou senha em alguma caixa de diálogo aleatória do site por acidente provavelmente não é uma boa idéia, então nesse sentido os desenvolvedores gnome-ssh-askpass fizeram a chamada certa.
Recentemente, mais e mais sites começaram a se envolver na prática de exibir um pop-up, desvanecendo tudo o que está fora da caixa de diálogo pop-up e capturando agressivamente o foco. Esta pode ser a causa raiz de gnome-ssh-askpass não conseguir pegar o teclado. Se o seu navegador estiver aberto em tal site, fechar o navegador ou sair do site agressivo pode ajudar. Se essa for a causa, talvez você esteja interessado em uma configuração de área de trabalho que impede que processos individuais capturem o foco completo (área de trabalho inteira). No KDE, por exemplo, esta configuração pode ser encontrada em ( Configurações do Sistema - & gt; Comportamento da janela - & gt; Foco - & gt; Prevenção do furto de foco ). Se você se sentir realmente paranóico, recomendo que você o defina como High ou Extreme . Naturalmente, isso também pode impedir que o próprio gnome-ssh-askpass pegue o teclado, ou com mais precisão: pegando o X focus.
Etapa 2: identifique processos suspeitos:
Sabendo que no Unix, os dispositivos aparecem como arquivos /dev , a próxima pergunta é qual dispositivo representa "o teclado" na hierarquia do sistema de arquivos. Podemos usar o utilitário lsof (list open files) para isso.
# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'
Observe que a maioria dos processos que contêm dispositivos abertos em um ambiente de trabalho típico está contendo /dev/pts/<N> (um pseudo tty ) aberto. Estes são os "dispositivos" de interesse.
Em uma área de trabalho gráfica típica do Linux, os processos não falam diretamente com o teclado. Em vez disso, o programa X (Xorg) controla todos os eventos do teclado através de um dispositivo /dev/input/event<N> . X usa um manipulador de eventos (evdev) que, entre outras coisas, manipula eventos de teclado. Você também pode verificar isso observando o X log: /var/log/Xorg.0.log onde keyboard é mencionado.
Os eventos do teclado são encaminhados do manipulador de eventos X para o processo que tem o ponteiro do mouse focalizado a qualquer momento por meio da entrada padrão do processo, que é aberta em /dev/pts/<N> . Estritamente falando: um processo na verdade não "pega o teclado", o teclado é mantido por X , o processo tem apenas (ou agarra) "foco" ou a atenção de X so X pode encaminhar eventos de teclado para ele através de um descritor de arquivo stdin aberto em /dev/pts/<N> .
Passo # 3: qual processo tem o foco do Xorg a qualquer momento?
Como descobrir qual processo tem o foco em um determinado momento? Aqui está uma pergunta do askubuntu respondendo isto:
O resumo da resposta é executar um script como o seguinte em um terminal enquanto navega com o 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
Etapa 4: aprofundar a atividade do processo
Depois de identificar um processo suspeito, a última etapa é investigar esse processo individual. Para isso, você pode usar o sistema de arquivos /proc do Linux ( man 5 proc ).
Quase tudo o que você pode querer saber sobre um processo está disponível em /proc . Na verdade, programas como lsof (lista de arquivos abertos), depuradores que examinam o estado do processo e utilitários de lista de processos como ps ou top , dependem do /proc que é preenchido pelo kernel, para dados.
Usando proc você pode encontrar onde o programa executável do processo está no disco (por exemplo, qualquer programa fora dos diretórios padrão do sistema, especialmente se ele está tentando esconder em um "não me preste atenção" tipo de nome, pode ser suspeito) e usando um depurador ou tracer chamada do sistema, você pode examinar o que exatamente eles estão fazendo no nível de chamada do sistema (mesmo se você não tiver seu código-fonte).
Os passos 2 e 3 devem fornecer-lhe todos os IDs do processo ( PID s) que possam potencialmente ler o seu teclado. Para cada um destes PIDS (vamos denotar cada um como $pid ) você pode:
Mapeie $ pid para sua linha de comando completa:
cat /proc/$pid/cmdline
Mapeie $ pid para seu executável no disco:
ls -l /proc/$pid/exe
Mapeie $ pid para seu diretório de trabalho atual:
ls -l /proc/$pid/cwd
Mapeie $ pid para o ambiente original
cat /proc/$pid/environ | tr 'strace -f -p $pid
0' '2'
Rastreie a atividade de chamada de sistema $ pid (e seus filhos-procs) em tempo real:
# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee
(Há mais: veja man 5 proc )
Se você vir um processo desconhecido que reage a cada pressionamento de tecla armazenando-o em um arquivo (via write ) ou enviando-o pela rede para sendto , talvez tenha encontrado um farejador de teclado.
Você também pode verificar quais processos têm pontos de extremidade de rede (tcp + udp) abertos:
%pre%Conclusão:
A causa mais provável do erro não é malware, mas vários processos tentando obter o controle do teclado ao mesmo tempo. Um dos dois é gnome-ssh-askpass (aquele que imprime o erro). O outro pode ser um navegador aberto em um site com uma caixa de diálogo de aquisição de foco agressiva.
Mesmo na remota chance de que você tenha algum malware instalado, a boa notícia é que, como você está no Linux, todos os processos são transparentes para você pesquisar e inspecionar. Seria muito difícil que o malware realmente se escondesse de você ou impedisse que você o localizasse facilmente usando as técnicas acima, matando seus processos e removendo todos os seus arquivos.