I'm running Jenkins CI inside a corporate network which uses a proxy for internet access.
I tried to configure proxy details in Plugins->Advanced, but even though the credentials are correct (yeah, I checked it a bunch of times), it cannot validate "Test URL" even on http://google.com and returns
Failed to connect to http://google.com (code 407).
Strangely, Jenkins is still able to download plugins itself (whoa!), but totally unable to connect to any HTTP resource. The message that outputs from the console is:
←[0mApr 16, 2015 1:58:56 PM
org.apache.commons.httpclient.HttpMethodDirector pro
cessProxyAuthChallenge INFO: Failure authenticating with NTLM #proxyrye.asg.com:80 Apr 16, 2015 2:09:09 PM
org.apache.commons.httpclient.HttpMethodDirector execute WithRetry
INFO: I/O exception (java.net.ConnectException) caught when processing
request: Connection timed out: connect Apr 16, 2015 2:09:09 PM
org.apache.commons.httpclient.HttpMethodDirector execute WithRetry
INFO: Retrying request Apr 16, 2015 2:09:10 PM
org.apache.commons.httpclient.auth.AuthChallengeProcesso r
selectAuthScheme INFO: ntlm authentication scheme selected ←[31mApr
16, 2015 2:09:10 PM org.apache.commons.httpclient.HttpMethodDirector
au thenticate SEVERE: Credentials cannot be used for NTLM
authentication: org.apache.commons.h
ttpclient.UsernamePasswordCredentials
org.apache.commons.httpclient.auth.InvalidCredentialsException:
Credentials cann ot be used for NTLM authentication:
org.apache.commons.httpclient.UsernamePasswo rdCredentials
at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme
.java:332)
We had this issue a rather long time with our Jenkins behind our company's proxy. The other day they changed the order of authentication schemes our proxy desires. This was the day our Jenkins stopped connecting to the internet.
Obviously Jenkins is not able to connect via a proxy that requires NTML authentication. This was what lead me to issue an improvement for Jenkins to extend the proxy configuration screen. During the work on the extension I discovered that Jenkins does not make use of all proxy related system properties, therefore it cannot work with NTLM.
As such the answer for a proxy that allows only NTLM authentication is: it will not work via the Jenkins UI.
But if your proxy allows other authentication schemes, you can follow our workaround, it is rather simple: add the java system property -Dhttp.auth.preference="basic" to your Jenkins startup script or to that one of your container.
This will force the underlying libraries and Java mechanisms Jenkins makes use of to connect to your proxy using basic authentication, not NTLM.
for Java JDK8 and above, Oracle has disabled basic auth tunnelling for Basic authentication. If you want to use Basic mode again (security will be compromised), execute Jenkins adding this parameter to your JAVA_OPTS variable
"-Djdk.http.auth.tunneling.disabledSchemes="
default value is
"-Djdk.http.auth.tunneling.disabledSchemes=Basic",
as Basic scheme is DISABLED by default, it will return HTTP 407 error even if your credentials were OK.
more on link https://issues.jenkins-ci.org/browse/JENKINS-48775 Thanks to Israel Romero Fiji
The below solution worked for me for the 407 problem in Windows 7 machine.
1. Stop Jenkins from Windows Services
2. Goto Services.msc > Jenkins > Right Click > Properties > Logon > This account and type in your username and password
3. Click Apply and Ok
3. Start Jenkins
I was getting this error while running jenkins with jetty server on jdk 8.
To resolve issue follow below steps:
Step 1:
Open URL https://updates.jenkins.io/ in browser
Step 2:
To export the Intermediate certificate:
Internet Explorer -> Tools -> Internet Options -> Content -> Certificates ->
Go to Trusted Root Certification Authorities Tab and find out the DST Root CA X3 certificate. Then Export the Certificate:
Select Certificate -> Export -> DER encoded Binary Format -> Save
save the certificate as jenkins.cer (for me it was saved to C:\jenkins\jenkins.cer
( From Firefox -> Tools -> Options -> Advanced -> Encryption -> View Certificates )
Step 3:
create keystore with name cacertskeystore
JAVA_HOME\bin\keytool -keystore C:\jenkins\cacertskeystore -genkey -alias cacerts
Step 4:
Add jenkins.cer to cacertskeystore using below command
JAVA_HOME\bin\keytool -import -trustcacerts -Keystore C:\jenkins\cacertskeystore -alias jenkins -file C:\jenkins\jenkins.cer
Step 5: Start jetty server with below command
JAVA_HOME\bin\java -DJENKINS_HOME=C:/jenkins/home -Djavax.net.ssl.trustStore=C:/jenkins/cacertskeystore -Djavax.net.ssl.trustStorePassword=password-provided-while-creating-keystore -jar jenkins.war --httpPort=8080--httpListenAddress=localhost
I found this question while affected by bug: https://issues.jenkins-ci.org/browse/JENKINS-48775
The temporary workaround is to open the Jenkins script console and type
ProxyConfiguration.open(new java.net.URL("http://jenkins.io")).content
Since it's an http url, and not an https url, it will refresh some caches and make the plugin manager work with the proxy settings, at least for some time. See the bug report for more details.
If you parse the exception, it states
Credentials cannot be used for NTLM authentication
So according to https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch04s09.html you might need to provide a domain name as well.
If your proxy is using Microsoft’s NTLM authentication scheme, then you will need to provide a domain name as well as a username. You can place both in the User name field: just enter the domain name, followed by a back-slash (\), followed by the username, such as “MyDomain\Joe Bloggs”.
Maybe that's the issue?
I ran into this issue today, and it finally ended up being a space at the end of the Spira URI in the Spira configuration. Must've been a bad copy and paste.
I got the Failed to connect to http://google.com (code 407) error in Test. But jenkins can check new version and install plugins&updates.
Put in credentials regardless of the Test. Then Save and go to available plugins/check jenkins version to check if it works.
Simple Hack:
Try using the IP of the domain rather than the address. -Dhttp.auth.preference="basic" actually didn't work for me :(
PS. Change both the browser and proxy and the Jenkins proxy to the IP
I have also faced same issue of jenkins-proxy-407-error
I have found work around for that, I Hope it will be useful for other users :
You can install Cntlm Authentication Proxy , it stands between your applications and the corporate proxy, adding NTLM authentication on-the-fly.
See here http://cntlm.sourceforge.net/
Once you install CNTLM, add your NTLM credentials in a file cntlm.ini . You can also configure Listen port or default to 3128 .
Find detailed instruction of CNTLM installation here
https://vijiboy.wordpress.com/2018/03/14/configure-cntlm-to-generate-hash-for-your-password-h-and-verify-m/
Start CNTLM service and go to jenkins, add
host: host name or localhost
port: Listen port specified in cntlm.ini or default 3128
keep username and password blank and you are set to use Jenkins.
Solution is so simple
If you tried to edit
jdk.http.auth.tunneling.disabledSchemes=Basic
to
jdk.http.auth.tunneling.disabledSchemes=
at location C:.......\java-1.8.0-openjdk\jre\lib\net.properties
Then later try to enter
fill this section with proper entries
Done.
Check this screenshot
Related
I have an API server which built with Spring Boot 2.4.x on public domain and public IP which serve APIs running several years normal.
After 2023-01-01, user reports front-end web fails to call API after 30 seconds of the first API calls. (The first API call is successfully)
We tried use other RESTful client software to call API and get same result. It's not the front-end web problem.
We trace the error with Chrome developer mode (DevTools) - Network tab, get (failed) net::ERR_TIMED_OUT in status field.
We do not change any our code, any SpringBoot version and settings or OS updates in server side in two months before 2023-01-01.
We guess it may cause by browser or OS updates of client side. But it cannot solve by retaining the old version of browser or OS.
We guess it may Tomcat version or SpringBoot version is not compatible with current browser or OS.
※ no proxy server between client and server
It's a huge modification difference when upgrading to Tomcat 10 and/or SpringBoot 3.x above.
So we try to upgrade to the SpringBoot 2.7.x but it remains occurs when enable SSL (https).
We tried the status is stable http calls without ERR_TIMED_OUT when SSL (https) is not set in any version of SpringBoot/Tomcat.
Did anyone face the same problem?
Environment: Spring Boot 2.4.2 (Tomcat 9.0.43) and 2.7.8 (Tomcat 9.0.71) which is the latest version of Spring Boot 2.7.x) have same problem
Settings in properties file: (SSL setup section in properties file, and the SSL (https) is successfully on)
[It's also the only difference between stable status and ERR_TIMED_OUT status]
server.port=8081
server.ssl.enabled=true
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password={my_key_store_password}
server.ssl.key-store-type=PKCS12
server.ssl.key-alias={my_alias}
Before the logging DEBUG mode enabled, the SpringBoot console or log file do not have any log when ERR_TIMED_OUT occurs.
It means that the http call connection do not send to SpringBoot API service, the connection eaten by Tomcat.
After we setup the logging DEBUG mode enabled, we got the log when ERR_TIMED_OUT occurs as below:
2023-02-15 05:41:53,658 DEBUG [https-jsse-nio-8081-exec-2] Http11Processor : Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper#523bac8a:org.apache.tomcat.util.net.SecureNioChannel#3326d48e:java.nio.channels.SocketChannel[connected local=/{my_server_ip}::8081 remote=/{my_client_ip}:55823]], Status in: [CONNECT_FAIL], State out: [CLOSED]
2023-02-15 05:41:53,658 DEBUG [https-jsse-nio-8081-exec-2] LimitLatch : Counting down[https-jsse-nio-8081-exec-2] latch=1
2023-02-15 05:41:53,658 DEBUG [https-jsse-nio-8081-exec-2] NioEndpoint : Calling [org.apache.tomcat.util.net.NioEndpoint#3e576e09].closeSocket([org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper#523bac8a:org.apache.tomcat.util.net.SecureNioChannel#3326d48e:java.nio.channels.SocketChannel[connected local=/{my_server_ip}:8081 remote=/{my_client_ip}:55823]])
The weird part is this error situation is only happen when we add the ssl settings as I described above.
UPDATES:
I prepare a test-apis project to demo this problem, it only use the sample code from [spring.io] https://spring.io/guides/gs/rest-service/ without any other settings or dependencies to re-produce this problem.
All you need to do is generate a PKCS12 type of keystore.p12 file of some domain name put at /test-apis/src/main/resources folder to test it
The sample code is put on GitHub https://github.com/tinalin314159/test-apis
I think this is not simply the Tomcat problem and I cannot re-produce it without SpringBoot package with just only Tomcat.
The way I generate the PKCS12 type of keystore.p12 :
openssl pkcs12 -export -in fullchain.pem -inkey privatekey.pem -out keystore.p12 -name tomcat -CAfile chain.pem -caname root
I'd already rule out the problem is not related to SpringBoot any version with the help of offical GitHub team of SpringBoot.
I focus on the problem maybe is the PKCS12 type of keystore.p.12 file may cause the Tomcat thread failed problem (TIMEOUT) due to the Chrome or OS updates after 2023/01/01.
Suddenly, I found a phase on https://whatsmychaincert.com/ mention about
You do not need to include the root certificate in the certificate
chain that you serve, since clients already have the root certificate
in their trust stores. Including the root is inefficient since it
increases the size of the SSL handshake.
After the trial of remove root cert. during the generation of PKCS12 type of keystore.p12 file it works. The SpringBoot API do not have any timeout anymore.
I guess there may have changes on Chrome or OS during the SSL handshake after 2023/01/01. If there have overhead during SSL handshake. The thread of Tomcat will dead after the first time successful API calls. Because we do not change SpringBoot version, Tomcat version and cert. before 2023/01/01. The only changes is Chrome or OS updates.
Thank you very much from offical GitHub team of SpringBoot help to let me clarify the problem where is and solved.
I'm trying to run following SPARQL-query on my local graphDB-Instance (GraphDB Free 9.4.1 on Windows).
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT * WHERE {
SERVICE <https://query.wikidata.org/sparql> {
?subj wdt:P31 wd:Q744913 ;
wdt:P625 ?coord ;
rdfs:label ?label
FILTER (lang(?label) = "en")
}
}
The query works without a problem on my personal computer.
But within my companies network, it doesn't, because we have a proxy.
I checked my proxy settings with a RDF4J-Java programm and they work perfectly fine.
[...]
System.setProperty("https.proxyHost", "<company_proxy>");
System.setProperty("https.proxyPort", "<company_proxy_port>");
System.setProperty("https.nonProxyHost", "localhost|127.0.0.1|<company_list>");
System.setProperty("https.proxyUser", "<user>");
System.setProperty("https.proxyPassword", "<password>");
[...]
I tried to set the same settings for GraphDB with different approaches
via the UI
via the C:\Users\XXXX\AppData\Local\GraphDB Free\runtime\conf\net configuration-file
via the C:\Users\XXXX\AppData\Roaming\GraphDB\conf\proxy.properties configuration-file
via the C:\Users\XXXX\AppData\Local\GraphDB Free\app\ configuration-file
All do something to the configuration, meaning I now see an error message and don't have a connection timeout anymore. Since I validated the settings with RDF4J I am guessing the problem is how I apply the configuration or there is a problem with parsing the configuration.
Edit:
I get an statuscode 407, Proxy Authentication Required.
I'm guessing, that graphDB doesn't accept the properties https.proxyUser and https.proxyPassword.
Did anybody had the same issue and has a solution? Or how could I debug this problem further?
ps. my password contains the '!' character. might this be the problem? I tried every escape mechanism i could think of (!, ^!, ^^!, all in "") but neither did work.
Edit 2.0:
The guys from ontotext found a bug and it was fixed with the release 9.5.0-TR14.
The proxy-configuration mentioned in this questions works now.
To closest possible scenario to simulate the issue with your proxy server was:
Download and install mitmproxy server
Trust the mitmproxy's certificate for all Java programs so GraphDB can use HTTPS connections to the proxy
# ~/.mitmproxy/mitmproxy-ca-cert.cer is the certificate shipped with the proxy
sudo keytool -importcert -file ~/.mitmproxy/mitmproxy-ca-cert.cer -alias mitmproxy -keystore $JAVA_HOME/jre/lib/security/cacerts
Start the proxy server with username and password
# The proxy will require username and password
mitmproxy --set proxyauth=testUser:testPassword
Start GraphDB and point it to the local mitmproxy server:
# Point the Apache HTTP Client to use the mitmproxy
./graphdb -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8080 -Dhttps.proxyUser=testUser -Dhttps.proxyPassword=testPassword
At this point, I was able to reproduce the HTTP 407 error, where the HTTPS client of GraphDB fails to negotiate the authenticating process with the proxy server. The same process works fine for the HTTP protocol, so this is how I have reached a workaround, which overcomes this glitch by specifying both the https.proxyUser and its http.proxyUser equivalent. The example works fine with your query and the mitmproxy server:
# Setup not only HTTPS but also HTTP connection
/graphdb -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8080 -Dhttps.proxyUser=testUser -Dhttps.proxyPassword=testPassword -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8080 -Dhttp.proxyUser=testUser -Dhttp.proxyPassword=testPassword
What you can try doing is setting up the 'graphdb.workbench.external-url' parameter to whatever URL/subpath your instance should reside at. This parameter is used for rewriting incoming requests and can help with API calls.
I am using Git with Intellij in Windows 10 environment. For some reason my git credentials are messed up. When I try to fetch/clone, Intellij is not asking me the credentials to enter. It appears as if it is trying to use already stored git credentials. I am getting the following error when I try to fetch :
7:58:31.180: git -c core.quotepath=false fetch origin --progress
--prune
java.io.IOException: Authentication failed: at
org.jetbrains.git4idea.ssh.SSHMain.authenticate(SSHMain.java:298) at
org.jetbrains.git4idea.ssh.SSHMain.start(SSHMain.java:172) at
org.jetbrains.git4idea.ssh.SSHMain.main(SSHMain.java:137) Caused by:
java.io.IOException: Publickey authentication failed. at
com.trilead.ssh2.auth.AuthenticationManager.authenticatePublicKey(AuthenticationManager.java:262)
at
com.trilead.ssh2.Connection.authenticateWithPublicKey(Connection.java:443)
at org.jetbrains.git4idea.ssh.SSHMain.tryPublicKey(SSHMain.java:352)
at org.jetbrains.git4idea.ssh.SSHMain.authenticate(SSHMain.java:231)
... 2 more Caused by: java.io.IOException: Invalid PEM structure,
'-----BEGIN...' missing at
com.trilead.ssh2.crypto.PEMDecoder.parsePEM(PEMDecoder.java:138) at
com.trilead.ssh2.crypto.PEMDecoder.decode(PEMDecoder.java:313) at
com.trilead.ssh2.auth.AuthenticationManager.authenticatePublicKey(AuthenticationManager.java:171)
... 5 more fatal: Could not read from remote repository. Please make
sure you have the correct access rights and the repository exists.
So, I googled and found various approaches and tried all of them only to find none is working for me.
I tried in the following ways:
1)Removing the credentials stored in Windows Credentials Manager
2)Change remote repository credentials (authentication) on Intellij IDEA 14
3)Git credential helper - update password
and so on.. Any other thoughts to fix the issue so that the Intellij would ask me the credentials before I fetch/clone my repo?
TL;DR Update to the latest version (2018.3 or above), it uses Native SSH by default and if everything works in the terminal, it should work in the IDE.
A bit more detailed answer below:
Git credential helpers work for HTTP-base connections. Judging by the error, you are using SSH, so no credential helper is involved so any manipulations around it will not help.
The error message also belongs to the IntelliJ Built-in SSH client, and the reason is either wrong ssh-key in use or unsupported key format - and builtin client is known to not support new OpenSSH key format - see https://youtrack.jetbrains.com/issue/IDEA-151116
The solution to this is to configure IDE to use Native SSH, which is, in fact, telling git to use system default SSH client, or the one bundled with GitForWindows in case it is used. Native SSH is supposed to support the key format in use.
Prior to 2018.3, IntelliJ was not able to handle interactive prompts for passphrase or host verification, so ssh-agent had to be used. Stating from 2018.3, IntelliJ can handle those prompts and Native SSH is the default. So updating should solve the issue should it be the key format, or some specific .ssh config not supported by the builtin SSH client.
I was running into some other issues when I configured Native SSH, but downgrading git version to 2.17.0 from 2.20.1 has solved the problem
I use the Elastic Beanstalk CLI to deploy my Spring Boot application to EB.
It all works correctly as long as I don't configure HTTPS.
According to the userdocs all I should need to do is create a .config file in my .ebextensions folder with the following content
option_settings:
aws:elb:listener:443:
SSLCertificateId: <arn for cert>
ListenerProtocol: HTTPS
InstancePort: 5000
InstanceProtocol: HTTP
aws:elb:listener:80:
ListenerEnabled: false
However, if I create my environment with that configuration the health checks fail due to being unable to communicate with the ELB. Looking at the environment in the AWS console both the HTTP and HTTPS listener ports have been disabled and the SSL cert is not associated with the load balancer.
Given the change in behaviour I think it's safe to say that the .config file is being picked up and applied, even if the config is somehow incorrect.
If I manually try to enable the HTTPS listener through the EB web GUI at this stage I get the following error.
LoadBalancerHTTPSPort: You have specified both the #deprecated(:default.aws:elb:loadbalancer:LoadBalancerHTTPSPort) option as well as one in the new aws:elb:listener:443 namespace. The :default.aws:elb:loadbalancer:LoadBalancerHTTPSPort option will be ignored.
So I can't even enable it manually even if I wanted to.
There are a binch of questions/answers on here that talk about uploading custom nginx conf files. I believe those to now be out of date and not applicable, but if someone can point me to something that works given the current state of EB I'm happy to go with that.
Some information for reference below
I'm using ACM to host my (self-signed) cert. For my purposes self-signed certs are ok while I test this. I don't know if that's confusing the load balancer, though the docs do mention using self-signed certs. I'll be moving to a proper cert later.
My .elasticbeanstalk/config.yaml looks like this
branch-defaults:
default:
environment: <name>
deploy:
artifact: target/<jar name>.jar
global:
application_name: <App name>
branch: null
default_ec2_keyname: <key name>
default_platform: Java 8
default_region: eu-west-1
include_git_submodules: true
instance_profile: null
platform_name: null
platform_version: null
profile: eb-cli
repository: null
sc: null
workspace_type: Application
The commandline I run to create the environment is
eb create <name> -c <name> --elb-type classic
EB CLI version info
eb --version
EB CLI 3.10.5 (Python 2.7.1)
Two possible solutions:
1.)
Have you uploaded your server certificate to ACM? It's unclear if you created with ACM or a 3rd party which would need uploading to ACM.
http://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html
2.)
Check the order of precedence for configs in Elastic Beanstalk.
.ebextensions have low precedence, so those option values could be overridden by higher precedence option settings.
The solution would be to update your cert in the console GUI. Navigate to the GUI https://aws.amazon.com/
Go to your elastic beanstalk gui -> click your environment -> click configuration on the left side bar -> click the gear icon next to "load balancing".
Now you'll see a list of ELB option settings. Choose your cert from the dropdown menu: "SSL certificate ID" and save.
Ok, I am completely stumped here. I am running the Jenkins application (v1.635) for Mac OSX. I am trying to connect to Active Directory through the LDAP Security Realm. No matter what I try (and I have tried a good 30+ variants), the login fails and nothing gets written to the jenkins.log file.
I have ApacheDirectoryStudio installed and it connects flawlessly, so I know it is a Jenkins issue (and not a network or ACL issue).
The LDAP server is using a self-signed SSL certificate, which I installed into the relevant cacerts file.
Here's my LDAP configuration (minus the sensitive corporate stuff)
Server: ldaps://subdomain.domain.com:636
root DN: DC=domain,DC=com
User search base: OU=Users and Computers
User search filter: sAMAccountName={0}
Group search base: OU=Jenkins Groups,OU=Groups
Group search filter: (&(objectclass=group)(cn={0}))
Group membership: Parse user attribute for list of groups
Group membership attribute: memberOf
Manager DN: CN=jenkins,OU=Users and Computers,DC=domain,DC=com
Manager Password: password
Display Name LDAP attribute: displayname
Email Address LDAP attribute: mail
Disable Ldap Email Resolver: unchecked
Any help is greatly appreciated. Even getting the log file to spit out some info would be great.
Thanks!
Edit #1: Sometimes an exception does show up in the log file. Hopefully this helps.
Nov 09, 2015 12:00:49 PM hudson.security.LDAPSecurityRealm$LDAPUserDetailsService loadUserByUsername
WARNING: Failed to search LDAP for username=myuser
org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to LDAP server; nested exception is javax.naming.CommunicationException: subdomain.domain.com:636 [Root exception is java.net.SocketTimeoutException: Connect timed out]
Edit #2: I have to go to an 1 1/2 hour meeting, so my responses will be delayed. Sorry.
So it's not ideal, but I was able to get the connection to work with the plain ldap connection (not ldaps). All I can figure is that Apache Directory Studio is smarter than Jenkins when it comes to establishing the connection. I suspect there may be an issue with the self-signed SSL certificate chain that Jenkins can't quite figure out. I really wish there was more verbosity to the logs in this matter. But for now, I have it working and since it is behind the corporate firewalls, the non-secure connection is less of a risk. I still intend to figure out the root cause, but for now, this will have to do. Thanks for your suggestions.