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.

CAUTION

Think carefully as you review and possibly attempt to implement these
controls. Read SSH vendor whitepapers and detailed SSH books; for example, check
out Michael Stahnke’s book Pro OpenSSH (Apress, 2005). Consider
hiring a consultant to help you gauge just what’s necessary and
appropriate for your organization.

To get the most use out of this article, you’ll need to fit the
following description:

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.