Key re-exchange is started by sending an SSH_MSG_KEXINIT packet while not already doing a key exchange. When this message is received, a party must respond with its own SSH_MSG_KEXINIT message, except in cases where the received SSH_MSG_KEXINIT already was a reply. Either party may initiate the re-exchange, but roles must not be changed (for example, the server remains the server, and the client remains the client).
Key re-exchange is performed using whatever encryption was in effect when the exchange was started. Encryption, compression, and MAC methods are not changed before a new SSH_MSG_NEWKEYS is sent after the key exchange (as in the initial key exchange). Re-exchange is processed identically to the initial key exchange, except that the session identifier remains unchanged. Some or all of the algorithms can be changed during the re-exchange. Host keys can also change. All keys and initialization vectors are recomputed after the exchange. Compression and encryption contexts are reset.
RFC 4253 recommends key exchange after every hour or 1Gbytes of transmitted data, which is met by SR OS default implementation.
SR OS can roll over keys via two mechanisms:
bytes (default is 1 Gbyte and the keys are negotiated)
minutes (default is 1 minute)
If both the bytes and minutes key rollover mechanisms are configured, the key rollover happens based on whichever occurs first.
If these parameters change, only new SSH connections inherit them. The existing SSH connections continue to use the previously configured parameters.