SSH, such as that from openssh.org, has generally replaced programs such as telnet and rsh at TRIUMF and other institutions. It uses encryption to defeat network "sniffing", effective on the shared Ethernet segments common in the 1980's, or on contemporay wireless LANs (IEEE 802.11), and also to assure connection to the "correct" server.
However, it is not at all resistant to monitoring installed on the endpoints - a much more likely target than today's professionally administered Internet backbone, while its identity assurance is often misunderstood. Thus it may give users a false sense of security.
The diagram below illustrates possible threats against an SSH session.
Use a trusted endpoint
Using a clean laptop over an open wireless link is better than using an untrusted PC, providing that end-to-end encryption is used. See this diagram; note that the most threats are mitigated. This takes no account of active threats - it is assumed that the laptop is well maintained and is protected against viruses, spyeare, service exploits, etc.
Use a trusted operating system
Boot a standalone system from a CDROM, such as Knoppix. This may be a viable technique when borrowing PCs belonging to friends or relatives, when you have no idea how secure their machine is. You don't need to change any settings or install any software - just insert a CD and reboot. (In some cases it may be necessary to change BIOS settings to allow the CDROM drive to boot before the hard drive)
Use a trusted SSH client
Run a clean copy of a trusted SSH client such as OpenSSH or PuTTY from a USB memory stick or CD, or download a clean copy off the Internet.
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pubIdeally, you should connect to each server on a trusted network before travelling, so as to populate the known_hosts file.
System managers should make every effort to preserve SSH keys across system upgrades and replacements. Doing so avoids the "cry wolf" syndrome.
Use a trusted SSH client (2)
Use an SSH applet such as Mindterm from appgate.com. This is a Java applet that must be installed on a trusted webserver before it can be used.
Use a One-Time-Password
Use an OTP system such as S/KEY, OPIE or OTPW
$ ssh-keygen Generating public/private RSA key pair. Enter file in which to save the key (/home/jondoe/.ssh/id_rsa):(for Windows, see generating keys on Windows)
One nice feature of SSH keys is that they may be restricted to work only from certain machines or domains by adding a "from" field to the authorized_keys file, e.g.
from="*.triumf.ca,machine2.some.other.org" ssh-dss AAA...
For unattended login between two machines, you can lock down the command that will run, as well as the machine that is allowed to login. E.g., in .ssh/authorized_keys on the target machine
command="/usr/bin/uptime",from="joe.example.com",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss AAAAB3N...and then on the initiating machine
ssh -i $HOME/.ssh/target_key user@target /usr/bin/uptimewhere (target_key,target_key.pub) is a keypair generated for this specific operation. I.e. it is a different key from your default login key, which should be protected with a passphrase.
There may also be multiple keys for one account, with different (or no) passphrases. For example, access to machine orchid.triumf.ca could be granted to rose.triumf.ca using key #1 with no passphrase, to any machine using key #2, and to any machine on shaw.ca or telus.ca domains using key #3. If key #3 is stolen, it won't work from anywhere else. If key #2 is stolen, it may be revoked and regenerated without affecting people using keys #1 or #3. In contrast, if a login password is stolen, it must be changed immediately, inconveniencing all users of the account worldwide.
The script pssh offers some convenience in using multiple keys.
It is recommended to disable password logins in /etc/ssh/sshd_config, particulary for root, to defeat SSH dictionary attacks. Consider using one of
PermitRootLogin without-password PasswordAuthentication noalso e.g.
AllowUsers *@triumf.ca email@example.com jane DenyUsers *@cn AllowGroups, DenyGroupsSee man sshd_config
Another useful option is to set "LogLevel VERBOSE". With that, SSH key fingerprints are logged to syslog, so that an administrator can tell which key was used to login to an account.