SSH is the widely used Secure Shell protocol commonly used to access
Unix hosts. The older Telnet protocol transmits user-id and password
information in the clear over the network, so anybody with a sniffer
and access to your network can intercept your passwords.
SSH comes in two flavours: SSH-1 and SSH-2. This sounds like SSH-2 might
be a natural upgrade from SSH-1, but in reality they have hardly anything
in common. SSH-1 is deprecated, so IVT does not support it. This may imply
that older hosts or network hardware that supports SSH-1 only cannot be
accessed from IVT. Since SSH-1 has a number of known weaknesses, it would
be best to upgrade the target in question to SSH-2, rather than downgrading
IVT to SSH-1 :-)
Secure Shell version 2 hosts use a keypair, made up of a private and a
public key.
Put simply, anything encrypted with either key can only be decrypted
with the other key. The public key is just that: public. The private
key must be kept secret. If you encrypt something with the private key,
anybody can verify the authenticity of the message by decrypting it with
your public key. If that succeeds, it proves the sender had access to the
private key. If somebody sends something encrypted with a public
key, only the holder of the private key can decipher the message.
An SSH host begins by sending its public key to the SSH client (like IVT).
Note that the first time you connect to a host, there is nothing
to prove that the host actually is the one you think it is (Kerberos is
better in this respect, it supports mutual authentication).
So, the first time you get a prompt from IVT, in which it shows a
fingerprint of the key, and you are asked to accept or reject it. For real
security, you must either obtain the public keys of the hosts you want to
connect to in advance, or call the system administrator of the machine on
the phone and verify the fingerprint. IVT supports an SSH_HOSTKEYS option
to allow you to carry a file with host keys with you. PuTTY stores these
keys in the registry only and does not allow to inspect or export such keys.
On subsequent connections the key is compared to the previously sent
key, and a difference is noted. That way, you know at least that you are
connecting to the same host.
Anyway, when the public key is accepted, it can be used to obtain confidentiality on the session. It is used first to exchange a session key for a fast, simpler cipher algorithm such as AES or 3DES, because cryptography based on a-symmetric keypairs is very slow compared to such symmetric ciphers. Once the key is established, the data stream between the client and the host is confidential: the data on the network can still be intercepted, but no sense can be made of it. The data can also not be modified in any way.
So, better authentication mechanisms were invented. The easiest of these is
a keypair of your own, of which you guard the private part by encrypting
it with a passphrase and store it on your local machine, the public part
is stored on all your SSH enabled hosts. Such a keypair is generated by
PuttyGen, for example, which is also part of the IVT distribution.
The IVT manual explains in detail how to generate the keys and how to use them.
The idea is that you prove to the host that you have access to the private
key, without the need to send that key itself. No eavesdropper can obtain
the key, the resulting security is much better than passwords since nobody
can access your private key.
IVT also supports "keyboard-interactive" authentication. The idea is that the host sends one or more prompts, the user types a response and this is transmitted over the secure channel to the host. SecureID tokens from RSA work this way. The token displays a code that changes every minute, the host can verify that you have the proper token if you type the correct number. This means that there is something you must know (a password) and something you have (the token) to get access.
The advantage of SSH is that it hardly requires any setup. The host must
run an SSH server, and anybody with an SSH client such as IVT can connect
securely. The disadvantage is that the user has no certainty over the
identity of the host unless an (unusual) amount of care is taken. Also, when
you have many hosts to administer, you have to store the public key on
all the hosts, once for every account you want to use. If you do not use
a keypair, you still end up typing passwords all the time. The password
learning system of IVT alleviates this - it remembers passwords for you in
a locally stored, encrypted file and sends them to the host when required.
This works for plain Telnet sessions, but also for SSH sessions. This allows
you to choose more complex passwords, because you don't have to type them.
This can raise the strength of passwords significantly, at the cost of having
your passwords stored. Although they are stored in encrypted, protected
format, some people are against storing passwords in any form.
Kerberos offers single sign-on, and has no key-distribution problems for
users, at the price of a more complex initial setup of the network. Since you
authenticate only once per day usually with a password), that password
should also be complex (long).