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

C-Kermit for Windows How-To

Frank da Cruz
ckw@kermitproject.org ← questions, problems, reports
Created: 16 July 2022
Last update: Fri Sep 23 13:35:29 2022 New York time
(work on this page is in progress...)

Ini files   SSH setup   New mouse features   [Back to CKW Beta test]

Initialization and customization files

C-Kermit — and especially C-Kermit for Windows (CKW) with its built-in SSH client and terminal emulator that distinguish it from other C-Kermit family members — has hundreds, maybe thousands, of features, commands, and options and therefore many commands. To illustrate, if you want to make a connection to another computer you have to tell CKW what kind of connection to make (e.g. serial port, modem, SSH). If it's a serial port, you have to tell CKW which port to use (like COM1, COM2), what speed to use (like 19200 bits per second), and what (if any) kind of flow control to use with it (hardware [RTS/CTS] or software [Xon/Xoff]). If it's a modem you need to specify the same information plus the type of modem it is and the phone number so CKW will know what commands to give to it, and what phone number. If it's an SSH connection you have say whether to use key-exchange authentication (and set that up in advance, explained below) or to use a password and you have tell it the IP hostname of the computer (host) you want to connect to. Then, once connected to the host, you have to choose which kind of terminal to emulate, and specify which character-set it uses for text files that might contain accented or non-Roman characters.
All of the terms and concepts used above are explained in detail in the book Using C-Kermit which is now available online.
All this would amount to typing a LOT of commands every time you wanted to make a connection. But you don't have to — that's what Ini files are for: initialization and customization. CKW has three Ini files:
Table 2: CKW directories
File Filename Directory Kermit variable
Root startup file k95.ini C:\ProgramData\Kermit 95\ \v(inidir)
Sitewide initialization file k95site.ini C:\ProgramData\Kermit 95\ \v(inidir)
Customization file k95custom.ini C:\Users\username\AppData\Roaming\Kermit 95\ \v(appdata)
Warning: the "k95" prefix on the filenames is likely to change (probably to "ckw") before CKW is released, to avoid conflicts with any earlier installation of Kermit 95 (K95).
The first two should not be changed. The third one, k95custom.ini, is your personal customization file. Every time you start CKW, it reads this file and executes the commands in it. Among the many things you can do in your customization file is define macros, which are multiple commands grouped into a single command. So, for example, here's a macro to make an ssh connection to foo.bar.com, where your user ID is "helga":

define foobar {
    set terminal font courier_new 10  # Font and size for CKW screens
    set terminal type vt220           # DEC VT220 terminal emulation
    set terminal character-set utf8   # Character encoding to use
    set terminal width 80             # CKW window width (characters)
    set terminal height 48            # CKW window height (lines)
    set terminal color lightgrey blue # Colors for the terminal screen
    set terminal scrollback 3000      # Keep a 3000-line scrollback buffer
    set gui window-position 1120 50   # Where to put CKW on computer screen 
    set ssh heartbeat 60              # Keep SSH session alive during idle time
    ssh foo.bar.com /user:helga       # Make SSH connection
Note: the /user: clause is unnecessary if you have set up passwordless SSH key exchange.

"foobar" is now a command you can type at the Kermit prompt, which connects and logs you in to foo.bar.com, at which point CKW switches automatically to its terminal screen, which is sized, colored, and positioned as you specified in the foobar macro. The parts that start with "# " are (optional) comments. Macros are thoroughly documented in Using C-Kermit, chapters 17-19.

The same script should work no matter whether you have set up SSH key exchange or not. The only difference is, if you haven't, you'll have to enter a password. On the other hand, if you do have key exchange working, you don't have to include the "/user:helga" because the keys know who you are (but it does no harm to leave it in).

For information about the commands themselves, type "help set terminal", "help set gui", "help set ssh", "help ssh" at the CKW command-window prompt, and for much greater detail see the terminal emulation section of the Kermit 95 manual.

Configuring the SSH client

For greater detail see SSH Support in C-Kermit for Windows 10.0b4 Beta 3.

The built-in handmade SSH support code from K95 2.1.3 was retired because (among other reasons) it didn't work any more due to changes in the ciphers used by modern SSH servers. As of the second CKW beta, SSH connections are accomplished through the Windows DLL (Dynamic Link Library) supplied with LibSSH, which supports only SSH V2.

K95's SSH client from 2003 is thoroughly documented HERE but it remains to be seen to what extent that document applies to CKW's new SSH client. About the latest version, see the file ssh-readme.txt in the CKB Beta.02 Zip archive for notes on the new implementation, which is also available online HERE.

Anyway, if you don't mind typing your host password every time you make an SSH connection, you can use CKW as-is "out of the box", no configuration required. Don't worry about security, your password is encrypted in transit. However, if you'd like the convenience of not having to type your password you'll need to take the steps that are described just below (if you haven't taken them already for some other Windows SSH client such as PuTTY).

Configuring the SSH client for passwordless connections

Warning: If you set up passwordless connections from your PC to other computers, be aware that if you walk away from your computer without logging out (e.g at work, to go the bathroom), anybody can use your computer to access those computers as you unless those computers use some form of multifactor authentication such as callback or shared secret (and even that is no guarantee).

Passwordless connections work by key exchange; the client sends its public key to the server and the server sends its own public key to the client. These are paired at each end with a secure, secret private key. Here's how to set up SSH key-exchange for login from CKW to most(?) Linux hosts. This procedure works in Windows 10 and later; the procedures for previous Windows versions, other Unix-family host operating systems (e.g. BSD, AIX, macOS), or for completely different OS families like VMS will differ. You can skip part A if you have already set up your SSH keys on Windows for some other SSH client. For that matter, you can also skip Part B for hosts you've already installed your SSH public key on.

A. On your PC   (you only need to do this once*)...
  1. Start Powershell. If you don't have an icon for it on your desktop, search for "powershell" (second icon from left in the toolbar on the bottom of your screen). Or in CKW, just give the command "run start powershell".
  2. Tell Powershell to "cd C:\Users\username\.ssh". (usually simply "cd .ssh" is sufficient).
  3. Give Powershell a "dir" command.
  4. If you don't see a file called id_rsa give Powershell the command:
    ssh-keygen asks you for a file name; just press Enter key to accept the default, which is id_rsa.
  5. ssh-keygen asks you for a passphrase (password) for accessing the file, you can hit the Enter key for no password, or else provide a password for it (but don't forget it!).
  6. ssh-keygen prints the details of what it did. Now give Powershell another "dir" command. You should see at least these three files
    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a----         8/25/2022   7:18 PM           2590 id_rsa
    -a----         8/25/2022   7:18 PM            564 id_rsa.pub
    -a----         8/26/2022   1:30 PM            697 known_hosts
  7. The id_rsa.pub file is your public key that you upload to every host you want to access without a password.
  8. You can close Powershell now.
* Strictly speaking, once for each key type you have to generate, in case all the hosts that you connect to don't accept the same key types, explained below.
B. Then for each host you want to connect to...
If you try this on any host other than Linux or NetBSD, please let me know the results or, better still, if you had to do it differently send me the details.)
  1. Start CKW and tell it to "cd .ssh" or if that didn't work (because CKW was cd'd to some other directory): "cd \v(home).ssh".
  2. Use CKW to make an SSH connection to the desired host, for example:
    ssh somehost.someuniversity.edu /user:username
    Since you don't have the keys set up at both ends yet, CKW prompts you for your host password. Enter the password, CKW makes the connection, and you'll find yourself in the terminal screen looking at a host shell session.
  3. Give shell the command "cd ~/.ssh".
  4. Start Kermit on the host and tell it to "get" a file. The name of the Kermit program on the host might be "kermit" or "ckermit" or "wermit" or "gkermit" or "ekermit". See below for what to do if the host doesn't have Kermit installed. Assuming it does, the command would be "kermit -g" (or "ckermit -g" or "wermit -g") followed by the filename; example:
  5. The upload should happen automatically and take just a couple seconds. and then you'll be back at the host shell prompt.
  6. At the host shell prompt, give an "ls -l" command. You should see something like this:
    -rw-------  1 fdc  kermit   563 Aug 25 19:31 authorized_keys
    -rw-------  1 fdc  kermit   563 Aug 25 19:31 id_rsa.pub
  7. Now here's the tricky part:
    • If the authorized_keys file DOESN'T EXIST, rename id_rsa.pub to authorized_keys:
      mv id_rsa.pub authorized_keys
    • If the authorized_keys file ALREADY EXISTS, you'll need to append id_rsa.pub file to it:
      cat id_rsa.pub >> authorized_keys
      Then check the authorized_keys file to make sure the new entry is there:
      tail authorized_keys
      and then remove the id_rsa.pub file:
      rm id_rsa.pub
  8. And finally, make sure all the files in your .ssh directory are protected from snoopers:
    chmod 600 *
That's for just one host connection. For every other host you want secure passwordless access to, you have to repeat part B.

If a host you use doesn't have Kermit installed... You'll need to find another way to upload the file. You could download and build C-Kermit on the host yourself, or you can use any other file-transfer method you have at hand that also works on the host, or you could email your public key from Windows to your ID on the host as an attachment.

About SSH key formats

As of 2022, there are four are four different generations of SSH keypairs; in chronological order: RSA, DSA, ECDSA, and ED25519. Each one is supposedly better than the previous ones so today EDS25519 is recommended. Any site that has an SSH server probably supports all four, but no guarantees.

The procedure given above uses the oldest generation, RSA, because that's what the Windows version of ssh-keygen generates unless you tell it otherwise. To specify a particular keypair type, use:

ssh keygen -t ed25519
the keys are created with filenames "id-type" (your private key) and "id-type.pub" (your public key); for example: id_ed25519 and id_ed25519.pub. So creating keys of different types doesn't destroy any keys you created with other types. The reason you might need to keep different key types is that all hosts do not necessarily support all key types.

Further reading:

If your new SSH keys didn't work

If you complete the above procedure for setting up passwordless access to a particular host and you are still prompted for a password, there are (at least) two possibilities:
  1. The SSH server on the host does not support the type of key you created. In that case, you have to create a different type of keypair and follow the whole procedure again, both parts A and B. But first check (2) because (although it's longer to explain) it's much easier to fix!
  2. SSH key exchange won't work on Unix-like operating systems like Linux, macOS, and *BSD, if your home (login) directory is not write-protected. Do this (using sample username "greta"):
    cd                     # cd to home directory
    cd ..                  # go one level up
    ls -l greta            # check the permissions of your login directory
    chmod g-w,o-w greta    # change to disallow write access to group and others
    ls -l greta            # check the results
    cd                     # go back to home directory

    By the same token your .ssh directory should be closed to the world:

    chmod 700 .ssh

    and the same for the files in it (your ssh keys and data):

    cd .ssh
    chmod 600 *
  1. Unix file permissions (Wikipedia)
  2. Unix chmod command (Wikipedia)

If you want a higher degree of protection

If you followed the default procedure — which creates RSA keys — and they work satisfactorily, but now you want to switch to a "more secure" key format, go through procedure again but substitute "ed25519" everywhere you see "rsa". See a discussion HERE or search Google for "rsa versus ed25519" (without the quotes).

New Mouse features

From David Goodwin, August-September 2022:

Added mouse wheel support in Beta 3. By default it scrolls one line at a time or one screen at a time while holding Ctrl. You can remap it to whatever you like with the new "set mouse wheel" command which works much like the existing "set mouse button" command - can map wheel scroll events to any keyboard verb, etc.

Xterm-compatible mouse event reporting will be in the next Beta. There is one new command that controls it all: "set mouse reporting {disabled, enabled, override}".

Mouse reporting allows applications on the remote host to request mouse events using one of four protocols:

  1. the old X10 protocol
  2. the newer X11/normal protocol from xterm
  3. the SGR protocol
  4. the urxvt protocol
The X10 protocol just sends left, right or middle click events along with the coordinates of the click. The other three protocols send separate events for mouse down and up, support the mouse wheel, and also send which modifiers were held (ctrl, shift, meta) at the time. So in tools like Midnight Commander you can click or double-click on files, mouse through the menus, scroll the selected pane with the mouse wheel, etc:

The default setting is Enabled which will only send mouse events to the remote host when requested if and only if that event is not mapped to some action within C-Kermit. So if you map right-click to paste with "set mouse button 2 none click \Kpaste" then right-clicks won't be sent to the remote application, they'll do \Kpaste as you told it to. If the application needed right-click for something you'd have to map right-click to \Kignore within C-Kermit in order for it to be passed through to the remote host.

The Override setting works slightly differently. As with the Enabled setting, when you're in a shell or another application that doesn't use the mouse all your mouse event mappings in CKW do whatever you've configured them to do. But when an application asks to receive mouse events, *all* mouse events are sent to the application and your mappings within CKW are ignored. So if you mapped right-lick to \Kpaste it would only do that outside of applications that use the mouse.

The New Open-Source Kermit Project hosted by Panix.com