Support using an SSH private key as auth mechanism

[lppedd]

This enhancements brings support for using an SSH key (+ optional passphrase) as an authentication mechanism.
Extremely useful in case the work is done over GitHub Enterprise instances.

Configuration example:

<distributionManagement>
  <site>
    <id>my-server-id</id>
    <url>scm:jgit:git@my-domain:my-org/my-repo.git</url>
  </site>
</distributionManagement>
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-scm-publish-plugin</artifactId>
  <version>3.2.0-SNAPSHOT</version>
  <configuration>
    <serverId>my-server-id</serverId>
    <scmBranch>gh-pages</scmBranch>
  </configuration>
</plugin>

And in settings.xml:

<servers>
  <server>
    <id>my-server-id</id>
    <privateKey>${user.home}/.ssh/id_rsa</privateKey>
    <passphrase>your-optional-passphrase</passphrase>
  </server>
</servers>

Note the jgit provider used in the distributionManagement.site.url element. This is needed as jgit is the only provider that currently supports using a private key.

The change is so small I don't even think it's worth creating a Jira issue tbh.
In case you really need it, just take my changes and create another PR.

---

Following this checklist to help us incorporate your contribution quickly and easily:

• [ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• [X] Each commit in the pull request should have a meaningful subject line and body.
• [ ] Format the pull request title like [MSCMPUBLISH-XXX] - Fixes bug in ApproximateQuantiles, where you replace MSCMPUBLISH-XXX with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message.
• [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [ ] Run mvn clean verify -Prun-its to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement if you are unsure please ask on the developers list.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004 you have to acknowledge this by using the following check-box.

• [X] I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004

• [ ] In any other case, please file an Apache Individual Contributor License Agreement.

[bmarwell]

Thanks! Do you think you could add a junit test? There are sshd mock servers you could use.

[lppedd]

Hey there @bmarwell! I've noticed all the currently present integration tests revolve around SVN.

Not sure how to mock a git server with SSH support. Probably JGit offers something useful.

Found this by googling quickly. https://archive.eclipse.org/jgit/site/5.6.0.201912101111-r/apidocs/org/eclipse/jgit/transport/ssh/SshTestHarness.html

My concern here is: we covered pretty much all the server element auth fields, and we're handling them through the platform, which is tested for us already. Should we really add a test case?

Up to you. I can try out the JGit test harness in the meantime.

[lppedd]

Also on another note: do you think I should add the privateKey and passphrase parameters to the mojo?

They might be useful in case a user wants to override them at build time with a property.
I might need them too now that I'm thinking about it.

[bmarwell]

The correct place would be the user's settings.xml file. But I'm not sure of there's a place for it yet.

[lppedd]

The correct place would be the user's settings.xml file

In terms of security it's definitely better, I agree.
But can't we say the same about username and password, which are parameters on this mojo already?

[lppedd]

I've been experimenting with auth tokens with the git and jgit SCM providers, as another alternative auth mechanism. I've improved the parameters' documentation to explain how the two can be used for this case.

I will test this out with GitHub Apps too, soon.

[lppedd]

Minimal usage example with jgit for a Jenkins declarative pipeline, where your-app-jenkins are GitHub App credentials.

stage('Publish site') {
  environment {
    CREDS = credentials('your-app-jenkins')
  }

  steps {
    bat 'mvnw clean site site:stage scm-publish:publish-scm' +
            ' -DauthUser=%CREDS_USR%' +
            ' -DauthToken=%CREDS_PSW%'
  }
}

And

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-scm-publish-plugin</artifactId>
  <version>${scmPublishVersion}</version>
  <dependencies>
    <dependency>
      <groupId>org.apache.maven.scm</groupId>
      <artifactId>maven-scm-provider-jgit</artifactId>
      <version>${scmProviderJGitVersion}</version>
    </dependency>
  </dependencies>
  <configuration>
    <username>${authUser}</username>
    <password>${authToken}</password>
  </configuration>
</plugin>

[lppedd]

@bmarwell hey there! Is there a chance we can merge this PR soon? Docs improvements and SSH key support would be nice to have for colleagues too.

[elharo]

This needs a JIRA issue

[bmarwell]

@lppedd I second what @elharo says. Do you have a JIRA account or should I just create an issue for you?

[kwin]

This would implicitly be solved via #29.