rfc.nroff

OpenSSL Source code for SFTP, SSH, and many others

Either party may send this message at any time.  This message, and the
argument string, is silently ignored.  This message might be used in
some implementations to make traffic analysis more difficult.  This
message is not currently sent by the implementation, but all
implementations are required to recognize and ignore it.
.IP "33 SSH_CMSG_EXIT_CONFIRMATION"

(no arguments)

Sent by the client in response to SSH_SMSG_EXITSTATUS.  This is the
last message sent by the client.
.IP "34 SSH_CMSG_X11_REQUEST_FORWARDING"
.TS
;
l l.
string	x11_authentication_protocol
string	x11_authentication_data
32-bit int	screen number (if SSH_PROTOFLAG_SCREEN_NUMBER)
.TE
Sent by the client during the preparatory phase, this message requests
that the server create a fake X11 display and set the DISPLAY
environment variable accordingly.  An internet-domain display is
preferable.  The given authentication protocol and the associated data
should be recorded by the server so that it is used as authentication
on connections (e.g., in .Xauthority).  The authentication protocol
must be one of the supported X11 authentication protocols, e.g.,
"MIT-MAGIC-COOKIE-1".  Authentication data must be a lowercase hex
string of even length.  Its interpretation is protocol dependent.
The data is in a format that can be used with e.g. the xauth program.
Supporting this message is optional.

The client is permitted (and recommended) to generate fake
authentication information and send fake information to the server.
This way, a corrupt server will not have access to the user's terminal
after the connection has terminated.  The correct authorization codes
will also not be left hanging around in files on the server (many
users keep the same X session for months, thus protecting the
authorization data becomes important).

X11 authentication spoofing works by initially sending fake (random)
authentication data to the server, and interpreting the first packet
sent by the X11 client after the connection has been opened.  The
first packet contains the client's authentication.  If the packet
contains the correct fake data, it is replaced by the client by the
correct authentication data, and then sent to the X server.
.IP "35 SSH_CMSG_AUTH_RHOSTS_RSA"
.TS
;
l l.
string	clint-side user name
32-bit int	client_host_key_bits
mp-int	client_host_key_public_exponent
mp-int	client_host_key_public_modulus
.TE
Requests authentication using /etc/hosts.equiv and .rhosts (or
equivalent) together with RSA host authentication.  The server should
check that the client side port number is less than 1024 (a privileged
port), and immediately reject authentication if it is not.  The server
responds with SSH_SMSG_FAILURE or SSH_SMSG_AUTH_RSA_CHALLENGE.  The
client must respond to the challenge with the proper
SSH_CMSG_AUTH_RSA_RESPONSE.  The server then responds with success if
access was granted, or failure if the client gave a wrong response.
Supporting this authentication method is optional but recommended in
most environments.
.IP "36 SSH_MSG_DEBUG"
.TS
;
l l.
string	debugging message sent to the other side
.TE
This message may be sent by either party at any time.  It is used to
send debugging messages that may be informative to the user in
solving various problems.  For example, if authentication fails
because of some configuration error (e.g., incorrect permissions for
some file), it can be very helpful for the user to make the cause of
failure available.  On the other hand, one should not make too much
information available for security reasons.  It is recommended that
the client provides an option to display the debugging information
sent by the sender (the user probably does not want to see it by default).
The server can log debugging data sent by the client (if any).  Either
party is free to ignore any received debugging data.  Every
implementation must be able to receive this message, but no
implementation is required to send these.
.IP "37 SSH_CMSG_REQUEST_COMPRESSION"
.TS
;
l l.
32-bit int	gzip compression level (1-9)
.TE
This message can be sent by the client in the preparatory operations
phase.  The server responds with SSH_SMSG_FAILURE if it does not
support compression or does not want to compress; it responds with
SSH_SMSG_SUCCESS if it accepted the compression request.  In the
latter case the response to this packet will still be uncompressed,
but all further packets in either direction will be compressed by gzip.
.RT


.ti 0
Encoding of Terminal Modes

Terminal modes (as passed in SSH_CMSG_REQUEST_PTY) 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
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
[POSIX] 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.
.IP "0 TTY_OP_END"
Indicates end of options.
.IP "1 VINTR"
Interrupt character; 255 if none.  Similarly for the other characters.
Not all of these characters are supported on all systems.
.IP "2 VQUIT"
The quit character (sends SIGQUIT signal on UNIX systems).
.IP "3 VERASE"
Erase the character to left of the cursor.
.IP "4 VKILL"
Kill the current input line.
.IP "5 VEOF "
End-of-file character (sends EOF from the terminal).
.IP "6 VEOL "
End-of-line character in addition to carriage return and/or linefeed.
.IP "7 VEOL2"
Additional end-of-line character.
.IP "8 VSTART"
Continues paused output (normally ^Q).
.IP "9 VSTOP"
Pauses output (^S).
.IP "10 VSUSP"
Suspends the current program.
.IP "11 VDSUSP"
Another suspend character.
.IP "12 VREPRINT"
Reprints the current input line.
.IP "13 VWERASE"
Erases a word left of cursor.
.IP "14 VLNEXT"
More special input characters; these are probably not supported on
most systems.
.IP "15 VFLUSH"
.IP "16 VSWTCH"
.IP "17 VSTATUS"
.IP "18 VDISCARD"

.IP "30 IGNPAR"
The ignore parity flag.  The next byte should be 0 if this flag is not
set, and 1 if it is set.
.IP "31 PARMRK"
More flags.  The exact definitions can be found in the POSIX standard.
.IP "32 INPCK"
.IP "33 ISTRIP"
.IP "34 INLCR"
.IP "35 IGNCR"
.IP "36 ICRNL"
.IP "37 IUCLC"
.IP "38 IXON"
.IP "39 IXANY"
.IP "40 IXOFF"
.IP "41 IMAXBEL"

.IP "50 ISIG"
.IP "51 ICANON"
.IP "52 XCASE"
.IP "53 ECHO"
.IP "54 ECHOE"
.IP "55 ECHOK"
.IP "56 ECHONL"
.IP "57 NOFLSH"
.IP "58 TOSTOP"
.IP "59 IEXTEN"
.IP "60 ECHOCTL"
.IP "61 ECHOKE"
.IP "62 PENDIN"

.IP "70 OPOST"
.IP "71 OLCUC"
.IP "72 ONLCR"
.IP "73 OCRNL"
.IP "74 ONOCR"
.IP "75 ONLRET"

.IP "90 CS7"
.IP "91 CS8"
.IP "92 PARENB"
.IP "93 PARODD"

.IP "192 TTY_OP_ISPEED"
Specifies the input baud rate in bits per second.
.IP "193 TTY_OP_OSPEED"
Specifies the output baud rate in bits per second.
.RT


.ti 0
The Authentication Agent Protocol

The authentication agent is a program that can be used to hold RSA
authentication keys for the user (in future, it might hold data for
other authentication types as well).  An authorized program can send
requests to the agent to generate a proper response to an RSA
challenge.  How the connection is made to the agent (or its
representative) inside a host and how access control is done inside a
host is implementation-dependent; however, how it is forwarded and how
one interacts with it is specified in this protocol.  The connection
to the agent is normally automatically forwarded over the secure
channel.

A program that wishes to use the agent first opens a connection to its
local representative (typically, the agent itself or an SSH server).
It then writes a request to the connection, and waits for response.
It is recommended that at least five minutes of timeout are provided
waiting for the agent to respond to an authentication challenge (this
gives sufficient time for the user to cut-and-paste the challenge to a
separate machine, perform the computation there, and cut-and-paste the
result back if so desired).

Messages sent to and by the agent are in the following format:
.TS
;
l l.
4 bytes	Length, msb first.  Does not include length itself.
1 byte	Packet type.  The value 255 is reserved for future extensions.
data	Any data, depending on packet type.  Encoding as in the ssh packet
protocol.
.TE

The following message types are currently defined:
.IP "1 SSH_AGENTC_REQUEST_RSA_IDENTITIES"

(no arguments)

Requests the agent to send a list of all RSA keys for which it can
answer a challenge.
.IP "2 SSH_AGENT_RSA_IDENTITIES_ANSWER"
.TS
;
l l.
32-bit int	howmany
howmany times:
32-bit int	bits
mp-int	public exponent
mp-int	public modulus
string	comment
.TE
The agent sends this message in response to the to
SSH_AGENTC_REQUEST_RSA_IDENTITIES.  The answer lists all RSA keys for
which the agent can answer a challenge.  The comment field is intended
to help identify each key; it may be printed by an application to
indicate which key is being used.  If the agent is not holding any
keys, howmany will be zero.
.IP "3 SSH_AGENTC_RSA_CHALLENGE
.TS
;
l l.
32-bit int	bits
mp-int	public exponent
mp-int	public modulus
mp-int	challenge
16 bytes	session_id
32-bit int	response_type
.TE
Requests RSA decryption of random challenge to authenticate the other
side.  The challenge will be decrypted with the RSA private key
corresponding to the given public key.

The decrypted challenge must contain a zero in the highest (partial)
byte, 2 in the next byte, followed by non-zero random bytes, a zero
byte, and then the real challenge value in the lowermost bytes.  The
real challenge must be 32 8-bit bytes (256 bits).

Response_type indicates the format of the response to be returned.
Currently the only supported value is 1, which means to compute MD5 of
the real challenge plus session id, and return the resulting 16 bytes
in a SSH_AGENT_RSA_RESPONSE message.
.IP "4 SSH_AGENT_RSA_RESPONSE"
.TS
;
l l.
16 bytes	MD5 of decrypted challenge
.TE
Answers an RSA authentication challenge.  The response is 16 bytes:
the MD5 checksum of the 32-byte challenge.
.IP "5 SSH_AGENT_FAILURE"

(no arguments)

This message is sent whenever the agent fails to answer a request
properly.  For example, if the agent cannot answer a challenge (e.g.,
no longer has the proper key), it can respond with this.  The agent
also responds with this message if it receives a message it does not
recognize.
.IP "6 SSH_AGENT_SUCCESS"

(no arguments)

This message is sent by the agent as a response to certain requests
that do not otherwise cause a message be sent.  Currently, this is
only sent in