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.
This document does not apply to C-Kermit 8.0 for Unix, which uses the external SSH client as its transport in making SSH connections, as described HERE.
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
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 are not available for OS/2.
Kermit's SSH connections are configured and controlled by the (new) SSH and SET SSH commands. These are described by HELP SSH and HELP SET SSH (the HELP text is reproduced below).
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". 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.
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.
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.
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 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.
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:
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.
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.
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.)
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:
[C:\K95\] K-95> Connection to blah closed.
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:
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:
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).
V1 RSA: \v(appdata)ssh/identity V2 RSA: \v(appdata)ssh/id_rsa V2 DSA: \v(appdata)ssh/id_dsa
Windows 95/98/98SE/ME: %windir%\ssh_known_hosts Windows NT/2000/XP: \v(common)ssh\ssh_known_hosts
\v(appdata)ssh/known_hosts
external-keyx gssapi hostbased publickey srp-gex-sha1 keyboard-interactive password none
aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour aes192-cbc aes256-cbc
Windows 95/98/98SE/ME: %windir%\ssh_known_hostss Windows NT/2000/XP: \v(common)ssh\ssh_known_hosts2
ssh-rsa ssh-dsa
hmac-md5 hmac-sha1 hmac-ripemd160 hmac-sha1-96 hmac-md5-96
\v(appdata)ssh/known_hosts2
[ Top ] [ Contents ] [ K95 Home ] [ Kermit Home ]