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

How To Re-Set the 0 Minutes forever denied setting?

Literally within minutes after updating the server on 12/23 for one account/client are getting denied; below find both Client logs and mFTP server logs

Client log 21:30 my time 00:30 client time

12/24/2022 00:30:19 1 0 O Global *** Scripting Step Begin: [FTP_Connect_Success]
12/24/2022 00:30:19 16 0 O Global Successfully connected to FTP site mysecure.org///toHSA
12/24/2022 00:30:19 1 0 O Global *** Scripting Step End: [FTP_Connect_Success] completed.

Client log 1 hour later after the update

12/24/2022 01:30:09 4 19 O Global Error during connect: The FTP Queue Component was unable to connect to FTP Server at 'mysecure.org///toHSA.' java.net.ConnectException: A remote host refused an attempted connect operation. (Connection refused). Please verify that the server, username, password and port number are correct.
12/24/2022 01:30:09 1 19 O Global *** Queue Step End: [SFTP_Connect] failed.


The site Setting(s) are 4 times in 8 seconds, 0 Minutes blocked (forever)

Global Dashboard note: <octets removed> by me
[02] Tue 03Jan23 08:30:07 - Connection denied from IP address 63.<octets removed> (local address 192.<octets removed>, port 22)

At about 08:40, Changed 0 minutes to 1 Minutes and checking the log...
[02] Tue 03Jan23 09:30:07 - Connection denied from IP address 63.<octets removed> (local address 192.<octets removed>, port 22)


Thanks,
JeffP...


  • Please check the site tab, "IP Access" the client's IP, if there as Deny, then depending on your rules, to explicitly allow select IPs then you can Allow if you have this rule to list each IP for all clients, Or if not, then delete the IP on this tab.

    So, I found the IP, and deleted and waited for next client automation cycle... and no more Denied

  • 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

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

  • Well, the working aspect of a key based on ssh dsa is not the problem, that's a choice, the problem as I see it is that it will likely be "removed" was the word used by the SW Tech, which I equate to deleted, meaning likely a new key added as I think you're asking will create the same basic problem, but add the aspect that dsa is depreciated; And to be clear the basic problem is that clients will be prompted to accept the new/different key/fingerprint as safe/trusted - this is problematic for Me as 99.9% of my clients are automated and depending on the software will either automagically accept & store the new fingerprint/key = good, or silently error/refuse to continue = bad. 

    And we can create a new key, which is recommended RSA 2048,that at the client side shouldn't be a problem as the type of key, well except for the auto accept/trust/store or not...

    BUT the SW Tech said to make a "snapshot" of the server (VM in my case) before adding the RSA key/fingerprint, which brings up a few issues; a) likely 1+ day to work w/my vendor to get a snapshot, b) how the flock-of-seagulls would a server "snapshot" be restored, consider that 98% of my clients are not having a problem, logs, any files retained on the server etc in the week+ of days that may transpire between adding and determining to roll-back? c) why make one? I mean, what eggactly is the risk to which components/aspects of the server is adding an RSA key impact?

    Well, I made an RSA Key for the other site, that has only a few users/clients and would also be a small list of three IT folks at my end to work with those clients to sort out any issues; vs the many IT & Business folks on the primary first site.

  • 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 DSA key before upgrading to 15.3.2, upgraded and it was still there and the fingerprint remains the same.

    Was your DSA key set at the server level in the Management Console or on a specific Domain?

    On the other point, yes, as you said, the snapshot will only be useful if it doesnt include the data drive. If you needed to revert you could try keeping a copy of the "Program Files" and "ProgramData" folders related to Serv-U. Theres no garuntee this would be "complete" but it is better than nothing for reverting or having something to restore from if you needed to speak to support. Might be worth raising a ticket with support about the official reverting process for 15.3.2 as others may want to know that here for testing?

  • Re-selecting is sketchy, I'm not sure how I would know if it was there and which; the SW Tech had me browse to one of the Rhinosoft folders and I think they said, "Yes, it's not here" clarifying "removed" as deleted from this location; however IF I was years ago the creator of this I would not have placed in that folder, so very un-definitive... And my concern about applying is because of the "snapshot" warning, the depreciated comment, and my not knowing if the dsa key I see is the prior key or just a new random key... so not worth a "try" vs risk/warnings... Disappointed

    Fingerprint Key "may" have been at the site level, but there's also a legacy key created in 2017 which I can assume if the server encryption tab dialog is showing the fingerprint/key, then it's ssh-dsa at server level, and is both shown in the UI and in its original folder, not in the Rhinosoft folder as the SW Tech expected. But, Now this brings up the question when Clients connect, is the domain key shared vs the server key? Because as noted prior, a new RSA key was added to the other domain/site and did not solve the connection for one client.

    Yes, reverting bothers me at every level.. and I followed all the steps in the SW how to Update, which didn't include the entire program folders or a server snapshot... And like many SW customers, I have a day-job programming and related, this is a side hustle inherited because another IT c 2014 was doing a poor job, and that many of my teams processing goes through the mFTP... but bandwidth to manage this was one reason SW was chosen, so I/we wouldn't have to do such intensive tasks...

  • 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 domain key is used first, if there isn't one defined at the domain level, the server-level key is used (see 15.3.2 release notes for a fix to this, but personally I've never had the issue).

  • The RSA key was only added to one site/domain where there are only a few user/clients and few of our IT to interface with.

    And, now re-reading your comments, and my observing that the legacy server level 2017 dsa key was still present and your ++thanks to test, that it's not removed (me wanting to shout loud enough for SW Techs to hear you & I on this, so as to no longer say to anyone that it will be removed = deleted...)

    So, one of our vendors was kind enough to Test the RSA key on the lesser site/domain; and they prior confirmed my concern that at least some clients will have to manually login to accept/Trust & save the RSA (new) key/fingerprint...

    So, To add the RSA key requires a change mgmt process and email blast to the partner/vendor/clients as well as an internal email so that our IT knows that any issues are likely solved by accepting the new RSA key and not another more complex problem to try to "fix" by re-installing software or changing passwords

    re: domain key - I'm not connecting/finding your saying there is fix in the release notes, are you referring to this...? 

    • Server Identity introduced to enhance security

      Serv-U 15.3.2 introduces the concept of Server Identity. This attribute enable increased security by assigning each MFT server a unique server identity comprising the Server UID with a secret key. This Server Identity is used to provide enhanced encryption of third party passwords, and can be shared among multiple instances of the same server (for example, in the case of load balancing where a master Serv-U instance with the same server definition is replicated across multiple hosts). See Creating, exporting, and importing the Server Identity in the Installation and Upgrade Guide for information.

  • The server identity is a new feature and not related. I was referring to this line in the release notes..

    01085165 Empty 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 key you should be fine ongoing and it may best to swap to this long term anyway.