calc2014

To request the fix / "Buddy Drop" please contact support and reference this link. When you do, please make support aware that this is a major problem needing a permanent fix, not a stop-gap/temporary fix, otherwise in future versions this fix will NOT be included. @"jeffpahf", @"damir.a", @"VISIX", @"mgebauer", @"jmihos"

Yes, just tried the Buddy Drop and it does fix the issue. Also, had another differernt user not able to connect prior to the fix and they were using Sun_SSH_2.4 client, just connecting from their Sun server natively with the sftp command line. The Buddy Drop fixed it for them too. This is a much bigger issue than…

Solarwinds have released a further KB article on this: SFTP connection not established for legacy Java clients This mentions that they are working on a "Buddy Drop" for 15.3.2 to allow the old clients to work so you will need to request this from Support. However, this is for the "transition period" for people to "upgrade…

0.1.54 is the final version of JSch, later versions are a non-official fork of the project. This is why so many pieces of business software have 0.1.54 bundled inside, in a lot of cases it cannot even be replaced so the software will just break. From the server end, you cannot tell users to change their software after it…

@"jeffpahf" is that in reference to the issue below? https://thwack.solarwinds.com/product-forums/serv-u-ftp-mft/f/forum/97585/jsch-and-other-software-can-t-connect-to-serv-u-15-3-2

The article claims you can roll back the version with your existing configuration as long as the Server Identity is removed from the Serv-U.archive file, but I am a little skeptical of this because some values in the config will already be encrypted with the identity. Take a backup! Let us know if that works, as least it…

@"jeffpahf", @"damir.a", @"VISIX" Please post any observations and frustrations on the new specific thread so that Solarwinds can see the impact. Thanks, hopefully we get a solution soon.

I have now posted about the cause of this issue with JSch and other clients in a separate specific thead.. JSch (and other software) can't connect to Serv-U 15.3.2 https://thwack.solarwinds.com/product-forums/serv-u-ftp-mft/f/forum/97585/jsch-and-other-software-can-t-connect-to-serv-u-15-3-2

Good point, do you want me to make a new thread specific to the issue with JSch or would you like to do this and then we can all put comments on the implications and problems with 15.3.2 and this issue?

@"jeffpahf"Now that we understand this issue maybe the title of the thread could be changed to "JSch client connection failure since Serv-U 15.3.2" or similar, as I imagine many others are having this issue and could contribute? Only a suggestion

You could trying to roll back the contents of the relevant Serv-U folders Program Files and ProgramData.

The main config files for Serv-U are in ProgramData. Theres a consideration though with this new version as I'm not sure the new config files will work with the old version due to the new "Server Identity" feature. If anyone has successfully rolled back please let us know. However, rolling back is not a long term solution…

Yes, I have the same problem, lots of my users cant connect in 15.3.2 because JSch is integrated into another application because it is a library and that part cannot be edited. It's the same in lots of commercial and automation applications. We really need Solarwinds to provide an option to toggle this setting on / off…

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?

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?

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?

The server identity is a new feature and not related. I was referring to this line in the release notes.. 01085165Empty Definition of a domain SSH Private Key blocks using the Server-wise defined Key. I've not experienced this in the past but maybe it has specific circumstances. Once your end users have accepted the RSA…

If your users have accepted the new fingerprint it will probably be best to just leave it on an RSA fingerprint now. If you need to go back to DSA or understand what happened, you'll need a copy of the old configuration from ProgramData so that you can see what fingerprint file it was pointing to before the upgrade. The…

Yes, if you need to use the old key fingerprint, maybe you can re-select it in the Management Console at the domain level and then it will retain the same fingerprint. It is located in Domain > Limits & Settings > Encryption. Worth a try? For what it's worth, I have just replicated this process by creating and applying a…

Thanks for the info @"jeffpahf" - is the DSA key set at the server or domain level? If you select the old DSA key again, does it work?

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…

Hi David, good idea, please can you submit this as a request to support in your portal?

If it isnt showing in the logs, there is probably something else listening on port 21, or you may be looking at the server log rather than the domain log

15.3 has TLS 1.2 and 1.3 support, would suggest upgrading to that I believe 1.2 has been supported for a few versions but I cannot be sure, best to check the Server > Settings > Enryption tab.

Sounds like another domain was already listening on the same IP address and port. You can use WinSCP command line to transfer files without a GUO in scripts, details here: https://winscp.net/eng/docs/scripting I'm not sure what code you have so I cant really advise on that, but serv-u supports FTP(S) and SFTP for file…

Please can you explain why you dont want the server to be accessible at all via its IP with an invalid cert warning? This would be the same with a web server if you accessed it by it's IP rather than it's hostname as the address does not match the certificate (you would get the same going to Google via…

If you look at the Domain Activity log when you try the above, does it give any other info? It may be that the user doesnt have permission assigned in Serv-U to access their home folder.

Serv-U Managent > Domain Details > IP Access > Add a rule for your IP, all other IPswill be rejected

@"danger_noodle" I havent heard of this, I would recommend raising a ticket with support and please let us know if it gets resolved as others may have the issue.

Hi @"ultrapep", I dont believe you can restrict on FQDN but you can add an IP Access rule either in the Global or Domain Details sections. Note that this will restrict all protocol, not just the web panel to that IP. Alternativly, just add a firewall rule on the server OS/firewall to only allow 443 from a specific IP or…