SSH Client Hardening: The Settings That Actually Matter

A good ~/.ssh/config does more than save you from typing long commands. It can prevent your SSH agent from being exposed to untrusted machines, make host identity verification explicit, keep dead connections from hanging forever, and make authentication behaviour predictable. But not every SSH option belongs in a global "security" block. Some are genuinely security-critical, some improve robustness, and others are useful only when your particular network or workflow calls for them. This article focuses on nine directives where that distinction matters.

The Problem

SSH already ships with sensible defaults. The danger is not that a completely empty configuration is automatically insecure; the danger is that a few seemingly harmless convenience settings can change the security boundary of a connection.

Consider a developer who regularly connects to a production server, a staging machine, and a jump host. Their SSH agent holds several private keys, the connections sometimes pass through unreliable networks, and the infrastructure occasionally gets rebuilt.

The important questions are not just "can I connect?" but:

• Can a compromised remote host use my SSH agent to authenticate somewhere else?
• Will SSH silently accept a new or changed host key?
• Where are trusted host keys stored, and are they isolated between environments?
• What happens when the network disappears for ten minutes?
• Will an unreachable host block a script for several minutes?
• Am I changing compression or authentication behaviour for a good reason, or simply because a blog told me to?

These are different problems, and they deserve different levels of configuration.

Security-Critical Settings

These are the settings where a careless value can directly weaken a security boundary. They deserve deliberate configuration rather than blind copying.

1. ForwardAgent — don't give the remote host your agent Critical

ForwardAgent controls whether your local SSH agent becomes available through the SSH connection. With ForwardAgent yes, a special channel — a Unix-domain socket — is opened on the remote host that pipes signing requests back to the agent running on your own machine.

Here is the part worth slowing down on, because it is easy to assume forwarding is harmless when it is not. Agent forwarding does not copy your private keys to the remote host — the key files never leave your laptop. So far, so safe. But the forwarded socket is a live line back to your agent, and your agent will happily sign whatever authentication challenges come down that line. While your session is open, anyone on the remote host who can reach that socket — in practice the root user, or an attacker who has already compromised the machine — can send their own signing requests to your agent.

They cannot read your keys. They do not need to. They can ask your agent to prove your identity to other servers, which means they can log in as you anywhere those keys are trusted, for as long as your session lasts. And this is where the earlier detail matters: because the agent holds all your loaded keys at once, a single compromised host does not merely expose the one key you used to reach it — it exposes your entire keyring. If your agent is holding your production key, your bastion key, and your personal key, an attacker on one forwarded host can attempt to use all three. OpenSSH's own manual states the warning plainly: agent forwarding should be enabled with caution.

If you genuinely need agent forwarding for a trusted bastion, scope it to that one host:

2. StrictHostKeyChecking — decide how much you trust host identity Critical

SSH does not authenticate the server merely because the connection is encrypted. It also needs to know which server is on the other end. Host keys stored in known_hosts provide that continuity of identity.

StrictHostKeyChecking controls what happens when the host key is unknown or has changed. This is one of the most consequential settings in a client configuration because accepting a changed key without investigation can turn an identity warning into a silent trust decision. Modern OpenSSH supports four practical values: yes, accept-new, ask, and no/off.

The values, from safest to most permissive

The important distinction between accept-new and no is what happens after the first connection. accept-new automatically records an unknown host key but still refuses a changed key. That makes it useful for environments where hosts are frequently created but identity changes should remain exceptional.

For a hardened workstation configuration, yes is the strongest choice — but only if you have a reliable process for provisioning host keys. Otherwise, you are likely to train users to bypass the warning instead of investigating it.

Robustness Settings

These directives are less about cryptographic strength and more about making SSH behave predictably when networks fail, machines disappear, or several environments need separate trust databases. They are especially valuable for automation, laptops, VPNs, cloud infrastructure, and unreliable networks.

3. UserKnownHostsFile — control where host trust is stored Recommended

UserKnownHostsFile changes the file or files used as the user's host-key database. This becomes particularly useful when you need different trust domains: for example, a temporary lab environment, a CI job, or an isolated fleet whose host keys should not be mixed with your everyday SSH history.

This is not a replacement for StrictHostKeyChecking. Think of the two directives as answering different questions: StrictHostKeyChecking decides how SSH reacts to host identity, while UserKnownHostsFile decides where that identity information is kept.

4. ServerAliveInterval + ServerAliveCountMax — detect dead sessions Recommended

These two directives work together.

ServerAliveInterval tells the client to send an encrypted keepalive request after a specified number of seconds with no data received from the server. ServerAliveCountMax determines how many unanswered probes are tolerated before SSH disconnects. The default interval is 0, meaning no SSH-level keepalive messages are sent; the default count is 3.

With that configuration, SSH sends a probe after 30 seconds of inactivity and disconnects after three unanswered probes — roughly 90 seconds of unresponsiveness.

These are different from TCP keepalives. SSH-level server-alive messages travel through the encrypted SSH channel, whereas TCP keepalive operates at the transport layer. The SSH mechanism is therefore useful when you want the SSH client itself to know that the encrypted session has stopped responding.

5. ConnectTimeout — don't wait forever to connect Recommended

ConnectTimeout limits how long SSH waits while establishing the connection. In current OpenSSH, the timeout also covers the initial SSH protocol handshake and key exchange.

Ten seconds is a useful starting point for interactive systems, although the right value depends on your network. A very aggressive timeout can make high-latency links unreliable; an excessively long timeout makes automation painfully slow when a host is down.

Situational Settings

These directives are useful, sometimes very useful, but they should not automatically be promoted into a universal security policy. Their correct values depend on the workload, network, debugging needs, and authentication architecture.

6. Compression — useful on slow links, unnecessary on fast ones Situational

Compression yes asks SSH to compress the data stream before encryption. It can reduce bandwidth consumption and improve interactive performance over slow links, particularly for compressible text-heavy traffic.

On a fast modern connection, compression can simply consume CPU without producing a meaningful bandwidth benefit. Already-compressed data — images, archives, videos, many database dumps — generally gains little.

7. LogLevel — useful when diagnosing SSH, noisy when overused Situational

LogLevel controls how much diagnostic information the SSH client emits. Common values include QUIET, FATAL, ERROR, INFO, VERBOSE, and the increasingly detailed DEBUG1 through DEBUG3.

For everyday use, INFO is usually the right balance. For troubleshooting, temporarily use -v, -vv, or -vvv on the command line instead of permanently increasing the global log level.

8. PreferredAuthentications — control authentication order Situational

PreferredAuthentications controls the order in which SSH tries authentication methods. It does not itself enable an authentication method that the server does not permit.

This distinction matters. If your environment is explicitly designed around public-key authentication, you may prefer to make that preference obvious:

But don't confuse ordering with disabling. If the goal is to prevent password authentication entirely, that is primarily a server-side policy such as PasswordAuthentication no and, depending on the environment, appropriate keyboard-interactive/PAM configuration. Mozilla's OpenSSH guidance recommends public-key-only authentication for suitable deployments.

A Practical Risk Classification

The easiest way to remember these directives is not by memorizing their names, but by asking what kind of problem they solve.

A Real-World Comparison

Consider two developers, Alice and Bob. Both connect from laptops to production infrastructure. Both use an SSH agent and both occasionally work from unreliable networks.

Bob wants SSH to "just work", so he disables anything that interrupts him:

Bob's configuration is superficially convenient. Alice's configuration is predictable.

Defaults at a Glance

A Hardened Configuration

Here is a practical hardened baseline. It deliberately does not turn every situational option into a global rule. The global block protects the most important boundaries and improves connection behaviour; host-specific blocks handle exceptions.

Checking What SSH Actually Uses

Configuration files become difficult to reason about once you have multiple Host blocks, includes, command-line overrides, and wildcard matches. Fortunately, OpenSSH can show the effective configuration before you connect.

This is one of the best debugging tools for SSH configuration. Instead of guessing which Host block won, ask the client what configuration it resolved for the destination.

The Short Version

You don't need dozens of SSH options to build a safer configuration. Start with the trust boundary:

1. Keep ForwardAgent no globally. Enable it only for explicitly trusted hosts that genuinely need it.
2. Don't weaken StrictHostKeyChecking to make warnings disappear. Use yes for controlled infrastructure, accept-new for suitable ephemeral environments, or leave the interactive default ask.
3. Use UserKnownHostsFile when you need separate trust domains. It controls the database; it does not replace host-key verification.
4. Use ServerAliveInterval and ServerAliveCountMax together. They turn dead connections into detectable failures.
5. Set a reasonable ConnectTimeout. Especially for automation and laptops that regularly move between networks.
6. Leave Compression, LogLevel, and PreferredAuthentications situational. They solve performance, diagnostics, and authentication-order problems — not the same security problem.

The best SSH configuration is therefore not the longest one. It is the one that makes the important security decisions explicit, makes network failures predictable, and leaves everything else at a sensible default until there is a reason to change it.