• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • ssh-credentials-plugin
    • None

      This is fallout from the fix for SECURITY-440 (see https://jenkins.io/security/advisory/2018-06-25/   )

      We upgraded to ensure that fix was installed back in June.
      For some reason it did not affect us until after upgrading to ssh-slaves 1.29.1 (from 1.28)

      We used to have the SSH private key that the master uses to log into the slaves, in $JENKINS_HOME/.ssh/jenkins - ie. not one of the names that jenkins searches for by default.
      When the master tries to connect to the client, it fails and there's no clue given as to why.

      This is the log I get when I try to reconnect to a node affected by this issue:
      ```
      SSHLauncher{host='fiasco', port=22, credentialsId='<elided>', jvmOptions='', javaPath='/usr/lib/jvm/java-8-openjdk-amd64/bin/java', prefixStartSlaveCmd='', suffixStartSlaveCmd='', launchTimeoutSeconds=210, maxNumRetries=10, retryWaitTime=15, sshHostKeyVerificationStrategy=hudson.plugins.sshslaves.verifiers.KnownHostsFileKeyVerificationStrategy, tcpNoDelay=true, trackCredentials=true}
      [12/11/18 10:33:49] [SSH] Opening SSH connection to fiasco:22.
      [12/11/18 10:33:49] [SSH] SSH host key matches key in Known Hosts file. Connection will be allowed.
      [12/11/18 10:33:49] [SSH] Authentication failed.
      Authentication failed.
      [12/11/18 10:33:49] Launch failed - cleaning up connection
      [12/11/18 10:33:49] [SSH] Connection closed.

      ```
      Similarly jenkins.log is silent about what the actual problem is:
      ```
      Dec 12, 2018 4:05:02 PM hudson.slaves.SlaveComputer tryReconnect
      INFO: Attempting to reconnect jessie-fiasco
      ```

      This issue has appeared before, in  https://issues.jenkins-ci.org/browse/JENKINS-24613 and it was claimed there that it has been documented. Can you please check that it actually was documented and point to where that documentation is? All I have been able to find is a reference in 24613 to a comment in the source code (https://github.com/jenkinsci/ssh-credentials-plugin/blob/master/src/main/java/com/cloudbees/jenkins/plugins/sshcredentials/impl/BasicSSHUserPrivateKey.java#L516). The list of accepted filenames is at line 484.

      I'm surprised there was no Big Fat Warning from the plugin about the change to requiring the private key to be pasted into the UI - at least I don't recall one.

      My request:
      Please log a warning in /var/log/jenkins/jenkins.log if the length of the private key in a SSH credential is less than 1 byte or so. That would give operators something to go on.

      Ideally there would be a warning in the UI of the credentials plugin.
      Another option would be a note on the page where you are required to enter the private key that files on disk are no longer accepted, or if they are, what the list of accepted filenames is.

       

          [JENKINS-55136] Log an error when ssh private key is empty

          Vince Murphy added a comment -

          Forgot to add - the workaround for us was:

          • Jenkins->Credentials->click on affected credential id->Update
          • Paste the private key contents into the field provided
          • Update the description so it no longer mentions file:/var/lib/jenkins/.ssh/jenkins
          • Save

          Vince Murphy added a comment - Forgot to add - the workaround for us was: Jenkins->Credentials->click on affected credential id->Update Paste the private key contents into the field provided Update the description so it no longer mentions file:/var/lib/jenkins/.ssh/jenkins Save

          Vince Murphy added a comment -

          After reading the java code I looked through my logs for this log message and did eventually find it.
          ```
          SECURITY-440: Migrating FileOnMasterPrivateKeySource to DirectEntryPrivateKeySource
          ```
          But I don't think that is enough information in this context (ie the log file, with no knowledge of the code).
          What does it mean, anyway?

          • The private key has been migrated for me? (it wasn't - is that a separate issue to look at?)
          • I should take steps to migrate the private key?

          Vince Murphy added a comment - After reading the java code I looked through my logs for this log message and did eventually find it. ``` SECURITY-440: Migrating FileOnMasterPrivateKeySource to DirectEntryPrivateKeySource ``` But I don't think that is enough information in this context (ie the log file, with no knowledge of the code). What does it mean, anyway? The private key has been migrated for me? (it wasn't - is that a separate issue to look at?) I should take steps to migrate the private key?

          Devin Nusbaum added a comment -

          Not sure why I am the default assignee here. Migration should be automatic when upgrading to a version with the SECURITY-440 fix. CC wfollonier who worked on that fix any might have an idea of what could be going on.

          Devin Nusbaum added a comment - Not sure why I am the default assignee here. Migration should be automatic when upgrading to a version with the SECURITY-440 fix. CC wfollonier who worked on that fix any might have an idea of what could be going on.

            Unassigned Unassigned
            xipmox Vince Murphy
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: