Seagull License Server Crack Serial Keyl
Zee Petty
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.
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
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?
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...
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 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 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...?
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.