Veja como resolver seu mistério. O objetivo é ensinar aos usuários "como pescar" usando os utilitários padrão do Ubuntu para investigar os detalhes de qualquer processo em seu sistema.
Etapa 1 (principalmente por curiosidade): identifique qual programa está causando esse 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 ambiente, o único programa que contém essa string de aviso no seu binário é gnome-ssh-askpass. Eu poderia procurar se há um bug registrado nesse programa em particular e até baixar sua fonte apt-get source ssh-askpass-gnome(observe que o nome do pacote é diferente do nome do programa) para uma inspeção mais aprofundada.
No entanto, suspeito que a causa raiz não seja um problema gnome-ssh-askpass. Como gnome-ssh-askpassestá solicitando sua senha, seus desenvolvedores simplesmente optaram por agir com cautela ao não agarrar o teclado, assumir o pior cenário possível e fazer a mensagem parecer super-paranóica. Mas observe que digitar sua senha ou senha em alguma caixa de diálogo aleatória do site por acidente provavelmente não é uma boa ideia; portanto, nesse sentido, os gnome-ssh-askpassdesenvolvedores fizeram a ligação certa.
Recentemente, mais e mais sites começaram a se engajar na prática de exibir um pop-up, esmaecendo tudo o resto fora da caixa de diálogo pop-up e agarrando agressivamente o foco. Essa pode ser a causa principal da gnome-ssh-askpassfalha ao agarrar o teclado. Se o seu navegador estiver aberto nesse site, fechar o navegador ou navegar para fora do site agressivo pode ajudar. Se essa for a causa, você pode estar interessado em uma configuração da área de trabalho, impedindo que processos individuais obtenham o foco completo (área de trabalho completa). No KDE, por exemplo, esta configuração pode ser encontrada em ( Configurações do sistema -> Comportamento da janela -> Foco -> Prevenção de roubo de foco ). Se você se sentir realmente paranóico, eu recomendaria configurá-lo para Highou Extreme. Obviamente, isso também pode impedirgnome-ssh-askpassagarrar o teclado ou, mais precisamente: agarrar o Xfoco.
Etapa 2: identificar 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 lsofutilitário (listar arquivos abertos) 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 mantêm os dispositivos abertos em um ambiente típico da área de trabalho está mantendo /dev/pts/<N>(uma pseudo-tty ) aberta. Estes são os "dispositivos" de interesse.
Alguns antecedentes sobre o que está acontecendo aqui:
Em uma área de trabalho gráfica típica do Linux, os processos não falam diretamente com o teclado. Em vez disso, o Xprograma (Xorg) controla todos os eventos do teclado através de um dispositivo /dev/input/event<N>. Xusa um manipulador de eventos (evdev) que, entre outras coisas, manipula eventos do teclado. Você também pode verificar isso consultando o Xlog: /var/log/Xorg.0.logwhere keyboardé mencionado.
Os eventos do teclado são encaminhados do Xmanipulador de eventos para o processo que tem o foco do ponteiro do mouse a qualquer momento, através da entrada padrão do processo que está aberta /dev/pts/<N>. Estritamente falando: um processo realmente não "agarra o teclado", o teclado é mantido por X, o processo só tem (ou agarra) "foco" ou a atenção de Xmodo que Xpode encaminhar eventos do teclado para ele por meio de um descritor de arquivo stdin aberto em /dev/pts/<N>.
Etapa 3: qual processo o Xorg focaliza em um determinado momento?
Como descobrir qual processo tem o foco em um determinado momento? Aqui está uma pergunta do askubuntu, respondendo a isso:
descubra o aplicativo com o mouse
O resumo da resposta é executar um script como o seguinte em um terminal enquanto navega pelo 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 recorrer ao sistema de /procarquivos Linux ( man 5 proc).
Quase tudo o que você pode querer saber sobre um processo está disponível em /proc. De fato, programas como lsof(listar arquivos abertos), depuradores que examinam o estado do processo e utilitários de listagem de processos como psou top, todos contam com o /procque é preenchido pelo kernel, para dados.
O uso de procvocê pode descobrir onde o programa executável do processo está no disco (por exemplo, qualquer programa fora dos diretórios padrão do sistema, especialmente se estiver tentando se esconder sob um tipo de nome "não preste atenção em mim" , pode ser suspeito) e usar um depurador ou rastreador de chamadas 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 o código fonte).
As etapas 2 e 3 devem fornecer todos os IDs de processo PIDque podem estar potencialmente lendo seu teclado. Para cada um desses PIDS (vamos denotar cada um como $pid), você pode:
Mapeie $ pid para sua linha de comando completa:
cat /proc/$pid/cmdline
Mapeie $ pid para o executável em disco:
ls -l /proc/$pid/exe
Mapeie $ pid para seu diretório de trabalho atual:
ls -l /proc/$pid/cwd
Mapeie $ pid para seu ambiente original
cat /proc/$pid/environ | tr '\000' '\012'
Rastreie a atividade de chamada do sistema $ pid (e seus filhos-procs) em tempo real:
strace -f -p $pid
(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 via sendto, você pode ter encontrado um sniffer de teclado.
Você também pode verificar quais processos têm pontos de extremidade de rede (tcp + udp) abertos:
# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee
Bottom line:
A causa mais provável do erro não é malware, mas vários processos que tentam 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 agressiva para aquisição de foco.
Mesmo com a chance remota de você realmente ter 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 para o malware realmente se esconder de você ou impedi-lo de localizá-lo facilmente usando as técnicas acima, matando seus processos e removendo todos os seus arquivos.