Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-30T19:33:26.457Z
Answers: @tensi I'd agree with you, but when I typed it up as a comment, it sounded more like an answer!
Answers: Peter Turner
Answers: CC BY-SA 3.0
Answers: 2017-03-30T20:51:45.137Z
Answers: @tensibai, I just gone done trying it and it didn't work. I guess I can remove that line.
Answers: Peter Turner
Answers: CC BY-SA 3.0
Answers: 2017-03-30T20:54:13.417Z
Answers: 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
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-30T20:55:21.663Z
Answers: But the answer itself makes sense I think, I can't tell not using ansible but sounds a factual observation now :)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-30T21:30:49.137Z
Answers: While using pipelining, did you disable requiretty in /etc/sudoers as mentioned in the docs? http://docs.ansible.com/ansible/intro_configuration.html#pipelining
Answers: Woodland
Answers: CC BY-SA 3.0
Answers: 2017-03-30T21:49:37.597Z
Answers: @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.
Answers: Peter Turner
Answers: CC BY-SA 3.0
Answers: 2017-03-31T17:29:05.680Z
Answers: 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.
Answers: Woodland
Answers: CC BY-SA 3.0
Answers: 2017-03-31T18:15:25.323Z
Answers: 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.
Answers: Peter Turner
Answers: CC BY-SA 4.0
Answers: 2019-04-17T22:37:17.553Z
Answers: this seems like an 'ansible trap'. Lost hours on it but would  upvote this more if I could!
Answers: james6125
Answers: CC BY-SA 4.0
Answers: 2019-04-18T01:19:01.327Z
Answers: @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.
Answers: Peter Turner
Answers: CC BY-SA 3.0
Answers: 2017-03-30T19:17:10.417Z
Answers: 2017-03-30T20:52:01.107Z
Answers: 2017-03-30T20:52:01.107Z
Answers: Peter Turner
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-30T19:27:16.283Z
Comments: 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....
Comments: Tensibai
Tags: <ansible><ports>
Title: Why is ansible not sending the correct sudo password?
UserDisplayName: Peter Turner
ThreadText: # 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**: @username_1, 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**: @username_2 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**: username_0 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.  
  
  ---
  
  