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)

The first two files 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 somehost {                     # (put the actual host name here)
    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.

"somehost" 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 somehost 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

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; 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.

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 in Windows 10 and 11). Or in CKW, just give the command "run start powershell".
2. Tell Powershell to go to your top-level directory: "cd C:\Users\username".
3. Give the command "dir .ssh" to find out if SSH has already been configured on your PC. If it hasn't you'll get a big error message. If it has you'll see something like the following and you (probably) won't have to do anything more on Windows end (proceed to Part B):

   Directory: C:\Users\username\.ssh
   
   Mode                 LastWriteTime         Length Name
   ----                 -------------         ------ ----
   -a----         9/20/2022   7:58 AM           1369 id_dsa
   -a----         9/20/2022   7:58 AM            600 id_dsa.pub
   -a----         8/25/2022   7:18 PM           2590 id_rsa
   -a----         8/25/2022   7:18 PM            564 id_rsa.pub
   -a----        12/13/2022   6:37 AM           4288 known_hosts
   

4. If there is no .ssh directory, give Powershell the command:

     ssh-keygen
   

   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.

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". And if THAT didn't work, cd to your home directory and then "mkdir .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. Start Kermit on the host. 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 name of the public-key file; example:
4. Give the following shell commands, which fetch your public key into the host's .ssh subdirectory of your login directory:

   cd ~/.ssh
   kermit -g id_rsa.pub
   

5. The upload should happen automatically and take just a second or two. 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 you can remove the id_rsa.pub file (not strictly necessary):

     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:

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.

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 the procedure again but substitute "ed25519" everywhere you see "rsa". See a discussion HERE or search Google for "rsa versus ed25519" (without the quotes).

Further reading:
https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement

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:

   cd
   chmod 700 .ssh
   

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

   cd .ssh
   chmod 600 *
   

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