SSH Security Primer: Client Security
- Client Security Settings: Challenges
- SSH Client Security: Workstation Security
- SSH Client Security: Digital Key Security
- SSH Client Security: Hidden Startup Files
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A common response to my SSH articles is a request for basic SSH security configuration information. Of course, each organization has unique needs, so no cookie-cutter solution can be applied universally, but this article reviews some of the issues and possible configurations that may work for you.
We’ll focus here on general OpenSSH precautions and security controls. Why OpenSSH? Because the OpenSSH distribution seems to be the version with the most significant use. In fact, many vendors derive their SSH implementations from OpenSSH, so learning OpenSSH provides a lot of baseline information on how SSH works.
To get the most use out of this article, you’ll need to fit the following description:
- You’ve read and reviewed the relevant SSH administration documentation and man pages.
- You know the operating system basics for each device that runs SSH. Extra points if you’ve read any of the Center for Internet Security’s security benchmarks for your client platform.
- You have a basic understanding of how TCP/IP networks work.
- You have a current, patched OpenSSH system set up.
- You’re prepared to look up the function of OpenSSH security files
mentioned in this article.
Safari has
hundreds of great SSH hits waiting for you.
Client Security Settings: Challenges
If you’re familiar with the SANS Institute’s Top 20 risk list, you know that hackers look to penetrate networks via poor SSH settings. Do you routinely authorize connections into your network via SSH secured by easily guessed passwords? Do know what your production configuration must be? Do you have systems in place to detect changes?
If you read my article on building inside-to-outside-to-back-inside encrypted tunnels, you know that this puncturing of your border defenses is possible when the client is configured to listen for and to forward communications back into the organization. But what if we controlled the client configuration in a way that makes forwarding rules impossible to create? I’m not convinced that an organization can truly secure most client software. There are so many challenges to any organization’s control:
- Self-important blowhards who insist that they need to run any software at any time for any reason. (People like me, for example, the most self-important customer in the world.)
- USB drives with special "roaming" versions of software that can run with user rights. Go ahead and ban Firefox—meanwhile, you’ve paid no attention to the USB drive providing a self-contained copy.
- USB and other devices with virtual machine managers and actual virtual machines on them. moka5 is an interesting derivation of this principle. (That’ll be a fun article to write. Can’t wait for the security outcry on that tool.)
In addition to all of this complexity, reading the ssh_config man page shows us that the SSH client software is especially difficult to control. Users can override any administrative defaults easily, either by sourcing a config file located on a machine that the administrator/root user may not control, or by supplying the overrides as command-line parameters. So how do you control this stuff?
Give up? Not today!
Begin by formulating and communicating clear policy against SSH tunnels, if that’s your organization’s decision. Additionally, if you can reach remote clients and do a review, pay careful attention to the SSH client-configuration directives shown in Table 1.
Table 1
Key security settings in ssh_config.
Directive
Security Importance
CheckHostIP
This setting ensures that the client checks the host key signature and IP with the recorded credentials in the known_hosts file. This check can help you detect that someone has hacked DNS and sent you to a counterfeit host.
GatewayPorts
Normally, forwarded ports are kept from being open to just anyone; they’re bound to localhost, an unroutable address. If this option is set to yes, the forwarding rules bind to all IP addresses, thus allowing many remote hosts to be able to use this user’s forwarding rules.
Suppose your organization has a hacker. The hacker finds out that you operate a promiscuous gateway. Whose IP address is in the logs of hacked systems and applications?
HostbasedAuthentication
Specifies whether to try rhosts-based authentication with public-key authentication. Huh? Using rhosts-based authentication just seems wrong. Trusting that another server is "secure enough" just seems wrong. The default setting is no. I’d love to see several good examples where this authentication is reasonably acceptable to use.
IdentityFile
This is the private key used in authentication. If the file permissions are set too openly, authentication won’t work. Be on the lookout for the same key being used by several different accounts. In the best case, a user has been very generous with his or her credential; in the worst case, a hacker has seeded a lot of accounts with a generic credential. In the absolute worst case, your CEO has shared her key on an anonymous share—the key without a passphrase.
LocalForward
Someone has implemented forwarding, possibly creating a stealth tunnel into your network. If this is contrary to your policy, you must respond.
LogLevel
Excessive logging can create true needle-in-a-haystack problems. Too little logging is too little help in an investigation. I can’t recommend a setting here, because the final log length depends on system activity, etc.
RemoteForward
Signs of more forwarding, worth reviewing only if forwarding goes against your policies.
RhostsRSAAuthentication
Specifies whether to try rhosts-based authentication with RSA host authentication. More rhosts, eh? And SSH protocol version 1, too (more on that later).
StrictHostKeyChecking
You work hard to maintain known_hosts files for your customers. What do you think of people who configure their SSH clients to accept any signature sent as valid, and blindly add the signatures to ssh_known_hosts? That’s as senseless as blindly clicking past the security panels when browsers complain about a website’s odd digital certificate.
You want your host-key checking to have the strictest evaluation. That said, some people will blindly accept any risk on behalf of your team and organization.
Anything with tunnel in the directive
Wow, this truly indicates using SSH as VPN technology. What do your policies say about this?
Of course, many other directives have some indirect security significance, and your SSH distribution may have some in addition to these. As you can see from Table 1, you need to come to a definite conclusion about policies regarding tunneling. Do you ignore it? Come out against it?
Host checking is another important item. SSH comes with a system to identify hosts via digital keys. Do you want to use it? If someone tries to implement the same key pair for all servers (to keep people from seeing that error message), do you have an answer? My answer was "No" because I felt that it undercut SSH security. But other people feel that all you need is encryption. What are your organization’s views? You must have policies regarding host checking. Don’t wait until too late in the implementation.