RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 4254, "The Secure Shell (SSH) Connection Protocol", January 2006

Note: This RFC has been updated by RFC 8308

Source of RFC: secsh (sec)

Errata ID: 6850
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Hamid Nazari
Date Reported: 2022-02-14
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section 5.1 says:

Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
values (and associated 'description' text) in the range of 0x00000005
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].  The IANA will not assign Channel Connection
Failure 'reason code' values in the range of 0xFE000000 to
0xFFFFFFFF.  Channel Connection Failure 'reason code' values in that
range are left for PRIVATE USE, as described in [RFC2434].


It should say:

Requests for assignments of new SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code'
values (and associated 'description' text) in the range of 0x00000005
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].  The IANA will not assign Channel Connection
Failure 'reason code' values in the range of 0xFE000000 to
0xFFFFFFFF.  Channel Connection Failure 'reason code' values in that
range are left for PRIVATE USE, as described in [RFC2434].

Notes:

The 'reason code' is present on SSH_MSG_CHANNEL_OPEN_FAILURE message to denote cause of the failure while original text attributes it to SSH_MSG_CHANNEL_OPEN by mistake.

Errata ID: 3878
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jim Wigginton
Date Reported: 2014-02-02
Verifier Name: Stephen Farrell
Date Verified: 2015-05-12

Section 5.2 says:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the amount of data
   sent.  Both parties MAY ignore all extra data sent after the allowed
   window is empty.

It should say:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the length of the data
   sent, length field included.  Both parties MAY ignore all extra data
   sent after the allowed window is empty.

Notes:

This is the data transfer packet:

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data

Since string's are defined by RFC4251 as being "stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string" it's unclear weather or not the uint32 length field contributes to the total or not. In my interoperability testing it seems that it does but it doesn't seem that this is all that clear from this RFC.

It is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. A strict interpretation would suggest it does not since the RFC makes no mention of it.

Status: Held for Document Update (1)

RFC 4254, "The Secure Shell (SSH) Connection Protocol", January 2006

Note: This RFC has been updated by RFC 8308

Source of RFC: secsh (sec)

Errata ID: 3877
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jim Wigginton
Date Reported: 2014-02-02
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-07-01

Section 6.10 says:

6.10.  Returning Exit Status

   When the command running at the other end terminates, the following
   message can be sent to return the exit status of the command.
   Returning the status is RECOMMENDED.  No acknowledgement is sent for
   this message.  The channel needs to be closed with
   SSH_MSG_CHANNEL_CLOSE after this message.

   The client MAY ignore these messages.

It should say:

6.10.  Returning Exit Status

   When the command running at the other end terminates, the following
   message can be sent to return the exit status of the command.
   Returning the status is RECOMMENDED.  No acknowledgement is sent for
   this message.  The channel needs to be closed by the server with
   SSH_MSG_CHANNEL_CLOSE after this message.

   The client MAY ignore these messages.

Notes:

Even though it can arguably be inferred from the text as written I think it'd make it more clear if the RFC explicitly said that the server is the one that should be sending the SSH_MSG_CHANNEL_CLOSE message.

Report New Errata



Advanced Search