evaluate the best SSH client (was: Print in PuTTy)

byrapaneni(*)gmail.com wrote:
|
| I came across ( FREE licence) TeraTerm Pro Web 3.1.3 - Enhanced
| Telnet/SSH2 Client at http://www.ayera.com/teraterm/. This Telnet has
| the print functionality built in. I also found 'Absolute Telnet' on
| http://www.celestialsoftware.net/ for $19.00 a piece when you buy 10
| or more.
|
| Could someone please post their findings/facts/reviews on these.
| I was [assigned] to a new project to find / [evaluate] the best
| SSH client for our organization.


While it is good that Yutaka Hirata has lately undertaken to enhance
TeraTerm for SSH2, I've tried the January 2005 "UTF-8 TeraTerm Pro"
release and found it unstable (at least under Windows 98SE on my
home machine). But I hope he will keep working on it.

There are many terminal-emulation programs available in the world:
some free, and numerous commercial products. You give no clues
about what kind of organization you belong to, but many enterprises
would be better off with a commercial product where the users can
get technical support by telephone.

In contrast, a free product must give a warning, not a warranty:

The entire risk as to the quality and performance of the
program is with you. Should the program prove defective,
you assume the cost of all necessary servicing, repair, or
correction.

Over the last two years, many vendors of terminal-emulating Telnet
clients have enhanced them to support SSH connectivity; some also
support other secure connection types, notably Kerberos and SSL.

SSH is popular because its administrative overhead is relatively
low, compared to the other secure-connection schemes, however,
this plus can quickly become a minus--there may be no quick way to
revoke a user's access if the access keys become compromised.
(Suppose the president of a business connects to all his accounts
by SSH from his laptop computer, and then the laptop gets stolen
at the airport?)

(Just to complete the picture, security can be provided at a lower
level of the networking stack using IPsec. With IPsec ESP beneath
it, even ordinary Telnet-over-TCP becomes secure.)

Anyway, for your investigation, you should check the following web
page, where I maintain links to nearly all terminal-emulation,
Telnet, and/or SSH client programs.

http://www.cs.utk.edu/~shuford/termi...emulation.html

This is part of my "Video Terminal Information" archive:

http://www.cs.utk.edu/~shuford/terminal_index.html

...RSS

--
Your cow joke might be worth a Frisbee.
http://www.stonyfield.com/weblogarch...op/000651.html

>>>>> "RSS" == Richard S Shuford <shuford@list.stratagy.REM0VE-THlS-PART.com> writes:

RSS> In contrast, a free product must give a warning, not a warranty:

RSS> The entire risk as to the quality and performance of the
RSS> program is with you. Should the program prove defective, you
RSS> assume the cost of all necessary servicing, repair, or
RSS> correction.

Most EULA's on commercial software say essentially the same thing --
disclaiming all warranties except replacing defective media. Support is
certainly a valuable service, but let's not pretend that commercial
software vendors provide warranties as to the correct functioning of their
software. Overwhelmingly, they do not.

RSS> SSH is popular because its administrative overhead is relatively
RSS> low, compared to the other secure-connection schemes, however,
RSS> this plus can quickly become a minus--there may be no quick way
RSS> to revoke a user's access if the access keys become compromised.

It is not accurate to ascribe this behavior to "SSH," as if it were a
limitation of the protocol. Rather, it is true if you use the default,
simplistic key-management/authorization mechanisms (known_hosts,
authorized_keys, etc.). The main SSH implementations, both free and
commercial, now support Kerberos and PKI (and they interoperate to boot).

--
Richard Silverman
res@qoxp.net

Richard E. Silverman <res(*)qoxp.net> wrote:
|
| Most EULA's on commercial software say essentially the same
| thing--disclaiming all warranties except replacing defective media.
| Support is certainly a valuable service, but let's not pretend that
| commercial software vendors provide warranties as to the correct
| functioning of their software. Overwhelmingly, they do not.

Perhaps I let poetic metaphor obscure the point. With a commercial
product, when something goes wrong, you can generally get somebody
on the telephone to help you. The "something" need not be a defect
in the program: there are many possible modes of failure. Figuring
out the source of a problem often requires technically informed
diagnostic troubleshooting, and it is unwise to expect that a naive
user can perform such troubleshooting unassisted.

Support for free software is typically obtained from volunteers, who
frequent Usenet and certain web sites in their spare time and answer
questions out of a spirit of helpfulness. But it is very difficult
for such a volunteer to direct a troubleshooting procedure while
communicating through casual Internet means. For some problems,
you've got to talk interactively to solve them.

(It is possible that some third-party person or company will sell
the service of providing telephone support for a free software
product, but such support is not always available.)

If an organization's users are able to get by with volunteer support,
or if the organization contains experts who can help out when one
session's output mysteriously freezes (when somebody typed Control-S
by accident!), then there is more leeway to adopt free software.


| It is not accurate to ascribe this behavior to "SSH," as if it were
| a limitation of the protocol. Rather, it is true if you use the
| default, simplistic key-management/authorization mechanisms
| (known_hosts, authorized_keys, etc.). The main SSH implementations,
| both free and commercial, now support Kerberos and PKI (and they
| interoperate to boot).

I'll guess that 99 and 44/100th percent of people who are connecting
via SSH are using known_hosts and authorized_keys (or equivalents).
However, if you've got a list of implementations that can use Kerberos
and PKI, please post it, and the rest of us can be better informed.

...RSS


--
Juvenile-deliquent heifers and steers commit vandalism.
http://www.stonyfield.com/weblogarch...le/000798.html

>>>>> "RSS" == Richard S Shuford <shuford@list.stratagy.REM0VE-THlS-PART.com> writes:

RSS> However, if you've got a list of implementations that can use
RSS> Kerberos and PKI, please post it, and the rest of us can be
RSS> better informed.

OpenSSH and VShell/SecureCRT (VanDyke) support Kerberos via GSSAPI; Tectia
(ssh.com) supports both Kerberos and X.509 certificates.

--
Richard Silverman <res@oreilly.com>
co-author: SSH, The Secure Shell (The Definitive Guide)
http://www.oreilly.com/catalog/sshtdg

Richard S. Shuford wrote:


> I'll guess that 99 and 44/100th percent of people who are connecting
> via SSH are using known_hosts and authorized_keys (or equivalents).
> However, if you've got a list of implementations that can use Kerberos
> and PKI, please post it, and the rest of us can be better informed.
>
> ...RSS

Kermit 95 supports SRP, GSS-Kerberos 5, in addition to the traditional
shared keys and password based authentication methods.

Jeffrey Altman