Icon The Kermit Project   |   Now hosted by Panix.com
New York City USA   •   kermit@kermitproject.org
since 1981

K95 Relay: A way to make Kermit 95 work with modern SSH servers
    MS Windows: New life for Kermit 95

Frank da Cruz
Created: 6 April 2022
Last update: Fri Dec 16 07:07:37 2022


Kermit 95 2.1.3 (K95) terminal-emulation and file transfer software for MS Windows had a number of security methods built in but the last K95 release was in 2003 — nearly 20 years ago at this writing — and all of those security methods have either vanished from the Internet or changed out from under K95 to the extent that in most cases K95 can no longer make Internet connections at all. This document summarizes the situation, suggests some possible remedies, and presents an interim procedure that users can implement themselves on their own home networks if they also have a Unix-based computer (or a Unix subsystem on their Windows PC).

NEWS: The first new release of C-Kermit for Windows (the former Kermit 95, last released 1 January 2003) entered Beta test on 17 July 2022; CLICK HERE to read about it and try it out. The second Beta test (17 August 2022) added an integrated modern SSH client, thus eliminating the need for the method described in this page. The third Beta was not able to make SSH connections to hosts that had the old "deprecated" encryption ciphers. The fourth Beta and later are able to connect to any SSH V2 server, old or new. Therefore, some of the sections of this page are obsolete, and marked correspondingly.

Thanks to Jeffrey Altman, David Goodwin, and "Anonymous" for their contributions to this document.



[Skip to next section]
For about 20 years (1995-2015) Kermit 95 was — by almost any measure — one of the world's top terminal emulators: number of terminals emulated, quality of emulation, integrated platform-independent file transfer, sophisticated file transfer and management controls, internationalization features, key mapping and customization, with a built-in scripting language for automation, and operating over over a variety of connection types including serial port, modem, Internet TCP/IP, and numerous other long-forgotten networking methods. On the Internet K95 supports Telnet, Rlogin, and SSH connection protocols and SSH, SSL, SRP, NTLM, Kerberos IV, and Kerberos V security and encryption methods.

K95 development stopped in January 2003 when Columbia University laid off our Windows and security programmer, Jeffrey Altman. Yet the software continued to work year after year across many new Windows releases, up to and including Windows 10 (and presumably also 11).

But the world has changed since 2003. Serial ports and modems have virtually vanished from the scene. Numerous networking methods supported by K95 including DECnet, LAT, and TES have disappeared. Telnet terminal connection protocol has been replaced by SSH, and FTP (which K95 also supports) has been banned from the Internet. SSL, SRP, Kerberos IV, and Kerberos V security methods have been stricken from the terminal-to-host landscape. The consequence of all this for K95 is simply this: the only way to make a terminal-to-host Internet connection today is with SSH.

Kermit 95 has supported SSH since K95 1.1.21 of April 2002 (20 years ago at this writing) and was a perfectly functioning SSH client until the OpenSSH project began removing the ciphers that Kermit used (3des-cbc, aes256-cbc, cast128-cbc, rijndael256-cbc, aes128-cbc, arcfour, rijndael128-cbc, aes192-cbc, blowfish-cbc, rijndael192-cbc) from new SSH server releases until there were none left, at which point K95 could not make a connection to any computer on the Internet that had an up-to-date SSH server.

Speaking as one of the designers and authors of K95 who still uses it all day every day, I don't want to give it up. I do almost all my work on text-mode connections to Unix shells, text editors, and developer tools, touch-typing 120wpm; I can get more work done per hour than almost anybody because I can do just about everything from my (K95‑customized) keyboard and I don't have to be switching back and forth between different applications all day, or between the keyboard and the mouse. Files fly back and forth in the same terminal session without context switching. If you're interested, I have more to say on this topic HERE.

The rest of this document describes some options for keeping K95 2.1.3 of 2003 in service for another 10 or 20 years, plus ideas for a new release.

A new K95 release? (section obsolete: there IS a new release)

When the Columbia Kermit Project was canceled in 2011, K95 source code was published on the Internet in hopes that some Windows programmer(s) would step up and build a new Open Source version, and in 2013 two projects made significant progress, but not quite enough for a general release. You can see the results here:


These efforts foundered on K95's security features, notably SSH. These were (and are, and always will be) a moving target. It might make good sense to pick up where the earlier projects left off but handle security in a completely different way, such as the one outlined in the next section.

Meanwhile, a new release of K95 might have benefits beyond satisfying us old-time text-mode touch-typers by filling the gap left when FTP (the Internet's venerable File Transfer Protocol, 1971-2021, RIP) was effectively banned from the Internet in 2021. Kermit's file-transfer protocol is infinitely more powerful than FTP ever was and than anything else available today; click here for a summary. The demise of FTP might also be sufficient reason to revive the long forgotten Internet Kermit Service Daemon.

Possibilities for a new K95 release include:

  1. No changes to current Open Source K95 code, but built without security. This would be like the K95 2.1.3 "nocrypto" distribution*, which was (and is) exportable to all countries; it could be put on the website for anybody in the world to download and use, and it would be usable with SSH relays as described below.
  2. Same as 1, but with with a new "set host /pty" command added to work with programs like Plink (next section). This would allow K95 to make SSH connections without needing a to use a second computer as a relay. Even better would be if Microsoft changed its own ssh program to have a pass-through option as an alternative to doing terminal emulation itself; then we wouldn't even need Plink.
  3. K95 includes many of the modules of C-Kermit. Built with the latest ones, rather than the 2003 ones, it would have many new features and bug fixes. For the first time in 19 years, K95 and C-Kermit will be in sync.
Any new K95 release will just be Kermit 95 itself, no frills like the GUI Dialer, massive dialing directories, etc. Again, visit this page to get an idea of the the Open Source versions where it left off in 2013, in case you want to look into working on it. Also note that one of the 2013 work-in-progress versions is on GITHUB and it has 11 forks.
* The is no single compilation flag like -DNOCRYPTO to do this. I believe the way to build K95 with no cryptography at all is to include the following flags in the makefile entry:
Then to add an SSH command like C-Kermit's, which "forks" an external "pipeable" ssh client (next section), include: -DSSHCMD.

False start: A passthrough Windows SSH client (section obsolete)

C-Kermit for Unix (Linux, macOS, BSD, etc) makes SSH connections by invoking the computer's existing SSH program with its input and output redirected from/to C-Kermit itself. Thus SSH protocol and ciphers can change all they want without requiring new C-Kermit releases. It would seem that K95 could work exactly the same way if there were an SSH client for Windows that worked exactly like Unix SSH, namely by reading and writing to/from standard input and output instead to/from the PC hardware. It turns out there is exactly such a client, the Putty Plink program (which can be downloaded HERE) — thanks to David Goodwin for pointing it out.

If you download this program to Windows and run it, it does exactly what is needed:

plink.exe fdc@server1.somehost.com
This gives me a "raw" SSH session in which the host's terminal escape sequences are passed through and not interpreted. But if I start K95 and tell it to:
set host /network-type:pipe "./plink.exe fdc@server1.somehost.com"
or equivalantly (I think):
set host /pipe "./plink.exe fdc@server1.somehost.com"
It seems to work:
[C:\Users\fdc\k95\] K-95> show connection

Status:       Active
Opened:       20220414 07:13:03
User:         fdc
PID:          4664
Type:         NET
To:           ./plink.exe fdc@server1.somehost.com
From:         Bronx (name of my Windows computer)
Elapsed time: 00:00:11
Encrypted:    No
Log:          (none)
but (a) it doesn't go into terminal mode automatically, and (b) when I tell K95 to CONNECT, I get a blank screen in which keystrokes have no effect and there is nothing in the scrollback buffer. In Task Manager if I double-click on the K95 process, it shows ./PLINK FDC@PANIX1.PANIX.COM underneath it as expected.

So even though Plink is doing its job under K95, K95 doesn't seem to have a mechanism to read from it or write to it. Apparently K95's "set host /network-type:pipe" command is not the same as C-Kermit's "set host /pty". So pipe != pty and there's apparently no way for K95 2.1.3 to use Plink because there's no way to route it through K95's terminal emulator, and we're still stuck needing changes to K95: changes that might work only in the newest Windows versions. However, David Goodwin observes:

As for Plink not working, I wonder if there is just some bug in K95? I don't see anything in the documentation that suggests it needs anything special. I wouldn't think we'd need PTYs to do this either - Plink has been around longer than PTY support in Windows and given it works fine in the windows terminal just attaching stdin/stdout to K95's terminal emulator should be enough. I assume this code is where the pipe is set up and it looks reasonable enough (though I don't really know the Win32 API) so perhaps the bug is elsewhere.

Another tester wrote that when trying the same thing with K95.EXE, the non-GUI version of mainline K95, the results were somewhat better, saying:

If I do:
set host /pipe cmd
I get the cmd.exe banner and a prompt where, if I type a command (dir) and then hit Control-M Control-J instead of enter key, it will only then echo back the command line and execute the command. So something is off with line buffering and CR LF translation since you can't see as you type and the Enter key won't work.

Once I launch Plink everything from that prompt by blindly typing the plink command line and then Control-M Control-J, it seems good to go. If you're using SSH password authentication, same deal with needing Control-M Control-J instead of enter at the password prompt.

So in short, the Plink method is promising but doesn't totally work with the current K95 release, 2.1.3, in either of its incarnations. But since it "amost works" in one of them, it is likely that only a little bit of programming is needed to make it operate as expected.

A workaround for K95 2.1.3: Using a second computer as a gateway

As of December 2022, C-Kermit for Windows works with all known SSH servers but when the day comes that SSH changes out from underneath it again, the workaround described here remains viable.

   Screen                                        * <-- Firewall
 +---------+            +--------+           +--------+           +----------+
 |         |  Telnet    |        |   SSH     |        |    SSH    |   Some   |
 | Windows +------------+ Ubuntu +-----------+ Router +-----------+ Internet | 
 |         | Clear text |        | Encrypted |        | Encrypted |   host   |
 +---------+            +--------+           +--------+           +----------+
   Keyboard               Gateway                *

This method works by piping through a redirectable SSH client as just described, but because Windows doesn't have one and K95 2.1.3 doesn't support pseudoterminals, we have to use a second computer that does have one. You can use this method if:

  1. You have your own private home network hidden behind a router provided by your ISP; and:
  2. you have a second, Unix-based computer (e.g. Ubuntu or Debian or Arch) on your home network (if you don't have one, you could look into the extremely low-cost and small Raspberry Pi).

    OR... (not tested yet) if you have Linux Subsystem for Windows on your Windows PC (in which case the Ubuntu box in the diagram would be inside the Windows box; and it could be not only Ubuntu but also but also Debian, Arch, Kali, OpenSUSE, etc); Windows 10 build 19041 or later.

  3. you have NOT configured your router to allow outside access to your home computers; and:
  4. The relay computer is wired to your router (not accessed wirelessly); wireless devices are visible to other people in your vicinity (such as in an apartment building).
With this setup you can make a clear-text Telnet connection to your Unix computer and then use its up-to-date SSH program to connect to the desired internet host:
ssh -e none somehost.org
Your network traffic is secure (i.e. encrypted) and although your local traffic is insecure, nobody can see it. The "-e none" directive makes SSH totally transparent to all bytes that pass through it, so you can conduct any kind of terminal session and transfer any kind of file between your Windows PC and the remote Internet host.

I have a PC with Windows 10 and another PC with Ubuntu 20.04 on my desk, each connected by Ethernet cable to my Optimum Online router. Ubuntu does not come with Telnet installed but it's in their application repository and you can add it. For instructions, Search Google for:

install telnet server on ubuntu
Substitute "debian" or other distribution name as appropriate (note: detailed instructions for Ubuntu are included below). Once Telnet is installed on the Unix computer you should be able to tell K95 to "telnet ubuntu" (or whatever its hostname is) and it will just work. Then, by hand, you can give a command like this at the Ubuntu shell prompt:
ssh -e none somehost.org
and have the same kind of session you did before everything changed. In particular, you can transfer files between your Windows PC and the Internet host as if they were connected directly and there was nothing at all between them.

Detour: About your private network

Home network on desk
My home setup - click to enlarge
When you have Internet service in your home, you probably also have your own modem and router. The photo shows my own World War II desk with an Ubuntu PC just left of the monitor and a Windows PC to its right (with a WWII stapler next to it, the only kind that works). Leaning against the Windows PC is the modem, and leaning against the modem is the router where each PC is connected by Ethernet cable (because wireless connections are less secure). Right of center below the monitor are some little boxes that allow the keyboard and screen to be switched between the two PCs. The keyboard, if you're interested, is THIS ONE.

Ethernet cables
Router with Ethernet cables
If your home network is private, as most or all of them are by default, these computers are not accessible from the outside world, they cannot even be addressed from outside. Thus anything you do locally (i.e. without making an Internet connection) with or between these computers is secure; no encryption required. For example, if you make a clear-text Telnet connection from Windows to Ubuntu, nobody can snoop your password or anything else.

If I log in to an Internet host from the Windows PC and the Ubuntu PC at the same time, and maybe even also from some stray laptops or old computers, all of these connections have the IP address of my router when seen from the outside world (as revealed by the host 'w' command). Within my home network, the PCs have addresses like,,, etc, which can't be seen from the outside, or even looked up:

[~] host
Host not found: 3(NXDOMAIN)
precisely because addresses in this range are reserved for private use.

CAVEAT:  Although your router protects you from hackers sneaking into your computer from outside, there is no protection whatever from your own web browser or any site that you visit with it, or any other application you run on Windows, or for that matter Windows itself, from spying on you and sending your data back to Microsoft, Google, Firefox, Amazon, and other gigantic corporation (or government agency, foreign government, etc). Furthermore, any Web page you visit in your browser is basically somebody else's program running on your computer and you have no way of knowing what it's doing behind the scenes. Ditto for Web-based email, such as Gmail and its attachments. Browsers such as Firefox and Chrome supposedly try to protect you from hostile pages and mail attachments, but even with the best intentions there is no way they know and block all the threats. Anti-virus software such as Symentec Endpoint Protection provides a degree of protection from hostile attacks, but it can never be perfect and I don't think it even tries to protect against corporate harvesting of your actions and "preferences" which they use for "targeted advertising" and who knows what else.

By the way, none of this is an issue for Kermit. In fact you're almost certainly much less likely to be spied on when using Kermit to make text-mode connections to other computers (especially through ssh) than you are using mainstream graphical Windows or Web applications.

Ubuntu setup

I happen to have an Ubuntu Linux computer on my desk, that I use for C-Kermit development and testing, so that's also my K95 Internet relay. It might also be possible to create the same setup on your Windows PC itself with Linux Subsystem for Windows, which is Ubuntu (Windows 10 or 11 required), in which case you wouldn't need a second computer.

Like most Linux distributions nowadays, Ubuntu does not include a Telnet server "out of the box", so you have to install and configure one yourself. The following is from THIS PAGE by Joshua Davis:


By default, Telnet server is disabled for security purposes in favor of SSH. However, you can enable Telnet for testing purposes or for legacy scripts. First, install the necessary packages:

sudo apt-get install -y xinetd telnetd
We'll need to configure the inetd configuration. Using your favorite editor and with root permission, open up /etc/inetd.conf. Unless you've modified this file, it will probably not exist or be pretty empty. Add the following line to the end of the file and save it.
telnet stream tcp nowait telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd
Next, we'll need to configure the xinetd service. Again, using your favorite editor and with root permission, open up /etc/xinetd.conf. And, again, unless you've modified this file, it will be pretty empty. Add the following lines to the end of the file and save it.
# Simple configuration file for xinetd
# Some defaults, and include /etc/xinetd.d/ defaults
# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info
    instances = 60
    log_type = SYSLOG authpriv
    log_on_success = HOST PID
    log_on_failure = HOST
    cps = 25 30
If you'd like to update the default configuration, edit /etc/xinetd.d/telnet and add the following:
# default on
# description: The telnet server serves telnet sessions; it uses
# unencrypted username/password pairs for authentication.
service telnet
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /usr/sbin/in.telnetd
    log_on_failure += USERID
and for extra security you can add these lines as you like:
only_from = # Only users in can access
only_from = .testy.com # Only allow access from testy.com
no_access = 192.168.120.{101,105} # Do not allow access from these two IPs
Finally, use the following command to start the telnet server:
sudo /etc/init.d/xinetd restart
Now, to test that it's running properly:
ss -tnlp
If successful, you should see the telnet server running on port 23.


You can also check the server with:

netstat -a | grep telnet

I followed these instructions and double checked the configuration files. Telnet worked locally, i.e. Ubuntu to Ubuntu, but I couldn't telnet from Windows to Ubuntu. A great deal of Google searching led to the crucial final step. At the Ubuntu shell prompt give this command:

sudo ufw allow 23   IMPORTANT!
It tells the router to allow incoming Telnet connections on port 23; look in Google for details:
linux ufw command
(ufw = "Uncomplicated Fire Wall".) The ufw command is "sticky", it remains in effect, even across multiple computer shutdowns and restarts, until some other ufw command is given to countermand it.

Now this setup might seem unsafe because it tells the router to accept Telnet connections from anywhere. There might be some way to tell ufw to make some distinction between internal and external accesses, but in any case the Telnet configuration will reject any connections that are not in the approved list, as in my own /etc/xinetd.d/telnet:

# default: on
# For use only on local network.
service telnet
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /usr/sbin/in.telnetd
    log_on_failure += USERID
The only_from clause restricts telnet acces to my own desktop computers.

Other Unix versions

I only have Ubuntu on my local network but I think that the same scheme will work on Debian and Arch Linux too; verification would be appreciated. Other Linux distributions, not to mention other Unix variants such as *BSD, are likely to have different tools. Any readers who can adapt this process to other Unix variants, or even non-Unix operating systems such as VMS, are encouraged to send their setups to be included in (or linked to from) this section, with credit of course.

By the way, a variation on this theme would be if you had a computer on your home network whose SSH server supported the old ciphers and also an SSH client that supported the new ones, this too could serve as an SSH relay for Kermit.

Using the relay

Using the relay setup is straightforward but a bit labor intensive: Use the connection exactly as if it were a direct connection to the Internet computer, connecting and escaping back, transferring files, etc. The only difference is that when you log out from the Internet host, you pop back to the relay computer, where you have to log out again.

The process can be streamlined in different ways, for example:

  1. Create a Kermit script to automate all the steps (next section).
  2. Use SSH key exchange to eliminate the need for passwords. Setting this up is beyond the scope of this document (search Google for ssh key pair tutorial) but if you know how to do it (or have done it already), you're all set.
A script can be written — either with or without key exchange — that gives the illusion of making a direct connection directly the desired Internet host, making the relay computer "invisible".

Problems noted...

I've been using the relay in four different sessions simultaneously since April 6th. The only problem noted so far is:
  1. A session can suddenly become unresponsive. K95 itself is OK: the mouse still works; you can still go back and forth between the terminal screeen and the command screen (Alt-x), but in the terminal screen the keyboard appears dead, keystrokes don't echo and have no effect. Sometimes the problem goes away and everything works again. A couple other times, after a long wait (not yet sure how long, minutes or hours), the following message appears in the command screen:
    client_loop: send disconnect: Broken pipe
    This indicates a problem between the ssh client on the relay and the ssh server on the host; it's nothing to do with K95. It happened to me only twice.
  2. Idle-limit disconnections. There can also be disconnections occasioned by an Internet Host whose ssh server is configured to kill sessions after a certain amount of inactivity, typically an hour or two. This can be avoided by adding the following command-line options to the relay's ssh command:
    -o TCPKeepAlive=yes -o ServerAliveCountMax=20 -o ServerAliveInterval=15
    I left an ssh relay session started with these options idle for 24 hours, and it was not disconnected.
  3. Windows crash leaves orphans behind on the relay. If Windows crashes or freezes and needs to be restarted, your relay will still have your sessions open. You can see them when you make a connection to the relay and type:
    ps -u username
    at the shell prompt, to receive a list of all your processes, e.g.:
    1179382 pts/0    00:00:00 bash
    1179396 pts/0    00:00:00 ssh
    1181237 pts/1    00:00:00 bash
    1181251 pts/1    00:00:00 ssh
    1181704 pts/2    00:00:00 bash
    1181723 pts/2    00:00:00 ps
    As far as I know, Unix offers no way for you to attach to an orphaned process and resume the session (as, for example, the late lamented TOPS-20 operating system did with its ATTACH command). So you can just let them die off on their own, eventually, or 'kill' ("man kill") them by process ID (first column).
  4. If the relay machine crashes, your K95 session will pop back to its command screen with an appropriate error message.
  5. In both cases 3 and 4, orphaned sessions might have been left behind on the Internet host that can be killed when you log in again; otherwise they will expire on their own after a while.
  6. If the Internet host itself crashes, your K95 screen should pop back to the Relay automatically with an appropriate message; no cleanup is necessary in this case.
  7. K95's status line shows the protocol as TELNET, not SSH (at lower right). K95 only knows the protocol used to make the connection to the relay, whose protocol to the host is (of course) SSH.

Automating your SSH logins

Instead of following all the steps listed above every time you make a connection, you can have a Kermit script do them for you. This example is called "k95samplerelay". You should edit it as needed to apply to your situation and rename it as desired ("k95relay" in this example). Then if you put a line in your k95custom.ini file like this one:
define k95relay take c:/users/youruserid/k95/k95relay
(substituting the path where you have stored the script), you can just give the command "k95relay" at the K95> prompt. Of course you can use any other name you want for the script, such as the name of the host you're connecting to, which makes sense if you'll be using this method to connect to more than one host.

Anyway computers and their user interfaces and dialogs (not to mention ISP conventions for naming local hosts) vary so much that it's not possible to create a script that works everywhere. You'll need a script for each Internet host you log in to. Possibly a suite of scripts, all of which call upon a single script to login to the relay, and then make the connection from there to the desired host. Here is the script I use for logging in to a NetBSD host via Ubuntu (CLICK HERE to download it):

# Connects from K95 on Windows to an Internet host through an SSH relay
# Frank da Cruz
# The Open Source Kermit Project
# 10 April 2022
# Last update: Tue Apr 19 08:16:23 2022
# Windows Kermit-95-to-Internet-host connection via ssh relay.  Totally
# password driven: covers the case where both the relay and the Internet host
# are logged in to with a password.  Many other combinations are possible,
# e.g. public/private key exchange between the relay and the Internet host
# and/or between Windows and the relay.  The purpose of this script is simply
# to show that whatever the authentication method, the process can be scripted
# to mimic direct ssh login from Kermit 95 on Windows to the Internet host,
# even when the host doesn't recognize K95's ssh ciphers.
# When the script starts it prompts you for the two passwords.
# To adapt this script to your own home network, change the definitions
# in the first two sections and then make other adjustments as required.
# Note: The Internet server name (\m(fulltarget) is FICTIONAL.

# User and computer names - CHANGE THESE
.relayuser = fdc                        # Username on relay
.targetuser = fdc                       # Username on Internet computer
.windowsuser = fdc                      # Username on Windows
.relay := \m(relayuser)-Ubuntu          # Relay hostname on local network
.fullrelay := \m(relay).home            # Full domain name of relay 
.fulltarget = server1.somehost.com      # Internet destination domain name

# Prompts, responses, and directories - CHANGE THESE IF NECESSARY
.relayshellprompt := [~]\32             # Relay shell prompt to wait for
.relaybadpassword := "Login incorrect"
.targetpassprompt := "Password: "
.defaultdirectory := C:/Users/\m(windowsuser)/tmp/ # Default Windows directory
.keepalive = 0              # Change this to 1 if you get "broken pipe" errors

# Other parameters derived from the user and computer names specified above
.shortrelay := \fupper(\fword(\m(relay),2,-)) # (for messages)
.shorttarget := \fword(\m(fulltarget),1)      # (for messages)
.banner := \fcapitalize(\m(shorttarget)) via \m(relay) # Banner for window
if \m(keepalive) {
    .sshcmd1 := ssh -l \m(targetuser) -e none 
    .sshcmd2 = -o TCPKeepAlive=yes -o ServerAliveCountMax=20
    .sshcmd3 = -o ServerAliveInterval=15
    .sshcommand := \m(sshcmd1) \m(sshcmd2) \m(sshcmd3) \m(fulltarget)
} else {
    .sshcommand := "ssh -l \m(targetuser) -e none \m(fulltarget)"
set title \m(banner)                    # Write window-frame banner
cd \m(defaultdirectory)                 # CD to desired Windows directory
if fail end 1 "cd \m(defaultdirectory) failed"

# Operational customizations - Colors, size, font, appearance, etc.
set command color white black           # Command screen color
set term color term lgray blue          # Terminal screen color

set terminal character-set utf8         # UTF-8 character encoding
set term apc unchecked                  # Application Program Command
set term width 80                       # Screen dimensions: 80 chars wide
set term height 45                      # and 45 lines high
set terminal font courier_new 10        # Font and size (points)
set gui window position 140 200         # Where to put window on PC screen
set terminal autodownload on            # Allow autodownload
set terminal scrollback 12000           # Allocate a big scrollback buffer

# Collect passwords...

undef _yy
while not def _yy {                     # Prompt for relay password
    askq _yy {\m(shortrelay) password: }
undef _zz
while not def _zz {                     # Prompt for Internet host password
    askq _zz {\m(shorttarget) password: }
# Connect to relay and log in
echo LOGGING IN TO RELAY \fupper(\m(shortrelay))...

set telnet auth type none               # Clear-text Telnet to relay
set host \m(fullrelay) telnet           # Connect but stay in command mode
input 10 Password:\32                   # Wait for password prompt
if success lineout \m(_yy)              # Send password
else end 1 "Relay password prompt not received"
minput 10 {\m(relayshellprompt)} {\m(relaybadpassword)}
switch \v(minput) {
  :0, echo, hangup, end 1 "Relay shell prompt not received"
  :1, break
  :2, echo, hangup, end 1 "FAILURE: Password not accepted"
  :default, end 1 "Problem with \m(shortrelay) login"
echo \m(shortrelay) LOGIN OK...

# Connect from relay to target and log in.  Host behaviors vary as to what
# happens if the incorrect password is given so we just connect after sending
# the password and see what happened.
echo LOGGING IN TO TARGET \fupper(\m(shorttarget))...
lineout \m(sshcommand)                  # Send ssh command to relay
input 10 \m(targetpassprompt)           # Wait for target password prompt
if fail end 1 "Target password prompt not received: \m(targetpassprompt)"
msleep 100                              # Brief pause
lineout \m(_zz)                         # Send password
if open connection echo "\fupper(\m(shorttarget)) CONNECTION OK"
else end 1 "\fupper(\m(shorttarget)) CONNECTION FAILED"
connect                                 # Open terminal window to target
end 0                                   # return code 0 = success

; Local Variables:
; comment-column:40
; comment-start:"# "
; End:

As you can see, the script prompts you for the relay and Internet host passwords, so you still have to type them each time. This is not necessarily necessary; as noted above, you could set up SSH key exchange, or use any other trick you can think of.

To adapt this script for your own use, first change the user, relay, fullrelay*, fulltarget, and windowsuser definitions just under the comment block at the top of the script. Put it in the directory you normally CD to on Windows, and then tell K95 to "take k95relay", see what happens, then make any needed or desired adjustments.

* The .home domain is used by Optimum for private home networks; I'm not sure if this is universal.

The New Open-Source Kermit Project hosted by Panix.com / Created: 10 April 2022