draft-ietf-secsh-connect-19.txt   draft-ietf-secsh-connect-20.txt 
Network Working Group T. Ylonen Network Working Group C. Lonvick, Ed.
Internet-Draft SSH Communications Security Corp Internet-Draft Cisco Systems, Inc
Expires: December 1, 2004 C. Lonvick, Ed. Expires: April 24, 2005 October 24, 2004
Cisco Systems, Inc
June 2, 2004
SSH Connection Protocol SSH Connection Protocol
draft-ietf-secsh-connect-19.txt draft-ietf-secsh-connect-20.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2004. This Internet-Draft will expire on April 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network
services over an insecure network. services over an insecure network.
This document describes the SSH Connection Protocol. It provides This document describes the SSH Connection Protocol. It provides
interactive login sessions, remote execution of commands, forwarded interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these TCP/IP connections, and forwarded X11 connections. All of these
channels are multiplexed into a single encrypted tunnel. channels are multiplexed into a single encrypted tunnel.
skipping to change at page 2, line 12 skipping to change at page 2, line 15
The SSH Connection Protocol has been designed to run on top of the The SSH Connection Protocol has been designed to run on top of the
SSH transport layer and user authentication protocols. SSH transport layer and user authentication protocols.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Global Requests . . . . . . . . . . . . . . . . . . . . . . . 3 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . . 3
5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . 4
5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . 4 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . 5
5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . 6 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . 6
5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . 6 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . 7
5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . 7 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . 8
6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . 8 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . 8
6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . 8 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . 9
6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . 8 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . 9
6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . 9 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . 9
6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . 9 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . 9
6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . 10 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . 10
6.4 Environment Variable Passing . . . . . . . . . . . . . . . 10 6.4 Environment Variable Passing . . . . . . . . . . . . . . . 11
6.5 Starting a Shell or a Command . . . . . . . . . . . . . . 10 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . 11
6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . 11 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . 12
6.7 Window Dimension Change Message . . . . . . . . . . . . . 12 6.7 Window Dimension Change Message . . . . . . . . . . . . . 12
6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . 12 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . 13
6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . 13 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . 13
7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . 14 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . 15
7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . 14 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . 15
7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . 15 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . 16
8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . 16 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . 17
9. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 18 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
12.2 Informative References . . . . . . . . . . . . . . . . . . . 19 12.2 Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this document were: Tatu Ylonen,
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffit was the original editor of (University of Jyvaskyla). Darren Moffit was the original editor of
this document and also made very substantial contributions. this document and also made very substantial contributions.
Additional contributors to this document include [need list]. Additional contributors to this document include [need list].
skipping to change at page 3, line 37 skipping to change at page 3, line 37
TCP/IP connections, and forwarded X11 connections. The service name TCP/IP connections, and forwarded X11 connections. The service name
for this protocol is "ssh-connection". for this protocol is "ssh-connection".
This document should be read only after reading the SSH architecture This document should be read only after reading the SSH architecture
document [SSH-ARCH]. This document freely uses terminology and document [SSH-ARCH]. This document freely uses terminology and
notation from the architecture document without reference or further notation from the architecture document without reference or further
explanation. explanation.
3. Conventions Used in This Document 3. Conventions Used in This Document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", All documents related to the SSH protocols shall use the keywords
and "MAY" that appear in this document are to be interpreted as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
described in [RFC2119]. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in
The used data types and terminology are specified in the architecture [RFC2119].
document [SSH-ARCH].
The architecture document also discusses the algorithm naming The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
conventions that MUST be used with the SSH protocols. FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434].
4. Global Requests 4. Global Requests
There are several kinds of requests that affect the state of the There are several kinds of requests that affect the state of the
remote end "globally", independent of any channels. An example is a remote end globally, independent of any channels. An example is a
request to start TCP/IP forwarding for a specific port. All such request to start TCP/IP forwarding for a specific port. All such
requests use the following format. requests use the following format.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string request name in US-ASCII only string request name in US-ASCII only
boolean want reply boolean want reply
... request-specific data follows ... request-specific data follows
Request names follow the DNS extensibility naming convention outlined The value of 'request name' follows the DNS extensibility naming
in [SSH-ARCH]. convention outlined in [SSH-ARCH].
The recipient will respond to this message with The recipient will respond to this message with
SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is
TRUE. TRUE.
byte SSH_MSG_REQUEST_SUCCESS byte SSH_MSG_REQUEST_SUCCESS
..... response specific data ..... response specific data
Usually the response specific data is non-existent. Usually the 'response specific data' is non-existent.
If the recipient does not recognize or support the request, it simply If the recipient does not recognize or support the request, it simply
responds with SSH_MSG_REQUEST_FAILURE. responds with SSH_MSG_REQUEST_FAILURE.
byte SSH_MSG_REQUEST_FAILURE byte SSH_MSG_REQUEST_FAILURE
In general, the reply messages do not include request type
identifiers. To make it possible for the originator of a request to
identify to which request each reply refers, it is REQUIRED that
replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as
the corresponding request messages. For channel requests, replies
that relate to the same channel MUST also be replied to in the right
order. However, channel requests for distinct channels MAY be
replied to out-of-order.
5. Channel Mechanism 5. Channel Mechanism
All terminal sessions, forwarded connections, etc. are channels. All terminal sessions, forwarded connections, etc., are channels.
Either side may open a channel. Multiple channels are multiplexed Either side may open a channel. Multiple channels are multiplexed
into a single connection. into a single connection.
Channels are identified by numbers at each end. The number referring Channels are identified by numbers at each end. The number referring
to a channel may be different on each side. Requests to open a to a channel may be different on each side. Requests to open a
channel contain the sender's channel number. Any other channel contain the sender's channel number. Any other
channel-related messages contain the recipient's channel number for channel-related messages contain the recipient's channel number for
the channel. the channel.
Channels are flow-controlled. No data may be sent to a channel until Channels are flow-controlled. No data may be sent to a channel until
skipping to change at page 5, line 8 skipping to change at page 5, line 19
other side, and includes the local channel number and initial window other side, and includes the local channel number and initial window
size in the message. size in the message.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string channel type in US-ASCII only string channel type in US-ASCII only
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
... channel type specific data follows ... channel type specific data follows
The channel type is a name as described in the SSH architecture The 'channel type' is a name as described in [SSH-ARCH] and
document, with similar extension mechanisms. `sender channel' is a [SSH-NUMBERS], with similar extension mechanisms. The 'sender
local identifier for the channel used by the sender of this message. channel' is a local identifier for the channel used by the sender of
`initial window size' specifies how many bytes of channel data can be this message. The 'initial window size' specifies how many bytes of
sent to the sender of this message without adjusting the window. channel data can be sent to the sender of this message without
`Maximum packet size' specifies the maximum size of an individual adjusting the window. The 'maximum packet size' specifies the
data packet that can be sent to the sender (for example, one might maximum size of an individual data packet that can be sent to the
want to use smaller packets for interactive connections to get better sender. For example, one might want to use smaller packets for
interactive response on slow links). interactive connections to get better interactive response on slow
links.
The remote side then decides whether it can open the channel, and The remote side then decides whether it can open the channel, and
responds with either responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
SSH_MSG_CHANNEL_OPEN_FAILURE.
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel uint32 recipient channel
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
... channel type specific data follows ... 'channel type' specific data follows
The 'recipient channel' is the channel number given in the original
open request, and 'sender channel' is the channel number allocated by
the other side.
where `recipient channel' is the channel number given in the original
open request, and `sender channel' is the channel number allocated by
the other side, or
byte SSH_MSG_CHANNEL_OPEN_FAILURE byte SSH_MSG_CHANNEL_OPEN_FAILURE
uint32 recipient channel uint32 recipient channel
uint32 reason code uint32 reason code
string additional textual information in ISO-10646 UTF-8 string description in ISO-10646 UTF-8 encoding [RFC3629]
encoding [RFC2279]
string language tag as defined in [RFC3066] string language tag as defined in [RFC3066]
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support
the specified channel type, it simply responds with the specified 'channel type', it simply responds with
SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the 'description'
information to the user. If this is done, the client software should string to the user. If this is done, the client software should take
take the precautions discussed in [SSH-ARCH]. the precautions discussed in [SSH-ARCH].
The following reason codes are defined: The following 'reason code' values are defined:
#define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 description reason code
#define SSH_OPEN_CONNECT_FAILED 2 ----------- -----------
#define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
#define SSH_OPEN_RESOURCE_SHORTAGE 4 SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
values (and associated 'description' text) in the range of 0x00000001
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as
described in [RFC2434]. The SSH_MSG_CHANNEL_OPEN 'reason code'
values in the range of 0xFE000000 to 0xFEFFFFFF are reserved for
PRIVATE USE. The SSH_MSG_CHANNEL_OPEN 'reason code' values in the
range of 0xFF000000 to 0xFFFFFFFF are also reserved for PRIVATE USE
as described in [RFC2434]. As is noted, the actual instructions to
the IANA is in [SSH-NUMBERS].
5.2 Data Transfer 5.2 Data Transfer
The window size specifies how many bytes the other party can send The window size specifies how many bytes the other party can send
before it must wait for the window to be adjusted. Both parties use before it must wait for the window to be adjusted. Both parties use
the following message to adjust the window. the following message to adjust the window.
byte SSH_MSG_CHANNEL_WINDOW_ADJUST byte SSH_MSG_CHANNEL_WINDOW_ADJUST
uint32 recipient channel uint32 recipient channel
uint32 bytes to add uint32 bytes to add
skipping to change at page 6, line 45 skipping to change at page 7, line 19
byte SSH_MSG_CHANNEL_EXTENDED_DATA byte SSH_MSG_CHANNEL_EXTENDED_DATA
uint32 recipient_channel uint32 recipient_channel
uint32 data_type_code uint32 data_type_code
string data string data
Data sent with these messages consumes the same window as ordinary Data sent with these messages consumes the same window as ordinary
data. data.
Currently, only the following type is defined. Currently, only the following type is defined.
#define SSH_EXTENDED_DATA_STDERR 1 data data_type_code
---- --------------
SSH_EXTENDED_DATA_STDERR 1
5.3 Closing a Channel 5.3 Closing a Channel
When a party will no longer send more data to a channel, it SHOULD When a party will no longer send more data to a channel, it SHOULD
send SSH_MSG_CHANNEL_EOF. send SSH_MSG_CHANNEL_EOF.
byte SSH_MSG_CHANNEL_EOF byte SSH_MSG_CHANNEL_EOF
uint32 recipient_channel uint32 recipient_channel
No explicit response is sent to this message; however, the No explicit response is sent to this message. However, the
application may send EOF to whatever is at the other end of the application may send EOF to whatever is at the other end of the
channel. Note that the channel remains open after this message, and channel. Note that the channel remains open after this message, and
more data may still be sent in the other direction. This message more data may still be sent in the other direction. This message
does not consume window space and can be sent even if no window space does not consume window space and can be sent even if no window space
is available. is available.
When either party wishes to terminate the channel, it sends When either party wishes to terminate the channel, it sends
SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST
send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this
message for the channel. The channel is considered closed for a message for the channel. The channel is considered closed for a
skipping to change at page 7, line 35 skipping to change at page 8, line 11
uint32 recipient_channel uint32 recipient_channel
This message does not consume window space and can be sent even if no This message does not consume window space and can be sent even if no
window space is available. window space is available.
It is recommended that any data sent before this message is delivered It is recommended that any data sent before this message is delivered
to the actual destination, if possible. to the actual destination, if possible.
5.4 Channel-Specific Requests 5.4 Channel-Specific Requests
Many channel types have extensions that are specific to that Many 'channel type' values have extensions that are specific to that
particular channel type. An example is requesting a pty (pseudo particular 'channel type'. An example is requesting a pty (pseudo
terminal) for an interactive session. terminal) for an interactive session.
All channel-specific requests use the following format. All channel-specific requests use the following format.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string request type in US-ASCII characters only string request type in US-ASCII characters only
boolean want reply boolean want reply
... type-specific data ... type-specific data
If want reply is FALSE, no response will be sent to the request. If 'want reply' is FALSE, no response will be sent to the request.
Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
messages. If the request is not recognized or is not supported for messages. If the request is not recognized or is not supported for
the channel, SSH_MSG_CHANNEL_FAILURE is returned. the channel, SSH_MSG_CHANNEL_FAILURE is returned.
This message does not consume window space and can be sent even if no This message does not consume window space and can be sent even if no
window space is available. Request types are local to each channel window space is available. The values of 'request type' are local to
type. each channel type.
The client is allowed to send further messages without waiting for The client is allowed to send further messages without waiting for
the response to the request. the response to the request.
request type names follow the DNS extensibility naming convention 'request type' names follow the DNS extensibility naming convention
outlined in [SSH-ARCH] outlined in [SSH-ARCH] and [SSH-NUMBERS].
byte SSH_MSG_CHANNEL_SUCCESS byte SSH_MSG_CHANNEL_SUCCESS
uint32 recipient_channel uint32 recipient_channel
byte SSH_MSG_CHANNEL_FAILURE byte SSH_MSG_CHANNEL_FAILURE
uint32 recipient_channel uint32 recipient_channel
These messages do not consume window space and can be sent even if no These messages do not consume window space and can be sent even if no
window space is available. window space is available.
skipping to change at page 9, line 13 skipping to change at page 9, line 38
uint32 recipient_channel uint32 recipient_channel
string "pty-req" string "pty-req"
boolean want_reply boolean want_reply
string TERM environment variable value (e.g., vt100) string TERM environment variable value (e.g., vt100)
uint32 terminal width, characters (e.g., 80) uint32 terminal width, characters (e.g., 80)
uint32 terminal height, rows (e.g., 24) uint32 terminal height, rows (e.g., 24)
uint32 terminal width, pixels (e.g., 640) uint32 terminal width, pixels (e.g., 640)
uint32 terminal height, pixels (e.g., 480) uint32 terminal height, pixels (e.g., 480)
string encoded terminal modes string encoded terminal modes
The encoding of terminal modes is described in Section Encoding of The 'encoded terminal modes' are described in Section 8. Zero
Terminal Modes (Section 8). Zero dimension parameters MUST be dimension parameters MUST be ignored. The character/row dimensions
ignored. The character/row dimensions override the pixel dimensions override the pixel dimensions (when nonzero). Pixel dimensions refer
(when nonzero). Pixel dimensions refer to the drawable area of the to the drawable area of the window.
window.
The dimension parameters are only informational. The dimension parameters are only informational.
The client SHOULD ignore pty requests. The client SHOULD ignore pty requests.
6.3 X11 Forwarding 6.3 X11 Forwarding
6.3.1 Requesting X11 Forwarding 6.3.1 Requesting X11 Forwarding
X11 forwarding may be requested for a session by sending X11 forwarding may be requested for a session by sending a
SSH_MSG_CHANNEL_REQUEST message.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "x11-req" string "x11-req"
boolean want reply boolean want reply
boolean single connection boolean single connection
string x11 authentication protocol string x11 authentication protocol
string x11 authentication cookie string x11 authentication cookie
uint32 x11 screen number uint32 x11 screen number
It is recommended that the authentication cookie that is sent be a It is RECOMMENDED that the 'x11 authentication cookie' that is sent
fake, random cookie, and that the cookie is checked and replaced by be a fake, random cookie, and that the cookie is checked and replaced
the real cookie when a connection request is received. by the real cookie when a connection request is received.
X11 connection forwarding should stop when the session channel is X11 connection forwarding should stop when the session channel is
closed; however, already opened forwardings should not be closed. However, already opened forwardings should not be
automatically closed when the session channel is closed. automatically closed when the session channel is closed.
If `single connection' is TRUE, only a single connection should be If 'single connection' is TRUE, only a single connection should be
forwarded. No more connections will be forwarded after the first, or forwarded. No more connections will be forwarded after the first, or
after the session channel has been closed. after the session channel has been closed.
The "x11 authentication protocol" is the name of the X11 The 'x11 authentication protocol' is the name of the X11
authentication method used, e.g. "MIT-MAGIC-COOKIE-1". authentication method used, e.g. "MIT-MAGIC-COOKIE-1".
The x11 authentication cookie MUST be hexadecimal encoded. The 'x11 authentication cookie' MUST be hexadecimal encoded.
X Protocol is documented in [SCHEIFLER]. The X Protocol is documented in [SCHEIFLER].
6.3.2 X11 Channels 6.3.2 X11 Channels
X11 channels are opened with a channel open request. The resulting X11 channels are opened with a channel open request. The resulting
channels are independent of the session, and closing the session channels are independent of the session, and closing the session
channel does not close the forwarded X11 channels. channel does not close the forwarded X11 channels.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string "x11" string "x11"
uint32 sender channel uint32 sender channel
skipping to change at page 11, line 20 skipping to change at page 11, line 46
This message will request the user's default shell (typically defined This message will request the user's default shell (typically defined
in /etc/passwd in UNIX systems) to be started at the other end. in /etc/passwd in UNIX systems) to be started at the other end.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "exec" string "exec"
boolean want reply boolean want reply
string command string command
This message will request the server to start the execution of the This message will request the server to start the execution of the
given command. The command string may contain a path. Normal given command. The 'command' string may contain a path. Normal
precautions MUST be taken to prevent the execution of unauthorized precautions MUST be taken to prevent the execution of unauthorized
commands. commands.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "subsystem" string "subsystem"
boolean want reply boolean want reply
string subsystem name string subsystem name
This last form executes a predefined subsystem. It is expected that This last form executes a predefined subsystem. It is expected that
these will include a general file transfer mechanism, and possibly these will include a general file transfer mechanism, and possibly
other features. Implementations may also allow configuring more such other features. Implementations may also allow configuring more such
mechanisms. As the user's shell is usually used to execute the mechanisms. As the user's shell is usually used to execute the
subsystem, it is advisable for the subsystem protocol to have a subsystem, it is advisable for the subsystem protocol to have a
"magic cookie" at the beginning of the protocol transaction to "magic cookie" at the beginning of the protocol transaction to
distinguish it from arbitrary output generated by shell distinguish it from arbitrary output generated by shell
initialization scripts etc. This spurious output from the shell may initialization scripts, etc. This spurious output from the shell may
be filtered out either at the server or at the client. be filtered out either at the server or at the client.
The server SHOULD not halt the execution of the protocol stack when The server SHOULD NOT halt the execution of the protocol stack when
starting a shell or a program. All input and output from these starting a shell or a program. All input and output from these
SHOULD be redirected to the channel or to the encrypted tunnel. SHOULD be redirected to the channel or to the encrypted tunnel.
It is RECOMMENDED to request and check the reply for these messages. It is RECOMMENDED to request and check the reply for these messages.
The client SHOULD ignore these messages. The client SHOULD ignore these messages.
Subsystem names follow the DNS extensibility naming convention Subsystem names follow the DNS extensibility naming convention
outlined in [SSH-ARCH]. outlined in [SSH-NUMBERS].
6.6 Session Data Transfer 6.6 Session Data Transfer
Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and
SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The
extended data type SSH_EXTENDED_DATA_STDERR has been defined for extended data type SSH_EXTENDED_DATA_STDERR has been defined for
stderr data. stderr data.
6.7 Window Dimension Change Message 6.7 Window Dimension Change Message
skipping to change at page 12, line 22 skipping to change at page 12, line 49
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient_channel uint32 recipient_channel
string "window-change" string "window-change"
boolean FALSE boolean FALSE
uint32 terminal width, columns uint32 terminal width, columns
uint32 terminal height, rows uint32 terminal height, rows
uint32 terminal width, pixels uint32 terminal width, pixels
uint32 terminal height, pixels uint32 terminal height, pixels
No response SHOULD be sent to this message. A response SHOULD NOT be sent to this message.
6.8 Local Flow Control 6.8 Local Flow Control
On many systems, it is possible to determine if a pseudo-terminal is On many systems, it is possible to determine if a pseudo-terminal is
using control-S/control-Q flow control. When flow control is using control-S/control-Q flow control. When flow control is
allowed, it is often desirable to do the flow control at the client allowed, it is often desirable to do the flow control at the client
end to speed up responses to user requests. This is facilitated by end to speed up responses to user requests. This is facilitated by
the following notification. Initially, the server is responsible for the following notification. Initially, the server is responsible for
flow control. (Here, again, client means the side originating the flow control. (Here, again, client means the side originating the
session, and server means the other side.) session, and server means the other side.)
The message below is used by the server to inform the client when it The message below is used by the server to inform the client when it
can or cannot perform flow control (control-S/control-Q processing). can or cannot perform flow control (control-S/control-Q processing).
If `client can do' is TRUE, the client is allowed to do flow control If 'client can do' is TRUE, the client is allowed to do flow control
using control-S and control-Q. The client MAY ignore this message. using control-S and control-Q. The client MAY ignore this message.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "xon-xoff" string "xon-xoff"
boolean FALSE boolean FALSE
boolean client can do boolean client can do
No response is sent to this message. No response is sent to this message.
skipping to change at page 13, line 32 skipping to change at page 14, line 13
The client MAY ignore these messages. The client MAY ignore these messages.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient_channel uint32 recipient_channel
string "exit-status" string "exit-status"
boolean FALSE boolean FALSE
uint32 exit_status uint32 exit_status
The remote command may also terminate violently due to a signal. The remote command may also terminate violently due to a signal.
Such a condition can be indicated by the following message. A zero Such a condition can be indicated by the following message. A zero
exit_status usually means that the command terminated successfully. 'exit_status' usually means that the command terminated successfully.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "exit-signal" string "exit-signal"
boolean FALSE boolean FALSE
string signal name without the "SIG" prefix. string signal name without the "SIG" prefix.
boolean core dumped boolean core dumped
string error message in ISO-10646 UTF-8 encoding string error message in ISO-10646 UTF-8 encoding
string language tag as defined in [RFC3066] string language tag as defined in [RFC3066]
The signal name is one of the following (these are from [POSIX]) The 'signal name' is one of the following (these are from [POSIX])
ABRT ABRT
ALRM ALRM
FPE FPE
HUP HUP
ILL ILL
INT INT
KILL KILL
PIPE PIPE
QUIT QUIT
SEGV SEGV
TERM TERM
USR1 USR1
USR2 USR2
Additional signal names MAY be sent in the format "sig-name@xyz", Additional 'signal name' values MAY be sent in the format
where `sig-name' and `xyz' may be anything a particular implementor "sig-name@xyz", where "sig-name" and "xyz" may be anything a
wants (except the `@' sign). However, it is suggested that if a particular implementor wants (except the "@" sign). However, it is
`configure' script is used, the non-standard signal names it finds be suggested that if a 'configure' script is used, any non-standard
encoded as "SIG@xyz.config.guess", where `SIG' is the signal name 'signal name' values it finds be encoded as "SIG@xyz.config.guess",
without the "SIG" prefix, and `xyz' be the host type, as determined where "SIG" is the 'signal name' without the "SIG" prefix, and "xyz"
by `config.guess'. be the host type, as determined by "config.guess".
The `error message' contains an additional explanation of the error The 'error message' contains an additional textual explanation of the
message. The message may consist of multiple lines. The client error message. The message may consist of multiple lines. The
software MAY display this message to the user. If this is done, the client software MAY display this message to the user. If this is
client software should take the precautions discussed in [SSH-ARCH]. done, the client software should take the precautions discussed in
[SSH-ARCH].
7. TCP/IP Port Forwarding 7. TCP/IP Port Forwarding
7.1 Requesting Port Forwarding 7.1 Requesting Port Forwarding
A party need not explicitly request forwardings from its own end to A party need not explicitly request forwardings from its own end to
the other direction. However, if it wishes that connections to a the other direction. However, if it wishes that connections to a
port on the other side be forwarded to the local side, it must port on the other side be forwarded to the local side, it must
explicitly request this. explicitly request this.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string "tcpip-forward" string "tcpip-forward"
boolean want reply boolean want reply
string address to bind (e.g. "0.0.0.0") string address to bind (e.g. "0.0.0.0")
uint32 port number to bind uint32 port number to bind
`Address to bind' and `port number to bind' specify the IP address The 'address to bind' and 'port number to bind' specify the IP
and port to which the socket to be listened is bound. The address address and port to which the socket to be listened is bound. The
should be "0.0.0.0" if connections are allowed from anywhere. (Note address should be "0.0.0.0" if connections are allowed from anywhere.
that the client can still filter connections based on information (Note that the client can still filter connections based on
passed in the open request.) information passed in the open request.)
Implementations should only allow forwarding privileged ports if the Implementations should only allow forwarding privileged ports if the
user has been authenticated as a privileged user. user has been authenticated as a privileged user.
Client implementations SHOULD reject these messages; they are Client implementations SHOULD reject these messages; they are
normally only sent by the client. normally only sent by the client.
If a client passes 0 as port number to bind and has want reply TRUE If a client passes 0 as port number to bind and has 'want reply' TRUE
then the server allocates the next available unprivileged port number then the server allocates the next available unprivileged port number
and replies with the following message, otherwise there is no and replies with the following message, otherwise there is no
response specific data. response specific data.
byte SSH_MSG_GLOBAL_REQUEST_SUCCESS byte SSH_MSG_REQUEST_SUCCESS
uint32 port that was bound on the server uint32 port that was bound on the server
A port forwarding can be canceled with the following message. Note A port forwarding can be canceled with the following message. Note
that channel open requests may be received until a reply to this that channel open requests may be received until a reply to this
message is received. message is received.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string "cancel-tcpip-forward" string "cancel-tcpip-forward"
boolean want reply boolean want reply
string address_to_bind (e.g. "127.0.0.1") string address_to_bind (e.g. "127.0.0.1")
skipping to change at page 16, line 13 skipping to change at page 16, line 43
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string "direct-tcpip" string "direct-tcpip"
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
string host to connect string host to connect
uint32 port to connect uint32 port to connect
string originator IP address string originator IP address
uint32 originator port uint32 originator port
`Host to connect' and `port to connect' specify the TCP/IP host and The 'host to connect' and 'port to connect' specify the TCP/IP host
port where the recipient should connect the channel. `Host to and port where the recipient should connect the channel. The 'host
connect' may be either a domain name or a numeric IP address. to connect' may be either a domain name or a numeric IP address.
`Originator IP address' is the numeric IP address of the machine The 'originator IP address' is the numeric IP address of the machine
where the connection request comes from, and `originator port' is the where the connection request comes from, and the 'originator port' is
port on the originator host from where the connection came from. the port on the originator host from where the connection originated.
Forwarded TCP/IP channels are independent of any sessions, and Forwarded TCP/IP channels are independent of any sessions, and
closing a session channel does not in any way imply that forwarded closing a session channel does not in any way imply that forwarded
connections should be closed. connections should be closed.
Client implementations SHOULD reject direct TCP/IP open requests for Client implementations SHOULD reject direct TCP/IP open requests for
security reasons. security reasons.
8. Encoding of Terminal Modes 8. Encoding of Terminal Modes
Terminal modes (as passed in a pty request) are encoded into a byte All "encoded terminal modes" (as passed in a pty request) are encoded
stream. It is intended that the coding be portable across different into a byte stream. It is intended that the coding be portable
environments. across different environments.
The tty mode description is a stream of bytes. The stream consists The tty mode description is a stream of bytes. The stream consists
of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0). of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0).
Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255
are not yet defined, and cause parsing to stop (they should only be are not yet defined, and cause parsing to stop (they should only be
used after any other data). used after any other data).
The client SHOULD put in the stream any modes it knows about, and the The client SHOULD put in the stream any modes it knows about, and the
server MAY ignore any modes it does not know about. This allows some server MAY ignore any modes it does not know about. This allows some
degree of machine-independence, at least between systems that use a degree of machine-independence, at least between systems that use a
POSIX-like tty interface. The protocol can support other systems as POSIX-like tty interface. The protocol can support other systems as
well, but the client may need to fill reasonable values for a number well, but the client may need to fill reasonable values for a number
of parameters so the server pty gets set to a reasonable mode (the of parameters so the server pty gets set to a reasonable mode (the
server leaves all unspecified mode bits in their default values, and server leaves all unspecified mode bits in their default values, and
only some combinations make sense). only some combinations make sense).
The following opcodes have been defined. The naming of opcodes The following opcodes have been defined. The naming of opcodes
mostly follows the POSIX terminal mode flags. mostly follows the POSIX terminal mode flags.
opcode argument description
------ -------- -----------
0 TTY_OP_END Indicates end of options. 0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly for the 1 VINTR Interrupt character; 255 if none. Similarly
other characters. Not all of these characters are for the other characters. Not all of these
supported on all systems. characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on POSIX 2 VQUIT The quit character (sends SIGQUIT signal on
systems). POSIX systems).
3 VERASE Erase the character to left of the cursor. 3 VERASE Erase the character to left of the cursor.
4 VKILL Kill the current input line. 4 VKILL Kill the current input line.
5 VEOF End-of-file character (sends EOF from the terminal). 5 VEOF End-of-file character (sends EOF from the
6 VEOL End-of-line character in addition to carriage return terminal).
and/or linefeed. 6 VEOL End-of-line character in addition to
carriage return and/or linefeed.
7 VEOL2 Additional end-of-line character. 7 VEOL2 Additional end-of-line character.
8 VSTART Continues paused output (normally control-Q). 8 VSTART Continues paused output (normally
control-Q).
9 VSTOP Pauses output (normally control-S). 9 VSTOP Pauses output (normally control-S).
10 VSUSP Suspends the current program. 10 VSUSP Suspends the current program.
11 VDSUSP Another suspend character. 11 VDSUSP Another suspend character.
12 VREPRINT Reprints the current input line. 12 VREPRINT Reprints the current input line.
13 VWERASE Erases a word left of cursor. 13 VWERASE Erases a word left of cursor.
14 VLNEXT Enter the next character typed literally, even if it 14 VLNEXT Enter the next character typed literally,
is a special character even if it is a special character
15 VFLUSH Character to flush output. 15 VFLUSH Character to flush output.
16 VSWTCH Switch to a different shell layer. 16 VSWTCH Switch to a different shell layer.
17 VSTATUS Prints system status line (load, command, pid etc). 17 VSTATUS Prints system status line (load, command,
pid, etc).
18 VDISCARD Toggles the flushing of terminal output. 18 VDISCARD Toggles the flushing of terminal output.
30 IGNPAR The ignore parity flag. The parameter SHOULD be 0 if 30 IGNPAR The ignore parity flag. The parameter
this flag is FALSE set, and 1 if it is TRUE. SHOULD be 0 if this flag is FALSE set,
and 1 if it is TRUE.
31 PARMRK Mark parity and framing errors. 31 PARMRK Mark parity and framing errors.
32 INPCK Enable checking of parity errors. 32 INPCK Enable checking of parity errors.
33 ISTRIP Strip 8th bit off characters. 33 ISTRIP Strip 8th bit off characters.
34 INLCR Map NL into CR on input. 34 INLCR Map NL into CR on input.
35 IGNCR Ignore CR on input. 35 IGNCR Ignore CR on input.
36 ICRNL Map CR to NL on input. 36 ICRNL Map CR to NL on input.
37 IUCLC Translate uppercase characters to lowercase. 37 IUCLC Translate uppercase characters to
lowercase.
38 IXON Enable output flow control. 38 IXON Enable output flow control.
39 IXANY Any char will restart after stop. 39 IXANY Any char will restart after stop.
40 IXOFF Enable input flow control. 40 IXOFF Enable input flow control.
41 IMAXBEL Ring bell on input queue full. 41 IMAXBEL Ring bell on input queue full.
50 ISIG Enable signals INTR, QUIT, [D]SUSP. 50 ISIG Enable signals INTR, QUIT, [D]SUSP.
51 ICANON Canonicalize input lines. 51 ICANON Canonicalize input lines.
52 XCASE Enable input and output of uppercase characters by 52 XCASE Enable input and output of uppercase
preceding their lowercase equivalents with `\'. characters by preceding their lowercase
equivalents with "\".
53 ECHO Enable echoing. 53 ECHO Enable echoing.
54 ECHOE Visually erase chars. 54 ECHOE Visually erase chars.
55 ECHOK Kill character discards current line. 55 ECHOK Kill character discards current line.
56 ECHONL Echo NL even if ECHO is off. 56 ECHONL Echo NL even if ECHO is off.
57 NOFLSH Don't flush after interrupt. 57 NOFLSH Don't flush after interrupt.
58 TOSTOP Stop background jobs from output. 58 TOSTOP Stop background jobs from output.
59 IEXTEN Enable extensions. 59 IEXTEN Enable extensions.
60 ECHOCTL Echo control characters as ^(Char). 60 ECHOCTL Echo control characters as ^(Char).
61 ECHOKE Visual erase for line kill. 61 ECHOKE Visual erase for line kill.
62 PENDIN Retype pending input. 62 PENDIN Retype pending input.
70 OPOST Enable output processing. 70 OPOST Enable output processing.
71 OLCUC Convert lowercase to uppercase. 71 OLCUC Convert lowercase to uppercase.
72 ONLCR Map NL to CR-NL. 72 ONLCR Map NL to CR-NL.
73 OCRNL Translate carriage return to newline (output). 73 OCRNL Translate carriage return to newline
74 ONOCR Translate newline to carriage return-newline (output).
74 ONOCR Translate newline to carriage
return-newline (output).
75 ONLRET Newline performs a carriage return
(output). (output).
75 ONLRET Newline performs a carriage return (output).
90 CS7 7 bit mode. 90 CS7 7 bit mode.
91 CS8 8 bit mode. 91 CS8 8 bit mode.
92 PARENB Parity enable. 92 PARENB Parity enable.
93 PARODD Odd parity, else even. 93 PARODD Odd parity, else even.
128 TTY_OP_ISPEED Specifies the input baud rate in bits per second. 128 TTY_OP_ISPEED Specifies the input baud rate in
129 TTY_OP_OSPEED Specifies the output baud rate in bits per second. bits per second.
129 TTY_OP_OSPEED Specifies the output baud rate in
bits per second.
9. Summary of Message Numbers 9. Summary of Message Numbers
#define SSH_MSG_GLOBAL_REQUEST 80 The following is a summary of messages and their associated message
#define SSH_MSG_REQUEST_SUCCESS 81 number.
#define SSH_MSG_REQUEST_FAILURE 82
#define SSH_MSG_CHANNEL_OPEN 90 SSH_MSG_GLOBAL_REQUEST 80
#define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 SSH_MSG_REQUEST_SUCCESS 81
#define SSH_MSG_CHANNEL_OPEN_FAILURE 92 SSH_MSG_REQUEST_FAILURE 82
#define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 SSH_MSG_CHANNEL_OPEN 90
#define SSH_MSG_CHANNEL_DATA 94 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91
#define SSH_MSG_CHANNEL_EXTENDED_DATA 95 SSH_MSG_CHANNEL_OPEN_FAILURE 92
#define SSH_MSG_CHANNEL_EOF 96 SSH_MSG_CHANNEL_WINDOW_ADJUST 93
#define SSH_MSG_CHANNEL_CLOSE 97 SSH_MSG_CHANNEL_DATA 94
#define SSH_MSG_CHANNEL_REQUEST 98 SSH_MSG_CHANNEL_EXTENDED_DATA 95
#define SSH_MSG_CHANNEL_SUCCESS 99 SSH_MSG_CHANNEL_EOF 96
#define SSH_MSG_CHANNEL_FAILURE 100 SSH_MSG_CHANNEL_CLOSE 97
SSH_MSG_CHANNEL_REQUEST 98
SSH_MSG_CHANNEL_SUCCESS 99
SSH_MSG_CHANNEL_FAILURE 100
10. IANA Considerations 10. IANA Considerations
This document is part of a set. The IANA considerations for the SSH This document is part of a set. The IANA considerations for the SSH
protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and
this document, are detailed in [SSH-NUMBERS]. this document, are detailed in [SSH-NUMBERS].
11. Security Considerations 11. Security Considerations
This protocol is assumed to run on top of a secure, authenticated This protocol is assumed to run on top of a secure, authenticated
skipping to change at page 19, line 17 skipping to change at page 20, line 15
implementations disable all the potentially dangerous features (e.g. implementations disable all the potentially dangerous features (e.g.
agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host
key has changed without notice or explanation. key has changed without notice or explanation.
12. References 12. References
12.1 Normative References 12.1 Normative References
[SSH-ARCH] [SSH-ARCH]
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
I-D draft-ietf-architecture-16.txt, May 2004. I-D draft-ietf-architecture-17.txt, October 2004.
[SSH-TRANS] [SSH-TRANS]
Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol",
I-D draft-ietf-transport-18.txt, May 2004. I-D draft-ietf-transport-19.txt, October 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", Ylonen, T. and C. Lonvick, "SSH Authentication Protocol",
I-D draft-ietf-userauth-21.txt, May 2004. I-D draft-ietf-userauth-22.txt, October 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Ylonen, T. and C. Lonvick, "SSH Protocol Assigned Ylonen, T. and C. Lonvick, "SSH Protocol Assigned
Numbers", I-D draft-ietf-assignednumbers-06.txt, May 2004. Numbers", I-D draft-ietf-assignednumbers-07.txt, October
2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
12.2 Informative References 12.2 Informative References
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995. Architecture", RFC 1884, December 1995.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
10646", RFC 2279, January 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
[SCHEIFLER] [SCHEIFLER]
Scheifler, R., "X Window System : The Complete Reference Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
Press ISBN 1555580882, February 1992. Press ISBN 1555580882, February 1992.
[POSIX] ISO/IEC, 9945-1., "Information technology -- Portable [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable
Operating System Interface (POSIX)-Part 1: System Operating System Interface (POSIX)-Part 1: System
Application Program Interface (API) C Language", ANSI/IEE Application Program Interface (API) C Language", ANSI/IEE
Std 1003.1, July 1996. Std 1003.1, July 1996.
Authors' Addresses Author's Address
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: ylo@ssh.com
Chris Lonvick (editor) Chris Lonvick (editor)
Cisco Systems, Inc Cisco Systems, Inc
12515 Research Blvd. 12515 Research Blvd.
Austin 78759 Austin 78759
USA USA
EMail: clonvick@cisco.com EMail: clonvick@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/