Secure Remote Access

Secure Access - The "Internet Cafe" Problem

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 SSH version 2 (disable SSH1 fallback; SSH1 is vulnerable to some man-in-the-middle attacks
Preferably use an SSH key; this will defeat shoulder-surfing and surveillance cameras that may record passwords - the passphrase is useless without the key.
Other services (X11, HTTP) may be tunnelled; see this example

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)

Preferably use an SSH key; a keyfile may be burned to the CD, or stored on other media such as a USB stick.
Use SSH 2

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.

Preferably use an SSH key
Use SSH 2
Pay attention to key signature warnings. They can alert you to bogus servers set up using DNS hijacking or rogue access points. The expected signature of a server can be found by e.g.
```
ssh-keygen -l -f  /etc/ssh/ssh_host_rsa_key.pub
```
Ideally, 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.

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

Use a trusted generator
Do not do secondary logins to non-OTP machines - the second password could be captured.

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

Generate a (public,private) key pair using e.g. ssh-keygen (on Linux). Use a passphrase. This is your personal passphrase, used to secure the key, and may be changed at any time without connecting to a remote machine.
```
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/jondoe/.ssh/id_dsa):
```
(for Windows, see generating keys on Windows)
Append the public key (id_dsa.pub) to $HOME/.ssh/authorized_keys on each target machine (this file should be mode 600 - not world-readable - and $HOME/.ssh should be mode 700)
Place the private key (id_dsa) in $HOME/.ssh on each client machine, or on a USB stick
Use the key with openssh (ssh user@host) or PuTTY (select configuration->SSH->Auth->Private Key File)
When prompted, enter the passphrase

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

See man sshd_config

Next: SSL threats

A.Daviel