7

When running an ansible task (with a script action), I'm getting this error message:

stderr: OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: mux_client_request_session: master session id: 2
Shared connection to 10.0.2.222 closed.

Now, there are a bunch of tasks targeting the same host before this one, and they all work fine.I know it's the client, because the client is Debian; the thing being provisioned is Centos.

When I tried to look up this error message, I discovered (to my chagrin) that what I got is usually the first part of some longer message for some other problem. I tried adding

Host 10.0.2.222
  ControlMaster no

to the beginning of my /etc/ssh/ssh_config because of this question out of pure desperation, but it didn't work and I genuinely don't know what could have gone wrong; I don't know enough about how SSH works to even figure out what the most likely culprit would be.

Improve this question
7
  • Try SSHing directly to 10.0.2.222 with the key file and username you've got Ansible configured with. If it fails, turn on verbose output with -v.
    – ceejayoz
    Jul 14, 2015 at 15:24
  • @ceejayoz It doesn't fail. That's the issue; The keys are configured fine, I can ssh into root with no problems. it's only failing about 10 tasks in.
    – Parthian Shot
    Jul 14, 2015 at 15:27
  • Try configuring ControlMaster no in your ~/.ssh/config instead of the global one, perhaps?
    – ceejayoz
    Jul 14, 2015 at 15:29
  • @ceejayoz Nope. On the bright side, it's definitely applying the rules.
    – Parthian Shot
    Jul 14, 2015 at 19:52
  • To me this looks like the rule is doing ssh -v to the client on the client, or something like that. Without you showing the playbook it impossible to say for sure.
    – wurtel
    Jul 15, 2015 at 8:50

1 Answer 1

Reset to default
9

This fixed the problem mentioned in the question (problems still exist with the ssh connection, but that's for another question).

By default, ansible adds some options which override ssh_config options. Specifically, it adds:

-o ControlMaster=auto -o ControlPersist=60s -o ControlPath="/home/devel/.ansible/cp/ansible-ssh-%h-%p-%r"

Figured that out by using -vvv with ansible-playbook.

You can fix / override those options by specifying ssh_args in the [ssh_connection] section of your .ansible.cfg as specified here. Also worth noting is that, counter to what you might infer from the name, changing ssh_args doesn't actually change all of the args. Ansible also passes -C -tt -v -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o ConnectTimeout=10 and other options (e.g. -o PasswordAuthentication=no -o User=root), some of which are simply immutable defaults, and some of which depend on variables you've specified in the playbook.

Improve this answer
3
  • 5
    Right, but which of the args in particular did you override to fix the problem?
    – brk3
    May 9, 2016 at 11:14
  • 4
    The first step is to set ssh_args to -o ControlMaster=no to disable re-using SSH connections (aka connection multiplexing). If that stops the failures, you could see whether your client or server openssh version is at fault - see this bug report . See this answer for similar issue solved by turning off ControlMaster. Once you have reliable SSH, you can think about updating openssh to fix with ControlMaster turned on.
    – RichVel
    Feb 26, 2017 at 9:34
  • (a bit late in responding... but yeah when you asked what args I changed I couldn't tell you b/c it'd been a year since I had this problem. You're right though, @brk3 . It's a shortcoming of this answer. :P )
    – Parthian Shot
    Oct 5, 2017 at 23:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .