Copie chaves ssh de um servidor para outro servidor


12

Eu tenho um servidor (vamos assumir que seu ip seja abcd) que permite que os usuários efetuem login via ssh. Agora quero trocar a maquina fisica mantendo o mesmo ip. Para que a nova máquina ainda seja acessada por um usuário como este

$ ssh abcd

O problema é que toda vez que um usuário tenta fazer login, ele recebe o seguinte erro de incompatibilidade de chave ssh.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ AVISO: A IDENTIFICAÇÃO DO HOST REMOTO FOI MUDADA! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
É POSSÍVEL QUE ALGUÉM ESTÁ FAZENDO ALGO DESAGRADÁVEL!
Alguém pode estar te espionando agora (ataque man-in-the-middle)!
Também é possível que a chave do host RSA tenha sido alterada.
A impressão digital da chave RSA enviada pelo host remoto é
02: dc: c6: 18: 1b: 34: b7: 1d: fa: 90: ab: e1: 95: 48: 69: 84.
Entre em contato com o administrador do sistema.
Adicione a chave do host correta em /home/user/.ssh/known_hosts para se livrar dessa mensagem.
Chave incorreta em /home/user/.ssh/known_hosts:37
A chave de host RSA para ex-alunos mudou e você solicitou uma verificação rigorosa.
Falha na verificação da chave do host.

Eu sei que o usuário pode excluir a linha # 37 do arquivo ~ / .ssh / known_hosts e da próxima vez que receber um prompt de sim / não. O que eu quero é que o usuário fique ciente de toda essa substituição da máquina e obtenha uma solicitação de senha.

Como fazer isso?


3
Você está ciente de que isso derrotaria ssha única proteção contra ataques de homens no meio e poderia resultar no envio de sua senha diretamente ao atacante, em vez da máquina pretendida? A menos que você saiba que é invulnerável a ataques ativos (por exemplo, você está na mesma rede interna segura que a máquina de destino), isso destrói ssho modelo de segurança.
David Schwartz

Sim. Ambas as máquinas estão nas mesmas redes internas. Até os usuários estão dentro da mesma rede interna. Diante dessa situação, quais são minhas opções?
Souvik Pal

Isto não é suficiente. Eles precisam estar na mesma rede interna segura . Ou seja, eles devem absolutamente 100% confiar que nenhum dispositivo está conectado àquela rede interna que não é 100% segura, e devem 100% confiar em todos que têm controle sobre esses dispositivos ou podem conectar um dispositivo a essa rede. Em outras palavras, em quase qualquer cenário realista, essa é uma péssima idéia.
22413 David Schwartz

2
É uma coisa perfeitamente razoável de se fazer. Estou replicando as chaves do servidor ssh para outro servidor para HA, para que, quando eu entre, receba esses erros. Além disso, recebo um email sobre failover.
Matt H

3
Eu concordo com o Matt. Se você estiver no controle de ambas as máquinas e, portanto, o proprietário das chaves, mover a chave do host de uma máquina para outra sob seu controle NÃO É UM HOMEM EM ATAQUE OU RISCOS DO MEIO. Se o usuário que está conectando confia na chave do host, isso não deve importar.
Ross

Respostas:


14

Como Ethabell mencionou, você pode copiar as chaves do host atual para o novo servidor.

Você pode encontrar as chaves do seu host abrindo seu sshd_configarquivo (na minha caixa do Ubuntu 12.04 /etc/ssh/sshd_config). No arquivo de configuração, procure as HostKeyentradas. Essas entradas informarão onde os arquivos de chave do host estão localizados. Você poderá copiar esses arquivos para o novo servidor e atualizar os novos sshd_configpara apontar para as chaves copiadas (ou simplesmente substituir os arquivos que já existem no novo servidor).

Além disso, observe esta seção na sshd_configpágina de manual, especificamente na parte sobre permissões:

Especifica um arquivo que contém uma chave de host privada usada pelo SSH. O padrão é /etc/ssh/ssh_host_keypara a versão 1 do protocolo e /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_keye /etc/ssh/ssh_host_rsa_keypara a versão 2. do protocolo. Observe que o sshd (8) se recusará a usar um arquivo se estiver acessível por grupo / mundo. É possível ter vários arquivos de chave do host. As teclas “rsa1” são usadas para a versão 1 e “dsa”, “ecdsa” ou “rsa” são usadas para a versão 2 do protocolo SSH.


1

Se você tivesse a chave do host original, poderia restaurá-la e isso interromperia o erro.

Ou você pode desativar o StrictHostKeyChecking no seu arquivo de configuração sshd.

... Fazer isso, no entanto, é uma péssima ideia. Se existe uma maneira de você rodar ssh-keygen -R server.example.comem máquinas clientes, essa seria a melhor maneira - porque desativar a verificação de chave do host é como dizer: "Ei, me ataque." Sinto falta de obscuridade quando as coisas mudam, mas a segurança deve ser a prioridade número 1 em detrimento das mudanças ocultas.


Você pode elaborar como restaurar as chaves do host em uma máquina mais nova?
Souvik Pal

1

Você pode tentar assim

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"' 

Observe que, se a pasta .ssh ainda não existir, o comando acima falhará. Além disso, pode ser melhor ao criar o arquivo para definir uma permissão mínima possível (basicamente leitura e gravação apenas para o proprietário). Aqui está um comando mais avançado:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys && echo "Key copied"'

Para obter mais informações sobre esse problema, acesse este site: Erro de alteração de chave do host SSH

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.