draft-ietf-secsh-connect-10.txt   draft-ietf-secsh-connect-11.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen Internet-Draft T. Kivinen
draft-ietf-secsh-connect-10.txt M. Saarinen Expires: January 18, 2002 SSH Communications Security Corp
Expires: 2 September, 2001 T. Rinne M. Saarinen
University of Jyvaskyla
T. Rinne
S. Lehtinen S. Lehtinen
SSH Communications Security SSH Communications Security Corp
2 March, 2001 July 20, 2001
Secure Shell Connection Protocol SSH Connection Protocol
draft-ietf-secsh-connect-11.txt
Status of This Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with
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 groups may also distribute working documents as other groups may also distribute working documents as Internet-
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 and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-Drafts
Drafts as reference material or to cite them other than as as reference material or to cite them other than as "work in
"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://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 January 18, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The Secure Shell Remote Login Protocol is a protocol for secure remote SSH is a protocol for secure remote login and other secure network
login and other secure network services over an insecure network. This services over an insecure network.
document describes the Secure Shell Connection Protocol. It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these channels
are multiplexed into a single encrypted tunnel. The Secure Shell Con-
nection Protocol has been designed to run on top of the Secure Shell
transport layer and user authentication protocols.
Table of Contents This document describes the SSH Connection Protocol. It provides
interactive login sessions, remote execution of commands,
forwarded TCP/IP connections, and forwarded X11 connections. All
of these channels are multiplexed into a single encrypted tunnel.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 The SSH Connection Protocol has been designed to run on top of the
2. Global Requests . . . . . . . . . . . . . . . . . . . . . . . . 2 SSH transport layer and user authentication protocols.
3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Opening a Channel . . . . . . . . . . . . . . . . . . . . . 3 Table of Contents
3.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 5
3.4. Channel-Specific Requests . . . . . . . . . . . . . . . . . 6
4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Opening a Session . . . . . . . . . . . . . . . . . . . . . 6
4.2. Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 7
4.3. X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Requesting X11 Forwarding . . . . . . . . . . . . . . . 7
4.3.2. X11 Channels . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Environment Variable Passing . . . . . . . . . . . . . . . . 8
4.5. Starting a Shell or a Command . . . . . . . . . . . . . . . 8
4.6. Session Data Transfer . . . . . . . . . . . . . . . . . . . 9
4.7. Window Dimension Change Message . . . . . . . . . . . . . . 9
4.8. Local Flow Control . . . . . . . . . . . . . . . . . . . . . 10
4.9. Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.10. Returning Exit Status . . . . . . . . . . . . . . . . . . . 10
5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . . 11
5.1. Requesting Port Forwarding . . . . . . . . . . . . . . . . . 12
5.2. TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 12
6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . . 13
7. Summary of Message Numbers . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 15
9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3
3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 3
3.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4
3.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6
3.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7
4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 7
4.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8
4.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8
4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1 >Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 8
4.3.2 >X11 Channels . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Environment Variable Passing . . . . . . . . . . . . . . . . 9
4.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10
4.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11
4.7 Window Dimension Change Message . . . . . . . . . . . . . . 11
4.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 11
4.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 12
5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 13
5.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14
5.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 14
6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 15
7. Summary of Message Numbers . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . 18
9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 18
10. Additional Information . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Secure Shell Connection Protocol has been designed to run on top of The SSH Connection Protocol has been designed to run on top of the
the Secure Shell transport layer and user authentication protocols. It SSH transport layer and user authentication protocols. It
provides interactive login sessions, remote execution of commands, provides interactive login sessions, remote execution of commands,
forwarded TCP/IP connections, and forwarded X11 connections. The forwarded TCP/IP connections, and forwarded X11 connections. The
service name for this protocol (after user authentication) is "ssh- service name for this protocol (after user authentication) is
connection". "ssh-connection".
This document should be read only after reading the Secure Shell Remote This document should be read only after reading the SSH
Login Protocol architecture document [SECSH-ARCH]. This document freely architecture document [SSH-ARCH]. This document freely uses
uses terminology and notation from the architecture document without terminology and notation from the architecture document without
reference or further explanation. reference or further explanation.
2. Global Requests 2. Global Requests
There are several kinds of requests that affect the state of the remote There are several kinds of requests that affect the state of the
end "globally", independent of any channels. An example is a request to remote end "globally", independent of any channels. An example is
start TCP/IP forwarding for a specific port. All such requests use the a request to start TCP/IP forwarding for a specific port. All
such requests use the following format.
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
The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS, The recipient will respond to this message with
SSH_MSG_REQUEST_FAILURE, or some request-specific continuation messages SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request-
if `want reply' is TRUE. specific continuation messages if `want reply' is TRUE.
byte SSH_MSG_REQUEST_SUCCESS byte SSH_MSG_REQUEST_SUCCESS
If the recipient does not recognize or support the request, it simply If the recipient does not recognize or support the request, it
responds with SSH_MSG_REQUEST_FAILURE. simply responds with SSH_MSG_REQUEST_FAILURE.
byte SSH_MSG_REQUEST_FAILURE byte SSH_MSG_REQUEST_FAILURE
3. Channel Mechanism 3. Channel Mechanism
All terminal sessions, forwarded connections, etc. are channels. Either All terminal sessions, forwarded connections, etc. are channels.
side may open a channel. Multiple channels are multiplexed into a Either side may open a channel. Multiple channels are multiplexed
single connection. into a single connection.
Channels are identified by numbers at each end. The number referring to Channels are identified by numbers at each end. The number
a channel may be different on each side. Requests to open a channel referring to a channel may be different on each side. Requests to
contain the sender's channel number. Any other channel-related messages open a channel contain the sender's channel number. Any other
contain the recipient's channel number for the channel. channel-related messages contain the recipient's channel number
for the channel.
Channels are flow-controlled. No data may be sent to a channel until a Channels are flow-controlled. No data may be sent to a channel
message is received to indicate that window space is available. until a message is received to indicate that window space is
available.
3.1. Opening a Channel 3.1 Opening a Channel
When either side wishes to open a new channel, it allocates a local When either side wishes to open a new channel, it allocates a
number for the channel. It then sends the following message to the local number for the channel. It then sends the following message
other side, and includes the local channel number and initial window to the other side, and includes the local channel number and
size in the message. initial window 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 architecture document, The channel type is a name as described in the SSH architecture
with similar extension mechanisms. `sender channel' is a local document, with similar extension mechanisms. `sender channel' is
identifier for the channel used by the sender of this message. `initial a local identifier for the channel used by the sender of this
window size' specifies how many bytes of channel data can be sent to the message. `initial window size' specifies how many bytes of
sender of this message without adjusting the window. `Maximum packet channel data can be sent to the sender of this message without
size' specifies the maximum size of an individual data packet that can adjusting the window. `Maximum packet size' specifies the maximum
be sent to the sender (for example, one might want to use smaller size of an individual data packet that can be sent to the sender
(for example, one might want to use smaller packets for
packets for interactive connections to get better interactive response interactive connections to get better interactive response on slow
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 original where `recipient channel' is the channel number given in the
open request, and `sender channel' is the channel number allocated by original open request, and `sender channel' is the channel number
the other side, or 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 (ISO-10646 UTF-8 string additional textual information (ISO-10646 UTF-8 [RFC2279])
[RFC-2279]) string language tag (as defined in [RFC1766])
string language tag (as defined in [RFC-1766])
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
the specified channel type, it simply responds with support 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 should information to the user. If this is done, the client software
take the precautions discussed in [SECSH-ARCH]. should 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 3.2 Data Transfer
The window size specifies how many bytes the other party can send before The window size specifies how many bytes the other party can send
it must wait for the window to be adjusted. Both parties use the before it must wait for the window to be adjusted. Both parties
following message to adjust the window. use 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 number of After receiving this message, the recipient MAY send the given
bytes more than it was previously allowed to send; the window size is number of bytes more than it was previously allowed to send; the
incremented. window size 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 The maximum amount of data allowed is the current window size.
window size is decremented by the amount of data sent. Both parties MAY The window size is decremented by the amount of data sent. Both
ignore all extra data sent after the allowed window is empty. parties MAY ignore all extra data sent after the allowed window is
empty.
Additionally, some channels can transfer several types of data. An Additionally, some channels can transfer several types of data.
example of this is stderr data from interactive sessions. Such data can An example of this is stderr data from interactive sessions. Such
be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages,
integer specifies the type of the data. The available types and their where a separate integer specifies the type of the data. The
interpretation depend on the type of the channel. available types and their interpretation depend on the type of the
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. Data sent with these messages consumes the same window as ordinary
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 3.3 Closing a Channel
When a party will no longer send more data to a channel, it SHOULD send When a party will no longer send more data to a channel, it SHOULD
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 application No explicit response is sent to this message; however, the
may send EOF to whatever is at the other end of the channel. Note that application may send EOF to whatever is at the other end of the
the channel remains open after this message, and more data may still be channel. Note that the channel remains open after this message,
sent in the other direction. This message does not consume window space and more data may still be sent in the other direction. This
and can be sent even if no window space is available. message does not consume window space and can be sent even if no
window space 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 send SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST
back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this
the channel. The channel is considered closed for a party when it has message for the channel. The channel is considered closed for a
both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then party when it has both sent and received SSH_MSG_CHANNEL_CLOSE,
reuse the channel number. A party MAY send SSH_MSG_CHANNEL_CLOSE and the party may then reuse the channel number. A party MAY send
without having sent or received SSH_MSG_CHANNEL_EOF. SSH_MSG_CHANNEL_CLOSE without having sent or received
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 no This message does not consume window space and can be sent even if
window space is available. no window space is available.
It is recommended that any data sent before this message is delivered to
the actual destination, if possible. It is recommended that any data sent before this message is
delivered to the actual destination, if possible.
3.4. Channel-Specific Requests 3.4 Channel-Specific Requests
Many channel types have extensions that are specific to that particular Many channel types have extensions that are specific to that
channel type. An example is requesting a pty (pseudo terminal) for an particular channel type. An example is requesting a pty (pseudo
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 SSH_MSG_CHANNEL_SUCCESS or Otherwise, the recipient responds with either
SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-
the request is not recognized or is not supported for the channel, specific continuation messages. If the request is not recognized
SSH_MSG_CHANNEL_FAILURE is returned. or is not supported for 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
window space is available. Request types are local to each channel type. no window space is available. Request types are local to each
channel type.
The client is allowed to send further messages without waiting for the The client is allowed to send further messages without waiting for
response to the request. the response to the request.
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
window space is available. no window space is available.
4. Interactive Sessions 4. Interactive Sessions
A session is a remote execution of a program. The program may be a A session is a remote execution of a program. The program may be
shell, an application, a system command, or some built-in subsystem. It a shell, an application, a system command, or some built-in
may or may not have a tty, and may or may not involve X11 forwarding. subsystem. It may or may not have a tty, and may or may not
Multiple sessions can be active simultaneously. involve X11 forwarding. Multiple sessions can be active
simultaneously.
4.1. Opening a Session 4.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 requests Client implementations SHOULD reject any session channel open
to make it more difficult for a corrupt server to attack the client. requests to make it more difficult for a corrupt server to attack
the client.
4.2. Requesting a Pseudo-Terminal 4.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., 480) uint32 terminal width, pixels (e.g., 640)
uint32 terminal height, pixels (e.g., 640) 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''. Zero dimension parameters MUST be ignored. The Terminal Modes (Section 6). Zero dimension parameters MUST be
character/row dimensions override the pixel dimensions (when nonzero). ignored. The character/row dimensions override the pixel
Pixel dimensions refer to the drawable area of the window. dimensions (when nonzero). Pixel dimensions refer to the drawable
area of the 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 4.3 X11 Forwarding
4.3.1. Requesting X11 Forwarding 4.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 fake, It is recommended that the authentication cookie that is sent be a
random cookie, and that the cookie is checked and replaced by the real fake, random cookie, and that the cookie is checked and replaced
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 automatically closed; however, already opened forwardings should not be
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 authentication The `x11 authentication protocol' is the name of the X11
method used, e.g. "MIT-MAGIC-COOKIE-1". authentication method used, e.g. "MIT-MAGIC-COOKIE-1".
X Protocol is documented in [SCHEIFLER]. X Protocol is documented in [SCHEIFLER].
4.3.2. X11 Channels 4.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
channels are independent of the session, and closing the session channel resulting channels are independent of the session, and closing the
does not close the forwarded X11 channels. session 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 The recipient should respond with
SSH_MSG_CHANNEL_OPEN_FAILURE. SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
Implementations MUST reject any X11 channel open requests if they have Implementations MUST reject any X11 channel open requests if they
not requested X11 forwarding. have not requested X11 forwarding.
4.4. Environment Variable Passing 4.4 Environment Variable Passing
Environment variables may be passed to the shell/command to be started Environment variables may be passed to the shell/command to be
later. Typically, each machine will have a preconfigured set of started later. Typically, each machine will have a preconfigured
variables that it will allow. Since uncontrolled setting of environment set of variables that it will allow. Since uncontrolled setting
variables can be very dangerous, it is recommended that implementations of environment variables can be very dangerous, it is recommended
allow setting only variables whose names have been explicitly configured that implementations allow setting only variables whose names have
to be allowed. been explicitly configured to be allowed.
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 4.5 Starting a Shell or a Command
Once the session has been set up, a program is started at the remote Once the session has been set up, a program is started at the
end. The program can be a shell, an application program or a subsystem remote end. The program can be a shell, an application program or
with a host-independent name. Only one of these requests can succeed a subsystem with a host-independent name. Only one of these
per channel. requests 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 in This message will request the user's default shell (typically
/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 given This message will request the server to start the execution of the
command. The command string may contain a path. Normal precautions MUST given command. The command string may contain a path. Normal
be taken to prevent the execution of unauthorized commands. precautions MUST be taken to prevent the execution of unauthorized
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
these will include a general file transfer mechanism, and possibly other that these will include a general file transfer mechanism, and
features. Implementations may also allow configuring more such possibly other features. Implementations may also allow
mechanisms. As the user's shell is usually used to execute the configuring more such mechanisms. As the user's shell is usually
subsystem, it is advisable for the subsystem protocol to have a "magic used to execute the subsystem, it is advisable for the subsystem
cookie" at the beginning of the protocol transaction to distinguish from protocol to have a "magic cookie" at the beginning of the protocol
arbitrary output from shell initialization scripts etc. This spurious transaction to distinguish from arbitrary output from shell
output from the shell may be filtered out either at the server or at the initialization scripts etc. This spurious output from the shell
client. may 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
starting a shell or a program. All input and output from these SHOULD be when starting a shell or a program. All input and output from
redirected to the channel or to the encrypted tunnel. these SHOULD be redirected to the channel or to the encrypted
tunnel.
It is RECOMMENDED to request and check the reply for these messages. The It is RECOMMENDED to request and check the reply for these
client SHOULD ignore these messages. messages. The client SHOULD ignore these messages.
4.6. Session Data Transfer 4.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.
extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr The extended data type SSH_EXTENDED_DATA_STDERR has been defined
data. for stderr data.
4.7. Window Dimension Change Message 4.7 Window Dimension Change Message
When the window (terminal) size changes on the client side, it MAY send When the window (terminal) size changes on the client side, it MAY
a message to the other side to inform it of the new dimensions. send a message to the other side to inform it of the new
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 4.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
using control-S/control-Q flow control. When flow control is allowed, is using control-S/control-Q flow control. When flow control is
it is often desirable to do the flow control at the client end to speed allowed, it is often desirable to do the flow control at the
up responses to user requests. This is facilitated by the following client end to speed up responses to user requests. This is
notification. Initially, the server is responsible for flow control. facilitated by the following notification. Initially, the server
(Here, again, client means the side originating the session, and server is responsible for flow control. (Here, again, client means the
means the other side.) side originating the session, and server means the other side.)
The message below is used by the server to inform the client when it can The message below is used by the server to inform the client when
or cannot perform flow control (control-S/control-Q processing). If it can or cannot perform flow control (control-S/control-Q
`client can do' is TRUE, the client is allowed to do flow control using processing). If `client can do' is TRUE, the client is allowed to
control-S and control-Q. The client MAY ignore this message. do flow control 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.
4.9. Signals 4.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 which following message. Some systems may not implement signals, in
case they SHOULD ignore this message. which 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 4.10 Returning Exit Status
When the command running at the other end terminates, the following When the command running at the other end terminates, the
message can be sent to return the exit status of the command. Returning following message can be sent to return the exit status of the
the status is RECOMMENDED. No acknowledgment is sent for this message. command. Returning the status is RECOMMENDED. No acknowledgment
The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this is sent for this message. The channel needs to be closed with
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. Such a The remote command may also terminate violently due to a signal.
condition can be indicated by the following message. A zero exit_status
usually means that the command terminated successfully. Such a condition can be indicated by the following message. A
zero 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 (ISO-10646 UTF-8) string error message (ISO-10646 UTF-8)
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC1766])
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", where Additional signal names MAY be sent in the format "sig-name@xyz",
`sig-name' and `xyz' may be anything a particular implementor wants where `sig-name' and `xyz' may be anything a particular
(except the `@' sign). However, it is suggested that if a `configure' implementor wants (except the `@' sign). However, it is suggested
script is used, the non-standard signal names it finds be encoded as that if a `configure' script is used, the non-standard signal
"SIG@xyz.config.guess", where `SIG' is the signal name without the "SIG" names it finds be encoded as "SIG@xyz.config.guess", where `SIG'
prefix, and `xyz' be the host type, as determined by `config.guess'. is the signal name without the "SIG" prefix, and `xyz' 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 explanation of the
message. The message may consist of multiple lines. The client software error message. The message may consist of multiple lines. The
MAY display this message to the user. If this is done, the client client software MAY display this message to the user. If this is
software should take the precautions discussed in [SECSH-ARCH]. done, the client software should take the precautions discussed in
[SSH-ARCH].
5. TCP/IP Port Forwarding 5. TCP/IP Port Forwarding
5.1 Requesting Port Forwarding
5.1. Requesting Port Forwarding A party need not explicitly request forwardings from its own end
to the other direction. However, if it wishes that connections to
A party need not explicitly request forwardings from its own end to the a port on the other side be forwarded to the local side, it must
other direction. However, if it wishes that connections to a port on explicitly request this.
the other side be forwarded to the local side, it must 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 and `Address to bind' and `port number to bind' specify the IP address
port to which the socket to be listened is bound. The address should be and port to which the socket to be listened is bound. The address
"0.0.0.0" if connections are allowed from anywhere. (Note that the should be "0.0.0.0" if connections are allowed from anywhere.
client can still filter connections based on information passed in the (Note that the client can still filter connections based on
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
user has been authenticated as a privileged user. the user has been authenticated as a privileged user.
Client implementations SHOULD reject these messages; they are normally Client implementations SHOULD reject these messages; they are
only sent by the client. normally only sent by the client.
A port forwarding can be cancelled with the following message. Note A port forwarding can be cancelled with the following message.
that channel open requests may be received until a reply to this message Note that channel open requests may be received until a reply to
is received. this 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 normally Client implementations SHOULD reject these messages; they are
only sent by the client. normally only sent by the client.
5.2. TCP/IP Forwarding Channels 5.2 TCP/IP Forwarding Channels
When a connection comes to a port for which remote forwarding has been When a connection comes to a port for which remote forwarding has
requested, a channel is opened to forward the port to the other side. been requested, a channel is opened to forward the port to the
other 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 previously Implementations MUST reject these messages unless they have
requested a remote TCP/IP port forwarding with the given port number. previously requested a remote TCP/IP port forwarding with the
given 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 messages following packet is sent to the other side. Note that these
MAY be sent also for ports for which no forwarding has been explicitly messages MAY be sent also for ports for which no forwarding has
requested. The receiving side must decide whether to allow the been explicitly requested. The receiving side must decide whether
forwarding. to 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 and port `Host to connect' and `port to connect' specify the TCP/IP host
where the recipient should connect the channel. `Host to connect' may and port where the recipient should connect the channel. `Host to
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 where `Originator IP address' is the numeric IP address of the machine
the connection request comes from, and `originator port' is the port on where the connection request comes from, and `originator port' is
the originator host from where the connection came from. the port on the originator host from where the connection came
from.
Forwarded TCP/IP channels are independent of any sessions, and closing a Forwarded TCP/IP channels are independent of any sessions, and
session channel does not in any way imply that forwarded connections closing a session channel does not in any way imply that forwarded
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
security reasons. for security reasons.
6. Encoding of Terminal Modes 6. Encoding of Terminal Modes
Terminal modes (as passed in a pty request) are encoded into a byte Terminal modes (as passed in a pty request) are encoded into a
stream. It is intended that the coding be portable across different byte stream. It is intended that the coding be portable across
environments. different environments.
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).
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 used
after any other data).
The client SHOULD put in the stream any modes it knows about, and the The tty mode description is a stream of bytes. The stream
server MAY ignore any modes it does not know about. This allows some consists of opcode-argument pairs. It is terminated by opcode
degree of machine-independence, at least between systems that use a TTY_OP_END (0). Opcodes 1 to 159 have a single uint32 argument.
POSIX-like tty interface. The protocol can support other systems as Opcodes 160 to 255 are not yet defined, and cause parsing to stop
well, but the client may need to fill reasonable values for a number of (they should only be used after any other data).
parameters so the server pty gets set to a reasonable mode (the server The client SHOULD put in the stream any modes it knows about, and
leaves all unspecified mode bits in their default values, and only some the server MAY ignore any modes it does not know about. This
combinations make sense). allows some degree of machine-independence, at least between
systems that use a POSIX-like tty interface. The protocol can
support other systems as 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 server leaves all unspecified
mode bits in their default values, and only some combinations make
sense).
The following opcodes have been defined. The naming of opcodes mostly The following opcodes have been defined. The naming of opcodes
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).
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 terminal).
skipping to change at page 15, line 45 skipping to change at page 18, line 14
#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 8. 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-level transport. User authentication and protection against network-
attacks are assumed to be provided by the underlying protocols. level attacks are assumed to be provided by the underlying
protocols.
This protocol can, however, be used to execute commands on remote This protocol can, however, be used to execute commands on remote
machines. The protocol also permits the server to run commands on the machines. The protocol also permits the server to run commands on
client. Implementations may wish to disallow this to prevent an the client. Implementations may wish to disallow this to prevent
attacker from coming from the server machine to the client machine. an attacker from coming from the server machine to the client
machine.
X11 forwarding provides major security improvements over normal cookie- X11 forwarding provides major security improvements over normal
based X11 forwarding. The cookie never needs to be transmitted in the cookie-based X11 forwarding. The cookie never needs to be
clear, and traffic is encrypted and integrity-protected. No useful transmitted in the clear, and traffic is encrypted and integrity-
authentication data will remain on the server machine after the protected. No useful authentication data will remain on the
connection has been closed. On the other hand, in some situations a server machine after the connection has been closed. On the other
hand, in some situations a forwarded X11 connection might be used
to get access to the local X server across security perimeters.
forwarded X11 connection might be used to get access to the local X Port forwardings can potentially allow an intruder to cross
server across security perimeters. security perimeters such as firewalls. They do not offer anything
Port forwardings can potentially allow an intruder to cross security fundamentally new that a user could not do otherwise; however,
perimeters such as firewalls. They do not offer anything fundamentally they make opening tunnels very easy. Implementations should allow
new that a user could not do otherwise; however, they make opening policy control over what can be forwarded. Administrators should
tunnels very easy. Implementations should allow policy control over be able to deny forwardings where appropriate.
what can be forwarded. Administrators should be able to deny
forwardings where appropriate.
Since this protocol normally runs inside an encrypted tunnel, firewalls Since this protocol normally runs inside an encrypted tunnel,
will not be able to examine the traffic. firewalls will not be able to examine the traffic.
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 TCP/IP dangerous features (e.g. agent forwarding, X11 forwarding, and
forwarding) if the host key has changed. TCP/IP forwarding) if the host key has changed.
9. Trademark Issues 9. Trademark Issues
"ssh" is a registered trademark of SSH Communications Security Corp in As of this writing, SSH Communications Security Oy claims ssh as
the United States and/or other countries. its trademark. As with all IPR claims the IETF takes no position
regarding the validity or scope of this trademark claim.
10. References 10. Additional Information
[RFC-1766] Alvestrand, H: "Tags for the Identification of Languages", The current document editor is: Darren.Moffat@Sun.COM. Comments
March 1995. on this internet draft should be sent to the IETF SECSH working
group, details at: http://ietf.org/html.charters/secsh-
charter.html
[RFC-1884] Hinden, R., and Deering, S: "IP Version 6 Addressing References
Architecture", December 1995
[RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646", [RFC1766] Alvestrand, H., "Tags for the Identification of
January 1998. Languages", RFC 1766, March 1995.
[SCHEIFLER] Scheifler, R. W., et al: "X Window System : The Complete [RFC1884] Hinden, R., Deering, S. and Editors, "IP Version 6
Reference to Xlib, X Protocol, Icccm, Xlfd", 3rd edition, Digital Press, Addressing Architecture", RFC 1884, December 1995.
ISBN 1555580882, February 1992.
[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology [RFC2279] Yergeau, F., "UTF-8, a transformation format of
Application Program Interface (API) [C Language], July 1996. ISO 10646", RFC 2279, January 1998.
[SECSH-ARCH] Ylonen, T., et al: "Secure Shell Remote Login Protocol [SCHEIFLER] Scheifler, R., "X Window System : The Complete
Architecture", Internet-Draft, draft-ietf-secsh-architecture-08.txt Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
edition.", Digital Press ISBN 1555580882, Feburary
1992.
[SECSH-TRANS] Ylonen, T., et al: "Secure Shell Transport Layer [POSIX] ISO/IEC, 9945-1., "Information technology --
Protocol", Internet-Draft, draft-ietf-secsh-transport-10.txt Portable Operating System Interface (POSIX)-Part
1: System Application Program Interface (API) C
Language", ANSI/IEE Std 1003.1, July 1996.
[SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D
Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt draft-ietf-architecture-09.txt, July 2001.
11. Authors' Addresses [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-11.txt, July 2001.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D
draft-ietf-userauth-11.txt, July 2001.
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-
ietf-connect-11.txt, July 2001.
Authors' Addresses
Tatu Ylonen Tatu Ylonen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI HELSINKI FIN-00100
Finland Finland
E-mail: ylo@ssh.com
EMail: ylo@ssh.com
Tero Kivinen Tero Kivinen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI HELSINKI FIN-00100
Finland Finland
E-mail: kivinen@ssh.com
EMail: kivinen@ssh.com
Markku-Juhani O. Saarinen Markku-Juhani O. Saarinen
University of Jyvaskyla University of Jyvaskyla
Timo J. Rinne Timo J. Rinne
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI HELSINKI FIN-00100
Finland Finland
E-mail: tri@ssh.com
EMail: tri@ssh.com
Sami Lehtinen Sami Lehtinen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI HELSINKI FIN-00100
Finland Finland
E-mail: sjl@ssh.com
EMail: sjl@ssh.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing 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 revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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