Force Frequent SSH Session Key Renegotiation
Make the daemon renegotiate session keys every 512 MB of traffic or every hour (RekeyLimit 512M 1h). This bounds how much ciphertext a single key protects and how long a stolen session key stays useful; OpenSSH's default (default none) sets no time limit at all.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
What Pavois checks
Pavois runs sshd -T and requires the resolved line rekeylimit 536870912 3600. Note the normalisation: what an administrator writes as 512M 1h is printed by the daemon in bytes and seconds, which is exactly why the control reads the effective configuration instead of a file. sshd -T also resolves every Include and drop-in in /etc/ssh/sshd_config.d/, so a later file that restores default none is caught.
describe command('sshd -T') do
its('stdout') { should match(/^rekeylimit\s+536870912\s+3600$/i) }
endHow to verify it is applied
Run sshd -T | grep -i rekeylimit as root. Expected output:
rekeylimit 536870912 3600
536870912 is 512 MiB in bytes and 3600 is one hour in seconds. An unhardened host prints rekeylimit 0 0 (cipher default, no time limit).
Inspect & investigate
Rekeying is not logged at the default LogLevel INFO: it is a transparent, in-band renegotiation. sshd only traces it at debug level (rekeying %s, input ... bytes, rekey after %llu blocks), and the client shows the same with ssh -vv. There is therefore no audit line to hunt for: the enforceable evidence is the effective rekeylimit value itself.
Remediation
The Pavois harden plan uses the sshd_setting resource to set the directive rekeylimit to 512M 1h in the Pavois drop-in under /etc/ssh/sshd_config.d/. The file is validated with sshd -t -f <file> before being kept, and a change notifies a reload of ssh.service. The daemon then reports the value as 536870912 3600, which is what the check matches.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | rekeylimit |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | 512M 1h |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without a rekey limit, one set of keys can protect an unbounded volume of data for the whole life of a session (weeks, for a screen or tmux over SSH): a key recovered by an attacker decrypts everything from then on, and long-lived sessions accumulate ciphertext under a single key. Applying the limit costs a short renegotiation every 512 MB or every hour: negligible CPU on hardware with AES-NI, but measurable on large sustained SFTP transfers over slow CPUs. Before applying, watch for very old or embedded SSH clients and appliances that handle a server-initiated rekey badly (sshd itself reports rekeying not supported by peer): they may drop the connection at the one-hour mark. The reload leaves current sessions on their existing parameters; the limit applies to new sessions.