Last Updated Fri Jul 9 18:08:45 2010

Secure Access - The "Internet Cafe" Problem

Previous Next: SSL threats

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.



Compared to the previous unencrypted Web session, most of the threats are still present, with the exception of wireless LAN snooping.

Mitigation

There are a number of ways to lessen the risk of using untrusted systems and networks:

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)

This will defeat the most common threats - spyware and rootkits in the operating system. The PC is still vulnerable to hardware-based logging devices. Use of an SSH key will mitigate password logging.
This will of course require rebooting the PC, and access to a CDROM 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.

This will avoid trojan SSH clients - ones that have been tampered with to collect passwords or session logs. It will not defeat rootkits.

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

These systems must be configured in advance. Passwords may be listed on a sheet of paper, generated by a key fob device, or generated by software on a PDA or cellphone.

Use SSH Keys

SSH keys are fairly easy to use, but must be configured in advance ssh-agent may be used with ssh-add to remember passphases for the duration of a logged-in session. See the manpage. This is preferred over having a null passphrase. Modern systems start the agent with X when you login to a desktop, so just type ssh-add to get started.

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/uptime
where (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 no
also e.g.
AllowUsers *@triumf.ca joe@ubc.ca jane
DenyUsers *@cn
AllowGroups, DenyGroups

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.

See man sshd_config
Next: SSL threats

A.Daviel