1

I'm trying to build a jar using maven and automatically scp it to a remote machine.

This is my pom.xml

<properties>
    <deploy.username>root</deploy.username>
    <deploy.host>10.10.4.10</deploy.host>
    <deploy.port>22</deploy.port>
    <deploy.dir>/root</deploy.dir>
</properties>

<distributionManagement>
    <repository>
        <id>repo1</id>
        <url>scpexe://${deploy.host}:${deploy.dir}</url>
    </repository>
</distributionManagement>

This is my settings.xml:

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>repo1</id>
      <username>root</username>
      <password>root</password>
    </server>
  </servers>  
</settings>

This the error log

Caused by: org.eclipse.aether.transfer.MetadataTransferException: Could not transfer metadata com.github.rssanders3.spark:spark_quick_start:1.0-SNAPSHOT/maven-metadata.xml from/to repo1 (scpexe://10.10.4.10:/root): Exit code: 1 - Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

    at org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed(MetadataTransportListener.java:43)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
    at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:222)
    at org.eclipse.aether.internal.impl.DefaultDeployer.upload(DefaultDeployer.java:417)
    ... 28 more
Caused by: org.apache.maven.wagon.TransferFailedException: Exit code: 1 - Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

You can see the full output of maven -X in here

I'm submitting using the following command:

mvn deploy -DskipTests --settings settings.xml

The user name and and password is correct, I'm able to ssh to it use this credential. I even tried to scp a file to the remote without any problem.

I check maven debug output, it is loading the user defined settings.xml I created.

[DEBUG] Reading user settings from /Users/xuanyue/tmp/apache-spark-quickstart-project/settings.xml

And on the ssh server side, this is the only thing I get:

Feb 23 14:33:02 hadoop10 sshd[23804]: Connection closed by 192.168.100.26

I also tried replace scpexe with scp. Still not worked.

xuanyue
  • 1,368
  • 1
  • 17
  • 36

3 Answers3

0

Try running it with the -X option:

mvn -X deploy -DskipTests --settings settings.xml

I suspect the problem may be to do with the user at the other side and their permissions (not necessarily file system permissions).

hack_on
  • 2,532
  • 4
  • 26
  • 30
0

First you could restart sshd on your server with -v (or -vvv for full debug) and thus get more logs in your security file.

Also it looks to me you are trying to scp on a server, have you tried using the plugin org.apache.maven.wagon ?

See Mr Thivent's post: Uploading a File via SCP with Maven fails

Community
  • 1
  • 1
Adonis
  • 4,670
  • 3
  • 37
  • 57
  • Yes, I'm using wagon, version is 1.0-beta-6.. The same version you pointed to. But it doesn't show how to configure using the password. – xuanyue Feb 23 '17 at 22:29
  • When you first logged in via ssh did it ask you to add a RSA key? And I mean the very first time with the laptop you are using. – Adonis Feb 24 '17 at 07:50
  • There are two things you might want to try in your configuration, in settings.xml: 1. Use the filePermissions/directoryPermissions in the server section see http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html 2. Try to disable the host checking on the server side, see: http://stackoverflow.com/questions/2685988/how-to-avoid-maven-builds-stall-on-ssh-host-authenticity-problem/2687946#2687946 – Adonis Feb 24 '17 at 08:14
0

You probably need the Maven Wagon Provider for SSH. Note that it must be added as a build extension.

<project>
  ...
  <build>
    <extensions>
      <extension>
        <groupId>org.apache.maven.wagon</groupId>
         <artifactId>wagon-ssh</artifactId>
         <version>2.10</version>
      </extension>
    </extensions>
  </build>
  ...
</project>

If you have this Wagon Provider, then the failure is likely due to your using an ancient version of Maven Wagon (you mentioned version 1.0-beta-6), which might work well with matching ancient versions (but certainly won't work well with the modern maven-dist-plugin).

Beta versions of Maven Wagon SSH do not need to be used. The current version as of now is 2.10.

Likewise, I don't believe you need to include the Maven Wagon Plugin as the maven-dist-plugin doesn't use that plugin, it directly uses the more modern wagon-provider-api. You should only need the SSH Wagon extension.

Finally, you should run a remote sshd instance for testing, from the command line (so the information goes to the terminal) with enough debugging on to determine if you are reaching the test box, and if you are actually passing in valid credentials (as sshd considers them).

It is important to remember that sshd has specific configuration options which deny root logins, if they are set. If you have access to the remote sshd box, you might also want to verify the sshd settings.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • I upgrade to 2.10 now, but the problem is still there. I open a new ssh daemon on a different port with debug option. This link shows the sshd log at http://pastebin.com/6252TuYy. Weird thing is it doesn't show any failure * aside from a attempt using public key. But I'm using password and username. And these word doesn't exist in the log it yet. in sshd_config, root login is allowed and allow password log in... – xuanyue Feb 24 '17 at 03:45
  • So, with the debugging on, you should see both your server advertising the permitted authentication strategies and the clean advertising the available authentication strategies. Typically most systems try better strategies and then fall back to other less desired strategies, password will be near the end of the list. I'm assuming you can login manually with a plain ssh command, so it's not a problem with the servers. Odds are your client isn't advertising it can handle the password strategy, or your server is broadcasting it isn't supported. – Edwin Buck Feb 24 '17 at 18:15