Back to IVT main page.

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-2, 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.
However, the host still does not know who you are. SSH-2 will offer a list of valid authentication mechanisms to the remote client (such as IVT). Good old passwords are most common. Note that this is bad, since users choose bad passwords, and usernames are not secret. So anybody who can connect to your host and guess your password can login with SSH, and you are no more secure than with plain Telnet. Worse, some users get a false sense of security because they assume themselves secure because they use SSH...

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).

 

Back to IVT main page.