VOGONS


First post, by fragmentfi

User metadata
Rank Newbie
Rank
Newbie

The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work anymore. I've patched the program to be up to date (as of 2021).

The old programs can be still used if the ssh server configuration is changed to allow using less secure connection methods. The patched ones have been tested with the latest Ubuntu (20.04.2 LTS) release and needs to changes to ssh server configuration.

Old protocols and ciphers have been replaced as follows:
diffie-hellman-group1-sha1 -> diffie-hellman-group14-sha256
aes128-cbc -> aes128-ctr
hmac-sha1 -> hmac-sha2-256

I have only tested ssh and scp clients with password authentication. Key based authentication is most likely broken and needs some more work. Other changes to the program are minimal, the goal was just to get it working again with minimum effort.

I'm open for comments, bug reports and improvement ideas!

Source and binaries are available on GitHub:
https://github.com/AnttiTakala/SSH2DOS/

Reply 3 of 16, by mr.cat

User metadata
Rank Member
Rank
Member

Tervehdys Antti 😁

I'm not a DOS user but got curious: What are these DOS versions using as an entropy source?
There is no /dev/random for DOS is there? I know in some other systems there are separate entropy daemons used, and they need to be configured by the user.

Reply 4 of 16, by fragmentfi

User metadata
Rank Newbie
Rank
Newbie

Good question. The original implementation only uses rand() for randomness so it really isn't cryptographically secure at all. This could be addressed in the future but I wouldn't be surprised if the implementation has other potential security issues. On the other hand I would not use DOS based systems or programs for anything serious anyway 😁

Reply 5 of 16, by mr.cat

User metadata
Rank Member
Rank
Member

Thanks, that's pretty much what I suspected. You're right it's more of a convenience to provide connectivity to modern machines, not really for security.
Hopefully the potential users are aware of that.

Anyways, nice to see that even the humble ole DOS hasn't been left behind 😁

Reply 7 of 16, by fragmentfi

User metadata
Rank Newbie
Rank
Newbie

There is now a release package on GitHub for the initial release.

Something to note: the non-386 versions are slow. The process between starting the program and prompting for a password takes 11 seconds on my 266MHz Pentium II when connecting to a machine in the same network. For the 386 version it takes only about one second. As I currently only have Pentium class DOS machines, I'd be interested hearing some feedback and test results from slower machines.

Reply 8 of 16, by keenmaster486

User metadata
Rank l33t
Rank
l33t
fragmentfi wrote on 2021-04-15, 16:38:

There is now a release package on GitHub for the initial release.

Something to note: the non-386 versions are slow. The process between starting the program and prompting for a password takes 11 seconds on my 266MHz Pentium II when connecting to a machine in the same network. For the 386 version it takes only about one second. As I currently only have Pentium class DOS machines, I'd be interested hearing some feedback and test results from slower machines.

I can attempt this later today on my 286.

World's foremost 486 enjoyer.

Reply 9 of 16, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
fragmentfi wrote on 2021-04-15, 10:21:

Good question. The original implementation only uses rand() for randomness so it really isn't cryptographically secure at all. This could be addressed in the future but I wouldn't be surprised if the implementation has other potential security issues. On the other hand I would not use DOS based systems or programs for anything serious anyway 😁

Time for the return of the lava lamp entropy generator? 😁

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 11 of 16, by keenmaster486

User metadata
Rank l33t
Rank
l33t
fragmentfi wrote on 2021-04-15, 16:38:

There is now a release package on GitHub for the initial release.

Something to note: the non-386 versions are slow. The process between starting the program and prompting for a password takes 11 seconds on my 266MHz Pentium II when connecting to a machine in the same network. For the 386 version it takes only about one second. As I currently only have Pentium class DOS machines, I'd be interested hearing some feedback and test results from slower machines.

So I tried this, and after waiting several minutes, it never did give me the password prompt. Not sure if it ever would have if I had simply continued waiting. Either way it is just too slow to be usable.

World's foremost 486 enjoyer.

Reply 12 of 16, by fragmentfi

User metadata
Rank Newbie
Rank
Newbie

Thanks for testing. I haven't had any time to work on this recently but my plan is to add a faster (but way less secure) method as an option. Also I now have a 33MHz 486 setup to test with.

Reply 13 of 16, by HandOfFate

User metadata
Rank Member
Rank
Member

Thanks for updating the client fragmentfi!

I usually start a FTP server for incidental file transfers but using SSH will be much more convenient.

Stiletto wrote on 2021-04-19, 05:59:
fragmentfi wrote on 2021-04-15, 10:21:

Good question. The original implementation only uses rand() for randomness so it really isn't cryptographically secure at all. This could be addressed in the future but I wouldn't be surprised if the implementation has other potential security issues. On the other hand I would not use DOS based systems or programs for anything serious anyway 😁

Time for the return of the lava lamp entropy generator? 😁

Or input noise from poorly shielded microphone inputs 😜 (although I believe reading that fans and other repeating things nearby also make such noise somewhat predictable)

Am486 DX4 120MHz, no L2, 16MB, Tseng ET4000/W32 1MB VLB, ESS ES1869 /// 5x86 133MHz, 256kb L2, 64MB, S3 Virge/DX 4MB PCI, SB16 + Yucatan FX, PicoGUS /// Pentium III 1GHz, 512MB, Asus V7700 64MB AGP, SB Live!

Reply 14 of 16, by ajacocks

User metadata
Rank Member
Rank
Member

This is definitely useful for management of DOS-based systems in my house. It’s always handy to be able to easily reach back to my servers to grab information, easily.

- Alex

Reply 15 of 16, by radiance32

User metadata
Rank Member
Rank
Member
fragmentfi wrote on 2021-04-14, 18:40:
The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work […]
Show full quote

The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work anymore. I've patched the program to be up to date (as of 2021).

The old programs can be still used if the ssh server configuration is changed to allow using less secure connection methods. The patched ones have been tested with the latest Ubuntu (20.04.2 LTS) release and needs to changes to ssh server configuration.

Old protocols and ciphers have been replaced as follows:
diffie-hellman-group1-sha1 -> diffie-hellman-group14-sha256
aes128-cbc -> aes128-ctr
hmac-sha1 -> hmac-sha2-256

I have only tested ssh and scp clients with password authentication. Key based authentication is most likely broken and needs some more work. Other changes to the program are minimal, the goal was just to get it working again with minimum effort.

I'm open for comments, bug reports and improvement ideas!

Source and binaries are available on GitHub:
https://github.com/AnttiTakala/SSH2DOS/

Hey fragmentfi,

Since performance will be crucial for your SSH implementation on DOS systems with slow 8086/186/286 CPUs, here's something you can try to speed things up:
I've come across a very nice, extremely simple implementation of the XOR shift register (Xoshiro) type of random number generators that produces random numbers "nearly as good" as CPU intensive LCG (Linear Congruential type) RNGs,
and better random numbers than rand() (and faster too).

I've been writing an unbiased path tracer (a sort of GI ray tracer) in MS-DOS during the last few weeks for an upcoming video on my 200LX YouTube channel,
and since path tracing requires lots of random numbers (just like SSL encryption does in your SSH2DOS) and requires an RNG with good periodicity and high quality "randomness",
I initially used an LCG similar to linuxs' rand48() with good, but slow results, as there's more than a dozen multiplications and additions per number in the function.

After switching from the LCG to this XOR shift register RNG I've got nearly identical quality random numbers with a high periodicity and no observable patterns (int32_t only though, but that's enough as my renderer uses single precision floats throughout),
but my engine speed increased from 49 minutes to 31 minutes per frame! 😀, with identical quality results. I'm using the Borland C++ 3.2 IDE and compiler/linker for MS-DOS.

For security reasons you might want to leave the current RNG in there (or add a better one like an LCG), and maybe add a command line option to use the RNG you already use, or the LCG, or, this one, so users on slow systems like PC/XTs can use the command line switch to use this XOR shift RNG to get a nice speed boost... (although with less security, but you can't have it all 😀 )
It's really simple too, only 3 bit shifts and 3 XORs on an unsigned 32bit integer, here's the function:

// Fast Xor Shift 32bit precision RNG
static uint32_t _fXorState = 2171454626; // RANDOM SEED & STATE

inline uint32_t fXOrShift32(void)
{
fXorState ^= fXorState << 13;
fXorState ^= fXorState >> 17;
fXorState ^= fXorState << 5;
return fXorState;
}

With old C/C++ compilers on DOS, with a 16 bit target, you'll have to typedef uint32_t as an unsigned long int, but I'm sure you know that already 😀

The 80186 CPU (HP 200LX) does multi bit shifts 3x to 4x faster than a 8086/8088, as does the 80286,
so it's even better on those platforms...

All you have to do is find a good way to get a good random seed (_fXorState ) for the RNG...3

Cheers,
Radiance

Last edited by radiance32 on 2022-06-24, 08:41. Edited 1 time in total.

Check out my new HP 100/200LX Palmtop YouTube Channel! https://www.youtube.com/channel/UCCVChzZ62a-c4MdJWyRwdCQ

Reply 16 of 16, by radiance32

User metadata
Rank Member
Rank
Member
fragmentfi wrote on 2021-04-14, 18:40:
The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work […]
Show full quote

The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work anymore. I've patched the program to be up to date (as of 2021).

The old programs can be still used if the ssh server configuration is changed to allow using less secure connection methods. The patched ones have been tested with the latest Ubuntu (20.04.2 LTS) release and needs to changes to ssh server configuration.

Old protocols and ciphers have been replaced as follows:
diffie-hellman-group1-sha1 -> diffie-hellman-group14-sha256
aes128-cbc -> aes128-ctr
hmac-sha1 -> hmac-sha2-256

I have only tested ssh and scp clients with password authentication. Key based authentication is most likely broken and needs some more work. Other changes to the program are minimal, the goal was just to get it working again with minimum effort.

I'm open for comments, bug reports and improvement ideas!

Source and binaries are available on GitHub:
https://github.com/AnttiTakala/SSH2DOS/

I will also test it out this weekend on my 200LX palmtop, it's a double speed (16MHz 80186),
so it should be a good test for REALLY old/slow machines...

Cheers,
Radiance

Check out my new HP 100/200LX Palmtop YouTube Channel! https://www.youtube.com/channel/UCCVChzZ62a-c4MdJWyRwdCQ