SSH Client Security: Workstation Security
You must also check other client-side security settings that seem unrelated to OpenSSH’s client but can impact security. Do you share user home directories via NFS? I bet you do. Every UNIX user’s home directory is in NFS, right? What are the permissions? Consider the impact of poor permissions—that makes key placement easy, right? Well, think how efficiently people can retrieve keys when the jewels are stored in something like this:
Are you comfortable with your NFS permissions? Can "Public" add new keys to the authorized_keys files and thereby assume the identity of anyone on the UNIX server? Can the same "Public" set up a Trojan script that harvests the private-key passphrase—say, via code in .profile, or, even better, .bash_profile? Do you know for sure that every private key has an actual passphrase?
As I’ve mentioned before, I’ve seen anonymous FTP sites set into the /home file system. Here again, your local file permissions may be undercut by another service’s permissions!
Not using UNIX? Feeling gutsy? Are you using ancient Mac OS 7 or Windows 98, operating systems without file-level security but with file-sharing technologies built in? How well is your SSH client protected with these operating systems? Is it dated and full of ancient coding problems? These operating systems were great in their day, but are no longer supported by their vendors. They often have no real logging subsystems. Use something more secure, such as Mac OS X, Windows XP, Linux, FreeBSD, or OpenBSD. (And be sure to berate me for not calling out your favorite OS.)
Get a copy of Nessus or Metasploit. See your workstations as hackers see your workstations. Are you running services stupidly, as in our NFS example? Are some users running anonymous FTP, and now that service is the open door? Are you running Samba in ways that open your home directories despite UNIX permissions? Maybe you’re running ancient versions of tools with a long history of problems: sendmail, Samba, unpatched Windows?