The Kermit Project   |   Now hosted by Panix.com
New York City USA   •   kermit@kermitproject.org
…since 1981
Home C-Kermit E-Kermit Kermit 95 Scripts News About FAQ
Translations  (see below for credits):
Belarusian | Беларуская

Kermit 95's built-in SSH Client

IMPORTANT... Kermit 95 does not work with modern SSH servers because they have changed since K95 was last released in 2003. As of 2022, a brand-new open-source release — now called C-Kermit for Windows — is in preparation; see this page for details. The documentation in this page does, however, largely apply to the new release.

Sun Dec 8 11:01:22 2002
Most recent update: Tue Sep 5 19:55:58 2023

Kermit 95 2.0 (and later) for Windows includes Secure Shell (SSH) v1 and v2 clients, an FTP client (which can make secure or regular connections), and an HTTP client (ditto), in addition to the many connection methods and clients it had already. These are built-in, coded by hand like the rest of K95, and not loaded from some external library like, for example, Cygwin.

This document does not apply to C-Kermit for Unix, which uses the external SSH client as its transport in making SSH connections, as described HERE.

CONTENTS

  1. K95 SSH OVERVIEW
  2. TYPICAL SSH SESSION
  3. SSH AUTHENTICATION OPTIONS
     3.1. Host Authentication
     3.2. User Authentication
  4. KNOWN BUGS
  5. THINGS TO WATCH OUT FOR
  6. NOT IMPLEMENTED YET
  7. NEW COMMANDS FOR SSH
     7.1. The SSH Command
     7.2. The SET SSH Command
[ Kermit Home ] [ Kermit 95 ] [ Comparison with Other SSH Clients ]

1. K95 SSH OVERVIEW

[ Top ] [ Contents ] [ Next ]

SSH was added to Kermit 95 because increasingly many sites refuse Telnet (clear-text or secure) and require SSH for virtual terminal connections. As of version 1.1.21, the Windows (not OS/2) version of Kermit 95 includes SSH v1 and v2 clients:

The OS/2 version of Kermit 95 does not include an SSH client because the OpenSSH libraries were not available for OS/2.

Kermit's SSH connections are configured and controlled by its SSH and SET SSH commands. These are described by K95's HELP SSH and HELP SET SSH commands (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 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". 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 (or the illusion of it) by encrypting the session. SSH can work in the absence of authentication, but it also offers several options for authentication, none of them particularly secure except for Kerberos 5 GSSAPI and SRP.

3.1. Host Authentication

There are two sides to authentication:

  1. Is the host what it claims to be?
  2. Is the user who s/he claims 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 and it authenticates the client to the host only through the password file, just like an ordinary insecure login. The only difference is that the session (including the password) is encrypted, which makes hackers do a little extra work to decode their sniffer logs and get your password. The assumption is that hackers won't bother to do this since unencrypted passwords are easier to steal (like cars without steering-wheel locks), but of course this is wishful thinking as hacker tools evolve.

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.

There are two known-hosts files for each protocol version. 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: 

  SSH v1:  \v(common)ssh\known_hosts
  SSH v2:  \v(common)ssh\known_hosts2

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

  SSH v1:  \v(appdata)ssh\known_hosts
  SSH v2:  \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/Vista/etc store the application data in the Documents and Settings 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.: 

  SSH v1:  c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts
  SSH v2:  c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts2

On Windows 98 with multi-user support, this would be: 

  SSH v1:  c:\WINDOWS\Profiles\username\Application Data\Kermit 95\ssh\known_hosts
  SSH v2:  c:\WINDOWS\Profiles\username\Application Data\Kermit 95\ssh\known_hosts2

On Windows 98 without multi-user support, this would be: 

  SSH v1:  c:\WINDOWS\Application Data\Kermit 95\ssh\known_hosts
  SSH v2:  c:\WINDOWS\Application Data\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. 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 (don't use pasting; it's likely to cause spurious line breaks).

SSH STRICT-HOST-KEY-CHECK ON gives you some assurance 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 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; you can even do it automatically 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:

The default method of client authentication (that is, the method that is used unless you have configured K95 to use any of the other methods described below) is by prompting you locally for a password and then sending it (encrypted) to the server. This method requires you to type your password every time you log in (unlike, say, Kerberos 5, which gives you a "single network login").

If you must use SSH to contact a particular host, we recommend simple password authentication. If this is OK with you, skip the rest of this section; otherwise keep reading.

You can also use public/private key pairs, whose purpose is to allow you to log in to the host without typing your password. THIS IS DANGEROUS because your keys are stored on your Windows disk, where they can be stolen (especially easy on Windows 9x/ME PCs that are attached to the network, yet lack any form of file-system security). If your key files are encrypted, they can be decrypted offline. (The longer the passphrase for key-file encryption, the longer it takes to perform dictionary attacks against it; a 40-character character passphrase should be considered a minimum but most people don't use such a long passphrase, so most key files are ripe for plucking.)

Also note that public/private key pairs can be used only if the two computers have static IP names, since the IP host names are are imbedded in the keys themselves. For connections made through DHCP or any other dynamic-IP-name-and-address service, you'll have to use password authentication.

To use public/private key pairs you must have each host's public key in your PC's \v(APPDATA)\ssh\known_hosts (SSH v1) and/or \v(APPDATA)\ssh\known_hosts2 files (SSH v2), and you must also upload your own public key to each host and put it in the appropriate place, such as ~/.ssh/authorized_keys (SSH v1) and/or ~/.ssh/authorized_keys2 (SSH v2) when OpenSSH is the daemon. When all the right files and keys are in the right places in the appropriate formats, you can log in without a password. 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 make an SSH connection to it (logging in with a password), K95's status line shows me the SSH server's level is 2.0. If I want to be able to connect without typing a password, 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_keys2

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_keys2. But which public key? I have three of them (see the SSH KEY CREATE command description below): 

  SSH V1 RSA key:  identity.pub
  SSH V2 DSA key:  id_dsa.pub
  SSH V2 RSA key:  id_rsa.pub

Well, since the server uses SSH v2, I can ignore the identity.pub file, which is only for SSH v1. So I began by uploading my id_dsa.pub file to my ~/.ssh directory, renaming it to authorized_keys2, logging out, and making a new ssh connection to the same host. It let me in without password, so I guessed right the first time. Maybe the id_rsa.pub key would have worked too, who knows -- it probably depends on the server.

But now, of course, anybody who can obtain a copy of the id_dsa private key file from my Windows disk can log in to that host as me, without a password. And it's easy for them to locate the host because it's listed in my known_hosts2 file, along with all the other hosts I connect to with SSH v2. So what have I accomplished? I have pretty much left the keys to all my houses in the street, each key neatly labeled with the address of the house it unlocks.

So having satisfied myself that the key-exchange mechanism works as designed (by the SSH designers, not us), I deleted the authorized_keys2 file from the host and I deleted all the private keys from my Windows disk. Unlike Kerberos identities or X.509 certificates, compromised private keys can't be revoked or even tracked down. And unlike encrypted password authentication, which must be captured in its brief moment of transit, your key files are always available to hackers, and for that matter, to a potentially infinite number of them at once.

Note, by the way, that some SSH hosts do not support public/private key pair authentication at all, so every combination you try will fail. There's no way to know this without the host administrator telling you, or by exhausting all the combinations.

Since public/private key-pair authentication is unsafe, K95 also supports two secure authentication methods for SSH v2 that do do not require public/private key pairs:

Of course, secure authentication for SSH clients requires modified SSH servers, which are available. GSSAPI does not require host keys at all since Kerberos authentication is mutual.

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

external-keyx
Use the authentication performed as a side-effect of an key exchange algorithm such as GSSAPI.

gssapi
Kerberos 5 identity (requires Kerberos 5 to be installed at the host site and an SSH server that can authenticate your K5 identity).

hostbased
Like Rlogin (.rhosts file, not secure)

keyboard-interactive
Kermit prompts you locally for authentication info such as host password (or anything else the host might require).

password
Kermit prompts you locally for a single host password.

publickey
Public/private key-pair exchange (supported but not recommended, and not supported by Columbia's SSH servers).

srp-gex-sha1
Secure Remote Password (SRP, secure; requires an SSH server on the host that performs SRP authentication).

4. KNOWN BUGS

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

5. THINGS TO WATCH OUT FOR

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

6. NOT IMPLEMENTED YET

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

7. COMMANDS FOR SSH

[ Top ] [ Contents ] [ Previous ]

SECTION CONTENTS 

  7.1. The SSH Command
  7.2. The SET SSH Command

The remainder of this document lists K95's new 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.
Some of these commands have counterparts in the SSH Settings dialog in the new Dialer.

7.1. The SSH Command

An ssh-agent.exe program is supplied in K95's program directory. If you run it, it acts as an SSH agent program for other applications on your PC, such as Kermit 95.
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 /VERSION:{1,2} /SUBSYSTEM:name /X11-FORWARDING:{ON,OFF} ]
This command establishes a new connection using SSH version 1 or version 2 protocol. 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. 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 three forms of SSH keys. Each key is stored in its own file:

Key Type Private Key File Public Key File
v1 RSA keys \v(appdata)ssh/identity \v(appdata)ssh/identity.pub
v2 RSA keys \v(appdata)ssh/id_rsa \v(appdata)ssh/id_rsa.pub
v2 DSA keys \v(appdata)ssh/id_dsa \v(appdata)ssh/id_dsa.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:{V1-RSA,V2-DSA,V2-RSA} /V1-RSA-COMMENT:comment ] filename
This command creates a new private/public key pair. The defaults are: BITS:1024 and TYPE:V2-RSA. 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. V1 RSA key files may have an optional comment, which is ignored for other key types.

SSH KEY DISPLAY [ /FORMAT:{FINGERPRINT,IETF,OPENSSH,SSH.COM} ] filename
This command displays the contents of a public or private key file. The default format is OPENSSH.

SSH KEY V1 SET-COMMENT filename comment
This command replaces the comment associated with a V1 RSA key file.

SSH V2 REKEY
Requests that an existing SSH V2 connection generate new session keys.

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 CHECK-HOST-IP { ON, OFF }
Specifies whether the remote host's ip-address should be checked against the matching host key in the known_hosts file. This can be used to determine if the host key changed as a result of DNS spoofing. The default is ON.

SET SSH COMPRESSION { ON, OFF }
Specifies whether compression will be used. The default is ON.

SET SSH DYNAMIC-FORWARDING { ON, OFF }
Specifies whether Kermit is to act as a SOCKS4 service on port 1080 when connected to a remote host via SSH. When Kermit acts as a SOCKS4 service, it accepts connection requests and forwards the connections through the remote host. The default is OFF.

SET SSH GATEWAY-PORTS { ON, OFF }
Specifies whether Kermit should act as a gateway for forwarded connections received from the remote host. The default is OFF.

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: 

  V1 RSA:  \v(appdata)ssh/identity
  V2 RSA:  \v(appdata)ssh/id_rsa
  V2 DSA:  \v(appdata)ssh/id_dsa

SET SSH KERBEROS4 TGT-PASSING { ON, OFF }
Specifies whether Kermit should forward Kerberos 4 TGTs to the host. The default is OFF.

SET SSH KERBEROS5 TGT-PASSING { ON, OFF }
Specifies whether Kermit should forward Kerberos 5 TGTs to to the host. The default is OFF.

SET SSH PRIVILEGED-PORT { ON, OFF }
Specifies whether a privileged port (less than 1024) should be used when connecting to the host. Privileged ports are not required except when using SSH V1 with Rhosts or RhostsRSA authorization. The default is OFF.

SET SSH QUIET { ON, OFF }
Specifies whether all messages generated in conjunction with SSH protocols should be suppressed. The default is OFF.

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 protocol-version-specific 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 V1 CIPHER { 3DES, BLOWFISH, DES }
Specifies which cipher should be used to protect SSH version 1 connections. The default is 3DES.

SET SSH V1 GLOBAL-KNOWN-HOSTS-FILE filename
Specifies the location of the system-wide known-hosts file. The default location depends on the operating system:

Operating System File
Windows 95/98/98SE/ME %windir%\ssh_known_hosts
Windows NT/2000/XP/Vista/7/etc \v(common)ssh\ssh_known_hosts

SET SSH V1 USER-KNOWN-HOSTS-FILE filename
Specifies the location of the user-known-hosts-file. The default location is: 

  \v(appdata)ssh/known_hosts

SET SSH V2 AUTHENTICATION { EXTERNAL-KEYX, GSSAPI, HOSTBASED, KEYBOARD-INTERACTIVE, PASSWORD, PUBKEY, SRP-GEX-SHA1 } [ ... ]
Specifies an ordered list of SSH version 2 authentication methods to be used when connecting to the remote host. The default list is: 

  external-keyx gssapi hostbased publickey srp-gex-sha1 
  keyboard-interactive password none

SET SSH V2 CIPHERS { 3DES-CBC, AES128-CBC, AES192-CBC, AES256-CBC, ARCFOUR, BLOWFISH-CBC, CAST128-CBC, RIJNDAEL128-CBC, RIJNDAEL192-CBC, RIJNDAEL256-CBC }
Specifies an ordered list of SSH version ciphers to be used to encrypt the established connection. "Rijndael" is an alias for "aes". The default list is: 

  aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour aes192-cbc aes256-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: 

  Windows 95/98/98SE/ME: %windir%\ssh_known_hostss
  Windows NT/2000/XP:    \v(common)ssh\ssh_known_hosts2

SET SSH V2 HOSTKEY-ALGORITHMS { SSH-DSA, SSH-RSA }
Specifies an ordered list of hostkey algorithms to be used to verify the identity of the host. The default list is: 

  ssh-rsa ssh-dsa

SET SSH V2 MACS { HMAC-MD5 HMAC-MD5-96 HMAC-RIPEMD160 HMAC-SHA1 HMAC-SHA1-96 }
Specifies an ordered list of Message Authentication Code algorithms to be used for integrity protection of the established connection. The default list is: 

  hmac-md5 hmac-sha1 hmac-ripemd160 hmac-sha1-96 hmac-md5-96

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 OpenSSH engine. The level can range from 0 to 7. The default value is 2.

SET SSH VERSION { 1, 2, AUTOMATIC }
Specifies which SSH version should be negotiated. The default is AUTOMATIC which means use version 2 if supported; otherwise to fall back to version 1.

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.

SET SSH XAUTH-LOCATION filename
Specifies the location of the xauth executable (if provided with the X11 Server software.)

[ ў Беларускім ] [ Top ] [ Contents ] [ K95 Home ] [ Kermit Home ]

K95 SSH Client / The Kermit Project / Columbia University / kermit@kermitproject.org / 8 Dec 2002 / 9 May 2022