You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mina.apache.org by gn...@apache.org on 2013/07/26 15:30:51 UTC
[2/9] Remove third party documents from scm
http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/rfc4254.txt
----------------------------------------------------------------------
diff --git a/sshd-core/src/docs/rfc4254.txt b/sshd-core/src/docs/rfc4254.txt
deleted file mode 100644
index ebbf4e6..0000000
--- a/sshd-core/src/docs/rfc4254.txt
+++ /dev/null
@@ -1,1347 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Ylonen
-Request for Comments: 4254 SSH Communications Security Corp
-Category: Standards Track C. Lonvick, Ed.
- Cisco Systems, Inc.
- January 2006
-
-
- The Secure Shell (SSH) Connection Protocol
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- Secure Shell (SSH) is a protocol for secure remote login and other
- secure network services over an insecure network.
-
- 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.
-
- The SSH Connection Protocol has been designed to run on top of the
- SSH transport layer and user authentication protocols.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 1]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 2. Contributors ....................................................3
- 3. Conventions Used in This Document ...............................3
- 4. Global Requests .................................................4
- 5. Channel Mechanism ...............................................5
- 5.1. Opening a Channel ..........................................5
- 5.2. Data Transfer ..............................................7
- 5.3. Closing a Channel ..........................................9
- 5.4. Channel-Specific Requests ..................................9
- 6. Interactive Sessions ...........................................10
- 6.1. Opening a Session .........................................10
- 6.2. Requesting a Pseudo-Terminal ..............................11
- 6.3. X11 Forwarding ............................................11
- 6.3.1. Requesting X11 Forwarding ..........................11
- 6.3.2. X11 Channels .......................................12
- 6.4. Environment Variable Passing ..............................12
- 6.5. Starting a Shell or a Command .............................13
- 6.6. Session Data Transfer .....................................14
- 6.7. Window Dimension Change Message ...........................14
- 6.8. Local Flow Control ........................................14
- 6.9. Signals ...................................................15
- 6.10. Returning Exit Status ....................................15
- 7. TCP/IP Port Forwarding .........................................16
- 7.1. Requesting Port Forwarding ................................16
- 7.2. TCP/IP Forwarding Channels ................................18
- 8. Encoding of Terminal Modes .....................................19
- 9. Summary of Message Numbers .....................................21
- 10. IANA Considerations ...........................................21
- 11. Security Considerations .......................................21
- 12. References ....................................................22
- 12.1. Normative References .....................................22
- 12.2. Informative References ...................................22
- Authors' Addresses ................................................23
- Trademark Notice ..................................................23
-
-1. Introduction
-
- The SSH Connection Protocol has been designed to run on top of the
- SSH transport layer and user authentication protocols ([SSH-TRANS]
- and [SSH-USERAUTH]). It provides interactive login sessions, remote
- execution of commands, forwarded TCP/IP connections, and forwarded
- X11 connections.
-
- The 'service name' for this protocol is "ssh-connection".
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 2]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- This document should be read only after reading the SSH architecture
- document [SSH-ARCH]. This document freely uses terminology and
- notation from the architecture document without reference or further
- explanation.
-
-2. Contributors
-
- The major original contributors of this set of documents have been:
- Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
- Communications Security Corp), and Markku-Juhani O. Saarinen
- (University of Jyvaskyla). Darren Moffat was the original editor of
- this set of documents and also made very substantial contributions.
-
- Many people contributed to the development of this document over the
- years. People who should be acknowledged include Mats Andersson, Ben
- Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller,
- Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff
- Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph
- Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas
- Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon
- Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and
- Tadayoshi Kohno. Listing their names here does not mean that they
- endorse this document, but that they have contributed to it.
-
-3. Conventions Used in This Document
-
- All documents related to the SSH protocols shall use the keywords
- "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
- "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
- requirements. These keywords are to be interpreted as described in
- [RFC2119].
-
- The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
- FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
- APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
- this document when used to describe namespace allocation are to be
- interpreted as described in [RFC2434].
-
- Protocol fields and possible values to fill them are defined in this
- set of documents. Protocol fields will be defined in the message
- definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as
- follows.
-
- byte SSH_MSG_CHANNEL_DATA
- uint32 recipient channel
- string data
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 3]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- Throughout these documents, when the fields are referenced, they will
- appear within single quotes. When values to fill those fields are
- referenced, they will appear within double quotes. Using the above
- example, possible values for 'data' are "foo" and "bar".
-
-4. 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. Note that
- both the client and server MAY send global requests at any time, and
- the receiver MUST respond appropriately. All such requests use the
- following format.
-
- byte SSH_MSG_GLOBAL_REQUEST
- string request name in US-ASCII only
- boolean want reply
- .... request-specific data follows
-
- The value of 'request name' follows the DNS extensibility naming
- convention outlined in [SSH-ARCH].
-
- The recipient will respond to this message with
- SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is
- TRUE.
-
- byte SSH_MSG_REQUEST_SUCCESS
- .... response specific data
-
- Usually, the 'response specific data' is non-existent.
-
- If the recipient does not recognize or support the request, it simply
- responds with SSH_MSG_REQUEST_FAILURE.
-
- byte SSH_MSG_REQUEST_FAILURE
-
- In general, the reply messages do not include request type
- identifiers. To make it possible for the originator of a request to
- identify to which request each reply refers, it is REQUIRED that
- replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as
- the corresponding request messages. For channel requests, replies
- that relate to the same channel MUST also be replied to in the right
- order. However, channel requests for distinct channels MAY be
- replied to out-of-order.
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 4]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-5. Channel Mechanism
-
- All terminal sessions, forwarded connections, etc., are channels.
- Either side may open a channel. Multiple channels are multiplexed
- into a 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.
-
-5.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 in US-ASCII only
- uint32 sender channel
- uint32 initial window size
- uint32 maximum packet size
- .... channel type specific data follows
-
- The 'channel type' is a name, as described in [SSH-ARCH] and
- [SSH-NUMBERS], with similar extension mechanisms. The 'sender
- channel' is a local identifier for the channel used by the sender of
- this message. The 'initial window size' specifies how many bytes of
- channel data can be sent to the sender of this message without
- adjusting the window. The 'maximum 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 SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
- SSH_MSG_CHANNEL_OPEN_FAILURE.
-
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 5]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
- uint32 recipient channel
- uint32 sender channel
- uint32 initial window size
- uint32 maximum packet size
- .... channel type specific data follows
-
- The 'recipient channel' is the channel number given in the original
- open request, and 'sender channel' is the channel number allocated by
- the other side.
-
- byte SSH_MSG_CHANNEL_OPEN_FAILURE
- uint32 recipient channel
- uint32 reason code
- string description in ISO-10646 UTF-8 encoding [RFC3629]
- string language tag [RFC3066]
-
- 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 client MAY show the 'description'
- string to the user. If this is done, the client software should take
- the precautions discussed in [SSH-ARCH].
-
- The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in
- the following table. Note that the values for the 'reason code' are
- given in decimal format for readability, but they are actually uint32
- values.
-
- Symbolic name reason code
- ------------- -----------
- SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
- SSH_OPEN_CONNECT_FAILED 2
- SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
- SSH_OPEN_RESOURCE_SHORTAGE 4
-
- Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
- values (and associated 'description' text) in the range of 0x00000005
- to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
- described in [RFC2434]. The IANA will not assign Channel Connection
- Failure 'reason code' values in the range of 0xFE000000 to
- 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that
- range are left for PRIVATE USE, as described in [RFC2434].
-
- While it is understood that the IANA will have no control over the
- range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two
- parts and administered by the following conventions.
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 6]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction
- with locally assigned channels. For example, if a channel is
- proposed with a 'channel type' of "example_session@example.com",
- but fails, then the response will contain either a 'reason code'
- assigned by the IANA (as listed above and in the range of
- 0x00000001 to 0xFDFFFFFF) or a locally assigned value in the range
- of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does not
- understand the proposed 'channel type', even if it is a locally
- defined 'channel type', then the 'reason code' MUST be 0x00000003,
- as described above, if the 'reason code' is sent. If the server
- does understand the 'channel type', but the channel still fails to
- open, then the server SHOULD respond with a locally assigned
- 'reason code' value consistent with the proposed, local 'channel
- type'. It is assumed that practitioners will first attempt to use
- the IANA assigned 'reason code' values and then document their
- locally assigned 'reason code' values.
-
- o There are no restrictions or suggestions for the range starting
- with 0xFF. No interoperability is expected for anything used in
- this range. Essentially, it is for experimentation.
-
-5.2. Data Transfer
-
- 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 following message to adjust the window.
-
- byte SSH_MSG_CHANNEL_WINDOW_ADJUST
- uint32 recipient channel
- uint32 bytes to add
-
- After receiving this message, the recipient MAY send the given number
- of bytes more than it was previously allowed to send; the window size
- is incremented. Implementations MUST correctly handle window sizes
- of up to 2^32 - 1 bytes. The window MUST NOT be increased above
- 2^32 - 1 bytes.
-
- 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 determined by the maximum
- packet size for the channel, and the current window size, whichever
- is smaller. The window size is decremented by the amount of data
- sent. Both parties MAY ignore all extra data sent after the allowed
- window is empty.
-
-
-
-Ylonen & Lonvick Standards Track [Page 7]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- Implementations are expected to have some limit on the SSH transport
- layer packet size (any limit for received packets MUST be 32768 bytes
- or larger, as described in [SSH-TRANS]). The implementation of the
- SSH connection layer
-
- o MUST NOT advertise a maximum packet size that would result in
- transport packets larger than its transport layer is willing to
- receive.
-
- o MUST NOT generate data packets larger than its transport layer is
- willing to send, even if the remote end would be willing to accept
- very large packets.
-
- 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 data. The available types and
- their interpretation depend on the type of channel.
-
- 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. Note that the value
- for the 'data_type_code' is given in decimal format for readability,
- but the values are actually uint32 values.
-
- Symbolic name data_type_code
- ------------- --------------
- SSH_EXTENDED_DATA_STDERR 1
-
- Extended Channel Data Transfer 'data_type_code' values MUST be
- assigned sequentially. Requests for assignments of new Extended
- Channel Data Transfer 'data_type_code' values and their associated
- Extended Channel Data Transfer 'data' strings, in the range of
- 0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS
- method as described in [RFC2434]. The IANA will not assign Extended
- Channel Data Transfer 'data_type_code' values in the range of
- 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer
- 'data_type_code' values in that range are left for PRIVATE USE, as
- described in [RFC2434]. As is noted, the actual instructions to the
- IANA are in [SSH-NUMBERS].
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 8]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-5.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. A party MAY send
- SSH_MSG_CHANNEL_CLOSE without having sent or received
- SSH_MSG_CHANNEL_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 all data sent before this message be delivered
- to the actual destination, if possible.
-
-5.4. Channel-Specific Requests
-
- Many 'channel type' values have extensions that are specific to that
- particular 'channel type'. An example is requesting a pty (pseudo
- terminal) for an interactive session.
-
- All channel-specific requests use the following format.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string request type in US-ASCII characters only
- boolean want reply
- .... type-specific data follows
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 9]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- If 'want reply' is FALSE, no response will be sent to the request.
- Otherwise, the recipient responds with either
- SSH_MSG_CHANNEL_SUCCESS, 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. The values of 'request type' are local to
- each channel type.
-
- The client is allowed to send further messages without waiting for
- the response to the request.
-
- 'request type' names follow the DNS extensibility naming convention
- outlined in [SSH-ARCH] and [SSH-NUMBERS].
-
- 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.
-
-6. Interactive Sessions
-
- A session is a remote execution of a program. The program may be a
- shell, an application, a system command, 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.
-
-6.1. Opening a Session
-
- A session is started by sending the following message.
-
- byte SSH_MSG_CHANNEL_OPEN
- string "session"
- uint32 sender channel
- uint32 initial window size
- uint32 maximum packet size
-
- Client implementations SHOULD reject any session channel open
- requests to make it more difficult for a corrupt server to attack the
- client.
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 10]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-6.2. Requesting a Pseudo-Terminal
-
- A pseudo-terminal can be allocated for the session by sending the
- following message.
-
- 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., 640)
- uint32 terminal height, pixels (e.g., 480)
- string encoded terminal modes
-
- The 'encoded terminal modes' are described in Section 8. Zero
- dimension parameters MUST be ignored. The character/row dimensions
- override the pixel dimensions (when nonzero). Pixel dimensions refer
- to the drawable area of the window.
-
- The dimension parameters are only informational.
-
- The client SHOULD ignore pty requests.
-
-6.3. X11 Forwarding
-
-6.3.1. Requesting X11 Forwarding
-
- X11 forwarding may be requested for a session by sending a
- SSH_MSG_CHANNEL_REQUEST message.
-
- 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 'x11 authentication cookie' that is sent
- be a fake, random cookie, and that the cookie be 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.
-
-
-
-Ylonen & Lonvick Standards Track [Page 11]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- 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.
-
- The 'x11 authentication protocol' is the name of the X11
- authentication method used, e.g., "MIT-MAGIC-COOKIE-1".
-
- The 'x11 authentication cookie' MUST be hexadecimal encoded.
-
- The X Protocol is documented in [SCHEIFLER].
-
-6.3.2. X11 Channels
-
- X11 channels are opened with a channel open request. The resulting
- channels are independent of the session, and closing the session
- channel does not close the forwarded X11 channels.
-
- byte SSH_MSG_CHANNEL_OPEN
- string "x11"
- uint32 sender channel
- uint32 initial window size
- uint32 maximum packet size
- string originator address (e.g., "192.168.7.38")
- uint32 originator port
-
- The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION
- or SSH_MSG_CHANNEL_OPEN_FAILURE.
-
- Implementations MUST reject any X11 channel open requests if they
- have not requested X11 forwarding.
-
-6.4. Environment Variable Passing
-
- Environment variables may be passed to the shell/command to be
- started later. Uncontrolled setting of environment variables in a
- privileged process can be a security hazard. It is recommended that
- implementations either maintain a list of allowable variable names or
- only set environment variables after the server process has dropped
- sufficient privileges.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "env"
- boolean want reply
- string variable name
- string variable value
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 12]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-6.5. Starting a Shell or a Command
-
- Once the session has been set up, a program is started at the remote
- end. The program can be a shell, an application program, or a
- subsystem with a host-independent name. Only one of these requests
- can succeed per channel.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "shell"
- boolean want reply
-
- This message will request that the user's default shell (typically
- defined in /etc/passwd in UNIX systems) be started at the other end.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "exec"
- boolean want reply
- string command
-
- This message will request that the server start the execution of the
- given command. The 'command' string may contain a path. Normal
- precautions MUST be taken to prevent the execution of unauthorized
- commands.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "subsystem"
- boolean want reply
- string subsystem name
-
- This last form executes a predefined subsystem. It is expected that
- these will include a general file transfer mechanism, and possibly
- other features. Implementations may also allow configuring more such
- mechanisms. As the user's shell is usually used to execute the
- subsystem, it is advisable for the subsystem protocol to have a
- "magic cookie" at the beginning of the protocol transaction to
- distinguish it from arbitrary output generated by shell
- initialization scripts, etc. This spurious output from the shell may
- be filtered out either at the server or at the client.
-
- 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 redirected to the channel or to the encrypted tunnel.
-
- It is RECOMMENDED that the reply to these messages be requested and
- checked. The client SHOULD ignore these messages.
-
-
-
-Ylonen & Lonvick Standards Track [Page 13]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- Subsystem names follow the DNS extensibility naming convention
- outlined in [SSH-NUMBERS].
-
-6.6. 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.
-
-6.7. Window Dimension Change Message
-
- 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.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "window-change"
- boolean FALSE
- uint32 terminal width, columns
- uint32 terminal height, rows
- uint32 terminal width, pixels
- uint32 terminal height, pixels
-
- A response SHOULD NOT be sent to this message.
-
-6.8. Local Flow Control
-
- 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, 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 notification. Initially, the server is responsible for
- flow control. (Here, again, client means the 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 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 MAY ignore this message.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "xon-xoff"
- boolean FALSE
- boolean client can do
-
- No response is sent to this message.
-
-
-
-Ylonen & Lonvick Standards Track [Page 14]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-6.9. 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 SHOULD ignore this message.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "signal"
- boolean FALSE
- string signal name (without the "SIG" prefix)
-
- 'signal name' values will be encoded as discussed in the passage
- describing SSH_MSG_CHANNEL_REQUEST messages using "exit-signal" in
- this section.
-
-6.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 the status is RECOMMENDED. No acknowledgement is sent for
- this message. The channel needs to be closed with
- SSH_MSG_CHANNEL_CLOSE after this message.
-
- The client MAY ignore these messages.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "exit-status"
- boolean 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. A zero
- 'exit_status' usually means that the command terminated successfully.
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "exit-signal"
- boolean FALSE
- string signal name (without the "SIG" prefix)
- boolean core dumped
- string error message in ISO-10646 UTF-8 encoding
- string language tag [RFC3066]
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 15]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- 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 name' values MAY be sent in the format
- "sig-name@xyz", where "sig-name" and "xyz" may be anything a
- particular implementer wants (except the "@" sign). However, it is
- suggested that if a 'configure' script is used, any non-standard
- 'signal name' values it finds be encoded as "SIG@xyz.config.guess",
- where "SIG" is the 'signal name' without the "SIG" prefix, and "xyz"
- is the host type, as determined by "config.guess".
-
- The 'error message' contains an additional textual explanation of the
- error message. The message may consist of multiple lines separated
- by CRLF (Carriage Return - Line Feed) pairs. The client software MAY
- display this message to the user. If this is done, the client
- software should take the precautions discussed in [SSH-ARCH].
-
-7. TCP/IP Port Forwarding
-
-7.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
- 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 (e.g., "0.0.0.0")
- uint32 port number to bind
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 16]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- The 'address to bind' and 'port number to bind' specify the IP
- address (or domain name) and port on which connections for forwarding
- are to be accepted. Some strings used for 'address to bind' have
- special-case semantics.
-
- o "" means that connections are to be accepted on all protocol
- families supported by the SSH implementation.
-
- o "0.0.0.0" means to listen on all IPv4 addresses.
-
- o "::" means to listen on all IPv6 addresses.
-
- o "localhost" means to listen on all protocol families supported by
- the SSH implementation on loopback addresses only ([RFC3330] and
- [RFC3513]).
-
- o "127.0.0.1" and "::1" indicate listening on the loopback
- interfaces for IPv4 and IPv6, respectively.
-
- 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.
-
- Client implementations SHOULD reject these messages; they are
- normally only sent by the client.
-
- If a client passes 0 as port number to bind and has 'want reply' as
- TRUE, then the server allocates the next available unprivileged port
- number and replies with the following message; otherwise, there is no
- response-specific data.
-
- byte SSH_MSG_REQUEST_SUCCESS
- uint32 port that was bound on the server
-
- A port forwarding can be canceled 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 (e.g., "127.0.0.1")
- uint32 port number to bind
-
- Client implementations SHOULD reject these messages; they are
- normally only sent by the client.
-
-
-
-Ylonen & Lonvick Standards Track [Page 17]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-7.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.
-
- byte SSH_MSG_CHANNEL_OPEN
- string "forwarded-tcpip"
- uint32 sender channel
- uint32 initial window size
- uint32 maximum packet size
- string address that was connected
- uint32 port that was connected
- string originator IP address
- uint32 originator port
-
- Implementations MUST reject these messages unless they have
- 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
- following packet is sent to the other side. Note that these messages
- MAY also be sent 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 maximum packet size
- string host to connect
- uint32 port to connect
- string originator IP address
- uint32 originator port
-
- The 'host to connect' and 'port to connect' specify the TCP/IP host
- and port where the recipient should connect the channel. The 'host
- to connect' may be either a domain name or a numeric IP address.
-
- The 'originator IP address' is the numeric IP address of the machine
- from where the connection request originates, and the 'originator
- port' is the port on the host from where the connection originated.
-
- 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.
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 18]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- Client implementations SHOULD reject direct TCP/IP open requests for
- security reasons.
-
-8. Encoding of Terminal Modes
-
- All 'encoded 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 stream consists of opcode-
- argument pairs wherein the opcode is a byte value. 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 stream is terminated by opcode TTY_OP_END
- (0x00).
-
- The client SHOULD put any modes it knows about in the stream, and the
- server MAY ignore 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 naming of opcode values mostly follows the POSIX terminal mode
- flags. The following opcode values have been defined. Note that the
- values given below are in decimal format for readability, but they
- are actually byte values.
-
- opcode mnemonic description
- ------ -------- -----------
- 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
- POSIX 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.
- 11 VDSUSP Another suspend character.
-
-
-
-Ylonen & Lonvick Standards Track [Page 19]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- 12 VREPRINT Reprints the current input line.
- 13 VWERASE Erases a word left of cursor.
- 14 VLNEXT Enter the next character typed literally,
- even if it is a special character
- 15 VFLUSH Character to flush output.
- 16 VSWTCH Switch to a different shell layer.
- 17 VSTATUS Prints system status line (load, command,
- pid, etc).
- 18 VDISCARD Toggles the flushing of terminal output.
- 30 IGNPAR The ignore parity flag. The parameter
- SHOULD be 0 if this flag is FALSE,
- and 1 if it is TRUE.
- 31 PARMRK Mark parity and framing errors.
- 32 INPCK Enable checking of parity errors.
- 33 ISTRIP Strip 8th bit off characters.
- 34 INLCR Map NL into CR on input.
- 35 IGNCR Ignore CR on input.
- 36 ICRNL Map CR to NL on input.
- 37 IUCLC Translate uppercase characters to
- lowercase.
- 38 IXON Enable output flow control.
- 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, [D]SUSP.
- 51 ICANON Canonicalize input lines.
- 52 XCASE Enable input and output of uppercase
- characters by preceding their lowercase
- equivalents with "\".
- 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.
- 72 ONLCR Map NL to CR-NL.
- 73 OCRNL Translate carriage return to newline
- (output).
- 74 ONOCR Translate newline to carriage
- return-newline (output).
- 75 ONLRET Newline performs a carriage return
- (output).
-
-
-
-Ylonen & Lonvick Standards Track [Page 20]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- 90 CS7 7 bit mode.
- 91 CS8 8 bit mode.
- 92 PARENB Parity enable.
- 93 PARODD Odd parity, else even.
-
- 128 TTY_OP_ISPEED Specifies the input baud rate in
- bits per second.
- 129 TTY_OP_OSPEED Specifies the output baud rate in
- bits per second.
-
-9. Summary of Message Numbers
-
- The following is a summary of messages and their associated message
- number.
-
- SSH_MSG_GLOBAL_REQUEST 80
- SSH_MSG_REQUEST_SUCCESS 81
- SSH_MSG_REQUEST_FAILURE 82
- SSH_MSG_CHANNEL_OPEN 90
- SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91
- SSH_MSG_CHANNEL_OPEN_FAILURE 92
- SSH_MSG_CHANNEL_WINDOW_ADJUST 93
- SSH_MSG_CHANNEL_DATA 94
- SSH_MSG_CHANNEL_EXTENDED_DATA 95
- SSH_MSG_CHANNEL_EOF 96
- SSH_MSG_CHANNEL_CLOSE 97
- SSH_MSG_CHANNEL_REQUEST 98
- SSH_MSG_CHANNEL_SUCCESS 99
- SSH_MSG_CHANNEL_FAILURE 100
-
-10. IANA Considerations
-
- This document is part of a set. The IANA considerations for the SSH
- protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and
- this document, are detailed in [SSH-NUMBERS].
-
-11. Security Considerations
-
- This protocol is assumed to run on top of a secure, authenticated
- transport. User authentication and protection against network-level
- attacks are assumed to be provided by the underlying protocols.
-
- Full security considerations for this protocol are provided in
- [SSH-ARCH]. Specific to this document, it is RECOMMENDED that
- implementations disable all the potentially dangerous features (e.g.,
- agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host
- key has changed without notice or explanation.
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 21]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-12. References
-
-12.1. Normative References
-
- [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
- (SSH) Protocol Architecture", RFC 4251, January 2006.
-
- [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
- (SSH) Transport Layer Protocol", RFC 4253, January
- 2006.
-
- [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
- (SSH) Authentication Protocol", RFC 4252, January
- 2006.
-
- [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
- (SSH) Protocol Assigned Numbers", RFC 4250, January
- 2006.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
- an IANA Considerations Section in RFCs", BCP 26, RFC
- 2434, October 1998.
-
- [RFC3066] Alvestrand, H., "Tags for the Identification of
- Languages", BCP 47, RFC 3066, January 2001.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
-12.2. Informative References
-
- [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
- September 2002.
-
- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version
- 6 (IPv6) Addressing Architecture", RFC 3513, April
- 2003.
-
- [SCHEIFLER] Scheifler, R., "X Window System : The Complete
- Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
- edition.", Digital Press ISBN 1555580882, February
- 1992.
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 22]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
- [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable
- Operating System Interface (POSIX)-Part 1: System
- Application Program Interface (API) C Language", ANSI/
- IEE Std 1003.1, July 1996.
-
-Authors' Addresses
-
- Tatu Ylonen
- SSH Communications Security Corp
- Valimotie 17
- 00380 Helsinki
- Finland
-
- EMail: ylo@ssh.com
-
-
- Chris Lonvick (editor)
- Cisco Systems, Inc.
- 12515 Research Blvd.
- Austin 78759
- USA
-
- EMail: clonvick@cisco.com
-
-Trademark Notice
-
- "ssh" is a registered trademark in the United States and/or other
- countries.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 23]
-
-RFC 4254 SSH Connection Protocol January 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Ylonen & Lonvick Standards Track [Page 24]
-
http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/rfc4255.txt
----------------------------------------------------------------------
diff --git a/sshd-core/src/docs/rfc4255.txt b/sshd-core/src/docs/rfc4255.txt
deleted file mode 100644
index f350b7a..0000000
--- a/sshd-core/src/docs/rfc4255.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Schlyter
-Request for Comments: 4255 OpenSSH
-Category: Standards Track W. Griffin
- SPARTA
- January 2006
-
-
- Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes a method of verifying Secure Shell (SSH) host
- keys using Domain Name System Security (DNSSEC). The document
- defines a new DNS resource record that contains a standard SSH key
- fingerprint.
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 2. SSH Host Key Verification .......................................2
- 2.1. Method .....................................................2
- 2.2. Implementation Notes .......................................2
- 2.3. Fingerprint Matching .......................................3
- 2.4. Authentication .............................................3
- 3. The SSHFP Resource Record .......................................3
- 3.1. The SSHFP RDATA Format .....................................4
- 3.1.1. Algorithm Number Specification ......................4
- 3.1.2. Fingerprint Type Specification ......................4
- 3.1.3. Fingerprint .........................................5
- 3.2. Presentation Format of the SSHFP RR ........................5
- 4. Security Considerations .........................................5
- 5. IANA Considerations .............................................6
- 6. Normative References ............................................7
- 7. Informational References ........................................7
- 8. Acknowledgements ................................................8
-
-
-
-
-Schlyter & Griffin Standards Track [Page 1]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
-1. Introduction
-
- The SSH [6] protocol provides secure remote login and other secure
- network services over an insecure network. The security of the
- connection relies on the server authenticating itself to the client
- as well as the user authenticating itself to the server.
-
- If a connection is established to a server whose public key is not
- already known to the client, a fingerprint of the key is presented to
- the user for verification. If the user decides that the fingerprint
- is correct and accepts the key, the key is saved locally and used for
- verification for all following connections. While some security-
- conscious users verify the fingerprint out-of-band before accepting
- the key, many users blindly accept the presented key.
-
- The method described here can provide out-of-band verification by
- looking up a fingerprint of the server public key in the DNS [1][2]
- and using DNSSEC [5] to verify the lookup.
-
- In order to distribute the fingerprint using DNS, this document
- defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
- Basic understanding of the DNS system [1][2] and the DNS security
- extensions [5] is assumed by this document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [3].
-
-2. SSH Host Key Verification
-
-2.1. Method
-
- Upon connection to an SSH server, the SSH client MAY look up the
- SSHFP resource record(s) for the host it is connecting to. If the
- algorithm and fingerprint of the key received from the SSH server
- match the algorithm and fingerprint of one of the SSHFP resource
- record(s) returned from DNS, the client MAY accept the identity of
- the server.
-
-2.2. Implementation Notes
-
- Client implementors SHOULD provide a configurable policy used to
- select the order of methods used to verify a host key. This document
- defines one method: Fingerprint storage in DNS. Another method
- defined in the SSH Architecture [6] uses local files to store keys
- for comparison. Other methods that could be defined in the future
- might include storing fingerprints in LDAP or other databases. A
-
-
-
-Schlyter & Griffin Standards Track [Page 2]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
- configurable policy will allow administrators to determine which
- methods they want to use and in what order the methods should be
- prioritized. This will allow administrators to determine how much
- trust they want to place in the different methods.
-
- One specific scenario for having a configurable policy is where
- clients do not use fully qualified host names to connect to servers.
- In this scenario, the implementation SHOULD verify the host key
- against a local database before verifying the key via the fingerprint
- returned from DNS. This would help prevent an attacker from
- injecting a DNS search path into the local resolver and forcing the
- client to connect to a different host.
-
-2.3. Fingerprint Matching
-
- The public key and the SSHFP resource record are matched together by
- comparing algorithm number and fingerprint.
-
- The public key algorithm and the SSHFP algorithm number MUST
- match.
-
- A message digest of the public key, using the message digest
- algorithm specified in the SSHFP fingerprint type, MUST match the
- SSHFP fingerprint.
-
-2.4. Authentication
-
- A public key verified using this method MUST NOT be trusted if the
- SSHFP resource record (RR) used for verification was not
- authenticated by a trusted SIG RR.
-
- Clients that do validate the DNSSEC signatures themselves SHOULD use
- standard DNSSEC validation procedures.
-
- Clients that do not validate the DNSSEC signatures themselves MUST
- use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
- between themselves and the entity performing the signature
- validation.
-
-3. The SSHFP Resource Record
-
- The SSHFP resource record (RR) is used to store a fingerprint of an
- SSH public host key that is associated with a Domain Name System
- (DNS) name.
-
- The RR type code for the SSHFP RR is 44.
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 3]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
-3.1. The SSHFP RDATA Format
-
- The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
- type and the fingerprint of the public host key.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | fp type | /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
- / /
- / fingerprint /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.1.1. Algorithm Number Specification
-
- This algorithm number octet describes the algorithm of the public
- key. The following values are assigned:
-
- Value Algorithm name
- ----- --------------
- 0 reserved
- 1 RSA
- 2 DSS
-
- Reserving other types requires IETF consensus [4].
-
-3.1.2. Fingerprint Type Specification
-
- The fingerprint type octet describes the message-digest algorithm
- used to calculate the fingerprint of the public key. The following
- values are assigned:
-
- Value Fingerprint type
- ----- ----------------
- 0 reserved
- 1 SHA-1
-
- Reserving other types requires IETF consensus [4].
-
- For interoperability reasons, as few fingerprint types as possible
- should be reserved. The only reason to reserve additional types is
- to increase security.
-
-
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 4]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
-3.1.3. Fingerprint
-
- The fingerprint is calculated over the public key blob as described
- in [7].
-
- The message-digest algorithm is presumed to produce an opaque octet
- string output, which is placed as-is in the RDATA fingerprint field.
-
-3.2. Presentation Format of the SSHFP RR
-
- The RDATA of the presentation format of the SSHFP resource record
- consists of two numbers (algorithm and fingerprint type) followed by
- the fingerprint itself, presented in hex, e.g.:
-
- host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
- The use of mnemonics instead of numbers is not allowed.
-
-4. Security Considerations
-
- Currently, the amount of trust a user can realistically place in a
- server key is proportional to the amount of attention paid to
- verifying that the public key presented actually corresponds to the
- private key of the server. If a user accepts a key without verifying
- the fingerprint with something learned through a secured channel, the
- connection is vulnerable to a man-in-the-middle attack.
-
- The overall security of using SSHFP for SSH host key verification is
- dependent on the security policies of the SSH host administrator and
- DNS zone administrator (in transferring the fingerprint), detailed
- aspects of how verification is done in the SSH implementation, and in
- the client's diligence in accessing the DNS in a secure manner.
-
- One such aspect is in which order fingerprints are looked up (e.g.,
- first checking local file and then SSHFP). We note that, in addition
- to protecting the first-time transfer of host keys, SSHFP can
- optionally be used for stronger host key protection.
-
- If SSHFP is checked first, new SSH host keys may be distributed by
- replacing the corresponding SSHFP in DNS.
-
- If SSH host key verification can be configured to require SSHFP,
- SSH host key revocation can be implemented by removing the
- corresponding SSHFP from DNS.
-
-
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 5]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
- As stated in Section 2.2, we recommend that SSH implementors provide
- a policy mechanism to control the order of methods used for host key
- verification. One specific scenario for having a configurable policy
- is where clients use unqualified host names to connect to servers.
- In this case, we recommend that SSH implementations check the host
- key against a local database before verifying the key via the
- fingerprint returned from DNS. This would help prevent an attacker
- from injecting a DNS search path into the local resolver and forcing
- the client to connect to a different host.
-
- A different approach to solve the DNS search path issue would be for
- clients to use a trusted DNS search path, i.e., one not acquired
- through DHCP or other autoconfiguration mechanisms. Since there is
- no way with current DNS lookup APIs to tell whether a search path is
- from a trusted source, the entire client system would need to be
- configured with this trusted DNS search path.
-
- Another dependency is on the implementation of DNSSEC itself. As
- stated in Section 2.4, we mandate the use of secure methods for
- lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
- is especially important if SSHFP is to be used as a basis for host
- key rollover and/or revocation, as described above.
-
- Since DNSSEC only protects the integrity of the host key fingerprint
- after it is signed by the DNS zone administrator, the fingerprint
- must be transferred securely from the SSH host administrator to the
- DNS zone administrator. This could be done manually between the
- administrators or automatically using secure DNS dynamic update [11]
- between the SSH server and the nameserver. We note that this is no
- different from other key enrollment situations, e.g., a client
- sending a certificate request to a certificate authority for signing.
-
-5. IANA Considerations
-
- IANA has allocated the RR type code 44 for SSHFP from the standard RR
- type space.
-
- IANA has opened a new registry for the SSHFP RR type for public key
- algorithms. The defined types are:
-
- 0 is reserved
- 1 is RSA
- 2 is DSA
-
- Adding new reservations requires IETF consensus [4].
-
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 6]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
- IANA has opened a new registry for the SSHFP RR type for fingerprint
- types. The defined types are:
-
- 0 is reserved
- 1 is SHA-1
-
- Adding new reservations requires IETF consensus [4].
-
-6. Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
- [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [6] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
- Protocol Architecture", RFC 4251, January 2006.
-
- [7] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
- Transport Layer Protocol", RFC 4253, January 2006.
-
-7. Informational References
-
- [8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
- Roadmap", RFC 2411, November 1998.
-
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 7]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
- [9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [10] Eastlake 3rd, D., "DNS Request and Transaction Signatures
- ( SIG(0)s )", RFC 2931, September 2000.
-
- [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-8. Acknowledgements
-
- The authors gratefully acknowledge, in no particular order, the
- contributions of the following persons:
-
- Martin Fredriksson
-
- Olafur Gudmundsson
-
- Edward Lewis
-
- Bill Sommerfeld
-
-Authors' Addresses
-
- Jakob Schlyter
- OpenSSH
- 812 23rd Avenue SE
- Calgary, Alberta T2G 1N8
- Canada
-
- EMail: jakob@openssh.com
- URI: http://www.openssh.com/
-
-
- Wesley Griffin
- SPARTA
- 7075 Samuel Morse Drive
- Columbia, MD 21046
- USA
-
- EMail: wgriffin@sparta.com
- URI: http://www.sparta.com/
-
-
-
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 8]
-
-RFC 4255 DNS and SSH Fingerprints January 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Schlyter & Griffin Standards Track [Page 9]
-