Eu encontrei o problema. O problema era que o arquivo known_hosts tinha as permissões erradas.
Ele foi definido como 600 e deve ser 644 .
O servidor em questão é um executor e cria projetos com um usuário do sistema gitlab-runner . Esse usuário é usado para o SSH em outros servidores para implantar código, etc.
Sempre funcionou bem até adicionarmos um novo servidor como destino. O comando SSH agora sempre falha com o erro 'Falha na verificação da chave do host'. . O erro também é lançado quando tento outros servidores que funcionaram anteriormente. O arquivo known_hosts está limpo, mas o SSH não pede para adicionar o servidor a known_hosts , ele retorna a mensagem de erro diretamente.
Eu verifiquei as permissões da pasta ~/.ssh e dos arquivos. Eles estão corretos ( .ssh: 700 , known_hosts: 600 , id_rsa: 600 , id_rsa.pub: 644 ). Als reiniciou o servidor, mas não teve sucesso.
Parece que o SSH não está funcionando corretamente. Aqui está uma saída de depuração de conexão com um servidor através de SSH .
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to megatron.domain.com [10.139.20.204] port 22.
debug1: Connection established.
debug1: identity file /home/gitlab-runner/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gitlab-runner/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to megatron.achillescm.nl:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:/zgPQuuy6sG8UuLG9EHFSFAuY1QYNvQzKSyNYq//DJ0
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
Alguém tem uma ideia?
Eu encontrei o problema. O problema era que o arquivo known_hosts tinha as permissões erradas.
Ele foi definido como 600 e deve ser 644 .
debug1: identity file /home/gitlab-runner/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
As linhas acima sugerem que .ssh/id_rsa existe ( type 1 ), mas sua chave pública ( .ssh/id_rsa.pub ) para o usuário não possui ou tem alguns problemas ( type -1 ).
Certifique-se de que o arquivo ~/.ssh/id_rsa exista, tenha 600 permission, seja de propriedade do usuário. E o ~/.ssh/id_rsa.pub corresponde / pertence à mesma identidade (de acordo com este post ).
Aqui está um teste simples para ser executado como um usuário de acesso sudo (por exemplo, root ):
sudo -u gitlab-runner sh -c 'cd; wc -l .ssh/id_rsa; stat .ssh/id_rsa; head -n1 .ssh/id_rsa'
Veja também: O que significa "key_load_public: nenhum tal arquivo ou diretório" significa?
Às vezes, o mesmo problema surge se as permissões / dev / tty forem muito restritivas. Então você só pode ssh para um servidor corretamente como usuário root, ninguém mais pode. A correção é para o chmod 777 / dev / tty para que os outros possam fazê-lo.