OpenSSH has a parameter in the config files (ssh_config and sshd_config) for both client and server called RekeyLimit.

The default values for it are:

RekeyLimit 1G 1h

Which will force a rekey after 1Gbyte of data has been sent using the current key of after 1h has passed since the last key was generated.

But rfc4344 make some recommendations about rekeying which refer to number of packets:

   Because of possible information leakage through the MAC tag, SSH
   implementations SHOULD rekey at least once every 2**32 outgoing
   packets.  More explicitly, after a key exchange, an SSH
   implementation SHOULD NOT send more than 2**32 packets before
   rekeying again.

Is it possible to tell OpenSSH to force a rekey according to number of packets instead of number of bytes?

  • why? What are you trying to accomplish?
    – Jakuje
    Commented Apr 27, 2016 at 16:03
  • @Jakuje compliance with a standard that specifies just that: a rekey has to happen for every 2^28 packets.
    – Pandrei
    Commented Apr 28, 2016 at 8:31

2 Answers 2


Your answer is partially addressed in the SSH man page:

     Specifies the maximum amount of data that may be transmitted
     before the session key is renegotiated, optionally followed a
     maximum amount of time that may pass before the session key is
     renegotiated.  The first argument is specified in bytes and may
     have a suffix of `K', `M', or `G' to indicate Kilobytes,
     Megabytes, or Gigabytes, respectively.  The default is between
     `1G' and `4G', depending on the cipher.  The optional second
     value is specified in seconds and may use any of the units docu-
     mented in the TIME FORMATS section.  The default value for
     RekeyLimit is ``default none'', which means that rekeying is per-
     formed after the cipher's default amount of data has been sent or
     received and no time based rekeying is done.

A default is already set to 1Gig and 4Gigs of data but what does that mean? If you're sending small packets, it would take a long time to rekey, if you're sending large packets, the re-keying would occur more frequently. So let me ask: "What do you think your goal is in setting this to packet amounts would accomplish?"

Rekeying was done so that no one could store/obtain/sniff chunks of data for cryptanalysis attacks. (And or side channel attacks). There is a cost to performing these types of attacks: Storage, time, knowledge of encryption/cryptanalysis. Outside of nation state sponsored programs to attack this, I have yet to see, read, or hear about a non state actor even attempting to pull this off. There are other ways to attack a system.

But to answer your question, there is no definitive method listed to do this (packet based rekeying) so you have an option: Baseline your traffic, divide total data sent, by packets sent, then use that as your rekey number. E.g. 1Gig of traffic / 1000 packets(average amount of packets it took to send 1Gig) = Rekey number.

  • It is important to set the limit in packets because of rfc4344 recommendation and FCS_SSHC_EXT.1.8 in this document niap-ccevs.org/pp/cpp_nd_v1.0.pdf. Plus CISCO do the same thing: ip ssh rekey volume 500 sets the number of packet to be transmitted before a rekey.
    – Pandrei
    Commented Apr 27, 2016 at 12:30
  • Please re-read what is says, the answer was given to you. In OpenSSH, by DEFAULT this was ALREADY PROGRAMMED and is modified by changing the rekeylimit: The default is between "1G' and 4G', depending on the cipher" This means not matter the packet amount it will be changed. At some point OpenSSH developers felt that no matter the amount of packets, it would be the VOLUME OF DATA that would play the most critical part of the attack.
    – munkeyoto
    Commented Apr 27, 2016 at 12:34
  • while I can understand the "between 1G and 4G depending on the cipher", and the reason to choose amount of traffic over amount of packets, it does not help when you want to prove you are complaint with a standard which specifies: no mode than N packets can be encrypted using the same key.
    – Pandrei
    Commented Apr 27, 2016 at 12:42
  • 1
    @Pandrei "Standards consist of specific low level mandatory controls that help enforce and support the information security policy." OpenSSH was written to RFC specs (which IS THE STANDARD). I have NEVER EVER EVER in my career see an organization be OUT of compliance with default out of the box OpenSSH installed which is the case on hundreds of thousands or routers (JunOS, IOS, etc), systems (RHEL, Solaris, etc). So I think your interpretation of things is off.
    – munkeyoto
    Commented Apr 27, 2016 at 12:52

I realize this is an old question, but others may stumble upon it. @Pandrei's question is legit for users of Common Criteria. However, as @munkeyoto indicates, OpenSSH gives you handles to play with the data volume. What @Pandrei didn't seem to understand was that at 1 GB of data, this is 2^28 packets given the smallest possible packet size in the SSH protocol for a specific encryption algorithm (16 bytes). So if you set the data limit at 1GB, then you would automatically be in compliance with the NDcPP CC protection profile. The number of packets is inconsequential since you can just do math to figure out whatever number of packets that is depending on the encryption algorithm that was negotiated. Specifically, see section 9.3.2 of RFC 4251:

Because MACs use a 32-bit sequence number, they might start to leak information after 2^32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [SSH-TRANS] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2^28 packets at the very most.

In the end, this is moot, since v2.0 of the NDcPP will replace the need for packet-based rekeying with data- and time-based limits as per the RFC recommendations.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .