1

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)

  • 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 Mar 30 '17 at 19:27
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.

  • @tensi I'd agree with you, but when I typed it up as a comment, it sounded more like an answer! – Peter Turner Mar 30 '17 at 19:33
  • @tensibai, I just gone done trying it and it didn't work. I guess I can remove that line. – Peter Turner Mar 30 '17 at 20:51
  • 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 Mar 30 '17 at 20:54
  • But the answer itself makes sense I think, I can't tell not using ansible but sounds a factual observation now :) – Tensibai Mar 30 '17 at 20:55
  • While using pipelining, did you disable requiretty in /etc/sudoers as mentioned in the docs? docs.ansible.com/ansible/intro_configuration.html#pipelining – Woodland Hunter Mar 30 '17 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.