ERROR! SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh #13401
Comments
|
|
When testing against the box that is acting as the ssh proxy the response is as expected. Implication is that it's something to do with the ProxyCommand or, as in #12594 , the password. |
Note that ssh did not upgrade when ansible did. With ssh as above and ansible 1.9.4, ansible worked. With ssh as above and ansible 2.0.0, ansible started exhibiting the issue. |
|
What happens if you run: Could you show us the output, please? |
|
|
Could you now try the same command with |
|
Using sshpass with the sftp command works as expected. And Thanks for your help @amenonsen, that resolves the issue for me. |
|
OK, so sshpass and sftp just won't work from within Ansible. sshpass opens a pseudo-tty to talk to sftp and feed it the password, but doesn't expect it to behave interactively thereafter (which ssh normally doesn't, but sftp does; this explains why the first EXEC in your output doesn't fail). If you run it by hand it works because it opens /dev/tty, but not when Ansible executes it. I think (but have not verified) that if you set ANSIBLE_SSH_PIPELINING=y, then sshpass with also break ssh. If you feel like trying that and confirming the results, it would be a useful data point. This should probably be documented somewhere. |
|
Like this? |
|
Sorry, but it’s not clear: is this a bug and can we expect this to be fixed, or should we treat |
|
I have the same issue as soon as I upgraded to Ansible 2.0 on Arch Linux. OpenSSH_7.1p2, OpenSSL 1.0.2e 3 Dec 2015 Exporting ANSIBLE_SCP_IF_SSH=y works as expected |
|
I can confirm this issue. Using |
|
Same here. ANSIBLE_SCP_IF_SSH=y solves this problem. |
|
Same here: Error I get: Used to work with ansible < 2 |
|
Strange. If I use a hostname in my inventory I have this issue. But with an IP address it's ok. |
|
Same issue. |
|
Same issue on CentOS 6.5 with Ansible 2.0.0.2 |
|
CentOS 6 Same issue. Resolved with: |
|
OSX |
|
Same issue. Ubuntu 14.04 It does work after added a line scp_if_ssh = True in /etc/ansible/ansible.cfg |
|
Is anyone else having the same issue even after setting Ubuntu 14.04.4 |
|
Yes, but exporting the variable in the env works. |
|
OSX 10.11.3 |
|
I'm running Ansible on Linux Mint 17.3 and none of the proposed settings work for me. ansible-playbook works fine, but trying to run ansible -i hosts $somehost -m setup fails with this error. ansible 2.0.1.0 |
|
Even setting My current env: fatal: [vagrant@127.0.0.1]: FAILED! => {"failed": true, "msg": "ERROR! failed to transfer file to /home/vagrant/.ansible/tmp/ansible-tmp-1457146157.15-52289027718893/setup:\n\nssh: Could not resolve hostname 127.0.0.1]: Name or service not known\r\nlost connection\n"} |
|
@cristianoliveira have you tried adding |
|
Hey @Jacoblw I hoped both configs were the same. Anyway, I did and got the same error. |
This may help with some of the problems we've been seeing. Related to http://tracker.ceph.com/issues/16826 Inspired by ansible/ansible#13401 (comment) Signed-off-by: Zack Cerza <zack@redhat.com>
|
is there anything in ansible that if ssh or ping failed then wait and retry. |
|
Receiving "msg": "SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", |
|
@saeeda: You cannot discern a downed SFTP service from one that isn't there by default. |
|
@tima when activating my virtualenv, I just export that env variable, and the hosts that were giving error, start working. |
|
Why is this task marked as resolved when we can all reproduce it with current version of Ansible? -- 2.1.1.0 It is clear to me the without setting |
|
At least I am glad that I was able to workaround this bug by adding this to |
|
In my instance of this issue, adding |
|
thanks all, workaround corrects issue for me too Ansible 2.1.2.0 |
|
This works for me if you want to automate it. |
|
I'm getting the same error with ansible 2.1.2.0 trying to connect to a fresh Ubuntu 16.04 server installation. My ansible.cfg file: Here's the output from ansible -vvvv -m setup 192.168.5.160: I can SSH to the remote system as root using the public key. Adding the --ssh-extra-args made no difference. Any hints on what to try in order to fix the problem? Thanks! |
|
Remember that |
|
Thanks. I do have scp_if_ssh in the [ssh_connection] section (see above). Putting it there allowed the ssh connection process to proceed further, but there is still no data transfer. |
Are you able to connect using the ssh command from the ansible output? |
|
I believe my problem was that I needed to have the public key for the account I was running the playbook from installed in the root account on the remote system. I thought for sure I had checked that, but... It's working OK now. Sorry for the false alarm. |
|
Just thought I'd leave a note here - I ran into a very similar symptom, but it was due to pbrun being enabled on the target servers. I fixed it by setting ansible_become_method=pbrun |
|
Hello, In ansible 2.1.1, compared to 2.0.x, it's a bit better : now the error appears only when using async/polling commands. Please fix this bug, rollbacking to the code which was working before 2.x if needed. |
|
Those of you still seeing this should bring it up on the mailing list and/or IRC. As noted when this was closed: "Because this project is very active, we're unlikely to see comments on closed tickets, though the mailing list is a great way to get involved or discuss this one further." So, it's unlikely any ansible folks are seeing your comments... |
|
@O2Graphics do you have specifics on how you fixed it? I am having the same type of issue with Debian |
|
@untoldone sadly we still have weird issues with ansible 2.1.1 (bugs differents to #13401, #15766 and #16938). Here are some of the stuff we needed to change from 1.7.2 to 2.1.1:
Lastly, the best option we had was to go back to ansible 1.7.2 until we find more time to test the strange bugs of v2.1.x, search the bugtracker and/or report them. |
|
@O2Graphics Ugh ... that's really a bummer. I feel like these types of bugs + breaking changes + not obvious amounts of attention from the project owners makes me uncomfortable with Ansible as a whole. |
|
Thanks @nirik for pointing me at this bug. @O2Graphics Your first bullet point should be fixed via #15638 The second one is probably an issue with var caching. That's not an area I'm familiar with so we'll need a bug report with a reproducer for someone familiar with the cache plugins to look into. The last one I believe you're right. There was a lot of tightening of the code from 1.x to 2.x. Some of that made previously silent bugs now throw errors. For everyone in general: this bug is closed because, to the best of our knowledge and ability to test, the initially reported problem in this bug has been fixed via #15829 This can sometimes be tricky for us to determine on a bug this size when the original reporter isn't able to test our fix: we may have fixed a different issue with similar symptoms. In a similar vein, the reports of errors with similar symptoms are not the same issue (because they have a different cause than what was fixed) even if they result in similar symptoms. The best thing to do if you are still experiencing problems with code containing the fix mentioned above is to open a new bug report with enough detail that we can reproduce the issue. That will help us figure out in what other circumstances the code does the wrong thing. I'm going to lock this issue to further comments because the core team does not review closed bugs as part of their regular workflow and therefore comments here would likely never be seen leading to frustration that they never get addressed. Thanks for your understanding. |
and others
Issue Type:
Bug Report - related to #12594
Ansible Version & Configuration:
Environment: OSX 10.9.5
Summary:
Upgraded to 2.0.0 and started getting error above
Steps To Reproduce:
Expected Results:
Actual Results:
The text was updated successfully, but these errors were encountered: