<p>The cure (or bandaid) was to set Pipelining=False in the ansible.cfg file.  </p>

<p>This kind of stinks because I like Pipelining and it works, but I guess ansible is gonna treat that first ssh statement as something 'it owns' even though it's a local action.</p>

CC BY-SA 3.0
2017-03-30T19:33:26.457Z
@tensi I'd agree with you, but when I typed it up as a comment, it sounded more like an answer!
Peter Turner
CC BY-SA 3.0
2017-03-30T20:51:45.137Z
@tensibai, I just gone done trying it and it didn't work. I guess I can remove that line.
Peter Turner
CC BY-SA 3.0
2017-03-30T20:54:13.417Z
Just in case, you can edit your question to add more information of what you tried and didn't work, sorry for not helping much on the problem itself
Tensibai
CC BY-SA 3.0
2017-03-30T20:55:21.663Z
But the answer itself makes sense I think, I can't tell not using ansible but sounds a factual observation now :)
Tensibai
CC BY-SA 3.0
2017-03-30T21:30:49.137Z
While using pipelining, did you disable requiretty in /etc/sudoers as mentioned in the docs? http://docs.ansible.com/ansible/intro_configuration.html#pipelining
Woodland
CC BY-SA 3.0
2017-03-30T21:49:37.597Z
@woodland No, it is on and I knew about that I just didn't check for it because, It worked for me a few times before I went and refactored the script.  I removed a lot of become's and passwords and junk from the playbook and then it stopped working - now that you mention it, this is probably _the_ reason it wasn't working.
Peter Turner
CC BY-SA 3.0
2017-03-31T17:29:05.680Z
Peter did not mention Pipelining in his original post, only in this answer, hence the messy question. I agree that we should have a more authoritative answer, but the fact that you've recommended this for deletion, Jiri, is antithetical to finding a solution.
Woodland
CC BY-SA 3.0
2017-03-31T18:15:25.323Z
Yeah (seeming as I both answered and asked the question).  I think this is an answer to the question because if you see similar debug output in ansible, where "sudo:yes" doesn't work and "sudo:no" does work, then there's a good chance this is the issue.
Peter Turner
CC BY-SA 4.0
2019-04-17T22:37:17.553Z
this seems like an 'ansible trap'. Lost hours on it but would  upvote this more if I could!
james6125
CC BY-SA 4.0
2019-04-18T01:19:01.327Z
@james I think the other fix is to put something like notty or requriretty in your /etc/sudoers file - that way pipelining actually does work.  I was doing a roundabout method of connecting to devices that pipelining never seems to work for.
Peter Turner
CC BY-SA 3.0
2017-03-30T19:17:10.417Z
2017-03-30T20:52:01.107Z
2017-03-30T20:52:01.107Z
Peter Turner
<p>What does it mean when this:</p>

<pre><code>EXEC sshpass -d29 ssh -C -vvv 
  -o ControlMaster=auto 
  -o ControlPersist=60s 
  -o ControlPath="/root/.ansible/cp/ansible-ssh-%h-%p-%r" -o StrictHostKeyChecking=no\
  -o Port=58030 
  -o User=em7admin 
  -o ConnectTimeout=30 127.0.0.1 /bin/sh 
  -c 'sudo -H -p "[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: " 
  -S -u root /bin/sh 
  -c '"'"'echo BECOME-SUCCESS-mxraphooaxhpruunceorxkcelobceggf; LANG=C LC_MESSAGES=C LC_CTYPE=C /usr/bin/python'"'"''
</code></pre>

<p>returns this:</p>

<pre><code>debug1: Sending command: /bin/sh -c 'sudo -H -p \"[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: \" -S -u root /bin/sh -c '\"'\"'echo BECOME-SUCCESS-mxraphooaxhpruunceorxkcelobceggf; LANG=C LC_MESSAGES=C LC_CTYPE=C /usr/bin/python'\"'\"''
debug2: channel 2: request exec confirm 1
debug3: mux_session_confirm: sending success reply
debug2: callback done
debug2: channel 2: open confirm rwindow 0 rmax 32768
debug1: mux_client_request_session: master session id: 2
debug2: channel 2: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 2
debug2: exec request accepted on channel 2
debug2: channel 2: read&lt;=0 rfd 6 len 0
debug2: channel 2: read failed
debug2: channel 2: close_read
debug2: channel 2: input open -&gt; drain
debug2: channel 2: ibuf empty
debug2: channel 2: send eof
debug2: channel 2: input drain -&gt; closed
debug2: channel 2: rcvd ext data 67
[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: debug2: channel 2: written 67 to efd 8
debug2: channel 2: rcvd ext data 18
debug2: channel 2: rcvd ext data 67
Sorry, try again.\n[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: debug2: channel 2: written 85 to efd 8
debug2: channel 2: rcvd ext data 18
debug2: channel 2: rcvd ext data 67
Sorry, try again.\n[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: debug2: channel 2: written 85 to efd 8
debug2: channel 2: rcvd ext data 18
debug2: channel 2: rcvd ext data 36
Sorry, try again.\nsudo: 3 incorrect password attempts\ndebug2: channel 2: written 54 to efd 8
debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
debug3: mux_exit_message: channel 2: exit message, exitval 1
debug1: client_input_channel_req: channel 2 rtype eow@openssh.com reply 0
</code></pre>

<p>I've tried many combinations of ansible_ssh_pass and using the password from the commandline (I need to get ansible running so I can get the public keys on these devices),  but still it's sudo that isn't working.  Sudo does work for the username and password on the device.</p>

<p>The only wacky thing I'm doing here is setting the ansible_port after the play starts.  </p>

<pre><code>- hosts: devices
  gather_facts: False
  pre_tasks:
  - name: Get ephemeral port
    local_action: ephemeral_port
    register: ephemeral_port
  - name: Run local ssh command to enable proxy
    local_action: shell /usr/bin/ssh -p {{proxy_port}} -o 'HostKeyAlias=[{{proxy_ip}}]:{{proxy_port}}' -o 'UserKnownHostsFile=/home/user/.ssh/known_hosts' -i /home/user/.ssh/id_dsa -o 'ConnectTimeout=5' -o 'ControlMaster=auto' -o 'ControlPath=%r@%h:%p' -o 'ControlPersist=10s' -f -N -l user -L {{ephemeral_port.port}}:{{silo_private_ip}}:22 {{proxy_ip}}
  - name: Change ansible port to ephemeral port
    set_fact:
      ansible_port: "{{ephemeral_port.port}}"
  tasks:
    - name: test
      sudo: yes
      shell: hostname
</code></pre>

<p>I even had it working once, but I deleted the old playbook and I can't remember what was in it - this playbook is a lot simpler than the one I started with and I don't really want to start.</p>

<p>If I take out the pre_task part it works fine too (I just ran it once, copied the port number and hard coded it in as the <code>ansible_port</code> in the host_vars file) </p>

CC BY-SA 3.0
2017-03-30T19:27:16.283Z
Just a guess, but I think your [sudo via...] is passed as is, either a quote problem or you need to craft a non sensible thing to reproduce the problem and share it verbatim....
Tensibai
<ansible><ports>
Why is ansible not sending the correct sudo password?
Peter Turner
# Why is ansible not sending the correct sudo password?

(Asked by: username_0 on 2017-03-30)

What does it mean when this:
EXEC sshpass -d29 ssh -C -vvv 
  -o ControlMaster=auto 
  -o ControlPersist=60s 
  -o ControlPath="/root/.ansible/cp/ansible-ssh-%h-%p-%r" -o StrictHostKeyChecking=no\
  -o Port=58030 
  -o User=em7admin 
  -o ConnectTimeout=30 127.0.0.1 /bin/sh 
  -c 'sudo -H -p "[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: " 
  -S -u root /bin/sh 
  -c '"'"'echo BECOME-SUCCESS-mxraphooaxhpruunceorxkcelobceggf; LANG=C LC_MESSAGES=C LC_CTYPE=C /usr/bin/python'"'"''

returns this:
debug1: Sending command: /bin/sh -c 'sudo -H -p \"[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: \" -S -u root /bin/sh -c '\"'\"'echo BECOME-SUCCESS-mxraphooaxhpruunceorxkcelobceggf; LANG=C LC_MESSAGES=C LC_CTYPE=C /usr/bin/python'\"'\"''
debug2: channel 2: request exec confirm 1
debug3: mux_session_confirm: sending success reply
debug2: callback done
debug2: channel 2: open confirm rwindow 0 rmax 32768
debug1: mux_client_request_session: master session id: 2
debug2: channel 2: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 2
debug2: exec request accepted on channel 2
debug2: channel 2: read<=0 rfd 6 len 0
debug2: channel 2: read failed
debug2: channel 2: close_read
debug2: channel 2: input open -> drain
debug2: channel 2: ibuf empty
debug2: channel 2: send eof
debug2: channel 2: input drain -> closed
debug2: channel 2: rcvd ext data 67
[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: debug2: channel 2: written 67 to efd 8
debug2: channel 2: rcvd ext data 18
debug2: channel 2: rcvd ext data 67
Sorry, try again.\n[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: debug2: channel 2: written 85 to efd 8
debug2: channel 2: rcvd ext data 18
debug2: channel 2: rcvd ext data 67
Sorry, try again.\n[sudo via ansible, key=mxraphooaxhpruunceorxkcelobceggf] password: debug2: channel 2: written 85 to efd 8
debug2: channel 2: rcvd ext data 18
debug2: channel 2: rcvd ext data 36
Sorry, try again.\nsudo: 3 incorrect password attempts\ndebug2: channel 2: written 54 to efd 8
debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
debug3: mux_exit_message: channel 2: exit message, exitval 1
debug1: client_input_channel_req: channel 2 rtype eow@openssh.com reply 0

I've tried many combinations of ansible_ssh_pass and using the password from the commandline (I need to get ansible running so I can get the public keys on these devices),  but still it's sudo that isn't working.  Sudo does work for the username and password on the device.
The only wacky thing I'm doing here is setting the ansible_port after the play starts.  
- hosts: devices
  gather_facts: False
  pre_tasks:
  - name: Get ephemeral port
    local_action: ephemeral_port
    register: ephemeral_port
  - name: Run local ssh command to enable proxy
    local_action: shell /usr/bin/ssh -p {{proxy_port}} -o 'HostKeyAlias=[{{proxy_ip}}]:{{proxy_port}}' -o 'UserKnownHostsFile=/home/user/.ssh/known_hosts' -i /home/user/.ssh/id_dsa -o 'ConnectTimeout=5' -o 'ControlMaster=auto' -o 'ControlPath=%r@%h:%p' -o 'ControlPersist=10s' -f -N -l user -L {{ephemeral_port.port}}:{{silo_private_ip}}:22 {{proxy_ip}}
  - name: Change ansible port to ephemeral port
    set_fact:
      ansible_port: "{{ephemeral_port.port}}"
  tasks:
    - name: test
      sudo: yes
      shell: hostname

I even had it working once, but I deleted the old playbook and I can't remember what was in it - this playbook is a lot simpler than the one I started with and I don't really want to start.
If I take out the pre_task part it works fine too (I just ran it once, copied the port number and hard coded it in as the ansible_port in the host_vars file)

**Tags:** ansible, ports

> **Comments:**
> **username_1**: Just a guess, but I think your [sudo via...] is passed as is, either a quote problem or you need to craft a non sensible thing to reproduce the problem and share it verbatim....  

---

## 1 answers

### Answer by username_0 on 2017-03-30. Score: 3

The cure (or bandaid) was to set Pipelining=False in the ansible.cfg file.

This kind of stinks because I like Pipelining and it works, but I guess ansible is gonna treat that first ssh statement as something 'it owns' even though it's a local action.

> **Comments:**
> **username_0**: @tensi I'd agree with you, but when I typed it up as a comment, it sounded more like an answer!  
> **username_0**: @tensibai, I just gone done trying it and it didn't work. I guess I can remove that line.  
> **username_1**: Just in case, you can edit your question to add more information of what you tried and didn't work, sorry for not helping much on the problem itself  
> **username_1**: But the answer itself makes sense I think, I can't tell not using ansible but sounds a factual observation now :)  
> **username_2**: While using pipelining, did you disable requiretty in /etc/sudoers as mentioned in the docs? http://docs.ansible.com/ansible/intro_configuration.html#pipelining  
> **username_0**: @woodland No, it is on and I knew about that I just didn't check for it because, It worked for me a few times before I went and refactored the script.  I removed a lot of become's and passwords and junk from the playbook and then it stopped working - now that you mention it, this is probably _the_ reason it wasn't working.  
> **username_2**: Peter did not mention Pipelining in his original post, only in this answer, hence the messy question. I agree that we should have a more authoritative answer, but the fact that you've recommended this for deletion, Jiri, is antithetical to finding a solution.  
> **username_0**: Yeah (seeming as I both answered and asked the question).  I think this is an answer to the question because if you see similar debug output in ansible, where "sudo:yes" doesn't work and "sudo:no" does work, then there's a good chance this is the issue.  
> **username_3**: this seems like an 'ansible trap'. Lost hours on it but would  upvote this more if I could!  
> **username_0**: @james I think the other fix is to put something like notty or requriretty in your /etc/sudoers file - that way pipelining actually does work.  I was doing a roundabout method of connecting to devices that pipelining never seems to work for.  

---

