Automated Failed Account/Client Login 0 Minutes Setting - How To Reset?

Is it possible that the application could not get to the Serv-U server during the update and then flooded the server with connections that previously failed (causing the IP to be blocked)? If so the suggestion of going into Domain Details > IP Access and deleting the the specific entry for "deny" for your client IP address it should allow the application to connect again.

If you think this is a new issue with the latest update, please let us know the specific scenario so we can replicate it too.

Does your application only connect every hour or does it connect every 1 minute and then got blocked after 1 hour?

The update was minutes and occurred at on a Friday at 22ish hour +8 so very unlikely... Plus there are a few issues...

- any ssh dsa keys are automagically removed during the update
- NETWORK SERVICE account with full rights, should be added to program and hosted folders

So, far only noted impacted sites use JSCH and it's suggested that not having any key causes the Java clients to not continue their connection hand-shaking; and the solution is to add an RSA 2048 key, however this means other clients will need to automatically accept the key (preferred setting) or will have an error or warning or pop-up to accept & store; and making it worse for many clients for the 2 seems risky in light of not getting absolute cause->effect from SW

first off, I hope you're in Monday TZ, it's 11:37 pm Sunday for me, programming to get back on track after spending time on SU last week... 

Yeah, the RSA key is a change management process, email blast to our known user email; getting to business folks at our partners is easy getting to the correct tech to notify them to trust/accept & store the new RSA key not as easy....

I want to look at this from a different angle. Please can you let me know what version of JSCH you have experienced this issue with?

So, we've strolled off topic, but no worries from me...

At the client side there are two log files, this one that suggests checking user name & password, but the login never actually occurs
1) ...java.net.ConnectException: A remote host refused an attempted connect operation.
2) ...Session.connect: java.io.IOException: End of IO Stream Read. 

This second error message mends with SW Techs saying it's RFC rfc4253#section-4.2 not sending CRLF (non-windows systems send LF as they're often self-trimming and don't need the CR)

From the server side, is "connected" then "time out" & disconnect, as if the client & server are each waiting for the other to respond correctly.

Clients, these are two long time clients setup in SU c.2017, so pointing a finger at the RFC seems like SW should have warned that Java clients are going to have an issue(s).
SSH_FXP_INIT: client version 3 (JSCH-0.1.53)
SSH_FXP_INIT: client version 3 (JSCH-0.1.54)

The first response 1-week after applying the SR was to Roll-back but 20+other clients are not having a problem, well except for the pending task to trust/accept the new RSA key/fingerprint. But rolling back is not really a viable option after a week+ of days...

No worries either, happy to talk through the process.

Are the JSCH users able to connect now that you have an RSA host key on your domain/server, or are they still having the same problem?

We ran a few tests with the JSCH-0.1.53 as that client is also our/a vendor by switching to the domain with the RSA, and same result; which adds more weight to saying it's the client side.

The user was setup in the alternate domain (only a few user/clients connect here) and added a 2023 & Test RSA key/fingerprints and tested both as well as setup of same info in WinSCP which connected w/out issue using the same credentials. The 2023 RSA was also tested at the alt site/domain by one of our vendor clients not using JSCH and had no issues, connecting, download, upload and renaming a file.

You are correct, I've done a test app using the JSCH library 0.1.54 and it can no longer connect to Serv-U after being upgraded to 15.3.2. Having either RSA or DSA does not resolve the issue.

Please can you raise this with Solarwinds support and update the thread?

There's ticket from Jan 2... SW tech road map, 1. blame client, 2. roll-back, 3. blame client, 4. cite RFC, 5. We'll check & get back to you...

Do you have any way to check if the suspected CR missing the CRLF is the cause?
 RFC rfc4253#section-4.2 

And, that doesn't let SW off the hook, if this is the cause, Fair, but they should have included this a warning w/SR Docs

I can confirm the same, I have a client with jsch-0.1.53 which no longer works. Also an old client with OpenSSH 4.3 no longer works. Everything else works fine. Tried all options relating to host keys, but agree at this point it does not appear to be key related. 

I can confirm the same, I have a client with jsch-0.1.53 which no longer works. Also an old client with OpenSSH 4.3 no longer works. Everything else works fine. Tried all options relating to host keys, but agree at this point it does not appear to be key related. 

hope this helps... 
thwack.solarwinds.com/.../307082

Hello Jeffpahf, 

Thank you for your post and all the troubleshooting you have done so far. And I as well can confirm to be having same issue with about 20 or so integrations running into same issues you have explain in your forum thread. 

I hope we can see a hotfix applied as soon as possible.