[jolmg]

> Access is the biggest issue, as the OS only supports telnet, and serial access.

OpenSSH works on it. This page has links to precompiled packages:

https://scosales.com/knowledge-base/how-to-install-ssh-for-s...

links:

ftp://ftp2.sco.com/pub/skunkware/osr5/vols/openssh-3.4p1-VOLS.tar

ftp://ftp2.sco.com/pub/skunkware/osr5/vols/prngd-0.9.23-VOLS.tar

ftp://ftp2.sco.com/pub/skunkware/osr5/vols/zlib-1.1.4-VOLS.tar

Probably better to grab the sources and compile them yourself if you can, though.

> Migrating to Linux might be an option, but is most likely going to be hugely painful.

Probably. At least it sounds like you only have a few users for it, so getting them to adapt to a change of software might be easier.

[silverwasthere]

Maintaining access to a 20 year old ssh server will not be trivial. A modern client would usually fail to agree on encryption protocols in my experience.

[jolmg]

It's pretty trivial. Some things are disabled by default, but still available on the latest versions of clients. For the OpenSSH client, it will tell you what specifically the client and server failed to agree on, and you can just add the option to enable on the client one of the ciphers, kex algos, or whatever that the server accepts. I've had no trouble with neither the latest version of the OpenSSH client nor Putty to connect to such servers.

[thwarted]

Using ancient ciphers and kex algos can end up being just as secure as telnet.

[jolmg]

I mean, if they can compile the latest version of sshd to run on SCO OSr5, that's great! If they can't because it's no longer compatible or whatever, are you saying they may as well stay with telnet? Obviously, not using legacy software is best, but it's not like people can just snap their fingers. Software needs to be ported, people need to be trained, etc. Work and time is needed. In the meantime, using sshd seems like an easy upgrade.

On "ancient", the ciphers and kex algos used by the OSr5 sshd above were deprecated like 4 years ago. I'd like to think that among the select group of probably-not-technical people that have access, it's not exactly the same bar of technical ability to inspect the contents of a plaintext connection as that to inspect the contents of an encrypted connection that uses ciphers and kex algos deprecated a few years ago.

[nibbleshifter]

> A modern client would usually fail to agree on encryption protocols in my experience.

I run into this issue frequently. Usually its a "client soft disabled, alter config", but sometimes... Just sometimes its "spin up an old VM to use its ssh client".

[sitkack]

You SSH to sibling VM running under the same VMM, connect the serial port of the SSHVM to the application VM, clear text only runs over that virtual serial connection traveling through the VMM.

[kkielhofner]

Considering the other options you can add the deprecated ciphers and key exchange mechanisms with a few lines for the host in your SSH client config on the newer system.