At one time we faced a perhaps similar dilemma:  hardware with 
proprietary software/firmware that would not support then current 
security/encryption methods/protocols.  The hardware could not be 
replaced for two reasons:  it was integrated into specific systems that 
were in use; the vendor did not support the old hardware and we had 
insufficient external funding to replace all of the systems that would 
need to be replaced for compatibility with the vendor then current 
products.  The solution we used was to put a physical dedicated buffer 
computer (not virtual, no hypervisor) between all network accesses to 
the affected hardware system and the buffer machine was only on an 
internal network, as would be the affected hardware, all behind the 
"hardening" of our Internet connected networks (that included a 
honey-pot sacrificial "trap").  The buffer machine did a bi-directional 
translation from current methods to what was required by the affected 
hardware.  In addition, there was a terminal console machine that could 
be attached directly to the affected hardware platform and environment 
allowing us to fully manually configure -- in so far as the proprietary 
environment allowed -- as an "emergency" measure (that we rarely had to 
use).  There was some increase in latency, but as the affected hardware 
was not a real time system but merely a "low" latency and "high" 
throughput system, the increased latency and lowered throughput did not 
impact the usages of the affected hardware, and was fully transparent to 
the end users of the entire system.

On 11/5/21 08:14, Konstantin Olchanski wrote:
>>>>
>>>>> Once I had a clue I was able to install the vsftpd rpm
>>>>
>>>> Running an unmaintained, out-of-date, password based service like FTP ...
>>>
>>> I would presume the OP has a clue ...
>>
>> Why would you presume this? ...
>>
> 
> bah, hambug! He uses Linux, he has a clue.
> 
> Most likely FTP is needed to support some piece of old hardware that cannot be trivially
> replaced or upgraded.
> 
> With our MIDAS data acquisition software we have an important user with a standing requirement
> to support writing data to an FTP server (comlpete with clear-text password, etc),
> because that is the interface to their main sata store system. (*you* go and tell them
> "just write all your data to a usb drive!").
> 
> If ftp is needed, then it is needed, period.
> 
> I just recently had to junk a very nice multiport 1gige switch, just because
> the management interface is an https web page, *but* supports only SSLv3 (predates TLS)
> and only obsolete cyphers (RC4 & co). Modern web browser absolutely refuses to connect,
> even though it is on a very secure private network (direct wire connection!).
> 
> Very old web browser (SL6 firefox?) did manage to connect (after spewing nonsense
> about expired https certificates) but then my javascript was too old and the login
> page did not work.
> 
> So sometimes you have to "turn back the clock" and use "obsolete" and "insecure"
> and even "it's so dangerous now!" software and connectivity.
>