Problemas de verificação de chave do host SSH usando VIP

Temos dois servidores de produção em um VIP, apenas um está em uso por vez, por exemplo:

myservice.mycompany.uk normalmente aponta para server1, caso o server1 falhe, as alterações apontam para server2.

Existem outros servidores que precisam enviar arquivos para myservice.mycompany.uk via SFTP e devem ser totalmente transparentes para eles se fizermos o failover para o server2.

O problema é que, enquanto as chaves estão instaladas no servidor1 e no servidor2, os outros servidores terão problemas de verificação de chave do host, porque a chave do host do servidor2 é diferente da chave do host do servidor1. Isso causa um erro de segurança (uma vez que a verificação estrita está ativada) e uma linha deve ser removida de known_hosts para que funcione.

Nosso pessoal de TI sugeriu que possamos criar 2 entradas em known_hosts, uma com a chave para server1 e outra com server2, ambas com o host myservice.mycompany.uk.

É provável que funcione? Como isso pode ser feito com o putty / psftp no Windows? Como a chave do host está armazenada no registro e nomes duplicados não são permitidos. Existe uma maneira melhor, podemos, por exemplo, forçar os servidores a terem a mesma chave de host?

ssh cluster sftp

— Paul Creasey
fonte

Respostas:

Para facilitar para os clientes, eu usaria apenas a mesma chave de host em ambas as máquinas. Basta copiar uma das chaves (a do servidor atualmente em uso) para a segunda máquina. As chaves estão dentro /etc/ssh/ssh_host_*.

Outra opção é desativar a verificação de chave do host nos clientes. Isso pode ser feito ajustando seu ssh_configuso:

Host myservice.mycompany.uk
    StrictHostKeyChecking

— ℝaphink
fonte

Desativar a verificação da chave do host prejudica bastante o uso do SSH para transferir esses arquivos, duplicar a chave do host é provavelmente a melhor solução.

— James Yale

Desativar a verificação de chave do host não significa que a comunicação não esteja corretamente criptografada, que é o principal ponto do SSH. Dito isto, como eu disse, sou a favor da primeira solução.

— ℝaphink

Na versão cliente (com chaves de servidor diferentes) da solução, você também precisa adicionar UserKnownHostsFile=/dev/nulloutra coisa, a primeira chave entrará nos hosts conhecidos e a segunda levará a um aviso de "homem no meio".

— Nils

@ Nils isso não é necessário; A configuração StrictHostKeyChecking yesfará com que o arquivo UserKnownHosts seja ignorado em favor do arquivo de hosts conhecidos do sistema. Portanto, qualquer coisa que modifique os UserKnownHosts é inútil.

— Michael Lowman

Ok - eu preciso esclarecer isso mais detalhadamente: falo sobre o caso em que você tem duas chaves de servidor diferentes. Lá você deve especificar StrictHostKeyChecking noe definir adicionalmente o UserKnownHostsFile/ dev / null. Nesse caso, todas as chaves do host serão aceitas (tornando esse nível de segurança inútil, é claro).

— Nils

Arquivei isso dessa maneira, a raiz do usuário executa um script às 23:00 que se conecta ao endereço IP lógico do cluster Linux, portanto, em caso de failover do endereço IP, minha impressão digital ssh muda

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

Dessa forma, a configuração é apenas para raiz

— c4f4t0r
fonte