I trying to install HBase on a servers A and B (Ubuntu 18.04)
For that I using CDM (CDM 6.3.1~1466458.ubuntu1804) installed on server A to handle installation of HBASE on a server A and B.
But I have a problem during the step "Install Agents", the wizard display the following error message "Exhausted available authentication methods".
I have found some post on the Cloudera forum which speak about NOPASSWD to add into the sudoers file of the server B, but in my case I have already established a ssh connexion from the server A to the server B in command line and run a sudo command without any password, so I suppose my servers was correctly configured.
To be precise I trying to connect my servers by using a private key which I have generate a key couple in server A by using the following command :
ssh-keygen -t rsa
And after a add the content of the generated file .ssh/id_rsa.pub into the .ssh/authorized_keys file of server B After a retry I obtain the same result.
I found this trace in the log file:
2020-01-02 09:48:39,559 WARN NodeConfiguratorThread-22-0:com.cloudera.server.cmf.node.NodeConfigurator: Could not authenticate to SERVER_B net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods at net.schmizz.sshj.SSHClient.auth(SSHClient.java:232) at net.schmizz.sshj.SSHClient.auth(SSHClient.java:208) at com.cloudera.server.cmf.node.NodeConfigurator.connect(NodeConfigurator.java:416) at com.cloudera.server.cmf.node.NodeConfigurator.configure(NodeConfigurator.java:1028) at com.cloudera.server.cmf.node.NodeConfigurator.run(NodeConfigurator.java:1106) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Caused by: net.schmizz.sshj.userauth.UserAuthException: Problem getting public key from PKCS8KeyFile{resource=[PrivateKeyStringResource]} at net.schmizz.sshj.userauth.method.KeyedAuthMethod.putPubKey(KeyedAuthMethod.java:46) at net.schmizz.sshj.userauth.method.AuthPublickey.buildReq(AuthPublickey.java:62) at net.schmizz.sshj.userauth.method.AuthPublickey.buildReq(AuthPublickey.java:81) at net.schmizz.sshj.userauth.method.AbstractAuthMethod.request(AbstractAuthMethod.java:63) at net.schmizz.sshj.userauth.UserAuthImpl.authenticate(UserAuthImpl.java:68) at net.schmizz.sshj.SSHClient.auth(SSHClient.java:226) ... 9 more
Caused by: java.io.IOException: unrecognised object: OPENSSH PRIVATE KEY at org.bouncycastle.openssl.PEMParser.readObject(Unknown Source) at net.schmizz.sshj.userauth.keyprovider.PKCS8KeyFile.readKeyPair(PKCS8KeyFile.java:132) at net.schmizz.sshj.userauth.keyprovider.PKCS8KeyFile.getPublic(PKCS8KeyFile.java:78) at net.schmizz.sshj.userauth.method.KeyedAuthMethod.putPubKey(KeyedAuthMethod.java:44)
... 14 more
Does anyone have an idea to help me?
I hit this exact same issue, and it turns out ssh-keygen creates a private key file with BEGIN OPENSSH PRIVATE KEY that the Java libraries Cloudera uses don't know how to parse. You can instead use openssl with a command like:
openssl genrsa -out mykey.pem 1024
Unlike ssh-keygen that won't give you the public key you need, and the builtin openssl commands to get a public key from a private key aren't in a format Cloudera accepts. For that, you can use ssh-keygen like so:
ssh-keygen -y -f mykey.pem > mykey.pub
So I have found the origin of the problem. I need to add the pub key from server A on server B but I need also from server B to server A. That's all
I am trying to upload jar with Gradle and used Gradle SSH plugin: https://gradle-ssh-plugin.github.io/
Unfortunately, goal executed with error
* What went wrong:
Execution failed for task ':deploy'.
> reject HostKey: SERVERIPADDRESS
How to fix?
I found that there is similar error with Ant SSH task and it can be fixed with trust = true setting. Unfortunately, I can't find appropriate option here.
I.e. apparently, I need to configure SSH client so that it accept host's ID.
Try this:
ssh.settings {
knownHosts = allowAnyHosts
}
P.S: Sorry for editing mistakes, new to S.O.F.
Run: ssh-keyscan -t rsa server.com >> ~/.ssh/known_hosts
Explanation:
you have to add server SSH key info to your ~/.ssh/known_hosts file.
To obtain ssh-info run command ssh-keyscan -t rsa server.com
and add its output to ~/.ssh/known_hosts
As already said, you need to accept/validate the other server.
Another option for that would be to just connect to the server via ssh. Normally you will be asked to accept the server and the servers fingerprint will be added permanently to your known_hosts file.
Straight to specific problem
If I specify "fully qualified" SSH address with path in pom.xml
<scm>
<developerConnection>scm:git:username#hostname:/absolute/path/to/repo.git</developerConnection>
</scm>
and use it in command like
mvn --batch-mode release:prepare -Dtag=whatever -DreleaseVersion=3.0 -DdevelopmentVersion=4.0-SNAPSHOT
then I get error like
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on project maven_dependencies: Unable to tag SCM
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] fatal: 'hostname/absolute/path/to/repo.git' does not appear to be a git repository
[ERROR] fatal: Could not read from remote repository.
NOTE: The semicolon between hostname and /absolute/path/to/repo.git which was in pom.xml disappeared in the error output!
Additional details
Absolute vs relative path
Actually, I'm able to use Git with non-absolute path in SSH URL (relative to usernname's home directory). For example, using
scm:git:username#hostname:path/to/repo.git
instead of
scm:git:username#hostname:/home/username/path/to/repo.git
works perfectly.
Official documentation
I've read official Maven Release documentation for Git and, because standard SSH-like URL already worked at least in relative path case, I deliberately ignore its weird URL specification:
scm:git:ssh://username#hostname[:port]/~/path/to/repository
The reason to rebel and ignore this syntax is inability to imply path relative to user's home (which SSH does by default if path does not start with /). Moreover, colon : after hostname for standard SSH-like URL is a delimiter between hostname and path (not a port number)!
This means that Git URLs for SSH have to be specifically re-formatted for Maven Release plugin - what a headache!
I want to install bamboo agent on my working computer. I have downloaded the jar file and try to run it with following syntax
java -jar atlassian-bamboo-agent-installer-5.7.0.jar https://bamboo.xxxxx.org/agentServer/
I got error javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
The source of this error is clear to me - we have a self-signed SSL sertificate. I tried to run with following parameters
java -Dbamboo.agent.ignoreServerCertName=true -jar atlassian-bamboo-agent-installer-5.7.0.jar https://bamboo.xxxxx.org/agentServer/
but it does not work as well.
I tried to add the certificate using this link Java keytool easy way to add server cert from url/port
The sertificate seems to be installed, but it does not help. I still have the following error.
Do you know how can I fix it?
The problem was that bamboo did not obtained (for some reason) the keystorage created by keytool.
I needed to manually set the keystore in the bamboo configuration. In config/wrapper.conf you need to add following lines
wrapper.java.additional.3=-Djavax.net.ssl.keyStore=/#MODIFY_ME_TO_MY_HOME#/bamboo-agent-home/keystores/client.ks
wrapper.java.additional.4=-Djavax.net.ssl.keyStorePassword=#MY_AWESOME_PASSWORD#
wrapper.java.additional.5=-Djavax.net.ssl.trustStore=/#MODIFY_ME_TO_MY_HOME#/bamboo-agent-home/keystores/client.ts
This can be caused if you are running Bamboo behind Apache with SSL, if your default SSL VirtualHost is not returning the same SSLCertificate as your Bamboo VirtualHost. We had a similar problem, because I didn't know /etc/httpd/conf.d/ssl.conf created a VirtualHost.
I'm experimenting a bit with releasing my software (I've never done this before) and so far I've been able to execute mvn release:prepare. As I'm executing release:perform I get the following error:
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plug
in:2.7:deploy (default-deploy) on project img2stl: Failed to deploy artifacts: C
ould not transfer artifact nl.byterendition:img2stl:jar:0.9 from/to byterenditio
n-releases (https://localhost:443/svn/repo/releases): peer not authenticated ->
[Help 1]
I've set up a local password protected svn repository at localhost:443, so I added the following to my settings.xml in my .m2 folder
EDITED TO INCLUDE Edwin Buck's answer:
<?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>byterendition-releases</id>
<username>username</username>
<password>password</password>
</server>
<server>
<id>byterendition-snapshots</id>
<username>username</username>
<password>password</password>
</server>
</servers>
</settings>
This is the useful section of my pom:
<distributionManagement>
<repository>
<id>byterendition-releases</id>
<url>https://localhost:443/svn/repo/releases</url>
</repository>
<snapshotRepository>
<id>byterendition-snapshots</id>
<url>https://localhost:443/svn/repo/snapshots</url>
</snapshotRepository>
</distributionManagement>
How can I get maven to access the svn repository?
Ok, as Edwin Buck suggested I shouldn't use localhost, but since I haven't been able to get it to work otherwise I thought I'd try this using a remote SVN server I use for work. Now I get a different error:
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plug
in:2.7:deploy (default-deploy) on project img2stl: Failed to deploy artifacts: C
ould not transfer artifact nl.byterendition:img2stl:jar:0.9.5 from/to byterendit
ion-releases (https://svn.science.ru.nl/repos/estens/releases/): Failed to trans
fer file: https://svn.science.ru.nl/repos/estens/releases/nl/byterendition/img2s
tl/0.9.5/img2stl-0.9.5.jar. Return code is: 409, ReasonPhrase: Conflict. -> [Hel
p 1]
Again I can access this repo from Eclipse. Does anyone know what I'm doing wrong?
Since version 3.0.5 Maven checks the SSL certificate on https connections. You can temporarily fix this by adding the command line parameters
-Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true
Installing the SSL certificate into your JRE should permanently fix the issue.
Official documentation: http://maven.apache.org/wagon/wagon-providers/wagon-http/
Step 1. Download the certificate in DER format *.cer (/X.509 .cert) file to your local dir
(You can do this from your browser; For Chrome Click on the Lock symbol, Show Ceritficate --> Copy to File)
Step 2. Import it to Java trust store
\Program_Files\Java\jdk1.6.0_45\jre\lib\security>%JAVA_HOME%\jre\bin\keytool
-v -alias mavensrv -import -file d:\temp\apacher.cer -keystore trust.jks
Step 3. Give the path to maven as environment variables
set MAVEN_OPTS=-Xmx512m
-Djavax.net.ssl.trustStore=%JAVA_HOME%/jre/lib/security/trust.jks -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStore=%JAVA_HOME%/jre/lib/security/trust.jks -Djavax.net.ssl.keyStoreType=jks -Djavax.net.ssl.keyStorePassword=changeit
Your entry in settings.xml is for a server id of localhost but you are accessing repositories with id(s) of byterendition-releases and byterendition-snapshots.
This means that maven won't recogonize and associate the credentials with these two servers, because they have different "identities". You will need settings.xml entries for byterendition-releases and byterendition-snapshots.
Now if you added an entry like
<server>
<id>byterendition-releases</id>
<username>user</username>
<password>password</password>
</server>
Then maven would meet the https authentication challenge to byterendition-releases with a username of user and a password of password, because it has a server credential entry for byterendition-releases.
You'll also have to add in an additional entry for byterendition-snapshots, or set it to have the same server id as byterendition-releases.
--- Edited to keep up with the updated question ---
You are reaching for your repository with a localhost URL. While this might work if your repository is really on the same host machine, there are lots of reasons why it might not work.
The SVN repository is on a remote SVN server, so this will fail when developing elsewhere than the remote server.
The HTTP server is not configured to resolve localhost exactly the same way that it might resolve an external request.
Either way, ditch localhost. If you can't get a stable DNS name for the machine, even putting in an IP address is a better choice. If your SVN server is on DHCP, then invest the time into getting DynamicDNS working (but really, you should get a static IP for a server if you can).
https://github.com/escline/InstallCert provides the necessary tools and provides a step by step instruction on how to import a remote certificate into the system-wide certificate store.
I found that the Java version can make a difference here.
With Maven 3.0.5 I was getting this error with Java 6, but switching to Java 7 (or newer) resolved it for me.
It looks like a SSL problem when connecting to the server. Maybe before the username and password check.
Did you config the svn server with SSL client auth? This means you need to send a client certificate to the server.
I've had lot of security issues after upgrading to OSX Mavericks
SSL problem with Amazon AWS
peer not authenticated with Maven and Eclipse
trustAnchors parameter must be non-empty
I applied this JAVA update and it fixed all my issues:
http://support.apple.com/kb/DL1572?viewlocale=en_US
I'm using maven 3.5.3, and I choose to temporarily fix this SSL issue by adding the command line parameters according to above answers. But the parameters's format seems changed a little.
-D maven.wagon.http.ssl.insecure=true -D maven.wagon.http.ssl.allowall=true
Sorry I can't comment #Alex Punnen's answer, so I have to write a new answer.
I had the same issue using maven 3.6.0. All proposed solutions (using -Dmaven.wagon.http.ssl.insecure=true, -Dmaven.wagon.http.ssl.allowall=true, update CA store) did not work for me. Actually the deployment failed not on the first module but on the ~25ish or so, and was successful for all previous modules. Thus I assumed that in general the SSL handling was ok and there was general issue in the local <> server connection or certificates.
Leaving me quite confused for some time, I today stumbled across this jacoco issue where they mention the deployAtEnd parameter. Adding this parameter to my pom.xml as part of the deploy plugin configuration solved the issue for me.
However, I'm yet not clear on why the deployment failed on some later module and not on the first already.