SSH dramatically improves password security by encrypting your password as it passes over the network. Nevertheless, a password is still a weak form of authentication, and you must take care with it. You must choose a good password, memorable to you but not obvious to anyone else, and not easily guessable. You must also avoid having your password stolen, since possession alone is sufficient to grant access to your account. So, watch out: the guy at the next terminal might be surreptitiously “shoulder surfing” (watching as you type). That computer kiosk you’re about to use may have been tricked up to log all keystrokes to Cracker Central Command. And the nice-sounding fellow who calls from Corporate IT and asks for your password to “fix your account” might not be who he claims.

Consider public-key authentication instead, since it is two-factor : a stolen passphrase is useless without the private-key file, so an attacker needs to steal both. Of course, the SSH client on the computer you’re borrowing can be rigged to squirrel away your key after you blithely supply your passphrase to decrypt it. If you’re that worried, you shouldn’t use strange computers. In the future, one hopes, cryptographic smartcards and readers will be ubiquitous and supported by SSH so that you can carry your keys conveniently and use them in other computers without fear of disclosure.

If you must use password authentication because of its convenience, consider using a one-time password scheme such as S/Key to reduce risk. [5.4.5]

SSH operates on top of TCP, so it is vulnerable to some attacks against weaknesses in TCP and IP. The privacy, integrity, and authentication guarantees of SSH limit this vulnerability to denial-of-service attacks.

TCP/IP is resistant to network problems such as congestion and link failure. If the enemy blows up a router, IP can route around it. It wasn’t designed to resist an adversary injecting bogus packets into the network, however. The origin of TCP or IP control messages isn’t authenticated. As a result, TCP/IP has a number of inherent exploitable weaknesses, such as:

SSH provides no protection against attacks that break or prevent setup of TCP connections. On the other hand, SSH’s encryption and host authentication are effective against attacks that involve inappropriate routing that would otherwise permit reading of sensitive traffic or redirect a connection to a compromised server. Likewise, attacks that hijack or alter TCP data will fail, because SSH detects them, but they also break the SSH connection, because SSH responds to such problems by termination.

Because these threats focus on problems with TCP/IP, they can be effectively countered only by lower, network-level techniques, such as hardware link encryption or IPSEC. [1.6.4] IPSEC is the IP Security protocol that is part of the next-generation IP protocol, IPv6, and available as an add-on to the current IP standard, IPv4. It provides encryption, integrity, and data origin-authentication services at the IP packet level.

Even if an attacker can’t read your network traffic, he can glean a great deal of useful information by simply watching it—noting the amount of data, the source and destination addresses, and timing. A sudden increase in traffic with another company might tip him off that an impending business deal is in the works. Traffic patterns can also indicate backup schedules or times of day most vulnerable to denial-of-service attacks. Prolonged silence on an SSH connection from a sysadmin’s desktop might indicate that she’s stepped out, and that now is a good time to break in, electronically or physically.

SSH doesn’t address traffic-analysis attacks. SSH connections are easily identifiable as they generally go to a well-known port, and the SSH protocol makes no attempt to obfuscate traffic analysis . An SSH implementation could conceivably send random, no-op traffic over a connection when it’s otherwise idle, to frustrate activity correlation. OpenSSH, in fact, sends no-op packets in response to keystrokes when a program turns off tty echo (e.g., the su program prompting for a password). This makes it harder for an attacker to identify the keystrokes of value in a session.

A more serious concern regarding traffic analysis arises from recent work by U.C. Berkeley researchers Dawn Song, David Wagner, and Xuqing Tian. At the 10th Usenix Security Symposium (Washington D.C., August 2001), they presented a paper titled “Timing Analysis of Keystrokes and Timing Attacks on SSH”:

The paper applies traffic-analysis techniques to interactive SSH connections to infer information about the encrypted contents. The authors conclude that the keystroke timing data observable from existing SSH implementations reveals a dangerously significant amount of information about user terminal sessions—enough to locate typed passwords in the session data stream and reduce the computational work involved in guessing those passwords by a factor of 50. While this work describes a very sophisticated attack which has yet to yield any practical exploits (that we know of!), this area bears watching.

A covert channel is a means of signaling information in an unanticipated and unnoticed fashion. Suppose that one day, Sysadmin Sally decides her users are having too much fun, and she turns off email and instant messaging so that they can’t chat. To get around this, you and your friend agree to put messages to each other into world-readable files in your home directories, which you’ll check every once in a while for new messages. This unanticipated communication mechanism is a covert channel.

Covert channels are hard to eliminate. If Sysadmin Sally discovers your file-based technique, she can make all home directories unreadable and unsearchable by anyone but their owners, and prevent the owners from changing this restriction. While she’s at it, she can also make sure you can’t create files anywhere else, like /tmp. (Most of your programs don’t work now, but that doesn’t matter to Sally.) Even so, you and your friend can still list each other’s home directory nodes themselves, which reveals the directory modification date and number of files, so you devise a secret code based on these visible parameters and communicate by modifying them. This is a more complex covert channel, and you can imagine even more outlandish ones in the face of further restrictions from Sally.

SSH doesn’t attempt to eliminate covert channels . Their analysis and control are generally part of highly secure computer systems, such as those designed to handle information safely at various security classification levels within the same system. Incidentally, the SSH data stream itself can be used perfectly well as a covert channel: the encrypted contents of your SSH session might be a recipe for chocolate chip cookies, while a secret message about an impending corporate merger is represented in Morse code using even/odd packet lengths for dashes and dots.

Security tools don’t secure anything; they only help people to do so. It’s almost a cliché, but so important that it bears any amount of repeating. The best cryptography or most secure protocols in the world won’t help if users pick bad passwords, or write their passphrases on Post-it notes stuck to the undersides of their keyboards. They also won’t help sysadmins who neglect other aspects of host security, allowing host-key theft or wiretapping of terminal sessions.

As Bruce Schneier is fond of saying, “Security is a process, not a product.” SSH is a good tool, but it must be part of an overall and ongoing process of security awareness. Other aspects of host integrity must still be attended to; security advisories for relevant software and operating systems monitored, appropriate patches or workarounds applied promptly, and people educated and kept aware of their security responsibilities. Don’t just install SSH and think that you’re now secure; you’re not.