Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-48413

Hosts unreachable when using a private key with passphrase provided using the Credentials plugin

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Blocker
    • Resolution: Unresolved
    • Component/s: ansible-plugin
    • Labels:
      None
    • Environment:
      Debian Jessie
      OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
      jenkins 2.73.3 (stable)
      with plugin ansible 0.6.2
      and plugin credentials 2.1.16
      ansible-playbook 2.4.2.0
    • Similar Issues:

      Description

      TL;DR: it seems the ansible plugin does not get/provide the passphrase correctly from/to the credentials plugin.

      See also: -JENKINS-20879-

      When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

       

      When I add the

      --ssh-extra-args="-o BatchMode=yes"

      option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

       

      I have also tested the following:

      • the playbook's execution is OK using the passphraseless key
      • i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
      • the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary .sh file generated in the $CATALINA_HOME/temp folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (.key) containing the deciphered key

      All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

      The following SSH debug output is generated by Ansible with options :

       --ssh-extra-args="-o BatchMode=yes"

      and

      -vvvvv

       

      debug1: Next authentication method: publickey
      debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
      debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
      debug2: we did not send a packet, disable method
      debug1: No more authentication methods to try.
       Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

      But, as I understand the SSH message incorrect passphrase supplied to decrypt private key, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).

        Attachments

          Activity

          bardelotnzl Noël Bardelot created issue -
          bardelotnzl Noël Bardelot made changes -
          Field Original Value New Value
          Description When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

          When I add the `--ssh-extra-args="-o BatchMode=yes"` option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

          I have also tested the following:

            * the playbook's execution is OK using the passphraseless key

            * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH

            * the passphrase stored by the Credentials plugin seems fine (during some tests I could  see a temporary `.sh` file generated in the `$CATALINA_HOME/tmp` folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary `.key` file containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible (with `--ssh-extra-args="-o BatchMode=yes"` and `-vvvvv`):

          ```
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
          Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
          ```

          But, as I understand the SSH message `incorrect passphrase supplied to decrypt private key`, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           *   the playbook's execution is OK using the passphraseless key
           *   i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/tmp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}




          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          bardelotnzl Noël Bardelot made changes -
          Description When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           *   the playbook's execution is OK using the passphraseless key
           *   i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/tmp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}




          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/tmp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          bardelotnzl Noël Bardelot made changes -
          Description When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/tmp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          bardelotnzl Noël Bardelot made changes -
          Description When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          See also: JENKINS-20879

          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          bardelotnzl Noël Bardelot made changes -
          Description See also: JENKINS-20879

          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key)

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          See also: -JENKINS-20879-

          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          bardelotnzl Noël Bardelot made changes -
          Description See also: -JENKINS-20879-

          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          TL;DR: it seems the ansible plugin does not get/provide the passphrase correctly from/to the credentials plugin.

          ---

          See also: --JENKINS-20879--

          When I run a job with an Ansible build task that uses a private key with a passphrase provided by the Credentials plugin, the playbook hangs.

           

          When I add the
          {code:java}
          --ssh-extra-args="-o BatchMode=yes"{code}
          option to the build, Ansible fails quickly, and hosts are unreachable. That indicates to me that SSH is prompting for the passphrase of my private key. As the jenkins job is not interactive, it hangs without the option.

           

          I have also tested the following:
           * the playbook's execution is OK using the passphraseless key
           * i can reach the hosts using a manual SSH command with the passphrase-enabled key, after being prompted for the passphrase by SSH
           * the passphrase stored by the Credentials plugin seems fine : during some tests I could  see a temporary _.sh_ file generated in the _$CATALINA_HOME/temp_ folder of Jenkins/Tomcat, that contains the passphrase in clear-text, and is used to generate a temporary PEM file (_.key_) containing the deciphered key

          All in all it seems the only remaining explaination is that there is a bug in the implementation of the Ansible plugin.

          The following SSH debug output is generated by Ansible with options :
          {code:java}
           --ssh-extra-args="-o BatchMode=yes"{code}
          and
          {code:java}
          -vvvvv{code}
           
          {code:java}
          debug1: Next authentication method: publickey
          debug1: Trying private key: /usr/local/tomcat/temp/ssh1471148055772625127.key
          debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
          debug2: we did not send a packet, disable method
          debug1: No more authentication methods to try.
           Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).{code}
          But, as I understand the SSH message _incorrect passphrase supplied to decrypt private key_, it can also mean the PEM file is corrupted. And in fact, when I can see the file it is empty (0 byte).
          bardelotnzl Noël Bardelot made changes -
          Environment Debian Jessie

          jenkins 2.73.3 (stable)
          with plugin ansible 0.6.2
          and plugin credentials 2.1.16
          ansible-playbook 2.4.2.0
          Debian Jessie
          OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
          jenkins 2.73.3 (stable)
          with plugin ansible 0.6.2
          and plugin credentials 2.1.16
          ansible-playbook 2.4.2.0

            People

            • Assignee:
              sirot Jean-Christophe Sirot
              Reporter:
              bardelotnzl Noël Bardelot
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: