[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 RFC 4254

Network Working Group                           Tatu Ylonen <ylo@ssh.fi>
INTERNET-DRAFT                               SSH Communications Security
draft-ietf-secsh-connect-01.txt                            July 30, 1997
Expires in six months


                        SSH Connection Protocol

Status of This memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).

Abstract

This document describes the SSH connection protocol.  It multiplexes a
single encrypted tunnel into a number of channels (interactive sessions,
forwarded TCP/IP ports, X11 connections, etc).  It is intended to run
above the SSH user authentication layer.

























Tatu Ylonen <ylo@ssh.fi>                                        [page 1]

INTERNET-DRAFT                                             July 30, 1997

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Global Requests   . . . . . . . . . . . . . . . . . . . . . . . .  2
3.  Channel Mechanism   . . . . . . . . . . . . . . . . . . . . . . .  3
  3.1.  Opening a Channel   . . . . . . . . . . . . . . . . . . . . .  3
  3.2.  Data Transfer   . . . . . . . . . . . . . . . . . . . . . . .  4
  3.3.  Closing a Channel   . . . . . . . . . . . . . . . . . . . . .  5
  3.4.  Channel-Specific Requests   . . . . . . . . . . . . . . . . .  5
4.  Interactive Sessions  . . . . . . . . . . . . . . . . . . . . . .  6
  4.1.  Opening a Session   . . . . . . . . . . . . . . . . . . . . .  6
  4.2.  Requesting a Pseudo-Terminal  . . . . . . . . . . . . . . . .  6
  4.3.  X11 Forwarding  . . . . . . . . . . . . . . . . . . . . . . .  7
    4.3.1.  Requesting X11 Forwarding   . . . . . . . . . . . . . . .  7
    4.3.2.  X11 Channels  . . . . . . . . . . . . . . . . . . . . . .  7
  4.4.  Authentication Agent Forwarding   . . . . . . . . . . . . . .  8
    4.4.1.  Requesting Athentication Agent Forwarding   . . . . . . .  8
    4.4.2.  Authentication Agent Channels   . . . . . . . . . . . . .  8
  4.5.  Environment Variable Passing  . . . . . . . . . . . . . . . .  8
  4.6.  Starting Shell or Command   . . . . . . . . . . . . . . . . .  9
  4.7.  Session Data Transfer   . . . . . . . . . . . . . . . . . . .  9
  4.8.  Window Change Message   . . . . . . . . . . . . . . . . . . .  9
  4.9.  Local Flow Control  . . . . . . . . . . . . . . . . . . . . . 10
  4.10.  Signals  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  4.11.  Returning Exit Status  . . . . . . . . . . . . . . . . . . . 10
5.  TCP/IP Port Forwarding  . . . . . . . . . . . . . . . . . . . . . 11
  5.1.  Requesting Port Forwarding  . . . . . . . . . . . . . . . . . 11
  5.2.  TCP/IP Forwarding Channels  . . . . . . . . . . . . . . . . . 11
6.  FTP Forwarding  . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.  Encoding of Terminal Modes  . . . . . . . . . . . . . . . . . . . 12
8.  Summary of Message Numbers  . . . . . . . . . . . . . . . . . . . 16
9.  Security Considerations   . . . . . . . . . . . . . . . . . . . . 16
10.  Address of Author  . . . . . . . . . . . . . . . . . . . . . . . 17



1.  Introduction

This protocol has been designed to run over the SSH transport layer and
user authentication protocols.  The service name for this protocol
(after user authentication) is "ssh-connection".  It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections.

2.  Global Requests

There are several kinds of requests that affect the state of the remote
end "globally", independent of any channels.  An example is a request to
start TCP/IP forwarding for a specific port.  All such requests use the
following format.

            byte      SSH_MSG_GLOBAL_REQUEST
            string    request name


Tatu Ylonen <ylo@ssh.fi>                                        [page 2]

INTERNET-DRAFT                                             July 30, 1997

            boolean   want_reply
            ... request-specific data follows

The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS,
SSH_MSG_REQUEST_FAILURE, or some request-specific continuation messages.
If the recipient does not recognize or support the request, it simply
responds with SSH_MSG_REQUEST_FAILURE.

            byte      SSH_MSG_REQUEST_SUCCESS

            byte      SSH_MSG_REQUEST_FAILURE

3.  Channel Mechanism

All terminal sessions, forwarded connections, etc. are channels.  Either
side may open a channel.  Multiple channels are multiplexed on the
single connection.

Channels are identified by numbers at each end.  The number referring to
a channel may be different on each side.  Requests to open a channel
contain the sender's channel number.  Any other 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
message is received to indicate that window space is available.

3.1.  Opening a Channel

When either side wishes to open a new channel, it allocates a local
number for the channel.  It then sends the following message to the
other side, and includes the local channel number and initial window
size in the message.

            byte      SSH_MSG_CHANNEL_OPEN
            string    channel type
            uint32    sender_channel
            uint32    initial_window_size
            uint32    max_packet_size
            ... channel type specific data follows

The channel type is a name as described in the transport layer protocol,
with similar extension mechanisms (the domain name suffic convention).
Sender_channel is a local identifier for the channel used by the sender
of this message.  Initial_window_size specifies how many bytes of
channel data can be sent to the sender of this message without adjusting
the window.  Max_packet_size specifies the maximum size of an individual
data packet that can be sent to the sender (for example, one might want
to use smaller packets for interactive connections to get better
interactive response on slow links).

The remote side then decides whether it can open the channel, and
responds with either



Tatu Ylonen <ylo@ssh.fi>                                        [page 3]

INTERNET-DRAFT                                             July 30, 1997

  byte      SSH_MSG_CHANNEL_OPEN_CONFIRMATION
  uint32    recipient_channel
  uint32    sender_channel
  uint32    initial_window_size
  uint32    max_packet_size
  ... channel type specific data follows

where recipient_channel is the channel number given in the original open
request, and sender_channel is the channel number allocated by the other
side, or

            byte      SSH_MSG_CHANNEL_OPEN_FAILURE
            uint32    recipient_channel
            uint32    reason_code

If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support
the specified channel type, it simply responds with
SSH_MSG_CHANNEL_OPEN_FAILURE.

The following reason codes are defined:

#define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED    1
#define SSH_OPEN_CONNECT_FAILED                 2
#define SSH_OPEN_UNKNOWN_CHANNEL_TYPE           3
#define SSH_OPEN_RESOURCE_SHORTAGE              4

3.2.  Data Transfer

The window size specifies how many characters the other party can send
before it must wait for the window to be adjusted.  Both parties use the
following message to adjust the window.

            byte      SSH_MSG_CHANNEL_WINDOW_ADJUST
            uint32    recipient_channel
            uint32    bytes_to_add

Upon receiving this message, the recipient increases the number of bytes
it is allowed to send by the given amount.

Data transfer is done with messages of the following type.

            byte      SSH_MSG_CHANNEL_DATA
            uint32    recipient_channel
            string    data

The maximum amount of data allowed is the current window size.  The
window size is decremented by the amount of data sent.

Additionally, some channels can transfer several types of data.  An
example of this is stderr data from interactive sessions.  Such data can
be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate
integer specifies the type of the data.  The available types and their
interpretation depend on the type of the channel.


Tatu Ylonen <ylo@ssh.fi>                                        [page 4]

INTERNET-DRAFT                                             July 30, 1997

            byte      SSH_MSG_CHANNEL_EXTENDED_DATA
            uint32    recipient_channel
            uint32    data_type_code
            string    data

Data sent with these messages consumes the same window as ordinary data.

Currently, only the following type is defined.

          #define SSH_EXTENDED_DATA_STDERR                1

3.3.  Closing a Channel

When a party will no longer send more data to a channel, it should send
SSH_MSG_CHANNEL_EOF.

            byte      SSH_MSG_CHANNEL_EOF
            uint32    recipient_channel

No explicit response is sent to this message; however, the application
may send EOF to whatever is at the other end of the channel.  Note that
the channel remains open after this message, and more data may still be
sent in the other direction.  This message does not consume window space
and can be sent even if no window space is available.

When either party wishes to terminate the channel, it sends
SSH_MSG_CHANNEL_CLOSE.  Upon receiving this message, a party must send
back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message
for the channel.  The channel is considered closed for a party when it
has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then
reuse the channel number.  It is legal to send SSH_MSG_CHANNEL_CLOSE
without having sent or received SSH_MSG_EOF.

            byte      SSH_MSG_CHANNEL_CLOSE
            uint32    recipient_channel

This message does not consume window space and can be sent even if no
window space is available.

It is recommended that any data sent before this message be delivered to
the actual destination, if possible.  This message should not normally
flush buffers.

3.4.  Channel-Specific Requests

Many channel types have extensions that are specific to that particular
channel type.  An example is requesting a pty for an interactive
session.

All channel-specific requests use the following format.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel


Tatu Ylonen <ylo@ssh.fi>                                        [page 5]

INTERNET-DRAFT                                             July 30, 1997

            string    request type
            boolean   want_reply
            ... type-specific data

If want_reply is FALSE, no response will be sent to the request.
Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages.  If
the request is not recognized 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
window space is available.

Request names are local to each channel type (it is recommended that
names with the same extension rules again be used).

The client is allowed to send further messages without waiting for the
response to the request.

            byte      SSH_MSG_CHANNEL_SUCCESS
            uint32    recipient_channel

            byte      SSH_MSG_CHANNEL_FAILURE
            uint32    recipient_channel

These messages do not consume window space and can be sent even if no
window space is available.

4.  Interactive Sessions

A session is a remote execution of a command.  The command may be a
shell, a program, or some built-in subsystem.  It may or may not have a
tty, and may or may not involve X11 forwarding.  Multiple sessions can
be active simultaneously.

4.1.  Opening a Session

A session is started by sending the following message.  While this
message can be sent by either side, it is normally recommended for
clients not to permit opening new sessions to avoid a corrupt server
from attacking clients.

            byte      SSH_MSG_CHANNEL_OPEN
            string    "session"
            uint32    sender_channel
            uint32    initial_window_size
            uint32    max_packet_size

4.2.  Requesting a Pseudo-Terminal

A pseudo-terminal can be allocated for the session by sending the
following message.



Tatu Ylonen <ylo@ssh.fi>                                        [page 6]

INTERNET-DRAFT                                             July 30, 1997

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "pty-req"
            boolean   want_reply
            string    TERM environment variable value (e.g., vt100)
            uint32    terminal width, characters (e.g., 80)
            uint32    terminal height, rows (e.g., 24)
            uint32    terminal width, pixels (e.g., 480)
            uint32    terminal height, pixels (e.g., 640)
            string    encoded terminal modes

The encoding of terminal modes is described in Section ``Encoding of
Terminal Modes''.

4.3.  X11 Forwarding

4.3.1.  Requesting X11 Forwarding

X11 forwarding may be requested for a session by sending

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "x11-req"
            boolean   want_reply
            boolean   single_connection
            string    x11_authentication_protocol
            string    x11_authentication_cookie
            uint32    x11_screen_number

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
cookie when a connection request is received.

X11 connection forwarding should stop when the session channel is
closed; however, already opened forwardings should not be automatically
closed when the session channel is closed.
If single_connection is true, only a single connection should be
forwarded.  No more connections will be forwarded after the first, or
after the session channel has been closed.

4.3.2.  X11 Channels

Forwarded X11 connections are normal channels, independent of the
session that originated them.  X11 channels are opened with a normal
channel open request.  The resulting channels are independent of the
session, and closing the session channel does not imply closing
forwarded X11 channels.

            byte      SSH_MSG_CHANNEL_OPEN
            string    "x11"
            uint32    sender_channel
            uint32    initial_window_size
            uint32    max_packet_size


Tatu Ylonen <ylo@ssh.fi>                                        [page 7]

INTERNET-DRAFT                                             July 30, 1997

            string    originator_string

The recipient should respond with open confirmation or open failure.
Originator_string is a free-form implementation-dependent description of
the X11 client that made the connection.  It should typically contain
the IP address and port of the client, and may also contain user name or
other information if available.  It should be in a format that is
understandable by a user.

4.4.  Authentication Agent Forwarding

4.4.1.  Requesting Athentication 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 is allowed
to send futher messages without waiting for the reponse 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    max_packet_size

The recipient should respond with open confirmation or open failure.

4.5.  Environment Variable Passing

Environment variables may be passed to the shell/command to be started
later.  Typically, each machine will have a preconfigured set of
variables that it will allow.  Since uncontrolled setting of environment
variables can be very dangerous, it is recommended that implementations
allow setting only variables whose names have been explicitly configured
to be allowed.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "env"
            boolean   want_reply
            string    variable_name
            string    variable_value


Tatu Ylonen <ylo@ssh.fi>                                        [page 8]

INTERNET-DRAFT                                             July 30, 1997

4.6.  Starting Shell or Command

Once the session has been set up, a shell or command is started at the
remote end.  This can happen in any of a number of ways.  Only one of
these requests can succeed per channel.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "shell"
            boolean   want_reply

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "exec"
            boolean   want_reply
            string    command

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "subsystem"
            boolean   want_reply
            string    subsystem_name

This last form executes a predefined subsystem.  It expected that these
will include a general file transfer mechanism, and possibly other
features.  Implementations may also allow configuring more such
mechanisms.  Having a special message for them avoids the need to have
their paths and command names be supplied by the other side.  This also
makes it easier to implement them in the same executable as the rest of
the protocol on platforms where that is desirable.

It is strongly recommended to request and check the reply for these
messages.

4.7.  Session Data Transfer

Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and
SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism.  The
extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr
data.

4.8.  Window Change Message

When the window (terminal) size changes on the client side (client here
means the party who sent the create message for the session), it may
send a message to the other side to inform it of the new size.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "window-change"
            boolean   FALSE
            uint32    terminal width, columns
            uint32    terminal height, rows


Tatu Ylonen <ylo@ssh.fi>                                        [page 9]

INTERNET-DRAFT                                             July 30, 1997

            uint32    terminal width, pixels
            uint32    terminal height, pixels

No response is sent to this message.

4.9.  Local Flow Control

On many systems it is possible to determine if a pseudo-terminal is
using control-S control-Q flow control.  When this is the case, 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 two
notifications.  Initially, the server is responsible for flow control.
(Here, again, client means the side originating the session, and server
the other side.)

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
client_can_do is true, the client is allowed to do flow control using
control-S and control-Q.  The client is allowed to ignore this message.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "xon-xoff"
            boolean   FALSE
            boolean   client_can_do

If client_can_do is true, the client (originator) can do control-S
control-Q flow control locally.

No response is sent to this message.

4.10.  Signals

A signal can be delivered to the remote process/service using the
following message.  Some systems may not implement signals, in which
case they will ignore this message.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "signal"
            boolean   FALSE
            uint32    signal_number

4.11.  Returning Exit Status

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

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel


Tatu Ylonen <ylo@ssh.fi>                                       [page 10]

INTERNET-DRAFT                                             July 30, 1997

            string    "exit-status"
            string    FALSE
            uint32    exit_status

The remote command may also terminate violently due to a signal.  Such a
condition can be indicated by the following message.

            byte      SSH_MSG_CHANNEL_REQUEST
            uint32    recipient_channel
            string    "exit-signal"
            string    FALSE
            uint32    signal number
            boolean   core dumped

5.  TCP/IP Port Forwarding

5.1.  Requesting Port Forwarding

A party need not explicitly request forwardings from its own end to the
other direction.  However, it if wishes to have connections to a port on
the other side be forwarded to the local side, it must explicitly
request this.

            byte      SSH_MSG_GLOBAL_REQUEST
            string    "tcpip-forward"
            boolean   want_reply
            string    address_to_bind
            uint32    port_number_to_bind

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 should be
"0.0.0.0" if connections are allowed from anywhere.  (Note that the
client can still filter connections based on information passed in the
open request.)

Implementations should only allow forwarding privileged ports if the
user has been authenticated as a privileged user.

A port forwarding can be cancelled with the following message.  Note
that channel open requests may be received until a reply to this message
is received.

            byte      SSH_MSG_GLOBAL_REQUEST
            string    "cancel-tcpip-forward"
            boolean   want_reply
            string    address_to_bind
            uint32    port_number_to_bind

5.2.  TCP/IP Forwarding Channels

When a connection comes to a port for which remote forwarding has been
requested, a channel is opened to forward the port to the other side.



Tatu Ylonen <ylo@ssh.fi>                                       [page 11]

INTERNET-DRAFT                                             July 30, 1997

  byte      SSH_MSG_CHANNEL_OPEN
  string    "forwarded-tcpip"
  uint32    sender_channel
  uint32    initial_window_size
  uint32    max_packet_size
  string    address_that_was_connected
  uint32    port_that_was_connected
  string    originator_ip_address
  uint32    originator_port
  string    originator_string

When a connection comes to a locally forwarded TCP/IP port, the
following packet is sent to the other side.  Note that these messages
may be sent also for ports for which no forwarding has been explicitly
requested.  The receiving side must decide whether to allow the
forwarding.

            byte      SSH_MSG_CHANNEL_OPEN
            string    "direct-tcpip"
            uint32    sender_channel
            uint32    initial_window_size
            uint32    max_packet_size
            string    host_to_connect
            uint32    port_to_connect
            string    originator_ip_address
            uint32    originator_port
            string    originator_string

Host_to_connect and port_to_connect specify the TCP/IP host and port
where the recipient should connect the channel.  Host_to_connect may be
either a domain name or a numeric IP address.

Originator_ip_address is the numeric IP address of the machine where the
connection request comes from, and originator_port is the port on the
originator host from where the connection came from.  Originator_string
is a free-form description of where the connection came in a form that
can be displayed to the user.

Forwarded TCP/IP channels are independent of any sessions, and closing a
session channel does not in any way imply that forwarded connections
should be closed.

6.  FTP Forwarding

XXX

7.  Encoding of Terminal Modes

Terminal modes (as passed in a pty request) are encoded into a byte
stream.  It is intended that the coding be portable across different
environments.

The tty mode description is a stream of bytes.  The stream consists of


Tatu Ylonen <ylo@ssh.fi>                                       [page 12]

INTERNET-DRAFT                                             July 30, 1997

opcode-argument pairs.  It is terminated by opcode TTY_OP_END (0).
Opcodes 1-127 have one-byte arguments.  Opcodes 128-159 have 32-bit
integer arguments (stored msb first).  Opcodes 160-255 are not yet
defined, and cause parsing to stop (they should only be used after any
other data).

The client puts in the stream any modes it knows about, and the server
ignores any modes it does not know about.  This 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
follows the POSIX terminal mode flags.

   0 TTY_OP_END
      Indicates end of options.

   1 VINTR
      Interrupt character; 255 if none.  Similarly for the other
      characters.  Not all of these characters are supported on all
      systems.

   2 VQUIT
      The quit character (sends SIGQUIT signal on UNIX systems).

   3 VERASE
      Erase the character to left of the cursor.

   4 VKILL
      Kill the current input line.

   5 VEOF
      End-of-file character (sends EOF from the terminal).

   6 VEOL
      End-of-line character in addition to carriage return and/or
      linefeed.

   7 VEOL2
      Additional end-of-line character.

   8 VSTART
      Continues paused output (normally control-Q).
   9 VSTOP
      Pauses output (normally control-S).

   10 VSUSP
      Suspends the current program.



Tatu Ylonen <ylo@ssh.fi>                                       [page 13]

INTERNET-DRAFT                                             July 30, 1997

   11 VDSUSP
      Another suspend character.

   12 VREPRINT
      Reprints the current input line.

   13 VWERASE
      Erases a word left of cursor.

   14 VLNEXT
      More special input characters; these are probably not supported on
      most systems.

   15 VFLUSH
      Character to flush output.

   16 VSWTCH
      ???

   17 VSTATUS
      ???

   18 VDISCARD
      ???

   30 IGNPAR
      The ignore parity flag.  The next byte should be 0 if this flag is
      not set, and 1 if it is set.

   31 PARMRK
      Mark parity and framing errors.

   32 INPCK
      Enable checking of parity errors.

   33 ISTRIP
      Strip 8th bit off chars.

   34 INLCR
      Map NL into CR on input.

   35 IGNCR
      Ignore CR on input.

   36 ICRNL
      Map CR to NL on input.

   37 IUCLC
      ???

   38 IXON
      Enable output flow control.



Tatu Ylonen <ylo@ssh.fi>                                       [page 14]

INTERNET-DRAFT                                             July 30, 1997

   39 IXANY
      Any char will restart after stop.

   40 IXOFF
      Enable input flow control.

   41 IMAXBEL
      Ring bell on input queue full.

   50 ISIG
      Enable signals INTR, QUIT, DSUSP.

   51 ICANON
      Canonicalize input lines.

   52 XCASE
      ???

   53 ECHO
      Enable echoing.

   54 ECHOE
      Visually erase chars.

   55 ECHOK
      Kill character discards current line.

   56 ECHONL
      Echo NL even if ECHO is off.

   57 NOFLSH
      Don't flush after interrupt.

   58 TOSTOP
      Stop background jobs from output.

   59 IEXTEN
      Enable extensions.

   60 ECHOCTL
      Echo control characters as ^(Char).

   61 ECHOKE
      Visual erase for line kill.

   62 PENDIN
      Retype pending input.

   70 OPOST
      Enable output processing.

   71 OLCUC
      Convert lowercase to uppercase.


Tatu Ylonen <ylo@ssh.fi>                                       [page 15]

INTERNET-DRAFT                                             July 30, 1997

   72 ONLCR
      Map NL to CR-NL.

   73 OCRNL
      ???

   74 ONOCR
      ???

   75 ONLRET
      ???

   90 CS7
      7 bits.

   91 CS8
      8 bits.

   92 PARENB
      Parity enable.

   93 PARODD
      Odd parity, else even.

   128 TTY_OP_ISPEED
      Specifies the input baud rate in bits per second (as a 32-bit int,
      msb first).

   129 TTY_OP_OSPEED
      Specifies the output baud rate in bits per second (as a 32-bt int,
      msb first).

8.  Summary of Message Numbers

          #define SSH_MSG_GLOBAL_REQUEST                  30
          #define SSH_MSG_REQUEST_SUCCESS                 31
          #define SSH_MSG_REQUEST_FAILURE                 32
          #define SSH_MSG_CHANNEL_OPEN                    33
          #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION       34
          #define SSH_MSG_CHANNEL_OPEN_FAILURE            35
          #define SSH_MSG_CHANNEL_WINDOW_ADJUST           36
          #define SSH_MSG_CHANNEL_DATA                    37
          #define SSH_MSG_CHANNEL_EXTENDED_DATA           38
          #define SSH_MSG_CHANNEL_EOF                     39
          #define SSH_MSG_CHANNEL_CLOSE                   40
          #define SSH_MSG_CHANNEL_REQUEST                 41
          #define SSH_MSG_CHANNEL_SUCCESS                 42
          #define SSH_MSG_CHANNEL_FAILURE                 43

9.  Security Considerations

This protocol is assumed to run on top of a secure, authenticated
protocol.  User authentication and protection against network-level


Tatu Ylonen <ylo@ssh.fi>                                       [page 16]

INTERNET-DRAFT                                             July 30, 1997

attacks are assumed to be provided by the underlying protocol.

This protocol can, however, be used to execute commands on remote
machines.  The protocol also permits the server to run commands on the
client.  Implementations may wish to disallow this to prevent an
attacker from coming from the server machine to the client machine.

X11 forwarding provides major security improvements over normal cookie-
based X11 forwarding.  The cookie never needs to be transmitted in the
clear, and traffic is encrypted and integrity-protected.  No useful
authentication data will remain on the 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.

Port forwardings can potentially allow an intruder to cross security
perimeters such as firewalls.  They do not offer anything fundamentally
new that a user couldn't do otherwise; however, they make opening
tunnels very easy.  Implementations should allow policy control over
what can be forwarded.  Administrators should be able to deny
forwardings where appropriate.

Since this protocol normally runs inside an encrypted tunnel, firewalls
will not be able to examine the traffic.

10.  Address of Author

              Tatu Ylonen
              SSH Communications Security Ltd.
              Tekniikantie 12
              FIN-02150 ESPOO
              Finland

              E-mail: ylo@ssh.fi




















Tatu Ylonen <ylo@ssh.fi>                                       [page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/