0

I am experience strange behavior using ssh with a jump host. While the setup works on machine A (cygwin, OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015) it does not work on machine B (OpenSSH_6.7p1 Ubuntu-5ubuntu1.3, OpenSSL 1.0.1f 6 Jan 2014). This setup is supposed to be used by Ansible to connect to remote machines via the bastion host.

I have the following ssh.config

Host bastion
    HostName               a.a.a.a
    ProxyCommand           none
    UserKnownHostsFile     known_hosts

Host *
    User                   user
    Port                   22
    ForwardAgent           yes
    ProxyCommand           ssh forward@a.a.a.a nc %h %p
    PasswordAuthentication no
    UserKnownHostsFile     known_hosts

The known_hosts files resides in the same folder.

Calling

ssh bastion -F ssh.config

works on both machines. While

ssh user@b.b.b.b -F ssh.config

does work only on machine A and not on B resulting in

The authenticity of host 'a.a.a.a (a.a.a.a)' can't be established.
ECDSA key fingerprint is ###.

I tried changing the proxy command to

ProxyCommand ssh forward@a.a.a.a -F ssh.config nc %h %p

This solved the issue with

ssh user@b.b.b.b -F ssh.config

as it now worked on both machines. The config however is used also by rsync which is run by Ansible and as this is run from another base directory the ssh.config file cannot be found. I do not want to use absolute paths to allow for portability. The scripts are supposed to be run on local machines (some Windows with cygwin) as well as by a dedicated build server using remote agents.

I have now set ProxyCommand to

ProxyCommand ssh -o UserKnownHostsFile=/dev/null \
  -o StrictHostKeyChecking=no forward@a.a.a.a nc %h %p

This works on A+B but has also issues with rsync/ansible. The log gives me:

msg: Warning: Permanently added 'a.a.a.a' (ECDSA) to the list of known hosts.

Host key verification failed.

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 The initial configuration would not work headless as it required a manual step to set the host keys. The alternatives did break the following workflow (rsync). Any other options?

2

Possibility to "workaround" the security of host-keys is to use ssh-keyscan which will create you the known_hosts file and then you can connect without checking authenticity of the host manually.

It can be used like this:

ssh-keyscan hostname > known_hosts

You will loose the "one point" of security, but if this runs in trusted environment, it is acceptable.

  • Could point. I will give it a try. Meanwhile I have resorted to not checking keys at all. Using ssh-keyscan would actually improve this. – pintxo Oct 27 '15 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.