RFC 4335

The Secure Shell (SSH) Session Channel Break Extension

📅 published January 2006, from ietf

RFC 4335: The Secure Shell (SSH) Session Channel Break Extension 🎀

Title block, the tea ☕

  • Authors: J. Galbraith (VanDyke Software) and P. Remaker (Cisco Systems, Inc) 💅
  • Category: Standards Track ✨
  • Date: January 2006 🌸
  • Obsoletes / Updates: the title block doesn't list either one 🙈

Okay bestie, this one is a Standards Track doc, which means it's an actual protocol spec people are supposed to implement. So every detail matters, no skipping 😭

Status of This Memo 🌈

So this document is an Internet standards track protocol, and the authors are asking the community for discussion and suggestions. If you want the current standardization state of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🫶

Copyright (C) The Internet Society (2006).

Abstract 🦋

The Session Channel Break Extension gives you a way to send a BREAK signal over a Secure Shell (SSH) terminal session. Slay 🔥

Table of Contents 🧚

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. The Break Request ...............................................3
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. References ......................................................4
   6.1. Normative References .......................................4
   6.2. Informative References .....................................5

1. Introduction ✨

Okay so SSH's session channel lets a client-user type commands and get output back from a remote host, and they get the SSH transport's privacy and integrity features too. Main character energy. SSH is really taking over from Telnet for terminal access, and it's giving "replacement era" 💖 [5] is where that session channel is described.

Now, Telnet has this thing called a "Console Server" [7]. A Telnet Network Virtual Terminal (NVT) can hook up to a physical RS-232/V.24 asynchronous port. So the NVT acts like a terminal sitting right there on that port, and the physical port becomes something you can address over the network 🧚 A bunch of big computer equipment vendors offer high-level admin functions through an async serial port, and they usually expect the terminal on the other end to be able to send a BREAK signal 🔥

A BREAK signal is when the TxD signal is held in a SPACE ("0") state for longer than a whole character time. In practice, a BREAK is usually 250 to 500 ms long 🌸

Telnet can send a "BREAK" too. RFC 854 [1] describes it as "a signal outside the USASCII set which is currently given local meaning within many systems". Console Server vendors read the TELNET BREAK as a physical BREAK, and that's how you get into the full set of admin functions on an async serial console port 👑

Here's the problem though. SSH session channels don't have an equivalent, so people have been stuck using Telnet for the "Console Server" job. Not ideal, bestie 💀

2. Conventions Used in This Document 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. Those are the BCP 14 vibes, so read them carefully 🎀

The "byte", "boolean", "uint32", and "string" data types are defined in [3]. Those are the building blocks we're using 🧱

3. The Break Request 🦋

This channel-specific request goes over a session channel (as described in [4]) and asks the remote host to do a BREAK operation. Here's the shape of it:

     byte      SSH_MSG_CHANNEL_REQUEST
     uint32    recipient channel
     string    "break"
     boolean   want_reply
     uint32    break-length in milliseconds

Okay, the BREAK length part is where things get spicy 🌶️

If the application getting this request can't control the BREAK length, then the BREAK length parameter SHOULD be ignored, and the default BREAK signal length of the chipset or underlying chipset driver SHOULD be sent. Not your call, chipset 😤

If the application can control the BREAK length, here are the suggestions. If a BREAK duration request is greater than 3000 ms, it SHOULD be interpreted as a request for a 3000 ms BREAK. This safeguard stops an unreasonably long BREAK from knocking a port out for as long as 49.7 days while the BREAK runs. Apps that need a longer BREAK can choose to ignore this suggestion 💅

If a BREAK duration request is less than 500 ms, it SHOULD be interpreted as a 500 ms BREAK, since most devices will recognize a BREAK that long. Apps that need a shorter BREAK can choose to ignore this suggestion too ✨

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 there's no default, 500 ms can be used as the BREAK length 🍓

If the SSH connection doesn't end on a physical serial port, the BREAK indication SHOULD be handled in a way that matches how BREAK is generally used as an attention/interrupt signal. For example, a service processor that needs an out-of-band way to get the attention of a system it manages 🧚

When an SSH connection cascades into another connection, the BREAK SHOULD be passed along the cascaded connection. For example, a Telnet session started from an SSH shell should carry along an SSH-initiated BREAK, and an SSH client started from a Telnet connection SHOULD pass along a BREAK indication from that Telnet connection. Chain reaction, iconic 🦋

If the 'want_reply' boolean is set, the server MUST reply using an SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be sent. No ghosting allowed 🫶

Last thing: this operation SHOULD be supported by any general purpose SSH client. It's giving "universal support" 🌈

4. Security Considerations 💀

⚠️ Okay bestie, this section is serious. Read every word.

Lots of computer systems treat serial consoles as local and secured. They read a BREAK signal as an instruction to halt the operating system or jump into privileged configuration modes. Because of that, extra care should be taken to make sure SSH access to BREAK-enabled ports is limited to users who have the right privileges to run those functions. Or, support for the BREAK facility MAY be implemented as configurable on a per-port or per-server basis 🔐

Implementations that take the BREAK length parameter literally, without the suggested BREAK time limit, may cause a denial of service to attached devices that receive that very long BREAK signal, or cause unexpected results from them 😱

5. IANA Considerations 🌸

IANA has assigned the Connection Protocol Channel Request Name "break" in accordance with [6]. Registered and official 📜

6. References 📚

6.1. Normative References 💜

  • [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
  • [4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
  • [5] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
  • [6] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.

6.2. Informative References 🧚

Authors' Addresses 🎀

Here are the authors' contact details, copied exactly:

Joseph Galbraith
VanDyke Software
4848 Tramway Ridge Blvd
Suite 101
Albuquerque, NM  87111
US

Phone: +1 505 332 5700
EMail: galb-list@vandyke.com


Phillip Remaker
Cisco Systems, Inc
170 West Tasman Drive
San Jose, CA  95120
US

Phone: +1 408 526 8614
EMail: remaker@cisco.com

Here's the legal stuff, kept word for word:

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

Same deal here, the IPR boilerplate stays exact:

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thank you, IASA 🫶

📦 where this page comes from