Eu tenho um comportamento estranho usando ssh com um host de salto. Enquanto a configuração funciona na máquina A ( cygwin, OpenSSH_7.1p1, OpenSSL 1.0.2d 9 de julho de 2015 ), ela não funciona na máquina B ( OpenSSH_6.7p1 Ubuntu-5ubuntu1.3, OpenSSL 1.0.1f 6 jan 2014 ). Esta configuração deve ser usada pelo Ansible para conectar máquinas remotas através do host bastion.
Eu tenho o seguinte ssh.config
Host bastion
HostName a.a.a.a
ProxyCommand none
UserKnownHostsFile known_hosts
Host *
User user
Port 22
ForwardAgent yes
ProxyCommand ssh [email protected] nc %h %p
PasswordAuthentication no
UserKnownHostsFile known_hosts
Os arquivos known_hosts residem na mesma pasta.
Chamando
ssh bastion -F ssh.config
funciona em ambas as máquinas. Enquanto
ssh [email protected] -F ssh.config
funciona apenas na máquina A e não na B resultando em
The authenticity of host 'a.a.a.a (a.a.a.a)' can't be established.
ECDSA key fingerprint is ###.
Eu tentei alterar o comando do proxy para
ProxyCommand ssh [email protected] -F ssh.config nc %h %p
Isso resolveu o problema com
ssh [email protected] -F ssh.config
como agora funcionava em ambas as máquinas. A configuração, no entanto, é usada também pelo rsync , que é executado pelo Ansible e, como isso é executado a partir de outro diretório base, o arquivo ssh.config não pode ser encontrado. Eu não quero usar caminhos absolutos para permitir a portabilidade. Os scripts devem ser executados em máquinas locais (alguns Windows com cygwin ), bem como por um servidor de compilação dedicado usando agentes remotos.
Eu agora defini ProxyCommand para
ProxyCommand ssh -o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no [email protected] nc %h %p
Isso funciona em A + B, mas também tem problemas com rsync / ansible . O log me dá:
msg: Warning: Permanently added 'a.a.a.a' (ECDSA) to the list of known hosts.
Falha na verificação da chave do host.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
TL; DR A configuração inicial não funcionaria sem cabeça, pois exigia uma etapa manual para definir as chaves do host. As alternativas quebraram o seguinte fluxo de trabalho ( rsync ). Alguma outra opção?
Possibilidade de "solucionar" a segurança das chaves do host é usar ssh-keyscan , que criará o arquivo known_hosts e, em seguida, você poderá se conectar sem verificar a autenticidade do host manualmente.
Pode ser usado assim:
ssh-keyscan hostname > known_hosts
Você perderá o "um ponto" de segurança, mas se isso for executado em um ambiente confiável, é aceitável.