draft-ietf-secsh-connect-17.txt   draft-ietf-secsh-connect-18.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
Internet-Draft T. Kivinen Internet-Draft SSH Communications Security Corp
Expires: January 12, 2004 SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Editor, Ed.
M. Saarinen Sun Microsystems, Inc
University of Jyvaskyla Oct 2003
T. Rinne
S. Lehtinen
SSH Communications Security Corp
July 14, 2003
SSH Connection Protocol SSH Connection Protocol
draft-ietf-secsh-connect-17.txt draft-ietf-secsh-connect-18.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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt. 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 January 12, 2004. This Internet-Draft will expire on March 31, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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, interactive login sessions, remote execution of commands, forwarded
forwarded TCP/IP connections, and forwarded X11 connections. All TCP/IP connections, and forwarded X11 connections. All of these
of these channels are multiplexed into a single encrypted tunnel. channels are multiplexed into a single encrypted tunnel.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . 3
3.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 4
3.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4
3.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5
4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6
4.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7
4.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8
4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8
4.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8
4.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9
4.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 6.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10
4.7 Window Dimension Change Message . . . . . . . . . . . . . . 11 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10
4.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11
4.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.7 Window Dimension Change Message . . . . . . . . . . . . . . 12
4.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 12 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12
5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 13
5.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14
6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14
7. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . 18 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16
9. Intellectual Property . . . . . . . . . . . . . . . . . . . 18 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18
10. Additional Information . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. iana cONSiderations . . . . . . . . . . . . . . . . . . . . 19
12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 21
1. Introduction
1. Contributors
The major original contributors of this document were: Tatu Ylonen,
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications
Security Corp), and Markku-Juhani O. Saarinen (University of
Jyvaskyla)
The document editor is: Darren.Moffat@Sun.COM. Comments on this
internet draft should be sent to the IETF SECSH working group,
details at: http://ietf.org/html.charters/secsh-charter.html
2. Introduction
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. It SSH transport layer and user authentication protocols. It provides
provides interactive login sessions, remote execution of commands, interactive login sessions, remote execution of commands, forwarded
forwarded TCP/IP connections, and forwarded X11 connections. The TCP/IP connections, and forwarded X11 connections. The service name
service name for this protocol (after user authentication) is for this protocol is "ssh-connection".
"ssh-connection".
This document should be read only after reading the SSH This document should be read only after reading the SSH architecture
architecture document [SSH-ARCH]. This document freely uses document [SSH-ARCH]. This document freely uses terminology and
terminology and notation from the architecture document without notation from the architecture document without reference or further
reference or further explanation. explanation.
2. Global Requests 3. Conventions Used in This Document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
and "MAY" that appear in this document are to be interpreted as
described in [RFC2119].
The used data types and terminology are specified in the architecture
document [SSH-ARCH].
The architecture document also discusses the algorithm naming
conventions that MUST be used with the SSH protocols.
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 remote end "globally", independent of any channels. An example is a
a request to start TCP/IP forwarding for a specific port. All request to start TCP/IP forwarding for a specific port. All such
such requests use the following format. requests use the following format.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string request name (restricted to US-ASCII) string request name (restricted to US-ASCII)
boolean want reply boolean want reply
... request-specific data follows ... request-specific data follows
Request names follow the DNS extensibility naming convention outlined
Request names follow the DNS extensibility naming convention in [SSH-ARCH].
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' SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is
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 If the recipient does not recognize or support the request, it simply
simply responds with SSH_MSG_REQUEST_FAILURE. responds with SSH_MSG_REQUEST_FAILURE.
byte SSH_MSG_REQUEST_FAILURE byte SSH_MSG_REQUEST_FAILURE
3. 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 Channels are identified by numbers at each end. The number referring
referring to a channel may be different on each side. Requests to to a channel may be different on each side. Requests to open a
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 channel-related messages contain the recipient's channel number for
for the channel. the channel.
Channels are flow-controlled. No data may be sent to a channel Channels are flow-controlled. No data may be sent to a channel until
until a message is received to indicate that window space is a message is received to indicate that window space is available.
available.
3.1 Opening a Channel 5.1 Opening a Channel
When either side wishes to open a new channel, it allocates a When either side wishes to open a new channel, it allocates a local
local number for the channel. It then sends the following message number for the channel. It then sends the following message to the
to the other side, and includes the local channel number and other side, and includes the local channel number and initial window
initial window size in the message. size in the message.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string channel type (restricted to US-ASCII) string channel type (restricted to US-ASCII)
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 the SSH architecture
document, with similar extension mechanisms. `sender channel' is document, with similar extension mechanisms. `sender channel' is a
a local identifier for the channel used by the sender of this local identifier for the channel used by the sender of this message.
message. `initial window size' specifies how many bytes of `initial window size' specifies how many bytes of channel data can be
channel data can be sent to the sender of this message without sent to the sender of this message without adjusting the window.
adjusting the window. `Maximum packet size' specifies the maximum `Maximum packet size' specifies the maximum size of an individual
size of an individual data packet that can be sent to the sender data packet that can be sent to the sender (for example, one might
(for example, one might want to use smaller packets for want to use smaller packets for interactive connections to get better
interactive connections to get better interactive response on slow interactive response on slow links).
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
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
where `recipient channel' is the channel number given in the where `recipient channel' is the channel number given in the original
original open request, and `sender channel' is the channel number open request, and `sender channel' is the channel number allocated by
allocated by the other side, or 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 (ISO-10646 UTF-8 [RFC2279]) string additional textual information (ISO-10646 UTF-8 [RFC2279])
string language tag (as defined in [RFC1766]) string language tag (as defined in [RFC3066])
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support
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 additional
information to the user. If this is done, the client software information to the user. If this is done, the client software should
should take the precautions discussed in [SSH-ARCH]. take the precautions discussed in [SSH-ARCH].
The following reason codes are defined: The following reason codes are defined:
#define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
#define SSH_OPEN_CONNECT_FAILED 2 #define SSH_OPEN_CONNECT_FAILED 2
#define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
#define SSH_OPEN_RESOURCE_SHORTAGE 4 #define SSH_OPEN_RESOURCE_SHORTAGE 4
3.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 before it must wait for the window to be adjusted. Both parties use
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
After receiving this message, the recipient MAY send the given After receiving this message, the recipient MAY send the given number
number of bytes more than it was previously allowed to send; the of bytes more than it was previously allowed to send; the window size
window size is incremented. is incremented.
Data transfer is done with messages of the following type. Data transfer is done with messages of the following type.
byte SSH_MSG_CHANNEL_DATA byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel uint32 recipient channel
string data string data
The maximum amount of data allowed is the current window size. The maximum amount of data allowed is the current window size. The
The window size is decremented by the amount of data sent. Both window size is decremented by the amount of data sent. Both parties
parties MAY ignore all extra data sent after the allowed window is MAY ignore all extra data sent after the allowed window is empty.
empty.
Additionally, some channels can transfer several types of data. Additionally, some channels can transfer several types of data. An
An example of this is stderr data from interactive sessions. Such example of this is stderr data from interactive sessions. Such data
data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a
where a separate integer specifies the type of the data. The separate integer specifies the type of the data. The available types
available types and their interpretation depend on the type of the and their interpretation depend on the type of the channel.
channel.
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 #define SSH_EXTENDED_DATA_STDERR 1
3.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, channel. Note that the channel remains open after this message, and
and more data may still be sent in the other direction. This more data may still be sent in the other direction. This message
message does not consume window space and can be sent even if no does not consume window space and can be sent even if no window space
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
party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and
and the party may then reuse the channel number. A party MAY send the party may then reuse the channel number. A party MAY send
SSH_MSG_CHANNEL_CLOSE without having sent or received SSH_MSG_CHANNEL_CLOSE without having sent or received
SSH_MSG_CHANNEL_EOF. SSH_MSG_CHANNEL_EOF.
byte SSH_MSG_CHANNEL_CLOSE byte SSH_MSG_CHANNEL_CLOSE
uint32 recipient_channel uint32 recipient_channel
This message does not consume window space and can be sent even if This message does not consume window space and can be sent even if no
no window space is available. window space is available.
It is recommended that any data sent before this message is It is recommended that any data sent before this message is delivered
delivered to the actual destination, if possible. to the actual destination, if possible.
3.4 Channel-Specific Requests 5.4 Channel-Specific Requests
Many channel types have extensions that are specific to that Many channel types 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 (restricted to US-ASCII) string request type (restricted to US-ASCII)
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 Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request- or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
specific continuation messages. If the request is not recognized messages. If the request is not recognized or is not supported for
or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is the channel, SSH_MSG_CHANNEL_FAILURE is returned.
returned.
This message does not consume window space and can be sent even if This message does not consume window space and can be sent even if no
no window space is available. Request types are local to each window space is available. Request types are local to each channel
channel type. 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]
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 These messages do not consume window space and can be sent even if no
no window space is available. window space is available.
4. Interactive Sessions 6. Interactive Sessions
A session is a remote execution of a program. The program may be A session is a remote execution of a program. The program may be a
a shell, an application, a system command, or some built-in shell, an application, a system command, or some built-in subsystem.
subsystem. It may or may not have a tty, and may or may not It may or may not have a tty, and may or may not involve X11
involve X11 forwarding. Multiple sessions can be active forwarding. Multiple sessions can be active simultaneously.
simultaneously.
4.1 Opening a Session 6.1 Opening a Session
A session is started by sending the following message. A session is started by sending the following message.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string "session" string "session"
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
Client implementations SHOULD reject any session channel open Client implementations SHOULD reject any session channel open
requests to make it more difficult for a corrupt server to attack requests to make it more difficult for a corrupt server to attack the
the client. client.
4.2 Requesting a Pseudo-Terminal 6.2 Requesting a Pseudo-Terminal
A pseudo-terminal can be allocated for the session by sending the A pseudo-terminal can be allocated for the session by sending the
following message. following message.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
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 encoding of terminal modes is described in Section Encoding of
Terminal Modes (Section 6). Zero dimension parameters MUST be Terminal Modes (Section 8). Zero dimension parameters MUST be
ignored. The character/row dimensions override the pixel ignored. The character/row dimensions override the pixel dimensions
dimensions (when nonzero). Pixel dimensions refer to the drawable (when nonzero). Pixel dimensions refer to the drawable area of the
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.
4.3 X11 Forwarding 6.3 X11 Forwarding
4.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
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 authentication cookie that is sent be a
fake, random cookie, and that the cookie is checked and replaced fake, random cookie, and that the cookie is checked and replaced by
by the real cookie when a connection request is received. 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, forwarded. No more connections will be forwarded after the first, or
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]. X Protocol is documented in [SCHEIFLER].
4.3.2 X11 Channels 6.3.2 X11 Channels
X11 channels are opened with a channel open request. The X11 channels are opened with a channel open request. The resulting
resulting channels are independent of the session, and closing the channels are independent of the session, and closing the session
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
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
string originator address (e.g. "192.168.7.38") string originator address (e.g. "192.168.7.38")
uint32 originator port uint32 originator port
The recipient should respond with
SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE. The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION
or SSH_MSG_CHANNEL_OPEN_FAILURE.
Implementations MUST reject any X11 channel open requests if they Implementations MUST reject any X11 channel open requests if they
have not requested X11 forwarding. have not requested X11 forwarding.
4.4 Environment Variable Passing 6.4 Environment Variable Passing
Environment variables may be passed to the shell/command to be Environment variables may be passed to the shell/command to be
started later. Uncontrolled setting of environment variables in a started later. Uncontrolled setting of environment variables in a
privileged process can be a security hazard. It is recommended privileged process can be a security hazard. It is recommended that
that implementations either maintain a list of allowable variable implementations either maintain a list of allowable variable names or
names or only set environment variables after the server process only set environment variables after the server process has dropped
has dropped sufficient privileges. sufficient privileges.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "env" string "env"
boolean want reply boolean want reply
string variable name string variable name
string variable value string variable value
4.5 Starting a Shell or a Command 6.5 Starting a Shell or a Command
Once the session has been set up, a program is started at the Once the session has been set up, a program is started at the remote
remote end. The program can be a shell, an application program or end. The program can be a shell, an application program or a
a subsystem with a host-independent name. Only one of these subsystem with a host-independent name. Only one of these requests
requests can succeed per channel. can succeed per channel.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "shell" string "shell"
boolean want reply boolean want reply
This message will request the user's default shell (typically defined
This message will request the user's default shell (typically in /etc/passwd in UNIX systems) to be started at the other end.
defined 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 This last form executes a predefined subsystem. It is expected that
that these will include a general file transfer mechanism, and these will include a general file transfer mechanism, and possibly
possibly other features. Implementations may also allow other features. Implementations may also allow configuring more such
configuring more such mechanisms. As the user's shell is usually mechanisms. As the user's shell is usually used to execute the
used to execute the subsystem, it is advisable for the subsystem subsystem, it is advisable for the subsystem protocol to have a
protocol to have a "magic cookie" at the beginning of the protocol "magic cookie" at the beginning of the protocol transaction to
transaction to distinguish it from arbitrary output generated by distinguish it from arbitrary output generated by shell
shell initialization scripts etc. This spurious output from the initialization scripts etc. This spurious output from the shell may
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 The server SHOULD not halt the execution of the protocol stack when
when starting a shell or a program. All input and output from starting a shell or a program. All input and output from these SHOULD
these SHOULD be redirected to the channel or to the encrypted be redirected to the channel or to the encrypted tunnel.
tunnel.
It is RECOMMENDED to request and check the reply for these It is RECOMMENDED to request and check the reply for these messages.
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-ARCH].
4.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. SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The
The extended data type SSH_EXTENDED_DATA_STDERR has been defined extended data type SSH_EXTENDED_DATA_STDERR has been defined for
for stderr data. stderr data.
4.7 Window Dimension Change Message 6.7 Window Dimension Change Message
When the window (terminal) size changes on the client side, it MAY When the window (terminal) size changes on the client side, it MAY
send a message to the other side to inform it of the new send a message to the other side to inform it of the new dimensions.
dimensions.
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. No response SHOULD be sent to this message.
4.8 Local Flow Control 6.8 Local Flow Control
On many systems, it is possible to determine if a pseudo-terminal On many systems, it is possible to determine if a pseudo-terminal is
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 allowed, it is often desirable to do the flow control at the client
client end to speed up responses to user requests. This is end to speed up responses to user requests. This is facilitated by
facilitated by the following notification. Initially, the server the following notification. Initially, the server is responsible for
is responsible for flow control. (Here, again, client means the flow control. (Here, again, client means the side originating 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 The message below is used by the server to inform the client when it
it can or cannot perform flow control (control-S/control-Q can or cannot perform flow control (control-S/control-Q processing).
processing). If `client can do' is TRUE, the client is allowed to If `client can do' is TRUE, the client is allowed to do flow control
do flow control using control-S and control-Q. The client MAY using control-S and control-Q. The client MAY ignore this message.
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.
4.9 Signals 6.9 Signals
A signal can be delivered to the remote process/service using the A signal can be delivered to the remote process/service using the
following message. Some systems may not implement signals, in following message. Some systems may not implement signals, in which
which case they SHOULD ignore this message. case they SHOULD ignore this message.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "signal" string "signal"
boolean FALSE boolean FALSE
string signal name without the "SIG" prefix. string signal name without the "SIG" prefix.
Signal names will be encoded as discussed in the "exit-signal" Signal names will be encoded as discussed in the "exit-signal"
SSH_MSG_CHANNEL_REQUEST. SSH_MSG_CHANNEL_REQUEST.
4.10 Returning Exit Status 6.10 Returning Exit Status
When the command running at the other end terminates, the When the command running at the other end terminates, the following
following message can be sent to return the exit status of the message can be sent to return the exit status of the command.
command. Returning the status is RECOMMENDED. No acknowledgment Returning the status is RECOMMENDED. No acknowledgment is sent for
is sent for this message. The channel needs to be closed with this message. The channel needs to be closed with
SSH_MSG_CHANNEL_CLOSE after this message. SSH_MSG_CHANNEL_CLOSE after this message.
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 Such a condition can be indicated by the following message. A zero
zero exit_status usually means that the command terminated exit_status usually means that the command terminated successfully.
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 (ISO-10646 UTF-8) string error message (ISO-10646 UTF-8)
string language tag (as defined in [RFC1766]) 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 names MAY be sent in the format "sig-name@xyz",
where `sig-name' and `xyz' may be anything a particular where `sig-name' and `xyz' may be anything a particular implementor
implementor wants (except the `@' sign). However, it is suggested wants (except the `@' sign). However, it is suggested that if a
that if a `configure' script is used, the non-standard signal `configure' script is used, the non-standard signal names it finds be
names it finds be encoded as "SIG@xyz.config.guess", where `SIG' encoded as "SIG@xyz.config.guess", where `SIG' is the signal name
is the signal name without the "SIG" prefix, and `xyz' be the host without the "SIG" prefix, and `xyz' be the host type, as determined
type, as determined by `config.guess'. by `config.guess'.
The `error message' contains an additional explanation of the The `error message' contains an additional explanation of the error
error message. The message may consist of multiple lines. The message. The message may consist of multiple lines. The client
client software MAY display this message to the user. If this is software MAY display this message to the user. If this is done, the
done, the client software should take the precautions discussed in client software should take the precautions discussed in [SSH-ARCH].
[SSH-ARCH].
5. TCP/IP Port Forwarding 7. TCP/IP Port Forwarding
5.1 Requesting Port Forwarding 7.1 Requesting Port Forwarding
A party need not explicitly request forwardings from its own end A party need not explicitly request forwardings from its own end to
to the other direction. However, if it wishes that connections to the other direction. However, if it wishes that connections to a
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 `Address to bind' and `port number to bind' specify the IP address
and port to which the socket to be listened is bound. The address and port to which the socket to be listened is bound. The address
should be "0.0.0.0" if connections are allowed from anywhere. should be "0.0.0.0" if connections are allowed from anywhere. (Note
(Note that the client can still filter connections based on that the client can still filter connections based on information
information passed in the open request.) passed in the open request.)
Implementations should only allow forwarding privileged ports if Implementations should only allow forwarding privileged ports if the
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 If a client passes 0 as port number to bind and has want reply TRUE
TRUE then the server allocates the next available unprivileged then the server allocates the next available unprivileged port number
port number and replies with the following message, otherwise and replies with the following message, otherwise there is no
there is no response specific data. response specific data.
byte SSH_MSG_GLOBAL_REQUEST_SUCCESS byte SSH_MSG_GLOBAL_REQUEST_SUCCESS
uint32 port that was bound on the server uint32 port that was bound on the server
A port forwarding can be cancelled with the following message. A port forwarding can be cancelled with the following message. Note
Note that channel open requests may be received until a reply to that channel open requests may be received until a reply to this
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")
uint32 port number to bind uint32 port number to bind
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.
5.2 TCP/IP Forwarding Channels 7.2 TCP/IP Forwarding Channels
When a connection comes to a port for which remote forwarding has When a connection comes to a port for which remote forwarding has
been requested, a channel is opened to forward the port to the been requested, a channel is opened to forward the port to the other
other side. side.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string "forwarded-tcpip" string "forwarded-tcpip"
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
string address that was connected string address that was connected
uint32 port that was connected uint32 port that was connected
string originator IP address string originator IP address
uint32 originator port uint32 originator port
Implementations MUST reject these messages unless they have Implementations MUST reject these messages unless they have
previously requested a remote TCP/IP port forwarding with the previously requested a remote TCP/IP port forwarding with the given
given port number. port number.
When a connection comes to a locally forwarded TCP/IP port, the When a connection comes to a locally forwarded TCP/IP port, the
following packet is sent to the other side. Note that these following packet is sent to the other side. Note that these messages
messages MAY be sent also for ports for which no forwarding has MAY be sent also for ports for which no forwarding has been
been explicitly requested. The receiving side must decide whether explicitly requested. The receiving side must decide whether to
to allow the forwarding. allow the forwarding.
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 `Host to connect' and `port to connect' specify the TCP/IP host and
and port where the recipient should connect the channel. `Host to port where the recipient should connect the channel. `Host to
connect' may be either a domain name or a numeric IP address. connect' may be either a domain name or a numeric IP address.
`Originator IP address' is the numeric IP address of the machine `Originator IP address' is the numeric IP address of the machine
where the connection request comes from, and `originator port' is where the connection request comes from, and `originator port' is the
the port on the originator host from where the connection came port on the originator host from where the connection came from.
from.
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 Client implementations SHOULD reject direct TCP/IP open requests for
for security reasons. security reasons.
6. Encoding of Terminal Modes 8. Encoding of Terminal Modes
Terminal modes (as passed in a pty request) are encoded into a Terminal modes (as passed in a pty request) are encoded into a byte
byte stream. It is intended that the coding be portable across stream. It is intended that the coding be portable across different
different environments. environments.
The tty mode description is a stream of bytes. The stream The tty mode description is a stream of bytes. The stream consists
consists of opcode-argument pairs. It is terminated by opcode of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0).
TTY_OP_END (0). Opcodes 1 to 159 have a single uint32 argument. Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255
Opcodes 160 to 255 are not yet defined, and cause parsing to stop are not yet defined, and cause parsing to stop (they should only be
(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 client SHOULD put in the stream any modes it knows about, and the
the server MAY ignore any modes it does not know about. This server MAY ignore any modes it does not know about. This allows some
allows some degree of machine-independence, at least between degree of machine-independence, at least between systems that use a
systems that use a POSIX-like tty interface. The protocol can POSIX-like tty interface. The protocol can support other systems as
support other systems as well, but the client may need to fill well, but the client may need to fill reasonable values for a number
reasonable values for a number of parameters so the server pty of parameters so the server pty gets set to a reasonable mode (the
gets set to a reasonable mode (the server leaves all unspecified server leaves all unspecified mode bits in their default values, and
mode bits in their default values, and only some combinations make only some combinations make sense).
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.
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 for the
other characters. Not all of these characters are other characters. Not all of these characters are
supported on all systems. supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on POSIX 2 VQUIT The quit character (sends SIGQUIT signal on POSIX
systems). systems).
skipping to change at page 18, line 14 skipping to change at page 18, line 21
(output). (output).
75 ONLRET Newline performs a carriage return (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 bits per second.
129 TTY_OP_OSPEED Specifies the output baud rate in bits per second. 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second.
7. Summary of Message Numbers 9. Summary of Message Numbers
#define SSH_MSG_GLOBAL_REQUEST 80 #define SSH_MSG_GLOBAL_REQUEST 80
#define SSH_MSG_REQUEST_SUCCESS 81 #define SSH_MSG_REQUEST_SUCCESS 81
#define SSH_MSG_REQUEST_FAILURE 82 #define SSH_MSG_REQUEST_FAILURE 82
#define SSH_MSG_CHANNEL_OPEN 90 #define SSH_MSG_CHANNEL_OPEN 90
#define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91
#define SSH_MSG_CHANNEL_OPEN_FAILURE 92 #define SSH_MSG_CHANNEL_OPEN_FAILURE 92
#define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93
#define SSH_MSG_CHANNEL_DATA 94 #define SSH_MSG_CHANNEL_DATA 94
#define SSH_MSG_CHANNEL_EXTENDED_DATA 95 #define SSH_MSG_CHANNEL_EXTENDED_DATA 95
#define SSH_MSG_CHANNEL_EOF 96 #define SSH_MSG_CHANNEL_EOF 96
#define SSH_MSG_CHANNEL_CLOSE 97 #define SSH_MSG_CHANNEL_CLOSE 97
#define SSH_MSG_CHANNEL_REQUEST 98 #define SSH_MSG_CHANNEL_REQUEST 98
#define SSH_MSG_CHANNEL_SUCCESS 99 #define SSH_MSG_CHANNEL_SUCCESS 99
#define SSH_MSG_CHANNEL_FAILURE 100 #define SSH_MSG_CHANNEL_FAILURE 100
8. Security Considerations 10. 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
transport. User authentication and protection against network- transport. User authentication and protection against network-level
level attacks are assumed to be provided by the underlying attacks are assumed to be provided by the underlying protocols.
protocols.
It is RECOMMENDED that implementations disable all the potentially It is RECOMMENDED that implementations disable all the potentially
dangerous features (e.g. agent forwarding, X11 forwarding, and dangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IP
TCP/IP forwarding) if the host key has changed. forwarding) if the host key has changed.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
Section 8 of [SSH-ARCH] Section 8 of [SSH-ARCH]
9. Intellectual Property 11. iana cONSiderations
This document is part of a set, the IANA considerations for the SSH
protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],
[SSH-CONNECT] are detailed in [SSH-NUMBERS].
12. Intellectual Property
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 or other rights that might be claimed to
pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; neither does it represent might or might not be available; neither does it represent that it
that it has made any effort to identify any such rights. has made any effort to identify any such rights. Information on the
Information on the IETF's procedures with respect to rights in IETF's procedures with respect to rights in standards-track and
standards-track and standards-related documentation can be found standards-related documentation can be found in BCP-11. Copies of
in BCP-11. Copies of claims of rights made available for claims of rights made available for publication and any assurances of
publication and any assurances of licenses to be made available, licenses to be made available, or the result of an attempt made to
or the result of an attempt made to obtain a general license or obtain a general license or permission for the use of such
permission for the use of such proprietary rights by implementers proprietary rights by implementers or users of this specification can
or users of this specification can be obtained from the IETF be obtained from the IETF Secretariat.
Secretariat.
The IETF has been notified of intellectual property rights claimed The IETF has been notified of intellectual property rights claimed in
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.
10. Additional Information Normative References
The current document editor is: Darren.Moffat@Sun.COM. Comments [SSH-ARCH]
on this internet draft should be sent to the IETF SECSH working Ylonen, T., "SSH Protocol Architecture", I-D
group, details at: http://ietf.org/html.charters/secsh- draft-ietf-architecture-15.txt, Oct 2003.
charter.html
References [SSH-TRANS]
Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-17.txt, Oct 2003.
[RFC1766] Alvestrand, H., "Tags for the Identification of [SSH-USERAUTH]
Languages", RFC 1766, March 1995. Ylonen, T., "SSH Authentication Protocol", I-D
draft-ietf-userauth-18.txt, Oct 2003.
[RFC1884] Hinden, R., Deering, S. and Editors, "IP Version 6 [SSH-CONNECT]
Addressing Architecture", RFC 1884, December 1995. Ylonen, T., "SSH Connection Protocol", I-D
draft-ietf-connect-18.txt, Oct 2003.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of [SSH-NUMBERS]
ISO 10646", RFC 2279, January 1998. Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct
2003.
[SCHEIFLER] Scheifler, R., "X Window System : The Complete [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd Requirement Levels", BCP 14, RFC 2119, March 1997.
edition.", Digital Press ISBN 1555580882, Feburary
1992.
[POSIX] ISO/IEC, 9945-1., "Information technology -- Informative References
Portable Operating System Interface (POSIX)-Part
1: System Application Program Interface (API) C
Language", ANSI/IEE Std 1003.1, July 1996.
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D [RFC3066] Alvestrand, H., "Tags for the Identification of
draft-ietf-architecture-14.txt, July 2003. Languages", BCP 47, RFC 3066, January 2001.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
draft-ietf-transport-16.txt, July 2003. Architecture", RFC 1884, December 1995.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
draft-ietf-userauth-17.txt, July 2003. 10646", RFC 2279, January 1998.
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- [SCHEIFLER]
ietf-connect-17.txt, July 2003. Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
Press ISBN 1555580882, Feburary 1992.
[SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable
Numbers", I-D draft-ietf-secsh-assignednumbers- Operating System Interface (POSIX)-Part 1: System
03.txt, July 2003. Application Program Interface (API) C Language", ANSI/IEE
Std 1003.1, July 1996.
Authors' Addresses Authors' Addresses
Tatu Ylonen Tatu Ylonen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
HELSINKI FIN-00100 HELSINKI FIN-00100
Finland Finland
EMail: ylo@ssh.com EMail: ylo@ssh.com
Tero Kivinen Darren J. Moffat (editor)
SSH Communications Security Corp Sun Microsystems, Inc
Fredrikinkatu 42 17 Network Circle
HELSINKI FIN-00100 Menlo Park CA 94025
Finland USA
EMail: kivinen@ssh.com EMail: Darren.Moffat@Sun.COM
Markku-Juhani O. Saarinen Intellectual Property Statement
University of Jyvaskyla
Timo J. Rinne The IETF takes no position regarding the validity or scope of any
SSH Communications Security Corp intellectual property or other rights that might be claimed to
Fredrikinkatu 42 pertain to the implementation or use of the technology described in
HELSINKI FIN-00100 this document or the extent to which any license under such rights
Finland might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
EMail: tri@ssh.com The IETF invites any interested party to bring to its attention any
Sami Lehtinen copyrights, patents or patent applications, or other proprietary
SSH Communications Security Corp rights which may cover technology that may be required to practice
Fredrikinkatu 42 this standard. Please address the information to the IETF Executive
HELSINKI FIN-00100 Director.
Finland
EMail: sjl@ssh.com The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished to
to others, and derivative works that comment on or otherwise others, and derivative works that comment on or otherwise explain it
explain it or assist in its implementation may be prepared, or assist in its implementation may be prepared, copied, published
copied, published and distributed, in whole or in part, without and distributed, in whole or in part, without restriction of any
restriction of any kind, provided that the above copyright notice kind, provided that the above copyright notice and this paragraph are
and this paragraph are included on all such copies and derivative included on all such copies and derivative works. However, this
works. However, this document itself may not be modified in any document itself may not be modified in any way, such as by removing
way, such as by removing the copyright notice or references to the the copyright notice or references to the Internet Society or other
Internet Society or other Internet organizations, except as needed Internet organizations, except as needed for the purpose of
for the purpose of developing Internet standards in which case the developing Internet standards in which case the procedures for
procedures for copyrights defined in the Internet Standards copyrights defined in the Internet Standards process must be
process must be followed, or as required to translate it into followed, or as required to translate it into languages other than
languages other than English. English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not be
be revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on This document and the information contained herein is provided on an
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 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/