ssh Command: Harden the Linux SSH Client Against Downgrade Attacks and MITM

What is SSH client security?

Most SSH security documentation focuses exclusively on the server daemon (sshd_config) and ignores the client side. However, the SSH client is equally important: a hardened server connected to by a client with weak cipher negotiation, disabled host key checking, or an insecure agent forwarding configuration can undermine the entire security posture. The SSH client is configured via command-line flags or the ~/.ssh/config file (user-level) and /etc/ssh/ssh_config (system-wide). For administrative workstations used to manage production servers, SSH client hardening is a mandatory security control that is rarely implemented. Enforcing cipher restrictions on the client side also prevents negotiation of deprecated algorithms even when the remote server permits them.

Syntax

ssh user@host
ssh -i ~/.ssh/id_ed25519 user@host
ssh -o 'Ciphers aes256-gcm@openssh.com' user@host
ssh -o 'HostKeyAlgorithms ssh-ed25519' user@host
ssh -J jumphost user@targethost
ssh -o 'StrictHostKeyChecking yes' user@host

The -o flag passes configuration options directly. Key options: Ciphers restricts allowed encryption algorithms; MACs restricts integrity algorithms; KexAlgorithms restricts key exchange; HostKeyAlgorithms restricts host key types; StrictHostKeyChecking yes refuses connections to hosts with changed keys. Configuration file options use the same names without -o.

Key Security Options

Common Use Cases

Force Specific Cipher Suites to Prevent Downgrade Attacks

If an attacker performs a machine-in-the-middle attack and can manipulate the SSH handshake, they may negotiate weaker ciphers to facilitate later decryption or exploitation. Restricting the client to a known-strong cipher list ensures the connection either uses approved algorithms or fails — never degrades silently.

# Test: connect with enforced strong ciphers
ssh -o 'Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com' \
    -o 'MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com' \
    -o 'KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521' \
    user@host

Create a Hardened ~/.ssh/config for Production Server Access

A per-host SSH configuration in ~/.ssh/config allows applying different security policies to different servers without repeating command-line options. For production servers accessed from an administrator’s workstation, this should enforce strong algorithms, disable agent forwarding, and specify the correct identity file.

# ~/.ssh/config
Host prod-server
  HostName 192.0.2.10
  User admin
  IdentityFile ~/.ssh/id_ed25519_prod
  StrictHostKeyChecking yes
  ForwardAgent no
  ForwardX11 no
  Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
  MACs hmac-sha2-256-etm@openssh.com
  KexAlgorithms curve25519-sha256

Use ProxyJump Securely Instead of Agent Forwarding

A common pattern is using a bastion/jump host to access internal servers. The traditional approach using ForwardAgent yes is insecure — the bastion can authenticate as you to other hosts using your agent. The modern approach using ProxyJump (-J) creates a direct tunnel without exposing the SSH agent to the intermediate host.

# Insecure (legacy) approach - avoid:
ssh -A user@bastion  # exposes your agent to bastion

# Secure approach using ProxyJump:
ssh -J user@bastion user@internal-server

# In ~/.ssh/config:
Host internal-*
  ProxyJump user@bastion
  ForwardAgent no

Security Relevance: The Forgotten Half of SSH Security

Practical Examples

Audit current SSH client configuration for security issues

ssh -G user@host 2>/dev/null | grep -E '(forwardagent|forwardx11|stricthostkeychecking|ciphers|macs|kexalgorithms)'
cat ~/.ssh/config 2>/dev/null
ls -la ~/.ssh/
cat /etc/ssh/ssh_config | grep -v '^#' | grep -v '^$'

ssh -G dumps the effective configuration for a connection as it would be applied. grep for the key security parameters to audit the current state. Also check the permissions of ~/.ssh/ (should be 700) and ~/.ssh/config (should be 600).

Test that a server rejects weak ciphers

ssh -o 'Ciphers 3des-cbc' user@host 2>&1 | grep -i 'no matching\|cipher'
ssh -o 'MACs hmac-md5' user@host 2>&1 | grep -i 'no matching\|MAC'

Attempts to connect using an intentionally weak cipher. A hardened server configured with a strong cipher whitelist will respond with ‘no matching cipher found’. If the connection succeeds, the server accepts weak ciphers and its sshd_config needs to be tightened.

Verify host key fingerprint before first connection

# Get the fingerprint from the server console (not over network)
ssh -o 'FingerprintHash sha256' user@host  # Compare displayed fingerprint

# Or retrieve server's key fingerprint directly if you have console access
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Before the first SSH connection to a new server, verify the host key fingerprint out-of-band (via server console, provider API, or cloud metadata). Accept the fingerprint only after this verification. This prevents trust-on-first-use attacks where an attacker intercepts the initial connection before the key is cached in known_hosts.

Troubleshooting Common Issues

Summary

SSH client hardening is the frequently neglected complement to sshd_config. Disabling agent forwarding globally, enforcing strong cipher suites, setting StrictHostKeyChecking to yes, and using ProxyJump instead of agent forwarding for bastion host access are the four most impactful client-side changes for production environments. Apply them system-wide via /etc/ssh/ssh_config and per-host via ~/.ssh/config to enforce these policies consistently across all connections from your administrative workstation, ensuring no individual session inadvertently uses weaker negotiated settings.

• Disable ForwardAgent globally (ForwardAgent no in ssh_config) — use ProxyJump for bastion access instead
• Set StrictHostKeyChecking to yes for production server access — ‘ask’ mode (the default) accepts first-use without verification
• Store the production cipher list in ~/.ssh/config per host — this is more reliable than command-line flags that are easy to forget