Legacy SSH key configuration for DOS

As part of my deep dive into retro computing, I’ve recently had to figure out some SSH configuration in order for older DOS-based computers to be able to connect and authenticate. This is a summary of what I found out, since I had to puzzle my way through this and couldn’t find any info already online about it.

Why?

I had been perfectly fine using the excellent MTCP suite of tools to create an FTP server on my retro PCs, then getting in from the modern computer side. This avoids the need to setup a relatively insecure FTP server always running, ready-to-go, on the modern computer. But it still requires me to take the single-tasking DOS machine into FTP server mode. It would be nicer to be able to use SSH-based, encrypted commands offhandedly whenever I need to transfer files.

The SSHDOS project hasn’t had a release since 2006, but is reported to work well. But when I tried using it to get into my modern Mac or FreeBSD systems, I’d get a key exchange error on the DOS side:

C:\NET\SSH>SSH2D386.EXE incanus 192.168.0.3
SSH2DOS v0.2.1. 386+ version
Remote host closed connection
DH key exchange failed
Socket write error. File: transprt.c, line: 698
Connection closed by peer
C:\NET\SSH>

I did some digging, shelved the project for a while, but then recently got back to it, did some debugging and a bit of trial and error, and eventually figured it out.

The fix

  1. On the legacy DOS client, at the command line:

    a. Use Diffie-Hellman group1 key exchange. SSHDOS supports this with the -g argument. This alone won’t solve the problem for you, though, and you’ll get the same error as above.

  2. On the modern SSH server, in your sshd_config:

    a. Support the ssh-dss host key algorithm, the only one available on the client, by adding the line HostKeyAlgorithms +ssh-dss.

    b. Add an actual DSA host key with the line HostKey /etc/ssh/ssh_host_dsa_key. If you don’t already have this key from a legacy install of SSH, create it with sudo ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key. It does not need a passphrase.

    c. Support group1-sha1 key exchange, the best available on the client, by adding the line KexAlgorithms +diffie-hellman-group1-sha1.

    d. Support the aes128-cbc cipher, the best available on the client, by adding the line Ciphers +aes128-cbc.

    e. Uncomment the other HostKey lines that may exist in your config file. Currently, on modern systems, this should include rsa, ecdsa, and ed25519. These are the defaults, and work as-is without the lines being uncommented, but once you specifically add the DSA key above, you’ll need to uncomment or add those too to not lose modern client support.

    All together, you should have these new and/or uncommented lines in your sshd_config, in any order:

    HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKeyAlgorithms +ssh-dss
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc

  3. Restart your SSH server. On the Mac, you don’t have to do anything, as SSH server processes are on an as-requested basis. On FreeBSD, do a sudo service sshd restart.

  4. Test with both your modern and legacy DOS client(s).

That’s it! I hope this helps someone else out there.

Technically, yes, this allows for less secure SSH into your servers, but if you (and your other users, if any) are using modern clients, they’ll automatically prefer the newer, more secure methods. This just allows old clients to connect if that’s all they support. Hey, it’s better than FTP!