Início / computer / Perguntas / 1692785
Accepted
Danijel
Asked: 2021-12-14 02:12:36 +0800 CST

Login SSH no mesmo endereço IP, mas sistema operacional diferente?

  • 772

Conectei o Raspberry Pi com o Raspbian OS à rede local e configurei o login SSH usando chaves ssh. Eu faço login com sucesso apenas por ssh [email protected](IP estático atribuído ao Raspberry Pi).

Agora removi o sistema operacional Raspbian e inseri um cartão SD com o Ubuntu Server (sem cabeça) nele.

Liguei o Raspberry Pi e tentei fazer o login, mas recebi o erro:

ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:asfasfdasdfasfdasfdasdfasdfasdfasdfasfasdf.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /home/joedoe/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /home/joedoe/.ssh/known_hosts:13
ERROR:   remove with:
ERROR:   ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"
ERROR: ECDSA host key for 192.168.5.163 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Eu continuei e adicionei ao meu .ssh/config:

host 192.168.5.163
    StrictHostKeyChecking no

mas agora eu recebo

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:asdfasdfasdfasdfasdfasdfasdfasdfasdf.
Please contact your system administrator.
Add correct host key in /home/joedoe/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/joedoe/.ssh/known_hosts:13
  remove with:
  ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
[email protected]: Permission denied (publickey,password).

Claramente, o problema é que eu quero fazer login em dois sistemas operacionais diferentes no mesmo endereço IP, mas o novo sistema operacional Ubuntu não acena a configuração de login SSH e não me permite fazer login de forma alguma.

Como devo proceder para poder usar os dois sistemas operacionais de forma intercambiável?

ssh

5 respostas

  1. Você pode corrigir o problema imediato seguindo as instruções no erro (você deve fazer isso toda vez que trocar de caixa) -

    ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"

    O problema que você está encontrando é que seu computador detectou que o sistema em que está fazendo login é diferente daquele visto anteriormente, e o aviso está lá para evitar ataques man-in-the-middle.

    Existem várias maneiras de lidar com isso corretamente. Eles incluem:

    1. Configurando nomes para cada caixa /etc/hostse, em seguida, referindo-se à conexão SSH por nome em vez de IP. Dessa forma, o SSH associará diferentes impressões digitais do servidor a cada nome.

    2. Ignorar a verificação (isso abre você para ataques mitm, portanto, faça isso apenas se você entender e estiver confortável com os riscos.) Você pode ignorar essa verificação adicionando -o UserKnownHostsFile=/dev/nullao seu comando ssh ou-o StrictHostKeyChecking=no

      2a. Você pode criar uma configuração que apenas ignore a verificação de chave para um IP colocando o seguinte em~/.ssh/config

      Host 192.168.5.163 StrictHostKeyChecking não UserKnownHostsFile=/dev/null

    3. Eu não aconselharia isso, a menos que as máquinas desempenhem a mesma função, mas você pode fazer com que as chaves do host sejam /etc/sshas mesmas em ambos os servidores (e restart sshdno que você alterou). Dessa forma, ambos os servidores parecerão iguais para o cliente.

    • 30
  2. Best Answer

    Existem várias soluções potenciais.

    A solução mais fácil é a que davidgo propôs em sua resposta, que, como ele menciona, deixa você aberto a um ataque MitM (improvável, mas é bom praticar uma boa segurança mesmo em situações particulares).

      Host 192.168.5.163
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null

    Uma solução um pouco melhor seria, como proposto por Eugen Rieck, sincronizar os /etc/ssh/ssh_host_*key*arquivos entre os dois sistemas operacionais de destino.

    Um método mais confiável seria decidir especificamente a qual sistema operacional se conectar, para que você receba um erro se se conectar ao sistema operacional errado. Isso, por exemplo, permitiria que scripts usando ssh falhem se tiverem como alvo o sistema operacional errado.
    Você pode fazer isso usando efetivamente um Alias ​​no arquivo ~/.ssh/ssh_config.

    Host raspbian-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_raspbian

Host centos-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_centos

    Você pode se conectar ssh <your_user>@raspbian-pipara recuperar a chave do Raspbian OS e, em seguida, mudar para o CentOS no seu Raspberry Pi, faça o mesmo ssh <your_user>@centos-pipara obter a chave do CentOS. Então, no futuro, sempre que você se conectar ao sistema operacional errado, receberá o erro da chave do host. Certifique-se de usar o sistema operacional correto na primeira vez que usar o comando SSH, para não armazenar acidentalmente a chave de host do CentOS no arquivo de hosts conhecidos do Raspbian.

    Isenção de responsabilidade: nunca usei esta solução e não estou em condições de testá-la, mas deve funcionar corretamente pelo meu entendimento e pela documentação do ssh.

    • 29

  3. A maneira mais fácil de fazer isso é copiar /etc/ssh/ssh_host_*_key*de uma instalação para outra - isso dará a ambos os sistemas operacionais as mesmas chaves de host e, portanto, a impressão digital.

    • 21

  4. Outra opção é dar a cada sistema operacional um endereço IP diferente. Eles obtêm o mesmo agora porque o servidor DHCP vê o mesmo endereço MAC. Assim, você pode configurar uma instalação para usar um endereço IP estático.

    Eu seguiria a sugestão de Eugen - isso simplifica as coisas. Ou obtenha um segundo Pi e execute as duas máquinas ao mesmo tempo.

    • 8

  5. Eu pessoalmente uso uma Autoridade de Certificação OpenSSH para todos os meus servidores Linux. Isso evita muitos problemas ao configurar um novo e orquestrar meus dispositivos de terminal (desktops, laptops e hosts de salto), sobre os quais eu escrevi anteriormente .

    Embora esse recurso não tenha sido originalmente projetado para esse caso de uso (incomum), ele fornece uma solução alternativa para o problema. Basta assinar ambas as chaves de host com a chave privada de sua CA e adicionar a parte pública ao seu known_hostsarquivo, e seu cliente SSH confiará automaticamente em ambos os conjuntos de chaves de host sem gritar com você sobre as discrepâncias. Você ainda pode precisar remover todas as chaves de host lembradas com ssh-keygen -Rantecedência, no entanto.

    Isso tem a vantagem de que ambos os sistemas podem manter suas chaves de host separadas e diferentes, o que fornece a capacidade de distingui-las por chaves de host (e certificados - há um campo de "identidade" que você pode personalizar ao assinar os certificados). Isso também é seguro, pois você não precisa confiar cegamente em um host arbitrário que aparece nesse endereço IP específico.

    Mesmo se você quiser se proteger contra chaves vazadas, você pode adicionar "nomes/endereços IP permitidos" como "principais" ao assinar os certificados, por exemplo:

    ssh-keygen -s my_ca -I "RaspOS on RPi" -h -n 192.0.2.0 ssh_host_rsa_key.pub

    O certificado não será confiável, a menos que seja apresentado pelo host em 192.0.2.0, a menos que um invasor de alguma forma sequestre seu tráfego , além das chaves e certificados do host.

    Bem, agora tenho que admitir que é mais fácil copiar as chaves do host entre os dois sistemas operacionais, pois eles estão na mesma máquina física.

    • 0

relate perguntas