New York City USA
•
kermit@kermitproject.org
…since
1981
|
|
The Kermit Project
|
Now hosted by
Panix.com
New York City USA
•
kermit@kermitproject.org
…since
1981
|
Frank da Cruz
fdc@columbia.edu
Created: 6 April 2022
Last update: Fri Dec 16 07:07:37 2022
Thanks to Jeffrey Altman, David Goodwin, and "Anonymous" for their contributions to this document.
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.
https://www.kermitproject.org/k95sourcecode.html
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:
| * | 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:
-DNO_AUTHENTICATION -DNO_ENCRYPTION -DNO_KERBEROS -DNO_SSH -DNO_SSL -DNO_SRP Then to add an SSH command like C-Kermit's, which "forks" an external "pipeable" ssh client (next section), include: -DSSHCMD. |
If you download this program to Windows and run it, it does exactly what is needed:
plink.exe fdc@server1.somehost.comThis 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 cI 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.
*
*
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:
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.
ssh -e none somehost.org
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 ubuntuSubstitute "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
|
| My home setup - click to enlarge |
|
| Router with Ethernet cables |
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 192.168.0.2, 192.168.0.3, 192.168.0.4, etc, which can't be seen from the outside, or even looked up:
[~] host 192.168.0.3 Host 3.0.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
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.
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 telnetdWe'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.telnetdNext, 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 = 192.168.120.0/24 # Only users in 192.168.120.0 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 restartNow, to test that it's running properly:
ss -tnlpIf successful, you should see the telnet server running on port 23.
END:QUOTE
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
only_from 192.168.1.3 192.168.1.4 127.0.1.1
}
The 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.
The process can be streamlined in different ways, for example:
client_loop: send disconnect: Broken pipeThis 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.
-o TCPKeepAlive=yes -o ServerAliveCountMax=20 -o ServerAliveInterval=15I left an ssh relay session started with these options idle for 24 hours, and it was not disconnected.
ps -u usernameat 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 psAs 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).
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
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):
# K95RELAY (SAMPLE VERSION):
# 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
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
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
echo
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 |