Search code examples
dockergithubssh-keys

Git push fails because of ssh key: Host key verification failed. from inside a docker

"git push" command from inside a docker container inside a pod fails with the command:

debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed.

The groovy code that initiates git push:

sshagent (['my_deploy_key'])
                            {
                                sh "ls -la /dev/tty"
                                sh "ssh -Tv git@github.xx.xxx.com"
                                sh "git push origin ${branch}"

                            }

The log shows the /dev/tty exists with the right permissions:

[ssh-agent]   Exec ssh-agent (binary ssh-agent on a remote machine)
Executing sh script inside container my-project of pod my-project-1611882622034-s6sj2-xnx40
Executing command: "ssh-agent" 
exit
SSH_AUTH_SOCK=/tmp/ssh-Dm0jcALohFq6/agent.68; export SSH_AUTH_SOCK;
SSH_AGENT_PID=69; export SSH_AGENT_PID;
echo Agent pid 69;
SSH_AUTH_SOCK=/tmp/ssh-Dm0jcALohFq6/agent.68
SSH_AGENT_PID=69
Running ssh-add (command line suppressed)
Identity added: /home/jenkins/agent/workspace/Test_Dev/mydir@tmp/private_key_6404034659918914698.key (deploy-key)
[ssh-agent] Started.
[Pipeline] {
[Pipeline] sh
+ ls -la /dev/tty
crw-rw-rw- 1 root root 5, 0 Jan 29 01:10 /dev/tty
[Pipeline] sh
+ ssh -Tv git@github.xx.xxx.com
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to github.xx.xxx.com [153.64.42.159] port 22.
debug1: Connection established.
debug1: SELinux support disabled
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jenkins/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version babeld-7fdd29b
debug1: no match: babeld-7fdd29b
debug1: Authenticating to github.xx.xxx.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+VP3LqRsSmtwgQhOdiuCaRKG8wTCeNRdwTlOvrILZq8
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification fail

ed.

Please advice

Solution

  • The SSH protocol does not usually use traditional certificate authorities like TLS does. Instead, when you connect to a machine for the first time, you are prompted to verify its host key, which you typically do out of band. This way, you can verify the remote system is who they claim to be.

    This message occurs because normally you are prompted on the terminal to verify the host key, but in this case, there is no terminal, so you cannot be prompted. The only safe thing to do is to fail to connect.

    In this case, you will want to store your GitHub Enterprise instance's host key as part of your config. You can find these by running ssh-keyscan github.xx.xxx.com. You should take this output (minus the lines starting with #) and store it in /etc/ssh/ssh_known_hosts in your container or in the ~/.ssh/known_hosts file for the given user.

    You can also verify that the fingerprint is correct by going to https://github.xx.xxx.com/api/v3/meta and verifying that SHA256:+VP3LqRsSmtwgQhOdiuCaRKG8wTCeNRdwTlOvrILZq8 is the right fingerprint for the key.

    Note that some people will suggest disabling host key verification, but this is not secure and is equivalent to operating on an unencrypted connection, so you should not do this. You should also not run ssh-keyscan each time in your container, because that means you'll accept any host key that's presented, even if it belongs to an attacker, which is equally insecure.