How to Set SSH Compression Level Above 6 in SSH Protocol Version 2

When attempting to configure SSH compression with a level higher than 6 using command-line options, many users encounter the following debug output:

debug1: Enabling compression at level 6.

This occurs regardless of the various syntax attempts:

ssh -v -C -o CompressionLevel=9 user@host
ssh -v -o 'Compression=yes' -o 'CompressionLevel=9' user@host

The key insight comes from SSH protocol implementation details:

The CompressionLevel option only affects SSH Protocol Version 1 (SSH-1)
SSH Protocol Version 2 (SSH-2) hardcodes the compression level to 6
Modern SSH implementations default to Protocol 2 for security reasons

For SSH-2, you have several approaches:

1. Accept the Default Level 6

The simplest solution is to accept the built-in compression level:

ssh -C user@host

2. Pipe Through External Compression

For more control, use external compression tools:

# Compress before SSH
tar czf - /path/to/files | ssh user@host "cat > archive.tar.gz"

# Decompress after SSH
ssh user@host "cat largefile.txt" | gzip -9 > compressed_file.txt.gz

3. Modify SSH Source Code (Advanced)

For those who need absolute control and can compile from source:

// In openssh-*/compress.c, look for:
#define COMP_DEFLATE_LEVEL 6

// Change to:
#define COMP_DEFLATE_LEVEL 9

Check actual compression ratios with these commands:

# Before compression
ls -lh file.txt

# After SSH transfer with compression
ssh -C user@host "cat file.txt" | wc -c

Remember that higher compression levels significantly increase CPU usage with diminishing returns on compression ratio.

When working with large data transfers over SSH, many developers hit a frustrating limitation - the compression level seems hard-capped at 6 despite attempting various configuration approaches. Let's examine the core issue through these failed attempts:

ssh -v -C -o CompressionLevel=9 user@ip
ssh -v -o 'Compression=yes' -o 'CompressionLevel=9' user@ip

All variations result in the same verbose output:

debug1: Enabling compression at level 6.

The key insight comes from SSH's protocol evolution. While SSHv1 allowed configurable compression levels up to 9, SSHv2 (the current standard) implements compression differently:

Uses zlib with hardcoded Z_DEFAULT_COMPRESSION (equivalent to level 6)
Prioritizes security and reliability over extreme compression
Has compression algorithm negotiated during handshake

While you can't directly override the level in SSHv2, these approaches achieve similar results:

Option 1: Pre-compress Your Data

tar czvf - /path/to/data | ssh user@ip "tar xzf -"

Using tar with maximum gzip compression (-9 flag):

tar --use-compress-program="gzip -9" -cvf - /path | ssh user@ip "tar xvf -"

Option 2: SSH Tunnel + External Compression

ssh -C -L 2222:localhost:22 user@ip
# Then in another terminal:
gzip -9c file | nc localhost 2222

Before pursuing maximum compression, understand these tradeoffs:

Level	CPU Usage	Bandwidth Saving
1	Low	~20%
6	Medium	~60%
9	High	~65%

The marginal gains beyond level 6 rarely justify the CPU overhead, especially on modern networks.

For true maximum compression in file transfers, consider:

# Using rsync with maximum compression
rsync -az --compress-level=9 /path user@ip:/dest

# Using dedicated tools for large datasets
borg create --compression lzma,9 user@ip:archive::backup /path

ServerDevWorker