I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
Update: Kermit is going Open Source as of July 1st, 2011.
This is the Windows version of Kermit: http://www.columbia.edu/kermit/k95.html
There are less expensive terminal emulators, but at $64.00 you get tremendous value. Kermit is highly customizable, scriptable, adaptable, robust, flexible.. well, you get the idea. The Swiss Army knife of terminal emulators.
All this power does not come without cost, however. Learning Kermit is not quickly done, and mastering it could take weeks, maybe even longer. Some of the learning curve has been flattened by a new GUI version that at least gets you started quickly, but even that isn't as easy and intuitive as it might be, and there are a few rough spots.
However, I don't think any of the GUI glitches are serious, and because the command line is always instantly available (just hit ALT-X) you can always get what you need. Combining the command line with the GUI (you can, of course just use the command line if you prefer) is the right way to do it: instant connectivity through the GUI, without losing any of the command line's power. Command line access is not something you generally see in any of the competitive products at all - I'm not even aware of any I have used that have this. As you also get very powerful scripting ability, Kermit is hard to beat at any price.
At least at this point, the Kermit GUI probably isn't something you'd hand out to ordinary users as is. There's just too much power there and not enough smoothness. However, as a true geek (or even geek in training) looking to harness this kind of power for your own needs, or to turn over locked down setups to users, this may be just what you need. Yes, there is a lot to learn. The GUI is good enough to get you going immediately and from there you can start learning the more advanced features. And it isn't that far off from being usable by ordinary people; the next version may very well be suitable for that.
What you really need to pay attention to when you first start up the Kermit GUI is the unfortunately named "Dialer" (most would call this the "Connection Manager"). This isn't just for dial-up modems (though that is part of its function). Actually, the dialer is where you define connections, and how you make connections to other machines. It's a separate window from the GUI itself, and although at first I found that odd and a bit unsettling, the idea grew on me and I now think it's the right idea. A separate window lets you manage multiple connections from one place, and keeps all that completely separate from the connection itself.
What you see in the picture above is Kermit 95 running on Windows XP (which is running under Virtual PC on a Mac as it happens). The larger blue window is the K95 GUI itself; the Dialer is the smaller window below it.
The Dialer looks different and has an additional, entirely different help system for its menu and toolbar. That's because it was written in an entirely different development environment. See http://www.columbia.edu/kermit/newdialer.html for an explanation of how this came to be.
Right here is probably a good time to mention that you really should go read the manual before you dive in. You won't of course, and neither did I, but you should. But since you won't, I'll say again that you need to be in the Dialer to start with.
If you've never used Kermit before, you might be tempted to click on "Quick". That's a simple window that asks you to tell it what type of connection (Dialup, TCP/IP, SSH, FTP, LAT), where to go, and to choose something from a "based on" list. Nice idea, but that's not how it works. The only things in the list to start with are Templates, and you can't use them for this. Later, after you have defined a full connection, you can use this "Quick" to quickly connect to a new host. However, unless this really is a one time connection that you will not want again, or unless you are really in a terrible hurry, don't use this because there's no way to save it for future use - it seems to be a throw-away. That's too bad, because both alternatives are much more clumsy to use. I think it would be very nice if "Quick" could use Templates and could save an entry if you want it to.
I've been told that this ability WILL be in version 2.1.4, available soon.
What you have to do now is either make a new connection or clone one. Making a new connection takes you through every possible screen, and that's not a bad thing to do at least once to see what all your choices are, but it's a lot quicker to use "Clone". As you can clone a Template, that's one way to get a fairly speedy first time user connection: Clone one of the templates, and then use "Quick" to make a connection based on that.
Don't put too much importance on the minor clumsiness here. Once you have your most common types of connections created, it's fairly quick to clone one, change the host name and login, and be off and running. You don't even have to come back to the Dialer ever again if you tell it to put a shortcut on your Desktop for the connection. For most of us, we'll set up a few connections that we use every day and hardly ever have to deal with this at all.
Another area of slight clumsiness is editing an existing connection: although creating a new connection brings you through every possible attribute screen, editing an existing connection gives you no choice but to Go back and select the screens individually, one by one. It would be nice to have the same "Next/Cancel" buttons here as are present when adding a new connection. Again, this is an area where the authors are aware improvement is needed. But it isn't horrible as it stands now: you have a drop down menu that allows you to choose the screen you want to go to, and as long as you know where what you want to change is, you can get there quickly. And how often are you likely to be making changes - once you have a particular connection set up, it's probably not going to need tweaking. These little quibbles are minor and will have little or nothing to do with your day to day use of Kermit.
One note on the GUI: in some places, dialog boxes that you would expect to be able to click away with a single click sometimes require a double click. If something seems "stuck", remember that. This is an unfortunate side effect of the laudable effort to make this a cross-platform application.
By the way, the help manual is local to your machine but can also be accessed on-line. It's still HTML locally, which I think is much preferable to Windows style help files. However, that does limit your ability to search, so you'll probably want to use the on-line version when possible: http://www.columbia.edu/kermit/search.html
There's also "Context" help listed in the Help menu. You might expect that would mean that you can highlight a command you are trying to use and jump right to that section, but that's not what it is. What they mean by "context" is whether you are in command mode or in the emulator: choosing context help brings up appropriate keys that you can use in the mode you are presently in.
Another menu choice that may not be immediately obvious is "Locus". The manual explains it:
Locus refers to the target of file management commands when Kermit has a connection to a server on another computer. Historically, commands such as CD, DIRECTORY, DELETE, RENAME, and MKDIR have always acted locally in all Kermit programs. To ask a remote server to do these things required a REMOTE or "R" prefix: e.g. REMOTE CD or RCD. When the FTP client was added to Kermit in 2002, this behavior seemed unnatural to users of text-mode FTP clients. Thus the notion of Locus was introduced: Local means that unprefixed file management commands are executed on the local computer; Remote means they are sent to the remote FTP or Kermit server for execution. By default, Kermit switches Locus automatically every time you make or break a connection, depending on what kind of connection it is. When you make an FTP connection, Kermit switches its Locus to Remote. When you make any other kind of connection, or when you break any connection, its Locus switches back to Local.
It's unlikely that you will need anything that you won't find here. If you did run across something unusual, you have complete control of what keys send and mean. You can redefine function keys, change behavior: whatever you need to do. Only some of that is available from the GUI menus; you will need to drop to command mode for complete control. But that is COMPLETE control - while you may need more knowledge of the host machine to have the necessary information, if you do have it, you can mold Kermit to whatever it is you need. That's power.
It's important to mention that Kermit supports Unicode. Kermit has extensive support for character sets and the ability to convert among them. Take a look at http://www.columbia.edu/kermit/glass2.gif
The initial creation of a connection (from the Dialer) leads you through fourteen screens that let you define just about anything you could ever imagine, but one sometimes useful feature is missing: at some sites, I want to prevent users from just closing their terminal window without properly exiting their session. That's a feature other terminal emulators have added in recent years. Kermit does have a menu setting that can ASK you if you really want to disconnect, but I'd like that "X" button disabled entirely. Interestingly, this version does support creating connections that are locked down with no menu or tool bar, which is a very nice feature. If they would also turn off the ability to close the Window while connected, that would cover everything.
But everything else is there: screen colors, font sizes, authentication methods, logins, the download directory, linewrap, scrollback size, how to handle file name collisions, environment variables, tcp buffer sizes, socks and proxy servers, key maps, printer control (even conversion to Postscript) and of course complete logging.
You'll undoubtedly notice that both "scp" and "sftp" are conspicuously missing. The authors of Kermit explain why at http://www.columbia.edu/kermit/skermit.html, but I personally think they need to lower their standards and go with the accepted protocols. I am not going to stop using scp both because I like it and because I may not have the desire or even the permission to install Kermit on the hosts I need to work with. For many years prior to this release the Kermit authors had a similar attitude toward ssh; they didn't see the need for it in Kermit. I thought they were dead wrong then, and I think they are just as wrong about this. They do say that they intend to add these features in spite of their dislike for them.
Their reasons for preferring Kermit as a transfer protocol go way beyond the obvious fact that it's their baby. Here is some of what they have to say:
Their concerns about SSH in general are mostly arguments concerning compromised keys. A very good article about Windows security in general talks about this: http://www.columbia.edu/kermit/safe.html and it's worth reading for any Windows user anyway.
Another useful link is their comparison of ssh clients: http://www.columbia.edu/kermit/winsshclients.html
One omission from the GUI Windows version is the ability to upload files from a terminal session. You don't get a GUI menu choice that would let you pick a file and choose your method (zmodem, kermit, etc). However, you can simply do ALT-X and use SEND from the Kermit command prompt. Or, if the Unix host is running Kermit, use "kermit -s file". In either case, that may be all you need to do. Downloads and uploads can be completely automatic: for example, I did "sz file" while logged into a Unix host and Kermit automatically received it. When I did a SEND from the ALT-X prompt, the Unix host happily recieved it without any intervention on my part also. Can you live without a GUI pick dialog to upload files? I can, but I do think they need to add this in a future release.
If the receiving computer doesn't have Kermit, you can probably bootstrap it: see http://www.columbia.edu/kermit/gkermit.html#boot
Compatible software is available for Unix (SCO, Linux, BSD, Solaris, etc) from http://www.columbia.edu/kermit/ckermit.html including hundreds of prebuilt binaries that you can download from here: http://www.columbia.edu/kermit/ckbinaries.html
These are the places where you will really appreciate Kermit's power. Forget the GUI for this: this isn't a graphical, drag and drop client and may never be. You can use the Dialer to define an FTP connection, but that's almost (but not quite) useless, since the GUI really doesn't support these to any degree: this isn't a GUI drag and drop for FTP. Perhaps someday they can include a nice GUI file transfer that can use FTP, HTTP, Kermit, Scp and everything else, but that's a big project, and the real value of Kermit in this area is scripting. This is where Kermit shines.
Configuring FTP in the dialer does have value : you can use it to easily set the many possible authentication and encryption options. You could also put a script in the login box, either as immediate commands or to run an external script file.
See http://www.columbia.edu/kermit/ftpscripts.html for some ftp specific scripts, and the Script Library has an incredible array of other scripts that can help you solve all manner of nasty or annoying problems. You really need to look at the manual to appreciate all the power here, but you can also get a good idea just by using "?" at the command prompt:
[C:\Program Files\Kermit 95 2.1\] K-95> ftp mput ? Filename, or switch, one of t he following: /after: /larger-than: /server-character-set: /array: /listfile: /server-rename-to: /as-name: /local-character-set: /simulate /before: /move-to: /smaller-than: /binary /nobackupfiles /tenex /command /not-after: /text /delete /not-before: /transparent /error-action: /quiet /type: /except: /recover /update /filenames: /recursive /unique-server-names /filter: /rename-to:
Full documentation is at http://www.columbia.edu/kermit/ckermit80.html#ftp
Of course Kermit still supports modems. In addition to dial up connections, it can also handle numeric and alphanumeric paging. Remember that this is all scriptable; while you probably wouldn't have much use for interactive paging, scripted paging is an entirely different story.
Kermit can also be a server. This isn't GotoMyPC or PCAnywhere and it's not meant to be. This is to transfer files (there's also a facilty to read and send messages). If you are running NT or XP, you would use WIKSD, which is really just Kermit 95 running as a service, and limited (by design) to file transfer while doing so. Both of these are authenticated access: the would be user has to log in.
Unlike many companies nowadays, Kermit has more than reasonable support. There's no charge for email support ([email protected]), and they usually respond very quickly. Additionally, there is a newsgroup (comp.protocols.kermit.misc) and of course the website : http://www.kermit-project.org/support.html
Some user comments: http://www.columbia.edu/kermit/tsreviews.html
Kermit resisted SSH firmly. You'll find leftover hints of their attitude at their telnetd page ("The Telnet and FTP protocols have options that provide for strong authentication and encryption just as SSH does.").
That's why I was surprised to see ssh support, though it was still obvious that Frank had a bad taste in his mouth about it.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2012-07-12 Tony Lawrence
We're terrible animals. I think that the Earth's immune system is trying to get rid of us, as well it should. (Kurt Vonnegut)