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.

Community
  • 1
Parthian Shot
  • 1,165
  • 4
  • 16
  • 32
  • 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 '15 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 '15 at 15:27
  • Try configuring `ControlMaster no` in your `~/.ssh/config` instead of the global one, perhaps? – ceejayoz Jul 14 '15 at 15:29
  • @ceejayoz Nope. On the bright side, it's definitely applying the rules. – Parthian Shot Jul 14 '15 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 '15 at 08:50
  • Found out what it was when I ran the playbook with `-vvv`. Apparently, ansible was overriding the options in its command-line invocations of SSH. I'll answer this later today with my fix, but this certainly wasn't intuitive behavior on ansible's part. Nothing to do with my specific playbook; just stupid ansible nonsense assuming it knows better than my /etc configuration files. – Parthian Shot Jul 15 '15 at 16:34
  • check /home on the target machine - I got this error when /home was 100% –  Jun 15 '16 at 09:11

1 Answers1

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.

Parthian Shot
  • 1,165
  • 4
  • 16
  • 32
  • 5
    Right, but which of the args in particular did you override to fix the problem? – brk3 May 09 '16 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](https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing)). If that stops the failures, you could see whether your client or server openssh version is at fault - see [this bug report](https://bugzilla.redhat.com/show_bug.cgi?id=1242682) . See [this answer](http://stackoverflow.com/a/39382868/992887) 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 '17 at 09: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 05 '17 at 23:19