The Kermit 95 SSH Client

SSH was originally added to Kermit 95 because many sites began to refuse Telnet connections (clear-text or secure) and accept only SSH connections. K95 v1.1.21 introduced SSH v1 and v2 clients based on OpenSSH 3.0.2p1, and Kermit 95 version 3.0 switched the implementation to one based on libssh.

K95's SSH client is only available on Windows XP Service Pack 3 or newer due to the development tools required to build libssh and openssl.
K95 can make SSH connections to any host that has a modern SSH 2.0 server. Support for SSHv1 and older SSHv2 ciphers were dropped in K95 v3.0.
As with all Kermit's other features, the SSH client is configurable by the user in every conceivable way (so anybody who doesn't like its defaults or behavior can change them) and it includes built-in key creation and management tools so no external "helper applications" are required.
When needed, the SSH backend can be user-replaceable

The OS/2 version of Kermit 95 does not include an SSH client because the libssh and OpenSSL libraries are not available for Open Watcom, the compiler used to build Kermit 95 for OS/2.

Kermit's SSH connections are configured and controlled by the SSH and SET SSH commands. These are described by HELP SSH and HELP SET SSH (the HELP text is reproduced below).

2. TYPICAL SSH SESSION

[ Top ] [ Contents ] [ Next ] [ Previous ]

At the K-95> prompt, simply type "ssh somehost", where somehost is the IP host name or address of the host you want to connect to or, if your user ID on the destination host is different from your local user ID, "ssh somehost /user:remoteuserid" or "ssh remoteuserid@somehost". You might get some messages or questions about the hostname the first time you make a connection, for example:

  [C:\K95] K-95> ssh xyzcorp.com
  The authenticity of host 'xyzcorp.com' can't be established.
  DSA key fingerprint is 85:f9:8b:cd:23:12:01:d9:cf:7a:12:cf:b5:5d:ab:60.
  Are you sure you want to continue connecting (yes/no)?

but that's normal for any SSH client. Unless you have reason to believe the host is an imposter, say "yes" (more about this in the next section). Now K95 asks you for your password, you type it into the box, K95 sends it over the encrypted connection, and off you go.

From this point, an SSH session is like any other K95 terminal session. You can escape back to the prompt with Alt-X, return to the terminal screen with C or Alt-X, transfer files, whatever you want. When you log out from the host, K95 should pop back to its command screen automatically, but that depends on the SSH server.

A single instance of K95 presently can not manage multiple terminal sessions, SSH, Telnet, modem, or otherwise, but of course you can run multiple instances of K95. You can, however, have an FTP session and/or an HTTP session at the same time as a terminal session in a single K95 instance.

3. SSH AUTHENTICATION OPTIONS

[ Top ] [ Contents ] [ Next ] [ Previous ]

SECTION CONTENTS

  3.1. Host Authentication
  3.2. User Authentication

SSH provides security by encrypting the session. SSH can work in the absence of authentication, but it also offers several options for authentication.

3.1. Host Authentication

There are two sides to authentication:

Is the host what it claims to be?
Is the user who they claim to be?

In its simplest form, SSH lets the user make encrypted connections without setting up any kind of keys or other special authentication procedures or files, and all the host administrator has to do is install the ssh server and generate host keys. No alteration of the host login system is required. This is why SSH is so popular compared to authentication methods that are more secure and manageable: it's easy to get started. However, this kind of SSH connection does not authenticate the host to the client.

The most important command to know about before you try to make an SSH connection is SET SSH STRICT-HOST-KEY-CHECK. The values are ON, OFF, and ASK.

ON means K95 won't make an SSH connection to a host whose public key is not in its known-hosts file.
OFF means K95 will connect to any SSH host.
ASK means K95 will ask you if it's OK to connect to a host whose key is not in its known-hosts file. This is the default.

There are two known-hosts files. A user file is stored in the \v(appdata)ssh directory and is automatically updated based upon the connections you make. The system-wide known-host file is (optionally) stored in the \v(common)ssh directory for the operating system and is never updated by Kermit 95. It is there to be maintained by the system administrator.

Your global known-hosts files are kept in a directory common to all users:

  \v(common)ssh\known_hosts2

and your user-specific (and K95-specific) known-hosts files are:

  \v(appdata)ssh\known_hosts2

(\v(appdata) is Kermit's User Application Data Directory variable. The user's application data directory is located in a system dependent manner. Windows 95/98/98SE/ME/NT store the application data with the user's profile. Windows 2000/XP store the application data in the Documents and Settings directory, and later Windows releases use the Users directory. Tell K95 to "show var appdata" to see its definition.) Thus, on Windows XP these files are in the SSH subdirectory of your Windows APPDATA directory, e.g.:

  c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts2

And on Windows 11:

  C:\Users\username\AppData\Roaming\Kermit 95\ssh\known_hosts2

(\v(common) is Kermit's Common Data Directory variable. The common data directory is located in a system dependent manner. Windows 95/98/98SE/ME/NT store the common application data in the WINDOWS directory. Windows 2000/XP stores the application data in the Documents and Settings\All Users directory. Later windows releases use ProgramData. Tell K95 to "show var common" to see its definition.)

Each file contains a series of (long) "lines", one per host, each line containing the hostname and aliases and then the key in Base 64; this is the host's public key. Adding a host key means appending such a line to the appropriate file.

SSH STRICT-HOST-KEY-CHECK ON gives you some assurrance that the host you have connected to is the one you meant to connect to. But it also means your first connection to a particular host is likely to be refused. It's the classic chicken-and-egg situation. You're supposed to get host keys from a trusted source such as a disk or CDROM from your host administrators, but if you didn't, how do you get a key when it's on the very host you can't connect to because you don't have its key? The possibilities include:

You can make some other kind of trusted connection to it (e.g. with Kerberos 5 Telnet) and download the key, or:
You can tell K95 to:
```
  SET SSH STRICT-HOST-KEY-CHECK OFF (or ASK)
```
and then make an SSH connection to the host, authenticate with your password, and then the host key is automatically retrieved and added to your known-hosts file, and then future connections to that host can be made with SSH STRICT-HOST-KEY-CHECK ON. But of course since you have bypassed the host authentication process to obtain the key, future authentication using this key is worthless and you might as well not have have bothered if it turns out the host you connected to was not the one you were meant to.

You might wonder if keeping host keys is a good idea. The advantage is the protection they offer against man-in-the-middle attacks and DNS spoofing (but not compromised hosts). The disadvantage is that anybody who can access your host keys (legitimately or not) knows which hosts you access, which in itself might be information you'd rather not reveal, but also tells hackers which hosts to attack in your name. As noted, Kermit 95 (like all other SSH clients) appends new host keys to your user host-key file(s). You can delete these files if you wish; for example, in your K95 ON_EXIT macro definition.

3.2. User Authentication

Independent of how the host is authenticated to K95, is the method by which K95 authenticates you to the host:

Password
Public/Private Key Pair
GSSAPI (Kerberos)
Keyboard-Interactive

The method of client authentication depends on both the configuration of the server (it might not be configured to allow password authentication, especially for privileged accounts), and the order in which Kermit 95 is configured to attempt authentication methods. Which method is used is ultimately up to the server, but for Servers that accept multiple methods Kermit 95 can be configured to try them in a partiular order. By default, this is: GSSAPI, Public/Private Key pair, Keyboard-Interactive, Password.

Password authentication involves Kermit 95 prompting you for your password, then transmitting it (encrypted) to the remote host. This may be disabled by server configuration for privileged (or all) accounts to prevent brute-force attacks, especially on hosts exposed to the public internet.

You can also use public/private key pairs to authenticate. This has a few advantages over password authentication:

No secrets (password or private key) are transmitted to the server, so a compromised server or man-in-the-middle attack can't obtain your credentials
Brute-force attacks against the server can't discover your credentials
With a suitable SSH Agent, the private key can be stored on a hardware authentication device (SmartCard or USB token such as a YubiKey) making it much more difficult to steal

The primary down-side is that your private key is normally stored on your hard disk where anyone with access to your computer can get it. If someone manages to steal your private key, then it provides no better security than a regular password provided you encrypted your private key with a string passphrase. If you don't encrypt your private key, then anyone who manages steal a copy of it from your computer will be able to log in as you, no password required.

To use public/private key pairs you must have each host's public key in your PC's \v(APPDATA)\ssh\known_hosts2 file, and you must also upload your own public key to each host and put it in the appropriate place, such as ~/.ssh/authorized_keys when OpenSSH is the daemon. When all the right files and keys are in the right places in the appropriate formats, when you log in you'll be prompted for your private key passphrase (if you set one for your private key) and then login using your public/private key pair. In order to determine the correct type of key to use you must know the configuration of the SSH daemon. If you are not the host administrator, contact the appropriate administrator for assistance. (A common error is to leave the permissions on the ~/.ssh/ directory and the files it contains world or group accessible. SSH daemons refuse to use identity files that are accessible to anyone other than the account owner.

Here's an example. I have a guest ID on a Linux machine at a remote site. If I want to be able to connect using public key authentication, then (1) my end is already done, since K95 added the host's public key to my known_hosts2 file the first time I made an SSH connection to it; but (2) I must add my PC's public key to my:

   
  ~/.ssh/authorized_keys

file on the host. In this case there happened to be no such file. So all I had to do was upload my public key to the host as ~/.ssh/authorized_keys. But which public key? That depends on your SSH server. If at all possible, you should use an ED25519 key as the rest have varying levels of security issues. DSA keys are now deprecated and will be removed in a future release of Kermit 95. The required OpenSSH version for some supported key types is listed below:

  Key Type      Public Key File      OpenSSH Version                    
  ED25519 key   id_ed25519.pub       6.5 or newer (released 2014-01-29)
  ECDSA key     id_ecdsa.pub         5.7 or newer (released 2011-01-24)
  RSA key       id_rsa.pub
  DSA key       id_dsa.pub           7.0 or older

For other SSH servers, you'll have to look up the specifications of the SSH server software in use, or try them one after another until you find one that works.

For GSSAPI authentication to work you need MIT Kerberos for Windows (available here) installed and configured on your PC, and the SSH server you're connecting to must also have Kerberos configured. If everything is set up correctly you should be able to log in automatically with no password required thanks to Kerberos single sign-on.

Keyboard Interactive authentication is entirely up to the server. The server sends one or more prompts to Kermit 95 to have you fill out. These prompts could be for almost anything, but usually it's just a single prompt for your password (equivalent to regular password authentication), or two prompts - one for your password and one for a two-factor authentication token.

The complete list of K95's SSH v2 authentication methods is:

gssapi: Kerberos 5 identity (MIT Kerberos for Windows to be installed on your machine, Kerberos 5 to be installed at the host site and an SSH server that can authenticate your K5 identity).
keyboard-interactive: Kermit prompts you locally for authentication information such as host password or anything else the host might require. The host may ask Kermit to prompt for multiple values such as a password and a two-factor authentication token.
password: Kermit prompts you locally for a single host password.
publickey: Public/private key-pair exchange.

4. KNOWN BUGS

[ Top ] [ Contents ] [ Next ] [ Previous ]

The result of "ssh hostname /command:{any command ...}" might be truncated.
"show ssh" doesn't pause at the end of each screen, and it only shows your SET SSH (or default) values, not the current or negotiated ones.
Sometimes when you log out from a host and K95 returns to its command screen, it prints the "Connection Closed" message and the prompt in the wrong order:
```
  [C:\K95\] K-95> Connection to blah closed.
```

5. THINGS TO WATCH OUT FOR

[ Top ] [ Contents ] [ Next ] [ Previous ]

Stairsteps. SSH servers on some Unix systems (usually old ones but reportedly also some new ones too) do not translate LF to CRLF, so lines come out on your screen in stairstep fashion. You can usually fix this by giving an "stty sane" command at the Unix host prompt, or by telling Kermit to "set terminal newline on". Other SSH clients behave exactly the same way with the same hosts.
Some SSH servers do not break the connection when you log out. If you log out but Kermit stays in its terminal screen, use Alt-u to disconnect. (The same thing happens with other SSH clients.)

6. NOT IMPLEMENTED YET

[ Top ] [ Contents ] [ Next ] [ Previous ]

Support for managing keys in the SSH Agent (SSH AGENT ADD, SSH AGENT DELETE, SSH AGENT LIST)
Dynamic (SOCKS) port forwarding (SET SSH DYNAMIC-FORWARDING)
SSH through HTTP and SOCKS proxy servers
The SET TCP commands do not currently affect SSH connections
xauth is not currently run for X11 forwarding (SET SSH XAUTH-LOCATION)
The following SET SSH commands from K95 2.1.3 are unimplemented:
- SET SSH CHECK-HOST-IP
- SET SSH GATEWAY-PORTS
- SET SSH PRIVILEGED-PORT
- SET SSH QUIET
- SET SSH V2 AUTO-REKEY
Telnet through SSH port forwarding.
Incoming SSH.
Integration of HTTP, RDNS, DNS SRV, etc.
SHOW SSH shows only settings, not details about current connection.

7. COMMANDS FOR SSH

[ Top ] [ Contents ] [ Next ] [ Previous ]

SECTION CONTENTS

  7.1. The SSH Command
  7.2. The SET SSH Command
  7.3. The SKERMIT Command

The remainder of this document lists K95's SSH-related commands. You can also find most of this information with K95's HELP commmand (HELP SSH, HELP SET SSH, etc). Notation:

BOLD: A keyword, to be typed literally. Keywords can be abbreviated to any length that does not clash with any other keyword that can appear in the same place.
Italics: A parameter, for which you would substitute an actual value.
{ thing1, thing2, ... }: A comma-separated list inside italicized braces indicates a choice: pick one of the items.
[ anything ]: Anything within italicized square brackets is optional.

Many of these commands have counterparts in the SSH Settings dialog in the Dialer.

7.1. The SSH Command

Syntax: SSH { ADD, AGENT, CLEAR, KEY, [ OPEN ], V2 } operands...: Performs the SSH-related action specified by the keyword.

Let's look at the most important and most commonly used SSH command first:

SSH [ OPEN ] host [ port ] [ /COMMAND:command /USER:username /PASSWORD:passwd /SUBSYSTEM:name /X11-FORWARDING:{ON,OFF} ]

This command establishes a new connection using SSH. The connection is made to the specified host on the SSH port (you can override the port by including a port name or number after the host name). Once the connection is established the authentication negotiations begin. If the authentication is accepted, the local and remote port forwarding lists (if any) are used to establish the desired connection(s) and if X11 Forwarding is active, this results in a remote port forwarding between the X11 clients on the remote host and X11 Server on the local machine. If a /COMMAND is provided, the command is executed on the remote host in place of your default shell.

Approximate Synonym: SET HOST /NETWORK:SSH. This is exactly like SSH OPEN, except it does not enter the Terminal screen (unless you include the /CONNECT switch). This allows SSH connections to be made in scripts, in which interactions with the host are to be automated. To see how to set up an SSH-based Kermit file-transfer and -management service (similar to SFTP but with greater flexibility, functionality, friendliness, and scriptability), CLICK HERE.

If your username on the host is not the same as K95's \v(userid) value, you must include the /USER: switch to specify the username on the host, or alternatively you can supply your username as part of the host (username@host). You can find out K95's \(userid) value by typing SHOW VAR USERID at the K95 prompt. You can set this variable globally with the SET LOGIN USERID command, in which case it is used for all future network logins until you EXIT from K95. The /USER: switch, on the other hand, applies only to the command with which it is given, and leaves the global USERID setting alone.

Here are the rest of the SSH commands in alphabetical order:

SSH ADD LOCAL-PORT-FORWARD local-port host port

Adds a port forwarding triplet to the local port forwarding list. The triplet specifies a local port to be forwarded and the hostname / ip-address and port number to which the port should be forwarded from the remote host. Port forwarding is activated at connection establishment and continues until the connection is terminated.

SSH ADD REMOTE-PORT-FORWARD remote-port host port

Adds a port forwarding triplet to the remote port forwarding list. The triplet specifies a remote port to be forwarded and the hostname/ip-address and port number to which the port should be forwarded from the local machine. Port forwarding is activated at connection establishment and continues until the connection is terminated.

SSH AGENT ADD [ identity-file ]

Adds the contents of the identity-file (if any) to the SSH AGENT private key cache. If no identity-file is specified, all files specified with SET SSH IDENTITY-FILE are added to the cache.

SSH AGENT DELETE [ identity-file ]

Deletes the contents of the identity-file (if any) from the SSH AGENT private key cache. If no identity-file is specified, all files specified with SET SSH IDENTITY-FILE are deleted from the cache.

SSH AGENT LIST [ /FINGERPRINT ]

Lists the contents of the SSH AGENT private key cache. If /FINGERPRINT is specified, the fingerprint of the private keys are displayed instead of the keys.

SSH CLEAR LOCAL-PORT-FORWARD

Clears the local port forwarding list.

SSH CLEAR REMOTE-PORT-FORWARD

Clears the remote port forwarding list.

SSH KEY Commands:

The SSH KEY commands create and manage public and private key pairs (identities). There are four forms of SSH keys. Each key is stored in its own file:

   Key Type      Private Key File          Public Key File           
   RSA keys      \v(appdata)ssh/id_rsa     \v(appdata)ssh/id_rsa.pub
   DSA keys      \v(appdata)ssh/id_dsa     \v(appdata)ssh/id_dsa.pub
   ECDSA Keys    \v(appdata)ssh/id_ecdsa   \v(appdata)ssh/id_ecdsa.pub
   ED25519 Keys  \v(appdata)ssh/id_ed25519 \v(appdata)ssh/id_ed25519.pub

Keys are stored using the OpenSSH keyfile format. The private key files can be (optionally) protected by specifying a passphrase. A passphrase is a longer version of a password. English text provides no more than 2 bits of key data per character. 56-bit keys can be broken by a brute force attack in approximately 24 hours. When used, private key files should therefore be protected by a passphrase of at least 40 characters (about 80 bits).

SSH KEY CHANGE-PASSPHRASE [ /NEW-PASSPHRASE:passphrase OLD-PASSPHRASE:passphrase ] filename

This re-encrypts the specified private key file with a new passphrase. The old passphrase is required. If the passphrases (and filename) are not provided Kermit prompts your for them.

SSH KEY CREATE [ /BITS:bits /PASSPHRASE:passphrase /TYPE:{DSS,RSA,ECDSA,ED25519} ] filename

This command creates a new private/public key pair. The defaults are: BITS:0 and TYPE:ED25519. The filename is the name of the private key file. The public key is created with the same name with .pub appended to it. If a filename is not specified Kermit prompts you for it.

The number of bits allowed depends on the key type. For ED25519, this setting is not relevant so is always 0. DSS can have either 1024 or 2048 bits (default 1024). RSA supports 1024, 2048, 3072, and 4096 or 82192 (default 3072). ECDSA supports 256, 384 or 521 (default 256).

ED25519 is the most modern and secure of the key types supported and should be used whenever the host supports it (most should at this point, as it has been around since the mid-2000s).

SSH KEY DISPLAY [ /FORMAT:{FINGERPRINT,OPENSSH,SSH.COM} ] filename

This command displays the contents of a public or private key file. The default format is OPENSSH.

SSH LOAD dll-name

New in Kermit 95 3.0: This command is only available when no SSH backend DLL was loaded on startup, either due to there being no compatible DLL available or due to the loading of optional network libraries being disabled via command line parameter.

This command takes one or more DLL filenames separated by a semicolon (;) which will attempted in order. The first DLL that loads successfully will enable all SSH commands and be used for all SSH operations until Kermit is restarted. When a DLL loads successfully, the SSH LOAD command becomes unavailable.

On some platforms, Kermit 95 might not have this command either because there exists only one compatible SSH backend and its built-in to the .exe file, or because no compatible backend exists for that platform whether built in or in DLL form.

SSH REMOVE LOCAL-PORT-FORWARD local-port

New in Kermit 95 3.0: this command removes a single local port forward, specified by the local port number. This does not have any effect on an active SSH session.

SSH REMOVE REMOTE-PORT-FORWARD remote-port

New in Kermit 95 3.0: this command removes a single remote port forward, specified by the remote port number. This does not have any effect on an active SSH session.

7.2. The SET SSH Command

SET SSH AGENT-FORWARDING { ON, OFF }

If an authentication agent is in use, setting this value to ON results in the connection to the agent being forwarded to the remote computer. The default is OFF.

SET SSH AGENT-LOCATION location

Specifies AF_UNIX socket Kermit 95 should use to connect to your SSH Agent for public key authentication.

SET SSH COMPRESSION { ON, OFF }

Specifies whether compression will be used. The default is ON.

SET SSH DIRECTORY directory

New in Kermit 94 3.0: Specifies where Kermit 95 should look for the user known hosts file and identity files. By default this is \v(appdata)ssh, but you may like to set it to \v(home).ssh in order to share files with the version of OpenSSH shipped with modern versions of Windows.

This setting also affects the default name of the user known hosts file. When this setting is unchanged from its default, the default user known hosts filename is known_hosts2 (\v(appdata)ssh/known_hosts2) for compatibility with previous versions of Kermit 95. If you set a different SSH directory (or even the same SSH directory) with the SET SSH DIRECTORY command, then the default user known hosts file will be known_hosts (eg, \v(home).ssh/known_hosts) for compatibility with OpenSSH and other clients.

SET SSH GSSAPI DELEGATE-CREDENTIALS { ON, OFF }

Specifies whether Kermit should delegate GSSAPI credentials to the remote host after authentication. Delegating credentials allows the credentials to be used from the remote host. The default is OFF.

SET SSH IDENTITY-FILE filename [ filename [ ... ] ]

Specifies one or more files from which the user's authorization identities (private keys) are to be read when using public key authorization. These are files used in addition to the default files:

  RSA:     \v(appdata)ssh/id_rsa
  DSA:     \v(appdata)ssh/id_dsa
  ECDSA:   \v(appdata)ssh/id_ecdsa
  ED25519: \v(appdata)ssh/id_ed25519

SET SSH STRICT-HOST-KEY-CHECK { ASK, ON, OFF }

Specifies how Kermit should behave if the host key check fails. When strict host key checking is OFF, the new host key is added to the user-known-hosts-file. When strict host key checking is ON, the new host key is refused and the connection is dropped. When set to ASK, Kermit prompt you to say whether the new host key should be accepted. The default is ASK. Strict host key checking protects you against Trojan horse attacks. It depends on you to maintain the contents of the known-hosts-file with current host keys.

SET SSH USE-OPENSSH-CONFIG { ON, OFF }

Specifies whether Kermit should parse an OpenSSH configuration file after applying Kermit's SET SSH commands. The configuration file would be located at \v(appdata)ssh/ssh_config. The default is OFF.

SET SSH V2 AUTHENTICATION { GSSAPI, KEYBOARD-INTERACTIVE, PASSWORD, PUBKEY } [ ... ]

Specifies an ordered list of SSH authentication methods to be used when connecting to the remote host. The default list is:

  gssapi publickey keyboard-interactive password

SET SSH V2 CIPHERS { 3DES-CBC, AES128-CBC, AES192-CBC, AES256-CBC, AES128-CTR, AES192-CTR, AES256-CTR, AES128-GCM@OPENSSH.COM, AES256-GCM@OPENSSH.COM, CHACHAE20-POLY1305 }

Specifies an ordered list of SSH ciphers to be used to encrypt the established connection. The default list is:

  aes256-gcm@openssh.com aes128-gcm@openssh.com aes256-ctr aes192-ctr
  aes128-ctr aes256-cbc aes192-cbc aes128-cbc 3des-cbc

SET SSH V2 GLOBAL-KNOWN-HOSTS-FILE filename

Specifies the location of the system-wide known-hosts file. The default location depends on the operating system:

  \v(common)ssh\ssh_known_hosts2

SET SSH V2 HOSTKEY-ALGORITHMS { ECDSA-SHA2-NISTP256, ECDSA-SHA2-NISTP384, ECDSA-SHA2-NISTP521, RSA-SHA2-256, RSA-SHA2-512, SSH-DSS, SSH-ED25519, SSH-RSA }

Specifies an ordered list of hostkey algorithms to be used to verify the identity of the host. The default list is

  ssh-ed25519 ecdsa-sha2-nistp521 ecdsa-sha2-nistp384 ecdsa-sha2-nistp256
  rsa-sha2-512 rsa--256 ssh-rsa

SET SSH V2 KEY-EXCHANGE-METHODS { CURVE25519-SHA256, CURVE25519-SHA256@LIBSSH.ORG, DIFFIE-HELLMAN-GROUP1-SHA1, DIFFIE-HELLMAN-GROUP14-SHA1, DIFFIE-HELLMAN-GROUP14-SHA256, DIFFIE-HELLMAN-GROUP16-SHA512, DIFFIE-HELLMAN-GROUP18-SHA512, DIFFIE-HELLMAN-GROUP-EXCHANGE-SHA1, DIFFIE-HELLMAN-GROUP-EXCHANGE-SHA256, ECDH-SHA2-NISTP256, ECDH-SHA2-NISTP384, ECDH-SHA2-NISTP521 }

New in Kermit 95 3.0: Specifies an ordered list of Key Exchange Methods to be used to generate per-connection keys. The default list is:

  curve25519-sha256 curve25519-sha256@libssh.org ecdh-sha2-nistp256
  ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group18-sha512
  diffie-hellman-group16-sha512 diffie-hellman-group-exchange-sha256
  diffie-hellman-group14-sha256 diffie-hellman-group14-sha1
  diffie-hellman-group1-sha1 ext-info-c

SET SSH V2 MACS { HMAC-SHA1, HMAC-SHA1-ETM@OPENSSH.COM, HMAC-SHA2-256, HMAC-SHA2-256-ETM@OPENSSH.COM, HMAC-SHA2-512, HMAC-SHA2-512-ETM@OPENSSH.COM, NONE }

Specifies an ordered list of Message Authentication Code algorithms to be used for integrity protection of the established connection. The default list is:

  hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com
  hmac-sha1-etm@openssh.com hmac-sha2-256 hmac-sha2-512 hmac-sha1

SET SSH V2 USER-KNOWN-HOSTS-FILE filename

Specifies the location of the user-known-hosts file. The default location is:

  \v(appdata)ssh/known_hosts2

SET SSH VERBOSE level

Specifies how many messages should be generated by the LibSSH engine. The level can range from 0 to 7. The default value is 2.

SET SSH X11-FORWARDING { ON, OFF }

Specifies whether X Windows System Data is to be forwarded across the established SSH connection. The default is OFF. When ON, the DISPLAY value is either set using the SET TELNET ENV DISPLAY command or read from the DISPLAY environment variable.

7.3. The SKERMIT Command

SKERMIT [ OPEN ] host [ port ] [/USER:username /PASSWORD:passwd } ]

This is an approximate synonym for:

  SSH OPEN host port /USER:username /PASSWORD:pwd /SUBSYSTEM:kermit

Which opens an SSH connection to the host using the kermit subsystem. This requires kermit to be registered as a subsystem with the remote SSH server. For more details on this, see: https://kermitproject.org/skermit.html

8. LOADABLE SSH SUPPORT

[ Top ] [ Contents ] [ Previous ]

Kermit 95 built for certain combinations of Windows versions or OS/2 may support dynamically loadable SSH backends. Rather than SSH being built-in to Kermit 95, it lives in a DLL that is loaded on startup. This allows multiple different backends to be included with the correct one loaded automatically.

At this time the ability to load different SSH backends is primarily used on x86 and x86-64 versions of Kermit 95 for Windows XP and newer where four backends provided:

  DLL           Description                                                          
  k95ssh.dll    For Windows Vista or newer
  k95sshg.dll   For Windows Vista or newer with MIT Kerberos for Windows installed
  k95sshx.dll   For Windows XP/Server 2003
  k95sshgx.dll  For Windows XP/Server 2003  with MIT Kerberos for Windows installed

If all available SSH backends fail to load when Kermit 95 is started, there are no SSH backends available, or if you instructed Kermit 95 not to load optional network DLLs on startup via command line arguments, you can at any time load an SSH backend using the SSH LOAD command specifying the DLL to load.

This feature, where enabled, also allows 3rd-party SSH backends to be supported. This may be to use a custom build of libssh with different features selected, or an entirely different SSH implementation that allows SSH connections to be made on older Windows releases or IBM OS/2.

[ Top ] [ Contents ] [ K95 Home ] [ Kermit Home ]

K95 SSH Client / The Kermit Project / 27 January 2025