Geralmente, a abordagem que você adota é sempre a mesma: você verifica a impressão digital da chave por meio de um canal que o invasor não pode ter manipulado.

Por exemplo, na minha antiga universidade, você poderia ir até a recepção do centro de computação e obter um panfleto com uma lista de impressões digitais de todas as chaves e certificados importantes. Se for um servidor de um amigo que você conhece pessoalmente, você pode ligar para ele e pedir que ele leia a impressão digital para você. Se for um servidor gerenciado e hospedado, alguns dos provedores de hospedagem mais preocupados com a segurança podem se oferecer para enviar as impressões digitais para você.

A essência é: se você tiver motivos para acreditar que sua conexão de rede está comprometida, tente obter a impressão digital sem usar a rede.

Para o seu Raspberry Pi, existem várias opções muito simples:

• Basta conectar um cabo de rede do seu computador direto ao Raspberry Pi. Boom: não há mais "meio" onde alguém poderia montar um ataque Man-in-the-middle.
• Conecte-se ao console serial do Pi a partir do seu PC e faça login no console diretamente. Boom: nem rede tem mais.
• Conecte um teclado USB e um monitor HDMI ao seu Pi e faça login diretamente no console.
• Retire o cartão SD (ou stick USB ou qualquer que seja o seu meio de inicialização), monte o sistema de arquivos ext2 no seu PC (se você não roda Linux, pode precisar de software extra para isso, ou pode inicializar em um Linux LiveCD) , e verifique a chave em /etc/ssh/ssh_host_ecdsa_key.

Isso responde à pergunta mais específica sobre como verificar a chave do host. Agora, para sua pergunta mais geral:

Sou novo nesse tipo de coisa e quero descartar o ataque man-in-the-middle.

Para montar um ataque man-in-the-middle em sua LAN, o invasor precisa de acesso físico à sua infraestrutura de LAN. Então, se você quiser descartar um ataque man-in-the-middle, você pode literalmente rastrear seus cabos e procurar por um "man-in-the-middle", ou seja, um dispositivo que você não reconhece. Mas tenha cuidado: esses dispositivos podem ser minúsculos e bem escondidos.

Você também pode procurar sinais de arrombamento na fechadura de sua porta ou em outros pontos de entrada de sua casa (janelas, etc.)

Agora, você pode fazer uma análise de plausibilidade: o que é mais provável, que alguém invadiu sua casa e instalou um dispositivo em sua LAN sem que você percebesse, só para ver o que você está fazendo com seu Raspberry Pi? Ou é mais provável que 192.168.1.123 tenha sido atribuído a um dispositivo diferente antes (ou que você atualizou, reinstalou ou reconfigurou seu Pi) e a chave antiga ainda estava armazenada em cache no seu PC?

Se estamos falando de um WiFi, porém, um ataque MitM não requer acesso físico. Portanto, torna-se muito mais provável que alguém seja capaz de montar tal ataque sem que você perceba. No entanto, a questão ainda permanece: o que o invasor quer ao farejar a conexão entre você e seu Pi?

Da mesma forma, se algum dispositivo em sua LAN também estiver conectado a uma rede diferente (um WiFi, uma rede de bairro, a Internet), esse dispositivo poderá ser comprometido por meio dessa rede e, assim, fornecer a um invasor acesso à sua LAN.

Conforme mencionado em um comentário acima, um Raspberry Pi comprometido é uma coisa valiosa, mas qualquer invasor competente saberia comprometê-lo de uma maneira que não alterasse a chave do host.

Quando você se conecta a qualquer host pela primeira vez, o SSH salva suas informações de identificação. Se essa identificação mudar no futuro, ele exibirá esta mensagem.

Isso pode acontecer, por exemplo, após reinstalar o sistema de destino, substituindo-o por outro com o mesmo IP/nome de host que você usa para se conectar ou após regenerar as chaves SSH do servidor do sistema. Se isso soa como algo que você fez recentemente, esse é o motivo.

Também pode ser alguém interceptando sua conexão (e realmente enviando sua identificação), mas em uma LAN é improvável.

Faça login no Raspberry Pi na máquina com a qual você normalmente faz login. Observe a chave. Confirme se a impressão digital está correta.

Se você nunca configurou nenhuma maneira segura de fazer login no Raspberry Pi de qualquer local, então você não tem um. Da próxima vez, faça isso quando configurar a máquina. Por exemplo, tire uma foto da impressão digital da chave no console quando estiver configurando o sistema operacional.

Você já teve outros dispositivos em sua rede local aos quais se conectou com ssh, como outros Pi:s ou alguns computadores * nix regulares?

Se você usar DHCP, um endereço IP atribuído (por tempo limitado, na forma de um "concessão" de DHCP) a um dispositivo pode ser reutilizado por outro dispositivo posteriormente. Se você se conectou com ssh a um dispositivo, o ssh lembra a chave do host para esse endereço IP. Quando um novo dispositivo obtém o mesmo endereço IP atribuído e você tenta se conectar com o ssh, obtém o erro acima.

Muitos servidores DHCP tentam atribuir endereços "quase permanentes" com base no MAC (o endereço de hardware ethernet) do dispositivo que solicita um endereço IP, mas não é perfeito - por exemplo, se todos os endereços IP no intervalo disponível para DHCP já forem usados alguns têm de ser reutilizados. Ou se o roteador / servidor doméstico / qualquer dispositivo que você usa para DHCP for redefinido ou substituído.

Você não está sendo hackeado.

Por que alguém iria querer acesso “man-in-the-middle” a um Raspberry Pi em uma LAN pessoal?

“…Quero saber o que devo fazer para realmente descartar (ou confirmar) um ataque antes de consertá-lo.”

As chances de alguém "man-in-the-middle" atacar você em sua LAN por meio de um Raspberry Pi são praticamente nulas. Qual é o benefício de eles fazerem isso se, de alguma forma, violarem sua LAN e você tiver uma boa máquina Windows em que eles possam entrar?

A principal razão pela qual alguém faz "man-in-the-middle" é capturar dados - como credenciais e outros - e depois enlouquecer com eles. Eles obtêm algumas credenciais para um Raspberry Pi e isso leva a quê? A menos que seu Raspberry Pi esteja de alguma forma fazendo transações financeiras e tal, mas duvido.

O cenário mais provável é que você reinstalou o sistema operacional no Raspberry Pi, o que alteraria a assinatura de identificação e acabaria em um cenário como o que você está lidando. Porque normalmente é por isso que uma incompatibilidade de identificação como essa acontece; algo mudou a identificação.

No mundo não-Raspberry Pi, isso pode acontecer se você trocar um disco do sistema de uma máquina para outra - como em uma atualização de hardware e tal - e ainda acontece com mais frequência com VMs e onde a instalação/remoção de sistemas é muito fácil .

Quanto a, de alguma forma, fornecer a você algum tipo de lista de maneiras pelas quais você pode confirmar por conta própria, honestamente, além da avaliação de senso comum que descrevo, isso não é realmente possível.

Na maioria das vezes, especialmente ao lidar com dispositivos relativamente efêmeros como o Raspberry Pis, essa mensagem é benigna; talvez você tenha colocado um cartão SD diferente, reinstalado o sistema operacional, atribuído o mesmo IP a um dispositivo diferente ou qualquer uma das cerca de uma dúzia de ações que podem resultar em uma nova impressão digital do host. No entanto, sugiro que você não se contente com "a maior parte do tempo" quando se trata de hospedar impressões digitais, pois são muito fáceis de verificar.

Como outros já apontaram corretamente, você precisa verificar a impressão digital da chave do host por meio de um canal confiável. Em outras palavras, não apenas SSH para o Pi e execute os comandos abaixo, pois isso seria vulnerável ao mesmo (potencial) ataque MitM que você está tentando descartar. Nesse caso, sugiro que você use a conexão HDMI do Pi, ou serial, ou alguma outra conexão confiável, para verificar a impressão digital do host.

Agora, para realmente verificar a impressão digital, você precisará de um shell no Raspberry Pi. Digite ssh-keygen -l(letra minúscula 'L') e pressione [Enter] . Isso solicitará o nome do arquivo da chave. A chave que você deseja deve estar /etc/ssh(o caminho padrão sugerido não contém as chaves do host do sistema; ignore-as aqui). Procure a chave ECDSA, pois é com ela que seu cliente SSH relatou se conectar. Você obterá o mesmo resultado se usar a chave pública ( .pubextensão) ou a chave privada (sem extensão), mas, a menos que esteja logado como root, você só poderá ler a chave pública.

ssh-keygen -lseguido pela inserção do nome de arquivo da chave privada correta, produzirá a impressão digital dessa chave. Deve ser algo como isto:

pi@raspberrypi:~$ ssh-keygen -l
Enter file in which the key is (/root/.ssh/id_rsa): /etc/ssh/ssh_host_ecdsa_key.pub
256 SHA256:0xg...[redacted]...rduY. root@pi (ECDSA)

(Esse nome de arquivo pode ou não estar correto para o seu Raspberry Pi. Verifique ls -l /etc/sshprimeiro.)

Você então compararia cuidadosamente a impressão digital que seu sistema produz com a que você obteve sshanteriormente. Se eles corresponderem, a conexão será verificada e você poderá atualizar com segurança seu local de ~/.ssh/known_hostsacordo. Se eles não corresponderem, algo estranho está acontecendo que exigiria uma investigação mais aprofundada.

Quero saber o que devo fazer para realmente descartar (ou confirmar) um ataque antes de consertá-lo.

Você precisa usar um canal 100% confiável para receber essas informações.

A melhor abordagem é fazer login no sistema diretamente - ou seja: conectar um teclado e monitor ou usar um console serial, se apropriado.

Depois de fazer login, execute um dos seguintes comandos:

ssh-keygen -l -f <( ssh-keyscan 127.0.0.1 )

ou:

for k in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -l -f "${k}"; done

Isso vai:

• ssh-keyscan- Conecte-se ao servidor SSH do sistema local e solicite as chaves do host
  • Você também pode trocar 127.0.0.1por um host remoto se precisar ... embora fazer esta operação remotamente exija confiança absoluta de que o controle remoto é quem diz ser e que tudo entre você e o controle remoto pode ser confiável.
  • Usando 127.0.0.1irá rotear a conexão através da interface de loopback e se comunicará diretamente com o sistema local. (ignorando possíveis iptablesregras para redirecionar o tráfego)
  • No caso de um ataque, using localhostpode realmente redirecioná-lo para outro host (usando /etc/hosts), então evite usá-lo.
• ssh-keygen- Mostrar as impressões digitais ( -l) das chaves no arquivo fornecido ( -f ${file})
  • Usando com ssh-keyscan 127.0.0.1(ou seja: opção 1) irá realmente se conectar ao daemon em execução e consultar as chaves como qualquer outro cliente faria
  • Usar com arquivos no sistema de arquivos local (ou seja: opção 2) pode ser considerado a abordagem um pouco " mais segura ", mas isso não considera configuração incorreta ou incorreta do servidor, com chaves localizadas em outro lugar... precisa ir cavando para as chaves corretas.

Em seguida, depois de obter as impressões digitais, compare-as cuidadosamente com a chave oferecida pelo sistema remoto ao qual você está tentando se conectar (ou seja: SHA256:0xgFiU5j9W2WgyurDOgORf+qeFQoHf0YE6G92KnrduYno seu exemplo).

Se a impressão digital não corresponder , você confirmou que um ataque está em andamento e não está falando com o sistema que pensa estar.

Se a impressão digital corresponder, ótimo! Resolva o problema usando ssh-keygen -R ${hostname}e continue seu caminho.

Notas:

• A ressalva padrão de que, se um sistema for comprometido, talvez você deva considerar a chave do host comprometida também ... nesse caso, você não terá como saber.
• Pode ser possível causar uma colisão de hash e apresentar a mesma impressão digital para duas chaves diferentes... caso em que você não terá como saber.
• Qualquer tráfego baseado em rede pode ser alterado ou redirecionado usando iptables... se você suspeitar que um sistema está comprometido, pode ser uma boa ideia verificar isso também.

É impossível fazer isso sem ter um canal de comunicação 100% confiável. No seu caso, você pode fazer login no Pi e recuperar as chaves diretamente. Em outras situações, talvez seja necessário " aceitar a palavra de um colega "... Cuidado onde você deposita sua confiança.

Sou novo nesse tipo de coisa e quero descartar o ataque man-in-the-middle.

Em uma pequena rede local, é muito provável que você esteja falando com o sistema que pensa estar.

Se o endereço IP remoto estiver em sua sub-rede e não houver nenhum outro dispositivo desconhecido ou suspeito presente em sua rede, será difícil construir um ataque MITM. Para maior certeza, tente remover todos os outros dispositivos ou até mesmo criar um link ponto a ponto entre seu computador e o computador remoto (embora o endereçamento e o DHCP possam se tornar problemáticos nessa situação).

Se você suspeitar que seu roteador não é confiável, lembre-se de que ele pode anunciar rotas e nomes (DNS / mDNS / WINS) para o seu sistema, nos quais seu sistema geralmente confiará implicitamente. Se a internet puder ser retirada da equação, esses truques de roteamento/redirecionamento não poderão ser executados, a menos que sejam facilitados internamente.

... " Confiança na computação " é um tópico muito grande, e há tantos caminhos que poderíamos enviar para você aqui... Encorajo você a perguntar/ler/jogar/etc... é a melhor maneira de aprender .

Como já foi discutido em outras respostas ... a situação mais provável em que você se encontra aqui é:

1. Você reinstalou o sistema operacional em seu Raspberry Pi
2. Seu servidor DHCP concedeu uma concessão que foi concedida anteriormente a outro host sshcom o qual você usou e que foi concedida recentemente ao seu Raspberry Pi

Normalmente, as pessoas aceitarão a impressão digital exibida na primeira conexão e ficarão satisfeitas com isso no futuro.

Em sistemas particularmente sensíveis, você deve confirmar se a impressão digital está exatamente correta na primeira conexão.

Se a impressão digital mudar, algo sobre o host mudou - por exemplo, um impostor ou uma reinstalação.

A mensagem basicamente significa que você está se conectando a um computador diferente em um IP/endereço específico do anterior.

Por que isso pode acontecer além do MITM? Possivelmente o computador foi reinstalado. Possivelmente você coloca um computador diferente no IP e espera totalmente a mensagem.

No contexto de uma conexão roteada inteiramente por meio de sua LAN, as chances de um ataque real em vez de um motivo benigno são muito baixas.