On Sun, 17 Sep 2000, Jonas Thorell wrote:
> Scott Corley wrote:
>
> >Can anyone tell what SSH is and how to use it?
>
> Basically a remote shell like telnet over a encrypted
> channel. I have no idea of how to use it on an Amiga
> unfortunately (haven't kept up on that front...) but
> from the point of view of the user it works like telnet
> (but with another client in most cases). From the administrators
> point of view it's a bit more complicated (but worth it).
>
> For more info take a look at http://www.openssh.org
In order to use it you need a server on the server side and a client on
the client side. There are currently no SSH sservers for the Amiga, but
there are at least three client implemntations:
1) An ixemul port of the Unix SSH client. This just runs under the shell,
so it can be problematic with respect to terminal-related features, but it
for the most part works reasonably provided that you have ixemul set up.
With a suitable CON: replacement such as KingCON you get scrollback. As
of 4 days ago, it's now even legal in the US and Canada. :-) Look for
comm/net/SSH.lha on Aminet.
2) AmigaSSH. This combines an SSH client with Napsaterm (the VT-100
emulating Telnet client from AmiTCP), so it's more usable terminal-wise,
but different versions have had different problems so I never had very
good luck with it overall. However, I haven't tried V3. It has no
scrollback buffer. See:
http://www.lysator.liu.se/~lilja/amigassh/
3) MiamiTelnet. MiamiTelnet (included with MiamiDx) includes SSH client
support, along with it's fairly good VT-100 emulation and scrollback
buffer. This is the SSH client I normally use, although it still has a
couple of bugs.
There are a couple of really useful things about SSH, beyond merely being
an encrypted Telnet:
1) Better authentication mechanisms. Although you can use ordinary
password dialog as in Telnet, and this is more secure due to encrypting
the password on the wire, what's even better is to use RSA authentication.
Here you store a public key on the server and its mating private key on
the client, encrypted by a passphrase. The private key is *never*
transmitted *at all*, even encrypted, and stealing the public key from the
server gains nothing.
2) Port forwarding. You can set up additional "tunnels" via SSH to allow
*other* protocols to share the encrypted link and gain (authenticated)
access through firewalls. This is something like a VPN link, but with
advantages and disadvantages.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
