draft-ietf-secsh-connect-07.txt   draft-ietf-secsh-connect-08.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-connect-07.txt M. Saarinen draft-ietf-secsh-connect-08.txt M. Saarinen
Expires in six months T. Rinne Expires in six months T. Rinne
S. Lehtinen S. Lehtinen
SSH Communications Security SSH Communications Security
11 May 2000 21 Nov, 2000
SSH Connection Protocol SSH Connection Protocol
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 all provisions of Section 10 of RFC2026. with 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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.
Abstract Abstract
SSH is a protocol for secure remote login and other secure network ser- SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network. This document describes the SSH connec- vices over an insecure network. This document describes the SSH Connec-
tion protocol. It provides interactive login sessions, remote execution tion Protocol. It provides interactive login sessions, remote execution
of commands, forwarded TCP/IP connections, and forwarded X11 connec- of commands, forwarded TCP/IP connections, and forwarded X11 connec-
tions. All of these channels are multiplexed into a single encrypted tions. All of these channels are multiplexed into a single encrypted
tunnel. The SSH Connection Protocol has been designed to run on top of tunnel. The SSH Connection Protocol has been designed to run on top of
the SSH transport layer and user authentication protocols. the SSH transport layer and user authentication protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Global Requests . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Global Requests . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . . 3 3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Opening a Channel . . . . . . . . . . . . . . . . . . . . . 3 3.1. Opening a Channel . . . . . . . . . . . . . . . . . . . . . 3
3.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 5 3.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 5
3.4. Channel-Specific Requests . . . . . . . . . . . . . . . . . 6 3.4. Channel-Specific Requests . . . . . . . . . . . . . . . . . 5
4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . . 6 4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Opening a Session . . . . . . . . . . . . . . . . . . . . . 6 4.1. Opening a Session . . . . . . . . . . . . . . . . . . . . . 6
4.2. Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 7 4.2. Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 6
4.3. X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Requesting X11 Forwarding . . . . . . . . . . . . . . . 7 4.3.1. Requesting X11 Forwarding . . . . . . . . . . . . . . . 7
4.3.2. X11 Channels . . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. X11 Channels . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Authentication Agent Forwarding . . . . . . . . . . . . . . 8 4.4. Environment Variable Passing . . . . . . . . . . . . . . . . 8
4.4.1. Requesting Authentication Agent Forwarding . . . . . . . 8 4.5. Starting a Shell or a Command . . . . . . . . . . . . . . . 8
4.4.2. Authentication Agent Channels . . . . . . . . . . . . . 8 4.6. Session Data Transfer . . . . . . . . . . . . . . . . . . . 9
4.5. SSH1 Authentication Agent Forwarding . . . . . . . . . . . . 9 4.7. Window Dimension Change Message . . . . . . . . . . . . . . 9
4.5.1. Requesting SSH1 Authentication Agent Forwarding . . . . 9 4.8. Local Flow Control . . . . . . . . . . . . . . . . . . . . . 9
4.5.2. SSH1 Authentication Agent Channels . . . . . . . . . . . 9 4.9. Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Environment Variable Passing . . . . . . . . . . . . . . . . 9 4.10. Returning Exit Status . . . . . . . . . . . . . . . . . . . 10
4.7. Starting a Shell or a Command . . . . . . . . . . . . . . . 10 5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . . 11
4.8. Session Data Transfer . . . . . . . . . . . . . . . . . . . 10 5.1. Requesting Port Forwarding . . . . . . . . . . . . . . . . . 11
4.9. Window Dimension Change Message . . . . . . . . . . . . . . 11 5.2. TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 12
4.10. Local Flow Control . . . . . . . . . . . . . . . . . . . . 11 6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . . 13
4.11. Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Summary of Message Numbers . . . . . . . . . . . . . . . . . . . 15
4.12. Returning Exit Status . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 15
5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . . 12 9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Requesting Port Forwarding . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 13 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . . 14
7. Summary of Message Numbers . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 16
9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The SSH Connection Protocol has been designed to run on top of the SSH The SSH Connection Protocol has been designed to run on top of the SSH
transport layer and user authentication protocols. It provides transport layer and user authentication protocols. It provides
interactive login sessions, remote execution of commands, forwarded interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. The service name for TCP/IP connections, and forwarded X11 connections. The service name for
this protocol (after user authentication) is "ssh-connection". this protocol (after user authentication) is "ssh-connection".
This document should be read only after reading the SSH architecture This document should be read only after reading the SSH architecture
skipping to change at page 4, line 57 skipping to change at page 4, line 49
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 before
it must wait for the window to be adjusted. Both parties use the it must wait for the window to be adjusted. Both parties use the
following message to adjust the window. 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 number of
bytes more that it was previously allowed to send; the window size is bytes more than it was previously allowed to send; the window size is
incremented. 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. The
window size is decremented by the amount of data sent. Both parties MAY window size is decremented by the amount of data sent. Both parties MAY
skipping to change at page 8, line 4 skipping to change at page 7, line 51
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 fake,
random cookie, and that the cookie is checked and replaced by the real random cookie, and that the cookie is checked and replaced by the real
cookie when a connection request is received. 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 automatically
closed when the session channel is closed. 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.
`X11 authentication protocol is the name of the X11 authentication `X11 authentication protocol is the name of the X11 authentication
method used, i.e. "MIT-MAGIC-COOKIE-1". method used, i.e. "MIT-MAGIC-COOKIE-1".
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 resulting
channels are independent of the session, and closing the session channel channels are independent of the session, and closing the session channel
does not close the forwarded X11 channels. 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_CONFIRMATION or
SSH_MSG_CHANNEL_OPEN_FAILURE. 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 have
not requested X11 forwarding. not requested X11 forwarding.
4.4. Authentication Agent Forwarding 4.4. Environment Variable Passing
It is RECOMMENDED that authentication agent forwarding is allowed even
when either or both parties do not support the SSH authentication agent
protocol [SSH-AGENT].
4.4.1. Requesting Authentication Agent Forwarding
Authentication agent forwarding may be requested for a session by
sending
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "auth-agent-req"
boolean want reply
The server responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE (if `want reply' is TRUE). The client MAY send
further messages without waiting for the response to this message.
4.4.2. Authentication Agent Channels
When an application requests a connection to the authentication agent,
the following message is sent to the originator of the session.
byte SSH_MSG_CHANNEL_OPEN
string "auth-agent"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
The recipient SHOULD respond with open confirmation or open failure.
Implementations MUST reject any agent channel open requests if they have
not requested agent forwarding.
4.5. SSH1 Authentication Agent Forwarding
Implementations MAY support ssh1 authentication agent forwarding in
order to provide compatibility with old ssh versions.
4.5.1. Requesting SSH1 Authentication Agent Forwarding
Authentication agent forwarding may be requested for a session by
sending
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "auth-ssh1-agent-req"
boolean want reply
The server responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE (if `want reply' is TRUE). The client MAY send
further messages without waiting for the response to this message.
4.5.2. SSH1 Authentication Agent Channels
When an application requests a connection to the authentication agent,
the following message is sent to the originator of the session.
byte SSH_MSG_CHANNEL_OPEN
string "auth-ssh1-agent"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
The recipient SHOULD respond with open confirmation or open failure.
Implementations MUST reject any agent channel open requests if they have
not requested ssh1 agent forwarding.
4.6. 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 started
later. Typically, each machine will have a preconfigured set of later. Typically, each machine will have a preconfigured set of
variables that it will allow. Since uncontrolled setting of environment variables that it will allow. Since uncontrolled setting of environment
variables can be very dangerous, it is recommended that implementations variables can be very dangerous, it is recommended that implementations
allow setting only variables whose names have been explicitly configured allow setting only variables whose names have been explicitly configured
to be allowed. 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.7. 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 remote
end. Program can be a shell, an application program or a subsystem with end. The program can be a shell, an application program or a subsystem
a host-independent name. Only one of these requests can succeed per with a host-independent name. Only one of these requests can succeed
channel. 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 defined in
/etc/passwd in UNIX systems) to be started at the other end.
/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 given
command. The command string may contain a path. Normal precautions MUST command. The command string may contain a path. Normal precautions MUST
be taken to prevent the execution of unauthorized commands. be taken to prevent the execution of unauthorized commands.
skipping to change at page 11, line 5 skipping to change at page 9, line 34
features. Implementations may also allow configuring more such features. Implementations may also allow configuring more such
mechanisms. mechanisms.
The server SHOULD not halt the execution of the protocol stack when The server SHOULD not halt the execution of the protocol stack when
starting a shell or a program. All input and output from these SHOULD be starting a shell or a program. All input and output from these SHOULD be
redirected to the channel or to the encrypted tunnel. 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 messages. The
client SHOULD ignore these messages. client SHOULD ignore these messages.
4.8. 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. The
extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr
data. data.
4.9. 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 send
a message to the other side to inform it of the new dimensions. 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.10. 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 is
using control-S control-Q flow control. When flow control is allowed, using control-S/control-Q flow control. When flow control is allowed,
it is often desirable to do the flow control at the client end to speed it is often desirable to do the flow control at the client end to speed
up responses to user requests. This is facilitated by the following up responses to user requests. This is facilitated by the following
notification. Initially, the server is responsible for flow control. notification. Initially, the server is responsible for flow control.
(Here, again, client means the side originating the session, and server (Here, again, client means the side originating the session, and server
the other side.) 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 it can
or cannot perform flow control (control-S/control-Q processing). If or cannot perform flow control (control-S/control-Q processing). If
`client can do' is TRUE, the client is allowed to do flow control using `client can do' is TRUE, the client is allowed to do flow control using
control-S and control-Q. The client MAY ignore this message. 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.11. 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 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
uint32 signal number string signal name without the "SIG" prefix.
4.12. Returning Exit Status Signal names will be encoded as discussed in the "exit-signal"
SSH_MSG_CHANNEL_REQUEST.
When the command running at the other end terminates, The following 4.10. Returning Exit Status
When the command running at the other end terminates, the following
message can be sent to return the exit status of the command. Returning message can be sent to return the exit status of the command. Returning
the status is RECOMMENDED. No acknowledgment is sent for this message. the status is RECOMMENDED. No acknowledgment is sent for this message.
The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this
message. 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"
skipping to change at page 12, line 33 skipping to change at page 11, line 13
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. Such a
condition can be indicated by the following message. A zero exit_status condition can be indicated by the following message. A zero exit_status
usually means that the command terminated successfully. 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
uint32 signal number string signal name without the "SIG" prefix.
boolean core dumped boolean core dumped
string error message (ISO-10646 UTF-8 [RFC-2044]) string error message (ISO-10646 UTF-8 [RFC-2044])
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-1766])
The signal name is one of the following (these are from [POSIX]):
ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2
Additional signal names MAY be sent in the format "sig-name@xyz", where
`sig-name' and `xyz' may be anything a particular implementor wants
(except the `@' sign). However, it is suggested that if a `configure'
script is used, the non-standard signal names it finds be encoded as
"SIG@xyz.config.guess", where `SIG' 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 error
message. The message may consist of multiple lines. The client software message. The message may consist of multiple lines. The client software
MAY display this message to the user. If this is done, the client MAY display this message to the user. If this is done, the client
software should take the precautions discussed in [SSH-ARCH]. 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 A party need not explicitly request forwardings from its own end to the
other direction. However, if it wishes to have connections to a port on other direction. However, if it wishes that connections to a port on
the other side be forwarded to the local side, it must explicitly the other side be forwarded to the local side, it must explicitly
request this. 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 and
skipping to change at page 14, line 32 skipping to change at page 13, line 36
security reasons. 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 byte
stream. It is intended that the coding be portable across different stream. It is intended that the coding be portable across different
environments. environments.
The tty mode description is a stream of bytes. The stream consists of 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). opcode-argument pairs. It is terminated by opcode TTY_OP_END (0).
Opcodes 1-159 have a single uint32 argument. Opcodes 160-255 are not yet Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are
defined, and cause parsing to stop (they should only be used after any not yet defined, and cause parsing to stop (they should only be used
other data). after any other data).
The client SHOULD put in the stream any modes it knows about, and the The client SHOULD put in the stream any modes it knows about, and the
server MAY ignore any modes it does not know about. This allows some server MAY ignore any modes it does not know about. This allows some
degree of machine-independence, at least between systems that use a degree of machine-independence, at least between systems that use a
POSIX-like tty interface. The protocol can support other systems as POSIX-like tty interface. The protocol can support other systems as
well, but the client may need to fill reasonable values for a number of 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 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 leaves all unspecified mode bits in their default values, and only some
combinations make sense). combinations make sense).
skipping to change at page 16, line 46 skipping to change at page 15, line 51
X11 forwarding provides major security improvements over normal cookie- X11 forwarding provides major security improvements over normal cookie-
based X11 forwarding. The cookie never needs to be transmitted in the based X11 forwarding. The cookie never needs to be transmitted in the
clear, and traffic is encrypted and integrity-protected. No useful clear, and traffic is encrypted and integrity-protected. No useful
authentication data will remain on the server machine after the authentication data will remain on the server machine after the
connection has been closed. On the other hand, in some situations a 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 forwarded X11 connection might be used to get access to the local X
server across security perimeters. server across security perimeters.
Port forwardings can potentially allow an intruder to cross security Port forwardings can potentially allow an intruder to cross security
perimeters such as firewalls. They do not offer anything fundamentally perimeters such as firewalls. They do not offer anything fundamentally
new that a user couldn't do otherwise; however, they make opening new that a user could not do otherwise; however, they make opening
tunnels very easy. Implementations should allow policy control over tunnels very easy. Implementations should allow policy control over
what can be forwarded. Administrators should be able to deny what can be forwarded. Administrators should be able to deny
forwardings where appropriate. forwardings where appropriate.
Since this protocol normally runs inside an encrypted tunnel, firewalls Since this protocol normally runs inside an encrypted tunnel, firewalls
will not be able to examine the traffic. will not be able to examine the traffic.
It is RECOMMENDED that implementations disable all of 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 TCP/IP
forwarding) if the host key has changed. forwarding) if the host key has changed.
9. Trademark Issues 9. Trademark Issues
SSH is a registered trademark and Secure Shell is a trademark of SSH SSH is a registered trademark and Secure Shell is a trademark of SSH
Communications Security Corp. SSH Communications Security Corp permits Communications Security Corp. SSH Communications Security Corp permits
the use of these trademarks as the name of this standard and protocol, the use of these trademarks as the name of this standard and protocol,
and permits their use to describe that a product conforms to this and permits their use to describe that a product conforms to this
standard, provided that the following acknowledgement is included where standard, provided that the following acknowledgement is included where
skipping to change at page 17, line 29 skipping to change at page 16, line 33
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages",
March 1995. March 1995.
[RFC-1884] Hinden, R., and Deering, S., "IP Version 6 Addressing [RFC-1884] Hinden, R., and Deering, S., "IP Version 6 Addressing
Architecture", December 1995 Architecture", December 1995
[RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and
ISO 10646", October 1996. ISO 10646", October 1996.
[Scheifler] Scheifler, R. W., et al, "X Window System : The Complete
Reference to Xlib, X Protocol, Icccm, Xlfd", 3rd edition, Digital Press,
ISBN 1555580882, February 1992.
[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information
technology-- Portable Operating System Interface (POSIX)-Part 1: System
Application Program Interface (API) [C Language], July 1996.
[SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet
Draft, draft-ietf-secsh-architecture-05.txt Draft, draft-ietf-secsh-architecture-05.txt
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet
Draft, draft-ietf-secsh-transport-07.txt Draft, draft-ietf-secsh-transport-07.txt
[SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol",
Internet Draft, draft-ietf-secsh-userauth-07.txt Internet Draft, draft-ietf-secsh-userauth-07.txt
11. Authors' Addresses 11. Authors' Addresses
 End of changes. 

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