The Secure Shell (SSH) Session Channel Break Extension
Extracted elements (15)
The 3000 ms upper bound on BREAK duration is a safeguard: a uint32 break-length field could encode up to ~49.7 days of BREAK time, which would render the attached serial port completely unavailable for that duration. Applications requiring longer BREAKs may ignore the suggestion.
The absence of a BREAK signal facility in SSH session channels forced users to continue using Telnet for 'Console Server' applications, where a BREAK signal is required to access privileged administrative functions on asynchronous serial console ports. This extension was created to fill that gap.
When SSH sessions cascade (e.g., a Telnet session from an SSH shell, or an SSH client from a Telnet connection), BREAK signals SHOULD be propagated through the entire chain to maintain consistent terminal behavior.
If a BREAK duration request greater than 3000 ms is received, it SHOULD be interpreted as a request for a 3000 ms BREAK, to prevent an unreasonably long BREAK from making a port unavailable for up to 49.7 days.
If a BREAK duration request of less than 500 ms is received, it SHOULD be interpreted as a 500 ms BREAK, since most devices will recognize a BREAK of that length.
If the application receiving the break request cannot control the BREAK length, the break-length parameter SHOULD be ignored and the default BREAK signal length of the chipset or underlying chipset driver SHOULD be sent.
If the break-length parameter is 0, the BREAK SHOULD be interpreted as the default BREAK signal length of the chipset or underlying chipset driver; if no default exists, 500 ms can be used.
If the SSH connection does not terminate on a physical serial port, the BREAK indication SHOULD be handled in a manner consistent with the general use of BREAK as an attention/interrupt signal.
If the want_reply boolean is set, the server MUST reply using SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE. If a BREAK of any kind was performed, SSH_MSG_CHANNEL_SUCCESS MUST be sent; if no BREAK was performed, SSH_MSG_CHANNEL_FAILURE MUST be sent.
In a case where an SSH connection cascades to another connection, the BREAK SHOULD be passed along the cascaded connection; for example, an SSH client initiated from a Telnet connection SHOULD pass a BREAK indication from the Telnet connection.
The break operation SHOULD be supported by any general purpose SSH client.
IANA assigned the Connection Protocol Channel Request Name "break" in the SSH protocol assigned numbers registry (RFC 4250) to identify this session channel break extension request.
Implementations that literally interpret the BREAK length parameter without imposing the suggested 3000 ms time limit may cause a denial of service to or unexpected results from attached devices receiving a very long BREAK signal.
Many systems treat serial consoles as local and secured and interpret a BREAK signal as an instruction to halt the OS or enter privileged configuration modes. SSH access to BREAK-enabled ports MUST be limited to users with appropriate privileges, or BREAK support MAY be made configurable per-port or per-server.
The break channel request is sent as SSH_MSG_CHANNEL_REQUEST with fields: uint32 recipient channel, string "break", boolean want_reply, and uint32 break-length in milliseconds.