Intermittent Authentication failed or partial success error - chilkat

I am getting an intermittent Authentication failed or partial success. (1) error.
ChilkatLog:
AuthenticatePw:
DllDate: May 25 2017
ChilkatVersion: 9.5.0.68
UnlockPrefix: XXXXXXXXX
Architecture: Little Endian; 64-bit
Language: .NET 4.5 / x64
VerboseLogging: 0
login: XXXXXXX
sshAuthenticatePw:
requestUserAuthService:
sendServiceRequest:
svcName: ssh-userauth
SentServiceReq: ssh-userauth
--sendServiceRequest
ssh-userauth service accepted.
--requestUserAuthService
AuthMethods: password
passwordAuth:
Sent login/password
Authentication failed or partial success. (1)
PartialSuccess1: 0
AuthList: password
important:
This is likely a simple invalid login and/or password error,
meaning your application did not send the correct login and/or password.
--important
--passwordAuth
--sshAuthenticatePw
Failed.
--AuthenticatePw
--ChilkatLog
What does the (1) in Authentication failed or partial success. (1) mean? Is it the AuthFailReason mentioned here

The LastErrorText is designed to provide information for quick resolution of problems. It contains the information that would likely be needed by the developer to understand the cause of a problem. In our opinion, it is much better than an obscure single-line message or an error code.
It also provides information for Chilkat -- so that if you send us the LastErrorText, we can see context and usually understand the cause of the problem and the solution in one step. Some lines in the LastErrorText might be obscure to the application developer. That's OK, because they are lines meant for us.
In this case the "Authentication failed or partial success. (1)" line is telling Chilkat the execution path that was taken in the internal code. We don't have to guess.
The SSH authentication protocol is such that it's possible for the server to respond with an SSH2_MSG_USERAUTH_FAILURE response, but indicate partial success. In this case, the partial success was 0 (false), so it points to a hard failure -- most likely the simple case that the username and/or password was incorrect.
There is one more possibility, which is somewhat rare. If the server also accepts keyboard-interactive, then you can set Ssh.UncommonOptions = "KeyboardInteractiveFollowup" (or SFtp.UncommonOptions = "KeyboardInteractiveFollowup") to cause Chilkat to retry with a keyboard-interactive request.

Related

TLS errors using Chilkat library to access Microsoft Graph APIs

I've been trying to use Chilkat library to play around and learn about using Microsoft Graph APIs but it seems I keeps getting TLS errors (connectFailReason 109) with even the simplest GETs and POSTs. This is what a typical log looks like:
ChilkatLog:
QuickGetSb:
DllDate: May 29 2021
ChilkatVersion: 9.5.0.87
UnlockPrefix: XXXXXXXXXXXXXXXX
Architecture: Little Endian; 32-bit
Language: C++ Builder / clang / 32-bit
VerboseLogging: 0
Component successfully unlocked using purchased unlock code.
url: https://graph.microsoft.com/v1.0/users
httpRequestStr:
a_quickReq:
quickHttpRequest:
httpVerb: GET
url: https://graph.microsoft.com/v1.0/users
openHttpConnection:
Opening connection directly to HTTP server.
httpHostname: graph.microsoft.com
httpPort: 443
tls: True
socket2Connect:
connect2:
connectImplicitSsl:
clientHandshake:
clientHandshake2:
ProcessHelloRetryRequest:
readHandshakeMessages:
WindowsError: An existing connection was forcibly closed by the remote host.
WindowsErrorCode: 0x2746
maxToReceive: 5
Failed to receive data on the TCP socket
Failed to read beginning of SSL/TLS record.
b: 0
dbSize: 0
nReadNBytes: 0
idleTimeoutMs: 60000
--readHandshakeMessages
--ProcessHelloRetryRequest
--clientHandshake2
--clientHandshake
Client handshake failed. (3)
--connectImplicitSsl
connectFailReason: 109
ConnectFailReason: 109
--connect2
--socket2Connect
connect: Socket fatal error.
--openHttpConnection
--quickHttpRequest
--a_quickReq
--httpRequestStr
Failed.
--QuickGetSb
--ChilkatLog
The library is not the very latest version but it isn't TOO old (about a year and a half - version 9.5.0.86). I didn't want to upgrade just yet because I have some "live" projects using this dev box (and this is just a "learning journey") so I was wondering if anyone can tell me whether the library version is the most likely issue or whether, perhaps, I'm missing some simple settings in the CkHttp object - the only thing I really do with it is set the auth token (which seems to have been retrieved correctly judging from the logs I output.
The actual API calls are pretty straightforward - mostly simple (slightly modified) examples from Chilkat website. But even the simplest http.quickGetStr("https://graph.microsoft.com/v1.0/me"); fails with a log similar to the above.
So, if anyone can suggest any properties to set to ckHttp to solve this issue (or confirm that library needs to be upgraded to access graph.microsoft.com - if, indeed, that is the case) - I would greatly appreaciate it.
Marko
This problem is already fixed. Contact support#chilkatsoft.com to get a pre-release build for v9.5.0.92.

Twisted ssh - session execCommand implementation

Good day. I apologize for asking for obvious things because I'm writing in PHP and I know Python at the level "I started learning this yesterday". I've already spent a few days on this - but to no avail.
I downloaded twisted example of the SSH server for version 20.3 from here https://docs.twistedmatrix.com/en/twisted-20.3.0/conch/examples/. Line 162 has an execCommand method that I need to implement to make it work. Then I noticed a comment in this method "We don't support command execution sessions". Therefore, the question: Is this comment apply only to the example, or twisted library entirely. Ie, is it possible to implement this method to make the example server will work as I need?
More information. I don't think that this info is required to answer my questions above.
Why do I need it? I'm trying to compile an environment for writing functional (!) tests (there would be no such problems with the unit tests, I guess). Our API uses the SSH client (phpseclib / SSH2) by 30%+ of endpoints. Whatever I do, I had only 3 options of the results depending on how did I implement this method: (result: success, response: "" - empty; result: success, response: "1"; result: failed, response: "Unable to fulfill channel request at… SSH2.php:3853"). Those were for an SSH2 Client. If the error occurs (3rd case), the server shows logs in the terminal:
[SSHServerTransport, 0,127.0.0.1] Got remote error, code 11 reason: ""
[SSHServerTransport, 0,127.0.0.1] connection lost
I just found this works:
def execCommand(self, protocol, cmd):
protocol.write('Some text to return')
protocol.session.conn.sendEOF(protocol.session)
If I don't send EOF the client throws a timeout error.

Play Framework 2.3 WS SSL Disable AlgorithmChecker

I'm currently trying to use WS in Play 2.3 to interact with the Visa Direct Payments API but I am struggling as the sandbox key provided is RSA has a key size of 1024 and, from what I've read in the source code comments, is considered not safe so is disabled.
As this is just sandbox I would like to know if there is a way to disable this extra key checking, I have already tried ws.acceptAnyCertificate=true without any luck.
The errors I am recieving in the console are as follows:
[warn] p.a.l.w.s.ConfigSSLContextBuilder - validateKeyStore: Skipping certificate with weak key size in visasandboxcert: Certificate failed: cert = "CN=841edac8-d8cd-4593-b575-fdf3bbee5e67,OU=VMT,O=Visa,L=Foster City,ST=CA,C=US" failed on constraint RSA keySize < 2048, algorithm = RSA, keySize = 1024
[error] play - Cannot invoke the action, eventually got an error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Can anyone give me any advice how I can get round this? Preferably without changing the Play source code and building from that.
First, you need to talk to Visa Direct Payments and file a bug report letting them know that a 1024 bit key is utterly unacceptable in this day and age.
Second, you need to set:
ws.ssl.disabledKeyAlgorithms="RSA keySize < 1024"
which will tell the Algorithms checker to ease up. See Certificate Validation for more details.
if you are using play 2.6.x, you can do it this way
play.ws {
ssl {
debug.handshake = true
disabledKeyAlgorithms =["RSA keySize < 1024"]
}
}

Some questions about protobuf

We are building a RTB(real time bidding) platform. Using nginx as http server, the bidder is writen in lua, google protocol buffer for serializing data and Zlog for logs. After test runs, we got three error messages in the nginx error log:
"[libprotobuf Error, google/protobuf/wire_format.cc:1053]
String field contains invalid UTF-8 data when parsing a protocol buffer.
Use the 'bytes' type if you intend to send raw bytes."
So we went back to check the source code of protocol buffer, and found that this check is controlled by a macro(-DNDEBUG: it means NOT debug mode?, according to the comment). And -DNDEBUG disables GOOGLE_PROTOBUF_UTF8_VALIDATION(i think?). So, we enabled this macro(-DNDEBUG) in the configuration. However, after testing, we still got the same error message. And then, we changed all the "String" type to "Bytes" typr in XXX.proto. After testing, the same error message showed.
worker process 53574 exited on signal 11(core dumped),then process died.
lua entry thread aborted: runtime error:/home/bilin/rtb/src/lua/shared/log.lua:34: 'short' is not callable"
Hope somebody can help us solving those problems.
Thank you.

Jetty HttpParser Full

I'm getting these warnings in my log file:
WARN 2013-01-15 00:08:15,550 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#2d0a7424{l(/10.13.61.19:17602)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#22e7a7e3,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2355,c=-3},r=41}
WARN 2013-01-15 00:08:17,275 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#3e428386{l(/10.13.61.19:17605)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#40a77d2a,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-5,l=108,c=-3},r=57}
WARN 2013-01-15 00:09:34,560 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#39c117ad{l(/10.13.61.19:17708)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#11c95f6f,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=1940,c=-3},r=522}
WARN 2013-01-15 00:09:37,185 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#574e9325{l(/10.13.61.19:17722)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#6e997c49,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2675,c=-3},r=101}
WARN 2013-01-15 00:09:37,281 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#6838d5cb{l(/10.13.61.19:17726)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#d9f6b12,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2641,c=-3},r=4}
WARN 2013-01-15 00:10:22,723 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#6f282964{l(/10.13.61.19:17805)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#44627fa1,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2211,c=-3},r=61}
Does anyone know what they mean or how to fix them? I'm using jetty-8.1.5.v20120716 . As you can see, they happen very frequently.
Translation: The request entity is too large.
Some client is issuing an excessively sized request URI + request headers.
This will result in a HTTP Response Code 413 Request Entity Too Large to that client.
Got something similar from maven-jetty-plugin; solved by clearing all cookies for the host.
I met the same question in solr-Query,and the reason is "the request is too long".So I add a set which name "requestHeaderSize" in jetty.xml then the problem is fixed . The size is depended on your demand. Hope this can help you~
I found the root cause of a log message like this (HttpParser Full) to be related to using Kerberos auth.
Kerberos adds header data for each Active Directory group.
See this Microsoft support article for more info.